Permalink
Comparing changes
Choose two branches to see what’s changed or to start a new pull request.
If you need to, you can also or
learn more about diff comparisons.
Open a pull request
Create a new pull request by comparing changes across two branches. If you need to, you can also .
Learn more about diff comparisons here.
...
- 16 commits
- 10 files changed
- 10 contributors
Commits on Jan 23, 2020
-
Simplify signature of remove_piece()
This is a non-functional simplification. Instead of passing the piece type for remove_piece, we can rely on the board. The only exception is en-passant which must be explicitly set because the destination square for the capture is not the same as the piece to remove. Verified also in the Chess960 castling case by running a couple of perft, see the pull request discussion: #2460 STC LLR: 2.94 (-2.94,2.94) [-3.00,1.00] Total: 18624 W: 4147 L: 4070 D: 10407 Ptnml(0-2): 223, 1933, 4945, 1938, 260 http://tests.stockfishchess.org/tests/view/5dfeaa93e70446e17e451163 No functional change
-
This is a non-functional simplification. If we use the "side to move" of the entry instead of the template, one of the classify methods goes away. Furthermore, I've resolved the colors in some of the statements (we're already assuming direction using NORTH), and used stm (side to move) instead of "us," since this is much clearer to me. This is not tested because it is non-functional, only applies building the bitbase and there are no changes to the binary (on my machine). Closes #2485 No functional change
-
Determine opposite colors mathematically
This is a non-functional speed-up: master has to access SquareBB twice while this patch determines opposite_colors just using the values of the squares. It doesn't seem to change the overall speed of bench, but calling opposite_colors(...) 10 Million times: master: 39.4 seconds patch: 11.4 seconds. The only data point I have (other than my own tests), is a quite old failed STC test: LLR: -2.93 (-2.94,2.94) [-1.50,4.50] Total: 24308 W: 5331 L: 5330 D: 13647 Ptnml(0-2): 315, 2577, 6326, 2623, 289 http://tests.stockfishchess.org/tests/view/5e010256c13ac2425c4a9a67 Closes #2498 No functional change
-
Use a std::bitset for KPKBitbase
This is a non-functional simplification. Looks like std::bitset works good for the KPKBitbase. Thanks for Jorg Oster for helping get the speed up (the [] accessor is faster than test()). Speed testing: 10k calls to probe: master 9.8 sec patch 9.8 sec. STC LLR: 2.94 (-2.94,2.94) {-1.50,0.50} Total: 100154 W: 19025 L: 18992 D: 62137 Ptnml(0-2): 1397, 11376, 24572, 11254, 1473 http://tests.stockfishchess.org/tests/view/5e21e601346e35ac603b7d2b Closes #2502 No functional change -
Fixes conflict with tune.h STRINGIFY macro. No functional change
-
Use (strict) greater-than-operator for 'improving'
Currently on a normal bench run in ~0,7% of cases 'improving' is set to true although the static eval isn't improving at all, just keeping equal. It looks like the strict gt-operator is more appropriate here, since it returns to 'improving' its literal meaning without sideffects. STC {-1.00,3.00} failed yellow: https://tests.stockfishchess.org/tests/view/5e1ec38c8fd5f550e4ae1c28 LLR: -2.93 (-2.94,2.94) {-1.00,3.00} Total: 53155 W: 10170 L: 10109 D: 32876 Ptnml(0-2): 863, 6282, 12251, 6283, 892 non-regression LTC passed: https://tests.stockfishchess.org/tests/view/5e1f1c0d8fd5f550e4ae1c41 LLR: 2.98 (-2.94,2.94) {-1.50,0.50} Total: 23961 W: 3114 L: 3018 D: 17829 Ptnml(0-2): 163, 2220, 7114, 2298, 170 CLoses #2496 bench: 4561386 -
Less reduction for escape moves at ttPv nodes
At expected PV nodes or nodes which marked as PV node in the hash table, reduce escape moves even one ply less. STC: LLR: 2.94 (-2.94,2.94) {-1.00,3.00} Total: 31795 W: 6140 L: 5953 D: 19702 Ptnml(0-2): 525, 3625, 7455, 3695, 583 http://tests.stockfishchess.org/tests/view/5e25d77fc3b97aa0d75bc013 LTC: LLR: 2.94 (-2.94,2.94) {0.00,2.00} Total: 43975 W: 5708 L: 5454 D: 32813 Ptnml(0-2): 314, 4012, 13070, 4242, 325 http://tests.stockfishchess.org/tests/view/5e2618c1c3b97aa0d75bc03c Closes #2505 Bench: 4475583 -
This patch greatly increases the endgame penalty for having a trapped rook. Idea was a result of witnessing Stockfish losing some games at CCCC exchanging pieces in the position with a trapped rook which directly lead to a lost endgame. This patch should partially fix such behavior making this penalty high even in deep endgames. Passed STC http://tests.stockfishchess.org/tests/view/5e279d7cc3b97aa0d75bc1c4 LLR: 2.94 (-2.94,2.94) {-1.00,3.00} Total: 8528 W: 1706 L: 1588 D: 5234 Ptnml(0-2): 133, 957, 1985, 1024, 159 Passed LTC http://tests.stockfishchess.org/tests/view/5e27aee4c3b97aa0d75bc1e1 LLR: 2.95 (-2.94,2.94) {0.00,2.00} Total: 88713 W: 11520 L: 11130 D: 66063 Ptnml(0-2): 646, 8170, 26342, 8492, 676 Closes #2510 Bench: 4964462 ---------------------- Comment by Malcolm Campbell: Congrats! I think this might be a common pattern - scores that seem to mainly apply to the midgame are often better with a similar (or at least fairly big) endgame value as well. Maybe there are others eval parameters we can tweak like this...
-
History update for pruned captures
Use a SEE pruned capture move for history updates: this patch collects pruned capture moves also in the failed captures list, so that they get an update in capture history. STC: LLR: 2.95 (-2.94,2.94) {-1.00,3.00} Total: 11124 W: 2222 L: 2089 D: 6813 Ptnml(0-2): 186, 1280, 2506, 1381, 200 http://tests.stockfishchess.org/tests/view/5e28995fc3b97aa0d75bc294 LTC: LLR: 2.94 (-2.94,2.94) {0.00,2.00} Total: 25552 W: 3418 L: 3211 D: 18923 Ptnml(0-2): 168, 2354, 7538, 2490, 200 http://tests.stockfishchess.org/tests/view/5e2943734744cfa4d6af415b Closes #2511 Bench: 4810202
Commits on Jan 25, 2020
-
Double the "RestrictedPiece" bonus for restricted moves targeting occupied squares. STC LLR: 3.58 (-2.94,2.94) {-1.00,3.00} Total: 25504 W: 4887 L: 4697 D: 15920 Ptnml(0-2): 387, 2935, 5947, 3051, 422 https://tests.stockfishchess.org/tests/view/5e2aa15dab2d69d58394f94d LTC LLR: 2.94 (-2.94,2.94) {0.00,2.00} Total: 28572 W: 3826 L: 3621 D: 21125 Ptnml(0-2): 224, 2609, 8403, 2791, 239 https://tests.stockfishchess.org/tests/view/5e2ae7f4ab2d69d58394f9a6 Bench: 4719086
Commits on Jan 27, 2020
-
Instead of computing the initiative bonus on the material score + dynamic score compute it on (material score/2) + dynamic score, Passed STC http://tests.stockfishchess.org/tests/view/5e2c4945ab2d69d58394fa8f LLR: 2.94 (-2.94,2.94) {-1.00,3.00} Total: 39387 W: 7594 L: 7386 D: 24407 Ptnml(0-2): 658, 4519, 9165, 4649, 697 Passed LTC http://tests.stockfishchess.org/tests/view/5e2c85ccab2d69d58394faa7 LLR: 2.95 (-2.94,2.94) {0.00,2.00} Total: 32588 W: 4206 L: 3986 D: 24396 Ptnml(0-2): 244, 2909, 9738, 3111, 253 closes #2516 Bench: 4765486
-
Advise the kernel to use huge pages (Linux)
Align the TT allocation by 2M to make it huge page friendly and advise the kernel to use huge pages. Benchmarks on my i7-8700K (6C/12T) box: (3 runs per bench per config) vanilla (nps) hugepages (nps) avg ================================================================================== bench | 3012490 3024364 3036331 3071052 3067544 3071052 +1.5% bench 16 12 20 | 19237932 19050166 19085315 19266346 19207025 19548758 +1.1% bench 16384 12 20 | 18182313 18371581 18336838 19381275 19738012 19620225 +7.0% On my box, huge pages have a significant perf impact when using a big hash size. They also speed up TT initialization big time: vanilla (s) huge pages (s) speed-up ======================================================================= time stockfish bench 16384 1 1 | 5.37 1.48 3.6x In practice, huge pages with auto-defrag may always be enabled in the system, in which case this patch has no effect. This depends on the values in /sys/kernel/mm/transparent_hugepage/enabled and /sys/kernel/mm/transparent_hugepage/defrag. closes #2463 No functional change -
Dynamic Complexity based on psqt
Adjust initiative score by psqt/2 instead of materialScore/2 which simplifies #2516 Passed STC http://tests.stockfishchess.org/tests/view/5e2e667dab2d69d58394fc73 LLR: 2.94 (-2.94,2.94) {-1.50,0.50} Total: 23198 W: 4506 L: 4353 D: 14339 Ptnml(0-2): 396, 2615, 5380, 2728, 418 Passed LTC http://tests.stockfishchess.org/tests/view/5e2ed75cab2d69d58394fcbf LLR: 2.94 (-2.94,2.94) {-1.50,0.50} Total: 8519 W: 1179 L: 1062 D: 6278 Ptnml(0-2): 50, 775, 2472, 843, 74 closes #2522 Bench: 4684459
Commits on Jan 28, 2020
-
Less NMP if the position was previously in PV.
The intention of the patch is to avoid aggressive null move pruning (NMP) in positions that have previously been found to be important (PV nodes). If we already do not apply NMP for current PV nodes, it makes sense to apply it less often for positions that have previously been PV nodes too. STC: LLR: 2.96 (-2.94,2.94) {-1.00,3.00} Total: 14959 W: 2921 L: 2782 D: 9256 Ptnml(0-2): 254, 1679, 3493, 1762, 282 http://tests.stockfishchess.org/tests/view/5e2f6637ab2d69d58394fcfd LTC: LLR: 2.95 (-2.94,2.94) {0.00,2.00} Total: 6442 W: 899 L: 753 D: 4790 Ptnml(0-2): 42, 549, 1885, 659, 61 http://tests.stockfishchess.org/tests/view/5e2f767bab2d69d58394fd04 closes #2525 Bench: 4725546 -
More bonus for bestMoves on past PV nodes
It looks like it is important to keep past PV (ttPv) nodes as close as possible to current PV nodes. Credits to Mark Tenzer (31m059) & Stefan Geschwentner who first tried ideas on ttPv nodes. STC: https://tests.stockfishchess.org/tests/view/5e2ff5efab2d69d58394fd52 LLR: 2.95 (-2.94,2.94) {-1.00,3.00} Total: 13302 W: 2647 L: 2507 D: 8148 Ptnml(0-2): 237, 1540, 2956, 1632, 260 LTC: https://tests.stockfishchess.org/tests/view/5e2fff38ab2d69d58394fd55 LLR: 2.95 (-2.94,2.94) {0.00,2.00} Total: 15797 W: 2137 L: 1960 D: 11700 Ptnml(0-2): 96, 1443, 4628, 1547, 130 closes #2529 bench: 5545845
Loading
This comparison is taking too long to generate.
Unfortunately it looks like we can’t render this comparison for you right now. It might be too big, or there might be something weird with your repository.
You can try running this command locally to see the comparison on your machine:
git diff c3483fa9a7...71e0b5385e