Using a second slot in hash tables

[golmman]

I am new to chess programming so this might be a stupid question. What advantages has a second slot when using hash tables?

I tested a hash table using only one slot with a depth preferred replacement strategy. My hit rate in the middlegame was 15-20% with 4mio slots.
Now I decided to improve the table by adding one slot. The first slot remained depth preferred while the second was set to always replace. The total slot amount remained 4mio slots. I tried several proportions, 1.5mio depth preferred and 2.5mio always replace slots for example.

The great disappointment is that the hit rate was lowered in most cases and I never reached more than 20%.

So what is the theory behind it? Why do all good chess engines use at least 2 slots in their hash tables?

[bob]

I am new to chess programming so this might be a stupid question. What advantages has a second slot when using hash tables?

I tested a hash table using only one slot with a depth preferred replacement strategy. My hit rate in the middlegame was 15-20% with 4mio slots.
Now I decided to improve the table by adding one slot. The first slot remained depth preferred while the second was set to always replace. The total slot amount remained 4mio slots. I tried several proportions, 1.5mio depth preferred and 2.5mio always replace slots for example.

The great disappointment is that the hit rate was lowered in most cases and I never reached more than 20%.

So what is the theory behind it? Why do all good chess engines use at least 2 slots in their hash tables?

Depth-preferred is a "global" concept. "always-store" is a "local concept. If you search very deeply, you can fill the table with lots of deep draft entries, and not be able to store new entries far out in the tree which will hurt performance. That's why we use two. And usually the always-store is 2x bigger than the depth-preferred.

[Gian-Carlo Pascutto]

Two things to keep in mind when you run this test:

- The load factor on the hashtable should be big enough that enough entries get replaced so that the replacement strategy actually matters.

- Hitrate is a poor indicator of quality. A hit at depthleft 10 is worth exponentially more than a hit at depthleft 1.

[hgm]

If you do only depth-preferred, and the search overflows the hash table (like it does at long TC), the table wll be monopolized by entries close to the root. That means the search of the sub-trees beyond that wll now become extremely inefficient, as it cannot use the hash at all.

A sensitive test for hashing is the time you need to solve Fine #70.