WebAssembly 那些事兒

WebAssembly 那些事兒

什麼是 WebAssembly？

WebAssembly 是除 JavaScript 之外，另外一種能夠在網頁中運行的編程語言，而且相比之下在某些功能和性能問題上更具優點，過去咱們想在瀏覽器中運行代碼來對網頁中各類元素進行控制，只有 JavaScript 這一種選擇，而現在咱們能夠將其它語言（C/C++ etc.）編譯成 wasm 格式的代碼在瀏覽器中運行。

WebAssembly 的目標是對高級程序中間表示的適當低級抽象，即 wasm 代碼旨在由編譯器生成而不是由人來寫。

每一種目標彙編語言（x8六、ARM etc.）都依賴於特定的機器結構，當咱們想要把代碼放到用戶的機器上執行的時候，並不知道目標機器結構是什麼樣的，而 WebAssembly 與其餘的彙編語言不同，它不依賴於具體的物理機器，能夠抽象地理解成它是 概念機器的機器語言，而不是實際的物理機器的機器語言，正由於如此 WebAssembly 指令有時也被稱爲虛擬指令，它比 JavaScript 代碼更直接地映射到機器碼，同時它也表明了「如何能在通用的硬件上更有效地執行代碼」的一種理念。

目前對於 WebAssembly 支持狀況最好的編譯器工具鏈是 LLVM，還有一個易用的工具叫作 Emscripten，它經過本身的後端先把代碼轉換成本身的中間代碼（asm.js），而後再轉化成 WebAssembly，實際上它是基於 LLVM 的一系列編譯工具的集合。

Tip：不少 WebAssembly 開發者用 C 語言或者 Rust 開發，再編譯成 WebAssembly，其實還有其餘的方式來開發 WebAssembly 模塊： 使用 TypeScript 開發 WebAssembly 模塊，或者 直接書寫 WebAssembly 文本 etc.。

WebAssembly 代碼存儲在 .wasm 文件內，這類文件是要瀏覽器直接執行的，由於 .wasm 文件內是二進制文件難以閱讀，爲方便開發者查看官方給出對 .wasm 文件的閱讀方法：
把 .wasm 文件經過工具轉爲 .wast 的文本格式，開發者能夠在必定程度上理解這個 .wast 文件（經過 S- 表達式寫成，相似於 lisp 語言的代碼書寫風格）。

Tip：.wast 文件和 .wasm 文件之間的相互轉化能夠經過工具 wabt 實現。

爲何 WebAssembly 更快？

一些關於性能的歷史

- JavaScript 於 1995 年問世，它的設計初衷並非爲了執行起來快，在前 10 個年頭它的執行速度也確實不快。

- 緊接着，瀏覽器市場競爭開始激烈起來。

- 廣爲流傳的「性能大戰」在 2008 年打響，許多瀏覽器引入 JIT 編譯器，JavaScript 代碼的運行速度漸漸變快（10倍！），這使得 JavaScript 的性能達到一個轉折點。

---

知識遷移：Javascript JIT 工做原理

在代碼的世界中，一般有兩種方式來翻譯機器語言：解釋器和編譯器。

• 若是是經過解釋器，翻譯是一行行地邊解釋邊執行
• 編譯器是把源代碼整個編譯成目標代碼，執行時再也不須要編譯器，直接在支持目標代碼的平臺上運行

解釋器啓動和執行的更快，咱們不須要等待整個編譯過程完成就能夠運行代碼，從第一行開始翻譯就能夠依次繼續執行。正是由於這個緣由，解釋器看起來更加適合 JavaScript，對於一個 Web 開發人員來說，可以快速執行代碼並看到結果是很是重要的。但是當咱們運行一樣的代碼一次以上的時候，解釋器的弊處就顯現出來：好比執行一個循環，那解釋器就不得不一次又一次的進行翻譯，這是一種效率低下的表現。

編譯器的問題則剛好相反：它須要花一些時間對整個源代碼進行編譯，而後生成目標文件才能在機器上執行。對於有循環的代碼執行的很快，由於它不須要重複的去翻譯每一次循環。

另一個不一樣是，編譯器能夠用更多的時間對代碼進行優化，以使的代碼執行的更快；而解釋器是在 runtime 時進行這一步驟的，這就決定它不可能在翻譯的時候用不少時間進行優化。

Just-in-time 編譯器：綜合二者的優勢

爲了解決解釋器的低效問題，後來的瀏覽器把編譯器也引入進來，造成混合模式。不一樣的瀏覽器實現這一功能的方式不一樣，不過其基本思想是一致的：在 JavaScript 引擎中增長一個監視器（也叫分析器），監視器監控着代碼的運行狀況，記錄代碼一共運行多少次、如何運行等信息。

起初，監視器監視着全部經過解釋器的代碼，若是同一行代碼運行屢次，這個代碼段就被標記成 「warm」，若是運行不少次則被標記成 「hot」。

基線編譯器

若是一段代碼變成 「warm」，那麼 JIT 就把它送到編譯器去編譯，而且把編譯結果存儲起來。

代碼段的每一行都會被編譯成一個「樁」（stub），同時給這個樁分配一個以「行號 + 變量類型」的索引，若是監視器監視到執行一樣的代碼和一樣的變量類型，那麼就直接把這個已編譯的版本 push 出來給瀏覽器。經過這樣的作法能夠加快執行速度，可是正如前我所說的，編譯器還能夠找到更有效地執行代碼的方法（優化）。

基線編譯器能夠作一部分這樣的優化，不過基線編譯器優化的時間不能過久，由於會使得程序的執行在這裏 hold 住，不過若是代碼確實很是 「hot」（也就是說幾乎全部的執行時間都耗費在這裏），那麼花點時間作優化也是值得的。

優化編譯器

若是一個代碼段變得 「very hot」，監視器會把它發送到優化編譯器中，生成一個更快速和高效的代碼版本出來，而且存儲之。爲了生成一個更快速的代碼版本，優化編譯器必須作一些假設：例如它會假設由同一個構造函數生成的實例都有相同的形狀，就是說全部的實例都有相同的屬性名，而且都以一樣的順序初始化，那麼就能夠針對這一模式進行優化。

整個優化器起做用的鏈條是這樣的，監視器從他所監視代碼的執行狀況作出本身的判斷，接下來把它所整理的信息傳遞給優化器進行優化，若是某個循環中先前每次迭代的對象都有相同的形狀，那麼就能夠認爲它之後迭代的對象的形狀都是相同的，但是對於 JavaScript 歷來就沒有保證這麼一說，前 99 個對象保持着形狀，可能第 100 個就減小某個屬性。

正是因爲這樣的狀況，編譯代碼須要在運行以前檢查其假設是否是合理的，若是合理那麼優化的編譯代碼會運行，若是不合理那麼 JIT 會認爲這是一個錯誤的假設，而且把優化代碼丟掉，這時執行過程將會回到解釋器或者基線編譯器，這一過程叫作去優化。

一般優化編譯器會使得代碼變得更快，可是一些狀況也會引發一些意想不到的性能問題。若是代碼一直陷入優化去優化的怪圈，那麼程序執行將會變慢，還不如基線編譯器快。大多數的瀏覽器限制當優化去優化循環發生的時候會嘗試跳出這種循環，好比若是 JIT 反覆作 10 次以上的優化而且又丟棄的操做，那麼就不繼續嘗試去優化這段代碼。

一個優化的例子：類型特化（Type specialization）

JavaScript 所使用的動態類型體系在運行時須要進行額外的解釋工做，例以下面代碼：

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

+= 循環中這一步看起來很簡單，只須要進行一步計算，可是偏偏由於是用動態類型，所須要的步驟要比咱們所想象的更復雜一些：咱們假設 arr 是一個有 100 個整數的數組，當代碼被標記爲 「warm」 時，基線編譯器就爲函數中的每個操做生成一個樁，sum += arr[i]會有一個相應的樁，而且把裏面的 += 操做當成整數加法，可是 sum 和 arr[i] 兩個數並不保證都是整數，由於在 JavaScript 中類型都是動態類型，在接下來的循環當中 arr[i] 頗有可能變成了string 類型，整數加法和字符串鏈接是徹底不一樣的兩個操做，會被編譯成不一樣的機器碼。

JIT 處理這個問題的方法是編譯多基線樁：若是一個代碼段是單一形態的（即老是以同一類型被調用），則只生成一個樁：若是是多形態的（即調用的過程當中，類型不斷變化），則會爲操做所調用的每個類型組合生成一個樁。這就是說 JIT 在選擇一個樁以前會進行多分枝選擇（相似於決策樹），問本身不少問題纔會肯定最終選擇哪一個。

正是由於在基線編譯器中每行代碼都有本身的樁，因此 JIT 在每行代碼被執行的時候都會檢查數據類型，在循環的每次迭代 JIT 也都會重複一次分枝選擇。

若是代碼在執行的過程當中 JIT 不是每次都重複檢查的話，那麼執行的還會更快一些，而這就是優化編譯器所須要作的工做之一。在優化編譯器中，整個函數被統一編譯，這樣的話就能夠在循環開始執行以前進行類型檢查。

一些瀏覽器的 JIT 優化更加複雜：在 Firefox 中給一些數組設定特定的類型，好比數組裏面只包含整型，若是 arr 是這種數組類型，那麼 JIT 就不須要檢查 arr[i] 是否是整型，這也意味着 JIT 能夠在進入循環以前進行全部的類型檢查。

---

- 隨着性能的提高 JavaScript 能夠應用到更多領域（Node.js etc.）

- 經過 WebAssembly 咱們頗有可能正處於第二個拐點！

當前的 JavaScript 性能如何？

下圖片介紹 JS 引擎性能使用的大概分佈狀況，各個部分所花的時間取決於頁面所用的 JavaScript 代碼，其比例並不表明真實狀況下的確切比例狀況，而且這些任務並非離散執行或者按固定順序依次執行的，而是交叉執行：好比某些代碼在進行解析時，其餘一些代碼正在運行而另外一些正在編譯。

• Parsing：表示把源代碼變成解釋器能夠運行的代碼所花的時間；
• Compiling + optimizing：表示基線編譯器和優化編譯器所花的時間（某些優化編譯器的工做並不在主線程運行）
• Re-optimizing：當 JIT 發現優化假設錯誤，丟棄優化代碼所花的時間（包括重優化的時間、拋棄並返回到基線編譯器的時間）
• Execution：執行代碼的時間
• Garbage collection：垃圾回收、清理內存的時間

早期的 JavaScript 執行相似於下圖，各個過程順序進行：

各個瀏覽器處理下圖中不一樣的過程有着細微的差異，咱們使用 SpiderMonkey 做爲模型來說解不一樣的階段：

文件獲取

這一步並無顯示在圖表中，可是看似簡單的從服務器獲取文件得這個步驟，卻會花費很長時間，WebAssembly 比 JavaScript 的壓縮率更高，即在服務器和客戶端之間傳輸文件更快，尤爲在網絡很差的狀況下。

解析

當文件到達瀏覽器時 JavaScript 源代碼就被解析成抽象語法樹，瀏覽器採用懶加載的方式進行，只解析真正須要的部分，而對於瀏覽器暫時不須要的函數只保留它的樁。解析事後 AST（抽象語法樹）就變成了中間代碼（字節碼：一種中間代碼，經過虛擬機轉換爲機器語言）提供給 JS 引擎編譯，而 WebAssembly 則不須要這種轉換，由於它自己就是中間代碼，要作的只是解碼而且檢查確認代碼沒有錯誤便可。

---

知識遷移：抽象語法樹

抽象語法樹（Abstract Syntax Tree）也稱爲 AST 語法樹，指的是源代碼語法所對應的樹狀結構。

程序代碼自己能夠被映射成爲一棵語法樹，而經過操縱語法樹咱們可以精準的得到程序代碼中的某個節點。Espsrima 提供一個在線解析的工具，咱們能夠藉助於這個工具將 JavaScript 代碼解析爲一個 JSON 文件表示的樹狀結構，舉例以下所示：

// Life, Universe, and Everything
var answer = 6 * 7;

{
    "type": "Program",
    "body": [
        {
            "type": "VariableDeclaration",
            "declarations": [
                {
                    "type": "VariableDeclarator",
                    "id": {
                        "type": "Identifier",
                        "name": "answer"
                    },
                    "init": {
                        "type": "BinaryExpression",
                        "operator": "*",
                        "left": {
                            "type": "Literal",
                            "value": 6,
                            "raw": "6"
                        },
                        "right": {
                            "type": "Literal",
                            "value": 7,
                            "raw": "7"
                        }
                    }
                }
            ],
            "kind": "var"
        }
    ],
    "sourceType": "script"
}

抽象語法樹的做用很是的多，好比編譯器、IDE、壓縮優化代碼 etc.，在 JavaScript 中雖然咱們並不會經常與 AST 直接打交道，但卻也會常常涉及到它的使用：例如使用 UglifyJS 來壓縮代碼時，這背後的原理就是在對 JavaScript 的抽象語法樹進行操做。

---

編譯和優化

JavaScript 是在代碼的執行階段編譯的，由於它是弱類型語言，當變量類型發生變化時，一樣的代碼會被編譯成不一樣版本，不一樣瀏覽器處理 WebAssembly 的編譯過程也不一樣，有些瀏覽器只對 WebAssembly 作基線編譯，而另外一些瀏覽器用 JIT 來編譯，不論哪一種方式，WebAssembly 都更貼近機器碼因此它更快：

1. 在編譯優化代碼以前不須要提早運行代碼以知道變量都是什麼類型
2. 編譯器不須要對一樣的代碼作不一樣版本的編譯
3. 不少優化在 LLVM 階段就已經完成

重優化

有些狀況下 JIT 會反覆地進行拋棄優化代重優化過程，當 JIT 在優化假設階段作的假設在執行階段發現是不正確的時候，就會發生這種狀況：好比當循環中發現本次循環所使用的變量類型和上次循環的類型不同，或者原型鏈中插入了新的函數，都會使 JIT 拋棄已優化的代碼。

1. 須要花時間丟掉已優化的代碼而且回到基線版本
2. 若是函數依舊頻繁被調用，JIT 可能會再次把它發送到優化編譯器又作一次優化編譯

而在 WebAssembly 中類型都是肯定的，因此 JIT 不須要根據變量的類型作優化假設，也就是說 WebAssembly 沒有重優化階段。

執行

開發人員本身也能夠寫出執行效率很高的 JavaScript 代碼，這須要瞭解 JIT 的優化機制，例如要知道什麼樣的代碼編譯器會對其進行特殊處理，然而大多數的開發者是不知道 JIT 內部的實現機制的，即便知道 JIT 的內部機制也很難寫出符合 JIT 標準的代碼，由於人們一般爲了代碼可讀性更好而使用的編碼模式偏偏不合適編譯器對代碼的優化；加之 JIT 會針對不一樣的瀏覽器作不一樣的優化，因此對於一個瀏覽器優化的比較好，極可能在另一個瀏覽器上執行效率就比較差。

正是由於這樣執行 WebAssembly 一般會比較快，不少 JIT 爲 JavaScript 所作的優化在 WebAssembly 並不須要；另外 WebAssembly 就是爲編譯器而設計的，開發人員不直接對其進行編程，這樣就使得 WebAssembly 專一於提供更加理想的指令（執行效率更高的指令）給機器便可。

垃圾回收

JavaScript 中開發者不須要手動清理內存中不用的變量，JS 引擎會自動地作這件事情即垃圾回收的過程。但是當咱們想要實現性能可控，垃圾回收可能就是一個大問題：垃圾回收器會自動開始，這是不受控制的，因此頗有可能它會在一個不合適的時機啓動，目前的大多數瀏覽器已經能給垃圾回收安排一個合理的啓動時間，不過這仍是會增長代碼執行的開銷。

目前爲止 WebAssembly 不支持垃圾回收，內存操做都是手動控制的，這對於開發者來說確實會增長開發成本，不過也使得代碼的執行效率更高。

WebAssembly 的如今與將來

JavaScript 和 WebAssembly 之間調用的中間函數

目前在 Javascript 中調用 WebAssembly 的速度比本應達到的速度要慢，這是由於中間須要作一次「蹦牀運動」：JIT 沒有辦法直接處理 WebAssembly，因此 JIT 要先把 WebAssembly 函數發送到懂它的地方，這一過程是引擎中比較慢的地方。

按理來說，若是 JIT 知道如何直接處理 WebAssembly 函數，那麼速度會有百倍的提高，若是咱們傳遞的是單一任務給 WebAssembly 模塊，那麼不用擔憂這個開銷，由於只有一次轉換，也會比較快，可是若是是頻繁地從 WebAssembly 和 JavaScript 之間切換，那麼這個開銷就必需要考慮了。

快速加載

JIT 必需要在快速加載和快速執行之間作權衡，若是在編譯和優化階段花了大量的時間，那麼執行的必然會很快，可是啓動會比較慢。目前有大量的工做正在研究，如何使預編譯時間和程序真正執行時間二者平衡。WebAssembly 不須要對變量類型作優化假設，因此引擎也不關心在運行時的變量類型，這就給效率的提高提供了更多的可能性，好比可使編譯和執行這兩個過程並行。加之最新增長的 JavaScript API 容許 WebAssembly 的流編譯，這就使得在字節流還在下載的時候就啓動編譯。

FireFox 目前正在開發兩個編譯器系統：一個編譯器先啓動，對代碼進行部分優化，在代碼已經開始運行時，第二個編譯器會在後臺對代碼進行全優化，當全優化過程完畢，就會將代碼替換成全優化版本繼續執行。

添加後續特性到 WebAssembly 標準的過程

直接操做 DOM

目前 WebAssembly 沒有任何方法能夠與 DOM 直接交互，就是說咱們還不能經過好比 element.innerHTML 的方法來更新節點。想要操做 DOM 必需要經過 JS，那麼就要在 WebAssembly 中調用 JavaScript 函數，無論怎麼樣都要經過 JS 來實現，這比直接訪問 DOM 要慢得多，因此這是將來必定要解決的一個問題。

共享內存的併發性

提高代碼執行速度的一個方法是使代碼並行運行，不過有時也會拔苗助長，由於不一樣的線程在同步的時候可能會花費更多的時間。這時若是可以使不一樣的線程共享內存，那就能下降這種開銷，實現這一功能 WebAssembly 將會使用 JavaScript 中的 SharedArrayBuffer，而這一功能的實現將會提升程序執行的效率。

SIMD（單指令，多數據）

SIMD（Single Instruction, Multiple Data）在處理存放大量數據的數據結構有其獨特的優點，好比存放不少不一樣數據的 vector（容器），就能夠用同一個指令同時對容器的不一樣部分作處理，這種方法會大幅提升複雜計算的效率好比遊戲或者 VR 應用。

異常處理

許多語言都仿照 C++ 式的異常處理，可是 WebAssembly 並無包含異常處理，若是咱們用 Emscripten 編譯代碼，就知道它會模擬異常處理，可是這一過程很是之慢，慢到想用 「DISABLEEXCEPTIONCATCHING」 標記把異常處理關掉。若是異常處理加入到 WebAssembly 中那就沒必要再採用模擬的方式，而異常處理對於開發者來說又特別重要，因此這也是將來的一大功能點。