Apple's Mac Pro - A True PowerMac Successor
by Anand Lal Shimpi on August 16, 2006 12:27 PM EST- Posted in
- Mac
iLife '06 Performance with iPhoto, iMovie HD and iDVD
One of the benefits of OS X and Apple's application suites is that most of the applications are already properly threaded. Even though you wouldn't expect it, iPhoto is threaded quite well and thus our import photos test gets a speedup from going to quad cores.
The test is simple; we timed the import of 379 photos into iPhoto which, believe it or not, is quite CPU intensive and not as I/O bound as you'd think. After we got the time we divided it into 379 to get the number of pictures imported per second. We included the performance of a hypothetical dual core Mac Pro in addition to the native quad offerings in order to provide a good point of comparison to the dual processor PowerMac G5s.
Although there's a slight performance boost when going from dual to quad core (6.9%), this test is largely dependent on clock speed within a single microprocessor architecture. Comparing the Woodcrest based Xeons to the older G5s is no contest, at 2.0GHz the Mac Pro is already 14% faster than the 2.5GHz PowerMac G5; even if we account for the dual vs. quad core comparison, the 2.0GHz Mac Pro is still noticeably faster than the G5.
The next application we looked at was iMovie HD. There are two primary focuses for performance in iMovie HD, video import speed (if you are dealing with a non-DV or non-iSight video source) and effect rendering speed. We focused on the latter, measuring the time it takes to render the most CPU intensive transition and video effect in iMovie HD.
Our Macs have gotten a little too fast for the billow transition test, as the Mac Pro 2.66GHz can now complete the test in 3 seconds flat. All of the Mac Pros here are faster than the PowerMac G5s, which is what we'd expect given what we learned in the iMac Core Duo vs. iMac G5 article.
Rendering the "Electricity" Video FX sees no benefit going from dual to quad cores, but the Mac Pro doesn't need it as the 2.0GHz configuration is already 26.5% faster than the PowerMac G5 2.5GHz.
Finally we've got iDVD, an application that you can use to create DVDs that are playable on any consumer DVD player. There are once again two aspects to performance in iDVD, video encoding performance and menu encoding performance. Since we've already looked at video encoding performance with Quicktime, this test is predominantly limited by how long it takes to encode the menu system in our test DVD. There is a small 13 second iSight video and audio that's encoded in the process but it adds a matter of seconds to the overall time. The image is written to disc instead of sent to the DVD burner for obvious reasons. The results are expressed in seconds, lower being better. This workload is multithreaded.
The benchmark gets just under 11% thanks to the 4 cores in the Mac Pro, but even without them the Mac Pro 2.66GHz is able to outperform the PowerMac G5 2.5GHz by just under 13%. The Xeon seems to scale much better with clock speed in this test than the G5.
Facebook
Twitter
RSS
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 saQuestar - 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
Yeah but you also lose quality, so very few people use it.
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.