瞭解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函數的緣由。若是仍然編譯此類函數，則開銷將沒法表達。

程序員的歡樂時光……