Interesting overall, although I think mixed results as a takeaway:
The initial Sheets calculation worker ported from JS to WasmGC was “roughly two times slower”.
After profiling, it was determined that speedups could be found by adding standard optimizations for speculative inlining and devirtualization to the Chrome implementation of WasmGC.
More profiling revealed that some important special cases, like regexps, could be massively sped up by moving to non-wasm native code calls for those special cases.
Finally, a number of JS-specific optimizations were found to be pessimizations for the new WasmGC backend, and performance was improved by backing them out.
Only #4 here seems obviously general and under a typical porter’s control. The improvements in #2 really depend on how general these optimizations turn out to be, since your average third-party code author is not going to have a direct line to the Chrome WasmGC team. And #3 is even more narrow in potential applications.
and then WasmGC got enabled by default in Chrome in late October 2023. In other words #2 was more about implementing WasmGC in Chrome in general, not as a step of porting as it kinda comes off as.
Although less fast than I would have expected. Their initial attempt was slower than the Javascript version, and after tuning the performance, they managed to get the WasmGC version to be twice as fast as the Javascript version. That’s an improvement, but a smaller one than I’d have expected.
I think this is expected given that what they’ve actually done:
By mid 2021, the teams had a working Java to WasmGC compiler. Toward the end of the same year, they had a prototype version of Google Sheets running as WasmGC and doing calculations.
That is, this is not “rewrite JavaScript to WASM because speed”, this is “compile existing Java to WASM”. Which explains why they need WasmGC in the first place: naively, I’d assume spreadsheet calculation is exactly the case where you don’t want gc and can benefit greatly from carefully designing layout of data structures in memory, but, if your main goal is comparability with existing Java system and the solution to compact is compilation from the same Java source, they of course you need a gc
Yeah I once met someone who went to work on the Microsoft Excel team after an acquisition
The recalc engine was apparently written in assembly language for many platforms, not even in C! (this was in ~2016 or so I think, so Excel was already ~30 years old by that point)
It’s just really hot code, arguably the hottest if you consider how many people are updating Excel spreadsheets every day for work, etc. :)
They were starting from a point where JS was “more than three times slower than the Java version,” and (for C-like languages which, unlike Java, do a lot of optimization at compile time) Wasm is typically somewhere between 1-2x slower than native, so it’s about where I would have expected.
The fact that it’s a totally new Java implementation makes me expect there is probably room to get it closer to 1x in the future, but it sounds like it’s already close.
For those who skimmed past it like me, the code was written in Java and a Java-to-WasmGC POC compiler was used to produce the resulting WasmGC byte code. (original comment follows)
Is there any mention of what WasmGC-targeting language is actually being used here? Given talks about specific optimisation comparisons I would assume probably AssemblyScript, but confirmation would be nice.
Interesting overall, although I think mixed results as a takeaway:
Only #4 here seems obviously general and under a typical porter’s control. The improvements in #2 really depend on how general these optimizations turn out to be, since your average third-party code author is not going to have a direct line to the Chrome WasmGC team. And #3 is even more narrow in potential applications.
From what I can gather,
and then WasmGC got enabled by default in Chrome in late October 2023. In other words #2 was more about implementing WasmGC in Chrome in general, not as a step of porting as it kinda comes off as.
Answer: it’s faster to execute in the browser.
Although less fast than I would have expected. Their initial attempt was slower than the Javascript version, and after tuning the performance, they managed to get the WasmGC version to be twice as fast as the Javascript version. That’s an improvement, but a smaller one than I’d have expected.
I think this is expected given that what they’ve actually done:
That is, this is not “rewrite JavaScript to WASM because speed”, this is “compile existing Java to WASM”. Which explains why they need WasmGC in the first place: naively, I’d assume spreadsheet calculation is exactly the case where you don’t want gc and can benefit greatly from carefully designing layout of data structures in memory, but, if your main goal is comparability with existing Java system and the solution to compact is compilation from the same Java source, they of course you need a gc
Yeah I once met someone who went to work on the Microsoft Excel team after an acquisition
The recalc engine was apparently written in assembly language for many platforms, not even in C! (this was in ~2016 or so I think, so Excel was already ~30 years old by that point)
It’s just really hot code, arguably the hottest if you consider how many people are updating Excel spreadsheets every day for work, etc. :)
They were starting from a point where JS was “more than three times slower than the Java version,” and (for C-like languages which, unlike Java, do a lot of optimization at compile time) Wasm is typically somewhere between 1-2x slower than native, so it’s about where I would have expected.
The fact that it’s a totally new Java implementation makes me expect there is probably room to get it closer to 1x in the future, but it sounds like it’s already close.
For those who skimmed past it like me, the code was written in Java and a Java-to-WasmGC POC compiler was used to produce the resulting WasmGC byte code. (original comment follows)
Is there any mention of what WasmGC-targeting language is actually being used here? Given talks about specific optimisation comparisons I would assume probably AssemblyScript, but confirmation would be nice.wasmgc is actually really exciting