![[Image]](../Images/ch_as_header2.jpg)
Setting the appropriate hash table size for your chess engine should be a relatively simple matter, right? Well, as it turns out, the optimum hash table size depends on the position. In this article, I will take a look at some test results that show some interesting phenomena. The machine used to run these tests was an Athlon XP 2400+ with 166Mhz front side bus speed, 12X bus multiplier, and 7-3-3 2.5 CAS latency DRAM.
Most of us operate under the assumption that bigger hash tables are always better. While this is not always the case, it is a good general rule to follow. But, it is not too difficult to find instances where a smaller hash table size can mean better performance out of an engine, as this article will show.
Three different positions were examined during tests with the default CA engine (Tiger 15). The first position was simply the initial position on the chessboard when a game starts. Shown below is a plot of time to reach a certain ply depth as a function of the hash table size. We can see that for all depths, increasing the hash table size seems to increase performance by only a very small amount. If you were to take the slope of the curves shown on this plot, you would see that you get about a 1% increase in performance for every doubling of the hash tables.
![[Starting position]](020/starting.jpg) |
Note that for a depth of 16, using 24M of hash will actually slow the engine down somewhat. This is contrary to what will be shown in subsequent plots.
The second position is an example of a typical middlegame position where there are a fair number of transpositional possibilities. Here we see that doubling the hash table size results in about a 10% increase in performance (on the average), across the various ply depths. We also see that there appears to be a "sweet spot" at around 24Mb of hash. This behavior is also evident in our next set of results as well.
![[rnbq2k1/p1r2p1p/1p1p1Pp1/1BpPn1N1/P7/2P5/6PP/R1B1QRK1 w - -]](020/middle.jpg) |
![[8/5k2/3K4/3P4/8/8/2R5/3r4 b - -]](020/end.jpg) |
In all the cases that were examined, there was only a small penalty for using large hash tables (i.e. a decreasing number of nodes per second processed), and there appears to be no one point where hash table usage is most efficient 100% of the time. Note also that in some of the tables, there are multiple depths listed. This is a characteristic of negascout algorithms, sometimes they search again at the same depth.
One conclusion that can be drawn from this data, is that doubling the hash table size decreases the time to reach a certain analysis depth by about 10% for some middlegame positions. At higher depths, there is an even greater benefit, while at lower depths, there is not as much. For endgame positions, there is about a 20% speedup in time to reach a certain depth. Thus we see a practical illustration of larger hash tables being more important in the endgame.
Surely it would be nice to extend this analysis with additional machines and positions, but these results should get you thinking about the subject. Note that extrapolating these results to other engines would probably not be a wise thing to do. Rather, these results provide graphical confirmation of the effect of hash table sizing for one engine, with a particular subset of positions.
<>