<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	>
<channel>
	<title>Comments on: Mac Pro performance</title>
	<atom:link href="http://www.rassoc.com/gregr/weblog/2008/02/24/mac-pro-performance/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.rassoc.com/gregr/weblog/2008/02/24/mac-pro-performance/</link>
	<description>Musings on just about everything.</description>
	<pubDate>Sun, 12 Oct 2008 10:23:17 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.6</generator>
		<item>
		<title>By: gregr</title>
		<link>http://www.rassoc.com/gregr/weblog/2008/02/24/mac-pro-performance/#comment-7594</link>
		<dc:creator>gregr</dc:creator>
		<pubDate>Tue, 26 Feb 2008 14:39:24 +0000</pubDate>
		<guid isPermaLink="false">http://www.rassoc.com/gregr/weblog/2008/02/24/mac-pro-performance/#comment-7594</guid>
		<description>@Ted - actually, in this particular workload, disk performance doesn't make that big of a difference.  Even in the case where a 1:1 preview could be generated in 1 second (faster than any of these scenarios), that means the system needs to read 1 raw file per second, and write one 1:1 preview per second (and likely make one database update).  That means reading roughly 10 MB/sec, and writing some level less than that (and these numbers were verified during the tests).

So even a 2.5" laptop disk can comfortably keep up with this.  The particular operation I was testing here is CPU-bound.

Generating regular previews is a different animal - in that case, it appears to be much more I/O intensive.

In any case, for the sake of completeness...the Mac pro had 3 disks - one for system, one for photos, and one for the Lightroom database.  And the Macbook Pro had a single internal drive.  All of the VM's had a single virtual disk, mapped to the MP system drive.</description>
		<content:encoded><![CDATA[<p>@Ted - actually, in this particular workload, disk performance doesn&#8217;t make that big of a difference.  Even in the case where a 1:1 preview could be generated in 1 second (faster than any of these scenarios), that means the system needs to read 1 raw file per second, and write one 1:1 preview per second (and likely make one database update).  That means reading roughly 10 MB/sec, and writing some level less than that (and these numbers were verified during the tests).</p>
<p>So even a 2.5&#8243; laptop disk can comfortably keep up with this.  The particular operation I was testing here is CPU-bound.</p>
<p>Generating regular previews is a different animal - in that case, it appears to be much more I/O intensive.</p>
<p>In any case, for the sake of completeness&#8230;the Mac pro had 3 disks - one for system, one for photos, and one for the Lightroom database.  And the Macbook Pro had a single internal drive.  All of the VM&#8217;s had a single virtual disk, mapped to the MP system drive.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Ted</title>
		<link>http://www.rassoc.com/gregr/weblog/2008/02/24/mac-pro-performance/#comment-7568</link>
		<dc:creator>Ted</dc:creator>
		<pubDate>Tue, 26 Feb 2008 06:05:40 +0000</pubDate>
		<guid isPermaLink="false">http://www.rassoc.com/gregr/weblog/2008/02/24/mac-pro-performance/#comment-7568</guid>
		<description>There's one large puzzling omission. Since you go to great lengths to document the usage level of each processor type, I'm surprised you did not mention the disk types and their throughput at all.

When you generate previews for an app like Lightroom or Aperture or Bridge etc from RAW files, one of the major determinants of performance is how quickly the app can read the raw file off disk and then how fast it can write the big preview back out.  This is going to have as much of an effect on the throughput as anything. It can sometimes be the ultimate bottleneck of the process, yet the attention is on the processors, which could be waiting for data both coming from and going to the disk. In other words, some of the performance differences in your CPU measurements may be reflecting disk bottlenecks which are not accounted for, especially when a poor little 2.5" laptop disk is involved in such a demanding read/write operation against the heavy-duty disk subsystem of a Mac Pro.

Everyone seems so obsessed with multicore, when performance in this type of app always stands on the three legs of CPU, RAM, and disk. You got the first two covered, but the third is missing in action. If this was comparing Final Cut or Photoshop, then the scratch disk setup would be absolutely critical to the performance comparison, so if you ever branch out your tests that way, don't leave that out.

Still, you're going to be really happy with that Mac Pro! (I sure am.)</description>
		<content:encoded><![CDATA[<p>There&#8217;s one large puzzling omission. Since you go to great lengths to document the usage level of each processor type, I&#8217;m surprised you did not mention the disk types and their throughput at all.</p>
<p>When you generate previews for an app like Lightroom or Aperture or Bridge etc from RAW files, one of the major determinants of performance is how quickly the app can read the raw file off disk and then how fast it can write the big preview back out.  This is going to have as much of an effect on the throughput as anything. It can sometimes be the ultimate bottleneck of the process, yet the attention is on the processors, which could be waiting for data both coming from and going to the disk. In other words, some of the performance differences in your CPU measurements may be reflecting disk bottlenecks which are not accounted for, especially when a poor little 2.5&#8243; laptop disk is involved in such a demanding read/write operation against the heavy-duty disk subsystem of a Mac Pro.</p>
<p>Everyone seems so obsessed with multicore, when performance in this type of app always stands on the three legs of CPU, RAM, and disk. You got the first two covered, but the third is missing in action. If this was comparing Final Cut or Photoshop, then the scratch disk setup would be absolutely critical to the performance comparison, so if you ever branch out your tests that way, don&#8217;t leave that out.</p>
<p>Still, you&#8217;re going to be really happy with that Mac Pro! (I sure am.)</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: John</title>
		<link>http://www.rassoc.com/gregr/weblog/2008/02/24/mac-pro-performance/#comment-7541</link>
		<dc:creator>John</dc:creator>
		<pubDate>Mon, 25 Feb 2008 19:49:43 +0000</pubDate>
		<guid isPermaLink="false">http://www.rassoc.com/gregr/weblog/2008/02/24/mac-pro-performance/#comment-7541</guid>
		<description>Sorry got the wrong idea.  I thought the tests on the MacPro and MacBookPro were run on the same version of Lightroom in VM Fusion running on Leopard.

Thanks for the clarification .</description>
		<content:encoded><![CDATA[<p>Sorry got the wrong idea.  I thought the tests on the MacPro and MacBookPro were run on the same version of Lightroom in VM Fusion running on Leopard.</p>
<p>Thanks for the clarification .</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: gregr</title>
		<link>http://www.rassoc.com/gregr/weblog/2008/02/24/mac-pro-performance/#comment-7532</link>
		<dc:creator>gregr</dc:creator>
		<pubDate>Mon, 25 Feb 2008 17:15:45 +0000</pubDate>
		<guid isPermaLink="false">http://www.rassoc.com/gregr/weblog/2008/02/24/mac-pro-performance/#comment-7532</guid>
		<description>@John - not sure what you mean about running the same thing in Leopard?  The Mac Pro and Macbook Pro are both running Leopard (10.5.2)...

@Martin - I don't have Parallels, although I could probably download a trial.

As for boot camp - that's a good idea, and would be a great data point...unfortunately, it kinda sounds like a lot of work (since I'd have to install windows fresh on that partition, whereas I had the VM images laying around).  I'll look around at the office and see if I can find a C2D Windows machine I can borrow for a bit.</description>
		<content:encoded><![CDATA[<p>@John - not sure what you mean about running the same thing in Leopard?  The Mac Pro and Macbook Pro are both running Leopard (10.5.2)&#8230;</p>
<p>@Martin - I don&#8217;t have Parallels, although I could probably download a trial.</p>
<p>As for boot camp - that&#8217;s a good idea, and would be a great data point&#8230;unfortunately, it kinda sounds like a lot of work (since I&#8217;d have to install windows fresh on that partition, whereas I had the VM images laying around).  I&#8217;ll look around at the office and see if I can find a C2D Windows machine I can borrow for a bit.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Martin</title>
		<link>http://www.rassoc.com/gregr/weblog/2008/02/24/mac-pro-performance/#comment-7473</link>
		<dc:creator>Martin</dc:creator>
		<pubDate>Mon, 25 Feb 2008 09:50:27 +0000</pubDate>
		<guid isPermaLink="false">http://www.rassoc.com/gregr/weblog/2008/02/24/mac-pro-performance/#comment-7473</guid>
		<description>You could try bootcamp on the Macbook Pro, that'd measure Windows without virtualization.

Good tests tho. Do you have Parallels to test that as well?

It would be interesting to test both VM Engines.</description>
		<content:encoded><![CDATA[<p>You could try bootcamp on the Macbook Pro, that&#8217;d measure Windows without virtualization.</p>
<p>Good tests tho. Do you have Parallels to test that as well?</p>
<p>It would be interesting to test both VM Engines.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: John</title>
		<link>http://www.rassoc.com/gregr/weblog/2008/02/24/mac-pro-performance/#comment-7457</link>
		<dc:creator>John</dc:creator>
		<pubDate>Mon, 25 Feb 2008 08:16:41 +0000</pubDate>
		<guid isPermaLink="false">http://www.rassoc.com/gregr/weblog/2008/02/24/mac-pro-performance/#comment-7457</guid>
		<description>Why not do a similar test using boot camp rather than a vertial machine.   Also running the same process in Mac OS Leopard would be interesting.</description>
		<content:encoded><![CDATA[<p>Why not do a similar test using boot camp rather than a vertial machine.   Also running the same process in Mac OS Leopard would be interesting.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
