FW: 圖說 WebAssembly

https://www.zcfy.cc/article/an-abridged-cartoon-introduction-to-webassembly-ndash-smashing-magazine

 

圖說 WebAssembly

原文連接： www.smashingmagazine.com

最近，WebAssembly 在 JavaScript 圈很是的火！人們都在談論它多麼多麼快，怎樣怎樣改變 Web 開發領域。可是沒有人講他到底爲何那麼快。在這篇文章裏，我將會幫你瞭解 WebAssembly 到底爲何那麼快。

第一，咱們須要知道它究竟是什麼！WebAssembly 是一種可使用非 JavaScript 編程語言編寫代碼而且能在瀏覽器上運行的技術方案。

（看大圖）

當你們談論起 WebAssembly 時，首先想到的就是 JavaScript。如今，我沒有必須在 WebAssembly 和 JavaScript 中選一個的意思。實際上，咱們期待開發者在一個項目中把 WebAssembly 和 JavaScript 結合使用。可是，比較這二者是有用的，這對你瞭解 WebAssembly 有必定幫助。

拓展閱讀閱讀：

一點點性能歷史

1995 年 JavaScript 誕生。它的設計時間很是短，前十年發展迅速。

緊接着瀏覽器廠商們就開始了更多的競爭。

2008年，人們稱之爲瀏覽器性能大戰的時期開始了。不少瀏覽器加入了即時編譯器，又稱之爲JITs。在這種模式下，JavaScript在運行的時候，JIT 選擇模式而後基於這些模式使代碼運行更快。

這些 JITs 的引入是瀏覽器運行代碼機制的一個轉折點。全部的忽然之間，JavaScript 的運行速度快了10倍。

（看大圖）

隨着這種改進的性能，JavaScript 開始被用於意想不到的事情，好比使用Node.js和Electron構建應用程序。

如今 WebAssembly 多是的另外一個轉折點。

（看大圖）

在咱們沒有搞清楚 JavaScript 和 WebAssembly 之間的性能差前，咱們須要理解 JS 引擎所作的工做。

JavaScript 是如何在瀏覽器中運行的呢？

做爲一個開發人員，您將JavaScript添加到頁面時，您有一個目標並遇到一個問題。

• 目標：你想要告訴計算機作什麼
• 問題：你和計算機使用不通的語言。

您說的是人類的語言，計算機說的是機器語言。儘管你不認爲 JavaScript 或者其餘高級語言是人類語言，但事實就是這樣的。它們的設計是爲了讓人們認知，不是爲機器設計的。

因此JavaScript引擎的工做就是把你的人類語言轉化成機器所理解的語言。

我想到電影《Arrival》，這就像人類和外星人進行交談。

（看大圖）

在這部電影中，人類語言不能從逐字翻譯成外星語言。他們的語言反映出兩種對世界不一樣的認知。人類和機器也是這樣。

因此，怎麼進行翻譯呢？

在編程中，一般有兩種翻譯方法將代碼翻譯成機器語言。你可使用解釋器或者編譯器。

使用解釋器，翻譯的過程基本上是一行一行及時生效的。

（看大圖）

編譯器是另一種工做方式，它在執行前翻譯。

（看大圖）

每種翻譯方法都有利弊。

解釋器的利弊

解釋器很快的獲取代碼而且執行。您不須要在您能夠執行代碼的時候知道所有的編譯步驟。所以，解釋器感受與 JavaScript 有着天然的契合。web 開發者可以當即獲得反饋很重要。

這也是瀏覽器最開始使用 JavaScript 解釋器的緣由之一。

可是使用解釋器的弊端是當您運行相同的代碼的時候。好比，您執行了一個循環。而後您就會一遍又一遍的作一樣的事情。

編譯器的利弊

編譯器則有相反的效果。在程序開始的時候，它可能須要稍微多一點的時間來了解整個編譯的步驟。可是當運行一個循環的時候他會更快，由於他不須要重複的去翻譯每一次循環裏的代碼。

由於解釋器必須在每次循環訪問時不斷從新轉換代碼，做爲一個能夠擺脫解釋器低效率的方法，瀏覽器開始將編譯器引入。

不一樣的瀏覽器實現起來稍有不一樣，可是基本目的是相同的。他們給 JavaScript 引擎添加了一個新的部分，稱爲監視器（也稱爲分析器）。該監視器在 JavaScript 運行時監控代碼，並記錄代碼片斷運行的次數以及使用了那些數據類型。

若是相同的代碼行運行了幾回，這段代碼被標記爲 「warm」。若是運行次數比較多，就被標記爲 「hot」。
被標記爲 「warm」 的代碼被扔給基礎編譯器，只能提高一點點的速度。被標記爲 「hot」 的代碼被扔給優化編譯器，速度提高的更多。

（看大圖）

瞭解更多，能夠讀 https://hacks.mozilla.org/2017/02/a-crash-course-in-just-in-time-jit-compilers/

耗時比較：JavaScript Vs. WebAssembly

這張圖大體給出瞭如今一個程序的啓動性能，目前 JIT 編譯器在瀏覽器中很常見。

該圖顯示了 JS 引擎運行程序花費的時間。顯示的時間並非平均的。這個圖片代表，JS 引擎作的這些任務花費的時間取決於頁面中 JavaScript 作了什麼事情。可是咱們能夠用這個圖來構建一個心理模型。

（看大圖）

每欄顯示花費在特定任務上的時間。

• Parsing - 講源碼轉換成解釋器能夠運行的東西所用的事情。

• Compiling + optimizing - 花費在基礎編譯和優化編譯上的時間。有一些優化編譯的工做不在主線程，因此這裏並不包括這些時間。

• Re-optimizing - 當預先編譯優化的代碼不能被優化的狀況下，JIT 將這些代碼從新優化，若是不能從新優化那麼久丟給基礎編譯去作。這個過程叫作從新優化。
• Execution - 執行代碼的過程
• Garbage collection - 清理內存的時間

一個重要的事情要注意：這些任務不會發生在離散塊或特定的序列中。相反，它們將被交叉執行。好比正在作一些代碼解析時，還執行者一些其餘的邏輯，有些代碼編譯完成後，引擎又作了一些解析，而後又執行了一些邏輯，等等。

這種交叉執行對早期 JavaScript 的性能有很大的幫助，早期的 JavaScript 的執行就像下圖同樣：

（看大圖）

一開始，當只有一個解釋器運行 JavaScript 時，執行速度至關緩慢。JITs 的引入，大大提高了執行效率。

監視和編譯代碼的開銷是須要權衡的事情。若是 JavaScript 開發人員按照相同的方式編寫JavaScript，解析和編譯時間將會很小。可是，性能的提高使開發人員可以建立更大的JavaScript應用程序。

這意味着還有改進的餘地。

下面是 WebAssembly 如何比較典型 web 應用。

（看大圖）

瀏覽器的 JS 引擎有輕微的不一樣。我是基於 SpiderMonkey 來說。

請求

這沒有展現在圖上，可是從服務器獲取文件是會消耗時間的

下載執行與 JavaScript 等效的 WebAssembly 文件須要更少的時間，由於它的體積更小。WebAssembly 設計的體積更小，能夠以二進制形式表示。

即便使用 gzip 壓縮的 JavaScript文件很小，但 WebAssembly 中的等效代碼可能更小。

因此說，下載資源的時間會更少。在網速慢的狀況下更能顯示出效果來。

解析

JavaScript 源碼一旦被下載到瀏覽器，源將被解析爲抽象語法樹（AST）。

一般瀏覽器解析源碼是懶惰的，瀏覽器首先會解析他們真正須要的東西，沒有及時被調用的函數只會被建立成存根。

在這個過程當中，AST被轉換爲該 JS 引擎的中間表示（稱爲字節碼）。

相反，WebAssembly 不須要被轉換，由於它已是字節碼了。它僅僅須要被解碼並肯定沒有任何錯誤。

（看大圖）

編譯 + 優化

如前所述，JavaScript 是在執行代碼期間編譯的。由於 JavaScript 是動態類型語言，相同的代碼在屢次執行中都有可能都由於代碼裏含有不一樣的類型數據被從新編譯。這樣會消耗時間。

相反，WebAssembly 與機器代碼更接近。例如，類型是程序的一部分。這是速度更快的一個緣由：

• 編譯器不須要在運行代碼時花費時間去觀察代碼中的數據類型，在開始編譯時作優化。

• 編譯器不須要去每次執行相同代碼中數據類型是否同樣。

• 更多的優化在 LLVM 最前面就已經完成了。因此編譯和優化的工做不多。

（看大圖）

從新優化

有時 JIT 拋出一個優化版本的代碼，而後從新優化。

JIT 基於運行代碼的假設不正確時，會發生這種狀況。例如，當進入循環的變量與先前的迭代不一樣時，或者在原型鏈中插入新函數時，會發生從新優化。

在 WebAssembly 中，類型是明確的，所以 JIT 不須要根據運行時收集的數據對類型進行假設。這意味着它沒必要通過從新優化的週期。

（看大圖）

執行

儘量編寫執行性能好的 JavaScript。因此，你可能須要知道 JIT 是如何作優化的。

然而，大多數開發者並不知道 JIT 的內部原理。即便是那些瞭解 JIT 內部原理的開發人員，也很難實現最佳的方案。有不少時候，人們爲了使他們的代碼更易於閱讀（例如：將常見任務抽象爲跨類型工做的函數）會阻礙編譯器優化代碼。

正因如此，執行 WebAssembly 代碼一般更快。有些必須對 JavaScript 作的優化不須要用在 WebAssembly 上

另外，WebAssembly 是爲編譯器設計的。意思是，它是專門給編譯器來閱讀，並非當作編程語言讓程序員去寫的。

因爲程序員不須要直接編程，WebAssembly 提供了一組更適合機器的指令。根據您的代碼所作的工做，這些指令的運行速度能夠在10％到800％之間。

（看大圖）

垃圾回收

在 JavaScript 中，開發者不須要擔憂內存中無用變量的回收。JS 引擎使用一個叫垃圾回收器的東西來自動進行垃圾回收處理。

這對於控制性能可能並非一件好事。你並不能控制垃圾回收時機，因此它可能在很是重要的時間去工做，從而影響性能。

如今，WebAssembly 根本不支持垃圾回收。內存是手動管理的（就像 C/C++）。雖然這些可能讓開發者編程更困難，但它的確提高了性能。

（看大圖）

總而言之，這些都是在許多狀況下，在執行相同任務時WebAssembly 將賽過 JavaScript 的緣由。

在某些狀況下，WebAssembly 不能像預期的那樣執行，還有一些更改使其更快。我在另外一篇文章中更深刻地介紹了這些將來的功能。

WebAssembly 是如何工做的？

如今，您瞭解開發人員爲何對 WebAssembly 感到興奮，讓咱們來看看它是如何工做的。

當我談到上面的 JIT 時，我談到了與機器的溝通像與外星人溝通。

（看大圖）

我如今想看看這個外星人的大腦如何工做 - 機器的大腦如何解析和理解交流內容。

這個大腦的一部分是專一于思考，例如算術和邏輯。有一部分腦部提供短時間記憶，另外一部分提供長期記憶。

這些不一樣的部分都有名字。

• 負責思考的部分是算術邏輯單元（ALU）。
• 短時間儲存由寄存器（Registers）提供。
• 隨機存儲器（或RAM）來提供長期儲存能力。

（看大圖）

機器碼中的語句被稱爲指令。

當一條指令進入大腦時會發生什麼？它被拆分紅了多個的部分並有特殊的含義。

被拆分紅的多個部分分別進入不一樣的大腦單元進行處理，這也是拆分指令所依賴的方式。

例如，這個大腦從機器碼中取出4-10位，並將它們發送到 ALU。ALU進行計算，它根據 0 和 1 的位置來肯定是否須要將兩個數相加。

這個塊被稱爲「操做碼」，由於它告訴 ALU 執行什麼操做。

（看大圖）

那麼這個大腦會拿後面的兩個塊來肯定他們所要操做的數。這兩個塊對應的是寄存器的地址。

（看大圖）

請注意添加在機器碼上面的標註（ADD R1 R2），這使咱們更容易瞭解發生了什麼。這就是彙編。它被稱爲符號機器碼。這樣人類也能看懂機器碼的含義。

您能夠看到，這個機器的彙編和機器碼之間有很是直接的關係。每種機器內部有不一樣的結構，因此每種機器都有本身獨有的彙編語言。

因此咱們並不僅有一個翻譯的目標。
相反，咱們的目標是不一樣類型的機器碼。就像人類說不一樣的語言同樣，機器也有不一樣的語言。

您但願可以將這些任何一種高級編程語言轉換爲任何一種彙編語言。這樣作的一個方法是建立一大堆不一樣的翻譯器，能夠從任意一種語言轉換成任意一種彙編語言。

（看大圖）

這樣作的效率很是低。爲了解決這個問題，大多數編譯器會在高級語言和彙編語言之間多加一層。編譯器將把高級語言翻譯成一種更低級的語言，但比機器碼的等級高。這就是中間代碼（IR）。

（看大圖）

意思就是編譯器能夠將任何一種高級語言轉換成一種中間語言。而後，編譯器的另外的部分將中間語言編譯成目標機器的彙編代碼。

編譯器的「前端」將高級編程語言轉換爲IR。編譯器的「後端」將 IR 轉換成目標機器的彙編代碼。

（看大圖）

WebAssembly 適合在哪裏使用？

您可能會將 WebAssembly 當作是另一種目標彙編語言。這是真的，這些機器語言（x86，ARM等）中的每一種都對應於特定的機器架構。

當你的代碼運行在用戶的機器的 web 平臺上的時候，你不知道你的代碼將會運行在那種機器結構上。

因此 WebAssembly 和別的彙編語言是有一些不一樣的。因此他是一個概念機上的機器語言，不是在一個真正存在的物理機上運行的機器語言。

正因如此，WebAssembly 指令有時候被稱爲虛擬指令。它比 JavaScript 代碼更快更直接的轉換成機器代碼，但它們不直接和特定硬件的特定機器代碼對應。

在瀏覽器下載 WebAssembly後，使 WebAssembly 的迅速轉換成目標機器的彙編代碼。

（看大圖）

若是想在您的頁面裏上添加 WebAssembly，您須要將您的代碼編譯成 .wasm 文件。

編譯到 .wasm 文件

當前對 WebAssembly 支持最多的編譯器工具鏈稱是 LLVM。有許多不一樣的「前端」和「後端」能夠插入到 LLVM 中。

注意：大多數 WebAssembly 模塊開發者使用 C 和 Rust 編寫代碼，而後編譯成 WebAssembly，可是這裏有其餘建立 WebAssembly 模塊的途徑。好比，這裏有一個實驗性工具，他能夠幫你使用 TypeScript 建立一個 WebAssembly 模塊，你能夠在這裏直接編輯WebAssembly。

假設咱們想經過 C 來建立 WebAssembly。咱們可使用 clang 「前端」 從 C 編譯成 LLVM 中間代碼。當它變成 LLVM 的中間代碼（IR）之後，LLVM 能夠理解他，因此 LLVM 能夠對代碼作一些優化。

若是想讓 LLVM 的 IR 變成 WebAssembly，咱們須要一個 「後端」。目前 LLVM 項目中有一個正在開發中的。這個「後端」對作這件事情很重要，應該很快就會完成。惋惜，它如今還不能用。

另外有一個工具叫作 Emscripten，它用起來比較簡單。它還能夠有比較有用的能夠選擇，好比說由 IndexDB 支持的文件系統。

（看大圖）

無論你使用的什麼工具鏈，最終的結果都應該是以 .wasm 結尾的文件。來讓咱們看一下如何將它用在你的 web 頁面。

在 JavaScript 中加載一個 .wasm 組件

.wasm 文件是 WebAssembly 組件，它能夠被 JavaScript 加載。到目前爲止，加載過程有點複雜。

function fetchAndInstantiate(url, importObject) {
  return fetch(url).then(response =>
    response.arrayBuffer()
  ).then(bytes =>
    WebAssembly.instantiate(bytes, importObject)
  ).then(results =>
    results.instance
  );
}

您能夠在文檔中更深刻地瞭解這些。

咱們正在努力使這個過程更容易。咱們指望對工具鏈進行改進，並與現有的模塊管理工具（如Webpack）或加載器（如SystemJS）相結合。我相信，加載 WebAssembly 模塊愈來愈簡單，就像加載 JavaScript 同樣。

可是，WebAssembly模塊和JS模塊之間存在重大差別。目前，WebAssembly 中的函數只能使用 WebAssembly 類型（整數或浮點數）做爲參數或返回值。

（看大圖）

對於任何更復雜的數據類型（如字符串），必須使用 WebAssembly 模塊的內存。

若是你以前主要使用 JavaScript，可能對於直接訪問內存是不熟悉的。C，C ++和Rust等性能更高的語言每每具備手動內存管理功能。WebAssembly 模塊的內存模擬這些語言中的堆。

爲此，它使用 JavaScript 中稱爲 ArrayBuffer。ArrayBuffer 是一個字節數組。所以，數組的索引做爲內存地址。

若是要在 JavaScript 和 WebAssembly 之間傳遞一個字符串，須要將字符轉換爲等效的字符碼。而後你須要將它寫入內存數組。因爲索引是整數，因此能夠將索引傳遞給 WebAssembly 函數。所以，字符串的第一個字符的索引能夠看成指針。

（看大圖）

任何人開發的 WebAssembly 模塊極可能被 Web 開發人員使用併爲該模塊建立一個的裝飾器。這樣，您當作用戶來使用這個模塊就不須要考慮內存管理的事情了。

我已經在另外一篇文章中解釋了更多關於使用WebAssembly模塊的內容。

WebAssembly 如今是什麼狀態？

二月二十八日，四大瀏覽器宣佈達成共識，即 WebAssembly 的 MVP （最小化可行產品）已經完成。大約一週後，Firefox會默認打開 WebAssembly 支持，而Chrome則在第二週開始。它也可用於預覽版本的Edge和Safari。

這提供了一個穩定的初始版本，瀏覽器開始支持。

（看大圖）

該核心不包含社區組織計劃的全部功能。即便在初始版本中，WebAssembly 也會很快。可是，經過修復和新功能的組合，未來應該可以更快。我在另外一篇文章中詳細介紹了這些功能。

總結

使用WebAssembly，能夠更快地在 web 應用上運行代碼。這裏有 幾個 WebAssembly 代碼運行速度比 JavaScript 高效的緣由。

• 文件加載 - WebAssembly 文件體積更小，因此下載速度更快。
• 解析 - 解碼 WebAssembly 比解析 JavaScript 要快
• 編譯和優化 - 編譯和優化所需的時間較少，由於在將文件推送到服務器以前已經進行了更多優化，JavaScript 須要爲動態類型屢次編譯代碼
• 從新優化 - WebAssembly 代碼不須要從新優化，由於編譯器有足夠的信息能夠在第一次運行時得到正確的代碼
• 執行 - 執行能夠更快，WebAssembly 指令更接近機器碼
• 垃圾回收 - 目前 WebAssembly 不直接支持垃圾回收，垃圾回收都是手動控制的，因此比自動垃圾回收效率更高。

目前瀏覽器中的 MVP（最小化可行產品） 已經很快了。在接下來的幾年裏，隨着瀏覽器的發展和新功能的增長，它將在將來幾年內變得更快。沒有人能夠確定地說，這些性能改進能夠實現什麼樣的應用。可是，若是過去有任何跡象，咱們能夠期待驚奇。

(rb, ms, cm, il)

This article has been republished from Medium.

JavaScript 瀏覽器 程序員 C 設計

 

---

版權聲明

本譯文僅用於學習、研究和交流目的，歡迎非商業轉載。轉載請註明出處、譯者和衆成翻譯的完整連接。

衆成翻譯@2015-2018 （京ICP備17024260-1號）