Crafty and Stockfish question

[bob]

At present, we base our move selection mainly on how often the book move was played when the book was built from a GM pgn game collection. Then we use book learning to fine-tune that for the moves that appear to be bad after we actually play them in a game and then do real searches and discover that the move led us to a bad position or result.

This is where I think having a parser or function that just writes all PV lines in a given eval window size +/-.... to a file in PGN format as it searches() from root... I would prefer Crafty's own evaluation over a GM pgn method, because it can cover millions of moves to analyze, quicker.

The problem is the time factor. How deep will you let each search go? With a PGN collection of 10M games, averaging (say) 60 plies deep for the book lines, that is 60M positions. at 1 sec per position 60M seconds or almost 700 _days_ of computing power. 1 second per position is not very good analysis to try to understand the positions with material imabalance... positions with serious king-side attacks.... etc...

[jhaglund]

That is where using multiple threads & a concurrent search comes into play... when you leave your book you search the end of each leaf as you arrive... like in the next post i made.

The same tactics used in multiple thread searches can also be used in a parser. Instead of applying all 8 threads to one move apply each thread per move ...

1 move with 8 threads per 1sec... 1/1
8 moves with 1 thread per 1sec ... 8/1
batch them over the cluster...
60M / threads*#pc's ... reduced to a couple day

Besides the fact i wouldn't take all the moves from human play. Having Crafty generate the pv lines in a window seems less time wasted. Doing this do each eco variation for make 2000+eco books @2gb each was what i had in mind... then crafty would open up that particular book...