Closed HadrienG2 closed 3 years ago
I agree with you : this naive parallelism is not satisfactory.
With the actual ddmax, when you reach a success you can exit of the loop of independent : "For each schedule". So it is not obvious that to switch configuration loop and the run loop will help to get the first success configuration.
As we want to leave ddmax and use an other algorithm rddmin which perform iteratively ddmin search, we wont' spent to much time on ddmax parallelism.
You are right that in this case, it may be better to investigate how to make rddmin fast instead :)
V3.2.1 implements parallelism in dichotomy part of rddmin algorithm. Let me known if it is not sufficient.
Currently, verrou_dd processes configurations in order, and only allows itself to perform multiple runs of a configuration in parallel. This has two problems:
Here is an alternate algorithm proposal:
Parameters:
Main thread:
I think this algorithm is pretty good, because since the executor is FIFO and we schedule the first run of each configuration, then the second run of each configuration, and so on, multiple runs will only actually execute in parallel when the CPU has nothing better to do. Therefore, we reach a good compromise between keeping the CPU busy and avoiding potentially wasted work.
One thing which is lost with respect to the current algorithm is that no message will be printed when a configuration starts to be tested, only when verrou_dd is done testing a configuration. Also, configurations will be printed out of order, but I don't think this is a big deal (they were hardly identifiable anyhow).