More Chasm Love. This is the last minor release of...
# webassembly
c
More Chasm Love. This is the last minor release of the Chasm 1.x series, all of the things I want to do next require at least some breaking changes. Over the past couple of weeks Chasms undergone a bit of a transformation, it's had a new compiler, gained a ton of performance and now it ships with a real GC. Theres a ton more, please read the release notes from the last few releases. TLDR
Copy code
Phase          1.5.0     1.7.0     Difference
Decode         267.5 ms  219.3 ms   48.0 ms faster (−18.0%)
Validation     1.498 s   150.5 ms   1.347 s faster (−90.0%)
Instantiation  2.358 s   923.2 ms   1.435 s faster (−60.8%)
Execution      2.272 s   1.508 s    763.9 ms faster (−33.6%)
Rough priorities for the 2.0 series: • A new host functions interface with direct access to the stack • Threads proposal (It's now Stage 4 and in the process of being merged) • A new embedding api for working with externs which will leverage the new GC @Igor Yakovlev • Remove the now deprecated macosX64 target ... Then something around components github.com/CharlieTap/chasm/…/1.7.0
.wasm 4
🚀 11
Somewhat related I also released this at the start of the week, its Kotlin Multiplatform Doom project which leverages Chasm and WebGPU. github.com/CharlieTap/mood
❣️ 1
🔥 1
b
Just wondering 1. What do you use for performance measurements? 2. What's happening during
Instantiation
Why is it so heavy?
c
Those metrics in particular are timings for Chasm against this, basically a huge corpus of different realworld wasm workloads. The majority of time spent in instantiation is the compiler. Chasm's compiler does a bunch of different optimisations: • Linking every instruction so it has direct references to what it needs • Precomputing the stack frame so we don't push or pop, every instruction has a slot it knows to output to • We create specialised versions of the most hot handlers, for most numeric instructions we have variants which take from immediate or a stack slot, this removes a huge amount of traffic as most wasm work is moving between locals and the stack • Fusing super instructions • We predecode every handler into a lambda and build a "program". Basically removes the terrible switch on opcode you see in most interpreters And a ton of other smaller tweaks Other than the corpus the main benchmark I use is coremark
b
I see. Have you considered/tried performing all/majority of operations lazily?
c
Yes, I actually have a variant that did that. But it requires a check at runtime to say is this function or block compiled yet which I didn't really want. I optimise Chasm with the intent it will be used in apps, where theres explicit init phase where we can get away with instantiation and we get absolute performance when we invoke
The new single pass compiler is not bad either, you can see in the numbers above instantiating 300+ modules takes less than a second, some are chunky too like esbuild and sqlite etc