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.
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'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!
WebAssembly right now simply is not. Will it ever become a sound success story? There is so little impact it has made so far after almost 10 years. We still don't have all applications running super-fast on the web. This is a failure.
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.
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.
(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
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.)
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!
WebAssembly right now simply is not. Will it ever become a sound success story? There is so little impact it has made so far after almost 10 years. We still don't have all applications running super-fast on the web. This is a failure.
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.
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/