7 ms·

Firefox 9 uses type inference to improve JavaScript performance by 20-30%

123 points by 11031a 15y ago

thurn 15y ago
Excellent, I hope we can get this in Chrome pretty soon too.
- mrsebastian 15y ago
  Yea, I was thinking the same thing. Chakra (IE9) already has it, I think.
  - jmilloy 15y ago
    > Type Optimizations: One of the most important aspects of enabling performance on JavaScript is to create an efficient type system. The IE9 script engine uses many of the techniques common in modern dynamic language implementations, including type representation, polymorphic inline caching (also called type evolution or hidden classes), and efficient implementation of machine types. http://blogs.msdn.com/b/ie/archive/2010/03/18/the-new-javascript-engine-in-internet-explorer-9.aspx http://blogs.msdn.com/b/ie/archive/2010/03/18/the-new-javasc...
- DrJokepu 15y ago
  (edit: I have said something stupid, nothing to see here, move along)
  - ootachi 15y ago
    You're confusing Crankshaft with type inference. Crankshaft, which landed around Chrome 10, is an SSA-based optimization infrastructure. Type inference augments an optimization infrastructure with additional information. The two are complementary. V8 does not use type inference.
    - magicalist 15y ago
      I don't think that's quite correct. IonMonkey also uses an SSA-based intermediate representation, and Crankshaft does generate type specialized code (as does TraceMonkey). The big thing that IonMonkey is adding is type inference through static analysis, which is a big deal for JavaScript.
      - rayiner 15y ago
        He's correct. This type inference is actually being added to JaegerMonkey according to the article, though IonMonkey will have it too when it's ready. Crankshaft uses type feedback, not type inference. Ie: it will monitor the types of objects to generate type-specialized code, but will not do static type inference on the code to generate type-specialized code.
  - grantg 15y ago
    So you did ycombinator's version of [deleted]. :P
sjs 15y ago
> Other languages, like JavaScript, are weakly typed, which means that the programmer doesn’t have to worry about such piffling minutiae; you can just write some code and let the compiler do the heavy lifting. JavaScript isn't weakly typed, you can't for example "cast" a number to a string. There is automatic coercion but that's a different thing. I think he means dynamically typed in this case, that or duck typing. > Type inference fills in the gap between strong and weak typing so that you can still write sloppy code, but reap some of the speed boost. I don't even know what to say about this. Following this faulty logic might lead one to believe that Haskell has type inference to make all that sloppy Haskell code perform well. Type inference doesn't have anything to do with strong and weak typing, it has to do with manifest and implicit (or inherent) typing.
- m0th87 15y ago
  Automatic coercion is a part of weak typing [1], and JavaScript certainly is weakly typed ([2], first line). If you define the ability to cast as weak typing, then even C++ would be so. Obviously this definition does not hold. I don't get how the type inference remark is faulty logic either. Haskell is orthogonal because it is statically typed, but type inference when applied to dynamically typed languages certainly can provide a performance boost. 1: http://en.wikipedia.org/wiki/Weak_typing http://en.wikipedia.org/wiki/Weak_typing 2: http://en.wikipedia.org/wiki/JavaScript http://en.wikipedia.org/wiki/JavaScript
  - randomdata 15y ago
    > If you define the ability to cast as weak typing, then even C++ would be so. Which is funny because your first link states: "In C++, a weakly typed language, you can cast memory to any type freely as long as you do so explicitly." I'm pretty sure the last time I read that article it said that there is no generally accepted definition of weak typing. This discussion seems to echo that.
    - nickknw 15y ago
      > I'm pretty sure the last time I read that article it said that there is no generally accepted definition of weak typing. This discussion seems to echo that. Agreed. There ARE definitions but they aren't terribly specific, useful, or even very consistent. Funnily enough, the wikipedia article on strong typing includes C and C++ as an example of strong typing. In this case anyway, I think it's clear that the author was really talking about the static vs dynamic distinction, and should have used those terms instead: > Some languages are strongly typed, which means that the programmer must define the type of every class, function, and variable that he uses; tiresome, but it can have big pay-offs in terms of overall speed. Other languages, like JavaScript, are weakly typed, which means that the programmer doesn’t have to worry about such piffling minutiae; you can just write some code and let the compiler do the heavy lifting.
ori_b 15y ago
I'm surprised that this wasn't already done. It seems like it's relatively low hanging fruit.
- starwed 15y ago
  Some not very technical discussion of what was involved here: http://blog.mozilla.com/dmandelin/2011/04/22/mozilla-javascript-2011/ http://blog.mozilla.com/dmandelin/2011/04/22/mozilla-javascr... (Scroll down to the 'Type Inference' section) And somewhat more technical (although mostly about IonMonkey) here: https://bugzilla.mozilla.org/show_bug.cgi?id=650180 https://bugzilla.mozilla.org/show_bug.cgi?id=650180 -edit- Found actual 'Type Inference' bugzilla discussion: https://bugzilla.mozilla.org/show_bug.cgi?id=557407 https://bugzilla.mozilla.org/show_bug.cgi?id=557407
- ootachi 15y ago
  It's not low-hanging fruit at all. First, making it fast is extremely difficult. JavaScript compilers are under extreme pressure to compile code quickly, unlike any other type-inferring compiler, because JS compilation keeps the user from seeing the page. Second, in order to be useful, type inference for JavaScript has to be speculative. JS's semantics require that ints overflow into doubles, for example, meaning that a conservative type inference engine would have to assume every number can potentially be a double. This is too imprecise to be useful, so the inference engine speculates. If the engine guesses wrong, the compiler must not only recompile the function under the new assumptions but also (since this is a global analysis) potentially update every other function that the function called. Finally, the presence of eval() and the like mean that almost no inference can be totally sound, requiring even more dynamic checks. There's a reason that (despite what some others are saying in this thread) V8 and Chakra haven't done this yet: it takes a long time to get right.
  - masklinn 15y ago
    On the other hand, most of the dynamic checks (type assertion barriers) will be there anyway as the JIT-generated code needs them (for type-specialized traces). Static type inference may even allow for doing away with some, if it's possible to statically prove types are fully known at compile time for a code section.
natmaster 15y ago
They are confusing weak typing with static typing.
- tlrobinson 15y ago
  I almost wish I hadn't learned the distinction between strong/weak and static/dynamic typing, because it drives me crazy when people use the incorrect terminology.
Myrth 15y ago
> By the time Firefox 9 reaches the Aurora channel at the end of September, though, type inference should just make your web surfing 20-30% faster — period. Mmm.. I think they've forgot to factor in the ratio of JavaScript involvement in overall web surfing experience?
- masklinn 15y ago
  Since it's firefox we're talking about, this will likely (positively) impact the browser's own chrome and any extension you've installed, as well as in-page javascript.
simon_kun 15y ago
If you're interested in the relative performance of the current crop of JS engines, you may like to check http://arewefastyet.com/?a=b&view=regress http://arewefastyet.com/?a=b&view=regress for commit by commit benchmarking over time.
Joeri 15y ago
Mobile optimization fail. Their ipad-optimized version cuts off part of the content, and the well-hidden link to go to the desktop version doesn't work. And that's even sidestepping the whole issue that the interaction model of their ipad version is worse than that of a regular website. But it's nice to see that the race is still on, with each browser leapfrogging the others every once in a while.
- comex 15y ago
  Right, article is unreadable (doesn't scroll) on iPhone.
51Cards 15y ago
Interesting that I'm not seeing this on Are We Fast Yet? I thought that was always the bleeding edge JaegerMonkey specs.
- bzbarsky 15y ago
  You can see the TI+JM graph at http://arewefastyet.com/?a=b&view=regress http://arewefastyet.com/?a=b&view=regress

123 points by 11031a 15y ago

thurn 15y ago

Excellent, I hope we can get this in Chrome pretty soon too.

mrsebastian 15y ago
Yea, I was thinking the same thing. Chakra (IE9) already has it, I think.
- jmilloy 15y ago
  > Type Optimizations: One of the most important aspects of enabling performance on JavaScript is to create an efficient type system. The IE9 script engine uses many of the techniques common in modern dynamic language implementations, including type representation, polymorphic inline caching (also called type evolution or hidden classes), and efficient implementation of machine types. http://blogs.msdn.com/b/ie/archive/2010/03/18/the-new-javascript-engine-in-internet-explorer-9.aspx http://blogs.msdn.com/b/ie/archive/2010/03/18/the-new-javasc...
DrJokepu 15y ago
(edit: I have said something stupid, nothing to see here, move along)
- ootachi 15y ago
  You're confusing Crankshaft with type inference. Crankshaft, which landed around Chrome 10, is an SSA-based optimization infrastructure. Type inference augments an optimization infrastructure with additional information. The two are complementary. V8 does not use type inference.
  - magicalist 15y ago
    I don't think that's quite correct. IonMonkey also uses an SSA-based intermediate representation, and Crankshaft does generate type specialized code (as does TraceMonkey). The big thing that IonMonkey is adding is type inference through static analysis, which is a big deal for JavaScript.
    - rayiner 15y ago
      He's correct. This type inference is actually being added to JaegerMonkey according to the article, though IonMonkey will have it too when it's ready. Crankshaft uses type feedback, not type inference. Ie: it will monitor the types of objects to generate type-specialized code, but will not do static type inference on the code to generate type-specialized code.
- grantg 15y ago
  So you did ycombinator's version of [deleted]. :P

sjs 15y ago

> Other languages, like JavaScript, are weakly typed, which means that the programmer doesn’t have to worry about such piffling minutiae; you can just write some code and let the compiler do the heavy lifting. JavaScript isn't weakly typed, you can't for example "cast" a number to a string. There is automatic coercion but that's a different thing. I think he means dynamically typed in this case, that or duck typing. > Type inference fills in the gap between strong and weak typing so that you can still write sloppy code, but reap some of the speed boost. I don't even know what to say about this. Following this faulty logic might lead one to believe that Haskell has type inference to make all that sloppy Haskell code perform well. Type inference doesn't have anything to do with strong and weak typing, it has to do with manifest and implicit (or inherent) typing.

m0th87 15y ago
Automatic coercion is a part of weak typing [1], and JavaScript certainly is weakly typed ([2], first line). If you define the ability to cast as weak typing, then even C++ would be so. Obviously this definition does not hold. I don't get how the type inference remark is faulty logic either. Haskell is orthogonal because it is statically typed, but type inference when applied to dynamically typed languages certainly can provide a performance boost. 1: http://en.wikipedia.org/wiki/Weak_typing http://en.wikipedia.org/wiki/Weak_typing 2: http://en.wikipedia.org/wiki/JavaScript http://en.wikipedia.org/wiki/JavaScript
- randomdata 15y ago
  > If you define the ability to cast as weak typing, then even C++ would be so. Which is funny because your first link states: "In C++, a weakly typed language, you can cast memory to any type freely as long as you do so explicitly." I'm pretty sure the last time I read that article it said that there is no generally accepted definition of weak typing. This discussion seems to echo that.
  - nickknw 15y ago
    > I'm pretty sure the last time I read that article it said that there is no generally accepted definition of weak typing. This discussion seems to echo that. Agreed. There ARE definitions but they aren't terribly specific, useful, or even very consistent. Funnily enough, the wikipedia article on strong typing includes C and C++ as an example of strong typing. In this case anyway, I think it's clear that the author was really talking about the static vs dynamic distinction, and should have used those terms instead: > Some languages are strongly typed, which means that the programmer must define the type of every class, function, and variable that he uses; tiresome, but it can have big pay-offs in terms of overall speed. Other languages, like JavaScript, are weakly typed, which means that the programmer doesn’t have to worry about such piffling minutiae; you can just write some code and let the compiler do the heavy lifting.

ori_b 15y ago

I'm surprised that this wasn't already done. It seems like it's relatively low hanging fruit.

starwed 15y ago
Some not very technical discussion of what was involved here: http://blog.mozilla.com/dmandelin/2011/04/22/mozilla-javascript-2011/ http://blog.mozilla.com/dmandelin/2011/04/22/mozilla-javascr... (Scroll down to the 'Type Inference' section) And somewhat more technical (although mostly about IonMonkey) here: https://bugzilla.mozilla.org/show_bug.cgi?id=650180 https://bugzilla.mozilla.org/show_bug.cgi?id=650180 -edit- Found actual 'Type Inference' bugzilla discussion: https://bugzilla.mozilla.org/show_bug.cgi?id=557407 https://bugzilla.mozilla.org/show_bug.cgi?id=557407
ootachi 15y ago
It's not low-hanging fruit at all. First, making it fast is extremely difficult. JavaScript compilers are under extreme pressure to compile code quickly, unlike any other type-inferring compiler, because JS compilation keeps the user from seeing the page. Second, in order to be useful, type inference for JavaScript has to be speculative. JS's semantics require that ints overflow into doubles, for example, meaning that a conservative type inference engine would have to assume every number can potentially be a double. This is too imprecise to be useful, so the inference engine speculates. If the engine guesses wrong, the compiler must not only recompile the function under the new assumptions but also (since this is a global analysis) potentially update every other function that the function called. Finally, the presence of eval() and the like mean that almost no inference can be totally sound, requiring even more dynamic checks. There's a reason that (despite what some others are saying in this thread) V8 and Chakra haven't done this yet: it takes a long time to get right.
- masklinn 15y ago
  On the other hand, most of the dynamic checks (type assertion barriers) will be there anyway as the JIT-generated code needs them (for type-specialized traces). Static type inference may even allow for doing away with some, if it's possible to statically prove types are fully known at compile time for a code section.

natmaster 15y ago

They are confusing weak typing with static typing.

tlrobinson 15y ago
I almost wish I hadn't learned the distinction between strong/weak and static/dynamic typing, because it drives me crazy when people use the incorrect terminology.

Myrth 15y ago

> By the time Firefox 9 reaches the Aurora channel at the end of September, though, type inference should just make your web surfing 20-30% faster — period. Mmm.. I think they've forgot to factor in the ratio of JavaScript involvement in overall web surfing experience?

masklinn 15y ago
Since it's firefox we're talking about, this will likely (positively) impact the browser's own chrome and any extension you've installed, as well as in-page javascript.

simon_kun 15y ago

If you're interested in the relative performance of the current crop of JS engines, you may like to check http://arewefastyet.com/?a=b&view=regress http://arewefastyet.com/?a=b&view=regress for commit by commit benchmarking over time.

Joeri 15y ago

Mobile optimization fail. Their ipad-optimized version cuts off part of the content, and the well-hidden link to go to the desktop version doesn't work. And that's even sidestepping the whole issue that the interaction model of their ipad version is worse than that of a regular website. But it's nice to see that the race is still on, with each browser leapfrogging the others every once in a while.

comex 15y ago
Right, article is unreadable (doesn't scroll) on iPhone.

51Cards 15y ago

Interesting that I'm not seeing this on Are We Fast Yet? I thought that was always the bleeding edge JaegerMonkey specs.

bzbarsky 15y ago
You can see the TI+JM graph at http://arewefastyet.com/?a=b&view=regress http://arewefastyet.com/?a=b&view=regress