2008-08-31 23:59:13 -06:00
|
|
|
/*
|
2008-10-19 10:56:28 -06:00
|
|
|
Stockfish, a UCI chess playing engine derived from Glaurung 2.1
|
2021-01-08 09:04:23 -07:00
|
|
|
Copyright (C) 2004-2021 The Stockfish developers (see AUTHORS file)
|
2008-08-31 23:59:13 -06:00
|
|
|
|
2008-10-19 10:56:28 -06:00
|
|
|
Stockfish is free software: you can redistribute it and/or modify
|
2008-08-31 23:59:13 -06:00
|
|
|
it under the terms of the GNU General Public License as published by
|
|
|
|
the Free Software Foundation, either version 3 of the License, or
|
|
|
|
(at your option) any later version.
|
2009-01-07 06:28:04 -07:00
|
|
|
|
2008-10-19 10:56:28 -06:00
|
|
|
Stockfish is distributed in the hope that it will be useful,
|
2008-08-31 23:59:13 -06:00
|
|
|
but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
|
|
GNU General Public License for more details.
|
2009-01-07 06:28:04 -07:00
|
|
|
|
2008-08-31 23:59:13 -06:00
|
|
|
You should have received a copy of the GNU General Public License
|
|
|
|
along with this program. If not, see <http://www.gnu.org/licenses/>.
|
|
|
|
*/
|
|
|
|
|
2013-07-23 07:31:57 -06:00
|
|
|
#ifndef THREAD_H_INCLUDED
|
2008-08-31 23:59:13 -06:00
|
|
|
#define THREAD_H_INCLUDED
|
|
|
|
|
2015-02-22 06:40:46 -07:00
|
|
|
#include <atomic>
|
2015-01-18 00:00:50 -07:00
|
|
|
#include <condition_variable>
|
|
|
|
#include <mutex>
|
|
|
|
#include <thread>
|
2012-03-24 14:36:33 -06:00
|
|
|
#include <vector>
|
2010-02-13 03:40:55 -07:00
|
|
|
|
2011-04-24 02:20:03 -06:00
|
|
|
#include "material.h"
|
2008-08-31 23:59:13 -06:00
|
|
|
#include "movepick.h"
|
2011-04-24 02:20:03 -06:00
|
|
|
#include "pawns.h"
|
2008-08-31 23:59:13 -06:00
|
|
|
#include "position.h"
|
2011-11-23 12:07:29 -07:00
|
|
|
#include "search.h"
|
2019-03-12 01:35:10 -06:00
|
|
|
#include "thread_win32_osx.h"
|
2008-08-31 23:59:13 -06:00
|
|
|
|
2021-02-26 02:02:13 -07:00
|
|
|
namespace Stockfish {
|
2011-04-24 02:20:03 -06:00
|
|
|
|
2017-08-13 00:58:31 -06:00
|
|
|
/// Thread class keeps together all the thread-related stuff. We use
|
|
|
|
/// per-thread pawn and material hash tables so that once we get a
|
|
|
|
/// pointer to an entry its life time is unlimited and we don't have
|
|
|
|
/// to care about someone changing the entry under our feet.
|
2013-07-31 01:33:26 -06:00
|
|
|
|
2015-11-20 23:48:50 -07:00
|
|
|
class Thread {
|
2013-07-31 01:33:26 -06:00
|
|
|
|
2019-09-15 23:51:25 -06:00
|
|
|
std::mutex mutex;
|
|
|
|
std::condition_variable cv;
|
2017-08-13 00:58:31 -06:00
|
|
|
size_t idx;
|
|
|
|
bool exit = false, searching = true; // Set before starting std::thread
|
2019-03-12 01:35:10 -06:00
|
|
|
NativeThread stdThread;
|
2015-11-20 23:48:50 -07:00
|
|
|
|
|
|
|
public:
|
2017-08-13 00:58:31 -06:00
|
|
|
explicit Thread(size_t);
|
2015-11-05 00:40:23 -07:00
|
|
|
virtual ~Thread();
|
|
|
|
virtual void search();
|
2017-08-31 01:34:32 -06:00
|
|
|
void clear();
|
2015-11-05 00:40:23 -07:00
|
|
|
void idle_loop();
|
2017-08-04 11:48:07 -06:00
|
|
|
void start_searching();
|
2015-11-20 23:48:50 -07:00
|
|
|
void wait_for_search_finished();
|
2013-07-31 01:33:26 -06:00
|
|
|
|
2015-01-09 04:35:44 -07:00
|
|
|
Pawns::Table pawnsTable;
|
2012-12-16 04:00:54 -07:00
|
|
|
Material::Table materialTable;
|
2019-11-02 18:04:05 -06:00
|
|
|
size_t pvIdx, pvLast;
|
Use exploration rate for reductions
This patch measures how frequently search is exploring new configurations.
This is done be computing a running average of ttHit. The ttHitAverage rate
is somewhat low (e.g. 30% for startpos) in the normal case, while it can be
very high if no progress is made (e.g. 90% for the fortress I used for testing).
This information can be used to influence search. In this patch, by adjusting
reductions if the rate > 50%. A first version (using a low ttHitAverageResolution
and this 50% threshold) passed testing:
STC
LLR: 2.96 (-2.94,2.94) [-1.50,4.50]
Total: 26425 W: 5837 L: 5650 D: 14938
http://tests.stockfishchess.org/tests/view/5dcede8b0ebc5902563258fa
LTC
LLR: 2.96 (-2.94,2.94) [0.00,3.50]
Total: 32313 W: 5392 L: 5128 D: 21793
http://tests.stockfishchess.org/tests/view/5dcefb1f0ebc590256325c0e
However, as discussed in pull request 2414, using a larger ttHitAverageResolution
gives a better approximation of the underlying distributions. This needs a slight
adjustment for the threshold as the new distributions are shifted a bit compared
to the older ones, and this threshold seemingly is sensitive (we used 0.53125 here).
https://github.com/official-stockfish/Stockfish/pull/2414
This final version also passed testing, and is used for the patch:
STC
LLR: 2.95 (-2.94,2.94) [-1.50,4.50]
Total: 16025 W: 3555 L: 3399 D: 9071
http://tests.stockfishchess.org/tests/view/5dd070b90ebc5902579e20c2
LTC
LLR: 2.96 (-2.94,2.94) [0.00,3.50]
Total: 37576 W: 6277 L: 5998 D: 25301
http://tests.stockfishchess.org/tests/view/5dd0f58e6f544e798086f224
Closes https://github.com/official-stockfish/Stockfish/pull/2414
Bench: 4989584
2019-11-15 10:16:27 -07:00
|
|
|
uint64_t ttHitAverage;
|
2018-06-02 09:41:37 -06:00
|
|
|
int selDepth, nmpMinPly;
|
|
|
|
Color nmpColor;
|
Use average bestMoveChanges across all threads #2072
The current update only by main thread depends on the luck of
whether main thread sees any/many changes to the best move or not.
It then makes large, lumpy changes to the time to be
used (1x, 2x, 3x, etc) depending on that sample of 1.
Use the average across all threads to get a more reliable
number with a smoother distribution.
STC @ 5+0.05 th 4 :
LLR: 2.95 (-2.94,2.94) [0.50,4.50]
Total: 51899 W: 11446 L: 11029 D: 29424
http://tests.stockfishchess.org/tests/view/5ca32ff20ebc5925cf0016fb
STC @ 5+0.05 th 8 :
LLR: 2.96 (-2.94,2.94) [0.50,4.50]
Total: 13851 W: 2843 L: 2620 D: 8388
http://tests.stockfishchess.org/tests/view/5ca35ae00ebc5925cf001adb
LTC @ 20+0.2 th 8 :
LLR: 2.95 (-2.94,2.94) [0.00,3.50]
Total: 48527 W: 7941 L: 7635 D: 32951
http://tests.stockfishchess.org/tests/view/5ca37cb70ebc5925cf001cec
Further work:
Similar changes might be possible for the fallingEval and timeReduction calculations (and elsewhere?), using either the min, average or max values across all threads.
Bench 3506898
2019-04-03 01:35:55 -06:00
|
|
|
std::atomic<uint64_t> nodes, tbHits, bestMoveChanges;
|
Lazy SMP
Start all threads searching on root position and
use only the shared TT table as synching scheme.
It seems this scheme scales better than YBWC for
high number of threads.
Verified for nor regression at STC 3 threads
LLR: -2.95 (-2.94,2.94) [-3.00,1.00]
Total: 40232 W: 6908 L: 7130 D: 26194
Verified for nor regression at LTC 3 threads
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 28186 W: 3908 L: 3798 D: 20480
Verified for nor regression at STC 7 threads
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 3607 W: 674 L: 526 D: 2407
Verified for nor regression at LTC 7 threads
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 4235 W: 671 L: 528 D: 3036
Tested with fixed games at LTC with 20 threads
ELO: 44.75 +-7.6 (95%) LOS: 100.0%
Total: 2069 W: 407 L: 142 D: 1520
Tested with fixed games at XLTC (120secs) with 20 threads
ELO: 28.01 +-6.7 (95%) LOS: 100.0%
Total: 2275 W: 349 L: 166 D: 1760
Original patch of mbootsector, with additional work
from Ivan Ivec (log formula), Joerg Oster (id loop
simplification) and Marco Costalba (assorted formatting
and rework).
Bench: 8116244
2015-10-06 00:15:17 -06:00
|
|
|
|
|
|
|
Position rootPos;
|
2020-08-09 10:11:38 -06:00
|
|
|
StateInfo rootState;
|
2016-04-11 08:45:36 -06:00
|
|
|
Search::RootMoves rootMoves;
|
2019-05-15 02:50:27 -06:00
|
|
|
Depth rootDepth, completedDepth;
|
2017-06-30 09:20:00 -06:00
|
|
|
CounterMoveHistory counterMoves;
|
|
|
|
ButterflyHistory mainHistory;
|
Improve move order near the root
Current move histories are known to work well near the leaves, whilst at
higher depths they aren't very helpful. To address this problem this
patch introduces a table dedicated for what's happening at plies 0-3.
It's structured like mainHistory with ply index instead of color.
It get cleared with each new search and is filled during iterative
deepening at higher depths when recording successful quiet moves near
the root or traversing nodes which were in the principal variation
(ttPv).
Medium TC (20+0.2):
https://tests.stockfishchess.org/tests/view/5e4d358790a0a02810d096dc
LLR: 2.94 (-2.94,2.94) {-0.50,1.50}
Total: 100910 W: 16682 L: 16376 D: 67852
Ptnml(0-2): 1177, 10983, 25883, 11181, 1231
LTC:
https://tests.stockfishchess.org/tests/view/5e4e2cb790a0a02810d09714
LLR: 2.95 (-2.94,2.94) {0.25,1.75}
Total: 80444 W: 10495 L: 10095 D: 59854
Ptnml(0-2): 551, 7479, 23803, 7797, 592
closes https://github.com/official-stockfish/Stockfish/pull/2557
Bench: 4705960
2020-02-21 06:01:59 -07:00
|
|
|
LowPlyHistory lowPlyHistory;
|
2017-11-03 05:37:11 -06:00
|
|
|
CapturePieceToHistory captureHistory;
|
2019-10-08 08:44:01 -06:00
|
|
|
ContinuationHistory continuationHistory[2][2];
|
Use per-thread dynamic contempt
We now use per-thread dynamic contempt. This patch has the following
effects:
* for Threads=1: **non-functional**
* for Threads>1:
* with MultiPV=1: **no regression, little to no ELO gain**
* with MultiPV>1: **clear improvement over master**
First, I tried testing at standard MultiPV=1 play with [0,5] bounds.
This yielded 2 yellow and 1 red test:
5+0.05, Threads=5:
LLR: -2.96 (-2.94,2.94) [0.00,5.00]
Total: 82689 W: 16439 L: 16190 D: 50060
http://tests.stockfishchess.org/tests/view/5aa93a5a0ebc5902952892e6
5+0.05, Threads=8:
LLR: -2.96 (-2.94,2.94) [0.00,5.00]
Total: 27164 W: 4974 L: 4983 D: 17207
http://tests.stockfishchess.org/tests/view/5ab2639b0ebc5902a6fbefd5
5+0.5, Threads=16:
LLR: -2.97 (-2.94,2.94) [0.00,5.00]
Total: 41396 W: 7127 L: 7082 D: 27187
http://tests.stockfishchess.org/tests/view/5ab124220ebc59029516cb62
Then, I tested with Skill Level=17 (implicitly MutliPV=4), showing
a clear improvement:
5+0.05, Threads=5:
LLR: 2.96 (-2.94,2.94) [0.00,5.00]
Total: 3498 W: 1316 L: 1135 D: 1047
http://tests.stockfishchess.org/tests/view/5ab4b6580ebc5902932aeca2
Next, I tested the patch with MultiPV=1 again, this time checking for
non-regression ([-3, 1]):
5+0.5, Threads=5:
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 65575 W: 12786 L: 12745 D: 40044
http://tests.stockfishchess.org/tests/view/5ab4e8500ebc5902932aecb3
Finally, I ran some tests with fixed number of games, checking if
reverting dynamic contempt gains more elo with Skill Level=17 (i.e.
MultiPV) than applying the "prevScore" fix and this patch. These tests
showed, that this patch gains 15 ELO when playing with Skill Level=17:
5+0.05, Threads=3, "revert dynamic contempt" vs. "WITHOUT this patch":
ELO: -11.43 +-4.1 (95%) LOS: 0.0%
Total: 20000 W: 7085 L: 7743 D: 5172
http://tests.stockfishchess.org/tests/view/5ab636450ebc590295d88536
5+0.05, Threads=3, "revert dynamic contempt" vs. "WITH this patch":
ELO: -26.42 +-4.1 (95%) LOS: 0.0%
Total: 20000 W: 6661 L: 8179 D: 5160
http://tests.stockfishchess.org/tests/view/5ab62e680ebc590295d88524
---
***FAQ***
**Why should this be commited?**
I believe that the gain for multi-thread MultiPV search is a sufficient
justification for this otherwise neutral change. I also believe this
implementation of dynamic contempt is more logical, although this may
be just my opinion.
**Why is per-thread contempt better at MultiPV?**
A likely explanation for the gain in MultiPV mode is that during
search each thread independently switches between rootMoves and via
the shared contempt score skews each other's evaluation.
**Why were the tests done with Skill Level=17?**
This was originally suggested by @Hanamuke and the idea is that with
Skill Level Stockfish sometimes plays also moves it thinks are slightly
sub-optimal and thus the quality of all moves offered by the MultiPV
search is checked by the test.
**Why are the ELO differences so huge?**
This is most likely because of the nature of Skill Level mode --
since it slower and weaker than normal mode, bugs in evaluation have
much greater effect.
---
Closes https://github.com/official-stockfish/Stockfish/pull/1515.
No functional change -- in single thread mode.
2018-03-30 02:47:05 -06:00
|
|
|
Score contempt;
|
Do more reductions for late quiet moves in case of consecutive fail highs.
Idea of this patch can be described as following - in case we have consecutive fail highs and we reach late enough moves at root node probability of remaining quiet moves being able to produce even bigger value than moves that produced previous cutoff (so ones that should be high in move ordering but now they fail to produce beta cutoff because we actually reached high move count) should be quiet small so we can reduce them more.
passed STC
LLR: 2.94 (-2.94,2.94) {-0.25,1.25}
Total: 53392 W: 5681 L: 5474 D: 42237
Ptnml(0-2): 214, 4104, 17894, 4229, 255
https://tests.stockfishchess.org/tests/view/5f88501adcdad978fe8c527e
passed LTC
LLR: 2.94 (-2.94,2.94) {0.25,1.25}
Total: 59136 W: 2773 L: 2564 D: 53799
Ptnml(0-2): 30, 2117, 25078, 2300, 43
https://tests.stockfishchess.org/tests/view/5f884dbfdcdad978fe8c527a
closes https://github.com/official-stockfish/Stockfish/pull/3184
Bench: 4066972
2020-10-17 05:40:10 -06:00
|
|
|
int failedHighCnt;
|
2008-08-31 23:59:13 -06:00
|
|
|
};
|
|
|
|
|
2013-01-16 01:28:41 -07:00
|
|
|
|
2017-08-13 00:58:31 -06:00
|
|
|
/// MainThread is a derived class specific for main thread
|
2013-01-16 01:28:41 -07:00
|
|
|
|
|
|
|
struct MainThread : public Thread {
|
2017-08-13 00:58:31 -06:00
|
|
|
|
|
|
|
using Thread::Thread;
|
|
|
|
|
2017-08-13 06:33:25 -06:00
|
|
|
void search() override;
|
2017-06-23 23:15:46 -06:00
|
|
|
void check_time();
|
2015-12-23 02:07:54 -07:00
|
|
|
|
Use average bestMoveChanges across all threads #2072
The current update only by main thread depends on the luck of
whether main thread sees any/many changes to the best move or not.
It then makes large, lumpy changes to the time to be
used (1x, 2x, 3x, etc) depending on that sample of 1.
Use the average across all threads to get a more reliable
number with a smoother distribution.
STC @ 5+0.05 th 4 :
LLR: 2.95 (-2.94,2.94) [0.50,4.50]
Total: 51899 W: 11446 L: 11029 D: 29424
http://tests.stockfishchess.org/tests/view/5ca32ff20ebc5925cf0016fb
STC @ 5+0.05 th 8 :
LLR: 2.96 (-2.94,2.94) [0.50,4.50]
Total: 13851 W: 2843 L: 2620 D: 8388
http://tests.stockfishchess.org/tests/view/5ca35ae00ebc5925cf001adb
LTC @ 20+0.2 th 8 :
LLR: 2.95 (-2.94,2.94) [0.00,3.50]
Total: 48527 W: 7941 L: 7635 D: 32951
http://tests.stockfishchess.org/tests/view/5ca37cb70ebc5925cf001cec
Further work:
Similar changes might be possible for the fallingEval and timeReduction calculations (and elsewhere?), using either the min, average or max values across all threads.
Bench 3506898
2019-04-03 01:35:55 -06:00
|
|
|
double previousTimeReduction;
|
2020-04-12 12:30:08 -06:00
|
|
|
Value bestPreviousScore;
|
2019-12-08 04:06:19 -07:00
|
|
|
Value iterValue[4];
|
2017-08-13 00:58:31 -06:00
|
|
|
int callsCnt;
|
Simplify pondering time management (#1899)
stopOnPonderhit is used to stop search quickly on a ponderhit. It is set by mainThread as part of its time management. However, master employs it as a signal between mainThread and the UCI thread. This is not necessary, it is sufficient for the UCI thread to signal that pondering finished, and mainThread should do its usual time-keeping job, and in this case stop immediately.
This patch implements this, removing stopOnPonderHit as an atomic variable from the ThreadPool,
and moving it as a normal variable to mainThread, reducing its scope. In MainThread::check_time() the search is stopped immediately if ponder switches to false, and the variable stopOnPonderHit is set.
Furthermore, ponder has been moved to mainThread, as the variable is only used to exchange signals between the UCI thread and mainThread.
The version has been tested locally (as fishtest doesn't support ponder):
Score of ponderSimp vs master: 2616 - 2528 - 8630 [0.503] 13774
Elo difference: 2.22 +/- 3.54
which indicates no regression.
No functional change.
2019-01-20 11:14:24 -07:00
|
|
|
bool stopOnPonderhit;
|
|
|
|
std::atomic_bool ponder;
|
2013-01-13 16:32:30 -07:00
|
|
|
};
|
|
|
|
|
2011-04-24 02:20:03 -06:00
|
|
|
|
2016-01-16 14:34:29 -07:00
|
|
|
/// ThreadPool struct handles all the threads-related stuff like init, starting,
|
2015-11-20 23:48:50 -07:00
|
|
|
/// parking and, most importantly, launching a thread. All the access to threads
|
2017-08-13 00:58:31 -06:00
|
|
|
/// is done through this class.
|
2011-04-24 02:20:03 -06:00
|
|
|
|
2013-02-04 14:38:42 -07:00
|
|
|
struct ThreadPool : public std::vector<Thread*> {
|
2012-08-19 03:20:15 -06:00
|
|
|
|
2017-08-10 13:32:50 -06:00
|
|
|
void start_thinking(Position&, StateListPtr&, const Search::LimitsType&, bool = false);
|
2017-12-26 02:40:42 -07:00
|
|
|
void clear();
|
2017-08-13 00:58:31 -06:00
|
|
|
void set(size_t);
|
|
|
|
|
|
|
|
MainThread* main() const { return static_cast<MainThread*>(front()); }
|
|
|
|
uint64_t nodes_searched() const { return accumulate(&Thread::nodes); }
|
|
|
|
uint64_t tb_hits() const { return accumulate(&Thread::tbHits); }
|
2020-05-31 23:31:14 -06:00
|
|
|
Thread* get_best_thread() const;
|
|
|
|
void start_searching();
|
|
|
|
void wait_for_search_finished() const;
|
2016-04-11 08:45: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
|
|
|
std::atomic_bool stop, increaseDepth;
|
2017-07-13 17:07:19 -06:00
|
|
|
|
2016-04-11 08:45:36 -06:00
|
|
|
private:
|
|
|
|
StateListPtr setupStates;
|
2017-08-13 00:58:31 -06:00
|
|
|
|
|
|
|
uint64_t accumulate(std::atomic<uint64_t> Thread::* member) const {
|
|
|
|
|
|
|
|
uint64_t sum = 0;
|
|
|
|
for (Thread* th : *this)
|
|
|
|
sum += (th->*member).load(std::memory_order_relaxed);
|
|
|
|
return sum;
|
|
|
|
}
|
2011-04-24 02:20:03 -06:00
|
|
|
};
|
|
|
|
|
2012-06-24 02:30:40 -06:00
|
|
|
extern ThreadPool Threads;
|
2011-04-24 02:20:03 -06:00
|
|
|
|
2021-02-26 02:02:13 -07:00
|
|
|
} // namespace Stockfish
|
|
|
|
|
2013-07-23 07:31:57 -06:00
|
|
|
#endif // #ifndef THREAD_H_INCLUDED
|