I've written all my Advent of Code 2016 puzzles in Rust that I've then compiled to asm.js and WebAssembly and both asm.js and WebAssembly always outperformed the idiomatic JavaScript solutions by a factor of 10x and sometimes even up to 40x. Firefox has the best asm.js and wasm support, with Edge being the second fastest browser and Chrome being the slowest (I only tested those 3). WebAssembly is always faster by about 10% in all the browsers than asm.js. However asm.js supports vector instructions and wasm doesn't. So when your inner loops are vectorized your asm.js even runs as fast in Firefox as the same code compiled as native code.
Do you have a link to your puzzles or perhaps a blog entry with a more full write up of your findings? There are not too many examples like this in the wild yet and another data point would be interesting.
I also hoped to see a bigger improvement, but it turned out that Javascript is already very fast for nbody.
Maybe I should have picked a well known numeric benchmark where Javascript is still far behind - any suggestions for that? Or are the Javascript VMs already too good for numeric benchmarks?
You can try increasing `N` in the nbody problem, and also measuring the memory overhead.
You could also try one of the hashing / crypto algorithms in JS. They should involve a lot of integer arithmetic that should make WebAssembly stand out.
More tips:
* for performance measurement, setup the benchmark so that JS run takes atleast 30 seconds. (Increase N, etc)
* close all other applications and tabs
* If you have linux, set the CPU governor to performance
* Measure the CPU temperature and make sure you let the CPU cool down between runs. In modern CPUs, the cores get throttled automatically when they reach a certain temperature.
Probably yes ;) Javascript is already compiled down to machine code for quite a while. And if the code is very 'static' (like asm.js) the JS engine will leave the code alone, and the garbage collector will be inactive. Performance between asm.js and WebAssembly is pretty much the identical at the moment, with 10% to 20% disadvantage vs native there isn't that much room for drastic improvement. I think WebAssembly will mostly bring improvements for 64-bit integer operations and vector math, but for average integer and floating point code, JS is already very fast.
I think the biggest advantage of WASM will be predictable performance. E.g., no sudden garbage collector pauses, and more predictable across different browser brands (eventually).
Well remember, WebAssembly just a different representation format for the same instruction set, executed by the underlying virtual machine (v8, spidermonkey, etc). So you should expect to see much of a performance difference.
The main benefit of WebAssembly is so that we can write code using our favorite languages (not just javascript!) and compile to a common binary format the browser understands. The objectives of WebAssembly never had anything to do with performance.
> The main benefit of WebAssembly is so that we can write code using our favorite languages
JavaScript is already common format that browser understands and there are implementations for a lot of languages translating them to JavaScript. So WebAssembly definitely is about performance, because using other languages is already solved problem.
As far as I understand you can call JS APIs from WebAssembly, which means you use the already available DOM APIs. I don't know exactly what the calling convention from WASM to JS looks like, but I guess it's specified somewhere.
As a comparison, I wrote an identical program in both C++ and JavaScript. It was doing repeated calls to a kd-tree, and was CPU-limited in both cases. The JavaScript version was slower, but only by a factor of 5-7 or so. I was rather surprised, because I was expecting a factor of 100-500, as I get with C++/CPython.
I don't expect WebAssembly to improve much on the speed, because it is already pretty fast.
Javascript engines are fairly speedy compared to CPython; not only are they industrial-grade JITs (as opposed to CPython being a naive interpreter), but JS is an easier language to optimize. Further, WebAssembly has overhead.
The CPython interpreter has actually seen a lot of performance work, they've long been pushing the boundaries of interpreter optimizations that you can do portably & compatibly. I wouldn't describe it as a "naive interpreter".
The promise that WASM holds IMO is for portability, not (merely) performance. How cool is it that I could write a game or application or library in C/C++/Rust/golang/swift/etc and expect it to be able to run on any modern CPU but also a browser?
I wouldn't say that's "cool", that's just what browsers could do 20 years ago with Java applets and ActiveX. Lots of languages target the JVM and you can compile C to it as well if you're willing to treat memory as a large byte array (there is a project that runs JIT-compiles LLVM bytecode on the JVM even).
The article shows that WebAssembly implementations often struggle to match Java. I see no reason to believe that browsers are actually easier to secure than a JVM, especially Firefox which doesn't even really do renderer sandboxing. They seem about the same level of difficulty. All the browser guys have done here is reinvent the same concepts of 20 years ago with a different instruction set that has "Web" in the name.
Worth remembering this is an early version of WebAssembly that is semantically similar to ASM.JS. Further performance improvements are very likely, can see some of the planned improvements here:
JavaScript is not the slow beast it used to be; when Google built V8 when they introduced Chrome, javascript got seriously fast. A lot of improvements have been made since then.
