| 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: SFisGOD
Date: Thu Dec 13 13:35:35 2018 +0100 Timestamp: 1544704535 A combo of parameter tweaks Joint work by SFisGOD, xoroshiro and Chess13234. This combo consists of the following tweaks: Assorted bonuses and penalties by SFisGOD Bishop and Rook PSQT by SFisGOD Tempo Value by xoroshiro Futility pruning by Chess13234 STC: LLR: 2.95 (-2.94,2.94) [0.00,4.00] Total: 9005 W: 2082 L: 1882 D: 5041 Elo +7.72 http://tests.stockfishchess.org/tests/view/5c11628c0ebc5902ba119e90 LTC: LLR: 2.95 (-2.94,2.94) [0.00,4.00] Total: 44207 W: 7451 L: 7157 D: 29599 Elo +2.31 http://tests.stockfishchess.org/tests/view/5c1172a40ebc5902ba119fa3 Bench: 3332460 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: Kurt
Date: Thu Dec 13 13:20:31 2018 +0100 Timestamp: 1544703631 Asymmetrical 8x8 Pawn PSQT STC: LLR: 2.96 (-2.94,2.94) [0.00,5.00] Total: 13323 W: 3015 L: 2818 D: 7490 Elo +5.14 http://tests.stockfishchess.org/tests/view/5c00a2520ebc5902bcedd41b LTC: LLR: 2.96 (-2.94,2.94) [0.00,5.00] Total: 52294 W: 9093 L: 8756 D:34445 http://tests.stockfishchess.org/tests/view/5c00b2c40ebc5902bcedd596 Some obvious followups to this are to further tune this PSQT, or try 8x8 for other pieces. As of now I don't plan on trying this for other pieces as I think the majority of the ELO it brings is for pawns and kings. Looking at the new values, the differences between kingside and queenside are quite significant. I am very hopeful that this a llows SF to understand and plan pawn structures even better than it already does. Cheers! Closes https://github.com/official-stockfish/Stockfish/pull/1839 Bench: 3569243 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: Tue Dec 11 13:47:56 2018 +0100 Timestamp: 1544532476 Changes identified in RENAME/REFORMATTING thread (#1861) I've gone through the RENAME/REFORMATTING thread and changed everything I could find, plus a few more. With this, let's close the previous issue and open another. 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: Sun Dec 9 13:11:13 2018 +0100 Timestamp: 1544357473 Tweak CMH pruning STC: (yellow) LLR: -2.94 (-2.94,2.94) [0.00,5.00] Total: 48919 W: 10625 L: 10517 D: 27777 Elo +0.77 http://tests.stockfishchess.org/tests/view/5c07e6a20ebc5902bcee7395 LTC: LLR: 2.96 (-2.94,2.94) [0.00,5.00] Total: 50360 W: 8424 L: 8102 D: 33834 Elo +2.22 http://tests.stockfishchess.org/tests/view/5c0812450ebc5902bcee76f4 Bench: 3775064 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 Dec 9 12:59:57 2018 +0100 Timestamp: 1544356797 remove extra line. 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 Dec 9 12:59:57 2018 +0100 Timestamp: 1544356797 remove parenthesis. 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 Dec 9 12:59:57 2018 +0100 Timestamp: 1544356797 add paren. 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 Dec 9 12:59:57 2018 +0100 Timestamp: 1544356797 simplify opposite_colors 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: Stéphane Nicolet
Date: Thu Dec 6 15:04:04 2018 +0100 Timestamp: 1544105044 Revert "pseudo_legal() and MOVE_NONE" This reverts commit 33d95482182e459eb033de47a31f142880aa9afb , which crashed in DEBUG mode because of the following assert in position.h ```` Assertion failed: (is_ok(m)), function capture, file ./position.h, line 369. ```` 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: Thu Dec 6 14:40:08 2018 +0100 Timestamp: 1544103608 Simplify Killer Move Penalty STC: LLR: 2.96 (-2.94,2.94) [-3.00,1.00] Total: 20816 W: 4525 L: 4402 D: 11889 Elo +2.05 http://tests.stockfishchess.org/tests/view/5c017cb90ebc5902bcede5b4 LTC: LLR: 2.96 (-2.94,2.94) [-3.00,1.00] Total: 39287 W: 6401 L: 6309 D: 26577 Elo +0.81 http://tests.stockfishchess.org/tests/view/5c01825e0ebc5902bcede686 Bench: 3773021 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 Dec 6 14:08:39 2018 +0100 Timestamp: 1544101719 Simplify time manager in search() Remove the F[] array which I find unhelpful and rename `improvingFactor` to `fallingEval` since larger values indicate a falling eval and more time use. I realise a test was not strictly necessary, but I ran STC [-3,1] just to check there are no foolish errors before creating the pull request: STC: LLR: 2.96 (-2.94,2.94) [-3.00,1.00] Total: 35804 W: 7753 L: 7659 D: 20392 Elo +0.91 http://tests.stockfishchess.org/tests/view/5bef3a0c0ebc595e0ae39c19 It was then suggested to clean the constants around `fallingEval` to make it more clear this is a factor around ~1 that adjusts time up or downwards depending on some conditions. We then ran a double test with this simplification suggestion: STC: LLR: 2.96 (-2.94,2.94) [-3.00,1.00] Total: 68435 W: 14936 L: 14906 D: 38593 Elo +0.15 http://tests.stockfishchess.org/tests/view/5c02c56b0ebc5902bcee0184 LTC: LLR: 2.95 (-2.94,2.94) [-3.00,1.00] Total: 37258 W: 6324 L: 6230 D: 24704 Elo +0.88 http://tests.stockfishchess.org/tests/view/5c030a520ebc5902bcee0a32 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 Dec 6 14:02:29 2018 +0100 Timestamp: 1544101349 pseudo_legal() and MOVE_NONE MOVE_NONE is represented as SQ_A1 to SQ_A1 which is never pseudo_legal. STC LLR: 2.95 (-2.94,2.94) [-3.00,1.00] Total: 38807 W: 8363 L: 8275 D: 22169 Elo +0.79 http://tests.stockfishchess.org/tests/view/5c05f11d0ebc5902bcee4c86 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: Sun Dec 2 20:18:51 2018 +0100 Timestamp: 1543778331 Introduce concept of double pawn protection. Exclude doubly protected by pawns squares when calculating attackers on king ring. Idea of this patch is not to count attackers if they attack only squares that are protected by two pawns. STC LLR: 2.95 (-2.94,2.94) [0.00,5.00] Total: 70040 W: 15476 L: 15002 D: 39562 Elo +2.35 http://tests.stockfishchess.org/tests/view/5c0354860ebc5902bcee1106 LTC LLR: 2.96 (-2.94,2.94) [0.00,5.00] Total: 16530 W: 2795 L: 2607 D: 11128 Elo +3.95 http://tests.stockfishchess.org/tests/view/5c0385080ebc5902bcee14b5 This is third king safety patch in recent times so we probably need retuning of king safety parameters. Bench: 3057978 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: Sat Dec 1 11:28:10 2018 +0100 Timestamp: 1543660090 Penalize refuted killers in continuation history Currently we apply a penalty in continuation history for refuted TT moves. We can use the same idea to also penalize refuted killer moves in continuation history. STC: http://tests.stockfishchess.org/tests/view/5c00ccbd0ebc5902bcedd768 LLR: 2.96 (-2.94,2.94) [0.00,5.00] Total: 54366 W: 12086 L: 11687 D: 30593 Elo +2.55 LTC: http://tests.stockfishchess.org/tests/view/5c0107880ebc5902bceddc9c LLR: 2.96 (-2.94,2.94) [0.00,5.00] Total: 25457 W: 4302 L: 4078 D: 17077 Elo +3.06 Bench: 3419069 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: ElbertoOne
Date: Sat Dec 1 10:29:10 2018 +0100 Timestamp: 1543656550 Remove Overload bonus Compensate by giving the Hanging bonus to weak doubly-attacked non pawn enemies pieces. STC: http://tests.stockfishchess.org/tests/view/5bfd53c40ebc5902bced9237 LLR: 2.96 (-2.94,2.94) [-3.00,1.00] Total: 62107 W: 13664 L: 13622 D: 34821 Elo +0.23 LTC: http://tests.stockfishchess.org/tests/view/5bfd74700ebc5902bced9618 LLR: 2.96 (-2.94,2.94) [-3.00,1.00] Total: 86406 W: 14381 L: 14365 D: 57660 Elo +0.06 A possible follow up would be to tune the hanging bonus and/or try to simplify the hanging bonus condition. Bench: 3810849 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: Stéphane Nicolet
Date: Thu Nov 29 16:17:23 2018 +0100 Timestamp: 1543504643 Restore development version 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: Stéphane Nicolet
Date: Thu Nov 29 15:45:26 2018 +0100 Timestamp: 1543502726 Stockfish 10 Official release version of Stockfish 10. This is also the 10th anniversary version of the Stockfish project, which started exactly ten years ago! I wish to extend a huge thank you to all contributors and authors in our amazing community :-) Bench: 3939338 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: Stéphane Nicolet
Date: Thu Nov 29 15:15:43 2018 +0100 Timestamp: 1543500943 Update list of authors 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: Sebastian Buchwald
Date: Thu Nov 29 15:01:54 2018 +0100 Timestamp: 1543500114 Use emplace_back() in TB code The patch was tested for correctness by running bench with and without the change against current master, and the tablebase hit numbers were found to be identical in both cases. See the pull request comments for details: https://github.com/official-stockfish/Stockfish/pull/1826 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: 31m059
Date: Tue Nov 27 08:53:14 2018 +0100 Timestamp: 1543305194 Simplify casting extension On November 16th, before the removal of the depth condition, I tried revising castling extensions to only handle castling moves, rather than moves that change castling rights generally. It appeared to be a slight Elo gain at STC but insufficient to pass [0, 4] (+0.5 Elo), but what I overlooked was that it made pos.can_castle(us) irrelevant and should have been a simplification. Recent discussion with @Chess13234 and Michael Chaly (@Vizvezdenec) inspired me to take a second look, and the simplification continues to pass when rebased on the current master. This replaces two conditions with one, because type_of(move) == CASTLING implies pos.can_castle(Us), allowing us to remove the latter condition. STC: LLR: 2.95 (-2.94,2.94) [-3.00,1.00] Total: 110948 W: 24209 L: 24263 D: 62476 Elo -0.17 http://tests.stockfishchess.org/tests/view/5bf8f65c0ebc5902bced3a63 LTC: LLR: 2.95 (-2.94,2.94) [-3.00,1.00] Total: 88283 W: 14681 L: 14668 D: 58934 Elo +0.05 http://tests.stockfishchess.org/tests/view/5bf994a60ebc5902bced4349 Bench: 3939338 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: Steinar H. Gunderson
Date: Tue Nov 27 08:39:23 2018 +0100 Timestamp: 1543304363 Turn on MADV_RANDOM for Syzygy mmaps (on Unix-like builds) When running on a cloud VM (n1-highcpu-96) with several NVMe SSDs and some non-SSDs for tablebases, I noticed that the average SSD request size was more than 256 kB. This doesn't make a lot of sense for Syzygy tablebases, which have a block size of 32 bytes and very low locality. Seemingly, the tablebase access patterns during probing make the OS, at least Linux, think that readahead is advantageous; normally, it gives up doing readahead if there are too many misses, but it doesn't, perhaps due to the fairly high overall hit rates. (It seems the kernel cannot distinguish between reading a block that was paged in because the userspace wanted it explicitly, and one that was read as part of readahead.) Setting MADV_RANDOM effectively turns off readahead, which causes the request size to drop to 4 kB. In the aforemented cloud VM test, this roughly tripled the amount of I/O requests that were able to go through, while reducing the total traffic from 2.8 GB/sec to 56 MB/sec (moving the bottleneck to the non-SSDs; it seems the SSDs could have sustained many more requests). Closes https://github.com/official-stockfish/Stockfish/pull/1829 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: Jörg Oster
Date: Sun Nov 25 11:27:40 2018 +0100 Timestamp: 1543141660 Qsearch simplification. (#1828) Don't do an extra TT update in case of a fail-high, but simply break off the moves loop and let the TT update at the end of qsearch do this job. Same workflow/logic as in our main search function now. Tested for no regression to be on the safe side. STC LLR: 2.96 (-2.94,2.94) [-3.00,1.00] Total: 30237 W: 6665 L: 6560 D: 17012 Elo +1.21 http://tests.stockfishchess.org/tests/view/5bf928e80ebc5902bced3f3a LTC LLR: 2.95 (-2.94,2.94) [-3.00,1.00] Total: 51067 W: 8625 L: 8553 D: 33889 Elo +0.49 http://tests.stockfishchess.org/tests/view/5bf937180ebc5902bced3fdc 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: Sat Nov 24 02:14:18 2018 +0100 Timestamp: 1543022058 Reintroduce tropism to kingdanger Tropism in kingdanger was simplified away in this pull request #1821. This patch reintroduces tropism in kingdanger with using quadratic scaling. Passed STC http://tests.stockfishchess.org/tests/view/5bf7c1b10ebc5902bced1f8f LLR: 2.96 (-2.94,2.94) [0.00,5.00] Total: 52803 W: 11835 L: 11442 D: 29526 Elo +2.59 Passed LTC http://tests.stockfishchess.org/tests/view/5bf816e90ebc5902bced24f1 LLR: 2.96 (-2.94,2.94) [0.00,5.00] Total: 17204 W: 2988 L: 2795 D: 11421 Elo +3.90 How do we continue from there? I've recently tried to introduce tropism difference term in kingdanger which passed STC 6 times but failed LTC all the time. Maybe using quadratic scaling for it will also be helpful. Bench 4041387 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: 31m059
Date: Sat Nov 24 02:09:35 2018 +0100 Timestamp: 1543021775 Remove the tropism term from kingDanger A recent LTC tuning session by @candirufish showed this term decreasing significantly. It appears that it can be removed altogether without significant Elo loss. I also thank @GuardianRM, whose attempt to remove tropism from king danger inspired this one. After this PR is merged, my next step will be to attempt to tune the coefficients of this new, simplified kingDanger calculation. STC: LLR: 2.95 (-2.94,2.94) [-3.00,1.00] Total: 12518 W: 2795 L: 2656 D: 7067 Elo +3.86 http://tests.stockfishchess.org/tests/view/5befadda0ebc595e0ae3a289 LTC: LLR: 2.96 (-2.94,2.94) [-3.00,1.00] Total: 164771 W: 26463 L: 26566 D: 111742 Elo -0.22 http://tests.stockfishchess.org/tests/view/5befcca70ebc595e0ae3a343 LTC 2, rebased on Stockfish 10 beta: LLR: 2.96 (-2.94,2.94) [-3.00,1.00] Total: 75226 W: 12563 L: 12529 D: 50134 Elo +0.16 http://tests.stockfishchess.org/tests/view/5bf2e8910ebc5902bcecb919 Bench: 3412071 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: Tue Nov 20 08:00:19 2018 +0100 Timestamp: 1542697219 Force time check on TB probe in search. Because of aggressive time management and optimistic assumptions about move overhead, it's still very easy to get Stockfish to forfeit on time when we hit an endgame and have Syzygy EGTB on a spinning drive. The latency from serving a few thousand EGTB probes (~10ms each), of which there can currently be up to 4000 outstanding before a time check, will easily overwhelm the default Move Overhead of 30ms. This problem was first raised by Gian-Carlo Pascutto and some solutions and improvements were discussed in the following pull requests: https://github.com/official-stockfish/Stockfish/pull/1471 https://github.com/official-stockfish/Stockfish/pull/1623 https://github.com/official-stockfish/Stockfish/pull/1783 This patch is a minimal change proposed by Marco Costalba to lower the impact of the bug. We now force a check of the clock right after each tablebase read. No functional change. see source |