Therefore, I would recommend setting the cache space size as high as your available RAM allows (but not letting the memory swap). So, while your observations were based on a CPU with a low number of threads (8), on a Xeon CPU with higher number of threads (96) it took faster to evaluate the position. Although it evaluated just 6% more nodes, it achieved 22% NPS increase and 20% time decrease. With even bigger number of threads (96) and higher depth (45), the difference is even more pronounced. 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%. Thus, at 12 threads and a depth of 30, a large enough cache caused NPS to increase by 15%, the number of evaluated nodes increased by 27%, but the overall time increased by 14%. The final moves that the engine recommended also differ, starting from the 2nd ply (d7d5 vs g8f6). 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 10515490443 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Īs you see, with the larger cache, the engine evaluated the higher number of nodes and higher NPS and higher "seldepth". 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 7726548978 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 Setoption name UCI_AnalyseMode value true You can get the factual information yourself easily, by issuing the following commands to your UCI engine (assuming your CPU has 12 threads) with a 1 MB cache: uci The data suggests that keeping hashfull below 30% is best to maintain One could use 6000 as a reasonable value for the Hash.Īccording to a StockFish Wiki article that explains the cost of not having enough cache, The value is specified in MiB, and typicalĬonsumer hardware will have GiB of RAM. Leaving some memory free for other tasks. Set the hash to nearly the maximum amount of memory (RAM) available, For a chess engine, it is faster to get the calculated results from RAM even with cache miss than to calculate the results of the same position again. The optimal chess engine cache size does not correlate with the size of the RAM cache of the CPU. Therefore, you will get a higher "seldepth" value (selective search depth in plies) and more evaluated nodes, if not higher net nodes per second (NPS). With a larger cache size, it will evaluate more moves up to the given search depth in plies. The engine does not calculate all possible moves up to a given number of plies but tries to evaluate only the best moves. Therefore, it may take slower but produce higher quality results, i.e., the results will be different and better. A larger cache is especially beneficial if you have a CPU with many threads and cores a higher cache may produce results faster from a certain number of threads.Ī larger cache size allows the engine to avoid calculating again the same positions caused by different moves. Therefore, with a larger cache, at a higher time spent, it usually evaluates a higher number of moves, thus producing better results. Anyway, it only evaluates some possible moves to reach this depth. A chess engine tries to allocate an approximate amount of time to reach a certain depth.
0 Comments
Leave a Reply. |