Alasan Google Spreadsheet mentransfer pekerja penghitungannya dari JavaScript ke WasmGC

Google Spreadsheet adalah salah satu produk pertama di Google yang menggunakan WasmGC di Chrome. Langkah ini diumumkan pada tahun 2022, dan tim Spreadsheet serta Chrome berpartner pada standardisasi, engineering, serta alat untuk memberikan masukan real-time terkait pengoptimalan. Kemitraan ini menjadi preseden bagaimana tim engineering di Google dapat bekerja sama secara efektif dengan Chrome untuk menjalankan lebih banyak aplikasi Google di WasmGC.

Tantangan: JavaScript

Mesin kalkulasi Google Spreadsheet awalnya ditulis dalam Java dan diluncurkan pada tahun 2006. Pada awal produk, semua penghitungan dilakukan di server. Namun, sejak tahun 2013, mesin telah berjalan di browser menggunakan JavaScript. Hal ini awalnya dilakukan melalui Google Web Toolkit (GWT), lalu melalui Java untuk Closure JavaScript transpiler (J2CL). Mesin kalkulasi JavaScript berjalan di Pekerja Web dan berkomunikasi dengan thread utama menggunakan MessageChannel.

Memigrasikan pengguna dari server ke versi JavaScript mesin kalkulasi (dan kemudian dari GWT ke J2CL) adalah tugas besar yang memerlukan validasi yang cermat. Untuk memastikan bahwa mesin kalkulasi JavaScript memberikan hasil yang sama persis dengan versi Java, tim Spreadsheet mengembangkan mekanisme validasi internal. Mekanisme ini dapat memproses korpus sheet yang besar dan memvalidasi bahwa hasilnya identik di antara beberapa versi mesin kalkulasi. Tim Spreadsheet menggunakan alat ini secara rutin untuk memvalidasi perubahan pada Spreadsheet. Namun, tim tidak hanya membandingkan hasil penghitungan tersebut, mereka juga membandingkan performa antara JavaScript pada klien dan Java di server. Mereka mendapati bahwa versi JavaScript mesin kalkulasi lebih dari tiga kali lebih lambat daripada versi Java.

Mengapa JavaScript lebih lambat daripada Java?

JavaScript sangat cepat untuk bahasa yang dinamis dan diketik secara longgar. Investasi besar dalam compiler tepat waktu (JIT) (misalnya, Maglev, Sparkplug, dan Turbofan) selama 15 tahun terakhir telah meningkatkan performa JavaScript. Namun, jenis longgar dan perilaku dinamis JavaScript mempersulit compiler JIT untuk menghasilkan kode yang optimal. Ini berarti JavaScript masih tertinggal di belakang bahasa seperti Java dan C++ untuk throughput mentah. TypeScript menambahkan keamanan jenis ke JavaScript, tetapi informasi jenis tersebut dirancang untuk mempermudah pengembangan, bukan untuk memberikan jaminan yang diperlukan oleh compiler untuk menghasilkan kode yang optimal. Untuk kasus seperti Google Sheets, ketika {i>spreadsheet<i} besar membutuhkan waktu puluhan detik untuk menghitung, JavaScript adalah hal yang cepat, tetapi tidak cukup cepat.

Solusi: WasmGC

WasmGC adalah ekstensi untuk spesifikasi WebAssembly yang ada yang menambahkan primitif yang diperlukan untuk mengompilasi bahasa yang dibersihkan sampah memori (seperti Java). Misalnya, WasmGC menambahkan instruksi untuk menentukan jenis dan mengalokasikan struktur data yang dikumpulkan sampah memori. WasmGC siap digunakan untuk bahasa pembersihan sampah memori seperti yang dilakukan Wasm untuk C++ (misalnya, Photoshop atau Google Earth), yaitu untuk membawanya ke web dengan kecepatan yang mendekati native. Di Google, kami percaya bahwa WasmGC berpotensi lebih berpengaruh daripada Wasm karena popularitas bahasa pembersihan sampah memori.

Google Workspace berpartner dengan Chrome

Spesifikasi draf MVP WasmGC dipublikasikan pada tahun 2019. Pada akhir tahun 2020, Google Workspace dan Chrome bekerja sama untuk mengevaluasi WasmGC menggunakan mesin penghitungan Spreadsheet. Tim multiplatform Workspace memiliki keahlian yang signifikan dalam membangun serta mengoptimalkan compiler dan transpiler. Spreadsheet, yang merupakan bagian dari Workspace, diidentifikasi sebagai kandidat ideal untuk mengevaluasi WasmGC: spreadsheet ini sensitif terhadap performa serta memiliki mekanisme validasi performa dan ketepatan yang tangguh. Chrome memiliki tim V8 untuk membangun dan mengoptimalkan runtime WasmGC serta berkontribusi pada Binaryen untuk membangun pengoptimalan ahead of time (AOT). Antara Chrome dan Workspace, ada semua keahlian yang diperlukan untuk membangun dan mengoptimalkan toolchain WasmGC, dengan Google Spreadsheet sebagai tempat pengujian yang ideal.

Prototipe pertama

Pada pertengahan 2021, tim sudah memiliki Java ke compiler WasmGC yang berfungsi. Menjelang akhir tahun yang sama, mereka menjalankan versi prototipe Google Spreadsheet yang berjalan sebagai WasmGC dan melakukan perhitungan. Dalam prosesnya, mereka menghadapi banyak tantangan. Alat untuk pembuatan profil dan pengambilan heap dump tidak ada dan harus dibangun. Implementasi yang ada mengandalkan banyak library JavaScript yang penggantinya harus ditemukan atau ditulis untuk WasmGC. Memvalidasi keakuratan mesin kalkulasi Wasm memerlukan upaya yang memakan waktu karena sifat eksperimental spesifikasi, compiler, dan library baru. Namun, mekanisme validasi Spreadsheet sekali lagi sangat membantu. Akhirnya, tim berhasil menyelesaikan semuanya, dan data performa mulai tersedia pada awal tahun 2022.

Pengoptimalan tambahan

Versi awal Sheets Wasm menunjukkan performa penghitungan sekitar dua kali lebih lambat daripada JavaScript. Namun, ini bukan hasil yang buruk untuk spesifikasi baru, compiler baru, dan beberapa library baru. Sejak saat itu, tim Spreadsheet mulai melakukan pengoptimalan. Dari pengoptimalan yang mereka temukan, beberapa kategori muncul:

  • Mereplikasi pengoptimalan inti yang sudah ada di Java Virtual Machine (JVM) dan V8.
  • Menggunakan API browser yang sangat dioptimalkan.
  • Menghapus pola coding khusus JavaScript.

Pertama, tim Spreadsheet perlu mereplikasi pengoptimalan yang sudah ada di toolchain lainnya. Contoh terbaiknya adalah mengoptimalkan pengiriman metode virtual, yang telah lama dioptimalkan oleh JVM dan V8, tetapi tidak ada apa pun untuk WasmGC. Menerapkan penyelarasan spekulatif dan devirtualisasi—dua pengoptimalan yang sangat umum—dapat mempercepat waktu penghitungan sekitar 40% di Chrome.

Kedua, ada kasus ketika API browser didukung oleh implementasi native yang dioptimalkan dan sulit bersaing dengan penggunaan Wasm. String dan ekspresi reguler adalah dua contoh yang baik. Secara khusus, dengan ekspresi reguler, tim melihat percepatan operasi ekspresi reguler hampir 100 kali lipat saat beralih dari re2j (dikompilasi ke WasmGC) ke API browser RegExp di Chrome, yang dapat mengompilasi setiap ekspresi reguler ke kode mesinnya sendiri.

Terakhir, mereka menemukan bahwa pengoptimalan selama bertahun-tahun telah menyebabkan codebase terlalu pas dengan JavaScript. Misalnya, mereka memiliki struktur data inti di Spreadsheet yang memburamkan garis antara array dan peta. Tindakan ini efisien dalam JavaScript, yang otomatis memodelkan array sparse sebagai peta, tetapi lambat di platform lain. Jadi mereka harus menulis ulang kode dengan cara yang lebih agnostik platform. Hal ini adalah hal lain yang disukai tim tentang WebAssembly: hal ini memudahkan aplikasi multiplatform untuk mendapatkan kinerja yang baik di web. Anda tidak harus menekuk seluruh aplikasi ke keunikan JavaScript.

Hasil akhir

Setelah semua pengoptimalan ini, Spreadsheet versi WasmGC final mencapai performa penghitungan sekitar dua kali lebih cepat daripada JavaScript, yang menunjukkan peningkatan empat kali lipat dari titik awal versi WasmGC awal.

Kesimpulan

WasmGC adalah teknologi canggih yang berpotensi memajukan cara developer membangun aplikasi web. Dalam beberapa tahun mendatang, di Google, kami berharap WasmGC semakin berkembang untuk mendukung multithreading memori bersama dan semakin meningkatkan performa thread tunggal. Semua developer web sebaiknya mempertimbangkan penggunaan WasmGC untuk project berperforma tinggi berikutnya. Bergabunglah dengan kami dan jadikan web lebih cepat dan lancar bersama-sama!

Ucapan terima kasih

Terima kasih untuk rekan-rekan yang mengerjakan implementasi WasmGC.