Apple's Mac Pro - A True PowerMac Successor
by Anand Lal Shimpi on August 16, 2006 12:27 PM EST- Posted in
- Mac
Rosetta Performance (or lack thereof)
With no Universal Binary versions of Adobe or Microsoft applications, you're bound to run into something that isn't native on the Mac Pro. Of course if there's performance to be lost, we're there to benchmark it.
First off, let's look at our Word HTML conversion test. Note that this test used to crash on earlier builds of OS X, but Apple has thankfully fixed the problem so it now completes. The only other problem is that it takes a long time to complete:
The fastest Mac Pro configuration we tested took about three times as long to complete this test as the PowerMac G5, and that's about how things feel when you're running a Rosetta application. The application is always bearable, but it feels like everything takes 2 - 3x as long as it would if it were native.
Next up we ran PSBench under Photoshop CS2 and came away with some more interesting results:
| Apple Mac Pro 2.66GHz (Quad) | Apple Mac Pro 2.66GHz (Dual) | Apple PowerMac G5 2.5GHz (Dual) | |
| Rotate Clockwise - 90 degrees |
0.6
|
0.5
|
0.5
|
| Rotate Clockwise - 9 degrees |
2.2
|
3
|
1.2
|
| Rotate Clockwise - 0.9 degrees |
4
|
4.1
|
3.6
|
| 1 pixel Gaussian Blur |
2.2
|
2.3
|
2.1
|
| 3.7 pixel Gaussian Blur |
2.5
|
3.4
|
2.8
|
| 85 pixel Gaussian Blur |
3
|
4.2
|
3.1
|
| 50%, 1 pixel, 0 level unsharp mask |
2.3
|
3
|
2.2
|
| 50%, 3.7 pixel, 0 lever unsharp mask |
3.4
|
4.3
|
3.6
|
| 50%, 10 pixel, 5 level unsharp mask |
3.2
|
4.6
|
4
|
| Despeckle filter |
2.2
|
2.4
|
2.5
|
| RGB to CMYK |
3.8
|
5.2
|
3.4
|
| 60% Reduction |
1.4
|
1.6
|
1.4
|
| Lens Flare |
5.3
|
5.3
|
4.9
|
| Color Halftone Filter |
21.5
|
23.1
|
9.2
|
| NTSC Colors Filter |
5.9
|
5.9
|
4.1
|
| Accented Edges Brush Strokes |
13.3
|
13.7
|
10.7
|
| Pointillize Filter |
31
|
36.9
|
15.8
|
| Watercolor Filter |
28.8
|
31.2
|
20.8
|
| Polar Coordinates |
2.1
|
2.9
|
1.6
|
| Radial Blur Filter |
7.3
|
11.3
|
17.1
|
| Lighting Effects Filter |
3.5
|
4
|
2.9
|
| Total |
149.5
|
172.9
|
117.5
|
The PowerMac G5 is still faster, overall it completed all of the tasks about 32% faster than the dual core Mac Pro 2.66GHz but comparing it to the shipping quad core configuration closed that gap even more. There were even some tests that the non-native Mac Pro could complete quicker than the PowerMac G5, which bodes well for how fast the Mac Pro will be when Photoshop CS3 eventually comes out.
Overall, Rosetta has gotten better in terms of stability, but performance is still no where near native G5 performance on average (nor did anyone expect it to be). You can get by using Rosetta, but it will irritate you especially if you're using any Universal Binary applications on a regular basis as the difference in performance is fairly apparent.
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.