Media Encoding Performance with iTunes and Quicktime

The encoding tests here are identical to the ones that we run in our CPU tests, except obviously run under Mac OS X 10.4.4 instead of Windows XP.  It's important to note that iTunes, Quicktime as well as the iLife and iWork suites are all Universal applications, meaning that they run natively on both PowerPC and x86 architectures.  The performance comparisons on these next few pages is done without any binary translation.

MP3 Encoding Performance - iTunes 6.0.2

The iMac G5 is pretty strong at floating point performance as we've already seen, so the fact that the Core Duo completed the 304MB encoding task in 3/4 of the time set off some alarms.  The 1.9GHz iMac G5 is a single core, single processor machine, while the Core Duo based iMac has two cores running at 1.83GHz.  The iTunes encoding test, like many operations in Mac OS X applications, is multithreaded, meaning that it takes advantage of multi-core or multi-processor systems.  So the question we need to be asking is how much of this performance advantage is due to the Core Duo's dual cores?

Luckily, OS X's processor panel provides a quick and easy way to disable one of the cores in the Core Duo machine, so we have a way of finding out.  With one core disabled, I added the non-existant iMac Core Solo 1.83GHz to the graph:

MP3 Encoding Performance Take 2 - iTunes 6.0.2

With an encoding time of 73 seconds, the Core Solo 1.83GHz is actually slower than the G5 1.9GHz.  Intel doesn't win because of a faster single core. They win because they have two cores where Apple could previously only put one. 

Let's take a look at Quicktime next; once again, this is the same test that's run in our CPU reviews.  This time around, I've included the Core Solo from the start:

H.264 Encoding Performance - Quicktime Pro 7.0.4

While the Core Duo wins the test, the Core Solo is actually slower than the single core G5.  We can cut Intel a little slack here, as it seems that Quicktime isn't very well optimized for their processors and Apple is reportedly working on fixing that, but the point is that we have now seen two cases where the G5 doesn't lose because it's a slower chip. It loses because there is only one of them in the iMac. 

Boot Time iLife '06 Performance with iMovie HD
Comments Locked

35 Comments

View All Comments

  • Anand Lal Shimpi - Tuesday, January 31, 2006 - link

    Turning off one core leaves the full 2MB of cache for the other core to use since it is a shared L2.

    Take care,
    Anand
  • Eug - Tuesday, January 31, 2006 - link

    quote:

    Turning off one core leaves the full 2MB of cache for the other core to use since it is a shared L2.

    Take care,
    Anand

    Cool thanks.

    P.S. I have read elsewhere that the new iMac Core Duo uses less than half of the CPU's processing power to play back H.264 Hi-Def 1920x1080 video at a full 24 fps. If true, that's great, because my iMac 2.0 chokes on that. It plays back relatively smoothly, but only at about 12-15 fps.

    That bodes well for a future single-core Yonah Mac mini.

    Then again, probably not, considering that I suspect the iMac Core Duo does so well on H.264 playback because of its Radeon X1600. I'd doubt the Mac mini would get anything close to that any time soon.
  • Anand Lal Shimpi - Tuesday, January 31, 2006 - link

    Max CPU utilization (across both CPUs) when playing a 1080p stream scaled to fit the screen is about 60%, but it usually hovers below 50%. I am not sure whether or not the X1600's H.264 decode acceleration is taken advantage of (I doubt it), I'm trying to find out now. Also remember that on the PC side, the X1600 will only accelerate up to 720p.

    Take care,
    Anand

  • Anand Lal Shimpi - Tuesday, January 31, 2006 - link

    I just confirmed with ATI, the X1600's H.264 decode acceleration is currently not supported under OS X. ATI is working with Apple on trying to get the support built in, but currently it isn't there.

    Take care,
    Anand
  • Eug - Tuesday, January 31, 2006 - link

    quote:

    I just confirmed with ATI, the X1600's H.264 decode acceleration is currently not supported under OS X. ATI is working with Apple on trying to get the support built in, but currently it isn't there.

    Thanks again for the info. That's actually good news in a way. Things are looking up for that single-core Yonah Mac mini HTPC.
  • andrep74 - Tuesday, January 31, 2006 - link

    Isn't performance/Watt a function of the CPU, not the platform?
  • Kyteland - Tuesday, January 31, 2006 - link

    That picture of Jobs doesn't say "PC vs Intel" it says "PowerPC vs Intel". Jobs is just standing in the way. He's comparing the old mac to the new mac.
  • Calin - Tuesday, January 31, 2006 - link

    You could think about it that way - but in the end, the buyer is interested on the total energy consumption/heat production (as this is what he pays for, and what he must get rid of).
    Have you heard of the Toyota D4D engine? It has a record of 2.4 liter (less than a gallon) diesel fuel used per a hundred kilometers (60 miles). However, the same engine on a Land Cruiser 4x4 all options will get you much less (four times less maybe).
    It doesn't worths talking about performance per watt at the processor level, it is better at the platform level.
  • BUBKA - Tuesday, January 31, 2006 - link

    Were these benches done with a USB 2.0 device plugged in?
  • Furen - Tuesday, January 31, 2006 - link

    I was under the impression that Intel was blaming Microsoft for that, so that would not apply to OSX, though if the driver works perfectly for every platform except Napa I'd guess its a hardware problem that MS will fix in software (which is well enough as long as it works). The power consumption difference is probably less than 10W anyway. It matters on a notebook but hardly matters with a desktop.

Log in

Don't have an account? Sign up now