Many moons ago I was preparing for an interview to join wasmer, back then they showed me that by running wasmer as a kernel extension in Linux they have made it run four orders of magnitude (10,000 times) faster. Given the WASI, I keep thinking more than the plugin usability of things like wasmer, what is the point of WASM not being accepted as a second binary in all operating systems? Windows could support .exe as well as .wasm for example and we would finally have a cross-plaform binary. Apple would never accept; Microsoft will do, and Linux can simply have,
Such speedup is not plausible at all. It had to be a flawed benchmark relying on some API being very slow in userspace (probably on purpose, not using it the right way). The raw execution speed of WASM can't change much just because it is in a kernel.
That's probable, though if we want to give them the benefit of the doubt, it could be a non-optimised benchmark, ie, something that may be written during the average devoper might ordinarily write, rather than hyper-optimised code specifically for that benchmark.
What they had done was wiring kernel level operations, without any of the userspace security checks into the wasmer. Their logic was that given the sandbox of wasmer; what would happen if you removed the sandbox of the OS? And I remember their article was featured in HN for two days or so as well. It was interesting. It wasn't that WASM ran faster than C, it was the API calls. And I keep wondering about an architecture where you have a highly sandboxed universal assembly with some API hardening; a middle ground, and so imagine an app that ran everywhere and was 10~100 times faster. Could be really cool.
Yes, it's not a new idea. See Microsoft Singularity research OS for a more recent example.
You would still have slower than native execution speed, security problems with Spectre attacks (in HW process isolation it's avoided by not having other memory mapped at all, other mitigations exist but they cost a lot of performance).
Syscall speedups affect only specific programs or stupidly written SW like some games that are checking current time many many times per frame.
It's not just syscalls. If you trust all of the running code, you can use a single address space for all applications and even the kernel, which lets you avoid TLB flushes.
Whether that's still a good idea given Spectre is another question.
Judging by the slow speed of node here, I wonder if it was run without forcing optimizations. It doesn't do OSR (on-stack replacement), meaning that a benchmark script doesn't get a chance to tier up from the baseline compiler to the fully optimized tier.
Running with
node --no-liftoff
avoids this problem.
(This is not an issue on the Web, where code must return to the event loop anyhow, allowing tiering up to work, and node is optimized for that kind of workflow.)
It's genuinely great to see WASM runtimes are getting closer to native code while being sandboxed, but these benchmarks assume you're not bundling a whole Runtime + GC + stdlib inside the sandbox.
One fairly revealing microbenchmark for WASM runtimes is `int8` dot products & angular/cosine distances.
(My) NumKong [1] has implementations targeting both vanilla AVX2/Haswell and AVX2-VNNI/Alder Lake, which makes it easy to see where runtimes and code generators leave performance on the table.
I started a few Wasmtime/Cranelift PRs around this, but didn’t manage to finish them :facepalm: Might be a fun weekend project for someone interested in backend/codegen work.
It'd be nice to see memory use. Ideally base usage, then cost of running 1 of a thing, then cost of running 50 if a thing.
Personally low my 50% speed vs native does not sound like the worst to me. I've spent years using perl, java (in v4-v7 days), node... These have various ways they are less good than native, and we collectively seem to accept that. Ideally yes wasm gets faster but a 2x is pretty ok!
My only issue with WASM is that it forces me to contort my platform abstraction later to terrible web APIs. Other than that it's great. I can compile C++ with plain clang or the WASI SDK, and it runs everywhere at near native speeds with minimal boilerplate.
In my opinion, WebAssembly just needs to be better than what it replaced (asm.js) to be called a success story. And it definitely is better than asm.js.
Unlike HTML or CSS or JavaScript which are by definition large enabling technologies that enable completely new things, WASM is always that small step to make C/C++ and other native languages usable on the web. I never thought of WASM as a magic wand that makes web apps super fast and you probably shouldn’t.
>In my opinion, WebAssembly just needs to be better than what it replaced (asm.js) to be called a success story.
That would be only true if WASM was meant as a transitionary technology. But it has been with us for more than a decade, and it's only so-so. And if you think this, what do you think should replace it?
Is speeding up apps an aim of WebAssembly? I’m not being sarcastic… most of the slowdown you see in webapps is due to the DOM and/or network latency and WebAssembly offers nothing new there. The JavaScript language is very rarely the reason why an app is slow.
I’ve used WebAssembly to great success creating a unified codebase that runs on Node, an iOS app and on the web. It’s a niche but in that area it opens doors that were previously impossible to open.
Obviously it is, I've been writing a scientific library that runs in-browser and WebAssembly has been a blessing, it's easily 10x faster than the backend Python code it replaced, and 2-5x faster than I could achieved with JavaScript.
I agree. It is mostly a solution looking for a problem and has close to the same functional downsides as Flash or Applets other than "transparency".
Its 'sandbox' is also escapeable at both the engine level in V8, Gecko and JavaScriptCore (All in C/C++) and at the implementation level; especially if the software was converted from C to WASM.
So it is not the silver bullet people think it is.
Many moons ago I was preparing for an interview to join wasmer, back then they showed me that by running wasmer as a kernel extension in Linux they have made it run four orders of magnitude (10,000 times) faster. Given the WASI, I keep thinking more than the plugin usability of things like wasmer, what is the point of WASM not being accepted as a second binary in all operating systems? Windows could support .exe as well as .wasm for example and we would finally have a cross-plaform binary. Apple would never accept; Microsoft will do, and Linux can simply have,
Such speedup is not plausible at all. It had to be a flawed benchmark relying on some API being very slow in userspace (probably on purpose, not using it the right way). The raw execution speed of WASM can't change much just because it is in a kernel.
That's probable, though if we want to give them the benefit of the doubt, it could be a non-optimised benchmark, ie, something that may be written during the average devoper might ordinarily write, rather than hyper-optimised code specifically for that benchmark.
What they had done was wiring kernel level operations, without any of the userspace security checks into the wasmer. Their logic was that given the sandbox of wasmer; what would happen if you removed the sandbox of the OS? And I remember their article was featured in HN for two days or so as well. It was interesting. It wasn't that WASM ran faster than C, it was the API calls. And I keep wondering about an architecture where you have a highly sandboxed universal assembly with some API hardening; a middle ground, and so imagine an app that ran everywhere and was 10~100 times faster. Could be really cool.
Yes, it's not a new idea. See Microsoft Singularity research OS for a more recent example.
You would still have slower than native execution speed, security problems with Spectre attacks (in HW process isolation it's avoided by not having other memory mapped at all, other mitigations exist but they cost a lot of performance).
Syscall speedups affect only specific programs or stupidly written SW like some games that are checking current time many many times per frame.
It's not just syscalls. If you trust all of the running code, you can use a single address space for all applications and even the kernel, which lets you avoid TLB flushes.
Whether that's still a good idea given Spectre is another question.
Judging by the slow speed of node here, I wonder if it was run without forcing optimizations. It doesn't do OSR (on-stack replacement), meaning that a benchmark script doesn't get a chance to tier up from the baseline compiler to the fully optimized tier.
Running with
node --no-liftoff
avoids this problem.
(This is not an issue on the Web, where code must return to the event loop anyhow, allowing tiering up to work, and node is optimized for that kind of workflow.)
We have some more comprehensive benchmarks at https://r-carissimi.github.io/wasure/, with fairly different results.
libsodium is very numeric operation heavy IIRC
What are the numbers in that table? Is higher better or is higher worse? How does fully native C compare? What options are you using?
Edit: ah, higher numbers are better. But that fact is hidden way down in a block of text behind a collapsed details view.
Was there a sign saying “beware of the leopard”?
Curious where my wasm2go would stand compared to wazero. I should test it myself. :)
https://github.com/ncruces/wasm2go
Seconding this as a brilliant project!
Shameless self promotion here but I’m currently using wasm2go to build a native Go runtime for MicroPython https://github.com/gregfurman/micropython-go
Thanks for the kind words!
Added you to my users page a couple days ago, hope you don't mind: https://github.com/ncruces/wasm2go/blob/main/USERS.md
It's genuinely great to see WASM runtimes are getting closer to native code while being sandboxed, but these benchmarks assume you're not bundling a whole Runtime + GC + stdlib inside the sandbox.
One fairly revealing microbenchmark for WASM runtimes is `int8` dot products & angular/cosine distances.
(My) NumKong [1] has implementations targeting both vanilla AVX2/Haswell and AVX2-VNNI/Alder Lake, which makes it easy to see where runtimes and code generators leave performance on the table.
I started a few Wasmtime/Cranelift PRs around this, but didn’t manage to finish them :facepalm: Might be a fun weekend project for someone interested in backend/codegen work.
[1]: https://github.com/ashvardanian/NumKong
It'd be nice to see memory use. Ideally base usage, then cost of running 1 of a thing, then cost of running 50 if a thing.
Personally low my 50% speed vs native does not sound like the worst to me. I've spent years using perl, java (in v4-v7 days), node... These have various ways they are less good than native, and we collectively seem to accept that. Ideally yes wasm gets faster but a 2x is pretty ok!
WAVM in Rust? WAVM does not yet support ARM MTE or RISC-V CHERI?
wasmtime-mte could be added to the benchmark.
[flagged]
My only issue with WASM is that it forces me to contort my platform abstraction later to terrible web APIs. Other than that it's great. I can compile C++ with plain clang or the WASI SDK, and it runs everywhere at near native speeds with minimal boilerplate.
In my opinion, WebAssembly just needs to be better than what it replaced (asm.js) to be called a success story. And it definitely is better than asm.js.
Unlike HTML or CSS or JavaScript which are by definition large enabling technologies that enable completely new things, WASM is always that small step to make C/C++ and other native languages usable on the web. I never thought of WASM as a magic wand that makes web apps super fast and you probably shouldn’t.
>In my opinion, WebAssembly just needs to be better than what it replaced (asm.js) to be called a success story.
That would be only true if WASM was meant as a transitionary technology. But it has been with us for more than a decade, and it's only so-so. And if you think this, what do you think should replace it?
I have a couple ideas.
Is speeding up apps an aim of WebAssembly? I’m not being sarcastic… most of the slowdown you see in webapps is due to the DOM and/or network latency and WebAssembly offers nothing new there. The JavaScript language is very rarely the reason why an app is slow.
I’ve used WebAssembly to great success creating a unified codebase that runs on Node, an iOS app and on the web. It’s a niche but in that area it opens doors that were previously impossible to open.
Obviously it is, I've been writing a scientific library that runs in-browser and WebAssembly has been a blessing, it's easily 10x faster than the backend Python code it replaced, and 2-5x faster than I could achieved with JavaScript.
OP said:
> We still don't have all applications running super-fast on the web. This is a failure.
My point is that the vast majority of webapps do not rely on specific scientific libraries doing complex calculations.
You have probably run WebAssembly without noticing it, I would call that a success.
I agree. It is mostly a solution looking for a problem and has close to the same functional downsides as Flash or Applets other than "transparency".
Its 'sandbox' is also escapeable at both the engine level in V8, Gecko and JavaScriptCore (All in C/C++) and at the implementation level; especially if the software was converted from C to WASM.
So it is not the silver bullet people think it is.
[0] https://nvd.nist.gov/vuln/detail/cve-2026-11645
[1] https://issues.chromium.org/issues/334120897
[2] https://trustsig.eu/blog/wasm2c-tableflip-unchecked-calloc/