Different solutions depending on the number of threads about timeloop

[angshuman-parashar]

In general I wouldn't recommend using num-threads more than available hardware threads, that will only slow the mapper down. It's best to keep it un-set, in which case Timeloop will probe the number of available hardware threads and fork that many mapper threads. However, if you are trying to diagnose/debug the mapper's behavior then of course you can use the parameter.

To answer your specific question - when the mapper creates a certain number of threads, it partitions the mapspace among the threads. Due to the nature of the RNG it's hard to deterministically determine which specific mapping each thread will decide to visit. Therefore, you may see situations where a larger number of threads are behaving unexpectedly because they got unlucky and happened to visit a number of bad mappings. Could you please expand the timeout even further and see if it helps?

[egiacomin]

Got it. I will let the mapper use the available nb of threads automatically then.

As you said, looks like the 16 threads version got lucky and visited the good mapping very early. I increased the timeout by 100x and the 8/2 threads were able to find the same solution. Thanks for the insights.