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.

I am not aware of any of the major gaming consoles uses Wasm or Wasmi in particular for their engine but I am sure they'd let us know if they ever used Wasm as execution model for all their games.

What's more likely is that Wasm is used in some indie games for those major game consoles.

I know of one game engine (Firefly-zero) and one game where Wasmi is used as game engine and plugin engine respectively. There likely are more, but that's what I know for a certain.

I experimented with running Doom using Wasmi and it even works in the browser, thus in a double sandbox where Wasmi itself is compiled to Wasm: (references in the article) https://wasmi-labs.github.io/wasmi-doom/

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.

Awww, makes me very happy to hear! :) Thank you!

Wasmtime, being an optimizing JIT, usually is ~10 times faster than Wasmi during execution.

However, execution is just one metric that might be of importance.

For example, Wasmi's lazy startup time is much better (~100-1000x) since it does not have to produce machine code. This can result in cases where Wasmi is done executing while Wasmtime is still generating machine code.

Old post with some measurements: https://wasmi-labs.github.io/blog/posts/wasmi-v0.32/

Always benchmark and choose the best tool for your usage pattern.

Yes, rational is to provide a pragmatic and efficient solution to infinite loops.

There is a variety of ways to implement fuel metering with varying trade-offs, e.g. performance, determinism and precision.

In this comment I roughly described how Wasmi implements its fuel metering: https://news.ycombinator.com/item?id=44229953

Wasmi's design focuses on performance and determinism but isn't as precise since instructions are always considered as group.

I am really sorry I have waited so long to extend Wasmi's resumable calls with this very useful feature. :S Feel free to message me if you ever plan to adjust your design to make use of it.

I don't know how fuel metering in Wasmtime works and what its overhead is but keep in mind that Wasmi is an interpreter based Wasm runtime whereas Wasmtime generates machine code (JIT).

In past experiments I remember that fuel metering adds roughly 5-10% overhead to Wasmi executions. The trick is to not bump or decrease a counter for every single executed instruction but instead to group instructions together in so-called basic blocks and bump a counter for the whole group of instructions.

This is also the approach that is implemented by certain Wasm tools to add fuel metering to an existing Wasm binary.

Great question!

Wasmi's fuel metering can be thought of as is there was an adjustable counter and for each instruction that Wasmi executes this counter is decreased by some amount. If it reached 0 the resumable call will yield back to the host (in this case the OS) where it can be decided how to, or if, the call shall be resumed.

For efficiency reasons fuel metering in Wasmi is not implemented as described above but I wanted to provide a simple description.

With this, one is no longer reliant on clocks or on other measures to provide each call its own time frame by providing an amount of fuel for each Wasm app that can be renewed (or not) when it runs out of fuel. So this is useful for building a Wasm scheduler.

> Every iteration of the loop polls the network and input drivers, draws the desktop interface, runs one step of each active WASM application, and flushes the GPU framebuffer.

This is really interesting and I was wondering how you implemented that using Wasmi. Seems like the code for that is here:

https://github.com/Askannz/munal-os/blob/2d3d361f67888cb2fe8...

It might interest you that newer versions of Wasmi (v0.45+) extended the resumable function call feature to make it possible to yield upon running out of fuel: https://docs.rs/wasmi/latest/wasmi/struct.TypedFunc.html#met...

Seeing that you are already using Wasmi's fuel metering this might be a more efficient or failure proof approach to execute Wasm apps in steps.

An example for how to do this can be found in Wasmi's own Wast runner: https://github.com/wasmi-labs/wasmi/blob/019806547aae542d148...

Wasmi author here. Glad to see Wasmi being used in embedded contexts were it really shines. :)

I just watched the demo video of Munal OS and am still in awe of all of its features. Really impressive work!

Have you had experience implementing SSA via sea-of-nodes representation? Could it be that in this case dominance frontier is no longer important and one could use the simpler SSA construction algorithms that do not require dominance frontiers?

Yes this iterative process is indeed very visible. Wasmi started out as a mostly safe Rust interpreter and over time went more and more into a performance oriented direction.

Though I have to say that the "list of addresses" approach is not optimal in Rust today since Rust is missing explicit tail calls. Stitch applies some tricks to achieve tail calls in Rust but this has some drawbacks that are discussed in detail at Stitch's README.

Furthermore the "list of addresses" (or also known as threaded code dispatch) has some variance. From what I know both Wasm3 and Stitch use direct threaded code which stores a list of function pointers to instruction handlers and use tail calls or computed-goto to fetch the next instruction. The downside compared to bytecode is that direct threaded code uses more memory and also it is only faster when coupled with computed-goto or tail calls. Otherwise compilers nowadawys are pretty solid in their optimizations for loop-switch constructs and could technically even generate computed-goto-like code.

Thus, due to the lower memory usage, the downsides of using tail calls in Rust and the potential of compiler optimizations with loop-switch constructs we went for the bytecode approach in Wasmi.

No I do not but it is a very interesting question and probably not even answerable in practice because not every instruction takes the same amount of time to execute to completion. An outlier in this regard are for example host function calls which could do arbitrary things on the host side or bulk-memory operations which scale linearly with their inputs etc.

Also great job on Wizard btw! Your article about Wizard was a really interesting read to me.

The abundance of Wasm runtimes is a testimony of how great the WebAssembly standard really is!

Oh this is very interesting! I wish I knew about this before I wrote my own benchmarking suite. :D

Thank you! :)

when using lazy-unchecked translation with relatively small programs, setting up the Linker sometimes can take up the majority of the overall execution with ~50 host functions (which is a common average number). We are talking about microseconds, but microseconds come to play an importance at these scales. This is why for Wasmi we implemented the LinkerBuilder for a 120x speed-up. :)

I am aware of Wizard and I think it is a pretty interesting Wasm runtime. It would be really cool if it was part of Wasmi's benchmark testsuite (https://github.com/wasmi-labs/wasmi-benchmarks). Contributions to add more Wasm runtimes and more test cases are very welcome.

The non-WASI test cases are only for testing translation performance, thus their imports are not necessary to be satisfied. This would have been the case if the benchmarks tested instantiation performance instead. Usually instantiation is pretty fast though for most Wasm runtimes compared to translation time.