September 3, 2008
TraceMonkey Update
We have been busy, mostly fixing bugs for stability, but also winning a bit more performance, since TraceMonkey landed on mozilla-central, from which Firefox 3.1 alpha-stage nightly builds are built. Tonight's builds include a fix for the bug that ilooped a SunSpider test (my apologies to those of you who suffered that bug's bite).But what I'm sure everyone wants to know is: how do we compare to V8?
Here are the results from head-to-head SunSpider on Windows XP on a Mac Mini and Windows Vista on a MacBook Pro, testing against last night's Firefox automated build and yesterday's Chrome beta:
We win by 1.28x and 1.19x, respectively. Maybe we should rename TraceMonkey "V10" ;-).
Ok, it's only SunSpider, one popular yet arguably non-representative benchmark suite. We are not about to be braggy. ("Don't be braggy" is our motto here at Mozilla ;-).)
But it's worth digging deeper into the results. Let's look at the ratios by test:
We win on the bit-banging, string, and regular expression benchmarks. We are around 4x faster at the SunSpider micro-benchmarks than V8.
This graph does show V8 cleaning our clock on a couple of recursion-heavy tests. We have a plan, to trace recursion (not just tail recursion). We simply haven't had enough hours in the day to get to it, but it's "next".
This reminds me: TraceMonkey is only a few months old, excluding the Tamarin Tracing Nanojit contributed by Adobe (thanks again, Ed and co.!), which we've built on and enhanced with x86-64 support and other fixes. We've developed TraceMonkey in the open the whole way. And we're as fast as V8 on SunSpider!
This is not a trivial feat. As we continue to trace unrecorded bytecode and operand combinations, we will only get faster. As we add recursion, trace-wise register allocation, and other optimizations, we will eliminate the losses shown above and improve our ratios linearly across the board, probably by 2 or greater.
I'll keep updating the blog every week, as we do this work. Your comments are welcome as always.
V8 is great work, very well-engineered, with room to speed up too. (And Chrome looks good to great -- the multi-process architecture is righteous, but you expected no less praise from an old Unix hacker like me.)
What spectators have to realize is that this contest is not a playoff where each contending VM is eliminated at any given hype-event point. We believe that Franz&Gal-style tracing has more "headroom" than less aggressively speculative approaches, due to its ability to specialize code, making variables constant and eliminating dead code and conditions at runtime, based on the latent types inherent in almost all JavaScript programs. If we are right, we'll find out over the next weeks and months, and so will you all.
Anyway, we're very much in the game and moving fast -- "reports of our death are greatly exaggerated." Stay tuned!
Posted by brendan at 1:45 AM | Comments (30)
August 23, 2008
TraceMonkey: JavaScript Lightspeed
I'm extremely pleased to announce the launch of TraceMonkey, an evolution of Firefox's SpiderMonkey JavaScript engine for Firefox 3.1 that uses a new kind of Just-In-Time (JIT) compiler to boost JS performance by an order of magnitude or more.Results
Let's cut straight to the charts. Here are the popular SunSpider macro- and micro-benchmarks average scores, plus results for an image manipulation benchmark and a test using the Sylvester 3D JS library's matrix multiplication methods:
Here are some select SunSpider micro-benchmarks, to show some near-term upper bounds on performance:
This chart shows speedup ratios over the SpiderMonkey interpreter, which is why
"empty loop with globals" (a loop using global loop control and accumulator
variables) shows a greater speedup -- global variables in JavaScript,
especially if undeclared by var, can be harder to optimize in an
interpreter than local variables in a function.
Here are the fastest test-by-test SunSpider results, sorted from greatest speedup to least:
The lesser speedups need their own chart, or they would be dwarfed by the above results:
(Any slowdown is a bug we will fix; we're in hot pursuit of the one biting binary-trees, which is heavily recursive -- it will be fixed.)
With SunSpider, some of the longest-running tests are string and regular-expression monsters, and since like most JS engines, we use native (compiled C++) code for most of the work, there's not as much speedup. Amdahl's Law predicts that this will bound the weighted-average total Sunspider score, probably to around 2. No matter how fast we JIT the rest of the code, the total score will be... 2.
But this is only a start. With tracing, performance will keep going up. We have easy small linear speedup tasks remaining (better register allocation, spill reduction around built-in calls). We will trace string and regular expression code and break through the "2" barrier. We will even trace into DOM methods. The tracing JIT approach scales as you move more code into JS, or otherwise into view of the tracing machinery.
Finally, schrep created a screencast (UPDATE: link fixed) that visually demonstrates the speedup gained by TraceMonkey. These speedups are not just for micro-benchmarks. You can see and feel them.
How We Did It
We've been working with Andreas Gal of UC Irvine on TraceMonkey, and it has been a blast. We started a little over sixty days (and nights ;-) ago, and just yesterday, shaver pushed the results of our work into the mozilla-central Hg repository for inclusion in Firefox 3.1.Continue reading "TraceMonkey: JavaScript Lightspeed"
Posted by brendan at 11:31 AM | Comments (11)
April 3, 2008
Popularity
It seems (according to one guru, but coming from this source, it's a left-handed compliment) that JavaScript is finally popular.
To me, a nerd from a tender age, this is something between a curse and a joke. (See if you are in my camp: isn't the green chick hotter?)
Brendan Eich convinced his pointy-haired boss at Netscape that the Navigator browser should have its own scripting language, and that only a new language would do, a new language designed and implemented in big hurry, and that no existing language should be considered for that role.
I don't know why Doug is making up stories. He wasn't at Netscape. He has heard my recollections about JavaScript's birth directly, told in my keynotes at Ajax conferences. Revisionist shenanigans to advance a Microhoo C# agenda among Web developers?
Who knows, and it's hard to care, but in this week of the tenth anniversary of mozilla.org, a project I co-founded, I mean to tell some history.
Posted by brendan at 7:56 PM | Comments (27)
November 29, 2007
My @media Ajax Keynote
Herewith a hacked-up version of my S5 slides (UPDATED URL), with notes and commentary interpolated at the bottom of each slide.
Continue reading "My @media Ajax Keynote"
Posted by brendan at 2:36 AM | Comments (6)
November 5, 2007
ES4 News and Opinion
ES4 News
Some news on language size: the proposed ECMAScript 4th edition (ES4) grammar is a bit more than twice as big as ES3's, counting several ways (concrete productions, abstract syntax tree node types):
Syntax ES3 ES4 ------ --- --- Concrete 238 490 Type Exprs 50 Classes & Interfaces 23 Patterns 17Abstract 33 77
This is not out of line given the eight years since ES3, which came less than three years after ES1. Much of ES4 has been developed and shipped in ES3-based languages: AS3 in Flash, JS1.6 and 1.7 in Firefox, Opera's extensions including array destructuring. And we're being generous with syntactic conveniences, which desugar to a smaller core language.
On the compatibility front, we have a new document on known incompatibilities between ES3 (ECMA-262 Edition 3 the spec, not real-world behavior of ES3 implementations in browsers -- note well) and ES4.
Contradiction
Chris Wilson: "... I don't think the other Microsoft guys ever intended to say 'everything about ES4 is bad'."
Pratap Lakshman (Microsoft): "We do not support or agree to the current ES4 proposal, either in whole or in part."
Continue reading "ES4 News and Opinion"
Posted by brendan at 10:47 PM | Comments (3)