Is there already a performance advantage with the current WASM implementations for number crunching code compared to writing plain Javascript?
My experience is that modern JS engines are already pretty good at optimizing that kind of code, so I'm wondering if there are still significant speedups to be had by using WASM, given that it's still pretty new and didn't have much time to get optimized further yet.
Depends if you measure against asm.js or handwritten Javascript, and on which browser.
For my emulator stuff (mostly bit twiddling on integers: https://floooh.github.io/tiny8bit/), I saw a very slight improvement of WASM vs asm.js on browsers that have special handling for asm.js (in the meantime I have dropped asm.js, and only compile to WASM, since all browsers support it).
On iOS Safari (which I guess doesn't have special asm.js handling) WASM is a whopping 3x..5x faster than running the same code compiled to asm.js.
The question now is how much slower 'idiomatic, handwritten Javascript' is on iOS Safari versus the same code written in C compiled to asm.js, but I think another 3x..5x slower is realistic.
> Is there already a performance advantage with the current WASM implementations for number crunching code compared to writing plain Javascript?
I may be out of date here, but IME neither JavaScript nor WASM is any good for actual "number crunching" (i.e. statistical or scientific code). For that, you want at least a compiler/language that uses the latest SIMD instructions and lets you choose 32- or 64-bit floats. Better still, you want one that automatically parallelizes loops (you may need to align your data), gives you cheap GPU access, and above all is simple enough that you can figure out why the compiler isn't performing the optimizations you expect.
Modern JS engines are pretty good at speeding up the weirdness that is JS, so maybe WASM will only have small benefits, but using either for numerical work would be making your life unnecessarily hard.
WASM does let you choose between 32 and 64 bit floats. SIMD and threading are mentioned in the article as things that are being worked on now.
GPU access is about browser APIs rather than being something tied to WASM. We have webgl now and it seems like there's more coming hopefully (https://github.com/gpuweb/gpuweb).
>and above all is simple enough that you can figure out why the compiler isn't performing the optimizations you expect.
Reading WASM seems easier to me than reading real assembly, so double-checking a WASM compiler's output seems much easier than double-checking a native compiler's output. Of course it's on the compilers to support WASM well, but hopefully that simplicity aids them too.
My experience is that modern JS engines are already pretty good at optimizing that kind of code, so I'm wondering if there are still significant speedups to be had by using WASM, given that it's still pretty new and didn't have much time to get optimized further yet.