了解PHP 8的JIT

PHP 8的即时编译器是Opcache扩展的一部分，旨在在运行时将某些操做码编译为CPU指令。

这意味着使用JIT，Zend VM不须要解释某些操做码，而且这些指令将直接做为CPU级指令执行。

PHP 8的JIT

PHP 8将带来的最受评论的功能之一是Just In Time（JIT）编译器。许多博客和社区都在谈论它，而且确定会引发很大的轰动，可是到目前为止，我发现关于JIT应该作什么的细节不多。

通过屡次研究和放弃后，我决定亲自检查PHP源代码。结合我对C语言的一点了解以及到目前为止所收集的全部分散信息，我提出了这篇文章，但愿它也能够帮助您更好地理解PHP的JIT。

简化了事情：当JIT按预期工做时，您的代码将不会经过Zend VM执行，而是直接做为一组CPU级指令执行。

这就是整个想法。

可是要更好地理解它，咱们须要考虑php在内部如何工做。不是很复杂，可是须要一些介绍。

我写了一篇博客文章，其中概述了php的工做原理。若是您认为此处的帖子太过密集，则只需检查另外一个便可，稍后再回来。事情变得更容易理解。

PHP代码如何执行？

咱们都知道php是一种解释语言。但这究竟是什么意思？

每当您要执行PHP代码时（不管是代码段仍是整个Web应用程序），都必须经过php解释器。最经常使用的是PHP FPM和CLI解释器。

他们的工做很是简单：接收php代码，对其进行解释，而后将结果返回回去。

一般，每种解释语言都会发生这种状况。有些人可能会删除一些步骤，但整体思路是相同的。在PHP中，它是这样的：

1. 读取PHP代码并将其转换为一组称为Token的关键字。经过此过程，解释器能够了解在程序的哪一个部分中编写了哪些代码。第一步称为Lexing或Tokenizing。
2. 有了令牌，PHP解释器将分析此令牌集合并尝试使它们有意义。结果，经过称为解析的过程生成了抽象语法树（AST）。此AST是一组节点，指示应执行哪些操做。例如，“ echo 1 +1”实际上应表示“打印1 +1的结果”或更实际地是“打印操做，该操做为1 +1”。
3. 例如，借助AST，能够更轻松地了解操做和优先级。将这棵树转换成能够执行的东西须要一个中间表示（IR），在PHP中咱们称之为操做码。将AST转换为操做码的过程称为编译。
4. 如今，有了Opcodes即是有趣的部分：执行代码！PHP具备称为Zend VM的引擎，该引擎可以接收操做码列表并执行它们。执行全部操做码后，Zend VM存在而且该程序终止。

我有一个图表，可让您更加清楚：

有关PHP解释流程的简化概述。

如您所见，很简单。可是这里有一个瓶颈：若是您的php代码可能不会常常更改，那么每次执行代码时对其进行词法分析和解析有什么意义？

最后，咱们只关心操做码，对吗？对！这就是存在Opcache扩展的缘由。

Opcache扩展

Opcache扩展是PHP附带的，一般没有太大的理由要停用它。若是使用PHP，则可能应该打开Opcache。

它的做用是为操做码添加一个内存共享缓存层。它的工做是从AST中提取新生成的操做码并将其缓存，以便进一步执行能够轻松地跳过词法分析和语法分析阶段。

这是考虑了Opcache扩展的流程示意图：

PHP使用Opcache的解释流程。若是文件已经被解析，则php会为其获取缓存的操做码，而不是再次解析。

惊讶地看到它如何精美地跳过了Lexing，解析和编译步骤iling。

旁注：这就是PHP 7.4的预加载功能大放异彩的地方！它使您能够告诉PHP FPM解析代码库，将其转换为操做码并甚至在执行任何操做以前就将其缓存。

您可能想知道JIT的位置，对吗？我但愿如此，这就是为何我要写这篇文章的缘由……

即时编译器有效地作什么？

在听完PHP Internals News的PHP和JIT播客专题节目中的Zeev的解释后，我对JIT的实际用途有了一些了解。

若是Opcache使获取操做码的速度更快，以便它们能够直接转到Zend VM，则应该使用JIT使它们彻底在没有Zend VM的状况下运行。

Zend VM是用C编写的程序，充当操做码和CPU自己之间的一层。JIT的做用是在运行时生成编译的代码，所以php能够跳过Zend VM并直接进入CPU。从理论上讲，咱们应该从中得到性能。

起初，这听起来很奇怪，由于要编译机器代码，您须要为每种类型的体系结构编写一个很是具体的实现。但实际上这是很合理的。

PHP的JIT实现使用名为DynASM（动态汇编程序）的库，该库将一种特定格式的一组CPU指令映射为许多不一样CPU类型的汇编代码。所以，即时编译器使用DynASM将操做码转换为特定于体系结构的机器代码。

可是，有一个想法困扰了我不少时间了……

若是预加载可以在执行以前将php代码解析为操做码，而且DynASM能够将操做码编译为机器代码（及时编译），那为何咱们不当即使用Ahead of Time编译当即编译PHP？

经过听Zeev的一集，我获得的线索之一就是PHP的类型很弱，这意味着PHP一般在Zend VM尝试执行某个操做码以前才知道变量的类型。

经过查看zend_value联合类型，能够看出这一点，该类型具备许多指向变量的不一样类型表示形式的指针。每当Zend VM尝试从zend_value中获取值时，它都会使用ZSTR_VAL之类的宏来尝试从值联合访问字符串指针。

例如，该Zend VM处理程序应处理“更小或等于”（<=）表达式。看一下它如何分支到许多不一样的代码路径中，只是为了猜想操做数类型。

用机器代码复制这种类型推断逻辑是不可行的，而且可能使事情变得更慢。

在对类型进行求值后编译全部内容也不是一个好选择，由于编译为机器代码是一项占用大量CPU的任务。所以，在运行时编译全部内容也是很差的。

即时编译器的行为如何？

如今咱们知道咱们没法推断类型来生成足够好的提早编译。咱们也知道在运行时进行编译很昂贵。JIT对PHP有何好处？

为了平衡此等式，PHP的JIT尝试仅编译一些认为能够产生回报的操做码。为此，它将分析Zend VM正在执行的操做码，并检查哪些代码可能有意义。（根据您的配置）

编译某个操做码后，它将把执行委派给该已编译代码，而不是委派给Zend VM。看起来以下：

PHP的JIT解释流程。若是已编译，则操做码不会经过Zend VM执行。

所以，在Opcache扩展中，有两条指令可检测是否应编译某个Opcode。若是是，则编译器而后使用DynASM将此操做码转换为机器代码，并执行此新生成的机器代码。

有趣的是，因为当前实现中已编译的代码以兆字节为单位（也是可配置的），所以代码执行必须可以在JIT和解释的代码之间无缝切换。

顺便说一下，来自Benoit Jacquemont的有关php JIT的演讲帮助我了解了不少事情。

我仍不肯定编译部分什么时候有效进行，但我想我如今暂时不想知道。

所以，您的性能提高可能不会很大

我但愿如今更加清楚，为何每一个人都在说大多数php应用程序不会由于使用Just In Time编译器而得到巨大的性能优点。为何Zeev建议为您的应用程序分析和试验不一样的JIT配置是最好的方法。

若是使用PHP FPM，一般将在多个请求之间共享已编译的操做码，但这仍然不能改变游戏规则。

这是由于JIT优化了CPU约束的操做，而且当今大多数php应用程序都比任何东西受I / O约束更多。不论是否要访问磁盘或网络，处理操做是否已编译都没有关系。时间将很是类似。

除非…

您正在执行不受I / O约束的操做，例如图像处理或机器学习。任何不接触I / O的东西都将从“即时编译器”中受益。

这也是为何人们如今说咱们更愿意编写用PHP而不是C编写的本机PHP函数的缘由。若是仍然编译此类函数，则开销将没法表达。

程序员的欢乐时光……