Hacker News Reader

Comment by herobird | Hacker News Reader

> 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...

View on HN

Thanks again for making Wasmi :)

> 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:

That is really interesting! I remember looking for something like that in the Wasmi docs at some point but it must have been before that feature was implemented. I would probably have chosen a different design for the WASM apps if I had it.

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.

Please don't take it as a reproach! Not your fault at all, and at least it forced me into creative problem-solving ;)

Not OP, but I'm confused how this would be helpful. You're saying for example, he can use this function to create a coroutine out of a function, begin it, and if the function fails by e.g. running out of memory, you can give the module more memory and then resume the coroutine? If so, how is that different than what naturally happens? Does wasm not have try/catch? Also, wouldn't the module then need to back up manually and retry the malloc after it failed? I'm so lost.

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.

Is it deterministic? I.e. would running the same function "time out" at the exactly same state, if run in different environments?

Possibly answered one sibling next to you, https://news.ycombinator.com/item?id=44230721

Yes, Wasmi's fuel metering is deterministic.

We used fuel metering with wasmtime, but that made everything quite slow, certain things veeery slow.

How is the performance when using fuel with wasmi?

We are considering to use epoch counter, but for now we just turned fuel off.

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.

> Great question!

Thanks! I have lots more too. Are there directions in space? What kind of matter is fire made of? If you shine a laser into a box with one-way mirrors on the inside, will it reflect forever? Do ants feel like they're going in regular motion and we're just going in slow motion? Why do people mainly marry and make friends with people who look extraordinarily similar to themselves? How do futures work in Rust? Why is the C standard still behind a paywall? Let me know if you need any more great questions.

Flame is what you see when gases burn in the air. As the material burns, it breaks down and releases flammable gases, which burn too, giving the effect of flame. If you have ever tried burning fine-grade steel wool, you will have seen that it burns without any flame because the iron burns directly without making gases first.

I was told it was plasma. Who is wrong, them or you? Either way, I can't trust one of you...

Perhaps you should look it up yourself? Plasma is not found in flame, but it is in lightning.

"If you shine a laser into a box with one-way mirrors on the inside, will it reflect forever?"

No, because each reflection comes at a cost (some light transformed to heat)

"Why do people mainly marry and make friends with people who look extraordinarily similar to themselves?"

To not get so much surprises and have a more stable life. (I didn't choose that path.)

(But I feel it would be too much OT answering the other questions and don't want to distract from this great submission or the interesting Wasmi concept)

No, I do not accept this. There must be a way. What if the mirror box has a high enough heat? Would it work then? The box could be made of a heat resistant material, like fiberglass.

It's not that the mirror or box is damaged by heat, it's that each bit of heat energy comes from a bit of light energy. Eventually the light bounces enough times that there's no energy left in it.

I understand, but what I mean is, what if there is no more opportunity for the light to emit heat, because the surrounding environment is already saturated with so much heat that it can't accept more? Is this a possible way to prevent the light from emitting heat and therefore prevent the light from decreasing its luminousness? There must be a way!

Why must there be a way?

A few notes: * There's no such thing as "absolute hot" state that meansno more heat can be added * Blackbody radiation means that above a certain temperature, regardless of what you make your mirror out of, it will be spontaneously emitting visible light at all times.

Indeed. There is only an absolute zero, that cannot get colder, but more heat is always possible as more heat means more rapid movement of elements. While absolute zero at 0 K means no movement.

Are you aware of that old concept and why it doesn't work?

https://de.wikipedia.org/wiki/Perpetuum_mobile

Same principle.

Basically, what you propose negates the nature of reality. There is always friction/energy loss into heat (increased chaotic movement). Only way to deal with it, if you want permanent cycles, is constantly add energy in the same amount that is lost.

> Does wasm not have try/catch

Not currently. There's an accepted proposal, but its in progress.

It's awesome that Wasmi is fast enough to run GUI apps. I'm working on an app runtime for making highly portable GUI apps. I'm targeting wasm because it seems to strike a good balance between performance and implementation simplicity. Ideally it would be possible to run apps on a runtime hacked together by a small team or even a single person. The fact that an interpreted (if highly optimized) wasm runtime like Wasmi is clearly capable of running GUI apps is exciting.

Reply on news.ycombinator.com