VisualWorks
WebVelocity
The news is spreading quickly, Google has decided to make their own browser.. Google Chrome, which is odd considering that there's already Mozilla Chrome. Anyway, what's interesting to me is the brewing Javascript engine war that's going on. Let's take a look:
Safari 4, nightly builds - WebKit, has a new engine called SquirrelFish. It makes their javascript run faster.
Firefox 3, nightly builds, has a new engine called SpiderMonkey. It makes their javascript run even faster. It uses traced dynamic compilation.
Chrome, has another new engine called V8. It makes their javascript run the fastest. It uses jit and garbage collection with a heritage from Smalltalk, Self, Strongtalk and Resilient (OOVM).
Is it that much of a surprise that the same technology that powers Smalltalk can super charge Javascript? no not really, they're both similar dynamic languages. It's interesting though that hot on the heels of SpiderMonkey's success at speeding up Javascript comes V8. And hot on the heels of SquirrelFish came SpiderMonkey. Three new Javascript engines in as many months? I love it.
It wouldn't surprise me if Safari took V8 in under its hood - though I think the Firefox guys are wed to their shiny new engine, so they're unlikely to pick up V8. We'll see.
By rkj on September 3, 2008, 12:59:11 amhttp://en.wikipedia.org/wiki/SpiderMonkey_(Javascript_engine)
"SpiderMonkey is the code name for the first ever JavaScript engine, written by Brendan Eich at Netscape Communications, later released as open source and now maintained by the Mozilla Foundation."
By liorean on September 3, 2008, 8:23:49 amI ran a whole slew of browsers, all with different scripting engines, through the SunSpider benchmark. You can see the results here.
http://web-graphics.com/2008/09/02/scripting-engines-just-got-a-whole-lot-faster/
Clearly, TraceMonkey is beating V8 on that particular set of tests. However, while V8 is a fully brewed engine, TraceMonkey still has a lot of code that simply doesn't get JITed because it's in the DOM/BOM code, and the nanoJIT can not trace through that code barrier yet. So, expect TraceMonkey to get a speedup between that test result and the finished Ff3.1 browser, when DOM code can be traced, too.
By liorean on September 3, 2008, 8:27:06 amI ran a whole slew of browsers, all with different scripting engines, through the SunSpider benchmark. You can see the results here.
http://web-graphics.com/2008/09/02/scripting-engines-just-got-a-whole-lot-faster/
Clearly, TraceMonkey is beating V8 on that particular set of tests. However, while V8 is a fully brewed engine, TraceMonkey still has a lot of code that simply doesn't get JITed because it's in the DOM/BOM code, and the nanoJIT can not trace through that code barrier yet. So, expect TraceMonkey to get a speedup between that test result and the finished Ff3.1 browser, when DOM code can be traced, too.