- This topic has 3 replies, 2 voices, and was last updated 7 years ago by
.
-
Posts
-
Hello.
I have measured my display with about 3,500 patches and now my PC does the follow up calculations (Measuring colour swatches for characterisation). The program has done this for 21h and the remaining time is now 15h. Quite a long time.
But what really leaves my wondering is that the process only uses around 12% of my CPU ressources. Why this, or what is here the bottleneck? Or is this behaviour of Displaycal a bug? Because — if I remember that correctly — some time ago those calculations used up nearly all the ressources of my CPU.
Hi,
I have measured my display with about 3,500 patches and now my PC does the follow up calculations (Measuring colour swatches for characterisation). The program has done this for 21h and the remaining time is now 15h. Quite a long time.
That doesn’t seem right. Is progress still happening, or is it just sitting there? What’s your measurement instrument please?
But what really leaves my wondering is that the process only uses around 12% of my CPU ressources.
Most of Argyll CMS is single-threaded, so in case you have multiple cores, only the equivalent of one core will be in use (in reality, context switches will evenly distribute the load across all cores, e.g. resulting in roughly 12.5% utilization overall with 8 cores).
Good that not only I felt that there is something wrong with it. The program ran the whole time, but seemed to progressively slow down and then stuck at 859 samples. And that was the point where I ended the process.Thank you for the explanation how Argyll works. So now that it isn’t multithreaded I will force it to use only one core so that it can benefit from the turbo boost function.
But this is strange — I could swear that my processor was completely used in earlier versions. I noticed the processing since the fans ran on high speed. But maybe just a bug back then.
So now that it isn’t multithreaded I will force it to use only one core so that it can benefit from the turbo boost function.
That probably won’t be enough. Windows will prevent the other core(s) from entering the deep sleep states that are needed for Turbo Boost, because there are always a multitude of background processes that will be distributed across all available cores.
But this is strange — I could swear that my processor was completely used in earlier versions. I noticed the processing since the fans ran on high speed. But maybe just a bug back then.
The current stable version of DisplayCAL will use two threads when doing inverse color lookup, and this can max out a dualcore CPU (atleast for a short while). In the next version, it will be able to use up to 65 cores (if you have them 😉 – but even on “just” a quadcore this will provide a nice boost and reduce a part of the processing time needed to generate a profile).
