為什麼facebook的hiphop要把php轉換成了C++，而不是把php改成編譯型的語言。。。直接執行編譯後的檔案不是更快嗎？
回複內容：
首先得把曆史看完整了：Facebook在HipHop（HPHPc）之後推出了HHVM（HipHop VM），前者是（在運行前）把PHP編譯為C++再編譯為機器碼，而後者是（在運行時）把PHP編譯為機器碼。所以說是可以把PHP編譯為機器碼，而且Facebook也已經在HPHPc和HHVM裡都這麼做了。
（當然，HHVM要把PHP編譯為機器碼也經過了幾種內部形式，只不過沒有像HPHPc那樣選用暴露在外的C++作為編譯的中間形式而已。）
於是剩下的問題是：
1、為什麼HPHPc要選擇把PHP編譯為C++再編譯為機器碼？
2、什麼時候編譯為機器碼？哪些東西不便於事先（AOT）編譯為機器碼？
先討論第一個問題。
HPHPc是一種AOT編譯（Ahead-Of-Time）方案，它所支援的PHP的子集其實就可以說是“編譯型”的了。其最終目標也是把PHP編譯為機器碼。具體做法是先編譯到C++，再利用普通C++編譯器最終編譯到機器碼。這樣其實是拿C++當作了編譯器的IR（intermediate representation，中間表示）來用，因為已經有現成的C++編譯器可以把C++源碼編譯到機器碼，等於編譯器後端（IR -> 機器碼）的功夫可以省下來，只要寫個編譯器前端（源碼 -> IR）即可。這就是前面各位的回答提到的觀點。
直接執行編譯後的檔案不是更快嗎？
C++源碼也不是“直接執行”撒。還是得用C++編譯器編譯到機器碼。要把事情看完整了。
以前類似的方案還有以C--
或者乾脆以C為目標語言，先把自己的語言編譯為C--或者C，然後拿現成的C編譯器當編譯器後端來用。
其實還有一個好處，那就是HipHop的runtime是用C++寫的：像Variant
這樣的內建類型是用一個C++類來實現的，要跟這樣的runtime連結起來，最方便的做法還是產生C++代碼——剩下的事情就交給現成的連結器（linker）解決就好。C++很少跟其它語言編譯出來的目標代碼直接連結，通常C++要跟別的native語言互動都會export出一組C介面；甚至不同C++編譯器編譯出來的目標代碼之間都不一定能連結在一起。把PHP編譯為C++源碼就完全不用自己管連結啊相容性啥的問題了。
好奇的同學可以去看看HPHPc產生的C++代碼長啥樣。例如爆棧上的一帖所說：What does the C++ output of the HipHop PHP compiler look like?
再來討論第二個問題。
把整個編譯流出都算上，HPHPc + g++是在使用者寫的PHP代碼執行前就把PHP編譯為機器碼的，是AOT；而HHVM則是在使用者寫的PHP代碼正在執行的時候把PHP編譯為機器碼的，是動態編譯器（籠統說它是JIT編譯器也行，但嚴格說它比JIT編譯器的工作時機要更遲一些）。
AOT編譯不便於應對在運行時才被產生/載入的PHP源碼，所以它要支援eval就比較困難。通常一個AOT方案要應對動態產生/載入的代碼，會在runtime裡帶上一個解譯器或者JIT編譯器，那這個runtime的實現複雜度就變得跟一個完整的VM差不多了。所以HPHPc選擇乾脆不支援eval、create_function()之類的動態功能。
而在運行時編譯（JIT或者說動態編譯）則可以完美的應對動態載入的代碼，反正你動態產生我就拿過來動態編譯，兵來將擋水來土掩。HHVM選擇了這條路，因此也可以支援更大的PHP子集。
其缺點是因為編譯是在運行時進行的，所以編譯時間也得算進已耗用時間裡，這樣編譯就不便於做重量級的、效費比低的最佳化，實現JIT編譯器要更小心的考慮效費平衡。因為他們不想重新寫一遍IL到機器碼的過程，搞這個巨麻煩。你知道產生機器碼是一個多麼喪心病狂的事情嗎？謝邀~逼格高的回答就不說了，解釋型語言和編譯型語言在寫法，項目結構，編碼思路有根本上的區別的，如果創造了一個php是編譯型的，光創造語言這個成本巨大不說，現有業務已經是PHP寫好的，如果更換為新語言，還不如全部重新用成熟的編譯型語言比如java寫~你看，號稱輪子哥的 @vczh發明的語言也大多是虛擬機器語言或者編譯到CLI的，產生本地代碼需要大量的編程工作和最佳化工作，相對於成熟的c++編譯器來說，重新寫一個php編譯器明顯是費力不討好的事情。這個太麻煩了，他們~~~~
