3 ms·
> I don't think there's any reason for asm.js to have resulted in slower execution than Wasm The perfect article: https://hacks.mozilla.org/2017/03/why-webasse
by IshKebab 10mo ago
> I don't think there's any reason for asm.js to have resulted in slower execution than Wasm
The perfect article: https://hacks.mozilla.org/2017/03/why-webassembly-is-faster-than-asm-js/ https://hacks.mozilla.org/2017/03/why-webassembly-is-faster-...
Honestly the differences are less than I would have expected, but that article is also nearly a decade old so I would imagine WASM engines have improved a lot since then.
Fundamentally I think asm.js was a fragile hack and WASM is a well-engineered solution.
- gr4vityWall 10mo agoAfter reading the, I don't feel convinced abtout the runtime performance advantages of WASM over asm.js. he CPU features mentioned could be added to JS runtimes. Toolchain improvements could go both ways, and I expect asm.js would benefit from JIT improvements over the years. I agree 100% with the startup time arguments made by the article, though. No way around it if you're going through the typical JS pipeline in the browser. The argument for better load/store addressing on WASM is solid, and I expect this to have higher impact today than in 2017, due to the huge caches modern CPUs have. But it's hard to know without measuring it, and I don't know how hard it would be to isolate that in a benchmark. Thank you for linking it. It was a fun read. I hope my post didn't sound adversarial to any arguments you made. I wonder what asm.js could have been if it was formally specified, extended and optimized for, rather than abandoned in favor of WASM.
- IshKebab 10mo agoWhatever it would have ended up like it would have been a big hack so I'm glad everyone agreed to go with a proper solution for once!