4 ms·

I like asm.js and have used it (http://wry.me/hacking/Turing-Drawings/ http://wry.me/hacking/Turing-Drawings/ ). But I understand the basic case for 'web byteco

I like asm.js and have used it (http://wry.me/hacking/Turing-Drawings/ http://wry.me/hacking/Turing-Drawings/ ). But I understand the basic case for 'web bytecode' to be this: software fault isolation and portable low-level distribution formats have both been demonstrated showing considerably less overhead than the roughly 2x of current asm.js, going back to the 90s (e.g. http://www.eecs.harvard.edu/~greg/cs255sp2004/wahbe93efficient.pdf http://www.eecs.harvard.edu/~greg/cs255sp2004/wahbe93efficie... and http://en.wikipedia.org/wiki/Architecture_Neutral_Distribution_Format http://en.wikipedia.org/wiki/Architecture_Neutral_Distributi... ). asm.js will improve, and it has a great adoption path, but it hasn't yet been shown to run as fast as that old work claimed to have done.

azakai 14y ago
To be fair, the 2x figure was from a few months ago, and was from the very first prototype of OdinMonkey (asm.js optimizations) in Firefox. Things have improved since then and will continue to do so, see http://arewefastyet.com/#machine=12&view=breakdown&suite=asmjs-ubench http://arewefastyet.com/#machine=12&view=breakdown&s... http://arewefastyet.com/#machine=12&view=breakdown&suite=asmjs-apps http://arewefastyet.com/#machine=12&view=breakdown&s... for more current numbers. Many are better than 2x slower than native. The first prototype was basically a few months of work by 1 engineer specifically on OdinMonkey, building on a few years of work on the more general IonMonkey optimizing compiler. Those are far far smaller amounts of time than have been spent on compilers like gcc and clang, so it is not surprising there is a performance difference. But it will get much smaller.