Wasmtime's epoch system was designed specifically to have a much, much lower performance impact than fuel metering, at the cost of being nondeterministic. Since different embeddings have different needs there, wasmtime provides both mechanisms. Turning epochs on should be trivial if your system provides any sort of concurrency: https://github.com/bytecodealliance/wasmtime/blob/main/examp...

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.

This is really cool stuff. I've always wanted fuel-based work with a high level programming languages. Having a language compile to wasm with wasmi now seems like a nice way to achieve that.

I had no idea what fuel is until this discussion.

What's the rationale? Just preventing infinite loops from hanging the host?

If the inefficiency is the counter, what if you just calculated an instruction offset - start < threshold every once in a while?

This probably makes no sense, ignore it, I'm way in over my head.

[1] https://github.com/bytecodealliance/wasmtime/issues/4109

[2] https://github.com/bytecodealliance/wasmtime/blob/main/examp...

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 first encountered this with gas in the Ethereum VM. For Ethereum, they price different operations to reflect their real world cost: storing something forever on the blockchain is expensive whereas multiplying numbers is cheap

I’m not sure what it’s used for in this context or how instructions are weighted

Let's consider that you create a serverless platform which runs wasm/wasi code. The code can do an infinite loop and suck resources while blocking the thread that runs the code in the host. Now, with a fuel mechanism the code yields after a certain amount of instructions, giving the control back to the host. The host can then do things such as stop the guest from running, or store the amount of fuel to some database, bill the user and continue execution.