Tại sao chúng ta vẫn làm GPU hoạt động trong JavaScript? (Bản demo và điểm chuẩn WebGPU trực tiếp🚀)
Why Are We Still Doing GPU Work in JavaScript? (Live WebGPU Benchmark & Demo🚀)
Ứng dụng web truyền thống chủ yếu dùng JavaScript trên CPU, không hiệu quả cho các tác vụ cần xử lý song song cao. WebGPU mở ra khả năng truy cập trực tiếp vào GPU, giúp tăng hiệu năng đáng kể cho các phép tính như mô phỏng hạt (particle simulations). Các developer nên cân nhắc dùng WebGPU cho những công việc nặng về tính toán, nơi xử lý song song trên quy mô lớn mang lại lợi ích, vì nó mở ra một cấp độ hiệu năng mới cho ứng dụng web.
JavaScript đã là ngôn ngữ chính của web trong nhiều năm. Sự phổ biến của nó có lẽ làm ngạc nhiên ngay cả người tạo ra nó, Brendan Eich, người nổi tiếng đã xây dựng phiên bản đầu tiên của ngôn ngữ này chỉ trong khoảng một tuần. Một trong...
JavaScript đã là ngôn ngữ chính của web trong nhiều năm. Sự phổ biến của nó có lẽ đã làm ngạc nhiên ngay cả người tạo ra nó, Brendan Eich, người nổi tiếng đã xây dựng phiên bản đầu tiên của ngôn ngữ này chỉ trong khoảng một tuần.
Một trong những lý do khiến JavaScript trở nên thống trị là sức mạnh tuyệt đối của trình duyệt. Từ một ứng dụng duy nhất — trình duyệt — chúng ta có thể truy cập hàng trăm triệu trang web và ứng dụng. Không cần phải tải xuống hoặc cài đặt bất cứ điều gì. Đó là một phần rất lớn của sự thành công.
Và các nhà cung cấp trình duyệt đang làm việc hết sức chăm chỉ để làm cho JavaScript ngày càng nhanh hơn. Động cơ hiện đại được tối ưu hóa cực kỳ tốt. Nhưng vẫn còn một hạn chế cơ bản:
JavaScript chạy trên CPU.
Vậy còn những tác vụ hoàn hảo cho GPU thì sao?
Đây là nơi WebGPU xuất hiện. 🚀
Chúng ta hãy xem nó thực sự có thể làm được những gì — và khi nào thì việc sử dụng nó thực sự có ý nghĩa.
Nhân tiện — buổi nói chuyện jsDay của tôi đang ngày càng gần hơn! Ở đó tôi sẽ nói về **WebGPU + WebAssembly, chính xác là những thứ bạn thấy trong bài viết này: GPU trong trình duyệt, bộ đổ bóng điện toán và đẩy web tiến xa hơn bình thường một chút.
Để ăn mừng điều đó (và có thể giúp tôi xoa dịu thần kinh trước hội nghị một chút 😅), tôi đã ghi lại một đoạn phim quảng cáo ngắn cho buổi nói chuyện mà bạn có thể tìm thấy tại đây
Nếu bạn muốn xem và cho một lượt thích thì tôi thực sự đánh giá cao.
Và nếu bạn sắp tham dự **jsDay, hãy đến chào sau buổi nói chuyện! 🙂
Lưu ý nhanh trước khi chúng tôi bắt đầu
Tôi đã viết về WebGPU trong một bài viết khác nên tôi sẽ không lặp lại phần giới thiệu đầy đủ ở đây:
Tại sao WebGPU được cho là tương lai của Web (Bản demo trực tiếp)
Nhưng hãy tóm tắt ngắn gọn một điều quan trọng.
WebGPU không chỉ có đồ họa — mặc dù nó hoạt động rất đẹp.
Nó cũng mang lại cho chúng ta thứ gì đó vô cùng mạnh mẽ:
quyền truy cập vào điện toán GPU.
CPU và GPU (Nhắc nhở nhanh)
Điều này sẽ hiển nhiên đối với hầu hết các bạn, nhưng hãy phân biệt nhanh giữa người mới bắt đầu và những người đã ngủ quên trong học kỳ đầu tiên ở trường đại học:
CPU có khả năng thực hiện lần lượt một số công việc phức tạp rất tốt.
Trong trình duyệt, điều đó thường có nghĩa là JavaScript hoặc WebAssugging.
GPU thực hiện rất tốt những việc đơn giản song song trên diện rộng.
Và trong trình duyệt, API cho phép chúng ta sử dụng chúng là WebGPU.
Đó là lý do tại sao GPU thực hiện rất tốt các tác vụ mà cùng một thao tác cần được lặp lại hàng nghìn hoặc hàng triệu lần.
Tôi muốn tự mình kiểm tra nó
Nếu bạn đọc bài viết của tôi thường xuyên, có thể bạn biết tôi không thích tin vào mọi thứ. Tôi thích thử bản thân mình hơn. 🙂
Vì vậy, tôi đã xây dựng một ứng dụng nhỏ đánh giá JavaScript và WebGPU.
Đây không phải là những điểm chuẩn mang tính học thuật cao trong đó cùng một thuật toán được triển khai theo từng dòng trong các hệ thống khác nhau. Có lẽ tôi đã không nhận được bằng tiến sĩ từ MIT nhờ họ. 😅
Thay vào đó, tôi đã thử một cách thiết thực hơn:
Tôi đã thử nghiệm cách hoạt động của cả hai công nghệ khi chúng giải quyết cùng một vấn đề theo cách tự nhiên đối với chúng mà không cố ý thiên vị một trong hai.
Bạn có thể khám phá mọi thứ ở đây:
Kho lưu trữ GitHub
https://github.com/sylwia-lask/webgpu-bench
Bản trình diễn trực tiếp
https://sylwia-lask.github.io/webgpu-bench/
Hãy thoải mái chơi với nó. 😄
Kịch bản 1 - Mô phỏng hạt
Thử nghiệm đầu tiên là mô phỏng hạt.
Nếu bạn đọc trực tuyến về WebGPU — hoặc hỏi ChatGPT — thì đây thường được coi là một ví dụ điển hình về tính ưu việt của GPU.
Mỗi hạt có hai thuộc tính:
- vị trí
(x, y) - vận tốc
(vx, vy)
Mỗi khung hình chúng tôi cập nhật như thế này:
x = x + vx
y = y + vy
Và nếu hạt chạm vào viền màn hình, chúng tôi sẽ đảo ngược vận tốc để mô phỏng lực nảy.
Mã giả:
cho mỗi hạt:
pos += vel
if pos.x < 0 hoặc pos.x > chiều rộng:
vel.x = -vel.x
if pos.y < 0 hoặc pos.y > chiều cao: vel.y = -vel.y
Vì vậy, trình đổ bóng điện toán thực hiện một cách hiệu quả những việc như:
pos += vel
Về cơ bản, đó là hai phần bổ sung nổi cho mỗi hạt (cộng với kiểm tra số lần thoát).
kết quả
Đáng ngạc nhiên là… hầu như không có sự khác biệt giữa việc triển khai JavaScript và WebGPU. Cả hai phiên bản đều tạo ra FPS rất giống nhau.
Trong khi đó, phiên bản WebGPU yêu cầu nhiều mã nguyên mẫu hơn.
Tại sao điều đó lại xảy ra?
1️⃣ Thuật toán cực kỳ đơn giản
Bản cập nhật hạt chỉ thực hiện 2–4 thao tác dấu phẩy động trên mỗi luồng.
GPU thực sự tỏa sáng khi công việc nặng tính toán chứ không phải khi công việc nhẹ như thế này.
2️⃣ Canvas 2D cũng xuất hiện trên GPU
Đây là điều mà nhiều nhà phát triển giao diện người dùng không nhận ra.
Ngay cả khi bạn sử dụng Canvas 2D, trình duyệt vẫn thường hiển thị nó bằng cách sử dụng khả năng tăng tốc GPU.
Các trình duyệt như Chrome hoặc Edge sử dụng nội bộ các hệ thống như Skia hoặc Dawn, cuối cùng sẽ đưa ra lệnh gọi vẽ tới GPU.
Vậy trong thực tế:
- WebGPU → bạn nói chuyện trực tiếp với GPU
- Canvas 2D → trình duyệt giao tiếp với GPU cho bạn
Và trình duyệt này được tối ưu hóa rất tốt cho những thứ như fillRect().
Vì vậy, phiên bản CPU không phải là “chỉ dành cho CPU” như mọi người thường nghĩ.
GPU có thể giành chiến thắng ở đây không?
Có lẽ là có — nhưng chỉ khi chúng tôi thực hiện mô phỏng phức tạp hơn.
Ví dụ: một cái gì đó giống như trọng lực của n vật, trong đó mọi hạt đều hút mọi hạt khác. Điều đó sẽ làm tăng đáng kể số lượng môn toán.
Nhưng thành thật mà nói… tôi quá lười để thực hiện điều đó. 😅
Kịch bản 2 - Phép nhân ma trận
Bây giờ hãy xem thứ gì đó mà GPU thực sự yêu thích.
Nhân ma trận.
Mặc dù có cái tên đáng sợ nhưng ý tưởng lại rất đơn giản. Hãy tưởng tượng hai lưới số. Để tính một ô trong ma trận kết quả:
- chúng tôi lấy một hàng từ ma trận đầu tiên
- một cột từ ma trận thứ hai
- nhân các số theo cặp
- cộng các kết quả lại với nhau
Ví dụ:
[1 2] [5 6]
[3 4] × [7 8]
Để tính ô trên cùng bên trái:
1×5 + 2×7 = 19
Và thao tác này phải được lặp lại cho mọi ô trong ma trận kết quả.
Đối với ma trận lớn, điều đó nhanh chóng trở thành hàng triệu phép nhân.
Đó chính xác là loại khối lượng công việc mà GPU được thiết kế cho.
kết quả
Ở đây kết quả rất rõ ràng.
WebGPU hoàn toàn đè bẹp JavaScript.
Và ma trận càng lớn thì sự khác biệt càng lớn.
Điều này hoàn toàn hợp lý:
Nhân ma trận về cơ bản là cùng một thao tác đơn giản được lặp lại hàng nghìn hoặc hàng triệu lần — kịch bản chính xác mà GPU tỏa sáng.
Và hãy nhớ rằng đây là một trong những hoạt động quan trọng nhất trong khoa học máy tính. Phép nhân ma trận được sử dụng nhiều trong:
- đồ họa máy tính
- mô phỏng vật lý
- máy tính khoa học
- và tất nhiên… LLM yêu quý của chúng tôi 🤖
Kịch bản 3 - Đường ống xử lý hình ảnh
Tiêu chuẩn thứ ba đã kiểm tra một thứ gần giống với công việc đồ họa truyền thống hơn: quy trình xử lý hình ảnh.
GPU một lần nữa hoàn toàn thống trị việc triển khai CPU.
Loại khối lượng công việc này rất tự nhiên đối với GPU:
- mỗi pixel có thể được xử lý độc lập
- thao tác tương tự được áp dụng cho hàng nghìn hoặc hàng triệu pixel
Điều này một lần nữa lại phù hợp hoàn hảo với mô hình thực thi GPU.
Vậy chúng ta có nên thay thế JavaScript bằng WebGPU không?
Tất nhiên là không. 🙂
WebGPU rất mạnh mẽ — nhưng nó chỉ có ý nghĩa đối với một số loại vấn đề nhất định. Nói chung, WebGPU tỏa sáng khi bạn cần:
- thực hiện nhiều thao tác đơn giản
- trên lượng lớn dữ liệu
- song song
Đối với logic ứng dụng thông thường, JavaScript vẫn là công cụ hoàn hảo.
Vẫn còn một số hạn chế thực tế
WebGPU cũng vẫn là một công nghệ tương đối non trẻ.
Nếu bạn kiểm soát được môi trường và có thể yêu cầu người dùng chạy các trình duyệt hiện đại, bạn hoàn toàn có thể bắt đầu thử nghiệm nó.
Nhưng nếu bạn đang xây dựng thứ gì đó cho nhiều đối tượng — nơi ai đó có thể mở ứng dụng của bạn trong một trình duyệt Android lạ từ năm 2018 — thì có lẽ bạn nên cẩn thận.
Hoặc triển khai dự phòng, chẳng hạn như sử dụng WebGL.
Vấn đề nồi hơi
Nếu kiểm tra kho lưu trữ, bạn sẽ nhận thấy rằng WebGPU yêu cầu thiết lập khá nhiều.
Bạn cần:
- yêu cầu bộ chuyển đổi
- yêu cầu một thiết bị
- tạo bộ đệm
- định cấu hình đường ống
- quản lý bộ mã hóa lệnh
- v.v.
Có rất nhiều bản tóm tắt.
Có, các tác nhân mã hóa như Claude hoặc ChatGPT có thể trợ giúp việc này.
Nhưng đây là một cảnh báo nhỏ ⚠️
WebGPU vẫn còn mới và LLM không phải lúc nào cũng hiệu quả trong việc tạo mã WebGPU chính xác. Đôi khi, bạn vẫn cần quay lại quy trình làm việc cổ điển của nhà phát triển:
- đọc tài liệu
- duyệt tìm các vấn đề về GitHub
- gỡ lỗi mọi thứ theo cách thủ công
Giống như ngày xưa. 😄
suy nghĩ cuối cùng
Câu hỏi không còn là liệu WebGPU có trở nên quan trọng hay không.
Câu hỏi thực sự là chúng ta sẽ cần nó trong bao lâu.
Bởi vì WebGPU về cơ bản là một tiêu chuẩn mới, hiện đại để làm việc với GPU trong trình duyệt.
Và đối với những loại vấn đề mà GPU được thiết kế để giải quyết — GPU có thể cực kỳ mạnh mẽ. 🚀
Tác giả: Sylwia Laskowska