Home  >  Article  >  Backend Development  >  “Facebook 开发的高性能PHP虚拟机 HHVM 比官方的 PHP解释器 快超过9倍”的说法是否属实?

“Facebook 开发的高性能PHP虚拟机 HHVM 比官方的 PHP解释器 快超过9倍”的说法是否属实?

WBOY
WBOYOriginal
2016-06-17 08:32:06970browse
github.com/facebook/hhv
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分支,添加了类型支持,语法上大致就从

<span class="x">$i = 1;</span>

回复内容:

PHP5.2时代,这样的测评结果是有可能的,这是PHP5.3依赖,PHP核心团队把性能改善拍排在很前面的原因。

HHVM快是因为JIT,能在运行时先动态优化再编译执行:

1.

比如
<code class="language-text">// 定义两个function
function foo() {}
function bar() {}
// 调用只用到foo(),没用到bar()
foo()
</code>
争论这个完全 没有意义~ 这就好比争论公鸡和母鸡谁更能下单 ~ 除非你有机会能进程亿级这个量级 才能有机会接触这个。。 如果真到那个时候 你已经超越码农存在 也不会在知乎上。 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的第三方模块会产生兼容性问题。
Statement:
The content of this article is voluntarily contributed by netizens, and the copyright belongs to the original author. This site does not assume corresponding legal responsibility. If you find any content suspected of plagiarism or infringement, please contact admin@php.cn