摘要：周四正式發(fā)布了編程語(yǔ)言，將靜態(tài)類型以及一些現(xiàn)代的語(yǔ)言特性引入了。這是對(duì)優(yōu)化之路上的新里程碑。但是語(yǔ)言層面的優(yōu)化限制太多，對(duì)而言還是不夠用。其次是優(yōu)化運(yùn)行的步驟。在這方面進(jìn)行調(diào)整，可以提升運(yùn)行的性能。值得注意的是，給的影響很大。

Facebook周四正式發(fā)布了Hack編程語(yǔ)言，將靜態(tài)類型以及一些現(xiàn)代的語(yǔ)言特性引入了PHP。這是Facebook對(duì)PHP優(yōu)化之路上的新里程碑。

這個(gè)問題可以從不同角度來(lái)回答。簡(jiǎn)單直接的回答是，F(xiàn)acebook的規(guī)模太大了。PHP的性能問題限制了Facebook的發(fā)展。從另一個(gè)角度來(lái)回答，則是要回答既然PHP不夠用，為什么不干脆換掉？

把PHP換掉也有“整體換”和“局部換”的區(qū)別。最徹底的方案就是完全離開PHP，用別的語(yǔ)言重寫一套。但是對(duì)于Facebook而言這個(gè)代價(jià)太高了。如果切換的話，多年來(lái)在PHP的積累就完全作廢了。而且Facebook的業(yè)務(wù)邏輯非常復(fù)雜，據(jù)說(shuō)PHP代碼有2千萬(wàn)行…… 而且，F(xiàn)acebook員工眾多，切換到一種新的語(yǔ)言，學(xué)習(xí)成本也不低。

既然整體換不可行，那就局部換吧。例如給PHP寫C/C++擴(kuò)展，可以提升性能。但是PHP擴(kuò)展開發(fā)起來(lái)成本高，一般只適用于比較穩(wěn)定的庫(kù)，適用范圍很有限。另一個(gè)方案將性能瓶頸的地方用其他語(yǔ)言實(shí)現(xiàn)，然后通過RPC（Remote Procedure Call，遠(yuǎn)程過程調(diào)用）在PHP和其他語(yǔ)言之間通訊。Twitter就用了這條路線，大量組件使用Scala和Java編寫，通過RPC與展現(xiàn)層的Rails通訊。事實(shí)上，F(xiàn)acebook在這方面已經(jīng)做了不少工作，為了減少RPC調(diào)用的開銷，F(xiàn)acebook還專門開發(fā)了Thrift。然而，C++開發(fā)成本比PHP高很多，不適合用在需要快速修改的地方，而且大量RPC調(diào)用終究會(huì)影響性能。

整體換不現(xiàn)實(shí)，Thrift不夠用，那么Facebook優(yōu)化PHP就勢(shì)在必行了。

優(yōu)化PHP，最先想到的是作性能分析，找出瓶頸，然后進(jìn)行對(duì)應(yīng)的優(yōu)化。Facebook為此開發(fā)了XHProf工具。XHProf精確到函數(shù)層面，數(shù)據(jù)收集組件使用C開發(fā)（PHP擴(kuò)展），報(bào)告組件用了PHP。支持PHP 5.2以上版本，對(duì)于定位性能瓶頸很有幫助。

但是PHP語(yǔ)言層面的優(yōu)化限制太多，對(duì)Facebook而言還是不夠用。所以Facebook需要對(duì)PHP語(yǔ)言的實(shí)現(xiàn)本身進(jìn)行優(yōu)化。

首先可以考慮的方案是改善PHP的官方實(shí)現(xiàn)。PHP的官方解釋器運(yùn)行PHP代碼的過程可以分為兩步：第一步，將PHP編譯為bytecode；第二步，運(yùn)行bytecode。那么改善PHP的官方實(shí)現(xiàn)就可以從這兩個(gè)方面著手。

首先是優(yōu)化編譯PHP的步驟，這方面的工作已經(jīng)有ZendOptimizerPlus做了。它會(huì)在內(nèi)存中緩存編譯好的bytecode，這樣以后訪問代碼的時(shí)候就可以直接訪問緩存好了的bytecode，省去了從磁盤讀取再重新編譯的開銷。但是由于PHP語(yǔ)言的動(dòng)態(tài)性，這個(gè)方法的效果一般，最好的情況下也只能提升20%的性能。

其次是優(yōu)化運(yùn)行bytecode的步驟。上面提到的ZendOptimizerPlus主要是優(yōu)化編譯PHP，但是也附帶做了一些bytecode運(yùn)行的優(yōu)化。PHP有三種方式來(lái)運(yùn)行bytecode：CALL、SWITCH和GOTO，默認(rèn)使用CALL，也就是函數(shù)調(diào)用。優(yōu)化函數(shù)調(diào)用，常用的方法就是內(nèi)聯(lián)（Inline function），也就是將函數(shù)展開，將函數(shù)體插入替換調(diào)用該函數(shù)的地方，這樣可以節(jié)省每次調(diào)用函數(shù)帶來(lái)的額外時(shí)間開支。但是這種做法其實(shí)是用“空間換時(shí)間”，如果內(nèi)聯(lián)過頭了，空間開銷會(huì)很大，得不償失。在這方面進(jìn)行調(diào)整，可以提升運(yùn)行bytecode的性能。

此外還可以將整個(gè)PHP解釋器用匯編重寫，以快聞名的LuaJIT就是這么干的。

然而，無(wú)論是內(nèi)聯(lián)優(yōu)化還是用匯編重寫，代價(jià)都很大，而且如果優(yōu)化官方實(shí)現(xiàn)的話，還要考慮PHP的向下兼容……

既然這個(gè)方案不太現(xiàn)實(shí)，那么不如把PHP搬到JVM上吧？JVM性能相當(dāng)不錯(cuò)。

把PHP搬到JVM的工作，有人已經(jīng)做過了。例如，IBM的P8（已死）和Quercus（半死不活）。Facebook也研究過這個(gè)方案，2012年的時(shí)候，還有Facebook遷移到JVM的傳聞。其實(shí)Facebook早已放棄這條路線。根據(jù)Facebook的研究，Quercus的性能和Zend+APC相比，差不了太多。這一方案效果不理想的原因可能是，JVM本身性能的優(yōu)化是針對(duì)Java做的，其他語(yǔ)言在JVM上實(shí)現(xiàn)，不一定能用到這些優(yōu)化。動(dòng)態(tài)語(yǔ)言尤為如此。因?yàn)镴ava本身是靜態(tài)類型的，所以很多優(yōu)化JVM就沒必要做，而在JVM上跑的動(dòng)態(tài)語(yǔ)言需要這些優(yōu)化。

既然JVM是為Java優(yōu)化的，搬上去不合適，那不如針對(duì)PHP開發(fā)一個(gè)VM？這樣就可以作大量針對(duì)性地優(yōu)化了。然而開發(fā)VM可沒有那么容易，成本不小，所以Facebook最初的選擇是將PHP編譯成C/C++之類性能優(yōu)異的語(yǔ)言。也就是HHVM的前身——HPHPc。具體的做法是將PHP翻譯為C++，然后再編譯。

相比VM，這樣的實(shí)現(xiàn)比較簡(jiǎn)單，而且能放手做優(yōu)化（因?yàn)槭请x線編譯，所以可以用時(shí)間換性能）。但是PHP的很多動(dòng)態(tài)內(nèi)容編譯成C++比較麻煩，因此HPHPc禁掉了eval()之類的特性，即使這樣，還是帶來(lái)了一些問題，特別是由于需要將動(dòng)態(tài)include的文件都編譯在一起，最終的部署文件體積太龐大了，都過G了。

和HPHPc類似的項(xiàng)目有Roadsend和phc，前者已經(jīng)不維護(hù)了，后者也是命運(yùn)坎坷。

編譯到C++的效果不好，所以Facebook最終決定，還是寫一個(gè)VM吧。

FaceBook開發(fā)HHVM的陣容相當(dāng)豪華，其中包括

Andrei Alexandrescu, 《C++ Coding Standards》的作者。

Drew Paroski，改進(jìn)了.NET虛擬機(jī)的JIT。

Jason Evans，jemalloc的開發(fā)者(jemalloc將Firefox的內(nèi)存消耗降低了一半)。

Keith Adams，VMware核心架構(gòu)。

Sara Golemon，《Extending and Embedding PHP》作者，PHP內(nèi)核領(lǐng)域的專家。

值得注意的是，Keith Adams給HHVM的影響很大。HHVM使用了JIT技術(shù)，一般的代碼通過解釋器執(zhí)行(因?yàn)镴IT也是有開銷的)，而常用的代碼則使用JIT優(yōu)化。通常而言，VM判斷是否需要進(jìn)行JIT優(yōu)化是通過以下兩種策略的一種：method-at-a-time（如果函數(shù)的執(zhí)行超過了閾值，就進(jìn)行JIT優(yōu)化）和tracing (如果循環(huán)的執(zhí)行超過了閾值，就進(jìn)行JIT優(yōu)化)。但是HHVM使用的是一種獨(dú)特的策略，basic-block-at-a-time，這個(gè)策略和VMware的x86 hypervisor相似。使用這個(gè)策略與Facebook希望支持類型推導(dǎo)的閉包有關(guān)。

上面提到了類型推導(dǎo)。事實(shí)上，F(xiàn)acebook推出了一個(gè)運(yùn)行在HHVM上的PHP改良語(yǔ)言——Hack。Hack里加入了類型的支持：

加了類型之后，除了方便大型團(tuán)隊(duì)協(xié)作，避免編程中出現(xiàn)的錯(cuò)誤之外，還有一個(gè)重要的原因就是能夠讓HHVM更好地優(yōu)化性能。JIT優(yōu)化最主要的方面就是根據(jù)類型來(lái)生成特定的指令，這樣可以減少大量的指令和條件判斷。而對(duì)于PHP這樣的動(dòng)態(tài)語(yǔ)言，要推斷清楚類型是非常困難的，所以Hack就直接讓程序員寫上了。

兼容性

HHVM除了作為Hack的VM之外，還可以運(yùn)行原生的PHP。兼容性測(cè)試表明，HHVM對(duì)PHP的兼容度已經(jīng)達(dá)到98.58%了。由于HHVM使用了獨(dú)特的JIT優(yōu)化策略，因此Facebook自行開發(fā)了tracelet輔助庫(kù)，這個(gè)庫(kù)只支持x86 64bit系統(tǒng)，所以HHVM也只能在64位系統(tǒng)上使用——不過這個(gè)問題不大，現(xiàn)在的服務(wù)器硬件基本都支持64位了。需要考慮的是PHP擴(kuò)展的問題。由于PHP語(yǔ)言包含非常之多的擴(kuò)展，而Facebook的HHVM只實(shí)現(xiàn)了自家用到的擴(kuò)展，所以可能有為HHVM重寫PHP擴(kuò)展的需要。好在相比為官方PHP實(shí)現(xiàn)寫擴(kuò)展，為HHVM寫擴(kuò)展比較容易，對(duì)性能要求不高的擴(kuò)展可以使用純PHP編寫，然后編譯到HHVM二進(jìn)制文件中即可，詳見HHVM wiki。還有一個(gè)要小心的問題就是HHVM是常駐內(nèi)存的，所以如果某處PHP代碼有內(nèi)存泄露問題的話，可能拖慢整個(gè)HHVM服務(wù)的速度，甚至導(dǎo)致HHVM掛掉。

參考


HHVM 項(xiàng)目主頁(yè)
Hack項(xiàng)目主頁(yè)
The Hiphop compiler for PHP


編撰 SegmentFault