Rebel wrote:bob wrote:Rebel wrote:When implementing hash tables in the days that memory was limited (1 Mb if you were rich) I set-up my hash table data structure as follows:
- One hash table for odd plies
- One hash table for even plies
And where ever possible make the odd ply HT twice as big as the even ply HT because that one is accessed the most due to the AB behaviour. And it also worked great in case of a full HT. Anno 2012 I wonder if that's still the case.
Anyone using a somewhat similar system ?
You realize that if you do an even-ply search, 1/2 of the hash stores are going to be from that last layer of even-ply searches??? That is, for every depth N-1 node where N-1 is odd, you will always see a depth N search (and probe).
I don't see why this makes any sense at all...
I have a display, it gives the percentages how both HT tables fill and the odd-ply HT fills a lot faster than the even ply HT. It's exactly what one might expect from a well ordered search. And so it makes sense to declare a bigger odd-ply-HT than an even-ply-HT. Just try yourself.
See my response to Sam. I simply counted wtm and btm positions throughout the search (none in q-search since I don't hash there) and found a reasonable balance...
I'll post the numbers in a few minutes, will have to extract and format...
Here we go.
First postion is BTM, kopec#22. Searched to depth=22
wtm=10,718,001 btm=8,587,532
time=39.66 mat=0 n=118,450,786 fh=95% nps=3.0M
The "even plies" (wtm, since BTM was root) were bigger, but not by a lot.
Next position is WTM, kopec#24, searched to depth=19
wtm=5411683 btm=6442429
time=49.83 mat=0 n=109541418 fh=93% nps=2.2M
Even plies (btm this time) slightly larger.
Next (and final) position is wtm, kopec#21, searched to depth=20
wtm=6760964 btm=3109970
time=15.51 mat=0 n=53688784 fh=94% nps=3.5M
This time the odd plies (wtm) is bigger.
I ran the entire set and saw absolutely no consistency other than the totals seemed to bounce to favor one side or the other about equal numbers of times...
Here's a few others just for fun, but just the wtm/btm counters:
wtm=7060090 btm=6452962
wtm=3893962 btm=3689548
wtm=9946589 btm=16398992
wtm=4324817 btm=6880681
wtm=8218700 btm=5259557
Those last ones were searched with a fixed time limit rather than a fixed depth...
Seems to be no correlation between STM and node distribution, nor odd/even ply depth.