FW: 图说 WebAssembly
圖說 WebAssembly
原文鏈接： www.smashingmagazine.com最近，WebAssembly 在 JavaScript 圈非常的火！人們都在談論它多么多么快，怎樣怎樣改變 Web 開發(fā)領域。但是沒有人講他到底為什么那么快。在這篇文章里，我將會幫你了解 WebAssembly 到底為什么那么快。
第一，我們需要知道它到底是什么！WebAssembly 是一種可以使用非 JavaScript 編程語言編寫代碼并且能在瀏覽器上運行的技術方案。
（看大圖）
當大家談論起 WebAssembly 時，首先想到的就是 JavaScript。現(xiàn)在，我沒有必須在 WebAssembly 和 JavaScript 中選一個的意思。實際上，我們期待開發(fā)者在一個項目中把 WebAssembly 和 JavaScript 結合使用。但是，比較這兩者是有用的，這對你了解 WebAssembly 有一定幫助。
拓展閱讀閱讀：
一點點性能歷史
1995 年 JavaScript 誕生。它的設計時間非常短，前十年發(fā)展迅速。
緊接著瀏覽器廠商們就開始了更多的競爭。
2008年，人們稱之為瀏覽器性能大戰(zhàn)的時期開始了。很多瀏覽器加入了即時編譯器，又稱之為JITs。在這種模式下，JavaScript在運行的時候，JIT 選擇模式然后基于這些模式使代碼運行更快。
這些 JITs 的引入是瀏覽器運行代碼機制的一個轉折點。所有的突然之間，JavaScript 的運行速度快了10倍。
（看大圖）
隨著這種改進的性能，JavaScript 開始被用于意想不到的事情，比如使用Node.js和Electron構建應用程序。
現(xiàn)在 WebAssembly 可能是的另一個轉折點。
（看大圖）
在我們沒有搞清楚 JavaScript 和 WebAssembly 之間的性能差前，我們需要理解 JS 引擎所做的工作。
JavaScript 是如何在瀏覽器中運行的呢？
作為一個開發(fā)人員，您將JavaScript添加到頁面時，您有一個目標并遇到一個問題。
- 目標：你想要告訴計算機做什么
- 問題：你和計算機使用不通的語言。
您說的是人類的語言，計算機說的是機器語言。盡管你不認為 JavaScript 或者其他高級語言是人類語言，但事實就是這樣的。它們的設計是為了讓人們認知，不是為機器設計的。
所以JavaScript引擎的工作就是把你的人類語言轉化成機器所理解的語言。
我想到電影《Arrival》，這就像人類和外星人進行交談。
（看大圖）
在這部電影中，人類語言不能從逐字翻譯成外星語言。他們的語言反映出兩種對世界不同的認知。人類和機器也是這樣。
所以，怎么進行翻譯呢？
在編程中，通常有兩種翻譯方法將代碼翻譯成機器語言。你可以使用解釋器或者編譯器。
使用解釋器，翻譯的過程基本上是一行一行及時生效的。
（看大圖）
編譯器是另外一種工作方式，它在執(zhí)行前翻譯。
（看大圖）
每種翻譯方法都有利弊。
解釋器的利弊
解釋器很快的獲取代碼并且執(zhí)行。您不需要在您可以執(zhí)行代碼的時候知道全部的編譯步驟。因此，解釋器感覺與 JavaScript 有著自然的契合。web 開發(fā)者能夠立即得到反饋很重要。
這也是瀏覽器最開始使用 JavaScript 解釋器的原因之一。
但是使用解釋器的弊端是當您運行相同的代碼的時候。比如，您執(zhí)行了一個循環(huán)。然后您就會一遍又一遍的做同樣的事情。
編譯器的利弊
編譯器則有相反的效果。在程序開始的時候，它可能需要稍微多一點的時間來了解整個編譯的步驟。但是當運行一個循環(huán)的時候他會更快，因為他不需要重復的去翻譯每一次循環(huán)里的代碼。
因為解釋器必須在每次循環(huán)訪問時不斷重新轉換代碼，作為一個可以擺脫解釋器低效率的方法，瀏覽器開始將編譯器引入。
不同的瀏覽器實現(xiàn)起來稍有不同，但是基本目的是相同的。他們給 JavaScript 引擎添加了一個新的部分，稱為監(jiān)視器（也稱為分析器）。該監(jiān)視器在 JavaScript 運行時監(jiān)控代碼，并記錄代碼片段運行的次數(shù)以及使用了那些數(shù)據(jù)類型。
如果相同的代碼行運行了幾次，這段代碼被標記為 “warm”。如果運行次數(shù)比較多，就被標記為 “hot”。
被標記為 “warm” 的代碼被扔給基礎編譯器，只能提升一點點的速度。被標記為 “hot” 的代碼被扔給優(yōu)化編譯器，速度提升的更多。
（看大圖）
了解更多，可以讀 https://hacks.mozilla.org/2017/02/a-crash-course-in-just-in-time-jit-compilers/
耗時比較：JavaScript Vs. WebAssembly
這張圖大致給出了現(xiàn)在一個程序的啟動性能，目前 JIT 編譯器在瀏覽器中很常見。
該圖顯示了 JS 引擎運行程序花費的時間。顯示的時間并不是平均的。這個圖片表明，JS 引擎做的這些任務花費的時間取決于頁面中 JavaScript 做了什么事情。但是我們可以用這個圖來構建一個心理模型。
（看大圖）
每欄顯示花費在特定任務上的時間。
-
Parsing - 講源碼轉換成解釋器可以運行的東西所用的事情。
-
Compiling + optimizing - 花費在基礎編譯和優(yōu)化編譯上的時間。有一些優(yōu)化編譯的工作不在主線程，所以這里并不包括這些時間。
- Re-optimizing - 當預先編譯優(yōu)化的代碼不能被優(yōu)化的情況下，JIT 將這些代碼重新優(yōu)化，如果不能重新優(yōu)化那么久丟給基礎編譯去做。這個過程叫做重新優(yōu)化。
- Execution - 執(zhí)行代碼的過程
- Garbage collection - 清理內存的時間
一個重要的事情要注意：這些任務不會發(fā)生在離散塊或特定的序列中。相反，它們將被交叉執(zhí)行。比如正在做一些代碼解析時，還執(zhí)行者一些其他的邏輯，有些代碼編譯完成后，引擎又做了一些解析，然后又執(zhí)行了一些邏輯，等等。
這種交叉執(zhí)行對早期 JavaScript 的性能有很大的幫助，早期的 JavaScript 的執(zhí)行就像下圖一樣：
（看大圖）
一開始，當只有一個解釋器運行 JavaScript 時，執(zhí)行速度相當緩慢。JITs 的引入，大大提升了執(zhí)行效率。
監(jiān)視和編譯代碼的開銷是需要權衡的事情。如果 JavaScript 開發(fā)人員按照相同的方式編寫JavaScript，解析和編譯時間將會很小。但是，性能的提升使開發(fā)人員能夠創(chuàng)建更大的JavaScript應用程序。
這意味著還有改進的余地。
下面是 WebAssembly 如何比較典型 web 應用。
（看大圖）
瀏覽器的 JS 引擎有輕微的不同。我是基于 SpiderMonkey 來講。
請求
這沒有展示在圖上，但是從服務器獲取文件是會消耗時間的
下載執(zhí)行與 JavaScript 等效的 WebAssembly 文件需要更少的時間，因為它的體積更小。WebAssembly 設計的體積更小，可以以二進制形式表示。
即使使用 gzip 壓縮的 JavaScript文件很小，但 WebAssembly 中的等效代碼可能更小。
所以說，下載資源的時間會更少。在網速慢的情況下更能顯示出效果來。
解析
JavaScript 源碼一旦被下載到瀏覽器，源將被解析為抽象語法樹（AST）。
通常瀏覽器解析源碼是懶惰的，瀏覽器首先會解析他們真正需要的東西，沒有及時被調用的函數(shù)只會被創(chuàng)建成存根。
在這個過程中，AST被轉換為該 JS 引擎的中間表示（稱為字節(jié)碼）。
相反，WebAssembly 不需要被轉換，因為它已經是字節(jié)碼了。它僅僅需要被解碼并確定沒有任何錯誤。
（看大圖）
編譯 + 優(yōu)化
如前所述，JavaScript 是在執(zhí)行代碼期間編譯的。因為 JavaScript 是動態(tài)類型語言，相同的代碼在多次執(zhí)行中都有可能都因為代碼里含有不同的類型數(shù)據(jù)被重新編譯。這樣會消耗時間。
相反，WebAssembly 與機器代碼更接近。例如，類型是程序的一部分。這是速度更快的一個原因：
- 編譯器不需要在運行代碼時花費時間去觀察代碼中的數(shù)據(jù)類型，在開始編譯時做優(yōu)化。
-
編譯器不需要去每次執(zhí)行相同代碼中數(shù)據(jù)類型是否一樣。
-
更多的優(yōu)化在 LLVM 最前面就已經完成了。所以編譯和優(yōu)化的工作很少。
（看大圖）
重新優(yōu)化
有時 JIT 拋出一個優(yōu)化版本的代碼，然后重新優(yōu)化。
JIT 基于運行代碼的假設不正確時，會發(fā)生這種情況。例如，當進入循環(huán)的變量與先前的迭代不同時，或者在原型鏈中插入新函數(shù)時，會發(fā)生重新優(yōu)化。
在 WebAssembly 中，類型是明確的，因此 JIT 不需要根據(jù)運行時收集的數(shù)據(jù)對類型進行假設。這意味著它不必經過重新優(yōu)化的周期。
（看大圖）
執(zhí)行
盡可能編寫執(zhí)行性能好的 JavaScript。所以，你可能需要知道 JIT 是如何做優(yōu)化的。
然而，大多數(shù)開發(fā)者并不知道 JIT 的內部原理。即使是那些了解 JIT 內部原理的開發(fā)人員，也很難實現(xiàn)最佳的方案。有很多時候，人們?yōu)榱耸顾麄兊拇a更易于閱讀（例如：將常見任務抽象為跨類型工作的函數(shù)）會阻礙編譯器優(yōu)化代碼。
正因如此，執(zhí)行 WebAssembly 代碼通常更快。有些必須對 JavaScript 做的優(yōu)化不需要用在 WebAssembly 上
另外，WebAssembly 是為編譯器設計的。意思是，它是專門給編譯器來閱讀，并不是當做編程語言讓程序員去寫的。
由于程序員不需要直接編程，WebAssembly 提供了一組更適合機器的指令。根據(jù)您的代碼所做的工作，這些指令的運行速度可以在10％到800％之間。
（看大圖）
垃圾回收
在 JavaScript 中，開發(fā)者不需要擔心內存中無用變量的回收。JS 引擎使用一個叫垃圾回收器的東西來自動進行垃圾回收處理。
這對于控制性能可能并不是一件好事。你并不能控制垃圾回收時機，所以它可能在非常重要的時間去工作，從而影響性能。
現(xiàn)在，WebAssembly 根本不支持垃圾回收。內存是手動管理的（就像 C/C++）。雖然這些可能讓開發(fā)者編程更困難，但它的確提升了性能。
（看大圖）
總而言之，這些都是在許多情況下，在執(zhí)行相同任務時WebAssembly 將勝過 JavaScript 的原因。
在某些情況下，WebAssembly 不能像預期的那樣執(zhí)行，還有一些更改使其更快。我在另一篇文章中更深入地介紹了這些未來的功能。
WebAssembly 是如何工作的？
現(xiàn)在，您了解開發(fā)人員為什么對 WebAssembly 感到興奮，讓我們來看看它是如何工作的。
當我談到上面的 JIT 時，我談到了與機器的溝通像與外星人溝通。
（看大圖）
我現(xiàn)在想看看這個外星人的大腦如何工作 - 機器的大腦如何解析和理解交流內容。
這個大腦的一部分是專注于思考，例如算術和邏輯。有一部分腦部提供短期記憶，另一部分提供長期記憶。
這些不同的部分都有名字。
- 負責思考的部分是算術邏輯單元（ALU）。
- 短期儲存由寄存器（Registers）提供。
- 隨機存儲器（或RAM）來提供長期儲存能力。
（看大圖）
機器碼中的語句被稱為指令。
當一條指令進入大腦時會發(fā)生什么？它被拆分成了多個的部分并有特殊的含義。
被拆分成的多個部分分別進入不同的大腦單元進行處理，這也是拆分指令所依賴的方式。
例如，這個大腦從機器碼中取出4-10位，并將它們發(fā)送到 ALU。ALU進行計算，它根據(jù) 0 和 1 的位置來確定是否需要將兩個數(shù)相加。
這個塊被稱為“操作碼”，因為它告訴 ALU 執(zhí)行什么操作。
（看大圖）
那么這個大腦會拿后面的兩個塊來確定他們所要操作的數(shù)。這兩個塊對應的是寄存器的地址。
（看大圖）
請注意添加在機器碼上面的標注（ADD R1 R2），這使我們更容易了解發(fā)生了什么。這就是匯編。它被稱為符號機器碼。這樣人類也能看懂機器碼的含義。
您可以看到，這個機器的匯編和機器碼之間有非常直接的關系。每種機器內部有不同的結構，所以每種機器都有自己獨有的匯編語言。
所以我們并不只有一個翻譯的目標。
相反，我們的目標是不同類型的機器碼。就像人類說不同的語言一樣，機器也有不同的語言。
您希望能夠將這些任何一種高級編程語言轉換為任何一種匯編語言。這樣做的一個方法是創(chuàng)建一大堆不同的翻譯器，可以從任意一種語言轉換成任意一種匯編語言。
（看大圖）
這樣做的效率非常低。為了解決這個問題，大多數(shù)編譯器會在高級語言和匯編語言之間多加一層。編譯器將把高級語言翻譯成一種更低級的語言，但比機器碼的等級高。這就是中間代碼（IR）。
（看大圖）
意思就是編譯器可以將任何一種高級語言轉換成一種中間語言。然后，編譯器的另外的部分將中間語言編譯成目標機器的匯編代碼。
編譯器的“前端”將高級編程語言轉換為IR。編譯器的“后端”將 IR 轉換成目標機器的匯編代碼。
（看大圖）
WebAssembly 適合在哪里使用？
您可能會將 WebAssembly 當做是另外一種目標匯編語言。這是真的，這些機器語言（x86，ARM等）中的每一種都對應于特定的機器架構。
當你的代碼運行在用戶的機器的 web 平臺上的時候，你不知道你的代碼將會運行在那種機器結構上。
所以 WebAssembly 和別的匯編語言是有一些不同的。所以他是一個概念機上的機器語言，不是在一個真正存在的物理機上運行的機器語言。
正因如此，WebAssembly 指令有時候被稱為虛擬指令。它比 JavaScript 代碼更快更直接的轉換成機器代碼，但它們不直接和特定硬件的特定機器代碼對應。
在瀏覽器下載 WebAssembly后，使 WebAssembly 的迅速轉換成目標機器的匯編代碼。
（看大圖）
如果想在您的頁面里上添加 WebAssembly，您需要將您的代碼編譯成 .wasm 文件。
編譯到 .wasm 文件
當前對 WebAssembly 支持最多的編譯器工具鏈稱是 LLVM。有許多不同的“前端”和“后端”可以插入到 LLVM 中。
注意：大多數(shù) WebAssembly 模塊開發(fā)者使用 C 和 Rust 編寫代碼，然后編譯成 WebAssembly，但是這里有其他創(chuàng)建 WebAssembly 模塊的途徑。比如，這里有一個實驗性工具，他可以幫你使用 TypeScript 創(chuàng)建一個 WebAssembly 模塊，你可以在這里直接編輯WebAssembly。
假設我們想通過 C 來創(chuàng)建 WebAssembly。我們可以使用 clang “前端” 從 C 編譯成 LLVM 中間代碼。當它變成 LLVM 的中間代碼（IR）以后，LLVM 可以理解他，所以 LLVM 可以對代碼做一些優(yōu)化。
如果想讓 LLVM 的 IR 變成 WebAssembly，我們需要一個 “后端”。目前 LLVM 項目中有一個正在開發(fā)中的。這個“后端”對做這件事情很重要，應該很快就會完成。可惜，它現(xiàn)在還不能用。
另外有一個工具叫做 Emscripten，它用起來比較簡單。它還可以有比較有用的可以選擇，比如說由 IndexDB 支持的文件系統(tǒng)。
（看大圖）
不管你使用的什么工具鏈，最終的結果都應該是以 .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); }您可以在文檔中更深入地了解這些。
我們正在努力使這個過程更容易。我們期望對工具鏈進行改進，并與現(xiàn)有的模塊管理工具（如Webpack）或加載器（如SystemJS）相結合。我相信，加載 WebAssembly 模塊越來越簡單，就像加載 JavaScript 一樣。
但是，WebAssembly模塊和JS模塊之間存在重大差異。目前，WebAssembly 中的函數(shù)只能使用 WebAssembly 類型（整數(shù)或浮點數(shù)）作為參數(shù)或返回值。
（看大圖）
對于任何更復雜的數(shù)據(jù)類型（如字符串），必須使用 WebAssembly 模塊的內存。
如果你之前主要使用 JavaScript，可能對于直接訪問內存是不熟悉的。C，C ++和Rust等性能更高的語言往往具有手動內存管理功能。WebAssembly 模塊的內存模擬這些語言中的堆。
為此，它使用 JavaScript 中稱為 ArrayBuffer。ArrayBuffer 是一個字節(jié)數(shù)組。因此，數(shù)組的索引作為內存地址。
如果要在 JavaScript 和 WebAssembly 之間傳遞一個字符串，需要將字符轉換為等效的字符碼。然后你需要將它寫入內存數(shù)組。由于索引是整數(shù)，所以可以將索引傳遞給 WebAssembly 函數(shù)。因此，字符串的第一個字符的索引可以當作指針。
（看大圖）
任何人開發(fā)的 WebAssembly 模塊很可能被 Web 開發(fā)人員使用并為該模塊創(chuàng)建一個的裝飾器。這樣，您當做用戶來使用這個模塊就不需要考慮內存管理的事情了。
我已經在另一篇文章中解釋了更多關于使用WebAssembly模塊的內容。
WebAssembly 現(xiàn)在是什么狀態(tài)？
二月二十八日，四大瀏覽器宣布達成共識，即 WebAssembly 的 MVP （最小化可行產品）已經完成。大約一周后，Firefox會默認打開 WebAssembly 支持，而Chrome則在第二周開始。它也可用于預覽版本的Edge和Safari。
這提供了一個穩(wěn)定的初始版本，瀏覽器開始支持。
（看大圖）
該核心不包含社區(qū)組織計劃的所有功能。即使在初始版本中，WebAssembly 也會很快。但是，通過修復和新功能的組合，將來應該能夠更快。我在另一篇文章中詳細介紹了這些功能。
總結
使用WebAssembly，可以更快地在 web 應用上運行代碼。這里有 幾個 WebAssembly 代碼運行速度比 JavaScript 高效的原因。
- 文件加載 - WebAssembly 文件體積更小，所以下載速度更快。
- 解析 - 解碼 WebAssembly 比解析 JavaScript 要快
- 編譯和優(yōu)化 - 編譯和優(yōu)化所需的時間較少，因為在將文件推送到服務器之前已經進行了更多優(yōu)化，JavaScript 需要為動態(tài)類型多次編譯代碼
- 重新優(yōu)化 - WebAssembly 代碼不需要重新優(yōu)化，因為編譯器有足夠的信息可以在第一次運行時獲得正確的代碼
- 執(zhí)行 - 執(zhí)行可以更快，WebAssembly 指令更接近機器碼
- 垃圾回收 - 目前 WebAssembly 不直接支持垃圾回收，垃圾回收都是手動控制的，所以比自動垃圾回收效率更高。
目前瀏覽器中的 MVP（最小化可行產品） 已經很快了。在接下來的幾年里，隨著瀏覽器的發(fā)展和新功能的增加，它將在未來幾年內變得更快。沒有人可以肯定地說，這些性能改進可以實現(xiàn)什么樣的應用。但是，如果過去有任何跡象，我們可以期待驚奇。
(rb, ms, cm, il)
This article has been republished from Medium.
JavaScript 瀏覽器 程序員 C 設計版權聲明
本譯文僅用于學習、研究和交流目的，歡迎非商業(yè)轉載。轉載請注明出處、譯者和眾成翻譯的完整鏈接。 眾成翻譯@2015-2018 （京ICP備17024260-1號）轉載于:https://my.oschina.net/SamXIAO/blog/3071499
總結
以上是生活随笔為你收集整理的FW: 图说 WebAssembly的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： Loadrunner中几个超时函数的用法
- 下一篇： dhcp服务器显示不启用,如何启用dhc