(轉)WASM（WebAssember）快速瞭解第六篇——WebAssembly如今在哪裏，下一步是什麼？

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

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

這提供了瀏覽器能夠發佈的穩定內核。該核心不包含社區組織計劃的全部功能，但確實提供了足夠的功能，可使WebAssembly快速且可用。

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

即便在初始發行版中，WebAssembly也會很快。可是經過修復和新功能的組合，它未來應該會變得更快。

改善瀏覽器中的WebAssembly性能

隨着瀏覽器改進其引擎中的WebAssembly支持，速度將有所提升。瀏覽器供應商正在獨立處理這些問題。

JS和WebAssembly之間的更快的函數調用

當前，用JS代碼調用WebAssembly函數的速度比須要的慢。那是由於它必須作一些叫作「踩踏」的事情。JIT不知道如何直接處理WebAssembly，所以必須將WebAssembly路由到能夠處理的東西。這是引擎自己中的一小段代碼，它確實進行了設置以運行優化的WebAssembly代碼。

這可能比JIT知道如何直接處理它的速度慢100倍。

若是要將單個大型任務傳遞給WebAssembly模塊，您將不會注意到此開銷。可是，若是您在WebAssembly和JS之間有不少來回操做（就像處理較小的任務同樣），那麼這種開銷是顯而易見的。

加載時間更快

JIT必須在更快的加載時間和更快的執行時間之間進行權衡。若是您花費更多時間提早進行編譯和優化，則能夠加快執行速度，但會減慢啓動速度。

有不少正在進行的工做來平衡前期編譯（這確保一旦代碼開始運行就不會產生麻煩），而且基本的事實是，大多數代碼的運行時間不足以使優化值得進行。

因爲WebAssembly無需推測將使用哪一種類型，所以引擎沒必要擔憂在運行時監視類型。這給了他們更多的選擇，例如使編譯工做與執行並行化。

另外，JavaScript API的最新添加將容許WebAssembly的流式編譯。這意味着當字節仍在下載時，引擎能夠開始編譯。

在Firefox中，咱們正在使用兩個編譯器的系統。一個編譯器將提早運行，而且在優化代碼方面作得很好。在運行代碼的同時，另外一個編譯器將在後臺進行全面優化。徹底優化的代碼版本將在準備就緒時交換。

在規範中添加MVP後功能

WebAssembly的目標之一是指定小塊並逐步進行測試，而不是預先設計全部內容。

這意味着能夠預期有許多功能，但還沒有100％完善。他們將必須執行規範過程，全部瀏覽器供應商都將參與其中。

這些功能稱爲將來功能。這裏僅僅是少數。

直接使用DOM

當前，尚沒法與DOM進行交互。這意味着您沒法執行element.innerHTML從WebAssembly更新節點的操做。

相反，您必須經過JS來設置值。這可能意味着將值傳遞迴JavaScript調用者。另外一方面，這可能意味着從WebAssembly中調用JavaScript函數-JavaScript和WebAssembly函數均可以用做WebAssembly模塊中的導入。

不管哪一種方式，經過JavaScript的速度均可能比直接訪問的速度慢。WebAssembly的某些應用程序可能會一直存在，直到解決爲止。

共享內存併發

加快代碼速度的一種方法是使代碼的不一樣部分能夠同時並行運行。可是，這有時會拔苗助長，由於線程之間的通訊開銷可能比任務最初佔用的時間更多。

可是，若是您能夠在線程之間共享內存，則能夠減小此開銷。爲此，WebAssembly將使用JavaScript的新SharedArrayBuffer。一旦在瀏覽器中安裝了該組件，工做組就能夠開始指定WebAssembly應該如何使用它們。

SIMD

若是您閱讀其餘文章或觀看有關WebAssembly的討論，則可能會聽到有關SIMD支持的信息。首字母縮寫詞表明單條指令，多條數據。這是並行運行事物的另外一種方式。

SIMD能夠採用大數據結構，例如不一樣數字的向量，並同時將相同的指令應用於不一樣的部分。經過這種方式，它能夠大大加快遊戲或VR所需的各類複雜計算的速度。

對於通常的Web應用程序開發人員來講，這並非過重要。但這對於使用多媒體的開發人員（例如遊戲開發人員）很是重要。

異常處理

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

若是使用Emscripten編譯代碼，它將模擬某些編譯器優化級別的異常處理。可是，這很是慢，所以您可能須要使用該DISABLE_EXCEPTION_CATCHING標誌將其關閉。

一旦在WebAssembly中本地處理了異常，就沒必要進行此仿真。

其餘改進-使開發人員更輕鬆

未來的某些功能不會影響性能，但會使開發人員更輕鬆地使用WebAssembly。

• 一流的源代碼級開發人員工具。當前，在瀏覽器中調試WebAssembly就像調試原始程序集。可是，不多有開發人員能在思惟上將其源代碼映射到彙編。咱們正在研究如何改善工具支持，以便開發人員能夠調試其源代碼。
• 垃圾收集。若是能夠提早定義類型，則應該能夠將代碼轉換爲WebAssembly。所以，使用諸如TypeScript之類的代碼應可編譯爲WebAssembly。可是，目前惟一的障礙是WebAssembly不知道如何與現有的垃圾收集器進行交互，例如JS引擎內置的垃圾收集器。此將來功能的想法是使WebAssembly經過一組低級GC基本類型和操做對內置GC進行一流訪問。
• ES6 模塊集成。瀏覽器當前添加了對使用script標記加載JavaScript模塊的支持。添加此功能後，<script src=url type="module">即便url指向WebAssembly模塊，相似的標籤也能夠工做。

結論

WebAssembly現在發展很快，而且隨着新功能和瀏覽器實現的改進，它應該會變得更快。

最後

介紹下本系列文章的源做者

Lin Clark

Lin在Mozilla的Advanced Development工做，主要研究Rust和WebAssembly。