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

http://www.extremetech.com/computing/94532-firefox-9-javascript-performance-improved-by-20-30-with-type-inference

by 11031a • 15 years ago

123 46 15 years ago

extremetech.com

thurn• 15 years ago

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

mrsebastian• 15 years ago

Yea, I was thinking the same thing.

Chakra (IE9) already has it, I think.

jmilloy• 15 years 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-javasc...

DrJokepu• 15 years ago

(edit: I have said something stupid, nothing to see here, move along)

ootachi2• 15 years 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.

grantg• 15 years ago

So you did ycombinator's version of [deleted]. :P

sjs2• 15 years 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• 15 years 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

2: http://en.wikipedia.org/wiki/JavaScript

randomdata• 15 years 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.

jrockway• 15 years ago

What? C++ is weakly typed; it has one type called "big block of memory". Everything on top of that is just an annotation that the compiler uses to generate code, and the compiler will not do any checking to ensure that what it's generating makes sense.

varikin2• 15 years ago

That description was meant for those who don't understand programming, weak & strong typing, & type inference. It is a good enough description for those who don't know and will never care to know more.

I understand the importance of defining thing correctly, but does the average person need to care or worry about the difference between strongly/weakly typed & statically/dynamically typed?

sjs2• 15 years ago

Probably not, that's certainly a fair point. But in that case why go into it at all? Just say it's magic "faster" juice (and don't post it to HN).

One thing I'm curious about as a developer is how this is different than the type inference that SpiderMonkey already did. The JIT certainly didn't represent numbers as strings in memory or something equally silly prior to this new type inference. Is it better inference that optimizes away boxing or can optimize across function calls or something?

(Just musing "out loud", I don't expect answers to these questions here on HN.)

Dn_Ab• 15 years ago

Agree. Can one say Mediumly Typed? To me a strongly typed language is very stern - you trade some slight annoyance for some slight sanity checks. For example strong typing would not let you say 5 + 5.0 because float <> int.

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

I'm not sure even manifest typing would be the correct term as he mentions performance. So it looks like he is looking for static vs dynamic.

Dynamic typing but inferring types statically where possible. It is interesting that type inference in a statically typed language leads to less noise and type inference in a dynamic language leads to some speed boost.

ori_b5• 15 years ago

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

starwed• 15 years ago

Some not very technical discussion of what was involved here: 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

-edit- Found actual 'Type Inference' bugzilla discussion: https://bugzilla.mozilla.org/show_bug.cgi?id=557407

ootachi2• 15 years 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.

masklinn3• 15 years 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.

seanalltogether• 15 years ago

Yeah the biggest problem is that there are millions of pre-existing codebases all over the web that mozilla needs to make sure don't break. Since it is a speculative engine, the possibility of breaking even a small percentage of those codebases becomes very likely, so it's really not an easy thing to do.

I'll be curious if it's good enough to enable by default, or if the developer needs to flag the engine somehow to enable the feature.

ori_b5• 15 years ago

> 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

You only run type inference after you detect the hot loops. Same with other expensive optimizations. This is something that all JITs out there do -- you start with simple interpretation (or extremely cheap compilation, in the case of V8), and then when you detect that you're spending a whole lot of time in one section of code, you replace it with a highly optimized version.

Type inference is not that expensive compared to several more interesting optimizations done on several JITs that are in production systems. In some long running JITs, the compilation of some hot loops takes far longer than static compilations, running in a low priority thread in the background (while the less optimized code keeps going in the foreground).

Finally, if anything, JITs allow more time to run heavy optimizations because they can leave those running in the background without affecting the use of the program or hurting developer productivity.

> JS's semantics require that ints overflow into doubles, for example

On recent x86 processors, you would just use doubles in most cases. It turns out that they're on par with integers for speed, although I believe there were some differences on latency. I'd have to look back at the Intel opt manual to confirm, though. However, if you really want to solve the issue (say, on ARM where integer/float performance actually matters -- especially since lots of architectures are still on softfloat), then you'd use a combination of guards, versioning, and VRP to solve the issue, not type inference.

> Finally, the presence of eval() and the like mean that almost no inference can be totally sound, requiring even more dynamic checks.

Yep, eval is a terrible language feature if you care about making things fast. Regardless of whether you have type inference or not.

masklinn3• 15 years ago

It's not, and it's much harder to integrate in a JITted environment than type-specialized paths (where the types are observed at runtime). Strongtalk, for instance, discards pretty much all of its static type information before JITing. HotSpot may very well do the same thing, since it arose from Strongtalk's work.

natmaster• 15 years ago

They are confusing weak typing with static typing.

tlrobinson• 15 years 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• 15 years 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?

masklinn3• 15 years 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• 15 years 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 for commit by commit benchmarking over time.

Joeri• 15 years 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• 15 years ago

Right, article is unreadable (doesn't scroll) on iPhone.

51Cards• 15 years ago

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

bzbarsky2• 15 years ago

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

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

Related Stories