標準化進展非常緩慢。為此 Fermyon 加入了 字節(jié)碼聯(lián)盟 親自推動標準化進程，并通過構建 Spin 代碼實現(xiàn)來充分利用標準

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

“

這方面也有一些好消息：

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

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

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

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

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

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

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

“

Fermyon 的愿景是，在五年內，WebAssembly 將成為常態(tài)，而不是小眾市場。新一波應用程序將能夠利用 WebAssembly 的速度、安全性和組件模型。為了實現(xiàn)這一目標，我們每個人都可以發(fā)揮作用。

Wasmtime 1.0 性能概覽

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

什么是性能

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

“

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

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

wasmtime 對于改善這四個象限中的每一項都做了大量工作。

Wasm 模塊實例化

WebAssembly 之所以安全是因為wasm 模塊每個實例與生俱來的隔離性。為了有效地利用這種隔離性，Wasm的一些應用將每一個工作單元實例化為一個新的實例，例如服務器上每個傳入的請求。因此，極快的模塊實例化是像Wasmtime這樣的Wasm VM的一個關鍵要求。

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

虛擬內存技術

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

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

延遲初始化

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

優(yōu)化結果

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

運行時性能

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

加速棧走查（Stack-Walking）

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

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

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

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

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

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

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

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

團隊使用了基于代際的中斷[5]取代了 “燃料（fuel）”機制，性能提升了兩倍。

“

使用 “燃料”機制還是代際中斷，是一種權衡。“燃料”機制更加精準，而代際中斷性能更好。

Cranelift 編譯代碼的質量

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

寄存器分配器改造：regalloc2

在過去的一年里，wasmtime引入了新的寄存器分配器 regalloc2[6]。寄存器分配器是編譯器的一個部分，它為程序中的值分配存儲位置。在真正的CPU中，指令對寄存器中的數(shù)據(jù)進行操作，寄存器是一些小的存儲位置，每個位置可以容納一個值（例如，一個64位的數(shù)字）。寄存器分配器決定在什么時候將哪些值保存在哪些寄存器中。做好這一點可以大大改善程序的性能，因為它意味著更少的數(shù)值移動。WebAssembly，作為一個抽象的、與硬件無關的虛擬機，沒有大多數(shù)指令的輸入和輸出位置的概念。

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

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

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

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

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

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

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

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

regalloc2

切換到 regalloc2 顯著改善了編譯時間，因為寄存器分配占編譯時間的很大一部分：測量單線程時間（不是并行編譯），SpiderMonkey.wasm 的構建速度提高了 6%，bz2 的構建速度提高了 10%。

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

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

標準程序優(yōu)化

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

總結

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

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

審核編輯：劉清