The sad state of multi-threaded RAW processing

[Schewe]

Also note that when you run CS5 on a Mac as a 32-bit app, CS5 can access less ram than CS4 could–which was also 32-bit. But CS4 was running using Carbon API's which allowed Photoshop CS4 to go pretty much right up to the full 4 gigs of addressable ram for a 32-bit app.

CS5 however is using Cocoa API's and as far as I know can only use a bit over 2 gigs or so of ram after a chunk is reserved for the actual application. So, running CS5 as a 32-bit app in ram heavy uses will be less good than CS4 was...

[madmanchan]

What about LR3 in a 64 bit environment? Should that run super smooth and fast?

Hi Mark, both LR 2 and LR 3 support 64-bit on both Mac and Windows. No caveats there.

Unfortunately, I can't really quantify LR 3 performance in a meaningful way at present. This may sound strange but I haven't really used Lightroom 3 much yet (even though I want to!). Most of my development and engineering time has been spent on the Camera Raw side.

[BernardLanguillier]

Also note that when you run CS5 on a Mac as a 32-bit app, CS5 can access less ram than CS4 could–which was also 32-bit. But CS4 was running using Carbon API's which allowed Photoshop CS4 to go pretty much right up to the full 4 gigs of addressable ram for a 32-bit app.

CS5 however is using Cocoa API's and as far as I know can only use a bit over 2 gigs or so of ram after a chunk is reserved for the actual application. So, running CS5 as a 32-bit app in ram heavy uses will be less good than CS4 was...

This makes the porting of plug-ins to 64 bits all the more important.

Cheers,
Bernard

[Mark D Segal]

Hi Mark, both LR 2 and LR 3 support 64-bit on both Mac and Windows. No caveats there.

Unfortunately, I can't really quantify LR 3 performance in a meaningful way at present. This may sound strange but I haven't really used Lightroom 3 much yet (even though I want to!). Most of my development and engineering time has been spent on the Camera Raw side.

Thanks Eric. I suppose it's safe to assume that running it in 64-bit with upwards of 4GB of RAM should be fine. (And thinking of the other big piece of raw processing software I have, likely the same story in spades with Capture-1 for the Phase files.) Increasingly gotta face the fact that my computer was just fine about 3 and 1/2 years ago!

[Sheldon N]

If that export writes files to you harddisk it's no wonder, the disk is the weakest link, it's slow compared to cpu/memory. while doing the export and file writing the CPU has to wait for the harddisk. 8 cores working on 8 files to convert and write the file to disc just would all be sitting and waiting and competing for a piece of the disc resource. Or files would be buffered in memory and 1 core would (slowly) flush them to disc.

Get 8 seperate disc and store the results expoerted file on different discs......that might improve performance.

The reference in Digloyds rant is as far as I read it more targeted at operations like sharpening, uprezzing which are compute intensive and, I agree with the article, could make much better use of available cores. Saving a RAW file as TIFF, JPEG or whatever is not compute intensive, it's what they call disc bound for speed.

Actually, Lightroom is not really disk bound at all for export or import. The only time that you would start to see a bandwidth limitation due to disk speed is when exporting very large files (1Ds III/5D II or larger) as uncompressed TIF files. They are large enough that a they can present a bottleneck if you aren't using a fast drive. The reason being is that less CPU calculations are required for determining the compression (vs JPG or Compressed TIF)  so they render faster, and of course the file sizes are larger. A multi drive RAID 0 setup will speed up your processing for uncompressed TIF's, but not for exporting regular JPG's. Lloyd Chamber's sections on Disk Speed and Drive Speed summarize the issue well.

On the issue of RAM, I haven't found Lightroom to be very memory hungry. I am running 64 bit LR on a PC with 8GB of RAM, and it rarely will even use 1/2 of the available memory.

[madmanchan]

Yes, Mark, running LR in 64-bit more with gobs of RAM (4 GB or more) is more than fine.

[Mark D Segal]

Yes, Mark, running LR in 64-bit more with gobs of RAM (4 GB or more) is more than fine.

Thanks Eric, I like "more than fine".

Right now on Windows XP 32-bit architecture one really only accesses less than 3 GB. So one more indicator of the need for all those in my position wanting to process these large files efficiently to upgrade the hardware.

[Jack Flesher]

While Lloyd's comment is correct for most of the software, if I look at his graphs, it certainly appears that C1 made better use of the additional but slower cores than it did on fewer, faster cores... Or am I missing something obvious?

[knweiss]

Today I had some spare time and decided to benchmark Bibble 5 vs Lightroom 3 Beta 2 by myself because I was curious how good Bibble 5's multi-threading really is. So I downloaded the free Bibble 5 trial for Mac OS X. My test consists of a batch export of 100 Canon 5D Mark II RAW files to JPEG (80% quality, sRGB, no resizing, no sharpening). Both source and destination images were stored on the same Intel Postville 160 GB SSD. My system is an early 2008 Mac Pro with 8x 2.8 GHz Intel Xeon Cores and 10 GB of 800 MHz DDR2 RAM running Snow Leopard 10.6.3 (64-bit kernel). Here are my test results:

• Lightroom 3 Beta 2: 307s (~3s/image)
• Bibble 5: 58s (0.58s/image)

[/b]
Conclusion:

• LR3 is more than 5 times slower than Bibble 5.
• Slow storage is not the cause of the bad multi-threading performance.

I've captured some CPU usage graphs with Mac OS X's "Activity Monitor" during the batch export to give you an idea how good Bibble 5 sustains the available cores and how much CPU is wasted with the Lightroom beta.

As a Lightroom user I really would appreciate if LR would be able match Bibble's performance in the final LR3 release. The performance gap to Bibble5 is simply too large right now because LR unfortunately is not able utilize the available hardware.

[digitaldog]

As a Lightroom user I really would appreciate if LR would be able match Bibble's performance in the final LR3 release. The performance gap to Bibble5 is simply too large right now because LR unfortunately is not able utilize the available hardware.

Can you try with LR2? Beta’s are usually slow and not optimized till nearly the end of development so its not totally a fair test. And it would be interesting to see how much slower LR3 is to LR2 even at this beta stage as a reality check and how LR2 compares with Bibble.

[Sheldon N]

Can you try with LR2? Beta’s are usually slow and not optimized till nearly the end of development so its not totally a fair test. And it would be interesting to see how much slower LR3 is to LR2 even at this beta stage as a reality check and how LR2 compares with Bibble.

From Lloyd's tests LR2 and LR3 beta are very close in performance, with a slight edge going to LR3beta for overall speed. Hopefully you are right and the final version of LR3 is even faster.  Of course, the performance we are seeing from LR3 pales in comparison to what is possible - as shown by Bibble.

[knweiss]

Can you try with LR2? Beta’s are usually slow and not optimized till nearly the end of development so its not totally a fair test. And it would be interesting to see how much slower LR3 is to LR2 even at this beta stage as a reality check and how LR2 compares with Bibble.

• Lightroom 2.7 (64-bit): 284s (2.84s/image)
• Lightroom 3 Beta 2 (64-bit): 307s (3.07s/image)
• Bibble 5: 58s (0.58s/image)

[digitaldog]

• Lightroom 2.7 (64-bit): 284s (2.84s/image)
• Lightroom 3 Beta 2 (64-bit): 307s (3.07s/image)
• Bibble 5: 58s (0.58s/image)

Big difference in terms of Bibble processing, no question. The differences between LR 2&3 is of course also interesting and one would hope 3.0 would at least match or better surpass 2.0 when released. We do have a lot more going on under the hood with 3.0, much better rendering. If it doesn’t get much faster, I guess that’s a worthwhile trade off.

[Mark D Segal]

Big difference in terms of Bibble processing, no question. The differences between LR 2&3 is of course also interesting and one would hope 3.0 would at least match or better surpass 2.0 when released. We do have a lot more going on under the hood with 3.0, much better rendering. If it doesn’t get much faster, I guess that’s a worthwhile trade off.

True, but it would really be interesting to understand why LR is so much slower in respect of the actions tested compared with Bibble, and whether the same holds true for image editing operations, where even on my now relatatively dated WINXP 32-bit system LR is very responsive with Canon 1Ds3 files (25 or so MB each). Seems as if image editing functions don't challenge our computer systems in the same way that batch exporting and such actions would.

[knweiss]

Big difference in terms of Bibble processing, no question. The differences between LR 2&3 is of course also interesting and one would hope 3.0 would at least match or better surpass 2.0 when released. We do have a lot more going on under the hood with 3.0, much better rendering. If it doesn’t get much faster, I guess that’s a worthwhile trade off.

I know that one could argue that this is an apples to oranges comparison because there are lots of differences in the algorithms both programs use - that's for sure. I.e. the absolute running time is not of particular importance here. The real problem is that LR is unable to saturate all the CPU cores! No matter how complex or inefficient the export code is, it should be able to keep all the CPUs busy. Take a look at Bibble's CPU usage graph from my last posting. If it doesn't look like this during a CPU-limited job there's something wrong with (the multi-threading of) the code.

Isn't it distressing that people spend thousands of dollars on new computer hardware just to gain a little performance and at the same time the software doesn't utilize the available hardware resources?

[daws]

Isn't it distressing that people spent thousands of dollars on new computer hardware just to gain a little performance and at the same time the software doesn't utilize the available hardware resources?

I understand what you're saying. But having just purchased a loaded 64-bit machine 'pon which CS5 screams, I'm not distressed. In the over-quarter-century since my first 8086, I'm used to sometimes code leading gear, sometimes gear leading code. Nothing advances on a linear front; in this case the code will catch up.

Too, there are three professionals over whom it's best to never crack the whip for speed: one's doctor, one's accountant, and the guy developing one's apps.

[alain]

True, but it would really be interesting to understand why LR is so much slower in respect of the actions tested compared with Bibble, and whether the same holds true for image editing operations, where even on my now relatatively dated WINXP 32-bit system LR is very responsive with Canon 1Ds3 files (25 or so MB each). Seems as if image editing functions don't challenge our computer systems in the same way that batch exporting and such actions would.

Bibble on PC is really fast for image operations, especially culling can be done fast.  Unfortunally I can't test on a 8 core.

[knweiss]

I.e. the absolute running time is not of particular importance here. The real problem is that LR is unable to saturate all the CPU cores! No matter how complex or inefficient the export code is, it should be able to keep all the CPUs busy. Take a look at Bibble's CPU usage graph from my last posting. If it doesn't look like this during a CPU-limited job there's something wrong with (the multi-threading of) the code.

Did anyone already try LR3 final? Is it able to keep all cores busy during batch export?