Firefox 4's JavaScript Now Faster Than Chrome's

An anonymous reader writes "Firefox 4's JavaScript engine is now faster than V8 (used in Chrome) and Nitro (used in Safari) in the SunSpider benchmark on x86. On Mozilla's test system Nitro completes the benchmark in 369.7 milliseconds, V8 in 356.5 milliseconds, and Firefox 4's TraceMonkey and JaegerMonkey combination in 350.3 milliseconds. Conceivably Tech has a brief rundown of some benchmark figures from their test system obtained with the latest JS preview build of Firefox 4: 'Our AMD Phenom X6-based Dell XPS 7100 PC completed the Sunspider test with the latest Firefox JS (4.0 b8-pre) build in 478.6 ms this morning, while Chrome 8.0.560.0 clocked in at 589.8 ms.' On x86-64 Nitro still has the lead over V8 and TraceMonkey+JaegerMonkey in the SunSpider benchmark."

Thanks for the hard work

[DontLickJesus]

Seeing that Firefox on a few weeks ago was starting to lag pretty severely behind Chrome, I applaud and thank the Firefox team for their hard work. This is also a boon for their technique, the so-called "shotgunning" method of pushing through compilation the old way if it will complete faster than the optimizations. I had become afraid I might have to move to Chrome, looks like that won't be necessary.

As a developer I completely understand the dislike of the "everything in a browser" attitude, but we need to look beyond that. The next version of ECMAScript will give us the security we've been wanting, and this round of browsers will give us the speed we need. Enabling universal, secure process level interaction between machines is the goal. You can think of it as widgets, .Net, or whichever other poison you want, but Javascript is free of ownership and frankly a damn good language when written properly.

Now give me an 100% on the Acid3 test please, that way I'll have multiple tools to leverage against my boss next time he asks me to make a web app IE6 compatible.

Re:6 milliseconds! Wheee!!!

[Jahava]

I'm not looking forward to 'the next level' of the web. It will only have more dancing and blinking crap on the page.

Want to make you site fast? You don't need Ajax, Flash, or any other "Hype du Jour". Toss it all out, stick with plain old HTML and make it look decent with simple CSS. Wham, your site is now an order of magnitude faster. You don't need those five load balancers and those twenty application servers just to serve up a page that could easily run on one server when you actually had a clue.

Want to view content? I agree with your theme in that case, and there are plenty of sites out there that are designed around just that: simple presentation-focused static content display.

However, most of the impetus for "Web 2.0" has not been around content viewing, but rather about utilizing the web browser as an effective, cross-platform thin client for applications. Now, granted, some sites are (ab)using AJAX and whatnot for purposes ranging from nefarious to just annoying, and there is some spillover from the dynamic application-based web pages into the static information-based ones, but it's generally kept in balance by the ease with which people can transition to a competing website if yours is too annoying.

Recent advancements in Javascript execution speed are oriented towards polishing the thin client experience and capabilities. If fast Javascript execution becomes ubiquitous, sites can design much more successful thin clients because they can take that execution speed for granted. It's not all just flashing lights and annoying ads: take a look at the stunning Deluge BitTorrent Client's Web UI [deluge-torrent.org] to see how nicely "Web 2.0" can be used.

Re:FF4 has some pretty serious memory leaks still,

[Anonymous Coward]

Memory fragmentation [pavlov.net] will cause a program to use more memory, not cause it to slow down. Since Firefox moved to jealloc [pavlov.net] in 2008, memory fragmentation in Firefox is low. As with memory leaks, these problems were fixed years ago, but users still complain that the problems are being ignored and not fixed.

Re:Quake II was released in 1997.

[Bert64]

There is a general trend to higher level (which are bigger/slower) languages, look at the current fascination with ruby...

The general trend has been that while hardware gets faster, software gets slower so the overall user experience remains the same... If you want a laugh, install some really old software on new hardware, i ran windows 3.0 on a p133 with 32mb a few years ago and it booted almost instantly compared to the 386/486 machines it was typically used on.

Re:FF4

[KingMotley]

I would say quite a few have a beta 6. You are probably used to seeing commercial beta releases which you only see the public betas. I've seen semi-public betas get into the 30's.

Re:FF4 has some pretty serious memory leaks still,

[Mitchell314]

Memory fragmentation can cause it to slow down because it takes more overhead to find free space for more allocations.

Re:Thanks for the hard work

[n0-0p]

I'll try explaining this again. SunSpider doesn't perform sufficient runs to take advantage of the tracing logic. And given the way the test is designed you will actually take a performance hit if you burn many cycles on front-end analysis. So, you consistently hit the unoptimized path where a good implementation uses simple translation logic for emitted instructions, along with a fast and light-weight assembler. (Comparing to YASM is silly, btw, because the needs of real-time JIT are very different from compiling in advance.)

Since Mozilla already had most of the instruction generation logic from their old bytecode implementation, and the test isn't hitting their trace optimizer, the biggest improvement here is coming from the introduction of the Nitro assembler. That's not true for most other JS benchmarks, but it is true for SunSpider. This is why I said I want to see their performance on benchmarks that would take advantage of their tracing optimizations in real-world scenarios--not a test like SunSpider which is heavily weighted towards the compilation speed and baseline (unoptimized) execution speed.

Re:Benchmarks

[asa]

I am sure this will set off a whole series of arguments over benchmarks, tuning, fairness, etc. But from this article I will just take this: I don't care which one is fastest to the few dozen milliseconds, they are probably all in the same "class" now. Everybody wins. (I can sorta understand not including IE, but wonder why they didn't include Opera?)

Now that Javascript is so much faster, ....

Sunspider is a particularly bad benchmark. It was developed before any of the browsers had JITs. V8 is a bit better but still doesn't really stress the browser with the kinds of tasks that are still slow in JS. Mozilla's Kraken benchmark, http://krakenbenchmark.com/ [krakenbenchmark.com] does that. If you want to see why we still have a long ways to go, compare the speeds all browsers get on the Kraken tests with compiled code implementations of those features. Firefox leads the way on much of that, but it's still slow compared to native code. Kraken should help us focus on the real goal which isn't one-upping each other on various tests that are already fast in JS, but trying to catch up to compiled code. We all have a ways to go there.

- A