4 ms·

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

by 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.
- mraleph 14y ago
  Nope, that is not what I say. 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.
  - acqq 14y ago
    "if everything that is needed can be implemented" 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.
    - mraleph 14y ago
      > 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?

by mraleph 14y ago

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.

mraleph 14y ago
Nope, that is not what I say. 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.
- acqq 14y ago
  "if everything that is needed can be implemented" 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.
  - mraleph 14y ago
    > 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?