Final Words

The Mac Pro is pretty much everything the PowerMac G5 should have been. It's cooler, quieter, faster, has more expansion and it gives you more for your value than the older systems ever could.

If you were happy with your PowerMac G5, then you'll definitely be happy with the Mac Pro. And if you're a heavy multitasker, you will quickly be spoiled by the four very high performance cores that have found their way into the familiar looking chassis.

We did want a little more out of the system; for a company that usually embraces up and coming standards we wanted to see things like eSATA or CrossFire/SLI supported, but that's mostly for the geek in us that just likes playing around with interesting technologies. We would've also appreciated a more upgrade friendly setup; while we do appreciate how easy it is to install new drives and memory, replacing your CPUs is much more time intensive. Seeing as how you can now buy CPUs for your Mac from Newegg thanks to Apple using regular Intel processors, we'd assume that CPU upgrades will be done a bit more frequently especially as time goes on and prices drop.

From a performance standpoint, running OS X, the Mac Pro is truly Apple's fastest system by a long shot. Some of the performance advantages over the PowerMac G5 aren't enormous, but then you look at situations like iPhoto, Xcode or Final Cut Pro where the G5 is just put to shame. Rosetta performance is just about as good as it gets, the only real solution to that problem is for Adobe and Microsoft to hurry up and release updated software. Unfortunately since Apple isn't really a favorite of either company, it's not like greater than usual amounts of resources are being thrown at releasing new products specifically for the Mac platform.

Would we suggest staying away from the Mac Pro until all applications are available as Universal Binaries? No. But make sure you know what you're getting yourself into before you buy anything: emulated performance is bearable, but it's by no means fast.

One of our biggest concern about the Mac Pro is that users who don't need 8 memory slots or four cores would be better off if Apple released a single socket Core 2 based Mac tower. The memory performance of FBD on the Intel 5000X chipset is absolutely horrid and there's nothing you can do about it unless you switch entirely to an all serial interface or go back to using regular DDR2 memory.

The memory performance of the Mac Pro is noticeably better than the PowerMac G5 and competitive with other products in the Mac lineup (for now), but it's still significantly lower than where it could be. Intel seems married to its FBD strategy for now, which unfortunately means that as long as Apple wants two sockets for the Mac Pro, you'll need to deal with FBD. Our recommendation to Apple? Give us a Core 2 based tower. Our recommendation to Intel? Give us an alternative to FBD.

Power Consumption
POST A COMMENT

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. Reply
  • 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. Reply
  • 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 Reply
  • 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. Reply
  • 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. Reply
  • 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.
    Reply
  • 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.
    Reply
  • michael2k - Saturday, August 19, 2006 - link

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

    Thanks for the best laugh I've had all week!
    I really needed it!!
    Reply
  • 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.
    Reply

Log in

Don't have an account? Sign up now