Say I have an 8 cores/16 threads system, and 1 x 1T SSD. I would like the first plot to have -r 16 to squeeze all the juice from the CPU. Once this plot passes phase 1, then start a second concurrent plot with -r 15 (since the first plot now needs about 1 thread so it doesn't get interruppted), then start a 3rd plot with -r 14 etc...
I believe this will kick off the plotting much faster and always keep the CPU busy and not rest for a moment. Now the above number may be too aggressive and we may say want to reserve, say 2 threads, for the system and all other programs, we can just have a configurable parameter threads offset of -2.
So every time when a new plot kick off, the -r parameter will be [Total system threads] - 1 x [Number of current plots in progress (reserve one thread for each plot)] + [the offset parameter].
With that formula, it is obvious that the number of threads calculated will be 0 as long as there is already one plot running at phase 1. This doesn't make a lot of sense if you want to allow more than one plots at phase 1. To make it compatible with multiple plots at phase 1 and many other scenarios, we can provide another configurable parameter threads range of, say [2,6]. Then. in this case, as long as the global current plots in progress does not exceed the maximum global plots allowed (as explained in #453 ), the manager should start a new plot with the lower bound 2 threads. Correspondingly if the formula in the previous paragraph gives a number larger than 6, we should only start a new plot with 6 threads.
I hope I explain it well and it is not too complicated. Although not tested, I do believe this will improve CPU utilization rate substantially. Let me know if you have any questions. Thanks!
The idea is like this:
Say I have an 8 cores/16 threads system, and 1 x 1T SSD. I would like the first plot to have -r 16 to squeeze all the juice from the CPU. Once this plot passes phase 1, then start a second concurrent plot with -r 15 (since the first plot now needs about 1 thread so it doesn't get interruppted), then start a 3rd plot with -r 14 etc...
I believe this will kick off the plotting much faster and always keep the CPU busy and not rest for a moment. Now the above number may be too aggressive and we may say want to reserve, say 2 threads, for the system and all other programs, we can just have a configurable parameter
threads offset
of -2.So every time when a new plot kick off, the -r parameter will be [Total system threads] - 1 x [Number of current plots in progress (reserve one thread for each plot)] + [the offset parameter].
With that formula, it is obvious that the number of threads calculated will be 0 as long as there is already one plot running at phase 1. This doesn't make a lot of sense if you want to allow more than one plots at phase 1. To make it compatible with multiple plots at phase 1 and many other scenarios, we can provide another configurable parameter
threads range
of, say [2,6]. Then. in this case, as long as the global current plots in progress does not exceed the maximum global plots allowed (as explained in #453 ), the manager should start a new plot with the lower bound 2 threads. Correspondingly if the formula in the previous paragraph gives a number larger than 6, we should only start a new plot with 6 threads.I hope I explain it well and it is not too complicated. Although not tested, I do believe this will improve CPU utilization rate substantially. Let me know if you have any questions. Thanks!