The G5 as Server CPU

While it is the Xserve and not the PowerMac that is Apple's server platform, we could not resist the temptation to test the G5 based machine as a server too. Installed on the machine was the server version of Mac OS X Tiger. So in fact, we are giving the Apple platform a small advantage: the 2.5 GHz CPUs are a bit faster than the 2.3 GHz of the Xserve, and the RAM doesn't use ECC as in the Xserve.

A few months before, we had a quick test run with the beautifully designed and incredible silent 1U Xserve and results were similar, albeit lower, than the ones that we measured on the PowerMac.

Network performance wasn't an issue. We used a direct Gigabit Ethernet link between client and server. On average, the server received 4 Mbit/s and sent 19 Mbit/s of data, with a peak of 140 Mbit/s, way below the limits of Gigabit. The disk system wasn't very challenged either: up to 600 KB of reads and at most 23 KB/s writes. You can read more about our MySQL test methods here.

Ever heard about the famous English Plum pudding? That is the best way to describe the MySQL performance on the G5/ Mac OS X server combination. Performance is decent with one or two virtual client connecting. Once we go to 5 and 10 concurrent connections, the Apple plum pudding collapses.

Dual G5 2,5 GHz PowerMac Dual Xeon DP 3,6 GHz (HT on) Dual Xeon DP 3,6 GHz (HT out) Dual Opteron 2.4Ghz
1 192 286 287 290
2 274 450 457 438
5 113 497 559 543
10 62 517 583 629
20 50 545 561 670
35 50 486 573 650
50 47 495 570 669

Performance is at that point only 1/10th of the Opteron and Xeon. We have tested this on Panther (10.3) and on Tiger (10.4.1), triple-checked every possible error and the result remains the same: something is terribly wrong with the MySQL server performance.

SPEC CPU 2000 Int numbers compiled with GCC show that the G5 reaches about 75% of the integer performance of an equally clocked Opteron. So, the purely integer performance is not the issue. The Opteron should be quite faster, but not 10 times faster.

We checked with the activity monitor, and the CPUs were indeed working hard: up to 185% CPU load on the MySQL process. Notice that the MySQL process consists of no less than 60 threads.

We did a check with Apache 1.3 and the standard "ab" (Apachebench) benchmark:

Concurrency Dual Powermac G5 2.5 GHz (Panther) Dual Powermac G5 2.7 GHz (Tiger) Dual Xeon 3.6 GHz
5 216.34 217.6 3776.44
20 216.24 217.68 3711.4
50 269.38 218.32 3624.63
100 249.51 217.69 3768.89
150 268.59 256.89 3600.1

The new OS, Tiger doesn't help: the 2.7 GHz (10.4.1) is as fast as the 2.5 GHz on Panther (10.3). More importantly, Apache shows exactly the same picture as MySQL: performance is 10 times more worse than on the Xeon (and Opteron) on Linux. Apple is very proud about the Mac OS X Unix roots, but it seems that the typical Unix/Linux software isn't too fond of Apple. Let us find out what happened!

Micro CPU benchmarks: isolating the FPU Mac OS X: beautiful but…
Comments Locked

116 Comments

View All Comments

  • seanp789 - Saturday, June 4, 2005 - link

    well thats great and all but yours news says apple is switchign to intel so i dont think much will be changing in the power pc lineup
  • Brazilian Joe - Saturday, June 4, 2005 - link

    I would like to see this Article re-done, with more benches to give a clearer picture. I think MACOS X should be pitched against Darwin in the PPC platform, since there may be hidden differences. Darwin works on x86 too (and x86_64?), it would be very interesting to see the SAME OS under the Mac Platform running on different hardware. And having the software compiled with the same compiler present on Darwin, we should get a more consistent result. Linux and BSD should not be ditched, however. The perfornance difference Of linux/FreeBSD/OpenBSD in PPC vs PC is also a very interesting subject to investigate.
    I think this article, along with all the complaints of inconsistency in the results, sohuld fuel a new series of articles: One, Just comparing Darwin/MacOS X on Both platforms. Another For Linux, using a GCC version as close as possible to that used on Darwin. Another for FreeBSD, and yet another for OpenBSD. The last article Would get everything and summarize. I think this would be much more complete and satisfying/informative for the reader crowd.
  • iljitsch - Saturday, June 4, 2005 - link

    There seems to be considerable confusion between threads and processes in the review. I have no trouble believing that MacOS doesn't do so well with process gymnastics, but considering the way Apple itself leverages threads, I would assume those perform much better.

    I don't understand why Apache 1.3 was used here, Apache 2.0 has much better multiprocessor capabilities and would have allowed to test the difference between the request-are-handled-in-processes and requests-are-handled-in-threads ways of doing things.
  • Phil - Saturday, June 4, 2005 - link

    #79: Wow. I had no idea that they were actually going to do it, I had assumed that it was typical industry nonsense!
    If this is true, then IMHO Apple won't be in much of a better position (with regards to this article) as they'll still need to work on the OS, regardless.

    Can anyone speculate as to why they *really* want to switch to x86/Intel? I wonder if they'll consider AMD too...
  • rorsten - Saturday, June 4, 2005 - link

    Uhm, the estimation for power consumption is completely wrong. The only significant CMOS power consumption - especially for an SOI chip - is the current required to charge or discharge the gates of the FETs, which only happens when a value changes (the clock accounts for most of the power consumption on a modern synchronous chip). Since we're talking about current only, this is purely resistive power, I^2R style, and since the current is related to the number of transitions per second, increasing the clock rate linearly increases the current which quadratically increases the power consumption.
  • kamper - Saturday, June 4, 2005 - link

    Here's another story about Apple and Intel from cnet:
    http://news.com.com/Apple+to+ditch+IBM%2C+switch+t...

    Interesting in the context of this article but I won't believe it without much more substantial proof :)

    +1 on getting a db test using the same os on all architectures whether it be linux or bsd

    +1 on fixing the table so that it renders in firefox
  • shanep - Saturday, June 4, 2005 - link

    Re: NetBSD.

    Sorry, I just noticed it is not supported yet by NetBSD.

    Forget I mentioned it.
  • shanep - Saturday, June 4, 2005 - link

    "Wessonality: Our next project if we can keep the G5 long enough in the labs."

    How about testing these machines with NetBSD 2.0.2 to keep the hardware comparison on as close an equal footing as possible.

    This should mostly remove many red herrings associated with multiple differences in software across different hardware.
  • michaelok - Saturday, June 4, 2005 - link

    "i've had for awhile about OS X server handling large numbers of thread. My OS X servers ALWAYS tank hard with lots of open sessions, so i keep them around only for emergencies. T"

    Moshe Bar (openMosix) has been an avid Mac follower for years, I see he has a few suggestions for OSX, including ditching the Mach so you can run FreeBSD natively, which has much better peformance. In fact, thread performance is one of FreeBSDs strong points, although Linux has largely caught up.

    Also research his Byte articles, you can see how a proper comparison can be done, although he does not claim to be a benchmarking expert.

    http://www.moshebar.com/tech/?q=node/5
    http://www.byte.com/documents/s=7865/byt1064782374...
  • johannesrexx - Saturday, June 4, 2005 - link

    Everybody should use Firefox by default because it's far more secure. Use IE only when you must.

Log in

Don't have an account? Sign up now