標(biāo)準(zhǔn)化進(jìn)展非常緩慢。為此 Fermyon 加入了 字節(jié)碼聯(lián)盟 親自推動(dòng)標(biāo)準(zhǔn)化進(jìn)程，并通過構(gòu)建 Spin 代碼實(shí)現(xiàn)來充分利用標(biāo)準(zhǔn)

語言支持不夠。Fermyon 認(rèn)為前 20 種語言中至少有 15 種必須完全支持 WebAssembly 以及 WASI 和組件，才能正確地認(rèn)為 WebAssembly 被很好地采用。Fermyon 采取的立場(chǎng)是將注意力集中在最受歡迎的語言上，這就是為什么使用 Rust 而不是 C 或Zig。

“

這方面也有一些好消息：

語言支持正在迅速增長，今年C#、Python和Ruby都增加了支持

wasi 支持現(xiàn)在是進(jìn)入 wasm 游戲領(lǐng)域的籌碼

在主流實(shí)現(xiàn)語言未能發(fā)揮作用的地方，該語言的替代實(shí)現(xiàn)正在加緊發(fā)展，比如 tinygo 對(duì)于 wasm 的支持就超越了 go

生態(tài)系統(tǒng)不是可選的。WebAssembly 有望成為下一波計(jì)算浪潮，但除非 Fermyon 能圍繞它建立生態(tài)系統(tǒng)，所以 Fermyon 正在努力聯(lián)合相關(guān)其他企業(yè)合作共建社區(qū)。

社區(qū)實(shí)現(xiàn)碎片化。（比如 deno 和其他非標(biāo)準(zhǔn)化實(shí)現(xiàn)，文章沒有明說）?？杀氖?，有時(shí)這僅僅是由于無知和不參與：“我們不知道有一個(gè)標(biāo)準(zhǔn)為此而出現(xiàn)”。所以目前發(fā)布的組件規(guī)范（正在進(jìn)行中，但正在迅速成熟）旨在解決這類問題，這個(gè)標(biāo)準(zhǔn)使得在不同的主機(jī)實(shí)現(xiàn)之間共享 WebAssembly 二進(jìn)制文件成為可能。

還有一個(gè)不幸的趨勢(shì)，即一些開發(fā)人員選擇與組件模型相反的工作，創(chuàng)建與他們自己的主機(jī)運(yùn)行時(shí)的強(qiáng)鏈接。走這條路一方面會(huì)導(dǎo)致平臺(tái)鎖定，另一方面會(huì)毫無意義地重新編寫相同的代碼（針對(duì)略有不同的主機(jī)進(jìn)行工具化）。幸運(yùn)的是，那些準(zhǔn)備最好的人（Fastly、Mozilla、Microsoft）反而選擇推動(dòng)互操作性標(biāo)準(zhǔn)以造福所有人。這是正確的第一步。

為了阻止破壞性的碎片化“手榴彈”，我們必須增加社會(huì)壓力，不要我行我素，而要堅(jiān)持互操作性標(biāo)準(zhǔn)。做到這一點(diǎn)的一個(gè)關(guān)鍵方法是彼此公開合作（通過字節(jié)碼聯(lián)盟、W3 和 CNCF 等組織），不僅要?jiǎng)?chuàng)建和實(shí)施標(biāo)準(zhǔn)，還要?jiǎng)?chuàng)建對(duì)話論壇。

“

Fermyon 的愿景是，在五年內(nèi)，WebAssembly 將成為常態(tài)，而不是小眾市場(chǎng)。新一波應(yīng)用程序?qū)⒛軌蚶?WebAssembly 的速度、安全性和組件模型。為了實(shí)現(xiàn)這一目標(biāo)，我們每個(gè)人都可以發(fā)揮作用。

Wasmtime 1.0 性能概覽

近日字節(jié)碼聯(lián)盟發(fā)布了 wasmtime 1.0 性能概覽[2] 的一篇文章，為將在 9.20號(hào)發(fā)布的 wasmtime 1.0 穩(wěn)定版做前期鋪墊，介紹了 wasmtime 團(tuán)隊(duì)近期在編譯器和運(yùn)行時(shí)中所做的工作。這里只做重點(diǎn)摘要，并非全文翻譯，對(duì)細(xì)節(jié)感興趣的可進(jìn)一步參閱原文。

什么是性能

讓 Wasmtime 和 Cranelift 變得更快意味著什么？所謂的“快”是什么意思？

“

Cranelift 也被用于 Rust Debug 模式編譯后端

當(dāng) Wasmtime 執(zhí)行 Wasm 程序時(shí)，CPU既執(zhí)行從Wasm字節(jié)碼編譯的本地指令，也執(zhí)行 "Wasmtime Runtime "的一部分，Wasmtime Runtime 用于維護(hù)數(shù)據(jù)結(jié)構(gòu)以幫助實(shí)現(xiàn)Wasm語義。這兩部分的執(zhí)行有兩個(gè)階段：啟動(dòng)初始化（Wasm代碼的編譯，和運(yùn)行時(shí)的初始化）和 穩(wěn)態(tài)（steady-state）執(zhí)行。這兩個(gè)層面的四個(gè)組合都對(duì)性能有一定的影響，可以分別進(jìn)行優(yōu)化。

wasmtime 對(duì)于改善這四個(gè)象限中的每一項(xiàng)都做了大量工作。

Wasm 模塊實(shí)例化

WebAssembly 之所以安全是因?yàn)閣asm 模塊每個(gè)實(shí)例與生俱來的隔離性。為了有效地利用這種隔離性，Wasm的一些應(yīng)用將每一個(gè)工作單元實(shí)例化為一個(gè)新的實(shí)例，例如服務(wù)器上每個(gè)傳入的請(qǐng)求。因此，極快的模塊實(shí)例化是像Wasmtime這樣的Wasm VM的一個(gè)關(guān)鍵要求。

現(xiàn)在 wasmtime 的模塊實(shí)例化速度已經(jīng)被優(yōu)化到了微秒級(jí)別。這是如何做到的呢？

虛擬內(nèi)存技術(shù)

在過去，wasmtime 是通過為 wasm 應(yīng)用初始化一大塊內(nèi)存（通過malloc或mmap或一些其他分配器），然后將數(shù)據(jù)復(fù)制到正確的位置。

現(xiàn)在，是從現(xiàn)代計(jì)算機(jī)使用的虛擬內(nèi)存技術(shù)獲得靈感，實(shí)現(xiàn)了一個(gè) 實(shí)例分配器[3]使用了mmap 、madvise 和寫時(shí)復(fù)制（copy-on-write）的技術(shù)將實(shí)例化的成本大大的降低了。

延遲初始化

Wasmtime運(yùn)行時(shí)在開始執(zhí)行已編譯的Wasm代碼之前，要花費(fèi)大量時(shí)間來初始化數(shù)據(jù)結(jié)構(gòu)。所以，團(tuán)隊(duì)為函數(shù)引用表和它們所指向的函數(shù)閉包對(duì)象實(shí)現(xiàn)了延遲初始化[4]。

優(yōu)化結(jié)果

SpiderMonkey.wasm 的實(shí)例化時(shí)間從大約2毫秒到5微秒，快了400倍。

運(yùn)行時(shí)性能

Wasm 執(zhí)行過程中的大部分 CPU 時(shí)間通常花在Wasm程序本身，或它調(diào)用的 "hostcalls"（這是Wasmtime用戶插入Wasmtime的代碼，無法直接控制），除此之外，Wasmtime本身有一些部分在某些情況下必須運(yùn)行，這部分代碼就是 Wasmtime Runtime 的性能優(yōu)化之處。

加速棧走查（Stack-Walking）

之前，為了讓W(xué)asmtime列舉所有的棧幀（stackframes），Cranelift編譯器產(chǎn)生了所謂的 "unwind info"。這是一種元數(shù)據(jù)，描述了編譯后的代碼將在任意給定點(diǎn)上把值放在棧中。利用這些元數(shù)據(jù)，Wasmtime的 "unwinder"能夠逆向程序狀態(tài)：它理解一個(gè)活動(dòng)函數(shù)每次調(diào)用的棧幀，最終找出誰調(diào)用了它，并在棧上迭代，直到它到達(dá)Wasm的初始入口。整個(gè)過程非常慢。

團(tuán)隊(duì)對(duì)此進(jìn)行了改進(jìn)，確保始終保持一個(gè)幀指針的鏈表，從而達(dá)到棧走查像遍歷鏈表那么簡單。這種性能改進(jìn)是一個(gè)巨大的質(zhì)量改進(jìn)：它允許啟用棧跟蹤，并大幅提高Wasmtime的健壯性。

加速多任務(wù)協(xié)作 與 代際（Epoch） 中斷

Wasmtime的一個(gè)常見用例是同時(shí)并發(fā)運(yùn)行許多不同的 WebAssembly guests，并在它們之間設(shè)置時(shí)間片。Wasmtime內(nèi)置支持在一個(gè)異步事件循環(huán)上運(yùn)行對(duì)Wasm的調(diào)用。

Wasmtime 用戶在這種情況下可能遇到的一個(gè)問題是如何限制 Wasm 程序的執(zhí)行時(shí)間。通常，當(dāng)與事件循環(huán)異步運(yùn)行時(shí)，計(jì)算密集型任務(wù)應(yīng)拆分為多個(gè)段，以便事件循環(huán)不會(huì)停止超過最大“時(shí)間片”。

通過將 Wasm 字節(jié)碼標(biāo)準(zhǔn)編譯為本地機(jī)器代碼，Wasm 中的循環(huán)成為編譯代碼中的循環(huán)，并運(yùn)行盡可能多的迭代，沒有限制。如果用戶從事件循環(huán)中調(diào)用此函數(shù)，則該事件循環(huán)可能會(huì)無限期停止。

因此，特別是在運(yùn)行不受信任的代碼時(shí)，Wasmtime 用戶必須建立一種在一定時(shí)間限制后重新獲得控制權(quán)的方法。所以 Wasmtime 必須提供一種在某個(gè)時(shí)間點(diǎn)中斷 Wasm 執(zhí)行的方法。

之前，實(shí)現(xiàn)這一行為的主要方式是通過“燃料（fuel）”。這是一種機(jī)制，通過該機(jī)制，已編譯的 Wasm 代碼增加了對(duì)“操作”進(jìn)行計(jì)數(shù)的代碼，根據(jù)限制檢查當(dāng)前計(jì)數(shù)，如果超出限制，則返回給調(diào)用者或事件循環(huán)?！叭剂希╢uel）”是一種有效的機(jī)制，但它成本很高：它需要用“計(jì)數(shù)”來擴(kuò)充每一段代碼，并經(jīng)常將該計(jì)數(shù)存儲(chǔ)到內(nèi)存中并檢查它。

團(tuán)隊(duì)使用了基于代際的中斷[5]取代了 “燃料（fuel）”機(jī)制，性能提升了兩倍。

“

使用 “燃料”機(jī)制還是代際中斷，是一種權(quán)衡?！叭剂稀睓C(jī)制更加精準(zhǔn)，而代際中斷性能更好。

Cranelift 編譯代碼的質(zhì)量

Cranelift 用于將Wasm字節(jié)碼編譯成計(jì)算機(jī)可以直接執(zhí)行的本地機(jī)器代碼。

寄存器分配器改造：regalloc2

在過去的一年里，wasmtime引入了新的寄存器分配器 regalloc2[6]。寄存器分配器是編譯器的一個(gè)部分，它為程序中的值分配存儲(chǔ)位置。在真正的CPU中，指令對(duì)寄存器中的數(shù)據(jù)進(jìn)行操作，寄存器是一些小的存儲(chǔ)位置，每個(gè)位置可以容納一個(gè)值（例如，一個(gè)64位的數(shù)字）。寄存器分配器決定在什么時(shí)候?qū)⒛男┲当４嬖谀男┘拇嫫髦小Ｗ龊眠@一點(diǎn)可以大大改善程序的性能，因?yàn)樗馕吨俚臄?shù)值移動(dòng)。WebAssembly，作為一個(gè)抽象的、與硬件無關(guān)的虛擬機(jī)，沒有大多數(shù)指令的輸入和輸出位置的概念。

regalloc2的設(shè)計(jì)是為了支持更高級(jí)的算法，以決定如何向寄存器分配數(shù)值。當(dāng)引入時(shí)，它將SpiderMonkey.wasm的運(yùn)行時(shí)性能提高了約5%，將另一個(gè)CPU密集型基準(zhǔn)測(cè)試bz2的性能提高了4%。

更好的模式管理：新的后端、ISLE和持續(xù)的調(diào)整

指令選擇問題是指選擇最佳的CPU指令來實(shí)現(xiàn)一個(gè)給定的程序行為。因?yàn)槊總€(gè)CPU都有自己獨(dú)特的指令集，而且這些指令可以以許多不同的方式組合，這是一個(gè)非常難解決的組合難題。Cranelift最初采用了一種新的編譯器后端設(shè)計(jì)，可以實(shí)現(xiàn)更高級(jí)的模式匹配，目前采取的方法是用模式匹配DSL（特定領(lǐng)域語言）來表達(dá)底層的指令，這樣我們就可以更容易地調(diào)整這些模式。

未來：中端優(yōu)化

在未來，我們計(jì)劃為Cranelift引入更先進(jìn)的中端優(yōu)化。中端優(yōu)化器 "是編譯器的一部分，在程序被 "降級(jí)"為機(jī)器特定的形式之前（也就是在指令選擇之前），以各種方式對(duì)程序進(jìn)行轉(zhuǎn)換，使其更快。有一套經(jīng)典的優(yōu)化方法，幾乎所有的編譯器都會(huì)執(zhí)行，包括簡化常數(shù)表達(dá)式（1+1變成2）等基本規(guī)則。但也有許多更復(fù)雜和微妙的轉(zhuǎn)換。

Cranelift: 編譯時(shí)優(yōu)化

除了優(yōu)化Cranelift生成的代碼，編譯過程本身如果太慢，那么Wasmtime可能需要很長的時(shí)間來啟動(dòng)新的代碼，將會(huì)阻礙生產(chǎn)力（對(duì)于Wasm開發(fā)人員）和響應(yīng)能力（對(duì)于訪問新應(yīng)用程序的最終用戶）。因此，編譯器的速度是一個(gè)重要的指標(biāo)。

廣義上講，我們可以通過在后端關(guān)鍵部分選擇更好的算法來提高編譯時(shí)間，如寄存器分配器或優(yōu)化通道，或通過做一般的程序優(yōu)化，如減少內(nèi)存使用。

regalloc2

切換到 regalloc2 顯著改善了編譯時(shí)間，因?yàn)榧拇嫫鞣峙湔季幾g時(shí)間的很大一部分：測(cè)量單線程時(shí)間（不是并行編譯），SpiderMonkey.wasm 的構(gòu)建速度提高了 6%，bz2 的構(gòu)建速度提高了 10%。

中端優(yōu)化器：將多個(gè)passes合并為一

算法重新設(shè)計(jì)也可以大大縮短編譯時(shí)間。在我們的中端優(yōu)化器原型中，我們對(duì)編譯器設(shè)計(jì)的相關(guān)部分采取了一種新的方法：幾個(gè)不同的 "程序"，或以某種方式改造程序的特定算法，被合并成一個(gè)統(tǒng)一的框架，只對(duì)程序進(jìn)行一次處理。

標(biāo)準(zhǔn)程序優(yōu)化

一種特別有效的提高速度的改變是減少內(nèi)存的分配和使用。程序分配的內(nèi)存越少，它的運(yùn)行速度就越快，至少有兩個(gè)原因：內(nèi)存分配器本身可能很慢，而且使用更多的內(nèi)存也會(huì)導(dǎo)致更多的緩沖區(qū)未命中和內(nèi)存流量。由于其多線程編譯模式，Cranelift也傾向于對(duì)分配器施加特別大的壓力。

總結(jié)

高性能是任何希望成為構(gòu)建高效、持久系統(tǒng)的基礎(chǔ)的軟件的一個(gè)關(guān)鍵方面。如果 WebAssembly 想要成功，它的運(yùn)行速度必須能達(dá)到與本地代碼競爭的水平。這也是 wasmtime 性能優(yōu)化的終極目標(biāo)。

通過該篇文章我們簡單了解了 Wasmtime 和 Cranelift 性能優(yōu)化的相關(guān)工作，以及當(dāng)前 wasmtime 1.0 的性能狀態(tài)（詳細(xì)數(shù)據(jù)見原文）。后續(xù)的文章將介紹該團(tuán)隊(duì)如何確保 Wasmtime 安全以及編譯器生成正確的代碼。

審核編輯：劉清