🔧 阿川の電商水電行
多年來，JavaScript一直是Web的主要語言。它的流行程度可能甚至讓它的創造者Brendan Eich都感到驚訝，據說他只花了一周左右的時間就建置了該語言的第一個版本。
JavaScript之所以能佔據主導地位，其中一個重要原因在於瀏覽器的強大功能。我們只需透過瀏覽器這個應用程式，就能存取數億個網站和應用程式，無需下載或安裝任何軟體。這正是其成功的關鍵。
瀏覽器廠商一直不遺餘力地提升 JavaScript 的速度。現代引擎已經過高度優化。但仍存在一個根本性的限制：
JavaScript 在 CPU 上運作。
那麼，哪些任務最適合用GPU來完成呢？
這就是WebGPU 的用武之地。 🚀
讓我們來看看它實際上能做什麼——以及什麼時候使用它才真正有意義。
順便一提——我的jsDay演講越來越近了！我將在會議上談論WebGPU + WebAssembly ，這正是你在本文中看到的那些內容：瀏覽器中的 GPU、計算著色器，以及將 Web 技術推向比以往更遠的地方。
為了慶祝（也可能是為了稍微緩解我會前的緊張情緒😅），我錄製了一個演講的宣傳短片，你可以在這裡找到。
如果你願意觀看並點個贊，我將不勝感激。
如果你也來參加jsDay ，演講結束後記得來打個招呼！ 🙂
開始之前有簡短的說明
我已經在另一篇文章中介紹過 WebGPU，所以這裡就不再贅述了：
但我們先簡單回顧一下一件重要的事情。
WebGPU 不僅僅是圖形處理——儘管它的圖形處理能力非常出色。
它也賦予我們一些極其強大的東西：
存取GPU運算資源。
CPU 與 GPU（快速回顧）
這一點對你們大多數人來說顯而易見，但我們還是為初學者和那些大學第一學期都在睡覺的人做一個簡單的區分：
CPU非常擅長連續執行幾個複雜的任務。
在瀏覽器中，這通常意味著JavaScript 或 WebAssembly 。
GPU非常擅長大規模並行執行簡單的任務。
在瀏覽器中，允許我們使用它們的 API 是WebGPU 。
這就是為什麼 GPU 非常擅長執行需要重複數千次或數百萬次相同操作的任務。
我想親自測試一下。
如果你經常看我的帖子，你可能知道我不喜歡盲目相信別人，我更喜歡親身嘗試。 🙂
所以我開發了一個小型應用程式，用於測試JavaScript 與 WebGPU 的效能。
這些並非那種在不同系統中逐行實現完全相同演算法的超學術性基準測試。多虧了它們，我可能拿不到麻省理工的博士學位。 😅
相反，我嘗試了一種更實際的方法：
我測試了兩種技術在以各自的自然方式解決相同問題時的表現，並沒有刻意偏袒任何一種技術。
您可以在這裡探索所有內容：
GitHub 倉庫
https://github.com/sylwia-lask/webgpu-bench
線上示範
https://sylwia-lask.github.io/webgpu-bench/
歡迎您親自體驗。 😄
場景 1 — 粒子模擬
第一個測試是粒子模擬。
如果你在網路上閱讀有關 WebGPU 的內容——或詢問 ChatGPT——這通常會被視為 GPU 優越性的經典範例。
每個粒子都具有兩個屬性：
-
位置
(x, y) -
速度
(vx, vy)
每一幀我們都這樣更新：
x = x + vx
y = y + vy如果粒子撞到螢幕邊緣，我們就會反轉速度來模擬反彈。
虛擬程式碼:
for each particle:
pos += vel
if pos.x < 0 or pos.x > width:
vel.x = -vel.x
if pos.y < 0 or pos.y > height:
vel.y = -vel.y因此，計算著色器實際上執行類似以下的操作：
pos += vel這基本上是每個粒子進行兩次浮點數加法運算（加上一次反彈檢查）。
結果
令人驚訝的是…JavaScript 和 WebGPU 實作之間幾乎沒有區別。兩個版本產生的幀率非常相似。
同時，WebGPU 版本需要編寫更多的樣板程式碼。
為什麼會發生這種情況？
1️⃣ 演算法極為簡單
粒子更新每個執行緒僅執行 2-4 次浮點運算。
GPU 在運算密集型任務中才能真正發揮優勢，而不是在這個輕量級任務中。
2️⃣ Canvas 2D 最終也會在 GPU 上處理
這是很多前端開發人員沒有意識到的。
即使使用Canvas 2D ，瀏覽器通常也會使用 GPU 加速進行渲染。
Chrome 或 Edge 等瀏覽器內部使用Skia或Dawn等系統，最終向 GPU 發出繪圖呼叫。
因此，在實踐中：
-
WebGPU → 直接與 GPU 通訊
-
Canvas 2D → 瀏覽器會自動與 GPU 通訊
瀏覽器針對fillRect()等函數進行了非常好的最佳化。
所以 CPU 版本並不像人們通常認為的那樣「僅限 CPU 使用」。
GPU能否勝出？
或許可以——但前提是我們得讓模擬變得更複雜。
例如，像n體引力這樣的問題，其中每個粒子都吸引其他所有粒子。這將大大增加數學運算量。
但說實話……我太懶了，沒去實現。 😅
情境 2 — 矩陣乘法
現在讓我們來看看GPU最喜歡的東西。
矩陣乘法。
儘管名字聽起來嚇人，但原理很簡單。想像兩個數字格。要計算結果矩陣中的一個單元格：
-
我們從第一個矩陣中取出一行。
-
第二個矩陣中的一列
-
成對乘數
-
將結果相加。
例子：
[1 2] [5 6]
[3 4] × [7 8]計算左上角單元格：
1×5 + 2×7 = 19對結果矩陣中的每個單元格，必須重複此操作。
對於大型矩陣，這很快就會變成數百萬次的乘法運算。
這正是GPU設計之初就旨在處理的那種工作負載。
結果
結果非常明確。
WebGPU 完全碾壓 JavaScript。
矩陣越大，這種差異就越大。
這完全合情合理：
矩陣乘法本質上是同一個簡單操作重複數千次或數百萬次——這正是 GPU 大顯身手的場景。
別忘了，矩陣乘法是計算機科學中最重要的運算之一。矩陣乘法廣泛應用於：
-
電腦圖形
-
物理模擬
-
科學計算
-
當然還有…我們摯愛的LLMs們🤖
場景 3 — 影像處理流程
第三個基準測試更接近傳統的圖形工作：影像處理流程。
在這裡，GPU 再次完全壓制了CPU 的實作。
這種工作負載非常適合GPU：
-
每個像素都可以獨立處理。
-
同樣的操作可以應用於成千上萬個像素。
這與 GPU 執行模型完美契合。
那我們應該用 WebGPU 取代 JavaScript 嗎？
當然不是。 🙂
WebGPU 功能強大，但它只適用於某些類型的問題。一般來說，WebGPU 在以下情況下表現出色：
-
執行許多簡單的操作
-
大量資料
-
並聯
對於常規應用程式邏輯，JavaScript 仍然是完美的工具。
仍然存在一些實際限制
WebGPU也是一項相對較新的技術。
如果你能控制環境，並且可以要求使用者執行現代瀏覽器，那麼你完全可以開始進行相關實驗。
但是，如果你要為廣大用戶群開發應用程式——例如有人可能會在 2018 年的某個奇怪的 Android 瀏覽器中開啟你的應用程式——那你最好還是謹慎一些。
或實作備用方案，例如使用 WebGL。
樣板問題
如果你查看程式碼庫，你會發現 WebGPU 需要相當多的設定。
你需要：
-
請求適配器
-
請求設備
-
建立緩衝區
-
配置管道
-
管理命令編碼器
-
等等。
有很多重複的模板內容。
是的，像 Claude 或 ChatGPT 這樣的編碼代理可以提供協助。
但這裡有個小提醒⚠️
WebGPU 仍處於發展初期， LLM（語言邏輯模型）在產生正確的 WebGPU 程式碼方面並不總是表現出色。有時，您仍然需要回歸傳統的開發工作流程：
-
閱讀文件
-
瀏覽 GitHub 問題
-
手動除錯
就像以前一樣。 😄
最後想說的話
問題不再是WebGPU是否會變得重要。
真正的問題是，我們什麼時候需要它。
因為 WebGPU 本質上是瀏覽器中使用 GPU 的一種新的、現代的標準。
對於GPU旨在解決的那類問題而言，它的效能極為強大。 🚀
1) --- 會變成分隔線（上一行必須是空白）
2) # 會變成一級標題
3) ## 會變成二級標題
4) ### 會變成三級標題
5) **粗體文字**會顯示粗體文字
6) ```當第一行與最後一行會顯示程式碼
7) 請搜尋 Markdown 語法，了解各種格式
