PHP 8: JIT – Stitcher.io

Dmitry Stogov は最近、PHP に JIT コンパイラを追加するための RFC を公開しました。 それで、それは何についてですか？ 「JIT」は「PHP を即座に改善する」という意味ですか、それとももっと微妙なトピックですか? 今日は、「JIT」が実際に何をするのか、そしてさらに重要なこととして、その難しさについて簡単に見ていきます。 と それが PHP の世界にもたらす機会。

# JITとは?

「JIT」は「ジャストインタイム」の略です。 PHP がインタープリター型言語であることはおそらくご存じでしょう。C、Java、または Rust プログラムのようにコンパイルされるわけではありません。 代わりに、実行時に機械語 (CPU が理解できるもの) に変換されます。

「JIT」は、実行時にコードの一部をコンパイルして、コンパイルされたバージョンを代わりに使用できるようにする手法です。

実行時に生成される、解釈されたコードの「キャッシュされたバージョン」のようなものと考えてください。

それはどのように機能しますか？

実行中のコードを監視する、いわゆる「モニター」があります。 このモニターは、再実行されるコードの部分を検出すると、その部分を頻度に応じて「ウォーム」または「ホット」としてマークします。 これらのホット パーツは、最適化されたマシン コードとしてコンパイルし、実際のコードの代わりにオンザフライで使用できます。

このトピックにはもっと複雑なものがあると想像できます。 もう少し詳しく知りたい場合は、Mozilla の JIT コンパイラのクラッシュ コースを参照してください。 このブログ投稿の目的のためには、JIT コンパイラーがプログラムのパフォーマンスを大幅に向上させる可能性があることを理解するだけで十分です。
しかし 正しくするのは難しいことです。

PHP コア開発者の 1 人である Zeev は、フラクタル生成のデモを少し前に示しました。

ファンシーですね。 ちょっと待って…

# 楽しいことばかりじゃない

部屋にいる象に話しかけましょう。フラクタル アニメーションの生成に PHP が使用されることはめったにありません。

JIT コンパイラーがコードのホットな部分を識別しようとすることを知っていれば、なぜそれがフラクタルの例にそのような影響を与えるのかを推測できます。同じ計算が何度も何度も行われているからです。 ただし、PHP は Web コンテキストで最も頻繁に使用されるため、そこでの JIT の影響も測定する必要があります。

残念ながら、Web リクエストを処理する際のホット コードはかなり少ないことがわかりました。 これは、JIT が Web パフォーマンスをまったく改善できなかったという意味ではありませんが、フラクタルの例のような同様の改善も見られません。

これはJITを捨てる理由ですか？ 絶対にありません！ 私たちが期待するパフォーマンスへの影響がないかもしれませんが、それを追加する良い議論があります。

• これは、PHP が Web の外で非常にパフォーマンスの高い言語として使用されるための扉を開きます。
• JIT は時間の経過とともに改善される可能性があり、コードも同様です。

これらは、JIT を支持する有効な議論です。 残念ながら、それに対する反対意見もあります。

# 維持する複雑さ

JIT はマシン コードを生成するため、「上級プログラマー」が理解するには複雑な内容であることが想像できます。

たとえば、マシン コードを出力として使用すると、PHP の JIT コンパイラで発生する可能性のあるバグをデバッグするのが難しくなります。 幸いなことに、デバッグを支援するツールがあります。 しかし、それでも、 は マシンコード。 JIT コンパイラーにバグがあるとします。それを修正する方法を知っている開発者が必要です。 Dmitry は、これまでほとんどのコーディングを行ってきた人物であり、PHP コアの開発は自発的に行われていることを思い出してください。

現在、このようなコード ベースを保守できる人はごくわずかであるため、JIT コンパイラを適切に保守できるかどうかという疑問は正当化されるように思われます。 もちろん、人々はコンパイラがどのように機能するかを学ぶことができます。 しかし、それでも複雑な素材です。 現在、プル リクエストには約 5 万行のコードが追加されています。 これは平均的な client-web-application-codebase ではありません。 これは、CPU プログラミングにできる限り近いものです。

繰り返しますが、これは JIT を放棄する理由にはなりませんが、メンテナンスのコストは慎重に検討する必要があります。 まず第一に、コードを維持しなければならない人たちによるものです。 ユーザーランド コミュニティは、一部のバグ修正やバージョンの更新に、現在慣れているよりも時間がかかる可能性があることも認識しておく必要があります。

# では、なぜそれが必要なのですか?

現在、JIT は Web アプリケーションに短期的なメリットをほとんどもたらさないと考えているのであれば、その考えは正しいかもしれません。 実際に使用する前に、本番アプリケーションにどのような影響があるかを判断するのは困難です。

JIT RFC は、PHP 8 で有効にすることを提案しましたが、PHP 7.4 で実験的なバージョンを追加することも提案しました。 残念ながら、RFC は PHP 8 では合格しましたが、7.4 では合格しませんでした。 これは、実際のプロジェクトで試すことができるようになる前に、PHP 8 まで待たなければならないことを意味します。 もちろん、既に確認したい場合は、ソースから PHP 8 をコンパイルすることもできます。

JIT は短期的には大幅な改善をもたらさないかもしれませんが、Web 言語としても、より一般的な目的の言語としても、PHP が成長する多くの可能性が開かれることを覚えておく必要があります。 答えが必要な質問: このおそらく明るい未来は、今日投資する価値があるでしょうか?

ユーザーランドのプログラマーであるあなたはどう思いますか? Hacker News で議論しましょう。 個人的に連絡を取りたい場合は、 ツイッター または電子メールで！