WebAssembly試玩

時間 2021-01-16

標籤 web 算法編程 windows 數組 promise 瀏覽器緩存安全架構欄目 HTML 简体版

原文原文鏈接

一.What?web

WebAssembly or wasm is a new portable, size- and load-time-efficient format suitable for compilation to the web.

一種可移植，體積小且加載迅速的（二進制）格式，適用於編譯到Web算法

主要目標是在Web環境支持高性能應用。但設計上不依賴Web特性，也不針對Web特性提供功能，也能夠用在其它環境編程

簡單理解，就是定義了一種編譯目標格式，能在支持該格式的任何環境得到接近原生的執行性能。至關於容許擴展native模塊，在苛求性能的場景，用其它更合適的語言（好比C++）來實現，再提早編譯到WebAssembly形式，就能得到媲美native的性能體驗windows

其設計目標分2方面：數組

快速，安全和可移植的語義promise

快速：以接近原生代碼的性能執行，並利用全部現代硬件通用的功能瀏覽器

安全：代碼通過驗證並在內存安全的沙盒環境中執行，防止數據損壞或安全違規緩存

定義良好：充分且精確地定義合法程序及其行爲，以一種容易推斷非正式與正式的方式安全

獨立於硬件：可在全部現代架構，臺式機或移動設備以及嵌入式系統上進行編譯架構

獨立於語言：不偏向任何特定語言，編程模型或對象模型

獨立於平臺：能夠嵌入到瀏覽器中，做爲stand-alone VM運行，或者集成到其餘環境中

開放：程序可以以簡單通用的方式與他們的環境交互

高效、可移植的表示

小巧：具備比典型文本或原生代碼格式體積更小的二進制格式，可以快速傳輸

模塊化：程序能夠拆分紅較小的部分，能夠單獨傳輸，緩存和使用

高效：能夠在單趟（遍歷）中快速對其進行解碼，驗證和編譯，等同於實時（JIT）或提早（AOT）編譯

流式：容許在拿到全部數據以前，儘早開始解碼、驗證和編譯

可並行：容許將解碼、驗證和編譯拆分紅多個獨立的並行任務

可移植：對現代硬件上不受普遍支持的架構不作假設

由主流瀏覽器（Chrome, Edge, Firefox, and WebKit）協力推進其標準化進程：

WebAssembly is currently being designed as an open standard by a W3C Community Group that includes representatives from all major browsers.

P.S.這個事情由瀏覽器廠商牽頭作（他們4個站在一塊兒搞事情，很值得期待），只是順便創建開放標準（不止面向Web環境），動力源自想要進一步提高JS運行時性能，在V8引入JIT以後，想要進一步提高性能已經不太可能了，由於面臨JS語言特性方面的限制（好比解釋型，弱類型）。Web能力愈來愈強大，客戶端JS愈來愈重，進一步提高JS執行性能的需求仍在，因此纔有了WebAssembly的釜底抽薪

二.wasm與wast
咱們知道WebAssembly定義了一種二進制格式，這種格式就是wasm，例如：

0061 736d 0100 0000 0187 8080 8000 0160
027f 7f01 7f03 8280 8080 0001 0004 8480
8080 0001 7000 0005 8380 8080 0001 0001
0681 8080 8000 0007 9080 8080 0002 066d
656d 6f72 7902 0003 6763 6400 000a ab80
8080 0001 a580 8080 0001 017f 0240 2000
450d 0003 4020 0120 0022 026f 2100 2002
2101 2000 0d00 0b20 020f 0b20 010b

這串十六進制數對應的C代碼是：

// 展轉相除法求最大公約數
int gcd(int m, int n) {
    if (m == 0) return n;
    return gcd(n % m, m);
}

wasm的可讀性等於0，爲了緩解這個問題，就定義了一種可讀性好一些的文本格式，叫wast：

(module
 (table 0 anyfunc)
 (memory $0 1)
 (export "memory" (memory $0))
 (export "gcd" (func $gcd))
 (func $gcd (; 0 ;) (param $0 i32) (param $1 i32) (result i32)
  (local $2 i32)
  (block $label$0
   (br_if $label$0
    (i32.eqz
     (get_local $0)
    )
   )
   (loop $label$1
    (set_local $0
     (i32.rem_s
      (get_local $1)
      (tee_local $2
       (get_local $0)
      )
     )
    )
    (set_local $1
     (get_local $2)
    )
    (br_if $label$1
     (get_local $0)
    )
   )
   (return
    (get_local $2)
   )
  )
  (get_local $1)
 )
)

括號有點Lisp風格，但至少是可讀的，例如：

// 導出了兩個東西，分別叫`memory`和`gcd`
(export "memory" (memory $0))
(export "gcd" (func $gcd))
// 函數簽名，接受2個int32類型參數，返回int32類型值
(func $gcd (; 0 ;) (param $0 i32) (param $1 i32) (result i32)
// 函數體...就不猜了

P.S.wast與wasm可以互相轉換，詳細見WABT: The WebAssembly Binary Toolkit

另外，在瀏覽器的Source面板可以看到另外一種文本指令：

func (param i32 i32) (result i32)
(local i32)
  block
    get_local 0
    i32.eqz
    br_if 0
    loop
      get_local 1
      get_local 0
      tee_local 2
      i32.rem_s
      set_local 0
      get_local 2
      set_local 1
      get_local 0
      br_if 0
    end
    get_local 2
    return
  end
  get_local 1
end

與wast長得很像，不知道有沒有名字，或者也屬於wast？這個是瀏覽器根據wasm轉換出來的

三.試玩環境
環境要求：

C/C++編譯環境Emscripten

支持WebAssembly的瀏覽器（最新的Chrome默認支持）

在線環境
有無傷試玩環境：WebAssembly Explorer

COMPILE再DOWNLOAD就能獲得wasm，簡直好用

注意，默認是C++環境，想用C的話，左側選擇C99或C89，不然函數名會被編壞，例如C++11的wast：

(module
 (table 0 anyfunc)
 (memory $0 1)
 (export "memory" (memory $0))
 (export "_Z3gcdii" (func $_Z3gcdii))
 (func $_Z3gcdii (; 0 ;) (param $0 i32) (param $1 i32) (result i32)
  (local $2 i32)
  (block $label$0
   (br_if $label$0
    (i32.eqz
     (get_local $0)
    )
   )
   (loop $label$1
    (set_local $0
     (i32.rem_s
      (get_local $1)
      (tee_local $2
       (get_local $0)
      )
     )
    )
    (set_local $1
     (get_local $2)
    )
    (br_if $label$1
     (get_local $0)
    )
   )
   (return
    (get_local $2)
   )
  )
  (get_local $1)
 )
)

函數名被編成_Z3gcdii了，猜想是命名空間之類的東西在做怪，C++不太熟，乖乖用C

P.S.除了C/C++，其它語言也能夠玩WebAssembly，好比Rust

本地環境
下載平臺SDK

按照安裝步驟來作

不出意外的話，到這裏就裝好了，能夠emcc -v試一下：

INFO:root:(Emscripten: Running sanity checks)
emcc (Emscripten gcc/clang-like replacement + linker emulating GNU ld) 1.37.22
clang version 4.0.0  (emscripten 1.37.22 : 1.37.22)
Target: x86_64-pc-windows-msvc
Thread model: posix
InstalledDir: D:\emsdk-portable-64bit\clang\e1.37.22_64bit
INFO:root:(Emscripten: Running sanity checks)

在Windows環境可能會遇到一個DLL缺失（MSVCP140.dll）的報錯，能夠手動安裝須要的C++環境，具體見MSVCP140.dll not found · Issue #5605 · kripken/emscripten

而後能夠編一個試試（把以前的C代碼保存成文件gcd.c）：

emcc ./c/gcd.c -Os -s WASM=1 -s SIDE_MODULE=1 -s BINARYEN_ASYNC_COMPILATION=0 -o ./output/gcd.wasm

P.S.更多用法見Emscripten Tutorial

獲得的gcd.wasm內容以下：

0061 736d 0100 0000 000c 0664 796c 696e
6b80 80c0 0200 010a 0260 027f 7f01 7f60
0000 0241 0403 656e 760a 6d65 6d6f 7279
4261 7365 037f 0003 656e 7606 6d65 6d6f
7279 0200 8002 0365 6e76 0574 6162 6c65
0170 0000 0365 6e76 0974 6162 6c65 4261
7365 037f 0003 0403 0001 0106 0b02 7f01
4100 0b7f 0141 000b 072b 0312 5f5f 706f
7374 5f69 6e73 7461 6e74 6961 7465 0002
0b72 756e 506f 7374 5365 7473 0001 045f
6763 6400 0009 0100 0a40 0327 0101 7f20
0004 4003 4020 0120 006f 2202 0440 2000
2101 2002 2100 0c01 0b0b 0520 0121 000b
2000 0b03 0001 0b12 0023 0024 0223 0241
8080 c002 6a24 0310 010b

注意，方法名默認會被添上下劃線（_）前綴，本例中導出的方法名爲_gcd，具體見Interacting with code：

The keys passed into mergeInto generate functions that are prefixed by _. In other words myfunc: function() {}, becomes function _myfunc() {}, as all C methods in emscripten have a _ prefix. Keys starting with $ have the $ stripped and no underscore added.

在JS中使用模塊接口應該加上下劃線（不知道有沒有配置項能去掉它）

四.試玩

WebAssembly.compile(new Uint8Array(`
    0061 736d 0100 0000 0187 8080 8000 0160
    027f 7f01 7f03 8280 8080 0001 0004 8480
    8080 0001 7000 0005 8380 8080 0001 0001
    0681 8080 8000 0007 9080 8080 0002 066d
    656d 6f72 7902 0003 6763 6400 000a ab80
    8080 0001 a580 8080 0001 017f 0240 2000
    450d 0003 4020 0120 0022 026f 2100 2002
    2101 2000 0d00 0b20 020f 0b20 010b 
    `.match(/\S{2}/g).map(s => parseInt(s, 16))
)).then(module => {
    const instance = new WebAssembly.Instance(module);
    console.log(instance.exports);
    const { gcd } = instance.exports;
    console.log('gcd(328, 648)', gcd(328, 648));
});

其中十六進制串來自在線試玩，與最初的wasm示例內容一致。把這些東西粘到Chrome的Console執行就能夠了，一切正常的話，會獲得報錯：

VM40:1 Uncaught (in promise) CompileError: WasmCompile: Wasm code generation disallowed in this context

這是由於默認的CSP（內容安全策略）限制，很容易解決，開隱身模式（Ctrl/CMD + Shift + N）便可

會獲得輸出：

{memory: Memory, gcd: ƒ}
gcd(328, 648) 8

第一行是加載咱們的WebAssembly獲得的模塊導出內容，包括一個內存對象和gcd方法，第二行輸出就是調用高性能模塊計算出的最大公約數

WebAssembly.compile等相關API能夠參考：

JavaScript API – WebAssembly：規範定義

WebAssembly – JavaScript | MDN：含有示例

另外，本地編譯獲得的版本要求imports env（並且函數名被添了下劃線_前綴）：

WebAssembly.compile(new Uint8Array(`
    0061 736d 0100 0000 000c 0664 796c 696e
    6b80 80c0 0200 010a 0260 027f 7f01 7f60
    0000 0241 0403 656e 760a 6d65 6d6f 7279
    4261 7365 037f 0003 656e 7606 6d65 6d6f
    7279 0200 8002 0365 6e76 0574 6162 6c65
    0170 0000 0365 6e76 0974 6162 6c65 4261
    7365 037f 0003 0403 0001 0106 0b02 7f01
    4100 0b7f 0141 000b 072b 0312 5f5f 706f
    7374 5f69 6e73 7461 6e74 6961 7465 0002
    0b72 756e 506f 7374 5365 7473 0001 045f
    6763 6400 0009 0100 0a40 0327 0101 7f20
    0004 4003 4020 0120 006f 2202 0440 2000
    2101 2002 2100 0c01 0b0b 0520 0121 000b
    2000 0b03 0001 0b12 0023 0024 0223 0241
    8080 c002 6a24 0310 010b 
    `.match(/\S{2}/g).map(s => parseInt(s, 16))
)).then(module => {
    let imports = {
        env: {
            memoryBase: 0,
            memory: new WebAssembly.Memory({ initial: 256 }),
            tableBase: 0,
            table: new WebAssembly.Table({ initial: 0, element: 'anyfunc' })
        }
    };
    const instance = new WebAssembly.Instance(module, imports);
    console.log(instance.exports);
    // 注意下劃線前綴
    const { _gcd } = instance.exports;
    console.log('gcd(328, 648)', _gcd(328, 648));
});

能夠獲得相似輸出：

{__post_instantiate: ƒ, runPostSets: ƒ, _gcd: ƒ}
gcd(328, 648) 8

應該是Emscripten默認添了一些可有可無的東西，功能上與咱們的簡版是等價的

五.優缺點及應用場景
優點
代碼體積很小

300k左右（壓縮後）JavaScript 邏輯改用WebAssembly重寫後，體積僅有90k左右

但使用WebAssembly須要引入一個50k-100k的JavaScript類庫做爲基礎設施

安全性稍有提高

雖然源碼對應的WebAssembly文本指令仍然毫無遮掩，但逆向成本高了一些

性能提高

理論上WebAssembly擁有接近native的執行性能，由於跳過了解釋環節，而且文件體積在傳輸方面也有優點

固然，前提是在業務代碼量很大，且要求極致性能的場景，在benchmark等重複執行的場景，JIT並不比AOT慢多少

缺點
目前能力有限：

僅支持幾種基本數據類型（i32 / i64 / f32 / f64 / i8 / i16）

沒法直接訪問DOM和其它Web API

沒法控制GC

應用場景
WebAssembly爲瀏覽器定義了一種標準可執行二進制格式，這樣更多的開發者都能經過統一的編譯機制參與進來，共建繁榮的Web生態，願景是美好的，但面臨一些實際問題

首先WebAssembly的初衷是「在Web環境支持高性能應用」，爲了突破性能瓶頸，那麼可能的應用場景是：

視頻解碼

圖像處理

3D/WebVR/AR可視化

渲染引擎

物理引擎

壓縮/加密算法

…等運算量比較大的場景

固然，些支持未來也可能會都內置到瀏覽器裏，而不用經過「擴展插件」之類的方式來作。但WebAssembly的真正意義是提供了一種容許自行擴展高性能「native」模塊的能力，畢竟等瀏覽器提供，再等到兼容性可接受可能須要至關長的一段時間，而有了這種能力以後，不用再苦苦等待市場主流瀏覽器都支持某個原生特性了，本身動手就搞定了，並且不存在兼容性差別。反過來，可能涌現出一批受歡迎的社區模塊，並逐步被吸納做爲瀏覽器原生支持，生態回饋Web環境

參考資料
WebAssembly

WebAssembly 實踐：如何寫代碼：很不錯的入門指南

如何評論瀏覽器最新的 WebAssembly 字節碼技術？

WebAssembly：解決 JavaScript 痼疾的銀彈？

WebAssembly，Web的新時代

Can WebAssembly be polyfilled?

wasm-arrays：WebAssembly數組包裝庫