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

为什么facebook的hiphop要把php转换成了C++,而不是把php改成编译型的语言。。。直接执行编译后的文件不是更快么?
关注者
140
被浏览
7248
首先得把历史看完整了: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编译器要更小心的考虑效费平衡。