Land Ho, Fast JavaScript!

Firefox just got a whole lot faster.

I’m excited to announce that Mozilla’s new JavaScript engine, JägerMonkey, is now available for testing!

What is JägerMonkey?

JägerMonkey is our new optimizing JIT compiler for JavaScript. It sits underneath our existing JIT, TraceMonkey, which appeared in Firefox 3.5. If you recall from previous posts, TraceMonkey’s job is to optimize loops to very fast machine code. However, not all code has loops, and not all loops can be trace compiled.

JägerMonkey is a general-purpose compiler which converts entire methods to machine code. The goal is to get great baseline performance. When it detects a loop that can be traced, it automatically engages the trace compiler, which makes it even faster. Yes, that’s right: there’s a turbo button inside.

This hybrid approach is designed to use well-established optimization techniques that work everywhere, and combine them with our existing hyper-optimizing engine that handles smaller subsets of code.

Results.

If you’ve been obsessing over Are We Fast Yet? like me, you’ve seen the numbers dive. Want to try it out? Click here to get preview builds of Firefox 4 with our new JavaScript engine. You can play demos like JSNES at a full, glorious 60FPS.

Disclaimer: It’s a preview – we’re still ironing out the rare kinks. Please report bugs or tell us if something’s wrong (or slow!)

Benchmarks.

We’ve been using the SunSpider 0.9.1 and V8-v5 benchmarks to gauge our general progress. SunSpider is a full 2X faster over Firefox 3.6!

Our improvement on the V8-v5 benchmark is even more dramatic – 4X!

Ongoing Work.

The rockin’ doesn’t stop here. Right now we’re polishing off the final pieces to get into the next Firefox 4.0 Beta. At the same time, here are some of the immediate performance works-in-progress:

  1. Function Calls. As discussed previously, this is one of our last big areas of optimization. The first of four major pieces, caching call sequences, was completed this week. The second big chunk, which Luke Wagner has slated for this week, will make arguments and stack frames faster. Brian Hackett, Chris Leary, and Bill McCloskey have more stack frame optimizations as part of the third wave.
  2. Tracer Integration. Deciding when to use the turbo button is pretty hard, but Bill and Dave have been researching it thoroughly. Right now we’re just scratching the surface, and we will have much better heuristics by the end of the month.
  3. Web Optimizations. Community member Jan de Mooij is continually finding demos and real-world tools and improving performance “gotchas” in our engine, like making common arithmetic patterns faster.

Conclusions.

Firefox 4 is seeing dramatic wins over 3.6 and the web is feeling faster. You can try it out now using a JS Engine Preview, or wait for Firefox 4 Beta 6.

Please stay tuned as we approach JägerMonkey end-game for Firefox 4. Dave Mandelin and I will be blogging, and for smaller things, tweeting (his here) progress & technical updates.

50 thoughts on “Land Ho, Fast JavaScript!

  1. Colby Russell

    You can try it out now using a JS Engine Preview, or wait for Firefox 4 Beta 6.

    Are these speed gains going to be enabled for chrome as well? If I remember correctly, tracing was initially enabled only for content, until it was decided to throw the switch for chrome, too, on the default configuration.

    Reply
  2. Mark

    I’m almost embarrassed to say that I have been obsessing over arewefastyet a bit.

    I am curious what the numbers look like when comparing 3.6 on dromaeo (as well as other browsers). Do the new JS improvements reflect an improvement there?

    Dromaeo doesn’t come up much when comparing browser speeds. I wonder why that is. I have a vague memory that it does a better job of reflecting real world page loading speed.

    Reply
  3. voracity

    Yep, I keep a regular eye on arewefastyet.com. (It’s like keeping an eye on the score in a Sierra adventure game — pointless, but gives you an idea of progress made in a simple, fun way.) JM+TM is *so* close to passing Nitro on the V8 benchmark. Wouldn’t it be fun to beat V8 on V8, though?

    Reply
  4. Robert Kaiser

    I’ve been checking arewefastyet quite a lot, and it’s really nice to see, though not listing current m-c or even current stable branches there makes us look worse than your awesome work really is. :)

    Given that “my” beloved SeaMonkey will make the jump from the same base as FF 3.5 to the same base as FF 4.0 within a month of the FF4 release, this will be even more exciting for our users than it is for the millions of Firefox users out there who at least have 3.6 available right now. ;-)

    Reply
  5. nwt

    Has it been enabled for x64? I’m running the linked to Linux x64 build; it’s still as slow as the previous ones from latest-mozilla-central for V8 and SS (i. e. no improvement at all).

    Reply
  6. Reece Dunn

    Fantastic work. It’s been really interesting in following the development for this and seeing the time come down on the arewefastyet.com website (yup, another AWFY junkie :D).

    I’m looking forward to seeing how fast you can make it for release and also where Firefox.next and beyond will go.

    What next? PsychicMonkey — the predictive trace engine ;)?

    Reply
  7. Luke Wagner

    @glandium: while they aren’t supported at the moment, there are plans for ia64, sparc, and one other that slips my memory that members of the community are pursuing.

    Reply
  8. dvander Post author

    @Colby Russell – Yes, we are going to enable chrome method JIT’ing next week.

    @nwt – Yes, it is enabled for x64. It should be faster than m-c on everything except maybe SunSpider. I’ll look into that, thanks.

    Reply
  9. James Gray

    Seriously awesome work.

    I do have one question: Why is JM faster than JM+TM on SunSpider? Is this a bug in the graphs, or does SunSpider naturally bring out a lot of switching between tracing/method JITs?

    Reply
  10. genobis

    I admit and congratulate – it’s a great progress indeed! However, it’s still few times slower than Google Chrome… (according to results from (dromaeo.com) why the difference is so great? Are forthcoming improvements going to change it?

    Reply
  11. dvander Post author

    @James The real problem is that SunSpider is so short-running (it was built to complete on IE6 before the heat death of the universe). It’s not enough time for the trace compiler to pay off. We’re working on the heuristics in bug 580468.

    @genobis Yes, definitely. We’re still tracking down Dromaeo regressions. However, we’d also like to focus on benchmarks that we believe have more value for the web, like Kraken. (Disclaimer: Both are made by Mozilla.)

    Reply
  12. genobis

    Thank you for your response, dvander :) But what do you mean by “value for the web”? I think it’s very different both for users and developers. For example, I’m working on a ajax-based RIA (using GWT and ExtGWT) and in this case the crucial factor is how browser handles an awful lot of generated DOM. FF 3.6 responsibility was rather poor (sliders in data grid with many rows and columns were stuck, for example), in FF 4 this problem disappeared.

    Anyway, what I’m trying to say is that someone else may expect/hope for something totally different. So that’s may question – if you are going to focus on some particular areas, which would that be?

    Sorry for being that persistent, I’m just really curious :)

    Reply
  13. abral

    I’ve tried tests on dromaeo (i’ve never tried them before), and chromium 6 is really faster than firefox 4 beta 7…
    However, I would like to know: what do you think about using LLVM as a javascript engine? It’s really fast, simple to implement and, above all, has a lot of optimizations!
    However, you could get some ideas from LuaJIT, it seems to be the fastest JIT (watch here http://shootout.alioth.debian.org/), at times faster than compiled languages.

    Reply
    1. dvander Post author

      abral – Whether LLVM could be used for JavaScript on the web is an interesting question. The problem is that LLVM is not a one-size-fits-all solution. It’s designed for statically typed languages, and you won’t gain anything by pumping JavaScript bytecode into it.

      JavaScript is made fast via specialization, and in most browsers that’s done dynamically as code runs (whether via tracing, recompilation, or inline caching). It’s possible that LLVM could serve a role here in two ways:

      (1) Browsers could, instead of compiling to assembly, compile to LLVM IR, and see if that offers any advantages. I suspect it wouldn’t without…

      (2) If you can infer or speculate types for a function, such that most of the function looks statically typed, LLVM would be able to do very well.

      However, compilation itself also needs to be very quick, and LLVM is heavyweight.

      You might be interested in Mason Chang’s experiments with LLVM and ActionScript.

      Reply
  14. pavan

    u rock firefox!! nothin can beat u in overall rating. chrome may hv speed but no addons!!
    a simple comparison—

    chrome- a formula 1 racing car with no steering wheel or brakes.
    firefox- a luxurios BMW not as fast as a f1 car but really nice handling with a steering wheel and brakes.

    so thatsthe reason why FF beats all on the overall basis!! hope the tabpreviews adn speed dial comes preinstalled in ff4 !!

    Reply
    1. dvander Post author

      Sven – The recursion limit (like the script timeout) is there to prevent scripts from running off into the weeds. It was effectively raised in 4.0, depending on how small the function recursing is. At one point we had a plan for tail recursion optimizations, but it petered out during 3.7 and won’t make 4.0.

      Reply
  15. Marion Niskala

    I obligation have a number of ability coupled with to say gratitude to everyone about the quality hints We now have often appreciated opportunities your current webpage. We’re pumped cheery as regards the graduation directed to this kindly of derived education delightful a look by the side of additionally the genuine entirety placement of feet wouldn’t lean to ensue completely be over deficient on the way against your situate position. Plainly force really ensue of an average assist persons, I’ll forever live fortunate to be intelligent to of what I’ve considered since of this point.

    Reply
  16. title loan

    The Pay day development Size advance territory unit inward at to be the larger a district of our superlative equity credit item and administrations. the only enjoying purpose of obtaining some actually Pay day development Size advance over the only real one check day progress, are about to be Associate in Nursing Size credit demonstrates just may pay off this specific equity credit line distinctive with Associate in Nursing broadened quantity of sooner or later. These kinds of makes it get to be varied less hard-to-please just simply that you just simply entirely may hold parts no over potential.

    Reply
  17. Florentina Thoby

    I am especially proud because credit unions are not-for-profit organization that exists to serve their membership rather than shareholders whom seek maximize profit through fees and services. I just love my Credit Union.

    Reply
  18. Leonard Kolm

    I believe that is among the such a lot vital info for me. And i am happy studying your article. However wanna observation on few normal issues, The website style is perfect, the articles is in reality excellent : D. Good job, cheers

    Reply
  19. Arthur

    Gracias por colgar en la web artículos como este, porque este tipo de contenidos deberían de ser más frecuentes que aquellos que faltan a la verdad.

    Reply
  20. Dino Draheim

    I’m not positive the place you are getting your information, however good topic. I needs to spend a while studying more or figuring out more. Thanks for excellent info I was on the lookout for this info for my mission.|

    Reply
  21. Valentin

    I have a difficult time illustrating my thoughts on web content, however I truly felt I ought to below. Your short article is actually really excellent. I just like the way you wrote this information.

    Reply
  22. Arletha Langhorn

    Many thanks for putting in the time to explain this, I feel firmly regarding this and also love finding out more on this subject. Ideally, as you gain experience, will you mind updating your blogging site along with even more information? That is incredibly helpful for me.

    Reply
  23. Reagan Trullinger

    I like your blog post as well as everything you show our company is current and extremely useful. maintain sharing such sort of write-ups right here. I was able to discover good information from your blog post articles.

    Reply
  24. Ricardo Cheu

    This is actually a wonderful article. I like this topic.This website has bunches of advantage.I discovered numerous interesting traits from this internet site. It helps me in lots of ways.Thanks for posting this once again.

    Reply
  25. Ted

    Thank you to your publish. I’d enjoy to convey the tariff associated with automobile insurance vary from scheme to a new, due to the fact there are plenty of diverse facets which give go up towards the total cost. As an illustration, the particular design to make from the automobile will have a considerable bearing on the associated fee.

    Reply
  26. casino qq

    Hey There. I found your blog the use of msn. This is an extremely well
    written article. I’ll make sure to bookmark it and come back to learn extra of your helpful info.
    Thank you for the post. I’ll definitely comeback.

    Reply

Leave a Reply

Your email address will not be published.

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong> <pre lang="" line="" escaped="">