Google Spreadsheet adalah salah satu produk pertama di Google yang menggunakan WasmGC di Chrome. Perubahan ini diumumkan pada tahun 2022, dan tim Spreadsheet serta Chrome berkolaborasi dalam standardisasi, engineering, dan alat untuk memberikan masukan real-time tentang pengoptimalan. Kemitraan ini menetapkan preseden tentang cara tim engineering di Google dapat bekerja secara efektif dengan Chrome agar lebih banyak aplikasi Google berjalan di WasmGC.
Tantangan: JavaScript
Mesin penghitung Google Spreadsheet awalnya ditulis dalam Java dan diluncurkan pada tahun 2006. Pada awal peluncuran produk, semua perhitungan dilakukan di server. Namun, sejak tahun 2013, mesin ini telah berjalan di browser menggunakan JavaScript. Hal ini awalnya dilakukan melalui Google Web Toolkit (GWT), dan kemudian melalui transpiler JavaScript Java ke Closure (J2CL). Mesin penghitung JavaScript berjalan di Web Worker dan berkomunikasi dengan thread utama menggunakan MessageChannel.
Memigrasikan pengguna dari server ke mesin penghitung versi JavaScript (dan selanjutnya dari GWT ke J2CL) adalah tugas besar yang memerlukan validasi yang cermat. Untuk memastikan bahwa mesin penghitungan JavaScript menghasilkan hasil yang sama persis dengan versi Java, tim Spreadsheet mengembangkan mekanisme validasi internal. Mekanisme ini dapat memproses banyak kumpulan data sheet dan memvalidasi bahwa hasilnya identik di antara beberapa versi mesin penghitungan. Tim Spreadsheet menggunakan alat ini secara rutin untuk memvalidasi perubahan pada Spreadsheet. Namun, tim tidak hanya membandingkan hasil perhitungan tersebut, tetapi juga membandingkan performa antara JavaScript di klien dan Java di server. Mereka mendapati bahwa mesin penghitungan versi JavaScript lebih lambat lebih dari tiga kali lipat dibandingkan dengan versi Java.
Mengapa JavaScript lebih lambat daripada Java?
JavaScript cepat untuk bahasa dinamis yang tidak memiliki jenis data yang ketat. Investasi besar-besaran 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 membuat compiler JIT sulit menghasilkan kode yang optimal. Artinya, JavaScript masih tertinggal dari 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 jenis jaminan yang diperlukan oleh compiler untuk menghasilkan kode yang optimal. Untuk kasus seperti Google Spreadsheet, yang memerlukan waktu puluhan detik untuk menghitung spreadsheet besar, JavaScript memang cepat, tetapi tidak cukup cepat.
Solusi: WasmGC
WasmGC adalah ekstensi untuk spesifikasi WebAssembly yang ada yang menambahkan primitif yang diperlukan untuk mengompilasi bahasa yang dikumpulkan sampah (seperti Java). Misalnya, WasmGC menambahkan petunjuk untuk menentukan jenis dan mengalokasikan struktur data yang dikumpulkan sampah. WasmGC siap melakukan hal yang sama untuk bahasa yang dikumpulkan sampah seperti yang dilakukan Wasm untuk C++ (misalnya, Photoshop atau Google Earth), yaitu membawanya ke web dengan kecepatan mendekati kecepatan native. Di Google, kami yakin bahwa WasmGC berpotensi memberikan dampak yang lebih besar daripada Wasm karena popularitas bahasa yang dikumpulkan sampah.
Google Workspace bekerja sama dengan Chrome
Draf spesifikasi MVP WasmGC dipublikasikan pada tahun 2019. Pada akhir tahun 2020, Google Workspace dan Chrome berkolaborasi untuk mengevaluasi WasmGC menggunakan mesin penghitungan Spreadsheet. Tim multiplatform Workspace memiliki keahlian yang signifikan dalam membangun dan mengoptimalkan compiler dan transpiler. Spreadsheet, yang merupakan bagian dari Workspace, diidentifikasi sebagai kandidat ideal untuk mengevaluasi WasmGC: Spreadsheet sensitif terhadap performa dan memiliki mekanisme validasi performa dan kebenaran yang kuat. Chrome memiliki tim V8 untuk membangun dan mengoptimalkan runtime WasmGC serta kontributor 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 platform pengujian yang ideal.
Prototipe pertama
Pada pertengahan tahun 2021, tim telah memiliki compiler Java ke WasmGC yang berfungsi. Menjelang akhir tahun yang sama, mereka memiliki versi prototipe Google Spreadsheet yang berjalan sebagai WasmGC dan melakukan penghitungan. Dalam perjalanannya, mereka menghadapi banyak tantangan. Alat untuk pembuatan profil dan pengambilan dump heap tidak ada dan harus dibuat. Implementasi yang ada mengandalkan banyak library JavaScript yang penggantinya harus ditemukan atau ditulis untuk WasmGC. Memvalidasi kebenaran mesin penghitungan Wasm adalah upaya yang memakan waktu karena sifat eksperimental spesifikasi, compiler, dan library baru. Namun, mekanisme validasi Spreadsheet sekali lagi sangat membantu. Pada akhirnya, tim berhasil membuat semuanya berfungsi, dan data performa mulai masuk pada awal tahun 2022.
Pengoptimalan tambahan
Versi awal Sheets Wasm menunjukkan performa penghitungan yang kira-kira dua kali lebih lambat daripada JavaScript. Namun, ini bukan hasil yang buruk untuk spesifikasi baru, kompilator baru, dan beberapa pustaka baru. Mulai saat ini, tim Spreadsheet mulai melakukan pengoptimalan. Dari pengoptimalan yang mereka temukan, muncul beberapa kategori:
- Mereplikasi pengoptimalan inti yang sudah ada di Java Virtual Machine (JVM) dan di V8.
- Menggunakan API browser yang sangat dioptimalkan.
- Menghapus pola coding khusus JavaScript.
Pertama, tim Spreadsheet perlu mereplikasi pengoptimalan yang sudah ada di toolchain lain. Contoh terbaiknya adalah mengoptimalkan pengiriman metode virtual, yang telah lama dioptimalkan oleh JVM dan V8, tetapi tidak ada yang tersedia untuk WasmGC. Penerapan penyisipan spekulatif dan devirtualisasi—dua pengoptimalan yang sangat umum—mempercepat waktu penghitungan sekitar 40% di Chrome.
Kedua, ada kasus ketika API browser didukung oleh implementasi native yang dioptimalkan dan sulit ditandingi menggunakan Wasm. String dan ekspresi reguler adalah dua contoh yang baik. Secara khusus, dengan ekspresi reguler, tim melihat peningkatan kecepatan operasi ekspresi reguler hampir 100 kali lipat saat beralih dari re2j (dikompilasi ke WasmGC) ke RegExp browser API di Chrome, yang dapat mengompilasi setiap ekspresi reguler ke kode mesinnya sendiri.
Terakhir, mereka mendapati bahwa pengoptimalan selama bertahun-tahun telah menyebabkan codebase terlalu cocok dengan JavaScript. Misalnya, mereka memiliki struktur data inti di Spreadsheet yang mengaburkan batas antara array dan peta. Hal ini efisien di JavaScript, yang secara otomatis memodelkan array jarang sebagai peta, tetapi lambat di platform lain. Jadi, mereka harus menulis ulang kode dengan cara yang lebih agnostik terhadap platform. Hal lain yang disukai tim tentang WebAssembly adalah: WebAssembly mempermudah aplikasi multiplatform mendapatkan performa yang baik di web. Anda tidak perlu menyesuaikan seluruh aplikasi dengan keunikan JavaScript.
Hasil akhir
Setelah semua pengoptimalan ini, versi akhir WasmGC Spreadsheet 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, kami di Google berharap WasmGC akan berkembang untuk mendukung multithreading memori bersama dan lebih meningkatkan performa thread tunggal. Kami mendorong semua developer web untuk mempertimbangkan penggunaan WasmGC untuk project berperforma tinggi berikutnya. Bergabunglah bersama kami dan jadikan web sebagai tempat yang lebih cepat dan lancar bersama-sama.
Ucapan terima kasih
Terima kasih kepada semua orang yang mengerjakan implementasi WasmGC dan studi kasus ini: 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, dan Emanuel Ziegler.