我正在使用 macOS 应用程序 Stockfish，它使用当前版本的 Stockfish 14.1 作为国际象棋引擎，令我惊讶的是，当我设置时，我的计算机（Apple M1 Pro 10C）达到深度 30 所需的时间要少得多与我将其设置为 8GB 时相比，哈希表大小为 1MB。
大小为 1MB 的哈希表需要大约 18 秒才能达到初始国际象棋位置的深度 30。 大小为 8192MB 的哈希表需要大约 85 秒才能达到初始国际象棋位置的深度 30。
这是否意味着重新计算比使用内存更快？
这是否意味着重新计算比使用内存更快？
我猜（对 Stockfish 内部结构一无所知）；这意味着哈希表太大而无法保留在 CPU 的缓存中（使哈希表访问变慢）；并且更大的哈希表的性能优势（“更少的冲突，更短的具有相同哈希的事物列表”）与性能成本（更多的缓存未命中）相比相形见绌。
国际象棋引擎试图分配一个大概的时间来达到一定的深度。无论如何，它不会评估达到此深度的所有可能移动。因此，缓存越大，花费的时间越长，它通常会评估更多的移动次数，从而产生更好的结果。如果您的 CPU 有很多线程和内核，那么更大的缓存尤其有用；从一定数量的线程，更高的缓存可能会更快地产生结果。
更大的缓存大小可以让引擎避免再次计算不同移动导致的相同位置。因此，它可能会花费更慢的时间，但会产生更高质量的结果，即结果会有所不同且更好。引擎不会计算达到给定层数的所有可能移动，而是尝试仅评估最佳移动。使用较大的缓存大小，它将评估更多移动到给定的层搜索深度。因此，如果不是更高的每秒净节点数 (NPS)，您将获得更高的“seldepth”值（层中的选择性搜索深度）和更多的评估节点。
这与 CPU 缓存无关，因为即使缓存未命中，从 RAM 中获取计算结果也比再次计算相同位置的结果更快。
您可以通过向具有 1 MB 缓存的 UCI 引擎（假设您的 CPU 有 12 个线程）发出以下命令来获取事实信息：
uci
setoption name Threads value 12
setoption name Hash value 1
setoption name UCI_AnalyseMode value true
go depth 30
在我的电脑上，它给出了以下结果：
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
如果我运行相同的命令，但缓存大小是 32768 MB 而不是 1 MB (
setoption name Hash value 32768info 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
如您所见，缓存越大，引擎评估的节点数越多，NPS 和“seldepth”也越高。引擎推荐的最后一步也不同，从第二层开始（d7d5 vs g8f6）。因此，在 12 线程和 30 深度时，足够大的缓存导致 NPS 增加了 15%，评估节点数增加了 27%，但整体时间增加了 14%。
hashfull后面的值表示缓存空间的充满度，单位为几十个百分点，即hashfull 1000表示100.0%； “hashfull 22”意味着 2.2%。
更多的螺纹数 (96) 和更高的深度 (45)，差异更加明显。虽然它只评估了 6% 的节点，但它实现了 22% 的 NPS 增加和 20% 的时间减少。因此，虽然您的观察是基于线程数较少 (8) 的 CPU，但在线程数较多 (96) 的 Xeon CPU 上，评估位置的速度更快。以下是结果：
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
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
因此，我建议将缓存空间大小设置为可用 RAM 允许的最大大小（但不要让内存交换）。
如果我按时间而不是按层数设置限制（例如“go movetime 3600000”让评估花费一小时），在具有 12 线程和 32 GB 缓存的 CPU 上，大约需要 10 分钟才能填充完全占用缓存空间，但即使在一小时的计算中，更大的缓存大小也会产生更好的结果。