Similar efforts, using dramatically different mechanisms, occurred inside other major JavaScript engines, such as Google's V8, the WebKit JavaScript engine, etc. Over the last few years, lots of experimentation occurred, and a lot of learning about JavaScript performance happened.
Now the Mozilla team are starting to incorporate a number of lessons learned from all these experiments into the next revision of their JavaScript engine, with the basic technique being to try to incorporate the good aspects of multiple approaches:
So, a type-specializing trace JIT generates really fast code, but can’t generate native code for the situations described above. Conversely, an optionally specializing method JIT generates moderately fast code, but can generate native code for any JavaScript program. So the two techniques are complementary–we want the method JIT to provide good baseline performance, and then for code that traces well, tracing will push performance even higher.
It's interesting that much of this progress is able to occur because the various competing teams (Google, WebKit, Mozilla, etc.) are all doing their work out in the open:
We decided to import the assembler from Apple’s open-source Nitro JavaScript JIT. (Thanks, WebKit devs!) We know it’s simple and fast from looking at it before (I did measurements that showed it was very fast at compiling regular expressions), it’s open-source, and it’s well-designed C++, so it was a great fit.
This work is delightful for multiple reasons:
- As a user, I can continue to anticipate better browsers, faster web pages, and a happier overall experience
- As a programmer, I can continue to benefit from learning about all these different techniques
Nothing but goodness in all directions!
No comments:
Post a Comment