php8.0增加了哪些功能

php8.0增加了哪些功能？很多新手對此不是很清楚，為了幫助大家解決這個難題，下面小編將為大家詳細講解，有這方面需求的人可以來學習下，希望你能有所收獲。

什么是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本質上是復雜的觀點聯系起來時，請考慮我們花在引入新特性上的大部分時間實際上是花在討論該特性上的。對于大多數功能，甚至修復，代碼可能需要幾分鐘或幾小時的編寫時間，而討論則需要幾周或幾個月的時間。在極少數情況下，一個特性的代碼可能需要幾個小時或幾天的時間來編寫，但在這些極少數情況下，討論總是需要更長的時間。

看完上述內容是否對您有幫助呢？如果還想對相關知識有進一步的了解或閱讀更多相關文章，請關注億速云行業資訊頻道，感謝您對億速云的支持。