size of hash almost change nothing for berserk13

[Uri Blass]

I tested berserk 2M hash against 256M hash at 1M nodes per move with 36 games and the 2M hash team won the match
37-35

games are from the opening position with no book when every team included contempt 0,10,20,30,40,50 and every engine in the team played against every engine in the other side

8 games out of 72 were non draws(hash 256 when hash is not mentioned and always 1M nodes per move:
1)hash2 cont10-cont50 0-1(158 moves)
2)hash2 cont20-cont 30 1-0(83 moves)
3)cont20-hash2 cont40 0-1(62 moves)
4)hash2 cont40-cont40 1-0(170 moves)
5)cont10-hash2 cont50 1-0(88 moves)
6)hash2 cont 50-cont10 1-0(63 moves)
7)hash2 cont50-cont20 1-0(78 moves)
8)cont30-hash2 cont0 1-0(70 moves)

Edit:Maybe you need more nodes per move than the size of hash but in this case I believe using 64 mbytes hash is clearly enough for average of 30 seconds per move and you can gain almost nothing from higher hash.

[Uri Blass]

With 2M nodes per move I finally got a win for the team with 256 mbytes with 66 draws and 6 wins for the 256 mbytes.
team(always winner is with more hash)
30-20 1-0
40-20 1-0
30-20 0-1
0-50 1-0
50-20 0-1
20-50 1-0

[hgm]

Playing games seems a very indirect (and thus inaccurate) method for determining the effect of the hash size. At low draw rate a speedup of 1% typically increases the rating with 1 Elo (70 Elo per doubling), which would result in 0.14% result improvement, which needs some 80,000 games to measure. While measuring the speedup directly from time-to-depth can easily be done with 1% accuracy on a couple of hundred positions, taking as much time as one or two games.

From such time-to-depth measurements I found that you only start to notice a slowdown if the hash size gets below 1/10 of the number of nodes in the tree. How rapidly the search time increases after that depends on the effectiveness of the replacement scheme; the best scheme I tried (equi-distributed draft) gave a speedup proportional to the 12th root of the hash size. (So a speed doubling for a 4096 times larger table.)

[Uri Blass]

Playing games seems a very indirect (and thus inaccurate) method for determining the effect of the hash size. At low draw rate a speedup of 1% typically increases the rating with 1 Elo (70 Elo per doubling), which would result in 0.14% result improvement, which needs some 80,000 games to measure. While measuring the speedup directly from time-to-depth can easily be done with 1% accuracy on a couple of hundred positions, taking as much time as one or two games.

From such time-to-depth measurements I found that you only start to notice a slowdown if the hash size gets below 1/10 of the number of nodes in the tree. How rapidly the search time increases after that depends on the effectiveness of the replacement scheme; the best scheme I tried (equi-distributed draft) gave a speedup proportional to the 12th root of the hash size. (So a speed doubling for a 4096 times larger table.)

The problem with measuring time to depth is that the advantage of bigger hash is not only about being faster to finish the same depth and sometimes engines can see thanks to hash tables more plies forward because the leaf position that they get at depth 12 is already something that they got with a shorter line and analyzed.

I can add that chess engines can use information that they learned during the search to improve their search and evaluation and with bigger hash tables they may have more information because hash tables may be used not only for specific positions but also for memorizations of statistics.

For example about changing the evaluation during the search:
The engine may remember that if the last 4 plies were Bg4 h3 Bh5 g4 then it happens often that there is a change of the hash move from Bg6 to Bf7 and learn to increase the piece square table for bishop at f7 or to reduce the piece square table for a bishop at g6

I do not know if there are engines that use this type of idea.

[hgm]

'Hash grafting' is not very important in the middle-game. It requires reaching the same position through a shorter path, and if there are many pieces around the chances that they all end up in the same location is quite small. So it is mainly an effect that you see in end-games with very few pieces (such as KRK), or mostly immobile pieces (Pawn endings).

If you are worrying about this, it would be better to measure the effect of grafting by itself. By comparing the normal version of the engine with one that accepts only exact-depth hash hits, and taking statistics of how often a (rejected) over-deep hit would have a result that differs from the subsequent search result, and whther this difference would then propagate to the root.