For the following change; would it be possible to increase the number of threads, please?
=========
Thumbnail Threads (Preferences / File Display Modes / Thumbnails) maximum limit increased from 8 to 32. (When Opus launches it also limits the value to the number of CPU threads.)
=========
E.g. use the maximum number a CPU supports (which a user could adjust if necessary) or a much higher number?
I am using an Intel Core i9 7980XE with 36 threads enabled installed on Windows 10 64 bit Version 1803. With upcoming CPUs such as the AMD's Ryzen Threadripper 2950X supporting 64 threads; would a number higher than 32 be more efficient?
With the thread limit, we are not sure if it's sensible or not to raise the number too high.
At some point the disk/filesystem becomes the bottleneck, and increasing the thread count too high may even slow things down.
Where that point is, we don't know, as we don't have any HEDT/Threadripper systems to test with. We're interested in feedback from people who do and who have tried various thread sizes to check how performance scales against them.
Agreed; from the article linked to below by andersonnnunes anything above 32 threads for Windows yields little to no benefit and like you said can actually cause a drop in performance. Apologies the AMD CPU I had intended to mention was the top of the line ThreadRipper, 2990WX and not the 2950X.
I perfectly understand that you wouldn’t have HEDT/Threadripper systems available to test this; they’re not very affordable. If you wish I can try 16 and 32 threads for you with Directory Opus? My concern is however how to do this in repeatable way? Would an automated benchmark be more suitable?
My OS drive is an 800GB Corsair Neutron NX500 PCI Express SSD (3 GB/s read, 2.8 GB/s write) so it will take a lot to saturate it. My secondary mechanical hard drive is accelerated with a 32 GB Intel Optane M.2 module. Please let me know if I can assist you further; I’ll do my best to accommodate you.
Many thanks for the link that you kindly provided. It was a very good read. I’m not too surprised that multi-threaded performance on Windows reaches it’s limit at about 32. I'll send a donation to that website too since I also found it really useful for comparison during the Meltdown/Spectre performance evaluations earlier this year.
I have written OpenMP C++, Intel intrinsics and Intel assembly language in Linux and was always impressed by how much speed up I could obtain. It’s likely the threading code has been optimised over the years and likely gets reviewed frequently by very technically minded people. The code is probably very new too.
On Windows the code is likely to be very old and suffers from too much management/admin overhead as the number of threads increases. Another reason for it not changing over the years is probably compatibility reasons. Although slowly Microsoft is changing some of the old code in it’s OS for the better with Windows Server 2016/2019 and Windows 10 e.g. the removal of SMBv1.
It's probably quite hard to do a fully scientific test, with all the filesystem caching that will happen, but if you disable thumbnail caching in Opus (on the same Prefs page as the thumbnail threads setting) and open the same folder in thumbnails mode with a couple of different thread settings that might be enough to tell you if it's you're gaining anything from the current limit vs, say, half that. If you do still see improvements at the max thread count, we could try increasing the limit.
Sorry for the delay. I agree I don't think it is possible to do a fully scientific test. With 3.72 GB of photos (1130 images) with caching disabled with thread counts of 8, 16 and 32 all of the images render in less than a second. CPU usage doesn't noticeably increase from 0% at anytime. To a human the task is complete almost before it starts!
The images were stored on my 800 GB Corsair Neutron NX500 PCI Express (NVMe) SSD for this test (3 GB/s read, 2.8 GB/s write). Suffice to say performance in all cases is incredibly quick.
Please let me know if I can carry out any other tests for you. Thanks very much