php8.0 バージョンの最適化と改善の包括的な解釈-PHPチュートリアル-php.cn

php8.0 バージョンの最適化と改善の包括的な解釈

困難な状況に陥ったり、過去に生きたりしていない限り、JIT が PHP 8 に入りつつあることに気づくでしょう: 投票する今日は静かに終了しました。大多数の人が PHP8 にマージすることに同意したため、これが公式です。この記事では、php8.0 バージョンの最適化と改善について包括的に説明します。

PHP8 公式発表「PHP 8 が登場します!」 PHP チームは最初のベータ版である混乱のアルファ 1 をリリースし、それがどのように機能するかを詳しく掘り下げました (ただし、退屈させたくないので少しだけです)。

誰に話しているのかわからないので、簡単な質問から始めて、複雑な質問に進んでいきます。すでに知っていると確信している場合はスキップしても問題ありませんタイトルの質問に対する答えその部分です。。。

JIT とは何ですか?

PHP は、Zend VM と呼ばれる仮想マシン、つまり仮想プロセッサを実装します。 PHP は人間が判読できるスクリプトを、仮想マシンが理解できる命令 (オペコードと呼びます) にコンパイルします。この実行段階を「コンパイル時間」と呼びます。実行の「ランタイム」フェーズでは、仮想マシン (Zend VM) がコードの命令 (オペコード) を実行します。これはすべてうまく機能します。APC (過去) や OPCache (現在) のようなツールはコードの命令 (オペコード) をキャッシュできるため、必要な場合にのみ「コンパイル時間」が発生します。

まず、JIT とは何かを説明するコード行があります。

ジャストインタイム

は、コードの中間表現を受け入れるコンパイラ戦略であり、タイムリーに実行できるように、実行時にこれをアーキテクチャに依存するマシンコードに変換します。

PHP では、これは、JIT が Zend VM によって生成された命令を中間表現として使用し、アーキテクチャに依存するマシンコードを出力することを意味します。したがって、コードのホストはもはや ZendVM ではなく CPU になります。

なぜ PHP に JIT が必要なのでしょうか?

PHP 7.0 より前は、PHP 内部コミュニティの焦点はパフォーマンスであり、Facebook の HHVM プロジェクトによってもたらされた健全な競争によってもたらされました。 PHP 7.0 のコア変更のほとんどは PHPNG パッチに含まれており、これにより PHP がコアでメモリと CPU を利用する方法が大幅に改善されました。それ以来、私たち全員がパフォーマンスに集中することを余儀なくされました。 PHP 7.0 以降、いくつかのパフォーマンスの向上、

HashTable

(PHP のコアデータ構造) の最適化、特定のオペコードの Zend VM 特殊化、コンパイラー特殊化の特定のシーケンス、および継続的な改善が行われています。 OPCache のオプティマイザーコンポーネント。。。それ以外にもたくさんあるので、とても退屈です。

これらの最適化が私たちを前進させることができるのは限界であり、さらに改善する能力においては急速に近づいているか、壁にぶつかっている可能性があることは厳然たる事実です。

注:

「これ以上改善することはできない」と言うとき、私たちが本当に言いたいのは、「さらに改善するにはトレードオフをしなければならない」ということです。もはや魅力的には見えません。」。。パフォーマンスの最適化について議論するときは、常にトレードオフについて議論します。多くの場合、シンプルさとパフォーマンスの間にはトレードオフがあります。私たちは皆、最も単純なコードが最も速いコードであると考えたがりますが、現代の C プログラミングの世界ではそうではありません。通常、最速のコードは、アーキテクチャに依存する組み込み関数またはプラットフォーム (コンパイラ) に依存する組み込み関数を利用するように準備されたコードです。シンプルだからといって最高のパフォーマンスが保証されるわけではありません。。。

現時点では、PHP のパフォーマンスを向上させるには、PHP の JIT 機能が最善の方法であると思われます。

JIT を使用すると Web サイトが高速化されますか?

可能性はありますが、明らかではありません。期待した答えではないかもしれません: 一般に、PHP で書かれたアプリケーションは

I/O バインド

、

JIT

で CPU 上で最適に動作します。 をバインドします。 「I/O と CPU バインド」とは正確には何を意味しますか?

コードまたはアプリケーションの一般的なパフォーマンス特性を説明する場合、I/O バウンド および

CPU バウンド

という用語を使用します。。最も簡単な言い方は次のとおりです:

I/O を改善 (削減、最適化) できれば、I/O バウンドの一部はコードの実行が速くなります。

CPU が実行している命令を改善 (削減、最適化) するか、CPU のクロック速度を (魔法のように) 上げることができれば、CPU に依存するコードの実行速度が向上します。 )
コードまたはアプリケーションは、I/O バウンド、CPU バウンド、または CPU と I/O の両方に同様にバインドされる場合があります。
一般的に、PHP アプリケーションは I/O バウンドになる傾向があります。アプリケーションの速度を低下させるのは、データベース、キャッシュ、ファイル、ソケットなどへの接続、読み書きなどの実行中の I/O です。。

#CPU バウンドの PHP とはどのようなものですか?

ほとんどの PHP アプリケーションの性質上、多くの PHP プログラマーは CPU バウンドのコードに慣れていません。彼らの仕事は、多くの場合、データベースやキャッシュに接続し、軽量の Works を実行することです。 html/json/xml 応答を出力します。

コードベースを見回すと、I/O に関係のないコードがたくさん見つかったり、I/O から完全に切り離された関数を呼び出すコードさえ見つかって混乱してしまうかもしれません。 I/O よりも非 I/O を処理するコード行の方が多い場合でも、アプリケーションを CPU バウンドにする必要はありません。

PHP は実際には非常に高速で、世界で最も高速に解釈される言語の 1 つです。 Zend VM が I/O に関係のない関数を呼び出すことと、マシンコードで同じ呼び出しを行うことの間に大きな違いはありません。

明らかに違いがありますが、実際には、マシンコードには呼び出し規約があり、Zend VM には呼び出し規約があり、マシンコードにはプロローグがあり、Zend VM にはプロローグがあります。Zend オペコードで何かを呼び出す c_level_function() あるいは、マシンコードは呼び出し側アプリケーションのパフォーマンスに大きな影響を与えませんが、その呼び出しには大きな影響を与えているように見えます。

注: 呼び出し規約は、別の関数に入る前に実行される一連の命令を大まかに指し、プロローグは、別の関数に入るときに実行される一連の命令を指します。どちらの場合も、呼び出し規約はパラメータをスタックにプッシュし、プロローグはパラメータをスタックからポップします。

ループ、末尾呼び出し、X についてはどうですか? 「PHP は実際には非常に賢いので、OPCache のオプティマイザーコンポーネントを有効にすると、あたかもコードが魔法のように、記述できる最も効率的な形式に変換されるかのようです。」という質問が聞こえます。

ここで、JIT は、VM によって確立された規則ではなく、Zend 関数の呼び出し規則を変更しないことに注意することが重要です。Zend は、いつでも JIT モードと VM モードを切り替えることができなければなりません。 VM 呼び出し規約によって確立された規約を維持することが決定されました。そのため、JIT の実行中は、どこにいてもこれらの呼び出しが大幅に高速化されることはありません。

CPU バウンドの PHP コードがどのようなものかを確認したい場合は、Zend/bench.php ファイルを見てください。これは明らかに極端な CPU コードの例ですが、 JIT の本当のハイライトは数学の分野にあるということを私たちに知らせてくれるはずです。

PHP は計算の高速化と究極のトレードオフをもたらしますか?

いいえ、これは PHP の範囲を拡大するために行いました。これはかなり大きなものです。

この非常に偏った PHP 開発者の意見では、2019 年に Web プログラマーであり、次のプロジェクトで PHP を使用することを考えていないのであれば、Web に関して間違ったことをしていることになります。

PHP で数学をより速く実行する能力を向上させることは、一見すると非常に狭い範囲であるように思えます。

しかし、これは実際には、機械学習、3D レンダリング、2D (GUI) レンダリング、データ分析 (ほんの数例を挙げると) への扉を開きます。

PHP 7.4 ではなぜ使用できないのですか?

私は JIT を「究極のトレードオフ」と呼びましたが、それはその通りだと思います。これはおそらく、これまで考案された中で最も複雑なコンパイラ戦略の 1 つであり、おそらく最も複雑です。 JIT を導入すると、かなりの複雑さが生じます。

Dmitry (JIT の作者) に PHP を複雑にしたのかと尋ねたら、彼は「いいえ、複雑なことは嫌いです」と答えるでしょう (これは直接の引用です)。

結局のところ、私たちが理解していないのは複雑さであり、現在、JIT 実装を本当に理解している社内開発者はほとんどいません (数人未満)。

PHP 7.4 は急速に進歩しており、php7.4 にマージすると、(実際的な意味で) デバッグ、修正、改善できる人が少数しかいない PHP のバージョンが残ることになります。 PHP 7.4 へのマージに反対票を投じた人にとって、この状況は容認できません。

今から PHP 8 までの間、私たちの多くは暇なときに JIT を理解しようと努めることになるでしょう:

まだ実装すべき機能がいくつかあり、PHP 用に作り直す必要があります。 8 ツールを作成するには、まず JIT を理解する必要があります。私たちにはこの時間が必要であり、大多数の有権者が私たちに時間を与えるのがふさわしいと考えてくれたことに非常に感謝しています。

複雑さはひどいことの同義語ではありません:

複雑さは星雲のように美しい場合もあり、JIT はそのような複雑さです。原理的には、複雑なものを完全に理解するだけで、見かけの複雑さをほんの少し軽減するだけです。言い換えれば、Dmitry と同じくらい JIT に精通した社内開発者が 20 人いたとしても、JIT の複雑さはそれほど変わりません。

PHP の開発は遅くなるでしょうか?

そう考える理由はありません。 PHP 8 が一般公開される頃には、少なくともバグを修正して PHP を前進させるために十分な数の人々が JIT に精通していると自信を持って言える十分な時間があります。今日のように機能することができました。

これを JIT が本質的に複雑であるという点に結び付けようとする場合、新機能の導入に費やされる時間の多くは、実際にはその機能の議論に費やされることを考慮してください。ほとんどの機能、あるいは修正の場合、コードの作成には数分から数時間かかり、議論には数週間から数か月かかることがあります。まれに、機能のコードを記述するのに数時間または数日かかることがありますが、このようなまれなケースでは、議論には常に時間がかかります。