BB+/others: 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 hashtable 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 BB+ or somebody else give me some help?

[BB+]

For engines like Rybka and IvanHoe, where hashing is done in qsearch, I would say it is close to 50%. A short IvanHoe computation verifies this, as in a 1 second search I get 41% hashfull (of 32mb) in 1488285 nodes searched. I do recall it is significantly lower for those that don't hash in qsearch.

Stockfish 1.8 still reported "hashfull", and from a depth 18 search I get

Code: Select all

info nodes 4088803 nps 1269026 time 3222 hashfull 268

and at 16 bytes per entry from a 32mb hash, this is not much more than the 10% figure you gave. OTOH, the increase in "hashfull" for this Stockfish version appears rather non-linear. Here is a depth 20 search with 128mb:

Code: Select all

info nodes 1173037 nps 1169528 time 1003 hashfull 0
info nodes 2484425 nps 1224457 time 2029 hashfull 0
info nodes 3822776 nps 1246421 time 3067 hashfull 1
info nodes 5196645 nps 1266239 time 4104 hashfull 5
info nodes 6523909 nps 1260171 time 5177 hashfull 15
info nodes 7850330 nps 1261705 time 6222 hashfull 30
info nodes 9152947 nps 1259868 time 7265 hashfull 52
info nodes 10499718 nps 1264264 time 8305 hashfull 80

So the first 4 seconds used almost no hash, but not so for the second four, and so after 8 seconds about 8% was reported as used.

Incidentally, I found a post from VR back when he was counting nodes more standardly, and both of the output lines with "hashfull" list it as "500".

Code: Select all

Subject: Re: The mistake of nullmover in the last game
From: Vasik Rajlich
Message Number: 346507
Date: February 02, 2004 at 07:19:15
[...]
3:42:33.797  --<< info nps 1042509 nodes 34840654 hashfull 500
[...]
3:43:01.922  --<< info nps 1224218 nodes 34388309 hashfull 500

[ernest]

For engines like Rybka and IvanHoe, where hashing is done in qsearch, I would say it is close to 50%.

Thanks, BB+
For Houdini, which gives the "filled" hash % (as can be seen in console mode or with the Shredder GUI), I also see something close to 50% (assuming that indeed the hash entry is 16 bytes)

[BB+]

Seems to me that Houdini eats up hash at nearly twice the rate of IvanHoe. Part of this might be slightly higher NPS, but I don't think that explains everything. Of course, IvanHoe has so many types of Hash (normal, pawns, PV, eval, TripleBase, maybe more for all I know) that the comparison might be unfair.