“Facebook 開發的高效能PHP虛擬機器 HHVM 比官方的 PHP解譯器 快超過9倍”的說法是否屬實？

https://github.com/facebook/hhvm

HHVM (aka the HipHop Virtual Machine) is an open-source virtual machine designed for executing programs written in Hack and PHP. HHVM uses a just-in-time compilation approach to achieve superior performance while maintaining the flexibility that PHP developers are accustomed to. To date, HHVM (and its predecessor HPHPc before it) has realized over a 9x increase in web request throughput and over a 5x reduction in memory consumption for Facebook compared with the PHP 5.2 engine + APC.
註：HHVM支援PHP和Hack兩種語言的解釋編譯。
Hack是FB搞的、一門更像C語言的PHP分支，添加了類型支援，文法上大致就從

$i = 1;

回複內容：

PHP5.2時代，這樣的測評結果是有可能的，這是PHP5.3依賴，PHP核心團隊把效能改善拍排在很前面的原因。

HHVM快是因為JIT，能在運行時先動態最佳化再編譯執行：

1.

比如

// 定義兩個functionfunction foo() {}function bar() {}// 調用只用到foo()，沒用到bar()foo()

爭論這個完全 沒有意義~ 這就好比爭論公雞和母雞誰更能下單 ~ 除非你有機會能進程億級這個量級 才能有機會接觸這個。。 如果真到那個時候 你已經超越碼農存在 也不會在知乎上。 SO
要有時間還是關注下 前言技術 瞭解語言本身的基礎 ~~類型的動態綁定改成了靜態繫結啊。
類型的動態綁定用的是爽，但是代價不小。
代價1：類型檢查要在運行時進行。
代價2：變數值的空間要可變，不同的類型需要的儲存空間是不同的。
代價3：處理動態綁定一般要解譯器來做。解譯器比編譯器慢多少不用說了吧。

所以咯，如果能夠去掉上面的幾個代價，提速和節約記憶體是當然的。既然你都知道int $1 = 1;就是int i=1;了，你覺得既然C語言比PHP快那麼多，為什麼HHVM就不行呢？其實聊HHVM的根本原因還是對PHP的最佳化

• 大家對於這一類“動態語言”比較常見的最佳化是，在效能瓶頸的地方用其他語言（代表性的C/C++）來代替，比如Twitter就將大量的商務邏輯放到了Scala裡，而Rails只負責前端頁面上的展現。
  
• 另外一種比較進階的方案是最佳化官方語言的實現，比如Zend，如果分析過PHP的代碼，就會發現它的C代碼除去空行注釋後居然還有80+萬行（PHP 5.2.1），而Zend引擎部分只有不到10萬行。
• 比第一個方法更進一步的是，將PHP代碼轉成C/C++，然後編譯成本地代碼；
  
• 上面的效果很顯著，但是缺點也很明顯，就是開銷很大！WORE，那就來試著做一個更好的實現虛擬機器；

從HHVM的發展軌跡上看，很類似於：
HPHPc------> HPHP （08年開始Facebook就開始使用的HipHop，包括HPHPc、HPHPi、HPHPd）-----> HHVM（維基百科：HHVM是在HPHPc的基礎上構建，它會將PHP代碼轉換成進階別的位元組碼，在運行時即時JIT編譯器會將這些位元組碼翻譯成機器碼。）

而HHVM快的原因，在各種新聞報道中都提到了bytecode+JIT這個關鍵技術，其實研究JIT的路子也走了很長。
比如：

2010 年 IBM 日本研究院基於他們的JVM代碼開發了P9，效能是官方PHP的2.5到9.5倍，論文Evaluation of a just-in-time compiler retrofitted for PHP ；
2008 年有人用 LLVM 實驗過zend虛擬機器，結果是慢了 21 倍——llvm.org 的頁面 ；

而且JIT本身也是會耗時的，對於一些很簡單的程式，執行過程上最佳化不完全，沒準還比interpreter慢，比如JAVA和.NET最初版本的JIT在效能測試時很容易就被幹掉，所以並不存在絕對的事情，更多還是在細節問題的處理上（參考HHVM的發布軌跡），其中最關鍵的上面的兄弟已經說到了，就是類型的推斷已經從語言轉移到了程式員身上，HHVM編譯出來的代碼直接使用了原生類型，避免了interpreter對參數的判斷和box、unbox的問題，正是這一點明顯提升了效能，甚至做到了和C語言的執行效果不大。

目前HHVM還是存在一些問題，比如對第三方擴充支援較少（比如MongoDB、Redis，在底層還是要用PHP代碼實現）、記憶體泄露問題等等，但長遠來看，除非PHP被其他替代掉，否則算是一個趨勢。沒有得到社區的支援，PHP7才是未來，hhvm只會曇花一現去一家公司面試時問過hhvm當時沒瞭解過直接回答問題，並不屬實。（或是在特定環境下得出的偶然結論）

實測多種市場流行cms framework的benchmark，在大多數情況下同等環境的效能優劣是php7 > hhvm > php5。並且效能差距還沒遇到過大於100%的情況。

值得一提的是，在php5直接轉換到hhvm的情況下，有些cms的第三方模組會產生相容性問題。

