Robert Nicholson が、JVM での PHP の実装である P8 について説明しているこのビデオをここで見ていました。ある時点で、彼は将来的にネイティブ PHP のパフォーマンスを上回ることを目指していると述べています。
彼は、JRuby と Jython について言及しています。これらは、ネイティブの対応物よりも遅く始まりましたが、最終的にはそれらを上回りました。JVM 上の別の PHP インタープリターである Quercus は、mod_php よりも4 倍高速であると主張しており、これも注目に値します。
これは、JVM が C より遅いという一般的な考えが間違っているということですか、それとも元の C 実装に欠陥があるということですか?
それは、JVM が C よりも遅いという一般的な考えが間違っているということですか、それとも元の C 実装に欠陥があるということですか?
両方のビット
JVM は長い間使用されており、効率が大幅に向上しています。ガベージ コレクション、ジッティング、キャッシング、およびその他の領域は、PHP などの「リファレンス」実装よりも高度です。
PHP の内部を調べれば、効率が簡単に向上する理由がわかるでしょう。
個人的には、JVM が CPython よりも優れているとは思えませんが、間違っている可能性もあります。これは、JVM GC が高速であり、IronPython も高速であるためです。パフォーマンスの向上は、スタックレス Python などの C コール スタックに依存しない場合があります。Jython サイトの状態
Jython は CPython とほぼ同じ速さで、速いときもあれば遅いときもあります。>ほとんどの JVM (確かに最速の JVM) は長時間実行されるため、ホット コードは時間の経過とともにより高速に実行されます。
キャッシュが生成されるとJVMがCパフォーマンスレベルに到達するなど、基本的にVM実装コードのより高いレベルの側面を無効にするため、これを事実と見なすことができます（とにかく大部分はCで書かれています）
PHP や Python などの多くのインタープリター言語では、同等の C 呼び出しへの橋渡しにすぎず、マシン コードに飛び込みます。JVM では、Jitter はバイトコードを同等のマシン コードに変換することで同様の機能を実行します。最終的に、高レベルの構文やバイトコードなどの中間表現は、通常、とにかく C 速度またはより高速な CPU 操作に削減されます...したがって、すべて同じであり、ロード時の完全な効率までのレイテンシにのみ影響する中間ステップが増えるだけです。新しいコード。RAM には、「本当の違いは何ですか?」と言うポイントがあります。答えは、そこにたどり着くプロセスと、スタック巻き上げの速度、ガベージ コレクション アルゴリズム、レジスタの使用法、算術などの論理表現を決定する最終的な表現だけです。
それほど難しくありません。C で実装を作成する場合は、独自の GC、JIT などを作成する必要があります (高速かつ効率的にするため)。それを本当にうまくやるには、多くの経験を持ち、彼らに多くの時間を与える、本当に賢い人々が必要です。
私はここで手足を踏み出して、PHPの現在の実装（内部作業の知識ではなく、私が見たベンチマークや、PHPについてもっと知っている人々が私に言ったことに基づいている）は状態ではないと言いますアートの。Facebook はこれに対処しようとしていますが、珍しい方法でそれを行っています (特殊なニーズがあり、PHP の一般的な使用方法がhttp://www.stanford.edu/class/ee380/Abstracts/100505.htmlを参照)。
要約: したがって、誰かが PHP を Java (または任意の高速 VM) に実装する場合、スーパー GC や JIT を高速化する必要はありません (単純なコンパイラのみ)。
仮想マシンが何をするかについてのヒントがここにあります。たとえば、Java 仮想マシンは最初にバイトコードのどの部分が最も頻繁に実行されるかをチェックし、次に関連する部分をネイティブ コードにコンパイルします (その後、コンパイルされた C コードなどと同様の速度で実行する必要があります)。
ところで、PHP はバイトコードにコンパイルされますか、それともメモリ内のデータ構造を使用して解釈されるだけですか? 最初に PHP を Java 仮想マシンによって実行可能なバイトコードに変換することにより、既存の (言語にとらわれない) バイトコード実行の最適化から自動的に利益を得ることができます。