Closed vondele closed 8 years ago
I can't say why constant nodes is not reproducible but in my experience constant depth IS reproducible. Just play 1000 games in, e.g. cutechess-cli between the same SF build and you will see that all games are exactly the same, even if they contain 150+ moves. This pertains to a lower extent to games between different builds (some differing moves at the end, especially in longer games) as well as between Stockfish and BrainFish, or Stockfish-CFish, or Stockfish- pedantFish. From your listing it is seen that at given depth (e.g., depth 9), all runs have the same pv (some only the first move)
@lantonov I've played my share of Stockfish games but I don't think I've ever seen two identical versions of Stockfish play the exact same game. I guess it could have something to do with the time control?
@lantonov yes, I can confirm that constant depth is reproducible.
@stockfishdeveloper if the search is based on time, it will not give identical games, however, on depth or on nodes, it should.
Yes, this is what makes two identical builds have the same bench.
@stockfishdeveloper actually the issue is still slightly different. Things are reproducible also with nodes if the games are played in the same order, it is when the order changes, or as in the example above, played twice, that it is not giving the same answer.
Well, obviously some table is not being cleared when we get the "ucinewgame" command. As far as I know the UCI protocol calls for literally a complete clean of everything to start a new game(or position) fresh.
git bissect
@lucasart I tried SF8 SF7 SF6 and those commits suggested by blame on search::clear, but couldn't find any good commit.
Fixed by #862
I was expecting the (single threaded) search to be reproducible after a 'ucinewgame'. It is also what the comment in the code suggests:
/// Search::clear() resets search state to zero, to obtain reproducible results
However, I noticed that this is not the case, and sometimes analysing games different bestmoves are suggested depending on the history of games played.
To reproduce, the following expect script can be used (or typed at the cli)
which results in
where the first analysis of the start pos leads to 'nodes 14985' being searched and the second to 'nodes 14982'. In this case, it is a small difference, different bestmoves is not so nice.
I'm wondering if anybody can figure out which piece of state is not reset between the two games, and what should be added to the uicnewgame reset.