Main menu:

Site search

Categories

Archive

JägerMonkey Update: Getting Faster

Time for another JägerMonkey update: how far we’ve come, what’s happening next, and our plan to bring it all together in time for Firefox 4.

How far we’ve come. So far this year, we’ve done two huge things:

  • Switched the JavaScript engine’s basic value representation from a pointer-sized value to 2 new 64-bit representations, one for x64, the other for x86 and ARM. This is a huge patch, touching 20,000+ lines of code–think of doing a full vascular system transplant surgically. Luke Wagner just landed this change to the TraceMonkey repository. The main reason for doing this is to enable better JIT code generation, but we are already seeing some small-to-medium speedups on certain programs.
  • Written the JägerMonkey method JIT compiler for x86 (with ARM support mostly there). One of the key challenges was generating good code out from SpiderMonkey’s stack-based bytecode. Stack-based bytecodes tend to spend a lot of time reading from and writing to the stack compared to register-based bytecodes like Nitro’s. We designed a compilation strategy that works with our register allocator to boil away most of the stack traffic. We simulate stack operations during compilation and then generate “equivalent” code that keeps things in registers instead of in stack memory. The compiler also has fast paths for arithmetic, PICs, and all the other usual dynamic language JIT stuff. David Anderson led this effort, ably assisted by Sean Stangl.

At this point, our JIT can generate code about as good as Nitro or V8, except for a few optimizations that we are missing, such as fast paths for the mod operator or comparing floating-point numbers. We also need to make a few more improvements to our register allocator. And, of course, we need to bring up the x64 version of the JIT. But overall, the JIT code is looking very good.

All in all, JägerMonkey is now about 3x faster than the baseline interpreter we started with.

Remaining Performance Work. The areas where our performance is still really hurting are in the runtime: function calls, strings, and regular expressions:

  • Regular expressions. The benchmarks are kind of heavy on regular expressions. We started with a simple regular expression compiler, created by me, extended by Luke Wagner. But there are still a lot of regular expressions it doesn’t compile, which run in the slower regular expression interpreter. Because we now use the same assembler that Nitro does, we can use their regular expression compiler, Yarr, too. Chris Leary took on the job of porting over Yarr to SpiderMonkey, and it’s about to land.
  • Strings. SunSpider is pretty heavy on strings, especially string concatenation and string replace operations. I would imagine those are pretty common for web code, too, so it’s a good thing to optimize. Ropes help a lot with string concatenation, so JavaScript intern Alan Pierce coded up some ropes, which are also about to land. Alan is now working on replacement and other string operations that need performance help.
  • Function calls. As of today, function calls in SpiderMonkey are very slow compared to the competition. One of the main problems there is that we have a very large stack frame, that encodes all kinds of optional elements and duplicate copies of information available elsewhere. The current design is convenient for a basic interpreter, but it can’t deliver the kind of fast JavaScript people now expect. Luke Wagner will be applying his surgical skills to the “Stack Frame Evisceration” subproject, which will leave us with a lean stack frame. That plus some JIT improvements should give us fast function calls.

Once we get these items and the JIT improvements already discussed, we should be fast. There are about 30 bugs on file for JM performance, some easy, some hard, some compiler, some runtime, some big wins, some small–anyone who wants to help make us fast should check out the list.

Real Artists Ship. Being fast only counts if it ships. Getting us ready to ship is the priority focus right now. Shipping is mostly about getting out a beta and finding and fixing bugs. There are a couple of big chunks we need to do for a beta JM:

  • x64 JIT compiler. Sean Stangl is moving right along from the x86 JIT compiler to the x64 version. It will be basically the same design, but should be even more effective because x64 has so many more registers.
  • Integration with the trace JIT. Of course, we already have a JIT, the tracing JIT, which generates excellent code for certain programs, especially simple math kernels. So we need to be able to switch back and forth between the method JIT and the trace JIT, hopefully at the ideal times. David Anderson is now working on this. Combining the two systems most effectively will take a lot of tuning, which will have to be ongoing as the performance characteristics of both JITs are still improving.
  • Debugging JIT code. Running 4x slower as soon as you turn on Firebug is not as good as, say, not running 4x slower. We are going to make it possible to debug jitted JavaScript code, so there should be minimal slowdown during debugging. JägerMonkey intern Andrew Drake is taking care of this part. So far, he has already solved the hard problem, setting breakpoints in JIT code, by adding a dynamic recompilation feature to JM. Once he fills in the API implementations, it should be ready to go.

That’s our plan. Right now, things are going well–we are actually having a kind of traffic jam landing JavaScript patches (including both our perf work and other JS work). We’ll update as work continues.

Comments

Pingback from Tweets that mention David Mandelin: JägerMonkey Update: Getting Faster: Time for another JägerMonkey update: how far we’ve come, what’… — Topsy.com
Time: July 19, 2010, 3:30 pm

[…] This post was mentioned on Twitter by Deb Richardson and Seth Rosenblatt, Gen Kanai. Gen Kanai said: YES! RT @planetmozilla: David Mandelin: JägerMonkey Update: Getting Faster: Time for another JägerMonkey update. http://bit.ly/aQxwDb […]

Comment from ancestor
Time: July 19, 2010, 4:17 pm

Thanks, I think you are doing a great job with these updates. They are regular, detailed, and understandable for an outsider even despite the subject being very involved. I think all the teams should take example the JavaScript guys :)

Comment from Firefox
Time: July 19, 2010, 11:53 pm

These kind of updates are the reason why following the development of Firefox is so interesting. IE, Chrome and Opera don’t even come close.

Comment from Josh
Time: July 20, 2010, 1:07 am

Perhaps the slogan for Firefox 4 should be “We’re back, baby!”

Pingback from David Cameron set for talks with President Barack Obama – BBC News – Latest, top stories in the U.S. – Top Stories in the U.S.
Time: July 20, 2010, 1:19 am

[…] David Mandelin's blog » JägerMonkey Update: Getting Faster […]

Comment from pd
Time: July 20, 2010, 2:55 am

Congratulations on all the hard work. Cannot wait to feel a real difference that, to be honest, I didn’t much feel with just TraceMonkey.

Pingback from David Mandelin's blog » JägerMonkey Update: Getting Faster | Chrome OS Blog
Time: July 20, 2010, 4:18 am

[…] Visit link: David Mandelin's blog » JägerMonkey Update: Getting Faster […]

Comment from Paul
Time: July 20, 2010, 5:40 am

“Stack-based bytecodes tend to spend a lot of time reading from and writing to the stack compared to register-based bytecodes like Nitro’s.”
So would you say that SpiderMonkey’s stack-based methodology is the foundation of the JavaScript house you are building? Spending “a lot of time” would seem to indicate inherent slowness. I suppose that rebuilding the foundation (retooling the bytecode) would be a monumental task, but will it be a necessary one for the future?
Given the apparent foundation you have to work with, the JS Team has done an outstanding job. I’ve been following bugzilla quite a bit (although I am not a developer and often times have no idea what I’m reading) and am really happy about the fine work the JS Team is doing. Many thanks!!!

Pingback from PKR GAME Chip hack cheat for play money!!!!Texas Hold’Em Poker | Poker 777 Casino
Time: July 20, 2010, 4:16 pm

[…] David Mandelin's blog » JägerMonkey Update: Getting Faster […]

Pingback from Download Faster HD | Watch Movies Megavideo
Time: July 22, 2010, 9:21 am

[…] David Mandelin's blog » JägerMonkey Update: Getting Faster […]

Comment from Jan
Time: July 26, 2010, 8:07 am

@Paul: no inherent slowness. As David points out in the article, the compiler generates optimized code to hold values in registers instead of reading/writing them to/from the stack. Afaik, in the end there should be no measurable difference.

Pingback from Sortie de Firefox 4.0 Bêta 2
Time: July 27, 2010, 9:15 am

[…] JavaScript speed improvements due to engine optimizations. […]

Pingback from MozillaZine.jp » Blog Archive » Firefox 4 Beta 2 がリリースされた
Time: July 27, 2010, 10:32 pm

[…] エンジンの最適化による JavaScript 性能の向上 […]

Comment from Jack Morris
Time: July 28, 2010, 12:53 am

Hi, I’m not a expert, but Dromaeo JavaScript tests show only a +55% speed of Firefox 4 beta2 over Firefox 3.6.8.

Opera/Chrome are far still 3x over Firefox 4 beta2. It’s very much gap and I don’t think it’s only regexp, strings and functions, but more and more optimizations.

Do you think Firefox 4.0 final build is 3 times more speed than beta2?
Thank you very much

Pingback from Las App Tabs llegan a Firefox en una nueva beta | Tuiter.com
Time: July 28, 2010, 1:33 am

[…] ha mejorado la capacidad de respuesta y desplazamiento de las capas, así como algunos cambios en XPCOM. Estas modificaciones son más orientadas para desarrolladores que para usuarios, pero son mejoras […]

Pingback from Las App Tabs llegan a Firefox en una nueva beta | Intercambio de enlaces
Time: July 28, 2010, 1:58 am

[…] ha mejorado la capacidad de respuesta y desplazamiento de las capas, así como algunos cambios en XPCOM. Estas modificaciones son más orientadas para desarrolladores que para usuarios, pero son mejoras […]

Pingback from Las App Tabs llegan a Firefox en una nueva beta » com3.es
Time: July 28, 2010, 5:13 am

[…] ha mejorado la capacidad de respuesta y desplazamiento de las capas, así como algunos cambios en XPCOM. Estas modificaciones son más orientadas para desarrolladores que para usuarios, pero son mejoras […]

Pingback from Segona beta del Firefox 4, endavant! | GNULinux.cat
Time: July 28, 2010, 12:42 pm

[…] Millores en la velocitat de Javascript. […]

Pingback from [Firefox] Une Beta 2 de qualité et riche pour Firefox 4.0 ! – Websourcing.fr
Time: July 28, 2010, 10:48 pm

[…] Javascript V8 (Google Chrome) et Nitro (Safari) avec un test SunSpider réalisé 19 % plus vite par le dernier JaegerMonkey. Il pourraient bien les dépasser bientôt (même si je m’attends à une réaction immédiate […]

Pingback from Mozilla Firefox 4.0 Beta 2 ออกมาให้นักพัฒนาทดสอบแล้ว | ThaiDC.com
Time: July 29, 2010, 10:43 pm

[…] ความเร็วในการประมวลผล JavaScript เร็วขึ้นด้วยการใส่ลิงตัวใหม่เข้าไป JägerMonkey […]

Comment from portable oxygen concentrator
Time: August 3, 2010, 2:19 am

oh mozilla firefox 4… when you release??

Comment from Sam
Time: August 4, 2010, 2:20 pm

Awesome work you guys! I can’t wait to take the latest release for a spin.
Chrome is fast, but FF is still superior in functionality, so if you give me the Chrome performance, I will be one happy dude!
One question, when the code is JITed, is that only for the lifespan of the page or as long as the script is cached?

Pingback from Anonymous
Time: August 5, 2010, 11:32 am

[…] Mejoras en la velociad del motor Javascript. […]

Comment from Florida Drug And Alcohol Test
Time: August 5, 2010, 11:18 pm

Thanks for sharing the updated new regarding JägerMonkey.Keep coming with more updates.

Comment from seo company
Time: August 7, 2010, 10:31 pm

Hello, I have browsed most of your posts. This page iswhere I got the most useful information for my information gathering. Thanks for posting, maybe we can see more on this. Are you aware of any other websites on this subject

Comment from Ciprian Mustiata
Time: August 8, 2010, 10:39 am

Hi David. I want to congratulate you and all Mozilla team for advances that JM does. As I’ve like to do tracking of arewefastyet, I’ve mostly see that the two designs, the FatVal branch and the tracing branch are fairly similar in performance (right now with a bit better “baseline” JIT code) but they are not integrated. So my question is when the integration is expected to land and the second question, if the tracing will be like 10% slower than JM, and the integration will not be completed till the 4.0 release date, the question is: which of the JS engines will be used: the fatval or the tracing one?

Pingback from Firefox 4 Beta 3 Released. | LinuxReaders
Time: August 11, 2010, 10:34 pm

[…] JavaScript speed improvements due to engine optimizations. […]

Comment from Martin
Time: August 14, 2010, 9:03 am

This is a nice blog to read through

Comment from Mike
Time: August 22, 2010, 1:32 am

Wow. Very informative post.

Pingback from Mozilla Firefox 4.0 Beta 4 Released | Dushan's Projects
Time: August 24, 2010, 12:02 pm

[…] JavaScript speed improvements due to engine optimizations. […]

Pingback from El blag de […] » Mozilla lanza Firefox 4 beta 4
Time: August 25, 2010, 4:52 am

[…] Mejoras en la velocidad de JavaScript gracias a optimizaciones en el intérprete. […]

Pingback from New Firefox 4 beta features tab manager, faster page rendering « ITS Gonna be legen wait for it … DARY
Time: August 26, 2010, 2:12 am

[…] JavaScript speed improvements due to engine optimizations. […]

Pingback from Firefox 4 Beta 1 Released
Time: September 15, 2010, 7:09 am

[…] JavaScript speed improvements due to engine optimizations. […]

Pingback from Firefox 4 beta 2 ya está disponible
Time: September 21, 2010, 12:34 am

[…] Mejoras en la velociad del motor Javascript. […]

Comment from Sonic Producer Beats
Time: September 24, 2010, 12:25 am

Thanks for sharing the regular JägerMonkey Update!

Comment from Simon
Time: October 10, 2010, 5:03 am

You guys are the best. If there is one aria where Firefox needs to improve it’s in speed. With JägerMonkey increasing speed by 30% i think FF just got that much better.

Comment from SEO Services
Time: October 10, 2010, 1:14 pm

TraceMonkey was a bit of a disappointment. Hopefully Jager will get the job done. Thank you for keeping us updated.

Pingback from Las App Tabs llegan a Firefox en una nueva beta | Noticias tecnológicas
Time: October 17, 2010, 8:00 pm

[…] ha mejorado la capacidad de respuesta y desplazamiento de las capas, así como algunos cambios en XPCOM. Estas modificaciones son más orientadas para desarrolladores que para usuarios, pero son mejoras […]

Comment from WebpageFX
Time: October 21, 2010, 10:48 am

Can’t wait to test Firefox 4 with the new JavaScript engine!!!

Comment from ALISE
Time: October 22, 2010, 5:38 pm

I like this information and it has given me some sort of desire to have success for some reason, so thanks. Furthermore I′m definitely considering blogging these facts in my own blog!

Pingback from Mozilla FireFox 4 Beta 6 Version released
Time: October 24, 2010, 3:21 am

[…] JavaScript speed improvements due to engine optimizations. […]

Pingback from Mozilla FireFox 4 Beta 6 Version released
Time: October 24, 2010, 3:21 am

[…] JavaScript speed improvements due to engine optimizations. […]

Comment from PPI Claims
Time: October 26, 2010, 7:20 am

nic stuff yet again

Comment from backlinks
Time: November 8, 2010, 2:41 am

A great news indeed, thank you for sharing this great news.

Pingback from Mozilla Firefox 4.0 Beta 7 Final | NS Software Collection
Time: November 19, 2010, 12:37 am

[…] JavaScript speed improvements due to engine optimizations […]

Comment from Honda Fuel Pump
Time: November 24, 2010, 10:55 pm

Honda Fuel Pump -Shop for Hummer Fuel Pump from Car Parts Warehouse at wholesale price online. Visit Car Parts Warehouse to buy premier quality replacement car and truck parts for all makes and models