Firefox 4's JavaScript Now Faster Than Chrome's 352
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."
The Best Java Script Engine Available... (Score:2, Informative)
FF4 has some pretty serious memory leaks still, to (Score:0, Informative)
I've been trying the alphas and betas, but they still haven't managed to fix the numerous memory leaks that have plagued Firefox for so long now.
It's no longer worth opening bug reports, since the community just doesn't want to admit there's a problem in the first place. They'll blame the memory leaks on third-party extensions or plugins, even when these memory leaks arise using a pristine installation without either. Or they'll say it's just a problem with the user's system, even when it happens under many different versions of Linux, Windows and Mac OS X, running on all sorts of hardware, under many different configurations. Clearly, it's a problem with Firefox itself.
Somehow, all of the other browser developers manage to put out browsers that don't leak huge amounts of memory after relatively short browsing sessions. Opera, Chrome, Safari, and even recent releases of IE don't go consuming gigabytes of memory, even after leaving them open for months at a time. Firefox will exceed that in less than an hour.
Re:no Internet Explorer comparison? (Score:2, Informative)
"3. Why isn't Opera/IE/something here?
Right now, the performance tests are run on a Mac, which means no IE. Also the tests rely on a "shell" JS engine that runs in a command line. It doesn't test browsers. We'll change that, eventually."
Interesting? (Score:4, Informative)
I really don't see the point in a posting like this. Its all
My _______ (1) is _______ (2) than yours
with typical choices for (1):
- car
- wife / husband / significant other
- d*ck
- browser
- javascript
- OS
and choices for (2) like:
- faster
- harder
- more expensive
- longer
- more open
- prettier
Now that we have covered all these discussions, can we move on please?
CU, Martin
Re:FF4 has some pretty serious memory leaks still, (Score:5, Informative)
It's not a memory leak problem. This is pretty obvious when, after weeks of continuous use, Firefox's memory usage remains more or less constant.
However, Firefox does have a memory fragmentation problem. After continuous use, the program will become noticeably slower on certain tasks which it previously had no issues with. This is particularly the case if you're visiting more intensive webpages. Often you're better just restarting it after the first 100 or so tabs.
Re:FF4 has some pretty serious memory leaks still, (Score:3, Informative)
Re:thats great but.... (Score:3, Informative)
Note the times for this article, however. The benchmarks that they are running are taking less than half a second from loading the JavaScript code to finishing running. That's a fairly good test for typical web pages, but it's a pretty pointless benchmark. Any script that does that little will run at an adequate speed with a fairly naive bytecode interpreter.
The things that really benefit from JavaScript speed are long-running scripts. Consider something like a Flash game that runs for minutes at a time. When I compile programs, the compiler typically spends a second or so of CPU time running optimisations. This can easily save several seconds of CPU time over the total run time of the program, but would be pointless for a short-lived web script. This trade changes when the scripts are running for a long time.
Modern JavaScript implementations do dynamic optimisation based on run time profiling. This is what the trace stuff was all about. Trace-based optimisations work by finding a set of basic blocks that run in a particular order - irrespective of where they are in the source code - and creating an optimised sequence (without any branches except to leave the trace), so the common-case execution of a sequence of functions / methods does not involve any jumps. Benchmarks that complete in well under a second won't give this kind of stuff any time to kick in.
JavaScript implementations need to be optimised for two things: fast start up (very noticeable to the user) and CPU usage for longer-running scripts. These benchmarks are only really testing the former, while things like the canvas tag and WebGL are making the latter more important.
Verified on my sw-only 3D benchmark as well (Score:3, Informative)
Re:and yet Firefox still can't use 1 core... :( (Score:4, Informative)
Just about any moron can make a new browser window per tab and not have them talking to each other. But it takes a fair amount of work to get them connected enough for performance reasons without causing one tab to crash others.
Re:FF4 has some pretty serious memory leaks still, (Score:3, Informative)
Your operating system should be dealing with that, not the browser.
Re:What Mozilla giveth, Slashcode taketh away. (Score:3, Informative)
I hate the new comments system, too.
Shit, I thought that I was the only person that happened to. I even had to log out/in to get the preference change to "stick".
Re:FF4 (Score:2, Informative)
PhD or not, you're still an idiot.
Re:Quake II was released in 1997. (Score:3, Informative)
Today, a decade and a half later, we have cell phones that are many hundreds of times faster than those Pentium and Pentium II systems,
A hundred times faster than a 233 MHz processor? That's 23 GHz. What phone has a 23 GHz processor?
Re:Thanks for the hard work (Score:4, Informative)
There are several things wrong here:
1) Spidermonkey still compiles the AST to bytecode.
2) An assembler does just that: assembles. This means a 1-1 mapping of some other sort of
representation of the exact machine instructions you want into actual bits in memory.
There are no smarts here and no optimization going on; the only question is how fast
you generate those bits in memory; an ideal assembler does this as fast as possible
and without using too much memory. Now you have to generate assembly (or whatever
representation the assembler takes as input) for it to assemble. That's the job of
the compiler. JaegerMonkey takes the bytecode generated in step 1 and compiles it,
passing the output to the assembler borrowed from Nitro. This compilation step is
where (some of) the optimization takes place, and this is not code shared with Nitro.
3) Tracemonkey is most certainly useful for Sunspider; just not as useful as for other
things. See, for example, http://arewefastyet.com/?machine=6 [arewefastyet.com] where the purple line is
below the black one solely because of Tracemonkey. Alernately, see
https://bug580468.bugzilla.mozilla.org/attachment.cgi?id=482609 [mozilla.org] where you can see the
scores on each sunspider subtest as of a week or so ago; the -m column is JaegerMonkey
without Tracemonkey, -j is Tracemonkey without Jaegermonkey, and -mjp is what's
actually being used now (a combination of the two, with some smarts about deciding
when to use which one).
4) The goal of Kraken is in fact to include anticipated use cases. If you know
anticipated use cases it doesn't include, I'm sure Rob Sayre would love to know what
they are.