| Windows x64 for Haswell CPUs Windows x64 for modern computers Windows x64 Windows 32 Linux x64 for Haswell CPUs Linux x64 for modern computers Linux x64 | Author: mstembera
Date: Thu Jan 10 16:36:59 2019 +0100 Timestamp: 1547134619 Minor cleanup to recent 'Flag critical search tree in hash table' patch No functional change |
| Windows x64 for Haswell CPUs Windows x64 for modern computers Windows x64 Windows 32 Linux x64 for Haswell CPUs Linux x64 for modern computers Linux x64 | Author: Joost VandeVondele
Date: Wed Jan 9 16:57:24 2019 +0100 Timestamp: 1547049444 Small improvements to the CI infrastructure - avoid inlining for the debug testing so that suppressions work - provide more output for triggered errors No functional change. |
| Windows x64 for Haswell CPUs Windows x64 for modern computers Windows x64 Windows 32 Linux x64 for Haswell CPUs Linux x64 for modern computers Linux x64 | Author: MJZ1977
Date: Wed Jan 9 15:05:33 2019 +0100 Timestamp: 1547042733 Flag critical search tree in hash table Introducing new concept, saving principal lines into the transposition table to generate a "critical search tree" which we can reuse later for intelligent pruning/extension decisions. For instance in this patch we just reduce reduction for these lines. But a lot of other ideas are possible. To go further : tune some parameters, how to add or remove lines from the critical search tree, how to use these lines in search choices, etc. STC : LLR: 2.94 (-2.94,2.94) [0.50,4.50] Total: 59761 W: 13321 L: 12863 D: 33577 Elo +2.66 http://tests.stockfishchess.org/tests/view/5c34da5d0ebc596a450c53d3 LTC : LLR: 2.96 (-2.94,2.94) [0.00,3.50] Total: 26826 W: 4439 L: 4191 D: 18196 Elo +3.21 http://tests.stockfishchess.org/tests/view/5c35ceb00ebc596a450c65b2 Special thanks to Miguel Lahoz for his help in transposition table in/out. Bench: 3399866 |
| Windows x64 for Haswell CPUs Windows x64 for modern computers Windows x64 Windows 32 Linux x64 for Haswell CPUs Linux x64 for modern computers Linux x64 | Author: Miguel Lahoz
Date: Sun Jan 6 16:02:31 2019 +0100 Timestamp: 1546786951 Introduce Multi-Cut This was inspired after reading about [Multi-Cut](https://www.chessprogramming.org/Multi-Cut). We now do non-singular cut node pruning. The idea is to prune when we have a "backup plan" in case our expected fail high node does not fail high on the ttMove. For singular extensions, we do a search on all other moves but the ttMove. If this fails high on our original beta, this means that both the ttMove, as well as at least one other move was proven to fail high on a lower depth search. We then assume that one of these moves will work on a higher depth and prune. STC: LLR: 2.96 (-2.94,2.94) [0.50,4.50] Total: 72952 W: 16104 L: 15583 D: 41265 Elo +2.48 http://tests.stockfishchess.org/tests/view/5c3119640ebc596a450c0be5 LTC: LLR: 2.95 (-2.94,2.94) [0.00,3.50] Total: 27103 W: 4564 L: 4314 D: 18225 Elo +3.20 http://tests.stockfishchess.org/tests/view/5c3184c00ebc596a450c1662 Bench: 3145487 |
| Windows x64 for Haswell CPUs Windows x64 for modern computers Windows x64 Windows 32 Linux x64 for Haswell CPUs Linux x64 for modern computers Linux x64 | Author: Joost VandeVondele
Date: Fri Jan 4 15:36:39 2019 +0100 Timestamp: 1546612599 Check tablebase files This addresses partially issue #1911 in that it documents in our Readme the command that users can use to verifying the md5sum of their downloaded tablebase files. Additionally, a quick check of the file size (the size of each tablebase file modulo 64 is 16 as pointed out by @syzygy1) has been implemented at launch time in Stockfish. Closes https://github.com/official-stockfish/Stockfish/pull/1927 and https://github.com/official-stockfish/Stockfish/issues/1911 No functional change. |
| Windows x64 for Haswell CPUs Windows x64 for modern computers Windows x64 Windows 32 Linux x64 for Haswell CPUs Linux x64 for modern computers Linux x64 | Author: Marco Costalba
Date: Fri Jan 4 14:23:14 2019 +0100 Timestamp: 1546608194 Delay castling legality check Delay legality check of castling moves at search time, just before making the move, as is the standard with all the other move types. This should avoid an useless and not trivial legality check when the castling is then not tried later. For instance due to a previous cut-off. The patch is also a big simplification and allows to entirely remove generate_castling() Bench changes due to a different move sequence out of MovePicker. STC: LLR: 2.95 (-2.94,2.94) [-3.00,1.00] Total: 45073 W: 9918 L: 9843 D: 25312 Elo +0.58 http://tests.stockfishchess.org/tests/view/5c2f176f0ebc596a450bdfb3 LTC: LLR: 3.15 (-2.94,2.94) [-3.00,1.00] Total: 10156 W: 1707 L: 1560 D: 6889 Elo +5.03 http://tests.stockfishchess.org/tests/view/5c2e7dfd0ebc596a450bcdf4 Verified with perft both in standard and Chess960 cases. Closes https://github.com/official-stockfish/Stockfish/pull/1929 Bench: 3559104 |
| Windows x64 for Haswell CPUs Windows x64 for modern computers Windows x64 Windows 32 Linux x64 for Haswell CPUs Linux x64 for modern computers Linux x64 | Author: Marco Costalba
Date: Tue Jan 1 14:10:26 2019 +0100 Timestamp: 1546348226 Assorted trivial cleanups (#1894) To address https://github.com/official-stockfish/Stockfish/issues/1862 No functional change. |
| Windows x64 for Haswell CPUs Windows x64 for modern computers Windows x64 Windows 32 Linux x64 for Haswell CPUs Linux x64 for modern computers Linux x64 | Author: protonspring
Date: Tue Jan 1 13:38:09 2019 +0100 Timestamp: 1546346289 Remove openFiles in pawns. (#1917) A single popcount in evaluate.cpp replaces all openFiles stuff in pawns. It doesn't seem to affect performance at all. STC LLR: 2.96 (-2.94,2.94) [-3.00,1.00] Total: 28103 W: 6134 L: 6025 D: 15944 Elo +1.35 http://tests.stockfishchess.org/tests/view/5b7d70a20ebc5902bdbb1999 No functional change. |
| Windows x64 for Haswell CPUs Windows x64 for modern computers Windows x64 Windows 32 Linux x64 for Haswell CPUs Linux x64 for modern computers Linux x64 | Author: protonspring
Date: Tue Jan 1 13:36:56 2019 +0100 Timestamp: 1546346216 Remove "Any" predicate filter (#1914) This custom predicate filter creates an unnecessary abstraction layer, but doesn't make the code any more readable. The code is clear enough without it. No functional change. |
| Windows x64 for Haswell CPUs Windows x64 for modern computers Windows x64 Windows 32 Linux x64 for Haswell CPUs Linux x64 for modern computers Linux x64 | Author: protonspring
Date: Tue Jan 1 13:35:53 2019 +0100 Timestamp: 1546346153 Remove as useless micro-optimization in pawns generation (#1915) The extra condition is used as a shortcut to skip the following 3 assignments: ```C++ Bitboard b1 = shift<UpRight>(pawnsOn7) & enemies; Bitboard b2 = shift<UpLeft >(pawnsOn7) & enemies; Bitboard b3 = shift<Up >(pawnsOn7) & emptySquares; ``` In case of EVASION with no target on 8th rank (the common case), we end up performing the 3 statements for nothing because b1 = b2 = b3 = 0. But this is just a small micro-optimization and the condition is quite confusing, so just remove it and prefer a readable code instead. STC LLR: 2.95 (-2.94,2.94) [-3.00,1.00] Total: 78020 W: 16978 L: 16967 D: 44075 Elo +0.05 http://tests.stockfishchess.org/tests/view/5c27b4fe0ebc5902ba135bb0 No functional change. |
| Windows x64 for Haswell CPUs Windows x64 for modern computers Windows x64 Windows 32 Linux x64 for Haswell CPUs Linux x64 for modern computers Linux x64 | Author: erbsenzaehler
Date: Sat Dec 29 11:49:16 2018 +0100 Timestamp: 1546080556 Improve the Readme I tried to improve the Readme because many people in my local chess club do not understand some of the UCO options properly. Starting point of this was Cfish's Readme by Ronald de Man, some internet resources and the Stockfish code itself. Closes https://github.com/official-stockfish/Stockfish/pull/1898 Initial commit by user @erbsenzaehler, with help from users Adrian Petrescu, @alayan-stk-2 and Elvin Liu. No functional change Co-Authored-By: Alayan-stk-2 <> Co-Authored-By: Adrian Petrescu <> Co-Authored-By: Elvin Liu <> |
| Windows x64 for Haswell CPUs Windows x64 for modern computers Windows x64 Windows 32 Linux x64 for Haswell CPUs Linux x64 for modern computers Linux x64 | Author: 31m059
Date: Thu Dec 27 21:38:31 2018 +0100 Timestamp: 1545943111 Always initialize and evaluate king safety Recent tests by @xoto10, @Vizvezdenec, and myself seemed to hint that Elo could be gained by expanding the number of cases where king safety is applied. Several users (@Spliffjiffer, @Vizvezdenec) have anticipated benefits specifically in evaluation of tactics. It appears that we actually do not need to restrict the cases in which we initialize and evaluate king safety at all: initializing and evaluating it in every position appears roughly Elo-neutral at STC and possibly a substantial Elo gain at LTC. Any explanation for this scaling is, at this point, conjecture. Assuming it is not due to chance, my hypothesis is that initialization of king safety in all positions is a mild slowdown, offset by an Elo gain of evaluating king safety in all positions. At STC this produces Elo gains and losses that offset each other, while at longer time control the slowdown is much less important, leaving only the Elo gain. It probably helps SF to explore king attacks much earlier in search with high numbers of enemy pieces concentrating but not essentially attacking king ring. Thanks to @xoto10 and @Vizvezdenec for helping run my LTC! Closes https://github.com/official-stockfish/Stockfish/pull/1906 STC: LLR: 2.95 (-2.94,2.94) [-3.00,1.00] Total: 35432 W: 7815 L: 7721 D: 19896 Elo +0.92 http://tests.stockfishchess.org/tests/view/5c24779d0ebc5902ba131b26 LTC: LLR: 2.95 (-2.94,2.94) [-3.00,1.00] Total: 12887 W: 2217 L: 2084 D: 8586 Elo +3.59 http://tests.stockfishchess.org/tests/view/5c25049a0ebc5902ba132586 Bench: 3163951 ------------------ How to continue from there? * Next step will be to tune all the king danger terms once more after that :-) |
| Windows x64 for Haswell CPUs Windows x64 for modern computers Windows x64 Windows 32 Linux x64 for Haswell CPUs Linux x64 for modern computers Linux x64 | Author: noobpwnftw
Date: Mon Dec 24 11:24:29 2018 +0100 Timestamp: 1545647069 Simplify SYSTEM_LOGICAL_PROCESSOR_INFORMATION_EX loop (#1892) When iterating through 'SYSTEM_LOGICAL_PROCESSOR_INFORMATION_EX' structure, do not use structure member beyond known size. API is guaranteed to provide us at lease one element upon successful, and no element in the structure can have a zero size. No functional change. |
| Windows x64 for Haswell CPUs Windows x64 for modern computers Windows x64 Windows 32 Linux x64 for Haswell CPUs Linux x64 for modern computers Linux x64 | Author: noobpwnftw
Date: Mon Dec 24 11:20:14 2018 +0100 Timestamp: 1545646814 Fix crash in best_group() (#1891) This pull request fixes a rare crashing bug on Windows inside our NUMA code, first reported by Dann Corbit in the following forum thread (thanks!): https://groups.google.com/forum/?fromgroups=#!topic/fishcooking/gA6aoMEuOwg The fix is to not use structure member beyond known size when iterating through 'SYSTEM_LOGICAL_PROCESSOR_INFORMATION_EX' structure. We note that the Microsoft API is guaranteed to provide us at least one element upon successful, and no element in the structure can have a zero size. No functional change. |
| Windows x64 for Haswell CPUs Windows x64 for modern computers Windows x64 Windows 32 Linux x64 for Haswell CPUs Linux x64 for modern computers Linux x64 | Author: Joost VandeVondele
Date: Mon Dec 24 11:06:47 2018 +0100 Timestamp: 1545646007 Extend stack to ss-5, and remove conditions The `&& (ss-1)->killers[0] ` conditions are there seemingly to protect accessing ss-5. This is unneeded and not so intuitive (as the killer is checked for equality with currentMove, and that one is non-zero once we're high enough in the stack, this protects access to ss-5). We can just extend the stack from ss-4 to ss-5, so we can call update_continuation_histories(ss-1, ..) always in search. This goes a bit further than #1881 and addresses a comment in #1878. passed STC: http://tests.stockfishchess.org/tests/view/5c1aa8d50ebc5902ba127ad0 LLR: 3.12 (-2.94,2.94) [-3.00,1.00] Total: 53515 W: 11734 L: 11666 D: 30115 Elo +0.44 passed LTC: http://tests.stockfishchess.org/tests/view/5c1b272c0ebc5902ba12858d LLR: 2.95 (-2.94,2.94) [-3.00,1.00] Total: 140176 W: 23123 L: 23192 D: 93861 Elo -0.17 Bench: 3451321 |
| Windows x64 for Haswell CPUs Windows x64 for modern computers Windows x64 Windows 32 Linux x64 for Haswell CPUs Linux x64 for modern computers Linux x64 | Author: protonspring
Date: Mon Dec 24 10:44:38 2018 +0100 Timestamp: 1545644678 Improve endgame KBN vs K (#1877) Even when playing without endgame table bases, this particular endgame should be a win 100% of the time when Stockfish is given a KRBK position, assuming there are enough moves remaining in the FEN to finish the game without hitting the 50 move rule. PROBLEM: The issue with master here is that the PushClose difference per square is 20, however, the difference in squares for the PushToCorners array is usually less. Thus, the engine prefers to move the kings closer together rather than pushing the weak king to the correct corner. What happens is if the weak king is in a safe corner, SF still prefers pushing the kings together. Occasionally, the strong king traps the weak king in the safe corner. It takes a while for SF to figure it out, but often draws the game by the 50 move rule (on shorter time controls). This patch increases the PushToCorners values to correct this problem. We also added an assert to catch any overflow problem if anybody would want to increase the array values again in the future. It was tested in a couple of matches starting with random KRBK positions and showed increased winning rates, see https://github.com/official-stockfish/Stockfish/pull/1877 No functional change |
| Windows x64 for Haswell CPUs Windows x64 for modern computers Windows x64 Windows 32 Linux x64 for Haswell CPUs Linux x64 for modern computers Linux x64 | Author: erbsenzaehler
Date: Sun Dec 23 18:17:44 2018 +0100 Timestamp: 1545585464 Update our continuous integration machinery (#1889) * Update our continuous integration machinery Ubuntu 16.04 can now be used with travis. Updating all the other stuff when there. Invoking the lld linker seems to save 5 minutes with clang on linux. No functional change. * fix |
| Windows x64 for Haswell CPUs Windows x64 for modern computers Windows x64 Windows 32 Linux x64 for Haswell CPUs Linux x64 for modern computers Linux x64 | Author: mstembera
Date: Sun Dec 23 16:10:07 2018 +0100 Timestamp: 1545577807 Use a bit less code to calculate hashfull() (#1830) * Use a bit less code to calculate hashfull(). Change post increment to preincrement as is more standard in the rest of stockfish. Scale result so we report 100% instead of 99.9% when completely full. No functional change. |
| Windows x64 for Haswell CPUs Windows x64 for modern computers Windows x64 Windows 32 Linux x64 for Haswell CPUs Linux x64 for modern computers Linux x64 | Author: mstembera
Date: Sun Dec 23 16:09:03 2018 +0100 Timestamp: 1545577743 Turn on random access for Syzygy files in Windows (#1840) * This is the Windows version of https://github.com/official-stockfish/Stockfish/pull/1829 No functional change. |
| Windows x64 for Haswell CPUs Windows x64 for modern computers Windows x64 Windows 32 Linux x64 for Haswell CPUs Linux x64 for modern computers Linux x64 | Author: protonspring
Date: Sun Dec 23 16:05:24 2018 +0100 Timestamp: 1545577524 Simplify generate_castling (#1885) Although this is a compile-time constant, we stick the castlingSide into a CastlingRight, then pull it out again. This seems unecessarily complex. No functional change. |
| Windows x64 for Haswell CPUs Windows x64 for modern computers Windows x64 Windows 32 Linux x64 for Haswell CPUs Linux x64 for modern computers Linux x64 | Author: protonspring
Date: Thu Dec 20 10:47:18 2018 +0100 Timestamp: 1545299238 Simplify KBNK endgame implementation We do not need to change the winnerKSq variable, so we can simplify a little bit the logic of the code by changing only the loserKSq variable when it is necessary. Also consolidate and clarify comments. See the pull request thread for a proof that the code is correct: https://github.com/official-stockfish/Stockfish/pull/1854 No functional change |
| Windows x64 for Haswell CPUs Windows x64 for modern computers Windows x64 Windows 32 Linux x64 for Haswell CPUs Linux x64 for modern computers Linux x64 | Author: Guenther Demetz
Date: Tue Dec 18 09:38:06 2018 +0100 Timestamp: 1545122286 Tweak main killer penalty Apply refuted main killer penalty also on early TT cut-offs. This makes penalty logic more consistent with the logic at normal search. Failed STC: http://tests.stockfishchess.org/tests/view/5c121e730ebc5902ba11aad8 LLR: -2.95 (-2.94,2.94) [0.00,5.00] Total: 72193 W: 15848 L: 15625 D: 40720 Elo +1.07 Passed LTC: http://tests.stockfishchess.org/tests/view/5c17b1b10ebc5902ba123c24 LLR: 2.95 (-2.94,2.94) [0.00,5.00] Total: 35073 W: 5886 L: 5625 D: 23562 Elo +2.59 Closes https://github.com/official-stockfish/Stockfish/pull/1878 bench: 3393939 |
| Windows x64 for Haswell CPUs Windows x64 for modern computers Windows x64 Windows 32 Linux x64 for Haswell CPUs Linux x64 for modern computers Linux x64 | Author: mstembera
Date: Tue Dec 18 08:51:25 2018 +0100 Timestamp: 1545119485 New voting formula for threads We now use a quadratic formula during the vote for threads when deciding on which thread to pick a move from. time control 5+0.05, with 8 threads: LLR: 2.95 (-2.94,2.94) [0.00,5.00] Total: 20202 W: 4031 L: 3813 D: 12358 Elo +3.75 http://tests.stockfishchess.org/tests/view/5c16c8e60ebc5902ba1223e2 time control 20+0.2, with 8 threads: LLR: 2.96 (-2.94,2.94) [0.00,5.00] Total: 14330 W: 2290 L: 2115 D: 9925 Elo +4.24 http://tests.stockfishchess.org/tests/view/5c16efca0ebc5902ba122993 20000 games match at time control 5+0.05, with 31 threads: ELO: 5.63 +-2.8 (95%) LOS: 100.0% Total: 20000 W: 3539 L: 3215 D: 13246 Elo +5.63 http://tests.stockfishchess.org/tests/view/5c16f07a0ebc5902ba122a20 Closes https://github.com/official-stockfish/Stockfish/pull/1876 No functional change (in simple thread mode) |
| Windows x64 for Haswell CPUs Windows x64 for modern computers Windows x64 Windows 32 Linux x64 for Haswell CPUs Linux x64 for modern computers Linux x64 | Author: 31m059
Date: Sun Dec 16 10:04:49 2018 +0100 Timestamp: 1544951089 Use stronglyProtected ~stronglyProtected is quite similar to ~attackedBy[Them][PAWN] & ~attackedBy2[Them], the only difference appears to be that the former includes squares attacked twice by both sides. The resulting logic is simpler, and the change appears to be at least Elo-neutral at both STC and LTC. STC: LLR: 2.95 (-2.94,2.94) [-3.00,1.00] Total: 35924 W: 7978 L: 7885 D: 20061 Elo +0.90 http://tests.stockfishchess.org/tests/view/5c14a5c00ebc5902ba11ed72 LTC: LLR: 2.96 (-2.94,2.94) [-3.00,1.00] Total: 37078 W: 6125 L: 6030 D: 24923 Elo +0.89 http://tests.stockfishchess.org/tests/view/5c14ae880ebc5902ba11eed8 Bench: 3646542 |
| Windows x64 for Haswell CPUs Windows x64 for modern computers Windows x64 Windows 32 Linux x64 for Haswell CPUs Linux x64 for modern computers Linux x64 | Author: Alain SAVARD
Date: Sun Dec 16 09:57:43 2018 +0100 Timestamp: 1544950663 Refactor king ring calculation Compute the "double protection by pawns" expression only once in initialize(), instead of once for each piece in the piece loop. Passed STC http://tests.stockfishchess.org/tests/view/5c1506380ebc5902ba11f3b4 LLR: 2.95 (-2.94,2.94) [-3.00,1.00] Total: 9494 W: 2191 L: 2045 D: 5258 Elo +5.34 Inspired by Nick Pelling's test http://tests.stockfishchess.org/tests/view/5c144d110ebc5902ba11e4af and an older test of mine http://tests.stockfishchess.org/tests/view/5c0402810ebc5902bcee1fc8 Non functional change. |