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: VoyagerOne
Date: Thu Jul 11 11:59:36 2019 +0200 Timestamp: 1562839176 Tweak capture scoring formula STC: LLR: 2.96 (-2.94,2.94) [0.00,4.00] Total: 20556 W: 4685 L: 4438 D: 11433 Elo +4.17 http://tests.stockfishchess.org/tests/view/5d25d26e0ebc5925cf0d0b4a LTC: LLR: 2.95 (-2.94,2.94) [0.00,4.00] Total: 14856 W: 2649 L: 2446 D: 9761 Elo +4.75 http://tests.stockfishchess.org/tests/view/5d25d8b20ebc5925cf0d0c6d bench: 3206912 see source |
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: xoto10
Date: Thu Jul 11 11:51:27 2019 +0200 Timestamp: 1562838687 Combo of statscore divisor and pawn psqt changes Passed STC 10+0.1 th 1: LLR: 2.96 (-2.94,2.94) [0.00,4.00] Total: 13282 W: 3100 L: 2881 D: 7301 Elo +5.73 http://tests.stockfishchess.org/tests/view/5d21132e0ebc5925cf0c81f4 Passed LTC 60+0.6 th 1: LLR: 2.95 (-2.94,2.94) [0.00,4.00] Total: 44243 W: 7768 L: 7468 D: 29007 Elo +2.36 http://tests.stockfishchess.org/tests/view/5d2119050ebc5925cf0c832b Bench 3705891 see source |
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 Jul 11 11:42:08 2019 +0200 Timestamp: 1562838128 Use score instead of array to evaluate shelter This is a non-functional simplification. Instead of an array of values, just use a Score. STC LLR: 2.95 (-2.94,2.94) [-3.00,1.00] Total: 16309 W: 3673 L: 3541 D: 9095 Elo +2.81 http://tests.stockfishchess.org/tests/view/5d24f3b80ebc5925cf0ceb5b No functional change see source |
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: Daniel Axtens
Date: Thu Jul 11 11:30:09 2019 +0200 Timestamp: 1562837409 Enable popcount and prefetch for ppc-64 PowerPC has had popcount instructions for a long time, at least as far back as POWER5 (released 2004). Enable them via a gcc builtin. Using a gcc builtin has the added bonus that if compiled for a processor that lacks a hardware instruction, gcc will include a software popcount implementation that does not use the instruction. It might be slower than the table lookups (or it might be faster) but it will certainly work. So this isn't going to break anything. On my POWER8 VM, this leads to a ~4.27% speedup. Fir prefetch, the gcc builtin generates a 'dcbt' instruction, which is supported at least as far back as the G5 (2002) and POWER4 (2001). This leads to a ~5% speedup on my POWER8 VM. No functional change see source |
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 Jul 1 14:07:54 2019 +0200 Timestamp: 1561982874 Smoothly change playing strength with skill level. (#2142) The current skill levels (1-20) allow for adjusting playing strengths, but do so in big steps (e.g. level 10 vs level 11 is a ~143 Elo jump at STC). Since the 'Skill Level' input can already be a floating point number, this patch uses the fractional part of the input to provide the user with fine control, allowing for varying the playing strength essentially continuously. The implementation internally still uses integer skill levels (needed since they pick Depths), but non-deterministically rounds up or down the used skill level such that the average integer skill corresponds to the input floating point one. As expected, intermediate (fractional) skill levels yield intermediate playing strenghts. Tested at STC, playing level 10 against levels between 10 and 11 for 10000 games level 10.25 ELO: 24.26 +-6.2 level 10.5 ELO: 67.51 +-6.3 level 10.75 ELO: 98.52 +-6.4 level 11 ELO: 143.65 +-6.7 http://tests.stockfishchess.org/tests/view/5cd9c6b40ebc5925cf056791 http://tests.stockfishchess.org/tests/view/5cd9d22b0ebc5925cf056989 http://tests.stockfishchess.org/tests/view/5cd9cf610ebc5925cf056906 http://tests.stockfishchess.org/tests/view/5cd9d2490ebc5925cf05698e No functional change. see source |
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 Jul 1 14:07:23 2019 +0200 Timestamp: 1561982843 Introduce coordination between searching threads (#2204) this patch improves threading performance by introducing some coordination between threads. The observation is that threading is an area where a lot of Elo can potentially be gained: https://github.com/glinscott/fishtest/wiki/UsefulData#elo-from-threading At STC, 8 threads gain roughly 320 Elo, vs sequential at the same time, however, loses 66 Elo against a single thread with 8x more time. This 66 Elo should be partially recoverable with improved threading. To improve threading, this patch introduces some LMR at nodes that are already being searched by other threads. This requires some coordination between threads, avoiding however synchronisation. To do so, threads leave a trail of breadcrumbs to mark the nodes they are searching. These breadcrumbs are stored in a small hash table, which is only probed at low plies (currently ply < 8). A couple of variants of this patch passed both STC and LTC threaded tests. I picked the simpler, more robust version. I expect that further tests can find further improvements. STC (5+0.05 @ 8 threads): LLR: 2.95 (-2.94,2.94) [0.50,4.50] Total: 26209 W: 5359 L: 5079 D: 15771 Elo +3.71 http://tests.stockfishchess.org/tests/view/5d0a9b030ebc5925cf0a8e6f LTC (20+0.2 @ 8 threads): LLR: 2.96 (-2.94,2.94) [0.00,3.50] Total: 34832 W: 5650 L: 5382 D: 23800 Elo +2.67 http://tests.stockfishchess.org/tests/view/5d0c67a20ebc5925cf0aafa7 other passed/tested variants: http://tests.stockfishchess.org/tests/view/5d0a9b030ebc5925cf0a8e6f http://tests.stockfishchess.org/tests/view/5d0c67ca0ebc5925cf0aafa9 http://tests.stockfishchess.org/tests/view/5d0c67810ebc5925cf0aafa3 http://tests.stockfishchess.org/tests/view/5d0958ca0ebc5925cf0a74c6 For the sequential code there is no change in bench, and an earlier version of this patch passed a non-regression test. STC (10+0.1 @ 1 thread) LLR: 2.96 (-2.94,2.94) [-3.00,1.00] Total: 10471 W: 2364 L: 2220 D: 5887 Elo +4.78 http://tests.stockfishchess.org/tests/view/5d087ee20ebc5925cf0a6381 passed the additional non-regression tests at 2 and 4 threads 20+0.2 TC. The code was rebased on master prior to testing. 2 threads: LLR: 2.95 (-2.94,2.94) [-3.00,1.00] Total: 218863 W: 40927 L: 41153 D: 136783 Elo -0.36 http://tests.stockfishchess.org/tests/view/5d18c6c30ebc5925cf0b9566 4threads: LLR: 2.96 (-2.94,2.94) [-3.00,1.00] Total: 16839 W: 3017 L: 2889 D: 10933 Elo +2.64 http://tests.stockfishchess.org/tests/view/5d18c6ea0ebc5925cf0b9568 No functional change. see source |
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 Jun 30 15:22:37 2019 +0200 Timestamp: 1561900957 Move storm special condition to UnblockedStorm array (#2210) This is a functional simplification. Looks like we can accommodate the special initialization of Value in evaluate_shelter in the UnblockedStorm array. STC LLR: 2.95 (-2.94,2.94) [-3.00,1.00] Total: 32483 W: 7422 L: 7322 D: 17739 Elo +1.07 http://tests.stockfishchess.org/tests/view/5d14c5f80ebc5925cf0b48da LTC LLR: 2.96 (-2.94,2.94) [-3.00,1.00] Total: 35361 W: 6139 L: 6042 D: 23180 Elo +0.95 http://tests.stockfishchess.org/tests/view/5d14d69c0ebc5925cf0b4bd0 Bench 3596270 see source |
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: Jörg Oster
Date: Sun Jun 30 15:16:20 2019 +0200 Timestamp: 1561900580 Try to get a more precise bench time (#2211) Initialization of larger hash sizes can take some time. Don't include this time in the bench by resetting the timer after Search::clear(). Also move 'ucinewgame' command down in the list, so that it is processed after the configuration of Threads and Hash size. No functional change. see source |
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 Jun 27 09:46:36 2019 +0200 Timestamp: 1561621596 Bonus for double attacks on unsupported pawns This is a functional change that rewards double attacks on an unsupported pawns. STC (non-functional difference) LLR: 2.96 (-2.94,2.94) [0.50,4.50] Total: 83276 W: 18981 L: 18398 D: 45897 Elo +2.43 http://tests.stockfishchess.org/tests/view/5d0970500ebc5925cf0a77d4 LTC (incomplete looping version) LLR: 0.50 (-2.94,2.94) [0.00,3.50] Total: 82999 W: 14244 L: 13978 D: 54777 Elo +1.11 http://tests.stockfishchess.org/tests/view/5d0a8d480ebc5925cf0a8d58 LTC (completed non-looping version). LLR: 2.96 (-2.94,2.94) [0.00,3.50] Total: 223381 W: 38323 L: 37512 D: 147546 Elo +1.26 http://tests.stockfishchess.org/tests/view/5d0e80510ebc5925cf0ad320 Closes https://github.com/official-stockfish/Stockfish/pull/2205 Bench 3633546 ---------------------------------- Comments by Alain SAVARD: interesting result ! I would have expected that search would resolve such positions correctly on the very next move. This is not a very common pattern, and when it happens, it will quickly disappear. So I'm quite surprised that it passed LTC. I would be even more surprised if this would resist a simplification. Anyway, let's try to imagine a few cases. a) If you have White d5 f5 against Black e6, and White to move last move by Black was probably a capture on e6 and White is about to recapture on e6 b) If you have White d5 f5 against e6, and Black to move last move by White was possibly a capture on d5 or f5 or the pawn on e6 was pinned or could not move for some reason. and white wants to blast open the position and just pushed d4-d5 or f4-f5 Some possible follow-ups a) Motif is so rare that the popcount() can be safely replaced with a bool() But this would not pass a SPRT[0,4], So try a simplification with bool() and also without the & ~theirAttacks b) If it works, we probably can simply have this in the loop if (lever) score += S(0, 20); c) remove all this and tweak something in search for pawn captures (priority, SEE, extension,..) see source |
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: Vizvezdenec
Date: Thu Jun 27 09:26:08 2019 +0200 Timestamp: 1561620368 Introduce attacks on space area This patch introduces a small malus for every square in our space mask that is attacked by enemy. The value of the malus is completely arbitrary and is something we can tweak, also maybe we can gain some elo with tweaking space threshold after this addition. Passed STC http://tests.stockfishchess.org/tests/view/5d10ce590ebc5925cf0af30b LLR: 2.96 (-2.94,2.94) [0.50,4.50] Total: 7082 W: 1648 L: 1449 D: 3985 Elo +9.77 Passed LTC http://tests.stockfishchess.org/tests/view/5d10d2d80ebc5925cf0af3fd LLR: 2.96 (-2.94,2.94) [0.00,3.50] Total: 79494 W: 13727 L: 13324 D: 52443 Elo +1.76 Closes https://github.com/official-stockfish/Stockfish/pull/2207 bench 3516460 see source |
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: Sergei Ivanov
Date: Thu Jun 27 09:05:03 2019 +0200 Timestamp: 1561619103 Do not define increment operators on Value, Depth and Direction These operators are never used and do not make sense for these types. No functional change. see source |
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: joergoster
Date: Thu Jun 27 08:57:59 2019 +0200 Timestamp: 1561618679 Improve multiPV mode Skip all moves during the Non-PV (zero-window) search which will be searched as PV moves later anyways. We also wake sure the moves will be reported to the GUI despite they're not being searched — some GUIs may get confused otherwise, and it would unnecessarily complicate the code. Tested with MultiPV=4 STC http://tests.stockfishchess.org/tests/view/5ce7137c0ebc5925cf070d69 LLR: 2.95 (-2.94,2.94) [0.50,4.50] Total: 8233 W: 3708 L: 3424 D: 1101 Elo +11.99 LTC http://tests.stockfishchess.org/tests/view/5ce798d60ebc5925cf071d17 LLR: 2.95 (-2.94,2.94) [0.00,3.50] Total: 7369 W: 3197 L: 2911 D: 1261 Elo +13.49 Closes https://github.com/official-stockfish/Stockfish/pull/2163 No functional change. (in single PV mode) see source |
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: Sat Jun 22 09:57:07 2019 +0200 Timestamp: 1561190227 Make the debug counters thread safe. needed to use them in a threaded run. No functional change. see source |
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: Vizvezdenec
Date: Fri Jun 21 10:05:50 2019 +0200 Timestamp: 1561104350 Rewrite "More bonus for free passed pawn" -removes wideUnsafeSquares bitboard -removes a couple of bitboard operations -removes one if operator -updates comments so they actually represent what this part of code is doing now. passed non-regression STC http://tests.stockfishchess.org/tests/view/5d0c1ae50ebc5925cf0aa8db LLR: 2.96 (-2.94,2.94) [-3.00,1.00] Total: 16892 W: 3865 L: 3733 D: 9294 Elo +2.72 No functional change see source |
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: Vizvezdenec
Date: Thu Jun 20 16:52:02 2019 +0200 Timestamp: 1561042322 More bonus for free passed pawn Give even more bonus to passed pawn if adjacent squares to its path are not attacked. passed STC http://tests.stockfishchess.org/tests/view/5d08c9b10ebc5925cf0a6630 LLR: 2.95 (-2.94,2.94) [0.50,4.50] Total: 175197 W: 39859 L: 38816 D: 96522 Elo +2.07 passed LTC http://tests.stockfishchess.org/tests/view/5d0ab8240ebc5925cf0a8fe4 LLR: 2.95 (-2.94,2.94) [0.00,3.50] Total: 92928 W: 16124 L: 15682 D: 61122 Elo +1.65 Bench: 3398333 see source |
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: Thu Jun 20 16:39:22 2019 +0200 Timestamp: 1561041562 Change multi-cut pruning condition Use comparison of eval with beta to predict potential cutNodes. This allows multi-cut pruning to also prune possibly mislabeled Pv and NonPv nodes. STC: LLR: 2.95 (-2.94,2.94) [0.50,4.50] Total: 54305 W: 12302 L: 11867 D: 30136 Elo +2.78 http://tests.stockfishchess.org/tests/view/5d048ba50ebc5925cf0a15e8 LTC: LLR: 2.95 (-2.94,2.94) [0.00,3.50] Total: 189512 W: 32620 L: 31904 D: 124988 Elo +1.31 http://tests.stockfishchess.org/tests/view/5d04bf740ebc5925cf0a17f0 Normally I would think such changes are risky, specially for PvNodes, but after trying a few other versions, it seems this version is more sound than I initially thought. Aside from this, a small funtional change is made to return singularBeta instead of beta to be more consistent with the fail-soft logic used in other parts of search. ============================= How to continue from there ? We could try to audit other parts of the search where the "cutNode" variable is used, and try to use dynamic info based on heuristic eval rather than on this variable, to check if the idea behind this patch could also be applied successfuly. Bench: 3503788 see source |
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: VoyagerOne
Date: Thu Jun 20 16:22:45 2019 +0200 Timestamp: 1561040565 QuietPick Speed-up Non-functional speedup: no need to generate, score, or sort quiet moves if SkipQuiet is true. Thanks to @mstembera for his suggestion. STC: LLR: 2.95 (-2.94,2.94) [0.00,4.00] Total: 27910 W: 6406 L: 6129 D: 15375 Elo +3.45 http://tests.stockfishchess.org/tests/view/5d07e0920ebc5925cf0a58a8 Closes https://github.com/official-stockfish/Stockfish/pull/2194 No functional change see source |
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: Thu Jun 20 16:15:57 2019 +0200 Timestamp: 1561040157 Fix progress issue with shuffling extensions Fixes issues #2126 and #2189 where no progress in rootDepth is made for particular fens: 8/8/3P3k/8/1p6/8/1P6/1K3n2 b - - 0 1 8/1r1rp1k1/1b1pPp2/2pP1Pp1/1pP3Pp/pP5P/P5K1/8 w - - 79 46 the cause are the shuffle extensions. Upon closer analysis, it appears that in these cases a shuffle extension is made for every node searched, and progess can not be made. This patch implements a fix, namely to limit the number of extensions relative to the number of nodes searched. The ratio employed is 1/4, which fixes the issues seen so far, but it is a heuristic, and I expect that certain positions might require an even smaller fraction. The patch was tested as a bug fix and passed: STC: LLR: 2.95 (-2.94,2.94) [-3.00,1.00] Total: 56601 W: 12633 L: 12581 D: 31387 Elo +0.32 http://tests.stockfishchess.org/tests/view/5d02b37a0ebc5925cf09f6da LTC: LLR: 2.96 (-2.94,2.94) [-3.00,1.00] Total: 52042 W: 8907 L: 8837 D: 34298 Elo +0.47 http://tests.stockfishchess.org/tests/view/5d0319420ebc5925cf09fe57 Furthermore, to confirm that the shuffle extension in this form indeed still brings Elo, one more test at VLTC was performed: VLTC: LLR: 2.96 (-2.94,2.94) [0.00,3.50] Total: 142022 W: 20963 L: 20435 D: 100624 Elo +1.29 http://tests.stockfishchess.org/tests/view/5d03630d0ebc5925cf0a011a Bench: 3961247 see source |
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: syzygy1
Date: Thu Jun 20 16:09:40 2019 +0200 Timestamp: 1561039780 Partial revert of "Assorted trivial cleanups 5/2019". Since root_probe() and root_probe_wdl() do not reset all tbRank values if they fail, it is necessary to do this in rank_root_move(). This fixes issue #2196. Alternatively, the loop could be moved into both root_probe() and root_probe_wdl(). No functional change see source |
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: VoyagerOne
Date: Fri Jun 14 19:59:17 2019 +0200 Timestamp: 1560535157 Simplify SEE Pruning (#2191) Simplify SEE Pruning Note this should also be a speedup... If givesCheck is extended we know (except for DC) that it will have a positive SEE. So this new logic will be triggered before doing another expensive SEE function. STC: LLR: 2.95 (-2.94,2.94) [-3.00,1.00] Total: 24429 W: 5484 L: 5368 D: 13577 Elo +1.65 http://tests.stockfishchess.org/tests/view/5cffbccd0ebc5925cf09a154 LTC: LLR: 2.95 (-2.94,2.94) [-3.00,1.00] Total: 28428 W: 4873 L: 4765 D: 18790 Elo +1.32 http://tests.stockfishchess.org/tests/view/5d0015f60ebc5925cf09acb1 Bench: 3897263 see source |
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: Fri Jun 14 08:22:02 2019 +0200 Timestamp: 1560493322 Remove backmost_sq (#2190) This is a non-functional simplification. backmost_sq and frontmost_sq are redundant. It seems quite clear to always use frontmost_sq and use the correct color. Non functional change. see source |
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: Stefan Geschwentner
Date: Fri Jun 14 07:36:42 2019 +0200 Timestamp: 1560490602 Increase pawns cache (#2187) Increase size of the pawns table by the factor 8. This decreases the number of recalculations of pawn structure information significantly (at least at LTC). I have done measurements for different depths and pawn cache sizes. First are given the number of pawn entry calculations are done (in parentheses is the frequency that a call to probe triggers a pawn entry calculation). The delta% are the percentage of less done pawn entry calculations in comparison to master VSTC: bench 1 1 12 STC: bench 8 1 16 LTC: bench 64 1 20 VLTC: bench 512 1 24 VSTC STC LTC VLTC master 82218(6%) 548935(6%) 2415422(7%) 9548071(7%) pawncache*2 79859(6%) 492943(5%) 2084794(6%) 8275206(6%) pawncache*4 78551(6%) 458758(5%) 1827770(5%) 7112531(5%) pawncache*8 77963(6%) 439421(4%) 1649169(5%) 6128652(4%) delta%(p2-m) -2.9% -10.2% -13.7% -13.3% delta%(p4-m) -4.5% -16.4% -24.3% -25.5% delta%(p8-m) -5.2% -20.0% -31.7% -35.8% STC: (non-regression test because at STC the effect is smaller than at LTC) LLR: 2.96 (-2.94,2.94) [-3.00,1.00] Total: 22767 W: 5160 L: 5040 D: 12567 Elo +1.83 http://tests.stockfishchess.org/tests/view/5d00f6040ebc5925cf09c3e2 LTC: LLR: 2.94 (-2.94,2.94) [0.00,4.00] Total: 26340 W: 4524 L: 4286 D: 17530 Elo +3.14 http://tests.stockfishchess.org/tests/view/5d00a3810ebc5925cf09ba16 No functional change. see source |
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: VoyagerOne
Date: Mon Jun 10 00:26:47 2019 +0200 Timestamp: 1560119207 No DC prune in QS (#2185) Don't prune discover checks in qSearch STC: LLR: 2.96 (-2.94,2.94) [0.50,4.50] Total: 23176 W: 5320 L: 5039 D: 12817 Elo +4.21 http://tests.stockfishchess.org/tests/view/5cfbc9350ebc5925cf094ab3 LTC: LLR: 2.95 (-2.94,2.94) [0.00,3.50] Total: 128428 W: 22222 L: 21679 D: 84527 Elo +1.47 http://tests.stockfishchess.org/tests/view/5cfbf0b70ebc5925cf094ebc Bench: 3883245 see source |
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: Sun Jun 9 14:57:08 2019 +0200 Timestamp: 1560085028 Assorted trivial cleanups 5/2019 No functional change. bench: 4178282 see source |
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: Stefan Geschwentner
Date: Sun Jun 9 14:34:51 2019 +0200 Timestamp: 1560083691 Remove depth condition for ttPv (#2166) Currently PV nodes with a depth <= 4 were ignored for ttPv. Now remove this constraint and use all PV nodes. STC: LLR: 2.96 (-2.94,2.94) [-3.00,1.00] Total: 52209 W: 11755 L: 11694 D: 28760 Elo +0.41 http://tests.stockfishchess.org/tests/view/5cebc2d30ebc5925cf07b93a LTC: LLR: 2.96 (-2.94,2.94) [-3.00,1.00] Total: 20874 W: 3689 L: 3568 D: 13617 Elo +2.01 http://tests.stockfishchess.org/tests/view/5cec01fc0ebc5925cf07c62d see source |