O slideshow foi denunciado.
Utilizamos seu perfil e dados de atividades no LinkedIn para personalizar e exibir anúncios mais relevantes. Altere suas preferências de anúncios quando desejar.
What’s new in PHP7
PHP7で変わること
̶̶言語仕様とエンジンの改善ポイント
hnw
PHPカンファレンス関西2015
(2015/5/30)発表資料
自己紹介
❖ @hnw
❖ 勤務先:KLab株式会社
❖ カレーとバグが大好物
❖ PHP歴15年
❖ PHPや周辺エクステンションにバグレポ・PR多数
アジェンダ
❖ PHP7、さいきんどう?
❖ PHP7の新機能
❖ 性能改善と背景
❖ データ構造の変更
❖ HHVMとPHP
まずはアンケート
PHP7って

聞いたことがある人?
実際にPHP7を

動かしたことがある人?
❖ PHP7、さいきんどう?
❖ PHP7の新機能
❖ 性能改善と背景
❖ データ構造の変更
❖ HHVMとPHP
PHP7?
❖ PHP 5.6.xの次のバージョンがPHP 7.0.0
❖ PHP6はスキップ
❖ 約10年ぶりのメジャーバージョンアップ
さいきんのPHP7
❖ 予定通り3月に新機能の導入を凍結
❖ RFCが大量に出ていたので個人的に心配していた
❖ そろそろalpha1を出す予定だったが、遅延ぎみ
❖ まだ議論が残っているため
❖ 11月にPHP7リリース予定
PHPのRFCシステム
❖ 新機能の導入にはRFCと呼ばれる説明ページが必要
❖ 提案内容や変更による影響などを書く
❖ MLで議論後、投票によって採用・不採用が決まる
❖ 過半数または2/3以上の同意が必要(内容による)
❖ スピード感は無い...
PHP7に対するRFC
❖ PHP7で採択されたRFCは48個
❖ 参考:PHP 5.6は17個、PHP 5.5は20個
→普段のマイナーバージョンアップよりは変化が大きい
PHP7で変わらないこと
❖ PHPは言語仕様の変更に対して非常に保守的
❖ PHP7でも後方互換性は重視されている
❖ 移行コストは十分低いはず
❖ PHP7、さいきんどう?
❖ PHP7の新機能
❖ 性能改善と背景
❖ データ構造の変更
❖ HHVMとPHP
致命的エラーが例外になった
❖ PHP5までの致命的エラー
❖ エラーハンドリングできず、即座に終了していた
❖ PHP7の致命的エラー
❖ EngineExceptionという新しい例外になった
❖ トップレベルに到達すると今まで通りのエラー...
??演算子の新設
❖ nullでなければその値を、nullなら右オペランドを返す
❖ isset()と同様に未定義値に対しても使える
❖ ようやくisset()地獄から解放されるぞ!
無名クラスの導入
❖ クラス定義と同時にインスタンス化できる構文を導入
❖ その場限りのインスタンスを作りたいときに便利
AST(抽象構文木)の導入
❖ 解釈フェーズが

1段増えた
❖ 文法解釈の柔軟性が

上がった
❖ opcode最適化
Zend VM
opcode
Parser
Lexer
token
PHP
Zend VM
opcode
Parser
L...
返り値のタイプヒントをサポート
❖ 関数の返り値に型が指定できるようになった
❖ 抽象クラスやインターフェースで指定すると便利
スカラ型のタイプヒントをサポート
❖ 以下の型が引数・返り値で指定できるようになった
❖ int型
❖ float型
❖ string型
❖ bool型
❖ ようやく落としどころが見つかった
非推奨だった機能を廃止
❖ PHP5.6までに非推奨になった機能をPHP7で廃止
❖ ereg関数(preg関数使ってね)
❖ mysql関数(mysqli関数かPDO使ってね)
❖ その他
非推奨だった機能を廃止
❖ 今までもdeprecated(非推奨)エラーが出ていたはず
❖ いま開発環境が E_DEPRECATEDの人は注意
❖ php.iniが空だとdeprecatedエラーは出ません
❖ PHP7、さいきんどう?
❖ PHP7の新機能
❖ 性能改善と背景
❖ データ構造の変更
❖ HHVMとPHP
PHP7は速いらしい
❖ 「PHP5より倍速い」
❖ 「HHVMとほぼ互角」
❖ ホントに?
PHP7の性能(1)
Zeevのブログ記事(2014/7)より
PHP7の性能(2)
DmitryのZendCon 2014での発表(2014/10)より
PHP7の性能(3)
RasmusのFluent 2015での発表(2015/4)より
PHP7の性能(4)
❖ ごく最近まで性能改善が続いている
速くなりすぎ?
❖ PHP7は確かに速い
❖ この1年で倍の高速化(WordPressで比較)
❖ 今までも性能改善をサボっていたわけじゃない
❖ 10年間(PHP5.0→5.6)で倍の高速化
❖ 5.4以降は頭打ちの感さえあった
何があったのか?
❖ 現代のCPUに合わせて大幅なデータ構造変更を行った
❖ データ量の削減・データ局所性の改善
❖ 高速化チームの裁量が大きかった
❖ RFC「Move the phpng branch into master」
❖ 様々なア...
❖ PHP7、さいきんどう?
❖ PHP7の新機能
❖ 性能改善と背景
❖ データ構造の変更
❖ HHVMとPHP
データ構造の変更
❖ PHP7で見直したデータ構造
❖ PHPの変数(zval)
❖ 文字列(zend_string)
❖ 配列(HashTable / Bucket)
❖ 特にzvalの見直しは非常に大胆だが有効だった
データ構造変更の必要性(1)
❖ これまでのデータ構造は32bit CPUの頃の設計
❖ 16bytes中14bytesを使う構造だった
❖ 64bit CPUでは24bytes中6bytesが未使用
❖ 64bit時代に対応したデータ構造が必要
データ構造変更の必要性(2)
❖ キャッシュを効率的に使う発想が無い頃の設計
❖ メモリやキャッシュが相対的に速かった
❖ 現代のCPUではキャッシュを有効活用する必要性
❖ CPU速度に比べるとメモリ速度の改善は鈍い
❖ キャッシュサイズもあ...
PHP5のzval(int型)
❖ 計24bytes
❖ 常にポインタ参照される
❖ 参照カウント&コピーオンライト
PHP7のzval(int型)
❖ 計16bytes
❖ 参照カウントしない、代入では常にコピー
新zvalへの評価
❖ どの環境でも16bytes
→64bit時代に対応
❖ ポインタ参照が1段減った
❖ int型・float型・bool型でコピーオンライト廃止
→メモリ消費量減少
→キャッシュに優しくなった
❖ PHP7で我々は本物の配列を手に入れた!
配列にも大改革
❖ PHP7で我々は本物の配列を手に入れた!
配列にも大改革
配列とは
❖ (典型的には)連続するメモリ領域を確保する
❖ インデックスは0から連続する数字
❖ 読み書きが高速
リンゴ
バナナ
トマト
ニンジン
0
1
2
3
連想配列とは
❖ 文字列をキーにできる
❖ そこそこ読み書きも速い(配列よりは遅い)
"apple"
0
"banana" "carrot"
1 2 3 4 5 6 7
キーのハッシュ値を計算
"apple"=>リンゴ"banana"=>バナナ...
PHP5の配列
❖ PHP5までは連想配列しか無かった
❖ $array[1]でも連想配列アクセスしていた
❖ 他の言語の配列に比べると遅かった
PHP7の配列
❖ PHP7から配列と連想配列が作れるようになった
❖ 内部で自動的に選択される
❖ キーが0から連続する数字なら配列になる
→for文での配列のループ処理が高速になった
PHP7の配列
arData
flagsrefcount type gc_info
zend_array
u nTableMask
nNumUsed nNumOfElements
nTableSize nInternalPointer
nNext...
Bucket構造体の改善
❖ Bucket構造体:配列の要素1個に対応するデータ構造
❖ PHP5(72bytes)→PHP7(32bytes)
❖ メモリ使用量が劇的に減った
→配列のメモリ効率が良くなった
Bucket構造体の改善
❖ PHP7ではBucketの配列を連続領域に確保
❖ PHP5では1個ずつメモリ確保していた
→foreach文でのアクセス速度が有利に
❖ PHP7、さいきんどう?
❖ PHP7の新機能
❖ 性能改善と背景
❖ データ構造の変更
❖ HHVMとPHP
HHVMとは
❖ Facebookが自社向けに開発したPHPの実装
❖ PHP5より断然高速
❖ PHPコアコミッターがフルタイムでHHVMにコミット
❖ OSS開発もうまく回っている
→PHPでは初の「もう一つの選択肢」
HHVMの評価
❖ PHP7の登場で速度面のアドバンテージは失った
❖ JITコンパイルが効く状況では速い
❖ 実アプリケーションでの差は縮まった
❖ 魅力は多い
❖ 開発の活発さ、フットワークの軽さ
❖ Hack言語の仕様面での挑戦(例:as...
選択肢があることの価値
❖ HHVMはPHPに新しい価値を与えてくれた
❖ 必要に応じて別の実装を選べる状況
❖ PHP7での速度改善のモチベーション
❖ PythonやRubyでは当たり前の状況
❖ お互いに良い影響を与え続ける関係が望ましい
まとめ
❖ PHP7への移行のハードルは低い
❖ 便利そうな新機能が実装された
❖ 高速化のため大胆なリファクタリングが行われた
❖ 現代のアーキテクチャに合わせた最適化をした
❖ 他の選択肢があることに価値がある
❖ PHPもHHVMも盛り上...
ご静聴
ありがとう
ございました
Próximos SlideShares
Carregando em…5
×

PHP7で変わること ——言語仕様とエンジンの改善ポイント

167.712 visualizações

Publicada em

PHPカンファレンス関西2015にて発表

Publicada em: Tecnologia
  • Entre para ver os comentários

PHP7で変わること ——言語仕様とエンジンの改善ポイント

  1. 1. What’s new in PHP7 PHP7で変わること ̶̶言語仕様とエンジンの改善ポイント hnw PHPカンファレンス関西2015 (2015/5/30)発表資料
  2. 2. 自己紹介 ❖ @hnw ❖ 勤務先:KLab株式会社 ❖ カレーとバグが大好物 ❖ PHP歴15年 ❖ PHPや周辺エクステンションにバグレポ・PR多数
  3. 3. アジェンダ ❖ PHP7、さいきんどう? ❖ PHP7の新機能 ❖ 性能改善と背景 ❖ データ構造の変更 ❖ HHVMとPHP
  4. 4. まずはアンケート
  5. 5. PHP7って
 聞いたことがある人?
  6. 6. 実際にPHP7を
 動かしたことがある人?
  7. 7. ❖ PHP7、さいきんどう? ❖ PHP7の新機能 ❖ 性能改善と背景 ❖ データ構造の変更 ❖ HHVMとPHP
  8. 8. PHP7? ❖ PHP 5.6.xの次のバージョンがPHP 7.0.0 ❖ PHP6はスキップ ❖ 約10年ぶりのメジャーバージョンアップ
  9. 9. さいきんのPHP7 ❖ 予定通り3月に新機能の導入を凍結 ❖ RFCが大量に出ていたので個人的に心配していた ❖ そろそろalpha1を出す予定だったが、遅延ぎみ ❖ まだ議論が残っているため ❖ 11月にPHP7リリース予定
  10. 10. PHPのRFCシステム ❖ 新機能の導入にはRFCと呼ばれる説明ページが必要 ❖ 提案内容や変更による影響などを書く ❖ MLで議論後、投票によって採用・不採用が決まる ❖ 過半数または2/3以上の同意が必要(内容による) ❖ スピード感は無いが、十分機能している印象
  11. 11. PHP7に対するRFC ❖ PHP7で採択されたRFCは48個 ❖ 参考:PHP 5.6は17個、PHP 5.5は20個 →普段のマイナーバージョンアップよりは変化が大きい
  12. 12. PHP7で変わらないこと ❖ PHPは言語仕様の変更に対して非常に保守的 ❖ PHP7でも後方互換性は重視されている ❖ 移行コストは十分低いはず
  13. 13. ❖ PHP7、さいきんどう? ❖ PHP7の新機能 ❖ 性能改善と背景 ❖ データ構造の変更 ❖ HHVMとPHP
  14. 14. 致命的エラーが例外になった ❖ PHP5までの致命的エラー ❖ エラーハンドリングできず、即座に終了していた ❖ PHP7の致命的エラー ❖ EngineExceptionという新しい例外になった ❖ トップレベルに到達すると今まで通りのエラーになる →ユニットテストで致命的エラーから復帰できる
  15. 15. ??演算子の新設 ❖ nullでなければその値を、nullなら右オペランドを返す ❖ isset()と同様に未定義値に対しても使える ❖ ようやくisset()地獄から解放されるぞ!
  16. 16. 無名クラスの導入 ❖ クラス定義と同時にインスタンス化できる構文を導入 ❖ その場限りのインスタンスを作りたいときに便利
  17. 17. AST(抽象構文木)の導入 ❖ 解釈フェーズが
 1段増えた ❖ 文法解釈の柔軟性が
 上がった ❖ opcode最適化 Zend VM opcode Parser Lexer token PHP Zend VM opcode Parser Lexer token PHP Opcode Compiler AST PHP 5 PHP 7
  18. 18. 返り値のタイプヒントをサポート ❖ 関数の返り値に型が指定できるようになった ❖ 抽象クラスやインターフェースで指定すると便利
  19. 19. スカラ型のタイプヒントをサポート ❖ 以下の型が引数・返り値で指定できるようになった ❖ int型 ❖ float型 ❖ string型 ❖ bool型 ❖ ようやく落としどころが見つかった
  20. 20. 非推奨だった機能を廃止 ❖ PHP5.6までに非推奨になった機能をPHP7で廃止 ❖ ereg関数(preg関数使ってね) ❖ mysql関数(mysqli関数かPDO使ってね) ❖ その他
  21. 21. 非推奨だった機能を廃止 ❖ 今までもdeprecated(非推奨)エラーが出ていたはず ❖ いま開発環境が E_DEPRECATEDの人は注意 ❖ php.iniが空だとdeprecatedエラーは出ません
  22. 22. ❖ PHP7、さいきんどう? ❖ PHP7の新機能 ❖ 性能改善と背景 ❖ データ構造の変更 ❖ HHVMとPHP
  23. 23. PHP7は速いらしい ❖ 「PHP5より倍速い」 ❖ 「HHVMとほぼ互角」 ❖ ホントに?
  24. 24. PHP7の性能(1) Zeevのブログ記事(2014/7)より
  25. 25. PHP7の性能(2) DmitryのZendCon 2014での発表(2014/10)より
  26. 26. PHP7の性能(3) RasmusのFluent 2015での発表(2015/4)より
  27. 27. PHP7の性能(4) ❖ ごく最近まで性能改善が続いている
  28. 28. 速くなりすぎ? ❖ PHP7は確かに速い ❖ この1年で倍の高速化(WordPressで比較) ❖ 今までも性能改善をサボっていたわけじゃない ❖ 10年間(PHP5.0→5.6)で倍の高速化 ❖ 5.4以降は頭打ちの感さえあった
  29. 29. 何があったのか? ❖ 現代のCPUに合わせて大幅なデータ構造変更を行った ❖ データ量の削減・データ局所性の改善 ❖ 高速化チームの裁量が大きかった ❖ RFC「Move the phpng branch into master」 ❖ 様々なアイデアを約1年間に渡って実現
  30. 30. ❖ PHP7、さいきんどう? ❖ PHP7の新機能 ❖ 性能改善と背景 ❖ データ構造の変更 ❖ HHVMとPHP
  31. 31. データ構造の変更 ❖ PHP7で見直したデータ構造 ❖ PHPの変数(zval) ❖ 文字列(zend_string) ❖ 配列(HashTable / Bucket) ❖ 特にzvalの見直しは非常に大胆だが有効だった
  32. 32. データ構造変更の必要性(1) ❖ これまでのデータ構造は32bit CPUの頃の設計 ❖ 16bytes中14bytesを使う構造だった ❖ 64bit CPUでは24bytes中6bytesが未使用 ❖ 64bit時代に対応したデータ構造が必要
  33. 33. データ構造変更の必要性(2) ❖ キャッシュを効率的に使う発想が無い頃の設計 ❖ メモリやキャッシュが相対的に速かった ❖ 現代のCPUではキャッシュを有効活用する必要性 ❖ CPU速度に比べるとメモリ速度の改善は鈍い ❖ キャッシュサイズもあまり増えていない
  34. 34. PHP5のzval(int型) ❖ 計24bytes ❖ 常にポインタ参照される ❖ 参照カウント&コピーオンライト
  35. 35. PHP7のzval(int型) ❖ 計16bytes ❖ 参照カウントしない、代入では常にコピー
  36. 36. 新zvalへの評価 ❖ どの環境でも16bytes →64bit時代に対応 ❖ ポインタ参照が1段減った ❖ int型・float型・bool型でコピーオンライト廃止 →メモリ消費量減少 →キャッシュに優しくなった
  37. 37. ❖ PHP7で我々は本物の配列を手に入れた! 配列にも大改革
  38. 38. ❖ PHP7で我々は本物の配列を手に入れた! 配列にも大改革
  39. 39. 配列とは ❖ (典型的には)連続するメモリ領域を確保する ❖ インデックスは0から連続する数字 ❖ 読み書きが高速 リンゴ バナナ トマト ニンジン 0 1 2 3
  40. 40. 連想配列とは ❖ 文字列をキーにできる ❖ そこそこ読み書きも速い(配列よりは遅い) "apple" 0 "banana" "carrot" 1 2 3 4 5 6 7 キーのハッシュ値を計算 "apple"=>リンゴ"banana"=>バナナ "tomato"=>トマト "tomato" "carrot"=>ニンジン
  41. 41. PHP5の配列 ❖ PHP5までは連想配列しか無かった ❖ $array[1]でも連想配列アクセスしていた ❖ 他の言語の配列に比べると遅かった
  42. 42. PHP7の配列 ❖ PHP7から配列と連想配列が作れるようになった ❖ 内部で自動的に選択される ❖ キーが0から連続する数字なら配列になる →for文での配列のループ処理が高速になった
  43. 43. PHP7の配列 arData flagsrefcount type gc_info zend_array u nTableMask nNumUsed nNumOfElements nTableSize nInternalPointer nNextFreeElement pDestructor zval Bucket[] h (hash value) key (キーへのポインタ) h key 0 1 h key 2 zval zval ❖ 他言語の配列と同じ構造
 (数字キーのみの場合)
  44. 44. Bucket構造体の改善 ❖ Bucket構造体:配列の要素1個に対応するデータ構造 ❖ PHP5(72bytes)→PHP7(32bytes) ❖ メモリ使用量が劇的に減った →配列のメモリ効率が良くなった
  45. 45. Bucket構造体の改善 ❖ PHP7ではBucketの配列を連続領域に確保 ❖ PHP5では1個ずつメモリ確保していた →foreach文でのアクセス速度が有利に
  46. 46. ❖ PHP7、さいきんどう? ❖ PHP7の新機能 ❖ 性能改善と背景 ❖ データ構造の変更 ❖ HHVMとPHP
  47. 47. HHVMとは ❖ Facebookが自社向けに開発したPHPの実装 ❖ PHP5より断然高速 ❖ PHPコアコミッターがフルタイムでHHVMにコミット ❖ OSS開発もうまく回っている →PHPでは初の「もう一つの選択肢」
  48. 48. HHVMの評価 ❖ PHP7の登場で速度面のアドバンテージは失った ❖ JITコンパイルが効く状況では速い ❖ 実アプリケーションでの差は縮まった ❖ 魅力は多い ❖ 開発の活発さ、フットワークの軽さ ❖ Hack言語の仕様面での挑戦(例:async)
  49. 49. 選択肢があることの価値 ❖ HHVMはPHPに新しい価値を与えてくれた ❖ 必要に応じて別の実装を選べる状況 ❖ PHP7での速度改善のモチベーション ❖ PythonやRubyでは当たり前の状況 ❖ お互いに良い影響を与え続ける関係が望ましい
  50. 50. まとめ ❖ PHP7への移行のハードルは低い ❖ 便利そうな新機能が実装された ❖ 高速化のため大胆なリファクタリングが行われた ❖ 現代のアーキテクチャに合わせた最適化をした ❖ 他の選択肢があることに価値がある ❖ PHPもHHVMも盛り上がっていってほしい
  51. 51. ご静聴 ありがとう ございました

×