Earlier quoted context omitted.
Even though it's using JavaScript as a kind of bytecode, it is just JavaScript / HTML5 (and some CSS, but that's pretty anedoctical I guess). Asm.js is a subset of JavaScript. As soon as Chrome fixes the crash, it'll run in a browser that supports just HTML5 (for presenting the page / the DOM / the canvas) and JavaScript with no special asm.js optimizations, and we'll have to see how fast/slow it is then. To correct…
I understand that. Take a read of this: http://mrale.ph/blog/2013/03/28/why-asmjs-bothers-me.html . I have a lot of respect for Egorov, and I agree with his views on this matter quite entirely. The sole benefit of embedding a bytecode in a language is that you get the side effect that it can run anywhere that language runs. But in general, this implies performance penalties, especially when the language is relatively…
> 2. It runs on browsers that don't know about asm.js, but it's effectively an emulated machine, and it's slow.
Do you have benchmark numbers to support that? In my experience, asm.js code is quite fast even without special asm.js optimizations. It depends on the benchmark obviously, but look at
http://kripken.github.io/mloc_emscripten_talk/#/27
Many of those benchmarks are very fast in browsers without special asm.js optimizations.
All they need to do to be fast on asm.js code is to optimize typed array operations and basic math, and those are things browsers have been doing for a long time. Google even added a Mandreel benchmark to Octane for this reason.
Emscripten and Mandreel output, with or without asm.js, tends to be quite fast, generally faster than handwritten code. asm.js is often faster than that, because it's easier to optimize, even without special optimizations for it. Those special optimizations can help even more, but they are not necessary for it to run, nor are things "slow/emulated" without them.