3 ms·

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

by 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.
  - mraleph 13y ago
    > 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. Yep. Now look at the list of these things. Do you see what it is in the sum? In the sum it is real-world JavaScript. Which is precisely reveals the goal: JavaScript should run fast. I think we are looping about this issue because we see different connotations in the sentence "optimize for asm.js". I see connotation "optimize for asm.js as described by it's specification (with AOT and stuff)", while what actually happens is that underlying JavaScript that serves as foundation for asm.js specification is being optimized. That is why I always prefer to say "asm.js-style code". > Likewise GC tests that pretty much require a generational GC to be fast Actually with Splay it is easier to be fast if you don't have a moving generational GC :-)
    - azakai 13y ago
      Ok, then I think we do understand each other. The only question then is what words to use to avoid confusion. So you are fully ok with the phrase "optimize for asm.js-style code"? I didn't mean splay necessarily ;) It is easy to make a benchmark that relies heavily on GGC or escape analysis.
      - mraleph 13y ago
        > So you are fully ok with the phrase "optimize for asm.js-style code"? I would say I am more OK with it as it highlights the fact that it's about spirit not about complete adherence to asm.js spec. Unfortunately there is no compact and at the same time clear way to say what V8 does right now, e.g. saying "optimizing for type stable code" is most accurate but does not help to understand what V8 actually does and how it relates to improvements on Emscripten output.

by azakai 13y ago

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.
- mraleph 13y ago
  > 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. Yep. Now look at the list of these things. Do you see what it is in the sum? In the sum it is real-world JavaScript. Which is precisely reveals the goal: JavaScript should run fast. I think we are looping about this issue because we see different connotations in the sentence "optimize for asm.js". I see connotation "optimize for asm.js as described by it's specification (with AOT and stuff)", while what actually happens is that underlying JavaScript that serves as foundation for asm.js specification is being optimized. That is why I always prefer to say "asm.js-style code". > Likewise GC tests that pretty much require a generational GC to be fast Actually with Splay it is easier to be fast if you don't have a moving generational GC :-)
  - azakai 13y ago
    Ok, then I think we do understand each other. The only question then is what words to use to avoid confusion. So you are fully ok with the phrase "optimize for asm.js-style code"? I didn't mean splay necessarily ;) It is easy to make a benchmark that relies heavily on GGC or escape analysis.
    - mraleph 13y ago
      > So you are fully ok with the phrase "optimize for asm.js-style code"? I would say I am more OK with it as it highlights the fact that it's about spirit not about complete adherence to asm.js spec. Unfortunately there is no compact and at the same time clear way to say what V8 does right now, e.g. saying "optimizing for type stable code" is most accurate but does not help to understand what V8 actually does and how it relates to improvements on Emscripten output.