Thank you! :) In the `wasmi-benchmarks` suite we support ~20 different Wasm runtimes and compare their performance with each other, including optimizing JITs such as Wasmtime/Wasmer Cranelift and baseline JITs such as Wasmtime Winch and Wasmer Singlepass.

The geomean of performance of Wasmi compared to baseline JITs across all benchmarks in the repository ranges from 2.5-5.2x slower depending on hardware. And compared to opimizing JITs geomean ranges from 5.3-10.7x slower.

Wasmtime's Pulley is a very interesting interpreter. It isn't the fastest but it is the only Wasm interpreter that sits behind an elaborate optimization pipeline. Thus if you feed unoptimized Wasm, it would likely outperform the other interpreters. However, unoptimized Wasm is extremely uncommon.

When I've measured this in the past I've seen Wasmtime's Cranelift compiler generating code that runs roughly 1.5x-1.9x slower than native (LLVM) on SPEC 2017 workloads, with x86-64 being closer to 1.5x and AArch64 closer to 1.9x. From what I recall, interpreter performance was generally more like 10x slower than native, with some workloads that involved heavy cryptography/SIMD being 30x slower.

No, they're not getting close. Top performing Wasm runtimes (like those in V8 and JSC) are generally between 10% (for pure math workloads) and 2x (conservatively, for ef allocation heavy ones) the speed of equivalent native implementations. But that's including the JIT compilation tiers; the performance of interpreters alone lags by an order of magnitude.

I've been poking at a C version of this (https://github.com/dan-eicher/javelina) which would be interesting to benchmark against as it does a similar tail-calling dispatch mechanism. Plus copy-and-patch JIT but that probably only works on x86-64 as that's the only place I've ever tested it. The main differences from a brief skim of TFA is mine doesn't have any fallback (so non-tail calls will blow up the C stack) and the function calls always go through the trampoline so the VM doesn't have to care if it's calling JIT or interpreted code which, I'm assuming, your function pointer embedding thing is designed to optimize away.

And the JavaCard firewall algorithm would be an interesting non-spec addition to a wasm VM which is running code you really, really don't want to escape the sandbox. Something to look into for inspiration on the subject, perhaps? Not sure if there's any sort of proposal for sandboxing these things as I just took the spec file and implemented it using the dodgy weasels where it was mainly to see how far they've come with no real plan to use it for anything so kept it strictly to what the spec said a wasm interpreter needs to do.

Anyhoo, didn't really realize there were so many different projects doing the same thing, kind of interesting, actually...

hey, I'm not super familliar with webassembly interpreters in general so id ask here:

What's the usecase? like I guess edge, chrome etc already have their own interpreters for webassembly built in. do you aim to replace those and be bundled with them?

Or is this for other browsers? or even just other apps (whats the usecase there as opposed to just native execution)

Hi there! It's really great seeing someone putting in the work to make a WASM interpreter fast :) I'm very much interested in this because I want my game's scripting system to simply run WASM so I need a fast WASM interpreter because iOS forbids JIT and most gaming consoles allegedly do so as well. I know it's NDA gated so one has to be light on details, but have you heard about people using wasmi interpreter on one of the major gaming consoles? I could imagine how that also makes awesome modding possible, especially when being able to limit how many resources those mods are allowed to consume.

Can I use it to embed PGlite in an app and distribute it like that? ie not to dependend on the host JIT/interpreter

From my experiences indirect-threading and direct-threading are only ~10-15% of performance apart. However, the switch-loop dispatch that is used on platforms that do not support tail-calls can be a lot slower. However, the slowdown highly depends on the underlying hardware. For example, on Apple Silicon the slow-down is huge, whereas on Intel the slowdown isn't that drastic.

Unfortunately, I haven't tested any of the Wasm runtimes on low-powered hardware so far but that would be a great addition and I'd be extremely interested in how the fast interpreters such as Wasmi, Wasm3 and Stitch perform there. From what I know Wasm3 was optimized for those targets, so it might fare well and if Wasmi does not yet perform well there it should be fairly easy to catch up since the architectural foundation is similar.

Also, Wasmi's auto-dispatch feature that automatically detects if tail-calls can be used is very conservative. We might be able to cover more targets in the future with it, thus avoiding the slower switch-loop for more platforms eventually.

From the people that use Wasmi on lower-powered hardware (e.g. the Firefly-zero people) they seem to be very happy with Wasmi's performance so far.

Thank you! It means a lot coming from someone with your experience in the field.