Google Trang tính là một trong những sản phẩm đầu tiên của Google sử dụng WasmGC trên Chrome. Quyết định này được công bố vào năm 2022 và các nhóm Trang tính và Chrome đã hợp tác về việc chuẩn hoá, kỹ thuật và công cụ để cung cấp ý kiến phản hồi theo thời gian thực về việc tối ưu hoá. Quan hệ đối tác này đã đặt ra tiền lệ cho cách các nhóm kỹ sư tại Google có thể làm việc hiệu quả với Chrome để có nhiều ứng dụng Google hơn chạy trên WasmGC.
Thách thức: JavaScript
Công cụ tính toán của Google Trang tính ban đầu được viết bằng Java và ra mắt vào năm 2006. Trong những ngày đầu của sản phẩm, tất cả các phép tính đều diễn ra trên máy chủ. Tuy nhiên, kể từ năm 2013, công cụ này đã chạy trong trình duyệt bằng JavaScript. Ban đầu, việc này được thực hiện thông qua Google Web Toolkit (GWT) và sau đó là thông qua trình biên dịch chuyển đổi Java sang JavaScript Closure (J2CL). Công cụ tính toán JavaScript chạy trong một Trình chạy web và giao tiếp với luồng chính bằng MessageChannel.
Việc di chuyển người dùng từ máy chủ sang phiên bản JavaScript của công cụ tính toán (và sau đó từ GWT sang J2CL) là một công việc lớn đòi hỏi phải xác thực cẩn thận. Để đảm bảo rằng công cụ tính toán JavaScript tạo ra kết quả chính xác giống như phiên bản Java, nhóm Trang tính đã phát triển một cơ chế xác thực nội bộ. Cơ chế này có thể xử lý một lượng lớn trang tính và xác thực rằng kết quả giống nhau giữa nhiều phiên bản của công cụ tính toán. Nhóm Trang tính thường xuyên sử dụng công cụ này để xác thực các thay đổi đối với Trang tính. Nhưng nhóm nghiên cứu không chỉ so sánh kết quả của những phép tính đó mà còn so sánh hiệu suất giữa JavaScript trên máy khách và Java trên máy chủ. Họ nhận thấy rằng phiên bản JavaScript của công cụ tính toán chậm hơn phiên bản Java hơn ba lần.
Tại sao JavaScript chậm hơn Java?
JavaScript là một ngôn ngữ động, có kiểu dữ liệu lỏng lẻo và nhanh chóng. Việc đầu tư mạnh vào các trình biên dịch đúng thời điểm (JIT) (ví dụ: Maglev, Sparkplug và Turbofan) trong 15 năm qua đã giúp tăng hiệu suất của JavaScript. Tuy nhiên, các loại lỏng và hành vi động của JavaScript khiến trình biên dịch JIT gặp khó khăn trong việc tạo mã tối ưu. Điều này có nghĩa là JavaScript vẫn thua kém các ngôn ngữ như Java và C++ về thông lượng thô. TypeScript thêm tính năng an toàn về kiểu vào JavaScript, nhưng thông tin kiểu đó được thiết kế để giúp quá trình phát triển dễ dàng hơn, chứ không phải để cung cấp các loại đảm bảo mà trình biên dịch cần để tạo mã tối ưu. Đối với các trường hợp như Google Trang tính, trong đó các bảng tính lớn có thể mất hàng chục giây để tính toán, JavaScript tuy nhanh nhưng chưa đủ nhanh.
Giải pháp: WasmGC
WasmGC là một tiện ích cho quy cách WebAssembly hiện có, thêm các nguyên hàm cần thiết để biên dịch các ngôn ngữ thu gom rác (chẳng hạn như Java). Ví dụ: WasmGC thêm hướng dẫn để xác định các loại và phân bổ cấu trúc dữ liệu được thu gom rác. WasmGC sắp thực hiện cho các ngôn ngữ thu gom rác những gì Wasm đã làm cho C++ (ví dụ: Photoshop hoặc Google Earth), đó là đưa các ngôn ngữ này lên web ở tốc độ gần như gốc. Tại Google, chúng tôi tin rằng WasmGC có tiềm năng tác động lớn hơn cả Wasm do sự phổ biến của các ngôn ngữ thu gom rác.
Google Workspace hợp tác với Chrome
Thông số kỹ thuật dự thảo MVP của WasmGC được phát hành vào năm 2019. Vào cuối năm 2020, Google Workspace và Chrome đã hợp tác để đánh giá WasmGC bằng công cụ tính toán của Trang tính. Nhóm đa nền tảng của Workspace có chuyên môn đáng kể trong việc xây dựng và tối ưu hoá trình biên dịch cũng như trình chuyển đổi mã. Trang tính, một phần của Workspace, được xác định là ứng cử viên lý tưởng để đánh giá WasmGC: ứng dụng này nhạy cảm với hiệu suất và có hiệu suất mạnh mẽ cũng như cơ chế xác thực tính chính xác. Chrome có nhóm V8 để xây dựng và tối ưu hoá thời gian chạy WasmGC cũng như những người đóng góp cho Binaryen để xây dựng các tính năng tối ưu hoá trước thời gian (AOT). Chrome và Workspace có tất cả kiến thức chuyên môn cần thiết để xây dựng và tối ưu hoá chuỗi công cụ WasmGC, với Google Trang tính là nền tảng thử nghiệm lý tưởng.
Nguyên mẫu đầu tiên
Vào giữa năm 2021, các nhóm đã có một trình biên dịch Java sang WasmGC đang hoạt động. Vào cuối năm đó, họ đã có một phiên bản nguyên mẫu của Google Trang tính chạy dưới dạng WasmGC và thực hiện các phép tính. Trên hành trình đó, họ gặp phải nhiều thách thức. Không có công cụ để lập hồ sơ và lấy tệp báo lỗi. Bạn phải tạo công cụ này. Phương thức triển khai hiện tại dựa vào nhiều thư viện JavaScript mà bạn phải tìm hoặc viết các thư viện thay thế cho WasmGC. Việc xác thực tính chính xác của công cụ tính toán Wasm là một công việc tốn thời gian do bản chất thử nghiệm của thông số kỹ thuật, trình biên dịch và thư viện mới. Tuy nhiên, các cơ chế xác thực của Trang tính lại một lần nữa cực kỳ hữu ích. Cuối cùng, các nhóm đã khắc phục được vấn đề và dữ liệu hiệu suất bắt đầu xuất hiện vào đầu năm 2022.
Các phương pháp tối ưu hoá khác
Phiên bản ban đầu của Sheets Wasm cho thấy hiệu suất tính toán chậm hơn JavaScript khoảng hai lần. Tuy nhiên, đây không phải là kết quả tệ đối với một thông số kỹ thuật mới, trình biên dịch mới và một số thư viện mới. Từ thời điểm này, nhóm Trang tính bắt đầu tối ưu hoá. Trong số các phương pháp tối ưu hoá mà họ tìm thấy, có một vài danh mục nổi bật:
- Sao chép các tính năng tối ưu hoá cốt lõi đã tồn tại trong Máy ảo Java (JVM) và trong V8.
- Sử dụng các API trình duyệt được tối ưu hoá cao.
- Xoá các mẫu lập trình dành riêng cho JavaScript.
Trước tiên, nhóm Trang tính cần sao chép các hoạt động tối ưu hoá đã có trong các chuỗi công cụ khác. Ví dụ điển hình nhất về điều này là việc tối ưu hoá chuyển phát phương thức ảo. JVM và V8 đã tối ưu hoá tính năng này từ lâu, nhưng không có gì tồn tại cho WasmGC. Việc triển khai nội tuyến suy đoán và giải mã – hai phương pháp tối ưu hoá rất phổ biến – đã giúp tăng tốc thời gian tính toán lên khoảng 40% trong Chrome.
Thứ hai, có những trường hợp API trình duyệt được hỗ trợ bởi các phương thức triển khai gốc được tối ưu hoá, khó cạnh tranh với việc sử dụng Wasm. Chuỗi và biểu thức chính quy là hai ví dụ điển hình. Cụ thể, với biểu thức chính quy, nhóm nghiên cứu nhận thấy tốc độ các thao tác biểu thức chính quy tăng gần 100 lần khi chuyển từ re2j (biên dịch sang WasmGC) sang API trình duyệt RegExp trong Chrome. API này có thể biên dịch từng biểu thức chính quy thành mã máy riêng.
Cuối cùng, họ nhận thấy rằng việc tối ưu hoá trong nhiều năm đã khiến cơ sở mã trở nên quá phù hợp với JavaScript. Ví dụ: họ có một cấu trúc dữ liệu cốt lõi trong Trang tính làm mờ ranh giới giữa các mảng và bản đồ. Cách này hiệu quả trong JavaScript, tự động mô hình hoá các mảng thưa thớt dưới dạng bản đồ, nhưng lại chậm trên các nền tảng khác. Vì vậy, họ phải viết lại mã theo cách không phụ thuộc vào nền tảng. Đây là một điểm khác mà nhóm chúng tôi thích về WebAssembly: công nghệ này giúp các ứng dụng đa nền tảng dễ dàng đạt được hiệu suất tốt trên web. Bạn không cần phải điều chỉnh toàn bộ ứng dụng theo đặc điểm riêng của JavaScript.
Kết quả cuối cùng
Sau tất cả các hoạt động tối ưu hoá này, phiên bản WasmGC cuối cùng của Trang tính đạt được hiệu suất tính toán nhanh gấp đôi so với JavaScript, tức là cải thiện gấp 4 lần so với điểm xuất phát của phiên bản WasmGC ban đầu.
Kết luận
WasmGC là một công nghệ mạnh mẽ có tiềm năng cải tiến cách nhà phát triển xây dựng ứng dụng web. Trong những năm tới, tại Google, chúng tôi hy vọng WasmGC sẽ phát triển để hỗ trợ đa luồng bộ nhớ dùng chung và cải thiện hơn nữa hiệu suất của luồng đơn. Tất cả nhà phát triển web đều nên cân nhắc sử dụng WasmGC cho dự án hiệu suất cao tiếp theo của họ. Hãy cùng chúng tôi biến web trở thành một nơi nhanh chóng và mượt mà hơn!
Lời cảm ơn
Cảm ơn những người đã làm việc trong quá trình triển khai WasmGC và nghiên cứu điển hình này: Diwas Adhikary, Matthew Albright, Ksenia Bukina, Julien Dramaix, Asim Fazal, Michael Frederick, Goktug Gokdogan, Janice Gu, Adam Klein, Manos Koukoutos, Jakob Kummerow, Matthias Liedtke, Thomas Lively, Roberto Lublinerman, Vishrut Mehta, Thomas Nattestad, Josh Pearlstein, Joaquim Perotti, Chris Ruenes, Steven Saviano, Derek Schuff, Tim Sears, Michael Thomas, Yuan Tian, Philipp Weis, Mason Wu, Alon Zakai và Emanuel Ziegler.