Workstation, yes; Server, no.

The G5 is a gigantic improvement over the previous CPU in the PowerMac, the G4e. The G5 is one of the most superscalar CPUs ever, and has all the characteristics that could give Apple the edge, especially now that the clock speed race between AMD and Intel is over. However, there is still a lot of work to be done.

First of all, the G5 needs a lower latency access to the memory because right now, the integer performance of the G5 leaves a lot to be desired. The Opteron and Xeon have a better integer engine, and especially the Pentium 4/Xeon has a better Branch predictor too. The Opteron's memory subsystem runs circles around the G5's.

Secondly, it is clear that the G5 FP performance, despite its access to 32 architectural registers, needs good optimisation. Only one of our flops tests was " Altivectorized", which means that the GCC compiler needs to improve quite a bit before it can turn those many open source programs into super fast applications on the Mac. In contrast, the Intel compiler can vectorize all 8 tests.

Altivec or the velocity engine can make the G5 shine in workstation applications. A good example is Lightwave where the G5 takes on the best x86 competition in some situations, and remains behind in others.

The future looks promising in the workstation market for Apple, as the G5 has a lot of unused potential and the increasing market share of the Power Mac should tempt developers to put a little more effort in Mac optimisation.

The server performance of the Apple platform is, however, catastrophic. When we asked Apple for a reaction, they told us that some database vendors, Sybase and Oracle, have found a way around the threading problems. We'll try Sybase later, but frankly, we are very sceptical. The whole "multi-threaded Mach microkernel trapped inside a monolithic FreeBSD cocoon with several threading wrappers and coarse-grained threading access to the kernel", with a "backwards compatibility" millstone around its neck sounds like a bad fusion recipe for performance.

Workstation apps will hardly mind, but the performance of server applications depends greatly on the threading, signalling and locking engine. I am no operating system expert, but with the data that we have today, I think that a PowerPC optimised Linux such as Yellow Dog is a better idea for the Xserve than Mac OS X server.

References

Threading on OS X
http://developer.apple.com/technotes/tn/tn2028.html

Basics OS X
http://developer.apple.com/documentation/macosx/index.html


Mac OS X versus Linux
POST A COMMENT

113 Comments

View All Comments

  • 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.
    Reply
  • 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.
    Reply
  • 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...
    Reply
  • 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. Reply
  • 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
    Reply
  • shanep - Saturday, June 4, 2005 - link

    Re: NetBSD.

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

    Forget I mentioned it.
    Reply
  • 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.
    Reply
  • 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...
    Reply
  • johannesrexx - Saturday, June 4, 2005 - link

    Everybody should use Firefox by default because it's far more secure. Use IE only when you must. Reply
  • michaelok - Saturday, June 4, 2005 - link

    "with one benchmark showing that the PowerMac is just a mediocre PC while another shows it off as a supercomputer, the unchallenged king of the personal computer world."

    Well, things are a little different when you connect, say, 32768 processors together, i.e. you go from running MySQL to Teradata, so yes, the Power architecture seems to dominate, and the Virginia Tech supercomputer is still up there, at 7th.

    http://www.top500.org/lists/plists.php?Y=2004&...

    " The RISC ISA, which is quite complex and can hardly be called "Reduced" (The R of RISC), provides 32 architectural registers"

    'Reduced Instruction Set' is misleading, it actually refers to a design philosophy of using *smaller, simpler* instructions, instead of a single complex instruction. This is to be compared with the Itanium for example, which Intel calls 'EPIC' (Explicit Parallel Instruction Computing), but it is essentially derived from VLIW (Very Long Instruction Word).

    Anyway, nice article, certainly much more to discuss here, such as SMT (Simultaneous Multithreading), (when that is available for the Apple :), vs. Intel's Hyperthreading. We'll still be comparing Apples to Oranges but isn't that why everybody buys the Motor Trend articles, i.e. '68 Mustang vs. '68 GT?


    Reply

Log in

Don't have an account? Sign up now