WebAssembly Backend Redux!

[0x000000000000000000]

Hey @katsujukou and @harryprayiv,

I’ve been following your progress on purs-wasm with great interest, and it’s truly fantastic work. Since we are both tackling the unique challenges of building AOT (Ahead-Of-Time) backends for PureScript, I wanted to share a recent architectural breakthrough I had with gopurs that might directly help with the “typeclass dictionary elimination” and “primitive inlining” optimizations you mentioned.

Like you, I initially built my backend consuming standard CoreFn. But I quickly hit a hard performance ceiling: because CoreFn strips away static type information, the backend is forced into dynamic boxing and heavy runtime checks, which severely limits what an AOT compiler can optimize.

To break this ceiling, I created a fork of the compiler to emit a Typed AST (tcorefn: essentially CoreFn + dataDecls array + ann.type on every single node). Having the strict type available at compile time changed everything:

• It allowed the backend to completely eliminate primitive boxing.
• It made it possible to translate typeclass dictionaries directly into native, statically-typed structs (zero-cost abstraction).

This single architectural shift resulted in a huge performance jump, putting the generated Go code on par with V8 on a single thread (at least, because I still work on optimizations). I detailed the process and the benchmark results in my devlog here:

Leveraging a blazing-fast runtime: a (new) Go backend for PureScript

News #2: Victory! That’s fantastic. The TAST approach has more than paid off: that’s a big x10 in perfs. So much so that I’ll soon be submitting a PR to add tcorefn (= corefn JSON + dataDecls array at the root + ann.type on each node) to the available options for purs compile --codegen (among corefn, docs, js…). ADTs, Records and functions have been added to the whitelist, and they’ve enabled numerous improvements (struct, eager uncurrying…). For now, I’m working with a fork of Purescrip…

Given how strict WebAssembly is with primitive types (i32, i64, f64), I imagine having access to a fully typed AST would allow purs-wasm to emit native instructions directly without relying on workarounds, and finally solve the dictionary elimination problem?

I am currently preparing a PR to the official PureScript compiler to add --codegen tcorefn as a standard option. I’d love to hear your thoughts on this. If tcorefn could also unlock WebAssembly’s true speed, I think a friendly “coalition” of AOT backends pushing for this feature would be a huge step forward for the whole ecosystem.

Feel free to let me know if you’d like some help exploring TAST for the Wasm project. I’d be more than happy to jump in, or even run some tests on my end to see if it brings a tangible performance gain for WebAssembly.

Keep up the amazing work!