Right hash size

[Torom]

Hey,

I noticed that almost all of Stockfish's settings are well documented, except for the hash size. The readme only says to set it after the threads. But what is the right hash size?

I have often read that bigger <> better. This issue discusses the correct hash size for the TCEC. There it is described that there are a variety of factors for the correct hash size and no general statement can be made. But how do I test which hash size is the right one for my system? Which benchmarks should I test and what should I look out for?

I once saw a Stockfish fork where a formula was given. But I can't find it right now. I think this is a question that many Stockfish users ask themselves over time. Since there is probably no simple short answer, perhaps a wiki article for this would be useful.

Thanks in advance.

[osteslag]

Don’t know how helpful it is, but issue #2755 also talks about hash usage.

[MichaelB7]

A common rule of thumb ( from ancient chess computer days) is that a user should be using about 70% of the available hash. So that depends on time and how fast your computer and the number of threads. On some modern hardware with a large number of cores and threads, a large hash may get filled very fast, in just a few minutes. If you are only doing very short search with just a single thread, a large hash is not needed. This is the reason why hash utilization is being reported on the command line, it is useful information. If you are using Windows Large Pages with default settings, best practice is to set hash in 2048 MB increments, -> 2048, 4096, 6144 etc.

[vondele]

improving docs would be useful I guess. The rule of thumb is, never more than the computer can support, i.e. avoid more than say 70% of total RAM (unless you have a lot) seems a good idea (assuming you have a single chess engine running, not matches between multiple engines). Usually, you need to have a look at how much hash is used in search, this depends on TC. Probably ideal is to have the hash only say, 50-70% filled. The default hash is almost always too small on modern computers, but the UCI protocol suggests using a small number. Most memory related problems seem to come from table base use. The rule if thumb IMO seems to be, if you use N man TB, leave enough memory free for N-1 man TB to be in RAM.

[maximmasiutin]

There is no right hash size, everything depend on your workloads. Just monitor the UCI output, i.e., by parsing debug log, and see the "hashfull" value. If it reaches 1000, try to increase the hash size. If the hash is almost full but never gets full, you get optimal results in terms of higer number of nodes evaluated, or higher NPS values. It is always faster to get results from cache for a duplicate position, then to re-evaluate a position again.

The StockFish chess engine tries to allocate an approximate time to reach a given depth. You never know for sure (in milliseconds) how long will it take to evaluate a position given a particular depth. However, it should be taken into consideration that StockFish does not evaluate all possible moves to that depth. Therefore, a larger cache typically evaluates more moves even at a higher time cost, but leading to better results. A larger cache is especially useful if your CPU has many threads and cores; above a certain number of threads, a larger cache can provide faster results.

A larger cache size allows the engine to avoid recalculating the same position caused by different moves. So it might take slower but give higher quality results, which means different but better results. Instead of counting all possible moves up to a certain number of plies, the engine tries to evaluate only the best reasonable moves. With larger cache sizes, more moves are evaluated to the specified search depth. Therefore, with a larger cache, we can achieve higher seldepth (selective search depth in layers) and more evaluated nodes, if not higher nodes per second (NPS).

Some say that a larger chess engine hash actually slows down the result because it doesn't fit in the CPU cache, e.g. 18MB on an Intel i5-12500 CPU. The argument goes that larger chess engine hashes produce more CPU cache misses and are thus slower than smaller hashes. However, a CPU cache miss is not as expensive as a chess engine re-evaluating a position.

You can get the facts by issuing the following command to a UCI engine with a 1MB cache (assuming your CPU has 12 threads):

uci
setoption name Threads value 12
setoption name Hash value 1
setoption name UCI_AnalyseMode value true
go depth 30

On my computer, it gave the following results:

Depth: 30, Threads: 12, Cache: 1 MB

info depth 30 seldepth 28 multipv 1 score cp 36 nodes 77265471 nps 10348978 hashfull 1000 tbhits 0 time 7466 pv d2d4 g8f6 c2c4 e7e6 g1f3 d7d5 g2g3 c7c5 f1g2 c5d4 e1g1 f8e7 f3d4 e6e5 d4f3 e5e4 f3e5 b8c6 e5c6 b7c6

If I run the same commands, but the cache size is 32768 MB rather than 1 MB (setoption name Hash value 32768), I get the following results:

Depth: 30, Threads: 12, Cache: 32768 MB (32 GB)

info depth 30 seldepth 42 multipv 1 score cp 24 nodes 105154983 nps 12110443 hashfull 22 tbhits 0 time 8683 pv d2d4 d7d5 g1f3 g8f6 c2c4 d5c4 e2e3 e7e6 f1c4 c7c5 e1g1 a7a6 d4c5 f8c5 d1d8 e8d8 c4e2 d8e7 b1d2 c8d7 d2b3 c5d6 b3a5 b7b6 a5c4 d7b5 f1d1 b5c4 e2c4 h8c8 c4e2 b8c6 c1d2
bestmove d2d4 ponder d7d5

As you can see, the engine with the larger cache evaluates to a higher number of nodes and a higher NPS and higher "seldepth". The moves recommended by the engine are also different, starting from the second ply (d7d5 vs. g8f6). For example, at 12 threads and 30 depth, a sufficiently large cache results in a 15% increase in NPS, a 27% increase in the number of evaluation nodes, but a 14% increase in total time.

The value after "hashfull" means the fullness of the cache space in tens of percentage points, i.e., "hashfull 1000" mean 100.0%; "hashfull 22" mean 2.2%.

The difference is more pronounced with more threads (96) and greater depth (45). Although it only increased the number of evaluated nodes by 6%, it achieved a 22% increase in NPS and a 20% decrease in time. Here are the results:

Depth: 45, Threads: 96, Cache: 1 MB

info depth 45 seldepth 31 multipv 1 score cp 22 nodes 7744802440 nps 49384683 hashfull 1000 tbhits 0 time 156826 pv e2e4 e7e5 g1f3 b8c6 f1c4 f8c5 d2d3 d7d6 c2c3 g8f6 b1d2 e8g8 e1g1 a7a6 c4b3 h7h6 f1e1 f8e8 h2h3 c8e6 d2c4 b7b5 c4e3 e6b3 d1b3 c5e3 c1e3
bestmove e2e4 ponder e7e5

Depth: 45, Threads: 96, Cache: 327680 MB (320 GB)

info depth 45 seldepth 57 multipv 1 score cp 18 nodes 8238379798 nps 63446824 hashfull 143 tbhits 0 time 129847 pv e2e4 e7e5 g1f3 b8c6 f1b5 g8f6 e1g1 f6e4 f1e1 e4d6 f3e5 c6e5 e1e5 f8e7 b5f1 e8g8 d2d4 e7f6 e5e1 f8e8 c2c3 e8e1 d1e1 d6e8 c1f4 d7d5 b1d2 c8f5 e1e3 e8d6 a2a4 a7a5 f1d3 f5d3 e3d3 c7c6 a1e1 g7g6 h2h3 h7h5 e1e2 f6g7
bestmove e2e4 ponder e7e5

Therefore, I recommend setting the cache memory size to the maximum size available RAM allows (but don't swap out memory).

P.S. If I set the limit by time instead of number of moves (e.g. "go movetime 3600000" makes the evaluation take an hour), on a CPU with 12 threads and 32GB cache it takes about 10 minutes to completely fill the cache space. However, even for an hour-long calculation, larger cache sizes give better results.

[dav1312]

For posterity, a test is available in the wiki showing the elo cost of a small hash

The data suggests that keeping hashfull below 30% is best to maintain strength.

https://github.com/official-stockfish/Stockfish/wiki/Useful-data#elo-cost-of-small-hash

[vondele]

no, it means typically setting hash as large as possible, unless the hashfull number shown by SF is consistently below 30%.

[OverLordGoldDragon]

consistently above, you mean?

below 30% is best to maintain strength

[vondele]

no the hash should be so large it is filled less than 30%. Anyway, the procedure is rather simple, in general more hash is better.

[dav1312]

It seems "hashfull" isn't same as "hash"

Hash is the total available amount, hashfull is how full the hash is.
You can have 16GB of RAM, give the engine 14GB of hash and the hash be 50% full (500 hashfull).
During engine games, it is better for the average hashfull to be below 300 (hash 30% full).

[RogerThiede]

it means typically setting hash as large as possible

I don't know who the average user of Stockfish is, but I do imagine that at some point in the future the average user would be instantiating runs of Stockfish on cloud servers more often than not. My typical usage in prior years has been on dual socket servers with up to 1TB of RAM, and choice of hashsize can have large implications on performance due to cache coherency and interleaving.
For a desktop user with one socket (or more specifically with one memory controller,) typically setting hash as large as possible without going into swap space still makes the most sense.