這篇文章帶大家了解一下PHP 8 中的 JIT，並聊聊JIT 是怎麼參與解釋流程的，希望對(duì)大家有幫助！

PHP 8 的JIT（Just In Time）編譯器將作為擴(kuò)充整合到php 中?Opcache 擴(kuò)充?用於執(zhí)行時(shí)間將某些操作碼直接轉(zhuǎn)換為從cpu 指令。

這表示使用JIT後，Zend VM 不需要解釋某些操作碼，而這些指令將直接作為CPU級(jí)指令執(zhí)行。

PHP 8 的 JIT

PHP 8 Just In Time(JIT)編譯器帶來(lái)的影響是毋庸置疑的。但到目前為止，我發(fā)現(xiàn)關(guān)於 JIT 應(yīng)該做什麼卻知之甚少。

經(jīng)過(guò)多次研究和放棄，我決定親自檢查PHP原始碼。結(jié)合我對(duì)C語(yǔ)言的一些知識(shí)和我目前收集到的所有零散信息，我提出了這篇文章，我希望它能幫助您更好地理解PHP的JIT。

簡(jiǎn)單一點(diǎn)來(lái)說(shuō) ： 當(dāng)JIT如預(yù)期運(yùn)作時(shí)，您的程式碼不會(huì)透過(guò)Zend VM執(zhí)行，而是作為一組CPU級(jí)指令直接執(zhí)行。

這就是全部的想法。

但為了更好地理解它，我們需要考慮php如何在內(nèi)部運(yùn)作。不是很複雜，但需要一些介紹。

我寫(xiě)了一篇部落格文章，大致概述了php的工作原理。如果你覺(jué)得這篇文章寫(xiě)太多了，就去查另一篇，稍後再來(lái)。事情會(huì)變得更容易理解。

PHP的程式碼是怎麼執(zhí)行的?

總所周知， PHP 是解釋型語(yǔ)言，但這句話本身是什麼意思呢？

每次執(zhí)行 PHP 程式碼（命令列腳本或 WEB 應(yīng)用程式）時(shí)，都要經(jīng)過(guò) PHP 解譯器。最常用的是 PHP-FPM 和 CLI 解譯器。

解釋器的工作很簡(jiǎn)單：接收 PHP 程式碼，對(duì)其進(jìn)行解釋，然後傳回結(jié)果。

一般的解釋型語(yǔ)言都是這個(gè)流程。有些語(yǔ)言可能會(huì)減少幾個(gè)步驟，但總體的思路相同。在 PHP 中，這個(gè)流程如下：

• 讀取 PHP 程式碼並將其解釋為一組稱為 Tokens 的關(guān)鍵字。這個(gè)過(guò)程讓解釋器知道各個(gè)程式都寫(xiě)了哪些程式碼。 這一步稱為 Lexing 或 Tokenizing 。

• 拿到 Tokens 集合以後，PHP解譯器會(huì)試著解析他們。透過(guò)稱為 Parsing 的過(guò)程產(chǎn)生抽象語(yǔ)法樹(shù)（AST）。這裡 AST 是一個(gè)節(jié)點(diǎn)集表示要執(zhí)行哪些動(dòng)作。例如，「 echo 1 1 」實(shí)際意義是 「印 1 1 的結(jié)果」 或者更詳細(xì)的說(shuō) 「印出一個(gè)動(dòng)作，這個(gè)動(dòng)作是 1 1」。

• 有了 AST ，可以更輕鬆地理解操作和優(yōu)先順序。將抽象語(yǔ)法樹(shù)轉(zhuǎn)換成可以被 CPU 執(zhí)行的操作需要一個(gè)用於過(guò)渡的表達(dá)式(IR)，在 PHP 中我們稱為 Opcodes 。將 AST 轉(zhuǎn)換為 Opcodes 的過(guò)程稱為 compilation 。

• 有了 Opcodes ，有趣的部分就來(lái)了： executing 程式碼！?PHP 有一個(gè)稱為 Zend VM 的引擎，該引擎能夠接??收一系列 Opcodes 並執(zhí)行它們。執(zhí)行所有 Opcodes 後， Zend VM 就會(huì)將程式終止。

這個(gè)圖可以讓你更清楚：

#一個(gè)簡(jiǎn)化版的 PHP 解釋流程概述。

如你所見(jiàn)。這裡有個(gè)問(wèn)題：即使 PHP 程式碼沒(méi)改變，每次執(zhí)行還是會(huì)走此流程嗎？

讓我們看回 Opcodes 。對(duì)了！這就是 Opcache 擴(kuò)充 存在的原因。

Opcache 擴(kuò)充功能

Opcache 擴(kuò)充是 PHP 附帶的，通常沒(méi)必要停用它。使用 PHP 最好開(kāi)啟 Opcache 。

它的作用是為 Opcodes 增加一個(gè)記憶體共享快取層。它的工作是從 AST 中提取新生成的 Opcodes 並快取它們，以便執(zhí)行時(shí)可以跳過(guò) Lexing/Tokenizing 和 Parsing 步驟。

這是包含 Opcache 擴(kuò)充功能的流程示意圖：

PHP 使用 Opcache 的解釋流程。如果檔案已經(jīng)被解析，則 PHP 會(huì)為其取得快取的 Opcodes ，而不是再次解析。

完美的跳過(guò)了 Lexing/Tokenizing 、 Parsing 和 Compiling 步驟 ? 。

附註：?這是超讚的?PHP 7.4 預(yù)先載入功能 RFC ?! 允許你告訴 PHP FPM 解析程式碼庫(kù)，將其轉(zhuǎn)換為 Opcodes 並且在執(zhí)行之前就將其快取。

你想知道JIT是怎麼參與這個(gè)解釋流程的嗎？這篇文章的將說(shuō)明。

Just In Time 編譯有什麼效果?

聽(tīng)了 Zeev 在 PHP Internals News 發(fā)表的 PHP 和 JIT 廣播 之後，我弄清楚了 JIT 實(shí)際做了什麼事情。

如果說(shuō) Opcache 擴(kuò)充功能可以更快的取得 Opcodes 將其直接轉(zhuǎn)到 Zend VM，則 JIT 讓它們完全不使用 Zend VM 即可運(yùn)作。

Zend VM 是用 C 編寫(xiě)的程序，可作為 Opcodes 和 CPU 之間的一層。 JIT 在執(zhí)行階段直接產(chǎn)生編譯後的程式碼，因此 PHP 可以跳過(guò) Zend VM 並直接被 CPU 執(zhí)行。 從理論上說(shuō)，性能會(huì)更好。

這聽(tīng)起來(lái)很奇怪，因?yàn)樵诰幾g成機(jī)器碼之前，需要為每種類(lèi)型的結(jié)構(gòu)體寫(xiě)一個(gè)具體的實(shí)作。但其實(shí)這也是合理的。

PHP 的 JIT 使用了名為?DynASM (Dynamic Assembler) ?的函式庫(kù)，該函式庫(kù)將特定格式的一組 CPU 指令對(duì)應(yīng)為許多不同 CPU 類(lèi)型的彙編程式碼。因此，編譯器只需要使用 DynASM 就可以將 Opcodes 轉(zhuǎn)換為特定結(jié)構(gòu)體的機(jī)器碼。

但是，有一個(gè)問(wèn)題困擾了我很久。

如果預(yù)先載入能夠在執(zhí)行之前將PHP 程式碼解析為Opcodes，而DynASM 可以將Opcodes 編譯為機(jī)器碼(Just In Time 編譯) ，為什麼我們不立即使用執(zhí)行前編譯(Ahead of Time 編譯) 立刻編譯PHP 呢？

透過(guò)收聽(tīng) Zeev 的廣播，我找到的原因之一是 PHP 是弱型別語(yǔ)言，這表示在 Zend VM 嘗試執(zhí)行某個(gè)操作碼之前， PHP 通常不知道變數(shù)的型別。

可以查看?Zend_value 聯(lián)合類(lèi)型 得知, 很多指標(biāo)指向不同類(lèi)型的變數(shù)。每當(dāng) Zend VM 嘗試從 Zend_value 取得值時(shí)，它都會(huì)使用像?ZSTR_VAL?這樣的宏，取得聯(lián)合類(lèi)型中字串的指標(biāo)。

例如，這個(gè) Zend VM handler 是處理「小於或等於」(

使用機(jī)器碼執(zhí)行類(lèi)型推斷邏輯是不可行的，並且可能變得更慢。

先求值再編譯也不是個(gè)好選擇，因?yàn)榫幾g成機(jī)器碼就是 CPU 密集型任務(wù)。因此，在運(yùn)行時(shí)編譯所有內(nèi)容也不好。

那麼 Just In Time 編譯是怎麼做的?

現(xiàn)在我們知道無(wú)法很好的推論類(lèi)型來(lái)提前編譯。我們也知道在運(yùn)行時(shí)進(jìn)行編譯的運(yùn)算成本很高。那麼 JIT 對(duì) PHP 有何好處呢？

為了尋求平衡， PHP 的 JIT 嘗試只編譯有價(jià)值的 Opcodes 。為此， JIT 會(huì)分析 Zend VM 要執(zhí)行的 Opcodes 並檢查可能編譯的地方。 （根據(jù)設(shè)定檔）

當(dāng)某個(gè) Opcode 編譯後，它將把執(zhí)行交給該編譯後的程式碼，而不是交給 Zend VM ?？雌饋?lái)如下：

PHP 的 JIT 解釋流程。如果已編譯，則 Opcodes 不會(huì)透過(guò) Zend VM 執(zhí)行。

因此，在 Opcache 擴(kuò)充中，有兩個(gè)偵測(cè)指令判斷要不要編譯 Opcode 。如果要，編譯器將使用 DynASM 將此 Opcode 轉(zhuǎn)換為機(jī)器碼，並執(zhí)行此機(jī)器碼。

有趣的是，由於目前介面中編譯的程式碼有 MB 的限制(也是可設(shè)定的)，所以程式碼執(zhí)行必須能夠在 JIT 和解釋程式碼之間無(wú)縫切換。

順便說(shuō)一句，Benoit Jacquemont 在 php 的 JIT 上的這篇演講幫助我理解了這整件事。

我仍然不確定編譯部分什麼時(shí)候有效進(jìn)行，但我想現(xiàn)在我真的不想知道。

所以你的效能收益可能不會(huì)很大

我希望現(xiàn)在大家都很清楚為什麼大多數(shù) php 應(yīng)用程式不會(huì)因?yàn)槭褂眉磿r(shí)編譯器而獲得很大的效能效益。這也是為什麼 Zeev 建議為你的應(yīng)用程式分析和試驗(yàn)不同的 JIT 配置是最好的方法。

如果您使用的是PHP FPM，則通常會(huì)在多個(gè)請(qǐng)求之間共用已編譯的操作碼，但這仍然不能改變遊戲規(guī)則。

這是因?yàn)镴IT優(yōu)化了計(jì)算密集型的操作，而如今大多數(shù)php應(yīng)用程式比其他任何東西都更受I/O約束. 如果您無(wú)論如何都要訪問(wèn)磁碟或網(wǎng)絡(luò)，則處理操作是否已編譯則無(wú)關(guān)緊要。時(shí)間上將非常相似。

除非…

你正在做一些不受I/O約束的事情， 像是圖像處理或機(jī)器學(xué)習(xí)。任何不接觸I/O的東西都將受益於JIT編譯器。

這也是為什麼現(xiàn)在人們說(shuō)我們更願(yuàn)意用PHP寫(xiě)原生功能而不是C寫(xiě)的原因。如果仍然要編譯此功能，則開(kāi)銷(xiāo)將毫無(wú)表現(xiàn)力。

有趣的時(shí)光成為一個(gè)PHP程式設(shè)計(jì)師…

希望本文對(duì)您有幫助，讓您能更好的理解PHP8的JIT。

原文網(wǎng)址：https://thephp.website/en/issue/php-8-jit/

推薦：《PHP視頻教程》

以上是一文深入了解 PHP 8 中的 JIT的詳細(xì)內(nèi)容。更多資訊請(qǐng)關(guān)注PHP中文網(wǎng)其他相關(guān)文章！