8 ms·

Ok, I'll bite. - 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 som

by jeresig 14y ago

Ok, I'll bite. - 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.

mistercow 14y ago
>- 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.
- jeresig 14y ago
  Ah! In that case I'm not sure - but according to mraleph's comment above it looks like there might be some issues in V8 for some of the benchmarks: https://code.google.com/p/v8/issues/detail?id=2223 https://code.google.com/p/v8/issues/detail?id=2223
  - azakai 14y ago
    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. http://kripken.github.com/mloc_emscripten_talk/#/27 http://kripken.github.com/mloc_emscripten_talk/#/27
niggler 14y ago
Thanks for replying. "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.
- jlongster 14y ago
  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.
mraleph 14y ago
> - 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 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.
- jeresig 14y ago
  If others have not read the parent's blog post on Asm.js, I highly recommend it: http://mrale.ph/blog/2013/03/28/why-asmjs-bothers-me.html http://mrale.ph/blog/2013/03/28/why-asmjs-bothers-me.html I also largely agree with Jason's comment on that post: http://mrale.ph/blog/2013/03/28/why-asmjs-bothers-me.html#comment-845480388 http://mrale.ph/blog/2013/03/28/why-asmjs-bothers-me.html#co... 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).
- acqq 14y ago
  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.
nnethercote 14y ago
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.)

by jeresig 14y ago

mistercow 14y ago

>- 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.

jeresig 14y ago
Ah! In that case I'm not sure - but according to mraleph's comment above it looks like there might be some issues in V8 for some of the benchmarks: https://code.google.com/p/v8/issues/detail?id=2223 https://code.google.com/p/v8/issues/detail?id=2223
- azakai 14y ago
  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. http://kripken.github.com/mloc_emscripten_talk/#/27 http://kripken.github.com/mloc_emscripten_talk/#/27

niggler 14y ago

Thanks for replying. "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.

jlongster 14y ago
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.

mraleph 14y ago

> - 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 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.

jeresig 14y ago
If others have not read the parent's blog post on Asm.js, I highly recommend it: http://mrale.ph/blog/2013/03/28/why-asmjs-bothers-me.html http://mrale.ph/blog/2013/03/28/why-asmjs-bothers-me.html I also largely agree with Jason's comment on that post: http://mrale.ph/blog/2013/03/28/why-asmjs-bothers-me.html#comment-845480388 http://mrale.ph/blog/2013/03/28/why-asmjs-bothers-me.html#co... 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).
acqq 14y ago
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.

nnethercote 14y ago

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.)