The GetDPI Photography Forum

Great to see you here. Join our insightful photographic forum today and start tapping into a huge wealth of photographic knowledge. Completing our simple registration process will allow you to gain access to exclusive content, add your own topics and posts, share your work and connect with other members through your own private inbox! And don’t forget to say hi!

DPR: 907X and CFV II 50C sample gallery and impressions

docholliday

Well-known member
LrC scales fine with 8 cores/16 threads (e.g., building previews). Out of curiosity: for which LrC operations do you need to use many cores?
With active 8 cores (or less), you should not see any delay with sliders. If you are in any way using Adobe DNG Converter, make sure it is updated as it is not part of the Creative Cloud.
Not scaling well has a meaning if there is the necessity for scaling. And this is not the case.
The current LrC version does not need to scale up to more than 8 cores, development and sliders are already real-time with 4 cores.
Then your performance problem lies elsewhere and scaling up will probably not solve your problem.
Again, I'm not here to try and fix this, as Adobe has admitted it's a problem but has no priority to fix it. It does use all 32C/64T or 64C/128T when generating previews and exporting. It's just the develop module that doesn't.

Scaling is obviously needed, as the 8 cores isn't maxing out the code performance and still resulting in a laggy/delayed interface. Yes, there is a point where more cores won't help. It's the point where the code is running so fast that additional threads would actually slow it down from having to spin up threads and switch results back in. If it scaled correctly, like it does for other processes, it would speed up to the point where it's running "real time" and the code can't process any faster at the current clock frequency.

Also, ACR scales appropriately and produces lagless changes. Grab a slider in ACR , scrub the crap out of it back and forth, and it shows each step smoothly with all cores rising and settling on the final setting without delay. Do the same, with the same file and settings in LR, and it'll start lagging and dropping update frames with 8 cores at most maxing out and delaying the final draw after releasing. C1 performs just like ACR, as does PS.
 

SrMphoto

Well-known member
Again, I'm not here to try and fix this, as Adobe has admitted it's a problem but has no priority to fix it. It does use all 32C/64T or 64C/128T when generating previews and exporting. It's just the develop module that doesn't.

Scaling is obviously needed, as the 8 cores isn't maxing out the code performance and still resulting in a laggy/delayed interface. Yes, there is a point where more cores won't help. It's the point where the code is running so fast that additional threads would actually slow it down from having to spin up threads and switch results back in. If it scaled correctly, like it does for other processes, it would speed up to the point where it's running "real time" and the code can't process any faster at the current clock frequency.

Also, ACR scales appropriately and produces lagless changes. Grab a slider in ACR , scrub the crap out of it back and forth, and it shows each step smoothly with all cores rising and settling on the final setting without delay. Do the same, with the same file and settings in LR, and it'll start lagging and dropping update frames with 8 cores at most maxing out and delaying the final draw after releasing. C1 performs just like ACR, as does PS.
Thanks for the explanations. I think everyone here is baffled why you don't see lag-less changes if you have at least 4 active cores. But we should leave you alone, as you are not interested in fixing it on your side (if that is possible at all).
 
Top