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

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

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

PHP 8 の JIT

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

いろいろ調(diào)べて諦めた結(jié)果、PHPのソースコードを自分でチェックすることにしました。 C 言語に関する私の知識の一部と、これまでに集めた散在する情報をすべて組み合わせて、この記事を作成しました。これが、PHP の JIT をよりよく理解するのに役立つことを願っています。

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

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

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

私は、php の仕組みの概要を説明するブログ投稿を書きました。この投稿が多すぎると思われる場合は、別の投稿を確認して、後で戻ってきてください。物事が理解しやすくなります。

PHP コードはどのように実行されますか?

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

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

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

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

• PHP コードを読み取り、それをトークンと呼ばれるキーワードのセットとして解釈します。このプロセスにより、インタプリタは各プログラムにどのようなコードが記述されているかを知ることができます。 このステップは、レクシングまたはトークン化と呼ばれます。

• #トークン コレクションを取得した後、PHP インタープリターはそれらを解析しようとします。抽象構(gòu)文ツリー (AST) は、Parsing と呼ばれるプロセスを通じて生成されます。ここで、AST は、実行する操作を表すノードのセットです。たとえば、「echo 1 1」は実際には「1 1 の結(jié)果を出力」、より具體的には「操作を出力、この操作は 1 1」を意味します。

• AST を使用すると、操作と優(yōu)先順位を理解しやすくなります。抽象構(gòu)文ツリーを CPU で実行できる操作に変換するには、PHP ではオペコードと呼ばれる遷移式 (IR) が必要です。 AST をオペコードに変換するプロセスは、 コンパイル と呼ばれます。

• オペコードの楽しい部分は、コードの実行です。 PHP には Zend VM と呼ばれるエンジンがあり、一連のオペコードを受け取って実行できます。すべてのオペコードが実行された後、Zend VM はプログラムを終了します。

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

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

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

Opcache 拡張機能

が存在する理由です。

Opcache 拡張機能

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

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

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

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

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

補足:

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

JIT がこの通訳プロセスにどのように參加しているか知りたいですか?この記事では説明します。

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

PHP Internals News での Zeev の PHP と JIT のブロードキャストを聞いた後、JIT が実際に何をするのか理解しました。

Opcache 拡張機能がより高速にオペコードを取得し、Zend VM に直接転送できる場合、JIT により、Zend VM をまったく使用せずにオペコードを?qū)g行できます。

Zend VM は C で書かれたプログラムで、オペコードと CPU の間の層として機能します。 JIT は実行時にコンパイルされたコードを直接生成するため、PHP は Zend VM をスキップして CPU によって直接実行できます。 理論的には、パフォーマンスは向上します。

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

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

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

プリロードによって実行前に PHP コードをオペコードに解析でき、DynASM がオペコードをマシン コードにコンパイルできる (ジャスト イン タイム コンパイル) 場合、なぜ Ahead of Time コンパイルを使用しないのでしょうか) PHP のコンパイルについてはどうでしょうかすぐに？

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

PHP FPM を使用している場合は、通常、コンパイルされたオペコードを複數(shù)のリクエスト間で共有しますが、それでも大きな変革にはなりません。

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

ただし...

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

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

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

---

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

---

元のアドレス: https://thephp.website/en/issue/php-8-jit/

推奨: 「PHP ビデオ」チュートリアル＃＃＃"＃＃＃

以上がPHP 8 の JIT の詳細の詳細內(nèi)容です。詳細については、PHP 中國語 Web サイトの他の関連記事を參照してください。