rapidlua

The article doesn't mention the number/class of CPUs in the system used for the benchmark. It claims that 'Singlepass' compilation of clang.wasm took 2s and 'Cranelift' took 9s.

Running the same benchmark myself in Linux on a 4CPU VirtualBox on a MacBook Pro, I see 11s and 42s respectively. For reference , V8/Node.js compiles the same file in 27s.

Compiled files were 339 MiB (Singlepass), 640 MiB (Cranelift) and 90 MiB (V8/Node.js).

Clang.wasm itself is 45 MiB.

> but the bundle is enormous - over a megabyte of data

If only DOT layout engine and JSON output format is enabled at compile time it is about 600KiB, or less than 200KiB Gzipped. https://github.com/rapidlua/viz.js

> A nice thing about having an SVG render is that it's very easy to attach events, and inline SVGs can be styled with CSS.

Indeed it’s super handy! I’m using this approach in https://LuaJIT.me to produce an interactive visualisation of a graph of traces in a JIT compiler.

I doubt that WASM is good as an embedded language, unless performance requirements outweigh the inconvenience.

Dynamic languages are great for experimentation and exploring the system, e.g. a console in the browser is the fantastic tool and web dev people tend to try things there first. By embedding wasm, you are making tinkering with the system you provide less enjoyable for your users.

One could argue that since many languages compile to wasm, you can pick whichever suites you best. But in reality, you are probably limited to languages with thin runtimes, e.g. Rust or C. Otherwise you will end up with a huge wasm blob. Imagine, there are 2 Java extensions, a C# one and something in Python, all running simultaneously. It means 3 different runtimes with a footprint by far exceeding that of the application logic in an extension.

Another burden is the bridging between the host and an extension. Unlike lua or js you can’t pass and inspect objects, the only option is to marshal data as a byte blob. So if you were to pick up a language no one used to write extensions for the particular application before, the very first think you have to do is writing marshalers.

Last but not least, I disagree with the article calling S-expressions ugly and strongly believe in the opposite.

We are on the same page irt tail calls. I assume that instruction handlers (non-standard calling convention, tail-calls next handler) need to invoke helper functions quite often. These helpers adhere to standard C calling convention. VM state is in registers. Unless they are callee-saved, registers have to be saved to stack and restored after each helper call. (LuaJIT VM uses helper functions heavily.)

> Did you check out the "GHC calling convention"?

GHC allocates registers for arguments from the fixed list where most but not all registers are callee-save in other common CC-s. This is a big improvement; still there are valid reasons to want it customisable.

E.g. in LuaJIT next instruction is decoded as a part of an instruction handler before dispatching to the next handler. Instruction arguments are passed to a handler; they shouldn't use callee-saved registers.

Another complication is the stack frame. There's a requirement to keep the stack pointer aligned (16 byte on x86_64). Call instruction pushes the return address and the pointer becomes misaligned. If the called function wishes to call further functions it has to adjust the stack pointer to make it aligned, even if it doesn't use the stack. The stack pointer is adjusted in a function prologue, hence there's a slowdown even if a nested function call is on a cold path.

Whether these micro-optimisations are worthwhile remains to be seen.

I am currently exploring the similar approach. The idea is to compile to llvm IR and then augment it. There's a musttail marker in the language to enforce tail calls no matter what the optimisation level is.

Passing VM state via arguments is suboptimal since argument registers are often clobbered and one would normally use callee-saved registers. I have developed a patch for llvm allowing to specify registers used for passing arguments and making more registers available for allocation without spilling.

I intend to reimplement LuaJIT VM in C with IR augmentation to verify the performance.