Dev Builds » 20180516-2051

You are viewing an old NCM Stockfish dev build test. You may find the most recent dev build tests using Stockfish 15 as the baseline here.

Use this dev build

NCM plays each Stockfish dev build 20,000 times against Stockfish 7. This yields an approximate Elo difference and establishes confidence in the strength of the dev builds.

Summary

Host Duration Avg Base NPS Games Wins Losses Draws Elo
ncm-et-3 06:01:21 2002469 2398 1152 60 1186 +170.75 ± 9.58
ncm-et-4 06:01:25 1996421 2402 1098 87 1217 +155.92 ± 9.5
ncm-et-5 01:47:34 2006034 713 355 18 340 +178.4 ± 18.01
ncm-et-6 01:47:32 2025326 719 358 16 345 +179.75 ± 17.82
ncm-et-7 01:47:38 2024346 712 344 19 349 +171.23 ± 17.73
ncm-et-8 01:47:42 2001640 719 366 15 338 +185.41 ± 18.03
ncm-et-9 06:01:14 2000672 2375 1146 60 1169 +171.58 ± 9.66
ncm-et-10 06:01:21 1985874 2371 1127 70 1174 +166.58 ± 9.66
ncm-et-11 01:47:48 2021244 719 349 17 353 +173.56 ± 17.58
ncm-et-12 01:47:42 2006604 716 338 24 354 +163.44 ± 17.66
ncm-et-13 06:01:01 1966877 2363 1094 74 1195 +160.49 ± 9.56
ncm-et-14 01:47:47 2019940 712 342 14 356 +173.08 ± 17.4
ncm-et-15 06:01:12 1975096 2367 1127 52 1188 +170.22 ± 9.53
ncm-et-16 01:47:33 2002048 714 352 18 344 +176.23 ± 17.88
20000 9548 544 9908 +168.49 ± 3.32

Test Detail

ID Host Started (UTC) Duration Base NPS Games Wins Losses Draws Elo CLI PGN
50628 ncm-et-10 2018-08-21 09:32 00:23:53 1961159 159 72 3 84 +161.48 ± 35.61 ↓
50627 ncm-et-15 2018-08-21 09:32 00:23:55 1910551 152 70 4 78 +161.58 ± 37.4 ↓
50626 ncm-et-9 2018-08-21 09:31 00:24:30 1986406 164 81 2 81 +182.47 ± 36.47 ↓
50625 ncm-et-13 2018-08-21 09:31 00:24:54 1931702 155 76 5 74 +171.93 ± 38.98 ↓
50624 ncm-et-3 2018-08-21 09:28 00:27:27 1990664 181 83 3 95 +164.93 ± 33.44 ↓
50623 ncm-et-4 2018-08-21 09:27 00:28:45 1989402 189 92 5 92 +172.92 ± 34.69 ↓
50622 ncm-et-13 2018-08-21 08:15 01:14:49 1986721 500 235 15 250 +164.07 ± 20.94 ↓
50621 ncm-et-10 2018-08-21 08:13 01:17:21 1983106 500 252 13 235 +180.8 ± 21.72 ↓
50620 ncm-et-9 2018-08-21 08:13 01:16:51 1987825 500 240 18 242 +165.8 ± 21.46 ↓
50619 ncm-et-15 2018-08-21 08:13 01:17:45 1943983 500 229 14 257 +159.78 ± 20.54 ↓
50618 ncm-et-3 2018-08-21 08:12 01:15:07 1992090 500 226 12 262 +158.93 ± 20.21 ↓
50617 ncm-et-4 2018-08-21 08:11 01:14:57 1990823 500 228 17 255 +156.39 ± 20.73 ↓
50616 ncm-et-10 2018-08-21 06:57 01:15:14 1982634 500 226 22 252 +150.51 ± 21.01 ↓
50615 ncm-et-13 2018-08-21 06:57 01:17:08 1899817 500 220 18 262 +148.85 ± 20.39 ↓
50614 ncm-et-15 2018-08-21 06:57 01:15:06 1981381 500 249 10 241 +180.8 ± 21.28 ↓
50613 ncm-et-4 2018-08-21 06:56 01:13:58 1992724 500 220 14 266 +152.18 ± 20.07 ↓
50612 ncm-et-9 2018-08-21 06:56 01:16:18 1989243 500 257 10 233 +188.08 ± 21.74 ↓
50611 ncm-et-3 2018-08-21 06:55 01:15:30 1990032 500 255 16 229 +180.8 ± 22.15 ↓
50610 ncm-et-15 2018-08-21 05:39 01:16:49 1979663 500 239 11 250 +171.02 ± 20.82 ↓
50609 ncm-et-13 2018-08-21 05:39 01:16:55 1932368 500 225 14 261 +156.39 ± 20.33 ↓
50608 ncm-et-3 2018-08-21 05:39 01:15:38 1989085 500 257 16 227 +182.61 ± 22.27 ↓
50607 ncm-et-10 2018-08-21 05:39 01:17:21 1950421 500 245 13 242 +174.55 ± 21.33 ↓
50606 ncm-et-9 2018-08-21 05:39 01:16:06 1988927 500 236 14 250 +165.8 ± 20.91 ↓
50605 ncm-et-4 2018-08-21 05:39 01:16:10 1988139 500 227 24 249 +149.68 ± 21.21 ↓
30778 ncm-et-13 2018-05-17 01:19 00:31:25 2024099 208 97 7 104 +160.93 ± 32.64 ↓
30777 ncm-et-16 2018-05-17 01:18 00:32:05 2000345 214 114 8 92 +188.69 ± 35.36 ↓
30776 ncm-et-6 2018-05-17 01:18 00:32:07 2025245 219 111 4 104 +185.6 ± 32.51 ↓
30775 ncm-et-9 2018-05-17 01:18 00:32:24 2024590 211 104 4 103 +178.97 ± 32.56 ↓
30774 ncm-et-15 2018-05-17 01:18 00:32:31 2018232 215 93 2 120 +156.92 ± 29.1 ↓
30773 ncm-et-12 2018-05-17 01:18 00:32:40 1992699 216 100 10 106 +154.14 ± 32.63 ↓
30772 ncm-et-10 2018-05-17 01:18 00:32:32 2018395 212 98 9 105 +155.46 ± 32.69 ↓
30771 ncm-et-4 2018-05-17 01:18 00:32:39 1992521 213 103 11 99 +160.61 ± 34.04 ↓
30770 ncm-et-5 2018-05-17 01:17 00:32:57 1987642 213 109 2 102 +191.94 ± 32.52 ↓
30769 ncm-et-14 2018-05-17 01:17 00:33:04 2019696 212 102 1 109 +180.09 ± 30.92 ↓
30768 ncm-et-3 2018-05-17 01:17 00:32:58 2027210 217 101 4 112 +167.1 ± 30.92 ↓
30767 ncm-et-7 2018-05-17 01:17 00:33:11 2022957 212 102 8 102 +165.54 ± 33.21 ↓
30766 ncm-et-11 2018-05-17 01:17 00:33:13 2022467 219 100 8 111 +155.58 ± 31.58 ↓
30765 ncm-et-8 2018-05-17 01:17 00:33:45 1979997 219 118 4 97 +200.5 ± 33.96 ↓
30764 ncm-et-13 2018-05-17 00:02 01:15:50 2026555 500 241 15 244 +169.27 ± 21.27 ↓
30763 ncm-et-9 2018-05-17 00:02 01:15:05 2027046 500 228 12 260 +160.64 ± 20.32 ↓
30762 ncm-et-16 2018-05-17 00:02 01:15:28 2003751 500 238 10 252 +171.02 ± 20.68 ↓
30761 ncm-et-5 2018-05-17 00:02 01:14:37 2024427 500 246 16 238 +172.78 ± 21.64 ↓
30760 ncm-et-7 2018-05-17 00:02 01:14:27 2025736 500 242 11 247 +173.67 ± 20.98 ↓
30759 ncm-et-4 2018-05-17 00:02 01:14:56 2024918 500 228 16 256 +157.24 ± 20.65 ↓
30758 ncm-et-8 2018-05-17 00:02 01:13:57 2023283 500 248 11 241 +179.0 ± 21.32 ↓
30757 ncm-et-15 2018-05-17 00:02 01:15:06 2016771 500 247 11 242 +178.11 ± 21.26 ↓
30756 ncm-et-6 2018-05-17 00:02 01:15:25 2025408 500 247 12 241 +177.22 ± 21.35 ↓
30755 ncm-et-12 2018-05-17 00:02 01:15:02 2020510 500 238 14 248 +167.53 ± 21.02 ↓
30754 ncm-et-10 2018-05-17 00:02 01:15:00 2019533 500 234 10 256 +167.53 ± 20.46 ↓
30753 ncm-et-14 2018-05-17 00:02 01:14:43 2020184 500 240 13 247 +170.15 ± 21.05 ↓
30752 ncm-et-3 2018-05-17 00:02 01:14:41 2025736 500 230 9 261 +164.93 ± 20.16 ↓
30751 ncm-et-11 2018-05-17 00:02 01:14:35 2020021 500 249 9 242 +181.7 ± 21.19 ↓

Commit

Commit ID 91a76331ca27b40d63f0031fbd7b9e41ead354d4
Author Tom Truscott
Date 2018-05-16 20:51:43 UTC
Use cycle detection to bound search value A position which has a move which draws by repetition, or which could have been reached from an earlier position in the game tree, is considered to be at least a draw for the side to move. Cycle detection algorithm by Marcel van Kervink: https://marcelk.net/2013-04-06/paper/upcoming-rep-v2.pdf ---------------------------- How does the algorithm work in practice? The algorithm is an efficient method to detect if the side to move has a drawing move, without doing any move generation, thus possibly giving a cheap cutoffThe most interesting conditions are both on line 1195: ``` if ( originalKey == (progressKey ^ stp->key) || progressKey == Zobrist::side) ``` This uses the position keys as a sort-of Bloom filter, to avoid the expensive checks which follow. For "upcoming repetition" consider the opening Nf3 Nf6 Ng1. The XOR of this position's key with the starting position gives their difference, which can be used to look up black's repeating move (Ng8). But that look-up is expensive, so line 1195 checks that the white pieces are on their original squares. This is the subtlest part of the algorithm, but the basic idea in the above game is there are 4 positions (starting position and the one after each move). An XOR of the first pair (startpos and after Nf3) gives a key matching Nf3. An XOR of the second pair (after Nf6 and after Ng1) gives a key matching the move Ng1. But since the difference in each pair is the location of the white knight those keys are "identical" (not quite because while there are 4 keys the the side to move changed 3 times, so the keys differ by Zobrist::side). The loop containing line 1195 does this pair-wise XOR-ing. Continuing the example, after line 1195 determines that the white pieces are back where they started we still need to make sure the changes in the black pieces represents a legal move. This is done by looking up the "moveKey" to see if it corresponds to possible move, and that there are no pieces blocking its way. There is the additional complication that, to match the behavior of is_draw(), if the repetition is not inside the search tree then there must be an additional repetition in the game history. Since a position can have more than one upcoming repetition a simple count does not suffice. So there is a search loop ending on line 1215. On the other hand, the "no-progress' is the same thing but offset by 1 ply. I like the concept but think it currently has minimal or negative benefit, and I'd be happy to remove it if that would get the patch accepted. This will not, however, save many lines of code. ----------------------------- STC: LLR: 2.95 (-2.94,2.94) [0.00,5.00] Total: 36430 W: 7446 L: 7150 D: 21834 http://tests.stockfishchess.org/tests/view/5afc123f0ebc591fdf408dfc LTC: LLR: 2.96 (-2.94,2.94) [0.00,5.00] Total: 12998 W: 2045 L: 1876 D: 9077 http://tests.stockfishchess.org/tests/view/5afc2c630ebc591fdf408e0c How could we continue after the patch: • The code in search() that checks for cycles has numerous possible variants. Perhaps the check need could be done in qsearch() too. • The biggest improvement would be to get "no progress" to be of actual benefit, and it would be helpful understand why it (probably) isn't. Perhaps there is an interaction with the transposition table or the (fantastically complex) tree search. Perhaps this would be hard to fix, but there may be a simple oversight. Closes https://github.com/official-stockfish/Stockfish/pull/1575 Bench: 4550412
Copyright 2011–2024 Next Chess Move LLC
Feedback & Support Terms of Service Privacy Policy Desktop Version