64-bit Firefox Performance on Mac OS X

I used standalone talos to test a 64-bit Mac OS X build against a 32-bit build. I created the two builds using the same optimized configuration and the same mercurial revision. Since only the 32-bit build can load any of the plugins that ship with Mac OS X 10.6 I removed all plugins from the plugin search paths. This way the 32-bit build wasn’t hurt by having to deal with more plugins than the 64-bit build. The tests were done on Mac OS X 10.6.1.

Ts: 64-bit is 6.5% faster
Tp: 64-bit is 6.3% faster
Twinopen: 64-bit is 5.1% faster
Tjss: 64-bit is 8.7% faster
Tsunspider: basically a tie, 64-bit is 0.2% faster

I’m not sure what all of the factors contributing to these results are yet, but it seems Apple’s investment in optimizing the OS and developer tools for x86_64 paid off.

16 thoughts on “64-bit Firefox Performance on Mac OS X

  1. Gecko 1.9.3 will support Mac OS X x86-64 push Mac OS X ppc to least tier two at that point when the tree can build Mac OS X x86-64.

  2. 64-bit on x86_64 is able to use more CPU registers than 32-bit, which is likely the difference. It isn’t because it is 64-bit. If the compiler could use all the registers available in 64-bit mode when compiling for 32-bit, the 32-bit build would likely be the same speed or faster. Too bad we’ll never be able to see the same test of 32-bit vs. 64-bit on PPC, where the number of registers is the same between 32-bit and 64-bit.

  3. The JavaScript team saw a gigantic sunspider win a few weeks ago. It was something like 10% or 20% faster in 64-bit than 32-bit (in the js shell, I think). I wonder why you’re not seeing that.

  4. Jesse, I saw a 1.27x speedup on my Linux box for Sunspider running the X64 TraceMonkey backend instead of the i386 backend. That was running the JS shell rather than the browser, but it’s unclear to me what the difference could be.

  5. I’m very much looking forward to playing with a 64-bit Firefox build. Thanks to all the contributors, and I hope everything is checked in and approved soon!

    Now, that said: are there any plans to incorporate Grand Central Dispatch, OpenCL, and H264/MP4 hardware acceleration support? With the advent of HTML5 and the increasing importance of media in the web browser, it would be nice going forward to have these features lined up and ready to go.

    A guy can hope, right?

    • What could firefox gain out of OpenCL? Let’s first hope x264 decides to play with OpenCL.

      (I’d look into it just to learn how x264 works… but I lack a video card that takes advantage of OpenCL).

      • You don’t need a video card to use OpenCL, it also runs on your CPU, it’s only faster on the GPU.

      • “What could firefox gain out of OpenCL?”

        Ideally, media playback (swf, mp4, wmv, etc) in hardware, just as Quicktime X currently does for mp4 content on OS X Snow Leopard. On a “lesser” level, a boost to JS performance, CSS 3D transforms, and other HTML5 features to make a greater case for migration away from Flash.

        I’m sure there are many other uses.

  6. Hmm, in my testing with SunSpider, the 64-Bit version was about the same speed as the 32-Bit, although I wasn’t comparing exactly the same builds.

    I wonder what Apple does to make Safari 4.0.3 x86_64 on 10.6.1 1.76x faster than x86 in SunSpider 0.9. Tested repeatedly.
    WebKit-nightly is even faster, although speed improvement over 32-Bit is only 21% which seems much saner. WebKit 64-Bit is still about 2.26x as fast as latest 3.7a1 nightly of Firefox.

    SunSpider 0.9 results:
    WebKit-nightly 64-Bit: 388.4 ms (Addons: Safari AdBlock, GreaseKit)
    Safari 4.0.3 64-Bit: 412.6ms (Addons: Safari AdBlock, GreaseKit)
    WebKit-nightly 32-Bit: 472.8 ms (Addons: Safari AdBlock, GreaseKit)
    Chromium-nightly 32-Bit: 482.2 ms
    Safari 4.0.3 32-Bit: 726.4 ms (Addons: Safari AdBlock, GreaseKit)
    Firefox 3.7a1-nightly 32-Bit: 918.4 ms (Clean Profile)
    Firefox 3.7a1-x86_64 GCD 64-Bit: 928.6 ms (Clean Profile, Build from http://tinyurl.com/yzg47su – LLVM builds were slower)
    Firefox 3.5.3 32-Bit: 1146.6 ms (Clean Profile)
    Firefox 3.5.3 32-Bit: 1778.4 ms (Default Profile, AdBlock Plus, NoScript – Blacklisting mode)
    Opera 10.00 32-Bit: 4890.4 ms
    Internet Explorer 8.0 32-Bit: 5937.8ms (No Addons)

    All tests were done on Nehalem MacPro 8-core Xeon 2.26GHz w/16 threads and 16GB RAM running the 32-Bit Darwin Kernel, besides IE8 test which was done on a HP DL380G5 8-core Xeon E5420 2.5GHz and 6GB RAM running Windows 2003 Std. 32-Bit (~3,5GB usable RAM).

    I also compared IE8 32-Bit vs. 64-Bit inside a Windows 7 x64 VM and they were about the same speed (not that it matters with that slowest of browsers ;-).

    While WebKit’s Nitro and Chrome’s V8 JavaScript engine still hold the performance crown, it is interesting to see however, that Firefox is very quickly gaining. Firefox 3.0 was still about 3000 ms in sunspider.

    After all WebKit shows that quite some performance gain can be achieved by 64-Bit binaries, if well optimized.

  7. Hy guys!
    Any of you knows if it’s possible to use CoreAnimation to realize a Firefox plugin, or if it’s planned in the near future to enable it, as a draw agent? Thanks

  8. I’m not sure if comments in older posts are actually read, so this isn’t particularly related to this post, but…

    I’m trying to re-write a QuickDraw plugin into Cocoa. However, I’m not finding any sample projects that show how to get NSViews, etc to work in a Plugin… can anyone point me at a good source of samples? I’m already using basicplugin from the Mozilla source…

    thanks.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s