4 ms·
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
by dwg 9y ago
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.
- zurn 9y agoWhere does even the 2x come from? Currently it looks very much like 1x vs integer hinted JS code like generated by asm.js.
- jfbastien 9y agoThat is incorrect. See: https://github.com/WebAssembly/spec/blob/master/papers/pldi2017.pdf 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.
- zurn 9y agoVery 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.
- jfbastien 9y agoFWIW 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.