(轉)WASM（WebAssember）快速瞭解第二篇——快速瞭解JIT

這是有關WebAssembly的系列文章的第二部分，若是您尚未閱讀其餘文章，咱們建議從頭開始。

JavaScript的啓動速度很慢，但後來有了所謂的JIT，它變得更快。可是，JIT如何工做？

瀏覽器如何運行JavaScript

當您做爲開發人員向頁面添加JavaScript時，您就有目標和問題。

目標：您想告訴計算機該怎麼作。

問題：您和計算機使用不一樣的語言。

您說人類語言，而計算機說機器語言。即便您不將JavaScript或其餘高級編程語言視爲人類語言，也是如此。它們是爲人類認知而不是機器認知而設計的。

所以，JavaScript引擎的工做是採用您的人工語言並將其變成機器能夠理解的東西。

我認爲這就像電影《到來》，其中有人和外星人試圖互相交談。

在那部電影中，人類和外星人不僅是逐字翻譯。兩組對世界的見解不一樣。人和機器也是如此（我將在下一篇文章中對此進行更多說明）。

那麼翻譯如何發生？

在編程中，一般有兩種翻譯成機器語言的方法。您可使用解釋器或編譯器。

有了翻譯員，這種翻譯幾乎是逐行進行的。

 另外一方面，編譯器不會即時進行翻譯。它能夠提早建立該翻譯並將其記錄下來。

這些處理翻譯的方式各有利弊。

解釋器的利弊

解釋器能夠快速啓動並運行。在開始運行代碼以前，無需完成整個編譯步驟。您只需開始翻譯第一行並運行它。

所以，解釋器彷佛很適合JavaScript之類的東西。對於Web開發人員而言，可以快速開始並運行其代碼很是重要。

這就是爲何瀏覽器最初使用JavaScript解釋器的緣由。

可是，當您屢次運行相同的代碼時，就會使用解釋器。例如，若是您處於循環中。而後，您必須一遍又一遍地進行相同的翻譯。 

編譯器的優缺點

編譯器具備相反的權衡。

啓動須要花費更多時間，由於它必須在開始時執行該編譯步驟。可是隨後循環中的代碼運行得更快，由於它不須要爲每次經過該循環重複翻譯。

另外一個區別是，編譯器有更多時間查看代碼並對其進行編輯，以使其運行更快。這些編輯稱爲優化。

解釋器在運行時進行工做，所以在翻譯階段能夠花不少時間來找出這些優化。

即時編譯器：一箭雙鵰

做爲擺脫解釋器效率低下的一種方式（瀏覽器每次循環時都必須不斷從新翻譯代碼），瀏覽器開始將編譯器混入其中。

不一樣的瀏覽器以略有不一樣的方式執行此操做，可是基本思想是相同的。他們向JavaScript引擎添加了一個新部件，稱爲監視器（又稱爲探查器）。該監視器在代碼運行時對其進行監視，並記錄其運行了多少次以及使用了哪一種類型。

首先，監視器只是經過解釋器運行全部內容。

若是同一行代碼運行了幾回，則該段代碼稱爲熱代碼。若是運行不少，則稱爲高溫。

基準編譯器

當功能開始變熱時，JIT會將其發送出去進行編譯。而後它將存儲該編譯。

函數的每一行都被編譯爲一個「存根」。存根由行號和變量類型索引（稍後將解釋爲何這很重要）。若是監視器發現執行再次使用相同的變量類型命中相同的代碼，則它將僅提取其編譯版本。

這有助於加快速度。可是就像我說的，還有更多的編譯器能夠作。找出解決方案的最有效方法可能須要一些時間。

基準編譯器將進行其中的一些優化（我在下面給出一個示例）。可是，它不想花費太多時間，由於它不想使執行時間太長。

可是，若是代碼真的很熱（若是正在運行不少次），那麼值得花費額外的時間進行更多的優化。

優化編譯器

當一部分代碼很是熱時，監視器會將其發送給優化的編譯器。這將建立該功能的另外一個甚至更快的版本，該版本也將被存儲。

爲了使代碼的版本更快，優化的編譯器必須作出一些假設。

例如，若是能夠假設由特定構造函數建立的全部對象都具備相同的形狀（即它們始終具備相同的屬性名稱，而且這些屬性以相同的順序添加），則它能夠基於在那。

優化編譯器經過監視代碼執行狀況來使用監視器收集的信息來作出這些判斷。若是對於先前經過循環的全部遍歷都爲真，則假定它將繼續爲真。

可是，固然，對於JavaScript，永遠不會有任何保證。您可能擁有所有具備相同形狀的99個對象，可是第100個對象可能缺乏屬性。

所以，編譯後的代碼須要在運行以前進行檢查，以查看這些假設是否有效。若是它們是，則編譯的代碼將運行。可是，若是不是這樣，JIT會假設本身作出了錯誤的假設，並浪費了優化後的代碼。

 

而後執行返回到解釋器或基準編譯版本。此過程稱爲反優化（或應急）。

一般，優化編譯器可以使代碼更快，但有時它們可​​能會致使意外的性能問題。若是您的代碼不斷進行優化，而後再進行優化，那麼最終結果將比僅執行基準編譯版本慢。

大多數瀏覽器都增長了限制，以在發生這些優化/反優化週期時突圍而出。若是JIT進行了10次以上的優化嘗試，而又不得不將其扔掉，它將中止嘗試。

優化示例：類型專門化

有不少不一樣類型的優化，可是我想看看一種類型的優化，以便您能夠感受到優化是如何發生的。優化編譯器的最大勝利之一就是所謂的類型專門化。

JavaScript使用的動態類型系統在運行時須要一些額外的工做。例如，考慮如下代碼：

function arraySum(arr) {
  var sum = 0;
  for (var i = 0; i < arr.length; i++) {
    sum += arr[i];
  }
}

+=循環中的步驟彷佛很簡單。看起來您能夠一步計算出來，可是因爲動態鍵入，它須要的步驟比您預期的要多。

假設這arr是一個100個整數的數組。代碼預熱後，基線編譯器將爲函數中的每一個操做建立一個存根。所以，將有一個存根sum += arr[i]，它將+=做爲整數加法處理操做。

可是，sum和arr[i]不能保證爲整數。因爲類型在JavaScript中是動態的，所以在循環的後續迭代中arr[i]可能會有一個字符串。整數加法和字符串串聯是兩個很是不一樣的操做，所以它們將編譯爲很是不一樣的機器代碼。

JIT處理此問題的方法是編譯多個基準存根。若是一段代碼是單態的（即始終以相同的類型調用），它將獲得一個存根。若是它是多態的（從一種代碼傳遞到另外一種代碼使用不一樣的類型調用），那麼它將爲經過該操做的每種類型的組合獲取一個存根。

這意味着JIT在選擇存根以前必須先問不少問題。

 

因爲基線編譯器中每行代碼都有其本身的存根集，所以，每次執行該行代碼時，JIT都須要繼續檢查類型。所以，對於循環中的每次迭代，都必須提出相同的問題。

 

若是JIT不須要重複這些檢查，則代碼的執行速度將大大提升。這就是優化編譯器要作的事情之一。

在優化編譯器中，整個函數將一塊兒編譯。移動類型檢查，使它們在循環以前發生。

 

一些JIT對此進行了進一步優化。例如，在Firefox中，對於僅包含整數的數組有一個特殊的分類。若是arr是這些數組之一，則JIT不須要檢查是否arr[i]爲整數。這意味着JIT能夠在進入循環以前執行全部類型檢查。

結論

簡而言之，這就是JIT。經過監視正在運行的代碼併發送要優化的熱代碼路徑，它可使JavaScript運行更快。這致使大多數JavaScript應用程序的性能獲得了許多方面的改進。

即便進行了這些改進，JavaScript的性能仍然是不可預測的。爲了使事情更快，JIT在運行時增長了一些開銷，包括：

• 優化和反優化
• 內存，用於監視器的簿記和恢復信息，以瞭解什麼時候發生救助
• 用於存儲功能的基準和優化版本的內存

這裏還有改進的餘地：能夠消除開銷，使性能更可預測。這就是WebAssembly要作的事情之一。

在接下來的文章中，我將更多地解釋裝配和編譯器如何使用它。

轉自：https://hacks.mozilla.org/2017/02/a-crash-course-in-just-in-time-jit-compilers/