为什么facebook的hiphop要把php转换成了C++而不是把php改成编译型的语言，直接执行编译后的文件不是更快么？

为什么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编译器明显是费力不讨好的事情。 这个太麻烦了，他们~~~~