herobird

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

If Wasmi supports all the Wasm proposals that you need for PGlite and if Wasmi supports all the WASI features you need (Wasmi only supported the standard WASI features without extensions), then Wasmi should work for your use-case. :)

Wasmi itself can be compiled to WebAssembly.

Cool project!

If you think that your Wasm interpreter is stable and kinda production ready enough, you might want to file a PR to the wasmi-benchmarks repo to add support for your Wasm runtime.

Would certainly be another great addition to have it. This would allow comparing your engine to all the others.

Wasmi does not directly compete with the large JIT engines such as Wasmtime and V8. Instead, Wasmi tries to fit perfectly into its niche. Its main purpose is that it is very easy to embed and provides great performance for those use-cases.

As detailed in the article, Wasmi is already used a lot for plugin systems, as game engine, as engine for executing smart contracts, and even as engine to run apps in experimental operating systems that have native Wasm support. It is also useful for cloud hosts that do not trust their inputs but need fast startup times and deterministic execution.

Furthermore, there are platforms such as iOS that outright forbid using JITs, so interpreters are the only option.

Fun fact: Wasm interpreter usually can even be embedded into Wasm environments themselves by compiling them to Wasm. Wasmi ran inside Wasmtime when it was used at Parity Technologies. This allowed them to hot-patch the Wasm runtime (Wasmi) without downtime.

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! :) 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.

hi, author here, ready to answer all your questions! (sorry for the delay, 2nd-chance post)

My view on specifications is that their long-term success depends on the value they provide relative to their complexity. Complexity inevitably grows over time, so spending that complexity budget carefully is crucial, especially since a specification is only useful if it remains implementable by a broad set of engines.

WebAssembly MVP is a good example: it offered limited initial value but was exceptionally simple. Overall, I am happy with how the spec evolved with the exceptions of 128-bit simd and relaxed-simd.

The main issue I see with 128-bit simd is that it was always clear it would not be the final vector extension. Modern hardware already widely supports 256-bit vector widths, with 512-bit becoming more common. Thus, 128-bit simd increasingly delivers only a fraction of native performance rather than the often-cited "near-native" performance. A flexible-vectors design (similar to ARM SVE or the RISC-V vector extension) could have provided a single, future-proof SIMD model and preserved "near-native" performance for much longer.

From a long-term perspective, this feels like a trade-off of short-term value for a large portion of the spec's complexity budget. Though, I may be underestimating the real challenges for JIT implementers, and I am likely biased being the author of a Wasm interpreter where flexible-vectors would be far more beneficial than 128-bit simd.

Why you think flexible-vectors might never have a realistic path to standardization?

> There is a lot of desire for advancement, but standardization means decisions are hard to reverse. For many, things are moving too quickly and in the wrong direction.

Most Wasm proposals are very elegantly designed and effective - meaning they provide lots of value for relatively minor specification bloat. Examples are tail-calls, multi-value, custom-page-sizes, memory64 and even gc.

However, the simd and flexible-simd increased spec bloat by a lot, are not future-proof and caused more fragmentation due to non-determinism. In my opinion work should have focused on flexible-vector (SVE-like) which was more aligned to Wasm's original goals of near-native performance. The reason for this development was that simd was simpler to implement and thus users could reap benefits earlier. Unfortunately, it seems the existence of simd completely stalled development of the superior flexible-vectors proposal.

If flexible-vectors (or similar) will ever be stabilized eventually, we will end up in one of two (bad) scenarios:

1) People will have to decide between simd and flexible-vectors for their compilation, depending on their target hardware which is totally against Wasm's original goals.

2) The simd proposal will be mostly unused and deprecated. Dead weight.

It's kinda frustrating that Mozilla's CEO thinks that axing ad-blockers would be financially beneficial for them. Quite the opposite is true (I believe) since a ton of users would leave Firefox for alternatives.

Article author here! Feel free to ask me anything. :)

Yes, Wasmi's fuel metering is deterministic.