Luminous Landscape Forum
Raw & Post Processing, Printing => Digital Image Processing => Topic started by: knweiss on May 13, 2010, 09:08:53 am
-
I think some of you will find this diglloyd RAW processing comparison interesting: http://macperformanceguide.com/Shootout-Ma...processing.html (http://macperformanceguide.com/Shootout-MacPro-RAW-processing.html)
Quote: "None of the RAW-file converters make full use of CPU resources. Put simply, this is the result of poor software engineering, notwithstanding the lame excuses you’re bound to hear from software vendors. ... In the simplest approach, programs could process one RAW file per CPU core, with a worker thread delivering I/O services— but none of them do. They all are brain-dead on the algorithm: process one file at a time, in sequence. It’s an idiotic algorithm for a multi-core world."
Personally, I'm using LR 2.7 on a 8-core Mac Pro with 10 GB RAM and I can confirm that LR makes bad use of the CPU resources. It really should be possible to saturate all available CPU cores during the export of several images...
-
I think some of you will find this diglloyd RAW processing comparison interesting: http://macperformanceguide.com/Shootout-Ma...processing.html (http://macperformanceguide.com/Shootout-MacPro-RAW-processing.html)
Personally, I'm using LR 2.7 on a 8-core Mac Pro with 10 GB RAM and I can confirm that LR makes bad use of the CPU resources. It really should be possible to saturate all available CPU cores during the export of several images...
Thanks for the link. This is not encouraging news for those of us planning to up-grade from two to four or four+ cores. I'm wondering how you know that Lightroom 2.7 makes bad use of CPU resources, and I'd be even more curious to know whether Phase Capture 1 and Photoshop CS5 would have the same issue. It makes one wonder whether up-grading to such high-powered hardware really makes sense until the software catches-up with the hardware.
Also, I wonder whether there are other more decisive efficiency constraints in the hardware - for example front bus capacity.
-
On the same subject, is Bridge/ACR 64 bit yet in CS5?
-
Personally, I'm using LR 2.7 on a 8-core Mac Pro with 10 GB RAM and I can confirm that LR makes bad use of the CPU resources. It really should be possible to saturate all available CPU cores during the export of several images...
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.
-
Hi,
Disk utilization in LR seems to be very low, but CPU utilization can be high in some situations, like building 1:1 previews.
It is not my opinion that discs are the bottleneck in Lightroom.
Best regards
Erik
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.
-
On the same subject, is Bridge/ACR 64 bit yet in CS5?
On my Windows 7 machine, Bridge.exe is in the Program Files (x86) folder, which indicates that it is still a 32 bit application. I don't know that this is a disadvantage, since the main advantage of 64 bit programs is to access a large memory space. This is important those working in Photoshop with large layered files, but I don't think Bridge needs that much memory.
Bill
-
On a similar note: Does CS5 retain the memory leak problems of old?
When stitching or other memory-intensive operations fail in CS4, reloading the program and re-trying the failed op usually rectifies the problem. Is this still present in CS5?
-
On a similar note: Does CS5 retain the memory leak problems of old?
When stitching or other memory-intensive operations fail in CS4, reloading the program and re-trying the failed op usually rectifies the problem. Is this still present in CS5?
Yes, in fact 32-bit CS5 seems to be worse than 32-bit CS4 in this regard. I don't think it's a matter of leaking per-se, but memory fragmentation.
-
Yes, in fact 32-bit CS5 seems to be worse than 32-bit CS4 in this regard. I don't think it's a matter of leaking per-se, but memory fragmentation.
What makes you say this?
-
I think some of you will find this diglloyd RAW processing comparison interesting: http://macperformanceguide.com/Shootout-Ma...processing.html (http://macperformanceguide.com/Shootout-MacPro-RAW-processing.html)
Quote: "None of the RAW-file converters make full use of CPU resources. Put simply, this is the result of poor software engineering, notwithstanding the lame excuses you’re bound to hear from software vendors. ... In the simplest approach, programs could process one RAW file per CPU core, with a worker thread delivering I/O services— but none of them do. They all are brain-dead on the algorithm: process one file at a time, in sequence. It’s an idiotic algorithm for a multi-core world."
Personally, I'm using LR 2.7 on a 8-core Mac Pro with 10 GB RAM and I can confirm that LR makes bad use of the CPU resources. It really should be possible to saturate all available CPU cores during the export of several images...
Unfortunally they didn't test Bibble 5, that one seems to scale very good to a lot of CPU's.
But to be honest I don't care much about batch processing speed. The UI speed is far more important and I have to say that Bibble is fast, very fast for that.
-
Unfortunally they didn't test Bibble 5, that one seems to scale very good to a lot of CPU's.
I agree. From all I've read about Bibble (I don't have first hand experience with it) they really seem to care about multi-threaded performance and scaling up to a decent number of cores (http://bibblelabs.com/products/bibble5/features/speed.html).
But to be honest I don't care much about batch processing speed. The UI speed is far more important and I have to say that Bibble is fast, very fast for that.
Again, I agree. UI speed really is even more important. But IMHO the export (batch processing) should be the easiest part of the RAW converter to scale up to a large number of cores.
Soon there (probably) will be a new Mac Pro model with two Intel Westmere Hexa-core CPUs with Hyperthreading support. I.e. the software will see 24 cores. Given diglloyd's test results: Do you think it would make sense to buy such a machine for photography with today's software? Scaling to a larger number of cores becomes more and more important each year but the software seems to be way behind.
-
What makes you say this?
That's just my personal observation. I'm seeing more of those program errors, clipboard errors, and plug-in failures with 32-bit CS5 than I did with 32-bit CS4. Looking at the working set for a freshly launched copy of CS5 versus CS4, it's apparent than CS5 uses more memory; so it should come as no shock that filters and plugins that run into memory problems on CS4 are going to have more problems on CS5.
-
That's just my personal observation. I'm seeing more of those program errors, clipboard errors, and plug-in failures with 32-bit CS5 than I did with 32-bit CS4. Looking at the working set for a freshly launched copy of CS5 versus CS4, it's apparent than CS5 uses more memory; so it should come as no shock that filters and plugins that run into memory problems on CS4 are going to have more problems on CS5.
Yuch. I already have Noiseware crashing CS4 routinely unless nothing else is running and the image has no more than one layer. But large image files need lots of RAM, so I'm wondering whether the key constraint is the use of 32-bit of OS with its inherent RAM limitation. I have no idea about how to write software, but we have what they give us, and if what they give us hogs memory and doesn't use cores to advantage, seems perhaos we just need lots more memory and not too many cores at this stage.
-
We have at least one Adobe engineer on this forum. Perhaps he will weigh in on this topic. It's difficult for any of us to comment in depth other than noting plug in problems (which may not necessarily be Adobe's fault).
Alan
-
On the Mac, only Photoshop is the 64-bit host under CS5. That is, if you want to take advantage of more memory on the Mac with CS5 in Camera Raw, you will want to open your files directly in Photoshop (i.e., have Photoshop be the host for Camera Raw), not Bridge.
-
Yuch. I already have Noiseware crashing CS4 routinely unless nothing else is running and the image has no more than one layer. But large image files need lots of RAM, so I'm wondering whether the key constraint is the use of 32-bit of OS with its inherent RAM limitation. I have no idea about how to write software, but we have what they give us, and if what they give us hogs memory and doesn't use cores to advantage, seems perhaos we just need lots more memory and not too many cores at this stage.
I've seen some issues with built-in PS functionality, but plug-ins seem to be the larger problem. Nik Plugins have been particularly bad for me. I _always_ save my file before running Silver EFEX Pro, because sometimes the plug-in doesn't just fail, it brings down Photoshop with it. Now I'm not saying that's Adobe's fault. Nik's software engineers obviously don't know how to handle low-memory situations gracefully. I was just relating the fact that these low-memory/fragmentation problems seem more likely to occur in CS5 than in CS4, due to CS5 having a larger memory footprint of its own. BTW, the problem is far worse for Mac users, because the transition from the old API's to Cocoa means that 32-bit CS5 can only use 2GB of RAM on the Mac, instead of 3GB.
It will be great when we can all run 64-bit with all of our plug-ins. But the reality is that most people have at least some plug-ins that are still 32-bit, and that situation may continue for a while yet.
-
Getting back to the original point about multi-threaded raw conversion and batch processing, maybe you can comment Eric. I _thought_ I had read in the past that if you open multiple RAW's in ACR from bridge, and then save the files from there (as opposed to using Image Processor or Photoshop Batching, which works serially), that ACR actually multiple threads for saving files? Whether it's down to using multiple cores or something else, I do know that saving a bunch of RAW's to Tiff or PSD is faster when using the 'Save' functionality in ACR as opposed to using Image Processor.
-
We have at least one Adobe engineer on this forum. Perhaps he will weigh in on this topic. It's difficult for any of us to comment in depth other than noting plug in problems (which may not necessarily be Adobe's fault).
Alan
Hi Alan - yes I agree - not blaming anyone for anything. It just seems to be applications in aggregate demanding more processing capacity than some of our systems can handle, for whatever reason. I tend to think way more RAM is the principle ingredient to a solution and that means upgrading to a 64 bit OS which means re-installing one's whole computer and hoping for the best.
-
On the Mac, only Photoshop is the 64-bit host under CS5. That is, if you want to take advantage of more memory on the Mac with CS5 in Camera Raw, you will want to open your files directly in Photoshop (i.e., have Photoshop be the host for Camera Raw), not Bridge.
Hi Eric,
What about LR3 in a 64 bit environment? Should that run super smooth and fast?
-
Getting back to the original point about multi-threaded raw conversion and batch processing, maybe you can comment Eric. I _thought_ I had read in the past that if you open multiple RAW's in ACR from bridge, and then save the files from there (as opposed to using Image Processor or Photoshop Batching, which works serially), that ACR actually multiple threads for saving files? Whether it's down to using multiple cores or something else, I do know that saving a bunch of RAW's to Tiff or PSD is faster when using the 'Save' functionality in ACR as opposed to using Image Processor.
Yes, you're right, Jeff. ACR has its own batch save mechanism which can do a better job of taking advantage of multiple cores. This has been recently improved in CR 6 (relative to CR 5). This is a very reasonable way to go, if you want to take a large group of raw files and save rendered results as TIFFs.
-
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...
-
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.
-
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
-
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!
-
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.
-
Yes, Mark, running LR in 64-bit more with gobs of RAM (4 GB or more) is more than fine.
-
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.
-
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?
-
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 (http://edge.bibblelabs.com/503-20100318/Bibble%205.0.3a%20Pro.dmg) 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.
(http://grab.by/grabs/45802b4e3cf8db752d34f7ba3dfd5d94.png)
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.
-
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.
-
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.
-
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)
-
- 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.
-
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.
-
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?
-
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.
-
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.
-
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?