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
|
|
|
|
Copyright (C) 2004-2008 Tord Romstad (Glaurung author)
|
2016-01-02 02:43:25 -07:00
|
|
|
Copyright (C) 2008-2015 Marco Costalba, Joona Kiiski, Tord Romstad
|
2018-11-19 03:18:21 -07:00
|
|
|
Copyright (C) 2015-2019 Marco Costalba, Joona Kiiski, Gary Linscott, Tord Romstad
|
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.
|
2008-09-03 15:33:49 -06: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.
|
2008-09-03 15:33:49 -06: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/>.
|
|
|
|
*/
|
|
|
|
|
2011-12-12 09:55:20 -07:00
|
|
|
#include <algorithm>
|
2008-08-31 23:59:13 -06:00
|
|
|
#include <cassert>
|
2010-01-19 03:48:22 -07:00
|
|
|
#include <cmath>
|
2014-12-30 02:31:50 -07:00
|
|
|
#include <cstring> // For std::memset
|
2011-12-25 01:04:28 -07:00
|
|
|
#include <iostream>
|
2008-08-31 23:59:13 -06:00
|
|
|
#include <sstream>
|
|
|
|
|
|
|
|
#include "evaluate.h"
|
2014-12-08 00:23:09 -07:00
|
|
|
#include "misc.h"
|
2009-06-11 07:11:08 -06:00
|
|
|
#include "movegen.h"
|
2008-08-31 23:59:13 -06:00
|
|
|
#include "movepick.h"
|
2016-09-17 00:19:06 -06:00
|
|
|
#include "position.h"
|
2008-08-31 23:59:13 -06:00
|
|
|
#include "search.h"
|
|
|
|
#include "thread.h"
|
2018-03-20 18:26:12 -06:00
|
|
|
#include "timeman.h"
|
2008-08-31 23:59:13 -06:00
|
|
|
#include "tt.h"
|
2014-10-26 00:09:19 -06:00
|
|
|
#include "uci.h"
|
2015-01-18 00:05:05 -07:00
|
|
|
#include "syzygy/tbprobe.h"
|
2014-11-25 16:45:28 -07:00
|
|
|
|
2011-11-26 04:07:35 -07:00
|
|
|
namespace Search {
|
|
|
|
|
|
|
|
LimitsType Limits;
|
2014-11-30 04:14:14 -07:00
|
|
|
}
|
|
|
|
|
2015-01-18 00:05:05 -07:00
|
|
|
namespace Tablebases {
|
|
|
|
|
|
|
|
int Cardinality;
|
|
|
|
bool RootInTB;
|
|
|
|
bool UseRule50;
|
|
|
|
Depth ProbeDepth;
|
|
|
|
}
|
|
|
|
|
|
|
|
namespace TB = Tablebases;
|
|
|
|
|
2011-12-04 03:46:31 -07:00
|
|
|
using std::string;
|
2012-03-06 02:09:37 -07:00
|
|
|
using Eval::evaluate;
|
2011-12-04 03:46:31 -07:00
|
|
|
using namespace Search;
|
|
|
|
|
2008-08-31 23:59:13 -06:00
|
|
|
namespace {
|
|
|
|
|
2016-01-16 14:34:29 -07:00
|
|
|
// Different node types, used as a template parameter
|
2016-01-18 15:20:16 -07:00
|
|
|
enum NodeType { NonPV, PV };
|
2010-11-08 01:44:28 -07:00
|
|
|
|
2017-03-14 22:00:03 -06:00
|
|
|
// Sizes and phases of the skip-blocks, used for distributing search depths across the threads
|
2018-03-18 16:38:58 -06:00
|
|
|
constexpr int SkipSize[] = { 1, 1, 2, 2, 2, 2, 3, 3, 3, 3, 3, 3, 4, 4, 4, 4, 4, 4, 4, 4 };
|
|
|
|
constexpr int SkipPhase[] = { 0, 1, 0, 1, 2, 3, 0, 1, 2, 3, 4, 5, 0, 1, 2, 3, 4, 5, 6, 7 };
|
2017-03-14 22:00:03 -06:00
|
|
|
|
Reintroduce depth 2 razoring (with additional margin)
The first depth 2 margin triggers the verification quiescence search.
This qsearch() result has to be better then the second lower margin,
so we only skip the razoring when the qsearch gives a significant
improvement.
Passed STC:
LLR: 2.95 (-2.94,2.94) [0.00,5.00]
Total: 32133 W: 7395 L: 7101 D: 17637
http://tests.stockfishchess.org/tests/view/5a93198b0ebc590297cc8942
Passed LTC:
LLR: 2.96 (-2.94,2.94) [0.00,5.00]
Total: 17382 W: 3002 L: 2809 D: 11571
http://tests.stockfishchess.org/tests/view/5a93b18c0ebc590297cc89c2
This Elo-gaining version was further simplified following a suggestion
of Marco Costalba:
STC:
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 15553 W: 3505 L: 3371 D: 8677
http://tests.stockfishchess.org/tests/view/5a964be90ebc590297cc8cc4
LTC:
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 13253 W: 2270 L: 2137 D: 8846
http://tests.stockfishchess.org/tests/view/5a9658880ebc590297cc8cca
How to continue after this patch?
Reformating the razoring code (step 7 in search()) to unify the
depth 1 and depth 2 treatements seems quite possible, this could
possibly lead to more simplifications.
Bench: 5765806
2018-02-28 05:41:24 -07:00
|
|
|
// Razor and futility margins
|
Simple razoring: depth 1 only, no distinction between PV / NonPV
We simplify the razoring logic by applying it to all nodes at depth 1 only.
An added advantage is that only one razor margin is needed now, and we treat
PV and Non-PV nodes in the same manner.
How to continue?
- There may be some conditions in which depth 2 razoring is beneficial.
- We can see whether the razor margin can be tuned, perhaps even with a
different value for PV nodes.
- Perhaps we can unify the treatment of PV and Non-PV nodes in other parts
of the search as well.
STC:
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 5474 W: 1281 L: 1127 D: 3066
http://tests.stockfishchess.org/tests/view/5b6de3b20ebc5902bdba0d1e
LTC:
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 62670 W: 10749 L: 10697 D: 41224
http://tests.stockfishchess.org/tests/view/5b6dee340ebc5902bdba0eb0
In addition, we ran a fixed LTC test against a similar patch which also
passed SPRT [-3, 1]:
ELO: 0.23 +-2.1 (95%) LOS: 58.6%
Total: 36412 W: 6168 L: 6144 D: 24100
http://tests.stockfishchess.org/tests/view/5b6e83940ebc5902bdba1485
We are opting for this patch as the more logical and simple of the two,
and it appears to be no less strong. Thanks in particular to @DU-jdto
for input into this patch.
Bench: 4476945
2018-08-12 01:47:30 -06:00
|
|
|
constexpr int RazorMargin = 600;
|
2018-03-07 14:31:51 -07:00
|
|
|
Value futility_margin(Depth d, bool improving) {
|
|
|
|
return Value((175 - 50 * improving) * d / ONE_PLY);
|
|
|
|
}
|
2008-08-31 23:59:13 -06:00
|
|
|
|
2019-03-05 12:48:29 -07:00
|
|
|
// Reductions lookup table, initialized at startup
|
2019-03-03 07:53:36 -07:00
|
|
|
int Reductions[64]; // [depth or moveNumber]
|
2010-02-25 09:27:27 -07:00
|
|
|
|
Retire FORCE_INLINE
No speed regression on my machine (i7-3770k, gcc 4.9.1, linux 3.16):
stat test master diff
mean 2,482,415 2,474,987 7,906
stdev 4,603 5,644 2,497
speedup 0.32%
P(speedup>0) 100.0%
Fishtest 9+0.03:
ELO: 0.26 +-1.8 (95%) LOS: 61.2%
Total: 60000 W: 12437 L: 12392 D: 35171
No functional change.
Resolves #334
2015-04-15 14:21:45 -06:00
|
|
|
template <bool PvNode> Depth reduction(bool i, Depth d, int mn) {
|
2019-03-03 07:53:36 -07:00
|
|
|
int r = Reductions[std::min(d / ONE_PLY, 63)] * Reductions[std::min(mn, 63)] / 1024;
|
|
|
|
return ((r + 512) / 1024 + (!i && r > 1024) - PvNode) * ONE_PLY;
|
2011-04-24 01:31:47 -06:00
|
|
|
}
|
|
|
|
|
2019-03-05 12:48:29 -07:00
|
|
|
constexpr int futility_move_count(bool improving, int depth) {
|
|
|
|
return (5 + depth * depth) * (1 + improving) / 2;
|
|
|
|
}
|
|
|
|
|
2017-01-25 07:32:10 -07:00
|
|
|
// History and stats update bonus, based on depth
|
2017-04-23 08:57:48 -06:00
|
|
|
int stat_bonus(Depth depth) {
|
2017-06-11 15:31:15 -06:00
|
|
|
int d = depth / ONE_PLY;
|
2018-08-12 02:02:51 -06:00
|
|
|
return d > 17 ? 0 : 29 * d * d + 138 * d - 134;
|
2017-01-25 07:32:10 -07:00
|
|
|
}
|
|
|
|
|
2018-11-19 23:45:00 -07:00
|
|
|
// Add a small random component to draw evaluations to keep search dynamic
|
Randomize draw eval
The patch adds a small random component (+-1) to VALUE_DRAW for the evaluation
of draw positions (mostly 3folds). This random component is not static, but
potentially different for each visit of the node (hence derived from the node
counter). The effect is that in positions with many 3fold draw lines, different
lines are followed at each iteration. This keeps the search much more dynamic,
as opposed to being locked to one particular 3fold.
An example of a position where master suffers from 3fold-blindness and this patch
solves quickly is the famous TCEC game 53:
FEN: 3r2k1/pr6/1p3q1p/5R2/3P3p/8/5RP1/3Q2K1 b - - 0 51
master doesn't see that this is a lost position (draw eval up to depth 50) as
Qf6-e6 d4-d5 (found by patch at depth 23) leads to a loss.
The 3fold-blindness is more important at longer TC, the patch was yellow STC and
LTC, but passed VLTC:
STC
LLR: -2.95 (-2.94,2.94) [0.00,5.00]
Total: 46328 W: 10048 L: 9953 D: 26327
http://tests.stockfishchess.org/tests/view/5b9c0ca20ebc592cf275f7c7
LTC
LLR: -2.95 (-2.94,2.94) [0.00,5.00]
Total: 54663 W: 8938 L: 8846 D: 36879
http://tests.stockfishchess.org/tests/view/5b9ca1610ebc592cf27601d3
VLTC
LLR: 2.95 (-2.94,2.94) [0.00,5.00]
Total: 31789 W: 4512 L: 4284 D: 22993
http://tests.stockfishchess.org/tests/view/5b9d1a670ebc592cf276076d
Credit to @crossbr for pointing to this problem repeatedly, and giving the hint
that many draw lines are typical in those situations.
Bench: 4756639
2018-10-14 12:33:24 -06:00
|
|
|
// and to avoid 3fold-blindness.
|
|
|
|
Value value_draw(Depth depth, Thread* thisThread) {
|
2018-11-19 23:45:00 -07:00
|
|
|
return depth < 4 ? VALUE_DRAW
|
Randomize draw eval
The patch adds a small random component (+-1) to VALUE_DRAW for the evaluation
of draw positions (mostly 3folds). This random component is not static, but
potentially different for each visit of the node (hence derived from the node
counter). The effect is that in positions with many 3fold draw lines, different
lines are followed at each iteration. This keeps the search much more dynamic,
as opposed to being locked to one particular 3fold.
An example of a position where master suffers from 3fold-blindness and this patch
solves quickly is the famous TCEC game 53:
FEN: 3r2k1/pr6/1p3q1p/5R2/3P3p/8/5RP1/3Q2K1 b - - 0 51
master doesn't see that this is a lost position (draw eval up to depth 50) as
Qf6-e6 d4-d5 (found by patch at depth 23) leads to a loss.
The 3fold-blindness is more important at longer TC, the patch was yellow STC and
LTC, but passed VLTC:
STC
LLR: -2.95 (-2.94,2.94) [0.00,5.00]
Total: 46328 W: 10048 L: 9953 D: 26327
http://tests.stockfishchess.org/tests/view/5b9c0ca20ebc592cf275f7c7
LTC
LLR: -2.95 (-2.94,2.94) [0.00,5.00]
Total: 54663 W: 8938 L: 8846 D: 36879
http://tests.stockfishchess.org/tests/view/5b9ca1610ebc592cf27601d3
VLTC
LLR: 2.95 (-2.94,2.94) [0.00,5.00]
Total: 31789 W: 4512 L: 4284 D: 22993
http://tests.stockfishchess.org/tests/view/5b9d1a670ebc592cf276076d
Credit to @crossbr for pointing to this problem repeatedly, and giving the hint
that many draw lines are typical in those situations.
Bench: 4756639
2018-10-14 12:33:24 -06:00
|
|
|
: VALUE_DRAW + Value(2 * (thisThread->nodes.load(std::memory_order_relaxed) % 2) - 1);
|
|
|
|
}
|
|
|
|
|
2016-01-16 14:34:29 -07:00
|
|
|
// Skill structure is used to implement strength limit
|
2015-01-31 02:43:47 -07:00
|
|
|
struct Skill {
|
2017-10-10 23:49:58 -06:00
|
|
|
explicit Skill(int l) : level(l) {}
|
2015-01-31 02:43:47 -07:00
|
|
|
bool enabled() const { return level < 20; }
|
|
|
|
bool time_to_pick(Depth depth) const { return depth / ONE_PLY == 1 + level; }
|
|
|
|
Move pick_best(size_t multiPV);
|
2010-02-07 01:53:15 -07:00
|
|
|
|
2015-01-31 02:43:47 -07:00
|
|
|
int level;
|
|
|
|
Move best = MOVE_NONE;
|
|
|
|
};
|
2010-02-07 01:53:15 -07:00
|
|
|
|
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
|
|
|
template <NodeType NT>
|
2018-05-08 02:43:46 -06:00
|
|
|
Value search(Position& pos, Stack* ss, Value alpha, Value beta, Depth depth, bool cutNode);
|
2010-05-08 02:54:51 -06:00
|
|
|
|
2018-03-13 01:10:59 -06:00
|
|
|
template <NodeType NT>
|
2016-12-20 03:17:38 -07:00
|
|
|
Value qsearch(Position& pos, Stack* ss, Value alpha, Value beta, Depth depth = DEPTH_ZERO);
|
2010-10-16 03:01:45 -06:00
|
|
|
|
2010-07-15 03:00:20 -06:00
|
|
|
Value value_to_tt(Value v, int ply);
|
|
|
|
Value value_from_tt(Value v, int ply);
|
2014-11-21 01:10:52 -07:00
|
|
|
void update_pv(Move* pv, Move move, Move* childPv);
|
2017-06-30 09:20:00 -06:00
|
|
|
void update_continuation_histories(Stack* ss, Piece pc, Square to, int bonus);
|
2019-01-01 06:10:26 -07:00
|
|
|
void update_quiet_stats(const Position& pos, Stack* ss, Move move, Move* quiets, int quietCount, int bonus);
|
|
|
|
void update_capture_stats(const Position& pos, Move move, Move* captures, int captureCount, int bonus);
|
2008-08-31 23:59:13 -06:00
|
|
|
|
2018-02-26 17:18:33 -07:00
|
|
|
inline bool gives_check(const Position& pos, Move move) {
|
|
|
|
Color us = pos.side_to_move();
|
|
|
|
return type_of(move) == NORMAL && !(pos.blockers_for_king(~us) & pos.pieces(us))
|
|
|
|
? pos.check_squares(type_of(pos.moved_piece(move))) & to_sq(move)
|
|
|
|
: pos.gives_check(move);
|
|
|
|
}
|
|
|
|
|
2017-08-15 02:05:22 -06:00
|
|
|
// perft() is our utility to verify move generation. All the leaf nodes up
|
|
|
|
// to the given depth are generated and counted, and the sum is returned.
|
|
|
|
template<bool Root>
|
|
|
|
uint64_t perft(Position& pos, Depth depth) {
|
|
|
|
|
|
|
|
StateInfo st;
|
|
|
|
uint64_t cnt, nodes = 0;
|
|
|
|
const bool leaf = (depth == 2 * ONE_PLY);
|
|
|
|
|
|
|
|
for (const auto& m : MoveList<LEGAL>(pos))
|
|
|
|
{
|
|
|
|
if (Root && depth <= ONE_PLY)
|
|
|
|
cnt = 1, nodes++;
|
|
|
|
else
|
|
|
|
{
|
|
|
|
pos.do_move(m, st);
|
|
|
|
cnt = leaf ? MoveList<LEGAL>(pos).size() : perft<false>(pos, depth - ONE_PLY);
|
|
|
|
nodes += cnt;
|
|
|
|
pos.undo_move(m);
|
|
|
|
}
|
|
|
|
if (Root)
|
|
|
|
sync_cout << UCI::move(m, pos.is_chess960()) << ": " << cnt << sync_endl;
|
|
|
|
}
|
|
|
|
return nodes;
|
|
|
|
}
|
|
|
|
|
2011-01-16 15:40:06 -07:00
|
|
|
} // namespace
|
2008-08-31 23:59:13 -06:00
|
|
|
|
|
|
|
|
2018-02-12 14:57:42 -07:00
|
|
|
/// Search::init() is called at startup to initialize various lookup tables
|
2008-08-31 23:59:13 -06:00
|
|
|
|
2011-11-26 04:07:35 -07:00
|
|
|
void Search::init() {
|
2010-06-01 14:28:45 -06:00
|
|
|
|
2019-03-03 07:53:36 -07:00
|
|
|
for (int i = 1; i < 64; ++i)
|
|
|
|
Reductions[i] = int(1024 * std::log(i) / std::sqrt(1.95));
|
2010-06-01 14:28:45 -06:00
|
|
|
}
|
|
|
|
|
|
|
|
|
2017-08-06 05:43:02 -06:00
|
|
|
/// Search::clear() resets search state to its initial value
|
2015-05-06 05:24:00 -06:00
|
|
|
|
2015-10-25 01:30:07 -06:00
|
|
|
void Search::clear() {
|
2015-05-06 05:24:00 -06:00
|
|
|
|
2017-08-06 05:43:02 -06:00
|
|
|
Threads.main()->wait_for_search_finished();
|
|
|
|
|
|
|
|
Time.availableNodes = 0;
|
2015-05-09 03:09:06 -06:00
|
|
|
TT.clear();
|
2017-12-26 02:40:42 -07:00
|
|
|
Threads.clear();
|
2018-10-27 14:12:34 -06:00
|
|
|
Tablebases::init(Options["SyzygyPath"]); // Free up mapped files
|
2015-05-06 05:24:00 -06:00
|
|
|
}
|
|
|
|
|
|
|
|
|
2015-11-05 00:40:23 -07:00
|
|
|
/// MainThread::search() is called by the main thread when the program receives
|
2016-01-16 14:34:29 -07:00
|
|
|
/// the UCI 'go' command. It searches from the root position and outputs the "bestmove".
|
2008-08-31 23:59:13 -06:00
|
|
|
|
2015-11-05 00:40:23 -07:00
|
|
|
void MainThread::search() {
|
2008-08-31 23:59:13 -06:00
|
|
|
|
2017-08-15 02:05:22 -06:00
|
|
|
if (Limits.perft)
|
|
|
|
{
|
|
|
|
nodes = perft<true>(rootPos, Limits.perft * ONE_PLY);
|
|
|
|
sync_cout << "\nNodes searched: " << nodes << "\n" << sync_endl;
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
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
|
|
|
Color us = rootPos.side_to_move();
|
|
|
|
Time.init(Limits, us, rootPos.game_ply());
|
2017-06-06 01:48:57 -06:00
|
|
|
TT.new_search();
|
2011-11-06 05:13:54 -07:00
|
|
|
|
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
|
|
|
if (rootMoves.empty())
|
2008-10-30 04:35:44 -06:00
|
|
|
{
|
2017-08-13 06:33:25 -06:00
|
|
|
rootMoves.emplace_back(MOVE_NONE);
|
2012-08-29 05:28:59 -06:00
|
|
|
sync_cout << "info depth 0 score "
|
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
|
|
|
<< UCI::value(rootPos.checkers() ? -VALUE_MATE : VALUE_DRAW)
|
2012-10-24 06:37:52 -06:00
|
|
|
<< sync_endl;
|
2012-01-14 03:45:54 -07:00
|
|
|
}
|
2014-11-10 06:46:05 -07:00
|
|
|
else
|
|
|
|
{
|
2015-01-18 00:00:50 -07:00
|
|
|
for (Thread* th : Threads)
|
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
|
|
|
if (th != this)
|
2015-11-20 23:48:50 -07:00
|
|
|
th->start_searching();
|
2012-01-14 03:45:54 -07:00
|
|
|
|
2015-11-05 00:40:23 -07:00
|
|
|
Thread::search(); // Let's start searching!
|
2014-11-10 06:46:05 -07:00
|
|
|
}
|
2013-05-03 02:25:25 -06:00
|
|
|
|
2013-12-02 11:04:09 -07:00
|
|
|
// When we reach the maximum depth, we can arrive here without a raise of
|
2017-07-13 17:07:19 -06:00
|
|
|
// Threads.stop. However, if we are pondering or in an infinite search,
|
2013-12-02 11:04:09 -07:00
|
|
|
// the UCI protocol states that we shouldn't print the best move before the
|
|
|
|
// GUI sends a "stop" or "ponderhit" command. We therefore simply wait here
|
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
|
|
|
// until the GUI sends one of those commands.
|
2017-08-04 11:48:07 -06:00
|
|
|
|
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
|
|
|
while (!Threads.stop && (ponder || Limits.infinite))
|
2017-08-04 11:48:07 -06:00
|
|
|
{} // Busy wait for a stop or a ponder reset
|
2010-12-30 08:18:22 -07:00
|
|
|
|
2017-08-04 11:48:07 -06:00
|
|
|
// Stop the threads if not already stopped (also raise the stop if
|
|
|
|
// "ponderhit" just reset Threads.ponder).
|
2017-07-13 17:07:19 -06:00
|
|
|
Threads.stop = true;
|
2015-11-09 01:50:02 -07:00
|
|
|
|
|
|
|
// Wait until all threads have finished
|
|
|
|
for (Thread* th : Threads)
|
|
|
|
if (th != this)
|
2015-11-20 23:48:50 -07:00
|
|
|
th->wait_for_search_finished();
|
2015-11-09 01:50:02 -07:00
|
|
|
|
2017-09-29 08:39:12 -06:00
|
|
|
// When playing in 'nodes as time' mode, subtract the searched nodes from
|
|
|
|
// the available ones before exiting.
|
|
|
|
if (Limits.npmsec)
|
|
|
|
Time.availableNodes += Limits.inc[us] - Threads.nodes_searched();
|
|
|
|
|
2015-12-23 02:07:54 -07:00
|
|
|
// Check if there are threads with a better score than main thread
|
2015-11-02 02:58:18 -07:00
|
|
|
Thread* bestThread = this;
|
Replace easyMove with simple scheme
Reduces time for a stable bestMove, giving some of the won time for the next move.
the version before the pvDraw passed both STC and LTC
passed STC:
http://tests.stockfishchess.org/tests/view/59e98d5a0ebc590ccbb896ec
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 78561 W: 13945 L: 13921 D: 50695
elo = 0.106 +- 1.445 LOS: 55.716%
passed LTC:
http://tests.stockfishchess.org/tests/view/59eb9df90ebc590ccbb897ae
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 29056 W: 3640 L: 3530 D: 21886
elo = 1.315 +- 1.982 LOS: 90.314%
This version, rebased on pvDrawPR with the obvious change, was verified again on STC:
http://tests.stockfishchess.org/tests/view/59ee104e0ebc590ccbb89899
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 19890 W: 3648 L: 3525 D: 12717
elo = 2.149 +- 2.895 LOS: 92.692%
and LTC:
http://tests.stockfishchess.org/tests/view/59f9673a0ebc590ccbb89ea0
Total : 17966
Win : 2273 ( 12.652%)
Loss : 2149 ( 11.961%)
Draw : 13544 ( 75.387%)
Score : 50.345%
Sensitivity : 0.014%
2*(W-L)/(W+L) : 5.608%
LLR [-3.0, 1.0] : 2.95
BayesElo range : [ -1.161, 4.876, 10.830] (DrawElo: 341.132)
LogisticElo range : [ -0.501, 2.105, 4.677]
LOS : 94.369 %
LTC again:
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 17966 W: 2273 L: 2149 D: 13544
LogisticElo range : [ -0.501, 2.105, 4.677]
LOS : 94.369 %
unchanged bench: 5234652
2017-11-03 06:51:53 -06:00
|
|
|
if ( Options["MultiPV"] == 1
|
2016-04-30 02:56:00 -06:00
|
|
|
&& !Limits.depth
|
2016-04-08 09:20:47 -06:00
|
|
|
&& !Skill(Options["Skill Level"]).enabled()
|
|
|
|
&& rootMoves[0].pv[0] != MOVE_NONE)
|
2015-12-23 02:07:54 -07:00
|
|
|
{
|
2018-12-18 00:50:57 -07:00
|
|
|
std::map<Move, int64_t> votes;
|
Introduce voting system for best move selection
Introduce voting system for best move selction in multi-threads mode.
Joint work with Stefan Geschwentner, based on ideas introduced by
Michael Stembera.
Moves are upvoted by every thread using the margin to the minimum score
across threads and the completed depth.
First thread voting for the winner move is selected as best thread.
Passed STC, LTC. A further LTC test with only 4 threads failed with positive
score. A LTC with 31 threads was stopped with LLR 0.77 after 25k games to
avoid use of excessive resources (equivalent to 1.5M STC games).
Similar ideas were proposed by Michael Stembera 2 years ago #507, #508.
This implementation seems simpler and more understandable, the results
slightly more promising.
Further possible work:
1) Tweak of the formula using for assigning votes.
2) Use a different baseline for the score dependent part: maximum score
or winning probability could make more sense.
3) Assign votes in `Thread::Search` as iterations are completed and use
voting results to stop search.
4) Select best thread as the threads voting for best move with the highest
completed depth or, alternatively, vote on PV moves.
Link to SPRT tests
[stopped LTC, 31 threads 20+0.02](http://tests.stockfishchess.org/tests/view/5b61dc090ebc5902bdb95192)
LLR: 0.77 (-2.94,2.94) [0.00,5.00]
Total: 25602 W: 3977 L: 3850 D: 17775
Elo: 1.70 [-0.68,4.07] (95%)
[passed LTC, 8 threads 20+0.02](http://tests.stockfishchess.org/tests/view/5b5df5180ebc5902bdb9162d)
LLR: 2.96 (-2.94,2.94) [0.00,5.00]
Total: 44478 W: 7602 L: 7300 D: 29576
Elo: 1.92 [-0.29,3.94] (95%)
[failed LTC, 4 threads 20+0.02](http://tests.stockfishchess.org/tests/view/5b5f39ef0ebc5902bdb92792)
LLR: -2.94 (-2.94,2.94) [0.00,5.00]
Total: 29922 W: 5286 L: 5285 D: 19351
Elo: 0.48 [-1.98,3.10] (95%)
[passed STC, 4 threads 5+0.05](http://tests.stockfishchess.org/tests/view/5b5dbf0f0ebc5902bdb9131c)
LLR: 2.97 (-2.94,2.94) [0.00,5.00]
Total: 9108 W: 2033 L: 1858 D: 5217
Elo: 6.11 [1.26,10.89] (95%)
No functional change (in simple threat mode)
2018-07-04 13:54:38 -06:00
|
|
|
Value minScore = this->rootMoves[0].score;
|
|
|
|
|
|
|
|
// Find out minimum score and reset votes for moves which can be voted
|
2018-08-08 09:48:06 -06:00
|
|
|
for (Thread* th: Threads)
|
Introduce voting system for best move selection
Introduce voting system for best move selction in multi-threads mode.
Joint work with Stefan Geschwentner, based on ideas introduced by
Michael Stembera.
Moves are upvoted by every thread using the margin to the minimum score
across threads and the completed depth.
First thread voting for the winner move is selected as best thread.
Passed STC, LTC. A further LTC test with only 4 threads failed with positive
score. A LTC with 31 threads was stopped with LLR 0.77 after 25k games to
avoid use of excessive resources (equivalent to 1.5M STC games).
Similar ideas were proposed by Michael Stembera 2 years ago #507, #508.
This implementation seems simpler and more understandable, the results
slightly more promising.
Further possible work:
1) Tweak of the formula using for assigning votes.
2) Use a different baseline for the score dependent part: maximum score
or winning probability could make more sense.
3) Assign votes in `Thread::Search` as iterations are completed and use
voting results to stop search.
4) Select best thread as the threads voting for best move with the highest
completed depth or, alternatively, vote on PV moves.
Link to SPRT tests
[stopped LTC, 31 threads 20+0.02](http://tests.stockfishchess.org/tests/view/5b61dc090ebc5902bdb95192)
LLR: 0.77 (-2.94,2.94) [0.00,5.00]
Total: 25602 W: 3977 L: 3850 D: 17775
Elo: 1.70 [-0.68,4.07] (95%)
[passed LTC, 8 threads 20+0.02](http://tests.stockfishchess.org/tests/view/5b5df5180ebc5902bdb9162d)
LLR: 2.96 (-2.94,2.94) [0.00,5.00]
Total: 44478 W: 7602 L: 7300 D: 29576
Elo: 1.92 [-0.29,3.94] (95%)
[failed LTC, 4 threads 20+0.02](http://tests.stockfishchess.org/tests/view/5b5f39ef0ebc5902bdb92792)
LLR: -2.94 (-2.94,2.94) [0.00,5.00]
Total: 29922 W: 5286 L: 5285 D: 19351
Elo: 0.48 [-1.98,3.10] (95%)
[passed STC, 4 threads 5+0.05](http://tests.stockfishchess.org/tests/view/5b5dbf0f0ebc5902bdb9131c)
LLR: 2.97 (-2.94,2.94) [0.00,5.00]
Total: 9108 W: 2033 L: 1858 D: 5217
Elo: 6.11 [1.26,10.89] (95%)
No functional change (in simple threat mode)
2018-07-04 13:54:38 -06:00
|
|
|
minScore = std::min(minScore, th->rootMoves[0].score);
|
|
|
|
|
|
|
|
// Vote according to score and depth
|
2015-12-07 14:51:43 -07:00
|
|
|
for (Thread* th : Threads)
|
2019-01-01 06:13:08 -07:00
|
|
|
{
|
|
|
|
int64_t s = th->rootMoves[0].score - minScore + 1;
|
|
|
|
votes[th->rootMoves[0].pv[0]] += 200 + s * s * int(th->completedDepth);
|
|
|
|
}
|
Introduce voting system for best move selection
Introduce voting system for best move selction in multi-threads mode.
Joint work with Stefan Geschwentner, based on ideas introduced by
Michael Stembera.
Moves are upvoted by every thread using the margin to the minimum score
across threads and the completed depth.
First thread voting for the winner move is selected as best thread.
Passed STC, LTC. A further LTC test with only 4 threads failed with positive
score. A LTC with 31 threads was stopped with LLR 0.77 after 25k games to
avoid use of excessive resources (equivalent to 1.5M STC games).
Similar ideas were proposed by Michael Stembera 2 years ago #507, #508.
This implementation seems simpler and more understandable, the results
slightly more promising.
Further possible work:
1) Tweak of the formula using for assigning votes.
2) Use a different baseline for the score dependent part: maximum score
or winning probability could make more sense.
3) Assign votes in `Thread::Search` as iterations are completed and use
voting results to stop search.
4) Select best thread as the threads voting for best move with the highest
completed depth or, alternatively, vote on PV moves.
Link to SPRT tests
[stopped LTC, 31 threads 20+0.02](http://tests.stockfishchess.org/tests/view/5b61dc090ebc5902bdb95192)
LLR: 0.77 (-2.94,2.94) [0.00,5.00]
Total: 25602 W: 3977 L: 3850 D: 17775
Elo: 1.70 [-0.68,4.07] (95%)
[passed LTC, 8 threads 20+0.02](http://tests.stockfishchess.org/tests/view/5b5df5180ebc5902bdb9162d)
LLR: 2.96 (-2.94,2.94) [0.00,5.00]
Total: 44478 W: 7602 L: 7300 D: 29576
Elo: 1.92 [-0.29,3.94] (95%)
[failed LTC, 4 threads 20+0.02](http://tests.stockfishchess.org/tests/view/5b5f39ef0ebc5902bdb92792)
LLR: -2.94 (-2.94,2.94) [0.00,5.00]
Total: 29922 W: 5286 L: 5285 D: 19351
Elo: 0.48 [-1.98,3.10] (95%)
[passed STC, 4 threads 5+0.05](http://tests.stockfishchess.org/tests/view/5b5dbf0f0ebc5902bdb9131c)
LLR: 2.97 (-2.94,2.94) [0.00,5.00]
Total: 9108 W: 2033 L: 1858 D: 5217
Elo: 6.11 [1.26,10.89] (95%)
No functional change (in simple threat mode)
2018-07-04 13:54:38 -06:00
|
|
|
|
|
|
|
// Select best thread
|
2019-01-01 06:13:08 -07:00
|
|
|
auto bestVote = votes[this->rootMoves[0].pv[0]];
|
2018-08-08 09:48:06 -06:00
|
|
|
for (Thread* th : Threads)
|
|
|
|
if (votes[th->rootMoves[0].pv[0]] > bestVote)
|
|
|
|
{
|
|
|
|
bestVote = votes[th->rootMoves[0].pv[0]];
|
|
|
|
bestThread = th;
|
Introduce voting system for best move selection
Introduce voting system for best move selction in multi-threads mode.
Joint work with Stefan Geschwentner, based on ideas introduced by
Michael Stembera.
Moves are upvoted by every thread using the margin to the minimum score
across threads and the completed depth.
First thread voting for the winner move is selected as best thread.
Passed STC, LTC. A further LTC test with only 4 threads failed with positive
score. A LTC with 31 threads was stopped with LLR 0.77 after 25k games to
avoid use of excessive resources (equivalent to 1.5M STC games).
Similar ideas were proposed by Michael Stembera 2 years ago #507, #508.
This implementation seems simpler and more understandable, the results
slightly more promising.
Further possible work:
1) Tweak of the formula using for assigning votes.
2) Use a different baseline for the score dependent part: maximum score
or winning probability could make more sense.
3) Assign votes in `Thread::Search` as iterations are completed and use
voting results to stop search.
4) Select best thread as the threads voting for best move with the highest
completed depth or, alternatively, vote on PV moves.
Link to SPRT tests
[stopped LTC, 31 threads 20+0.02](http://tests.stockfishchess.org/tests/view/5b61dc090ebc5902bdb95192)
LLR: 0.77 (-2.94,2.94) [0.00,5.00]
Total: 25602 W: 3977 L: 3850 D: 17775
Elo: 1.70 [-0.68,4.07] (95%)
[passed LTC, 8 threads 20+0.02](http://tests.stockfishchess.org/tests/view/5b5df5180ebc5902bdb9162d)
LLR: 2.96 (-2.94,2.94) [0.00,5.00]
Total: 44478 W: 7602 L: 7300 D: 29576
Elo: 1.92 [-0.29,3.94] (95%)
[failed LTC, 4 threads 20+0.02](http://tests.stockfishchess.org/tests/view/5b5f39ef0ebc5902bdb92792)
LLR: -2.94 (-2.94,2.94) [0.00,5.00]
Total: 29922 W: 5286 L: 5285 D: 19351
Elo: 0.48 [-1.98,3.10] (95%)
[passed STC, 4 threads 5+0.05](http://tests.stockfishchess.org/tests/view/5b5dbf0f0ebc5902bdb9131c)
LLR: 2.97 (-2.94,2.94) [0.00,5.00]
Total: 9108 W: 2033 L: 1858 D: 5217
Elo: 6.11 [1.26,10.89] (95%)
No functional change (in simple threat mode)
2018-07-04 13:54:38 -06:00
|
|
|
}
|
2015-12-23 02:07:54 -07:00
|
|
|
}
|
2015-11-02 02:58:18 -07:00
|
|
|
|
2016-01-16 01:03:56 -07:00
|
|
|
previousScore = bestThread->rootMoves[0].score;
|
2016-01-03 07:00:56 -07:00
|
|
|
|
2018-02-12 14:57:42 -07:00
|
|
|
// Send again PV info if we have a new best thread
|
2015-11-02 02:58:18 -07:00
|
|
|
if (bestThread != this)
|
|
|
|
sync_cout << UCI::pv(bestThread->rootPos, bestThread->completedDepth, -VALUE_INFINITE, VALUE_INFINITE) << sync_endl;
|
2014-11-23 17:53:00 -07:00
|
|
|
|
2015-11-02 02:58:18 -07:00
|
|
|
sync_cout << "bestmove " << UCI::move(bestThread->rootMoves[0].pv[0], rootPos.is_chess960());
|
|
|
|
|
|
|
|
if (bestThread->rootMoves[0].pv.size() > 1 || bestThread->rootMoves[0].extract_ponder_from_tt(rootPos))
|
|
|
|
std::cout << " ponder " << UCI::move(bestThread->rootMoves[0].pv[1], rootPos.is_chess960());
|
2014-11-23 17:53:00 -07:00
|
|
|
|
|
|
|
std::cout << sync_endl;
|
2008-08-31 23:59:13 -06:00
|
|
|
}
|
|
|
|
|
|
|
|
|
2017-03-14 22:00:03 -06:00
|
|
|
/// Thread::search() is the main iterative deepening loop. It calls search()
|
|
|
|
/// repeatedly with increasing depth until the allocated thinking time has been
|
|
|
|
/// consumed, the user stops the search, or the maximum search depth is reached.
|
2008-08-31 23:59:13 -06:00
|
|
|
|
2015-11-05 00:40:23 -07:00
|
|
|
void Thread::search() {
|
2008-08-31 23:59:13 -06:00
|
|
|
|
2018-12-19 13:04:36 -07:00
|
|
|
// To allow access to (ss-5) up to (ss+2), the stack must be oversized.
|
|
|
|
// The former is needed to allow update_continuation_histories(ss-1, ...),
|
|
|
|
// which accesses its argument at ss-4, also near the root.
|
|
|
|
// The latter is needed for statScores and killer initialization.
|
2019-02-27 13:25:12 -07:00
|
|
|
Stack stack[MAX_PLY+10], *ss = stack+7;
|
Fix a segfault.
this patch fixes a rare but reproducible segfault observed playing a
multi-threaded match, it is discussed somewhat in fishcooking.
From the core file, it could be observed that the issue was in qsearch, namely:
````
ss->pv[0] = MOVE_NONE;
````
and the backtrace shows the it arrives there via razoring, called from the rootNode:
````
(gdb) bt
alpha=-19, beta=682, depth=DEPTH_ZERO) at search.cpp:1247
````
Indeed, ss->pv can indeed by a nullptr at the rootNode. However, why is the
segfault so rare ?
The reason is that the condition that guards razoring:
````
(depth < 2 * ONE_PLY && eval <= alpha - RazorMargin)
````
is almost never true, since at the root alpha for depth < 5 is -VALUE_INFINITE.
Nevertheless with the new failHigh scheme, this is not guaranteed, and rootDepth > 5,
can still result in a depth < 2 search at the rootNode. If now another thread,
via the hash, writes a new low eval to the rootPos qsearch can be entered.
Rare but not unseen... I assume that some of the crashes in fishtest recently
might be due to this.
Closes https://github.com/official-stockfish/Stockfish/pull/1860
No functional change
2018-12-16 01:51:29 -07:00
|
|
|
Move pv[MAX_PLY+1];
|
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
|
|
|
Value bestValue, alpha, beta, delta;
|
Replace easyMove with simple scheme
Reduces time for a stable bestMove, giving some of the won time for the next move.
the version before the pvDraw passed both STC and LTC
passed STC:
http://tests.stockfishchess.org/tests/view/59e98d5a0ebc590ccbb896ec
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 78561 W: 13945 L: 13921 D: 50695
elo = 0.106 +- 1.445 LOS: 55.716%
passed LTC:
http://tests.stockfishchess.org/tests/view/59eb9df90ebc590ccbb897ae
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 29056 W: 3640 L: 3530 D: 21886
elo = 1.315 +- 1.982 LOS: 90.314%
This version, rebased on pvDrawPR with the obvious change, was verified again on STC:
http://tests.stockfishchess.org/tests/view/59ee104e0ebc590ccbb89899
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 19890 W: 3648 L: 3525 D: 12717
elo = 2.149 +- 2.895 LOS: 92.692%
and LTC:
http://tests.stockfishchess.org/tests/view/59f9673a0ebc590ccbb89ea0
Total : 17966
Win : 2273 ( 12.652%)
Loss : 2149 ( 11.961%)
Draw : 13544 ( 75.387%)
Score : 50.345%
Sensitivity : 0.014%
2*(W-L)/(W+L) : 5.608%
LLR [-3.0, 1.0] : 2.95
BayesElo range : [ -1.161, 4.876, 10.830] (DrawElo: 341.132)
LogisticElo range : [ -0.501, 2.105, 4.677]
LOS : 94.369 %
LTC again:
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 17966 W: 2273 L: 2149 D: 13544
LogisticElo range : [ -0.501, 2.105, 4.677]
LOS : 94.369 %
unchanged bench: 5234652
2017-11-03 06:51:53 -06:00
|
|
|
Move lastBestMove = MOVE_NONE;
|
|
|
|
Depth lastBestMoveDepth = DEPTH_ZERO;
|
2015-12-23 02:07:54 -07:00
|
|
|
MainThread* mainThread = (this == Threads.main() ? Threads.main() : nullptr);
|
Replace easyMove with simple scheme
Reduces time for a stable bestMove, giving some of the won time for the next move.
the version before the pvDraw passed both STC and LTC
passed STC:
http://tests.stockfishchess.org/tests/view/59e98d5a0ebc590ccbb896ec
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 78561 W: 13945 L: 13921 D: 50695
elo = 0.106 +- 1.445 LOS: 55.716%
passed LTC:
http://tests.stockfishchess.org/tests/view/59eb9df90ebc590ccbb897ae
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 29056 W: 3640 L: 3530 D: 21886
elo = 1.315 +- 1.982 LOS: 90.314%
This version, rebased on pvDrawPR with the obvious change, was verified again on STC:
http://tests.stockfishchess.org/tests/view/59ee104e0ebc590ccbb89899
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 19890 W: 3648 L: 3525 D: 12717
elo = 2.149 +- 2.895 LOS: 92.692%
and LTC:
http://tests.stockfishchess.org/tests/view/59f9673a0ebc590ccbb89ea0
Total : 17966
Win : 2273 ( 12.652%)
Loss : 2149 ( 11.961%)
Draw : 13544 ( 75.387%)
Score : 50.345%
Sensitivity : 0.014%
2*(W-L)/(W+L) : 5.608%
LLR [-3.0, 1.0] : 2.95
BayesElo range : [ -1.161, 4.876, 10.830] (DrawElo: 341.132)
LogisticElo range : [ -0.501, 2.105, 4.677]
LOS : 94.369 %
LTC again:
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 17966 W: 2273 L: 2149 D: 13544
LogisticElo range : [ -0.501, 2.105, 4.677]
LOS : 94.369 %
unchanged bench: 5234652
2017-11-03 06:51:53 -06:00
|
|
|
double timeReduction = 1.0;
|
Introduce dynamic contempt
Make contempt dependent on the current score of the root position.
The idea is that we now use a linear formula like the following to decide
on the contempt to use during a search :
contempt = x + y * eval
where x is the base contempt set by the user in the "Contempt" UCI option,
and y * eval is the dynamic part which adapts itself to the estimation of
the evaluation of the root position returned by the search. In this patch,
we use x = 18 centipawns by default, and the y * eval correction can go
from -20 centipawns if the root eval is less than -2.0 pawns, up to +20
centipawns when the root eval is more than 2.0 pawns.
To summarize, the new contempt goes from -0.02 to 0.38 pawns, depending if
Stockfish is losing or winning, with an average value of 0.18 pawns by default.
STC:
LLR: 2.95 (-2.94,2.94) [0.00,5.00]
Total: 110052 W: 24614 L: 23938 D: 61500
http://tests.stockfishchess.org/tests/view/5a72e6020ebc590f2c86ea20
LTC:
LLR: 2.97 (-2.94,2.94) [0.00,5.00]
Total: 16470 W: 2896 L: 2705 D: 10869
http://tests.stockfishchess.org/tests/view/5a76c5b90ebc5902971a9830
A second match at LTC was organised against the current master:
ELO: 1.45 +-2.9 (95%) LOS: 84.0%
Total: 19369 W: 3350 L: 3269 D: 12750
http://tests.stockfishchess.org/tests/view/5a7acf980ebc5902971a9a2e
Finally, we checked that there is no apparent problem with multithreading,
despite the fact that some threads might have a slightly different contempt
level that the main thread.
Match of this version against master, both using 5 threads, time control 30+0.3:
ELO: 2.18 +-3.2 (95%) LOS: 90.8%
Total: 14840 W: 2502 L: 2409 D: 9929
http://tests.stockfishchess.org/tests/view/5a7bf3e80ebc5902971a9aa2
Include suggestions from Marco Costalba, Aram Tumanian, Ronald de Man, etc.
Bench: 5207156
2018-02-09 10:43:53 -07:00
|
|
|
Color us = rootPos.side_to_move();
|
2018-06-11 01:46:05 -06:00
|
|
|
bool failedLow;
|
2008-10-30 04:35:44 -06:00
|
|
|
|
2019-02-27 13:25:12 -07:00
|
|
|
std::memset(ss-7, 0, 10 * sizeof(Stack));
|
|
|
|
for (int i = 7; i > 0; i--)
|
2018-07-28 07:33:39 -06:00
|
|
|
(ss-i)->continuationHistory = &this->continuationHistory[NO_PIECE][0]; // Use as sentinel
|
Fix a segfault.
this patch fixes a rare but reproducible segfault observed playing a
multi-threaded match, it is discussed somewhat in fishcooking.
From the core file, it could be observed that the issue was in qsearch, namely:
````
ss->pv[0] = MOVE_NONE;
````
and the backtrace shows the it arrives there via razoring, called from the rootNode:
````
(gdb) bt
alpha=-19, beta=682, depth=DEPTH_ZERO) at search.cpp:1247
````
Indeed, ss->pv can indeed by a nullptr at the rootNode. However, why is the
segfault so rare ?
The reason is that the condition that guards razoring:
````
(depth < 2 * ONE_PLY && eval <= alpha - RazorMargin)
````
is almost never true, since at the root alpha for depth < 5 is -VALUE_INFINITE.
Nevertheless with the new failHigh scheme, this is not guaranteed, and rootDepth > 5,
can still result in a depth < 2 search at the rootNode. If now another thread,
via the hash, writes a new low eval to the rootPos qsearch can be entered.
Rare but not unseen... I assume that some of the crashes in fishtest recently
might be due to this.
Closes https://github.com/official-stockfish/Stockfish/pull/1860
No functional change
2018-12-16 01:51:29 -07:00
|
|
|
ss->pv = pv;
|
2011-01-17 02:44:00 -07:00
|
|
|
|
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
|
|
|
bestValue = delta = alpha = -VALUE_INFINITE;
|
|
|
|
beta = VALUE_INFINITE;
|
2015-03-12 13:49:30 -06:00
|
|
|
|
2015-12-23 02:07:54 -07:00
|
|
|
if (mainThread)
|
2018-06-11 01:46:05 -06:00
|
|
|
mainThread->bestMoveChanges = 0, failedLow = false;
|
2013-07-03 10:58:49 -06:00
|
|
|
|
2018-02-04 13:42:56 -07:00
|
|
|
size_t multiPV = Options["MultiPV"];
|
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
|
|
|
Skill skill(Options["Skill Level"]);
|
2013-07-03 10:58:49 -06:00
|
|
|
|
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
|
|
|
// When playing with strength handicap enable MultiPV search that we will
|
|
|
|
// use behind the scenes to retrieve a set of possible moves.
|
|
|
|
if (skill.enabled())
|
|
|
|
multiPV = std::max(multiPV, (size_t)4);
|
2015-03-29 01:24:17 -06:00
|
|
|
|
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
|
|
|
multiPV = std::min(multiPV, rootMoves.size());
|
2012-10-24 04:05:20 -06:00
|
|
|
|
2018-04-18 20:16:19 -06:00
|
|
|
int ct = int(Options["Contempt"]) * PawnValueEg / 100; // From centipawns
|
Analysis Contempt combo box
This patch introduces an Analysis Contempt UCI combo box to control
the behaviour of contempt during analysis. The possible values are
Both, Off, White, Black. Technically, the engine is supposed to be in
analysis mode if UCI_AnalyseMode is set by the graphical user interface
or if the user has chosen infinite analysis mode ("go infinite").
Credits: the idea for the combo box is due to Michel Van den Bergh.
No functional change (outside analysis mode).
-----------------------------------------------------
The so-called "contempt" is an optimism value that the engine adds
to one color to avoid simplifications and keep tension in the position
during its search. It was introduced in Stockfish 9 and seemed to give
good results during the TCEC 11 tournament (Stockfish seemed to play a
little bit more actively than in previous seasons).
The patch does not change the play during match or blitz play, but gives
more options for correspondance players to decide for which color(s) they
would like to use contempt in analysis mode (infinite time). Here is a
description of the various options:
* Both : in analysis mode, use the contempt for both players (alternating)
* Off : in analysis mode, use the contempt for none of the players
* White : in analysis mode, White will play actively, Black will play passively
* Black : in analysis mode, Black will play actively, White will play passively
2018-04-18 09:30:00 -06:00
|
|
|
|
|
|
|
// In analysis mode, adjust contempt in accordance with user preference
|
|
|
|
if (Limits.infinite || Options["UCI_AnalyseMode"])
|
|
|
|
ct = Options["Analysis Contempt"] == "Off" ? 0
|
|
|
|
: Options["Analysis Contempt"] == "Both" ? ct
|
|
|
|
: Options["Analysis Contempt"] == "White" && us == BLACK ? -ct
|
|
|
|
: Options["Analysis Contempt"] == "Black" && us == WHITE ? -ct
|
|
|
|
: ct;
|
|
|
|
|
|
|
|
// In evaluate.cpp the evaluation is from the white point of view
|
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
|
|
|
contempt = (us == WHITE ? make_score(ct, ct / 2)
|
|
|
|
: -make_score(ct, ct / 2));
|
Introduce dynamic contempt
Make contempt dependent on the current score of the root position.
The idea is that we now use a linear formula like the following to decide
on the contempt to use during a search :
contempt = x + y * eval
where x is the base contempt set by the user in the "Contempt" UCI option,
and y * eval is the dynamic part which adapts itself to the estimation of
the evaluation of the root position returned by the search. In this patch,
we use x = 18 centipawns by default, and the y * eval correction can go
from -20 centipawns if the root eval is less than -2.0 pawns, up to +20
centipawns when the root eval is more than 2.0 pawns.
To summarize, the new contempt goes from -0.02 to 0.38 pawns, depending if
Stockfish is losing or winning, with an average value of 0.18 pawns by default.
STC:
LLR: 2.95 (-2.94,2.94) [0.00,5.00]
Total: 110052 W: 24614 L: 23938 D: 61500
http://tests.stockfishchess.org/tests/view/5a72e6020ebc590f2c86ea20
LTC:
LLR: 2.97 (-2.94,2.94) [0.00,5.00]
Total: 16470 W: 2896 L: 2705 D: 10869
http://tests.stockfishchess.org/tests/view/5a76c5b90ebc5902971a9830
A second match at LTC was organised against the current master:
ELO: 1.45 +-2.9 (95%) LOS: 84.0%
Total: 19369 W: 3350 L: 3269 D: 12750
http://tests.stockfishchess.org/tests/view/5a7acf980ebc5902971a9a2e
Finally, we checked that there is no apparent problem with multithreading,
despite the fact that some threads might have a slightly different contempt
level that the main thread.
Match of this version against master, both using 5 threads, time control 30+0.3:
ELO: 2.18 +-3.2 (95%) LOS: 90.8%
Total: 14840 W: 2502 L: 2409 D: 9929
http://tests.stockfishchess.org/tests/view/5a7bf3e80ebc5902971a9aa2
Include suggestions from Marco Costalba, Aram Tumanian, Ronald de Man, etc.
Bench: 5207156
2018-02-09 10:43:53 -07:00
|
|
|
|
2016-08-19 04:17:38 -06:00
|
|
|
// Iterative deepening loop until requested to stop or the target depth is reached
|
2017-07-02 04:10:50 -06:00
|
|
|
while ( (rootDepth += ONE_PLY) < DEPTH_MAX
|
2017-07-13 17:07:19 -06:00
|
|
|
&& !Threads.stop
|
2017-07-02 04:10:50 -06:00
|
|
|
&& !(Limits.depth && mainThread && rootDepth / ONE_PLY > Limits.depth))
|
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
|
|
|
{
|
2018-02-12 14:57:42 -07:00
|
|
|
// Distribute search depths across the helper threads
|
|
|
|
if (idx > 0)
|
2017-03-14 22:00:03 -06:00
|
|
|
{
|
|
|
|
int i = (idx - 1) % 20;
|
2018-07-05 10:33:18 -06:00
|
|
|
if (((rootDepth / ONE_PLY + SkipPhase[i]) / SkipSize[i]) % 2)
|
2018-02-12 14:57:42 -07:00
|
|
|
continue; // Retry with an incremented rootDepth
|
2017-03-14 22:00:03 -06:00
|
|
|
}
|
2015-01-25 03:07:43 -07:00
|
|
|
|
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
|
|
|
// Age out PV variability metric
|
2015-12-23 02:07:54 -07:00
|
|
|
if (mainThread)
|
2018-06-11 01:46:05 -06:00
|
|
|
mainThread->bestMoveChanges *= 0.517, failedLow = false;
|
2012-10-24 04:05:20 -06:00
|
|
|
|
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
|
|
|
// Save the last iteration's scores before first PV line is searched and
|
|
|
|
// all the move scores except the (new) PV are set to -VALUE_INFINITE.
|
|
|
|
for (RootMove& rm : rootMoves)
|
|
|
|
rm.previousScore = rm.score;
|
2013-08-24 10:29:44 -06:00
|
|
|
|
2018-06-02 09:41:37 -06:00
|
|
|
size_t pvFirst = 0;
|
|
|
|
pvLast = 0;
|
2018-04-18 10:38:38 -06:00
|
|
|
|
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
|
|
|
// MultiPV loop. We perform a full root search for each PV line
|
2018-06-02 09:41:37 -06:00
|
|
|
for (pvIdx = 0; pvIdx < multiPV && !Threads.stop; ++pvIdx)
|
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
|
|
|
{
|
2018-06-02 09:41:37 -06:00
|
|
|
if (pvIdx == pvLast)
|
2018-04-18 10:38:38 -06:00
|
|
|
{
|
2018-06-02 09:41:37 -06:00
|
|
|
pvFirst = pvLast;
|
|
|
|
for (pvLast++; pvLast < rootMoves.size(); pvLast++)
|
|
|
|
if (rootMoves[pvLast].tbRank != rootMoves[pvFirst].tbRank)
|
2018-04-18 10:38:38 -06:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
2017-07-13 17:30:03 -06:00
|
|
|
// Reset UCI info selDepth for each depth and each PV line
|
|
|
|
selDepth = 0;
|
|
|
|
|
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
|
|
|
// Reset aspiration window starting size
|
2015-10-23 23:27:24 -06:00
|
|
|
if (rootDepth >= 5 * ONE_PLY)
|
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
|
|
|
{
|
2018-06-02 09:41:37 -06:00
|
|
|
Value previousScore = rootMoves[pvIdx].previousScore;
|
Combo
Combo of two parameter tweaks and tuned values for Queen and ThreatByKing.
STC
LLR: 2.95 (-2.94,2.94) [0.00,4.00]
Total: 20180 W: 4439 L: 4198 D: 11543
http://tests.stockfishchess.org/tests/view/5bd7b8250ebc595e0ae22e97
LTC
LLR: 2.95 (-2.94,2.94) [0.00,4.00]
Total: 86312 W: 14106 L: 13685 D: 58521
http://tests.stockfishchess.org/tests/view/5bd803560ebc595e0ae23213
This combo consists of the following:
Queen Value (tuned values)
Iter: 72056, A: 5000, alpha 0.602000, gamma 0.101000, clipping old, rounding deterministic
param: QueenValueMg, best: 2528.91, start: 2528.00
param: QueenValueEg, best: 2687.12, start: 2698.00
ThreatByKing (tuned values)
Green STC (50.8k games)
http://tests.stockfishchess.org/tests/view/5bd1d5a00ebc595e0ae1cbec
LTC (I stopped this test at 71.2k games. It's likely yellow.)
http://tests.stockfishchess.org/tests/view/5bd263e70ebc595e0ae1d77e
WeakUnopposedPawn (tweak) by xoto (https://github.com/xoto10)
Green STC (102.8k games)
http://tests.stockfishchess.org/tests/view/5bd306bb0ebc595e0ae1e146
Yellow LTC (90.8k games)
http://tests.stockfishchess.org/tests/view/5bd3ea660ebc595e0ae1f16b
aspiTune1 (tweak) by vondele (https://github.com/vondele)
Green STC (125.9k games)
http://tests.stockfishchess.org/tests/view/5bd2ae100ebc595e0ae1dab0
Yellow LTC (107.9k games)
http://tests.stockfishchess.org/tests/view/5bd3eb700ebc595e0ae1f16f
Thank you @31m059 (Mark Tenzer) for helping me! Also, thank you very much
for recognizing my efforts. I genuinely appreciate it.
Bench: 3556672
2018-10-31 10:48:16 -06:00
|
|
|
delta = Value(20);
|
Fix dynamic contempt for MultiPV
Use rootMoves[PVIdx].previousScore instead of bestValue for
dynamic contempt. This is equivalent for MultiPV=1 (bench remained the
same, even for higher depths), but more correct for MultiPV.
STC (MultiPV=3):
LLR: 2.95 (-2.94,2.94) [0.00,5.00]
Total: 2657 W: 1079 L: 898 D: 680
http://tests.stockfishchess.org/tests/view/5aaa47cb0ebc590297330403
LTC (MultiPV=3):
LLR: 2.95 (-2.94,2.94) [0.00,5.00]
Total: 2390 W: 874 L: 706 D: 810
http://tests.stockfishchess.org/tests/view/5aaa593a0ebc59029733040b
VLTC 240+2.4 (MultiPV=3):
LLR: 2.96 (-2.94,2.94) [0.00,5.00]
Total: 2399 W: 861 L: 694 D: 844
http://tests.stockfishchess.org/tests/view/5aaf983e0ebc5902a182131f
LTC (MultiPV=4, Skill Level=17):
LLR: 2.95 (-2.94,2.94) [0.00,5.00]
Total: 747 W: 333 L: 175 D: 239
http://tests.stockfishchess.org/tests/view/5aabccee0ebc5902997ff006
Note: although the ELO differences seem huge, they are inflated by the
nature of Skill Level / MultiPV search, so I don't think they can be
reasonably compared with classic ELO strength.
See https://github.com/official-stockfish/Stockfish/pull/1491 for some
verifications searches with MultiPV = 10 at depths 12 and 24 from the
starting position and the position after 1.e4, comparing the outputs
of the full PV by the old master and by this patch.
No functional change for MultiPV=1
2018-03-14 09:47:45 -06:00
|
|
|
alpha = std::max(previousScore - delta,-VALUE_INFINITE);
|
|
|
|
beta = std::min(previousScore + delta, VALUE_INFINITE);
|
Introduce dynamic contempt
Make contempt dependent on the current score of the root position.
The idea is that we now use a linear formula like the following to decide
on the contempt to use during a search :
contempt = x + y * eval
where x is the base contempt set by the user in the "Contempt" UCI option,
and y * eval is the dynamic part which adapts itself to the estimation of
the evaluation of the root position returned by the search. In this patch,
we use x = 18 centipawns by default, and the y * eval correction can go
from -20 centipawns if the root eval is less than -2.0 pawns, up to +20
centipawns when the root eval is more than 2.0 pawns.
To summarize, the new contempt goes from -0.02 to 0.38 pawns, depending if
Stockfish is losing or winning, with an average value of 0.18 pawns by default.
STC:
LLR: 2.95 (-2.94,2.94) [0.00,5.00]
Total: 110052 W: 24614 L: 23938 D: 61500
http://tests.stockfishchess.org/tests/view/5a72e6020ebc590f2c86ea20
LTC:
LLR: 2.97 (-2.94,2.94) [0.00,5.00]
Total: 16470 W: 2896 L: 2705 D: 10869
http://tests.stockfishchess.org/tests/view/5a76c5b90ebc5902971a9830
A second match at LTC was organised against the current master:
ELO: 1.45 +-2.9 (95%) LOS: 84.0%
Total: 19369 W: 3350 L: 3269 D: 12750
http://tests.stockfishchess.org/tests/view/5a7acf980ebc5902971a9a2e
Finally, we checked that there is no apparent problem with multithreading,
despite the fact that some threads might have a slightly different contempt
level that the main thread.
Match of this version against master, both using 5 threads, time control 30+0.3:
ELO: 2.18 +-3.2 (95%) LOS: 90.8%
Total: 14840 W: 2502 L: 2409 D: 9929
http://tests.stockfishchess.org/tests/view/5a7bf3e80ebc5902971a9aa2
Include suggestions from Marco Costalba, Aram Tumanian, Ronald de Man, etc.
Bench: 5207156
2018-02-09 10:43:53 -07:00
|
|
|
|
Fix dynamic contempt for MultiPV
Use rootMoves[PVIdx].previousScore instead of bestValue for
dynamic contempt. This is equivalent for MultiPV=1 (bench remained the
same, even for higher depths), but more correct for MultiPV.
STC (MultiPV=3):
LLR: 2.95 (-2.94,2.94) [0.00,5.00]
Total: 2657 W: 1079 L: 898 D: 680
http://tests.stockfishchess.org/tests/view/5aaa47cb0ebc590297330403
LTC (MultiPV=3):
LLR: 2.95 (-2.94,2.94) [0.00,5.00]
Total: 2390 W: 874 L: 706 D: 810
http://tests.stockfishchess.org/tests/view/5aaa593a0ebc59029733040b
VLTC 240+2.4 (MultiPV=3):
LLR: 2.96 (-2.94,2.94) [0.00,5.00]
Total: 2399 W: 861 L: 694 D: 844
http://tests.stockfishchess.org/tests/view/5aaf983e0ebc5902a182131f
LTC (MultiPV=4, Skill Level=17):
LLR: 2.95 (-2.94,2.94) [0.00,5.00]
Total: 747 W: 333 L: 175 D: 239
http://tests.stockfishchess.org/tests/view/5aabccee0ebc5902997ff006
Note: although the ELO differences seem huge, they are inflated by the
nature of Skill Level / MultiPV search, so I don't think they can be
reasonably compared with classic ELO strength.
See https://github.com/official-stockfish/Stockfish/pull/1491 for some
verifications searches with MultiPV = 10 at depths 12 and 24 from the
starting position and the position after 1.e4, comparing the outputs
of the full PV by the old master and by this patch.
No functional change for MultiPV=1
2018-03-14 09:47:45 -06:00
|
|
|
// Adjust contempt based on root move's previousScore (dynamic contempt)
|
2018-04-23 01:13:07 -06:00
|
|
|
int dct = ct + 88 * previousScore / (abs(previousScore) + 200);
|
Introduce dynamic contempt
Make contempt dependent on the current score of the root position.
The idea is that we now use a linear formula like the following to decide
on the contempt to use during a search :
contempt = x + y * eval
where x is the base contempt set by the user in the "Contempt" UCI option,
and y * eval is the dynamic part which adapts itself to the estimation of
the evaluation of the root position returned by the search. In this patch,
we use x = 18 centipawns by default, and the y * eval correction can go
from -20 centipawns if the root eval is less than -2.0 pawns, up to +20
centipawns when the root eval is more than 2.0 pawns.
To summarize, the new contempt goes from -0.02 to 0.38 pawns, depending if
Stockfish is losing or winning, with an average value of 0.18 pawns by default.
STC:
LLR: 2.95 (-2.94,2.94) [0.00,5.00]
Total: 110052 W: 24614 L: 23938 D: 61500
http://tests.stockfishchess.org/tests/view/5a72e6020ebc590f2c86ea20
LTC:
LLR: 2.97 (-2.94,2.94) [0.00,5.00]
Total: 16470 W: 2896 L: 2705 D: 10869
http://tests.stockfishchess.org/tests/view/5a76c5b90ebc5902971a9830
A second match at LTC was organised against the current master:
ELO: 1.45 +-2.9 (95%) LOS: 84.0%
Total: 19369 W: 3350 L: 3269 D: 12750
http://tests.stockfishchess.org/tests/view/5a7acf980ebc5902971a9a2e
Finally, we checked that there is no apparent problem with multithreading,
despite the fact that some threads might have a slightly different contempt
level that the main thread.
Match of this version against master, both using 5 threads, time control 30+0.3:
ELO: 2.18 +-3.2 (95%) LOS: 90.8%
Total: 14840 W: 2502 L: 2409 D: 9929
http://tests.stockfishchess.org/tests/view/5a7bf3e80ebc5902971a9aa2
Include suggestions from Marco Costalba, Aram Tumanian, Ronald de Man, etc.
Bench: 5207156
2018-02-09 10:43:53 -07:00
|
|
|
|
Analysis Contempt combo box
This patch introduces an Analysis Contempt UCI combo box to control
the behaviour of contempt during analysis. The possible values are
Both, Off, White, Black. Technically, the engine is supposed to be in
analysis mode if UCI_AnalyseMode is set by the graphical user interface
or if the user has chosen infinite analysis mode ("go infinite").
Credits: the idea for the combo box is due to Michel Van den Bergh.
No functional change (outside analysis mode).
-----------------------------------------------------
The so-called "contempt" is an optimism value that the engine adds
to one color to avoid simplifications and keep tension in the position
during its search. It was introduced in Stockfish 9 and seemed to give
good results during the TCEC 11 tournament (Stockfish seemed to play a
little bit more actively than in previous seasons).
The patch does not change the play during match or blitz play, but gives
more options for correspondance players to decide for which color(s) they
would like to use contempt in analysis mode (infinite time). Here is a
description of the various options:
* Both : in analysis mode, use the contempt for both players (alternating)
* Off : in analysis mode, use the contempt for none of the players
* White : in analysis mode, White will play actively, Black will play passively
* Black : in analysis mode, Black will play actively, White will play passively
2018-04-18 09:30:00 -06:00
|
|
|
contempt = (us == WHITE ? make_score(dct, dct / 2)
|
|
|
|
: -make_score(dct, dct / 2));
|
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
|
|
|
}
|
2009-04-11 07:46:35 -06:00
|
|
|
|
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
|
|
|
// Start with a small aspiration window and, in the case of a fail
|
2018-02-12 14:57:42 -07:00
|
|
|
// high/low, re-search with a bigger window until we don't fail
|
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
|
|
|
// high/low anymore.
|
2018-10-19 02:33:01 -06:00
|
|
|
int failedHighCnt = 0;
|
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
|
|
|
while (true)
|
|
|
|
{
|
Fix issues from using adjustedDepth too broadly
The recently committed Fail-High patch (081af9080542a0d076a5482da37103a96ee15f64)
had a number of changes beyond adjusting the depth of search on fail high, with
some undesirable side effects.
1) Decreasing depth on PV output, confusing GUIs and players alike as described in
issue #1787. The depth printed is anyway a convention, let's consider adjustedDepth
an implementation detail, and continue to print rootDepth. Depth, nodes, time and
move quality all increase as we compute more. (fixing this output has no effect on
play).
2) Fixes go depth output (now based on rootDepth again, no effect on play), also
reported in issue #1787
3) The depth lastBestDepth is used to compute how long a move is stable, a new move
found during fail-high is incorrectly considered stable if based on adjustedDepth
instead of rootDepth (this changes time management). Reverting this passed STC
and LTC:
STC
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 82982 W: 17810 L: 17808 D: 47364
http://tests.stockfishchess.org/tests/view/5bd391a80ebc595e0ae1e993
LTC
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 109083 W: 17602 L: 17619 D: 73862
http://tests.stockfishchess.org/tests/view/5bd40c820ebc595e0ae1f1fb
4) In the thread voting scheme, the rank of the fail-high thread is now artificially
low, incorrectly since the quality of the move is much better than what adjustedDepth
suggests (e.g. if it takes 10 iterations to find VALUE_KNOWN_WIN, it has very low
depth). Further evidence comes from a test that showed that the move of highest
depth is not better than that of the last PV (which is potentially of much lower
adjustedDepth).
I.e. this test http://tests.stockfishchess.org/tests/view/5bd37a120ebc595e0ae1e7c3
failed SPRT[0, 5]:
LLR: -2.95 (-2.94,2.94) [0.00,5.00]
Total: 10609 W: 2266 L: 2345 D: 5998
In a running 5+0.05 th 8 test (more than 10000 games) a positive Elo estimate is
shown (strong enough for a [-3,1], possibly not [0,4]):
http://tests.stockfishchess.org/tests/view/5bd421be0ebc595e0ae1f315
LLR: -0.13 (-2.94,2.94) [0.00,4.00]
Total: 13644 W: 2573 L: 2532 D: 8539
Elo 1.04 [-2.52,4.61] / LOS 71%
Thus, restore old behavior as a bugfix, keeping the core of the fail-high patch
idea as resolving scheme. This is non-functional for bench, but changes searches
via time management and in the threaded case.
Bench: 3556672
2018-10-28 08:25:15 -06:00
|
|
|
Depth adjustedDepth = std::max(ONE_PLY, rootDepth - failedHighCnt * ONE_PLY);
|
2018-10-19 02:33:01 -06:00
|
|
|
bestValue = ::search<PV>(rootPos, ss, alpha, beta, adjustedDepth, false);
|
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
|
|
|
|
|
|
|
// Bring the best move to the front. It is critical that sorting
|
|
|
|
// is done with a stable algorithm because all the values but the
|
|
|
|
// first and eventually the new best one are set to -VALUE_INFINITE
|
|
|
|
// and we want to keep the same order for all the moves except the
|
|
|
|
// new PV that goes to the front. Note that in case of MultiPV
|
|
|
|
// search the already searched PV lines are preserved.
|
2018-06-02 09:41:37 -06:00
|
|
|
std::stable_sort(rootMoves.begin() + pvIdx, rootMoves.begin() + pvLast);
|
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
|
|
|
|
2018-02-12 14:57:42 -07:00
|
|
|
// If search has been stopped, we break immediately. Sorting is
|
|
|
|
// safe because RootMoves is still valid, although it refers to
|
|
|
|
// the previous iteration.
|
2017-07-13 17:07:19 -06:00
|
|
|
if (Threads.stop)
|
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
|
|
|
break;
|
2011-02-28 12:17:57 -07:00
|
|
|
|
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
|
|
|
// When failing high/low give some update (without cluttering
|
|
|
|
// the UI) before a re-search.
|
2015-12-23 02:07:54 -07:00
|
|
|
if ( mainThread
|
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
|
|
|
&& multiPV == 1
|
|
|
|
&& (bestValue <= alpha || bestValue >= beta)
|
|
|
|
&& Time.elapsed() > 3000)
|
Fix issues from using adjustedDepth too broadly
The recently committed Fail-High patch (081af9080542a0d076a5482da37103a96ee15f64)
had a number of changes beyond adjusting the depth of search on fail high, with
some undesirable side effects.
1) Decreasing depth on PV output, confusing GUIs and players alike as described in
issue #1787. The depth printed is anyway a convention, let's consider adjustedDepth
an implementation detail, and continue to print rootDepth. Depth, nodes, time and
move quality all increase as we compute more. (fixing this output has no effect on
play).
2) Fixes go depth output (now based on rootDepth again, no effect on play), also
reported in issue #1787
3) The depth lastBestDepth is used to compute how long a move is stable, a new move
found during fail-high is incorrectly considered stable if based on adjustedDepth
instead of rootDepth (this changes time management). Reverting this passed STC
and LTC:
STC
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 82982 W: 17810 L: 17808 D: 47364
http://tests.stockfishchess.org/tests/view/5bd391a80ebc595e0ae1e993
LTC
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 109083 W: 17602 L: 17619 D: 73862
http://tests.stockfishchess.org/tests/view/5bd40c820ebc595e0ae1f1fb
4) In the thread voting scheme, the rank of the fail-high thread is now artificially
low, incorrectly since the quality of the move is much better than what adjustedDepth
suggests (e.g. if it takes 10 iterations to find VALUE_KNOWN_WIN, it has very low
depth). Further evidence comes from a test that showed that the move of highest
depth is not better than that of the last PV (which is potentially of much lower
adjustedDepth).
I.e. this test http://tests.stockfishchess.org/tests/view/5bd37a120ebc595e0ae1e7c3
failed SPRT[0, 5]:
LLR: -2.95 (-2.94,2.94) [0.00,5.00]
Total: 10609 W: 2266 L: 2345 D: 5998
In a running 5+0.05 th 8 test (more than 10000 games) a positive Elo estimate is
shown (strong enough for a [-3,1], possibly not [0,4]):
http://tests.stockfishchess.org/tests/view/5bd421be0ebc595e0ae1f315
LLR: -0.13 (-2.94,2.94) [0.00,4.00]
Total: 13644 W: 2573 L: 2532 D: 8539
Elo 1.04 [-2.52,4.61] / LOS 71%
Thus, restore old behavior as a bugfix, keeping the core of the fail-high patch
idea as resolving scheme. This is non-functional for bench, but changes searches
via time management and in the threaded case.
Bench: 3556672
2018-10-28 08:25:15 -06:00
|
|
|
sync_cout << UCI::pv(rootPos, rootDepth, alpha, beta) << sync_endl;
|
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
|
|
|
|
|
|
|
// In case of failing low/high increase aspiration window and
|
|
|
|
// re-search, otherwise exit the loop.
|
|
|
|
if (bestValue <= alpha)
|
|
|
|
{
|
|
|
|
beta = (alpha + beta) / 2;
|
|
|
|
alpha = std::max(bestValue - delta, -VALUE_INFINITE);
|
2012-10-24 04:05:20 -06:00
|
|
|
|
2015-12-23 02:07:54 -07:00
|
|
|
if (mainThread)
|
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
|
|
|
{
|
2018-10-19 02:33:01 -06:00
|
|
|
failedHighCnt = 0;
|
2018-06-11 01:46:05 -06:00
|
|
|
failedLow = true;
|
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
|
|
|
mainThread->stopOnPonderhit = false;
|
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
|
|
|
}
|
|
|
|
}
|
|
|
|
else if (bestValue >= beta)
|
2018-10-19 02:33:01 -06:00
|
|
|
{
|
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
|
|
|
beta = std::min(bestValue + delta, VALUE_INFINITE);
|
2018-10-19 02:33:01 -06:00
|
|
|
if (mainThread)
|
2018-12-13 05:19:55 -07:00
|
|
|
++failedHighCnt;
|
2018-10-19 02:33:01 -06:00
|
|
|
}
|
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
|
|
|
else
|
|
|
|
break;
|
2013-02-03 03:14:21 -07:00
|
|
|
|
2015-10-20 20:46:06 -06:00
|
|
|
delta += delta / 4 + 5;
|
2014-11-10 06:46:05 -07:00
|
|
|
|
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
|
|
|
assert(alpha >= -VALUE_INFINITE && beta <= VALUE_INFINITE);
|
|
|
|
}
|
2009-04-11 07:46:35 -06:00
|
|
|
|
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
|
|
|
// Sort the PV lines searched so far and update the GUI
|
2018-06-02 09:41:37 -06:00
|
|
|
std::stable_sort(rootMoves.begin() + pvFirst, rootMoves.begin() + pvIdx + 1);
|
2011-04-02 02:05:53 -06:00
|
|
|
|
2017-08-18 11:38:18 -06:00
|
|
|
if ( mainThread
|
2018-06-02 09:41:37 -06:00
|
|
|
&& (Threads.stop || pvIdx + 1 == multiPV || Time.elapsed() > 3000))
|
Fix issues from using adjustedDepth too broadly
The recently committed Fail-High patch (081af9080542a0d076a5482da37103a96ee15f64)
had a number of changes beyond adjusting the depth of search on fail high, with
some undesirable side effects.
1) Decreasing depth on PV output, confusing GUIs and players alike as described in
issue #1787. The depth printed is anyway a convention, let's consider adjustedDepth
an implementation detail, and continue to print rootDepth. Depth, nodes, time and
move quality all increase as we compute more. (fixing this output has no effect on
play).
2) Fixes go depth output (now based on rootDepth again, no effect on play), also
reported in issue #1787
3) The depth lastBestDepth is used to compute how long a move is stable, a new move
found during fail-high is incorrectly considered stable if based on adjustedDepth
instead of rootDepth (this changes time management). Reverting this passed STC
and LTC:
STC
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 82982 W: 17810 L: 17808 D: 47364
http://tests.stockfishchess.org/tests/view/5bd391a80ebc595e0ae1e993
LTC
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 109083 W: 17602 L: 17619 D: 73862
http://tests.stockfishchess.org/tests/view/5bd40c820ebc595e0ae1f1fb
4) In the thread voting scheme, the rank of the fail-high thread is now artificially
low, incorrectly since the quality of the move is much better than what adjustedDepth
suggests (e.g. if it takes 10 iterations to find VALUE_KNOWN_WIN, it has very low
depth). Further evidence comes from a test that showed that the move of highest
depth is not better than that of the last PV (which is potentially of much lower
adjustedDepth).
I.e. this test http://tests.stockfishchess.org/tests/view/5bd37a120ebc595e0ae1e7c3
failed SPRT[0, 5]:
LLR: -2.95 (-2.94,2.94) [0.00,5.00]
Total: 10609 W: 2266 L: 2345 D: 5998
In a running 5+0.05 th 8 test (more than 10000 games) a positive Elo estimate is
shown (strong enough for a [-3,1], possibly not [0,4]):
http://tests.stockfishchess.org/tests/view/5bd421be0ebc595e0ae1f315
LLR: -0.13 (-2.94,2.94) [0.00,4.00]
Total: 13644 W: 2573 L: 2532 D: 8539
Elo 1.04 [-2.52,4.61] / LOS 71%
Thus, restore old behavior as a bugfix, keeping the core of the fail-high patch
idea as resolving scheme. This is non-functional for bench, but changes searches
via time management and in the threaded case.
Bench: 3556672
2018-10-28 08:25:15 -06:00
|
|
|
sync_cout << UCI::pv(rootPos, rootDepth, alpha, beta) << sync_endl;
|
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
|
|
|
}
|
2015-01-25 03:07:43 -07:00
|
|
|
|
2017-07-13 17:07:19 -06:00
|
|
|
if (!Threads.stop)
|
Fix issues from using adjustedDepth too broadly
The recently committed Fail-High patch (081af9080542a0d076a5482da37103a96ee15f64)
had a number of changes beyond adjusting the depth of search on fail high, with
some undesirable side effects.
1) Decreasing depth on PV output, confusing GUIs and players alike as described in
issue #1787. The depth printed is anyway a convention, let's consider adjustedDepth
an implementation detail, and continue to print rootDepth. Depth, nodes, time and
move quality all increase as we compute more. (fixing this output has no effect on
play).
2) Fixes go depth output (now based on rootDepth again, no effect on play), also
reported in issue #1787
3) The depth lastBestDepth is used to compute how long a move is stable, a new move
found during fail-high is incorrectly considered stable if based on adjustedDepth
instead of rootDepth (this changes time management). Reverting this passed STC
and LTC:
STC
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 82982 W: 17810 L: 17808 D: 47364
http://tests.stockfishchess.org/tests/view/5bd391a80ebc595e0ae1e993
LTC
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 109083 W: 17602 L: 17619 D: 73862
http://tests.stockfishchess.org/tests/view/5bd40c820ebc595e0ae1f1fb
4) In the thread voting scheme, the rank of the fail-high thread is now artificially
low, incorrectly since the quality of the move is much better than what adjustedDepth
suggests (e.g. if it takes 10 iterations to find VALUE_KNOWN_WIN, it has very low
depth). Further evidence comes from a test that showed that the move of highest
depth is not better than that of the last PV (which is potentially of much lower
adjustedDepth).
I.e. this test http://tests.stockfishchess.org/tests/view/5bd37a120ebc595e0ae1e7c3
failed SPRT[0, 5]:
LLR: -2.95 (-2.94,2.94) [0.00,5.00]
Total: 10609 W: 2266 L: 2345 D: 5998
In a running 5+0.05 th 8 test (more than 10000 games) a positive Elo estimate is
shown (strong enough for a [-3,1], possibly not [0,4]):
http://tests.stockfishchess.org/tests/view/5bd421be0ebc595e0ae1f315
LLR: -0.13 (-2.94,2.94) [0.00,4.00]
Total: 13644 W: 2573 L: 2532 D: 8539
Elo 1.04 [-2.52,4.61] / LOS 71%
Thus, restore old behavior as a bugfix, keeping the core of the fail-high patch
idea as resolving scheme. This is non-functional for bench, but changes searches
via time management and in the threaded case.
Bench: 3556672
2018-10-28 08:25:15 -06:00
|
|
|
completedDepth = rootDepth;
|
2015-11-02 02:58:18 -07:00
|
|
|
|
Replace easyMove with simple scheme
Reduces time for a stable bestMove, giving some of the won time for the next move.
the version before the pvDraw passed both STC and LTC
passed STC:
http://tests.stockfishchess.org/tests/view/59e98d5a0ebc590ccbb896ec
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 78561 W: 13945 L: 13921 D: 50695
elo = 0.106 +- 1.445 LOS: 55.716%
passed LTC:
http://tests.stockfishchess.org/tests/view/59eb9df90ebc590ccbb897ae
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 29056 W: 3640 L: 3530 D: 21886
elo = 1.315 +- 1.982 LOS: 90.314%
This version, rebased on pvDrawPR with the obvious change, was verified again on STC:
http://tests.stockfishchess.org/tests/view/59ee104e0ebc590ccbb89899
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 19890 W: 3648 L: 3525 D: 12717
elo = 2.149 +- 2.895 LOS: 92.692%
and LTC:
http://tests.stockfishchess.org/tests/view/59f9673a0ebc590ccbb89ea0
Total : 17966
Win : 2273 ( 12.652%)
Loss : 2149 ( 11.961%)
Draw : 13544 ( 75.387%)
Score : 50.345%
Sensitivity : 0.014%
2*(W-L)/(W+L) : 5.608%
LLR [-3.0, 1.0] : 2.95
BayesElo range : [ -1.161, 4.876, 10.830] (DrawElo: 341.132)
LogisticElo range : [ -0.501, 2.105, 4.677]
LOS : 94.369 %
LTC again:
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 17966 W: 2273 L: 2149 D: 13544
LogisticElo range : [ -0.501, 2.105, 4.677]
LOS : 94.369 %
unchanged bench: 5234652
2017-11-03 06:51:53 -06:00
|
|
|
if (rootMoves[0].pv[0] != lastBestMove) {
|
|
|
|
lastBestMove = rootMoves[0].pv[0];
|
Fix issues from using adjustedDepth too broadly
The recently committed Fail-High patch (081af9080542a0d076a5482da37103a96ee15f64)
had a number of changes beyond adjusting the depth of search on fail high, with
some undesirable side effects.
1) Decreasing depth on PV output, confusing GUIs and players alike as described in
issue #1787. The depth printed is anyway a convention, let's consider adjustedDepth
an implementation detail, and continue to print rootDepth. Depth, nodes, time and
move quality all increase as we compute more. (fixing this output has no effect on
play).
2) Fixes go depth output (now based on rootDepth again, no effect on play), also
reported in issue #1787
3) The depth lastBestDepth is used to compute how long a move is stable, a new move
found during fail-high is incorrectly considered stable if based on adjustedDepth
instead of rootDepth (this changes time management). Reverting this passed STC
and LTC:
STC
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 82982 W: 17810 L: 17808 D: 47364
http://tests.stockfishchess.org/tests/view/5bd391a80ebc595e0ae1e993
LTC
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 109083 W: 17602 L: 17619 D: 73862
http://tests.stockfishchess.org/tests/view/5bd40c820ebc595e0ae1f1fb
4) In the thread voting scheme, the rank of the fail-high thread is now artificially
low, incorrectly since the quality of the move is much better than what adjustedDepth
suggests (e.g. if it takes 10 iterations to find VALUE_KNOWN_WIN, it has very low
depth). Further evidence comes from a test that showed that the move of highest
depth is not better than that of the last PV (which is potentially of much lower
adjustedDepth).
I.e. this test http://tests.stockfishchess.org/tests/view/5bd37a120ebc595e0ae1e7c3
failed SPRT[0, 5]:
LLR: -2.95 (-2.94,2.94) [0.00,5.00]
Total: 10609 W: 2266 L: 2345 D: 5998
In a running 5+0.05 th 8 test (more than 10000 games) a positive Elo estimate is
shown (strong enough for a [-3,1], possibly not [0,4]):
http://tests.stockfishchess.org/tests/view/5bd421be0ebc595e0ae1f315
LLR: -0.13 (-2.94,2.94) [0.00,4.00]
Total: 13644 W: 2573 L: 2532 D: 8539
Elo 1.04 [-2.52,4.61] / LOS 71%
Thus, restore old behavior as a bugfix, keeping the core of the fail-high patch
idea as resolving scheme. This is non-functional for bench, but changes searches
via time management and in the threaded case.
Bench: 3556672
2018-10-28 08:25:15 -06:00
|
|
|
lastBestMoveDepth = rootDepth;
|
Replace easyMove with simple scheme
Reduces time for a stable bestMove, giving some of the won time for the next move.
the version before the pvDraw passed both STC and LTC
passed STC:
http://tests.stockfishchess.org/tests/view/59e98d5a0ebc590ccbb896ec
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 78561 W: 13945 L: 13921 D: 50695
elo = 0.106 +- 1.445 LOS: 55.716%
passed LTC:
http://tests.stockfishchess.org/tests/view/59eb9df90ebc590ccbb897ae
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 29056 W: 3640 L: 3530 D: 21886
elo = 1.315 +- 1.982 LOS: 90.314%
This version, rebased on pvDrawPR with the obvious change, was verified again on STC:
http://tests.stockfishchess.org/tests/view/59ee104e0ebc590ccbb89899
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 19890 W: 3648 L: 3525 D: 12717
elo = 2.149 +- 2.895 LOS: 92.692%
and LTC:
http://tests.stockfishchess.org/tests/view/59f9673a0ebc590ccbb89ea0
Total : 17966
Win : 2273 ( 12.652%)
Loss : 2149 ( 11.961%)
Draw : 13544 ( 75.387%)
Score : 50.345%
Sensitivity : 0.014%
2*(W-L)/(W+L) : 5.608%
LLR [-3.0, 1.0] : 2.95
BayesElo range : [ -1.161, 4.876, 10.830] (DrawElo: 341.132)
LogisticElo range : [ -0.501, 2.105, 4.677]
LOS : 94.369 %
LTC again:
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 17966 W: 2273 L: 2149 D: 13544
LogisticElo range : [ -0.501, 2.105, 4.677]
LOS : 94.369 %
unchanged bench: 5234652
2017-11-03 06:51:53 -06:00
|
|
|
}
|
|
|
|
|
2017-08-18 11:38:18 -06:00
|
|
|
// Have we found a "mate in x"?
|
|
|
|
if ( Limits.mate
|
|
|
|
&& bestValue >= VALUE_MATE_IN_MAX_PLY
|
|
|
|
&& VALUE_MATE - bestValue <= 2 * Limits.mate)
|
|
|
|
Threads.stop = true;
|
|
|
|
|
2015-12-23 02:07:54 -07:00
|
|
|
if (!mainThread)
|
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
|
|
|
continue;
|
2015-03-12 13:49:30 -06:00
|
|
|
|
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
|
|
|
// If skill level is enabled and time is up, pick a sub-optimal best move
|
2015-10-23 23:27:24 -06:00
|
|
|
if (skill.enabled() && skill.time_to_pick(rootDepth))
|
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
|
|
|
skill.pick_best(multiPV);
|
|
|
|
|
|
|
|
// Do we have time for the next iteration? Can we stop searching now?
|
2018-02-12 14:57:42 -07:00
|
|
|
if ( Limits.use_time_management()
|
|
|
|
&& !Threads.stop
|
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
|
|
|
&& !mainThread->stopOnPonderhit)
|
2019-01-01 06:10:26 -07:00
|
|
|
{
|
|
|
|
double fallingEval = (306 + 119 * failedLow + 6 * (mainThread->previousScore - bestValue)) / 581.0;
|
|
|
|
fallingEval = std::max(0.5, std::min(1.5, fallingEval));
|
|
|
|
|
|
|
|
// If the bestMove is stable over several iterations, reduce time accordingly
|
Simplify time management a bit
The new form is likely to trigger a bit more at LTC. Given that LTC
appears to be an improvement, I think that is fine.
The change is not very invasive: it does the same as before, use
potentially less time for moves that are very stable. Most of the
time, the full bonus was given if the bonus was given, so the gradual
part {3, 4, 5} didn't matter much. Whereas previously 'stable' was
expressed as the last 80% of iterations are the same, now I use a
fixed depth (10 iterations). For TCEC style TC, it will presumably
imply some more moves that are played quicker (and thus more time
on the clock when it potentially matters). Note that 10 iterations
of stability means we've been proposing that move for 99.9% of search
time.
passed STC
http://tests.stockfishchess.org/tests/view/5c30d2290ebc596a450c055b
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 70921 W: 15403 L: 15378 D: 40140
passed LTC
http://tests.stockfishchess.org/tests/view/5c31ae240ebc596a450c1881
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 17422 W: 2968 L: 2842 D: 11612
No functional change.
2019-01-02 03:09:50 -07:00
|
|
|
timeReduction = lastBestMoveDepth + 10 * ONE_PLY < completedDepth ? 1.95 : 1.0;
|
2019-01-01 06:10:26 -07:00
|
|
|
|
|
|
|
// Use part of the gained time from a previous stable move for the current move
|
|
|
|
double bestMoveInstability = 1.0 + mainThread->bestMoveChanges;
|
|
|
|
bestMoveInstability *= std::pow(mainThread->previousTimeReduction, 0.528) / timeReduction;
|
|
|
|
|
|
|
|
// Stop the search if we have only one legal move, or if available time elapsed
|
|
|
|
if ( rootMoves.size() == 1
|
|
|
|
|| Time.elapsed() > Time.optimum() * bestMoveInstability * fallingEval)
|
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
|
|
|
{
|
2019-01-01 06:10:26 -07:00
|
|
|
// If we are allowed to ponder do not stop the search now but
|
|
|
|
// keep pondering until the GUI sends "ponderhit" or "stop".
|
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
|
|
|
if (mainThread->ponder)
|
|
|
|
mainThread->stopOnPonderhit = true;
|
2019-01-01 06:10:26 -07:00
|
|
|
else
|
|
|
|
Threads.stop = true;
|
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
|
|
|
}
|
2019-01-01 06:10:26 -07:00
|
|
|
}
|
2008-08-31 23:59:13 -06:00
|
|
|
}
|
|
|
|
|
2015-12-23 02:07:54 -07:00
|
|
|
if (!mainThread)
|
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
|
|
|
return;
|
|
|
|
|
Replace easyMove with simple scheme
Reduces time for a stable bestMove, giving some of the won time for the next move.
the version before the pvDraw passed both STC and LTC
passed STC:
http://tests.stockfishchess.org/tests/view/59e98d5a0ebc590ccbb896ec
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 78561 W: 13945 L: 13921 D: 50695
elo = 0.106 +- 1.445 LOS: 55.716%
passed LTC:
http://tests.stockfishchess.org/tests/view/59eb9df90ebc590ccbb897ae
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 29056 W: 3640 L: 3530 D: 21886
elo = 1.315 +- 1.982 LOS: 90.314%
This version, rebased on pvDrawPR with the obvious change, was verified again on STC:
http://tests.stockfishchess.org/tests/view/59ee104e0ebc590ccbb89899
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 19890 W: 3648 L: 3525 D: 12717
elo = 2.149 +- 2.895 LOS: 92.692%
and LTC:
http://tests.stockfishchess.org/tests/view/59f9673a0ebc590ccbb89ea0
Total : 17966
Win : 2273 ( 12.652%)
Loss : 2149 ( 11.961%)
Draw : 13544 ( 75.387%)
Score : 50.345%
Sensitivity : 0.014%
2*(W-L)/(W+L) : 5.608%
LLR [-3.0, 1.0] : 2.95
BayesElo range : [ -1.161, 4.876, 10.830] (DrawElo: 341.132)
LogisticElo range : [ -0.501, 2.105, 4.677]
LOS : 94.369 %
LTC again:
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 17966 W: 2273 L: 2149 D: 13544
LogisticElo range : [ -0.501, 2.105, 4.677]
LOS : 94.369 %
unchanged bench: 5234652
2017-11-03 06:51:53 -06:00
|
|
|
mainThread->previousTimeReduction = timeReduction;
|
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
|
|
|
|
|
|
|
// If skill level is enabled, swap best PV line with the sub-optimal one
|
|
|
|
if (skill.enabled())
|
2017-10-10 23:49:58 -06:00
|
|
|
std::swap(rootMoves[0], *std::find(rootMoves.begin(), rootMoves.end(),
|
|
|
|
skill.best ? skill.best : skill.pick_best(multiPV)));
|
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
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
namespace {
|
2008-08-31 23:59:13 -06:00
|
|
|
|
2015-10-25 05:07:22 -06:00
|
|
|
// search<>() is the main search function for both PV and non-PV nodes
|
2008-08-31 23:59:13 -06:00
|
|
|
|
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
|
|
|
template <NodeType NT>
|
2018-05-08 02:43:46 -06:00
|
|
|
Value search(Position& pos, Stack* ss, Value alpha, Value beta, Depth depth, bool cutNode) {
|
2010-05-08 02:54:51 -06:00
|
|
|
|
Renaming some variables in code
Implements renaming suggestions by Marco Costalba, Günther Demetz,
Gontran Lemaire, Ronald de Man, Stéphane Nicolet, Alain Savard,
Joost VandeVondele, Jerry Donald Watson, Mike Whiteley, xoto10,
and I hope that I haven't forgotten anybody.
Perpetual renaming thread for suggestions:
https://github.com/official-stockfish/Stockfish/issues/1426
No functional change.
2018-03-15 03:44:26 -06:00
|
|
|
constexpr bool PvNode = NT == PV;
|
Let ss->ply denote the number of plies from the root to the current node
This patch lets ss->ply be equal to 0 at the root of the search.
Currently, the root has ss->ply == 1, which is less intuitive:
- Setting the rootNode bool has to check (ss-1)->ply == 0.
- All mate values are off by one: the code seems to assume that mated-in-0
is -VALUE_MATE, mate-1-in-ply is VALUE_MATE-1, mated-in-2-ply is VALUE_MATE+2, etc.
But the mate_in() and mated_in() functions are called with ss->ply, which is 1 in
at the root.
- The is_draw() function currently needs to explain why it has "ply - 1 > i" instead
of simply "ply > i".
- The ss->ply >= MAX_PLY tests in search() and qsearch() already assume that
ss->ply == 0 at the root. If we start at ss->ply == 1, it would make more sense to
go up to and including ss->ply == MAX_PLY, so stop at ss->ply > MAX_PLY. See also
the asserts testing for 0 <= ss->ply && ss->ply < MAX_PLY.
The reason for ss->ply == 1 at the root is the line "ss->ply = (ss-1)->ply + 1" at
the start for search() and qsearch(). By replacing this with "(ss+1)->ply = ss->ply + 1"
we keep ss->ply == 0 at the root. Note that search() already clears killers in (ss+2),
so there is no danger in accessing ss+1.
I have NOT changed pv[MAX_PLY + 1] to pv[MAX_PLY + 2] in search() and qsearch().
It seems to me that MAX_PLY + 1 is exactly right:
- MAX_PLY entries for ss->ply running from 0 to MAX_PLY-1, and 1 entry for the
final MOVE_NONE.
I have verified that mate scores are reported correctly. (They were already reported
correctly due to the extra ply being rounded down when converting to moves.)
The value of seldepth output to the user should probably not change, so I add 1 to it.
(Humans count from 1, computers from 0.)
A small optimisation I did not include: instead of setting ss->ply in every invocation
of search() and qsearch(), it could be set once for all plies at the start of
Thread::search(). This saves a couple of instructions per node.
No functional change (unless the search searches a branch MAX_PLY deep), so bench
does not change.
2017-09-16 13:49:29 -06:00
|
|
|
const bool rootNode = PvNode && ss->ply == 0;
|
2011-05-28 05:13:42 -06:00
|
|
|
|
2018-06-11 01:46:05 -06:00
|
|
|
// Check if we have an upcoming move which draws by repetition, or
|
2018-06-05 02:54:51 -06:00
|
|
|
// if the opponent had an alternative move earlier to this position.
|
|
|
|
if ( pos.rule50_count() >= 3
|
|
|
|
&& alpha < VALUE_DRAW
|
|
|
|
&& !rootNode
|
|
|
|
&& pos.has_game_cycle(ss->ply))
|
|
|
|
{
|
Randomize draw eval
The patch adds a small random component (+-1) to VALUE_DRAW for the evaluation
of draw positions (mostly 3folds). This random component is not static, but
potentially different for each visit of the node (hence derived from the node
counter). The effect is that in positions with many 3fold draw lines, different
lines are followed at each iteration. This keeps the search much more dynamic,
as opposed to being locked to one particular 3fold.
An example of a position where master suffers from 3fold-blindness and this patch
solves quickly is the famous TCEC game 53:
FEN: 3r2k1/pr6/1p3q1p/5R2/3P3p/8/5RP1/3Q2K1 b - - 0 51
master doesn't see that this is a lost position (draw eval up to depth 50) as
Qf6-e6 d4-d5 (found by patch at depth 23) leads to a loss.
The 3fold-blindness is more important at longer TC, the patch was yellow STC and
LTC, but passed VLTC:
STC
LLR: -2.95 (-2.94,2.94) [0.00,5.00]
Total: 46328 W: 10048 L: 9953 D: 26327
http://tests.stockfishchess.org/tests/view/5b9c0ca20ebc592cf275f7c7
LTC
LLR: -2.95 (-2.94,2.94) [0.00,5.00]
Total: 54663 W: 8938 L: 8846 D: 36879
http://tests.stockfishchess.org/tests/view/5b9ca1610ebc592cf27601d3
VLTC
LLR: 2.95 (-2.94,2.94) [0.00,5.00]
Total: 31789 W: 4512 L: 4284 D: 22993
http://tests.stockfishchess.org/tests/view/5b9d1a670ebc592cf276076d
Credit to @crossbr for pointing to this problem repeatedly, and giving the hint
that many draw lines are typical in those situations.
Bench: 4756639
2018-10-14 12:33:24 -06:00
|
|
|
alpha = value_draw(depth, pos.this_thread());
|
2018-06-05 02:54:51 -06:00
|
|
|
if (alpha >= beta)
|
|
|
|
return alpha;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Dive into quiescence search when the depth reaches zero
|
|
|
|
if (depth < ONE_PLY)
|
|
|
|
return qsearch<NT>(pos, ss, alpha, beta);
|
|
|
|
|
2014-02-15 01:20:27 -07:00
|
|
|
assert(-VALUE_INFINITE <= alpha && alpha < beta && beta <= VALUE_INFINITE);
|
2012-09-29 10:26:17 -06:00
|
|
|
assert(PvNode || (alpha == beta - 1));
|
2015-11-06 21:19:13 -07:00
|
|
|
assert(DEPTH_ZERO < depth && depth < DEPTH_MAX);
|
2016-06-23 08:14:51 -06:00
|
|
|
assert(!(PvNode && cutNode));
|
2016-08-19 04:17:38 -06:00
|
|
|
assert(depth / ONE_PLY * ONE_PLY == depth);
|
2008-08-31 23:59:13 -06:00
|
|
|
|
2017-11-03 05:37:11 -06:00
|
|
|
Move pv[MAX_PLY+1], capturesSearched[32], quietsSearched[64];
|
2009-11-05 03:11:02 -07:00
|
|
|
StateInfo st;
|
2014-12-13 00:16:35 -07:00
|
|
|
TTEntry* tte;
|
2010-06-02 06:22:48 -06:00
|
|
|
Key posKey;
|
2013-12-14 04:27:29 -07:00
|
|
|
Move ttMove, move, excludedMove, bestMove;
|
2016-09-14 07:09:41 -06:00
|
|
|
Depth extension, newDepth;
|
2018-08-20 04:06:52 -06:00
|
|
|
Value bestValue, value, ttValue, eval, maxValue, pureStaticEval;
|
2019-01-01 06:13:08 -07:00
|
|
|
bool ttHit, ttPv, inCheck, givesCheck, improving;
|
2019-02-27 05:36:48 -07:00
|
|
|
bool captureOrPromotion, doFullDepthSearch, moveCountPruning, ttCapture;
|
2017-08-09 19:43:30 -06:00
|
|
|
Piece movedPiece;
|
2017-11-03 05:37:11 -06:00
|
|
|
int moveCount, captureCount, quietCount;
|
2011-01-16 04:02:32 -07:00
|
|
|
|
2012-10-01 01:33:13 -06:00
|
|
|
// Step 1. Initialize node
|
2012-09-29 10:26:17 -06:00
|
|
|
Thread* thisThread = pos.this_thread();
|
2012-12-25 09:59:35 -07:00
|
|
|
inCheck = pos.checkers();
|
2018-05-22 12:30:58 -06:00
|
|
|
Color us = pos.side_to_move();
|
2017-11-03 05:37:11 -06:00
|
|
|
moveCount = captureCount = quietCount = ss->moveCount = 0;
|
2012-10-01 01:33:13 -06:00
|
|
|
bestValue = -VALUE_INFINITE;
|
2018-01-28 06:40:07 -07:00
|
|
|
maxValue = VALUE_INFINITE;
|
2012-10-01 01:33:13 -06:00
|
|
|
|
2016-01-16 14:34:29 -07:00
|
|
|
// Check for the available remaining time
|
2017-06-23 23:15:46 -06:00
|
|
|
if (thisThread == Threads.main())
|
|
|
|
static_cast<MainThread*>(thisThread)->check_time();
|
Get rid of timer thread
Unfortunately std::condition_variable::wait_for()
is not accurate in general case and the timer thread
can wake up also after tens or even hundreds of
millisecs after time has elapsded. CPU load, process
priorities, number of concurrent threads, even from
other processes, will have effect upon it.
Even official documentation says: "This function may
block for longer than timeout_duration due to scheduling
or resource contention delays."
So retire timer and use a polling scheme based on a
local thread counter that counts search() calls and
a small trick to keep polling frequency constant,
independently from the number of threads.
Tested for no regression at very fast TC 2+0.05 th 7:
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 32969 W: 6720 L: 6620 D: 19629
TC 2+0.05 th 1:
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 7765 W: 1917 L: 1765 D: 4083
And at STC TC, both single thread
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 15587 W: 3036 L: 2905 D: 9646
And with 7 threads
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 8149 W: 1367 L: 1227 D: 5555
bench: 8639247
2015-11-03 03:15:14 -07:00
|
|
|
|
Let ss->ply denote the number of plies from the root to the current node
This patch lets ss->ply be equal to 0 at the root of the search.
Currently, the root has ss->ply == 1, which is less intuitive:
- Setting the rootNode bool has to check (ss-1)->ply == 0.
- All mate values are off by one: the code seems to assume that mated-in-0
is -VALUE_MATE, mate-1-in-ply is VALUE_MATE-1, mated-in-2-ply is VALUE_MATE+2, etc.
But the mate_in() and mated_in() functions are called with ss->ply, which is 1 in
at the root.
- The is_draw() function currently needs to explain why it has "ply - 1 > i" instead
of simply "ply > i".
- The ss->ply >= MAX_PLY tests in search() and qsearch() already assume that
ss->ply == 0 at the root. If we start at ss->ply == 1, it would make more sense to
go up to and including ss->ply == MAX_PLY, so stop at ss->ply > MAX_PLY. See also
the asserts testing for 0 <= ss->ply && ss->ply < MAX_PLY.
The reason for ss->ply == 1 at the root is the line "ss->ply = (ss-1)->ply + 1" at
the start for search() and qsearch(). By replacing this with "(ss+1)->ply = ss->ply + 1"
we keep ss->ply == 0 at the root. Note that search() already clears killers in (ss+2),
so there is no danger in accessing ss+1.
I have NOT changed pv[MAX_PLY + 1] to pv[MAX_PLY + 2] in search() and qsearch().
It seems to me that MAX_PLY + 1 is exactly right:
- MAX_PLY entries for ss->ply running from 0 to MAX_PLY-1, and 1 entry for the
final MOVE_NONE.
I have verified that mate scores are reported correctly. (They were already reported
correctly due to the extra ply being rounded down when converting to moves.)
The value of seldepth output to the user should probably not change, so I add 1 to it.
(Humans count from 1, computers from 0.)
A small optimisation I did not include: instead of setting ss->ply in every invocation
of search() and qsearch(), it could be set once for all plies at the start of
Thread::search(). This saves a couple of instructions per node.
No functional change (unless the search searches a branch MAX_PLY deep), so bench
does not change.
2017-09-16 13:49:29 -06:00
|
|
|
// Used to send selDepth info to GUI (selDepth counts from 1, ply from 0)
|
|
|
|
if (PvNode && thisThread->selDepth < ss->ply + 1)
|
|
|
|
thisThread->selDepth = ss->ply + 1;
|
2009-11-05 03:11:02 -07:00
|
|
|
|
2016-01-18 15:20:16 -07:00
|
|
|
if (!rootNode)
|
2011-06-18 10:10:29 -06:00
|
|
|
{
|
2012-09-29 10:26:17 -06:00
|
|
|
// Step 2. Check for aborted search and immediate draw
|
2018-02-12 14:57:42 -07:00
|
|
|
if ( Threads.stop.load(std::memory_order_relaxed)
|
|
|
|
|| pos.is_draw(ss->ply)
|
|
|
|
|| ss->ply >= MAX_PLY)
|
2018-11-19 23:45:00 -07:00
|
|
|
return (ss->ply >= MAX_PLY && !inCheck) ? evaluate(pos)
|
Randomize draw eval
The patch adds a small random component (+-1) to VALUE_DRAW for the evaluation
of draw positions (mostly 3folds). This random component is not static, but
potentially different for each visit of the node (hence derived from the node
counter). The effect is that in positions with many 3fold draw lines, different
lines are followed at each iteration. This keeps the search much more dynamic,
as opposed to being locked to one particular 3fold.
An example of a position where master suffers from 3fold-blindness and this patch
solves quickly is the famous TCEC game 53:
FEN: 3r2k1/pr6/1p3q1p/5R2/3P3p/8/5RP1/3Q2K1 b - - 0 51
master doesn't see that this is a lost position (draw eval up to depth 50) as
Qf6-e6 d4-d5 (found by patch at depth 23) leads to a loss.
The 3fold-blindness is more important at longer TC, the patch was yellow STC and
LTC, but passed VLTC:
STC
LLR: -2.95 (-2.94,2.94) [0.00,5.00]
Total: 46328 W: 10048 L: 9953 D: 26327
http://tests.stockfishchess.org/tests/view/5b9c0ca20ebc592cf275f7c7
LTC
LLR: -2.95 (-2.94,2.94) [0.00,5.00]
Total: 54663 W: 8938 L: 8846 D: 36879
http://tests.stockfishchess.org/tests/view/5b9ca1610ebc592cf27601d3
VLTC
LLR: 2.95 (-2.94,2.94) [0.00,5.00]
Total: 31789 W: 4512 L: 4284 D: 22993
http://tests.stockfishchess.org/tests/view/5b9d1a670ebc592cf276076d
Credit to @crossbr for pointing to this problem repeatedly, and giving the hint
that many draw lines are typical in those situations.
Bench: 4756639
2018-10-14 12:33:24 -06:00
|
|
|
: value_draw(depth, pos.this_thread());
|
2012-09-29 10:26:17 -06:00
|
|
|
|
|
|
|
// Step 3. Mate distance pruning. Even if we mate at the next move our score
|
|
|
|
// would be at best mate_in(ss->ply+1), but if alpha is already bigger because
|
|
|
|
// a shorter mate was found upward in the tree then there is no need to search
|
2013-12-02 11:04:09 -07:00
|
|
|
// because we will never beat the current alpha. Same logic but with reversed
|
|
|
|
// signs applies also in the opposite condition of being mated instead of giving
|
|
|
|
// mate. In this case return a fail-high score.
|
2011-12-27 08:01:33 -07:00
|
|
|
alpha = std::max(mated_in(ss->ply), alpha);
|
|
|
|
beta = std::min(mate_in(ss->ply+1), beta);
|
2011-06-18 10:10:29 -06:00
|
|
|
if (alpha >= beta)
|
|
|
|
return alpha;
|
|
|
|
}
|
2010-02-24 03:19:47 -07:00
|
|
|
|
Cleanup MAX_PLY
This area has become obscure and tricky over the course of incremental
changes that did not respect the original's consistency and clarity. Now,
it's not clear why we use MAX_PLY = 120, or why we use MAX_PLY+6, among
other things.
This patch does the following:
* ID loop: depth ranges from 1 to MAX_PLY-1, and due to TT constraint (depth
must fit into an int8_t), MAX_PLY should be 128.
* stack[]: plies now range from 0 to MAX_PLY-1, hence stack[MAX_PLY+4],
because of the extra 2+2 padding elements (for ss-2 and ss+2). Document this
better, while we're at it.
* Enforce 0 <= ply < MAX_PLY:
- stop condition is now ss->ply >= MAX_PLY and not ss->ply > MAX_PLY.
- assert(ss->ply < MAX_PLY), before using ss+1 and ss+2.
- as a result, we don't need the artificial MAX_PLY+6 range. Instead we
can use MAX_PLY+4 and it's clear why (for ss-2 and ss+2).
* fix: extract_pv_from_tt() and insert_pv_in_tt() had no reason to use
MAX_PLY_PLUS_6, because the array is indexed by plies, so the range of
available plies applies (0..MAX_PLY before, and now 0..MAX_PLY-1).
Tested with debug compile, using MAX_PLY=16, and running bench at depth 17,
using 1 and 7 threads. No assert() fired. Feel free to submit to more severe
crash-tests, if you can think of any.
No functional change.
2014-11-03 08:36:24 -07:00
|
|
|
assert(0 <= ss->ply && ss->ply < MAX_PLY);
|
|
|
|
|
Let ss->ply denote the number of plies from the root to the current node
This patch lets ss->ply be equal to 0 at the root of the search.
Currently, the root has ss->ply == 1, which is less intuitive:
- Setting the rootNode bool has to check (ss-1)->ply == 0.
- All mate values are off by one: the code seems to assume that mated-in-0
is -VALUE_MATE, mate-1-in-ply is VALUE_MATE-1, mated-in-2-ply is VALUE_MATE+2, etc.
But the mate_in() and mated_in() functions are called with ss->ply, which is 1 in
at the root.
- The is_draw() function currently needs to explain why it has "ply - 1 > i" instead
of simply "ply > i".
- The ss->ply >= MAX_PLY tests in search() and qsearch() already assume that
ss->ply == 0 at the root. If we start at ss->ply == 1, it would make more sense to
go up to and including ss->ply == MAX_PLY, so stop at ss->ply > MAX_PLY. See also
the asserts testing for 0 <= ss->ply && ss->ply < MAX_PLY.
The reason for ss->ply == 1 at the root is the line "ss->ply = (ss-1)->ply + 1" at
the start for search() and qsearch(). By replacing this with "(ss+1)->ply = ss->ply + 1"
we keep ss->ply == 0 at the root. Note that search() already clears killers in (ss+2),
so there is no danger in accessing ss+1.
I have NOT changed pv[MAX_PLY + 1] to pv[MAX_PLY + 2] in search() and qsearch().
It seems to me that MAX_PLY + 1 is exactly right:
- MAX_PLY entries for ss->ply running from 0 to MAX_PLY-1, and 1 entry for the
final MOVE_NONE.
I have verified that mate scores are reported correctly. (They were already reported
correctly due to the extra ply being rounded down when converting to moves.)
The value of seldepth output to the user should probably not change, so I add 1 to it.
(Humans count from 1, computers from 0.)
A small optimisation I did not include: instead of setting ss->ply in every invocation
of search() and qsearch(), it could be set once for all plies at the start of
Thread::search(). This saves a couple of instructions per node.
No functional change (unless the search searches a branch MAX_PLY deep), so bench
does not change.
2017-09-16 13:49:29 -06:00
|
|
|
(ss+1)->ply = ss->ply + 1;
|
2015-12-20 13:37:18 -07:00
|
|
|
ss->currentMove = (ss+1)->excludedMove = bestMove = MOVE_NONE;
|
2018-07-28 07:33:39 -06:00
|
|
|
ss->continuationHistory = &thisThread->continuationHistory[NO_PIECE][0];
|
Cleanup MAX_PLY
This area has become obscure and tricky over the course of incremental
changes that did not respect the original's consistency and clarity. Now,
it's not clear why we use MAX_PLY = 120, or why we use MAX_PLY+6, among
other things.
This patch does the following:
* ID loop: depth ranges from 1 to MAX_PLY-1, and due to TT constraint (depth
must fit into an int8_t), MAX_PLY should be 128.
* stack[]: plies now range from 0 to MAX_PLY-1, hence stack[MAX_PLY+4],
because of the extra 2+2 padding elements (for ss-2 and ss+2). Document this
better, while we're at it.
* Enforce 0 <= ply < MAX_PLY:
- stop condition is now ss->ply >= MAX_PLY and not ss->ply > MAX_PLY.
- assert(ss->ply < MAX_PLY), before using ss+1 and ss+2.
- as a result, we don't need the artificial MAX_PLY+6 range. Instead we
can use MAX_PLY+4 and it's clear why (for ss-2 and ss+2).
* fix: extract_pv_from_tt() and insert_pv_in_tt() had no reason to use
MAX_PLY_PLUS_6, because the array is indexed by plies, so the range of
available plies applies (0..MAX_PLY before, and now 0..MAX_PLY-1).
Tested with debug compile, using MAX_PLY=16, and running bench at depth 17,
using 1 and 7 threads. No assert() fired. Feel free to submit to more severe
crash-tests, if you can think of any.
No functional change.
2014-11-03 08:36:24 -07:00
|
|
|
(ss+2)->killers[0] = (ss+2)->killers[1] = MOVE_NONE;
|
2016-12-05 10:58:12 -07:00
|
|
|
Square prevSq = to_sq((ss-1)->currentMove);
|
Cleanup MAX_PLY
This area has become obscure and tricky over the course of incremental
changes that did not respect the original's consistency and clarity. Now,
it's not clear why we use MAX_PLY = 120, or why we use MAX_PLY+6, among
other things.
This patch does the following:
* ID loop: depth ranges from 1 to MAX_PLY-1, and due to TT constraint (depth
must fit into an int8_t), MAX_PLY should be 128.
* stack[]: plies now range from 0 to MAX_PLY-1, hence stack[MAX_PLY+4],
because of the extra 2+2 padding elements (for ss-2 and ss+2). Document this
better, while we're at it.
* Enforce 0 <= ply < MAX_PLY:
- stop condition is now ss->ply >= MAX_PLY and not ss->ply > MAX_PLY.
- assert(ss->ply < MAX_PLY), before using ss+1 and ss+2.
- as a result, we don't need the artificial MAX_PLY+6 range. Instead we
can use MAX_PLY+4 and it's clear why (for ss-2 and ss+2).
* fix: extract_pv_from_tt() and insert_pv_in_tt() had no reason to use
MAX_PLY_PLUS_6, because the array is indexed by plies, so the range of
available plies applies (0..MAX_PLY before, and now 0..MAX_PLY-1).
Tested with debug compile, using MAX_PLY=16, and running bench at depth 17,
using 1 and 7 threads. No assert() fired. Feel free to submit to more severe
crash-tests, if you can think of any.
No functional change.
2014-11-03 08:36:24 -07:00
|
|
|
|
2018-02-27 10:38:08 -07:00
|
|
|
// Initialize statScore to zero for the grandchildren of the current position.
|
|
|
|
// So statScore is shared between all grandchildren and only the first grandchild
|
|
|
|
// starts with statScore = 0. Later grandchildren start with the last calculated
|
|
|
|
// statScore of the previous grandchild. This influences the reduction rules in
|
|
|
|
// LMR which are based on the statScore of parent position.
|
|
|
|
(ss+2)->statScore = 0;
|
|
|
|
|
2015-10-23 23:27:24 -06:00
|
|
|
// Step 4. Transposition table lookup. We don't want the score of a partial
|
|
|
|
// search to overwrite a previous full search TT value, so we use a different
|
|
|
|
// position key in case of an excluded move.
|
2013-11-18 23:19:28 -07:00
|
|
|
excludedMove = ss->excludedMove;
|
2018-02-12 14:57:42 -07:00
|
|
|
posKey = pos.key() ^ Key(excludedMove << 16); // Isn't a very good hash
|
2014-12-13 00:16:35 -07:00
|
|
|
tte = TT.probe(posKey, ttHit);
|
|
|
|
ttValue = ttHit ? value_from_tt(tte->value(), ss->ply) : VALUE_NONE;
|
2018-06-02 09:41:37 -06:00
|
|
|
ttMove = rootNode ? thisThread->rootMoves[thisThread->pvIdx].pv[0]
|
2015-12-20 13:37:18 -07:00
|
|
|
: ttHit ? tte->move() : MOVE_NONE;
|
2019-01-01 06:13:08 -07:00
|
|
|
ttPv = (ttHit && tte->is_pv()) || (PvNode && depth > 4 * ONE_PLY);
|
2008-09-06 07:53:43 -06:00
|
|
|
|
2015-10-23 23:27:24 -06:00
|
|
|
// At non-PV nodes we check for an early TT cutoff
|
2014-11-18 03:57:57 -07:00
|
|
|
if ( !PvNode
|
2014-12-13 00:16:35 -07:00
|
|
|
&& ttHit
|
2012-12-15 03:11:38 -07:00
|
|
|
&& tte->depth() >= depth
|
2015-10-23 23:27:24 -06:00
|
|
|
&& ttValue != VALUE_NONE // Possible in case of TT access race
|
2014-11-12 14:13:55 -07:00
|
|
|
&& (ttValue >= beta ? (tte->bound() & BOUND_LOWER)
|
|
|
|
: (tte->bound() & BOUND_UPPER)))
|
2008-09-06 07:53:43 -06:00
|
|
|
{
|
2017-01-09 03:57:34 -07:00
|
|
|
// If ttMove is quiet, update move sorting heuristics on TT hit
|
2017-01-25 07:32:10 -07:00
|
|
|
if (ttMove)
|
2016-08-24 08:52:05 -06:00
|
|
|
{
|
2017-01-25 07:32:10 -07:00
|
|
|
if (ttValue >= beta)
|
|
|
|
{
|
|
|
|
if (!pos.capture_or_promotion(ttMove))
|
2018-02-12 14:57:42 -07:00
|
|
|
update_quiet_stats(pos, ss, ttMove, nullptr, 0, stat_bonus(depth));
|
2016-08-24 08:52:05 -06:00
|
|
|
|
2018-12-18 00:05:09 -07:00
|
|
|
// Extra penalty for a quiet TT or main killer move in previous ply when it gets refuted
|
2018-12-19 13:04:36 -07:00
|
|
|
if ( ((ss-1)->moveCount == 1 || (ss-1)->currentMove == (ss-1)->killers[0])
|
|
|
|
&& !pos.captured_piece())
|
2018-12-18 00:05:09 -07:00
|
|
|
update_continuation_histories(ss-1, pos.piece_on(prevSq), prevSq, -stat_bonus(depth + ONE_PLY));
|
2017-01-25 07:32:10 -07:00
|
|
|
}
|
|
|
|
// Penalty for a quiet ttMove that fails low
|
2017-01-29 00:54:58 -07:00
|
|
|
else if (!pos.capture_or_promotion(ttMove))
|
2017-01-25 07:32:10 -07:00
|
|
|
{
|
2017-04-23 08:57:48 -06:00
|
|
|
int penalty = -stat_bonus(depth);
|
2018-05-22 12:30:58 -06:00
|
|
|
thisThread->mainHistory[us][from_to(ttMove)] << penalty;
|
2017-06-30 09:20:00 -06:00
|
|
|
update_continuation_histories(ss, pos.moved_piece(ttMove), to_sq(ttMove), penalty);
|
2017-01-25 07:32:10 -07:00
|
|
|
}
|
2016-08-24 08:52:05 -06:00
|
|
|
}
|
2012-12-15 03:11:38 -07:00
|
|
|
return ttValue;
|
2008-08-31 23:59:13 -06:00
|
|
|
}
|
|
|
|
|
2018-02-12 14:57:42 -07:00
|
|
|
// Step 5. Tablebases probe
|
2016-01-18 15:20:16 -07:00
|
|
|
if (!rootNode && TB::Cardinality)
|
2015-01-18 00:05:05 -07:00
|
|
|
{
|
2017-03-08 19:45:09 -07:00
|
|
|
int piecesCount = pos.count<ALL_PIECES>();
|
2015-01-18 00:05:05 -07:00
|
|
|
|
2016-12-20 03:18:19 -07:00
|
|
|
if ( piecesCount <= TB::Cardinality
|
|
|
|
&& (piecesCount < TB::Cardinality || depth >= TB::ProbeDepth)
|
2016-01-20 08:24:21 -07:00
|
|
|
&& pos.rule50_count() == 0
|
|
|
|
&& !pos.can_castle(ANY_CASTLING))
|
2015-01-18 00:05:05 -07:00
|
|
|
{
|
2016-07-16 00:10:45 -06:00
|
|
|
TB::ProbeState err;
|
2018-01-28 06:40:07 -07:00
|
|
|
TB::WDLScore wdl = Tablebases::probe_wdl(pos, &err);
|
2015-01-18 00:05:05 -07:00
|
|
|
|
2018-06-04 02:31:25 -06:00
|
|
|
// Force check of time on the next occasion
|
|
|
|
if (thisThread == Threads.main())
|
|
|
|
static_cast<MainThread*>(thisThread)->callsCnt = 0;
|
|
|
|
|
2016-07-16 00:10:45 -06:00
|
|
|
if (err != TB::ProbeState::FAIL)
|
2015-01-18 00:05:05 -07:00
|
|
|
{
|
2017-06-23 23:15:46 -06:00
|
|
|
thisThread->tbHits.fetch_add(1, std::memory_order_relaxed);
|
2015-01-18 00:05:05 -07:00
|
|
|
|
|
|
|
int drawScore = TB::UseRule50 ? 1 : 0;
|
|
|
|
|
2018-01-28 06:40:07 -07:00
|
|
|
value = wdl < -drawScore ? -VALUE_MATE + MAX_PLY + ss->ply + 1
|
|
|
|
: wdl > drawScore ? VALUE_MATE - MAX_PLY - ss->ply - 1
|
|
|
|
: VALUE_DRAW + 2 * wdl * drawScore;
|
2015-01-18 00:05:05 -07:00
|
|
|
|
2018-01-28 06:40:07 -07:00
|
|
|
Bound b = wdl < -drawScore ? BOUND_UPPER
|
|
|
|
: wdl > drawScore ? BOUND_LOWER : BOUND_EXACT;
|
2015-01-18 00:05:05 -07:00
|
|
|
|
2018-01-28 06:40:07 -07:00
|
|
|
if ( b == BOUND_EXACT
|
|
|
|
|| (b == BOUND_LOWER ? value >= beta : value <= alpha))
|
|
|
|
{
|
2019-01-01 06:13:08 -07:00
|
|
|
tte->save(posKey, value_to_tt(value, ss->ply), ttPv, b,
|
2018-01-28 06:40:07 -07:00
|
|
|
std::min(DEPTH_MAX - ONE_PLY, depth + 6 * ONE_PLY),
|
2018-07-03 16:58:16 -06:00
|
|
|
MOVE_NONE, VALUE_NONE);
|
2018-01-28 06:40:07 -07:00
|
|
|
|
|
|
|
return value;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (PvNode)
|
|
|
|
{
|
|
|
|
if (b == BOUND_LOWER)
|
|
|
|
bestValue = value, alpha = std::max(alpha, bestValue);
|
|
|
|
else
|
|
|
|
maxValue = value;
|
|
|
|
}
|
2015-01-18 00:05:05 -07:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2018-05-08 17:40:32 -06:00
|
|
|
// Step 6. Static evaluation of the position
|
2011-04-29 08:26:48 -06:00
|
|
|
if (inCheck)
|
2013-07-07 05:27:31 -06:00
|
|
|
{
|
2018-08-28 17:22:22 -06:00
|
|
|
ss->staticEval = eval = pureStaticEval = VALUE_NONE;
|
2018-03-13 16:19:36 -06:00
|
|
|
improving = false;
|
2018-05-08 17:40:32 -06:00
|
|
|
goto moves_loop; // Skip early pruning when in check
|
2013-07-07 05:27:31 -06:00
|
|
|
}
|
2014-12-13 00:16:35 -07:00
|
|
|
else if (ttHit)
|
2010-01-17 04:55:10 -07:00
|
|
|
{
|
2012-12-31 08:28:40 -07:00
|
|
|
// Never assume anything on values stored in TT
|
2018-08-28 17:22:22 -06:00
|
|
|
ss->staticEval = eval = pureStaticEval = tte->eval();
|
|
|
|
if (eval == VALUE_NONE)
|
|
|
|
ss->staticEval = eval = pureStaticEval = evaluate(pos);
|
2012-10-26 04:33:58 -06:00
|
|
|
|
2012-10-22 01:50:00 -06:00
|
|
|
// Can ttValue be used as a better position evaluation?
|
2018-02-12 14:57:42 -07:00
|
|
|
if ( ttValue != VALUE_NONE
|
2017-07-27 03:14:18 -06:00
|
|
|
&& (tte->bound() & (ttValue > eval ? BOUND_LOWER : BOUND_UPPER)))
|
|
|
|
eval = ttValue;
|
2012-12-27 04:13:31 -07:00
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
2018-08-28 17:22:22 -06:00
|
|
|
if ((ss-1)->currentMove != MOVE_NULL)
|
|
|
|
{
|
2019-01-31 07:18:33 -07:00
|
|
|
int bonus = -(ss-1)->statScore / 512;
|
2014-06-06 03:12:05 -06:00
|
|
|
|
2018-08-28 17:22:22 -06:00
|
|
|
pureStaticEval = evaluate(pos);
|
|
|
|
ss->staticEval = eval = pureStaticEval + bonus;
|
|
|
|
}
|
|
|
|
else
|
|
|
|
ss->staticEval = eval = pureStaticEval = -(ss-1)->staticEval + 2 * Eval::Tempo;
|
Use an affine formula to mix stats and eval
Follow-up for the previous patch: we use an affine formula to mix stats
and evaluation in search. The idea is to give a bonus if the previous
move of the opponent was historically bad, and a malus if the previous
move of the opponent was historically good.
More precisely, if x is the stat score of the previous move by the opponent,
we implement the following formulas to tweak the evaluation at an internal
node of the tree for our pruning decisions at this node:
if x = 0, use v' = eval(P)
if x > 0, use v' = eval(P) - 5 - x/1024
if x < 0, use v' = eval(P) + 5 - x/1024
For reference, the previous master had this simpler rule:
if x > 0, use v' = eval(P) - 10
if x <= 0, use v' = eval(P)
STC:
LLR: 2.95 (-2.94,2.94) [0.00,5.00]
Total: 29322 W: 6359 L: 6088 D: 16875
http://tests.stockfishchess.org/tests/view/5b76a5980ebc5902bdba957f
LTC:
LLR: 2.96 (-2.94,2.94) [0.00,5.00]
Total: 30893 W: 5154 L: 4910 D: 20829
http://tests.stockfishchess.org/tests/view/5b76ca6d0ebc5902bdba9914
Closes https://github.com/official-stockfish/Stockfish/pull/1740
Bench: 4592766
2018-08-17 17:23:36 -06:00
|
|
|
|
2019-01-01 06:13:08 -07:00
|
|
|
tte->save(posKey, VALUE_NONE, ttPv, BOUND_NONE, DEPTH_NONE, MOVE_NONE, pureStaticEval);
|
2011-10-31 01:28:59 -06:00
|
|
|
}
|
2008-08-31 23:59:13 -06:00
|
|
|
|
2018-05-08 17:40:32 -06:00
|
|
|
// Step 7. Razoring (~2 Elo)
|
Fix a segfault.
this patch fixes a rare but reproducible segfault observed playing a
multi-threaded match, it is discussed somewhat in fishcooking.
From the core file, it could be observed that the issue was in qsearch, namely:
````
ss->pv[0] = MOVE_NONE;
````
and the backtrace shows the it arrives there via razoring, called from the rootNode:
````
(gdb) bt
alpha=-19, beta=682, depth=DEPTH_ZERO) at search.cpp:1247
````
Indeed, ss->pv can indeed by a nullptr at the rootNode. However, why is the
segfault so rare ?
The reason is that the condition that guards razoring:
````
(depth < 2 * ONE_PLY && eval <= alpha - RazorMargin)
````
is almost never true, since at the root alpha for depth < 5 is -VALUE_INFINITE.
Nevertheless with the new failHigh scheme, this is not guaranteed, and rootDepth > 5,
can still result in a depth < 2 search at the rootNode. If now another thread,
via the hash, writes a new low eval to the rootPos qsearch can be entered.
Rare but not unseen... I assume that some of the crashes in fishtest recently
might be due to this.
Closes https://github.com/official-stockfish/Stockfish/pull/1860
No functional change
2018-12-16 01:51:29 -07:00
|
|
|
if ( !rootNode // The required rootNode PV handling is not available in qsearch
|
|
|
|
&& depth < 2 * ONE_PLY
|
|
|
|
&& eval <= alpha - RazorMargin)
|
Simple razoring: depth 1 only, no distinction between PV / NonPV
We simplify the razoring logic by applying it to all nodes at depth 1 only.
An added advantage is that only one razor margin is needed now, and we treat
PV and Non-PV nodes in the same manner.
How to continue?
- There may be some conditions in which depth 2 razoring is beneficial.
- We can see whether the razor margin can be tuned, perhaps even with a
different value for PV nodes.
- Perhaps we can unify the treatment of PV and Non-PV nodes in other parts
of the search as well.
STC:
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 5474 W: 1281 L: 1127 D: 3066
http://tests.stockfishchess.org/tests/view/5b6de3b20ebc5902bdba0d1e
LTC:
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 62670 W: 10749 L: 10697 D: 41224
http://tests.stockfishchess.org/tests/view/5b6dee340ebc5902bdba0eb0
In addition, we ran a fixed LTC test against a similar patch which also
passed SPRT [-3, 1]:
ELO: 0.23 +-2.1 (95%) LOS: 58.6%
Total: 36412 W: 6168 L: 6144 D: 24100
http://tests.stockfishchess.org/tests/view/5b6e83940ebc5902bdba1485
We are opting for this patch as the more logical and simple of the two,
and it appears to be no less strong. Thanks in particular to @DU-jdto
for input into this patch.
Bench: 4476945
2018-08-12 01:47:30 -06:00
|
|
|
return qsearch<NT>(pos, ss, alpha, beta);
|
2010-02-24 03:26:36 -07:00
|
|
|
|
2018-05-08 17:40:32 -06:00
|
|
|
improving = ss->staticEval >= (ss-2)->staticEval
|
|
|
|
|| (ss-2)->staticEval == VALUE_NONE;
|
|
|
|
|
|
|
|
// Step 8. Futility pruning: child node (~30 Elo)
|
2018-12-12 12:34:17 -07:00
|
|
|
if ( !PvNode
|
2013-11-08 03:42:22 -07:00
|
|
|
&& depth < 7 * ONE_PLY
|
2018-03-07 14:31:51 -07:00
|
|
|
&& eval - futility_margin(depth, improving) >= beta
|
2018-02-12 14:57:42 -07:00
|
|
|
&& eval < VALUE_KNOWN_WIN) // Do not return unproven wins
|
2016-10-07 23:06:33 -06:00
|
|
|
return eval;
|
2010-01-21 10:03:06 -07:00
|
|
|
|
2018-03-31 19:13:29 -06:00
|
|
|
// Step 9. Null move search with verification search (~40 Elo)
|
2010-05-08 02:54:51 -06:00
|
|
|
if ( !PvNode
|
2018-05-08 02:43:46 -06:00
|
|
|
&& (ss-1)->currentMove != MOVE_NULL
|
2018-08-12 02:02:51 -06:00
|
|
|
&& (ss-1)->statScore < 23200
|
2012-10-22 01:50:00 -06:00
|
|
|
&& eval >= beta
|
Combo
This PR is a combination of two unrelated [0, 4] patches that appeared promising
but not quite strong enough to pass on their own. The combination initially failed
STC with a positive score after a long run, and the subsequent speculative LTC test
passed.
* tweak_threatOnQueen4 :
Increase the middlegame components of ThreatByMinor[QUEEN]
and ThreatByRook[QUEEN] by 15 each. Bryan's (@crossbr) analysis of CCC Bonus Game 10
inspired several tests on penalizing a queen with limited safe mobility. While
attempting to implement this idea, I noticed that when I did not include the queen's
current square in the calculations, the Elo gains seemed to vanish--and only then did
I have the idea to revisit ThreatByMinor[QUEEN] and ThreatByRook[QUEEN], adding a
corresponding value to each. Without Bryan's work, this test would never have been
submitted. I would also like to recognize the efforts and contributions of @SFisGOD,
who also vigorously worked on this idea.
* Use pure static eval for null move pruning :
This idea was directly re-purposed from a promising test by Jerry Donald Watson
(@jerrydonaldwatson) in August. It was also independently developed and tested by
Stefan Geschwentner (@locutus2) previously.
Thank you all!
STC (failed yellow):
LLR: -2.96 (-2.94,2.94) [0.00,4.00]
Total: 83913 W: 17986 L: 17825 D: 48102
http://tests.stockfishchess.org/tests/view/5bbc59300ebc592439f76aa5
LTC:
LLR: 2.95 (-2.94,2.94) [0.00,4.00]
Total: 137198 W: 22351 L: 21772 D: 93075
http://tests.stockfishchess.org/tests/view/5bbce35f0ebc592439f77639
Bench: 4312846
2018-10-08 12:43:45 -06:00
|
|
|
&& pureStaticEval >= beta - 36 * depth / ONE_PLY + 225
|
2018-05-13 22:52:16 -06:00
|
|
|
&& !excludedMove
|
2018-05-22 12:30:58 -06:00
|
|
|
&& pos.non_pawn_material(us)
|
2018-06-04 01:10:30 -06:00
|
|
|
&& (ss->ply >= thisThread->nmpMinPly || us != thisThread->nmpColor))
|
2009-08-29 13:19:09 -06:00
|
|
|
{
|
2014-01-24 13:52:56 -07:00
|
|
|
assert(eval - beta >= 0);
|
2009-11-13 03:25:34 -07:00
|
|
|
|
2014-01-24 13:52:56 -07:00
|
|
|
// Null move dynamic reduction based on depth and value
|
2018-09-03 04:15:31 -06:00
|
|
|
Depth R = ((823 + 67 * depth / ONE_PLY) / 256 + std::min(int(eval - beta) / 200, 3)) * ONE_PLY;
|
2009-08-29 13:19:09 -06:00
|
|
|
|
2017-03-08 19:35:23 -07:00
|
|
|
ss->currentMove = MOVE_NULL;
|
2018-07-28 07:33:39 -06:00
|
|
|
ss->continuationHistory = &thisThread->continuationHistory[NO_PIECE][0];
|
2017-03-08 19:35:23 -07:00
|
|
|
|
2013-01-27 03:45:01 -07:00
|
|
|
pos.do_null_move(st);
|
2018-03-15 02:21:34 -06:00
|
|
|
|
2018-05-08 02:43:46 -06:00
|
|
|
Value nullValue = -search<NonPV>(pos, ss+1, -beta, -beta+1, depth-R, !cutNode);
|
2018-03-15 02:21:34 -06:00
|
|
|
|
2013-01-27 03:45:01 -07:00
|
|
|
pos.undo_null_move();
|
2009-08-24 08:46:03 -06:00
|
|
|
|
2014-02-12 06:16:21 -07:00
|
|
|
if (nullValue >= beta)
|
|
|
|
{
|
|
|
|
// Do not return unproven mate scores
|
|
|
|
if (nullValue >= VALUE_MATE_IN_MAX_PLY)
|
|
|
|
nullValue = beta;
|
|
|
|
|
2018-06-02 09:41:37 -06:00
|
|
|
if (thisThread->nmpMinPly || (abs(beta) < VALUE_KNOWN_WIN && depth < 12 * ONE_PLY))
|
2014-02-12 06:16:21 -07:00
|
|
|
return nullValue;
|
|
|
|
|
2018-06-02 09:41:37 -06:00
|
|
|
assert(!thisThread->nmpMinPly); // Recursive verification is not allowed
|
2018-05-24 10:26:21 -06:00
|
|
|
|
|
|
|
// Do verification search at high depths, with null move pruning disabled
|
2018-06-02 09:41:37 -06:00
|
|
|
// for us, until ply exceeds nmpMinPly.
|
2018-06-04 01:10:30 -06:00
|
|
|
thisThread->nmpMinPly = ss->ply + 3 * (depth-R) / 4;
|
2018-06-02 09:41:37 -06:00
|
|
|
thisThread->nmpColor = us;
|
2017-12-18 08:30:27 -07:00
|
|
|
|
2018-05-08 02:43:46 -06:00
|
|
|
Value v = search<NonPV>(pos, ss, beta-1, beta, depth-R, false);
|
2018-01-13 01:01:23 -07:00
|
|
|
|
2018-06-02 09:41:37 -06:00
|
|
|
thisThread->nmpMinPly = 0;
|
2014-02-12 06:16:21 -07:00
|
|
|
|
|
|
|
if (v >= beta)
|
|
|
|
return nullValue;
|
|
|
|
}
|
2009-08-29 13:19:09 -06:00
|
|
|
}
|
2008-08-31 23:59:13 -06:00
|
|
|
|
2018-05-08 17:40:32 -06:00
|
|
|
// Step 10. ProbCut (~10 Elo)
|
2016-08-28 04:39:49 -06:00
|
|
|
// If we have a good enough capture and a reduced search returns a value
|
|
|
|
// much above beta, we can (almost) safely prune the previous move.
|
2011-05-21 10:17:11 -06:00
|
|
|
if ( !PvNode
|
2012-10-03 02:08:10 -06:00
|
|
|
&& depth >= 5 * ONE_PLY
|
2011-12-30 09:08:07 -07:00
|
|
|
&& abs(beta) < VALUE_MATE_IN_MAX_PLY)
|
2011-05-21 10:17:11 -06:00
|
|
|
{
|
2018-12-11 05:47:56 -07:00
|
|
|
Value raisedBeta = std::min(beta + 216 - 48 * improving, VALUE_INFINITE);
|
|
|
|
MovePicker mp(pos, ttMove, raisedBeta - ss->staticEval, &thisThread->captureHistory);
|
2018-03-03 04:03:38 -07:00
|
|
|
int probCutCount = 0;
|
2018-03-06 14:11:45 -07:00
|
|
|
|
2018-03-03 04:03:38 -07:00
|
|
|
while ( (move = mp.next_move()) != MOVE_NONE
|
2019-01-04 16:27:14 -07:00
|
|
|
&& probCutCount < 2 + 2 * cutNode)
|
2018-08-28 18:27:47 -06:00
|
|
|
if (move != excludedMove && pos.legal(move))
|
2011-05-21 10:17:11 -06:00
|
|
|
{
|
2018-03-03 04:03:38 -07:00
|
|
|
probCutCount++;
|
|
|
|
|
2012-01-21 15:30:56 -07:00
|
|
|
ss->currentMove = move;
|
2018-07-28 07:33:39 -06:00
|
|
|
ss->continuationHistory = &thisThread->continuationHistory[pos.moved_piece(move)][to_sq(move)];
|
2017-03-08 19:35:23 -07:00
|
|
|
|
2017-06-16 20:27:36 -06:00
|
|
|
assert(depth >= 5 * ONE_PLY);
|
2018-02-12 14:57:42 -07:00
|
|
|
|
2016-11-11 06:02:28 -07:00
|
|
|
pos.do_move(move, st);
|
2018-02-25 19:01:37 -07:00
|
|
|
|
2018-03-13 01:20:20 -06:00
|
|
|
// Perform a preliminary qsearch to verify that the move holds
|
2018-12-11 05:47:56 -07:00
|
|
|
value = -qsearch<NonPV>(pos, ss+1, -raisedBeta, -raisedBeta+1);
|
2018-03-13 01:20:20 -06:00
|
|
|
|
2019-02-08 02:36:03 -07:00
|
|
|
// If the qsearch held, perform the regular search
|
2018-12-11 05:47:56 -07:00
|
|
|
if (value >= raisedBeta)
|
|
|
|
value = -search<NonPV>(pos, ss+1, -raisedBeta, -raisedBeta+1, depth - 4 * ONE_PLY, !cutNode);
|
2018-02-25 19:01:37 -07:00
|
|
|
|
2011-05-21 10:17:11 -06:00
|
|
|
pos.undo_move(move);
|
2018-03-02 03:38:11 -07:00
|
|
|
|
2018-12-11 05:47:56 -07:00
|
|
|
if (value >= raisedBeta)
|
2011-05-21 10:17:11 -06:00
|
|
|
return value;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2018-05-08 17:40:32 -06:00
|
|
|
// Step 11. Internal iterative deepening (~2 Elo)
|
2018-04-26 08:56:52 -06:00
|
|
|
if ( depth >= 8 * ONE_PLY
|
|
|
|
&& !ttMove)
|
2008-09-06 10:25:58 -06:00
|
|
|
{
|
2018-05-24 05:31:40 -06:00
|
|
|
search<NT>(pos, ss, alpha, beta, depth - 7 * ONE_PLY, cutNode);
|
2010-06-02 06:32:31 -06:00
|
|
|
|
2014-12-13 00:16:35 -07:00
|
|
|
tte = TT.probe(posKey, ttHit);
|
More robust interaction of singular search and iid
When iid (Internal iterative deepening) is invoked, the prior value of ttValue is
not guaranteed to be VALUE_NONE. As such, it is currently possible to enter a state
in which ttValue has a specific value which is inconsistent with tte->bound() and
tte->depth(). Currently, ttValue is only used within the search in a context that
prevents this situation from making a difference (and so this change is non-functional,
but this is not guaranteed to remain the case in the future.
For instance, just changing the tt depth condition in singular extension node to be
tte->depth() >= depth - 4 * ONE_PLY
instead of
tte->depth() >= depth - 3 * ONE_PLY
interacts badly with the absence of ttMove in iid. For the ttMove to become a singular
extension candidate, singularExtensionNode needs to be true. With the current master,
this requires that tte->depth() >= depth - 3 * ONE_PLY. This is not currently possible
if tte comes from IID, since the depth 'd' used for the IID search is always less than
depth - 4 * ONE_PLY for depth >= 8 * ONE_PLY (below depth 8 singularExtensionNode can
never be true anyway). However, with DU-jdto/Stockfish@251281a , this condition can be
met, and it is possible for singularExtensionNode to become true after IID. There are
then two mechanisms by which this patch can affect the search:
• If ttValue was VALUE_NONE prior to IID, the fact that this patch sets ttValue allows
the 'ttValue != VALUE_NONE' condition of singularExtensionNode to be met.
• If ttValue wasn't VALUE_NONE prior to IID, the fact that this patch modifies ttValue's
value causes a different 'rBeta' to be calculated if the singular extension search is
performed.
Tested at STC for non-regression:
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 76981 W: 17060 L: 17048 D: 42873
http://tests.stockfishchess.org/tests/view/5a7738b70ebc5902971a9868
No functional change
2018-02-24 17:14:29 -07:00
|
|
|
ttValue = ttHit ? value_from_tt(tte->value(), ss->ply) : VALUE_NONE;
|
2014-12-13 00:16:35 -07:00
|
|
|
ttMove = ttHit ? tte->move() : MOVE_NONE;
|
2008-08-31 23:59:13 -06:00
|
|
|
}
|
|
|
|
|
2018-02-12 14:57:42 -07:00
|
|
|
moves_loop: // When in check, search starts from here
|
2010-10-16 03:01:45 -06:00
|
|
|
|
2019-02-27 13:25:12 -07:00
|
|
|
const PieceToHistory* contHist[] = { (ss-1)->continuationHistory, (ss-2)->continuationHistory,
|
|
|
|
nullptr, (ss-4)->continuationHistory,
|
|
|
|
nullptr, (ss-6)->continuationHistory };
|
2017-06-30 09:20:00 -06:00
|
|
|
Move countermove = thisThread->counterMoves[pos.piece_on(prevSq)][prevSq];
|
2013-05-19 13:32:52 -06:00
|
|
|
|
2018-04-28 22:48:18 -06:00
|
|
|
MovePicker mp(pos, ttMove, depth, &thisThread->mainHistory,
|
|
|
|
&thisThread->captureHistory,
|
|
|
|
contHist,
|
|
|
|
countermove,
|
|
|
|
ss->killers);
|
2012-09-29 10:26:17 -06:00
|
|
|
value = bestValue; // Workaround a bogus 'uninitialized' warning under gcc
|
2013-08-09 00:21:55 -06:00
|
|
|
|
2019-02-27 05:36:48 -07:00
|
|
|
moveCountPruning = false;
|
2018-10-02 08:34:40 -06:00
|
|
|
ttCapture = ttMove && pos.capture_or_promotion(ttMove);
|
2010-10-16 03:01:45 -06:00
|
|
|
|
2018-02-12 14:57:42 -07:00
|
|
|
// Step 12. Loop through all pseudo-legal moves until no moves remain
|
|
|
|
// or a beta cutoff occurs.
|
2019-02-27 05:36:48 -07:00
|
|
|
while ((move = mp.next_move(moveCountPruning)) != MOVE_NONE)
|
2008-09-06 10:25:58 -06:00
|
|
|
{
|
2011-10-03 02:56:49 -06:00
|
|
|
assert(is_ok(move));
|
2011-01-16 15:40:06 -07:00
|
|
|
|
2011-05-28 03:35:52 -06:00
|
|
|
if (move == excludedMove)
|
|
|
|
continue;
|
|
|
|
|
2018-02-04 13:42:56 -07:00
|
|
|
// At root obey the "searchmoves" option and skip moves not listed in Root
|
|
|
|
// Move List. As a consequence any illegal move is also skipped. In MultiPV
|
2018-04-18 10:38:38 -06:00
|
|
|
// mode we also skip PV moves which have been already searched and those
|
|
|
|
// of lower "TB rank" if we are in a TB root position.
|
2018-06-02 09:41:37 -06:00
|
|
|
if (rootNode && !std::count(thisThread->rootMoves.begin() + thisThread->pvIdx,
|
|
|
|
thisThread->rootMoves.begin() + thisThread->pvLast, move))
|
2018-02-04 13:42:56 -07:00
|
|
|
continue;
|
2011-07-31 06:18:52 -06:00
|
|
|
|
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
|
|
|
ss->moveCount = ++moveCount;
|
2012-09-29 09:41:53 -06:00
|
|
|
|
2016-01-18 15:20:16 -07:00
|
|
|
if (rootNode && thisThread == Threads.main() && Time.elapsed() > 3000)
|
2015-12-09 00:07:34 -07:00
|
|
|
sync_cout << "info depth " << depth / ONE_PLY
|
|
|
|
<< " currmove " << UCI::move(move, pos.is_chess960())
|
2018-06-02 09:41:37 -06:00
|
|
|
<< " currmovenumber " << moveCount + thisThread->pvIdx << sync_endl;
|
2014-11-12 14:13:55 -07:00
|
|
|
if (PvNode)
|
2015-01-18 00:00:50 -07:00
|
|
|
(ss+1)->pv = nullptr;
|
2014-11-12 14:13:55 -07:00
|
|
|
|
2014-12-07 16:53:33 -07:00
|
|
|
extension = DEPTH_ZERO;
|
2013-09-28 06:43:50 -06:00
|
|
|
captureOrPromotion = pos.capture_or_promotion(move);
|
2017-08-09 19:43:30 -06:00
|
|
|
movedPiece = pos.moved_piece(move);
|
2018-02-26 17:18:33 -07:00
|
|
|
givesCheck = gives_check(pos, move);
|
2014-02-08 05:21:50 -07:00
|
|
|
|
2018-03-31 19:13:29 -06:00
|
|
|
// Step 13. Extensions (~70 Elo)
|
2008-08-31 23:59:13 -06:00
|
|
|
|
2018-04-02 16:13:35 -06:00
|
|
|
// Singular extension search (~60 Elo). If all moves but one fail low on a
|
|
|
|
// search of (alpha-s, beta-s), and just one fails high on (alpha, beta),
|
|
|
|
// then that move is singular and should be extended. To verify this we do
|
2018-09-21 15:18:46 -06:00
|
|
|
// a reduced search on all the other moves but the ttMove and if the
|
2018-02-12 14:57:42 -07:00
|
|
|
// result is lower than ttValue minus a margin then we will extend the ttMove.
|
2018-04-02 16:13:35 -06:00
|
|
|
if ( depth >= 8 * ONE_PLY
|
2012-04-28 04:08:10 -06:00
|
|
|
&& move == ttMove
|
2018-04-02 16:13:35 -06:00
|
|
|
&& !rootNode
|
2018-12-11 05:47:56 -07:00
|
|
|
&& !excludedMove // Avoid recursive singular search
|
2018-04-02 16:13:35 -06:00
|
|
|
&& ttValue != VALUE_NONE
|
|
|
|
&& (tte->bound() & BOUND_LOWER)
|
|
|
|
&& tte->depth() >= depth - 3 * ONE_PLY
|
2016-07-03 02:35:44 -06:00
|
|
|
&& pos.legal(move))
|
2009-11-21 06:22:52 -07:00
|
|
|
{
|
2019-01-05 13:53:21 -07:00
|
|
|
Value singularBeta = std::max(ttValue - 2 * depth / ONE_PLY, -VALUE_MATE);
|
2012-07-14 05:18:14 -06:00
|
|
|
ss->excludedMove = move;
|
2019-01-05 13:53:21 -07:00
|
|
|
value = search<NonPV>(pos, ss, singularBeta - 1, singularBeta, depth / 2, cutNode);
|
2012-07-14 05:18:14 -06:00
|
|
|
ss->excludedMove = MOVE_NONE;
|
|
|
|
|
2019-01-05 13:53:21 -07:00
|
|
|
if (value < singularBeta)
|
2014-12-07 16:53:33 -07:00
|
|
|
extension = ONE_PLY;
|
2019-01-05 13:53:21 -07:00
|
|
|
|
|
|
|
// Multi-cut pruning
|
|
|
|
// Our ttMove is assumed to fail high, and now we failed high also on a reduced
|
|
|
|
// search without the ttMove. So we assume this expected Cut-node is not singular,
|
|
|
|
// that is multiple moves fail high, and we can prune the whole subtree by returning
|
|
|
|
// the hard beta bound.
|
|
|
|
else if (cutNode && singularBeta > beta)
|
|
|
|
return beta;
|
2009-11-21 06:22:52 -07:00
|
|
|
}
|
2019-01-29 07:26:03 -07:00
|
|
|
|
|
|
|
// Check extension (~2 Elo)
|
|
|
|
else if ( givesCheck
|
|
|
|
&& (pos.blockers_for_king(~us) & from_sq(move) || pos.see_ge(move)))
|
2017-03-25 11:10:33 -06:00
|
|
|
extension = ONE_PLY;
|
2009-11-21 06:22:52 -07:00
|
|
|
|
2019-01-29 07:26:03 -07:00
|
|
|
// Castling extension
|
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
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
http://tests.stockfishchess.org/tests/view/5bf994a60ebc5902bced4349
Bench: 3939338
2018-11-23 23:55:09 -07:00
|
|
|
else if (type_of(move) == CASTLING)
|
2018-11-03 08:03:39 -06:00
|
|
|
extension = ONE_PLY;
|
|
|
|
|
2017-01-17 06:50:03 -07:00
|
|
|
// Calculate new depth for this move
|
2014-12-07 16:53:33 -07:00
|
|
|
newDepth = depth - ONE_PLY + extension;
|
2009-11-21 08:05:18 -07:00
|
|
|
|
2018-03-31 19:13:29 -06:00
|
|
|
// Step 14. Pruning at shallow depth (~170 Elo)
|
2016-09-07 21:57:52 -06:00
|
|
|
if ( !rootNode
|
2018-05-22 12:30:58 -06:00
|
|
|
&& pos.non_pawn_material(us)
|
2016-10-15 15:35:10 -06:00
|
|
|
&& bestValue > VALUE_MATED_IN_MAX_PLY)
|
2008-09-06 10:25:58 -06:00
|
|
|
{
|
2019-02-27 05:36:48 -07:00
|
|
|
// Skip quiet moves if movecount exceeds our FutilityMoveCount threshold
|
2019-03-05 12:48:29 -07:00
|
|
|
moveCountPruning = moveCount >= futility_move_count(improving,depth / ONE_PLY);
|
2019-02-27 05:36:48 -07:00
|
|
|
|
2016-09-07 21:57:52 -06:00
|
|
|
if ( !captureOrPromotion
|
|
|
|
&& !givesCheck
|
Remove Null Move Pruning material threshold
On November 30th, @xoto10 experimented with removing this threshold,
but the simplification barely failed LTC. I was inspired to try various
[0, 4] tweaks to increase its value, which would narrow the effects of
this threshold without removing it entirely. Various values repeatedly
led to Elo gains at both STC and LTC, most of which were insufficient
to pass.
After a couple of weeks, I tried again to find an Elo-gaining tweak
but noticed that I could raise the threshold higher and higher without
regression. I decided to try removing it entirely--forgetting that
@xoto10 had already attempted this. However, this now performs much
better at both STC and LTC, producing a STC Elo gain and also potentially
a smaller LTC one.
The reason appears to be a recent change in master (e8ffca3) near
this code, which interacts with this patch. This simplification
governs the conditions under which that patch's effects are applied.
Something non-obvious about that change has significantly improved
the performance of this simplification.
I recognize and thank @xoto10, who originally had this idea. Since
I ran several LTCs recently (to determine whether to open this PR,
or one for a related [0, 4]), I would also like to acknowledge the
other developers and CPU donors for their patience. Thank you all!
STC:
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 13445 W: 3000 L: 2862 D: 7583
http://tests.stockfishchess.org/tests/view/5c11f01b0ebc5902ba11a6b8
LTC:
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 33868 W: 5663 L: 5563 D: 22642
http://tests.stockfishchess.org/tests/view/5c11ffe90ebc5902ba11a8a9
Closes https://github.com/official-stockfish/Stockfish/pull/1870
Bench: 3343286
2018-12-12 22:35:00 -07:00
|
|
|
&& !pos.advanced_pawn_push(move))
|
2016-09-07 21:57:52 -06:00
|
|
|
{
|
2018-03-31 19:13:29 -06:00
|
|
|
// Move count based pruning (~30 Elo)
|
2017-04-22 01:03:17 -06:00
|
|
|
if (moveCountPruning)
|
2016-09-07 21:57:52 -06:00
|
|
|
continue;
|
2008-08-31 23:59:13 -06:00
|
|
|
|
2016-09-14 07:09:41 -06:00
|
|
|
// Reduced depth of the next LMR search
|
2017-08-29 11:06:19 -06:00
|
|
|
int lmrDepth = std::max(newDepth - reduction<PvNode>(improving, depth, moveCount), DEPTH_ZERO) / ONE_PLY;
|
2016-08-12 11:55:12 -06:00
|
|
|
|
2018-03-31 19:13:29 -06:00
|
|
|
// Countermoves based pruning (~20 Elo)
|
2018-12-06 16:14:34 -07:00
|
|
|
if ( lmrDepth < 3 + ((ss-1)->statScore > 0 || (ss-1)->moveCount == 1)
|
2017-08-09 19:43:30 -06:00
|
|
|
&& (*contHist[0])[movedPiece][to_sq(move)] < CounterMovePruneThreshold
|
|
|
|
&& (*contHist[1])[movedPiece][to_sq(move)] < CounterMovePruneThreshold)
|
2016-09-07 21:57:52 -06:00
|
|
|
continue;
|
2015-10-21 16:21:23 -06:00
|
|
|
|
2018-03-31 19:13:29 -06:00
|
|
|
// Futility pruning: parent node (~2 Elo)
|
2016-09-14 07:09:41 -06:00
|
|
|
if ( lmrDepth < 7
|
2016-10-15 15:35:10 -06:00
|
|
|
&& !inCheck
|
2016-09-14 07:09:41 -06:00
|
|
|
&& ss->staticEval + 256 + 200 * lmrDepth <= alpha)
|
2016-09-07 21:57:52 -06:00
|
|
|
continue;
|
2013-11-07 14:29:07 -07:00
|
|
|
|
2018-03-31 19:13:29 -06:00
|
|
|
// Prune moves with negative SEE (~10 Elo)
|
2018-06-12 23:22:52 -06:00
|
|
|
if (!pos.see_ge(move, Value(-29 * lmrDepth * lmrDepth)))
|
2016-09-14 07:09:41 -06:00
|
|
|
continue;
|
2016-07-23 01:49:18 -06:00
|
|
|
}
|
2018-06-11 23:32:21 -06:00
|
|
|
else if ( !extension // (~20 Elo)
|
2018-06-12 16:20:38 -06:00
|
|
|
&& !pos.see_ge(move, -PawnValueEg * (depth / ONE_PLY)))
|
2016-09-14 07:09:41 -06:00
|
|
|
continue;
|
2008-08-31 23:59:13 -06:00
|
|
|
}
|
|
|
|
|
2014-10-03 22:07:55 -06:00
|
|
|
// Speculative prefetch as early as possible
|
2015-02-07 11:13:41 -07:00
|
|
|
prefetch(TT.first_entry(pos.key_after(move)));
|
2014-10-02 15:19:14 -06:00
|
|
|
|
2013-12-02 11:04:09 -07:00
|
|
|
// Check for legality just before making the move
|
2016-07-03 02:35:44 -06:00
|
|
|
if (!rootNode && !pos.legal(move))
|
2011-05-28 03:35:52 -06:00
|
|
|
{
|
2015-07-28 04:53:13 -06:00
|
|
|
ss->moveCount = --moveCount;
|
2011-05-23 07:14:47 -06:00
|
|
|
continue;
|
2011-05-28 03:35:52 -06:00
|
|
|
}
|
2017-06-23 23:15:46 -06:00
|
|
|
|
2017-01-17 06:50:03 -07:00
|
|
|
// Update the current move (this must be done after singular extension search)
|
2011-05-23 07:14:47 -06:00
|
|
|
ss->currentMove = move;
|
2018-07-28 07:33:39 -06:00
|
|
|
ss->continuationHistory = &thisThread->continuationHistory[movedPiece][to_sq(move)];
|
2011-05-23 07:14:47 -06:00
|
|
|
|
2018-02-12 14:57:42 -07:00
|
|
|
// Step 15. Make the move
|
Compute checkers from scratch
This micro-optimization only complicates the code and provides no benefit.
Removing it is even a speedup on my machine (i7-3770k, linux, gcc 4.9.1):
stat test master diff
mean 2,403,118 2,390,904 12,214
stdev 12,043 10,620 3,677
speedup 0.51%
P(speedup>0) 100.0%
No functional change.
2015-02-15 00:49:20 -07:00
|
|
|
pos.do_move(move, st, givesCheck);
|
2008-09-03 15:33:49 -06:00
|
|
|
|
2018-02-12 14:57:42 -07:00
|
|
|
// Step 16. Reduced depth search (LMR). If the move fails high it will be
|
2011-11-19 05:55:26 -07:00
|
|
|
// re-searched at full depth.
|
2013-09-07 01:20:22 -06:00
|
|
|
if ( depth >= 3 * ONE_PLY
|
2014-11-07 14:40:24 -07:00
|
|
|
&& moveCount > 1
|
2016-08-16 07:53:45 -06:00
|
|
|
&& (!captureOrPromotion || moveCountPruning))
|
2008-09-06 10:25:58 -06:00
|
|
|
{
|
2017-09-04 14:27:22 -06:00
|
|
|
Depth r = reduction<PvNode>(improving, depth, moveCount);
|
2016-08-16 07:53:45 -06:00
|
|
|
|
2019-01-09 07:05:28 -07:00
|
|
|
// Decrease reduction if position is or has been on the PV
|
2019-01-01 06:13:08 -07:00
|
|
|
if (ttPv)
|
2019-01-09 07:05:28 -07:00
|
|
|
r -= ONE_PLY;
|
|
|
|
|
2018-08-08 01:45:58 -06:00
|
|
|
// Decrease reduction if opponent's move count is high (~10 Elo)
|
|
|
|
if ((ss-1)->moveCount > 15)
|
|
|
|
r -= ONE_PLY;
|
2017-09-04 14:27:22 -06:00
|
|
|
|
2018-08-08 01:45:58 -06:00
|
|
|
if (!captureOrPromotion)
|
|
|
|
{
|
2018-04-18 11:17:16 -06:00
|
|
|
// Increase reduction if ttMove is a capture (~0 Elo)
|
2017-06-21 15:05:14 -06:00
|
|
|
if (ttCapture)
|
|
|
|
r += ONE_PLY;
|
2017-06-23 23:15:46 -06:00
|
|
|
|
2018-04-18 11:17:16 -06:00
|
|
|
// Increase reduction for cut nodes (~5 Elo)
|
2016-08-16 07:53:45 -06:00
|
|
|
if (cutNode)
|
|
|
|
r += 2 * ONE_PLY;
|
|
|
|
|
|
|
|
// Decrease reduction for moves that escape a capture. Filter out
|
|
|
|
// castling moves, because they are coded as "king captures rook" and
|
2018-04-18 11:17:16 -06:00
|
|
|
// hence break make_move(). (~5 Elo)
|
2017-05-09 05:50:05 -06:00
|
|
|
else if ( type_of(move) == NORMAL
|
|
|
|
&& !pos.see_ge(make_move(to_sq(move), from_sq(move))))
|
2016-08-16 07:53:45 -06:00
|
|
|
r -= 2 * ONE_PLY;
|
|
|
|
|
2018-05-22 12:30:58 -06:00
|
|
|
ss->statScore = thisThread->mainHistory[us][from_to(move)]
|
2017-08-09 19:43:30 -06:00
|
|
|
+ (*contHist[0])[movedPiece][to_sq(move)]
|
|
|
|
+ (*contHist[1])[movedPiece][to_sq(move)]
|
|
|
|
+ (*contHist[3])[movedPiece][to_sq(move)]
|
2017-06-30 09:20:00 -06:00
|
|
|
- 4000;
|
2016-10-24 08:05:02 -06:00
|
|
|
|
2018-04-18 11:17:16 -06:00
|
|
|
// Decrease/increase reduction by comparing opponent's stat score (~10 Elo)
|
2017-09-21 00:58:29 -06:00
|
|
|
if (ss->statScore >= 0 && (ss-1)->statScore < 0)
|
2016-10-24 08:05:02 -06:00
|
|
|
r -= ONE_PLY;
|
|
|
|
|
2017-09-21 00:58:29 -06:00
|
|
|
else if ((ss-1)->statScore >= 0 && ss->statScore < 0)
|
2016-10-24 08:05:02 -06:00
|
|
|
r += ONE_PLY;
|
|
|
|
|
2018-04-18 11:17:16 -06:00
|
|
|
// Decrease/increase reduction for moves with a good/bad history (~30 Elo)
|
2018-07-20 20:21:54 -06:00
|
|
|
r -= ss->statScore / 20000 * ONE_PLY;
|
2016-08-16 07:53:45 -06:00
|
|
|
}
|
2014-06-03 03:32:45 -06:00
|
|
|
|
2018-07-20 20:21:54 -06:00
|
|
|
Depth d = std::max(newDepth - std::max(r, DEPTH_ZERO), ONE_PLY);
|
2011-06-25 07:31:57 -06:00
|
|
|
|
2018-05-08 02:43:46 -06:00
|
|
|
value = -search<NonPV>(pos, ss+1, -(alpha+1), -alpha, d, true);
|
2011-06-25 07:31:57 -06:00
|
|
|
|
2016-08-16 07:53:45 -06:00
|
|
|
doFullDepthSearch = (value > alpha && d != newDepth);
|
2011-11-19 05:55:26 -07:00
|
|
|
}
|
|
|
|
else
|
2014-11-08 03:39:38 -07:00
|
|
|
doFullDepthSearch = !PvNode || moveCount > 1;
|
2010-05-08 02:54:51 -06:00
|
|
|
|
2018-02-12 14:57:42 -07:00
|
|
|
// Step 17. Full depth search when LMR is skipped or fails high
|
2011-11-19 05:55:26 -07:00
|
|
|
if (doFullDepthSearch)
|
2018-05-08 02:43:46 -06:00
|
|
|
value = -search<NonPV>(pos, ss+1, -(alpha+1), -alpha, newDepth, !cutNode);
|
2010-02-24 03:55:58 -07:00
|
|
|
|
2013-12-02 11:04:09 -07:00
|
|
|
// For PV nodes only, do a full PV search on the first move or after a fail
|
|
|
|
// high (in the latter case search only if value < beta), otherwise let the
|
2016-01-16 14:34:29 -07:00
|
|
|
// parent node fail low with value <= alpha and try another move.
|
2016-01-18 15:20:16 -07:00
|
|
|
if (PvNode && (moveCount == 1 || (value > alpha && (rootNode || value < beta))))
|
2014-11-18 03:57:57 -07:00
|
|
|
{
|
|
|
|
(ss+1)->pv = pv;
|
2014-11-21 01:10:52 -07:00
|
|
|
(ss+1)->pv[0] = MOVE_NONE;
|
|
|
|
|
2018-05-08 02:43:46 -06:00
|
|
|
value = -search<PV>(pos, ss+1, -beta, -alpha, newDepth, false);
|
2014-11-12 14:13:55 -07:00
|
|
|
}
|
2014-11-18 03:57:57 -07:00
|
|
|
|
2018-02-12 14:57:42 -07:00
|
|
|
// Step 18. Undo move
|
2009-02-22 09:49:52 -07:00
|
|
|
pos.undo_move(move);
|
2008-08-31 23:59:13 -06:00
|
|
|
|
|
|
|
assert(value > -VALUE_INFINITE && value < VALUE_INFINITE);
|
2008-09-03 15:33:49 -06:00
|
|
|
|
2018-02-12 14:57:42 -07:00
|
|
|
// Step 19. Check for a new best move
|
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
|
|
|
// Finished searching the move. If a stop occurred, the return value of
|
|
|
|
// the search cannot be trusted, and we return immediately without
|
2014-05-01 00:28:49 -06:00
|
|
|
// updating best move, PV and TT.
|
2017-07-13 17:07:19 -06:00
|
|
|
if (Threads.stop.load(std::memory_order_relaxed))
|
2014-05-01 08:25:17 -06:00
|
|
|
return VALUE_ZERO;
|
2013-08-15 01:36:26 -06:00
|
|
|
|
2016-01-18 15:20:16 -07:00
|
|
|
if (rootNode)
|
2011-01-16 04:02:32 -07:00
|
|
|
{
|
2015-10-23 23:27:24 -06:00
|
|
|
RootMove& rm = *std::find(thisThread->rootMoves.begin(),
|
|
|
|
thisThread->rootMoves.end(), move);
|
2011-01-16 04:02:32 -07:00
|
|
|
|
2018-02-12 14:57:42 -07:00
|
|
|
// PV move or new best move?
|
2014-11-08 03:39:38 -07:00
|
|
|
if (moveCount == 1 || value > alpha)
|
2011-01-16 04:02:32 -07:00
|
|
|
{
|
2011-12-12 09:55:20 -07:00
|
|
|
rm.score = value;
|
2017-07-13 17:30:03 -06:00
|
|
|
rm.selDepth = thisThread->selDepth;
|
2014-11-12 14:13:55 -07:00
|
|
|
rm.pv.resize(1);
|
2014-11-21 01:10:52 -07:00
|
|
|
|
|
|
|
assert((ss+1)->pv);
|
|
|
|
|
|
|
|
for (Move* m = (ss+1)->pv; *m != MOVE_NONE; ++m)
|
|
|
|
rm.pv.push_back(*m);
|
2011-01-16 04:02:32 -07:00
|
|
|
|
|
|
|
// We record how often the best move has been changed in each
|
2011-02-12 11:04:27 -07:00
|
|
|
// iteration. This information is used for time management: When
|
2011-01-16 04:02:32 -07:00
|
|
|
// the best move changes frequently, we allocate some more time.
|
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
|
|
|
if (moveCount > 1 && thisThread == Threads.main())
|
2015-12-23 02:07:54 -07:00
|
|
|
++static_cast<MainThread*>(thisThread)->bestMoveChanges;
|
2011-02-17 01:24:55 -07:00
|
|
|
}
|
|
|
|
else
|
2017-07-23 18:25:23 -06:00
|
|
|
// All other moves but the PV are set to the lowest value: this
|
|
|
|
// is not a problem when sorting because the sort is stable and the
|
2013-12-02 11:04:09 -07:00
|
|
|
// move position in the list is preserved - just the PV is pushed up.
|
2011-12-12 09:55:20 -07:00
|
|
|
rm.score = -VALUE_INFINITE;
|
2011-12-10 11:14:13 -07:00
|
|
|
}
|
2011-01-16 04:02:32 -07:00
|
|
|
|
2011-08-06 02:15:46 -06:00
|
|
|
if (value > bestValue)
|
|
|
|
{
|
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
|
|
|
bestValue = value;
|
2011-08-06 02:15:46 -06:00
|
|
|
|
2012-10-03 06:11:20 -06:00
|
|
|
if (value > alpha)
|
2012-10-01 01:33:13 -06:00
|
|
|
{
|
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
|
|
|
bestMove = move;
|
2012-10-03 06:11:20 -06:00
|
|
|
|
2016-01-18 15:20:16 -07:00
|
|
|
if (PvNode && !rootNode) // Update pv even in fail-high case
|
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
|
|
|
update_pv(ss->pv, move, (ss+1)->pv);
|
2014-11-12 14:13:55 -07:00
|
|
|
|
2013-01-13 04:34:31 -07:00
|
|
|
if (PvNode && value < beta) // Update alpha! Always alpha < beta
|
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
|
|
|
alpha = value;
|
2012-11-17 04:44:19 -07:00
|
|
|
else
|
2012-10-05 07:00:35 -06:00
|
|
|
{
|
2012-11-17 04:44:19 -07:00
|
|
|
assert(value >= beta); // Fail high
|
2018-05-21 23:21:57 -06:00
|
|
|
ss->statScore = 0;
|
2012-10-05 07:00:35 -06:00
|
|
|
break;
|
|
|
|
}
|
2011-08-06 02:15:46 -06:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2018-02-12 14:57:42 -07:00
|
|
|
if (move != bestMove)
|
|
|
|
{
|
|
|
|
if (captureOrPromotion && captureCount < 32)
|
|
|
|
capturesSearched[captureCount++] = move;
|
|
|
|
|
|
|
|
else if (!captureOrPromotion && quietCount < 64)
|
|
|
|
quietsSearched[quietCount++] = move;
|
|
|
|
}
|
2008-08-31 23:59:13 -06:00
|
|
|
}
|
|
|
|
|
2016-01-16 14:34:29 -07:00
|
|
|
// The following condition would detect a stop only after move loop has been
|
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
|
|
|
// completed. But in this case bestValue is valid because we have fully
|
|
|
|
// searched our subtree, and we can anyhow save the result in TT.
|
2014-05-01 00:28:49 -06:00
|
|
|
/*
|
2017-07-13 17:07:19 -06:00
|
|
|
if (Threads.stop)
|
2014-05-01 00:28:49 -06:00
|
|
|
return VALUE_DRAW;
|
|
|
|
*/
|
|
|
|
|
2011-05-21 10:17:11 -06:00
|
|
|
// Step 20. Check for mate and stalemate
|
2011-10-18 04:24:47 -06:00
|
|
|
// All legal moves have been searched and if there are no legal moves, it
|
2016-01-16 14:34:29 -07:00
|
|
|
// must be a mate or a stalemate. If we are in a singular extension search then
|
2014-05-01 00:28:49 -06:00
|
|
|
// return a fail low score.
|
2016-10-03 07:36:40 -06:00
|
|
|
|
|
|
|
assert(moveCount || !inCheck || excludedMove || !MoveList<LEGAL>(pos).size());
|
|
|
|
|
2012-10-03 06:11:20 -06:00
|
|
|
if (!moveCount)
|
2014-05-11 02:56:25 -06:00
|
|
|
bestValue = excludedMove ? alpha
|
A better contempt implementation for Stockfish (#1325)
* A better contempt implementation for Stockfish
The round 2 of TCEC season 10 demonstrated the benefit of having a nice contempt implementation: it gives the strongest programs in the tournament the ability to slow down the game when they feel the position is slightly worse, prefering to stay in a complicated (even if slightly risky) middle game rather than simplifying by force into a drawn endgame.
The current contempt implementation of Stockfish is inadequate, and this patch is an attempt to provide a better one.
Passed STC non-regression test against master:
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 83360 W: 15089 L: 15075 D: 53196
http://tests.stockfishchess.org/tests/view/5a1bf2de0ebc590ccbb8b370
This contempt implementation is showing promising results in certains situations. For instance, it obtained a nice +30 Elo gain when playing with contempt=40 against Stockfish 7, compared to current master:
• master against SF 7 (20000 games at LTC): +121.2 Elo
• this patch with contempt=40 (20000 games at LTC): +154.11 Elo
This was the result of real cooperative work from the Stockfish team, with key ideas coming from Stefan Geschwentner (locutus2) and Chris Cain (ceebo) while most of the community helped with feedback and computer time.
In this commit the bench is unchanged by default, but you can test at home with the new contempt in the UCI options. The style of play will change a lot when using contempt different of zero (I repeat: not done in this version by default, however)!
The Stockfish team is still deliberating over the best default contempt value in self-play and the best contempt modeling strategy, to help users choosing a contempt value when playing against much weaker programs. These informations will be given in future commits when available :-)
Bench: 5051254
* Remove the prefetch
No functional change.
2017-12-04 23:25:42 -07:00
|
|
|
: inCheck ? mated_in(ss->ply) : VALUE_DRAW;
|
2016-08-23 07:57:56 -06:00
|
|
|
else if (bestMove)
|
2016-08-24 08:52:05 -06:00
|
|
|
{
|
2017-01-09 03:57:34 -07:00
|
|
|
// Quiet best move: update move sorting heuristics
|
2016-08-24 08:52:05 -06:00
|
|
|
if (!pos.capture_or_promotion(bestMove))
|
2018-06-11 01:46:05 -06:00
|
|
|
update_quiet_stats(pos, ss, bestMove, quietsSearched, quietCount,
|
|
|
|
stat_bonus(depth + (bestValue > beta + PawnValueMg ? ONE_PLY : DEPTH_ZERO)));
|
2018-07-03 17:11:54 -06:00
|
|
|
|
|
|
|
update_capture_stats(pos, bestMove, capturesSearched, captureCount, stat_bonus(depth + ONE_PLY));
|
2016-08-24 08:52:05 -06:00
|
|
|
|
2018-12-06 06:39:41 -07:00
|
|
|
// Extra penalty for a quiet TT or main killer move in previous ply when it gets refuted
|
2018-12-19 13:04:36 -07:00
|
|
|
if ( ((ss-1)->moveCount == 1 || ((ss-1)->currentMove == (ss-1)->killers[0]))
|
|
|
|
&& !pos.captured_piece())
|
2018-12-06 06:39:41 -07:00
|
|
|
update_continuation_histories(ss-1, pos.piece_on(prevSq), prevSq, -stat_bonus(depth + ONE_PLY));
|
|
|
|
|
2016-08-24 08:52:05 -06:00
|
|
|
}
|
2015-10-12 15:00:54 -06:00
|
|
|
// Bonus for prior countermove that caused the fail low
|
2018-05-13 22:52:16 -06:00
|
|
|
else if ( (depth >= 3 * ONE_PLY || PvNode)
|
2018-12-19 13:04:36 -07:00
|
|
|
&& !pos.captured_piece())
|
2017-06-30 09:20:00 -06:00
|
|
|
update_continuation_histories(ss-1, pos.piece_on(prevSq), prevSq, stat_bonus(depth));
|
2015-10-12 15:00:54 -06:00
|
|
|
|
2018-01-28 06:40:07 -07:00
|
|
|
if (PvNode)
|
|
|
|
bestValue = std::min(bestValue, maxValue);
|
|
|
|
|
2017-04-22 01:03:17 -06:00
|
|
|
if (!excludedMove)
|
2019-01-01 06:13:08 -07:00
|
|
|
tte->save(posKey, value_to_tt(bestValue, ss->ply), ttPv,
|
2017-04-22 01:03:17 -06:00
|
|
|
bestValue >= beta ? BOUND_LOWER :
|
|
|
|
PvNode && bestMove ? BOUND_EXACT : BOUND_UPPER,
|
2018-08-20 04:06:52 -06:00
|
|
|
depth, bestMove, pureStaticEval);
|
2010-05-08 02:54:51 -06:00
|
|
|
|
2009-03-22 07:49:18 -06:00
|
|
|
assert(bestValue > -VALUE_INFINITE && bestValue < VALUE_INFINITE);
|
|
|
|
|
2008-08-31 23:59:13 -06:00
|
|
|
return bestValue;
|
|
|
|
}
|
2008-09-03 15:33:49 -06:00
|
|
|
|
2011-12-10 11:14:13 -07:00
|
|
|
|
2008-08-31 23:59:13 -06:00
|
|
|
// qsearch() is the quiescence search function, which is called by the main
|
2016-12-20 03:17:38 -07:00
|
|
|
// search function with depth zero, or recursively with depth less than ONE_PLY.
|
2018-03-13 01:10:59 -06:00
|
|
|
template <NodeType NT>
|
2011-12-04 03:46:31 -07:00
|
|
|
Value qsearch(Position& pos, Stack* ss, Value alpha, Value beta, Depth depth) {
|
2008-08-31 23:59:13 -06:00
|
|
|
|
Renaming some variables in code
Implements renaming suggestions by Marco Costalba, Günther Demetz,
Gontran Lemaire, Ronald de Man, Stéphane Nicolet, Alain Savard,
Joost VandeVondele, Jerry Donald Watson, Mike Whiteley, xoto10,
and I hope that I haven't forgotten anybody.
Perpetual renaming thread for suggestions:
https://github.com/official-stockfish/Stockfish/issues/1426
No functional change.
2018-03-15 03:44:26 -06:00
|
|
|
constexpr bool PvNode = NT == PV;
|
2011-05-28 05:13:42 -06:00
|
|
|
|
2011-12-26 17:00:44 -07:00
|
|
|
assert(alpha >= -VALUE_INFINITE && alpha < beta && beta <= VALUE_INFINITE);
|
2012-10-07 01:34:04 -06:00
|
|
|
assert(PvNode || (alpha == beta - 1));
|
2011-12-26 17:00:44 -07:00
|
|
|
assert(depth <= DEPTH_ZERO);
|
2016-08-19 04:17:38 -06:00
|
|
|
assert(depth / ONE_PLY * ONE_PLY == depth);
|
2008-08-31 23:59:13 -06:00
|
|
|
|
2014-11-18 03:57:57 -07:00
|
|
|
Move pv[MAX_PLY+1];
|
2009-11-05 03:11:02 -07:00
|
|
|
StateInfo st;
|
2014-12-13 00:16:35 -07:00
|
|
|
TTEntry* tte;
|
2012-10-07 01:34:04 -06:00
|
|
|
Key posKey;
|
|
|
|
Move ttMove, move, bestMove;
|
2018-02-12 14:57:42 -07:00
|
|
|
Depth ttDepth;
|
2012-12-15 03:11:38 -07:00
|
|
|
Value bestValue, value, ttValue, futilityValue, futilityBase, oldAlpha;
|
2019-01-09 07:05:28 -07:00
|
|
|
bool ttHit, pvHit, inCheck, givesCheck, evasionPrunable;
|
2017-05-21 19:25:20 -06:00
|
|
|
int moveCount;
|
2009-11-05 03:11:02 -07:00
|
|
|
|
2014-11-18 03:57:57 -07:00
|
|
|
if (PvNode)
|
|
|
|
{
|
|
|
|
oldAlpha = alpha; // To flag BOUND_EXACT when eval above alpha and no available moves
|
|
|
|
(ss+1)->pv = pv;
|
|
|
|
ss->pv[0] = MOVE_NONE;
|
2014-11-12 14:13:55 -07:00
|
|
|
}
|
|
|
|
|
2018-07-19 10:26:05 -06:00
|
|
|
Thread* thisThread = pos.this_thread();
|
Let ss->ply denote the number of plies from the root to the current node
This patch lets ss->ply be equal to 0 at the root of the search.
Currently, the root has ss->ply == 1, which is less intuitive:
- Setting the rootNode bool has to check (ss-1)->ply == 0.
- All mate values are off by one: the code seems to assume that mated-in-0
is -VALUE_MATE, mate-1-in-ply is VALUE_MATE-1, mated-in-2-ply is VALUE_MATE+2, etc.
But the mate_in() and mated_in() functions are called with ss->ply, which is 1 in
at the root.
- The is_draw() function currently needs to explain why it has "ply - 1 > i" instead
of simply "ply > i".
- The ss->ply >= MAX_PLY tests in search() and qsearch() already assume that
ss->ply == 0 at the root. If we start at ss->ply == 1, it would make more sense to
go up to and including ss->ply == MAX_PLY, so stop at ss->ply > MAX_PLY. See also
the asserts testing for 0 <= ss->ply && ss->ply < MAX_PLY.
The reason for ss->ply == 1 at the root is the line "ss->ply = (ss-1)->ply + 1" at
the start for search() and qsearch(). By replacing this with "(ss+1)->ply = ss->ply + 1"
we keep ss->ply == 0 at the root. Note that search() already clears killers in (ss+2),
so there is no danger in accessing ss+1.
I have NOT changed pv[MAX_PLY + 1] to pv[MAX_PLY + 2] in search() and qsearch().
It seems to me that MAX_PLY + 1 is exactly right:
- MAX_PLY entries for ss->ply running from 0 to MAX_PLY-1, and 1 entry for the
final MOVE_NONE.
I have verified that mate scores are reported correctly. (They were already reported
correctly due to the extra ply being rounded down when converting to moves.)
The value of seldepth output to the user should probably not change, so I add 1 to it.
(Humans count from 1, computers from 0.)
A small optimisation I did not include: instead of setting ss->ply in every invocation
of search() and qsearch(), it could be set once for all plies at the start of
Thread::search(). This saves a couple of instructions per node.
No functional change (unless the search searches a branch MAX_PLY deep), so bench
does not change.
2017-09-16 13:49:29 -06:00
|
|
|
(ss+1)->ply = ss->ply + 1;
|
2018-02-12 14:57:42 -07:00
|
|
|
ss->currentMove = bestMove = MOVE_NONE;
|
2018-07-28 07:33:39 -06:00
|
|
|
ss->continuationHistory = &thisThread->continuationHistory[NO_PIECE][0];
|
2018-03-20 18:26:12 -06:00
|
|
|
inCheck = pos.checkers();
|
2017-05-21 19:25:20 -06:00
|
|
|
moveCount = 0;
|
2008-08-31 23:59:13 -06:00
|
|
|
|
2018-02-12 14:57:42 -07:00
|
|
|
// Check for an immediate draw or maximum ply reached
|
|
|
|
if ( pos.is_draw(ss->ply)
|
|
|
|
|| ss->ply >= MAX_PLY)
|
2018-03-13 16:19:36 -06:00
|
|
|
return (ss->ply >= MAX_PLY && !inCheck) ? evaluate(pos) : VALUE_DRAW;
|
Cleanup MAX_PLY
This area has become obscure and tricky over the course of incremental
changes that did not respect the original's consistency and clarity. Now,
it's not clear why we use MAX_PLY = 120, or why we use MAX_PLY+6, among
other things.
This patch does the following:
* ID loop: depth ranges from 1 to MAX_PLY-1, and due to TT constraint (depth
must fit into an int8_t), MAX_PLY should be 128.
* stack[]: plies now range from 0 to MAX_PLY-1, hence stack[MAX_PLY+4],
because of the extra 2+2 padding elements (for ss-2 and ss+2). Document this
better, while we're at it.
* Enforce 0 <= ply < MAX_PLY:
- stop condition is now ss->ply >= MAX_PLY and not ss->ply > MAX_PLY.
- assert(ss->ply < MAX_PLY), before using ss+1 and ss+2.
- as a result, we don't need the artificial MAX_PLY+6 range. Instead we
can use MAX_PLY+4 and it's clear why (for ss-2 and ss+2).
* fix: extract_pv_from_tt() and insert_pv_in_tt() had no reason to use
MAX_PLY_PLUS_6, because the array is indexed by plies, so the range of
available plies applies (0..MAX_PLY before, and now 0..MAX_PLY-1).
Tested with debug compile, using MAX_PLY=16, and running bench at depth 17,
using 1 and 7 threads. No assert() fired. Feel free to submit to more severe
crash-tests, if you can think of any.
No functional change.
2014-11-03 08:36:24 -07:00
|
|
|
|
|
|
|
assert(0 <= ss->ply && ss->ply < MAX_PLY);
|
2011-07-19 20:31:50 -06:00
|
|
|
|
2013-12-02 11:04:09 -07:00
|
|
|
// Decide whether or not to include checks: this fixes also the type of
|
2013-03-11 08:18:15 -06:00
|
|
|
// TT entry depth that we are going to use. Note that in qsearch we use
|
|
|
|
// only two types of depth in TT: DEPTH_QS_CHECKS or DEPTH_QS_NO_CHECKS.
|
2018-03-13 16:19:36 -06:00
|
|
|
ttDepth = inCheck || depth >= DEPTH_QS_CHECKS ? DEPTH_QS_CHECKS
|
2013-03-11 08:18:15 -06:00
|
|
|
: DEPTH_QS_NO_CHECKS;
|
2013-06-30 05:12:04 -06:00
|
|
|
// Transposition table lookup
|
2012-10-07 01:34:04 -06:00
|
|
|
posKey = pos.key();
|
2014-12-13 00:16:35 -07:00
|
|
|
tte = TT.probe(posKey, ttHit);
|
|
|
|
ttValue = ttHit ? value_from_tt(tte->value(), ss->ply) : VALUE_NONE;
|
More robust interaction of singular search and iid
When iid (Internal iterative deepening) is invoked, the prior value of ttValue is
not guaranteed to be VALUE_NONE. As such, it is currently possible to enter a state
in which ttValue has a specific value which is inconsistent with tte->bound() and
tte->depth(). Currently, ttValue is only used within the search in a context that
prevents this situation from making a difference (and so this change is non-functional,
but this is not guaranteed to remain the case in the future.
For instance, just changing the tt depth condition in singular extension node to be
tte->depth() >= depth - 4 * ONE_PLY
instead of
tte->depth() >= depth - 3 * ONE_PLY
interacts badly with the absence of ttMove in iid. For the ttMove to become a singular
extension candidate, singularExtensionNode needs to be true. With the current master,
this requires that tte->depth() >= depth - 3 * ONE_PLY. This is not currently possible
if tte comes from IID, since the depth 'd' used for the IID search is always less than
depth - 4 * ONE_PLY for depth >= 8 * ONE_PLY (below depth 8 singularExtensionNode can
never be true anyway). However, with DU-jdto/Stockfish@251281a , this condition can be
met, and it is possible for singularExtensionNode to become true after IID. There are
then two mechanisms by which this patch can affect the search:
• If ttValue was VALUE_NONE prior to IID, the fact that this patch sets ttValue allows
the 'ttValue != VALUE_NONE' condition of singularExtensionNode to be met.
• If ttValue wasn't VALUE_NONE prior to IID, the fact that this patch modifies ttValue's
value causes a different 'rBeta' to be calculated if the singular extension search is
performed.
Tested at STC for non-regression:
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 76981 W: 17060 L: 17048 D: 42873
http://tests.stockfishchess.org/tests/view/5a7738b70ebc5902971a9868
No functional change
2018-02-24 17:14:29 -07:00
|
|
|
ttMove = ttHit ? tte->move() : MOVE_NONE;
|
2019-01-01 06:13:08 -07:00
|
|
|
pvHit = ttHit && tte->is_pv();
|
2012-10-07 01:34:04 -06:00
|
|
|
|
2014-11-18 03:57:57 -07:00
|
|
|
if ( !PvNode
|
2014-12-13 00:16:35 -07:00
|
|
|
&& ttHit
|
2012-12-15 03:11:38 -07:00
|
|
|
&& tte->depth() >= ttDepth
|
|
|
|
&& ttValue != VALUE_NONE // Only in case of TT access race
|
2018-07-16 14:53:50 -06:00
|
|
|
&& (ttValue >= beta ? (tte->bound() & BOUND_LOWER)
|
|
|
|
: (tte->bound() & BOUND_UPPER)))
|
2012-12-15 03:11:38 -07:00
|
|
|
return ttValue;
|
2008-09-08 23:37:46 -06:00
|
|
|
|
2009-11-28 03:52:13 -07:00
|
|
|
// Evaluate the position statically
|
2018-03-13 16:19:36 -06:00
|
|
|
if (inCheck)
|
2010-05-22 02:56:46 -06:00
|
|
|
{
|
2013-11-08 03:42:22 -07:00
|
|
|
ss->staticEval = VALUE_NONE;
|
2010-06-03 11:29:48 -06:00
|
|
|
bestValue = futilityBase = -VALUE_INFINITE;
|
2010-05-22 02:56:46 -06:00
|
|
|
}
|
2009-03-24 08:48:14 -06:00
|
|
|
else
|
2010-01-21 08:58:00 -07:00
|
|
|
{
|
2014-12-13 00:16:35 -07:00
|
|
|
if (ttHit)
|
2012-12-27 04:13:31 -07:00
|
|
|
{
|
2012-12-31 08:28:40 -07:00
|
|
|
// Never assume anything on values stored in TT
|
2015-01-09 04:35:44 -07:00
|
|
|
if ((ss->staticEval = bestValue = tte->eval()) == VALUE_NONE)
|
2014-06-06 01:35:34 -06:00
|
|
|
ss->staticEval = bestValue = evaluate(pos);
|
2013-10-07 01:10:48 -06:00
|
|
|
|
|
|
|
// Can ttValue be used as a better position evaluation?
|
2018-07-16 14:53:50 -06:00
|
|
|
if ( ttValue != VALUE_NONE
|
2017-07-27 03:14:18 -06:00
|
|
|
&& (tte->bound() & (ttValue > bestValue ? BOUND_LOWER : BOUND_UPPER)))
|
|
|
|
bestValue = ttValue;
|
2012-12-27 04:13:31 -07:00
|
|
|
}
|
2012-12-01 10:06:29 -07:00
|
|
|
else
|
2014-06-06 03:12:05 -06:00
|
|
|
ss->staticEval = bestValue =
|
2015-10-23 23:27:24 -06:00
|
|
|
(ss-1)->currentMove != MOVE_NULL ? evaluate(pos)
|
|
|
|
: -(ss-1)->staticEval + 2 * Eval::Tempo;
|
2010-01-21 08:58:00 -07:00
|
|
|
|
2010-06-03 11:29:48 -06:00
|
|
|
// Stand pat. Return immediately if static value is at least beta
|
|
|
|
if (bestValue >= beta)
|
|
|
|
{
|
2014-12-13 00:16:35 -07:00
|
|
|
if (!ttHit)
|
2019-01-09 07:05:28 -07:00
|
|
|
tte->save(posKey, value_to_tt(bestValue, ss->ply), pvHit, BOUND_LOWER,
|
2018-07-03 16:58:16 -06:00
|
|
|
DEPTH_NONE, MOVE_NONE, ss->staticEval);
|
2010-06-04 01:46:38 -06:00
|
|
|
|
2010-06-03 11:29:48 -06:00
|
|
|
return bestValue;
|
|
|
|
}
|
2009-03-27 08:30:45 -06:00
|
|
|
|
2010-06-03 11:29:48 -06:00
|
|
|
if (PvNode && bestValue > alpha)
|
|
|
|
alpha = bestValue;
|
2008-09-07 00:31:30 -06:00
|
|
|
|
2014-04-27 02:13:59 -06:00
|
|
|
futilityBase = bestValue + 128;
|
2010-06-03 11:29:48 -06:00
|
|
|
}
|
2010-01-19 07:24:26 -07:00
|
|
|
|
2019-02-27 13:25:12 -07:00
|
|
|
const PieceToHistory* contHist[] = { (ss-1)->continuationHistory, (ss-2)->continuationHistory,
|
|
|
|
nullptr, (ss-4)->continuationHistory,
|
|
|
|
nullptr, (ss-6)->continuationHistory };
|
2018-07-19 10:26:05 -06:00
|
|
|
|
2008-08-31 23:59:13 -06:00
|
|
|
// Initialize a MovePicker object for the current position, and prepare
|
2010-01-19 07:24:26 -07:00
|
|
|
// to search the moves. Because the depth is <= 0 here, only captures,
|
2010-12-18 02:27:24 -07:00
|
|
|
// queen promotions and checks (only if depth >= DEPTH_QS_CHECKS) will
|
|
|
|
// be generated.
|
2018-07-19 10:26:05 -06:00
|
|
|
MovePicker mp(pos, ttMove, depth, &thisThread->mainHistory,
|
|
|
|
&thisThread->captureHistory,
|
|
|
|
contHist,
|
2018-04-28 22:48:18 -06:00
|
|
|
to_sq((ss-1)->currentMove));
|
2008-08-31 23:59:13 -06:00
|
|
|
|
2010-03-24 03:15:00 -06:00
|
|
|
// Loop through the moves until no moves remain or a beta cutoff occurs
|
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
|
|
|
while ((move = mp.next_move()) != MOVE_NONE)
|
2008-09-07 00:31:30 -06:00
|
|
|
{
|
2011-10-03 02:56:49 -06:00
|
|
|
assert(is_ok(move));
|
2008-09-07 00:31:30 -06:00
|
|
|
|
2018-02-26 17:18:33 -07:00
|
|
|
givesCheck = gives_check(pos, move);
|
2010-01-08 03:45:46 -07:00
|
|
|
|
2017-05-21 19:25:20 -06:00
|
|
|
moveCount++;
|
|
|
|
|
2008-08-31 23:59:13 -06:00
|
|
|
// Futility pruning
|
2018-03-13 16:19:36 -06:00
|
|
|
if ( !inCheck
|
2011-04-29 08:26:48 -06:00
|
|
|
&& !givesCheck
|
2013-08-24 02:05:48 -06:00
|
|
|
&& futilityBase > -VALUE_KNOWN_WIN
|
2013-12-03 14:58:39 -07:00
|
|
|
&& !pos.advanced_pawn_push(move))
|
2008-09-07 00:31:30 -06:00
|
|
|
{
|
2013-12-04 08:49:01 -07:00
|
|
|
assert(type_of(move) != ENPASSANT); // Due to !pos.advanced_pawn_push
|
|
|
|
|
|
|
|
futilityValue = futilityBase + PieceValue[EG][pos.piece_on(to_sq(move))];
|
2008-09-07 00:31:30 -06:00
|
|
|
|
2015-01-14 13:18:41 -07:00
|
|
|
if (futilityValue <= alpha)
|
2008-09-07 00:31:30 -06:00
|
|
|
{
|
2012-11-26 08:13:36 -07:00
|
|
|
bestValue = std::max(bestValue, futilityValue);
|
2008-09-07 00:31:30 -06:00
|
|
|
continue;
|
|
|
|
}
|
2011-02-22 15:23:45 -07:00
|
|
|
|
2016-10-06 11:55:10 -06:00
|
|
|
if (futilityBase <= alpha && !pos.see_ge(move, VALUE_ZERO + 1))
|
2012-11-26 08:13:36 -07:00
|
|
|
{
|
|
|
|
bestValue = std::max(bestValue, futilityBase);
|
2011-02-22 15:23:45 -07:00
|
|
|
continue;
|
2012-11-26 08:13:36 -07:00
|
|
|
}
|
2008-08-31 23:59:13 -06:00
|
|
|
}
|
|
|
|
|
2013-12-02 11:04:09 -07:00
|
|
|
// Detect non-capture evasions that are candidates to be pruned
|
2018-03-13 16:19:36 -06:00
|
|
|
evasionPrunable = inCheck
|
2017-05-21 19:25:20 -06:00
|
|
|
&& (depth != DEPTH_ZERO || moveCount > 2)
|
2012-04-28 04:08:10 -06:00
|
|
|
&& bestValue > VALUE_MATED_IN_MAX_PLY
|
2015-04-03 18:00:15 -06:00
|
|
|
&& !pos.capture(move);
|
2010-01-20 03:40:33 -07:00
|
|
|
|
|
|
|
// Don't search moves with negative SEE values
|
2018-03-13 16:19:36 -06:00
|
|
|
if ( (!inCheck || evasionPrunable)
|
2018-02-12 14:57:42 -07:00
|
|
|
&& !pos.see_ge(move))
|
2008-09-07 00:31:30 -06:00
|
|
|
continue;
|
2008-08-31 23:59:13 -06:00
|
|
|
|
2017-06-21 14:44:05 -06:00
|
|
|
// Speculative prefetch as early as possible
|
|
|
|
prefetch(TT.first_entry(pos.key_after(move)));
|
|
|
|
|
2013-12-02 11:04:09 -07:00
|
|
|
// Check for legality just before making the move
|
2016-07-03 02:35:44 -06:00
|
|
|
if (!pos.legal(move))
|
2017-05-21 19:25:20 -06:00
|
|
|
{
|
|
|
|
moveCount--;
|
2011-05-23 07:14:47 -06:00
|
|
|
continue;
|
2017-05-21 19:25:20 -06:00
|
|
|
}
|
2011-05-23 07:14:47 -06:00
|
|
|
|
2010-06-03 11:29:48 -06:00
|
|
|
ss->currentMove = move;
|
2018-07-28 07:33:39 -06:00
|
|
|
ss->continuationHistory = &thisThread->continuationHistory[pos.moved_piece(move)][to_sq(move)];
|
2010-06-03 11:29:48 -06:00
|
|
|
|
2009-11-05 03:11:02 -07:00
|
|
|
// Make and search the move
|
Compute checkers from scratch
This micro-optimization only complicates the code and provides no benefit.
Removing it is even a speedup on my machine (i7-3770k, linux, gcc 4.9.1):
stat test master diff
mean 2,403,118 2,390,904 12,214
stdev 12,043 10,620 3,677
speedup 0.51%
P(speedup>0) 100.0%
No functional change.
2015-02-15 00:49:20 -07:00
|
|
|
pos.do_move(move, st, givesCheck);
|
2018-03-13 01:10:59 -06:00
|
|
|
value = -qsearch<NT>(pos, ss+1, -beta, -alpha, depth - ONE_PLY);
|
2009-02-22 09:49:52 -07:00
|
|
|
pos.undo_move(move);
|
2008-08-31 23:59:13 -06:00
|
|
|
|
|
|
|
assert(value > -VALUE_INFINITE && value < VALUE_INFINITE);
|
|
|
|
|
2016-01-16 14:34:29 -07:00
|
|
|
// Check for a new best move
|
2008-09-07 00:31:30 -06:00
|
|
|
if (value > bestValue)
|
|
|
|
{
|
|
|
|
bestValue = value;
|
2011-08-07 03:29:47 -06:00
|
|
|
|
2012-10-07 01:34:04 -06:00
|
|
|
if (value > alpha)
|
|
|
|
{
|
2018-11-25 03:27:40 -07:00
|
|
|
bestMove = move;
|
|
|
|
|
2014-11-21 01:10:52 -07:00
|
|
|
if (PvNode) // Update pv even in fail-high case
|
2014-11-18 03:57:57 -07:00
|
|
|
update_pv(ss->pv, move, (ss+1)->pv);
|
2014-11-12 14:13:55 -07:00
|
|
|
|
2015-10-23 23:27:24 -06:00
|
|
|
if (PvNode && value < beta) // Update alpha here!
|
2012-10-07 01:34:04 -06:00
|
|
|
alpha = value;
|
2018-11-25 03:27:40 -07:00
|
|
|
else
|
|
|
|
break; // Fail high
|
2012-10-07 01:34:04 -06:00
|
|
|
}
|
2008-09-07 00:31:30 -06:00
|
|
|
}
|
2008-08-31 23:59:13 -06:00
|
|
|
}
|
|
|
|
|
2010-01-08 03:45:46 -07:00
|
|
|
// All legal moves have been searched. A special case: If we're in check
|
2009-06-11 07:57:42 -06:00
|
|
|
// and no legal moves were found, it is checkmate.
|
2018-03-13 16:19:36 -06:00
|
|
|
if (inCheck && bestValue == -VALUE_INFINITE)
|
2011-12-28 05:22:09 -07:00
|
|
|
return mated_in(ss->ply); // Plies to mate from the root
|
2008-08-31 23:59:13 -06:00
|
|
|
|
2019-01-09 07:05:28 -07:00
|
|
|
tte->save(posKey, value_to_tt(bestValue, ss->ply), pvHit,
|
2018-11-25 03:27:40 -07:00
|
|
|
bestValue >= beta ? BOUND_LOWER :
|
|
|
|
PvNode && bestValue > oldAlpha ? BOUND_EXACT : BOUND_UPPER,
|
2018-07-03 16:58:16 -06:00
|
|
|
ttDepth, bestMove, ss->staticEval);
|
2009-09-18 02:32:57 -06:00
|
|
|
|
2010-01-08 03:45:46 -07:00
|
|
|
assert(bestValue > -VALUE_INFINITE && bestValue < VALUE_INFINITE);
|
2009-04-18 07:03:33 -06:00
|
|
|
|
2008-08-31 23:59:13 -06:00
|
|
|
return bestValue;
|
|
|
|
}
|
|
|
|
|
2010-12-14 06:49:06 -07:00
|
|
|
|
2012-10-27 06:25:31 -06:00
|
|
|
// value_to_tt() adjusts a mate score from "plies to mate from the root" to
|
|
|
|
// "plies to mate from the current position". Non-mate scores are unchanged.
|
2013-12-02 11:04:09 -07:00
|
|
|
// The function is called before storing a value in the transposition table.
|
2012-10-27 06:25:31 -06:00
|
|
|
|
|
|
|
Value value_to_tt(Value v, int ply) {
|
|
|
|
|
|
|
|
assert(v != VALUE_NONE);
|
|
|
|
|
|
|
|
return v >= VALUE_MATE_IN_MAX_PLY ? v + ply
|
|
|
|
: v <= VALUE_MATED_IN_MAX_PLY ? v - ply : v;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
// value_from_tt() is the inverse of value_to_tt(): It adjusts a mate score
|
2013-12-02 11:04:09 -07:00
|
|
|
// from the transposition table (which refers to the plies to mate/be mated
|
2012-10-27 06:25:31 -06:00
|
|
|
// from current position) to "plies to mate/be mated from the root".
|
|
|
|
|
|
|
|
Value value_from_tt(Value v, int ply) {
|
|
|
|
|
|
|
|
return v == VALUE_NONE ? VALUE_NONE
|
|
|
|
: v >= VALUE_MATE_IN_MAX_PLY ? v - ply
|
|
|
|
: v <= VALUE_MATED_IN_MAX_PLY ? v + ply : v;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2014-11-21 01:10:52 -07:00
|
|
|
// update_pv() adds current move and appends child pv[]
|
2014-11-18 03:57:57 -07:00
|
|
|
|
2014-11-21 01:10:52 -07:00
|
|
|
void update_pv(Move* pv, Move move, Move* childPv) {
|
2014-11-18 03:57:57 -07:00
|
|
|
|
2014-11-21 01:10:52 -07:00
|
|
|
for (*pv++ = move; childPv && *childPv != MOVE_NONE; )
|
|
|
|
*pv++ = *childPv++;
|
2014-11-18 03:57:57 -07:00
|
|
|
*pv = MOVE_NONE;
|
|
|
|
}
|
|
|
|
|
2014-01-05 06:08:26 -07:00
|
|
|
|
2017-06-30 09:20:00 -06:00
|
|
|
// update_continuation_histories() updates histories of the move pairs formed
|
|
|
|
// by moves at ply -1, -2, and -4 with current move.
|
2014-01-05 06:08:26 -07:00
|
|
|
|
2017-06-30 09:20:00 -06:00
|
|
|
void update_continuation_histories(Stack* ss, Piece pc, Square to, int bonus) {
|
2016-08-23 07:57:56 -06:00
|
|
|
|
2019-02-27 13:25:12 -07:00
|
|
|
for (int i : {1, 2, 4, 6})
|
2017-03-14 22:00:03 -06:00
|
|
|
if (is_ok((ss-i)->currentMove))
|
2018-07-19 10:26:05 -06:00
|
|
|
(*(ss-i)->continuationHistory)[pc][to] << bonus;
|
2016-08-24 08:52:05 -06:00
|
|
|
}
|
2016-08-23 07:57:56 -06:00
|
|
|
|
2016-08-24 08:52:05 -06:00
|
|
|
|
2017-11-03 05:37:11 -06:00
|
|
|
// update_capture_stats() updates move sorting heuristics when a new capture best move is found
|
|
|
|
|
|
|
|
void update_capture_stats(const Position& pos, Move move,
|
2019-01-01 06:10:26 -07:00
|
|
|
Move* captures, int captureCount, int bonus) {
|
2017-11-03 05:37:11 -06:00
|
|
|
|
|
|
|
CapturePieceToHistory& captureHistory = pos.this_thread()->captureHistory;
|
|
|
|
Piece moved_piece = pos.moved_piece(move);
|
|
|
|
PieceType captured = type_of(pos.piece_on(to_sq(move)));
|
2018-07-03 17:11:54 -06:00
|
|
|
|
|
|
|
if (pos.capture_or_promotion(move))
|
|
|
|
captureHistory[moved_piece][to_sq(move)][captured] << bonus;
|
2017-11-03 05:37:11 -06:00
|
|
|
|
|
|
|
// Decrease all the other played capture moves
|
2019-01-01 06:10:26 -07:00
|
|
|
for (int i = 0; i < captureCount; ++i)
|
2017-11-03 05:37:11 -06:00
|
|
|
{
|
|
|
|
moved_piece = pos.moved_piece(captures[i]);
|
|
|
|
captured = type_of(pos.piece_on(to_sq(captures[i])));
|
2018-03-03 03:29:29 -07:00
|
|
|
captureHistory[moved_piece][to_sq(captures[i])][captured] << -bonus;
|
2017-11-03 05:37:11 -06:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2018-02-12 14:57:42 -07:00
|
|
|
// update_quiet_stats() updates move sorting heuristics when a new quiet best move is found
|
2016-08-24 08:52:05 -06:00
|
|
|
|
2018-02-12 14:57:42 -07:00
|
|
|
void update_quiet_stats(const Position& pos, Stack* ss, Move move,
|
2019-01-01 06:10:26 -07:00
|
|
|
Move* quiets, int quietCount, int bonus) {
|
2016-08-23 07:57:56 -06:00
|
|
|
|
2014-01-05 06:08:26 -07:00
|
|
|
if (ss->killers[0] != move)
|
|
|
|
{
|
|
|
|
ss->killers[1] = ss->killers[0];
|
|
|
|
ss->killers[0] = move;
|
|
|
|
}
|
2016-08-12 11:55:12 -06:00
|
|
|
|
2018-02-12 14:57:42 -07:00
|
|
|
Color us = pos.side_to_move();
|
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
|
|
|
Thread* thisThread = pos.this_thread();
|
2018-03-03 03:29:29 -07:00
|
|
|
thisThread->mainHistory[us][from_to(move)] << bonus;
|
2017-06-30 09:20:00 -06:00
|
|
|
update_continuation_histories(ss, pos.moved_piece(move), to_sq(move), bonus);
|
2015-01-31 02:43:47 -07:00
|
|
|
|
2017-03-08 19:35:23 -07:00
|
|
|
if (is_ok((ss-1)->currentMove))
|
2014-01-05 06:08:26 -07:00
|
|
|
{
|
2016-08-24 08:52:05 -06:00
|
|
|
Square prevSq = to_sq((ss-1)->currentMove);
|
2017-06-30 09:20:00 -06:00
|
|
|
thisThread->counterMoves[pos.piece_on(prevSq)][prevSq] = move;
|
2014-01-05 06:08:26 -07:00
|
|
|
}
|
|
|
|
|
2015-03-15 03:05:57 -06:00
|
|
|
// Decrease all the other played quiet moves
|
2019-01-01 06:10:26 -07:00
|
|
|
for (int i = 0; i < quietCount; ++i)
|
2014-01-05 06:08:26 -07:00
|
|
|
{
|
2018-03-03 03:29:29 -07:00
|
|
|
thisThread->mainHistory[us][from_to(quiets[i])] << -bonus;
|
2017-06-30 09:20:00 -06:00
|
|
|
update_continuation_histories(ss, pos.moved_piece(quiets[i]), to_sq(quiets[i]), -bonus);
|
2014-01-05 06:08:26 -07:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2015-01-25 03:07:43 -07:00
|
|
|
// When playing with strength handicap, choose best move among a set of RootMoves
|
|
|
|
// using a statistical rule dependent on 'level'. Idea by Heinz van Saanen.
|
2010-07-15 03:00:20 -06:00
|
|
|
|
2015-01-25 03:07:43 -07:00
|
|
|
Move Skill::pick_best(size_t multiPV) {
|
2010-07-15 03:00:20 -06:00
|
|
|
|
2016-04-11 08:45:36 -06:00
|
|
|
const RootMoves& rootMoves = Threads.main()->rootMoves;
|
2015-10-25 01:30:07 -06:00
|
|
|
static PRNG rng(now()); // PRNG sequence should be non-deterministic
|
2010-07-15 03:00:20 -06:00
|
|
|
|
2012-07-15 01:14:25 -06:00
|
|
|
// RootMoves are already sorted by score in descending order
|
2015-10-25 01:30:07 -06:00
|
|
|
Value topScore = rootMoves[0].score;
|
|
|
|
int delta = std::min(topScore - rootMoves[multiPV - 1].score, PawnValueMg);
|
2012-10-24 04:05:20 -06:00
|
|
|
int weakness = 120 - 2 * level;
|
2014-12-07 16:53:33 -07:00
|
|
|
int maxScore = -VALUE_INFINITE;
|
2012-07-15 01:14:25 -06:00
|
|
|
|
2015-10-25 01:30:07 -06:00
|
|
|
// Choose best move. For each move score we add two terms, both dependent on
|
2016-01-16 01:03:56 -07:00
|
|
|
// weakness. One is deterministic and bigger for weaker levels, and one is
|
2016-01-16 14:34:29 -07:00
|
|
|
// random. Then we choose the move with the resulting highest score.
|
2015-01-25 03:07:43 -07:00
|
|
|
for (size_t i = 0; i < multiPV; ++i)
|
2012-07-15 01:14:25 -06:00
|
|
|
{
|
|
|
|
// This is our magic formula
|
2015-10-25 01:30:07 -06:00
|
|
|
int push = ( weakness * int(topScore - rootMoves[i].score)
|
|
|
|
+ delta * (rng.rand<unsigned>() % weakness)) / 128;
|
2012-07-15 01:14:25 -06:00
|
|
|
|
2017-10-10 23:49:58 -06:00
|
|
|
if (rootMoves[i].score + push >= maxScore)
|
2012-07-15 01:14:25 -06:00
|
|
|
{
|
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
|
|
|
maxScore = rootMoves[i].score + push;
|
|
|
|
best = rootMoves[i].pv[0];
|
2012-07-15 01:14:25 -06:00
|
|
|
}
|
|
|
|
}
|
2015-10-25 01:30:07 -06:00
|
|
|
|
2012-07-15 01:14:25 -06:00
|
|
|
return best;
|
2010-07-15 03:00:20 -06:00
|
|
|
}
|
|
|
|
|
2017-06-23 23:15:46 -06:00
|
|
|
} // namespace
|
Get rid of timer thread
Unfortunately std::condition_variable::wait_for()
is not accurate in general case and the timer thread
can wake up also after tens or even hundreds of
millisecs after time has elapsded. CPU load, process
priorities, number of concurrent threads, even from
other processes, will have effect upon it.
Even official documentation says: "This function may
block for longer than timeout_duration due to scheduling
or resource contention delays."
So retire timer and use a polling scheme based on a
local thread counter that counts search() calls and
a small trick to keep polling frequency constant,
independently from the number of threads.
Tested for no regression at very fast TC 2+0.05 th 7:
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 32969 W: 6720 L: 6620 D: 19629
TC 2+0.05 th 1:
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 7765 W: 1917 L: 1765 D: 4083
And at STC TC, both single thread
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 15587 W: 3036 L: 2905 D: 9646
And with 7 threads
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 8149 W: 1367 L: 1227 D: 5555
bench: 8639247
2015-11-03 03:15:14 -07:00
|
|
|
|
2018-02-12 14:57:42 -07:00
|
|
|
/// MainThread::check_time() is used to print debug info and, more importantly,
|
|
|
|
/// to detect when we are out of available time and thus stop the search.
|
Get rid of timer thread
Unfortunately std::condition_variable::wait_for()
is not accurate in general case and the timer thread
can wake up also after tens or even hundreds of
millisecs after time has elapsded. CPU load, process
priorities, number of concurrent threads, even from
other processes, will have effect upon it.
Even official documentation says: "This function may
block for longer than timeout_duration due to scheduling
or resource contention delays."
So retire timer and use a polling scheme based on a
local thread counter that counts search() calls and
a small trick to keep polling frequency constant,
independently from the number of threads.
Tested for no regression at very fast TC 2+0.05 th 7:
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 32969 W: 6720 L: 6620 D: 19629
TC 2+0.05 th 1:
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 7765 W: 1917 L: 1765 D: 4083
And at STC TC, both single thread
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 15587 W: 3036 L: 2905 D: 9646
And with 7 threads
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 8149 W: 1367 L: 1227 D: 5555
bench: 8639247
2015-11-03 03:15:14 -07:00
|
|
|
|
2018-02-12 14:57:42 -07:00
|
|
|
void MainThread::check_time() {
|
2017-06-23 23:15:46 -06:00
|
|
|
|
2018-02-12 14:57:42 -07:00
|
|
|
if (--callsCnt > 0)
|
|
|
|
return;
|
2017-06-23 23:15:46 -06:00
|
|
|
|
2018-02-12 14:57:42 -07:00
|
|
|
// When using nodes, ensure checking rate is not lower than 0.1% of nodes
|
2018-03-14 14:35:57 -06:00
|
|
|
callsCnt = Limits.nodes ? std::min(1024, int(Limits.nodes / 1024)) : 1024;
|
Get rid of timer thread
Unfortunately std::condition_variable::wait_for()
is not accurate in general case and the timer thread
can wake up also after tens or even hundreds of
millisecs after time has elapsded. CPU load, process
priorities, number of concurrent threads, even from
other processes, will have effect upon it.
Even official documentation says: "This function may
block for longer than timeout_duration due to scheduling
or resource contention delays."
So retire timer and use a polling scheme based on a
local thread counter that counts search() calls and
a small trick to keep polling frequency constant,
independently from the number of threads.
Tested for no regression at very fast TC 2+0.05 th 7:
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 32969 W: 6720 L: 6620 D: 19629
TC 2+0.05 th 1:
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 7765 W: 1917 L: 1765 D: 4083
And at STC TC, both single thread
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 15587 W: 3036 L: 2905 D: 9646
And with 7 threads
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 8149 W: 1367 L: 1227 D: 5555
bench: 8639247
2015-11-03 03:15:14 -07:00
|
|
|
|
2018-02-12 14:57:42 -07:00
|
|
|
static TimePoint lastInfoTime = now();
|
Get rid of timer thread
Unfortunately std::condition_variable::wait_for()
is not accurate in general case and the timer thread
can wake up also after tens or even hundreds of
millisecs after time has elapsded. CPU load, process
priorities, number of concurrent threads, even from
other processes, will have effect upon it.
Even official documentation says: "This function may
block for longer than timeout_duration due to scheduling
or resource contention delays."
So retire timer and use a polling scheme based on a
local thread counter that counts search() calls and
a small trick to keep polling frequency constant,
independently from the number of threads.
Tested for no regression at very fast TC 2+0.05 th 7:
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 32969 W: 6720 L: 6620 D: 19629
TC 2+0.05 th 1:
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 7765 W: 1917 L: 1765 D: 4083
And at STC TC, both single thread
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 15587 W: 3036 L: 2905 D: 9646
And with 7 threads
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 8149 W: 1367 L: 1227 D: 5555
bench: 8639247
2015-11-03 03:15:14 -07:00
|
|
|
|
2018-03-27 08:22:53 -06:00
|
|
|
TimePoint elapsed = Time.elapsed();
|
2018-02-12 14:57:42 -07:00
|
|
|
TimePoint tick = Limits.startTime + elapsed;
|
Get rid of timer thread
Unfortunately std::condition_variable::wait_for()
is not accurate in general case and the timer thread
can wake up also after tens or even hundreds of
millisecs after time has elapsded. CPU load, process
priorities, number of concurrent threads, even from
other processes, will have effect upon it.
Even official documentation says: "This function may
block for longer than timeout_duration due to scheduling
or resource contention delays."
So retire timer and use a polling scheme based on a
local thread counter that counts search() calls and
a small trick to keep polling frequency constant,
independently from the number of threads.
Tested for no regression at very fast TC 2+0.05 th 7:
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 32969 W: 6720 L: 6620 D: 19629
TC 2+0.05 th 1:
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 7765 W: 1917 L: 1765 D: 4083
And at STC TC, both single thread
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 15587 W: 3036 L: 2905 D: 9646
And with 7 threads
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 8149 W: 1367 L: 1227 D: 5555
bench: 8639247
2015-11-03 03:15:14 -07:00
|
|
|
|
2018-02-12 14:57:42 -07:00
|
|
|
if (tick - lastInfoTime >= 1000)
|
|
|
|
{
|
|
|
|
lastInfoTime = tick;
|
|
|
|
dbg_print();
|
|
|
|
}
|
Get rid of timer thread
Unfortunately std::condition_variable::wait_for()
is not accurate in general case and the timer thread
can wake up also after tens or even hundreds of
millisecs after time has elapsded. CPU load, process
priorities, number of concurrent threads, even from
other processes, will have effect upon it.
Even official documentation says: "This function may
block for longer than timeout_duration due to scheduling
or resource contention delays."
So retire timer and use a polling scheme based on a
local thread counter that counts search() calls and
a small trick to keep polling frequency constant,
independently from the number of threads.
Tested for no regression at very fast TC 2+0.05 th 7:
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 32969 W: 6720 L: 6620 D: 19629
TC 2+0.05 th 1:
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 7765 W: 1917 L: 1765 D: 4083
And at STC TC, both single thread
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 15587 W: 3036 L: 2905 D: 9646
And with 7 threads
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 8149 W: 1367 L: 1227 D: 5555
bench: 8639247
2015-11-03 03:15:14 -07:00
|
|
|
|
2018-02-12 14:57:42 -07:00
|
|
|
// We should not stop pondering until told so by the GUI
|
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
|
|
|
if (ponder)
|
2018-02-12 14:57:42 -07:00
|
|
|
return;
|
Get rid of timer thread
Unfortunately std::condition_variable::wait_for()
is not accurate in general case and the timer thread
can wake up also after tens or even hundreds of
millisecs after time has elapsded. CPU load, process
priorities, number of concurrent threads, even from
other processes, will have effect upon it.
Even official documentation says: "This function may
block for longer than timeout_duration due to scheduling
or resource contention delays."
So retire timer and use a polling scheme based on a
local thread counter that counts search() calls and
a small trick to keep polling frequency constant,
independently from the number of threads.
Tested for no regression at very fast TC 2+0.05 th 7:
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 32969 W: 6720 L: 6620 D: 19629
TC 2+0.05 th 1:
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 7765 W: 1917 L: 1765 D: 4083
And at STC TC, both single thread
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 15587 W: 3036 L: 2905 D: 9646
And with 7 threads
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 8149 W: 1367 L: 1227 D: 5555
bench: 8639247
2015-11-03 03:15:14 -07:00
|
|
|
|
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
|
|
|
if ( (Limits.use_time_management() && (elapsed > Time.maximum() - 10 || stopOnPonderhit))
|
2018-02-12 14:57:42 -07:00
|
|
|
|| (Limits.movetime && elapsed >= Limits.movetime)
|
|
|
|
|| (Limits.nodes && Threads.nodes_searched() >= (uint64_t)Limits.nodes))
|
|
|
|
Threads.stop = true;
|
|
|
|
}
|
Get rid of timer thread
Unfortunately std::condition_variable::wait_for()
is not accurate in general case and the timer thread
can wake up also after tens or even hundreds of
millisecs after time has elapsded. CPU load, process
priorities, number of concurrent threads, even from
other processes, will have effect upon it.
Even official documentation says: "This function may
block for longer than timeout_duration due to scheduling
or resource contention delays."
So retire timer and use a polling scheme based on a
local thread counter that counts search() calls and
a small trick to keep polling frequency constant,
independently from the number of threads.
Tested for no regression at very fast TC 2+0.05 th 7:
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 32969 W: 6720 L: 6620 D: 19629
TC 2+0.05 th 1:
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 7765 W: 1917 L: 1765 D: 4083
And at STC TC, both single thread
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 15587 W: 3036 L: 2905 D: 9646
And with 7 threads
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 8149 W: 1367 L: 1227 D: 5555
bench: 8639247
2015-11-03 03:15:14 -07:00
|
|
|
|
2011-01-01 06:13:15 -07:00
|
|
|
|
2015-01-31 03:54:25 -07:00
|
|
|
/// UCI::pv() formats PV information according to the UCI protocol. UCI requires
|
|
|
|
/// that all (if any) unsearched PV lines are sent using a previous search score.
|
2011-01-01 06:13:15 -07:00
|
|
|
|
2015-01-31 03:54:25 -07:00
|
|
|
string UCI::pv(const Position& pos, Depth depth, Value alpha, Value beta) {
|
2011-06-22 00:03:28 -06:00
|
|
|
|
2015-01-31 03:54:25 -07:00
|
|
|
std::stringstream ss;
|
2018-03-27 08:22:53 -06:00
|
|
|
TimePoint elapsed = Time.elapsed() + 1;
|
2016-04-11 08:45:36 -06:00
|
|
|
const RootMoves& rootMoves = pos.this_thread()->rootMoves;
|
2018-06-02 09:41:37 -06:00
|
|
|
size_t pvIdx = pos.this_thread()->pvIdx;
|
2018-02-04 13:42:56 -07:00
|
|
|
size_t multiPV = std::min((size_t)Options["MultiPV"], rootMoves.size());
|
2016-10-20 13:16:09 -06:00
|
|
|
uint64_t nodesSearched = Threads.nodes_searched();
|
|
|
|
uint64_t tbHits = Threads.tb_hits() + (TB::RootInTB ? rootMoves.size() : 0);
|
2011-06-22 00:03:28 -06:00
|
|
|
|
2015-01-31 03:54:25 -07:00
|
|
|
for (size_t i = 0; i < multiPV; ++i)
|
|
|
|
{
|
2018-06-02 09:41:37 -06:00
|
|
|
bool updated = (i <= pvIdx && rootMoves[i].score != -VALUE_INFINITE);
|
2011-12-14 01:21:00 -07:00
|
|
|
|
2015-01-31 03:54:25 -07:00
|
|
|
if (depth == ONE_PLY && !updated)
|
|
|
|
continue;
|
2011-12-14 01:21:00 -07:00
|
|
|
|
2015-01-31 03:54:25 -07:00
|
|
|
Depth d = updated ? depth : depth - ONE_PLY;
|
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
|
|
|
Value v = updated ? rootMoves[i].score : rootMoves[i].previousScore;
|
2015-01-18 00:05:05 -07:00
|
|
|
|
2015-01-31 03:54:25 -07:00
|
|
|
bool tb = TB::RootInTB && abs(v) < VALUE_MATE - MAX_PLY;
|
2018-06-02 09:41:37 -06:00
|
|
|
v = tb ? rootMoves[i].tbScore : v;
|
2012-07-14 06:19:16 -06:00
|
|
|
|
2015-01-31 03:54:25 -07:00
|
|
|
if (ss.rdbuf()->in_avail()) // Not at first line
|
|
|
|
ss << "\n";
|
2015-01-03 02:51:38 -07:00
|
|
|
|
2015-01-31 03:54:25 -07:00
|
|
|
ss << "info"
|
|
|
|
<< " depth " << d / ONE_PLY
|
2017-07-13 17:30:03 -06:00
|
|
|
<< " seldepth " << rootMoves[i].selDepth
|
2015-01-31 03:54:25 -07:00
|
|
|
<< " multipv " << i + 1
|
|
|
|
<< " score " << UCI::value(v);
|
2015-01-03 02:51:38 -07:00
|
|
|
|
2018-06-02 09:41:37 -06:00
|
|
|
if (!tb && i == pvIdx)
|
2015-01-31 03:54:25 -07:00
|
|
|
ss << (v >= beta ? " lowerbound" : v <= alpha ? " upperbound" : "");
|
2011-12-14 01:21:00 -07:00
|
|
|
|
2016-10-20 13:16:09 -06:00
|
|
|
ss << " nodes " << nodesSearched
|
|
|
|
<< " nps " << nodesSearched * 1000 / elapsed;
|
2015-01-25 00:57:51 -07:00
|
|
|
|
2015-01-31 05:04:15 -07:00
|
|
|
if (elapsed > 1000) // Earlier makes little sense
|
2015-01-31 05:22:06 -07:00
|
|
|
ss << " hashfull " << TT.hashfull();
|
2011-12-14 01:21:00 -07:00
|
|
|
|
2016-10-20 13:16:09 -06:00
|
|
|
ss << " tbhits " << tbHits
|
2015-01-31 03:54:25 -07:00
|
|
|
<< " time " << elapsed
|
|
|
|
<< " pv";
|
2012-07-14 06:19:16 -06:00
|
|
|
|
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
|
|
|
for (Move m : rootMoves[i].pv)
|
2015-01-31 03:54:25 -07:00
|
|
|
ss << " " << UCI::move(m, pos.is_chess960());
|
2011-06-22 00:03:28 -06:00
|
|
|
}
|
|
|
|
|
2015-01-31 03:54:25 -07:00
|
|
|
return ss.str();
|
|
|
|
}
|
2008-08-31 23:59:13 -06:00
|
|
|
|
2010-12-29 03:00:32 -07:00
|
|
|
|
2015-10-25 01:30:07 -06:00
|
|
|
/// RootMove::extract_ponder_from_tt() is called in case we have no ponder move
|
2016-01-16 14:34:29 -07:00
|
|
|
/// before exiting the search, for instance, in case we stop the search during a
|
2015-10-25 01:30:07 -06:00
|
|
|
/// fail high at root. We try hard to have a ponder move to return to the GUI,
|
|
|
|
/// otherwise in case of 'ponder on' we have nothing to think on.
|
2015-01-20 01:13:30 -07:00
|
|
|
|
2016-09-23 11:28:34 -06:00
|
|
|
bool RootMove::extract_ponder_from_tt(Position& pos) {
|
|
|
|
|
2015-01-20 01:13:30 -07:00
|
|
|
StateInfo st;
|
2015-01-31 04:31:00 -07:00
|
|
|
bool ttHit;
|
2015-01-20 01:13:30 -07:00
|
|
|
|
|
|
|
assert(pv.size() == 1);
|
|
|
|
|
2019-01-01 06:10:26 -07:00
|
|
|
if (pv[0] == MOVE_NONE)
|
2016-09-23 23:30:37 -06:00
|
|
|
return false;
|
|
|
|
|
2016-11-11 06:02:28 -07:00
|
|
|
pos.do_move(pv[0], st);
|
2015-01-31 04:31:00 -07:00
|
|
|
TTEntry* tte = TT.probe(pos.key(), ttHit);
|
|
|
|
|
|
|
|
if (ttHit)
|
|
|
|
{
|
|
|
|
Move m = tte->move(); // Local copy to be SMP safe
|
|
|
|
if (MoveList<LEGAL>(pos).contains(m))
|
2016-07-09 13:01:42 -06:00
|
|
|
pv.push_back(m);
|
2015-01-31 04:31:00 -07:00
|
|
|
}
|
|
|
|
|
2016-07-09 13:01:42 -06:00
|
|
|
pos.undo_move(pv[0]);
|
|
|
|
return pv.size() > 1;
|
2015-01-20 01:13:30 -07:00
|
|
|
}
|
2016-06-03 23:53:29 -06:00
|
|
|
|
2018-04-18 10:38:38 -06:00
|
|
|
void Tablebases::rank_root_moves(Position& pos, Search::RootMoves& rootMoves) {
|
2016-06-03 23:53:29 -06:00
|
|
|
|
|
|
|
RootInTB = false;
|
2018-04-18 20:16:19 -06:00
|
|
|
UseRule50 = bool(Options["Syzygy50MoveRule"]);
|
|
|
|
ProbeDepth = int(Options["SyzygyProbeDepth"]) * ONE_PLY;
|
|
|
|
Cardinality = int(Options["SyzygyProbeLimit"]);
|
2018-04-18 10:38:38 -06:00
|
|
|
bool dtz_available = true;
|
2016-06-03 23:53:29 -06:00
|
|
|
|
2018-04-18 10:38:38 -06:00
|
|
|
// Tables with fewer pieces than SyzygyProbeLimit are searched with
|
|
|
|
// ProbeDepth == DEPTH_ZERO
|
2016-06-03 23:53:29 -06:00
|
|
|
if (Cardinality > MaxCardinality)
|
|
|
|
{
|
|
|
|
Cardinality = MaxCardinality;
|
|
|
|
ProbeDepth = DEPTH_ZERO;
|
|
|
|
}
|
|
|
|
|
2018-04-18 10:38:38 -06:00
|
|
|
if (Cardinality >= popcount(pos.pieces()) && !pos.can_castle(ANY_CASTLING))
|
|
|
|
{
|
|
|
|
// Rank moves using DTZ tables
|
|
|
|
RootInTB = root_probe(pos, rootMoves);
|
2017-11-07 01:26:13 -07:00
|
|
|
|
2018-04-18 10:38:38 -06:00
|
|
|
if (!RootInTB)
|
|
|
|
{
|
|
|
|
// DTZ tables are missing; try to rank moves using WDL tables
|
|
|
|
dtz_available = false;
|
|
|
|
RootInTB = root_probe_wdl(pos, rootMoves);
|
|
|
|
}
|
|
|
|
}
|
2016-06-03 23:53:29 -06:00
|
|
|
|
|
|
|
if (RootInTB)
|
|
|
|
{
|
2018-04-18 10:38:38 -06:00
|
|
|
// Sort moves according to TB rank
|
|
|
|
std::sort(rootMoves.begin(), rootMoves.end(),
|
2018-06-02 09:41:37 -06:00
|
|
|
[](const RootMove &a, const RootMove &b) { return a.tbRank > b.tbRank; } );
|
2016-06-03 23:53:29 -06:00
|
|
|
|
2018-04-18 10:38:38 -06:00
|
|
|
// Probe during search only if DTZ is not available and we are winning
|
2018-06-02 09:41:37 -06:00
|
|
|
if (dtz_available || rootMoves[0].tbScore <= VALUE_DRAW)
|
2016-06-03 23:53:29 -06:00
|
|
|
Cardinality = 0;
|
|
|
|
}
|
2018-04-18 10:38:38 -06:00
|
|
|
else
|
|
|
|
{
|
|
|
|
// Assign the same rank to all moves
|
|
|
|
for (auto& m : rootMoves)
|
2018-06-02 09:41:37 -06:00
|
|
|
m.tbRank = 0;
|
2018-04-18 10:38:38 -06:00
|
|
|
}
|
2016-06-03 23:53:29 -06:00
|
|
|
}
|