Search statistics

[Robert Pope]

I'm getting ready to take another look at my engine's search -- I've found a couple of positions where it performs really badly.

In the broader scheme, though, what are good statistics to collect to measure its efficiency. Right now, I just have nodes, time, and depth for the PV output. I'm adding qnodes, hash probes, and hash hits for a post-search summary. Is there anything else I should capture?

[Henk]

The percentage the first move tried is the best move or count the number of researches.

[bob]

The percentage the first move tried is the best move or count the number of researches.

Or the more recent thing many of us are doing, Every time you fail high, add the # of the move that caused the fail-high to a total. At the end, divide by the number of fail highs to get an average fail-high move number. Closer to 1.0 is better, 1.0 is perfect of course.

[hgm]

In my experience such statistics is pretty useless if you do not split it out by search depth. Otherwise you will just see what happens in QS nodes, and you would never know if your move ordering for deep searches sucks.

[Robert Pope]

In my experience such statistics is pretty useless if you do not split it out by search depth. Otherwise you will just see what happens in QS nodes, and you would never know if your move ordering for deep searches sucks.

You mean incremental (or cumulative) statistics by search depth? I don't see how that removes noise because of QS. Can you expand?

[hgm]

Keep the statistics (like how often your hash move or killers cause a cutoff, how many moves you search on the average in curt nodes before you have a cutoff, etc.) for every remaining depth separately.