2020-01-07 13:35:47 -07:00
|
|
|
# List of authors for Stockfish, as of January 7, 2020
|
2014-06-20 19:35:09 -06:00
|
|
|
|
2018-02-17 17:51:35 -07:00
|
|
|
Tord Romstad (romstad)
|
2016-11-04 07:39:24 -06:00
|
|
|
Marco Costalba (mcostalba)
|
|
|
|
|
Joona Kiiski (zamar)
|
|
|
|
|
Gary Linscott (glinscott)
|
2018-02-17 17:51:35 -07:00
|
|
|
|
2018-11-29 07:15:43 -07:00
|
|
|
Aditya (absimaldata)
|
2018-12-29 03:49:10 -07:00
|
|
|
Adrian Petrescu (apetresc)
|
2018-02-17 17:51:35 -07:00
|
|
|
Ajith Chandy Jose (ajithcj)
|
|
|
|
|
Alain Savard (Rocky640)
|
Adjust aspiration window with eval
This patch changes the base aspiration window size depending on the absolute
value of the previous iteration score, increasing it away from zero. This
stems from the observation that the further away from zero, the more likely
the evaluation is to change significantly with more depth. Conversely, a
tighter aspiration window is more efficient when close to zero.
A beneficial side-effect is that analysis of won positions without a quick
mate is less prone to waste nodes in repeated fail-high that change the eval
by tiny steps.
STC:
LLR: 2.96 (-2.94,2.94) [0.50,4.50]
Total: 60102 W: 13327 L: 12868 D: 33907
http://tests.stockfishchess.org/tests/view/5d9a70d40ebc5902b6cf39ba
LTC:
LLR: 2.95 (-2.94,2.94) [0.00,3.50]
Total: 155553 W: 25745 L: 25141 D: 104667
http://tests.stockfishchess.org/tests/view/5d9a7ca30ebc5902b6cf4028
Future work : the values used in this patch were only a reasonable guess.
Further testing should unveil more optimal values. However, the aspiration
window is rather tight with a minimum of 21 internal units, so discrete
integers put a practical limitation to such tweaking.
More exotic experiments around the aspiration window parameters could also
be tried, but efficient conditions to adjust the base aspiration window size
or allow it to not be centered on the current evaluation are not obvious.
The aspiration window increases after a fail-high or a fail-low is another
avenue to explore for potential enhancements.
Bench: 4043748
2019-10-07 11:02:33 -06:00
|
|
|
Alayan Feh (Alayan-stk-2)
|
2014-06-20 19:35:09 -06:00
|
|
|
Alexander Kure
|
2019-08-14 14:15:41 -06:00
|
|
|
Alexander Pagel (Lolligerhans)
|
2018-02-17 17:51:35 -07:00
|
|
|
Ali AlZhrani (Cooffe)
|
|
|
|
|
Andrew Grant (AndyGrant)
|
|
|
|
|
Andrey Neporada (nepal)
|
2014-06-20 19:35:09 -06:00
|
|
|
Andy Duplain
|
2018-02-17 17:51:35 -07:00
|
|
|
Aram Tumanian (atumanian)
|
|
|
|
|
Arjun Temurnikar
|
2014-06-20 19:35:09 -06:00
|
|
|
Auguste Pop
|
|
|
|
|
Balint Pfliegel
|
2018-02-17 17:51:35 -07:00
|
|
|
Ben Koshy (BKSpurgeon)
|
|
|
|
|
Bill Henry (VoyagerOne)
|
2020-01-07 13:35:47 -07:00
|
|
|
Bojun Guo (noobpwnftw, Nooby)
|
2018-02-17 17:51:35 -07:00
|
|
|
braich
|
2020-01-07 13:35:47 -07:00
|
|
|
Brian Sheppard (SapphireBrand, briansheppard-toast)
|
2018-02-17 17:51:35 -07:00
|
|
|
Bryan Cross (crossbr)
|
2020-01-07 13:35:47 -07:00
|
|
|
candirufish
|
|
|
|
|
Chess13234
|
2018-02-17 17:51:35 -07:00
|
|
|
Chris Cain (ceebo)
|
2020-01-07 13:35:47 -07:00
|
|
|
Dan Schmidt (dfannius)
|
|
|
|
|
Daniel Axtens (daxtens)
|
2018-02-17 17:51:35 -07:00
|
|
|
Daniel Dugovic (ddugovic)
|
2014-06-20 19:35:09 -06:00
|
|
|
Dariusz Orzechowski
|
2018-02-17 17:51:35 -07:00
|
|
|
David Zar
|
|
|
|
|
Daylen Yang (daylen)
|
2016-01-02 02:43:25 -07:00
|
|
|
DiscanX
|
2020-01-07 13:35:47 -07:00
|
|
|
double-beep
|
|
|
|
|
Eduardo Cáceres (eduherminio)
|
|
|
|
|
Eelco de Groot (KingDefender)
|
2018-12-29 03:49:10 -07:00
|
|
|
Elvin Liu (solarlight2)
|
2018-02-17 17:51:35 -07:00
|
|
|
erbsenzaehler
|
2016-01-02 02:43:25 -07:00
|
|
|
Ernesto Gatti
|
2018-02-17 17:51:35 -07:00
|
|
|
Fabian Beuke (madnight)
|
|
|
|
|
Fabian Fichter (ianfab)
|
|
|
|
|
fanon
|
|
|
|
|
Fauzi Akram Dabat (FauziAkram)
|
|
|
|
|
Felix Wittmann
|
|
|
|
|
gamander
|
|
|
|
|
gguliash
|
|
|
|
|
Gian-Carlo Pascutto (gcp)
|
|
|
|
|
Gontran Lemaire (gonlem)
|
|
|
|
|
Goodkov Vasiliy Aleksandrovich (goodkov)
|
2014-06-20 19:35:09 -06:00
|
|
|
Gregor Cramer
|
2018-08-12 10:40:03 -06:00
|
|
|
GuardianRM
|
2018-02-17 17:51:35 -07:00
|
|
|
Günther Demetz (pb00067, pb00068)
|
|
|
|
|
Guy Vreuls (gvreuls)
|
|
|
|
|
Henri Wiechers
|
2016-11-04 07:39:24 -06:00
|
|
|
Hiraoka Takuya (HiraokaTakuya)
|
2018-02-17 17:51:35 -07:00
|
|
|
homoSapiensSapiens
|
2014-06-20 19:35:09 -06:00
|
|
|
Hongzhi Cheng
|
2018-02-17 17:51:35 -07:00
|
|
|
Ivan Ivec (IIvec)
|
|
|
|
|
Jacques B. (Timshel)
|
|
|
|
|
Jan Ondruš (hxim)
|
2018-11-29 07:15:43 -07:00
|
|
|
Jared Kish (Kurtbusch)
|
2018-02-17 17:51:35 -07:00
|
|
|
Jarrod Torriero (DU-jdto)
|
2020-01-07 13:35:47 -07:00
|
|
|
Jean Gauthier (OuaisBla)
|
2018-09-03 04:46:05 -06:00
|
|
|
Jean-Francois Romang (jromang)
|
2020-01-07 13:35:47 -07:00
|
|
|
Jekaa
|
2018-02-17 17:51:35 -07:00
|
|
|
Jerry Donald Watson (jerrydonaldwatson)
|
|
|
|
|
Jonathan Calovski (Mysseno)
|
2019-10-31 23:58:11 -06:00
|
|
|
Jonathan Dumale (SFisGOD)
|
2018-02-17 17:51:35 -07:00
|
|
|
Joost VandeVondele (vondele)
|
|
|
|
|
Jörg Oster (joergoster)
|
Using a S-curve for the optimism measure
Add a logarithmic term in the optimism computation, increase
the maximal optimism and lower the contempt offset.
This increases the dynamics of the optimism aspects, giving
a boost for balanced positions without skewing too much on
unbalanced positions (but this version will enter panic mode
faster than previous master when behind, trying to draw faster
when slightly behind). This helps, since optimism is in general
a good thing, for instance at LTC, but too high optimism
rapidly contaminates play.
passed STC:
LLR: 2.96 (-2.94,2.94) [0.00,5.00]
Total: 159343 W: 34489 L: 33588 D: 91266
http://tests.stockfishchess.org/tests/view/5a8db9340ebc590297cc85b6
passed LTC:
LLR: 2.97 (-2.94,2.94) [0.00,5.00]
Total: 47491 W: 7825 L: 7517 D: 32149
http://tests.stockfishchess.org/tests/view/5a9456a80ebc590297cc8a89
It must be mentioned that a version of the PR with contempt 0
did not pass STC [0,5]. The version in the patch, which uses
default contempt 12, was found to be as strong as current master
on different matches against SF7 and SF8, both at STC and LTC.
One drawback maybe is that it raises the draw rate in self-play
from 56% to 59%, giving a little bit less sensitivity for SF
developpers to find evaluation improvements by selfplay tests
in fishtest.
Possible further work:
• tune the values accurately, while keeping in mind the drawrate issue
• check whether it is possible to remove linear and offset term
• try to simplify the S-shape curve
Bench: 5934644
2018-03-04 08:50:19 -07:00
|
|
|
Joseph Ellis (jhellis3)
|
2018-02-17 17:51:35 -07:00
|
|
|
Joseph R. Prostko
|
|
|
|
|
jundery
|
2020-01-07 13:35:47 -07:00
|
|
|
Justin Blanchard (UncombedCoconut)
|
2014-06-20 19:35:09 -06:00
|
|
|
Kelly Wilson
|
2018-02-17 17:51:35 -07:00
|
|
|
Ken Takusagawa
|
|
|
|
|
kinderchocolate
|
|
|
|
|
Kiran Panditrao (Krgp)
|
2014-06-20 19:35:09 -06:00
|
|
|
Kojirion
|
2018-11-29 07:15:43 -07:00
|
|
|
Leonardo Ljubičić (ICCF World Champion)
|
2018-02-17 17:51:35 -07:00
|
|
|
Leonid Pechenik (lp--)
|
2020-01-07 13:35:47 -07:00
|
|
|
Linus Arver (listx)
|
2018-02-17 17:51:35 -07:00
|
|
|
loco-loco
|
2018-12-01 02:28:10 -07:00
|
|
|
Lub van den Berg (ElbertoOne)
|
2018-02-17 17:51:35 -07:00
|
|
|
Luca Brivio (lucabrivio)
|
|
|
|
|
Lucas Braesch (lucasart)
|
|
|
|
|
Lyudmil Antonov (lantonov)
|
2019-08-14 14:15:41 -06:00
|
|
|
Maciej Żenczykowski (zenczykowski)
|
Smarter time management near stop limit
This patch makes Stockfish search same depth again if > 60% of optimum time is
already used, instead of trying the next iteration. The idea is that the next
iteration will generally take about the same amount of time as has already been
used in total. When we are likely to begin the last iteration, as judged by total
time taken so far > 0.6 * optimum time, searching the last depth again instead of
increasing the depth still helps the other threads in lazy SMP and prepares better
move ordering for the next moves.
STC :
LLR: 2.95 (-2.94,2.94) {-1.00,3.00}
Total: 13436 W: 2695 L: 2558 D: 8183
Ptnml(0-2): 222, 1538, 3087, 1611, 253
https://tests.stockfishchess.org/tests/view/5e1618a761fe5f83a67dd964
LTC :
LLR: 2.94 (-2.94,2.94) {0.00,2.00}
Total: 32160 W: 4261 L: 4047 D: 23852
Ptnml(0-2): 211, 2988, 9448, 3135, 247
https://tests.stockfishchess.org/tests/view/5e162ca061fe5f83a67dd96d
The code was revised as suggested by @vondele for multithreading:
STC (8 threads):
LLR: 2.95 (-2.94,2.94) {0.00,2.00}
Total: 16640 W: 2049 L: 1885 D: 12706
Ptnml(0-2): 119, 1369, 5158, 1557, 108
https://tests.stockfishchess.org/tests/view/5e19826a2cc590e03c3c2f52
LTC (8 threads):
LLR: 2.95 (-2.94,2.94) {-1.00,3.00}
Total: 16536 W: 2758 L: 2629 D: 11149
Ptnml(0-2): 182, 1758, 4296, 1802, 224
https://tests.stockfishchess.org/tests/view/5e18b91a27dab692fcf9a140
Thanks to those discussing Stockfish lazy SMP on fishcooking which made me
try this, and to @vondele for suggestions and doing related tests.
See full discussion in the pull request thread:
https://github.com/official-stockfish/Stockfish/pull/2482
Bench: 4586187
2020-01-11 15:10:22 -07:00
|
|
|
Malcolm Campbell (xoto10)
|
Introduce Overload
This patch applies a S(10, 5) bonus for every square that is:
- Occupied by an enemy piece which is not a pawn
- Attacked exactly once by our pieces
- Defended exactly once by enemy pieces
The idea is that these pieces must be defended. Their defenders have
dramatically limited mobility, and they are vulnerable to our future
attack.
As with connectivity, there are probably many more tests to be run in
this area. In particular:
- I believe @snicolet's queen overload tests have demonstrated a potential
need for a queen overload bonus above and beyond this one; however, the
conditions for "overload" in this patch are different (excluding pieces
we attack twice). My next test after this is (hopefully) merged will be
to intersect the Bitboard I define here with the enemy's queen attacks and
attempt to give additional bonus.
- Perhaps we should exclude pieces attacked by pawns--can pawns really be
overloaded? Should they have the same weight, or less? This didn't work
with a previous version, but it could work with this one.
- More generally, different pieces may need more or less bonus. We could
change bonuses based on what type of enemy piece is being overloaded, what
type of friendly piece is attacking, and/or what type of piece is being
defended by the overloaded piece and attacked by us, or any intersection
of these three. For example, here attacked/defended pawns are excluded,
but they're not totally worthless targets, and could be added again with
a smaller bonus.
- This list is by no means exhaustive.
STC:
LLR: 2.96 (-2.94,2.94) [0.00,5.00]
Total: 17439 W: 3599 L: 3390 D: 10450
http://tests.stockfishchess.org/tests/view/5ac78a2e0ebc59435923735e
LTC:
LLR: 2.95 (-2.94,2.94) [0.00,5.00]
Total: 43304 W: 6533 L: 6256 D: 30515
http://tests.stockfishchess.org/tests/view/5ac7a1d80ebc59435923736f
Closes https://github.com/official-stockfish/Stockfish/pull/1533
Bench: 5248871
----------------
This is my first time opening a PR, so I apologize if there are errors.
There are too many people to thank since I submitted my first test just
over a month ago. Thank you all for the warm welcome and here is to more
green patches!
In particular, I would like to thank:
- @crossbr, whose comment in a FishCooking thread first inspired me to
consider the overloading of pieces other than queens,
- @snicolet, whose queen overload tests inspired this one and served as
the base of my first overload attempts,
- @protonspring, whose connectivity tests inspired this one and who provided
much of the feedback needed to take this from red to green,
- @vondele, who kindly corrected me when I submitted a bad LTC test,
- @Rocky640, who has helped me over and over again in the past month.
Thank you all!
2018-04-06 17:20:48 -06:00
|
|
|
Mark Tenzer (31m059)
|
2020-01-07 13:35:47 -07:00
|
|
|
marotear
|
|
|
|
|
Matthew Lai (matthewlai)
|
|
|
|
|
Matthew Sullivan (Matt14916)
|
|
|
|
|
Michael An (man)
|
2018-02-17 17:51:35 -07:00
|
|
|
Michael Byrne (MichaelB7)
|
2018-09-03 04:46:05 -06:00
|
|
|
Michael Chaly (Vizvezdenec)
|
2020-01-07 13:35:47 -07:00
|
|
|
Michael Stembera (mstembera)
|
|
|
|
|
Michael Whiteley (protonspring)
|
2018-02-17 17:51:35 -07:00
|
|
|
Michel Van den Bergh (vdbergh)
|
Use single value for KingProtector.
After some recent big tuning session, the values for King Protector were
simplified to only be used on minor pieces. This patch tries to further
simplify by just using a single value, since current S(6,5) and S(5,6)
are close to each other. The value S(6,6) ended up passing, although
S(5,5) was also tried and failed STC.
STC
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 14261 W: 3288 L: 3151 D: 7822
http://tests.stockfishchess.org/tests/view/5b4ccdf50ebc5902bdb77f65
LTC
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 19606 W: 3396 L: 3273 D: 12937
http://tests.stockfishchess.org/tests/view/5b4ce4280ebc5902bdb7803b
Bench: 5448998
2018-07-16 10:51:43 -06:00
|
|
|
Miguel Lahoz (miguel-l)
|
2018-03-13 01:10:59 -06:00
|
|
|
Mikael Bäckman (mbootsector)
|
2020-01-07 13:35:47 -07:00
|
|
|
Mira
|
2018-02-17 17:51:35 -07:00
|
|
|
Miroslav Fontán (Hexik)
|
2018-04-30 23:12:17 -06:00
|
|
|
Moez Jellouli (MJZ1977)
|
2018-02-17 17:51:35 -07:00
|
|
|
Mohammed Li (tthsqe12)
|
|
|
|
|
Nathan Rugg (nmrugg)
|
2019-09-21 01:59:32 -06:00
|
|
|
Nick Pelling (nickpelling)
|
2018-02-17 17:51:35 -07:00
|
|
|
Nicklas Persson (NicklasPersson)
|
|
|
|
|
Niklas Fiekas (niklasf)
|
2020-01-07 13:35:47 -07:00
|
|
|
Nikolay Kostov (NikolayIT)
|
2018-09-03 04:46:05 -06:00
|
|
|
Ondrej Mosnáček (WOnder93)
|
2016-01-02 02:43:25 -07:00
|
|
|
Oskar Werkelin Ahlin
|
2014-06-20 19:35:09 -06:00
|
|
|
Pablo Vazquez
|
2020-01-07 13:35:47 -07:00
|
|
|
Panthee
|
2016-01-02 02:43:25 -07:00
|
|
|
Pascal Romaret
|
2018-02-17 17:51:35 -07:00
|
|
|
Pasquale Pigazzini (ppigazzini)
|
|
|
|
|
Patrick Jansen (mibere)
|
|
|
|
|
pellanda
|
2018-09-04 05:36:42 -06:00
|
|
|
Peter Zsifkovits (CoffeeOne)
|
2018-02-17 17:51:35 -07:00
|
|
|
Ralph Stößer (Ralph Stoesser)
|
2014-06-20 19:35:09 -06:00
|
|
|
Raminder Singh
|
2018-02-17 17:51:35 -07:00
|
|
|
renouve
|
|
|
|
|
Reuven Peleg
|
2014-06-20 19:35:09 -06:00
|
|
|
Richard Lloyd
|
2018-02-17 17:51:35 -07:00
|
|
|
Rodrigo Exterckötter Tjäder
|
2018-09-03 04:46:05 -06:00
|
|
|
Ron Britvich (Britvich)
|
2020-01-07 13:35:47 -07:00
|
|
|
Ronald de Man (syzygy1, syzygy)
|
2018-02-17 17:51:35 -07:00
|
|
|
Ryan Schmitt
|
2014-06-20 19:35:09 -06:00
|
|
|
Ryan Takker
|
2020-01-07 13:35:47 -07:00
|
|
|
Sami Kiminki (skiminki)
|
2018-11-29 07:15:43 -07:00
|
|
|
Sebastian Buchwald (UniQP)
|
2018-02-17 17:51:35 -07:00
|
|
|
Sergei Antonov (saproj)
|
2020-01-07 13:35:47 -07:00
|
|
|
Sergei Ivanov (svivanov72)
|
2016-01-02 02:43:25 -07:00
|
|
|
sf-x
|
2020-01-07 13:35:47 -07:00
|
|
|
Shane Booth (shane31)
|
2018-02-17 17:51:35 -07:00
|
|
|
Stefan Geschwentner (locutus2)
|
|
|
|
|
Stefano Cardanobile (Stefano80)
|
2020-01-07 13:35:47 -07:00
|
|
|
Steinar Gunderson (sesse)
|
2018-02-17 17:51:35 -07:00
|
|
|
Stéphane Nicolet (snicolet)
|
|
|
|
|
Thanar2
|
2014-06-20 19:35:09 -06:00
|
|
|
thaspel
|
2020-01-07 13:35:47 -07:00
|
|
|
theo77186
|
|
|
|
|
Tom Truscott
|
2018-02-17 17:51:35 -07:00
|
|
|
Tom Vijlbrief (tomtor)
|
2020-01-07 13:35:47 -07:00
|
|
|
Torsten Franz (torfranz, tfranzer)
|
|
|
|
|
Tracey Emery (basepr1me)
|
2018-02-17 17:51:35 -07:00
|
|
|
Uri Blass (uriblass)
|
2020-01-07 13:35:47 -07:00
|
|
|
Vince Negri (cuddlestmonkey)
|
2019-09-22 08:56:36 -06:00
|
|
|
|
Smarter time management near stop limit
This patch makes Stockfish search same depth again if > 60% of optimum time is
already used, instead of trying the next iteration. The idea is that the next
iteration will generally take about the same amount of time as has already been
used in total. When we are likely to begin the last iteration, as judged by total
time taken so far > 0.6 * optimum time, searching the last depth again instead of
increasing the depth still helps the other threads in lazy SMP and prepares better
move ordering for the next moves.
STC :
LLR: 2.95 (-2.94,2.94) {-1.00,3.00}
Total: 13436 W: 2695 L: 2558 D: 8183
Ptnml(0-2): 222, 1538, 3087, 1611, 253
https://tests.stockfishchess.org/tests/view/5e1618a761fe5f83a67dd964
LTC :
LLR: 2.94 (-2.94,2.94) {0.00,2.00}
Total: 32160 W: 4261 L: 4047 D: 23852
Ptnml(0-2): 211, 2988, 9448, 3135, 247
https://tests.stockfishchess.org/tests/view/5e162ca061fe5f83a67dd96d
The code was revised as suggested by @vondele for multithreading:
STC (8 threads):
LLR: 2.95 (-2.94,2.94) {0.00,2.00}
Total: 16640 W: 2049 L: 1885 D: 12706
Ptnml(0-2): 119, 1369, 5158, 1557, 108
https://tests.stockfishchess.org/tests/view/5e19826a2cc590e03c3c2f52
LTC (8 threads):
LLR: 2.95 (-2.94,2.94) {-1.00,3.00}
Total: 16536 W: 2758 L: 2629 D: 11149
Ptnml(0-2): 182, 1758, 4296, 1802, 224
https://tests.stockfishchess.org/tests/view/5e18b91a27dab692fcf9a140
Thanks to those discussing Stockfish lazy SMP on fishcooking which made me
try this, and to @vondele for suggestions and doing related tests.
See full discussion in the pull request thread:
https://github.com/official-stockfish/Stockfish/pull/2482
Bench: 4586187
2020-01-11 15:10:22 -07:00
|
|
|
|
Tweak futility pruning constants
Based on recent improvement of futility pruning by @locutus2 : we lower
the futility margin to apply it for more nodes but as a compensation
we also lower the history threshold to apply it to less nodes. Further
work in tweaking constants can always be done - numbers are guessed
"by hand" and are not results of some tuning, maybe there is some more
Elo to squeeze from this part of code.
Passed STC
LLR: 2.98 (-2.94,2.94) {-1.00,3.00}
Total: 15300 W: 3081 L: 2936 D: 9283
Ptnml(0-2): 260, 1816, 3382, 1900, 290
http://tests.stockfishchess.org/tests/view/5e18da3b27dab692fcf9a158
Passed LTC
LLR: 2.94 (-2.94,2.94) {0.00,2.00}
Total: 108670 W: 14509 L: 14070 D: 80091
Ptnml(0-2): 813, 10259, 31736, 10665, 831
http://tests.stockfishchess.org/tests/view/5e18fc9627dab692fcf9a180
Bench: 4643972
2020-01-12 16:59:06 -07:00
|
|
|
# Additionally, we acknowledge the authors and maintainers of fishtest,
|
Smarter time management near stop limit
This patch makes Stockfish search same depth again if > 60% of optimum time is
already used, instead of trying the next iteration. The idea is that the next
iteration will generally take about the same amount of time as has already been
used in total. When we are likely to begin the last iteration, as judged by total
time taken so far > 0.6 * optimum time, searching the last depth again instead of
increasing the depth still helps the other threads in lazy SMP and prepares better
move ordering for the next moves.
STC :
LLR: 2.95 (-2.94,2.94) {-1.00,3.00}
Total: 13436 W: 2695 L: 2558 D: 8183
Ptnml(0-2): 222, 1538, 3087, 1611, 253
https://tests.stockfishchess.org/tests/view/5e1618a761fe5f83a67dd964
LTC :
LLR: 2.94 (-2.94,2.94) {0.00,2.00}
Total: 32160 W: 4261 L: 4047 D: 23852
Ptnml(0-2): 211, 2988, 9448, 3135, 247
https://tests.stockfishchess.org/tests/view/5e162ca061fe5f83a67dd96d
The code was revised as suggested by @vondele for multithreading:
STC (8 threads):
LLR: 2.95 (-2.94,2.94) {0.00,2.00}
Total: 16640 W: 2049 L: 1885 D: 12706
Ptnml(0-2): 119, 1369, 5158, 1557, 108
https://tests.stockfishchess.org/tests/view/5e19826a2cc590e03c3c2f52
LTC (8 threads):
LLR: 2.95 (-2.94,2.94) {-1.00,3.00}
Total: 16536 W: 2758 L: 2629 D: 11149
Ptnml(0-2): 182, 1758, 4296, 1802, 224
https://tests.stockfishchess.org/tests/view/5e18b91a27dab692fcf9a140
Thanks to those discussing Stockfish lazy SMP on fishcooking which made me
try this, and to @vondele for suggestions and doing related tests.
See full discussion in the pull request thread:
https://github.com/official-stockfish/Stockfish/pull/2482
Bench: 4586187
2020-01-11 15:10:22 -07:00
|
|
|
# an amazing and essential framework for the development of Stockfish!
|
|
|
|
|
#
|
2019-09-22 08:56:36 -06:00
|
|
|
# https://github.com/glinscott/fishtest/blob/master/AUTHORS
|
Smarter time management near stop limit
This patch makes Stockfish search same depth again if > 60% of optimum time is
already used, instead of trying the next iteration. The idea is that the next
iteration will generally take about the same amount of time as has already been
used in total. When we are likely to begin the last iteration, as judged by total
time taken so far > 0.6 * optimum time, searching the last depth again instead of
increasing the depth still helps the other threads in lazy SMP and prepares better
move ordering for the next moves.
STC :
LLR: 2.95 (-2.94,2.94) {-1.00,3.00}
Total: 13436 W: 2695 L: 2558 D: 8183
Ptnml(0-2): 222, 1538, 3087, 1611, 253
https://tests.stockfishchess.org/tests/view/5e1618a761fe5f83a67dd964
LTC :
LLR: 2.94 (-2.94,2.94) {0.00,2.00}
Total: 32160 W: 4261 L: 4047 D: 23852
Ptnml(0-2): 211, 2988, 9448, 3135, 247
https://tests.stockfishchess.org/tests/view/5e162ca061fe5f83a67dd96d
The code was revised as suggested by @vondele for multithreading:
STC (8 threads):
LLR: 2.95 (-2.94,2.94) {0.00,2.00}
Total: 16640 W: 2049 L: 1885 D: 12706
Ptnml(0-2): 119, 1369, 5158, 1557, 108
https://tests.stockfishchess.org/tests/view/5e19826a2cc590e03c3c2f52
LTC (8 threads):
LLR: 2.95 (-2.94,2.94) {-1.00,3.00}
Total: 16536 W: 2758 L: 2629 D: 11149
Ptnml(0-2): 182, 1758, 4296, 1802, 224
https://tests.stockfishchess.org/tests/view/5e18b91a27dab692fcf9a140
Thanks to those discussing Stockfish lazy SMP on fishcooking which made me
try this, and to @vondele for suggestions and doing related tests.
See full discussion in the pull request thread:
https://github.com/official-stockfish/Stockfish/pull/2482
Bench: 4586187
2020-01-11 15:10:22 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|