您好,欢迎访问一九零五行业门户网

“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的第三方模块会产生兼容性问题。
其它类似信息

推荐信息