Google 試算表是 Google 在 Chrome 上率先使用 WasmGC 的產品之一。這是 2022 年宣布的遷移計畫,Google 試算表和 Chrome 團隊與標準化、工程和工具合作,針對最佳化作業提供即時意見回饋。這項合作計畫對於 Google 工程團隊如何與 Chrome 有效合作,讓他們能在 WasmGC 上執行更多 Google 應用程式。
挑戰:JavaScript
Google 試算表的計算引擎最初是以 Java 編寫,並於 2006 年推出。在產品推出初期,所有計算作業都在伺服器上進行。不過,自 2013 年起,引擎已經使用 JavaScript 在瀏覽器中執行。這項作業最初是透過 Google Web Toolkit (GWT),之後透過 Java 到 Closure JavaScript 轉譯器 (J2CL)。JavaScript 計算引擎會在網路工作站中執行,並使用 MessageChannel
與主執行緒通訊。
將使用者從伺服器遷移至 JavaScript 版本的計算引擎 (以及之後從 GWT 遷移至 J2CL),這是必須謹慎驗證的主要原因。為了確保 JavaScript 計算引擎產生的結果與 Java 版本完全相同,Google 試算表團隊開發了內部驗證機制。這項機制可處理大型工作表語料庫,並驗證計算引擎的多個版本之間的結果是否相同。Google 試算表團隊會定期使用這項工具驗證 Google 試算表的變更內容。不過,團隊不只比較這些計算結果,還比較了用戶端與伺服器 Java 之間的效能。他們發現 JavaScript 版本的計算引擎,比 Java 版本的慢了 3 倍以上。
為什麼 JavaScript 比 Java 慢?
JavaScript 針對鬆散類型的動態語言快速載入。過去 15 年來,Maglev、Sparkplug 和 Turbofan) 投入大量心力在及時發展型編譯器,因此提升了 JavaScript 的執行效能。然而,JavaScript 的類型和動態行為較不理想,因此 JIT 編譯器很難產生最佳程式碼。這表示 JavaScript 仍會落後於 Java 和 C++ 等語言,提供原始處理量。TypeScript 可提升 JavaScript 類型安全性,但這類類型資訊旨在簡化開發程序,而不是提供編譯器需要產生最佳程式碼所需的保證。在 Google 試算表這類情況下,大型試算表可能需要數十秒才能完成計算,這時 JavaScript 速度很快,但速度還不夠快。
解決方案:WasmGC
WasmGC 是現有 WebAssembly 規格的 擴充功能,可加入編譯垃圾收集語言 (例如 Java) 所需的基本功能。舉例來說,WasmGC 新增了定義類型及分配垃圾收集資料結構的操作說明。WasmGC 預計將 Wasm 針對 C++ (例如 Photoshop 或 Google 地球) 進行垃圾收集,以便以近乎原生的速度連上網路。Google 相信,由於垃圾收集的語言越來越受歡迎,我們相信 WasmGC 的影響力甚至比 Wasm 更出色。
Google Workspace 與 Chrome 攜手合作
WasmGC MVP 草稿規格於 2019 年發布。2020 年底,Google Workspace 和 Chrome 攜手合作,使用試算表計算引擎評估 WasmGC。Workspace 的多平台團隊具備豐富的專業知識,能建立及最佳化編譯器和轉譯器。Google 試算表是 Workspace 中的一項服務,是評估 WasmGC 的理想選擇:它不僅注重效能,也具備健全的效能和正確性驗證機制。Chrome 擁有 V8 團隊打造及最佳化 WasmGC 執行階段,以及對 Binaryen 提供內容貢獻者,協助他們預先 (AOT) 最佳化調整。無論是 Chrome 與 Workspace,還是具備建構和最佳化 WasmGC 工具鍊所需的專業知識,Google 試算表都是理想的測試平台。
第一個原型
在 2021 年中前,團隊打造了一個 Java 至 WasmGC 編譯器的工作。今年年底前,他們以 WasmGC 的形式執行 Google 試算表的原型版本,並進行計算。他們一路走來,他們克服了許多挑戰。不存在剖析及擷取記憶體快照資料的工具,因此需要建構。現有的實作方式仰賴許多 JavaScript 程式庫,而這些程式庫必須找到或編寫供 WasmGC 取代的替代程式庫。由於規格、編譯器和新程式庫屬於實驗性質,因此驗證 Wasm 計算引擎的正確性會耗費大量時間。但 Google 試算表的驗證機制過去一直都很有幫助。團隊最終終於順利獲得一切,成效資料也將於 2022 年初提供。
其他最佳化設定
試算表 Wasm 最初版的計算效能大約比 JavaScript 低了兩倍。不過,對於新規格、新編譯器和多個新程式庫而言,這並非不良結果。此時,Google 試算表團隊開始進行最佳化。他們根據這些改善內容發現以下幾個類別:
- 複製 Java 虛擬機器 (JVM) 和 V8 中既有的核心最佳化。
- 使用高度最佳化的瀏覽器 API。
- 移除 JavaScript 特有的編碼模式。
首先,Google 試算表團隊需要複製其他工具鍊中現有的最佳化內容。最好的例子是最佳化虛擬方法分派,這個方法已由 JVM 和 V8 最佳化,但 WasmGC 並沒有最佳化。在 Chrome 中導入推測內嵌和去虛擬化功能 (兩種很常見的最佳化做法),將計算時間縮短約 40%。
第二,有時候瀏覽器 API 均由最佳化原生實作支援,因此難以與 Wasm 競爭。字串和規則運算式就是兩個很好的範例。具體來說,在規則運算式中,團隊從 re2j (編譯至 WasmGC) 切換至 RegExp
瀏覽器 API 時,規則運算式作業的速度提升將近 100 倍,這項工具可將各個規則運算式編譯成各自的機器碼。
最後,他們發現數年的最佳化導致程式碼集過度適應 JavaScript。舉例來說,這些公司在 Google 試算表中使用核心資料結構,模糊處理了陣列與對應之間的線條。這在 JavaScript 中很有效率,可以自動將稀疏陣列建立成對應,但在其他平台上的執行速度較慢。因此他們必須以更適用於平台的方式重新編寫程式碼。WebAssembly 是開發團隊的另一項特色:這個平台可讓多平台應用程式更輕鬆地在網路上展現良好效能。您不需要將整個應用程式繫結至 JavaScript 的用語。
最終結果
完成上述所有最佳化調整後,Google 試算表的最終 WasmGC 版本計算效能大約是 JavaScript 的兩倍,代表從 WasmGC 初始版本起算,效能提升了 4 倍。
結論
WasmGC 是一項強大技術,可望推動開發人員建構網頁應用程式的方式。未來幾年內,Google 希望能看到 WasmGC 進一步支援共用記憶體多執行緒,並進一步改善單一執行緒效能。我們建議所有網頁程式開發人員考慮使用 WasmGC 推動下一個高效能專案。快來加入我們,讓網路世界變得更快、更順暢!
特別銘謝