A position that needs a physician

[syzygy]

reversed colors and SF failed to see 3.Kg4 wins and game was drawn.

I haven't tested that position yet, but if SF missed Kg4 that seems to be yet another instance of the same problem.

[bob]

reversed colors and SF failed to see 3.Kg4 wins and game was drawn.

I haven't tested that position yet, but if SF missed Kg4 that seems to be yet another instance of the same problem.

I am actually suspecting that this might just be an artifact of lazy SMP. Having multiple threads searching at different depths tends to introduce some crazy hash table anomalies at times. NOT collisions. Just depths that confuse the search when things get grafted from one sub-tree to another. There are plenty of these with traditional SMP via hash grafting. This appears to magnify the problem.

[lech]

Stockfish's MAXPLY = 120 if I remeber well, and it can return 0 in a deep search.

[Joerg Oster]

Stockfish's MAXPLY = 120 if I remeber well, and it can return 0 in a deep search.

That doesn't seem to be a problem, although I first thought that, too.
Even when I raised MAX_PLY to 192, I got the same odd behaviour.

Not storing draw scores in the TT, seems to have a positive effect.
At least, the fail-low cycle ending with a draw score was always interrupted at some point.

[bob]

Stockfish's MAXPLY = 120 if I remeber well, and it can return 0 in a deep search.

That doesn't seem to be a problem, although I first thought that, too.
Even when I raised MAX_PLY to 192, I got the same odd behaviour.

Not storing draw scores in the TT, seems to have a positive effect.
At least, the fail-low cycle ending with a draw score was always interrupted at some point.

The best solution is coordinated depth. A simple question, given

(a) a 30 ply search that returns a score of -1.2 for move X and

(b) a 33 ply search that returns a score of -2.4 for move Y;

Which move do you play and why? (note there is NO good answer to this question).

Given that, what about grafting branches between those two searches. How reliable will that be?

Not storing draw scores is just yet another way to weaken the program. Throw information away rather than trying to figure out why doing so solves the problem in a costly way.

[syzygy]

reversed colors and SF failed to see 3.Kg4 wins and game was drawn.

I haven't tested that position yet, but if SF missed Kg4 that seems to be yet another instance of the same problem.

I am actually suspecting that this might just be an artifact of lazy SMP. Having multiple threads searching at different depths tends to introduce some crazy hash table anomalies at times. NOT collisions. Just depths that confuse the search when things get grafted from one sub-tree to another. There are plenty of these with traditional SMP via hash grafting. This appears to magnify the problem.

Yes, it is not caused by hash collisions (storing 32-bit keys in tt entries does not solve it, I have tried that). Most likely this is simply the graph-history interaction problem, which indeed is probably getting magnified by different threads searching at different depths.

So it might be a good idea to prevent lazy smp from simultaneously launching different threads at different depths in the endgame.

However, I did manage to reproduce the problem with the YBW version of Stockfish. It seems to occur less often with YBW, but it is still there. It might have to do with certain combinations of reductions/extensions causing some positions in tree nodes further from the root to be searched at higher depth than identical positions in tree nodes closer to the root. Or maybe the positions in game 22 are simply especially prone to GHI problems (in which case other engines should show similar problems on them when pressed hard enough).

[lech]

Stockfish's MAXPLY = 120 if I remeber well, and it can return 0 in a deep search.

That doesn't seem to be a problem, although I first thought that, too.
Even when I raised MAX_PLY to 192, I got the same odd behaviour.

Not storing draw scores in the TT, seems to have a positive effect.
At least, the fail-low cycle ending with a draw score was always interrupted at some point.

Stockfish uses refined values in qsearch (PV) for non-EXACT TT values too. It can lead to odd behaviours. Why Stockfish team did it?

[Krgp]

The best solution is coordinated depth. A simple question, given

(a) a 30 ply search that returns a score of -1.2 for move X and

(b) a 33 ply search that returns a score of -2.4 for move Y;

Which move do you play and why? (note there is NO good answer to this question).

Given that, what about grafting branches between those two searches. How reliable will that be?

Not storing draw scores is just yet another way to weaken the program. Throw information away rather than trying to figure out why doing so solves the problem in a costly way.

Forgive me if my query sounds stupid and silly ...

However, is it possible to make these threads have uniform (pre-determined max depth) length ? Working it out could be a bit tricky, but my idea is ALL threads search up to a certain depth. If a thread achieves that depth earlier, it stops exploring that node and takes up some other node if possible. When ALL threads reach to this determined depth; next iteration (again limited to a further certain depth) can start (might be already in process on the threads that have reached our decided depth earlier) on ALL threads and the cycle continues. So when a 'stop' occurs we will have evaluation of uniform depth. Some or all threads might be working ... but we can pick up the best from the last determined depth ...

Is it possible ? Can it produce better results ?

[syzygy]

However, is it possible to make these threads have uniform (pre-determined max depth) length ? Working it out could be a bit tricky, but my idea is ALL threads search up to a certain depth. If a thread achieves that depth earlier, it stops exploring that node and takes up some other node if possible.

It is much simpler. At iteration N, all threads start searching the root node with depth N. Once a thread finishes, the other threads are stopped and the engine starts iteration N+1.