Hashtable feeding : usual values?

[ernest]

I would like to update the data I have concerning hashtable feeding, in most up-to-date programs.

1. Hashtable entry size: usually 16 bytes (exceptions I know: Rybka/8 bytes, ChessTiger/10 bytes)?

2. Ratio "number of hashtable entries" per "number of nodes, as reported" that is, how many of the nodes (as reported by the program "the usual way", not the obfuscated way ) lead to a hash table entry.
This may depend heavily on the program (what it does in quiescence, in null move, ...) but I have this reminiscence of 10%, which may be completely wrong with the latest programs.

Can somebody help me?

[micron]

Does your question (2) relate to the hit rate of hash table probes? My program can display appropriate statistics

Code: Select all

Hash table statistics:
1.5E+7 positions saved. Load factor 0.91
2.9E+7 probes
5.8E+6 hits (score used)         19%
4.2E+6 hits (useable move)       14%
4.8E+5 hits (useless)            1%
1.9E+7 misses                    64%

but the percentages depend on the starting position, the depth of search, and the table size. They are therefore of interest only to the engine's author, as he experiments with replacement strategies and so on.

Robert P.

[bob]

I would like to update the data I have concerning hashtable feeding, in most up-to-date programs.

1. Hashtable entry size: usually 16 bytes (exceptions I know: Rybka/8 bytes, ChessTiger/10 bytes)?

2. Ratio "number of hashtable entries" per "number of nodes, as reported" that is, how many of the nodes (as reported by the program "the usual way", not the obfuscated way ) lead to a hash table entry.
This may depend heavily on the program (what it does in quiescence, in null move, ...) but I have this reminiscence of 10%, which may be completely wrong with the latest programs.

Can somebody help me?

12 bytes is likely optimal. you need to store the following:

(1) "lock" (part of hash signature you don't use to address the entry0
(2) draft (remaining depth
(3) type of entry (3 types, EXACT, LOWER, UPPER)
(4) score (depends on your score range and resolution (centipawns, millipawns, etc).
(5) best move (depends on how you store moves. Most compact move is 8 bits. Most use significantly more for ease of extraction.

I use 16 bytes to store the entire 64 bit hash signature.

For proper size, it is more complex. You need one entry for most nodes that you will do a lookup for. In Crafty, where I do not hash the q-search, that means that total nodes / 10 is a good estimate since something like 75-80% of all nodes searched are in the q-search, and many are duplicated as the search iterates... If a program probes in the q-search then you might want at least 75% of the total nodes searched for the number of hash entries, since most everything gets stored.

Some programs like Crafty don't store in the q-search. At one point Junior did not store the last ply of the normal search. Others store everything. Best bet is to test with different sizes to tune to optimal time to a fixed depth completion for a wide variety of positions.

[ernest]

Thanks Bob!
What do you mean by

Best bet is to test with different sizes to tune to optimal time to a fixed depth completion for a wide variety of positions.

Are you talking from a programmer's view (trying to optimize his program), or for me trying to discover, for a given program, what is the hash entry size and the ratio "nb of hash entries/nb of nodes reported"

[bob]

Thanks Bob!
What do you mean by

Best bet is to test with different sizes to tune to optimal time to a fixed depth completion for a wide variety of positions.

Are you talking from a programmer's view (trying to optimize his program), or for me trying to discover, for a given program, what is the hash entry size and the ratio "nb of hash entries/nb of nodes reported"

Both, actually. Once you do that computation, it will be easy to choose a hash size for a given time control, for that specific program.