Still my #1 choice for my photography: wide gamut, true calibration, friendly pixel density.
Analysis of Photoshop CS5 CPU Core Usage
The diglloydMedium Benchmark was run on the 8-core 2.93GHz Mac Pro, and CS5 was given 16GB memory— more than enough, and during the test no disk activity was observed, so Photoshop CS5 was “free to run”. There was also ample system memory free at the end of the run, about 5.6GB.
Here is approximate CPU usage for each operation as the diglloydMedium benchmark was run:
Image size: ~800% Convert to profile: ~156% Rotate: ~200% Convert to Lab: ~135% Invert: ~112%
These are horrible figures, but read on for an explanation.
Setting aside virtual cores (hyperthreading) which is slightly better than useless, maximum CPU usage is 800% on the 8-core Mac Pro Nehalem. For this test , Photoshop CS5 averages roughly 170% CPU usage (taking duration into account), out of 800%. In other words, about 70-80% of the processing power is simply not used— wasted.
Why the first 64-bit test run is so horribly slow
As discussed above, CPU core utilization was seen to be atrocious. Why?
Memory allocation of very large quantities of memory is slow. MemoryTester’s 'stress' command can allocate and clear 16GB of memory in about 9 seconds (Mac Pro 8-core, 24GB). So that is the “lower bound” on what can be expected for time.
Photoshop apparently has an overhead of about 60 seconds for the same memory allocation (see Warm-up). That’s a serious performance problem that Adobe needs to address.
The explanation involves memory allocation. On the first run, Photoshop steadily allocates the memory it needs for running the diglloydMedium Benchmark (about 15GB of real memory). On the second run, CS5 already internally has that memory allocated and ready to go; it doesn’t need to ask Mac OS X for it.
In the CPU History graphs from Activity Monitor below, observe that most of the CPU usage is red. This indicates “system time” eg operating system calls eg memory allocation. On the second run, CPU usage is green, this indicates “application time”.
For more on how this affects performance, see the Warm-up page.