4 ms·
> Is there already a performance advantage with the current WASM implementations for number crunching code compared to writing plain Javascript? I may be out o
by username223 8y ago
> 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.
- AgentME 8y agoWASM 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 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.