PHP 8 新特性 JIT 理解

PHP 8 的 JIT（Just In Time）編譯器將作為擴充套件整合到 php 中 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 程式碼（命令列指令碼或者 WEB 應用）時，都要經過 PHP 直譯器。最常用的是 PHP-FPM 和 CLI 直譯器。

直譯器的工作很簡單：接收 PHP 程式碼，對其進行解釋，然後返回結果。

一般的直譯語言都是這個流程。有些語言可能會減少幾個步驟，但總體的思路相同。在 PHP 中，這個流程如下：

讀取 PHP 程式碼並將其解釋為一組稱為 Tokens 的關鍵字。這個過程讓直譯器知道各個程式都寫了哪些程式碼。 這一步稱為 Lexing 或 Tokenizing 。拿到 Tokens 集合以後，PHP 直譯器將嘗試解析他們。通過稱之為 Parsing 的過程生成抽象語法樹（AST）。這裡 AST 是一個節點集表示要執行哪些操作。比如，「 echo 1 + 1 」實際含義是 「列印 1 + 1 的結果」 或者更詳細的說 「列印一個操作，這個操作是 1 + 1」。有了 AST ，可以更輕鬆地理解操作和優先順序。將抽象語法樹轉換成可以被 CPU 執行的操作需要一個用於過渡的表示式 (IR)，在 PHP 中我們稱之為 Opcodes 。將 AST 轉換為 Opcodes 的過程稱為 compilation 。有了 Opcodes ，有趣的部分就來了： executing 程式碼！ PHP 有一個稱為 Zend VM 的引擎，該引擎能夠接收一系列 Opcodes 並執行它們。執行所有 Opcodes 後， Zend VM 就會將該程式終止。

這個圖可以讓你更清楚：

一個簡化版的 PHP 解釋流程概述。

如你所見。這裡有個問題：即使 PHP 程式碼沒改變，每次執行還是會走此流程嗎？

讓我們看回 Opcodes 。對了！這就是 Opcache 擴充套件 存在的原因。

Opcache 擴充套件

Opcache 擴充套件是 PHP 附帶的，通常沒必要停用它。使用 PHP 最好開啟 Opcache 。

它的作用是為 Opcodes 新增一個記憶體共用快取層。它的工作是從 AST 中提取新生成的 Opcodes 並快取它們，以便執行時

可以跳過 Lexing/Tokenizing 和 Parsing 步驟。

這是包含 Opcache 擴充套件的流程示意圖：

PHP 使用 Opcache 的解釋流程。如果檔案已經被解析，則 PHP 會為其獲取快取的 Opcodes ，而不是再次解析。

完美的跳過了 Lexing/Tokenizing 、 Parsing 和 Compiling 步驟 。

旁註： 這是超讚的 PHP 7.4 預載入功能 RFC ! 允許你告訴 PHP FPM 解析程式碼庫，將其轉換為 Opcodes 並且在執行之前就將其快取。

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

Just In Time 編譯有什麼效果？

聽了 Zeev 在 PHP Internals News 發表的 PHP 和 JIT 廣播 之後，我弄清了 JIT 實際做了什麼事情。

如果說 Opcache 擴充套件可以更快的獲取 Opcodes 將其直接轉到 Zend VM，則 JIT 讓它們完全不使用 Zend VM 即可執行。

Zend VM 是用 C 編寫的程式，充當 Opcodes 和 CPU 之間的一層。 JIT 在執行時直接生成編譯後的程式碼，因此 PHP 可以

跳過 Zend VM 並直接被 CPU 執行。 從理論上說，效能會更好。

這聽起來很奇怪，因為在編譯成機器碼之前，需要為每種型別的結構體編寫一個具體的實現。但實際上這也是合理的。

PHP 的 JIT 使用了名為 DynASM (Dynamic Assembler) 的庫，該庫將一種特定格式的一組 CPU 指令對映為許多不同 CPU 型別的組合程式碼。因此，編譯器只需要使用 DynASM 就可以將 Opcodes 轉換為特定結構體的機器碼。

但是，有一個問題困擾了我很久。

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

通過收聽 Zeev 的廣播，我找到的原因之一就是 PHP 是弱型別語言，這意味著在 Zend VM 嘗試執行某個操作碼之前， PHP 通常不知道變數的型別。

可以檢視 Zend_value 聯合型別 得知，很多指標指向不同型別的變數。每當 Zend VM 嘗試從 Zend_value 獲取值時，它都會使用像 ZSTR_VAL 這樣的宏，獲取聯合型別中字串的指標。

例如，這個 Zend VM handler 是處理「小於或等於」(<=) 表示式。看看它編碼這麼多的 if else 分支，只是為了型別推斷。

使用機器碼執行型別推斷邏輯是不可行的，並且可能變得更慢。

先求值再編譯也不是一個好選擇，因為編譯為機器碼是 CPU 密集型任務。因此，在執行時編譯所有內容也不好。

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

現在我們知道無法很好的推斷型別來提前編譯。我們也知道在執行時進行編譯的運算成本很高。那麼 JIT 對 PHP 有何好處呢？

為了尋求平衡， PHP 的 JIT 嘗試只編譯有價值的 Opcodes 。為此， JIT 會分析 Zend VM 要執行的 Opcodes 並檢查可能編譯的地方。（根據組態檔）

當某個 Opcode 編譯後，它將把執行交給該編譯後的程式碼，而不是交給 Zend VM 。看起來如下：

PHP 的 JIT 解釋流程。如果已編譯，則 Opcodes 不會通過 Zend VM 執行。

因此，在 Opcache 擴充套件中，有兩條檢測指令判斷要不要編譯 Opcode 。如果要，編譯器將使用 DynASM 將此 Opcode 轉換為機器碼，並執行此機器碼。

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

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

我仍然不確定編譯部分什麼時候有效進行，但我想現在我真的不想知道。

所以你的效能收益可能不會很大

我希望現在大家都很清楚為什麼大多數 php 應用程式不會因為使用即時編譯器而獲得很大的效能收益。這也是為什麼 Zeev 建議為你的應用程式分析和試驗不同的 JIT 設定是最好的方法。

如果您使用的是 PHP FPM，則通常會在多個請求之間共用已編譯的操作碼，但這仍然不能改變遊戲規則。

這是因為 JIT 優化了計算密集型的操作，而如今大多數 php 應用程式比其他任何東西都更受 I/O 約束。如果您無論如何都要存取磁碟或網路，則處理操作是否已編譯則無關緊要。時間上將非常相似。

除非…

你正在做一些不受 I/O 約束的事情， 像影象處理或機器學習。 任何不接觸 I/O 的東西都將受益於 JIT 編譯器。

這也是為什麼現在人們說我們更願意用 PHP 編寫原生功能而不是 C 編寫的原因。 如果仍然要編譯此功能，則開銷將毫無表現力。