Man, we are bringing a giant load of complexity into the browser with this. As I understand it, what we get in return is a 2x speed increase. I wonder if its worth it.
What complexity? It's just a new frontend for the complex tiered interpreter-and-JIT-compiler monstrosities that JS engines have.
A massively simpler frontend than JS itself — it's closer to, well, assembly :) while JS is a dynamic language.
What we get in return is very very close to native execution speed for all the performance-sensitive things you might want to run on a computer — game engines, crypto, compression, codecs, etc. — in a sandboxed and portable way. One executable for everything from the typical Windows/amd64 desktop to your NetBSD/mips toaster, potentially.
We are potentially removing the complexity at all ends.
Right now the chain is: Developer writes code in something like Typescript that then is translated to Javascript and then is downloaded by the browser (huge downloads compared to binary code). The browser then needs to parse that huge amount of javascript code to compile it into a bytecode that can then be JIT executed or interpreted.
With webassembly it would be as follows:
Developer writes code in the language of his/her choice, that then is compiled to a small bytecode. This bytecode is downloaded by the browser and then it is JIT executed or interpreted.
It is simpler, more flexible, and potentially faster.
As I understand it, potential performance gains are higher than 2x, and we're still in a pretty early stage. It depends on your application.
Also, as has been mentioned by others, WebAssembly could perhaps evolve to take a greater role, leading to a greater potential impact of performance gains.
Finally, if the complexity does in fact outweigh the benefit, the idea would eventually fade away. So far it looks promising. Time will tell.
These are already old numbers, and section 7.3 says 33.7% more efficient. Were one to run updated numbers, and use more than Chrome and Firefox, I'm pretty sure the numbers would be better still.
I note that the comment in 7.3 says the biggest speedup vs asm.js is in validation, so I assume this means the measurement includes startup. This advantage is easy to concede to WebAssembly due to its design.
FWIW I trust that the numbers were good when the Google and Mozilla folks gathered them, but I had nothing to do with numbers!
In particular, I haven't looked into validation. JSC doesn't treat asm.js any differently than JavaScript, so the comparison would be different as well.
Comments
Man, we are bringing a giant load of complexity into the browser with this. As I understand it, what we get in return is a 2x speed increase. I wonder if its worth it.
What complexity? It's just a new frontend for the complex tiered interpreter-and-JIT-compiler monstrosities that JS engines have.
A massively simpler frontend than JS itself — it's closer to, well, assembly :) while JS is a dynamic language.
What we get in return is very very close to native execution speed for all the performance-sensitive things you might want to run on a computer — game engines, crypto, compression, codecs, etc. — in a sandboxed and portable way. One executable for everything from the typical Windows/amd64 desktop to your NetBSD/mips toaster, potentially.
It's quite a bit more than a frontend, but I agree it isn't as complex as the JS engine itself. For comparison, this is the JSC wasm implementation: https://github.com/WebKit/webkit/tree/master/Source/JavaScri...
We are potentially removing the complexity at all ends.
Right now the chain is: Developer writes code in something like Typescript that then is translated to Javascript and then is downloaded by the browser (huge downloads compared to binary code). The browser then needs to parse that huge amount of javascript code to compile it into a bytecode that can then be JIT executed or interpreted.
With webassembly it would be as follows:
Developer writes code in the language of his/her choice, that then is compiled to a small bytecode. This bytecode is downloaded by the browser and then it is JIT executed or interpreted.
It is simpler, more flexible, and potentially faster.
That's assuming the old ways are deprecated and removed.
There's countries in the world that still use IE6, and that's comparatively an easier transition :)
As I understand it, potential performance gains are higher than 2x, and we're still in a pretty early stage. It depends on your application.
Also, as has been mentioned by others, WebAssembly could perhaps evolve to take a greater role, leading to a greater potential impact of performance gains.
Finally, if the complexity does in fact outweigh the benefit, the idea would eventually fade away. So far it looks promising. Time will tell.
Where does even the 2x come from? Currently it looks very much like 1x vs integer hinted JS code like generated by asm.js.
That is incorrect. See: https://github.com/WebAssembly/spec/blob/master/papers/pldi2...
These are already old numbers, and section 7.3 says 33.7% more efficient. Were one to run updated numbers, and use more than Chrome and Firefox, I'm pretty sure the numbers would be better still.
Very interesting looking paper, thanks.
I note that the comment in 7.3 says the biggest speedup vs asm.js is in validation, so I assume this means the measurement includes startup. This advantage is easy to concede to WebAssembly due to its design.
FWIW I trust that the numbers were good when the Google and Mozilla folks gathered them, but I had nothing to do with numbers!
In particular, I haven't looked into validation. JSC doesn't treat asm.js any differently than JavaScript, so the comparison would be different as well.