3 ms·
I think Lemire's measurements are unacceptably lazy. WebAssembly is faster than JavaScript on the right things; there are many measurements showing this. Typica
by titzer 5y ago
I think Lemire's measurements are unacceptably lazy. WebAssembly is faster than JavaScript on the right things; there are many measurements showing this. Typically, measurements that show JS on par or beating Wasm either end up falling into microbenchmarking traps (one small, hot loop, something gets deadcode-eliminated), or they end up relying on a particular type of dynamic optimization that Wasm engines don't yet do (inlining, escape analysis).
With SIMD and threads, Wasm can absolutely crush JS performance.
https://www.infoq.com/articles/webassembly-simd-multithreading-performance-gains/ https://www.infoq.com/articles/webassembly-simd-multithreadi...
- native_samples 5y agoIsn't SIMD new in this release of the spec? How can WASM crush JS using SIMD if they only just added support?
- titzer 5y agoIt's been implemented in browsers for longer than the spec has been out. In fact, one condition of a proposal being merged into the spec is that two production engines must have implemented it.
- torginus 5y agoWhy would Wasm engines need to do inlining and dead code elimination? My impression was that Wasm is basically native level-code, save for register allocation, and some arch-specific peephole optimizations. Dead code elimination is the job of the C++ compiler.
- titzer 5y agoGenerally, I don't disagree, but not all producers are LLVM. And JS inlining is driven by dynamic heuristics, speculatively inlining likely candidates, whereas statically-compiled C++ code generally doesn't have speculative inlining. So a Wasm call_indirect will not get dynamically optimized into a guarded inline.