In SpiderMonkey, asm.js code has been compiled by exactly the same pipeline as wasm since at least 2019. In fact, the way we compile it is literally to construct a pseudo-wasm module and run it through our wasm compiler (with a few flags to tweak the behavior to fit the asm.js semantics). In other words, if you're running asm.js in Firefox, you're literally just running wasm anyway, so how could it possibly be faster?
Furthermore, if you use wasm, you'll have fewer bounds checks (because of better memory allocation strategies[1]), access to SIMD, bulk memory operations, and a host of other niceties that have been added to wasm over the years. If your asm.js code is outperforming someone else's wasm code, that probably just means their wasm code is worse.
Requires a secure origin. If you serve a local (but non-localhost) SPA over HTTP then you're blocked from using crypto.subtle.digest. At least, that is one reason I have seen a hand-rolled SHA-256 deployed.
In SpiderMonkey, asm.js code has been compiled by exactly the same pipeline as wasm since at least 2019. In fact, the way we compile it is literally to construct a pseudo-wasm module and run it through our wasm compiler (with a few flags to tweak the behavior to fit the asm.js semantics). In other words, if you're running asm.js in Firefox, you're literally just running wasm anyway, so how could it possibly be faster?
Furthermore, if you use wasm, you'll have fewer bounds checks (because of better memory allocation strategies[1]), access to SIMD, bulk memory operations, and a host of other niceties that have been added to wasm over the years. If your asm.js code is outperforming someone else's wasm code, that probably just means their wasm code is worse.
[1]: https://spidermonkey.dev/blog/2025/01/15/is-memory64-actuall...
yeah turns out it was chrome that was slow, not firefox.
wasm hashing in chrome is half the speed of firefox.
asmjs with optimizations enabled in firefox are about on par, which supports your statement.
https://theultdev.github.io/web-sha256-benchmark
Made the requested benchmark:
https://theultdev.github.io/web-sha256-benchmark
https://github.com/TheUltDev/web-sha256-benchmark
It's Chrome wasm (windows) that is slow for me, 2x slower than asmjs.
FF with asmjs optimizations are 2x slower than wasm on FF.
Wasm in FF is 2x faster than wasm in Chrome for this hashing solution (for me).
That is surprising. Do you know the reasons? Is it a special use case or was asm really faster? I find that hard to believe.
It's a custom solution, but nothing special just incremental hashing for large files.
I took off the shelf wasm crypto libraries to compare it, but the leading one was 10x slower.
can we see?
3 replies →
what's wrong with the built in one?
https://developer.mozilla.org/en-US/docs/Web/API/SubtleCrypt...
Requires a secure origin. If you serve a local (but non-localhost) SPA over HTTP then you're blocked from using crypto.subtle.digest. At least, that is one reason I have seen a hand-rolled SHA-256 deployed.
Edit: oh, and it forces async.
no incremental hashing, so you can't hash files too large for ram.
I do use it for smaller files though, it's much faster.