PHP 8 の新機能 JIT の理解

PHP 8 の JIT (Just In Time) コンパイラーは、拡張機能として php に統合されます。Opcache 拡張機能は、特定のオペコードを CPU 命令からの命令に直接変換するために使用されます。 。

これは、JIT を使用すると、Zend VM が特定のオペコードを解釈する必要がなく、これらの命令が CPU レベルの命令として直接実行されることを意味します。

PHP 8 の JIT

PHP 8 Just In Time (JIT) コンパイラーの影響は疑いの余地がありません。しかし、これまでのところ、JIT が何を行うべきかについてはほとんど知られていないことがわかりました。

多くの調査と断念を経て、PHP ソース コードを自分でチェックアウトすることにしました。 C 言語に関する私の知識の一部と、これまでに収集したすべての情報を組み合わせて、この記事を作成しました。これが、PHP の JIT をよりよく理解するのに役立つことを願っています。

簡単に言うと、JIT が期待どおりに動作する場合、コードは Zend VM を通じてではなく、CPU レベルの命令のセットとして直接実行されます。

これが全体的なアイデアです。

しかし、それをよりよく理解するには、php が内部でどのように動作するかを考慮する必要があります。それほど複雑ではありませんが、少し説明が必要です。

PHP コードはどのように実行されるのでしょうか?

ご存知のとおり、PHP はインタプリタ型言語ですが、この文自体は何を意味するのでしょうか?

PHP コード (コマンド ライン スクリプトまたは WEB アプリケーション) が実行されるたびに、PHP インタープリターを通過する必要があります。最も一般的に使用されるのは、PHP-FPM と CLI インタープリターです。

インタプリタの仕事は単純です。PHP コードを受け取り、それを解釈し、結果を返すことです。

一般的な通訳言語はこのプロセスに従います。言語によってはいくつかの手順が省略される場合がありますが、一般的な考え方は同じです。 PHP では、プロセスは次のとおりです。

PHP コードを読み取り、それをトークンと呼ばれるキーワードのセットとして解釈します。このプロセスにより、インタプリタは各プログラムにどのようなコードが記述されているかを知ることができます。このステップは、レクシングまたはトークン化と呼ばれます。トークン コレクションを取得した後、PHP インタープリターはそれらを解析しようとします。抽象構文ツリー (AST) は、解析と呼ばれるプロセスを通じて生成されます。ここで、AST は、実行する操作を表すノードのセットです。たとえば、「echo 1 1」は実際には「1 1 の結果を出力」、より具体的には「操作を出力、この操作は 1 1」を意味します。 AST を使用すると、操作と優先順位を理解しやすくなります。抽象構文ツリーを CPU で実行できる操作に変換するには、PHP ではオペコードと呼ばれる遷移式 (IR) が必要です。 AST をオペコードに変換するプロセスはコンパイルと呼ばれます。オペコードの楽しい部分は、コードの実行です。 PHP には、一連のオペコードを受信して​​実行できる Zend VM と呼ばれるエンジンがあります。すべてのオペコードが実行された後、Zend VM はプログラムを終了します。

この図を見ると、より明確になります:

PHP 解釈プロセスの概要の簡略版。 ＃＃＃＃＃＃ご覧のように。ここで質問があります。PHP コードが変更されていない場合でも、このプロセスは実行されるたびに実行されますか?

オペコードを振り返ってみましょう。正しい！これが、Opcache 拡張機能が存在する理由です。

Opcache 拡張機能

Opcache 拡張機能は PHP に付属しているため、通常は無効にする必要はありません。 PHP を使用する場合は、Opcache をオンにすることをお勧めします。

その機能は、メモリ共有キャッシュ層をオペコードに追加することです。その役割は、新しく生成されたオペコードを AST から抽出してキャッシュし、実行中に字句解析/トークン化と解析のステップをスキップできるようにすることです。

これは、Opcache 拡張機能を含むプロセス図です。

PHP は、Opcache 解釈プロセスを使用します。ファイルがすでに解析されている場合、PHP は再度解析する代わりに、そのファイルのキャッシュされたオペコードを取得します。

字句解析/トークン化、解析、コンパイルのステップを完全にスキップします。

補足: これは素晴らしい PHP 7.4 プリロード機能 RFC です! これを使用すると、コード ベースを解析し、オペコードに変換し、実行前にキャッシュするように PHP FPM に指示できます。

JIT がこの解釈プロセスにどのように関与しているか知りたいですか?この記事では説明します。

Just In Time コンパイルの効果は何ですか?

PHP Internals News での Zeev の PHP と JIT のブロードキャストを聞いて、JIT が実際に何をするのかを理解しました。 Opcache 拡張機能がより高速にオペコードを取得し、Zend VM に直接転送できる場合、JIT により、Zend VM をまったく使用せずにオペコードを実行できます。

Zend VM は C で書かれたプログラムで、オペコードと CPU の間の層として機能します。 JIT は実行時にコンパイルされたコードを直接生成するため、PHP は

Zend VM をスキップして CPU によって直接実行できます。理論的には、パフォーマンスは向上します。

これは奇妙に聞こえます。なぜなら、マシンコードにコンパイルする前に、構造の種類ごとに特定の実装を記述する必要があるからです。しかし実際には、これは合理的です。

PHP の JIT は、DynaASM (Dynamic Assembler) と呼ばれるライブラリを使用します。これは、特定の形式の一連の CPU 命令を、さまざまな CPU タイプのアセンブリ コードにマップします。したがって、コンパイラーは DynASM を使用してオペコードを特定の構造のマシンコードに変換するだけで済みます。

しかし、私を長い間悩ませてきた問題があります。

プリロードによって実行前に PHP コードをオペコードに解析でき、DynASM がオペコードをマシンコードにコンパイルできる (Just In Time コンパイル) 場合は、なぜすぐに実行前コンパイル (Ahead of Time コンパイル) を使用しないのでしょうか。 PHP をすぐにコンパイルすることについて?

Zeev のブロードキャストを聞いてわかった理由の 1 つは、PHP は型指定が弱い言語であるということです。つまり、PHP は通常、Zend VM が変数の型を認識しようとするまで変数の型を認識できないのです。オペコードを実行します。

Zend_value 共用体型をチェックすると、多くのポインターがさまざまな型の変数を指していることがわかります。 Zend VM は Zend_value から値を取得しようとするたびに、ZSTR_VAL のようなマクロを使用して共用体型の文字列へのポインタを取得します。

たとえば、この Zend VM ハンドラーは「以下」(<=) 式を処理します。型推論のためだけに非常に多くの if else 分岐をどのようにエンコードするかを見てください。

マシンコードを使用して型推論ロジックを実行することは現実的ではなく、速度が遅くなる可能性があります。

マシンコードへのコンパイルは CPU を集中的に使用するタスクであるため、最初に評価してからコンパイルすることも良い選択肢ではありません。したがって、実行時にすべてをコンパイルするのも良くありません。

それでは、Just In Time はどのようにコンパイルされるのでしょうか?

型を事前にコンパイルするために適切に推論できないことがわかりました。また、実行時のコンパイルには計算コストがかかることもわかっています。では、PHP にとって JIT にはどのようなメリットがあるのでしょうか?

バランスを図るために、PHP の JIT は価値のあるオペコードのみをコンパイルしようとします。これを行うために、JIT は Zend VM が実行するオペコードを分析し、コンパイルの可能性をチェックします。 (設定ファイルによると)

オペコードがコンパイルされると、Zend VM ではなくコンパイルされたコードに実行が渡されます。次のようになります:

PHP の JIT 解釈プロセス。コンパイルされた場合、オペコードは Zend VM によって実行されません。

したがって、Opcache 拡張機能には、Opcode をコンパイルするかどうかを決定する 2 つの検出命令があります。その場合、コンパイラーは DynASM を使用してこのオペコードをマシンコードに変換し、このマシンコードを実行します。

興味深いことに、現在のインターフェイスではコンパイルされたコードには MB 制限 (構成も可能) があるため、コード実行では JIT コードと解釈されたコードの間でシームレスに切り替えることができなければなりません。

ところで、php の JIT に関する Benoit Jacquemont のこの講演は、この全体を理解するのに役立ちました。

コンパイル部分がいつ効果的に完了したかはまだわかりませんが、今は本当に知りたくないのだと思います。

したがって、パフォーマンスの向上はおそらく大きなものではありません

ほとんどの PHP アプリケーションがジャストインタイム コンパイラを使用してもパフォーマンスが向上しない理由が明らかになったことを願っています。パフォーマンスが向上します。これが、アプリケーションのさまざまな JIT 構成をプロファイリングして実験することが最良のアプローチであると Zeev が推奨している理由です。

PHP FPM を使用している場合、コンパイルされたオペコードを複数のリクエスト間で共有するのが一般的ですが、それでも状況を大きく変えるものではありません。

これは、JIT が計算量の多い操作を最適化し、今日のほとんどの php アプリケーションが他の何よりも I/O 制約を受けているためです。とにかくディスクまたはネットワークにアクセスする場合、処理操作がコンパイルされているかどうかは関係ありません。タイミングは非常に似たものになります。

ただし...

画像処理や機械学習など、I/O に依存しないことを行っている場合は除きます。 I/O に関係しないものはすべて、JIT コンパイラーの恩恵を受けます。

これが、人々が今、C で書くよりも PHP でネイティブ関数を書くことを好むと言われる理由です。この関数がコンパイルされたとしても、オーバーヘッドは表現できないほど大きくなります。

推奨チュートリアル:「PHP7」

以上がPHP 8 の新機能 JIT の理解の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。