Lý do Google Trang tính chuyển trình chạy tính toán từ JavaScript sang WasmGC

Google Trang tính là một trong những sản phẩm đầu tiên tại Google sử dụng WasmGC trên Chrome. Quyết định này được công bố vào năm 2022, đồng thời nhóm Trang tính và nhóm 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á. Mối quan hệ đối tác này đã tạo tiền lệ về cách các nhóm kỹ thuật 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ử thách: 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 ra mắt sản phẩm, mọi hoạt động tính toán đều diễn ra trên máy chủ. Tuy nhiên, 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 đó thông qua trình chuyển đổi mã nguồn từ Java sang JavaScript Closure (J2CL). Công cụ tính toán JavaScript chạy trong một Web Worker và giao tiếp với luồng chính bằng cách sử dụ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 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ả hoàn toàn giống như phiên bản Java, nhóm Sheets đã 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 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 phiên bản JavaScript của công cụ tính toán chậm hơn gấp 3 lần so với phiên bản Java.

Tại sao JavaScript chậm hơn Java?

JavaScript có tốc độ nhanh đối với một ngôn ngữ động, được nhập lỏng lẻo. Việc đầu tư mạnh mẽ vào các trình biên dịch tức thời (JIT) (ví dụ: Maglev, SparkplugTurbofan) trong 15 năm qua đã giúp tăng hiệu suất của JavaScript. Tuy nhiên, các kiểu lỏng lẻo và hành vi động của JavaScript khiến trình biên dịch JIT khó tạo ra mã tối ưu. Điều này có nghĩa là JavaScript vẫn tụt hậu so với các ngôn ngữ như Java và C++ về thông lượng thô. TypeScript bổ sung tính năng an toàn về kiểu cho JavaScript, nhưng thông tin về kiểu đó được thiết kế để giúp quá trình phát triển dễ dàng hơn, chứ không 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, nơi các bảng tính lớn có thể mất hàng chục giây để tính toán, JavaScript có tốc độ 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ó, giúp bổ sung các thành phần cơ bản cần thiết để biên dịch các ngôn ngữ thu thập rác (chẳng hạn như Java). Ví dụ: WasmGC thêm các chỉ 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 được thiết kế để hỗ trợ các ngôn ngữ được thu gom rác như Wasm đã hỗ trợ C++ (ví dụ: Photoshop hoặc Google Earth), tức là đưa các ngôn ngữ này lên web với tốc độ gần như gốc. Tại Google, chúng tôi tin rằng WasmGC có tiềm năng mang lại tác động lớn hơn cả Wasm do sự phổ biến của các ngôn ngữ thu thập rác.

Google Workspace kết hợp với Chrome

Bản nháp đặc tả MVP WasmGC được xuất bản 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ách sử dụ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 và trình chuyển đổi mã nguồn. Sheets (một phần của Workspace) được xác định là ứng dụng lý tưởng để đánh giá WasmGC: ứng dụng này nhạy cảm với hiệu suất và có các cơ chế xác thực hiệu suất cũng như độ chính xác mạnh mẽ. Chrome có nhóm V8 để tạo và tối ưu hoá thời gian chạy WasmGC cũng như những người đóng góp cho Binaryen để tạo các hoạt động tối ưu hoá trước thời gian (AOT). Giữa Chrome và Workspace, có tất cả chuyên môn cần thiết để xây dựng và tối ưu hoá một chuỗi công cụ WasmGC, trong đó Google Trang tính là một môi trường thử nghiệm lý tưởng.

Nguyên mẫu đầu tiên

Đến giữa năm 2021, các nhóm đã có một trình biên dịch Java sang WasmGC 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. Trong quá trình này, họ gặp phải nhiều thách thức. Chưa có công cụ để lập hồ sơ và lấy kết xuất heap nên chúng tôi phải tự xây dựng. Quy trình 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 việc tốn nhiều thời gian do tính chất thử nghiệm của quy cách, trình biên dịch và các thư viện mới. Nhưng cơ chế xác thực của Trang tính một lần nữa lại cực kỳ hữu ích. Cuối cùng, các nhóm đã giải quyết được mọi 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 điểm 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 khoảng hai lần so với JavaScript. Tuy nhiên, đây không phải là kết quả tệ đối với một quy cách 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 Sheets bắt đầu tối ưu hoá. Trong số những điểm tối ưu hoá mà họ tìm thấy, có một số danh mục nổi bật:

  • Sao chép các hoạt động tối ưu hoá cốt lõi đã có 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 mã hoá dành riêng cho JavaScript.

Trước tiên, nhóm Sheets cần sao chép những điểm 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á phương thức phân phối ảo. Phương thức này đã được JVM và V8 tối ưu hoá từ lâu, nhưng không có gì cho WasmGC. Việc triển khai nội tuyến suy đoánkhử ảo hoá (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 các API trình duyệt được hỗ trợ bằng các phương thức triển khai gốc được tối ưu hoá mà khó cạnh tranh bằ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 này nhận thấy tốc độ của các thao tác biểu thức chính quy tăng gần 100 lần khi chuyển từ re2j (được 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 nhiều năm tối ưu hoá đã khiến cơ sở mã được điều chỉnh quá mức cho 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 mảng và bản đồ. Điều 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 độc lập với nền tảng hơn. Đây là một điểm khác mà nhóm thích ở 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 của mình cho phù hợp với những đặc điểm riêng của JavaScript.

Kết quả cuối cùng

Sau tất cả những 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 hơn khoảng gấp đôi so với JavaScript, tức là cải thiện gấp 4 lần so với điểm bắt đầu của phiên bản WasmGC ban đầu.

Kết luận

WasmGC là một công nghệ mạnh mẽ có khả năng cải tiến cách nhà phát triển xây dựng các ứng dụng web. Trong những năm tới, tại Google, chúng tôi hy vọng WasmGC sẽ hỗ trợ đa luồng bộ nhớ dùng chung và cải thiện hơn nữa hiệu suất đơn luồng. Chúng tôi khuyến khích tất cả nhà phát triển web 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 tạo ra một môi trường web nhanh hơn và mượt mà hơn!

Lời cảm ơn

Cảm ơn những người đã tham gia 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.