> - I thought this was obvious: Chrome and normal Firefox are so much slower because they do not explicitly optimize the Asm.js code path.
Not everything is obvious here, actually.
If we are talking about vertex skinning benchmark where the difference between asm.js performance and Chrome's performance looks most "impressive" then a lot of that difference is caused by various bugs and limitations in V8's optimizing compiler: https://code.google.com/p/v8/issues/detail?id=2223
The same issues can easily affect other JavaScript code.
I personally strongly believe that one does not need to "explicitly optimize Asm.js code path" in the meaning "have a separate compilation pipeline for Asm.js code" to make asm.js code faster. All that one needs is to fix things that were neglected during JS VMs evolution.
I see no reason why these efforts can't run in parallel - as certain optimizations are needed to improve execution performance standardize them and expose them to user-written JavaScript.
I'll say that I would be totally happy if Asm.js was nothing more than a line drawn in the sand that all the browser vendors then aspired to match with normal JavaScript. Knowing what is theoretically possible in a browser is a huge motivator (as was seen in the last browser JS performance war of 2008/2009).
What you say is "One can make a JIT that ignores a single-line declaraton that defines a lot of assumpions. Then that same JIT can do a lot of analysis around, inserting even run-time checks, eventually to get the chance to come to most of the conclusions implied by the very line it ignored." Technically it is possible, practically, it is just as nonsensical as it sounds.
If you have some reasons that aren't technical, I can understand that. Otherwise, your insistence on ignoring "asm.js" can't be rationalized.
I am saying that if JS VMs already do a lot of optimizations which are not going to disappear anywhere even with "use asm" because they benefit normal JavaScript code. Now if JS VMs solve a range of known issues in implemented optimizations, fix known bugs, lift known limitations and then additionally implement certain optimizations then this would greatly improve performance of normal JavaScript code including its subset used by asm.js.
I don't understand desire to have another compilation pipeline on the side, if everything that is needed can be implemented in the main compilation pipeline and benefit JavaScript as whole, without restraining users to a strongly typed subset. This also leads to an unnecessary duplication.
I also think that if you think that restraining is essential you should push for another execution platform (e.g. statically typed bytecode or language). That would be much more honest towards language users and language evolution as whole.
I've never seen anybody proving that. Asm.js guys however proved that using the declaration that specifies the very fixed assertions, it's simple to achieve significant benefits. Once again, ignoring the precise and explicit information which otherwise is too demanding to be deduced simply doesn't have sense unless you're motivated by some non-technical reasons. So why you resist something that's technically better?
Nobody says that you need "a lot" of new code, you have only to introduce the implementation which uses the fixed assertions promised by the "asm.js" declaration. Note that in the approach you propose not only that same functionality has to be implemented but much much more code that would be just there to try to deduce what's otherwise obvious from that one single line.
So engine developers should implement asm.js support now, it's independent of whatever they'd want to introduce for any other optimizations. This simple approach is already there and it's proved it's effective.
> Asm.js guys however proved that using the declaration that specifies the very fixed assertions
Well, C compilers proved that long ago, nothing novel here. It is obviously easier to compile statically typed languages to efficient code. Especially if your language is limited to arithmetic and memory operations and your input source code is actually output of a sophisticated optimizing compiler that performs high-level optimizations for you.
> which otherwise is too demanding to be deduced
Let me repeat: JS engines already spend time on, as you say, deducing all kinds of information. This is not going anywhere, unless you are willing to make all JavaScript slower.
Because it is not going anywhere I am essentially arguing that it should be fixed to correctly infer more useful information than it does right now. Are you suggesting that VMs should just stay essentially unfixed?
At this point the onus seems to be on the asm.js-specific-optimizations-aren't-needed crowd to show that they can get performance that's even remotely close to optimized asm.js when using only non-asm.js-specific optimizations. If so, yeah, implement that! That'd be the best of all possible worlds; but it seems unlikely that loosely-constrained language X is as optimizable (with a roughly similar amount of resources) as tightly-constrained language Y. To my understanding, it's not a matter of current JavaScript engines needing to be "fixed" so much as just that they operate on a different class of problems than asm.js optimizers do, and thus the range of possible achievements is different, too.
> I don't understand desire to have another compilation pipeline on the side, if everything that is needed can be implemented in the main compilation pipeline and benefit JavaScript as whole, without restraining users to a strongly typed subset. This also leads to an unnecessary duplication.
There is hardly any duplication. All the optimizing machinery is being reused entirely. asm.js code is fast because the existing IonMonkey code generation makes it fast.
The only new part is something - the OdinMonkey module - that type checks asm.js code, and if it validates, then it feeds that into the existing IonMonkey compiler, with the types that were discovered during type checking.
Not everything is obvious here, actually.
If we are talking about vertex skinning benchmark where the difference between asm.js performance and Chrome's performance looks most "impressive" then a lot of that difference is caused by various bugs and limitations in V8's optimizing compiler: https://code.google.com/p/v8/issues/detail?id=2223
The same issues can easily affect other JavaScript code.
I personally strongly believe that one does not need to "explicitly optimize Asm.js code path" in the meaning "have a separate compilation pipeline for Asm.js code" to make asm.js code faster. All that one needs is to fix things that were neglected during JS VMs evolution.