Resig: Javascript Performance Rundown(ejohn.org)
ejohn.org
Resig: Javascript Performance Rundown
http://ejohn.org/blog/javascript-performance-rundown/
5 comments
It's an unfair zinger from what I've read. TraceMonkey may have been in development at Mozilla for 2 months, but significant portions of it came from Adobe and their Tamarin Tracing team. You can't dismiss the development time of the nanojit contribution just for hyperbole's sake. When I saw John Resig, who I very much respect for his work on javascript, make that statement, I realized there's a PR war going on here.
This was a cool article on TraceMonkey development: http://andreasgal.com/2008/08/22/tracing-the-web/
This was a cool article on TraceMonkey development: http://andreasgal.com/2008/08/22/tracing-the-web/
It would appear that TraceMonkey does optimization differently, and they both have a long way to go:
Here is what feng (@chromium.org) said on the v8-users list:
V8 has a simple compiler that generates dummy code ;-), there are a lot of rooms to improve from traditional compiler optimization perspective. It does not even have a register allocator.
What V8 focuses on is the bottleneck of JavaScript: property lookups. You can read papers about inline caches (small-talk, Java, etc).
Some background in GC is helpful too, currently V8 has a generational GC.
From I knew, TraceMonkey is quite different, it does speculative optimizations, which is a very interesting subject of VM and compiler development/research. It requires a interpreter/dummy compiler to fallback when speculation goes wrong. In some sense, both does runtime speculation, but inline cache patches the code if it speculates wrong, and trace jit falls back to safe solution.
Here is what feng (@chromium.org) said on the v8-users list:
V8 has a simple compiler that generates dummy code ;-), there are a lot of rooms to improve from traditional compiler optimization perspective. It does not even have a register allocator.
What V8 focuses on is the bottleneck of JavaScript: property lookups. You can read papers about inline caches (small-talk, Java, etc).
Some background in GC is helpful too, currently V8 has a generational GC.
From I knew, TraceMonkey is quite different, it does speculative optimizations, which is a very interesting subject of VM and compiler development/research. It requires a interpreter/dummy compiler to fallback when speculation goes wrong. In some sense, both does runtime speculation, but inline cache patches the code if it speculates wrong, and trace jit falls back to safe solution.
I definitely didn't intend for it to be that way - only so much as that V8 is the result of a long two years of dedicated work by a team of very smart people who produced an excellent result. Theoretically they reached a point at which they were happy with a solid release.
The Mozilla team is only just getting started on building tracing into Firefox. It's not done yet and it's still quite slow (in comparison to what the final result will be).
I wasn't trying to say anything silly like "oh wow, they're such slow coders!" more that the equivalent amount of work is only just beginning on the other end.
Obviously if you wanted to include all technologies involved in TraceMonkey then you might as well say "TraceMonkey, 10 years in the making" since the vast majority of the code comes from SpiderMonkey which has been around for quite some time.
The Mozilla team is only just getting started on building tracing into Firefox. It's not done yet and it's still quite slow (in comparison to what the final result will be).
I wasn't trying to say anything silly like "oh wow, they're such slow coders!" more that the equivalent amount of work is only just beginning on the other end.
Obviously if you wanted to include all technologies involved in TraceMonkey then you might as well say "TraceMonkey, 10 years in the making" since the vast majority of the code comes from SpiderMonkey which has been around for quite some time.
I realized there's a PR war going on here.
This blog post is definitely emotional, and that's a very good things. Great technologies come out of emotion-driven work.
This blog post is definitely emotional, and that's a very good things. Great technologies come out of emotion-driven work.
Mozilla still has it as an about:config use-at-your-own-risk feature in an unreleased version of FF
This is because Firefox is expected to work, while Google Chrome is just an exciting toy (nobody will get upset if their favorite page stops working).
This is because Firefox is expected to work, while Google Chrome is just an exciting toy (nobody will get upset if their favorite page stops working).
Since John's site is down temporarily I'll link my tests here
http://waynepan.com/2008/09/02/v8-tracemonkey-squirrelfish-i...
PS. I didn't know the secret v2 Dromaeo tests... running and updating now.
PS. I didn't know the secret v2 Dromaeo tests... running and updating now.
These numbers are not at all what I got, testing yesterday. Especially the Dromera tests, where the latest webkit nightly didn't finish even close to that.
I wonder where the discrepancy comes from?
I wonder where the discrepancy comes from?
Apparently there's a secret v2 test, did you use that?
http://v2.dromaeo.com/
He also says he used Safari without Squirrelfish in these tests, due to compilation issues on Windows.
He also says he used Safari without Squirrelfish in these tests, due to compilation issues on Windows.
I'm pretty sure Squirrelfish is still under pretty heavy windows development. For non-windows, they use some special GCC things that aren't supported under VC++, which they use to compile the windows version (AFAIK). Even if it ran, Squirrelfish is slower under windows because they have to cut out some of the optimizations.
In the comments, John says:
"It sounds like you're using the "regular" Dromaeo tests (which only test a subset of the SunSpider tests). The second version that I linked to includes a number of DOM and JavaScript library tests - which drastically normalize the field."
( http://v2.dromaeo.com/ )
"It sounds like you're using the "regular" Dromaeo tests (which only test a subset of the SunSpider tests). The second version that I linked to includes a number of DOM and JavaScript library tests - which drastically normalize the field."
( http://v2.dromaeo.com/ )
[deleted](1)
Zinger.
On the other hand, it's impressive that people at Google saw JS VM's coming two years ago and already shipped it with Chrome, while Mozilla still has it as an about:config use-at-your-own-risk feature in an unreleased version of FF ;)
But I like that people are taking this personally :) browser wars rock on!