前言#
最近打算寫編程語言（23 年終總結立的 flag），挑選了一下編譯的 backend，之前計劃編譯到 c backend，再利用 clang 編譯成二進制碼，好處自然是 c 的工具鏈已經非常成熟了，基於 llvm 也能很方便的編譯到各個 target，同時執行速度上也有保證 （畫外音吐槽：你怎麼不直接編譯到 llvm ir = =）。後來我又想折騰了（叛逆🐻），看了一下 rust 實現的 cranelift 後端，看上去是個不錯的選擇，因為 cranelift 主打的是 jit 編譯（也可以通過 object 模塊直接生成二進制文件），因此在代碼生成速度上要比 llvm 快的多（當然也沒有那麼多的優化 pass），同時依舊保持了非常不錯的性能。因為 cranelift 沒有提供其它語言的 binding，所以我又去學了一會兒 rust，然後放棄了（學 rust 第 n 次失敗，我太菜了😭）。最終，我靈感一閃，想到了將 webassembly 作為編譯的 backend，因此開始調研 wasm runtime，最終選擇了WAMR
為啥選擇 WAMR#
- 執行速度超快（非常接近原生的表現）
- 帶有解釋模式（剛好可以滿足在 dev 模式下快速啟動的需求）
- 帶有 wasi libc 支持
- 非常小的 binary size
開始折騰#
最開始打算先試用一下 WAMR，因此就先不考慮 embed 了，直接使用官方寫好的兩個 cli 進行測試，因為官方在 macOS 下只提供了 x86_64 的 prebuild binary，而我恰好用的是 arm 芯片，因此需要自己手動編譯一下，首先把 WAMR 的源碼下載到本地，我們需要 iwasm 和 wamrc 這兩個 cli，首先我們來編譯 iwasm
編譯 iwasm#
首先我們找到 iwasm 的路徑，在 product-mini/platforms/darwin 文件夾，可以看到 CMakeLists.txt 文件，感興趣的大家可以打開文件，裡面能看到編譯時可以設置的選項，我根據我使用的 case，在 product-mini/platforms/darwin 文件夾下新建了一個 make.sh 文件用於編譯，接下來我們來看看內容
#!/bin/sh
mkdir build && cd build
# 傳入編譯選項
cmake .. -DWAMR_BUILD_TARGET=AARCH64 -DWAMR_BUILD_JIT=0
# 編譯
make
cd ..
這段 shell 腳本裡，重點在於 cmake 這一段，我們傳入了兩個編譯選項，我們來解讀一下這些編譯選項的意思
WAMR_BUILD_TARGET=AARCH64 編譯到 arm 64 指令集
WAMR_BUILD_JIT=0 不編譯 JIT 功能 （其實最開始我是希望在 dev 模式下也可以使用 JIT 功能，這樣 dev 模式和最終的 build 模式的速度不至於差的太遠，目前 wamr 有兩種 JIT 模式，一種是 Fast JIT，一種是 LLVM JIT，其中 LLVM JIT 的體積太大，因此從一開始我就不打算編譯這個功能，畢竟只是在 dev 模式使用，沒有必要。另外一種 Fast JIT 倒是比較輕量，只需要增加非常少的二進制體積，性能按照官方的說法也能達到 llvm 的 50%，這對於 dev 模式來說足夠了，可惜在我的電腦上沒有編譯成功，後面再試試）
執行之後在 build 文件夾中可以看到 iwasm 可執行文件，在 AARCH64 架構下，純解釋執行的二進制文件只有 426 kb，可以說非常輕量了，接下來我們生成一個 webassembly 文件試試，這裡我選擇使用 rust 編譯到 wasm32-wasi target
首先我們使用 rustup 添加一下 wasm32-wasi 的 target
rustup target add wasm32-wasi
然後使用 cargo 創建一個新的 rust 項目
cargo new --bin hello_wasm
接下來我們來寫一個計算斐波那契的程序
use std::io;
fn fib_recursive(n: usize) -> usize {
match n {
0 | 1 => 1,
_ => fib_recursive(n - 2) + fib_recursive(n - 1),
}
}
fn main() {
println!("請輸入一個數字來計算斐波那契數列：");
let mut input = String::new();
io::stdin().read_line(&mut input).expect("無法讀取輸入");
let n: usize = input.trim().parse().expect("請輸入一個有效的數字");
// 計算斐波那契數列並測量時間
let start_time = std::time::Instant::now();
let result = fib_recursive(n);
let elapsed_time = start_time.elapsed();
println!("斐波那契數列第 {} 項的值為: {}", n, result);
println!("計算耗時: {:?}", elapsed_time);
}
編譯到 wasi
cargo build --target wasm32-wasi --release
編譯之後可以在 target/wasm32-wasi/release 找到編譯後的 hello_wasm.wasm 文件，讓我們使用剛剛編譯好的 iwasm 來執行一下這個 wasm 文件
iwasm --interp hello_wasm.wasm
可以看到程序順利執行了，在我的 mac mini (m1 芯片) 上，執行 fib (40) 耗時大約 3.7 s，而 rust 原生程序執行耗時為 337 ms，可以看到，純解釋器執行的 webassembly 效率大概是原生程序的 1 / 10 （其實已經是個不錯的成績了，這是因為 wamr 內部有一個快速解釋器的實現，將 webassembly 的棧式虛擬機指令先轉換成內部的 ir 再執行）
編譯 wamrc#
接下來是優化性能的重點，我們來編譯 wamrc，也就是將 wasm 文件轉換成 aot 文件，再使用上文編譯好的 iwasm 執行，來獲得更快的執行速度，因為 wamrc 依賴 llvm 做編譯優化，因此我們需要先編譯 llvm，在 macOS 下，我們先來安裝一下編譯 llvm 需要的依賴（已經安裝了 cmake 和 ninja 的可以忽略）
brew install cmake && brew install ninja
在 wamr-compiler 路徑下執行 build.sh
./build_llvm.sh
然後發現報錯了 = =，這裡我們跟著提示修復就好，看上去是我下載的 llvm 版本不支持 LLVM_CCACHE_BUILD 選項，這裡需要改一下 build-scripts/build_llvm.py 路徑下的編譯選項，將 ccache 選項關閉
LLVM_COMPILE_OPTIONS.append("-DLLVM_CCACHE_BUILD:BOOL=OFF")
修改之後再 build 一次 llvm，然後我們開始編譯 wamrc，這塊和編譯 iwasm 沒有什麼太大的區別，按照官方 readme 裡的編譯步驟就行
mkdir build && cd build
cmake .. -DWAMR_BUILD_PLATFORM=darwin
make
執行之後在 build 路徑下我們就得到了 wamrc 可執行文件，讓我們用 wamrc 編譯試試吧
./wamrc --size-level=3 -o hello_wasm.aot hello_wasm.wasm
這裡因為我是 arm64 架構的芯片，所以得加上 --size-level = 3 的選項，不然沒法編譯（和文件大小有關）
aot 執行 wasm#
我們將上面編譯的 aot 產物用 iwasm 來執行一下
./iwasm hello_wasm.aot
我們再來試著調用一下 fib (40)，這次在我的機器上執行耗時只花了 337 ms，和 rust 原生程序一致，雖然這一個簡單的例子無法完全代表 aot 和 rust 原生程序的執行速度差異，但是這也說明再經過 llvm 的優化之後，webassembly 也能達到接近原生的執行速度
小插曲#
node.js 使用的 v8 也是優化程度非常高的 jit 編譯器，但是和 aot 不同，v8 會先對 js 生成字節碼解釋執行，只有熱點函數才會進行 jit 編譯，同時因為 js 是動態類型的語言，比起 webassembly 這種靜態類型的語言也更加難以優化，那麼，作為動態語言的巔峰，執行上面的 fib 函數需要多久呢，在我的機器上，執行 fib (40) 大概耗費 959 ms，達到了 rust 原生程序的 30%，這裡也可以看出 v8 確實強