Rust在瀏覽器Wasm和後端伺服器中執行效能比較

banq發表於2022-03-07
Rust瀏覽器ASM後端伺服器

需求：有一個計算密集型程式，實現快速的演算法速度，然後需要將最終結果傳遞給瀏覽器；
解決方案：是在伺服器端（在 actix Web 伺服器中）執行它？還是在瀏覽器內的 Wasm 模組中執行它？
 
WASM 通常在客戶端執行，雖然它被編譯為二進位制格式，但它仍然在 WASM VM 中執行，這意味著它可能有點接近本機機器程式碼；
另一方面，在伺服器上執行的本機編譯的 Rust 程式碼通常會在本機機器程式碼的帳戶上更快（但同樣有很多變數和上下文無法承受）。

一些 CPU 密集型程式有時在 wasm 中明顯變慢，沒有明顯的原因。這是當前 wasm 實現的缺點之一，並且很難在程式方面修復：論文。
 
伺服器端程式碼很可能能夠使用 simd，但是並非所有瀏覽器都支援 SIMD，檢測一下瀏覽器是否支援它，如果支援，則獲得相當顯著的加速（並且 SIMD 首先適用於您的用例）。這幾乎是 WASM 在長時間執行的任務中比 JS 具有非常顯著的效能優勢的主要情況。
然而，您需要考慮的另一個因素是負載平衡：當客戶端數量增加時，您的伺服器是否仍然會更快？
最後，是否要將您的頁面提供給手機？如果是這樣，您的伺服器很可能會更快。
 
當你做你的 wasm 基準測試時，你是否開啟了 devtools標識？如果你這樣做，它會在某種除錯模式下執行，速度會慢 5-10 倍。
在Chrome瀏覽器中的開發工具dev tools控制檯有一個效能標籤，可以全速執行，當控制檯開啟時，wasm程式碼是 "分層 "的；而Firefox也有類似的 "開啟devtools "後速度更慢的行為。
在執行fibonacci演算法時，如果不開啟這個標識開關，其實現的WASM版本比javascript實現慢了5倍，開啟devtools後。一旦重新整理了頁面，關閉了它們，情況就相反了：WASM的速度是JS的5倍。
 
WASM VM 的效能無法與編譯為 x86 的應用程式相提並論：
一個方面是呼叫WASM模組的開銷。傳遞資料來往。這並不像人們想象的那樣多。如果你經常來回撥用，這可能是一個需要最佳化的領域。這也包括有多少資料被傳遞過去。因為這被複制了。
當你編譯Rust到WASM時，你會得到為你生成的捆綁JS檔案。另一個需要調查的領域是研究如何最佳化這些膠水程式碼。
WASM模組在使用前也要進行編譯和例項化。檢查這是否被包括在你的基準中。因為你可以在頁面載入後，在後臺，在你需要執行WASM數學程式碼之前提前做這個。
 
瀏覽器中的 WASM 目前通常非常緩慢且令人失望？錯了，純粹的計算（即不呼叫會減慢它的 JS）可以非常接近本機速度，如果它涉及大量 SIMD，您甚至可以擊敗本機程式碼。Idiomatic Rust 的速度也經常以 > 10 倍的速度擊敗慣用 JS。
JavaScript JIT 在最佳化方面表現出色，而 WASM 程式碼似乎沒有得到同樣的處理， wasm 仍然無法直接訪問任何瀏覽器 API。
 

相關文章