[譯][A crash course in WebAssembly] WebAssembly的進度和計劃

---

title: [A crash course in WebAssembly] WebAssembly的進度和計劃

date: 2018-3-24 10:26:00

categories: 翻譯

tags: WebAssembly

source: 原文地址

auther: Lin Clark

---

[A carsh course to WebAssembly] WebAssembly 進度與計劃

---

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

2月28日，四大主流瀏覽器宣佈他們一致認爲WebAssembly的MVP已經完成。這提供了瀏覽器能夠開始發佈的穩定的初始版本。

這爲瀏覽器提供了一個穩定的核心。此核心不包含社區組正在計劃的全部功能，但它確實提供了足夠的功能來確保WebAssembly快速且可用。

藉此，開發人員能夠開始發佈WebAssembly代碼。對於較早版本的瀏覽器，開發人員能夠發送一個asm.js版本的代碼。由於asm.js是JavaScript的子集，因此任何JS引擎均可以運行它。經過Emscripten，你能夠將相同的應用程序編譯爲WebAssembly和asm.js。

或者學習Rust，經過 LLVM toolchain 編譯到 .wasm 文件。

即便是較早的版本，WebAssembly依舊能體現性能優點。經過修復和添加新功能，將來性能會進一步提高。

提高 WebAssembly 在瀏覽器中的性能

隨着瀏覽器在其引擎中改進對WebAssembly的支持，性能將逐漸提高。瀏覽器供應正在各自獨立處理這些問題。

JS 與 WebAssembly之間更快的調用

目前，在JS代碼中調用WebAssembly函數比預期的慢。那是由於它必須作一些叫作「trampolining」的事情。 JIT不知道如何直接處理WebAssembly，因此它必須將WebAssembly發送能夠處理它的東西。這是段引擎自己的慢速代碼，它被設置爲運行優化的WebAssembly代碼。

若是JIT知道如何直接處理它，這將會快100倍！！。

你或許不會在傳遞一個大型任務的時候察覺到差異，但若是有許多的JS - WebAssembly之間的互相操做，性能差別就會格外明顯(就像傳遞一大堆小任務的時候，每一個任務都會經歷這個過程)。

更快的加載

JIT必須在加載時間和執行時間之間做出權衡。若是您提早花更多時間進行編譯和優化，這會就會加快執行速度，同時減慢啓動速度。

有不少正在進行的工做來平衡預編譯(確保代碼開始運行後不會出現跳動)而且事實上，大部分代碼不會有進行優化編譯所需的足夠多的運行時間。

因爲WebAssembly不須要推測類型，所以引擎沒必要在運行時監視類型。這給了他們更多選擇，例如將編譯工做和執行並行化。

另外，最近增長的JavaScript API將容許流式編譯WebAssembly。這意味着引擎能夠在一邊下載一邊編譯。

在Firefox中，咱們正在研究一個雙編譯器系統。 其中一個編譯器會提早運行，而且擅長優化代碼。另外一個編譯器會在運行代碼時在後臺執行徹底優化。代碼的徹底優化版將在其準備就緒時與正在運行的代碼切換。

爲規範添加post-MVP功能

WebAssembly的目標之一是在指定的一個小塊中進行測試，而不是事先設計好全部的東西。

這意味着有不少預期的功能，但尚未所有通過完備的思考。它們將不得不經歷全部瀏覽器供應商都積極參與的規範流程。

這些功能稱爲將來功能。這裏列出了一小部分

Working directly with the DOM

目前尚未辦法與DOM直接進行交互。這意味着你不能像element.innerHTML那樣經過WebAssembly更新一個節點。

做爲代替，你必須經過JS來設定值。這可能意味着將值傳遞迴JavaScript調用方。另外一方面，它可能意味着在WebAssembly中調用JavaScript函數 ———— JavaScript和WebAssembly函數均可以做爲導入的資源在WebAssembly模塊中使用。

不管哪一種方式，經過JavaScript訪問的速度可能比直接訪問慢。某些使用WebAssembly的應用程序可能會被妨礙，直到問題被解決。

共享內存併發 Shared memory concurrency

加速代碼運行的一種方法是使代碼的不一樣部分可以並行運行。然而，這有時會拔苗助長，由於線程之間的通訊開銷可能比任務花費更多的時間。

可是若是能夠在線程之間共享內存，這種開銷在必定程度上會減小。爲此，WebAssembly將使用JavaScript的新的SharedArrayBuffer。一旦在瀏覽器就緒，工做組就能夠開始規範WebAssembly如何與它們配合使用。

SIMD

若是你閱讀過其餘文章或參與過關於WebAssembly的討論，您可能會據說過SIMD。這個縮寫表明單指令，多數據。這是另外一種並行運行的方式。

SIMD使得獲取龐大的數據結構成爲可能，如不一樣數字的向量，並將同一條指令同時應用於不一樣的部分。經過這種方式，它能夠極大地加速遊戲或VR所需的複雜計算。

這對普通的Web應用程序開發人員來講並不重要。但對於遊戲開發人員這樣使用多媒體的開發人員來講，這很是重要。

異常處理

像 C++ 這樣的語言的許多代碼庫都使用異常。可是，異常還沒有被指定爲WebAssembly的一部分。

若是您使用Emscripten編譯代碼，它將模擬某些編譯器優化級別的異常處理。可是，這很慢，因此你可能想使用DISABLE_EXCEPTION_CATCHING標誌來關閉它。

若是異常在原生WebAssembly中獲得處理，這種仿真將不是必需的。

其餘改進 - 爲開發人員提供服務

一些將來的功能在不影響性能的前提下，可以使開發人員更輕鬆地使用WebAssembly。

• First-class source-level developer tools. - 一流的源代碼級開發人員工具 - 目前，在瀏覽器中調試WebAssembly就像調試原始彙編。只有一丟丟開發人員能夠在心中將其源代碼映射到彙編(人形編譯器嗎？？)。咱們正在研究如何改進工具支持，以便開發人員能夠調試他們的源代碼。

• Garbage collection - 垃圾回收 - 若是你能夠提早定義類型，就應該可以將你的代碼轉換爲WebAssembly。因此使用相似TypeScript的代碼應該也能夠編譯爲WebAssembly。可是，目前惟一的困難是WebAssembly不知道如何與現有的垃圾收集器進行交互，好比內置於JS引擎的垃圾收集器。這個將來功能的想法是經過一系列底層GC的原始類型和操做爲WebAssembly提供對內置GC的頂級訪問。

• ES6 module integration - ES6模塊整合 - 瀏覽器目前正在使用腳本標籤()添加對加載JavaScript模塊的支持。添加此功能後，即便url指向WebAssembly模塊，標籤(如