An OS built on top of WASM can provide modern features without the bloat of current CPUs, e.g. MMUs.
Ask HN: What are the use cases of WASM outside the browser?
21–27 of 27 posts
Re: Ask HN: What are the use cases of WASM outside the browser?
#22Re: Ask HN: What are the use cases of WASM outside the browser?
#23An OS built on top of WASM can provide modern features without the bloat of current CPUs, e.g. MMUs.
WASM sandboxing requires an MMU. It achieves its performance by trapping OOB reads via page faults.
Re: Ask HN: What are the use cases of WASM outside the browser?
#24Maybe a runtime for application plugins? You expose some apis in the wasm runtime and plug-in developers only have to target the wasm runtime.
Re: Ask HN: What are the use cases of WASM outside the browser?
#25An OS built on top of WASM can provide modern features without the bloat of current CPUs, e.g. MMUs.
Not if you care about side channels. There really aren't any good solutions here that let you safely run untrusted code in a shared address space. Yes, you can slap barriers behind every single branch and after every single store (memory ordering violations can cause mispeculations in straight line code!), but that's going to come with an enormous performance cost (academics regularly brag about inventing new mitigat…
Re: Ask HN: What are the use cases of WASM outside the browser?
#26Earlier quoted context omitted.
WASM sandboxing requires an MMU. It achieves its performance by trapping OOB reads via page faults.
I think they just worded that poorly. I suspect their suggestion is not that you run with the MMU _off_ (as doing so would trash your perf anyways since everything becomes uncacheable!) but rather that you don't need to context switch the page tables, which can lead to some pretty decent performance gains given that you can (on some platforms) avoid TLB flushes. Nowadays though I seriously would not consider the page…
Re: Ask HN: What are the use cases of WASM outside the browser?
#27Earlier quoted context omitted.
I think they just worded that poorly. I suspect their suggestion is not that you run with the MMU _off_ (as doing so would trash your perf anyways since everything becomes uncacheable!) but rather that you don't need to context switch the page tables, which can lead to some pretty decent performance gains given that you can (on some platforms) avoid TLB flushes. Nowadays though I seriously would not consider the page…
Nope, I meant what I wrote. You don't need an MMU, because you have no need for virtual memory or similar. Checking an integer is within some bounds is a much simpler problem, and in some cases the check can be elided through analysis on the code.