15Bit Offline Upload & Sell: Off
|
Ok, it seems like this will turn into another LR performance discussion thread anyway. Why do we bother having a search function?
There is some confusion with respect to LR and multicore performance. Actually there is a lot of confusion. This arises because there are many facets to the LR workflow, and they scale quite differently with CPU core count. It is however untrue to say that LR does not take advantage of multiple cores, because it does. And some tasks scale well with core-count. There is also some GPU contribution, but most of the work still seems to be done by the CPU. In more detail:
Import is generally limited by the read-write speed of the memory cards and hard drives. If you render previews at the same time, that will probably be CPU bound but will scale well with core count because each individual image can be rendered by an individual core. In some tests (especially with higher core count CPUs) it might appear that the import+render combined process doesn't scale well with core count, but that is most likely because copying data off the card is too slow to keep the CPU fed with data.
Image exporting scales very well with CPU core count, because each core can be fed an individual image to render.
It is notable that whenever you see LR benchmarks they are generally of the import or export functions, simply because they can be easily and reliably timed.
The problem is that we spend most time in the develop module editing images one by one, and this is where we most perceive slowness. Performance in the develop module is pretty much entirely CPU-bound (with some limited GPU assistance). Unfortunately the rendering of a single image is not as easy to multithread as the rendering of several images parallel. I also have a feeling that the Adobe rendering engine has some legacy issues either relating to old code or an approach to raw rendering that inherently doesn't multithread well. Either way, editing of an individual image doesn't scale all that well with CPU core count (though it does use multiple cores), and so responds much better to clockspeed that core-count. In order to speed up things when developing the only significant variables that folk have found are the image sharpening and noise reduction. These can noticably slow things down, so it is best to leave them until the end. There is some debate about the impact of SSD's, and certainly lower latency read characteristics won't hurt. That said, a typical raw file of 15-50MB is going to take a fraction of a second to read from any disk subsystem, whilst render times are in the order of seconds. So the disk subsystem is not the biggest bottleneck.
|