Is it normal for Stockfish 18 (stockfish-windows-x86-64-avx2.exe) to take much longer to reach higher depths?
For example, analyzing the following position up to depth 32 takes forever, whereas Stockfish 17 could do it in a minute (the nps are similar).
Fulvio wrote: ↑Fri Feb 06, 2026 5:40 pm
Is it normal for Stockfish 18 (stockfish-windows-x86-64-avx2.exe) to take much longer to reach higher depths?
For example, analyzing the following position up to depth 32 takes forever, whereas Stockfish 17 could do it in a minute (the nps are similar).
Fulvio wrote: ↑Fri Feb 06, 2026 5:40 pm
Is it normal for Stockfish 18 (stockfish-windows-x86-64-avx2.exe) to take much longer to reach higher depths?
For example, analyzing the following position up to depth 32 takes forever, whereas Stockfish 17 could do it in a minute (the nps are similar).
Fulvio wrote: ↑Fri Feb 06, 2026 5:40 pm
Is it normal for Stockfish 18 (stockfish-windows-x86-64-avx2.exe) to take much longer to reach higher depths?
For example, analyzing the following position up to depth 32 takes forever, whereas Stockfish 17 could do it in a minute (the nps are similar).
uci
setoption name Hash value 1024
setoption name Threads value 4
setoption name MultiPV value 4
isready
position startpos moves e2e4 c7c5 g1f3 e7e6 d2d4 c5d4 f3d4 b8c6 b1c3 d8c7 g2g3 a7a6 f1g2 d7d6 e1g1 c8d7 a2a4 g8f6 d4c6 d7c6 a4a5 f8e7 c1e3 a8c8 f1e1 f6d7 e3d4 e8g8 c3d5 c6d5 e4d5 e6e5 d4c3 f7f5 a1c1 e7g5 c3d2 g5d2 d1d2 e5e4 g3g4 g7g6 g4f5 g6f5 e1e3 d7e5 c2c4 g8h8 g1h1 c7g7 e3g3 g7f6 g2f1 f5f4
go depth 32
Time to depth is not a great metric anymore in 2026, even for a single-threaded engine. Since really depth is # of iterations of some root aspiration windows. And you might repeat depths. Skip depths, etc.
That being said -- it is common for modern engines to take LONGER to reach a given depth when using > 1 threads; the reason is that the engine will utilize information from other threads to extent various lines of play. IE, threads #1-7 have deposited information into the Transposition Table; Thread #8 will get to a node,find an entry from another thread, and apply extensions based on the promise. This all stems from Singular Extensions, which in general is tied to the TT. More TT hits => More extensions.
AndrewGrant wrote: ↑Sat Feb 07, 2026 5:29 pm
That being said -- it is common for modern engines to take LONGER to reach a given depth when using > 1 threads; the reason is that the engine will utilize information from other threads to extent various lines of play.
Thanks for the insight, intuitively it makes sense.
However, I still feel there's something peculiar going on with that specific position. It's a position where many lines lead to checkmate relatively quickly, so one would expect the search to converge faster. I also tried compiling it directly from source on a MacBook, and the behavior is the same.
What strikes me as odd is that in a more complex and balanced position