asm.js is JavaScript. It executes according to the semantics specified in ECMA-262.
The 2x performance numbers for OdinMonkey are not "best case": they include compilation time and will certainly improve (they are better now already).
Regarding having a "real IR", throwing away backwards compatibility for surface syntax doesn't work on the Web. It was tried, with XHTML 2.0 for example. It failed.
> asm.js is JavaScript. It executes according to the semantics specified in ECMA-262.
No, it's a strictly defined text-encoded bytecode that happens to be representable using a subset of valid JavaScript. If you deviate from the standard using valid JavaScript, you lose the gains.
Calling it "JavaScript" is just a semantic game. You can't output arbitrary but fully 100% standards-compliant JavaScript from a compiler and expect asm.js to do anything meaningful.
> Regarding having a "real IR", throwing away backwards compatibility for surface syntax doesn't work on the Web. It was tried, with XHTML 2.0 for example. It failed.
The irony is that these things fail because of the people who wish to maintain the status quo, and then those same people point to the failure as justification for maintaining the status quo.
It's not like you folks at Mozilla couldn't get support for a "real IR" from Google/Chrome -- that's half the market right there. In fact, the actual problem is that Google could never get support from you.
> If you deviate from the standard using valid JavaScript, you lose the gains.
That's true for lots of JavaScript optimizations. JS optimization is all about speculation that the more dynamic features won't be used. Try adding calls to "eval" within a JavaScript function in any modern JS engine and watch its performance drop by an order of magnitude. Does that make functions that don't use "eval" no longer JavaScript? After all, adding a call to the standardized function "eval" negates the performance benefits of "eval"-less JS.
asm.js is just this principle writ large.
> Calling it "JavaScript" is just a semantic game.
No, it means that asm.js is backwards compatible. That is not a game; that is the entire point. That is why asm.js worked in Chrome (with good performance even!) from day one.
> It's not like you folks at Mozilla couldn't get support for a "real IR" from Google/Chrome -- that's half the market right there. In fact, the actual problem is that Google could never get support from you.
Because PNaCl is not a good idea for Web content. People have this idea that Mozilla knows PNaCl is "better" than asm.js, but Mozilla wants to stick to JS out of some sort of pride or NIH syndrome. This is not the case. Backwards compatibility is the main advantage of asm.js, of course. But there are also many others: LLVM IR is a compiler IR and was not designed for this; asm.js is smaller when gzipped than LLVM bitcode; asm.js compiles faster than PNaCl; asm.js can reuse the JavaScript infrastructure, leading to a smaller, simpler browser; asm.js does not have the Pepper API which reimplements all of the Web APIs in underspecified ways.
Maybe it's time to go back to the HotJava[1] approach and use Java bytecode as the canonical "bytecode for the Web".
OK, to be fair, the browser itself doesn't really need to be written in Java. But other than Javascript, (and maybe Flash, I suppose) Java bytecode probably has the most penetration as a mechanism for delivering "programs" over the web. Maybe we should just embrace it...
The 2x performance numbers for OdinMonkey are not "best case": they include compilation time and will certainly improve (they are better now already).
Regarding having a "real IR", throwing away backwards compatibility for surface syntax doesn't work on the Web. It was tried, with XHTML 2.0 for example. It failed.