PHP 8 の JIT の詳細-PHP8-php.cn

この記事では、PHP 8 の JIT を理解し、JIT が解釈プロセスにどのように関与するかについて説明します。皆様のお役に立てれば幸いです。

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 はインタープリタ型言語ですが、この文自体は何を意味するのでしょうか?

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

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

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

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

この図を見ると、よりわかりやすくなります:

PHP 8 の JIT の詳細

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

オペコードを振り返ってみましょう。正しい！これが、

Opcache 拡張機能

が存在する理由です。

Opcache 拡張機能

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

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

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

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

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

補足:

これは素晴らしい 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 がオペコードをマシンコードにコンパイルできる (ジャストインタイムコンパイル) 場合、なぜ Ahead of Time コンパイルを使用しないのでしょうか) PHP のコンパイルについてはどうでしょうかすぐに？

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

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

たとえば、この Zend VM ハンドラーは「以下」(

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

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

それでは、ジャストインタイムコンパイルはどのように行われるのでしょうか?

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

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

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

PHP 8 の JIT の詳細

#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 でネイティブ関数を書くことを好むと言われる理由です。この関数がコンパイルされたとしても、オーバーヘッドは表現できないほど大きくなります。

PHP プログラマーになる楽しい時間...

この記事があなたのお役に立ち、PHP8 の JIT をより深く理解できるようになれば幸いです。