4 ms·

If you make changes to your site that make both IE6 and all other browsers fast, then what are you optimizing for? Because this is what is happening. asm.js i

by mraleph 13y ago

If you make changes to your site that make both IE6 and all other browsers fast, then what are you optimizing for? Because this is what is happening. asm.js is as a monolith: "use asm" in the foundation and a pyramid of typing rules, take one out everything crumbles. Right now V8 does not use "use asm" nor relies on any static typing (beyond what can be derived from JavaScript specification). For example when V8 improves its optimization pipeline to handle coercion of boolean to integer inline this helps asm.js code, but it also helps anyone doing this operation outside of asm.js specification compliant code. This coercion rule is just a part of the language, so I really see this as optimization of JavaScript as whole.

mercurial 13y ago
> If you make changes to your site that make both IE6 and all other browsers fast, then what are you optimizing for? If you specifically make changes to your site in order to make faster on IE6, and it also makes all other browsers fast, the "all other browsers" part is best described as a side-effect.
- andreypopp 13y ago
  > If you specifically make changes to your site in order to make faster on IE6, and it also makes all other browsers fast, the "all other browsers" part is best described as a side-effect. So did the v8 team do something specially to make asm.js faster? As mraleph said, the answer is no. So the fact that asm.js is now faster in Chrome is side-effect.
  - azakai 13y ago
    Again, the question is what you mean by "specifically". The v8 team look at asm.js benchmarks and make changes in v8 to make those benchmarks run faster, that's clear from their announcements. At the same time, those optimizations can also make other code faster, as they try to make them general optimizations as much as possible. So it's not true it's a "side-effect", since some of the time they literally start the process by looking at asm.js code, and finding how to make it run faster on v8. So asm.js is in a sense directly responsible for the optimization, and asm.js is sped up by it. But at the same time, the optimization added is - unlike Firefox's approach - relatively general, and helps other code too. In the end, I don't think there is any disagreement between us here.
azakai 13y ago
> If you make changes to your site that make both IE6 and all other browsers fast, then what are you optimizing for? This is really a philosophical debate at this point. All the one side is saying is that if a team of engineers focuses on making a certain type of code run fast (they look at that code, have benchmarks for it, find stuff that makes it run faster, etc.), then it is fair to say they are "optimizing for that type of code." While the other side is saying that if they write general optimizations that speed up not only that code but other code as well then they are "not optimizing for that type of code." Both sides are correct in what they mean. The only disagreement is in how to define the term "optimizing for." But as long as we all understand what we mean, there is no disagreement here at all. Yes, you are exactly correct that v8 does not notice "use asm", but yes, it is also correct that the v8 team has been optimizing for asm.js code, just as they optimize for typescript code (which like asm.js, Google deemed important enough to be put in Octane).
- mraleph 13y ago
  > just as they optimize for typescript code It's compiler itself that is in the Octane (though compiler itself is written in TypeScript). This particular benchmark pressures GC a lot and GC shares the top spot with a load from dictionary stub. TypeScript is on the different side of the scale compared to asm.js: it produces mostly what a normal human would write. This means normal prototypical inheritance, normal JS objects and so on. There is nothing really special about that. Though of course TypeScript compiler itself have performance profile atypical for a web application or game, it is a compiler after all. The hottest JavaScript function in this benchmark (if you skip GC and dictionary load) is Scanner.innerScan with 1% ticks. If you look at it you will see a typical scanner function most of compilers have. Any human would write it the same way, actually and the fact that it was written in TypeScript is irrelevant (compiler just stripped type annotations when it was compiling it). If you sum all this things together you will see why it is incorrect to say "X optimizes for Y" here.
  - azakai 13y ago
    Ok, I see your point, TypeScript is not a good example then, I did not analyze it in depth as you have. But my point still stands in general: Stuff in Octane is code that is intended to be optimized for, by definition. So recursive code, numerical computation code, asm.js code, Mandreel code, functional code, etc. etc. - browsers are optimizing for all of those, and different parts of Octane test each of those. edit: perhaps an even more specific example is the regex stuff in Octane and SunSpider, they test something very narrow. Likewise GC tests that pretty much require a generational GC to be fast, they also test something very specific. While the TypeScript test, as you said, is more general.
pcwalton 13y ago
> If you make changes to your site that make both IE6 and all other browsers fast, then what are you optimizing for? You still optimized for IE6. It just so happened that your optimizations made your site faster in other browsers too.
- mraleph 13y ago
  In this case I would better say that IE6 was a motivational example that caused me to find a performance bottleneck affecting all sites. I optimized bottleneck away.

by mraleph 13y ago

mercurial 13y ago

> If you make changes to your site that make both IE6 and all other browsers fast, then what are you optimizing for? If you specifically make changes to your site in order to make faster on IE6, and it also makes all other browsers fast, the "all other browsers" part is best described as a side-effect.

andreypopp 13y ago
> If you specifically make changes to your site in order to make faster on IE6, and it also makes all other browsers fast, the "all other browsers" part is best described as a side-effect. So did the v8 team do something specially to make asm.js faster? As mraleph said, the answer is no. So the fact that asm.js is now faster in Chrome is side-effect.
- azakai 13y ago
  Again, the question is what you mean by "specifically". The v8 team look at asm.js benchmarks and make changes in v8 to make those benchmarks run faster, that's clear from their announcements. At the same time, those optimizations can also make other code faster, as they try to make them general optimizations as much as possible. So it's not true it's a "side-effect", since some of the time they literally start the process by looking at asm.js code, and finding how to make it run faster on v8. So asm.js is in a sense directly responsible for the optimization, and asm.js is sped up by it. But at the same time, the optimization added is - unlike Firefox's approach - relatively general, and helps other code too. In the end, I don't think there is any disagreement between us here.

azakai 13y ago

> If you make changes to your site that make both IE6 and all other browsers fast, then what are you optimizing for? This is really a philosophical debate at this point. All the one side is saying is that if a team of engineers focuses on making a certain type of code run fast (they look at that code, have benchmarks for it, find stuff that makes it run faster, etc.), then it is fair to say they are "optimizing for that type of code." While the other side is saying that if they write general optimizations that speed up not only that code but other code as well then they are "not optimizing for that type of code." Both sides are correct in what they mean. The only disagreement is in how to define the term "optimizing for." But as long as we all understand what we mean, there is no disagreement here at all. Yes, you are exactly correct that v8 does not notice "use asm", but yes, it is also correct that the v8 team has been optimizing for asm.js code, just as they optimize for typescript code (which like asm.js, Google deemed important enough to be put in Octane).

mraleph 13y ago
> just as they optimize for typescript code It's compiler itself that is in the Octane (though compiler itself is written in TypeScript). This particular benchmark pressures GC a lot and GC shares the top spot with a load from dictionary stub. TypeScript is on the different side of the scale compared to asm.js: it produces mostly what a normal human would write. This means normal prototypical inheritance, normal JS objects and so on. There is nothing really special about that. Though of course TypeScript compiler itself have performance profile atypical for a web application or game, it is a compiler after all. The hottest JavaScript function in this benchmark (if you skip GC and dictionary load) is Scanner.innerScan with 1% ticks. If you look at it you will see a typical scanner function most of compilers have. Any human would write it the same way, actually and the fact that it was written in TypeScript is irrelevant (compiler just stripped type annotations when it was compiling it). If you sum all this things together you will see why it is incorrect to say "X optimizes for Y" here.
- azakai 13y ago
  Ok, I see your point, TypeScript is not a good example then, I did not analyze it in depth as you have. But my point still stands in general: Stuff in Octane is code that is intended to be optimized for, by definition. So recursive code, numerical computation code, asm.js code, Mandreel code, functional code, etc. etc. - browsers are optimizing for all of those, and different parts of Octane test each of those. edit: perhaps an even more specific example is the regex stuff in Octane and SunSpider, they test something very narrow. Likewise GC tests that pretty much require a generational GC to be fast, they also test something very specific. While the TypeScript test, as you said, is more general.

pcwalton 13y ago

> If you make changes to your site that make both IE6 and all other browsers fast, then what are you optimizing for? You still optimized for IE6. It just so happened that your optimizations made your site faster in other browsers too.

mraleph 13y ago
In this case I would better say that IE6 was a motivational example that caused me to find a performance bottleneck affecting all sites. I optimized bottleneck away.