WebAssembly và WebGPU khác nhau ở đâu: cái nào lo phần nghĩ, cái nào lo phần vẽ

WebAssembly và WebGPU thường được nhắc cùng nhau như hai “vũ khí” giúp trình duyệt chạy được những thứ nặng ngang ứng dụng cài đặt. Nghe tên thì giống, nhưng chúng giải hai bài toán khác hẳn nhau: một cái làm cho bộ xử lý chính tính nhanh hơn, cái kia mở cửa cho trang web ra lệnh thẳng cho card đồ hoạ. Bài này tách bạch hai thứ đó, nói rõ khi nào đáng dùng, khi nào không — và vì sao năm ứng dụng hiện tại của AppGiaiTri chưa dùng cái nào.

Hai bộ não trong một chiếc điện thoại

Để hiểu sự khác nhau, cần hình dung điện thoại có hai loại “bộ não”:

• Bộ xử lý chính: vài lõi rất thông minh, làm được mọi loại việc, xử lý từng chuỗi việc nối tiếp nhau. Giống một nhóm nhỏ kỹ sư giỏi.
• Card đồ hoạ: hàng trăm tới hàng nghìn lõi đơn giản, mỗi lõi chỉ làm phép tính nhỏ nhưng tất cả làm cùng lúc. Giống một đội công nhân đông đảo, mỗi người tô đúng một viên gạch.

Tô màu cho ba triệu điểm ảnh là việc của đội công nhân: mỗi điểm ảnh tính độc lập, càng đông người càng nhanh. Tính đường bay của một quả bóng có xoáy, va lưới, nảy sân là việc của nhóm kỹ sư: bước sau phụ thuộc bước trước, đông người cũng không giúp gì. Giữ hình ảnh này trong đầu, phần còn lại sẽ dễ hiểu.

WebAssembly: cho bộ xử lý chính chạy mã “đã dịch sẵn”

Mã của trang web truyền thống viết bằng JavaScript. Trình duyệt nhận mã ở dạng chữ, vừa chạy vừa phân tích xem nên dịch nó sang lệnh máy thế nào cho nhanh. Những bộ dịch này ngày nay giỏi đến kinh ngạc, nhưng vẫn phải đoán: một biến lúc thì chứa số, lúc thì chứa chữ, bộ dịch phải dè chừng.

WebAssembly (thường viết tắt Wasm) là một định dạng mã đã được dịch gần tới mức lệnh máy trước khi tới tay trình duyệt. Người làm viết bằng những ngôn ngữ như C, C++ hay Rust, dịch sang WebAssembly, rồi trình duyệt chỉ việc chuyển nốt bước cuối. Mọi trình duyệt lớn đã hỗ trợ từ năm 2017, nên gần như máy nào đang dùng cũng chạy được.

WebAssembly mạnh ở đâu

• Tính toán nặng, đều đặn, lặp đi lặp lại: mô phỏng vật lý với hàng trăm vật va chạm, giải mã âm thanh hay hình ảnh, nén dữ liệu, tìm đường cho nhiều nhân vật cùng lúc.
• Mang sẵn một thư viện lâu năm lên web: một bộ mô phỏng vật lý hay bộ giải mã đã được viết và mài giũa hàng chục năm bằng C++ có thể dịch sang WebAssembly thay vì viết lại từ đầu. Đây thường là lý do thật sự người ta dùng nó, hơn cả tốc độ.
• Tốc độ ổn định: không có những khoảng khựng khi bộ dịch đổi ý hay khi trình duyệt dọn bộ nhớ, vì mã WebAssembly thường tự quản bộ nhớ của mình.

Những cái giá ít được nói tới

• Dung lượng tải. Một thư viện vật lý dịch sang WebAssembly dễ nặng vài trăm kilobyte tới vài megabyte. So với toàn bộ mã của một ứng dụng AppGiaiTri hiện nay, đó có thể là gấp nhiều lần.
• Chi phí qua cầu. Mã WebAssembly không tự vẽ, không tự đọc thao tác chạm. Mỗi lần cần thì phải gọi sang JavaScript và ngược lại. Gọi qua lại vài lần mỗi khung hình thì không sao; gọi hàng nghìn lần thì cái lợi về tốc độ bị ăn mất.
• Sửa lỗi khó hơn. Lỗi trong mã đã dịch khó lần hơn lỗi trong mã chữ đọc được ngay trên trình duyệt.
• Không làm vẽ nhanh hơn. Đây là hiểu lầm phổ biến nhất. Nếu ứng dụng chậm vì phải tô quá nhiều điểm ảnh, chuyển sang WebAssembly không giúp gì: việc tô vẫn là của card đồ hoạ.

WebGPU: nói chuyện thẳng với đội công nhân

Từ lâu trang web đã dùng được card đồ hoạ qua WebGL — một chuẩn dựa trên thư viện đồ hoạ từ những năm 1990. Nó chạy được, nhưng cách ra lệnh đã cũ: mỗi lệnh vẽ tốn nhiều công kiểm tra, khó điều phối hàng nghìn vật thể, và gần như chỉ dùng để vẽ.

WebGPU là thế hệ kế tiếp, thiết kế theo cách các card đồ hoạ hiện đại thực sự làm việc. Chrome trên máy tính bật nó từ năm 2023, Chrome trên Android từ đầu 2024, và Safari theo sau ở các bản ra năm 2025. Hai điều nó mang lại:

1. Vẽ nhiều hơn với ít công điều phối hơn. Chuẩn bị sẵn “công thức vẽ” một lần, rồi gửi hàng loạt vật thể theo công thức đó. Một cảnh có hàng nghìn ngọn cỏ, hàng trăm chiếc xe trở nên khả thi trên điện thoại.
2. Tính toán chung trên card đồ hoạ. Đây là điểm mới thật sự: đội công nhân không chỉ tô màu mà còn làm phép tính bất kỳ, miễn là chia được thành nhiều việc nhỏ độc lập — hàng chục nghìn hạt khói, mô phỏng mặt nước, thậm chí chạy mô hình trí tuệ nhân tạo ngay trên máy.

Cái giá của WebGPU

• Không phải máy nào cũng có. Điện thoại cũ, trình duyệt cũ, card đồ hoạ trong danh sách đen của trình duyệt — tất cả đều không có WebGPU. Ứng dụng nghiêm túc phải có đường lui (thường là WebGL), tức là viết phần vẽ hai lần.
• Nhiều mã hơn hẳn. Vẽ một hình tròn bằng canvas hai chiều là một dòng. Bằng WebGPU là cả một trang thiết lập trước khi thấy được điểm ảnh đầu tiên.
• Máy nóng nhanh hơn nếu lạm dụng. Khả năng vẽ nhiều không có nghĩa là nên vẽ nhiều. Trên điện thoại, pin và nhiệt độ là trần thật sự.

Đặt cạnh nhau

Hai thứ không loại trừ nhau, và thường đi cùng nhau: phần tính toán vật lý và logic viết bằng C++ dịch sang WebAssembly, phần vẽ gửi qua WebGPU hoặc WebGL. Phần lớn các bộ công cụ làm ứng dụng giải trí ba chiều lớn khi xuất ra web đều làm theo đúng kiểu đó — và cũng vì thế mà bản web của chúng thường nặng hàng chục megabyte.

Vì sao AppGiaiTri hiện chưa dùng cái nào

Nói thẳng: cả năm ứng dụng hiện tại — Giao Đấu, Rượt Đuổi, Chiến Đấu, Không Chiến, Chinh Chiến — đều viết bằng JavaScript thuần và vẽ bằng canvas hai chiều. Không phải vì chưa biết, mà vì đo thấy chưa cần:

• Phần tính toán nhỏ. Một quả bóng, hai người chơi, vài chục hạt hiệu ứng. Ngay cả khi đối thủ máy mô phỏng trước đường bay của bóng — tính hàng trăm bước vật lý trong một khung hình — JavaScript vẫn làm xong trong một phần rất nhỏ của ngân sách khung hình. Chuyển sang WebAssembly sẽ thêm dung lượng tải và độ phức tạp để tiết kiệm một thứ vốn không phải là chỗ nghẽn.
• Chỗ nghẽn thật là số điểm ảnh. Và chỗ đó đã được xử lý bằng ngân sách điểm ảnh trong lõi vẽ, không cần đổi công nghệ.
• Mở nhanh quan trọng hơn đẹp hơn. Trải nghiệm phiên ngắn sống nhờ việc bấm là chạy. Mỗi megabyte thêm vào là thêm vài giây chờ trên mạng yếu.
• Chạy được trên máy cũ. Canvas hai chiều có ở mọi trình duyệt; không cần viết đường lui.

Khi nào sẽ đổi? Khi một ứng dụng cần thứ mà canvas hai chiều không kham nổi — cảnh ba chiều thật sự, hàng nghìn vật thể, ánh sáng động. Lúc đó WebGPU (với đường lui WebGL) là lựa chọn tự nhiên. WebAssembly thì chỉ vào cuộc khi có một khối tính toán nặng đo được là chỗ nghẽn, hoặc khi có một thư viện sẵn đáng mang lên. Nguyên tắc chung của chúng tôi: đo trước, đổi sau. Công nghệ mới đáng giá khi nó giải đúng cái đang làm chậm, không phải vì nó mới.