Leopard Beta Performance (June 2007)

Posted June 20th, 2007 in Geekbench | Comments

Last week MacRumors posted a first-hand report of the latest Leopard beta. The report, which covered what was new and improved with the latest Leopard beta, also included a link to the Geekbench Result Browser; someone benchmarked a Mac Pro running Leopard using Geekbench 2.

I thought it’d be interesting to compare the Leopard Geekbench result against a Tiger Geekbench result from a similarly-configured Mac Pro to see if there are any performance improvements in Leopard.

Setup

  • Mac Pro

    • Dual Intel Dual-Core Xeons @ 3.00GHz
    • 2.00 GB 667 MHz DDR2 FB-DIMM
    • Mac OS X 10.5 (Build 9A466)

  • Mac Pro

    • Dual Intel Dual-Core Xeons @ 3.00GHz
    • 2.00 GB 667 MHz DDR2 FB-DIMM
    • Mac OS X 10.4.9 (Build 8P2137)

I’ve reported the average overall score for each model and processor combination, where 1000 is the score a Power Mac G5 @ 1.6GHz would receive. Higher scores are better. Keep in mind that Geekbench 2 only measures processor and memory performance; it won’t catch any differences in other subsystems like, say, video drivers.

Results

Overall Performance

Mac Pro
Leopard		 5335
 
Mac Pro
Tiger		 5560
 

Integer Performance

Mac Pro
Leopard		 5130
 
Mac Pro
Tiger		 5174
 

Floating Point Performance

Mac Pro
Leopard		 8662
 
Mac Pro
Tiger		 8825
 

Memory Performance

Mac Pro
Leopard		 1816
 
Mac Pro
Tiger		 2366
 

Stream Performance

Mac Pro
Leopard		 1456
 
Mac Pro
Tiger		 1873
 

Conclusions

Processor performance (at least when it comes to Geekbench) is practically unchanged from Tiger to Leopard. While there’s been talk of enhancements in Leopard that will increase performance on multiple-core machines, there’s no sign of an improvement on a quad-core Mac Pro. It’s entirely possible that these ehancements will only really benefit Macs with eight or more cores.

Unlike processor performance, memory performance (in both the memory and stream sections) has decreased under Leopard. While some of the decrease could be explained by unoptimized libraries in Leopard (which some of the benchmarks rely on quite heavily), I don’t know why memory bandwidth decreased in the stream section.

Of course, Leopard is still in beta, so it’s not clear how these numbers will look once Leopard is released in October. I still think it’s interesting, though, to see where Leopard development is right now (especially now that Leopard is feature complete).

  • mlang

    Very little code is required to activate the multithreading ability of Leopard...


    Check out these videos. World of Warcraft beta with multithreading code gets a FPS SCORE of 160 while the non multithreaded version can only get to 40 FPS.


    Apple WWDC Demo of World of Warcraft on Leopard OSX 10.5
    http://www.youtube.com/watch?v=PM6s59OPJbk&...>

    Apple 32bit Vs 64bit WWDC demo OSX 10.5
    http://www.youtube.com/watch?v=gezP5g48fSU</p>

  • Cubert

    I just think Leopard is not optimized completely yet. Weren't there similar results with Tiger vs. Panther? I thought I remember significant benchmark improvements in Tiger from beta to release.


    The developer blogs report a generalized feeling of a quicker and more responsive OS, although I do believe the Intel Macs will see more of a benefit in Leopard than PowerPC Macs.


    Also, Thej, not all of us are going to be running 64-bit apps AND multi-core Macs. I want Leopard to fly for 32-bit apps and single processor Macs (G4 and G5).

  • Sam

    I'm not privy to the pre-release builds, I doubt there are any "debugging processes" that would affect streaming and memory benchmarks. I suspect Leopard may just really be slightly slower than Tiger. It's not unusual for newer releases to do more and be a little slower-- 10.0 through 10.4 was more an exception that people came to depend on (in part Apple got away with it because 10.0 was so incredibly slow).


    It's also not that unusual to trade better multi-core/parallel performance for slightly worse linear performance. It's possible the buffering, locking, synchronization, etc., are more tuned to the multiprocessing case. (More synchronization can allow more parallelism at the expense of higher overhead.)


    In other words, the real test will be real-world usage. Not having to wait for drives to mount or the Finder not locking up when accessing a share will more than make up for a 5-10% drop in some benchmarks to me.

  • thej

    Leopard will show performance increases that Geekbench can't because Geekbench isn't 64-bit and it does not use the new APIs available in Leopard. Specifically APIs that manage theads on multiple cores.

  • I think the same as George. Debugging processes are making it slower than tiger. Let's wait until October to see the real thing.

  • George Matook

    I'm no developer, but it is my understanding that such betas have multitudes of background/debugging processes running that would not normally be functional on a release version of the software. This, and the fact that they won't be finalizing the optimization until later in the production cycle, could be contributing to the unchanged and decreased performances you are seeing. Either way, I'm certainly looking forward to it (and your new benchmark) in October!
    -George

blog comments powered by Disqus