Unusual seldepth jumps

[mister-geordi-laforge]

It is very unlikely that I found a real bug, but this phenomenon seems to be interesting for me, especially because I have never seen this kind of artifact either in the old times of Glaurung, or in the recent 5-10 years with Stockfish. Originally I thought I found a scidvspc bug when I analyzed https://www.chessgames.com/perl/chessgame?gid=1552251 backwards, when at White's move 24 the seldepth suddenly began to jump crazily between 5 and 40, sometimes settling at 2, and not moving anymore. The last commit was ee3f7b6b6e1a1051b32cedb38ac89b3458ff4ab2 (Bad Outpost Pawn Scale by FauziAkram) by then, that was compiled with profile-build ARCH=x86-64-bmi2 COMP=gcc COMPCXX=g++. I have tested it about 8-10 times, and it showed this behaviour in more than half of the attempts.

Then, I pulled the newest commit 6dddcecb09df268d93810a1a38deb116f97672af (Optimize generate_moves by Tomasz Sobczyk), compiled, and tried via the command-line. I don't think that this is important, but the thread count was 4, syzygy was 5-men, and uci_analysemode was switched on. The fen is 2b1rrk1/p1pnqppp/1p1p2n1/3Pp3/2P1P3/6PP/P1P2PBN/1RBQR1K1 w - - 9 24. Interestingly, the seldepth continued to do wild jumps, but never went under 10, and never stalled. Sometimes it jumped crazily, sometimes not - I have never seen this, despite using a locally compiled Stockfish at least 2-3 times a week.

To be much more difficult to understand what's going on, out of 9 tries, once Stockfish went for the very strange best move of 24.Kh1 after 2-3 minutes, then on the next depth it returned to 24.h4, and never returned to that king move later, either in the same analysis or in the subsequent tests with a clean hash. Unfortunately, I did not save the PV for this really unexpected and bizarre 24.Kh1. Apart from this, the rather normal 24.h4 and 24.Rb3 are in the outputs everytime.

I don't know if I found anything that needs to be investigated deeper, but I am happy to run more tests if required. If a bisect is required, I'll do it in a several days.

A sidenote: I have never contributed anything here, did not even register, but I am following your efforts for a several years now. And you are AMAZING.

[MichaelB7]

I assume you are using multiple threads? My conjecture is that it may be an artifact from the small amount of randomization we do when positions are evaluated at 0.00. Try commenting lines out lines 87-90 and 795-797 (search.cpp) and see if your observation still holds. I only say this because the position you posted oscillates around 0.00. I have not done any testing.

[mister-geordi-laforge]

I assume you are using multiple threads? My conjecture is that it may be an artifact from the small amount of randomization we do when positions are evaluated at 0.00. Try commenting lines out lines 87-90 and 795-797 (search.cpp) and see if your observation still holds. I only say this because the position you posted oscillates around 0.00. I have not done any testing.

Thank you for the idea, I am going to test it in the next couple of days.

[snicolet]

As @MichaelB7 pointed, if the position leads to several draws, SF can start having the critical lines in the transposition table after some time of analysis, and the reported depths might become non-increasing because the transposition table cuts some branches of the search.

[mister-geordi-laforge]

Thank you for the explanation. I still did not have time to properly re-test it, so I am closing this issue as it is most probably not a thing that should be investigated deeper, anyway.