Using the Mac Pro

Internally the Mac Pro is a completely different beast than the outgoing PowerMac G5, but pressing the power button yields the same classic Mac startup sound and brings you to the same desktop that the G5 did. Of course the version of OS X installed on the Mac Pro is the x86 compatible Intel version, but it's impossible to tell as a user.

The Mac Pro is noticeably quieter than its predecessor, thanks to larger, slower spinning fans made possible by cooler running Intel processors. Power consumption is down noticeably compared to the PowerMac G5 and thus the system runs cooler and quieter.

The one noise you do hear more of (mainly since there's less fan noise to drown it out) comes from the HDD. With no sound deadening in the chassis, random seeks on the hard drive almost seem amplified. If you're in a quiet office, you'll hear the sounds of the hard drive. The Mac Pro seems to be shipping with one of two drives: the Seagate 7200.9 or the Western Digital WD2500JS, both in a 250GB size. Of the two, the Seagate appears to be the louder inside the case (subjectively) but you can't choose which one you get.

A nice feature is that each drive sled is labeled and the label is also visible in the OS. When you view the details of a drive in Apple's Disk Utility it will also tell you what bay it's located in.

The optical drive is the other noisy component in the system, but that only happens whenever a disc is spun up obviously. Optical drives are inherently noisy, but with such a quiet system everything else is that much more noticeable.

Software wise, the Mac Pro is pretty much identical to its predecessor. The system starts up slightly quicker than the PowerMac G5 and the OS itself feels a bit smoother. We actually noticed this when reviewing the MacBook Pro; there are many cases where the Intel based Macs feel noticeably quicker than the G5 equipped Macs. Our benchmarks support the increase in performance but it is definitely noticeable in some areas. In other areas, the Mac Pro just works and feels like a quieter G5.

As the last desktop Mac to make the transition to Intel processors, the Mac Pro enjoys having a much larger library of Universal Binary applications to run (apps that run native on x86 Macs). All of Apple's applications have been ported over to Universal Binaries either through patches or upgrades and many 3rd party applications have also been recompiled. If the application was written in Xcode, the transition is quite easy and thus those applications that were have since been re-released as UB apps. Unfortunately larger applications from non-Apple developers (e.g. Adobe and Microsoft) and most games -- with very little developer support to begin with -- have not been ported.

Both Adobe and Microsoft have stated that they will not update currently shipping products to Universal Binary versions and will instead simply offer support for Intel Macs in future versions. For Adobe that means the CS3 suite of applications, which is due out as early as the end of this year or as late as Q2 of next. For Microsoft, we're most definitely talking about sometime in mid to late 2007 (at best) as the Windows version of Office 2007 isn't due out until early next year itself.

To run those non-native applications Mac Pro users will have to rely on Rosetta, Apple's PowerPC to x86 binary translation software. We'll look at Rosetta performance on the Mac Pro towards the end of this article, but in practical use it's not terrible. All of the crashing we ran into when we first played with Rosetta on the iMac Core Duo has since been resolved with updates to OS X; now all that remains is a performance penalty when running non-native applications.

Thankfully, the Mac Pro's Xeons are about as quick as you can get. And while they will never be able to run PowerPC native applications as quickly as a G5, they can run them well enough for you to use them. Performance with Rosetta is bearable on the Mac Pro; in most cases you'll know you're not running a native application, and you'll probably begin looking for alternative applications to use (that are UBs), but you can get by if you have to use one. We would strongly recommend finding out if the applications you use on a regular basis are available as Universal Binaries before upgrading from a newer PowerPC Mac just so there are no surprises after taking the plunge.

The other suggestion we have is to make sure you've got enough memory on hand, especially if you're going to be multitasking heavily or running a lot of non-native applications. The 1GB that these systems come with is absolutely the minimum; we tried running with only 512MB enabled and came away thoroughly disappointed in the system's performance (thankfully this isn't a supported configuration). With 1GB, you can easily get by but we'd suggest a 2GB sweet spot at least. Remember that OS X does a great job caching everything; the more memory you throw at it the more it will use to keep from accessing the hard drive.

As the first quad processor (two socket, dual core) Mac we've tested, it's worth talking about the move from two to four cores and what that does for performance. When you move from one to two cores, you get a noticeable boost in performance from multithreaded applications as well as a tangible increase in multitasking performance; going from two to four however, isn't always as noticeable.

Very few applications, multithreaded or not, are entirely CPU bound; they are instead limited by software, memory bandwidth, I/O performance, network latency, user input or a combination of these bottlenecks. Even with those bottlenecks in place, the CPU does play a role in performance; it's just a question of how much of a role. What we noticed when testing the quad core Mac Pro was that these bottlenecks became even more apparent when working with four cores as compared to just two.

Individual applications rarely saw a huge benefit going from dual to quad core even if they saw a big boost when making the jump from single to dual core. In practical use, no single application felt faster when running on four cores vs. two. It was in multitasking that we noticed the biggest difference with quad cores, and it was actually the only place our benchmarks showed a significant difference in performance as well. While the four cores did their best to make our heavy multitasking sessions as responsive as possible, we did notice I/O limitations even more when using four cores than when using two.

The more parallelized our usage models become, the more parallelized our I/O subsystems will have to get in response in order to keep up. It's quite possible that RAID 0 (or 0+1) may be necessary to improve the multitasking experience when running with four cores. The balancing of processing power with I/O in multitasking scenarios is something we're still investigating, but it looks like those extra drive bays in the Mac Pro may come in handy after all.

Xeons Run Cooler than G5s The Test
Comments Locked

96 Comments

View All Comments

  • tmohajir - Thursday, August 17, 2006 - link

    I had the same question. I was debating whether to by 2 x 512MB or 1GB, and then thought it might affect performance if I went with the 1GB sticks. I think for now the best bet would be to buy 2 512s so that each branch has a channel with the same amount of memory. Then if I want to upgrade later, move all 4 512s to riser 1, and buy 2 1GB dimms when the price drops a little more and stick them in riser 2. So that way you still have 2GB total per branch.
  • dborod - Thursday, August 17, 2006 - link

    I decided to order my MacPro with 4 x 512 MB dimms so as to be able to fully utilize the available memory bandwidth. It seemed the easiest and safest approach for now.
  • dborod - Thursday, August 17, 2006 - link

    I decided to order my MacPro with 4 x 512 MB dimms so as to be able to fully utilize the available memory bandwidth. It seemed the easiest and sa
  • Questar - Wednesday, August 16, 2006 - link

    Why use MP3 encoding for performace testing in a multi cpu environment? MP3 encoding is not very threadable, and most likely is not threaded to any great extent in iTunes.
  • Griswold - Thursday, August 17, 2006 - link

    Somebody obviously has never used the multithreaded encoder of the LAME MT project. I see gains of up to 50% with that. Sure, that may not be relevant for a mac pro user, but it is proof that MP3 encoding benefits from SMT.
  • Questar - Thursday, August 17, 2006 - link

    Griswald stikes again.

    Yes I've heard of LAMEMT. So how's that sound quality you're getting without a bit resevoir? Pretty crappy I'll bet.
  • Griswold - Friday, August 18, 2006 - link

    Oh give me a break nutsack. Dont pretend you know what you're talking about here, as it doesnt match your first (false) post - you obviously never used LameMT. Disabling bit reservoir may come with a certain loss of quality, but its not nearly as much as you (or the poster above) want it to make to be. I'm willing to bet 95% of the people using mp3 wont notice the difference.

    I'm listening to the same song encoded with standard Lame and LameMT and the quality is virtually the same. Of course, you'll now say your ears are so much better, you got so much better audio equipment and what not.. but meh, it's just questdork talking.
  • michael2k - Saturday, August 19, 2006 - link

    The same 95% of the population who purchase tracks from the iTMS I bet :)
  • Questar - Friday, August 18, 2006 - link

    Thanks for the best laugh I've had all week!
    I really needed it!!
  • saratoga - Thursday, August 17, 2006 - link

    quote:

    Somebody obviously has never used the multithreaded encoder of the LAME MT project. I see gains of up to 50% with that.


    Yeah but you also lose quality, so very few people use it.

    quote:

    Sure, that may not be relevant for a mac pro user, but it is proof that MP3 encoding benefits from SMT.


    Not exactly. LAMEMT is only multithreaded when you use parts of the MP3 standard that can be multithreaded. Typical MP3 encoding as done by lame, itunes, xing, etc simply can not be multithreaded. LAMEMT can be multithreaded because it disables certain features that are incompatable and then implements software pipelining.

    The LAME devs have talked about trying to work around this problem in the past, but so far most people seem to think its just not worth the effort because the speed up is much worse then just running two copies of LAME (which gives a 100% speedup verses the 50% you saw), and of course the unresolved questions about just how badly quality would be hurt by rewriting LAME profiles from scratch to use the approach in LAMEMT.

Log in

Don't have an account? Sign up now