「Facebook が開発した高性能 PHP 仮想マシンである HHVM は、公式の PHP インタープリタよりも 9 倍以上高速です」という記述は本当ですか?

https://github.com/facebook/hhvm

HHVM ( HHVM は、Hack および PHP で記述されたプログラムを実行するために設計されたオープンソースの仮想マシンであり、PHP 開発者がこれまで慣れ親しんできた柔軟性を維持しながら、優れたパフォーマンスを実現します。 、HHVM (およびその前身である HPHPc) は、Web リクエストのスループットが 9 倍以上増加し、メモリ消費量が 5 倍以上削減 Facebook の場合、PHP 5.2 エンジン + APC と比較しました。
注: HHVM は、PHP および Hack 言語の解釈とコンパイルをサポートしています。
Hack は FB によって開発された C 言語に似た PHP のブランチで、構文は大まかに

<span class="x">$i = 1;</span>

のようなものです。 返信内容:

PHP5.2 時代にはこのような評価結果が得られたため、PHP5.3 では PHP コア チームがパフォーマンスの向上を非常に高く評価しています。

HHVM は、JIT が動的に最適化し、実行時にコンパイルして実行できるため高速です。

1.

例

<code class="language-text">// 定义两个function
function foo() {}
function bar() {}
// 调用只用到foo()，没用到bar()
foo()
</code>

これについて議論するのはまったく無意味です ～ オンドリとニワトリ、どちらが注文するのが上手かについて議論するようなものです ～ 何十億もの注文を処理する機会がある場合にのみ、これに触れる機会が得られます。 。 その時までにあなたがコーダーの存在を超えていたら、あなたはZhihuにいないでしょう。だから
時間があれば、前書きの技術に注目して、言語自体の基本を理解する必要があります~~ 型の動的バインディングが静的バインディングに変更されました。
タイプの動的バインディングは、使用すると楽しいですが、コストが高くなります。
コスト 1: 実行時に型チェックを実行する必要があります。
コスト 2: 変数値のスペースは可変である必要があり、タイプが異なれば異なるストレージ スペースが必要になります。
コスト 3: 動的バインディングを処理するには、通常、インタープリターが実行する必要があります。言うまでもなく、インタプリタはコンパイラよりもはるかに遅いです。

したがって、上記のコストを取り除くことができれば、高速化とメモリの節約は当然のことです。 int $1 = 1; が int i=1; であることは皆さんご存知でしょうが、C 言語は PHP よりもはるかに高速であるのに、なぜ HHVM ができないのだと思いますか? 実際、HHVM について話す根本的な理由は PHP の最適化です

• このタイプの「動的言語」の一般的な最適化は、他の言語 (代表的には C/C++) を使用することです。たとえば、Twitter は多くのビジネス ロジックを Scala に組み込みますが、Rails はフロントエンド ページの表示のみを担当します。
  
• もう 1 つのより高度な解決策は、Zend などの公式言語の実装を最適化することです。PHP コードを分析すると、空白行を削除した後の C コードには実際に 80 以上のコメントがあることがわかります。数千行（PHP 5.2.1）ですが、Zend エンジン部分の行数は 100,000 未満です。
• 最初の方法よりさらに進んだ方法は、PHP コードを C/C++ に変換してからローカル コードにコンパイルすることです。
  
• 上記の効果は顕著ですが、欠点は次のとおりです。これも重要です 明らかに、非常に高価です。さて、より良い仮想マシンの実装を試してみましょう。

HHVM の開発軌跡から見ると、次のようなものになります。
HPHPc --- --->HPHP (Facebook が 2008 年から使用している HPHPc、HPHPi、HPHPd などのヒップホップ) ----- >HHVM (Wikipedia: HHVM は HPHPc 上に構築されています。HHVM は PHP コードを高レベルのバイトコードに変換し、JIT コンパイラーがこれらのバイトコードをマシン コードに変換します。)

HHVM が高速である主な理由は、バイトコード + JIT という主要なテクノロジーがさまざまなニュース レポートで言及されているためです。実際、JIT に関する研究も大きく進んでいます。
例:

2010 年に日本 IBM 研究所は、JVM コードに基づいて P9 を開発しました。そのパフォーマンスは、公式の PHP の 2.5 倍から 9.5 倍です。ジャストインタイム コンパイラーの論文評価。 PHP 用に改良 ;
2008 年に、誰かが LLVM を使用して zend 仮想マシンを実験しましたが、結果は 21 倍遅くなりました - llvm.org ページ ; > さらに、JIT 自体にも時間がかかります。 はい、非常に単純なプログラムの中には、実行プロセスが完全には最適化されていないため、たとえば、JAVA や .NET の初期バージョンの JIT はインタプリタよりも遅くなる場合があります。パフォーマンス テスト中に強制終了されるため、絶対的なものはありません。そのほとんどは詳細の処理にあります (HHVM のリリース トラックを参照)。最も重要なことは、型推論が行われていることです。 HHVM によってコンパイルされたコードはネイティブ型を使用するため、インタプリタによるパラメータの判断やボックス化とアンボックス化の問題が回避され、C と比べて実行効果が大幅に向上します。言語。

現時点では、HHVM には、サードパーティの拡張機能 (MongoDB や Redis など、最後に PHP コードを実装する必要がある) のサポートが少ない、メモリ リークなど、いくつかの問題がまだあります。しかし、長期的には、PHP が他のものに置き換えられない限り、それはトレンドとみなされます。 コミュニティのサポートがなければ、PHP7 は未来であり、hhvm は一時的なものに過ぎません。 ある企業に面接に行った際にhhvmについて質問したのですが、当時は理解できませんでした。 質問に直接答えるのは真実ではありません。(または特定の環境で得られた偶然の結論)

市場で人気のあるさまざまな CMS フレームワークのベンチマークを実際に測定したところ、ほとんどの場合、同じ環境でのパフォーマンスの利点と欠点は php7 > >php5.そして、パフォーマンスの差が 100% を超えたことはありません。

php5 を hhvm に直接変換すると、CMS の一部のサードパーティ モジュールによって互換性の問題が発生することに注意してください。