Other than rehashing the exact arguments and diagrams presented in the mozilla marketing material and including an extensive "interview" with a mozilla engineer:
- I would have expected him to have tried it. There's no evidence in the post that he even fired up firefox nightly and ran even a simple test. The performance graph is straight out of asm.js marketing material
- In discussing chrome's performance, he just writes "A 4-10x performance difference is substantial" without explaining why chrome's performance suffers so much relative to firefox without asm.js (take the skinning demo. Why is chrome significantly worse than firefox?) This is a point that many have discussed, including some here in various posts about asm.js
- Certain sentences seem artificial. If you've read other posts by him, does "It is interesting to see such a large performance chasm appearing between Asm.js and the current engines in Firefox and Chrome. A 4-10x performance difference is substantial (this is in the realm of comparing these browsers to the performance of IE 6). Interestingly even with this performance difference many of these Asm.js demos are still usable on Chrome and Firefox, which is a good indicator for the current state of JavaScript engines. That being said their performance is simply not as good as the performance offered by a browser that is capable of optimizing Asm.js code." sound like something he would write? At all?
- I did not run performance benchmarks on my system because Asm.js does not yet support OS X (which is my primary OS). I fully intend to run some tests, and hopefully make some of my own, when that time comes. In the meantime it's not really beneficial for me to just re-run the same benchmarks that others have run on those platforms.
- I thought this was obvious: Chrome and normal Firefox are so much slower because they do not explicitly optimize the Asm.js code path.
- That's complete nonsense. I can't believe I have to say this but yes, I wrote those sentences.
> - 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.
It's working on Mac OS X now. I've run the Citadel demo on my own Mac. (I'm a Mozilla employee so I had access to the demo. It should be made available to everyone some time soon.)
>- I thought this was obvious: Chrome and normal Firefox are so much slower because they do not explicitly optimize the Asm.js code path.
I think the parent was asking for an explanation for why Chrome does so much worse than the non-asm.js Firefox. Which I guess is kind of a weird question given that Chrome beats non-asm.js FF in one of the three benchmarks, and is roughly tied with it in another.
Overall Chrome does similar to Firefox in non-asm.js mode on most benchmarks - slower on some, faster on some. There are however a few where Chrome is significantly slower, we've filed bugs for those things.
The big difference is between Firefox+asm.js and both Firefox and Chrome.
"I did not run performance benchmarks on my system because Asm.js does not yet support OS X (which is my primary OS)."
Given the relative percentage of web developers who use OSX (which is certainly non-trivial), wouldn't you think it would have been wise to state that?
But I guess the more interesting question is: did you try it on a system that firefox nightly+asm.js runs on? If so, can you describe that process? Did you try writing some code by hand or try taking a dummy program and run it through emscripten?
Taking a step back, it just seems really strange (and certainly many others, if this involved some other company like microsoft or google) that you would talk about performance without trying it.
There hasn't been any shadow of a doubt that asm.js works -- and it's ok for a blog post to help explain what a piece of technology is about. It's a less-technical post, yes, but if that's what the author wants to write about, so be it.
The better question is if it's the right approach, which is what mraleph has been arguing, and it's a much more appropriate argument.
Please proceed. Explain how a discussion of performance by someone who didn't actually perform the test is somehow trolling or evil. I'd say the same thing if Resig used Google or Microsoft marketing material rather than running the tests.
