什么是JIT？
PHP实现了一个虚拟机，一种虚拟处理器，我们称之为Zend VM。PHP将人类可读的脚本编译成虚拟机能够理解的指令（我们称之为操作码），这个执行阶段就是我们所说的“编译时”。在执行的“运行时”阶段，虚拟机（Zend VM）执行代码的指令（操作码）。
这一切工作得很好，像APC（过去）和OPCache（现在）这样的工具可以缓存代码的指令（操作码），以便“编译时”只在必须的时候发生。
首先，有一行代码解释了什么是JIT：
Just-in-time 是一种编译器策略，它接受代码的中间表示形式，并在运行时将其转换为依赖于体系结构的机器代码，以便及时执行。
在PHP中，这意味着JIT将为Zend VM生成的指令作为中间表示，并发出依赖于体系结构的机器代码，因此代码的宿主不再是ZendVM，而是CPU。
为什么PHP需要JIT？
在PHP 7.0之前，PHP内部社区关注的焦点是性能，这是由Facebook的HHVM项目带来的良性竞争带来的。PHP 7.0中的大部分核心更改都包含在PHPNG补丁中，这大大改进了PHP在其核心上利用内存和CPU的方式，从那时起，我们每个人都被迫关注性能。
自PHP 7.0以来，已经有了一些性能改进，HashTable （PHP的核心数据结构）的优化，某些操作码的Zend VM的专门化，某些序列的编译器的专门化，以及对OPCache的优化器组件的不断改进。。。除此之外还有很多其他的，太无聊了。
这是一个残酷的事实，这些优化只能带我们到目前为止，我们正在迅速接近，或可能已经遇到了砖墙，在我们的能力，以进一步改善它。
注意：当我们说“我们不能再改进了”时，我们真正的意思是，“我们必须做出取舍，以进一步改进它不再看起来有吸引力”。。。每当我们讨论性能优化时，我们都在讨论权衡。通常，在简单性和性能之间进行权衡。我们都想认为最简单的代码是最快的代码，但在现代的C编程世界中，情况并非如此。最快的代码通常是准备利用依赖于体系结构的内部函数或依赖于平台（编译器）的内部函数的代码。简单并不能保证最好的性能。
此时，PHP的JIT功能似乎是从PHP获得更多性能的最佳方法。
JIT会让我的网站更快吗？
很有可能，并不明显。
也许不是您期望的答案：在一般情况下，用PHP编写的应用程序是I/O绑定的，JIT在CPU绑定的代码上工作得最好。
“I/O和CPU绑定”到底是什么意思？
当我们想要描述一段代码或一个应用程序的一般性能特征时，我们使用术语I/O绑定和CPU绑定。
最简单的说法是：
-
如果我们能够改进（减少、优化）它所做的I/O，那么一段I/O绑定的代码将会运行得更快。
-
如果我们能够改进（减少、优化）CPU正在执行的指令，或者（神奇地）提高CPU的时钟速度，那么一段CPU限制的代码就会运行得更快：）
-
一段代码或一个应用程序可以是I/O绑定、CPU绑定，或者与CPU和I/O同等绑定。
-
一般来说，PHP应用程序往往是I/O绑定的——减慢它们速度的是它们正在执行的I/O——连接、读取和写入数据库、缓存、文件、套接字等等。
CPU绑定的PHP是什么样子的？
由于大多数PHP应用程序的性质，许多PHP程序员并不熟悉CPU绑定代码——他们的工作往往是连接到某个数据库，或者可能是一个缓存，做一些轻量级的工作，并输出html/json/xml响应。
您可能会环顾代码库，发现许多与I/O无关的代码，甚至调用与I/O完全断开连接的函数的代码，并且会感到困惑，我似乎是在暗示这并没有使您的应用程序CPU受到限制，即使处理非I/O的代码行数可能比I/O多。
PHP实际上相当快，它是世界上解释速度最快的语言之一。Zend VM调用与I/O无关的函数和在机器代码中进行相同的调用之间没有显著的区别。
这显然是有区别的，但事实是，机器代码有一个调用约定，Zend VM有一个调用约定，机器代码有一个序言，Zend VM有一个序言：在Zend操作码中调用某个c_level_function（）还是机器代码对调用应用程序的性能没有显著影响-尽管这似乎对那个电话有很大的影响。
注意：调用约定大致是指在进入另一个函数之前执行的一系列指令，序言是指在进入另一个函数时执行的一系列指令：在这两种情况下，调用约定都将参数推送到堆栈上，序言将它们从堆栈中弹出。
循环、尾调用和X呢？我听说你问过：PHP实际上非常聪明，启用了OPCache的优化器组件，你的代码就好像被魔法转化成了你能编写的最有效的形式。
现在需要注意的是，JIT不会改变Zend函数的调用约定，而不是VM建立的约定-Zend必须能够在任何时候在JIT和VM模式之间切换，因此决定保留VM建立的调用约定。因此，当JIT运行时，随处可见的那些调用并没有明显地加快速度。
如果您想了解CPU绑定的PHP代码是什么样子的，请查看Zend/bench.php文件… 这显然是一个极限的CPU代码示例，但它应该让我们知道JIT真正的亮点是在数学领域。
PHP是否为加快数学速度做出了最终的权衡？
不，我们这样做是为了扩大PHP的范围，而且相当大。
在这个非常偏颇的PHP开发人员看来，如果你在2019年是一名web程序员，你还没有考虑在下一个项目中使用PHP，那么你做的web是错误的。
在PHP中提高更快地执行数学的能力，乍一看，似乎是一个非常狭窄的范围。
然而，这实际上为机器学习、3d渲染、2d（gui）渲染和数据分析（仅举几个例子）打开了大门。
为什么我们不能在PHP 7.4中使用它呢？
我刚刚把JIT称为“最终的权衡”，我认为它是：它可以说是有史以来最复杂的编译器策略之一，也许是最复杂的。引入JIT就是引入相当的复杂性。
如果你问Dmitry（JIT的作者）他是否让PHP变得复杂，他会说“不，我讨厌复杂性”（这是一个直接的引语）。
归根结底，复杂是我们所不了解的，而目前，真正了解JIT实现的内部开发人员（不到几个）很少。
PHP 7.4的发展很快，合并到php7.4中会给我们留下一个PHP版本，只有不到几个人可以调试、修复或改进（在任何实际意义上）。对于那些对合并到PHP 7.4投反对票的人来说，这种情况是不可接受的。
在从现在到PHP 8的这段时间里，我们中的许多人将在业余时间努力理解JIT：
我们仍然有一些要实现的特性和需要为php8重写的工具，首先我们必须理解JIT。我们需要这一次，并非常感谢大多数选民认为适合把它交给我们。
复杂并不是可怕的同义词：
复杂可以是美丽的，就像星云一样，JIT就是那种复杂。原则上，你可以完全理解某件复杂的事情，并且只在表面上的复杂程度上稍微降低一点。换句话说，即使有20个内部开发人员和Dmitry一样熟悉JIT，它也不会真正改变JIT的复杂性。
PHP的开发速度会减慢吗？
没有理由认为会这样。我们有足够的时间可以满怀信心地说，到PHP 8普遍可用时，我们中已经有足够多的人熟悉JIT，至少在修复bug和推动PHP向前发展方面能够像今天一样发挥作用。
当试图将这一点与JIT本质上是复杂的观点联系起来时，请考虑我们花在引入新特性上的大部分时间实际上是花在讨论该特性上的。对于大多数功能，甚至修复，代码可能需要几分钟或几小时的编写时间，而讨论则需要几周或几个月的时间。在极少数情况下，一个特性的代码可能需要几个小时或几天的时间来编写，但在这些极少数情况下，讨论总是需要更长的时间。
原创文章，作者：FQIAH，如若转载，请注明出处：http://www.wangzhanshi.com/n/15289.html
