Performance

[Kronos3]

There has been little effort put into optimizing the the IR to produce fast executable bytecode. Some ideas that we should try similar to Wasmi, wasm3, wamr-fast, wasmtime. I've sorted these in sort of priority and feasibility:

1. Register-based IR. The idea here is to drop local_get and local_set to write directly to/from the stack as well as operate directly from the stack for other instructions. Wasmi has done a lot of great work in this area, we should see if we can leverage this and still maintain decoding in a single streamed-pass.
2. I'm hesitant around the wasm3 approach since it sort of breaks the "no native stack" requirement of the interpreter but we should look at it closer to validate that assumption. This may also depend on Explicit Tail Calls rust-lang/rfcs#3407.
3. Wasmtime has the Cranelift single-pass JIT winch. This would probably imply a ground up implementation. This is a separate proposal on it's own but I'm folding it in here as a long term idea.
   • https://github.com/bytecodealliance/rfcs/blob/main/accepted/wasmtime-baseline-compilation.md
   • I could not find any academic papers which will make this harder.
   • This also may break encapsulation so we would have it as a compile-time optional feature. This is useful for trusted executable code that we want to run in a sandbox for portability reasons

[kokroo]

@Kronos3 I will take a crack at this and #61 since this benefits my low-resource hardware directly.

#61 is easy peasy for me, but this one will need quite careful refactoring. I am afraid we might silently break something if we attempt what Wasmi does. I am wondering what kind of tests we can add to catch such cases before they take down a system in the wild. Any ideas or pointers would be appreciated before I attempt this!

[Kronos3]

@kokroo Thanks for offering, and glad this helps your setup! For #61, go for it, we'd welcome the PR.

This one is something we're going to keep with the maintainers. It touches core paths and the maintainers need to understand the design and implementation fully, so we'd rather own the refactor ourselves. Hope you understand!

[kokroo]

@Kronos3 No problem at all! I never thought I'd be able to do this end-to-end all by myself anyway, that's why I was seeking ideas regarding the tests to ensure stability.

I will still try to experiment for fun. I'd like to find out which path is the simplest while providing the biggest performance gains. I might add an issue or a PR with some benchmarks (not to be merged, just a demo for comparing different paths) if any of these experiments work out.