Sadly V8's dev team has yet to address the other problem that "use asm" solves - falling out of JIT sweet spots due to broken heuristics. If you maintain a large machine-generated JS codebase (like I do by proxy, with my compiler), it is a regular occurrence that new releases of Chrome (and Firefox, to be fair) will knock parts of your code out of the JIT sweet spot and suddenly start optimizing other parts. Sometimes code that was fast becomes slow for no reason, other times some slow code becomes fast and now you look at profiles and realize you need to remove caching logic or that your code will be faster if you remove an optimization.<p>The arms race never ends, and keeping up with it is a full-time job. asm.js fixes this, by precisely specifying the 'sweet spot' and giving you a guarantee that if you satisfy its requirements, <i>all</i> your code will be optimized, unless the VM is broken. This lets you build a compiler that outputs valid asm.js code, verify it, and leave it alone.<p>These days I don't even have time to keep up with the constant performance failures introduced by new releases, but JSIL is a nearly two-year-old project now and they cropped up regularly the whole time. Ignoring the performance failures isn't an option because customers don't want slow applications (and neither do I).
From what I understand writing fast javascript is hard because the engines are improving so fast no one knows what is fast yet. Thus asm.js is a promise to developers: "Stay within the subset and your javascript will be fast".<p>Yet it never was "use asm" which made asm.js fast. It was the js engine. "use asm" carries symantical knowledge so a browser can warn if you break out of the subset. It also serves as a strong hint that should make the optimizer's easier.<p>This is why I think asm.js is the future. Mozila does not need buy in from Google, or Apple, or MS. Instead developers can compile to asm.js and their code will run, and in time it will run faster.<p>So in effect Chrome supports arm.js but they are not making a promise. I think it would be better for the internet if they made this promise.
Getting the Citadel demo to run at 60fps is impressive. It means that V8 is "fast enough" to keep up with the video card on that application.<p>However, the benchmarks at [0] clearly show that this is not the end of the story. The "workload0" runs measure startup time. All the other workloads show runtime performance, and V8 is still quite a ways behind.<p>[0] <a href="http://arewefastyet.com/#machine=11&view=breakdown&suite=asmjs-apps" rel="nofollow">http://arewefastyet.com/#machine=11&view=breakdown&suite=asm...</a>
A point some people seem to be missing in this thread which I would like to emphasize is the value of <i>predictable</i> performance.<p>It is true that a JIT is in principle, capable of all the same things as an AOT compiler. It is true, that improving the speed of a JIT is valuable. However, that all glosses over the fact that a JIT is a black box. If I am working on an application <i>today</i> that has a mysterious slowdown after running for about 80 seconds, the promise that won't happen in <i>next year's</i> browser release is of no use to me whatsoever.<p>In fact, I would prefer the jit run at the same constant slow speed instead of starting out fast, giving a false sense of performance. I can OPTIMISE for that. I can work with that. I can't work with a JIT that can't decide how fast it's going to run, and why from release to release, from second to second. It's fine for most applications, but if I absolutely positively need to generate a frame at a constant fixed rate, an unpredictable JIT is a huge liability no matter how theoretically fast it can go on benchmarks. Stability trumps raw performance.
<a href="http://mrale.ph/blog/2013/03/28/why-asmjs-bothers-me.html" rel="nofollow">http://mrale.ph/blog/2013/03/28/why-asmjs-bothers-me.html</a> suggested that this would happen:<p>> When I sit down and think about performance gains that asm.js-implementation OdinMonkey-style brings to the table I don’t see anything that would not be possible to achieve within a normal JIT compilation framework and thus simultaneously make human written and compiler generated output faster.
I made the same experience with my hand optimized asm.js code.
<a href="http://s-macke.github.io/jor1k/" rel="nofollow">http://s-macke.github.io/jor1k/</a>
It runs as fast as asm.js in Firefox. Chrome is optimizing it really well.