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