Interesting example with 8 workers (tagged partial updates for clarify):
8/1bk2r1p/1p2RNp1/1Pp3P1/2Pp1K1P/3P4/r7/3R4 b - - 2 41
info depth 1 score cp -50 time 0 nodes 94 pv a2g2
partial info depth 2 score cp -72 time 0 nodes 597 pv a2h2 f4g3
partial info depth 2 score cp -72 time 0 nodes 650 pv a2h2 f4g3
info depth 2 score cp -72 time 0 nodes 722 pv a2h2 f4g3
partial info depth 3 score cp -69 time 0 nodes 1872 pv c7d8
partial info depth 4 score cp -67 time 0 nodes 2103 pv c7d8
partial info depth 3 score cp -67 time 0 nodes 2199 pv c7d8
partial info depth 3 score cp -42 time 0 nodes 2335 pv c7b8
info depth 4 score cp -72 time 0 nodes 2872 pv c7d8 d1f1 a2h2 e6e8 d8c7
partial info depth 5 score cp 3 time 1 nodes 3906 pv b7c8
partial info depth 5 score cp 3 time 1 nodes 4301 pv b7c8
partial info depth 6 score cp 8 time 1 nodes 5020 pv b7c8
partial info depth 5 score cp 8 time 1 nodes 4345 pv b7c8
info depth 5 score cp 19 time 1 nodes 6026 pv b7c8 e6e8 c8d7 e8h8 a2e2 h8h7 f7h7 f6h7
When workers do partial update, perhaps we should have some depth preference. The last 2 partial updates here could be rejected (depth=3), because a depth=4 one has come first:
info depth 2 score cp -72 time 0 nodes 722 pv a2h2 f4g3
partial info depth 3 score cp -69 time 0 nodes 1872 pv c7d8
partial info depth 4 score cp -67 time 0 nodes 2103 pv c7d8
partial info depth 3 score cp -67 time 0 nodes 2199 pv c7d8
partial info depth 3 score cp -42 time 0 nodes 2335 pv c7b8
In this example, we are lucky that the best move coming from these partial updates is the same as the depth=4 one, but this is not guaranteed, and these depth downgrade partial updates could lose some elo with many threads. Something worth testing (with many threads).
PS: Another interesting thing in this output is that depth=3 seems to have been skipped. With workers running depth<=3 and depth=4, when one of the depth=4 worker wins the race, this is what happens. It does a full UI update and signals all depth <= 3 threads that they are doing useless work and should stop immediately, and look for useful work to do. Which is why info depth 3 was never shown (excluding partial updates), as none of the depth=3 workers was allowed to complete its iteration. This is a feature (worth elo), not a bug.
lucasart
commented
4 years ago
Interesting example with 8 workers (tagged partial updates for clarify):
When workers do partial update, perhaps we should have some depth preference. The last 2 partial updates here could be rejected (depth=3), because a depth=4 one has come first:
In this example, we are lucky that the best move coming from these partial updates is the same as the depth=4 one, but this is not guaranteed, and these depth downgrade partial updates could lose some elo with many threads. Something worth testing (with many threads).
PS: Another interesting thing in this output is that depth=3 seems to have been skipped. With workers running depth<=3 and depth=4, when one of the depth=4 worker wins the race, this is what happens. It does a full UI update and signals all depth <= 3 threads that they are doing useless work and should stop immediately, and look for useful work to do. Which is why info depth 3 was never shown (excluding partial updates), as none of the depth=3 workers was allowed to complete its iteration. This is a feature (worth elo), not a bug.