The next version of Maligator is going to support off-thread workers! They run mostly isolated, support MessageChannel, can transfer ArrayBuffers, etc. Maligator manages a native threadpool, `createPool` overlays on that, to run many VMs that are scheduled across the board.
Also experimented with PGO (profile guided optimization), but waaay too early for that. First have to focus on extracting more performance and selecting better optimizations in the compiler budgets we have.
Released a new Maligator alpha with a bunch of microbench improvements. Taking our self-compile against Node.js to an average of 5.89x slower instead of 6.13x. Lots to do still :)
@jarredsumner Also, AOT compiled JS will always still need some form of GC, and some form of runtime (especially if interop with more dybamic code is needed). So a gap to Rust and C is inevitable. Mutating of primordials is happening less is current years, so things can be optimized there.
@jarredsumner An AOT story is, in the near future, only going to happen if both correctness and performance can be achieved. The whole ecosystem depends on libraries that use all kinds of JS features. Else it will be a new language, and then what's the point? Just use Rust or something.
Our IR pipeline has been rewritten to better keep track of dependent optimizations, while working with a specialization budget so we don't keep working indefinitely. The performance isn't fully back. Especially not on our self-hosted compiler, but that's a matter of time.
Vibed some more over the past few days.
- WASM build in the browser to view how Maligator goes from JS to C
- The first Maligator module: maligator:process
- Rewrote our optimization pipeline
The information is dynamically available so `execution[dynamicLookup]` works. But DCE is applied on static access, so `if (execution.command === "test")` is compiled away.
View the available options at https://t.co/dU6LnA6Gac
The following example shows initial lowering to an intermediate representation to create the JS object, and the optimizer in the second step completely removing it since it isn't observable.
https://t.co/eWASZ9FiWA
Far from polished, but the Maligator website now shows a sneak peak in what is happening under the hood for various JS statements from compiler frontend to the two targets: malw (serialized bytecode with metadata) and C output.
The past week we worked better performance, more work on test262 compliance, a few more Node.js API's implemented and better cache usage. Cold runs are still rough (and probably always will be), but incremental builds are pretty decent across all dev commands.
Also added support for the `engine.primordials = "locked"` build setting to Maligator. This allows the compiler to assume that all primordials (i.e builtins) are never mutated. This allows for un-guarded optimizations or even specialized replacements for builtins.
Our Maligator self-compile benchmark has been steadily going up the last week as we refactored to a full CFG intermediate representation. For now this is slower, but will allow better optimizations in the future.