TT hit/miss rates

[vladstamate]

Hi,

I am trying to see how way off mark I am compared with other engines in the TT hit/miss ratio.

From the start position, looking until depth 8, this is what I get

Code: Select all

Cache usage: hits=16009(16.26%) misses=15367(15.61%) conflicts=67063(68.13%)

hits - a value was found and returned
misses - either the depth of the value/move stored in the hash was not good enough or the node type and value do not play well with out current alpha/beta. Basically for some reason the entry is there but we cannot use/trust it. I use the move stored though for move ordering purposes.
conflicts - either I am probing an empty (non-written yet) entry or the full 64 bit hash does not match.

What are typical ratios?

Regards,
Vlad.

[micron]

I am trying to see how way off mark I am compared with other engines in the TT hit/miss ratio.
From the start position, looking until depth 8, this is what I get

Code: Select all

Cache usage: hits=16009(16.26%) misses=15367(15.61%) conflicts=67063(68.13%)

What are typical ratios?

I was interested by your results, having recently tweaked my TT code in the hope of increasing the number of fully useable hits. From the start position, my program reports:

Code: Select all

nominal 7 ply search:
5.2E+4 probes
1.3E+4 hits (score used) 25% [your 'hits']
9.4E+3 hits (move tried) 18% [your 'misses']
2.9E+4 misses            55% [your 'conflicts']

nominal 8 ply search:
2.4E+5 probes
6.5E+4 hits (score used) 27% [your 'hits']
2.9E+4 hits (move tried) 12% [your 'misses']
1.4E+5 misses            60% [your 'conflicts'] 

These percentages are sensitive to details of the replacement policy for the TT. My present policy is:
overwrite the cached node unless incoming_score_is_inexact && we_have_a_cache_hit && search_depth_of_cached_node > search_depth_of_incoming_node.

Robert P.

[hgm]

Does your replacement policy really matter, for such a shallow search? I would expect the tree to completely fit into the table, without hardly any collisions.

A second question: does that condition you give above really help? If the depth of the new search was less than for the same node in hash, it must mean that the bound of the latter is no good for your current window. But in PVS your whole search will keep using the current (null) window throughout, unless the score at the root changes. (Which happens very infrequently.)

So by keeping the entry with the worthless bound, any subsequent hit on it will have to do the search, no matter what the requested depth was. When you would store the result of the current search, no matter how undeep, at least future hits of lower requested depth could profit from it.

[micron]

You are right. If the TT is virtually empty, the best policy seems to be 'always overwrite'. I wish I had known this earlier. Replacement strategy becomes relevant when the table fills up, which is likely in, for example, an 11-ply search from the start.

The answer to your second question is "yes, it does help my program in wide deep searches". But I don't do PVS yet. When that is implemented, your interesting comments suggest that I might profitably revisit the TT replacement strategy.

[jwes]

You are right. If the TT is virtually empty, the best policy seems to be 'always overwrite'. I wish I had known this earlier. Replacement strategy becomes relevant when the table fills up, which is likely in, for example, an 11-ply search from the start..

If the TT is virtually empty, all replacement strategies are approximately the same.