2008-08-31 23:59:13 -06:00
|
|
|
/*
|
2008-10-19 10:56:28 -06:00
|
|
|
Stockfish, a UCI chess playing engine derived from Glaurung 2.1
|
2021-01-08 09:04:23 -07:00
|
|
|
Copyright (C) 2004-2021 The Stockfish developers (see AUTHORS file)
|
2008-08-31 23:59:13 -06:00
|
|
|
|
2008-10-19 10:56:28 -06:00
|
|
|
Stockfish is free software: you can redistribute it and/or modify
|
2008-08-31 23:59:13 -06:00
|
|
|
it under the terms of the GNU General Public License as published by
|
|
|
|
the Free Software Foundation, either version 3 of the License, or
|
|
|
|
(at your option) any later version.
|
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/>.
|
|
|
|
*/
|
|
|
|
|
2019-03-31 04:02:19 -06: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
|
|
|
|
2021-02-26 02:02:13 -07:00
|
|
|
namespace Stockfish {
|
|
|
|
|
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
|
Introducing NodeType Root
We transform rootNode into constexpr by adding a new NodeType `Root`,
which causes a speed up.
Local test:
```
Build Tester: 1.4.7.0
Windows 10 (Version 10.0, Build 0, 64-bit Edition)
Intel(R) Core(TM) i7-8750H CPU @ 2.20GHz
SafeMode: No
Running In VM: No
HyperThreading Enabled: Yes
CPU Warmup: Yes
Command Line: bench
Tests per Build: 25
ANOVA: n/a
Engine# (NPS) Speedup Sp Conf. 95% S.S.
patch (920.179,4) ---> master (906.329,2) ---> 1,528% 20.336,5 Yes No
```
---------
STC:
LLR: 2.94 (-2.94,2.94) <-0.50,2.50>
Total: 98216 W: 8348 L: 8102 D: 81766
Ptnml(0-2): 295, 6357, 35549, 6621, 286
https://tests.stockfishchess.org/tests/view/60b797e2457376eb8bcaa0ab
Yellow LTC:
LLR: -2.95 (-2.94,2.94) <0.50,3.50>
Total: 76936 W: 2651 L: 2626 D: 71659
Ptnml(0-2): 29, 2233, 33916, 2264, 26
https://tests.stockfishchess.org/tests/view/60b80d6d457376eb8bcaa145
closes https://github.com/official-stockfish/Stockfish/pull/3522
No functional change
2021-06-03 10:52:39 -06:00
|
|
|
enum NodeType { NonPV, PV, Root };
|
2010-11-08 01:44:28 -07:00
|
|
|
|
Remove razoring
has become ineffective now.
STC https://tests.stockfishchess.org/tests/view/5fe653403932f79192d3981a
LLR: 2.95 (-2.94,2.94) {-1.25,0.25}
Total: 63448 W: 5965 L: 5934 D: 51549
Ptnml(0-2): 230, 4738, 21769, 4745, 242
LTC https://tests.stockfishchess.org/tests/view/5fe6f0f03932f79192d39856
LLR: 2.93 (-2.94,2.94) {-0.75,0.25}
Total: 65368 W: 2485 L: 2459 D: 60424
Ptnml(0-2): 33, 2186, 28230, 2192, 43
closes https://github.com/official-stockfish/Stockfish/pull/3278
bench: 4493379
2020-12-26 05:48:04 -07:00
|
|
|
// Futility margin
|
2018-03-07 14:31:51 -07:00
|
|
|
Value futility_margin(Depth d, bool improving) {
|
Tuning Search
This patch tunes constant in search.cpp
STC:
LLR: 2.94 (-2.94,2.94) <-0.50,2.50>
Total: 30648 W: 2580 L: 2410 D: 25658
Ptnml(0-2): 80, 1969, 11093, 2065, 117
https://tests.stockfishchess.org/tests/view/60a71d3cce8ea25a3ef03fae
LTC:
LLR: 2.95 (-2.94,2.94) <0.50,3.50>
Total: 52896 W: 1776 L: 1617 D: 49503
Ptnml(0-2): 13, 1462, 23347, 1605, 21
https://tests.stockfishchess.org/tests/view/60a794ddce8ea25a3ef0400a
closes https://github.com/official-stockfish/Stockfish/pull/3491
Bench: 4004731
2021-05-21 23:47:23 -06:00
|
|
|
return Value(214 * (d - improving));
|
2018-03-07 14:31:51 -07:00
|
|
|
}
|
2008-08-31 23:59:13 -06:00
|
|
|
|
2019-03-05 12:48:29 -07:00
|
|
|
// Reductions lookup table, initialized at startup
|
2019-04-19 09:33:26 -06:00
|
|
|
int Reductions[MAX_MOVES]; // [depth or moveNumber]
|
2010-02-25 09:27:27 -07:00
|
|
|
|
Range reductions
adding reductions for when the delta between the static eval and the child's eval is consistently low.
passed STC
https://tests.stockfishchess.org/html/live_elo.html?614d7b3c7bdc23e77ceb8a5d
LLR: 2.95 (-2.94,2.94) <-0.50,2.50>
Total: 88872 W: 22672 L: 22366 D: 43834
Ptnml(0-2): 343, 10150, 23117, 10510, 316
passed LTC
https://tests.stockfishchess.org/html/live_elo.html?614daf3e7bdc23e77ceb8a82
LLR: 2.93 (-2.94,2.94) <0.50,3.50>
Total: 24368 W: 6153 L: 5928 D: 12287
Ptnml(0-2): 13, 2503, 6937, 2708, 23
closes https://github.com/official-stockfish/Stockfish/pull/3717
Bench: 5443950
2021-09-23 14:16:17 -06:00
|
|
|
Depth reduction(bool i, Depth d, int mn, bool rangeReduction) {
|
2019-09-28 14:27:23 -06:00
|
|
|
int r = Reductions[d] * Reductions[mn];
|
Range reductions
adding reductions for when the delta between the static eval and the child's eval is consistently low.
passed STC
https://tests.stockfishchess.org/html/live_elo.html?614d7b3c7bdc23e77ceb8a5d
LLR: 2.95 (-2.94,2.94) <-0.50,2.50>
Total: 88872 W: 22672 L: 22366 D: 43834
Ptnml(0-2): 343, 10150, 23117, 10510, 316
passed LTC
https://tests.stockfishchess.org/html/live_elo.html?614daf3e7bdc23e77ceb8a82
LLR: 2.93 (-2.94,2.94) <0.50,3.50>
Total: 24368 W: 6153 L: 5928 D: 12287
Ptnml(0-2): 13, 2503, 6937, 2708, 23
closes https://github.com/official-stockfish/Stockfish/pull/3717
Bench: 5443950
2021-09-23 14:16:17 -06:00
|
|
|
return (r + 534) / 1024 + (!i && r > 904) + rangeReduction;
|
2011-04-24 01:31:47 -06:00
|
|
|
}
|
|
|
|
|
2019-10-18 18:20:38 -06:00
|
|
|
constexpr int futility_move_count(bool improving, Depth depth) {
|
Tuned values for search constants
Tuned search constants after many search patches since the last
successful tune.
1st LTC @ 60+0.6 th 1 :
LLR: 2.97 (-2.94,2.94) {0.25,1.75}
Total: 57656 W: 7369 L: 7036 D: 43251
Ptnml(0-2): 393, 5214, 17336, 5437, 448
https://tests.stockfishchess.org/tests/view/5ee1e074f29b40b0fc95af19
SMP LTC @ 20+0.2 th 8 :
LLR: 2.95 (-2.94,2.94) {0.25,1.75}
Total: 83576 W: 9731 L: 9341 D: 64504
Ptnml(0-2): 464, 7062, 26369, 7406, 487
https://tests.stockfishchess.org/tests/view/5ee35a21f29b40b0fc95b008
The changes were rebased on top of a successful patch by Viz (see #2734)
and two different ways of doing this were tested. The successful test
modified the constants in the patch by Viz in a similar manner to the
tuning run:
LTC (rebased) @ 60+0.6 th 1 :
LLR: 2.94 (-2.94,2.94) {0.25,1.75}
Total: 193384 W: 24241 L: 23521 D: 145622
Ptnml(0-2): 1309, 17497, 58472, 17993, 1421
https://tests.stockfishchess.org/tests/view/5ee43319ca6c451633a995f9
Further work: the recent patch to quantize eval #2733 affects search quit
quite a bit, so doing another tune in, say, three months time might be a
good idea.
closes https://github.com/official-stockfish/Stockfish/pull/2735
Bench 4246971
2020-06-13 02:54:07 -06:00
|
|
|
return (3 + depth * depth) / (2 - improving);
|
2019-03-05 12:48:29 -07:00
|
|
|
}
|
|
|
|
|
2017-01-25 07:32:10 -07:00
|
|
|
// History and stats update bonus, based on depth
|
2019-09-28 14:27:23 -06:00
|
|
|
int stat_bonus(Depth d) {
|
Capping stat bonus at 2000
This patch updates the stat_bonus() function (used in the history tables to
help move ordering), keeping the same quadratic for small depths but changing
the values for depth >= 9:
The old bonus formula was increasing from zero at depth 1 to 4100 at depth 14,
then used the strange, small value of 73 for all depths >= 15.
The new bonus formula increases from 0 at depth 1 to 2000 at depth 8, then
keeps 2000 for all depths >= 8.
passed STC:
LLR: 2.94 (-2.94,2.94) <-0.50,2.50>
Total: 169624 W: 42875 L: 42454 D: 84295
Ptnml(0-2): 585, 19340, 44557, 19729, 601
https://tests.stockfishchess.org/tests/view/615bd69e9d256038a969b97c
passed LTC:
LLR: 3.07 (-2.94,2.94) <0.50,3.50>
Total: 37336 W: 9456 L: 9191 D: 18689
Ptnml(0-2): 20, 3810, 10747, 4067, 24
https://tests.stockfishchess.org/tests/view/615c75d99d256038a969b9b2
closes https://github.com/official-stockfish/Stockfish/pull/3731
Bench: 6261865
2021-10-04 12:37:26 -06:00
|
|
|
return std::min((6 * d + 229) * d - 215 , 2000);
|
2017-01-25 07:32:10 -07:00
|
|
|
}
|
|
|
|
|
2021-01-09 08:46:06 -07:00
|
|
|
// Add a small random component to draw evaluations to avoid 3-fold blindness
|
2019-09-27 11:25:22 -06:00
|
|
|
Value value_draw(Thread* thisThread) {
|
|
|
|
return VALUE_DRAW + Value(2 * (thisThread->nodes & 1) - 1);
|
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
|
|
|
}
|
|
|
|
|
Detect search explosions
This patch detects some search explosions (due to double extensions in
search.cpp) which can happen in some pathological positions, and takes
measures to ensure progress in search even for these pathological situations.
While a small number of double extensions can be useful during search
(for example to resolve a tactical sequence), a sustained regime of
double extensions leads to search explosion and a non-finishing search.
See the discussion in https://github.com/official-stockfish/Stockfish/pull/3544
and the issue https://github.com/official-stockfish/Stockfish/issues/3532 .
The implemented algorithm is the following:
a) at each node during search, store the current depth in the stack.
Double extensions are by definition levels of the stack where the
depth at ply N is strictly higher than depth at ply N-1.
b) during search, calculate for each thread a running average of the
number of double extensions in the last 4096 visited nodes.
c) if one thread has more than 2% of double extensions for a sustained
period of time (6 millions consecutive nodes, or about 4 seconds on
my iMac), we decide that this thread is in an explosion state and
we calm down this thread by preventing it to do any double extension
for the next 6 millions nodes.
To calculate the running averages, we also introduced a auxiliary class
generalizing the computations of ttHitAverage variable we already had in
code. The implementation uses an exponential moving average of period 4096
and resolution 1/1024, and all computations are done with integers for
efficiency.
-----------
Example where the patch solves a search explosion:
```
./stockfish
ucinewgame
position fen 8/Pk6/8/1p6/8/P1K5/8/6B1 w - - 37 130
go infinite
```
This algorithm does not affect search in normal, non-pathological positions.
We verified, for instance, that the usual bench is unchanged up to depth 20
at least, and that the node numbers are unchanged for a search of the starting
position at depth 32.
-------------
See https://github.com/official-stockfish/Stockfish/pull/3714
Bench: 5575265
2021-09-23 15:19:06 -06:00
|
|
|
// Check if the current thread is in a search explosion
|
|
|
|
ExplosionState search_explosion(Thread* thisThread) {
|
|
|
|
|
|
|
|
uint64_t nodesNow = thisThread->nodes;
|
|
|
|
bool explosive = thisThread->doubleExtensionAverage[WHITE].is_greater(2, 100)
|
|
|
|
|| thisThread->doubleExtensionAverage[BLACK].is_greater(2, 100);
|
|
|
|
|
|
|
|
if (explosive)
|
|
|
|
thisThread->nodesLastExplosive = nodesNow;
|
|
|
|
else
|
|
|
|
thisThread->nodesLastNormal = nodesNow;
|
|
|
|
|
|
|
|
if ( explosive
|
|
|
|
&& thisThread->state == EXPLOSION_NONE
|
|
|
|
&& nodesNow - thisThread->nodesLastNormal > 6000000)
|
|
|
|
thisThread->state = MUST_CALM_DOWN;
|
|
|
|
|
|
|
|
if ( thisThread->state == MUST_CALM_DOWN
|
|
|
|
&& nodesNow - thisThread->nodesLastExplosive > 6000000)
|
|
|
|
thisThread->state = EXPLOSION_NONE;
|
|
|
|
|
|
|
|
return thisThread->state;
|
|
|
|
}
|
|
|
|
|
2021-10-10 06:03:51 -06:00
|
|
|
// Skill structure is used to implement strength limit. If we have an uci_elo then
|
|
|
|
// we convert it to a suitable fractional skill level using anchoring to CCRL Elo
|
|
|
|
// (goldfish 1.13 = 2000) and a fit through Ordo derived Elo for match (TC 60+0.6)
|
|
|
|
// results spanning a wide range of k values.
|
2015-01-31 02:43:47 -07:00
|
|
|
struct Skill {
|
2021-10-10 06:03:51 -06:00
|
|
|
Skill(int skill_level, int uci_elo) {
|
|
|
|
if (uci_elo)
|
|
|
|
level = std::clamp(std::pow((uci_elo - 1346.6) / 143.4, 1 / 0.806), 0.0, 20.0);
|
|
|
|
else
|
|
|
|
level = double(skill_level);
|
|
|
|
}
|
|
|
|
bool enabled() const { return level < 20.0; }
|
|
|
|
bool time_to_pick(Depth depth) const { return depth == 1 + int(level); }
|
2015-01-31 02:43:47 -07:00
|
|
|
Move pick_best(size_t multiPV);
|
2010-02-07 01:53:15 -07:00
|
|
|
|
2021-10-10 06:03:51 -06:00
|
|
|
double level;
|
2015-01-31 02:43:47 -07:00
|
|
|
Move best = MOVE_NONE;
|
|
|
|
};
|
2010-02-07 01:53:15 -07:00
|
|
|
|
Introducing NodeType Root
We transform rootNode into constexpr by adding a new NodeType `Root`,
which causes a speed up.
Local test:
```
Build Tester: 1.4.7.0
Windows 10 (Version 10.0, Build 0, 64-bit Edition)
Intel(R) Core(TM) i7-8750H CPU @ 2.20GHz
SafeMode: No
Running In VM: No
HyperThreading Enabled: Yes
CPU Warmup: Yes
Command Line: bench
Tests per Build: 25
ANOVA: n/a
Engine# (NPS) Speedup Sp Conf. 95% S.S.
patch (920.179,4) ---> master (906.329,2) ---> 1,528% 20.336,5 Yes No
```
---------
STC:
LLR: 2.94 (-2.94,2.94) <-0.50,2.50>
Total: 98216 W: 8348 L: 8102 D: 81766
Ptnml(0-2): 295, 6357, 35549, 6621, 286
https://tests.stockfishchess.org/tests/view/60b797e2457376eb8bcaa0ab
Yellow LTC:
LLR: -2.95 (-2.94,2.94) <0.50,3.50>
Total: 76936 W: 2651 L: 2626 D: 71659
Ptnml(0-2): 29, 2233, 33916, 2264, 26
https://tests.stockfishchess.org/tests/view/60b80d6d457376eb8bcaa145
closes https://github.com/official-stockfish/Stockfish/pull/3522
No functional change
2021-06-03 10:52:39 -06:00
|
|
|
template <NodeType nodeType>
|
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
|
|
|
|
Introducing NodeType Root
We transform rootNode into constexpr by adding a new NodeType `Root`,
which causes a speed up.
Local test:
```
Build Tester: 1.4.7.0
Windows 10 (Version 10.0, Build 0, 64-bit Edition)
Intel(R) Core(TM) i7-8750H CPU @ 2.20GHz
SafeMode: No
Running In VM: No
HyperThreading Enabled: Yes
CPU Warmup: Yes
Command Line: bench
Tests per Build: 25
ANOVA: n/a
Engine# (NPS) Speedup Sp Conf. 95% S.S.
patch (920.179,4) ---> master (906.329,2) ---> 1,528% 20.336,5 Yes No
```
---------
STC:
LLR: 2.94 (-2.94,2.94) <-0.50,2.50>
Total: 98216 W: 8348 L: 8102 D: 81766
Ptnml(0-2): 295, 6357, 35549, 6621, 286
https://tests.stockfishchess.org/tests/view/60b797e2457376eb8bcaa0ab
Yellow LTC:
LLR: -2.95 (-2.94,2.94) <0.50,3.50>
Total: 76936 W: 2651 L: 2626 D: 71659
Ptnml(0-2): 29, 2233, 33916, 2264, 26
https://tests.stockfishchess.org/tests/view/60b80d6d457376eb8bcaa145
closes https://github.com/official-stockfish/Stockfish/pull/3522
No functional change
2021-06-03 10:52:39 -06:00
|
|
|
template <NodeType nodeType>
|
2019-09-28 14:27:23 -06:00
|
|
|
Value qsearch(Position& pos, Stack* ss, Value alpha, Value beta, Depth depth = 0);
|
2010-10-16 03:01:45 -06:00
|
|
|
|
2010-07-15 03:00:20 -06:00
|
|
|
Value value_to_tt(Value v, int ply);
|
Fix incorrect mate score.
Current master 648c7ec25db2040c0af34dd846dfa3f57af5ad0a will generate an
incorrect mate score for:
```
setoption name Hash value 8
setoption name Threads value 1
position fen 8/1p2KP2/1p4q1/1Pp5/2P5/N1Pp1k2/3P4/1N6 b - - 76 40
go depth 49
```
even though the position is a draw. Generally, SF tries to display only
proven mate scores, so this is a bug.
This was posted http://www.talkchess.com/forum3/viewtopic.php?f=2&t=72166
by Uri Blass, with the correct analysis that this must be related to the
50 moves draw rule being ignored somewhere.
Indeed, this is possible as positions and there eval are stored in the TT,
without reference to the 50mr counter. Depending on the search path followed
a position can thus be mate or draw in the TT (GHI or Graph history interaction).
Therefore, to prove mate lines, the TT content has to be used with care. Rather
than ignoring TT content in general or for mate scores (which impact search or
mate finding), it is possible to be more selective. In particular, @WOnder93
suggested to only ignore the TT if the 50mr draw ply is closer than the mate
ply. This patch implements this idea, by clamping the eval in the TT to
+-VALUE_MATED_IN_MAX_PLY. This retains the TTmove, but causes a research of
these lines (with the current 50mr counter) as needed.
This patch hardly ever affects search (as indicated by the unchanged
bench), but fixes the testcase. As the conditions are very specific,
also mate finding will almost never be less efficient (testing welcome).
It was also shown to pass STC and LTC non-regression testing, in a form
using if/then/else instead of ternary operators:
STC:
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 93605 W: 15346 L: 15340 D: 62919
http://tests.stockfishchess.org/tests/view/5db45bb00ebc5908127538d4
LTC:
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 33873 W: 7359 L: 7261 D: 19253
http://tests.stockfishchess.org/tests/view/5db4c8940ebc5902d6b146fc
closes https://github.com/official-stockfish/Stockfish/issues/2370
Bench: 4362323
2019-10-26 08:34:19 -06:00
|
|
|
Value value_from_tt(Value v, int ply, int r50c);
|
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);
|
Improve move order near the root
Current move histories are known to work well near the leaves, whilst at
higher depths they aren't very helpful. To address this problem this
patch introduces a table dedicated for what's happening at plies 0-3.
It's structured like mainHistory with ply index instead of color.
It get cleared with each new search and is filled during iterative
deepening at higher depths when recording successful quiet moves near
the root or traversing nodes which were in the principal variation
(ttPv).
Medium TC (20+0.2):
https://tests.stockfishchess.org/tests/view/5e4d358790a0a02810d096dc
LLR: 2.94 (-2.94,2.94) {-0.50,1.50}
Total: 100910 W: 16682 L: 16376 D: 67852
Ptnml(0-2): 1177, 10983, 25883, 11181, 1231
LTC:
https://tests.stockfishchess.org/tests/view/5e4e2cb790a0a02810d09714
LLR: 2.95 (-2.94,2.94) {0.25,1.75}
Total: 80444 W: 10495 L: 10095 D: 59854
Ptnml(0-2): 551, 7479, 23803, 7797, 592
closes https://github.com/official-stockfish/Stockfish/pull/2557
Bench: 4705960
2020-02-21 06:01:59 -07:00
|
|
|
void update_quiet_stats(const Position& pos, Stack* ss, Move move, int bonus, int depth);
|
Refactor final stats updates.
This PR refactors update_quiet_stats, update_capture_stats and search to more clearly reflect what is actually done.
Effectively, all stat updates that need to be done after search is finished and a bestmove is found,
are collected in a new function ```final_stats_update()```. This shortens our main search routine, and simplifies ```update_quiet_stats```.
The latter function is now more easily reusable with fewer arguments, as the handling of ```quietsSearched``` is only needed in ```final_stats_update```.
```update_capture_stats```, which was only called once is now integrated in ```final_stats_update```, which allows for removing a branch and reusing some ```stat_bonus``` calls. The need for refactoring was also suggested by the fact that the comments of ```update_quiet_stats``` and ```update_capture_stats``` were incorrect (e.g. ```update_capture_stats``` was called, correctly, also when the bestmove was a quiet and not a capture).
passed non-regression STC:
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 75196 W: 16364 L: 16347 D: 42485
http://tests.stockfishchess.org/tests/view/5db004ec0ebc5902c06db9e1
The diff is most easily readable as ```git diff master --patience```
No functional change
2019-10-23 00:26:47 -06:00
|
|
|
void update_all_stats(const Position& pos, Stack* ss, Move bestMove, Value bestValue, Value beta, Square prevSq,
|
Revert 5 recent patches
Revert 5 patches which were merged, but lead to a regression test that showed negative Elo gain:
http://tests.stockfishchess.org/tests/view/5e307251ab2d69d58394fdb9
This was discussed in depth in:
https://github.com/official-stockfish/Stockfish/issues/2531
Each patch was removed and tested as a simplification, full list below, and the whole combo as well.
After the revert the regression test showed a neutral result:
http://tests.stockfishchess.org/tests/view/5e334851708b13464ceea33c
As a result of this experience, the SPRT testing bounds will be made more strict.
Reverted patches:
1 Dynamic Complexity 6d0eabd5fe2961551477820ab7619e2c31e01ffd :
STC 10+0.1 https://tests.stockfishchess.org/tests/view/5e31fcacec661e2e6a340d08 :
LLR: 2.97 (-2.94,2.94) {-1.50,0.50}
Total: 38130 W: 7326 L: 7189 D: 23615
Ptnml(0-2): 677, 4346, 8843, 4545, 646
LTC 60+0.6 https://tests.stockfishchess.org/tests/view/5e32c18fec661e2e6a340d73 :
LLR: 2.94 (-2.94,2.94) {-1.50,0.50}
Total: 38675 W: 4941 L: 4866 D: 28868
Ptnml(0-2): 270, 3556, 11429, 3584, 291
3 More bonus for bestMoves on past PV nodes 71e0b5385e2717679a57c6b77d8c7ac5fff3b89f :
STC 10+0.1 https://tests.stockfishchess.org/tests/view/5e31fe93ec661e2e6a340d10 :
LLR: 2.95 (-2.94,2.94) {-1.50,0.50}
Total: 46100 W: 8853 L: 8727 D: 28520
Ptnml(0-2): 796, 5297, 10749, 5387, 813
LTC 60+0.6 https://tests.stockfishchess.org/tests/view/5e32c187ec661e2e6a340d71 :
LLR: 2.96 (-2.94,2.94) {-1.50,0.50}
Total: 16920 W: 2161 L: 2055 D: 12704
Ptnml(0-2): 115, 1498, 5006, 1569, 130
4 Tweak Restricted Piece Bonus 0ae00454ba6928d181b46103e5c83e6d58fcebe5 :
STC 10+0.1 https://tests.stockfishchess.org/tests/view/5e31fefaec661e2e6a340d15 :
LLR: 2.94 (-2.94,2.94) {-1.50,0.50}
Total: 88328 W: 17060 L: 16997 D: 54271
Ptnml(0-2): 1536, 10446, 20169, 10422, 1581
LTC 60+0.6 https://tests.stockfishchess.org/tests/view/5e32c17aec661e2e6a340d6f :
LLR: 2.95 (-2.94,2.94) {-1.50,0.50}
Total: 34784 W: 4551 L: 4466 D: 25767
Ptnml(0-2): 255, 3279, 10061, 3345, 262
5 History update for pruned captures 01b6088af39902001d2d6844561b6a2faa549282 :
STC 10+0.1 https://tests.stockfishchess.org/tests/view/5e31ff5eec661e2e6a340d1a :
LLR: 2.94 (-2.94,2.94) {-1.50,0.50}
Total: 29541 W: 5735 L: 5588 D: 18218
Ptnml(0-2): 483, 3445, 6820, 3469, 545
LTC 60+0.6 https://tests.stockfishchess.org/tests/view/5e32c196ec661e2e6a340d75 :
LLR: 2.94 (-2.94,2.94) {-1.50,0.50}
Total: 22177 W: 2854 L: 2757 D: 16566
Ptnml(0-2): 143, 2005, 6555, 2055, 164
6 Tweak trapped rook penalty 18fc21eba0368fd5e3c4c4b8ee1000c9ac445425 :
STC 10+0.1 https://tests.stockfishchess.org/tests/view/5e31ffb1ec661e2e6a340d1c :
LLR: 2.95 (-2.94,2.94) {-1.50,0.50}
Total: 24476 W: 4727 L: 4569 D: 15180
Ptnml(0-2): 390, 2834, 5659, 2933, 417
LTC 60+0.6 https://tests.stockfishchess.org/tests/view/5e32c19eec661e2e6a340d77 :
LLR: 2.95 (-2.94,2.94) {-1.50,0.50}
Total: 97332 W: 12492 L: 12466 D: 72374
Ptnml(0-2): 690, 9107, 28738, 9034, 720
All 5 as one simplification :
LTC 60+0.6 https://tests.stockfishchess.org/tests/view/5e334098708b13464ceea330 :
LLR: 2.94 (-2.94,2.94) {-1.50,0.50}
Total: 7829 W: 1079 L: 964 D: 5786
Ptnml(0-2): 52, 690, 2281, 781, 65
Bench: 5153165
2020-01-30 13:44:04 -07:00
|
|
|
Move* quietsSearched, int quietCount, Move* capturesSearched, int captureCount, Depth depth);
|
2008-08-31 23:59:13 -06:00
|
|
|
|
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;
|
2021-04-19 11:50:19 -06:00
|
|
|
ASSERT_ALIGNED(&st, Eval::NNUE::CacheLineSize);
|
2020-11-03 03:23:35 -07:00
|
|
|
|
2017-08-15 02:05:22 -06:00
|
|
|
uint64_t cnt, nodes = 0;
|
2019-09-28 14:27:23 -06:00
|
|
|
const bool leaf = (depth == 2);
|
2017-08-15 02:05:22 -06:00
|
|
|
|
|
|
|
for (const auto& m : MoveList<LEGAL>(pos))
|
|
|
|
{
|
2019-09-28 14:27:23 -06:00
|
|
|
if (Root && depth <= 1)
|
2017-08-15 02:05:22 -06:00
|
|
|
cnt = 1, nodes++;
|
|
|
|
else
|
|
|
|
{
|
|
|
|
pos.do_move(m, st);
|
2019-09-28 14:27:23 -06:00
|
|
|
cnt = leaf ? MoveList<LEGAL>(pos).size() : perft<false>(pos, depth - 1);
|
2017-08-15 02:05:22 -06:00
|
|
|
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-04-19 09:33:26 -06:00
|
|
|
for (int i = 1; i < MAX_MOVES; ++i)
|
Increase reductions with thread count
Respin of multi-thread idea that was simplified away recently: basically doing
more reductions with thread count since Lazy SMP naturally widens search. With
drawish book this idea got simplified away but with less drawish book it again
gains elo, maybe trying to reinstall other ideas that were simplified away
previously can be beneficial.
passed STC
LLR: 2.96 (-2.94,2.94) <-0.50,2.50>
Total: 39736 W: 10205 L: 9986 D: 19545
Ptnml(0-2): 45, 4254, 11064, 4447, 58
https://tests.stockfishchess.org/tests/view/615750702d02f48db3961b00
passed LTC
LLR: 2.97 (-2.94,2.94) <0.50,3.50>
Total: 60352 W: 15530 L: 15218 D: 29604
Ptnml(0-2): 24, 5900, 18016, 6212, 24
https://tests.stockfishchess.org/tests/view/6157d8935488e26ea5eace7f
closes https://github.com/official-stockfish/Stockfish/pull/3724
Bench 5714575
2021-10-03 02:27:40 -06:00
|
|
|
Reductions[i] = int((21.9 + std::log(Threads.size()) / 2) * std::log(i));
|
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();
|
2019-03-31 03:47:36 -06:00
|
|
|
Tablebases::init(Options["SyzygyPath"]); // Free mapped files
|
2015-05-06 05:24:00 -06:00
|
|
|
}
|
|
|
|
|
|
|
|
|
2019-03-31 03:47:36 -06:00
|
|
|
/// MainThread::search() is started when the program receives 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)
|
|
|
|
{
|
2019-09-28 14:27:23 -06:00
|
|
|
nodes = perft<true>(rootPos, Limits.perft);
|
2017-08-15 02:05:22 -06:00
|
|
|
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
|
|
|
|
2020-09-09 02:49:31 -06:00
|
|
|
Eval::NNUE::verify();
|
Add NNUE evaluation
This patch ports the efficiently updatable neural network (NNUE) evaluation to Stockfish.
Both the NNUE and the classical evaluations are available, and can be used to
assign a value to a position that is later used in alpha-beta (PVS) search to find the
best move. The classical evaluation computes this value as a function of various chess
concepts, handcrafted by experts, tested and tuned using fishtest. The NNUE evaluation
computes this value with a neural network based on basic inputs. The network is optimized
and trained on the evalutions of millions of positions at moderate search depth.
The NNUE evaluation was first introduced in shogi, and ported to Stockfish afterward.
It can be evaluated efficiently on CPUs, and exploits the fact that only parts
of the neural network need to be updated after a typical chess move.
[The nodchip repository](https://github.com/nodchip/Stockfish) provides additional
tools to train and develop the NNUE networks.
This patch is the result of contributions of various authors, from various communities,
including: nodchip, ynasu87, yaneurao (initial port and NNUE authors), domschl, FireFather,
rqs, xXH4CKST3RXx, tttak, zz4032, joergoster, mstembera, nguyenpham, erbsenzaehler,
dorzechowski, and vondele.
This new evaluation needed various changes to fishtest and the corresponding infrastructure,
for which tomtor, ppigazzini, noobpwnftw, daylen, and vondele are gratefully acknowledged.
The first networks have been provided by gekkehenker and sergiovieri, with the latter
net (nn-97f742aaefcd.nnue) being the current default.
The evaluation function can be selected at run time with the `Use NNUE` (true/false) UCI option,
provided the `EvalFile` option points the the network file (depending on the GUI, with full path).
The performance of the NNUE evaluation relative to the classical evaluation depends somewhat on
the hardware, and is expected to improve quickly, but is currently on > 80 Elo on fishtest:
60000 @ 10+0.1 th 1
https://tests.stockfishchess.org/tests/view/5f28fe6ea5abc164f05e4c4c
ELO: 92.77 +-2.1 (95%) LOS: 100.0%
Total: 60000 W: 24193 L: 8543 D: 27264
Ptnml(0-2): 609, 3850, 9708, 10948, 4885
40000 @ 20+0.2 th 8
https://tests.stockfishchess.org/tests/view/5f290229a5abc164f05e4c58
ELO: 89.47 +-2.0 (95%) LOS: 100.0%
Total: 40000 W: 12756 L: 2677 D: 24567
Ptnml(0-2): 74, 1583, 8550, 7776, 2017
At the same time, the impact on the classical evaluation remains minimal, causing no significant
regression:
sprt @ 10+0.1 th 1
https://tests.stockfishchess.org/tests/view/5f2906a2a5abc164f05e4c5b
LLR: 2.94 (-2.94,2.94) {-6.00,-4.00}
Total: 34936 W: 6502 L: 6825 D: 21609
Ptnml(0-2): 571, 4082, 8434, 3861, 520
sprt @ 60+0.6 th 1
https://tests.stockfishchess.org/tests/view/5f2906cfa5abc164f05e4c5d
LLR: 2.93 (-2.94,2.94) {-6.00,-4.00}
Total: 10088 W: 1232 L: 1265 D: 7591
Ptnml(0-2): 49, 914, 3170, 843, 68
The needed networks can be found at https://tests.stockfishchess.org/nns
It is recommended to use the default one as indicated by the `EvalFile` UCI option.
Guidelines for testing new nets can be found at
https://github.com/glinscott/fishtest/wiki/Creating-my-first-test#nnue-net-tests
Integration has been discussed in various issues:
https://github.com/official-stockfish/Stockfish/issues/2823
https://github.com/official-stockfish/Stockfish/issues/2728
The integration branch will be closed after the merge:
https://github.com/official-stockfish/Stockfish/pull/2825
https://github.com/official-stockfish/Stockfish/tree/nnue-player-wip
closes https://github.com/official-stockfish/Stockfish/pull/2912
This will be an exciting time for computer chess, looking forward to seeing the evolution of
this approach.
Bench: 4746616
2020-08-05 09:11:15 -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 (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
|
|
|
|
{
|
2020-05-31 23:31:14 -06:00
|
|
|
Threads.start_searching(); // start non-main threads
|
|
|
|
Thread::search(); // main thread 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
|
2020-05-31 23:31:14 -06:00
|
|
|
Threads.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-11-02 02:58:18 -07:00
|
|
|
Thread* bestThread = this;
|
2021-10-10 06:03:51 -06:00
|
|
|
Skill skill = Skill(Options["Skill Level"], Options["UCI_LimitStrength"] ? int(Options["UCI_Elo"]) : 0);
|
2019-03-31 03:47:36 -06:00
|
|
|
|
2020-07-09 14:01:06 -06:00
|
|
|
if ( int(Options["MultiPV"]) == 1
|
|
|
|
&& !Limits.depth
|
2021-10-10 06:03:51 -06:00
|
|
|
&& !skill.enabled()
|
2020-07-09 14:01:06 -06:00
|
|
|
&& rootMoves[0].pv[0] != MOVE_NONE)
|
2020-05-31 23:31:14 -06:00
|
|
|
bestThread = Threads.get_best_thread();
|
2015-11-02 02:58:18 -07:00
|
|
|
|
2020-04-12 12:30:08 -06:00
|
|
|
bestPreviousScore = 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
|
|
|
|
2019-03-31 03:47:36 -06:00
|
|
|
// To allow access to (ss-7) up to (ss+2), the stack must be oversized.
|
2018-12-19 13:04:36 -07:00
|
|
|
// The former is needed to allow update_continuation_histories(ss-1, ...),
|
2019-03-31 03:47:36 -06:00
|
|
|
// which accesses its argument at ss-6, also near the root.
|
Pre-initialize ss->ply
We pre-initialize ss->ply over the whole stack. There is no need
to re-assign the same value(s) over and over again while searching.
Probably a tiny speedup on longer searches.
Tested for no regression:
STC
LLR: 2.93 (-2.94,2.94) <-2.50,0.50>
Total: 25784 W: 2205 L: 2101 D: 21478
Ptnml(0-2): 62, 1660, 9368, 1716, 86
https://tests.stockfishchess.org/tests/view/60b516c6457376eb8bca9dfa
LTC
LLR: 2.94 (-2.94,2.94) <-2.50,0.50>
Total: 26200 W: 944 L: 878 D: 24378
Ptnml(0-2): 12, 732, 11545, 800, 11
https://tests.stockfishchess.org/tests/view/60b53652457376eb8bca9e0e
closes https://github.com/official-stockfish/Stockfish/pull/3516
No functional change.
2021-05-31 09:46:40 -06:00
|
|
|
// The latter is needed for statScore 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;
|
2019-09-28 14:27:23 -06:00
|
|
|
Depth lastBestMoveDepth = 0;
|
2015-12-23 02:07:54 -07:00
|
|
|
MainThread* mainThread = (this == Threads.main() ? Threads.main() : nullptr);
|
Use average bestMoveChanges across all threads #2072
The current update only by main thread depends on the luck of
whether main thread sees any/many changes to the best move or not.
It then makes large, lumpy changes to the time to be
used (1x, 2x, 3x, etc) depending on that sample of 1.
Use the average across all threads to get a more reliable
number with a smoother distribution.
STC @ 5+0.05 th 4 :
LLR: 2.95 (-2.94,2.94) [0.50,4.50]
Total: 51899 W: 11446 L: 11029 D: 29424
http://tests.stockfishchess.org/tests/view/5ca32ff20ebc5925cf0016fb
STC @ 5+0.05 th 8 :
LLR: 2.96 (-2.94,2.94) [0.50,4.50]
Total: 13851 W: 2843 L: 2620 D: 8388
http://tests.stockfishchess.org/tests/view/5ca35ae00ebc5925cf001adb
LTC @ 20+0.2 th 8 :
LLR: 2.95 (-2.94,2.94) [0.00,3.50]
Total: 48527 W: 7941 L: 7635 D: 32951
http://tests.stockfishchess.org/tests/view/5ca37cb70ebc5925cf001cec
Further work:
Similar changes might be possible for the fallingEval and timeReduction calculations (and elsewhere?), using either the min, average or max values across all threads.
Bench 3506898
2019-04-03 01:35:55 -06:00
|
|
|
double timeReduction = 1, totBestMoveChanges = 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();
|
2019-12-08 04:06:19 -07:00
|
|
|
int iterIdx = 0;
|
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--)
|
2019-10-08 08:44:01 -06:00
|
|
|
(ss-i)->continuationHistory = &this->continuationHistory[0][0][NO_PIECE][0]; // Use as a sentinel
|
2019-10-05 08:42:36 -06:00
|
|
|
|
Pre-initialize ss->ply
We pre-initialize ss->ply over the whole stack. There is no need
to re-assign the same value(s) over and over again while searching.
Probably a tiny speedup on longer searches.
Tested for no regression:
STC
LLR: 2.93 (-2.94,2.94) <-2.50,0.50>
Total: 25784 W: 2205 L: 2101 D: 21478
Ptnml(0-2): 62, 1660, 9368, 1716, 86
https://tests.stockfishchess.org/tests/view/60b516c6457376eb8bca9dfa
LTC
LLR: 2.94 (-2.94,2.94) <-2.50,0.50>
Total: 26200 W: 944 L: 878 D: 24378
Ptnml(0-2): 12, 732, 11545, 800, 11
https://tests.stockfishchess.org/tests/view/60b53652457376eb8bca9e0e
closes https://github.com/official-stockfish/Stockfish/pull/3516
No functional change.
2021-05-31 09:46:40 -06:00
|
|
|
for (int i = 0; i <= MAX_PLY + 2; ++i)
|
|
|
|
(ss+i)->ply = i;
|
|
|
|
|
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
|
|
|
|
2019-12-08 04:06:19 -07:00
|
|
|
if (mainThread)
|
|
|
|
{
|
2020-04-12 12:30:08 -06:00
|
|
|
if (mainThread->bestPreviousScore == VALUE_INFINITE)
|
2020-05-23 05:26:13 -06:00
|
|
|
for (int i = 0; i < 4; ++i)
|
2019-12-08 04:06:19 -07:00
|
|
|
mainThread->iterValue[i] = VALUE_ZERO;
|
|
|
|
else
|
2020-05-23 05:26:13 -06:00
|
|
|
for (int i = 0; i < 4; ++i)
|
2020-04-12 12:30:08 -06:00
|
|
|
mainThread->iterValue[i] = mainThread->bestPreviousScore;
|
2019-12-08 04:06:19 -07:00
|
|
|
}
|
|
|
|
|
Keep low ply history from previous move
This patch keeps the low-ply history from the previous move, shifting the data down by 2 ply.
Tested with closedpos book:
STC:
LLR: 2.93 (-2.94,2.94) {-0.50,1.50}
Total: 71584 W: 14175 L: 13891 D: 43518
Ptnml(0-2): 1069, 8228, 16993, 8354, 1148
https://tests.stockfishchess.org/tests/view/5ec0eaafe9d85f94dc429974
LTC:
LLR: 2.94 (-2.94,2.94) {0.25,1.75}
Total: 96552 W: 13946 L: 13498 D: 69108
Ptnml(0-2): 676, 9082, 28375, 9404, 739
https://tests.stockfishchess.org/tests/view/5ec145efe9d85f94dc4299b0
closes https://github.com/official-stockfish/Stockfish/pull/2688
Bench 5148950
2020-05-21 14:17:21 -06:00
|
|
|
std::copy(&lowPlyHistory[2][0], &lowPlyHistory.back().back() + 1, &lowPlyHistory[0][0]);
|
|
|
|
std::fill(&lowPlyHistory[MAX_LPH - 2][0], &lowPlyHistory.back().back() + 1, 0);
|
|
|
|
|
2020-05-23 05:26:13 -06:00
|
|
|
size_t multiPV = size_t(Options["MultiPV"]);
|
2021-10-10 06:03:51 -06:00
|
|
|
Skill skill(Options["Skill Level"], Options["UCI_LimitStrength"] ? int(Options["UCI_Elo"]) : 0);
|
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
|
|
|
|
Detect search explosions
This patch detects some search explosions (due to double extensions in
search.cpp) which can happen in some pathological positions, and takes
measures to ensure progress in search even for these pathological situations.
While a small number of double extensions can be useful during search
(for example to resolve a tactical sequence), a sustained regime of
double extensions leads to search explosion and a non-finishing search.
See the discussion in https://github.com/official-stockfish/Stockfish/pull/3544
and the issue https://github.com/official-stockfish/Stockfish/issues/3532 .
The implemented algorithm is the following:
a) at each node during search, store the current depth in the stack.
Double extensions are by definition levels of the stack where the
depth at ply N is strictly higher than depth at ply N-1.
b) during search, calculate for each thread a running average of the
number of double extensions in the last 4096 visited nodes.
c) if one thread has more than 2% of double extensions for a sustained
period of time (6 millions consecutive nodes, or about 4 seconds on
my iMac), we decide that this thread is in an explosion state and
we calm down this thread by preventing it to do any double extension
for the next 6 millions nodes.
To calculate the running averages, we also introduced a auxiliary class
generalizing the computations of ttHitAverage variable we already had in
code. The implementation uses an exponential moving average of period 4096
and resolution 1/1024, and all computations are done with integers for
efficiency.
-----------
Example where the patch solves a search explosion:
```
./stockfish
ucinewgame
position fen 8/Pk6/8/1p6/8/P1K5/8/6B1 w - - 37 130
go infinite
```
This algorithm does not affect search in normal, non-pathological positions.
We verified, for instance, that the usual bench is unchanged up to depth 20
at least, and that the node numbers are unchanged for a search of the starting
position at depth 32.
-------------
See https://github.com/official-stockfish/Stockfish/pull/3714
Bench: 5575265
2021-09-23 15:19:06 -06:00
|
|
|
doubleExtensionAverage[WHITE].set(0, 100); // initialize the running average at 0%
|
|
|
|
doubleExtensionAverage[BLACK].set(0, 100); // initialize the running average at 0%
|
|
|
|
|
|
|
|
nodesLastExplosive = nodes;
|
|
|
|
nodesLastNormal = nodes;
|
|
|
|
state = EXPLOSION_NONE;
|
Remove the Contempt UCI option
This patch removes the UCI option for setting Contempt in classical evaluation.
It is exactly equivalent to using Contempt=0 for the UCI contempt value and keeping
the dynamic part in the algo (renaming this dynamic part `trend` to better describe
what it does). We have tried quite hard to implement a working Contempt feature for
NNUE but nothing really worked, so it is probably time to give up.
Interested chess fans wishing to keep playing with the UCI option for Contempt and
use it with the classical eval are urged to download the version tagged "SF_Classical"
of Stockfish (dated 31 July 2020), as it was the last version where our search
algorithm was tuned for the classical eval and is probably our strongest classical
player ever: https://github.com/official-stockfish/Stockfish/tags
Passed STC:
LLR: 2.95 (-2.94,2.94) <-2.50,0.50>
Total: 72904 W: 6228 L: 6175 D: 60501
Ptnml(0-2): 221, 5006, 25971, 5007, 247
https://tests.stockfishchess.org/tests/view/60c98bf9457376eb8bcab18d
Passed LTC:
LLR: 2.93 (-2.94,2.94) <-2.50,0.50>
Total: 45168 W: 1601 L: 1547 D: 42020
Ptnml(0-2): 38, 1331, 19786, 1397, 32
https://tests.stockfishchess.org/tests/view/60c9c7fa457376eb8bcab1bb
closes https://github.com/official-stockfish/Stockfish/pull/3575
Bench: 4947716
2021-06-15 23:23:26 -06:00
|
|
|
trend = SCORE_ZERO;
|
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
|
|
|
|
Smarter time management near stop limit
This patch makes Stockfish search same depth again if > 60% of optimum time is
already used, instead of trying the next iteration. The idea is that the next
iteration will generally take about the same amount of time as has already been
used in total. When we are likely to begin the last iteration, as judged by total
time taken so far > 0.6 * optimum time, searching the last depth again instead of
increasing the depth still helps the other threads in lazy SMP and prepares better
move ordering for the next moves.
STC :
LLR: 2.95 (-2.94,2.94) {-1.00,3.00}
Total: 13436 W: 2695 L: 2558 D: 8183
Ptnml(0-2): 222, 1538, 3087, 1611, 253
https://tests.stockfishchess.org/tests/view/5e1618a761fe5f83a67dd964
LTC :
LLR: 2.94 (-2.94,2.94) {0.00,2.00}
Total: 32160 W: 4261 L: 4047 D: 23852
Ptnml(0-2): 211, 2988, 9448, 3135, 247
https://tests.stockfishchess.org/tests/view/5e162ca061fe5f83a67dd96d
The code was revised as suggested by @vondele for multithreading:
STC (8 threads):
LLR: 2.95 (-2.94,2.94) {0.00,2.00}
Total: 16640 W: 2049 L: 1885 D: 12706
Ptnml(0-2): 119, 1369, 5158, 1557, 108
https://tests.stockfishchess.org/tests/view/5e19826a2cc590e03c3c2f52
LTC (8 threads):
LLR: 2.95 (-2.94,2.94) {-1.00,3.00}
Total: 16536 W: 2758 L: 2629 D: 11149
Ptnml(0-2): 182, 1758, 4296, 1802, 224
https://tests.stockfishchess.org/tests/view/5e18b91a27dab692fcf9a140
Thanks to those discussing Stockfish lazy SMP on fishcooking which made me
try this, and to @vondele for suggestions and doing related tests.
See full discussion in the pull request thread:
https://github.com/official-stockfish/Stockfish/pull/2482
Bench: 4586187
2020-01-11 15:10:22 -07:00
|
|
|
int searchAgainCounter = 0;
|
|
|
|
|
2016-08-19 04:17:38 -06:00
|
|
|
// Iterative deepening loop until requested to stop or the target depth is reached
|
2019-09-28 14:27:23 -06:00
|
|
|
while ( ++rootDepth < MAX_PLY
|
2017-07-13 17:07:19 -06:00
|
|
|
&& !Threads.stop
|
2019-09-28 14:27:23 -06:00
|
|
|
&& !(Limits.depth && mainThread && rootDepth > 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
|
|
|
{
|
|
|
|
// Age out PV variability metric
|
2015-12-23 02:07:54 -07:00
|
|
|
if (mainThread)
|
Use average bestMoveChanges across all threads #2072
The current update only by main thread depends on the luck of
whether main thread sees any/many changes to the best move or not.
It then makes large, lumpy changes to the time to be
used (1x, 2x, 3x, etc) depending on that sample of 1.
Use the average across all threads to get a more reliable
number with a smoother distribution.
STC @ 5+0.05 th 4 :
LLR: 2.95 (-2.94,2.94) [0.50,4.50]
Total: 51899 W: 11446 L: 11029 D: 29424
http://tests.stockfishchess.org/tests/view/5ca32ff20ebc5925cf0016fb
STC @ 5+0.05 th 8 :
LLR: 2.96 (-2.94,2.94) [0.50,4.50]
Total: 13851 W: 2843 L: 2620 D: 8388
http://tests.stockfishchess.org/tests/view/5ca35ae00ebc5925cf001adb
LTC @ 20+0.2 th 8 :
LLR: 2.95 (-2.94,2.94) [0.00,3.50]
Total: 48527 W: 7941 L: 7635 D: 32951
http://tests.stockfishchess.org/tests/view/5ca37cb70ebc5925cf001cec
Further work:
Similar changes might be possible for the fallingEval and timeReduction calculations (and elsewhere?), using either the min, average or max values across all threads.
Bench 3506898
2019-04-03 01:35:55 -06:00
|
|
|
totBestMoveChanges /= 2;
|
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
|
|
|
|
Smarter time management near stop limit
This patch makes Stockfish search same depth again if > 60% of optimum time is
already used, instead of trying the next iteration. The idea is that the next
iteration will generally take about the same amount of time as has already been
used in total. When we are likely to begin the last iteration, as judged by total
time taken so far > 0.6 * optimum time, searching the last depth again instead of
increasing the depth still helps the other threads in lazy SMP and prepares better
move ordering for the next moves.
STC :
LLR: 2.95 (-2.94,2.94) {-1.00,3.00}
Total: 13436 W: 2695 L: 2558 D: 8183
Ptnml(0-2): 222, 1538, 3087, 1611, 253
https://tests.stockfishchess.org/tests/view/5e1618a761fe5f83a67dd964
LTC :
LLR: 2.94 (-2.94,2.94) {0.00,2.00}
Total: 32160 W: 4261 L: 4047 D: 23852
Ptnml(0-2): 211, 2988, 9448, 3135, 247
https://tests.stockfishchess.org/tests/view/5e162ca061fe5f83a67dd96d
The code was revised as suggested by @vondele for multithreading:
STC (8 threads):
LLR: 2.95 (-2.94,2.94) {0.00,2.00}
Total: 16640 W: 2049 L: 1885 D: 12706
Ptnml(0-2): 119, 1369, 5158, 1557, 108
https://tests.stockfishchess.org/tests/view/5e19826a2cc590e03c3c2f52
LTC (8 threads):
LLR: 2.95 (-2.94,2.94) {-1.00,3.00}
Total: 16536 W: 2758 L: 2629 D: 11149
Ptnml(0-2): 182, 1758, 4296, 1802, 224
https://tests.stockfishchess.org/tests/view/5e18b91a27dab692fcf9a140
Thanks to those discussing Stockfish lazy SMP on fishcooking which made me
try this, and to @vondele for suggestions and doing related tests.
See full discussion in the pull request thread:
https://github.com/official-stockfish/Stockfish/pull/2482
Bench: 4586187
2020-01-11 15:10:22 -07:00
|
|
|
if (!Threads.increaseDepth)
|
|
|
|
searchAgainCounter++;
|
|
|
|
|
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
|
2019-09-28 14:27:23 -06:00
|
|
|
if (rootDepth >= 4)
|
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
|
|
|
{
|
2020-04-12 12:30:08 -06:00
|
|
|
Value prev = rootMoves[pvIdx].previousScore;
|
Widen the aspiration window for larger evals
passed STC
LLR: 2.93 (-2.94,2.94) <-0.50,2.50>
Total: 36840 W: 9359 L: 9134 D: 18347
Ptnml(0-2): 111, 4130, 9722, 4337, 120
https://tests.stockfishchess.org/tests/view/617c601301c6d0988731d10a
passed LTC
LLR: 2.98 (-2.94,2.94) <0.50,3.50>
Total: 64824 W: 16377 L: 16043 D: 32404
Ptnml(0-2): 27, 6712, 18618, 7010, 45
https://tests.stockfishchess.org/tests/view/617c720d01c6d0988731d114
closes https://github.com/official-stockfish/Stockfish/pull/3768
Bench: 7683058
2021-10-29 09:45:09 -06:00
|
|
|
delta = Value(17) + int(prev) * prev / 16384;
|
2020-04-12 12:30:08 -06:00
|
|
|
alpha = std::max(prev - delta,-VALUE_INFINITE);
|
|
|
|
beta = std::min(prev + 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
|
|
|
|
Remove the Contempt UCI option
This patch removes the UCI option for setting Contempt in classical evaluation.
It is exactly equivalent to using Contempt=0 for the UCI contempt value and keeping
the dynamic part in the algo (renaming this dynamic part `trend` to better describe
what it does). We have tried quite hard to implement a working Contempt feature for
NNUE but nothing really worked, so it is probably time to give up.
Interested chess fans wishing to keep playing with the UCI option for Contempt and
use it with the classical eval are urged to download the version tagged "SF_Classical"
of Stockfish (dated 31 July 2020), as it was the last version where our search
algorithm was tuned for the classical eval and is probably our strongest classical
player ever: https://github.com/official-stockfish/Stockfish/tags
Passed STC:
LLR: 2.95 (-2.94,2.94) <-2.50,0.50>
Total: 72904 W: 6228 L: 6175 D: 60501
Ptnml(0-2): 221, 5006, 25971, 5007, 247
https://tests.stockfishchess.org/tests/view/60c98bf9457376eb8bcab18d
Passed LTC:
LLR: 2.93 (-2.94,2.94) <-2.50,0.50>
Total: 45168 W: 1601 L: 1547 D: 42020
Ptnml(0-2): 38, 1331, 19786, 1397, 32
https://tests.stockfishchess.org/tests/view/60c9c7fa457376eb8bcab1bb
closes https://github.com/official-stockfish/Stockfish/pull/3575
Bench: 4947716
2021-06-15 23:23:26 -06:00
|
|
|
// Adjust trend based on root move's previousScore (dynamic contempt)
|
|
|
|
int tr = 113 * prev / (abs(prev) + 147);
|
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
|
|
|
|
Remove the Contempt UCI option
This patch removes the UCI option for setting Contempt in classical evaluation.
It is exactly equivalent to using Contempt=0 for the UCI contempt value and keeping
the dynamic part in the algo (renaming this dynamic part `trend` to better describe
what it does). We have tried quite hard to implement a working Contempt feature for
NNUE but nothing really worked, so it is probably time to give up.
Interested chess fans wishing to keep playing with the UCI option for Contempt and
use it with the classical eval are urged to download the version tagged "SF_Classical"
of Stockfish (dated 31 July 2020), as it was the last version where our search
algorithm was tuned for the classical eval and is probably our strongest classical
player ever: https://github.com/official-stockfish/Stockfish/tags
Passed STC:
LLR: 2.95 (-2.94,2.94) <-2.50,0.50>
Total: 72904 W: 6228 L: 6175 D: 60501
Ptnml(0-2): 221, 5006, 25971, 5007, 247
https://tests.stockfishchess.org/tests/view/60c98bf9457376eb8bcab18d
Passed LTC:
LLR: 2.93 (-2.94,2.94) <-2.50,0.50>
Total: 45168 W: 1601 L: 1547 D: 42020
Ptnml(0-2): 38, 1331, 19786, 1397, 32
https://tests.stockfishchess.org/tests/view/60c9c7fa457376eb8bcab1bb
closes https://github.com/official-stockfish/Stockfish/pull/3575
Bench: 4947716
2021-06-15 23:23:26 -06:00
|
|
|
trend = (us == WHITE ? make_score(tr, tr / 2)
|
|
|
|
: -make_score(tr, tr / 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.
|
Simplify reduction for consecutive fails
Revert the heuristic introduced in #3184, by which we reduced more
the late sons of the root position after consecutive fail highs.
---
Before new net architecture:
STC:
LLR: 2.95 (-2.94,2.94) <-2.50,0.50>
Total: 226336 W: 20373 L: 20500 D: 185463
Ptnml(0-2): 755, 16087, 79595, 15992, 739
https://tests.stockfishchess.org/tests/view/609dec205085663412d08e9d
LTC:
LLR: 2.93 (-2.94,2.94) <-2.50,0.50>
Total: 67432 W: 2411 L: 2375 D: 62646
Ptnml(0-2): 33, 1944, 29714, 2004, 21
https://tests.stockfishchess.org/tests/view/609ee30f5085663412d08fc3
---
After new net architecture:
STC:
LLR: 2.95 (-2.94,2.94) <-2.50,0.50>
Total: 141752 W: 11591 L: 11617 D: 118544
Ptnml(0-2): 387, 9231, 51674, 9189, 395
https://tests.stockfishchess.org/tests/view/60a4320ace8ea25a3ef03cfd
LTC:
LLR: 2.95 (-2.94,2.94) <-2.50,0.50>
Total: 294072 W: 9825 L: 9950 D: 274297
Ptnml(0-2): 121, 8610, 129681, 8521, 103
https://tests.stockfishchess.org/tests/view/60a51b5ece8ea25a3ef03dcd
---
closes https://github.com/official-stockfish/Stockfish/pull/3490
Bench: 3752892
2021-05-21 23:41:52 -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)
|
|
|
|
{
|
Smarter time management near stop limit
This patch makes Stockfish search same depth again if > 60% of optimum time is
already used, instead of trying the next iteration. The idea is that the next
iteration will generally take about the same amount of time as has already been
used in total. When we are likely to begin the last iteration, as judged by total
time taken so far > 0.6 * optimum time, searching the last depth again instead of
increasing the depth still helps the other threads in lazy SMP and prepares better
move ordering for the next moves.
STC :
LLR: 2.95 (-2.94,2.94) {-1.00,3.00}
Total: 13436 W: 2695 L: 2558 D: 8183
Ptnml(0-2): 222, 1538, 3087, 1611, 253
https://tests.stockfishchess.org/tests/view/5e1618a761fe5f83a67dd964
LTC :
LLR: 2.94 (-2.94,2.94) {0.00,2.00}
Total: 32160 W: 4261 L: 4047 D: 23852
Ptnml(0-2): 211, 2988, 9448, 3135, 247
https://tests.stockfishchess.org/tests/view/5e162ca061fe5f83a67dd96d
The code was revised as suggested by @vondele for multithreading:
STC (8 threads):
LLR: 2.95 (-2.94,2.94) {0.00,2.00}
Total: 16640 W: 2049 L: 1885 D: 12706
Ptnml(0-2): 119, 1369, 5158, 1557, 108
https://tests.stockfishchess.org/tests/view/5e19826a2cc590e03c3c2f52
LTC (8 threads):
LLR: 2.95 (-2.94,2.94) {-1.00,3.00}
Total: 16536 W: 2758 L: 2629 D: 11149
Ptnml(0-2): 182, 1758, 4296, 1802, 224
https://tests.stockfishchess.org/tests/view/5e18b91a27dab692fcf9a140
Thanks to those discussing Stockfish lazy SMP on fishcooking which made me
try this, and to @vondele for suggestions and doing related tests.
See full discussion in the pull request thread:
https://github.com/official-stockfish/Stockfish/pull/2482
Bench: 4586187
2020-01-11 15:10:22 -07:00
|
|
|
Depth adjustedDepth = std::max(1, rootDepth - failedHighCnt - searchAgainCounter);
|
Introducing NodeType Root
We transform rootNode into constexpr by adding a new NodeType `Root`,
which causes a speed up.
Local test:
```
Build Tester: 1.4.7.0
Windows 10 (Version 10.0, Build 0, 64-bit Edition)
Intel(R) Core(TM) i7-8750H CPU @ 2.20GHz
SafeMode: No
Running In VM: No
HyperThreading Enabled: Yes
CPU Warmup: Yes
Command Line: bench
Tests per Build: 25
ANOVA: n/a
Engine# (NPS) Speedup Sp Conf. 95% S.S.
patch (920.179,4) ---> master (906.329,2) ---> 1,528% 20.336,5 Yes No
```
---------
STC:
LLR: 2.94 (-2.94,2.94) <-0.50,2.50>
Total: 98216 W: 8348 L: 8102 D: 81766
Ptnml(0-2): 295, 6357, 35549, 6621, 286
https://tests.stockfishchess.org/tests/view/60b797e2457376eb8bcaa0ab
Yellow LTC:
LLR: -2.95 (-2.94,2.94) <0.50,3.50>
Total: 76936 W: 2651 L: 2626 D: 71659
Ptnml(0-2): 29, 2233, 33916, 2264, 26
https://tests.stockfishchess.org/tests/view/60b80d6d457376eb8bcaa145
closes https://github.com/official-stockfish/Stockfish/pull/3522
No functional change
2021-06-03 10:52:39 -06:00
|
|
|
bestValue = Stockfish::search<Root>(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
|
|
|
|
2019-03-31 09:33:32 -06:00
|
|
|
failedHighCnt = 0;
|
2015-12-23 02:07:54 -07:00
|
|
|
if (mainThread)
|
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);
|
2019-03-31 09:33:32 -06: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
|
|
|
{
|
Assorted search parameter tune
STC https://tests.stockfishchess.org/tests/view/5f31219090816720665374ec
LLR: 2.96 (-2.94,2.94) {-0.50,1.50}
Total: 3376 W: 487 L: 359 D: 2530
Ptnml(0-2): 17, 253, 1042, 337, 39
LTC https://tests.stockfishchess.org/tests/view/5f3127f79081672066537502
LLR: 2.93 (-2.94,2.94) {0.25,1.75}
Total: 8360 W: 581 L: 475 D: 7304
Ptnml(0-2): 11, 407, 3238, 513, 11
closes https://github.com/official-stockfish/Stockfish/pull/2971
bench: 4733874
2020-08-10 07:38:44 -06:00
|
|
|
double fallingEval = (318 + 6 * (mainThread->bestPreviousScore - bestValue)
|
|
|
|
+ 6 * (mainThread->iterValue[iterIdx] - bestValue)) / 825.0;
|
2020-07-11 08:59:33 -06:00
|
|
|
fallingEval = std::clamp(fallingEval, 0.5, 1.5);
|
2019-01-01 06:10:26 -07:00
|
|
|
|
|
|
|
// If the bestMove is stable over several iterations, reduce time accordingly
|
Assorted search parameter tune
STC https://tests.stockfishchess.org/tests/view/5f31219090816720665374ec
LLR: 2.96 (-2.94,2.94) {-0.50,1.50}
Total: 3376 W: 487 L: 359 D: 2530
Ptnml(0-2): 17, 253, 1042, 337, 39
LTC https://tests.stockfishchess.org/tests/view/5f3127f79081672066537502
LLR: 2.93 (-2.94,2.94) {0.25,1.75}
Total: 8360 W: 581 L: 475 D: 7304
Ptnml(0-2): 11, 407, 3238, 513, 11
closes https://github.com/official-stockfish/Stockfish/pull/2971
bench: 4733874
2020-08-10 07:38:44 -06:00
|
|
|
timeReduction = lastBestMoveDepth + 9 < completedDepth ? 1.92 : 0.95;
|
|
|
|
double reduction = (1.47 + mainThread->previousTimeReduction) / (2.32 * timeReduction);
|
2019-01-01 06:10:26 -07:00
|
|
|
|
|
|
|
// Use part of the gained time from a previous stable move for the current move
|
Use average bestMoveChanges across all threads #2072
The current update only by main thread depends on the luck of
whether main thread sees any/many changes to the best move or not.
It then makes large, lumpy changes to the time to be
used (1x, 2x, 3x, etc) depending on that sample of 1.
Use the average across all threads to get a more reliable
number with a smoother distribution.
STC @ 5+0.05 th 4 :
LLR: 2.95 (-2.94,2.94) [0.50,4.50]
Total: 51899 W: 11446 L: 11029 D: 29424
http://tests.stockfishchess.org/tests/view/5ca32ff20ebc5925cf0016fb
STC @ 5+0.05 th 8 :
LLR: 2.96 (-2.94,2.94) [0.50,4.50]
Total: 13851 W: 2843 L: 2620 D: 8388
http://tests.stockfishchess.org/tests/view/5ca35ae00ebc5925cf001adb
LTC @ 20+0.2 th 8 :
LLR: 2.95 (-2.94,2.94) [0.00,3.50]
Total: 48527 W: 7941 L: 7635 D: 32951
http://tests.stockfishchess.org/tests/view/5ca37cb70ebc5925cf001cec
Further work:
Similar changes might be possible for the fallingEval and timeReduction calculations (and elsewhere?), using either the min, average or max values across all threads.
Bench 3506898
2019-04-03 01:35:55 -06:00
|
|
|
for (Thread* th : Threads)
|
2019-04-05 18:03:15 -06:00
|
|
|
{
|
Use average bestMoveChanges across all threads #2072
The current update only by main thread depends on the luck of
whether main thread sees any/many changes to the best move or not.
It then makes large, lumpy changes to the time to be
used (1x, 2x, 3x, etc) depending on that sample of 1.
Use the average across all threads to get a more reliable
number with a smoother distribution.
STC @ 5+0.05 th 4 :
LLR: 2.95 (-2.94,2.94) [0.50,4.50]
Total: 51899 W: 11446 L: 11029 D: 29424
http://tests.stockfishchess.org/tests/view/5ca32ff20ebc5925cf0016fb
STC @ 5+0.05 th 8 :
LLR: 2.96 (-2.94,2.94) [0.50,4.50]
Total: 13851 W: 2843 L: 2620 D: 8388
http://tests.stockfishchess.org/tests/view/5ca35ae00ebc5925cf001adb
LTC @ 20+0.2 th 8 :
LLR: 2.95 (-2.94,2.94) [0.00,3.50]
Total: 48527 W: 7941 L: 7635 D: 32951
http://tests.stockfishchess.org/tests/view/5ca37cb70ebc5925cf001cec
Further work:
Similar changes might be possible for the fallingEval and timeReduction calculations (and elsewhere?), using either the min, average or max values across all threads.
Bench 3506898
2019-04-03 01:35:55 -06:00
|
|
|
totBestMoveChanges += th->bestMoveChanges;
|
2019-04-05 18:03:15 -06:00
|
|
|
th->bestMoveChanges = 0;
|
|
|
|
}
|
Make extra time for bestMoveInstability dependent on rootdepth.
This change allocates more base time to moves and makes the additional time added for best move instability dependent on rootdepth.
STC 10+0.1 :
LLR: 2.94 (-2.94,2.94) <-0.50,2.50>
Total: 19432 W: 1711 L: 1553 D: 16168
Ptnml(0-2): 47, 1250, 6989, 1358, 72
https://tests.stockfishchess.org/tests/view/60b8cd41457376eb8bcaa1ad
LTC 60+0.6 :
LLR: 2.93 (-2.94,2.94) <0.50,3.50>
Total: 22480 W: 810 L: 693 D: 20977
Ptnml(0-2): 9, 603, 9902, 714, 12
https://tests.stockfishchess.org/tests/view/60b8e5bf457376eb8bcaa1e6
closes https://github.com/official-stockfish/Stockfish/pull/3526
Bench 4364128
2021-06-03 12:46:55 -06:00
|
|
|
double bestMoveInstability = 1.073 + std::max(1.0, 2.25 - 9.9 / rootDepth)
|
|
|
|
* totBestMoveChanges / Threads.size();
|
Change handling the special case of a single legal move.
Using no searching time in case of a single legal move is not beneficial from
a strength point of view, and this special case can be easily removed:
STC:
LLR: 2.93 (-2.94,2.94) {-1.25,0.25}
Total: 22472 W: 2458 L: 2357 D: 17657
Ptnml(0-2): 106, 1733, 7453, 1842, 102
https://tests.stockfishchess.org/tests/view/5f926cbc81eda81bd78cb6df
LTC:
LLR: 2.94 (-2.94,2.94) {-0.75,0.25}
Total: 37880 W: 1736 L: 1682 D: 34462
Ptnml(0-2): 22, 1392, 16057, 1448, 21
https://tests.stockfishchess.org/tests/view/5f92a26081eda81bd78cb6fe
The advantage of using the normal time management for a single legal move is that scores
reported for that move are reasonable, not searching leads to artifacts during games
(see e.g. https://tcec-chess.com/#div=sf&game=96&season=19)
The disadvantage of using normal time management of a single legal move is that thinking
times can be unnaturally long, making it 'painful to watch' in online tournaments.
This patch uses normal time management, but caps the used time to 500ms.
This should lead to reasonable scores, and be hardly perceptible.
closes https://github.com/official-stockfish/Stockfish/pull/3195
closes https://github.com/official-stockfish/Stockfish/pull/3183
variant of a patch suggested by SFisGOD
No functional change.
2020-10-22 23:39:35 -06:00
|
|
|
double totalTime = Time.optimum() * fallingEval * reduction * bestMoveInstability;
|
Minimal thinking time, even if only one rootMove.
without search, the eval returned can be misleading (e.g. mate instead of draw),
leading to wrong adjudication. With a minimal search, this is avoided.
This patch leads to 1ms long searches if there is only 1 move,
similar patches all indicate a small Elo gain.
Fixes https://github.com/official-stockfish/Stockfish/issues/2707
Passed non-regression STC:
LLR: 2.93 (-2.94,2.94) {-1.50,0.50}
Total: 22312 W: 4350 L: 4204 D: 13758
Ptnml(0-2): 323, 2488, 5437, 2536, 372
https://tests.stockfishchess.org/tests/view/5ed562b0f29b40b0fc95a7d0
closes https://github.com/official-stockfish/Stockfish/pull/2709
Bench: 4733799
2020-05-31 08:51:38 -06:00
|
|
|
|
Change handling the special case of a single legal move.
Using no searching time in case of a single legal move is not beneficial from
a strength point of view, and this special case can be easily removed:
STC:
LLR: 2.93 (-2.94,2.94) {-1.25,0.25}
Total: 22472 W: 2458 L: 2357 D: 17657
Ptnml(0-2): 106, 1733, 7453, 1842, 102
https://tests.stockfishchess.org/tests/view/5f926cbc81eda81bd78cb6df
LTC:
LLR: 2.94 (-2.94,2.94) {-0.75,0.25}
Total: 37880 W: 1736 L: 1682 D: 34462
Ptnml(0-2): 22, 1392, 16057, 1448, 21
https://tests.stockfishchess.org/tests/view/5f92a26081eda81bd78cb6fe
The advantage of using the normal time management for a single legal move is that scores
reported for that move are reasonable, not searching leads to artifacts during games
(see e.g. https://tcec-chess.com/#div=sf&game=96&season=19)
The disadvantage of using normal time management of a single legal move is that thinking
times can be unnaturally long, making it 'painful to watch' in online tournaments.
This patch uses normal time management, but caps the used time to 500ms.
This should lead to reasonable scores, and be hardly perceptible.
closes https://github.com/official-stockfish/Stockfish/pull/3195
closes https://github.com/official-stockfish/Stockfish/pull/3183
variant of a patch suggested by SFisGOD
No functional change.
2020-10-22 23:39:35 -06:00
|
|
|
// Cap used time in case of a single legal move for a better viewer experience in tournaments
|
|
|
|
// yielding correct scores and sufficiently fast moves.
|
|
|
|
if (rootMoves.size() == 1)
|
|
|
|
totalTime = std::min(500.0, totalTime);
|
|
|
|
|
|
|
|
// Stop the search if we have exceeded the totalTime
|
Minimal thinking time, even if only one rootMove.
without search, the eval returned can be misleading (e.g. mate instead of draw),
leading to wrong adjudication. With a minimal search, this is avoided.
This patch leads to 1ms long searches if there is only 1 move,
similar patches all indicate a small Elo gain.
Fixes https://github.com/official-stockfish/Stockfish/issues/2707
Passed non-regression STC:
LLR: 2.93 (-2.94,2.94) {-1.50,0.50}
Total: 22312 W: 4350 L: 4204 D: 13758
Ptnml(0-2): 323, 2488, 5437, 2536, 372
https://tests.stockfishchess.org/tests/view/5ed562b0f29b40b0fc95a7d0
closes https://github.com/official-stockfish/Stockfish/pull/2709
Bench: 4733799
2020-05-31 08:51:38 -06:00
|
|
|
if (Time.elapsed() > totalTime)
|
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
|
|
|
}
|
Smarter time management near stop limit
This patch makes Stockfish search same depth again if > 60% of optimum time is
already used, instead of trying the next iteration. The idea is that the next
iteration will generally take about the same amount of time as has already been
used in total. When we are likely to begin the last iteration, as judged by total
time taken so far > 0.6 * optimum time, searching the last depth again instead of
increasing the depth still helps the other threads in lazy SMP and prepares better
move ordering for the next moves.
STC :
LLR: 2.95 (-2.94,2.94) {-1.00,3.00}
Total: 13436 W: 2695 L: 2558 D: 8183
Ptnml(0-2): 222, 1538, 3087, 1611, 253
https://tests.stockfishchess.org/tests/view/5e1618a761fe5f83a67dd964
LTC :
LLR: 2.94 (-2.94,2.94) {0.00,2.00}
Total: 32160 W: 4261 L: 4047 D: 23852
Ptnml(0-2): 211, 2988, 9448, 3135, 247
https://tests.stockfishchess.org/tests/view/5e162ca061fe5f83a67dd96d
The code was revised as suggested by @vondele for multithreading:
STC (8 threads):
LLR: 2.95 (-2.94,2.94) {0.00,2.00}
Total: 16640 W: 2049 L: 1885 D: 12706
Ptnml(0-2): 119, 1369, 5158, 1557, 108
https://tests.stockfishchess.org/tests/view/5e19826a2cc590e03c3c2f52
LTC (8 threads):
LLR: 2.95 (-2.94,2.94) {-1.00,3.00}
Total: 16536 W: 2758 L: 2629 D: 11149
Ptnml(0-2): 182, 1758, 4296, 1802, 224
https://tests.stockfishchess.org/tests/view/5e18b91a27dab692fcf9a140
Thanks to those discussing Stockfish lazy SMP on fishcooking which made me
try this, and to @vondele for suggestions and doing related tests.
See full discussion in the pull request thread:
https://github.com/official-stockfish/Stockfish/pull/2482
Bench: 4586187
2020-01-11 15:10:22 -07:00
|
|
|
else if ( Threads.increaseDepth
|
2020-01-13 02:05:49 -07:00
|
|
|
&& !mainThread->ponder
|
Assorted search parameter tune
STC https://tests.stockfishchess.org/tests/view/5f31219090816720665374ec
LLR: 2.96 (-2.94,2.94) {-0.50,1.50}
Total: 3376 W: 487 L: 359 D: 2530
Ptnml(0-2): 17, 253, 1042, 337, 39
LTC https://tests.stockfishchess.org/tests/view/5f3127f79081672066537502
LLR: 2.93 (-2.94,2.94) {0.25,1.75}
Total: 8360 W: 581 L: 475 D: 7304
Ptnml(0-2): 11, 407, 3238, 513, 11
closes https://github.com/official-stockfish/Stockfish/pull/2971
bench: 4733874
2020-08-10 07:38:44 -06:00
|
|
|
&& Time.elapsed() > totalTime * 0.58)
|
Smarter time management near stop limit
This patch makes Stockfish search same depth again if > 60% of optimum time is
already used, instead of trying the next iteration. The idea is that the next
iteration will generally take about the same amount of time as has already been
used in total. When we are likely to begin the last iteration, as judged by total
time taken so far > 0.6 * optimum time, searching the last depth again instead of
increasing the depth still helps the other threads in lazy SMP and prepares better
move ordering for the next moves.
STC :
LLR: 2.95 (-2.94,2.94) {-1.00,3.00}
Total: 13436 W: 2695 L: 2558 D: 8183
Ptnml(0-2): 222, 1538, 3087, 1611, 253
https://tests.stockfishchess.org/tests/view/5e1618a761fe5f83a67dd964
LTC :
LLR: 2.94 (-2.94,2.94) {0.00,2.00}
Total: 32160 W: 4261 L: 4047 D: 23852
Ptnml(0-2): 211, 2988, 9448, 3135, 247
https://tests.stockfishchess.org/tests/view/5e162ca061fe5f83a67dd96d
The code was revised as suggested by @vondele for multithreading:
STC (8 threads):
LLR: 2.95 (-2.94,2.94) {0.00,2.00}
Total: 16640 W: 2049 L: 1885 D: 12706
Ptnml(0-2): 119, 1369, 5158, 1557, 108
https://tests.stockfishchess.org/tests/view/5e19826a2cc590e03c3c2f52
LTC (8 threads):
LLR: 2.95 (-2.94,2.94) {-1.00,3.00}
Total: 16536 W: 2758 L: 2629 D: 11149
Ptnml(0-2): 182, 1758, 4296, 1802, 224
https://tests.stockfishchess.org/tests/view/5e18b91a27dab692fcf9a140
Thanks to those discussing Stockfish lazy SMP on fishcooking which made me
try this, and to @vondele for suggestions and doing related tests.
See full discussion in the pull request thread:
https://github.com/official-stockfish/Stockfish/pull/2482
Bench: 4586187
2020-01-11 15:10:22 -07:00
|
|
|
Threads.increaseDepth = false;
|
|
|
|
else
|
|
|
|
Threads.increaseDepth = true;
|
2019-01-01 06:10:26 -07:00
|
|
|
}
|
2019-12-08 04:06:19 -07:00
|
|
|
|
|
|
|
mainThread->iterValue[iterIdx] = bestValue;
|
|
|
|
iterIdx = (iterIdx + 1) & 3;
|
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
|
|
|
|
Introducing NodeType Root
We transform rootNode into constexpr by adding a new NodeType `Root`,
which causes a speed up.
Local test:
```
Build Tester: 1.4.7.0
Windows 10 (Version 10.0, Build 0, 64-bit Edition)
Intel(R) Core(TM) i7-8750H CPU @ 2.20GHz
SafeMode: No
Running In VM: No
HyperThreading Enabled: Yes
CPU Warmup: Yes
Command Line: bench
Tests per Build: 25
ANOVA: n/a
Engine# (NPS) Speedup Sp Conf. 95% S.S.
patch (920.179,4) ---> master (906.329,2) ---> 1,528% 20.336,5 Yes No
```
---------
STC:
LLR: 2.94 (-2.94,2.94) <-0.50,2.50>
Total: 98216 W: 8348 L: 8102 D: 81766
Ptnml(0-2): 295, 6357, 35549, 6621, 286
https://tests.stockfishchess.org/tests/view/60b797e2457376eb8bcaa0ab
Yellow LTC:
LLR: -2.95 (-2.94,2.94) <0.50,3.50>
Total: 76936 W: 2651 L: 2626 D: 71659
Ptnml(0-2): 29, 2233, 33916, 2264, 26
https://tests.stockfishchess.org/tests/view/60b80d6d457376eb8bcaa145
closes https://github.com/official-stockfish/Stockfish/pull/3522
No functional change
2021-06-03 10:52:39 -06:00
|
|
|
template <NodeType nodeType>
|
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
|
|
|
|
Detect search explosions
This patch detects some search explosions (due to double extensions in
search.cpp) which can happen in some pathological positions, and takes
measures to ensure progress in search even for these pathological situations.
While a small number of double extensions can be useful during search
(for example to resolve a tactical sequence), a sustained regime of
double extensions leads to search explosion and a non-finishing search.
See the discussion in https://github.com/official-stockfish/Stockfish/pull/3544
and the issue https://github.com/official-stockfish/Stockfish/issues/3532 .
The implemented algorithm is the following:
a) at each node during search, store the current depth in the stack.
Double extensions are by definition levels of the stack where the
depth at ply N is strictly higher than depth at ply N-1.
b) during search, calculate for each thread a running average of the
number of double extensions in the last 4096 visited nodes.
c) if one thread has more than 2% of double extensions for a sustained
period of time (6 millions consecutive nodes, or about 4 seconds on
my iMac), we decide that this thread is in an explosion state and
we calm down this thread by preventing it to do any double extension
for the next 6 millions nodes.
To calculate the running averages, we also introduced a auxiliary class
generalizing the computations of ttHitAverage variable we already had in
code. The implementation uses an exponential moving average of period 4096
and resolution 1/1024, and all computations are done with integers for
efficiency.
-----------
Example where the patch solves a search explosion:
```
./stockfish
ucinewgame
position fen 8/Pk6/8/1p6/8/P1K5/8/6B1 w - - 37 130
go infinite
```
This algorithm does not affect search in normal, non-pathological positions.
We verified, for instance, that the usual bench is unchanged up to depth 20
at least, and that the node numbers are unchanged for a search of the starting
position at depth 32.
-------------
See https://github.com/official-stockfish/Stockfish/pull/3714
Bench: 5575265
2021-09-23 15:19:06 -06:00
|
|
|
Thread* thisThread = pos.this_thread();
|
|
|
|
|
|
|
|
// Step 0. Limit search explosion
|
|
|
|
if ( ss->ply > 10
|
|
|
|
&& search_explosion(thisThread) == MUST_CALM_DOWN
|
|
|
|
&& depth > (ss-1)->depth)
|
|
|
|
depth = (ss-1)->depth;
|
|
|
|
|
Introducing NodeType Root
We transform rootNode into constexpr by adding a new NodeType `Root`,
which causes a speed up.
Local test:
```
Build Tester: 1.4.7.0
Windows 10 (Version 10.0, Build 0, 64-bit Edition)
Intel(R) Core(TM) i7-8750H CPU @ 2.20GHz
SafeMode: No
Running In VM: No
HyperThreading Enabled: Yes
CPU Warmup: Yes
Command Line: bench
Tests per Build: 25
ANOVA: n/a
Engine# (NPS) Speedup Sp Conf. 95% S.S.
patch (920.179,4) ---> master (906.329,2) ---> 1,528% 20.336,5 Yes No
```
---------
STC:
LLR: 2.94 (-2.94,2.94) <-0.50,2.50>
Total: 98216 W: 8348 L: 8102 D: 81766
Ptnml(0-2): 295, 6357, 35549, 6621, 286
https://tests.stockfishchess.org/tests/view/60b797e2457376eb8bcaa0ab
Yellow LTC:
LLR: -2.95 (-2.94,2.94) <0.50,3.50>
Total: 76936 W: 2651 L: 2626 D: 71659
Ptnml(0-2): 29, 2233, 33916, 2264, 26
https://tests.stockfishchess.org/tests/view/60b80d6d457376eb8bcaa145
closes https://github.com/official-stockfish/Stockfish/pull/3522
No functional change
2021-06-03 10:52:39 -06:00
|
|
|
constexpr bool PvNode = nodeType != NonPV;
|
|
|
|
constexpr bool rootNode = nodeType == Root;
|
Reduce big time spikes by reducing PV re-searches.
Save time by reducing PV re-searches above original depth. Instead use 5% extra time on every move.
STC 10+0.1 th 1 :
LLR: 2.93 (-2.94,2.94) {-0.25,1.25}
Total: 90688 W: 9702 L: 9436 D: 71550
Ptnml(0-2): 408, 7252, 29792, 7450, 442
https://tests.stockfishchess.org/tests/view/5f8df807bacb75a4f9a47223
LTC 60+0.6 th 1 :
LLR: 2.97 (-2.94,2.94) {0.25,1.25}
Total: 97856 W: 4602 L: 4303 D: 88951
Ptnml(0-2): 53, 3757, 41057, 3960, 101
https://tests.stockfishchess.org/tests/view/5f8ec4872c92c7fe3a8c602d
closes https://github.com/official-stockfish/Stockfish/pull/3192
Bench 3943959
2020-10-21 07:52:13 -06:00
|
|
|
const Depth maxNextDepth = rootNode ? depth : depth + 1;
|
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.
|
Introducing NodeType Root
We transform rootNode into constexpr by adding a new NodeType `Root`,
which causes a speed up.
Local test:
```
Build Tester: 1.4.7.0
Windows 10 (Version 10.0, Build 0, 64-bit Edition)
Intel(R) Core(TM) i7-8750H CPU @ 2.20GHz
SafeMode: No
Running In VM: No
HyperThreading Enabled: Yes
CPU Warmup: Yes
Command Line: bench
Tests per Build: 25
ANOVA: n/a
Engine# (NPS) Speedup Sp Conf. 95% S.S.
patch (920.179,4) ---> master (906.329,2) ---> 1,528% 20.336,5 Yes No
```
---------
STC:
LLR: 2.94 (-2.94,2.94) <-0.50,2.50>
Total: 98216 W: 8348 L: 8102 D: 81766
Ptnml(0-2): 295, 6357, 35549, 6621, 286
https://tests.stockfishchess.org/tests/view/60b797e2457376eb8bcaa0ab
Yellow LTC:
LLR: -2.95 (-2.94,2.94) <0.50,3.50>
Total: 76936 W: 2651 L: 2626 D: 71659
Ptnml(0-2): 29, 2233, 33916, 2264, 26
https://tests.stockfishchess.org/tests/view/60b80d6d457376eb8bcaa145
closes https://github.com/official-stockfish/Stockfish/pull/3522
No functional change
2021-06-03 10:52:39 -06:00
|
|
|
if ( !rootNode
|
|
|
|
&& pos.rule50_count() >= 3
|
2018-06-05 02:54:51 -06:00
|
|
|
&& alpha < VALUE_DRAW
|
|
|
|
&& pos.has_game_cycle(ss->ply))
|
|
|
|
{
|
2019-09-27 11:25:22 -06:00
|
|
|
alpha = value_draw(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
|
2019-09-28 14:27:23 -06:00
|
|
|
if (depth <= 0)
|
Introducing NodeType Root
We transform rootNode into constexpr by adding a new NodeType `Root`,
which causes a speed up.
Local test:
```
Build Tester: 1.4.7.0
Windows 10 (Version 10.0, Build 0, 64-bit Edition)
Intel(R) Core(TM) i7-8750H CPU @ 2.20GHz
SafeMode: No
Running In VM: No
HyperThreading Enabled: Yes
CPU Warmup: Yes
Command Line: bench
Tests per Build: 25
ANOVA: n/a
Engine# (NPS) Speedup Sp Conf. 95% S.S.
patch (920.179,4) ---> master (906.329,2) ---> 1,528% 20.336,5 Yes No
```
---------
STC:
LLR: 2.94 (-2.94,2.94) <-0.50,2.50>
Total: 98216 W: 8348 L: 8102 D: 81766
Ptnml(0-2): 295, 6357, 35549, 6621, 286
https://tests.stockfishchess.org/tests/view/60b797e2457376eb8bcaa0ab
Yellow LTC:
LLR: -2.95 (-2.94,2.94) <0.50,3.50>
Total: 76936 W: 2651 L: 2626 D: 71659
Ptnml(0-2): 29, 2233, 33916, 2264, 26
https://tests.stockfishchess.org/tests/view/60b80d6d457376eb8bcaa145
closes https://github.com/official-stockfish/Stockfish/pull/3522
No functional change
2021-06-03 10:52:39 -06:00
|
|
|
return qsearch<PvNode ? PV : NonPV>(pos, ss, alpha, beta);
|
2018-06-05 02:54:51 -06:00
|
|
|
|
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));
|
2019-09-28 14:27:23 -06:00
|
|
|
assert(0 < depth && depth < MAX_PLY);
|
2016-06-23 08:14:51 -06:00
|
|
|
assert(!(PvNode && cutNode));
|
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;
|
2021-04-19 11:50:19 -06:00
|
|
|
ASSERT_ALIGNED(&st, Eval::NNUE::CacheLineSize);
|
2020-11-03 03:23:35 -07:00
|
|
|
|
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;
|
2020-07-18 07:30:00 -06:00
|
|
|
Value bestValue, value, ttValue, eval, maxValue, probCutBeta;
|
Remove formerPV variable.
STC:
LLR: 2.94 (-2.94,2.94) <-2.50,0.50>
Total: 75672 W: 6546 L: 6496 D: 62630
Ptnml(0-2): 238, 5274, 26761, 5326, 237
https://tests.stockfishchess.org/tests/view/60b349c0ec0c03148cbed055
LTC:
LLR: 2.98 (-2.94,2.94) <-2.50,0.50>
Total: 137816 W: 4676 L: 4689 D: 128451
Ptnml(0-2): 52, 4237, 60354, 4202, 63
https://tests.stockfishchess.org/tests/view/60b38970ec0c03148cbed075
closes https://github.com/official-stockfish/Stockfish/pull/3515
Bench: 4892288
2021-05-31 12:26:05 -06:00
|
|
|
bool givesCheck, improving, didLMR, priorCapture;
|
Singular quiet LMR
If ttMove is a capture and had a singular extension, it is probably the best move.
No need to make a decrease of LMR on other moves.
STC
LLR: 2.96 (-2.94,2.94) {-0.50,1.50}
Total: 41968 W: 8170 L: 7918 D: 25880
Ptnml(0-2): 733, 4770, 9726, 5022, 733
https://tests.stockfishchess.org/tests/view/5ed6b666f29b40b0fc95a884
LTC
LLR: 2.95 (-2.94,2.94) {0.25,1.75}
Total: 71376 W: 9200 L: 8827 D: 53349
Ptnml(0-2): 486, 6544, 21342, 6743, 573
https://tests.stockfishchess.org/tests/view/5ed7578bf29b40b0fc95a8c9
closes https://github.com/official-stockfish/Stockfish/pull/2713
Bench: 4733799
2020-06-02 14:27:11 -06:00
|
|
|
bool captureOrPromotion, doFullDepthSearch, moveCountPruning,
|
Remove noLMRExtension flag
This simplification patch removes the noLMRExtension flag. It was introduced in June
(see following link for that commit), but does not seem to be necessary anymore.
Link: https://github.com/official-stockfish/Stockfish/commit/e1f181ee643dcaa92c606b74b3abd23dede136cd
STC:
LLR: 2.94 (-2.94,2.94) <-2.50,0.50>
Total: 21200 W: 5369 L: 5228 D: 10603
Ptnml(0-2): 67, 2355, 5616, 2494, 68
https://tests.stockfishchess.org/tests/view/616c03d299b580bf37797dcb
LTC:
LLR: 2.94 (-2.94,2.94) <-2.50,0.50>
Total: 37536 W: 9387 L: 9278 D: 18871
Ptnml(0-2): 23, 3988, 10643, 4085, 29
https://tests.stockfishchess.org/tests/view/616c10f499b580bf37797ddd
closes https://github.com/official-stockfish/Stockfish/pull/3743
Bench: 4792969
2021-10-17 05:06:33 -06:00
|
|
|
ttCapture, singularQuietLMR;
|
2019-10-06 01:57:20 -06:00
|
|
|
Piece movedPiece;
|
Smooth improving
Smooth dependency on improvement margin in null move search.
STC
LLR: 2.93 (-2.94,2.94) <-0.50,2.50>
Total: 17384 W: 4468 L: 4272 D: 8644
Ptnml(0-2): 42, 1919, 4592, 2079, 60
https://tests.stockfishchess.org/tests/view/61689b8a1e5f6627cc1c0fdc
LTC
LLR: 2.94 (-2.94,2.94) <0.50,3.50>
Total: 45648 W: 11525 L: 11243 D: 22880
Ptnml(0-2): 26, 4731, 13036, 4997, 34
https://tests.stockfishchess.org/tests/view/6168a12c1e5f6627cc1c0fe3
It would be interesting to test if the other pruning/reduction heuristics
in master which are using the improving variable (ie the sign of improvement)
could benefit from a smooth function of the improvement value (or maybe a
Relu of the improvement value).
closes https://github.com/official-stockfish/Stockfish/pull/3740
Bench: 4916775
2021-10-14 14:26:42 -06:00
|
|
|
int moveCount, captureCount, quietCount, bestMoveCount, improvement;
|
2011-01-16 04:02:32 -07:00
|
|
|
|
2012-10-01 01:33:13 -06:00
|
|
|
// Step 1. Initialize node
|
2021-03-19 12:43:25 -06:00
|
|
|
ss->inCheck = pos.checkers();
|
|
|
|
priorCapture = pos.captured_piece();
|
|
|
|
Color us = pos.side_to_move();
|
Reduce more if multiple moves exceed alpha
Idea of this patch is the following: in case we already have four moves that
exceeded alpha in the current node, the probability of finding fifth should
be reasonably low. Note that four is completely arbitrary - there could and
probably should be some tweaks, both in tweaking best move count threshold
for more reductions and tweaking how they work - for example making more
reductions with best move count linearly.
passed STC:
https://tests.stockfishchess.org/tests/view/615f614783dd501a05b0aee2
LLR: 2.94 (-2.94,2.94) <-0.50,2.50>
Total: 141816 W: 36056 L: 35686 D: 70074
Ptnml(0-2): 499, 15131, 39273, 15511, 494
passed LTC:
https://tests.stockfishchess.org/tests/view/615fdff683dd501a05b0af35
LLR: 2.94 (-2.94,2.94) <0.50,3.50>
Total: 68536 W: 17221 L: 16891 D: 34424
Ptnml(0-2): 38, 6573, 20725, 6885, 47
closes https://github.com/official-stockfish/Stockfish/pull/3736
Bench: 6131513
2021-10-08 17:15:43 -06:00
|
|
|
moveCount = bestMoveCount = captureCount = quietCount = ss->moveCount = 0;
|
2021-03-19 12:43:25 -06:00
|
|
|
bestValue = -VALUE_INFINITE;
|
|
|
|
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)
|
continuation histories when in check
If in check, don't write to continuation histories ss-4, ss-6.
Adding inCheck to the stack was needed, and might be useful for
future patches.
Passed STC:
https://tests.stockfishchess.org/tests/view/5e9ee24acaaff5d60a50b812
LLR: 2.94 (-2.94,2.94) {-0.50,1.50}
Total: 61774 W: 11725 L: 11449 D: 38600
Ptnml(0-2): 971, 7211, 14322, 7337, 1046
Passed LTC:
https://tests.stockfishchess.org/tests/view/5e9eecb7caaff5d60a50b831
LLR: 2.94 (-2.94,2.94) {0.25,1.75}
Total: 250822 W: 32067 L: 31179 D: 187576
Ptnml(0-2): 1745, 23126, 74824, 23928, 1788
closes https://github.com/official-stockfish/Stockfish/pull/2645
bench: 4808463
2020-04-21 12:55:41 -06:00
|
|
|
return (ss->ply >= MAX_PLY && !ss->inCheck) ? evaluate(pos)
|
2020-06-24 14:19:58 -06:00
|
|
|
: value_draw(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);
|
|
|
|
|
Limit double extensions
Double extensions can lead to search explosions, for specific positions.
Currently, however, these double extensions are worth about 10Elo and cannot
be removed. This patch instead limits the number of double extensions given
to a maximum of 3.
This fixes https://github.com/official-stockfish/Stockfish/issues/3532
where the following testcase was shown to be problematic:
```
uci
setoption name Hash value 4
setoption name Contempt value 0
ucinewgame
position fen 8/Pk6/8/1p6/8/P1K5/8/6B1 w - - 37 130
go depth 20
```
passed STC:
https://tests.stockfishchess.org/tests/view/60c13161457376eb8bcaaa0f
LLR: 2.95 (-2.94,2.94) <-2.50,0.50>
Total: 73256 W: 6114 L: 6062 D: 61080
Ptnml(0-2): 222, 4912, 26306, 4968, 220
passed LTC:
https://tests.stockfishchess.org/tests/view/60c196fb457376eb8bcaaa6b
LLR: 2.94 (-2.94,2.94) <-2.50,0.50>
Total: 166440 W: 5559 L: 5594 D: 155287
Ptnml(0-2): 106, 4921, 73197, 4894, 102
closes https://github.com/official-stockfish/Stockfish/pull/3544
Bench: 5067605
2021-06-09 15:23:13 -06:00
|
|
|
(ss+1)->ttPv = false;
|
2019-04-24 11:51:57 -06:00
|
|
|
(ss+1)->excludedMove = bestMove = MOVE_NONE;
|
Limit double extensions
Double extensions can lead to search explosions, for specific positions.
Currently, however, these double extensions are worth about 10Elo and cannot
be removed. This patch instead limits the number of double extensions given
to a maximum of 3.
This fixes https://github.com/official-stockfish/Stockfish/issues/3532
where the following testcase was shown to be problematic:
```
uci
setoption name Hash value 4
setoption name Contempt value 0
ucinewgame
position fen 8/Pk6/8/1p6/8/P1K5/8/6B1 w - - 37 130
go depth 20
```
passed STC:
https://tests.stockfishchess.org/tests/view/60c13161457376eb8bcaaa0f
LLR: 2.95 (-2.94,2.94) <-2.50,0.50>
Total: 73256 W: 6114 L: 6062 D: 61080
Ptnml(0-2): 222, 4912, 26306, 4968, 220
passed LTC:
https://tests.stockfishchess.org/tests/view/60c196fb457376eb8bcaaa6b
LLR: 2.94 (-2.94,2.94) <-2.50,0.50>
Total: 166440 W: 5559 L: 5594 D: 155287
Ptnml(0-2): 106, 4921, 73197, 4894, 102
closes https://github.com/official-stockfish/Stockfish/pull/3544
Bench: 5067605
2021-06-09 15:23:13 -06:00
|
|
|
(ss+2)->killers[0] = (ss+2)->killers[1] = MOVE_NONE;
|
|
|
|
ss->doubleExtensions = (ss-1)->doubleExtensions;
|
Detect search explosions
This patch detects some search explosions (due to double extensions in
search.cpp) which can happen in some pathological positions, and takes
measures to ensure progress in search even for these pathological situations.
While a small number of double extensions can be useful during search
(for example to resolve a tactical sequence), a sustained regime of
double extensions leads to search explosion and a non-finishing search.
See the discussion in https://github.com/official-stockfish/Stockfish/pull/3544
and the issue https://github.com/official-stockfish/Stockfish/issues/3532 .
The implemented algorithm is the following:
a) at each node during search, store the current depth in the stack.
Double extensions are by definition levels of the stack where the
depth at ply N is strictly higher than depth at ply N-1.
b) during search, calculate for each thread a running average of the
number of double extensions in the last 4096 visited nodes.
c) if one thread has more than 2% of double extensions for a sustained
period of time (6 millions consecutive nodes, or about 4 seconds on
my iMac), we decide that this thread is in an explosion state and
we calm down this thread by preventing it to do any double extension
for the next 6 millions nodes.
To calculate the running averages, we also introduced a auxiliary class
generalizing the computations of ttHitAverage variable we already had in
code. The implementation uses an exponential moving average of period 4096
and resolution 1/1024, and all computations are done with integers for
efficiency.
-----------
Example where the patch solves a search explosion:
```
./stockfish
ucinewgame
position fen 8/Pk6/8/1p6/8/P1K5/8/6B1 w - - 37 130
go infinite
```
This algorithm does not affect search in normal, non-pathological positions.
We verified, for instance, that the usual bench is unchanged up to depth 20
at least, and that the node numbers are unchanged for a search of the starting
position at depth 32.
-------------
See https://github.com/official-stockfish/Stockfish/pull/3714
Bench: 5575265
2021-09-23 15:19:06 -06:00
|
|
|
ss->depth = depth;
|
Limit double extensions
Double extensions can lead to search explosions, for specific positions.
Currently, however, these double extensions are worth about 10Elo and cannot
be removed. This patch instead limits the number of double extensions given
to a maximum of 3.
This fixes https://github.com/official-stockfish/Stockfish/issues/3532
where the following testcase was shown to be problematic:
```
uci
setoption name Hash value 4
setoption name Contempt value 0
ucinewgame
position fen 8/Pk6/8/1p6/8/P1K5/8/6B1 w - - 37 130
go depth 20
```
passed STC:
https://tests.stockfishchess.org/tests/view/60c13161457376eb8bcaaa0f
LLR: 2.95 (-2.94,2.94) <-2.50,0.50>
Total: 73256 W: 6114 L: 6062 D: 61080
Ptnml(0-2): 222, 4912, 26306, 4968, 220
passed LTC:
https://tests.stockfishchess.org/tests/view/60c196fb457376eb8bcaaa6b
LLR: 2.94 (-2.94,2.94) <-2.50,0.50>
Total: 166440 W: 5559 L: 5594 D: 155287
Ptnml(0-2): 106, 4921, 73197, 4894, 102
closes https://github.com/official-stockfish/Stockfish/pull/3544
Bench: 5067605
2021-06-09 15:23:13 -06: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
|
|
|
|
Detect search explosions
This patch detects some search explosions (due to double extensions in
search.cpp) which can happen in some pathological positions, and takes
measures to ensure progress in search even for these pathological situations.
While a small number of double extensions can be useful during search
(for example to resolve a tactical sequence), a sustained regime of
double extensions leads to search explosion and a non-finishing search.
See the discussion in https://github.com/official-stockfish/Stockfish/pull/3544
and the issue https://github.com/official-stockfish/Stockfish/issues/3532 .
The implemented algorithm is the following:
a) at each node during search, store the current depth in the stack.
Double extensions are by definition levels of the stack where the
depth at ply N is strictly higher than depth at ply N-1.
b) during search, calculate for each thread a running average of the
number of double extensions in the last 4096 visited nodes.
c) if one thread has more than 2% of double extensions for a sustained
period of time (6 millions consecutive nodes, or about 4 seconds on
my iMac), we decide that this thread is in an explosion state and
we calm down this thread by preventing it to do any double extension
for the next 6 millions nodes.
To calculate the running averages, we also introduced a auxiliary class
generalizing the computations of ttHitAverage variable we already had in
code. The implementation uses an exponential moving average of period 4096
and resolution 1/1024, and all computations are done with integers for
efficiency.
-----------
Example where the patch solves a search explosion:
```
./stockfish
ucinewgame
position fen 8/Pk6/8/1p6/8/P1K5/8/6B1 w - - 37 130
go infinite
```
This algorithm does not affect search in normal, non-pathological positions.
We verified, for instance, that the usual bench is unchanged up to depth 20
at least, and that the node numbers are unchanged for a search of the starting
position at depth 32.
-------------
See https://github.com/official-stockfish/Stockfish/pull/3714
Bench: 5575265
2021-09-23 15:19:06 -06:00
|
|
|
// Update the running average statistics for double extensions
|
|
|
|
thisThread->doubleExtensionAverage[us].update(ss->depth > (ss-1)->depth);
|
|
|
|
|
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.
|
2020-09-13 20:28:32 -06:00
|
|
|
if (!rootNode)
|
2019-08-14 14:15:41 -06:00
|
|
|
(ss+2)->statScore = 0;
|
2018-02-27 10:38:08 -07:00
|
|
|
|
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;
|
Fix fragile code to use proper random 64 bit keys.
This fixes an old issue where we want to make a position unique but only
change a small number of bits in the key instead of all 64 of them randomly.
This is fragile and can lead to non uniqueness issues in the TT.
Key make_key(uint64_t seed) takes any integer and produces a unique random 64 bit key.
It is computationally efficient and is based on a congruential pseudo random number
generator using well tested constants by Donald Knuth
(see https://en.wikipedia.org/wiki/Linear_congruential_generator)
STC https://tests.stockfishchess.org/tests/view/5ef6c78f761b685b4c724bb6
LLR: 2.95 (-2.94,2.94) {-1.50,0.50}
Total: 154320 W: 29343 L: 29376 D: 95601
Ptnml(0-2): 2543, 18170, 35891, 17889, 2667
LTC https://tests.stockfishchess.org/tests/view/5ef7d1a9020eec13834a940e
LLR: 2.95 (-2.94,2.94) {-1.50,0.50}
Total: 53488 W: 6629 L: 6584 D: 40275
Ptnml(0-2): 372, 4878, 16183, 4955, 356
closes https://github.com/official-stockfish/Stockfish/pull/2773
bench: 4626776
2020-06-26 18:26:46 -06:00
|
|
|
posKey = excludedMove == MOVE_NONE ? pos.key() : pos.key() ^ make_key(excludedMove);
|
Adjust penalty on refuted early quiet moves
This patch changes how previous early moves are penalized in case
search finds a best move. Here, the first quiet move that was not
a transposition table move is penalized.
passed STC
https://tests.stockfishchess.org/tests/view/5f51d839ba100690c5cc5f69
LLR: 2.94 (-2.94,2.94) {-0.25,1.25}
Total: 10088 W: 1150 L: 997 D: 7941
Ptnml(0-2): 41, 772, 3278, 899, 54
passed LTC
https://tests.stockfishchess.org/tests/view/5f51e435ba100690c5cc5f76
LLR: 2.93 (-2.94,2.94) {0.25,1.25}
Total: 30808 W: 1564 L: 1405 D: 27839
Ptnml(0-2): 19, 1245, 12717, 1404, 19
closes https://github.com/official-stockfish/Stockfish/pull/3106
bench 3983758
2020-09-04 06:53:59 -06:00
|
|
|
tte = TT.probe(posKey, ss->ttHit);
|
|
|
|
ttValue = ss->ttHit ? value_from_tt(tte->value(), ss->ply, pos.rule50_count()) : VALUE_NONE;
|
2018-06-02 09:41:37 -06:00
|
|
|
ttMove = rootNode ? thisThread->rootMoves[thisThread->pvIdx].pv[0]
|
Adjust penalty on refuted early quiet moves
This patch changes how previous early moves are penalized in case
search finds a best move. Here, the first quiet move that was not
a transposition table move is penalized.
passed STC
https://tests.stockfishchess.org/tests/view/5f51d839ba100690c5cc5f69
LLR: 2.94 (-2.94,2.94) {-0.25,1.25}
Total: 10088 W: 1150 L: 997 D: 7941
Ptnml(0-2): 41, 772, 3278, 899, 54
passed LTC
https://tests.stockfishchess.org/tests/view/5f51e435ba100690c5cc5f76
LLR: 2.93 (-2.94,2.94) {0.25,1.25}
Total: 30808 W: 1564 L: 1405 D: 27839
Ptnml(0-2): 19, 1245, 12717, 1404, 19
closes https://github.com/official-stockfish/Stockfish/pull/3106
bench 3983758
2020-09-04 06:53:59 -06:00
|
|
|
: ss->ttHit ? tte->move() : MOVE_NONE;
|
2021-10-06 11:16:02 -06:00
|
|
|
ttCapture = ttMove && pos.capture_or_promotion(ttMove);
|
Add / remove leaves from search tree ttPv
add if previous leaf is in search tree and we didn't find a counter move
else remove the position if the leaf is the last one in search tree.
STC : https://tests.stockfishchess.org/tests/view/5f49203c3def640786115314
LLR: 2.95 (-2.94,2.94) {-0.25,1.25}
Total: 29968 W: 3381 L: 3195 D: 23392
Ptnml(0-2): 146, 2432, 9671, 2560, 175
LTC : https://tests.stockfishchess.org/tests/view/5f494bea3def640786115336
LLR: 2.96 (-2.94,2.94) {0.25,1.25}
Total: 84952 W: 4619 L: 4333 D: 76000
Ptnml(0-2): 86, 3765, 34481, 4065, 79
closes https://github.com/official-stockfish/Stockfish/pull/3075
Bench 3527337
2020-08-28 04:06:36 -06:00
|
|
|
if (!excludedMove)
|
Adjust penalty on refuted early quiet moves
This patch changes how previous early moves are penalized in case
search finds a best move. Here, the first quiet move that was not
a transposition table move is penalized.
passed STC
https://tests.stockfishchess.org/tests/view/5f51d839ba100690c5cc5f69
LLR: 2.94 (-2.94,2.94) {-0.25,1.25}
Total: 10088 W: 1150 L: 997 D: 7941
Ptnml(0-2): 41, 772, 3278, 899, 54
passed LTC
https://tests.stockfishchess.org/tests/view/5f51e435ba100690c5cc5f76
LLR: 2.93 (-2.94,2.94) {0.25,1.25}
Total: 30808 W: 1564 L: 1405 D: 27839
Ptnml(0-2): 19, 1245, 12717, 1404, 19
closes https://github.com/official-stockfish/Stockfish/pull/3106
bench 3983758
2020-09-04 06:53:59 -06:00
|
|
|
ss->ttPv = PvNode || (ss->ttHit && tte->is_pv());
|
Improve move order near the root
Current move histories are known to work well near the leaves, whilst at
higher depths they aren't very helpful. To address this problem this
patch introduces a table dedicated for what's happening at plies 0-3.
It's structured like mainHistory with ply index instead of color.
It get cleared with each new search and is filled during iterative
deepening at higher depths when recording successful quiet moves near
the root or traversing nodes which were in the principal variation
(ttPv).
Medium TC (20+0.2):
https://tests.stockfishchess.org/tests/view/5e4d358790a0a02810d096dc
LLR: 2.94 (-2.94,2.94) {-0.50,1.50}
Total: 100910 W: 16682 L: 16376 D: 67852
Ptnml(0-2): 1177, 10983, 25883, 11181, 1231
LTC:
https://tests.stockfishchess.org/tests/view/5e4e2cb790a0a02810d09714
LLR: 2.95 (-2.94,2.94) {0.25,1.75}
Total: 80444 W: 10495 L: 10095 D: 59854
Ptnml(0-2): 551, 7479, 23803, 7797, 592
closes https://github.com/official-stockfish/Stockfish/pull/2557
Bench: 4705960
2020-02-21 06:01:59 -07:00
|
|
|
|
2020-12-01 05:02:35 -07:00
|
|
|
// Update low ply history for previous move if we are near root and position is or has been in PV
|
Add / remove leaves from search tree ttPv
add if previous leaf is in search tree and we didn't find a counter move
else remove the position if the leaf is the last one in search tree.
STC : https://tests.stockfishchess.org/tests/view/5f49203c3def640786115314
LLR: 2.95 (-2.94,2.94) {-0.25,1.25}
Total: 29968 W: 3381 L: 3195 D: 23392
Ptnml(0-2): 146, 2432, 9671, 2560, 175
LTC : https://tests.stockfishchess.org/tests/view/5f494bea3def640786115336
LLR: 2.96 (-2.94,2.94) {0.25,1.25}
Total: 84952 W: 4619 L: 4333 D: 76000
Ptnml(0-2): 86, 3765, 34481, 4065, 79
closes https://github.com/official-stockfish/Stockfish/pull/3075
Bench 3527337
2020-08-28 04:06:36 -06:00
|
|
|
if ( ss->ttPv
|
2020-07-09 14:01:06 -06:00
|
|
|
&& depth > 12
|
|
|
|
&& ss->ply - 1 < MAX_LPH
|
|
|
|
&& !priorCapture
|
|
|
|
&& is_ok((ss-1)->currentMove))
|
Improve move order near the root
Current move histories are known to work well near the leaves, whilst at
higher depths they aren't very helpful. To address this problem this
patch introduces a table dedicated for what's happening at plies 0-3.
It's structured like mainHistory with ply index instead of color.
It get cleared with each new search and is filled during iterative
deepening at higher depths when recording successful quiet moves near
the root or traversing nodes which were in the principal variation
(ttPv).
Medium TC (20+0.2):
https://tests.stockfishchess.org/tests/view/5e4d358790a0a02810d096dc
LLR: 2.94 (-2.94,2.94) {-0.50,1.50}
Total: 100910 W: 16682 L: 16376 D: 67852
Ptnml(0-2): 1177, 10983, 25883, 11181, 1231
LTC:
https://tests.stockfishchess.org/tests/view/5e4e2cb790a0a02810d09714
LLR: 2.95 (-2.94,2.94) {0.25,1.75}
Total: 80444 W: 10495 L: 10095 D: 59854
Ptnml(0-2): 551, 7479, 23803, 7797, 592
closes https://github.com/official-stockfish/Stockfish/pull/2557
Bench: 4705960
2020-02-21 06:01:59 -07:00
|
|
|
thisThread->lowPlyHistory[ss->ply - 1][from_to((ss-1)->currentMove)] << stat_bonus(depth - 5);
|
|
|
|
|
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
|
Adjust penalty on refuted early quiet moves
This patch changes how previous early moves are penalized in case
search finds a best move. Here, the first quiet move that was not
a transposition table move is penalized.
passed STC
https://tests.stockfishchess.org/tests/view/5f51d839ba100690c5cc5f69
LLR: 2.94 (-2.94,2.94) {-0.25,1.25}
Total: 10088 W: 1150 L: 997 D: 7941
Ptnml(0-2): 41, 772, 3278, 899, 54
passed LTC
https://tests.stockfishchess.org/tests/view/5f51e435ba100690c5cc5f76
LLR: 2.93 (-2.94,2.94) {0.25,1.25}
Total: 30808 W: 1564 L: 1405 D: 27839
Ptnml(0-2): 19, 1245, 12717, 1404, 19
closes https://github.com/official-stockfish/Stockfish/pull/3106
bench 3983758
2020-09-04 06:53:59 -06:00
|
|
|
&& ss->ttHit
|
Increase TTdepth acceptance some Threads
Increase TTdepth acceptance only on half of the Threads
STC:
LLR: 2.96 (-2.94,2.94) <-0.50,2.50>
Total: 19272 W: 4956 L: 4766 D: 9550
Ptnml(0-2): 25, 1989, 5423, 2169, 30
https://tests.stockfishchess.org/tests/view/6172be6238cb9784038af9a7
LTC:
LLR: 2.93 (-2.94,2.94) <0.50,3.50>
Total: 23688 W: 6111 L: 5897 D: 11680
Ptnml(0-2): 2, 2275, 7081, 2479, 7
https://tests.stockfishchess.org/tests/view/6172e32938cb9784038af9c7
closes https://github.com/official-stockfish/Stockfish/pull/3754
No functional change in the single-threaded case
2021-10-22 07:35:42 -06:00
|
|
|
&& tte->depth() > depth - (thisThread->id() % 2 == 1)
|
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)
|
|
|
|
{
|
2020-12-01 05:02:35 -07:00
|
|
|
// Bonus for a quiet ttMove that fails high
|
2021-10-06 11:16:02 -06:00
|
|
|
if (!ttCapture)
|
Improve move order near the root
Current move histories are known to work well near the leaves, whilst at
higher depths they aren't very helpful. To address this problem this
patch introduces a table dedicated for what's happening at plies 0-3.
It's structured like mainHistory with ply index instead of color.
It get cleared with each new search and is filled during iterative
deepening at higher depths when recording successful quiet moves near
the root or traversing nodes which were in the principal variation
(ttPv).
Medium TC (20+0.2):
https://tests.stockfishchess.org/tests/view/5e4d358790a0a02810d096dc
LLR: 2.94 (-2.94,2.94) {-0.50,1.50}
Total: 100910 W: 16682 L: 16376 D: 67852
Ptnml(0-2): 1177, 10983, 25883, 11181, 1231
LTC:
https://tests.stockfishchess.org/tests/view/5e4e2cb790a0a02810d09714
LLR: 2.95 (-2.94,2.94) {0.25,1.75}
Total: 80444 W: 10495 L: 10095 D: 59854
Ptnml(0-2): 551, 7479, 23803, 7797, 592
closes https://github.com/official-stockfish/Stockfish/pull/2557
Bench: 4705960
2020-02-21 06:01:59 -07:00
|
|
|
update_quiet_stats(pos, ss, ttMove, stat_bonus(depth), depth);
|
2016-08-24 08:52:05 -06:00
|
|
|
|
2019-04-09 08:51:39 -06:00
|
|
|
// Extra penalty for early quiet moves of the previous ply
|
2019-10-05 08:42:36 -06:00
|
|
|
if ((ss-1)->moveCount <= 2 && !priorCapture)
|
2019-09-28 14:27:23 -06:00
|
|
|
update_continuation_histories(ss-1, pos.piece_on(prevSq), prevSq, -stat_bonus(depth + 1));
|
2017-01-25 07:32:10 -07:00
|
|
|
}
|
|
|
|
// Penalty for a quiet ttMove that fails low
|
2021-10-06 11:16:02 -06:00
|
|
|
else if (!ttCapture)
|
2017-01-25 07:32:10 -07:00
|
|
|
{
|
Revert 5 recent patches
Revert 5 patches which were merged, but lead to a regression test that showed negative Elo gain:
http://tests.stockfishchess.org/tests/view/5e307251ab2d69d58394fdb9
This was discussed in depth in:
https://github.com/official-stockfish/Stockfish/issues/2531
Each patch was removed and tested as a simplification, full list below, and the whole combo as well.
After the revert the regression test showed a neutral result:
http://tests.stockfishchess.org/tests/view/5e334851708b13464ceea33c
As a result of this experience, the SPRT testing bounds will be made more strict.
Reverted patches:
1 Dynamic Complexity 6d0eabd5fe2961551477820ab7619e2c31e01ffd :
STC 10+0.1 https://tests.stockfishchess.org/tests/view/5e31fcacec661e2e6a340d08 :
LLR: 2.97 (-2.94,2.94) {-1.50,0.50}
Total: 38130 W: 7326 L: 7189 D: 23615
Ptnml(0-2): 677, 4346, 8843, 4545, 646
LTC 60+0.6 https://tests.stockfishchess.org/tests/view/5e32c18fec661e2e6a340d73 :
LLR: 2.94 (-2.94,2.94) {-1.50,0.50}
Total: 38675 W: 4941 L: 4866 D: 28868
Ptnml(0-2): 270, 3556, 11429, 3584, 291
3 More bonus for bestMoves on past PV nodes 71e0b5385e2717679a57c6b77d8c7ac5fff3b89f :
STC 10+0.1 https://tests.stockfishchess.org/tests/view/5e31fe93ec661e2e6a340d10 :
LLR: 2.95 (-2.94,2.94) {-1.50,0.50}
Total: 46100 W: 8853 L: 8727 D: 28520
Ptnml(0-2): 796, 5297, 10749, 5387, 813
LTC 60+0.6 https://tests.stockfishchess.org/tests/view/5e32c187ec661e2e6a340d71 :
LLR: 2.96 (-2.94,2.94) {-1.50,0.50}
Total: 16920 W: 2161 L: 2055 D: 12704
Ptnml(0-2): 115, 1498, 5006, 1569, 130
4 Tweak Restricted Piece Bonus 0ae00454ba6928d181b46103e5c83e6d58fcebe5 :
STC 10+0.1 https://tests.stockfishchess.org/tests/view/5e31fefaec661e2e6a340d15 :
LLR: 2.94 (-2.94,2.94) {-1.50,0.50}
Total: 88328 W: 17060 L: 16997 D: 54271
Ptnml(0-2): 1536, 10446, 20169, 10422, 1581
LTC 60+0.6 https://tests.stockfishchess.org/tests/view/5e32c17aec661e2e6a340d6f :
LLR: 2.95 (-2.94,2.94) {-1.50,0.50}
Total: 34784 W: 4551 L: 4466 D: 25767
Ptnml(0-2): 255, 3279, 10061, 3345, 262
5 History update for pruned captures 01b6088af39902001d2d6844561b6a2faa549282 :
STC 10+0.1 https://tests.stockfishchess.org/tests/view/5e31ff5eec661e2e6a340d1a :
LLR: 2.94 (-2.94,2.94) {-1.50,0.50}
Total: 29541 W: 5735 L: 5588 D: 18218
Ptnml(0-2): 483, 3445, 6820, 3469, 545
LTC 60+0.6 https://tests.stockfishchess.org/tests/view/5e32c196ec661e2e6a340d75 :
LLR: 2.94 (-2.94,2.94) {-1.50,0.50}
Total: 22177 W: 2854 L: 2757 D: 16566
Ptnml(0-2): 143, 2005, 6555, 2055, 164
6 Tweak trapped rook penalty 18fc21eba0368fd5e3c4c4b8ee1000c9ac445425 :
STC 10+0.1 https://tests.stockfishchess.org/tests/view/5e31ffb1ec661e2e6a340d1c :
LLR: 2.95 (-2.94,2.94) {-1.50,0.50}
Total: 24476 W: 4727 L: 4569 D: 15180
Ptnml(0-2): 390, 2834, 5659, 2933, 417
LTC 60+0.6 https://tests.stockfishchess.org/tests/view/5e32c19eec661e2e6a340d77 :
LLR: 2.95 (-2.94,2.94) {-1.50,0.50}
Total: 97332 W: 12492 L: 12466 D: 72374
Ptnml(0-2): 690, 9107, 28738, 9034, 720
All 5 as one simplification :
LTC 60+0.6 https://tests.stockfishchess.org/tests/view/5e334098708b13464ceea330 :
LLR: 2.94 (-2.94,2.94) {-1.50,0.50}
Total: 7829 W: 1079 L: 964 D: 5786
Ptnml(0-2): 52, 690, 2281, 781, 65
Bench: 5153165
2020-01-30 13:44:04 -07: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
|
|
|
}
|
50-moves rule improvement for transposition table
User "adentong" reported recently of a game where Stockfish blundered a game
in a tournament because during a search there was an hash-table issue for
positions inside the tree very close to the 50-moves draw rule. This is part
of a problem which is commonly referred to as the Graph History Interaction (GHI),
and is difficult to solve in computer chess because storing the 50-moves counter
in the hash-table loses Elo in general.
Links:
Issue 2451 : https://github.com/official-stockfish/Stockfish/issues/2451
About the GHI : https://www.chessprogramming.org/Graph_History_Interaction
This patch tries to address the issue in this particular game and similar
reported games: it prevents that values from the transposition table are
getting used when the 50-move counter is close to reaching 100 (). The idea
is that in such cases values from previous searches, with a much lower 50-move
count, become less and less reliable.
More precisely, the heuristic we use in this patch is that we don't take the
transposition table cutoff when we have reached a 45-moves limit, but let the
search continue doing its job. There is a possible slowdown involved, but it will
also help to find either a draw when it thought to be losing, or a way to avoid
the draw by 50-move rule. This heuristics probably will not fix all possible cases,
but seems to be working reasonably well in practice while not losing too much Elo.
Passed non-regression tests:
STC:
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 274452 W: 59700 L: 60075 D: 154677
http://tests.stockfishchess.org/tests/view/5df546116932658fe9b451bf
LTC:
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 95235 W: 15297 L: 15292 D: 64646
http://tests.stockfishchess.org/tests/view/5df69c926932658fe9b4520e
Closes https://github.com/official-stockfish/Stockfish/pull/2453
Bench: 4586187
2019-12-12 04:53:47 -07:00
|
|
|
|
2020-12-01 05:02:35 -07:00
|
|
|
// Partial workaround for the graph history interaction problem
|
|
|
|
// For high rule50 counts don't produce transposition table cutoffs.
|
50-moves rule improvement for transposition table
User "adentong" reported recently of a game where Stockfish blundered a game
in a tournament because during a search there was an hash-table issue for
positions inside the tree very close to the 50-moves draw rule. This is part
of a problem which is commonly referred to as the Graph History Interaction (GHI),
and is difficult to solve in computer chess because storing the 50-moves counter
in the hash-table loses Elo in general.
Links:
Issue 2451 : https://github.com/official-stockfish/Stockfish/issues/2451
About the GHI : https://www.chessprogramming.org/Graph_History_Interaction
This patch tries to address the issue in this particular game and similar
reported games: it prevents that values from the transposition table are
getting used when the 50-move counter is close to reaching 100 (). The idea
is that in such cases values from previous searches, with a much lower 50-move
count, become less and less reliable.
More precisely, the heuristic we use in this patch is that we don't take the
transposition table cutoff when we have reached a 45-moves limit, but let the
search continue doing its job. There is a possible slowdown involved, but it will
also help to find either a draw when it thought to be losing, or a way to avoid
the draw by 50-move rule. This heuristics probably will not fix all possible cases,
but seems to be working reasonably well in practice while not losing too much Elo.
Passed non-regression tests:
STC:
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 274452 W: 59700 L: 60075 D: 154677
http://tests.stockfishchess.org/tests/view/5df546116932658fe9b451bf
LTC:
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 95235 W: 15297 L: 15292 D: 64646
http://tests.stockfishchess.org/tests/view/5df69c926932658fe9b4520e
Closes https://github.com/official-stockfish/Stockfish/pull/2453
Bench: 4586187
2019-12-12 04:53:47 -07:00
|
|
|
if (pos.rule50_count() < 90)
|
|
|
|
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;
|
|
|
|
|
Fix for incorrect VALUE_MATE_IN_MAX_PLY usage.
Fixes #2533, fixes #2543, fixes #2423.
the code that prevents false mate announcements depending on the TT
state (GHI), incorrectly used VALUE_MATE_IN_MAX_PLY. The latter
constant, however, also includes, counterintuitively, the TB win range.
This patch fixes that, by restoring the behavior for TB win scores,
while retaining the false mate correctness, and improving the mate
finding ability. In particular
no alse mates are announced with the poisened hash testcase
```
position fen 8/8/8/3k4/8/8/6K1/7R w - - 0 1
go depth 40
position fen 8/8/8/3k4/8/8/6K1/7R w - - 76 1
go depth 20
ucinewgame
```
mates are found with the testcases reported in #2543
```
position fen 4k3/3pp3/8/8/8/8/2PPP3/4K3 w - - 0 1
setoption name Hash value 1024
go depth 55
ucinewgame
```
and
```
position fen 4k3/4p3/8/8/8/8/3PP3/4K3 w - - 0 1
setoption name Hash value 1024
go depth 45
ucinewgame
```
furthermore, on the mate finding benchmark (ChestUCI_23102018.epd),
performance improves over master, roughly reaching performance with the
false mate protection reverted
```
Analyzing 6566 mate positions for best and found mates:
----------------best ---------------found
nodes master revert fixed master revert fixed
16000000 4233 4236 4235 5200 5201 5199
32000000 4583 4585 4585 5417 5424 5418
64000000 4852 4853 4855 5575 5584 5579
128000000 5071 5068 5066 5710 5720 5716
256000000 5280 5282 5279 5819 5827 5826
512000000 5471 5468 5468 5919 5935 5932
```
On a testcase with TB enabled, progress is made consistently, contrary
to master
```
setoption name SyzygyPath value ../../../syzygy/3-4-5/
setoption name Hash value 2048
position fen 1R6/3k4/8/K2p4/4n3/2P5/8/8 w - - 0 1
go depth 58
ucinewgame
```
The PR (prior to a rewrite for clarity)
passed STC:
LLR: 2.94 (-2.94,2.94) {-1.50,0.50}
Total: 65405 W: 12454 L: 12384 D: 40567
Ptnml(0-2): 920, 7256, 16285, 7286, 944
http://tests.stockfishchess.org/tests/view/5e441a3be70d848499f63d15
passed LTC:
LLR: 2.94 (-2.94,2.94) {-1.50,0.50}
Total: 27096 W: 3477 L: 3413 D: 20206
Ptnml(0-2): 128, 2215, 8776, 2292, 122
http://tests.stockfishchess.org/tests/view/5e44e277e70d848499f63d63
The incorrectly named VALUE_MATE_IN_MAX_PLY and VALUE_MATED_IN_MAX_PLY
were renamed into VALUE_TB_WIN_IN_MAX_PLY and VALUE_TB_LOSS_IN_MAX_PLY,
and correclty defined VALUE_MATE_IN_MAX_PLY and VALUE_MATED_IN_MAX_PLY
were introduced.
One further (corner case) mistake using these constants was fixed (go
mate X), which could lead to a premature return if X > MAX_PLY / 2,
but TB were present.
Thanks to @svivanov72 for one of the reports and help fixing the issue.
closes https://github.com/official-stockfish/Stockfish/pull/2552
Bench: 4932981
2020-02-11 12:42:32 -07:00
|
|
|
// use the range VALUE_MATE_IN_MAX_PLY to VALUE_TB_WIN_IN_MAX_PLY to score
|
|
|
|
value = wdl < -drawScore ? VALUE_MATED_IN_MAX_PLY + ss->ply + 1
|
|
|
|
: wdl > drawScore ? VALUE_MATE_IN_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))
|
|
|
|
{
|
Add / remove leaves from search tree ttPv
add if previous leaf is in search tree and we didn't find a counter move
else remove the position if the leaf is the last one in search tree.
STC : https://tests.stockfishchess.org/tests/view/5f49203c3def640786115314
LLR: 2.95 (-2.94,2.94) {-0.25,1.25}
Total: 29968 W: 3381 L: 3195 D: 23392
Ptnml(0-2): 146, 2432, 9671, 2560, 175
LTC : https://tests.stockfishchess.org/tests/view/5f494bea3def640786115336
LLR: 2.96 (-2.94,2.94) {0.25,1.25}
Total: 84952 W: 4619 L: 4333 D: 76000
Ptnml(0-2): 86, 3765, 34481, 4065, 79
closes https://github.com/official-stockfish/Stockfish/pull/3075
Bench 3527337
2020-08-28 04:06:36 -06:00
|
|
|
tte->save(posKey, value_to_tt(value, ss->ply), ss->ttPv, b,
|
2019-09-28 14:27:23 -06:00
|
|
|
std::min(MAX_PLY - 1, depth + 6),
|
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
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
Introduce capture history pruning
This patch introduces a heuristic that is similar to countermove based pruning but for captures - capture history pruning. The idea is that we can (almost) safely prune really late captures with negative history if they don't give check so will most likely not produce some king-attacking tactic.
passed STC
https://tests.stockfishchess.org/tests/view/5e8c60d40ffd2be7f15e5470
LLR: 2.94 (-2.94,2.94) {-0.50,1.50}
Total: 23748 W: 4758 L: 4529 D: 14461
Ptnml(0-2): 421, 2712, 5400, 2899, 442
passed LTC
https://tests.stockfishchess.org/tests/view/5e8c72bf0ffd2be7f15e547f
LLR: 2.96 (-2.94,2.94) {0.25,1.75}
Total: 17330 W: 2415 L: 2190 D: 12725
Ptnml(0-2): 126, 1561, 5107, 1704, 167
closes https://github.com/official-stockfish/Stockfish/pull/2618
bench 4417023
2020-04-07 07:53:24 -06:00
|
|
|
CapturePieceToHistory& captureHistory = thisThread->captureHistory;
|
|
|
|
|
2018-05-08 17:40:32 -06:00
|
|
|
// Step 6. Static evaluation of the position
|
continuation histories when in check
If in check, don't write to continuation histories ss-4, ss-6.
Adding inCheck to the stack was needed, and might be useful for
future patches.
Passed STC:
https://tests.stockfishchess.org/tests/view/5e9ee24acaaff5d60a50b812
LLR: 2.94 (-2.94,2.94) {-0.50,1.50}
Total: 61774 W: 11725 L: 11449 D: 38600
Ptnml(0-2): 971, 7211, 14322, 7337, 1046
Passed LTC:
https://tests.stockfishchess.org/tests/view/5e9eecb7caaff5d60a50b831
LLR: 2.94 (-2.94,2.94) {0.25,1.75}
Total: 250822 W: 32067 L: 31179 D: 187576
Ptnml(0-2): 1745, 23126, 74824, 23928, 1788
closes https://github.com/official-stockfish/Stockfish/pull/2645
bench: 4808463
2020-04-21 12:55:41 -06:00
|
|
|
if (ss->inCheck)
|
2013-07-07 05:27:31 -06:00
|
|
|
{
|
2020-06-24 14:19:58 -06:00
|
|
|
// Skip early pruning when in check
|
2019-03-29 07:05:02 -06:00
|
|
|
ss->staticEval = eval = VALUE_NONE;
|
2018-03-13 16:19:36 -06:00
|
|
|
improving = false;
|
Smooth improving
Smooth dependency on improvement margin in null move search.
STC
LLR: 2.93 (-2.94,2.94) <-0.50,2.50>
Total: 17384 W: 4468 L: 4272 D: 8644
Ptnml(0-2): 42, 1919, 4592, 2079, 60
https://tests.stockfishchess.org/tests/view/61689b8a1e5f6627cc1c0fdc
LTC
LLR: 2.94 (-2.94,2.94) <0.50,3.50>
Total: 45648 W: 11525 L: 11243 D: 22880
Ptnml(0-2): 26, 4731, 13036, 4997, 34
https://tests.stockfishchess.org/tests/view/6168a12c1e5f6627cc1c0fe3
It would be interesting to test if the other pruning/reduction heuristics
in master which are using the improving variable (ie the sign of improvement)
could benefit from a smooth function of the improvement value (or maybe a
Relu of the improvement value).
closes https://github.com/official-stockfish/Stockfish/pull/3740
Bench: 4916775
2021-10-14 14:26:42 -06:00
|
|
|
improvement = 0;
|
2020-06-24 14:19:58 -06:00
|
|
|
goto moves_loop;
|
2013-07-07 05:27:31 -06:00
|
|
|
}
|
Adjust penalty on refuted early quiet moves
This patch changes how previous early moves are penalized in case
search finds a best move. Here, the first quiet move that was not
a transposition table move is penalized.
passed STC
https://tests.stockfishchess.org/tests/view/5f51d839ba100690c5cc5f69
LLR: 2.94 (-2.94,2.94) {-0.25,1.25}
Total: 10088 W: 1150 L: 997 D: 7941
Ptnml(0-2): 41, 772, 3278, 899, 54
passed LTC
https://tests.stockfishchess.org/tests/view/5f51e435ba100690c5cc5f76
LLR: 2.93 (-2.94,2.94) {0.25,1.25}
Total: 30808 W: 1564 L: 1405 D: 27839
Ptnml(0-2): 19, 1245, 12717, 1404, 19
closes https://github.com/official-stockfish/Stockfish/pull/3106
bench 3983758
2020-09-04 06:53:59 -06:00
|
|
|
else if (ss->ttHit)
|
2010-01-17 04:55:10 -07:00
|
|
|
{
|
2019-06-09 07:07:36 -06:00
|
|
|
// Never assume anything about values stored in TT
|
2019-03-29 07:05:02 -06:00
|
|
|
ss->staticEval = eval = tte->eval();
|
2018-08-28 17:22:22 -06:00
|
|
|
if (eval == VALUE_NONE)
|
2019-03-29 07:05:02 -06:00
|
|
|
ss->staticEval = eval = evaluate(pos);
|
2012-10-26 04:33:58 -06:00
|
|
|
|
2020-12-01 05:02:35 -07:00
|
|
|
// Randomize draw evaluation
|
More random draw evaluations
Use the randomized draw function value_draw() also for draw evalutions.
This extends the earlier commit
https://github.com/official-stockfish/Stockfish/commit/97d2cc9a9c1c4b6ff1b470676fa18c7fc6509886
which did this only for 3folds.
As in that case, this test was yellow at STC and LTC, but green at VLTC,
indicative of the fact that the higher the drawrate, the more likely this
idea is beneficial.
STC:
LLR: -2.96 (-2.94,2.94) [0.50,4.50]
Total: 83573 W: 18584 L: 18335 D: 46654
http://tests.stockfishchess.org/tests/view/5d84e44d0ebc5971531d4f94
LTC:
LLR: -2.96 (-2.94,2.94) [0.00,3.50]
Total: 92252 W: 15240 L: 15160 D: 61852
http://tests.stockfishchess.org/tests/view/5d865dd90ebc5971531d68e1
VLTC: 120+1.2 @ 2th
LLR: 2.96 (-2.94,2.94) [0.00,3.50]
Total: 51902 W: 7323 L: 7028 D: 37551
http://tests.stockfishchess.org/tests/view/5d8763620ebc595f57c22b15
Closes https://github.com/official-stockfish/Stockfish/pull/2321
Bench: 3441237
2019-09-20 08:33:57 -06:00
|
|
|
if (eval == VALUE_DRAW)
|
2019-09-27 11:25:22 -06:00
|
|
|
eval = value_draw(thisThread);
|
More random draw evaluations
Use the randomized draw function value_draw() also for draw evalutions.
This extends the earlier commit
https://github.com/official-stockfish/Stockfish/commit/97d2cc9a9c1c4b6ff1b470676fa18c7fc6509886
which did this only for 3folds.
As in that case, this test was yellow at STC and LTC, but green at VLTC,
indicative of the fact that the higher the drawrate, the more likely this
idea is beneficial.
STC:
LLR: -2.96 (-2.94,2.94) [0.50,4.50]
Total: 83573 W: 18584 L: 18335 D: 46654
http://tests.stockfishchess.org/tests/view/5d84e44d0ebc5971531d4f94
LTC:
LLR: -2.96 (-2.94,2.94) [0.00,3.50]
Total: 92252 W: 15240 L: 15160 D: 61852
http://tests.stockfishchess.org/tests/view/5d865dd90ebc5971531d68e1
VLTC: 120+1.2 @ 2th
LLR: 2.96 (-2.94,2.94) [0.00,3.50]
Total: 51902 W: 7323 L: 7028 D: 37551
http://tests.stockfishchess.org/tests/view/5d8763620ebc595f57c22b15
Closes https://github.com/official-stockfish/Stockfish/pull/2321
Bench: 3441237
2019-09-20 08:33:57 -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
|
|
|
|
{
|
Simplify evaluate condition on search
Remove condition for MOVE_NULL on search.
STC:
LLR: 2.94 (-2.94,2.94) <-2.50,0.50>
Total: 47544 W: 11968 L: 11864 D: 23712
Ptnml(0-2): 150, 5535, 12318, 5599, 170
https://tests.stockfishchess.org/tests/view/616e37143799eb91f1f071ee
LTC:
LLR: 2.93 (-2.94,2.94) <-2.50,0.50>
Total: 67472 W: 16938 L: 16870 D: 33664
Ptnml(0-2): 49, 7119, 19331, 7189, 48
https://tests.stockfishchess.org/tests/view/616e3fab3799eb91f1f071f1
closes https://github.com/official-stockfish/Stockfish/pull/3746
bench: 5255771
2021-10-19 06:23:30 -06:00
|
|
|
ss->staticEval = eval = evaluate(pos);
|
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
|
|
|
|
2020-12-01 05:02:35 -07:00
|
|
|
// Save static evaluation into transposition table
|
Double extend more often via LMR
Allow for first three moves always a two plies deeper LMR search.
STC:
LLR: 2.96 (-2.94,2.94) <-2.50,0.50>
Total: 206096 W: 51966 L: 52093 D: 102037
Ptnml(0-2): 664, 23817, 54293, 23530, 744
https://tests.stockfishchess.org/tests/view/616f197d40f619782fd4f75a
LTC:
LLR: 2.93 (-2.94,2.94) <-2.50,0.50>
Total: 62384 W: 15567 L: 15492 D: 31325
Ptnml(0-2): 40, 6633, 17777, 6696, 46
https://tests.stockfishchess.org/tests/view/616ffa1b4f0b65a0e231e682
closes https://github.com/official-stockfish/Stockfish/pull/3752
Bench: 6154836
2021-10-21 01:39:28 -06:00
|
|
|
if (!excludedMove)
|
|
|
|
tte->save(posKey, VALUE_NONE, ss->ttPv, BOUND_NONE, DEPTH_NONE, MOVE_NONE, eval);
|
2011-10-31 01:28:59 -06:00
|
|
|
}
|
2008-08-31 23:59:13 -06:00
|
|
|
|
Simplify condition for assigning static-eval based bonus
for quiet move ordering and simplify bonus formula.
Due to clamping the bonus to relative low values the impact on high
depths is minimal, thus the restriction to low depths seems not
necessary.
Also the condition of movecount in previous node seems to be not
determinant.
Passed STC:
LLR: 2.95 (-2.94,2.94) {-1.25,0.25}
Total: 14600 W: 1424 L: 1323 D: 11853
Ptnml(0-2): 55, 1033, 5020, 1140, 52
https://tests.stockfishchess.org/tests/view/5fd67b381ac16912018885ec
Passed LTC:
LLR: 2.95 (-2.94,2.94) {-0.75,0.25}
Total: 85008 W: 3218 L: 3206 D: 78584
Ptnml(0-2): 49, 2840, 36700, 2880, 35
https://tests.stockfishchess.org/tests/view/5fd6af041ac16912018885f8
closes https://github.com/official-stockfish/Stockfish/pull/3265
bench: 4524994
2020-12-14 08:30:56 -07:00
|
|
|
// Use static evaluation difference to improve quiet move ordering
|
|
|
|
if (is_ok((ss-1)->currentMove) && !(ss-1)->inCheck && !priorCapture)
|
Introduce static history
The idea of this patch can be described as following: we update static
history stats based on comparison of the static evaluations of the
position before and after the move. If the move increases static evaluation
it's assigned positive bonus, if it decreases static evaluation
it's assigned negative bonus. These stats are used in movepicker
to sort quiet moves.
passed STC
https://tests.stockfishchess.org/tests/view/5fca4c0842a050a89f02cd66
LLR: 3.00 (-2.94,2.94) {-0.25,1.25}
Total: 78152 W: 7409 L: 7171 D: 63572
Ptnml(0-2): 303, 5695, 26873, 5871, 334
passed LTC
https://tests.stockfishchess.org/tests/view/5fca6be442a050a89f02cd75
LLR: 2.94 (-2.94,2.94) {0.25,1.25}
Total: 40240 W: 1602 L: 1441 D: 37197
Ptnml(0-2): 19, 1306, 17305, 1475, 15
closes https://github.com/official-stockfish/Stockfish/pull/3253
bench 3845156
2020-12-04 18:00:41 -07:00
|
|
|
{
|
Remove Tempo
The Tempo variable was introduced 10 years ago in our search because the
classical evaluation function was antisymmetrical in White and Black by design
to gain speed:
Eval(White to play) = -Eval(Black to play)
Nowadays our neural networks know which side is to play in a position when
they evaluate a position and are trained on real games, so the neural network
encodes the advantage of moving as an output of search. This patch shows that
the Tempo variable is not necessary anymore.
STC:
LLR: 2.94 (-2.94,2.94) <-2.50,0.50>
Total: 33512 W: 2805 L: 2709 D: 27998
Ptnml(0-2): 80, 2209, 12095, 2279, 93
https://tests.stockfishchess.org/tests/view/60a44ceace8ea25a3ef03d30
LTC:
LLR: 2.95 (-2.94,2.94) <-2.50,0.50>
Total: 53920 W: 1807 L: 1760 D: 50353
Ptnml(0-2): 16, 1617, 23650, 1658, 19
https://tests.stockfishchess.org/tests/view/60a477f0ce8ea25a3ef03d49
We also tried a match (20000 games) at STC using purely classical, result was neutral:
https://tests.stockfishchess.org/tests/view/60a4eebcce8ea25a3ef03db5
Note: there are two locations left in search.cpp where we assume antisymmetry
of evaluation (in relation with a speed optimization for null moves in lines
770 and 1439), but as the values are just used for heuristic pruning this
approximation should not hurt too much because the order of magnitude is still
true most of the time.
closes https://github.com/official-stockfish/Stockfish/pull/3481
Bench: 4015864
2021-05-18 17:24:51 -06:00
|
|
|
int bonus = std::clamp(-depth * 4 * int((ss-1)->staticEval + ss->staticEval), -1000, 1000);
|
Merge static history into main history,
thus simplifying and reducing the memory footprint.
I believe using static diff for better move ordering is more suited for
low depths, so restrict writing to low depths.
Todo: probably the condition for writing can be simplified
LTC:
LLR: 2.95 (-2.94,2.94) {-0.75,0.25}
Total: 18752 W: 768 L: 705 D: 17279
Ptnml(0-2): 7, 635, 8034, 688, 12
https://tests.stockfishchess.org/tests/view/5fd631791ac169120188859e
STC:
LLR: 2.95 (-2.94,2.94) {-1.25,0.25}
Total: 36504 W: 3380 L: 3313 D: 29811
Ptnml(0-2): 116, 2667, 12645, 2682, 142
https://tests.stockfishchess.org/tests/view/5fd5ed861ac1691201888569
closes https://github.com/official-stockfish/Stockfish/pull/3262
bench: 4018036
2020-12-13 13:23:30 -07:00
|
|
|
thisThread->mainHistory[~us][from_to((ss-1)->currentMove)] << bonus;
|
Introduce static history
The idea of this patch can be described as following: we update static
history stats based on comparison of the static evaluations of the
position before and after the move. If the move increases static evaluation
it's assigned positive bonus, if it decreases static evaluation
it's assigned negative bonus. These stats are used in movepicker
to sort quiet moves.
passed STC
https://tests.stockfishchess.org/tests/view/5fca4c0842a050a89f02cd66
LLR: 3.00 (-2.94,2.94) {-0.25,1.25}
Total: 78152 W: 7409 L: 7171 D: 63572
Ptnml(0-2): 303, 5695, 26873, 5871, 334
passed LTC
https://tests.stockfishchess.org/tests/view/5fca6be442a050a89f02cd75
LLR: 2.94 (-2.94,2.94) {0.25,1.25}
Total: 40240 W: 1602 L: 1441 D: 37197
Ptnml(0-2): 19, 1306, 17305, 1475, 15
closes https://github.com/official-stockfish/Stockfish/pull/3253
bench 3845156
2020-12-04 18:00:41 -07:00
|
|
|
}
|
|
|
|
|
Smooth improving
Smooth dependency on improvement margin in null move search.
STC
LLR: 2.93 (-2.94,2.94) <-0.50,2.50>
Total: 17384 W: 4468 L: 4272 D: 8644
Ptnml(0-2): 42, 1919, 4592, 2079, 60
https://tests.stockfishchess.org/tests/view/61689b8a1e5f6627cc1c0fdc
LTC
LLR: 2.94 (-2.94,2.94) <0.50,3.50>
Total: 45648 W: 11525 L: 11243 D: 22880
Ptnml(0-2): 26, 4731, 13036, 4997, 34
https://tests.stockfishchess.org/tests/view/6168a12c1e5f6627cc1c0fe3
It would be interesting to test if the other pruning/reduction heuristics
in master which are using the improving variable (ie the sign of improvement)
could benefit from a smooth function of the improvement value (or maybe a
Relu of the improvement value).
closes https://github.com/official-stockfish/Stockfish/pull/3740
Bench: 4916775
2021-10-14 14:26:42 -06:00
|
|
|
// Set up the improvement variable, which is the difference between the current
|
|
|
|
// static evaluation and the previous static evaluation at our turn (if we were
|
|
|
|
// in check at our previous move we look at the move prior to it). The improvement
|
|
|
|
// margin and the improving flag are used in various pruning heuristics.
|
|
|
|
improvement = (ss-2)->staticEval != VALUE_NONE ? ss->staticEval - (ss-2)->staticEval
|
|
|
|
: (ss-4)->staticEval != VALUE_NONE ? ss->staticEval - (ss-4)->staticEval
|
|
|
|
: 200;
|
|
|
|
|
|
|
|
improving = improvement > 0;
|
2018-05-08 17:40:32 -06:00
|
|
|
|
2021-08-05 08:34:37 -06:00
|
|
|
// Step 7. Futility pruning: child node (~50 Elo).
|
|
|
|
// The depth condition is important for mate finding.
|
2018-12-12 12:34:17 -07:00
|
|
|
if ( !PvNode
|
2021-08-05 08:34:37 -06:00
|
|
|
&& depth < 9
|
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
|
|
|
|
Remove razoring
has become ineffective now.
STC https://tests.stockfishchess.org/tests/view/5fe653403932f79192d3981a
LLR: 2.95 (-2.94,2.94) {-1.25,0.25}
Total: 63448 W: 5965 L: 5934 D: 51549
Ptnml(0-2): 230, 4738, 21769, 4745, 242
LTC https://tests.stockfishchess.org/tests/view/5fe6f0f03932f79192d39856
LLR: 2.93 (-2.94,2.94) {-0.75,0.25}
Total: 65368 W: 2485 L: 2459 D: 60424
Ptnml(0-2): 33, 2186, 28230, 2192, 43
closes https://github.com/official-stockfish/Stockfish/pull/3278
bench: 4493379
2020-12-26 05:48:04 -07:00
|
|
|
// Step 8. 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
|
Tuning Search
This patch tunes constant in search.cpp
STC:
LLR: 2.94 (-2.94,2.94) <-0.50,2.50>
Total: 30648 W: 2580 L: 2410 D: 25658
Ptnml(0-2): 80, 1969, 11093, 2065, 117
https://tests.stockfishchess.org/tests/view/60a71d3cce8ea25a3ef03fae
LTC:
LLR: 2.95 (-2.94,2.94) <0.50,3.50>
Total: 52896 W: 1776 L: 1617 D: 49503
Ptnml(0-2): 13, 1462, 23347, 1605, 21
https://tests.stockfishchess.org/tests/view/60a794ddce8ea25a3ef0400a
closes https://github.com/official-stockfish/Stockfish/pull/3491
Bench: 4004731
2021-05-21 23:47:23 -06:00
|
|
|
&& (ss-1)->statScore < 23767
|
2012-10-22 01:50:00 -06:00
|
|
|
&& eval >= beta
|
2019-08-14 18:46:09 -06:00
|
|
|
&& eval >= ss->staticEval
|
Tuning of a Null Move Parameter
STC:
LLR: 2.99 (-2.94,2.94) <-0.50,2.50>
Total: 78744 W: 19956 L: 19664 D: 39124
Ptnml(0-2): 259, 9005, 20573, 9255, 280
https://tests.stockfishchess.org/tests/view/6172017a38cb9784038af947
LTC:
LLR: 2.95 (-2.94,2.94) <0.50,3.50>
Total: 68528 W: 17309 L: 16964 D: 34255
Ptnml(0-2): 41, 7194, 19455, 7527, 47
https://tests.stockfishchess.org/tests/view/6172994d38cb9784038af983
closes https://github.com/official-stockfish/Stockfish/pull/3756
bench: 6689428
2021-10-21 18:04:28 -06:00
|
|
|
&& ss->staticEval >= beta - 20 * depth - improvement / 15 + 204
|
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
|
Simplify Null Move Search Reduction
slightly simpler formula for reduction computation.
first round of tests:
STC:
LLR: 2.97 (-2.94,2.94) <-2.50,0.50>
Total: 15632 W: 1319 L: 1204 D: 13109
Ptnml(0-2): 33, 956, 5733, 1051, 43
https://tests.stockfishchess.org/tests/view/60bd03c7457376eb8bcaa600
LTC:
LLR: 3.37 (-2.94,2.94) <-2.50,0.50>
Total: 86296 W: 2814 L: 2779 D: 80703
Ptnml(0-2): 33, 2500, 38039, 2551, 25
https://tests.stockfishchess.org/tests/view/60bd1ff0457376eb8bcaa653
recent tests:
STC:
LLR: 2.93 (-2.94,2.94) <-2.50,0.50>
Total: 23936 W: 1895 L: 1793 D: 20248
Ptnml(0-2): 40, 1470, 8869, 1526, 63
https://tests.stockfishchess.org/tests/view/611f9b7d4977aa1525c9cb6b
LTC:
LLR: 2.95 (-2.94,2.94) <-2.50,0.50>
Total: 62568 W: 1750 L: 1713 D: 59105
Ptnml(0-2): 19, 1560, 28085, 1605, 15
https://tests.stockfishchess.org/tests/view/611fa4814977aa1525c9cb71
functional on high depth
closes https://github.com/official-stockfish/Stockfish/pull/3535
Bench: 5375286
2021-06-06 22:20:39 -06:00
|
|
|
Depth R = std::min(int(eval - beta) / 205, 3) + depth / 3 + 4;
|
2009-08-29 13:19:09 -06:00
|
|
|
|
2017-03-08 19:35:23 -07:00
|
|
|
ss->currentMove = MOVE_NULL;
|
2019-10-08 08:44:01 -06:00
|
|
|
ss->continuationHistory = &thisThread->continuationHistory[0][0][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)
|
|
|
|
{
|
2020-03-30 14:45:35 -06:00
|
|
|
// Do not return unproven mate or TB scores
|
Fix for incorrect VALUE_MATE_IN_MAX_PLY usage.
Fixes #2533, fixes #2543, fixes #2423.
the code that prevents false mate announcements depending on the TT
state (GHI), incorrectly used VALUE_MATE_IN_MAX_PLY. The latter
constant, however, also includes, counterintuitively, the TB win range.
This patch fixes that, by restoring the behavior for TB win scores,
while retaining the false mate correctness, and improving the mate
finding ability. In particular
no alse mates are announced with the poisened hash testcase
```
position fen 8/8/8/3k4/8/8/6K1/7R w - - 0 1
go depth 40
position fen 8/8/8/3k4/8/8/6K1/7R w - - 76 1
go depth 20
ucinewgame
```
mates are found with the testcases reported in #2543
```
position fen 4k3/3pp3/8/8/8/8/2PPP3/4K3 w - - 0 1
setoption name Hash value 1024
go depth 55
ucinewgame
```
and
```
position fen 4k3/4p3/8/8/8/8/3PP3/4K3 w - - 0 1
setoption name Hash value 1024
go depth 45
ucinewgame
```
furthermore, on the mate finding benchmark (ChestUCI_23102018.epd),
performance improves over master, roughly reaching performance with the
false mate protection reverted
```
Analyzing 6566 mate positions for best and found mates:
----------------best ---------------found
nodes master revert fixed master revert fixed
16000000 4233 4236 4235 5200 5201 5199
32000000 4583 4585 4585 5417 5424 5418
64000000 4852 4853 4855 5575 5584 5579
128000000 5071 5068 5066 5710 5720 5716
256000000 5280 5282 5279 5819 5827 5826
512000000 5471 5468 5468 5919 5935 5932
```
On a testcase with TB enabled, progress is made consistently, contrary
to master
```
setoption name SyzygyPath value ../../../syzygy/3-4-5/
setoption name Hash value 2048
position fen 1R6/3k4/8/K2p4/4n3/2P5/8/8 w - - 0 1
go depth 58
ucinewgame
```
The PR (prior to a rewrite for clarity)
passed STC:
LLR: 2.94 (-2.94,2.94) {-1.50,0.50}
Total: 65405 W: 12454 L: 12384 D: 40567
Ptnml(0-2): 920, 7256, 16285, 7286, 944
http://tests.stockfishchess.org/tests/view/5e441a3be70d848499f63d15
passed LTC:
LLR: 2.94 (-2.94,2.94) {-1.50,0.50}
Total: 27096 W: 3477 L: 3413 D: 20206
Ptnml(0-2): 128, 2215, 8776, 2292, 122
http://tests.stockfishchess.org/tests/view/5e44e277e70d848499f63d63
The incorrectly named VALUE_MATE_IN_MAX_PLY and VALUE_MATED_IN_MAX_PLY
were renamed into VALUE_TB_WIN_IN_MAX_PLY and VALUE_TB_LOSS_IN_MAX_PLY,
and correclty defined VALUE_MATE_IN_MAX_PLY and VALUE_MATED_IN_MAX_PLY
were introduced.
One further (corner case) mistake using these constants was fixed (go
mate X), which could lead to a premature return if X > MAX_PLY / 2,
but TB were present.
Thanks to @svivanov72 for one of the reports and help fixing the issue.
closes https://github.com/official-stockfish/Stockfish/pull/2552
Bench: 4932981
2020-02-11 12:42:32 -07:00
|
|
|
if (nullValue >= VALUE_TB_WIN_IN_MAX_PLY)
|
2014-02-12 06:16:21 -07:00
|
|
|
nullValue = beta;
|
|
|
|
|
Assorted search and eval parameter tune
Search and eval parameter tune.
STC https://tests.stockfishchess.org/tests/view/5fba850a67cbf42301d6b07d
LLR: 2.94 (-2.94,2.94) {-0.25,1.25}
Total: 24312 W: 2388 L: 2228 D: 19696
Ptnml(0-2): 85, 1800, 8241, 1930, 100
LTC https://tests.stockfishchess.org/tests/view/5fbad5ea67cbf42301d6b0fa
LLR: 2.95 (-2.94,2.94) {0.25,1.25}
Total: 88376 W: 3619 L: 3351 D: 81406
Ptnml(0-2): 56, 2977, 37849, 3255, 51
closes https://github.com/official-stockfish/Stockfish/pull/3232
bench: 3600361
2020-11-24 09:06:30 -07:00
|
|
|
if (thisThread->nmpMinPly || (abs(beta) < VALUE_KNOWN_WIN && depth < 14))
|
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.
|
2019-09-28 14:27:23 -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
|
|
|
|
Search Parameters Tuning
A simple tuning on search.cpp.
based SPSA test:
https://tests.stockfishchess.org/tests/view/601f2a787f517a561bc493cd
passed STC:
LLR: 2.94 (-2.94,2.94) {-0.25,1.25}
Total: 117840 W: 10796 L: 10508 D: 96536
Ptnml(0-2): 422, 8381, 41041, 8639, 437
https://tests.stockfishchess.org/tests/view/602144c37f517a561bc494ae
passed LTC:
LLR: 2.96 (-2.94,2.94) {0.25,1.25}
Total: 25024 W: 972 L: 847 D: 23205
Ptnml(0-2): 7, 767, 10847, 876, 15
https://tests.stockfishchess.org/tests/view/602156877f517a561bc494be
closes https://github.com/official-stockfish/Stockfish/pull/3340
Bench: 3974098
2021-02-04 17:50:22 -07:00
|
|
|
probCutBeta = beta + 209 - 44 * improving;
|
Maximize usage of transposition table in probcut
Probcut is a heuristic that wasn't changed a lot in past years,
all attempts to change it using information / writing info to transposition table failed.
This patch has a number of differences that can be summarized as follows:
* For TT write/read we use depth - 3. Because probcut search is depth - 4 but we actually do the move prior to it so effectively we do depth - 3 search;
* In any case of depth of eval from transposition table being >= depth - 3 we either produce cutoff or refuse to even do probcut search, this is allowing us to write info of probcut to transposition table because we know that we wouldn't be overwriting some deeper data with our depth - 3 search - this is an important aspect of this patch;
* For some not really known reason this patch completely ignores tte->bound() - which was the case for previous patch that made probcut interact with TT, maybe 2) is the reason, although it's unproven.
A first version of this patch passed STC and LTC
passed STC
https://tests.stockfishchess.org/tests/view/5f05908a59f6f03532894613
LLR: 2.95 (-2.94,2.94) {-0.50,1.50}
Total: 95776 W: 18300 L: 17973 D: 59503
Ptnml(0-2): 1646, 10944, 22377, 11279, 1642
passed LTC
https://tests.stockfishchess.org/tests/view/5f06b54059f6f035328946bb
LLR: 2.94 (-2.94,2.94) {0.25,1.75}
Total: 57128 W: 7266 L: 6938 D: 42924
Ptnml(0-2): 372, 5163, 17217, 5389, 423
However, an additional bugfix was needed to avoid checking a condition on ttMove if was not available. This passed non-regression bounds on top of the first version:
at STC
https://tests.stockfishchess.org/tests/view/5f080e5059f6f03532894766
LLR: 2.94 (-2.94,2.94) {-1.50,0.50}
Total: 14096 W: 2800 L: 2628 D: 8668
Ptnml(0-2): 225, 1620, 3238, 1688, 277
at LTC
https://tests.stockfishchess.org/tests/view/5f0836a559f6f0353289479c
LLR: 2.95 (-2.94,2.94) {-1.50,0.50}
Total: 25352 W: 3228 L: 3139 D: 18985
Ptnml(0-2): 175, 2350, 7549, 2415, 187
closes https://github.com/official-stockfish/Stockfish/pull/2804
Bench 4540940
2020-07-10 15:06:55 -06:00
|
|
|
|
Remove early return in Probcut code
We simplify away early return in ProbCut, as it seems not to bring any strength anymore.
STC:
LLR: 2.93 (-2.94,2.94) <-2.50,0.50>
Total: 42632 W: 3705 L: 3617 D: 35310
Ptnml(0-2): 123, 2947, 15110, 2991, 145
https://tests.stockfishchess.org/tests/view/609c49da7746e3dc74ffae02
LTC:
LLR: 2.96 (-2.94,2.94) <-2.50,0.50>
Total: 35384 W: 1314 L: 1251 D: 32819
Ptnml(0-2): 11, 1130, 15355, 1177, 19
https://tests.stockfishchess.org/tests/view/609c71467746e3dc74ffae47
---
While at it, we also update the Elo estimate of ProbCut
(see https://tests.stockfishchess.org/tests/view/609bfb597746e3dc74ffabe3).
closes https://github.com/official-stockfish/Stockfish/pull/3462
bench: 3764662
2021-05-13 08:12:56 -06:00
|
|
|
// Step 9. ProbCut (~4 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
|
Retuned values after eval quantize patch.
The last search tune patch was tested before the implementation of #2733 which
presumably changed the search characteristics noticeably. Another tuning run was
done, see https://tests.stockfishchess.org/tests/view/5ee5b434ca6c451633a9a08c
and the updated values passed these tests:
STC:
LLR: 2.93 (-2.94,2.94) {-0.50,1.50}
Total: 34352 W: 6600 L: 6360 D: 21392
Ptnml(0-2): 581, 3947, 7914, 4119, 615
https://tests.stockfishchess.org/tests/view/5ee62f05ca6c451633a9a15f
LTC 60+0.6 th 1 :
LLR: 2.97 (-2.94,2.94) {0.25,1.75}
Total: 11176 W: 1499 L: 1304 D: 8373
Ptnml(0-2): 69, 933, 3403, 1100, 83
https://tests.stockfishchess.org/tests/view/5ee6205bca6c451633a9a147
SMP LTC 20+0.2 th 8 :
LLR: 2.93 (-2.94,2.94) {0.25,1.75}
Total: 54032 W: 6126 L: 5826 D: 42080
Ptnml(0-2): 278, 4454, 17280, 4698, 306
https://tests.stockfishchess.org/tests/view/5ee62f25ca6c451633a9a162
Closes https://github.com/official-stockfish/Stockfish/pull/2742
Bench 4957812
2020-06-14 14:50:27 -06:00
|
|
|
&& depth > 4
|
Maximize usage of transposition table in probcut
Probcut is a heuristic that wasn't changed a lot in past years,
all attempts to change it using information / writing info to transposition table failed.
This patch has a number of differences that can be summarized as follows:
* For TT write/read we use depth - 3. Because probcut search is depth - 4 but we actually do the move prior to it so effectively we do depth - 3 search;
* In any case of depth of eval from transposition table being >= depth - 3 we either produce cutoff or refuse to even do probcut search, this is allowing us to write info of probcut to transposition table because we know that we wouldn't be overwriting some deeper data with our depth - 3 search - this is an important aspect of this patch;
* For some not really known reason this patch completely ignores tte->bound() - which was the case for previous patch that made probcut interact with TT, maybe 2) is the reason, although it's unproven.
A first version of this patch passed STC and LTC
passed STC
https://tests.stockfishchess.org/tests/view/5f05908a59f6f03532894613
LLR: 2.95 (-2.94,2.94) {-0.50,1.50}
Total: 95776 W: 18300 L: 17973 D: 59503
Ptnml(0-2): 1646, 10944, 22377, 11279, 1642
passed LTC
https://tests.stockfishchess.org/tests/view/5f06b54059f6f035328946bb
LLR: 2.94 (-2.94,2.94) {0.25,1.75}
Total: 57128 W: 7266 L: 6938 D: 42924
Ptnml(0-2): 372, 5163, 17217, 5389, 423
However, an additional bugfix was needed to avoid checking a condition on ttMove if was not available. This passed non-regression bounds on top of the first version:
at STC
https://tests.stockfishchess.org/tests/view/5f080e5059f6f03532894766
LLR: 2.94 (-2.94,2.94) {-1.50,0.50}
Total: 14096 W: 2800 L: 2628 D: 8668
Ptnml(0-2): 225, 1620, 3238, 1688, 277
at LTC
https://tests.stockfishchess.org/tests/view/5f0836a559f6f0353289479c
LLR: 2.95 (-2.94,2.94) {-1.50,0.50}
Total: 25352 W: 3228 L: 3139 D: 18985
Ptnml(0-2): 175, 2350, 7549, 2415, 187
closes https://github.com/official-stockfish/Stockfish/pull/2804
Bench 4540940
2020-07-10 15:06:55 -06:00
|
|
|
&& abs(beta) < VALUE_TB_WIN_IN_MAX_PLY
|
2020-07-18 07:30:00 -06:00
|
|
|
// if value from transposition table is lower than probCutBeta, don't attempt probCut
|
|
|
|
// there and in further interactions with transposition table cutoff depth is set to depth - 3
|
|
|
|
// because probCut search has depth set to depth - 4 but we also do a move before it
|
|
|
|
// so effective depth is equal to depth - 3
|
Adjust penalty on refuted early quiet moves
This patch changes how previous early moves are penalized in case
search finds a best move. Here, the first quiet move that was not
a transposition table move is penalized.
passed STC
https://tests.stockfishchess.org/tests/view/5f51d839ba100690c5cc5f69
LLR: 2.94 (-2.94,2.94) {-0.25,1.25}
Total: 10088 W: 1150 L: 997 D: 7941
Ptnml(0-2): 41, 772, 3278, 899, 54
passed LTC
https://tests.stockfishchess.org/tests/view/5f51e435ba100690c5cc5f76
LLR: 2.93 (-2.94,2.94) {0.25,1.25}
Total: 30808 W: 1564 L: 1405 D: 27839
Ptnml(0-2): 19, 1245, 12717, 1404, 19
closes https://github.com/official-stockfish/Stockfish/pull/3106
bench 3983758
2020-09-04 06:53:59 -06:00
|
|
|
&& !( ss->ttHit
|
2020-07-11 08:59:33 -06:00
|
|
|
&& tte->depth() >= depth - 3
|
Maximize usage of transposition table in probcut
Probcut is a heuristic that wasn't changed a lot in past years,
all attempts to change it using information / writing info to transposition table failed.
This patch has a number of differences that can be summarized as follows:
* For TT write/read we use depth - 3. Because probcut search is depth - 4 but we actually do the move prior to it so effectively we do depth - 3 search;
* In any case of depth of eval from transposition table being >= depth - 3 we either produce cutoff or refuse to even do probcut search, this is allowing us to write info of probcut to transposition table because we know that we wouldn't be overwriting some deeper data with our depth - 3 search - this is an important aspect of this patch;
* For some not really known reason this patch completely ignores tte->bound() - which was the case for previous patch that made probcut interact with TT, maybe 2) is the reason, although it's unproven.
A first version of this patch passed STC and LTC
passed STC
https://tests.stockfishchess.org/tests/view/5f05908a59f6f03532894613
LLR: 2.95 (-2.94,2.94) {-0.50,1.50}
Total: 95776 W: 18300 L: 17973 D: 59503
Ptnml(0-2): 1646, 10944, 22377, 11279, 1642
passed LTC
https://tests.stockfishchess.org/tests/view/5f06b54059f6f035328946bb
LLR: 2.94 (-2.94,2.94) {0.25,1.75}
Total: 57128 W: 7266 L: 6938 D: 42924
Ptnml(0-2): 372, 5163, 17217, 5389, 423
However, an additional bugfix was needed to avoid checking a condition on ttMove if was not available. This passed non-regression bounds on top of the first version:
at STC
https://tests.stockfishchess.org/tests/view/5f080e5059f6f03532894766
LLR: 2.94 (-2.94,2.94) {-1.50,0.50}
Total: 14096 W: 2800 L: 2628 D: 8668
Ptnml(0-2): 225, 1620, 3238, 1688, 277
at LTC
https://tests.stockfishchess.org/tests/view/5f0836a559f6f0353289479c
LLR: 2.95 (-2.94,2.94) {-1.50,0.50}
Total: 25352 W: 3228 L: 3139 D: 18985
Ptnml(0-2): 175, 2350, 7549, 2415, 187
closes https://github.com/official-stockfish/Stockfish/pull/2804
Bench 4540940
2020-07-10 15:06:55 -06:00
|
|
|
&& ttValue != VALUE_NONE
|
2020-07-18 07:30:00 -06:00
|
|
|
&& ttValue < probCutBeta))
|
2011-05-21 10:17:11 -06:00
|
|
|
{
|
2020-07-18 07:30:00 -06:00
|
|
|
assert(probCutBeta < VALUE_INFINITE);
|
2021-03-19 12:43:25 -06:00
|
|
|
|
2020-07-18 07:30:00 -06:00
|
|
|
MovePicker mp(pos, ttMove, probCutBeta - ss->staticEval, &captureHistory);
|
Add / remove leaves from search tree ttPv
add if previous leaf is in search tree and we didn't find a counter move
else remove the position if the leaf is the last one in search tree.
STC : https://tests.stockfishchess.org/tests/view/5f49203c3def640786115314
LLR: 2.95 (-2.94,2.94) {-0.25,1.25}
Total: 29968 W: 3381 L: 3195 D: 23392
Ptnml(0-2): 146, 2432, 9671, 2560, 175
LTC : https://tests.stockfishchess.org/tests/view/5f494bea3def640786115336
LLR: 2.96 (-2.94,2.94) {0.25,1.25}
Total: 84952 W: 4619 L: 4333 D: 76000
Ptnml(0-2): 86, 3765, 34481, 4065, 79
closes https://github.com/official-stockfish/Stockfish/pull/3075
Bench 3527337
2020-08-28 04:06:36 -06:00
|
|
|
bool ttPv = ss->ttPv;
|
|
|
|
ss->ttPv = false;
|
2018-03-06 14:11:45 -07:00
|
|
|
|
Simplify probCutCount away
Simplify away the limitation in number of moves in probCut.
STC:
LLR: 2.96 (-2.94,2.94) <-2.50,0.50>
Total: 286768 W: 71888 L: 72133 D: 142747
Ptnml(0-2): 983, 33084, 75471, 32887, 959
https://tests.stockfishchess.org/tests/view/616c9b9b90e1312a3cd0ef0a
LTC:
LLR: 2.95 (-2.94,2.94) <-2.50,0.50>
Total: 69312 W: 17243 L: 17176 D: 34893
Ptnml(0-2): 42, 7452, 19614, 7493, 55
https://tests.stockfishchess.org/tests/view/616cebbf4f95b438f7a85f93
closes https://github.com/official-stockfish/Stockfish/pull/3745
bench: 5005810
2021-10-18 06:03:12 -06:00
|
|
|
while ((move = mp.next_move()) != MOVE_NONE)
|
2018-08-28 18:27:47 -06:00
|
|
|
if (move != excludedMove && pos.legal(move))
|
2011-05-21 10:17:11 -06:00
|
|
|
{
|
2019-10-18 07:23:00 -06:00
|
|
|
assert(pos.capture_or_promotion(move));
|
|
|
|
assert(depth >= 5);
|
|
|
|
|
|
|
|
captureOrPromotion = true;
|
2018-03-03 04:03:38 -07:00
|
|
|
|
2012-01-21 15:30:56 -07:00
|
|
|
ss->currentMove = move;
|
continuation histories when in check
If in check, don't write to continuation histories ss-4, ss-6.
Adding inCheck to the stack was needed, and might be useful for
future patches.
Passed STC:
https://tests.stockfishchess.org/tests/view/5e9ee24acaaff5d60a50b812
LLR: 2.94 (-2.94,2.94) {-0.50,1.50}
Total: 61774 W: 11725 L: 11449 D: 38600
Ptnml(0-2): 971, 7211, 14322, 7337, 1046
Passed LTC:
https://tests.stockfishchess.org/tests/view/5e9eecb7caaff5d60a50b831
LLR: 2.94 (-2.94,2.94) {0.25,1.75}
Total: 250822 W: 32067 L: 31179 D: 187576
Ptnml(0-2): 1745, 23126, 74824, 23928, 1788
closes https://github.com/official-stockfish/Stockfish/pull/2645
bench: 4808463
2020-04-21 12:55:41 -06:00
|
|
|
ss->continuationHistory = &thisThread->continuationHistory[ss->inCheck]
|
2019-10-18 07:23:00 -06:00
|
|
|
[captureOrPromotion]
|
|
|
|
[pos.moved_piece(move)]
|
|
|
|
[to_sq(move)];
|
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
|
2020-07-18 07:30:00 -06:00
|
|
|
value = -qsearch<NonPV>(pos, ss+1, -probCutBeta, -probCutBeta+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
|
2020-07-18 07:30:00 -06:00
|
|
|
if (value >= probCutBeta)
|
|
|
|
value = -search<NonPV>(pos, ss+1, -probCutBeta, -probCutBeta+1, depth - 4, !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
|
|
|
|
2020-07-18 07:30:00 -06:00
|
|
|
if (value >= probCutBeta)
|
Maximize usage of transposition table in probcut
Probcut is a heuristic that wasn't changed a lot in past years,
all attempts to change it using information / writing info to transposition table failed.
This patch has a number of differences that can be summarized as follows:
* For TT write/read we use depth - 3. Because probcut search is depth - 4 but we actually do the move prior to it so effectively we do depth - 3 search;
* In any case of depth of eval from transposition table being >= depth - 3 we either produce cutoff or refuse to even do probcut search, this is allowing us to write info of probcut to transposition table because we know that we wouldn't be overwriting some deeper data with our depth - 3 search - this is an important aspect of this patch;
* For some not really known reason this patch completely ignores tte->bound() - which was the case for previous patch that made probcut interact with TT, maybe 2) is the reason, although it's unproven.
A first version of this patch passed STC and LTC
passed STC
https://tests.stockfishchess.org/tests/view/5f05908a59f6f03532894613
LLR: 2.95 (-2.94,2.94) {-0.50,1.50}
Total: 95776 W: 18300 L: 17973 D: 59503
Ptnml(0-2): 1646, 10944, 22377, 11279, 1642
passed LTC
https://tests.stockfishchess.org/tests/view/5f06b54059f6f035328946bb
LLR: 2.94 (-2.94,2.94) {0.25,1.75}
Total: 57128 W: 7266 L: 6938 D: 42924
Ptnml(0-2): 372, 5163, 17217, 5389, 423
However, an additional bugfix was needed to avoid checking a condition on ttMove if was not available. This passed non-regression bounds on top of the first version:
at STC
https://tests.stockfishchess.org/tests/view/5f080e5059f6f03532894766
LLR: 2.94 (-2.94,2.94) {-1.50,0.50}
Total: 14096 W: 2800 L: 2628 D: 8668
Ptnml(0-2): 225, 1620, 3238, 1688, 277
at LTC
https://tests.stockfishchess.org/tests/view/5f0836a559f6f0353289479c
LLR: 2.95 (-2.94,2.94) {-1.50,0.50}
Total: 25352 W: 3228 L: 3139 D: 18985
Ptnml(0-2): 175, 2350, 7549, 2415, 187
closes https://github.com/official-stockfish/Stockfish/pull/2804
Bench 4540940
2020-07-10 15:06:55 -06:00
|
|
|
{
|
2020-07-18 07:30:00 -06:00
|
|
|
// if transposition table doesn't have equal or more deep info write probCut data into it
|
Adjust penalty on refuted early quiet moves
This patch changes how previous early moves are penalized in case
search finds a best move. Here, the first quiet move that was not
a transposition table move is penalized.
passed STC
https://tests.stockfishchess.org/tests/view/5f51d839ba100690c5cc5f69
LLR: 2.94 (-2.94,2.94) {-0.25,1.25}
Total: 10088 W: 1150 L: 997 D: 7941
Ptnml(0-2): 41, 772, 3278, 899, 54
passed LTC
https://tests.stockfishchess.org/tests/view/5f51e435ba100690c5cc5f76
LLR: 2.93 (-2.94,2.94) {0.25,1.25}
Total: 30808 W: 1564 L: 1405 D: 27839
Ptnml(0-2): 19, 1245, 12717, 1404, 19
closes https://github.com/official-stockfish/Stockfish/pull/3106
bench 3983758
2020-09-04 06:53:59 -06:00
|
|
|
if ( !(ss->ttHit
|
Do not overwrite valuable TT data after probcut.
This patch allows an engine to write probcut data only in case
the probcut search depth is greater than transposition table depth.
passed STC
https://tests.stockfishchess.org/tests/view/5f0b52e959f6f035328949a6
LLR: 2.97 (-2.94,2.94) {-0.50,1.50}
Total: 52544 W: 10145 L: 9880 D: 32519
Ptnml(0-2): 853, 6097, 12121, 6334, 867
passed LTC
https://tests.stockfishchess.org/tests/view/5f0bd94c59f6f035328949f3
LLR: 2.93 (-2.94,2.94) {0.25,1.75}
Total: 49576 W: 6164 L: 5863 D: 37549
Ptnml(0-2): 297, 4371, 15218, 4538, 364
closes https://github.com/official-stockfish/Stockfish/pull/2815
bench 4578298
2020-07-13 11:30:58 -06:00
|
|
|
&& tte->depth() >= depth - 3
|
|
|
|
&& ttValue != VALUE_NONE))
|
|
|
|
tte->save(posKey, value_to_tt(value, ss->ply), ttPv,
|
|
|
|
BOUND_LOWER,
|
|
|
|
depth - 3, move, ss->staticEval);
|
2011-05-21 10:17:11 -06:00
|
|
|
return value;
|
Maximize usage of transposition table in probcut
Probcut is a heuristic that wasn't changed a lot in past years,
all attempts to change it using information / writing info to transposition table failed.
This patch has a number of differences that can be summarized as follows:
* For TT write/read we use depth - 3. Because probcut search is depth - 4 but we actually do the move prior to it so effectively we do depth - 3 search;
* In any case of depth of eval from transposition table being >= depth - 3 we either produce cutoff or refuse to even do probcut search, this is allowing us to write info of probcut to transposition table because we know that we wouldn't be overwriting some deeper data with our depth - 3 search - this is an important aspect of this patch;
* For some not really known reason this patch completely ignores tte->bound() - which was the case for previous patch that made probcut interact with TT, maybe 2) is the reason, although it's unproven.
A first version of this patch passed STC and LTC
passed STC
https://tests.stockfishchess.org/tests/view/5f05908a59f6f03532894613
LLR: 2.95 (-2.94,2.94) {-0.50,1.50}
Total: 95776 W: 18300 L: 17973 D: 59503
Ptnml(0-2): 1646, 10944, 22377, 11279, 1642
passed LTC
https://tests.stockfishchess.org/tests/view/5f06b54059f6f035328946bb
LLR: 2.94 (-2.94,2.94) {0.25,1.75}
Total: 57128 W: 7266 L: 6938 D: 42924
Ptnml(0-2): 372, 5163, 17217, 5389, 423
However, an additional bugfix was needed to avoid checking a condition on ttMove if was not available. This passed non-regression bounds on top of the first version:
at STC
https://tests.stockfishchess.org/tests/view/5f080e5059f6f03532894766
LLR: 2.94 (-2.94,2.94) {-1.50,0.50}
Total: 14096 W: 2800 L: 2628 D: 8668
Ptnml(0-2): 225, 1620, 3238, 1688, 277
at LTC
https://tests.stockfishchess.org/tests/view/5f0836a559f6f0353289479c
LLR: 2.95 (-2.94,2.94) {-1.50,0.50}
Total: 25352 W: 3228 L: 3139 D: 18985
Ptnml(0-2): 175, 2350, 7549, 2415, 187
closes https://github.com/official-stockfish/Stockfish/pull/2804
Bench 4540940
2020-07-10 15:06:55 -06:00
|
|
|
}
|
2011-05-21 10:17:11 -06:00
|
|
|
}
|
Add / remove leaves from search tree ttPv
add if previous leaf is in search tree and we didn't find a counter move
else remove the position if the leaf is the last one in search tree.
STC : https://tests.stockfishchess.org/tests/view/5f49203c3def640786115314
LLR: 2.95 (-2.94,2.94) {-0.25,1.25}
Total: 29968 W: 3381 L: 3195 D: 23392
Ptnml(0-2): 146, 2432, 9671, 2560, 175
LTC : https://tests.stockfishchess.org/tests/view/5f494bea3def640786115336
LLR: 2.96 (-2.94,2.94) {0.25,1.25}
Total: 84952 W: 4619 L: 4333 D: 76000
Ptnml(0-2): 86, 3765, 34481, 4065, 79
closes https://github.com/official-stockfish/Stockfish/pull/3075
Bench 3527337
2020-08-28 04:06:36 -06:00
|
|
|
ss->ttPv = ttPv;
|
2011-05-21 10:17:11 -06:00
|
|
|
}
|
Update parametes in classical evaluation.
Passed STC (NNUE=False):
https://tests.stockfishchess.org/tests/view/5f42edfe5089a564a10d84a0
LLR: 2.96 (-2.94,2.94) {-0.25,1.25}
Total: 13840 W: 2591 L: 2336 D: 8913
Ptnml(0-2): 194, 1453, 3387, 1676, 210
Passed LTC (NNUE=False):
https://tests.stockfishchess.org/tests/view/5f4369795089a564a10d84d8
LLR: 2.95 (-2.94,2.94) {0.25,1.25}
Total: 159744 W: 19430 L: 18850 D: 121464
Ptnml(0-2): 960, 14185, 49030, 14709, 988
closes https://github.com/official-stockfish/Stockfish/pull/3080
bench: 3736029
2020-08-30 04:58:05 -06:00
|
|
|
|
Decrease depth for cutnodes with no tt move
By analogy to existing logic of decreasing depth for PvNodes w/o tt move
do the same for cutNodes.
Passed STC
https://tests.stockfishchess.org/tests/view/613abf5a689039fce12e1155
LLR: 2.94 (-2.94,2.94) <-0.50,2.50>
Total: 90336 W: 23108 L: 22804 D: 44424
Ptnml(0-2): 286, 10316, 23642, 10656, 268
Passed LTC
https://tests.stockfishchess.org/tests/view/613ae330689039fce12e1172
LLR: 2.94 (-2.94,2.94) <0.50,3.50>
Total: 37736 W: 9607 L: 9346 D: 18783
Ptnml(0-2): 21, 3917, 10730, 4180, 20
closes https://github.com/official-stockfish/Stockfish/pull/3697
bench 5891181
2021-09-10 02:38:50 -06:00
|
|
|
// Step 10. If the position is not in TT, decrease depth by 2 or 1 depending on node type
|
Reintroduce depth reduction
Reintroduce depth reduction if the position is not in TT.
STC https://tests.stockfishchess.org/tests/view/5f4652e85089a564a10d868c
LLR: 2.97 (-2.94,2.94) {-0.25,1.25}
Total: 40240 W: 4535 L: 4331 D: 31374
Ptnml(0-2): 215, 3276, 12969, 3410, 250
LTC https://tests.stockfishchess.org/tests/view/5f46ca5e5089a564a10d86f3
LLR: 2.93 (-2.94,2.94) {0.25,1.25}
Total: 63096 W: 3426 L: 3188 D: 56482
Ptnml(0-2): 51, 2798, 25645, 2970, 84
closes https://github.com/official-stockfish/Stockfish/pull/3072
bench: 3611906
2020-08-28 01:27:15 -06:00
|
|
|
if ( PvNode
|
|
|
|
&& depth >= 6
|
|
|
|
&& !ttMove)
|
|
|
|
depth -= 2;
|
2011-05-21 10:17:11 -06:00
|
|
|
|
Decrease depth for cutnodes with no tt move
By analogy to existing logic of decreasing depth for PvNodes w/o tt move
do the same for cutNodes.
Passed STC
https://tests.stockfishchess.org/tests/view/613abf5a689039fce12e1155
LLR: 2.94 (-2.94,2.94) <-0.50,2.50>
Total: 90336 W: 23108 L: 22804 D: 44424
Ptnml(0-2): 286, 10316, 23642, 10656, 268
Passed LTC
https://tests.stockfishchess.org/tests/view/613ae330689039fce12e1172
LLR: 2.94 (-2.94,2.94) <0.50,3.50>
Total: 37736 W: 9607 L: 9346 D: 18783
Ptnml(0-2): 21, 3917, 10730, 4180, 20
closes https://github.com/official-stockfish/Stockfish/pull/3697
bench 5891181
2021-09-10 02:38:50 -06:00
|
|
|
if ( cutNode
|
|
|
|
&& depth >= 9
|
|
|
|
&& !ttMove)
|
|
|
|
depth--;
|
|
|
|
|
CMH Pruning Tweak
replace CounterMovePruneThreshold by a depth dependent threshold
STC:
LLR: 2.94 (-2.94,2.94) <-0.50,2.50>
Total: 35512 W: 2718 L: 2552 D: 30242
Ptnml(0-2): 66, 2138, 13194, 2280, 78
https://tests.stockfishchess.org/tests/view/6104442fafad2da4f4ae3b94
LTC:
LLR: 2.96 (-2.94,2.94) <0.50,3.50>
Total: 36536 W: 1150 L: 1019 D: 34367
Ptnml(0-2): 10, 920, 16278, 1049, 11
https://tests.stockfishchess.org/tests/view/6104b033afad2da4f4ae3bbc
closes https://github.com/official-stockfish/Stockfish/pull/3636
Bench: 5848718
2021-07-31 06:18:49 -06:00
|
|
|
moves_loop: // When in check, search starts here
|
2010-10-16 03:01:45 -06:00
|
|
|
|
Range reductions
adding reductions for when the delta between the static eval and the child's eval is consistently low.
passed STC
https://tests.stockfishchess.org/html/live_elo.html?614d7b3c7bdc23e77ceb8a5d
LLR: 2.95 (-2.94,2.94) <-0.50,2.50>
Total: 88872 W: 22672 L: 22366 D: 43834
Ptnml(0-2): 343, 10150, 23117, 10510, 316
passed LTC
https://tests.stockfishchess.org/html/live_elo.html?614daf3e7bdc23e77ceb8a82
LLR: 2.93 (-2.94,2.94) <0.50,3.50>
Total: 24368 W: 6153 L: 5928 D: 12287
Ptnml(0-2): 13, 2503, 6937, 2708, 23
closes https://github.com/official-stockfish/Stockfish/pull/3717
Bench: 5443950
2021-09-23 14:16:17 -06:00
|
|
|
int rangeReduction = 0;
|
Introduce ProbCut for check evasions
The idea of this patch can be described as follows: if we are in check
and the transposition table move is a capture that returns a value
far above beta, we can assume that the opponent just blundered a piece
by giving check, and we return the transposition table value. This is
similar to the usual probCut logic for quiet moves, but with a different
threshold.
Passed STC
LLR: 2.94 (-2.94,2.94) {-0.25,1.25}
Total: 33440 W: 3056 L: 2891 D: 27493
Ptnml(0-2): 110, 2338, 11672, 2477, 123
https://tests.stockfishchess.org/tests/view/602cd1087f517a561bc49bda
Passed LTC
LLR: 2.98 (-2.94,2.94) {0.25,1.25}
Total: 10072 W: 401 L: 309 D: 9362
Ptnml(0-2): 2, 288, 4365, 378, 3
https://tests.stockfishchess.org/tests/view/602ceea57f517a561bc49bf0
The committed version has an additional fix to never return unproven wins
in the tablebase range or the mate range. This fix passed tests for non-
regression at STC and LTC:
STC:
LLR: 2.93 (-2.94,2.94) {-1.25,0.25}
Total: 26240 W: 2354 L: 2280 D: 21606
Ptnml(0-2): 85, 1763, 9372, 1793, 107
https://tests.stockfishchess.org/tests/view/602d86a87f517a561bc49c7a
LTC:
LLR: 2.95 (-2.94,2.94) {-0.75,0.25}
Total: 35304 W: 1299 L: 1256 D: 32749
Ptnml(0-2): 14, 1095, 15395, 1130, 18
https://tests.stockfishchess.org/tests/view/602d98d17f517a561bc49c83
Closes https://github.com/official-stockfish/Stockfish/pull/3362
Bench: 3830215
2021-02-20 14:48:08 -07:00
|
|
|
|
|
|
|
// Step 11. A small Probcut idea, when we are in check
|
Tuning Search
This patch tunes constant in search.cpp
STC:
LLR: 2.94 (-2.94,2.94) <-0.50,2.50>
Total: 30648 W: 2580 L: 2410 D: 25658
Ptnml(0-2): 80, 1969, 11093, 2065, 117
https://tests.stockfishchess.org/tests/view/60a71d3cce8ea25a3ef03fae
LTC:
LLR: 2.95 (-2.94,2.94) <0.50,3.50>
Total: 52896 W: 1776 L: 1617 D: 49503
Ptnml(0-2): 13, 1462, 23347, 1605, 21
https://tests.stockfishchess.org/tests/view/60a794ddce8ea25a3ef0400a
closes https://github.com/official-stockfish/Stockfish/pull/3491
Bench: 4004731
2021-05-21 23:47:23 -06:00
|
|
|
probCutBeta = beta + 409;
|
Introduce ProbCut for check evasions
The idea of this patch can be described as follows: if we are in check
and the transposition table move is a capture that returns a value
far above beta, we can assume that the opponent just blundered a piece
by giving check, and we return the transposition table value. This is
similar to the usual probCut logic for quiet moves, but with a different
threshold.
Passed STC
LLR: 2.94 (-2.94,2.94) {-0.25,1.25}
Total: 33440 W: 3056 L: 2891 D: 27493
Ptnml(0-2): 110, 2338, 11672, 2477, 123
https://tests.stockfishchess.org/tests/view/602cd1087f517a561bc49bda
Passed LTC
LLR: 2.98 (-2.94,2.94) {0.25,1.25}
Total: 10072 W: 401 L: 309 D: 9362
Ptnml(0-2): 2, 288, 4365, 378, 3
https://tests.stockfishchess.org/tests/view/602ceea57f517a561bc49bf0
The committed version has an additional fix to never return unproven wins
in the tablebase range or the mate range. This fix passed tests for non-
regression at STC and LTC:
STC:
LLR: 2.93 (-2.94,2.94) {-1.25,0.25}
Total: 26240 W: 2354 L: 2280 D: 21606
Ptnml(0-2): 85, 1763, 9372, 1793, 107
https://tests.stockfishchess.org/tests/view/602d86a87f517a561bc49c7a
LTC:
LLR: 2.95 (-2.94,2.94) {-0.75,0.25}
Total: 35304 W: 1299 L: 1256 D: 32749
Ptnml(0-2): 14, 1095, 15395, 1130, 18
https://tests.stockfishchess.org/tests/view/602d98d17f517a561bc49c83
Closes https://github.com/official-stockfish/Stockfish/pull/3362
Bench: 3830215
2021-02-20 14:48:08 -07:00
|
|
|
if ( ss->inCheck
|
|
|
|
&& !PvNode
|
|
|
|
&& depth >= 4
|
|
|
|
&& ttCapture
|
|
|
|
&& (tte->bound() & BOUND_LOWER)
|
|
|
|
&& tte->depth() >= depth - 3
|
|
|
|
&& ttValue >= probCutBeta
|
|
|
|
&& abs(ttValue) <= VALUE_KNOWN_WIN
|
|
|
|
&& abs(beta) <= VALUE_KNOWN_WIN
|
|
|
|
)
|
|
|
|
return probCutBeta;
|
|
|
|
|
|
|
|
|
2019-02-27 13:25:12 -07:00
|
|
|
const PieceToHistory* contHist[] = { (ss-1)->continuationHistory, (ss-2)->continuationHistory,
|
2019-10-18 07:23:00 -06:00
|
|
|
nullptr , (ss-4)->continuationHistory,
|
|
|
|
nullptr , (ss-6)->continuationHistory };
|
2019-03-31 03:47:36 -06:00
|
|
|
|
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,
|
Improve move order near the root
Current move histories are known to work well near the leaves, whilst at
higher depths they aren't very helpful. To address this problem this
patch introduces a table dedicated for what's happening at plies 0-3.
It's structured like mainHistory with ply index instead of color.
It get cleared with each new search and is filled during iterative
deepening at higher depths when recording successful quiet moves near
the root or traversing nodes which were in the principal variation
(ttPv).
Medium TC (20+0.2):
https://tests.stockfishchess.org/tests/view/5e4d358790a0a02810d096dc
LLR: 2.94 (-2.94,2.94) {-0.50,1.50}
Total: 100910 W: 16682 L: 16376 D: 67852
Ptnml(0-2): 1177, 10983, 25883, 11181, 1231
LTC:
https://tests.stockfishchess.org/tests/view/5e4e2cb790a0a02810d09714
LLR: 2.95 (-2.94,2.94) {0.25,1.75}
Total: 80444 W: 10495 L: 10095 D: 59854
Ptnml(0-2): 551, 7479, 23803, 7797, 592
closes https://github.com/official-stockfish/Stockfish/pull/2557
Bench: 4705960
2020-02-21 06:01:59 -07:00
|
|
|
&thisThread->lowPlyHistory,
|
Introduce capture history pruning
This patch introduces a heuristic that is similar to countermove based pruning but for captures - capture history pruning. The idea is that we can (almost) safely prune really late captures with negative history if they don't give check so will most likely not produce some king-attacking tactic.
passed STC
https://tests.stockfishchess.org/tests/view/5e8c60d40ffd2be7f15e5470
LLR: 2.94 (-2.94,2.94) {-0.50,1.50}
Total: 23748 W: 4758 L: 4529 D: 14461
Ptnml(0-2): 421, 2712, 5400, 2899, 442
passed LTC
https://tests.stockfishchess.org/tests/view/5e8c72bf0ffd2be7f15e547f
LLR: 2.96 (-2.94,2.94) {0.25,1.75}
Total: 17330 W: 2415 L: 2190 D: 12725
Ptnml(0-2): 126, 1561, 5107, 1704, 167
closes https://github.com/official-stockfish/Stockfish/pull/2618
bench 4417023
2020-04-07 07:53:24 -06:00
|
|
|
&captureHistory,
|
2018-04-28 22:48:18 -06:00
|
|
|
contHist,
|
|
|
|
countermove,
|
Improve move order near the root
Current move histories are known to work well near the leaves, whilst at
higher depths they aren't very helpful. To address this problem this
patch introduces a table dedicated for what's happening at plies 0-3.
It's structured like mainHistory with ply index instead of color.
It get cleared with each new search and is filled during iterative
deepening at higher depths when recording successful quiet moves near
the root or traversing nodes which were in the principal variation
(ttPv).
Medium TC (20+0.2):
https://tests.stockfishchess.org/tests/view/5e4d358790a0a02810d096dc
LLR: 2.94 (-2.94,2.94) {-0.50,1.50}
Total: 100910 W: 16682 L: 16376 D: 67852
Ptnml(0-2): 1177, 10983, 25883, 11181, 1231
LTC:
https://tests.stockfishchess.org/tests/view/5e4e2cb790a0a02810d09714
LLR: 2.95 (-2.94,2.94) {0.25,1.75}
Total: 80444 W: 10495 L: 10095 D: 59854
Ptnml(0-2): 551, 7479, 23803, 7797, 592
closes https://github.com/official-stockfish/Stockfish/pull/2557
Bench: 4705960
2020-02-21 06:01:59 -07:00
|
|
|
ss->killers,
|
Use lowply-history also on low depths
STC:
https://tests.stockfishchess.org/tests/view/5ed75078f29b40b0fc95a8b9
LLR: 2.93 (-2.94,2.94) {-0.50,1.50}
Total: 73928 W: 14301 L: 14005 D: 45622
Ptnml(0-2): 1243, 8572, 17096, 8752, 1301
LTC:
https://tests.stockfishchess.org/tests/view/5ed895e0f29b40b0fc95a976
LLR: 2.93 (-2.94,2.94) {0.25,1.75}
Total: 154848 W: 19684 L: 19074 D: 116090
Ptnml(0-2): 1048, 14108, 46627, 14468, 1173
closes https://github.com/official-stockfish/Stockfish/pull/2718
bench: 4582693
2020-06-06 04:56:38 -06:00
|
|
|
ss->ply);
|
2013-08-09 00:21:55 -06:00
|
|
|
|
2019-10-18 07:23:00 -06:00
|
|
|
value = bestValue;
|
Remove noLMRExtension flag
This simplification patch removes the noLMRExtension flag. It was introduced in June
(see following link for that commit), but does not seem to be necessary anymore.
Link: https://github.com/official-stockfish/Stockfish/commit/e1f181ee643dcaa92c606b74b3abd23dede136cd
STC:
LLR: 2.94 (-2.94,2.94) <-2.50,0.50>
Total: 21200 W: 5369 L: 5228 D: 10603
Ptnml(0-2): 67, 2355, 5616, 2494, 68
https://tests.stockfishchess.org/tests/view/616c03d299b580bf37797dcb
LTC:
LLR: 2.94 (-2.94,2.94) <-2.50,0.50>
Total: 37536 W: 9387 L: 9278 D: 18871
Ptnml(0-2): 23, 3988, 10643, 4085, 29
https://tests.stockfishchess.org/tests/view/616c10f499b580bf37797ddd
closes https://github.com/official-stockfish/Stockfish/pull/3743
Bench: 4792969
2021-10-17 05:06:33 -06:00
|
|
|
singularQuietLMR = moveCountPruning = false;
|
2010-10-16 03:01:45 -06:00
|
|
|
|
Cleanup of likelyFailLow logic
This patch broadens and simplifies definition of PvNode that is likely to fail low.
New definition can be described as following "If node was already researched
at depth >= current depth and failed low there" which is more logical than the
previous version and takes less space + allows to not recompute it every time during move loop.
Passed simplification STC
https://tests.stockfishchess.org/tests/view/609148bf95e7f1852abd2e82
LLR: 2.93 (-2.94,2.94) <-2.50,0.50>
Total: 20128 W: 1865 L: 1751 D: 16512
Ptnml(0-2): 63, 1334, 7165, 1430, 72
Passed simplification LTC
https://tests.stockfishchess.org/tests/view/6091691295e7f1852abd2e8b
LLR: 2.94 (-2.94,2.94) <-2.50,0.50>
Total: 95128 W: 3498 L: 3481 D: 88149
Ptnml(0-2): 41, 2956, 41549, 2981, 37
closes https://github.com/official-stockfish/Stockfish/pull/3455
Bench: 3933037
2021-05-05 10:03:20 -06:00
|
|
|
// Indicate PvNodes that will probably fail low if the node was searched
|
|
|
|
// at a depth equal or greater than the current depth, and the result of this search was a fail low.
|
|
|
|
bool likelyFailLow = PvNode
|
|
|
|
&& ttMove
|
|
|
|
&& (tte->bound() & BOUND_UPPER)
|
|
|
|
&& tte->depth() >= depth;
|
|
|
|
|
Introduce ProbCut for check evasions
The idea of this patch can be described as follows: if we are in check
and the transposition table move is a capture that returns a value
far above beta, we can assume that the opponent just blundered a piece
by giving check, and we return the transposition table value. This is
similar to the usual probCut logic for quiet moves, but with a different
threshold.
Passed STC
LLR: 2.94 (-2.94,2.94) {-0.25,1.25}
Total: 33440 W: 3056 L: 2891 D: 27493
Ptnml(0-2): 110, 2338, 11672, 2477, 123
https://tests.stockfishchess.org/tests/view/602cd1087f517a561bc49bda
Passed LTC
LLR: 2.98 (-2.94,2.94) {0.25,1.25}
Total: 10072 W: 401 L: 309 D: 9362
Ptnml(0-2): 2, 288, 4365, 378, 3
https://tests.stockfishchess.org/tests/view/602ceea57f517a561bc49bf0
The committed version has an additional fix to never return unproven wins
in the tablebase range or the mate range. This fix passed tests for non-
regression at STC and LTC:
STC:
LLR: 2.93 (-2.94,2.94) {-1.25,0.25}
Total: 26240 W: 2354 L: 2280 D: 21606
Ptnml(0-2): 85, 1763, 9372, 1793, 107
https://tests.stockfishchess.org/tests/view/602d86a87f517a561bc49c7a
LTC:
LLR: 2.95 (-2.94,2.94) {-0.75,0.25}
Total: 35304 W: 1299 L: 1256 D: 32749
Ptnml(0-2): 14, 1095, 15395, 1130, 18
https://tests.stockfishchess.org/tests/view/602d98d17f517a561bc49c83
Closes https://github.com/official-stockfish/Stockfish/pull/3362
Bench: 3830215
2021-02-20 14:48:08 -07:00
|
|
|
// Step 12. Loop through all pseudo-legal moves until no moves remain
|
2018-02-12 14:57:42 -07:00
|
|
|
// 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
|
|
|
|
Do move legality check before pruning.
This alllows to simplify the code because the move counter haven't to be
decremented later if a move isn't legal. As a side effect now illegal
pruned moves doesn't included anymore in move counter. So slightly less
pruning and reductions are done.
STC:
LLR: 2.94 (-2.94,2.94) {-1.50,0.50}
Total: 111016 W: 21106 L: 21077 D: 68833
Ptnml(0-2): 1830, 13083, 25736, 12946, 1913
https://tests.stockfishchess.org/tests/view/5f28816fa5abc164f05e4c26
LTC:
LLR: 2.94 (-2.94,2.94) {-1.50,0.50}
Total: 39264 W: 4909 L: 4843 D: 29512
Ptnml(0-2): 263, 3601, 11854, 3635, 279
https://tests.stockfishchess.org/tests/view/5f297902a5abc164f05e4c8e
closes https://github.com/official-stockfish/Stockfish/pull/2906
Bench: 4390086
2020-08-05 01:29:27 -06:00
|
|
|
// Check for legality
|
|
|
|
if (!rootNode && !pos.legal(move))
|
|
|
|
continue;
|
|
|
|
|
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)
|
2019-09-28 14:27:23 -06:00
|
|
|
sync_cout << "info depth " << depth
|
2015-12-09 00:07:34 -07:00
|
|
|
<< " 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
|
|
|
|
2019-09-28 14:27:23 -06:00
|
|
|
extension = 0;
|
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);
|
2019-03-31 02:44:55 -06:00
|
|
|
givesCheck = pos.gives_check(move);
|
2014-02-08 05:21:50 -07:00
|
|
|
|
2019-11-12 10:36:12 -07:00
|
|
|
// Calculate new depth for this move
|
|
|
|
newDepth = depth - 1;
|
|
|
|
|
2021-08-05 08:34:37 -06:00
|
|
|
// Step 13. Pruning at shallow depth (~200 Elo). Depth conditions are important for mate finding.
|
2019-11-12 10:36:12 -07:00
|
|
|
if ( !rootNode
|
|
|
|
&& pos.non_pawn_material(us)
|
Fix for incorrect VALUE_MATE_IN_MAX_PLY usage.
Fixes #2533, fixes #2543, fixes #2423.
the code that prevents false mate announcements depending on the TT
state (GHI), incorrectly used VALUE_MATE_IN_MAX_PLY. The latter
constant, however, also includes, counterintuitively, the TB win range.
This patch fixes that, by restoring the behavior for TB win scores,
while retaining the false mate correctness, and improving the mate
finding ability. In particular
no alse mates are announced with the poisened hash testcase
```
position fen 8/8/8/3k4/8/8/6K1/7R w - - 0 1
go depth 40
position fen 8/8/8/3k4/8/8/6K1/7R w - - 76 1
go depth 20
ucinewgame
```
mates are found with the testcases reported in #2543
```
position fen 4k3/3pp3/8/8/8/8/2PPP3/4K3 w - - 0 1
setoption name Hash value 1024
go depth 55
ucinewgame
```
and
```
position fen 4k3/4p3/8/8/8/8/3PP3/4K3 w - - 0 1
setoption name Hash value 1024
go depth 45
ucinewgame
```
furthermore, on the mate finding benchmark (ChestUCI_23102018.epd),
performance improves over master, roughly reaching performance with the
false mate protection reverted
```
Analyzing 6566 mate positions for best and found mates:
----------------best ---------------found
nodes master revert fixed master revert fixed
16000000 4233 4236 4235 5200 5201 5199
32000000 4583 4585 4585 5417 5424 5418
64000000 4852 4853 4855 5575 5584 5579
128000000 5071 5068 5066 5710 5720 5716
256000000 5280 5282 5279 5819 5827 5826
512000000 5471 5468 5468 5919 5935 5932
```
On a testcase with TB enabled, progress is made consistently, contrary
to master
```
setoption name SyzygyPath value ../../../syzygy/3-4-5/
setoption name Hash value 2048
position fen 1R6/3k4/8/K2p4/4n3/2P5/8/8 w - - 0 1
go depth 58
ucinewgame
```
The PR (prior to a rewrite for clarity)
passed STC:
LLR: 2.94 (-2.94,2.94) {-1.50,0.50}
Total: 65405 W: 12454 L: 12384 D: 40567
Ptnml(0-2): 920, 7256, 16285, 7286, 944
http://tests.stockfishchess.org/tests/view/5e441a3be70d848499f63d15
passed LTC:
LLR: 2.94 (-2.94,2.94) {-1.50,0.50}
Total: 27096 W: 3477 L: 3413 D: 20206
Ptnml(0-2): 128, 2215, 8776, 2292, 122
http://tests.stockfishchess.org/tests/view/5e44e277e70d848499f63d63
The incorrectly named VALUE_MATE_IN_MAX_PLY and VALUE_MATED_IN_MAX_PLY
were renamed into VALUE_TB_WIN_IN_MAX_PLY and VALUE_TB_LOSS_IN_MAX_PLY,
and correclty defined VALUE_MATE_IN_MAX_PLY and VALUE_MATED_IN_MAX_PLY
were introduced.
One further (corner case) mistake using these constants was fixed (go
mate X), which could lead to a premature return if X > MAX_PLY / 2,
but TB were present.
Thanks to @svivanov72 for one of the reports and help fixing the issue.
closes https://github.com/official-stockfish/Stockfish/pull/2552
Bench: 4932981
2020-02-11 12:42:32 -07:00
|
|
|
&& bestValue > VALUE_TB_LOSS_IN_MAX_PLY)
|
2019-11-12 10:36:12 -07:00
|
|
|
{
|
|
|
|
// Skip quiet moves if movecount exceeds our FutilityMoveCount threshold
|
|
|
|
moveCountPruning = moveCount >= futility_move_count(improving, depth);
|
|
|
|
|
Introduce capture history pruning
This patch introduces a heuristic that is similar to countermove based pruning but for captures - capture history pruning. The idea is that we can (almost) safely prune really late captures with negative history if they don't give check so will most likely not produce some king-attacking tactic.
passed STC
https://tests.stockfishchess.org/tests/view/5e8c60d40ffd2be7f15e5470
LLR: 2.94 (-2.94,2.94) {-0.50,1.50}
Total: 23748 W: 4758 L: 4529 D: 14461
Ptnml(0-2): 421, 2712, 5400, 2899, 442
passed LTC
https://tests.stockfishchess.org/tests/view/5e8c72bf0ffd2be7f15e547f
LLR: 2.96 (-2.94,2.94) {0.25,1.75}
Total: 17330 W: 2415 L: 2190 D: 12725
Ptnml(0-2): 126, 1561, 5107, 1704, 167
closes https://github.com/official-stockfish/Stockfish/pull/2618
bench 4417023
2020-04-07 07:53:24 -06:00
|
|
|
// Reduced depth of the next LMR search
|
Range reductions
adding reductions for when the delta between the static eval and the child's eval is consistently low.
passed STC
https://tests.stockfishchess.org/html/live_elo.html?614d7b3c7bdc23e77ceb8a5d
LLR: 2.95 (-2.94,2.94) <-0.50,2.50>
Total: 88872 W: 22672 L: 22366 D: 43834
Ptnml(0-2): 343, 10150, 23117, 10510, 316
passed LTC
https://tests.stockfishchess.org/html/live_elo.html?614daf3e7bdc23e77ceb8a82
LLR: 2.93 (-2.94,2.94) <0.50,3.50>
Total: 24368 W: 6153 L: 5928 D: 12287
Ptnml(0-2): 13, 2503, 6937, 2708, 23
closes https://github.com/official-stockfish/Stockfish/pull/3717
Bench: 5443950
2021-09-23 14:16:17 -06:00
|
|
|
int lmrDepth = std::max(newDepth - reduction(improving, depth, moveCount, rangeReduction > 2), 0);
|
Introduce capture history pruning
This patch introduces a heuristic that is similar to countermove based pruning but for captures - capture history pruning. The idea is that we can (almost) safely prune really late captures with negative history if they don't give check so will most likely not produce some king-attacking tactic.
passed STC
https://tests.stockfishchess.org/tests/view/5e8c60d40ffd2be7f15e5470
LLR: 2.94 (-2.94,2.94) {-0.50,1.50}
Total: 23748 W: 4758 L: 4529 D: 14461
Ptnml(0-2): 421, 2712, 5400, 2899, 442
passed LTC
https://tests.stockfishchess.org/tests/view/5e8c72bf0ffd2be7f15e547f
LLR: 2.96 (-2.94,2.94) {0.25,1.75}
Total: 17330 W: 2415 L: 2190 D: 12725
Ptnml(0-2): 126, 1561, 5107, 1704, 167
closes https://github.com/official-stockfish/Stockfish/pull/2618
bench 4417023
2020-04-07 07:53:24 -06:00
|
|
|
|
2021-01-01 02:59:35 -07:00
|
|
|
if ( captureOrPromotion
|
|
|
|
|| givesCheck)
|
|
|
|
{
|
|
|
|
// Capture history based pruning when the move doesn't give check
|
|
|
|
if ( !givesCheck
|
|
|
|
&& lmrDepth < 1
|
|
|
|
&& captureHistory[movedPiece][to_sq(move)][type_of(pos.piece_on(to_sq(move)))] < 0)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
// SEE based pruning
|
|
|
|
if (!pos.see_ge(move, Value(-218) * depth)) // (~25 Elo)
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
else
|
2019-11-12 10:36:12 -07:00
|
|
|
{
|
2021-05-17 01:13:34 -06:00
|
|
|
// Continuation history based pruning (~20 Elo)
|
CMH Pruning Tweak
Tweak pruning formula by adding up CMH values.
STC:
LLR: 2.94 (-2.94,2.94) <-0.50,2.50>
Total: 14608 W: 3837 L: 3641 D: 7130
Ptnml(0-2): 27, 1681, 3723, 1815, 58
https://tests.stockfishchess.org/tests/view/612792f362d20cf82b5ad156
LTC:
LLR: 2.94 (-2.94,2.94) <0.50,3.50>
Total: 53520 W: 13580 L: 13276 D: 26664
Ptnml(0-2): 28, 5610, 15183, 5908, 31
https://tests.stockfishchess.org/tests/view/6127d27062d20cf82b5ad191
closes https://github.com/official-stockfish/Stockfish/pull/3682
Bench: 5186641
2021-08-27 12:25:09 -06:00
|
|
|
if (lmrDepth < 5
|
|
|
|
&& (*contHist[0])[movedPiece][to_sq(move)]
|
|
|
|
+ (*contHist[1])[movedPiece][to_sq(move)]
|
|
|
|
+ (*contHist[3])[movedPiece][to_sq(move)] < -3000 * depth + 3000)
|
2019-11-12 10:36:12 -07:00
|
|
|
continue;
|
|
|
|
|
2020-01-09 19:02:09 -07:00
|
|
|
// Futility pruning: parent node (~5 Elo)
|
Remove second futility pruning depth limit
This patch removes futility pruning lmrDepth limit for futility pruning at parent nodes.
Since it's already capped by margin that is a function of lmrDepth there is no need to extra cap it with lmrDepth.
passed STC
https://tests.stockfishchess.org/tests/view/60e9b5dfd1189bed71812777
LLR: 2.97 (-2.94,2.94) <-2.50,0.50>
Total: 14872 W: 1264 L: 1145 D: 12463
Ptnml(0-2): 37, 942, 5369, 1041, 47
passed LTC
https://tests.stockfishchess.org/tests/view/60e9c635d1189bed71812790
LLR: 2.96 (-2.94,2.94) <-2.50,0.50>
Total: 40336 W: 1280 L: 1225 D: 37831
Ptnml(0-2): 24, 1057, 17960, 1094, 33
closes https://github.com/official-stockfish/Stockfish/pull/3612
bench: 5064969
2021-07-10 15:09:15 -06:00
|
|
|
if ( !ss->inCheck
|
Combo of various parameter tweaks
Combination of parameter tweaks in search, evaluation and time management.
Original patches by snicolet xoto10 lonfom169 and Vizvezdenec.
Includes:
* Use bigger grain of positional evaluation more frequently (up to 1 exchange difference in non-pawn-material);
* More extra time according to increment;
* Increase margin for singular extensions;
* Do more aggresive parent node futility pruning.
Passed STC
https://tests.stockfishchess.org/tests/view/6147deab3733d0e0dd9f313d
LLR: 2.94 (-2.94,2.94) <-0.50,2.50>
Total: 45488 W: 11691 L: 11450 D: 22347
Ptnml(0-2): 145, 5208, 11824, 5395, 172
Passed LTC
https://tests.stockfishchess.org/tests/view/6147f1d53733d0e0dd9f3141
LLR: 2.94 (-2.94,2.94) <0.50,3.50>
Total: 62520 W: 15808 L: 15482 D: 31230
Ptnml(0-2): 43, 6439, 17960, 6785, 33
closes https://github.com/official-stockfish/Stockfish/pull/3710
bench 5575265
2021-09-20 06:04:13 -06:00
|
|
|
&& lmrDepth < 8
|
|
|
|
&& ss->staticEval + 172 + 145 * lmrDepth <= alpha)
|
2019-11-12 10:36:12 -07:00
|
|
|
continue;
|
|
|
|
|
2020-01-09 19:02:09 -07:00
|
|
|
// Prune moves with negative SEE (~20 Elo)
|
SEE simplification
Simplified SEE formula by removing std::min. Should also be easier to tune.
STC:
LLR: 2.95 (-2.94,2.94) <-2.50,0.50>
Total: 22656 W: 1836 L: 1729 D: 19091
Ptnml(0-2): 54, 1426, 8267, 1521, 60
https://tests.stockfishchess.org/tests/view/610ae62f2a8a49ac5be79449
LTC:
LLR: 2.93 (-2.94,2.94) <-2.50,0.50>
Total: 26248 W: 806 L: 744 D: 24698
Ptnml(0-2): 6, 668, 11715, 728, 7
https://tests.stockfishchess.org/tests/view/610b17ad2a8a49ac5be79466
closes https://github.com/official-stockfish/Stockfish/pull/3643
bench: 4915145
2021-08-05 06:50:24 -06:00
|
|
|
if (!pos.see_ge(move, Value(-21 * lmrDepth * lmrDepth - 21 * lmrDepth)))
|
2019-11-12 10:36:12 -07:00
|
|
|
continue;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
Introduce ProbCut for check evasions
The idea of this patch can be described as follows: if we are in check
and the transposition table move is a capture that returns a value
far above beta, we can assume that the opponent just blundered a piece
by giving check, and we return the transposition table value. This is
similar to the usual probCut logic for quiet moves, but with a different
threshold.
Passed STC
LLR: 2.94 (-2.94,2.94) {-0.25,1.25}
Total: 33440 W: 3056 L: 2891 D: 27493
Ptnml(0-2): 110, 2338, 11672, 2477, 123
https://tests.stockfishchess.org/tests/view/602cd1087f517a561bc49bda
Passed LTC
LLR: 2.98 (-2.94,2.94) {0.25,1.25}
Total: 10072 W: 401 L: 309 D: 9362
Ptnml(0-2): 2, 288, 4365, 378, 3
https://tests.stockfishchess.org/tests/view/602ceea57f517a561bc49bf0
The committed version has an additional fix to never return unproven wins
in the tablebase range or the mate range. This fix passed tests for non-
regression at STC and LTC:
STC:
LLR: 2.93 (-2.94,2.94) {-1.25,0.25}
Total: 26240 W: 2354 L: 2280 D: 21606
Ptnml(0-2): 85, 1763, 9372, 1793, 107
https://tests.stockfishchess.org/tests/view/602d86a87f517a561bc49c7a
LTC:
LLR: 2.95 (-2.94,2.94) {-0.75,0.25}
Total: 35304 W: 1299 L: 1256 D: 32749
Ptnml(0-2): 14, 1095, 15395, 1130, 18
https://tests.stockfishchess.org/tests/view/602d98d17f517a561bc49c83
Closes https://github.com/official-stockfish/Stockfish/pull/3362
Bench: 3830215
2021-02-20 14:48:08 -07:00
|
|
|
// Step 14. Extensions (~75 Elo)
|
2008-08-31 23:59:13 -06:00
|
|
|
|
2020-01-09 19:02:09 -07:00
|
|
|
// Singular extension search (~70 Elo). If all moves but one fail low on a
|
2018-04-02 16:13:35 -06:00
|
|
|
// 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
|
Remove late irreversible move extension
We simplify away the late irreversible move extension, which
does not seem to be necessary in the current master.
STC
LLR: 2.93 (-2.94,2.94) {-1.50,0.50}
Total: 38584 W: 7464 L: 7342 D: 23778
Ptnml(0-2): 581, 4328, 9365, 4424, 594
https://tests.stockfishchess.org/tests/view/5f1c9669c09435d870cb9de9
LTC
LLR: 2.94 (-2.94,2.94) {-1.50,0.50}
Total: 27840 W: 3417 L: 3353 D: 21070
Ptnml(0-2): 120, 2315, 8994, 2363, 128
https://tests.stockfishchess.org/tests/view/5f1d2e22c09435d870cb9e21
closes https://github.com/official-stockfish/Stockfish/pull/2836
bench: 4829420
2020-07-25 14:30:05 -06:00
|
|
|
// result is lower than ttValue minus a margin, then we will extend the ttMove.
|
Introducing NodeType Root
We transform rootNode into constexpr by adding a new NodeType `Root`,
which causes a speed up.
Local test:
```
Build Tester: 1.4.7.0
Windows 10 (Version 10.0, Build 0, 64-bit Edition)
Intel(R) Core(TM) i7-8750H CPU @ 2.20GHz
SafeMode: No
Running In VM: No
HyperThreading Enabled: Yes
CPU Warmup: Yes
Command Line: bench
Tests per Build: 25
ANOVA: n/a
Engine# (NPS) Speedup Sp Conf. 95% S.S.
patch (920.179,4) ---> master (906.329,2) ---> 1,528% 20.336,5 Yes No
```
---------
STC:
LLR: 2.94 (-2.94,2.94) <-0.50,2.50>
Total: 98216 W: 8348 L: 8102 D: 81766
Ptnml(0-2): 295, 6357, 35549, 6621, 286
https://tests.stockfishchess.org/tests/view/60b797e2457376eb8bcaa0ab
Yellow LTC:
LLR: -2.95 (-2.94,2.94) <0.50,3.50>
Total: 76936 W: 2651 L: 2626 D: 71659
Ptnml(0-2): 29, 2233, 33916, 2264, 26
https://tests.stockfishchess.org/tests/view/60b80d6d457376eb8bcaa145
closes https://github.com/official-stockfish/Stockfish/pull/3522
No functional change
2021-06-03 10:52:39 -06:00
|
|
|
if ( !rootNode
|
|
|
|
&& depth >= 7
|
2012-04-28 04:08:10 -06:00
|
|
|
&& move == ttMove
|
2018-12-11 05:47:56 -07:00
|
|
|
&& !excludedMove // Avoid recursive singular search
|
2019-03-31 04:02:19 -06:00
|
|
|
/* && ttValue != VALUE_NONE Already implicit in the next condition */
|
2019-03-09 05:24:26 -07:00
|
|
|
&& abs(ttValue) < VALUE_KNOWN_WIN
|
2018-04-02 16:13:35 -06:00
|
|
|
&& (tte->bound() & BOUND_LOWER)
|
2020-08-08 04:07:07 -06:00
|
|
|
&& tte->depth() >= depth - 3)
|
2009-11-21 06:22:52 -07:00
|
|
|
{
|
Combo of various parameter tweaks
Combination of parameter tweaks in search, evaluation and time management.
Original patches by snicolet xoto10 lonfom169 and Vizvezdenec.
Includes:
* Use bigger grain of positional evaluation more frequently (up to 1 exchange difference in non-pawn-material);
* More extra time according to increment;
* Increase margin for singular extensions;
* Do more aggresive parent node futility pruning.
Passed STC
https://tests.stockfishchess.org/tests/view/6147deab3733d0e0dd9f313d
LLR: 2.94 (-2.94,2.94) <-0.50,2.50>
Total: 45488 W: 11691 L: 11450 D: 22347
Ptnml(0-2): 145, 5208, 11824, 5395, 172
Passed LTC
https://tests.stockfishchess.org/tests/view/6147f1d53733d0e0dd9f3141
LLR: 2.94 (-2.94,2.94) <0.50,3.50>
Total: 62520 W: 15808 L: 15482 D: 31230
Ptnml(0-2): 43, 6439, 17960, 6785, 33
closes https://github.com/official-stockfish/Stockfish/pull/3710
bench 5575265
2021-09-20 06:04:13 -06:00
|
|
|
Value singularBeta = ttValue - 3 * depth;
|
Remove formerPV variable.
STC:
LLR: 2.94 (-2.94,2.94) <-2.50,0.50>
Total: 75672 W: 6546 L: 6496 D: 62630
Ptnml(0-2): 238, 5274, 26761, 5326, 237
https://tests.stockfishchess.org/tests/view/60b349c0ec0c03148cbed055
LTC:
LLR: 2.98 (-2.94,2.94) <-2.50,0.50>
Total: 137816 W: 4676 L: 4689 D: 128451
Ptnml(0-2): 52, 4237, 60354, 4202, 63
https://tests.stockfishchess.org/tests/view/60b38970ec0c03148cbed075
closes https://github.com/official-stockfish/Stockfish/pull/3515
Bench: 4892288
2021-05-31 12:26:05 -06:00
|
|
|
Depth singularDepth = (depth - 1) / 2;
|
2021-03-19 12:43:25 -06:00
|
|
|
|
2012-07-14 05:18:14 -06:00
|
|
|
ss->excludedMove = move;
|
Adjust singular extension search depth
This patch applies a different singular extension search logic in case the position is ttPv && !PvNode.
It changes the depth of this search, higher for this types of nodes, and lower for other nodes.
passed STC
http://tests.stockfishchess.org/tests/view/5e72bbaae42a5c3b3ca2e75e
LLR: 2.94 (-2.94,2.94) {-0.50,1.50}
Total: 12692 W: 2608 L: 2389 D: 7695
Ptnml(0-2): 238, 1414, 2839, 1601, 254
passed LTC
http://tests.stockfishchess.org/tests/view/5e731c07e42a5c3b3ca2e770
LLR: 2.96 (-2.94,2.94) {0.25,1.75}
Total: 145716 W: 19218 L: 18626 D: 107872
Ptnml(0-2): 1100, 13605, 42899, 14111, 1143
closes https://github.com/official-stockfish/Stockfish/pull/2590
Bench: 5398277
2020-03-20 03:12:56 -06:00
|
|
|
value = search<NonPV>(pos, ss, singularBeta - 1, singularBeta, singularDepth, cutNode);
|
2012-07-14 05:18:14 -06:00
|
|
|
ss->excludedMove = MOVE_NONE;
|
|
|
|
|
2019-01-05 13:53:21 -07:00
|
|
|
if (value < singularBeta)
|
2019-05-02 11:36:25 -06:00
|
|
|
{
|
2019-09-28 14:27:23 -06:00
|
|
|
extension = 1;
|
Singular quiet LMR
If ttMove is a capture and had a singular extension, it is probably the best move.
No need to make a decrease of LMR on other moves.
STC
LLR: 2.96 (-2.94,2.94) {-0.50,1.50}
Total: 41968 W: 8170 L: 7918 D: 25880
Ptnml(0-2): 733, 4770, 9726, 5022, 733
https://tests.stockfishchess.org/tests/view/5ed6b666f29b40b0fc95a884
LTC
LLR: 2.95 (-2.94,2.94) {0.25,1.75}
Total: 71376 W: 9200 L: 8827 D: 53349
Ptnml(0-2): 486, 6544, 21342, 6743, 573
https://tests.stockfishchess.org/tests/view/5ed7578bf29b40b0fc95a8c9
closes https://github.com/official-stockfish/Stockfish/pull/2713
Bench: 4733799
2020-06-02 14:27:11 -06:00
|
|
|
singularQuietLMR = !ttCapture;
|
Limit double extensions
Double extensions can lead to search explosions, for specific positions.
Currently, however, these double extensions are worth about 10Elo and cannot
be removed. This patch instead limits the number of double extensions given
to a maximum of 3.
This fixes https://github.com/official-stockfish/Stockfish/issues/3532
where the following testcase was shown to be problematic:
```
uci
setoption name Hash value 4
setoption name Contempt value 0
ucinewgame
position fen 8/Pk6/8/1p6/8/P1K5/8/6B1 w - - 37 130
go depth 20
```
passed STC:
https://tests.stockfishchess.org/tests/view/60c13161457376eb8bcaaa0f
LLR: 2.95 (-2.94,2.94) <-2.50,0.50>
Total: 73256 W: 6114 L: 6062 D: 61080
Ptnml(0-2): 222, 4912, 26306, 4968, 220
passed LTC:
https://tests.stockfishchess.org/tests/view/60c196fb457376eb8bcaaa6b
LLR: 2.94 (-2.94,2.94) <-2.50,0.50>
Total: 166440 W: 5559 L: 5594 D: 155287
Ptnml(0-2): 106, 4921, 73197, 4894, 102
closes https://github.com/official-stockfish/Stockfish/pull/3544
Bench: 5067605
2021-06-09 15:23:13 -06:00
|
|
|
|
Detect search explosions
This patch detects some search explosions (due to double extensions in
search.cpp) which can happen in some pathological positions, and takes
measures to ensure progress in search even for these pathological situations.
While a small number of double extensions can be useful during search
(for example to resolve a tactical sequence), a sustained regime of
double extensions leads to search explosion and a non-finishing search.
See the discussion in https://github.com/official-stockfish/Stockfish/pull/3544
and the issue https://github.com/official-stockfish/Stockfish/issues/3532 .
The implemented algorithm is the following:
a) at each node during search, store the current depth in the stack.
Double extensions are by definition levels of the stack where the
depth at ply N is strictly higher than depth at ply N-1.
b) during search, calculate for each thread a running average of the
number of double extensions in the last 4096 visited nodes.
c) if one thread has more than 2% of double extensions for a sustained
period of time (6 millions consecutive nodes, or about 4 seconds on
my iMac), we decide that this thread is in an explosion state and
we calm down this thread by preventing it to do any double extension
for the next 6 millions nodes.
To calculate the running averages, we also introduced a auxiliary class
generalizing the computations of ttHitAverage variable we already had in
code. The implementation uses an exponential moving average of period 4096
and resolution 1/1024, and all computations are done with integers for
efficiency.
-----------
Example where the patch solves a search explosion:
```
./stockfish
ucinewgame
position fen 8/Pk6/8/1p6/8/P1K5/8/6B1 w - - 37 130
go infinite
```
This algorithm does not affect search in normal, non-pathological positions.
We verified, for instance, that the usual bench is unchanged up to depth 20
at least, and that the node numbers are unchanged for a search of the starting
position at depth 32.
-------------
See https://github.com/official-stockfish/Stockfish/pull/3714
Bench: 5575265
2021-09-23 15:19:06 -06:00
|
|
|
// Avoid search explosion by limiting the number of double extensions
|
Limit double extensions
Double extensions can lead to search explosions, for specific positions.
Currently, however, these double extensions are worth about 10Elo and cannot
be removed. This patch instead limits the number of double extensions given
to a maximum of 3.
This fixes https://github.com/official-stockfish/Stockfish/issues/3532
where the following testcase was shown to be problematic:
```
uci
setoption name Hash value 4
setoption name Contempt value 0
ucinewgame
position fen 8/Pk6/8/1p6/8/P1K5/8/6B1 w - - 37 130
go depth 20
```
passed STC:
https://tests.stockfishchess.org/tests/view/60c13161457376eb8bcaaa0f
LLR: 2.95 (-2.94,2.94) <-2.50,0.50>
Total: 73256 W: 6114 L: 6062 D: 61080
Ptnml(0-2): 222, 4912, 26306, 4968, 220
passed LTC:
https://tests.stockfishchess.org/tests/view/60c196fb457376eb8bcaaa6b
LLR: 2.94 (-2.94,2.94) <-2.50,0.50>
Total: 166440 W: 5559 L: 5594 D: 155287
Ptnml(0-2): 106, 4921, 73197, 4894, 102
closes https://github.com/official-stockfish/Stockfish/pull/3544
Bench: 5067605
2021-06-09 15:23:13 -06:00
|
|
|
if ( !PvNode
|
Tweak doubly singular condition (Topo's patch)
This patch relax a little bit the condition for doubly singular moves
(ie moves that are so forced that we think that they deserve a local
double extension of the search). We lower the margin and allow up to
six such double extensions in the path between the root and the critical
node.
Original idea by Siad Daboul (@TopoIogist) in PR #3709
Tested with the previous commit:
passed STC:
LLR: 2.94 (-2.94,2.94) <-0.50,2.50>
Total: 33048 W: 8458 L: 8236 D: 16354
Ptnml(0-2): 120, 3701, 8660, 3923, 120
https://tests.stockfishchess.org/tests/view/614b24347bdc23e77ceb88fe
passed LTC:
LLR: 2.95 (-2.94,2.94) <0.50,3.50>
Total: 54176 W: 13712 L: 13406 D: 27058
Ptnml(0-2): 36, 5653, 15399, 5969, 31
https://tests.stockfishchess.org/tests/view/614b3b727bdc23e77ceb8911
closes https://github.com/official-stockfish/Stockfish/pull/3714
Bench: 5792377
2021-09-23 03:20:03 -06:00
|
|
|
&& value < singularBeta - 75
|
|
|
|
&& ss->doubleExtensions <= 6)
|
More extensions if SE search is very low.
More extensions for non-PV nodes if value from singular extension search is significantly below singularBeta.
Passed STC:
LLR: 2.97 (-2.94,2.94) <-0.50,2.50>
Total: 25064 W: 2334 L: 2162 D: 20568
Ptnml(0-2): 82, 1720, 8768, 1868, 94
https://tests.stockfishchess.org/tests/view/6084ba7995e7f1852abd27e3
Passed LTC:
LLR: 2.94 (-2.94,2.94) <0.50,3.50>
Total: 67136 W: 2644 L: 2450 D: 62042
Ptnml(0-2): 46, 2134, 28990, 2376, 22
https://tests.stockfishchess.org/tests/view/6084d79195e7f1852abd27ee
closes https://github.com/official-stockfish/Stockfish/pull/3445
Bench: 4075325
2021-04-24 18:37:47 -06:00
|
|
|
extension = 2;
|
2019-05-02 11:36:25 -06:00
|
|
|
}
|
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,
|
Change multi-cut pruning condition
Use comparison of eval with beta to predict potential cutNodes. This
allows multi-cut pruning to also prune possibly mislabeled Pv and NonPv
nodes.
STC:
LLR: 2.95 (-2.94,2.94) [0.50,4.50]
Total: 54305 W: 12302 L: 11867 D: 30136
http://tests.stockfishchess.org/tests/view/5d048ba50ebc5925cf0a15e8
LTC:
LLR: 2.95 (-2.94,2.94) [0.00,3.50]
Total: 189512 W: 32620 L: 31904 D: 124988
http://tests.stockfishchess.org/tests/view/5d04bf740ebc5925cf0a17f0
Normally I would think such changes are risky, specially for PvNodes,
but after trying a few other versions, it seems this version is more
sound than I initially thought.
Aside from this, a small funtional change is made to return
singularBeta instead of beta to be more consistent with the fail-soft
logic used in other parts of search.
=============================
How to continue from there ?
We could try to audit other parts of the search where the "cutNode"
variable is used, and try to use dynamic info based on heuristic
eval rather than on this variable, to check if the idea behind this
patch could also be applied successfuly.
Bench: 3503788
2019-06-15 00:01:02 -06:00
|
|
|
// that multiple moves fail high, and we can prune the whole subtree by returning
|
|
|
|
// a soft bound.
|
2019-11-12 08:12:09 -07:00
|
|
|
else if (singularBeta >= beta)
|
Change multi-cut pruning condition
Use comparison of eval with beta to predict potential cutNodes. This
allows multi-cut pruning to also prune possibly mislabeled Pv and NonPv
nodes.
STC:
LLR: 2.95 (-2.94,2.94) [0.50,4.50]
Total: 54305 W: 12302 L: 11867 D: 30136
http://tests.stockfishchess.org/tests/view/5d048ba50ebc5925cf0a15e8
LTC:
LLR: 2.95 (-2.94,2.94) [0.00,3.50]
Total: 189512 W: 32620 L: 31904 D: 124988
http://tests.stockfishchess.org/tests/view/5d04bf740ebc5925cf0a17f0
Normally I would think such changes are risky, specially for PvNodes,
but after trying a few other versions, it seems this version is more
sound than I initially thought.
Aside from this, a small funtional change is made to return
singularBeta instead of beta to be more consistent with the fail-soft
logic used in other parts of search.
=============================
How to continue from there ?
We could try to audit other parts of the search where the "cutNode"
variable is used, and try to use dynamic info based on heuristic
eval rather than on this variable, to check if the idea behind this
patch could also be applied successfuly.
Bench: 3503788
2019-06-15 00:01:02 -06:00
|
|
|
return singularBeta;
|
Apply multicut pruning more often
This patch increases number of nodes where we produce multicut cutoffs.
The idea is that if our ttMove failed to produce a singular extension
but ttValue is greater than beta we can afford to do one more reduced search
near beta excluding ttMove to see if it will produce a fail high -
and if it does so produce muticut by analogy to existing logic.
passed STC
https://tests.stockfishchess.org/tests/view/5e9a162b5b664cdba0ce6e28
LLR: 2.94 (-2.94,2.94) {-0.50,1.50}
Total: 58238 W: 11192 L: 10917 D: 36129
Ptnml(0-2): 1007, 6704, 13442, 6939, 1027
passed LTC
https://tests.stockfishchess.org/tests/view/5e9a1e845b664cdba0ce7411
LLR: 2.94 (-2.94,2.94) {0.25,1.75}
Total: 137852 W: 17460 L: 16899 D: 103493
Ptnml(0-2): 916, 12610, 41383, 13031, 986
closes https://github.com/official-stockfish/Stockfish/pull/2640
bench 4881443
2020-04-17 18:28:47 -06:00
|
|
|
|
Simplify multi-cut condition
Now that the multi-cut condition is safer, we can avoid the cost of the sub-search.
STC:
https://tests.stockfishchess.org/tests/view/6165fd9283dd501a05b0b2fe
LLR: 2.93 (-2.94,2.94) <-2.50,0.50>
Total: 18648 W: 4745 L: 4600 D: 9303
Ptnml(0-2): 47, 2111, 4887, 2208, 71
LTC:
https://tests.stockfishchess.org/tests/view/616629ea83dd501a05b0b320
LLR: 2.96 (-2.94,2.94) <-2.50,0.50>
Total: 41704 W: 10407 L: 10302 D: 20995
Ptnml(0-2): 35, 4425, 11823, 4538, 31
closes https://github.com/official-stockfish/Stockfish/pull/3738
Bench: 5905086
2021-10-13 10:10:50 -06:00
|
|
|
// If the eval of ttMove is greater than beta, we reduce it (negative extension)
|
Apply multicut pruning more often
This patch increases number of nodes where we produce multicut cutoffs.
The idea is that if our ttMove failed to produce a singular extension
but ttValue is greater than beta we can afford to do one more reduced search
near beta excluding ttMove to see if it will produce a fail high -
and if it does so produce muticut by analogy to existing logic.
passed STC
https://tests.stockfishchess.org/tests/view/5e9a162b5b664cdba0ce6e28
LLR: 2.94 (-2.94,2.94) {-0.50,1.50}
Total: 58238 W: 11192 L: 10917 D: 36129
Ptnml(0-2): 1007, 6704, 13442, 6939, 1027
passed LTC
https://tests.stockfishchess.org/tests/view/5e9a1e845b664cdba0ce7411
LLR: 2.94 (-2.94,2.94) {0.25,1.75}
Total: 137852 W: 17460 L: 16899 D: 103493
Ptnml(0-2): 916, 12610, 41383, 13031, 986
closes https://github.com/official-stockfish/Stockfish/pull/2640
bench 4881443
2020-04-17 18:28:47 -06:00
|
|
|
else if (ttValue >= beta)
|
Simplify multi-cut condition
Now that the multi-cut condition is safer, we can avoid the cost of the sub-search.
STC:
https://tests.stockfishchess.org/tests/view/6165fd9283dd501a05b0b2fe
LLR: 2.93 (-2.94,2.94) <-2.50,0.50>
Total: 18648 W: 4745 L: 4600 D: 9303
Ptnml(0-2): 47, 2111, 4887, 2208, 71
LTC:
https://tests.stockfishchess.org/tests/view/616629ea83dd501a05b0b320
LLR: 2.96 (-2.94,2.94) <-2.50,0.50>
Total: 41704 W: 10407 L: 10302 D: 20995
Ptnml(0-2): 35, 4425, 11823, 4538, 31
closes https://github.com/official-stockfish/Stockfish/pull/3738
Bench: 5905086
2021-10-13 10:10:50 -06:00
|
|
|
extension = -2;
|
2009-11-21 06:22:52 -07:00
|
|
|
}
|
Extend captures and promotions
This patch introduces extension for captures and promotions. Every capture or
promotion that is not the first move in the list gets extended at PvNodes and
cutNodes. Special thanks to @locutus2 - all my previous attepmts that failed
on this idea were done only for PvNodes - idea to include also cutNodes was
based on his latest passed patch.
STC
https://tests.stockfishchess.org/tests/view/6134abf325b9b35584838574
LLR: 2.95 (-2.94,2.94) <-0.50,2.50>
Total: 188920 W: 47754 L: 47304 D: 93862
Ptnml(0-2): 595, 21754, 49344, 22140, 627
LTC
https://tests.stockfishchess.org/tests/view/613521de25b9b355848385d7
LLR: 2.93 (-2.94,2.94) <0.50,3.50>
Total: 8768 W: 2283 L: 2098 D: 4387
Ptnml(0-2): 7, 866, 2452, 1053, 6
closes https://github.com/official-stockfish/Stockfish/pull/3692
bench: 5564555
2021-09-05 15:17:46 -06:00
|
|
|
|
|
|
|
// Capture extensions for PvNodes and cutNodes
|
Update 2 search parameters after tune.
A tuning run on 3 search parameters was done with 200k games, narrow ranges (50-150%) and a small value for A (3% of total games) :
https://tests.stockfishchess.org/tests/view/613b5f4b689039fce12e1220
STC 10+0.1 :
LLR: 2.95 (-2.94,2.94) <-0.50,2.50>
Total: 73112 W: 18800 L: 18520 D: 35792
Ptnml(0-2): 205, 8395, 19115, 8597, 244
https://tests.stockfishchess.org/tests/view/613cb8d2689039fce12e1308
LTC 60+0.6 :
LLR: 2.95 (-2.94,2.94) <0.50,3.50>
Total: 45616 W: 11604 L: 11321 D: 22691
Ptnml(0-2): 24, 4769, 12946, 5038, 31
https://tests.stockfishchess.org/tests/view/613d07048253e53e97b55b32
closes https://github.com/official-stockfish/Stockfish/pull/3698
Bench 6504816
2021-09-12 02:19:38 -06:00
|
|
|
else if ( (PvNode || cutNode)
|
|
|
|
&& captureOrPromotion
|
Extend captures and promotions
This patch introduces extension for captures and promotions. Every capture or
promotion that is not the first move in the list gets extended at PvNodes and
cutNodes. Special thanks to @locutus2 - all my previous attepmts that failed
on this idea were done only for PvNodes - idea to include also cutNodes was
based on his latest passed patch.
STC
https://tests.stockfishchess.org/tests/view/6134abf325b9b35584838574
LLR: 2.95 (-2.94,2.94) <-0.50,2.50>
Total: 188920 W: 47754 L: 47304 D: 93862
Ptnml(0-2): 595, 21754, 49344, 22140, 627
LTC
https://tests.stockfishchess.org/tests/view/613521de25b9b355848385d7
LLR: 2.93 (-2.94,2.94) <0.50,3.50>
Total: 8768 W: 2283 L: 2098 D: 4387
Ptnml(0-2): 7, 866, 2452, 1053, 6
closes https://github.com/official-stockfish/Stockfish/pull/3692
bench: 5564555
2021-09-05 15:17:46 -06:00
|
|
|
&& moveCount != 1)
|
|
|
|
extension = 1;
|
|
|
|
|
|
|
|
// Check extensions
|
Check Extension with Static Evaluation
extension for checking moves, at higher depth and more decisive positions.
stc:
LLR: 2.97 (-2.94,2.94) <-0.50,2.50>
Total: 87008 W: 7337 L: 7100 D: 72571
Ptnml(0-2): 264, 5737, 31270, 5964, 269
https://tests.stockfishchess.org/tests/view/60b1034787a1a67ae56c47b6
ltc:
LLR: 2.94 (-2.94,2.94) <0.50,3.50>
Total: 79320 W: 2629 L: 2432 D: 74259
Ptnml(0-2): 29, 2205, 35000, 2392, 34
https://tests.stockfishchess.org/tests/view/60b1ae0b87a1a67ae56c487c
closes https://github.com/official-stockfish/Stockfish/pull/3514
Bench: 4447112
2021-05-30 22:47:35 -06:00
|
|
|
else if ( givesCheck
|
|
|
|
&& depth > 6
|
Extend quiet tt moves at PvNodes
Idea is to extend some quiet ttMoves if a lot of things indicate that
the transposition table move is going to be a good move:
1) move being a killer - so being the best move in nearby node;
2) reply continuation history is really good.
This is basically saying that move is good "in general" in this position,
that it is a good reply to the opponent move and that it was the best in
this position somewhere in search - so extending it makes a lot of sense.
In general in past year we had a lot of extensions of different types,
maybe there is something more in it :)
passed STC
LLR: 2.96 (-2.94,2.94) <-0.50,2.50>
Total: 42944 W: 10932 L: 10695 D: 21317
Ptnml(0-2): 141, 4869, 11210, 5116, 136
https://tests.stockfishchess.org/tests/view/614cca8e7bdc23e77ceb89f0
passed LTC
LLR: 2.93 (-2.94,2.94) <0.50,3.50>
Total: 156848 W: 39473 L: 38893 D: 78482
Ptnml(0-2): 125, 16327, 44913, 16961, 98
https://tests.stockfishchess.org/tests/view/614cf93d7bdc23e77ceb8a13
closes https://github.com/official-stockfish/Stockfish/pull/3719
Bench: 5714575
2021-09-25 22:39:27 -06:00
|
|
|
&& abs(ss->staticEval) > 100)
|
|
|
|
extension = 1;
|
|
|
|
|
|
|
|
// Quiet ttMove extensions
|
|
|
|
else if ( PvNode
|
|
|
|
&& move == ttMove
|
|
|
|
&& move == ss->killers[0]
|
|
|
|
&& (*contHist[0])[movedPiece][to_sq(move)] >= 10000)
|
Check Extension with Static Evaluation
extension for checking moves, at higher depth and more decisive positions.
stc:
LLR: 2.97 (-2.94,2.94) <-0.50,2.50>
Total: 87008 W: 7337 L: 7100 D: 72571
Ptnml(0-2): 264, 5737, 31270, 5964, 269
https://tests.stockfishchess.org/tests/view/60b1034787a1a67ae56c47b6
ltc:
LLR: 2.94 (-2.94,2.94) <0.50,3.50>
Total: 79320 W: 2629 L: 2432 D: 74259
Ptnml(0-2): 29, 2205, 35000, 2392, 34
https://tests.stockfishchess.org/tests/view/60b1ae0b87a1a67ae56c487c
closes https://github.com/official-stockfish/Stockfish/pull/3514
Bench: 4447112
2021-05-30 22:47:35 -06:00
|
|
|
extension = 1;
|
2019-01-29 07:26:03 -07:00
|
|
|
|
2019-11-12 10:36:12 -07:00
|
|
|
// Add extension to new depth
|
|
|
|
newDepth += extension;
|
Limit double extensions
Double extensions can lead to search explosions, for specific positions.
Currently, however, these double extensions are worth about 10Elo and cannot
be removed. This patch instead limits the number of double extensions given
to a maximum of 3.
This fixes https://github.com/official-stockfish/Stockfish/issues/3532
where the following testcase was shown to be problematic:
```
uci
setoption name Hash value 4
setoption name Contempt value 0
ucinewgame
position fen 8/Pk6/8/1p6/8/P1K5/8/6B1 w - - 37 130
go depth 20
```
passed STC:
https://tests.stockfishchess.org/tests/view/60c13161457376eb8bcaaa0f
LLR: 2.95 (-2.94,2.94) <-2.50,0.50>
Total: 73256 W: 6114 L: 6062 D: 61080
Ptnml(0-2): 222, 4912, 26306, 4968, 220
passed LTC:
https://tests.stockfishchess.org/tests/view/60c196fb457376eb8bcaaa6b
LLR: 2.94 (-2.94,2.94) <-2.50,0.50>
Total: 166440 W: 5559 L: 5594 D: 155287
Ptnml(0-2): 106, 4921, 73197, 4894, 102
closes https://github.com/official-stockfish/Stockfish/pull/3544
Bench: 5067605
2021-06-09 15:23:13 -06:00
|
|
|
ss->doubleExtensions = (ss-1)->doubleExtensions + (extension == 2);
|
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
|
|
|
|
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;
|
continuation histories when in check
If in check, don't write to continuation histories ss-4, ss-6.
Adding inCheck to the stack was needed, and might be useful for
future patches.
Passed STC:
https://tests.stockfishchess.org/tests/view/5e9ee24acaaff5d60a50b812
LLR: 2.94 (-2.94,2.94) {-0.50,1.50}
Total: 61774 W: 11725 L: 11449 D: 38600
Ptnml(0-2): 971, 7211, 14322, 7337, 1046
Passed LTC:
https://tests.stockfishchess.org/tests/view/5e9eecb7caaff5d60a50b831
LLR: 2.94 (-2.94,2.94) {0.25,1.75}
Total: 250822 W: 32067 L: 31179 D: 187576
Ptnml(0-2): 1745, 23126, 74824, 23928, 1788
closes https://github.com/official-stockfish/Stockfish/pull/2645
bench: 4808463
2020-04-21 12:55:41 -06:00
|
|
|
ss->continuationHistory = &thisThread->continuationHistory[ss->inCheck]
|
2019-10-18 07:23:00 -06:00
|
|
|
[captureOrPromotion]
|
|
|
|
[movedPiece]
|
|
|
|
[to_sq(move)];
|
2011-05-23 07:14:47 -06:00
|
|
|
|
Introduce ProbCut for check evasions
The idea of this patch can be described as follows: if we are in check
and the transposition table move is a capture that returns a value
far above beta, we can assume that the opponent just blundered a piece
by giving check, and we return the transposition table value. This is
similar to the usual probCut logic for quiet moves, but with a different
threshold.
Passed STC
LLR: 2.94 (-2.94,2.94) {-0.25,1.25}
Total: 33440 W: 3056 L: 2891 D: 27493
Ptnml(0-2): 110, 2338, 11672, 2477, 123
https://tests.stockfishchess.org/tests/view/602cd1087f517a561bc49bda
Passed LTC
LLR: 2.98 (-2.94,2.94) {0.25,1.25}
Total: 10072 W: 401 L: 309 D: 9362
Ptnml(0-2): 2, 288, 4365, 378, 3
https://tests.stockfishchess.org/tests/view/602ceea57f517a561bc49bf0
The committed version has an additional fix to never return unproven wins
in the tablebase range or the mate range. This fix passed tests for non-
regression at STC and LTC:
STC:
LLR: 2.93 (-2.94,2.94) {-1.25,0.25}
Total: 26240 W: 2354 L: 2280 D: 21606
Ptnml(0-2): 85, 1763, 9372, 1793, 107
https://tests.stockfishchess.org/tests/view/602d86a87f517a561bc49c7a
LTC:
LLR: 2.95 (-2.94,2.94) {-0.75,0.25}
Total: 35304 W: 1299 L: 1256 D: 32749
Ptnml(0-2): 14, 1095, 15395, 1130, 18
https://tests.stockfishchess.org/tests/view/602d98d17f517a561bc49c83
Closes https://github.com/official-stockfish/Stockfish/pull/3362
Bench: 3830215
2021-02-20 14:48:08 -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
|
|
|
|
Introduce DistanceFromPV
We introduce a metric for each internal node in search, called DistanceFromPV.
This distance indicated how far the current node is from the principal variation.
We then use this distance to search the nodes which are close to the PV a little
deeper (up to 4 plies deeper than the PV): this improves the quality of the search
at these nodes and bring better updates for the PV during search.
STC:
LLR: 2.96 (-2.94,2.94) {-0.25,1.25}
Total: 54936 W: 5047 L: 4850 D: 45039
Ptnml(0-2): 183, 3907, 19075, 4136, 167
https://tests.stockfishchess.org/tests/view/6037b88e7f517a561bc4a392
LTC:
LLR: 2.95 (-2.94,2.94) {0.25,1.25}
Total: 49608 W: 1880 L: 1703 D: 46025
Ptnml(0-2): 22, 1514, 21555, 1691, 22
https://tests.stockfishchess.org/tests/view/6038271b7f517a561bc4a3cb
Closes https://github.com/official-stockfish/Stockfish/pull/3369
Bench: 5037279
2021-02-26 02:13:37 -07:00
|
|
|
// Step 16. Late moves reduction / extension (LMR, ~200 Elo)
|
|
|
|
// We use various heuristics for the sons of a node after the first son has
|
|
|
|
// been searched. In general we would like to reduce them, but there are many
|
|
|
|
// cases where we extend a son if it has good chances to be "interesting".
|
2019-09-28 14:27:23 -06:00
|
|
|
if ( depth >= 3
|
Simplify reduced depth search
Simplification in reduced depth search.
STC https://tests.stockfishchess.org/tests/view/5f64c72fbb0cae038ca8f531
LLR: 2.94 (-2.94,2.94) {-1.25,0.25}
Total: 28320 W: 3475 L: 3359 D: 21486
Ptnml(0-2): 170, 2485, 8773, 2523, 209
LTC https://tests.stockfishchess.org/tests/view/5f650cfabb0cae038ca8f585
LLR: 2.95 (-2.94,2.94) {-0.75,0.25}
Total: 58392 W: 3354 L: 3285 D: 51753
Ptnml(0-2): 74, 2826, 23336, 2877, 83
closes https://github.com/official-stockfish/Stockfish/pull/3139
bench: 4201295
2020-09-20 01:03:37 -06:00
|
|
|
&& moveCount > 1 + 2 * rootNode
|
Simplify LMR multiThread condition
STC (8 threads):
LLR: 2.95 (-2.94,2.94) <-2.50,0.50>
Total: 110584 W: 27818 L: 27807 D: 54959
Ptnml(0-2): 156, 12089, 30791, 12100, 156
https://tests.stockfishchess.org/tests/view/6172ef436ce927be325583a9
LTC (8 threads):
LLR: 2.94 (-2.94,2.94) <-2.50,0.50>
Total: 23632 W: 6025 L: 5903 D: 11704
Ptnml(0-2): 5, 2292, 7100, 2414, 5
https://tests.stockfishchess.org/tests/view/6173cf096ce927be32558412
closes https://github.com/official-stockfish/Stockfish/pull/3757
No functional change (in the single-threaded case)
Bench: 6689428
2021-10-23 06:22:41 -06:00
|
|
|
&& ( !ss->ttPv
|
|
|
|
|| !captureOrPromotion
|
|
|
|
|| (cutNode && (ss-1)->moveCount > 1)))
|
2008-09-06 10:25:58 -06:00
|
|
|
{
|
Range reductions
adding reductions for when the delta between the static eval and the child's eval is consistently low.
passed STC
https://tests.stockfishchess.org/html/live_elo.html?614d7b3c7bdc23e77ceb8a5d
LLR: 2.95 (-2.94,2.94) <-0.50,2.50>
Total: 88872 W: 22672 L: 22366 D: 43834
Ptnml(0-2): 343, 10150, 23117, 10510, 316
passed LTC
https://tests.stockfishchess.org/html/live_elo.html?614daf3e7bdc23e77ceb8a82
LLR: 2.93 (-2.94,2.94) <0.50,3.50>
Total: 24368 W: 6153 L: 5928 D: 12287
Ptnml(0-2): 13, 2503, 6937, 2708, 23
closes https://github.com/official-stockfish/Stockfish/pull/3717
Bench: 5443950
2021-09-23 14:16:17 -06:00
|
|
|
Depth r = reduction(improving, depth, moveCount, rangeReduction > 2);
|
2016-08-16 07:53:45 -06:00
|
|
|
|
Reduce more if multiple moves exceed alpha
Idea of this patch is the following: in case we already have four moves that
exceeded alpha in the current node, the probability of finding fifth should
be reasonably low. Note that four is completely arbitrary - there could and
probably should be some tweaks, both in tweaking best move count threshold
for more reductions and tweaking how they work - for example making more
reductions with best move count linearly.
passed STC:
https://tests.stockfishchess.org/tests/view/615f614783dd501a05b0aee2
LLR: 2.94 (-2.94,2.94) <-0.50,2.50>
Total: 141816 W: 36056 L: 35686 D: 70074
Ptnml(0-2): 499, 15131, 39273, 15511, 494
passed LTC:
https://tests.stockfishchess.org/tests/view/615fdff683dd501a05b0af35
LLR: 2.94 (-2.94,2.94) <0.50,3.50>
Total: 68536 W: 17221 L: 16891 D: 34424
Ptnml(0-2): 38, 6573, 20725, 6885, 47
closes https://github.com/official-stockfish/Stockfish/pull/3736
Bench: 6131513
2021-10-08 17:15:43 -06:00
|
|
|
// Decrease reduction if on the PV (~2 Elo)
|
|
|
|
if ( PvNode
|
|
|
|
&& bestMoveCount <= 3)
|
Reduce in LMR reduction on PvNode
reduce reduction in LMR by 1 on PvNode.
STC:
LLR: 2.93 (-2.94,2.94) <-0.50,2.50>
Total: 266080 W: 22438 L: 21996 D: 221646
Ptnml(0-2): 774, 17874, 95376, 18168, 848
https://tests.stockfishchess.org/tests/view/60bc0661457376eb8bcaa4bb
LTC:
LLR: 2.93 (-2.94,2.94) <0.50,3.50>
Total: 20144 W: 698 L: 587 D: 18859
Ptnml(0-2): 2, 529, 8906, 626, 9
https://tests.stockfishchess.org/tests/view/60bcc3f2457376eb8bcaa58d
closes https://github.com/official-stockfish/Stockfish/pull/3534
bench: 5173012
2021-06-06 10:31:57 -06:00
|
|
|
r--;
|
|
|
|
|
2021-01-31 05:46:05 -07:00
|
|
|
// Decrease reduction if position is or has been on the PV
|
2021-05-13 20:47:41 -06:00
|
|
|
// and node is not likely to fail low. (~3 Elo)
|
2021-03-19 12:43:25 -06:00
|
|
|
if ( ss->ttPv
|
|
|
|
&& !likelyFailLow)
|
2019-09-28 14:27:23 -06:00
|
|
|
r -= 2;
|
2019-01-09 07:05:28 -07:00
|
|
|
|
Increase reduction at root
when the best move does not change frequently
STC:
LLR: 2.94 (-2.94,2.94) {-0.25,1.25}
Total: 51320 W: 5159 L: 4956 D: 41205
Ptnml(0-2): 215, 3897, 17242, 4082, 224
https://tests.stockfishchess.org/tests/view/5faa072367cbf42301d6a767
LTC:
LLR: 2.98 (-2.94,2.94) {0.25,1.25}
Total: 15952 W: 762 L: 642 D: 14548
Ptnml(0-2): 8, 561, 6725, 667, 15
https://tests.stockfishchess.org/tests/view/5faa4c3567cbf42301d6a794
closes https://github.com/official-stockfish/Stockfish/pull/3225
Bench: 3954692
2020-11-10 10:28:43 -07:00
|
|
|
// Increase reduction at root and non-PV nodes when the best move does not change frequently
|
2021-03-19 12:43:25 -06:00
|
|
|
if ( (rootNode || !PvNode)
|
|
|
|
&& thisThread->bestMoveChanges <= 2)
|
Increase reduction based on the number of best move changes.
Thanks to Vizvezdenec for the PvNode idea and also to vondele the !PvNode idea.
Passed STC:
LLR: 2.94 (-2.94,2.94) {-0.25,1.25}
Total: 19120 W: 1998 L: 1839 D: 15283
Ptnml(0-2): 76, 1445, 6375, 1572, 92
https://tests.stockfishchess.org/tests/view/5fa8af3e67cbf42301d6a6c9
Passed LTC:
LLR: 2.94 (-2.94,2.94) {0.25,1.25}
Total: 75584 W: 3454 L: 3205 D: 68925
Ptnml(0-2): 54, 2832, 31771, 3081, 54
closes https://github.com/official-stockfish/Stockfish/pull/3224
Bench: 3595418
2020-11-08 19:43:32 -07:00
|
|
|
r++;
|
|
|
|
|
Simplify LMR rule for non-checking captures
We simplify away the complicated rule in LMR for "non-checking captures
likely to be bad", as it seems not to bring any strength anymore.
STC:
LLR: 2.94 (-2.94,2.94) <-2.50,0.50>
Total: 55256 W: 4972 L: 4897 D: 45387
Ptnml(0-2): 177, 3976, 19234, 4077, 164
https://tests.stockfishchess.org/tests/view/609adf3b3a33eb67a844f842
LTC:
LLR: 2.95 (-2.94,2.94) <-2.50,0.50>
Total: 10344 W: 437 L: 353 D: 9554
Ptnml(0-2): 1, 322, 4449, 392, 8
https://tests.stockfishchess.org/tests/view/609b3dfa3a33eb67a844f88e
--
While at it, we also update the Elo estimate of the previous rule in LMR
(see https://tests.stockfishchess.org/tests/view/609af2a63a33eb67a844f867).
closes https://github.com/official-stockfish/Stockfish/pull/3460
Bench: 3840688
2021-05-12 06:38:26 -06:00
|
|
|
// Decrease reduction if opponent's move count is high (~1 Elo)
|
Retuned values after eval quantize patch.
The last search tune patch was tested before the implementation of #2733 which
presumably changed the search characteristics noticeably. Another tuning run was
done, see https://tests.stockfishchess.org/tests/view/5ee5b434ca6c451633a9a08c
and the updated values passed these tests:
STC:
LLR: 2.93 (-2.94,2.94) {-0.50,1.50}
Total: 34352 W: 6600 L: 6360 D: 21392
Ptnml(0-2): 581, 3947, 7914, 4119, 615
https://tests.stockfishchess.org/tests/view/5ee62f05ca6c451633a9a15f
LTC 60+0.6 th 1 :
LLR: 2.97 (-2.94,2.94) {0.25,1.75}
Total: 11176 W: 1499 L: 1304 D: 8373
Ptnml(0-2): 69, 933, 3403, 1100, 83
https://tests.stockfishchess.org/tests/view/5ee6205bca6c451633a9a147
SMP LTC 20+0.2 th 8 :
LLR: 2.93 (-2.94,2.94) {0.25,1.75}
Total: 54032 W: 6126 L: 5826 D: 42080
Ptnml(0-2): 278, 4454, 17280, 4698, 306
https://tests.stockfishchess.org/tests/view/5ee62f25ca6c451633a9a162
Closes https://github.com/official-stockfish/Stockfish/pull/2742
Bench 4957812
2020-06-14 14:50:27 -06:00
|
|
|
if ((ss-1)->moveCount > 13)
|
2019-09-28 14:27:23 -06:00
|
|
|
r--;
|
2019-05-02 11:36:25 -06:00
|
|
|
|
2021-05-11 08:04:02 -06:00
|
|
|
// Decrease reduction if ttMove has been singularly extended (~1 Elo)
|
Singular quiet LMR
If ttMove is a capture and had a singular extension, it is probably the best move.
No need to make a decrease of LMR on other moves.
STC
LLR: 2.96 (-2.94,2.94) {-0.50,1.50}
Total: 41968 W: 8170 L: 7918 D: 25880
Ptnml(0-2): 733, 4770, 9726, 5022, 733
https://tests.stockfishchess.org/tests/view/5ed6b666f29b40b0fc95a884
LTC
LLR: 2.95 (-2.94,2.94) {0.25,1.75}
Total: 71376 W: 9200 L: 8827 D: 53349
Ptnml(0-2): 486, 6544, 21342, 6743, 573
https://tests.stockfishchess.org/tests/view/5ed7578bf29b40b0fc95a8c9
closes https://github.com/official-stockfish/Stockfish/pull/2713
Bench: 4733799
2020-06-02 14:27:11 -06:00
|
|
|
if (singularQuietLMR)
|
Simplify singularQuietLMR
remove formerPV dependence
STC https://tests.stockfishchess.org/tests/view/5f4cb922ba100690c5cc5d35
LLR: 2.96 (-2.94,2.94) {-1.25,0.25}
Total: 113672 W: 12347 L: 12368 D: 88957
Ptnml(0-2): 566, 9537, 36699, 9420, 614
LTC https://tests.stockfishchess.org/tests/view/5f4e8474ba100690c5cc5e12
LLR: 2.93 (-2.94,2.94) {-0.75,0.25}
Total: 43032 W: 2298 L: 2227 D: 38507
Ptnml(0-2): 45, 1940, 17475, 2011, 45
closes https://github.com/official-stockfish/Stockfish/pull/3102
bench: 3290084
2020-09-03 04:18:42 -06:00
|
|
|
r--;
|
2017-09-04 14:27:22 -06:00
|
|
|
|
Increased reduction for captures in LMR
It now does, in LMR, an increased on reduction by 1 for captures in cut nodes.
STC:
LLR: 2.93 (-2.94,2.94) <-0.50,2.50>
Total: 30656 W: 2565 L: 2397 D: 25694
Ptnml(0-2): 63, 2012, 11029, 2142, 82
https://tests.stockfishchess.org/tests/view/60a96733ce8ea25a3ef04178
LTC:
LLR: 2.93 (-2.94,2.94) <0.50,3.50>
Total: 124840 W: 4139 L: 3878 D: 116823
Ptnml(0-2): 48, 3480, 55100, 3747, 45
https://tests.stockfishchess.org/tests/view/60a995f5ce8ea25a3ef041b7
closes https://github.com/official-stockfish/Stockfish/pull/3494
bench: 3864295
2021-05-24 05:15:04 -06:00
|
|
|
// Increase reduction for cut nodes (~3 Elo)
|
no cut node reduction for killer moves.
stc:
LLR: 2.95 (-2.94,2.94) <-0.50,2.50>
Total: 44344 W: 3474 L: 3294 D: 37576
Ptnml(0-2): 117, 2710, 16338, 2890, 117
https://tests.stockfishchess.org/tests/view/60d8ea673beab81350ac9eb8
ltc:
LLR: 2.93 (-2.94,2.94) <0.50,3.50>
Total: 82600 W: 2638 L: 2441 D: 77521
Ptnml(0-2): 38, 2147, 36749, 2312, 54
https://tests.stockfishchess.org/tests/view/60d9048f3beab81350ac9eed
closes https://github.com/official-stockfish/Stockfish/pull/3600
Bench: 5160239
2021-07-01 11:51:41 -06:00
|
|
|
if (cutNode && move != ss->killers[0])
|
|
|
|
r += 2;
|
Increased reduction for captures in LMR
It now does, in LMR, an increased on reduction by 1 for captures in cut nodes.
STC:
LLR: 2.93 (-2.94,2.94) <-0.50,2.50>
Total: 30656 W: 2565 L: 2397 D: 25694
Ptnml(0-2): 63, 2012, 11029, 2142, 82
https://tests.stockfishchess.org/tests/view/60a96733ce8ea25a3ef04178
LTC:
LLR: 2.93 (-2.94,2.94) <0.50,3.50>
Total: 124840 W: 4139 L: 3878 D: 116823
Ptnml(0-2): 48, 3480, 55100, 3747, 45
https://tests.stockfishchess.org/tests/view/60a995f5ce8ea25a3ef041b7
closes https://github.com/official-stockfish/Stockfish/pull/3494
bench: 3864295
2021-05-24 05:15:04 -06:00
|
|
|
|
Simplification in LMR
This commit removes the `!captureOrPromotion` condition from ttCapture reduction and from good/bad history reduction (similar to #3619).
passed STC:
https://tests.stockfishchess.org/tests/view/60fc734ad8a6b65b2f3a7922
LLR: 2.97 (-2.94,2.94) <-2.50,0.50>
Total: 48680 W: 3855 L: 3776 D: 41049
Ptnml(0-2): 118, 3145, 17744, 3206, 127
passed LTC:
https://tests.stockfishchess.org/tests/view/60fce7d5d8a6b65b2f3a794c
LLR: 2.93 (-2.94,2.94) <-2.50,0.50>
Total: 86528 W: 2471 L: 2450 D: 81607
Ptnml(0-2): 28, 2203, 38777, 2232, 24
closes https://github.com/official-stockfish/Stockfish/pull/3629
Bench: 4951406
2021-07-24 14:03:29 -06:00
|
|
|
// Increase reduction if ttMove is a capture (~3 Elo)
|
|
|
|
if (ttCapture)
|
|
|
|
r++;
|
|
|
|
|
|
|
|
ss->statScore = thisThread->mainHistory[us][from_to(move)]
|
|
|
|
+ (*contHist[0])[movedPiece][to_sq(move)]
|
|
|
|
+ (*contHist[1])[movedPiece][to_sq(move)]
|
|
|
|
+ (*contHist[3])[movedPiece][to_sq(move)]
|
|
|
|
- 4923;
|
|
|
|
|
|
|
|
// Decrease/increase reduction for moves with a good/bad history (~30 Elo)
|
|
|
|
r -= ss->statScore / 14721;
|
Tweak reductions for captures/promotions
From the third move reduce captures and promotions more if remaining depth is low.
STC:
LLR: 2.94 (-2.94,2.94) {-1.00,3.00}
Total: 25218 W: 5008 L: 4837 D: 15373
Ptnml(0-2): 439, 2950, 5717, 3001, 499
http://tests.stockfishchess.org/tests/view/5e1b33abd12216a2857e6359
LTC:
LLR: 2.95 (-2.94,2.94) {0.00,2.00}
Total: 35491 W: 4760 L: 4524 D: 26207
Ptnml(0-2): 264, 3288, 10413, 3460, 294
http://tests.stockfishchess.org/tests/view/5e1b88d5d12216a2857e6385
Closes https://github.com/official-stockfish/Stockfish/pull/2488
Bench: 4979757
2020-01-13 03:19:03 -07:00
|
|
|
|
Extend quiet tt moves at PvNodes
Idea is to extend some quiet ttMoves if a lot of things indicate that
the transposition table move is going to be a good move:
1) move being a killer - so being the best move in nearby node;
2) reply continuation history is really good.
This is basically saying that move is good "in general" in this position,
that it is a good reply to the opponent move and that it was the best in
this position somewhere in search - so extending it makes a lot of sense.
In general in past year we had a lot of extensions of different types,
maybe there is something more in it :)
passed STC
LLR: 2.96 (-2.94,2.94) <-0.50,2.50>
Total: 42944 W: 10932 L: 10695 D: 21317
Ptnml(0-2): 141, 4869, 11210, 5116, 136
https://tests.stockfishchess.org/tests/view/614cca8e7bdc23e77ceb89f0
passed LTC
LLR: 2.93 (-2.94,2.94) <0.50,3.50>
Total: 156848 W: 39473 L: 38893 D: 78482
Ptnml(0-2): 125, 16327, 44913, 16961, 98
https://tests.stockfishchess.org/tests/view/614cf93d7bdc23e77ceb8a13
closes https://github.com/official-stockfish/Stockfish/pull/3719
Bench: 5714575
2021-09-25 22:39:27 -06:00
|
|
|
// In general we want to cap the LMR depth search at newDepth. But if reductions
|
|
|
|
// are really negative and movecount is low, we allow this move to be searched
|
Allow some LMR double extensions
Allow some LMR double extensions for the second and third sons of each node.
STC:
LLR: 2.94 (-2.94,2.94) <-0.50,2.50>
Total: 170320 W: 42608 L: 42187 D: 85525
Ptnml(0-2): 516, 19635, 44422, 20086, 501
https://tests.stockfishchess.org/tests/view/616a9e3899b580bf37797cf4
LTC:
LLR: 2.93 (-2.94,2.94) <0.50,3.50>
Total: 74400 W: 18783 L: 18423 D: 37194
Ptnml(0-2): 46, 7812, 21129, 8162, 51
https://tests.stockfishchess.org/tests/view/616b378499b580bf37797d61
closes https://github.com/official-stockfish/Stockfish/pull/3742
Bench: 4877152
2021-10-17 03:56:35 -06:00
|
|
|
// deeper than the first move (this may lead to hidden double extensions).
|
Do more deeper LMR searches.
At expected cut nodes allow at least one ply deeper LMR search for the first seventh moves.
STC:
LLR: 2.93 (-2.94,2.94) <-0.50,2.50>
Total: 42880 W: 10964 L: 10738 D: 21178
Ptnml(0-2): 105, 4565, 11883, 4773, 114
https://tests.stockfishchess.org/tests/view/6179abd7a9b1d8fbcc4ee6f4
LTC:
LLR: 2.93 (-2.94,2.94) <0.50,3.50>
Total: 66872 W: 16930 L: 16603 D: 33339
Ptnml(0-2): 36, 6509, 20024, 6826, 41
https://tests.stockfishchess.org/tests/view/617a30fb2fbca9ca65972b5e
closes https://github.com/official-stockfish/Stockfish/pull/3770
Bench: 6295536
2021-10-31 05:09:40 -06:00
|
|
|
int deeper = r >= -1 ? 0
|
|
|
|
: moveCount <= 5 ? 2
|
|
|
|
: PvNode && depth > 6 ? 1
|
|
|
|
: cutNode && moveCount <= 7 ? 1
|
|
|
|
: 0;
|
Detect search explosions
This patch detects some search explosions (due to double extensions in
search.cpp) which can happen in some pathological positions, and takes
measures to ensure progress in search even for these pathological situations.
While a small number of double extensions can be useful during search
(for example to resolve a tactical sequence), a sustained regime of
double extensions leads to search explosion and a non-finishing search.
See the discussion in https://github.com/official-stockfish/Stockfish/pull/3544
and the issue https://github.com/official-stockfish/Stockfish/issues/3532 .
The implemented algorithm is the following:
a) at each node during search, store the current depth in the stack.
Double extensions are by definition levels of the stack where the
depth at ply N is strictly higher than depth at ply N-1.
b) during search, calculate for each thread a running average of the
number of double extensions in the last 4096 visited nodes.
c) if one thread has more than 2% of double extensions for a sustained
period of time (6 millions consecutive nodes, or about 4 seconds on
my iMac), we decide that this thread is in an explosion state and
we calm down this thread by preventing it to do any double extension
for the next 6 millions nodes.
To calculate the running averages, we also introduced a auxiliary class
generalizing the computations of ttHitAverage variable we already had in
code. The implementation uses an exponential moving average of period 4096
and resolution 1/1024, and all computations are done with integers for
efficiency.
-----------
Example where the patch solves a search explosion:
```
./stockfish
ucinewgame
position fen 8/Pk6/8/1p6/8/P1K5/8/6B1 w - - 37 130
go infinite
```
This algorithm does not affect search in normal, non-pathological positions.
We verified, for instance, that the usual bench is unchanged up to depth 20
at least, and that the node numbers are unchanged for a search of the starting
position at depth 32.
-------------
See https://github.com/official-stockfish/Stockfish/pull/3714
Bench: 5575265
2021-09-23 15:19:06 -06:00
|
|
|
|
|
|
|
Depth d = std::clamp(newDepth - r, 1, newDepth + deeper);
|
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
|
|
|
|
Range reductions
adding reductions for when the delta between the static eval and the child's eval is consistently low.
passed STC
https://tests.stockfishchess.org/html/live_elo.html?614d7b3c7bdc23e77ceb8a5d
LLR: 2.95 (-2.94,2.94) <-0.50,2.50>
Total: 88872 W: 22672 L: 22366 D: 43834
Ptnml(0-2): 343, 10150, 23117, 10510, 316
passed LTC
https://tests.stockfishchess.org/html/live_elo.html?614daf3e7bdc23e77ceb8a82
LLR: 2.93 (-2.94,2.94) <0.50,3.50>
Total: 24368 W: 6153 L: 5928 D: 12287
Ptnml(0-2): 13, 2503, 6937, 2708, 23
closes https://github.com/official-stockfish/Stockfish/pull/3717
Bench: 5443950
2021-09-23 14:16:17 -06:00
|
|
|
// Range reductions (~3 Elo)
|
|
|
|
if (ss->staticEval - value < 30 && depth > 7)
|
|
|
|
rangeReduction++;
|
|
|
|
|
Introduce DistanceFromPV
We introduce a metric for each internal node in search, called DistanceFromPV.
This distance indicated how far the current node is from the principal variation.
We then use this distance to search the nodes which are close to the PV a little
deeper (up to 4 plies deeper than the PV): this improves the quality of the search
at these nodes and bring better updates for the PV during search.
STC:
LLR: 2.96 (-2.94,2.94) {-0.25,1.25}
Total: 54936 W: 5047 L: 4850 D: 45039
Ptnml(0-2): 183, 3907, 19075, 4136, 167
https://tests.stockfishchess.org/tests/view/6037b88e7f517a561bc4a392
LTC:
LLR: 2.95 (-2.94,2.94) {0.25,1.25}
Total: 49608 W: 1880 L: 1703 D: 46025
Ptnml(0-2): 22, 1514, 21555, 1691, 22
https://tests.stockfishchess.org/tests/view/6038271b7f517a561bc4a3cb
Closes https://github.com/official-stockfish/Stockfish/pull/3369
Bench: 5037279
2021-02-26 02:13:37 -07:00
|
|
|
// If the son is reduced and fails high it will be re-searched at full depth
|
|
|
|
doFullDepthSearch = value > alpha && d < newDepth;
|
2020-03-14 10:04:50 -06:00
|
|
|
didLMR = true;
|
2011-11-19 05:55:26 -07:00
|
|
|
}
|
|
|
|
else
|
2020-03-14 10:04:50 -06:00
|
|
|
{
|
|
|
|
doFullDepthSearch = !PvNode || moveCount > 1;
|
|
|
|
didLMR = false;
|
|
|
|
}
|
2010-05-08 02:54:51 -06:00
|
|
|
|
Introduce ProbCut for check evasions
The idea of this patch can be described as follows: if we are in check
and the transposition table move is a capture that returns a value
far above beta, we can assume that the opponent just blundered a piece
by giving check, and we return the transposition table value. This is
similar to the usual probCut logic for quiet moves, but with a different
threshold.
Passed STC
LLR: 2.94 (-2.94,2.94) {-0.25,1.25}
Total: 33440 W: 3056 L: 2891 D: 27493
Ptnml(0-2): 110, 2338, 11672, 2477, 123
https://tests.stockfishchess.org/tests/view/602cd1087f517a561bc49bda
Passed LTC
LLR: 2.98 (-2.94,2.94) {0.25,1.25}
Total: 10072 W: 401 L: 309 D: 9362
Ptnml(0-2): 2, 288, 4365, 378, 3
https://tests.stockfishchess.org/tests/view/602ceea57f517a561bc49bf0
The committed version has an additional fix to never return unproven wins
in the tablebase range or the mate range. This fix passed tests for non-
regression at STC and LTC:
STC:
LLR: 2.93 (-2.94,2.94) {-1.25,0.25}
Total: 26240 W: 2354 L: 2280 D: 21606
Ptnml(0-2): 85, 1763, 9372, 1793, 107
https://tests.stockfishchess.org/tests/view/602d86a87f517a561bc49c7a
LTC:
LLR: 2.95 (-2.94,2.94) {-0.75,0.25}
Total: 35304 W: 1299 L: 1256 D: 32749
Ptnml(0-2): 14, 1095, 15395, 1130, 18
https://tests.stockfishchess.org/tests/view/602d98d17f517a561bc49c83
Closes https://github.com/official-stockfish/Stockfish/pull/3362
Bench: 3830215
2021-02-20 14:48:08 -07:00
|
|
|
// Step 17. Full depth search when LMR is skipped or fails high
|
2011-11-19 05:55:26 -07:00
|
|
|
if (doFullDepthSearch)
|
2019-07-11 23:22:46 -06:00
|
|
|
{
|
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
|
|
|
|
2020-12-01 05:02:35 -07:00
|
|
|
// If the move passed LMR update its stats
|
2019-10-18 18:20:38 -06:00
|
|
|
if (didLMR && !captureOrPromotion)
|
2019-07-11 23:22:46 -06:00
|
|
|
{
|
2019-07-12 02:17:24 -06:00
|
|
|
int bonus = value > alpha ? stat_bonus(newDepth)
|
|
|
|
: -stat_bonus(newDepth);
|
2019-07-11 23:22:46 -06:00
|
|
|
|
|
|
|
update_continuation_histories(ss, movedPiece, to_sq(move), bonus);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
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;
|
|
|
|
|
Reduce big time spikes by reducing PV re-searches.
Save time by reducing PV re-searches above original depth. Instead use 5% extra time on every move.
STC 10+0.1 th 1 :
LLR: 2.93 (-2.94,2.94) {-0.25,1.25}
Total: 90688 W: 9702 L: 9436 D: 71550
Ptnml(0-2): 408, 7252, 29792, 7450, 442
https://tests.stockfishchess.org/tests/view/5f8df807bacb75a4f9a47223
LTC 60+0.6 th 1 :
LLR: 2.97 (-2.94,2.94) {0.25,1.25}
Total: 97856 W: 4602 L: 4303 D: 88951
Ptnml(0-2): 53, 3757, 41057, 3960, 101
https://tests.stockfishchess.org/tests/view/5f8ec4872c92c7fe3a8c602d
closes https://github.com/official-stockfish/Stockfish/pull/3192
Bench 3943959
2020-10-21 07:52:13 -06:00
|
|
|
value = -search<PV>(pos, ss+1, -beta, -alpha,
|
|
|
|
std::min(maxNextDepth, newDepth), false);
|
2014-11-12 14:13:55 -07:00
|
|
|
}
|
2014-11-18 03:57:57 -07:00
|
|
|
|
Introduce ProbCut for check evasions
The idea of this patch can be described as follows: if we are in check
and the transposition table move is a capture that returns a value
far above beta, we can assume that the opponent just blundered a piece
by giving check, and we return the transposition table value. This is
similar to the usual probCut logic for quiet moves, but with a different
threshold.
Passed STC
LLR: 2.94 (-2.94,2.94) {-0.25,1.25}
Total: 33440 W: 3056 L: 2891 D: 27493
Ptnml(0-2): 110, 2338, 11672, 2477, 123
https://tests.stockfishchess.org/tests/view/602cd1087f517a561bc49bda
Passed LTC
LLR: 2.98 (-2.94,2.94) {0.25,1.25}
Total: 10072 W: 401 L: 309 D: 9362
Ptnml(0-2): 2, 288, 4365, 378, 3
https://tests.stockfishchess.org/tests/view/602ceea57f517a561bc49bf0
The committed version has an additional fix to never return unproven wins
in the tablebase range or the mate range. This fix passed tests for non-
regression at STC and LTC:
STC:
LLR: 2.93 (-2.94,2.94) {-1.25,0.25}
Total: 26240 W: 2354 L: 2280 D: 21606
Ptnml(0-2): 85, 1763, 9372, 1793, 107
https://tests.stockfishchess.org/tests/view/602d86a87f517a561bc49c7a
LTC:
LLR: 2.95 (-2.94,2.94) {-0.75,0.25}
Total: 35304 W: 1299 L: 1256 D: 32749
Ptnml(0-2): 14, 1095, 15395, 1130, 18
https://tests.stockfishchess.org/tests/view/602d98d17f517a561bc49c83
Closes https://github.com/official-stockfish/Stockfish/pull/3362
Bench: 3830215
2021-02-20 14:48:08 -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
|
|
|
|
Introduce ProbCut for check evasions
The idea of this patch can be described as follows: if we are in check
and the transposition table move is a capture that returns a value
far above beta, we can assume that the opponent just blundered a piece
by giving check, and we return the transposition table value. This is
similar to the usual probCut logic for quiet moves, but with a different
threshold.
Passed STC
LLR: 2.94 (-2.94,2.94) {-0.25,1.25}
Total: 33440 W: 3056 L: 2891 D: 27493
Ptnml(0-2): 110, 2338, 11672, 2477, 123
https://tests.stockfishchess.org/tests/view/602cd1087f517a561bc49bda
Passed LTC
LLR: 2.98 (-2.94,2.94) {0.25,1.25}
Total: 10072 W: 401 L: 309 D: 9362
Ptnml(0-2): 2, 288, 4365, 378, 3
https://tests.stockfishchess.org/tests/view/602ceea57f517a561bc49bf0
The committed version has an additional fix to never return unproven wins
in the tablebase range or the mate range. This fix passed tests for non-
regression at STC and LTC:
STC:
LLR: 2.93 (-2.94,2.94) {-1.25,0.25}
Total: 26240 W: 2354 L: 2280 D: 21606
Ptnml(0-2): 85, 1763, 9372, 1793, 107
https://tests.stockfishchess.org/tests/view/602d86a87f517a561bc49c7a
LTC:
LLR: 2.95 (-2.94,2.94) {-0.75,0.25}
Total: 35304 W: 1299 L: 1256 D: 32749
Ptnml(0-2): 14, 1095, 15395, 1130, 18
https://tests.stockfishchess.org/tests/view/602d98d17f517a561bc49c83
Closes https://github.com/official-stockfish/Stockfish/pull/3362
Bench: 3830215
2021-02-20 14:48:08 -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
|
|
|
|
Time-management fix in MultiPV mode.
When playing games in MultiPV mode we must take care to only track the
best move changing for the first PV line. Otherwise, SF will spend most
of its time for the initial moves after the book exit.
This has been observed and reported on Discord, but can also be seen in
games played in Stefan Pohl's MultiPV experiment.
Tested with MultiPV=4.
STC:
https://tests.stockfishchess.org/tests/view/615c24b59d256038a969b990
LLR: 2.95 (-2.94,2.94) <-0.50,2.50>
Total: 1744 W: 694 L: 447 D: 603
Ptnml(0-2): 32, 125, 358, 278, 79
LTC:
https://tests.stockfishchess.org/tests/view/615c31769d256038a969b993
LLR: 2.94 (-2.94,2.94) <0.50,3.50>
Total: 2048 W: 723 L: 525 D: 800
Ptnml(0-2): 10, 158, 511, 314, 31
closes https://github.com/official-stockfish/Stockfish/pull/3729
Bench: 5714575
2021-10-05 04:02:25 -06:00
|
|
|
// We record how often the best move has been changed in each iteration.
|
|
|
|
// This information is used for time management and LMR. In MultiPV mode,
|
|
|
|
// we must take care to only do this for the first PV line.
|
|
|
|
if ( moveCount > 1
|
|
|
|
&& !thisThread->pvIdx)
|
Use average bestMoveChanges across all threads #2072
The current update only by main thread depends on the luck of
whether main thread sees any/many changes to the best move or not.
It then makes large, lumpy changes to the time to be
used (1x, 2x, 3x, etc) depending on that sample of 1.
Use the average across all threads to get a more reliable
number with a smoother distribution.
STC @ 5+0.05 th 4 :
LLR: 2.95 (-2.94,2.94) [0.50,4.50]
Total: 51899 W: 11446 L: 11029 D: 29424
http://tests.stockfishchess.org/tests/view/5ca32ff20ebc5925cf0016fb
STC @ 5+0.05 th 8 :
LLR: 2.96 (-2.94,2.94) [0.50,4.50]
Total: 13851 W: 2843 L: 2620 D: 8388
http://tests.stockfishchess.org/tests/view/5ca35ae00ebc5925cf001adb
LTC @ 20+0.2 th 8 :
LLR: 2.95 (-2.94,2.94) [0.00,3.50]
Total: 48527 W: 7941 L: 7635 D: 32951
http://tests.stockfishchess.org/tests/view/5ca37cb70ebc5925cf001cec
Further work:
Similar changes might be possible for the fallingEval and timeReduction calculations (and elsewhere?), using either the min, average or max values across all threads.
Bench 3506898
2019-04-03 01:35:55 -06:00
|
|
|
++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
|
Reduce more if multiple moves exceed alpha
Idea of this patch is the following: in case we already have four moves that
exceeded alpha in the current node, the probability of finding fifth should
be reasonably low. Note that four is completely arbitrary - there could and
probably should be some tweaks, both in tweaking best move count threshold
for more reductions and tweaking how they work - for example making more
reductions with best move count linearly.
passed STC:
https://tests.stockfishchess.org/tests/view/615f614783dd501a05b0aee2
LLR: 2.94 (-2.94,2.94) <-0.50,2.50>
Total: 141816 W: 36056 L: 35686 D: 70074
Ptnml(0-2): 499, 15131, 39273, 15511, 494
passed LTC:
https://tests.stockfishchess.org/tests/view/615fdff683dd501a05b0af35
LLR: 2.94 (-2.94,2.94) <0.50,3.50>
Total: 68536 W: 17221 L: 16891 D: 34424
Ptnml(0-2): 38, 6573, 20725, 6885, 47
closes https://github.com/official-stockfish/Stockfish/pull/3736
Bench: 6131513
2021-10-08 17:15:43 -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
|
|
|
alpha = value;
|
Reduce more if multiple moves exceed alpha
Idea of this patch is the following: in case we already have four moves that
exceeded alpha in the current node, the probability of finding fifth should
be reasonably low. Note that four is completely arbitrary - there could and
probably should be some tweaks, both in tweaking best move count threshold
for more reductions and tweaking how they work - for example making more
reductions with best move count linearly.
passed STC:
https://tests.stockfishchess.org/tests/view/615f614783dd501a05b0aee2
LLR: 2.94 (-2.94,2.94) <-0.50,2.50>
Total: 141816 W: 36056 L: 35686 D: 70074
Ptnml(0-2): 499, 15131, 39273, 15511, 494
passed LTC:
https://tests.stockfishchess.org/tests/view/615fdff683dd501a05b0af35
LLR: 2.94 (-2.94,2.94) <0.50,3.50>
Total: 68536 W: 17221 L: 16891 D: 34424
Ptnml(0-2): 38, 6573, 20725, 6885, 47
closes https://github.com/official-stockfish/Stockfish/pull/3736
Bench: 6131513
2021-10-08 17:15:43 -06:00
|
|
|
bestMoveCount++;
|
|
|
|
}
|
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
|
2012-10-05 07:00:35 -06:00
|
|
|
break;
|
|
|
|
}
|
2011-08-06 02:15:46 -06:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2020-12-01 05:02:35 -07:00
|
|
|
// If the move is worse than some previously searched move, remember it to update its stats later
|
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;
|
|
|
|
*/
|
|
|
|
|
Introduce ProbCut for check evasions
The idea of this patch can be described as follows: if we are in check
and the transposition table move is a capture that returns a value
far above beta, we can assume that the opponent just blundered a piece
by giving check, and we return the transposition table value. This is
similar to the usual probCut logic for quiet moves, but with a different
threshold.
Passed STC
LLR: 2.94 (-2.94,2.94) {-0.25,1.25}
Total: 33440 W: 3056 L: 2891 D: 27493
Ptnml(0-2): 110, 2338, 11672, 2477, 123
https://tests.stockfishchess.org/tests/view/602cd1087f517a561bc49bda
Passed LTC
LLR: 2.98 (-2.94,2.94) {0.25,1.25}
Total: 10072 W: 401 L: 309 D: 9362
Ptnml(0-2): 2, 288, 4365, 378, 3
https://tests.stockfishchess.org/tests/view/602ceea57f517a561bc49bf0
The committed version has an additional fix to never return unproven wins
in the tablebase range or the mate range. This fix passed tests for non-
regression at STC and LTC:
STC:
LLR: 2.93 (-2.94,2.94) {-1.25,0.25}
Total: 26240 W: 2354 L: 2280 D: 21606
Ptnml(0-2): 85, 1763, 9372, 1793, 107
https://tests.stockfishchess.org/tests/view/602d86a87f517a561bc49c7a
LTC:
LLR: 2.95 (-2.94,2.94) {-0.75,0.25}
Total: 35304 W: 1299 L: 1256 D: 32749
Ptnml(0-2): 14, 1095, 15395, 1130, 18
https://tests.stockfishchess.org/tests/view/602d98d17f517a561bc49c83
Closes https://github.com/official-stockfish/Stockfish/pull/3362
Bench: 3830215
2021-02-20 14:48:08 -07: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
|
|
|
|
continuation histories when in check
If in check, don't write to continuation histories ss-4, ss-6.
Adding inCheck to the stack was needed, and might be useful for
future patches.
Passed STC:
https://tests.stockfishchess.org/tests/view/5e9ee24acaaff5d60a50b812
LLR: 2.94 (-2.94,2.94) {-0.50,1.50}
Total: 61774 W: 11725 L: 11449 D: 38600
Ptnml(0-2): 971, 7211, 14322, 7337, 1046
Passed LTC:
https://tests.stockfishchess.org/tests/view/5e9eecb7caaff5d60a50b831
LLR: 2.94 (-2.94,2.94) {0.25,1.75}
Total: 250822 W: 32067 L: 31179 D: 187576
Ptnml(0-2): 1745, 23126, 74824, 23928, 1788
closes https://github.com/official-stockfish/Stockfish/pull/2645
bench: 4808463
2020-04-21 12:55:41 -06:00
|
|
|
assert(moveCount || !ss->inCheck || excludedMove || !MoveList<LEGAL>(pos).size());
|
2016-10-03 07:36:40 -06:00
|
|
|
|
2012-10-03 06:11:20 -06:00
|
|
|
if (!moveCount)
|
2021-03-19 12:43:25 -06:00
|
|
|
bestValue = excludedMove ? alpha :
|
|
|
|
ss->inCheck ? mated_in(ss->ply)
|
|
|
|
: VALUE_DRAW;
|
2016-08-24 08:52:05 -06:00
|
|
|
|
2020-12-01 05:02:35 -07:00
|
|
|
// If there is a move which produces search value greater than alpha we update stats of searched moves
|
Refactor final stats updates.
This PR refactors update_quiet_stats, update_capture_stats and search to more clearly reflect what is actually done.
Effectively, all stat updates that need to be done after search is finished and a bestmove is found,
are collected in a new function ```final_stats_update()```. This shortens our main search routine, and simplifies ```update_quiet_stats```.
The latter function is now more easily reusable with fewer arguments, as the handling of ```quietsSearched``` is only needed in ```final_stats_update```.
```update_capture_stats```, which was only called once is now integrated in ```final_stats_update```, which allows for removing a branch and reusing some ```stat_bonus``` calls. The need for refactoring was also suggested by the fact that the comments of ```update_quiet_stats``` and ```update_capture_stats``` were incorrect (e.g. ```update_capture_stats``` was called, correctly, also when the bestmove was a quiet and not a capture).
passed non-regression STC:
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 75196 W: 16364 L: 16347 D: 42485
http://tests.stockfishchess.org/tests/view/5db004ec0ebc5902c06db9e1
The diff is most easily readable as ```git diff master --patience```
No functional change
2019-10-23 00:26:47 -06:00
|
|
|
else if (bestMove)
|
|
|
|
update_all_stats(pos, ss, bestMove, bestValue, beta, prevSq,
|
Revert 5 recent patches
Revert 5 patches which were merged, but lead to a regression test that showed negative Elo gain:
http://tests.stockfishchess.org/tests/view/5e307251ab2d69d58394fdb9
This was discussed in depth in:
https://github.com/official-stockfish/Stockfish/issues/2531
Each patch was removed and tested as a simplification, full list below, and the whole combo as well.
After the revert the regression test showed a neutral result:
http://tests.stockfishchess.org/tests/view/5e334851708b13464ceea33c
As a result of this experience, the SPRT testing bounds will be made more strict.
Reverted patches:
1 Dynamic Complexity 6d0eabd5fe2961551477820ab7619e2c31e01ffd :
STC 10+0.1 https://tests.stockfishchess.org/tests/view/5e31fcacec661e2e6a340d08 :
LLR: 2.97 (-2.94,2.94) {-1.50,0.50}
Total: 38130 W: 7326 L: 7189 D: 23615
Ptnml(0-2): 677, 4346, 8843, 4545, 646
LTC 60+0.6 https://tests.stockfishchess.org/tests/view/5e32c18fec661e2e6a340d73 :
LLR: 2.94 (-2.94,2.94) {-1.50,0.50}
Total: 38675 W: 4941 L: 4866 D: 28868
Ptnml(0-2): 270, 3556, 11429, 3584, 291
3 More bonus for bestMoves on past PV nodes 71e0b5385e2717679a57c6b77d8c7ac5fff3b89f :
STC 10+0.1 https://tests.stockfishchess.org/tests/view/5e31fe93ec661e2e6a340d10 :
LLR: 2.95 (-2.94,2.94) {-1.50,0.50}
Total: 46100 W: 8853 L: 8727 D: 28520
Ptnml(0-2): 796, 5297, 10749, 5387, 813
LTC 60+0.6 https://tests.stockfishchess.org/tests/view/5e32c187ec661e2e6a340d71 :
LLR: 2.96 (-2.94,2.94) {-1.50,0.50}
Total: 16920 W: 2161 L: 2055 D: 12704
Ptnml(0-2): 115, 1498, 5006, 1569, 130
4 Tweak Restricted Piece Bonus 0ae00454ba6928d181b46103e5c83e6d58fcebe5 :
STC 10+0.1 https://tests.stockfishchess.org/tests/view/5e31fefaec661e2e6a340d15 :
LLR: 2.94 (-2.94,2.94) {-1.50,0.50}
Total: 88328 W: 17060 L: 16997 D: 54271
Ptnml(0-2): 1536, 10446, 20169, 10422, 1581
LTC 60+0.6 https://tests.stockfishchess.org/tests/view/5e32c17aec661e2e6a340d6f :
LLR: 2.95 (-2.94,2.94) {-1.50,0.50}
Total: 34784 W: 4551 L: 4466 D: 25767
Ptnml(0-2): 255, 3279, 10061, 3345, 262
5 History update for pruned captures 01b6088af39902001d2d6844561b6a2faa549282 :
STC 10+0.1 https://tests.stockfishchess.org/tests/view/5e31ff5eec661e2e6a340d1a :
LLR: 2.94 (-2.94,2.94) {-1.50,0.50}
Total: 29541 W: 5735 L: 5588 D: 18218
Ptnml(0-2): 483, 3445, 6820, 3469, 545
LTC 60+0.6 https://tests.stockfishchess.org/tests/view/5e32c196ec661e2e6a340d75 :
LLR: 2.94 (-2.94,2.94) {-1.50,0.50}
Total: 22177 W: 2854 L: 2757 D: 16566
Ptnml(0-2): 143, 2005, 6555, 2055, 164
6 Tweak trapped rook penalty 18fc21eba0368fd5e3c4c4b8ee1000c9ac445425 :
STC 10+0.1 https://tests.stockfishchess.org/tests/view/5e31ffb1ec661e2e6a340d1c :
LLR: 2.95 (-2.94,2.94) {-1.50,0.50}
Total: 24476 W: 4727 L: 4569 D: 15180
Ptnml(0-2): 390, 2834, 5659, 2933, 417
LTC 60+0.6 https://tests.stockfishchess.org/tests/view/5e32c19eec661e2e6a340d77 :
LLR: 2.95 (-2.94,2.94) {-1.50,0.50}
Total: 97332 W: 12492 L: 12466 D: 72374
Ptnml(0-2): 690, 9107, 28738, 9034, 720
All 5 as one simplification :
LTC 60+0.6 https://tests.stockfishchess.org/tests/view/5e334098708b13464ceea330 :
LLR: 2.94 (-2.94,2.94) {-1.50,0.50}
Total: 7829 W: 1079 L: 964 D: 5786
Ptnml(0-2): 52, 690, 2281, 781, 65
Bench: 5153165
2020-01-30 13:44:04 -07:00
|
|
|
quietsSearched, quietCount, capturesSearched, captureCount, depth);
|
2018-12-06 06:39:41 -07:00
|
|
|
|
2015-10-12 15:00:54 -06:00
|
|
|
// Bonus for prior countermove that caused the fail low
|
2019-09-28 14:27:23 -06:00
|
|
|
else if ( (depth >= 3 || PvNode)
|
2019-10-05 08:42:36 -06:00
|
|
|
&& !priorCapture)
|
Further improve history updates
Now even double history updates if a search failed low at an expected PV or CUT node.
STC:
LLR: 2.93 (-2.94,2.94) <-0.50,2.50>
Total: 30736 W: 7891 L: 7674 D: 15171
Ptnml(0-2): 90, 3477, 8017, 3694, 90
https://tests.stockfishchess.org/tests/view/61364ae30cd98ab40c0c9da5
LTC:
LLR: 2.94 (-2.94,2.94) <0.50,3.50>
Total: 73600 W: 18684 L: 18326 D: 36590
Ptnml(0-2): 41, 7734, 20899, 8078, 48
https://tests.stockfishchess.org/tests/view/6136940f0cd98ab40c0c9df3
closes https://github.com/official-stockfish/Stockfish/pull/3694
Bench: 6030657
2021-09-07 05:22:20 -06:00
|
|
|
update_continuation_histories(ss-1, pos.piece_on(prevSq), prevSq, stat_bonus(depth) * (1 + (PvNode || cutNode)));
|
2015-10-12 15:00:54 -06:00
|
|
|
|
2018-01-28 06:40:07 -07:00
|
|
|
if (PvNode)
|
|
|
|
bestValue = std::min(bestValue, maxValue);
|
|
|
|
|
Add / remove leaves from search tree ttPv
add if previous leaf is in search tree and we didn't find a counter move
else remove the position if the leaf is the last one in search tree.
STC : https://tests.stockfishchess.org/tests/view/5f49203c3def640786115314
LLR: 2.95 (-2.94,2.94) {-0.25,1.25}
Total: 29968 W: 3381 L: 3195 D: 23392
Ptnml(0-2): 146, 2432, 9671, 2560, 175
LTC : https://tests.stockfishchess.org/tests/view/5f494bea3def640786115336
LLR: 2.96 (-2.94,2.94) {0.25,1.25}
Total: 84952 W: 4619 L: 4333 D: 76000
Ptnml(0-2): 86, 3765, 34481, 4065, 79
closes https://github.com/official-stockfish/Stockfish/pull/3075
Bench 3527337
2020-08-28 04:06:36 -06:00
|
|
|
// If no good move is found and the previous position was ttPv, then the previous
|
|
|
|
// opponent move is probably good and the new position is added to the search tree.
|
|
|
|
if (bestValue <= alpha)
|
|
|
|
ss->ttPv = ss->ttPv || ((ss-1)->ttPv && depth > 3);
|
|
|
|
// Otherwise, a counter move has been found and if the position is the last leaf
|
|
|
|
// in the search tree, remove the position from the search tree.
|
|
|
|
else if (depth > 3)
|
|
|
|
ss->ttPv = ss->ttPv && (ss+1)->ttPv;
|
|
|
|
|
2020-12-01 05:02:35 -07:00
|
|
|
// Write gathered information in transposition table
|
2020-02-24 15:32:17 -07:00
|
|
|
if (!excludedMove && !(rootNode && thisThread->pvIdx))
|
Add / remove leaves from search tree ttPv
add if previous leaf is in search tree and we didn't find a counter move
else remove the position if the leaf is the last one in search tree.
STC : https://tests.stockfishchess.org/tests/view/5f49203c3def640786115314
LLR: 2.95 (-2.94,2.94) {-0.25,1.25}
Total: 29968 W: 3381 L: 3195 D: 23392
Ptnml(0-2): 146, 2432, 9671, 2560, 175
LTC : https://tests.stockfishchess.org/tests/view/5f494bea3def640786115336
LLR: 2.96 (-2.94,2.94) {0.25,1.25}
Total: 84952 W: 4619 L: 4333 D: 76000
Ptnml(0-2): 86, 3765, 34481, 4065, 79
closes https://github.com/official-stockfish/Stockfish/pull/3075
Bench 3527337
2020-08-28 04:06:36 -06:00
|
|
|
tte->save(posKey, value_to_tt(bestValue, ss->ply), ss->ttPv,
|
2017-04-22 01:03:17 -06:00
|
|
|
bestValue >= beta ? BOUND_LOWER :
|
|
|
|
PvNode && bestMove ? BOUND_EXACT : BOUND_UPPER,
|
2019-03-29 07:05:02 -06:00
|
|
|
depth, bestMove, ss->staticEval);
|
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
|
|
|
|
2019-03-31 04:02:19 -06:00
|
|
|
// qsearch() is the quiescence search function, which is called by the main search
|
|
|
|
// function with zero depth, or recursively with further decreasing depth per call.
|
Introducing NodeType Root
We transform rootNode into constexpr by adding a new NodeType `Root`,
which causes a speed up.
Local test:
```
Build Tester: 1.4.7.0
Windows 10 (Version 10.0, Build 0, 64-bit Edition)
Intel(R) Core(TM) i7-8750H CPU @ 2.20GHz
SafeMode: No
Running In VM: No
HyperThreading Enabled: Yes
CPU Warmup: Yes
Command Line: bench
Tests per Build: 25
ANOVA: n/a
Engine# (NPS) Speedup Sp Conf. 95% S.S.
patch (920.179,4) ---> master (906.329,2) ---> 1,528% 20.336,5 Yes No
```
---------
STC:
LLR: 2.94 (-2.94,2.94) <-0.50,2.50>
Total: 98216 W: 8348 L: 8102 D: 81766
Ptnml(0-2): 295, 6357, 35549, 6621, 286
https://tests.stockfishchess.org/tests/view/60b797e2457376eb8bcaa0ab
Yellow LTC:
LLR: -2.95 (-2.94,2.94) <0.50,3.50>
Total: 76936 W: 2651 L: 2626 D: 71659
Ptnml(0-2): 29, 2233, 33916, 2264, 26
https://tests.stockfishchess.org/tests/view/60b80d6d457376eb8bcaa145
closes https://github.com/official-stockfish/Stockfish/pull/3522
No functional change
2021-06-03 10:52:39 -06:00
|
|
|
template <NodeType nodeType>
|
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
|
|
|
|
Introducing NodeType Root
We transform rootNode into constexpr by adding a new NodeType `Root`,
which causes a speed up.
Local test:
```
Build Tester: 1.4.7.0
Windows 10 (Version 10.0, Build 0, 64-bit Edition)
Intel(R) Core(TM) i7-8750H CPU @ 2.20GHz
SafeMode: No
Running In VM: No
HyperThreading Enabled: Yes
CPU Warmup: Yes
Command Line: bench
Tests per Build: 25
ANOVA: n/a
Engine# (NPS) Speedup Sp Conf. 95% S.S.
patch (920.179,4) ---> master (906.329,2) ---> 1,528% 20.336,5 Yes No
```
---------
STC:
LLR: 2.94 (-2.94,2.94) <-0.50,2.50>
Total: 98216 W: 8348 L: 8102 D: 81766
Ptnml(0-2): 295, 6357, 35549, 6621, 286
https://tests.stockfishchess.org/tests/view/60b797e2457376eb8bcaa0ab
Yellow LTC:
LLR: -2.95 (-2.94,2.94) <0.50,3.50>
Total: 76936 W: 2651 L: 2626 D: 71659
Ptnml(0-2): 29, 2233, 33916, 2264, 26
https://tests.stockfishchess.org/tests/view/60b80d6d457376eb8bcaa145
closes https://github.com/official-stockfish/Stockfish/pull/3522
No functional change
2021-06-03 10:52:39 -06:00
|
|
|
static_assert(nodeType != Root);
|
|
|
|
constexpr bool PvNode = nodeType == 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));
|
2019-09-28 14:27:23 -06:00
|
|
|
assert(depth <= 0);
|
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;
|
2021-04-19 11:50:19 -06:00
|
|
|
ASSERT_ALIGNED(&st, Eval::NNUE::CacheLineSize);
|
2020-11-03 03:23:35 -07:00
|
|
|
|
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;
|
Adjust penalty on refuted early quiet moves
This patch changes how previous early moves are penalized in case
search finds a best move. Here, the first quiet move that was not
a transposition table move is penalized.
passed STC
https://tests.stockfishchess.org/tests/view/5f51d839ba100690c5cc5f69
LLR: 2.94 (-2.94,2.94) {-0.25,1.25}
Total: 10088 W: 1150 L: 997 D: 7941
Ptnml(0-2): 41, 772, 3278, 899, 54
passed LTC
https://tests.stockfishchess.org/tests/view/5f51e435ba100690c5cc5f76
LLR: 2.93 (-2.94,2.94) {0.25,1.25}
Total: 30808 W: 1564 L: 1405 D: 27839
Ptnml(0-2): 19, 1245, 12717, 1404, 19
closes https://github.com/official-stockfish/Stockfish/pull/3106
bench 3983758
2020-09-04 06:53:59 -06:00
|
|
|
bool pvHit, givesCheck, captureOrPromotion;
|
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();
|
2019-04-13 09:17:47 -06:00
|
|
|
bestMove = MOVE_NONE;
|
continuation histories when in check
If in check, don't write to continuation histories ss-4, ss-6.
Adding inCheck to the stack was needed, and might be useful for
future patches.
Passed STC:
https://tests.stockfishchess.org/tests/view/5e9ee24acaaff5d60a50b812
LLR: 2.94 (-2.94,2.94) {-0.50,1.50}
Total: 61774 W: 11725 L: 11449 D: 38600
Ptnml(0-2): 971, 7211, 14322, 7337, 1046
Passed LTC:
https://tests.stockfishchess.org/tests/view/5e9eecb7caaff5d60a50b831
LLR: 2.94 (-2.94,2.94) {0.25,1.75}
Total: 250822 W: 32067 L: 31179 D: 187576
Ptnml(0-2): 1745, 23126, 74824, 23928, 1788
closes https://github.com/official-stockfish/Stockfish/pull/2645
bench: 4808463
2020-04-21 12:55:41 -06:00
|
|
|
ss->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)
|
continuation histories when in check
If in check, don't write to continuation histories ss-4, ss-6.
Adding inCheck to the stack was needed, and might be useful for
future patches.
Passed STC:
https://tests.stockfishchess.org/tests/view/5e9ee24acaaff5d60a50b812
LLR: 2.94 (-2.94,2.94) {-0.50,1.50}
Total: 61774 W: 11725 L: 11449 D: 38600
Ptnml(0-2): 971, 7211, 14322, 7337, 1046
Passed LTC:
https://tests.stockfishchess.org/tests/view/5e9eecb7caaff5d60a50b831
LLR: 2.94 (-2.94,2.94) {0.25,1.75}
Total: 250822 W: 32067 L: 31179 D: 187576
Ptnml(0-2): 1745, 23126, 74824, 23928, 1788
closes https://github.com/official-stockfish/Stockfish/pull/2645
bench: 4808463
2020-04-21 12:55:41 -06:00
|
|
|
return (ss->ply >= MAX_PLY && !ss->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.
|
continuation histories when in check
If in check, don't write to continuation histories ss-4, ss-6.
Adding inCheck to the stack was needed, and might be useful for
future patches.
Passed STC:
https://tests.stockfishchess.org/tests/view/5e9ee24acaaff5d60a50b812
LLR: 2.94 (-2.94,2.94) {-0.50,1.50}
Total: 61774 W: 11725 L: 11449 D: 38600
Ptnml(0-2): 971, 7211, 14322, 7337, 1046
Passed LTC:
https://tests.stockfishchess.org/tests/view/5e9eecb7caaff5d60a50b831
LLR: 2.94 (-2.94,2.94) {0.25,1.75}
Total: 250822 W: 32067 L: 31179 D: 187576
Ptnml(0-2): 1745, 23126, 74824, 23928, 1788
closes https://github.com/official-stockfish/Stockfish/pull/2645
bench: 4808463
2020-04-21 12:55:41 -06:00
|
|
|
ttDepth = ss->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();
|
Adjust penalty on refuted early quiet moves
This patch changes how previous early moves are penalized in case
search finds a best move. Here, the first quiet move that was not
a transposition table move is penalized.
passed STC
https://tests.stockfishchess.org/tests/view/5f51d839ba100690c5cc5f69
LLR: 2.94 (-2.94,2.94) {-0.25,1.25}
Total: 10088 W: 1150 L: 997 D: 7941
Ptnml(0-2): 41, 772, 3278, 899, 54
passed LTC
https://tests.stockfishchess.org/tests/view/5f51e435ba100690c5cc5f76
LLR: 2.93 (-2.94,2.94) {0.25,1.25}
Total: 30808 W: 1564 L: 1405 D: 27839
Ptnml(0-2): 19, 1245, 12717, 1404, 19
closes https://github.com/official-stockfish/Stockfish/pull/3106
bench 3983758
2020-09-04 06:53:59 -06:00
|
|
|
tte = TT.probe(posKey, ss->ttHit);
|
|
|
|
ttValue = ss->ttHit ? value_from_tt(tte->value(), ss->ply, pos.rule50_count()) : VALUE_NONE;
|
|
|
|
ttMove = ss->ttHit ? tte->move() : MOVE_NONE;
|
|
|
|
pvHit = ss->ttHit && tte->is_pv();
|
2012-10-07 01:34:04 -06:00
|
|
|
|
2014-11-18 03:57:57 -07:00
|
|
|
if ( !PvNode
|
Adjust penalty on refuted early quiet moves
This patch changes how previous early moves are penalized in case
search finds a best move. Here, the first quiet move that was not
a transposition table move is penalized.
passed STC
https://tests.stockfishchess.org/tests/view/5f51d839ba100690c5cc5f69
LLR: 2.94 (-2.94,2.94) {-0.25,1.25}
Total: 10088 W: 1150 L: 997 D: 7941
Ptnml(0-2): 41, 772, 3278, 899, 54
passed LTC
https://tests.stockfishchess.org/tests/view/5f51e435ba100690c5cc5f76
LLR: 2.93 (-2.94,2.94) {0.25,1.25}
Total: 30808 W: 1564 L: 1405 D: 27839
Ptnml(0-2): 19, 1245, 12717, 1404, 19
closes https://github.com/official-stockfish/Stockfish/pull/3106
bench 3983758
2020-09-04 06:53:59 -06:00
|
|
|
&& ss->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
|
continuation histories when in check
If in check, don't write to continuation histories ss-4, ss-6.
Adding inCheck to the stack was needed, and might be useful for
future patches.
Passed STC:
https://tests.stockfishchess.org/tests/view/5e9ee24acaaff5d60a50b812
LLR: 2.94 (-2.94,2.94) {-0.50,1.50}
Total: 61774 W: 11725 L: 11449 D: 38600
Ptnml(0-2): 971, 7211, 14322, 7337, 1046
Passed LTC:
https://tests.stockfishchess.org/tests/view/5e9eecb7caaff5d60a50b831
LLR: 2.94 (-2.94,2.94) {0.25,1.75}
Total: 250822 W: 32067 L: 31179 D: 187576
Ptnml(0-2): 1745, 23126, 74824, 23928, 1788
closes https://github.com/official-stockfish/Stockfish/pull/2645
bench: 4808463
2020-04-21 12:55:41 -06:00
|
|
|
if (ss->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
|
|
|
{
|
Adjust penalty on refuted early quiet moves
This patch changes how previous early moves are penalized in case
search finds a best move. Here, the first quiet move that was not
a transposition table move is penalized.
passed STC
https://tests.stockfishchess.org/tests/view/5f51d839ba100690c5cc5f69
LLR: 2.94 (-2.94,2.94) {-0.25,1.25}
Total: 10088 W: 1150 L: 997 D: 7941
Ptnml(0-2): 41, 772, 3278, 899, 54
passed LTC
https://tests.stockfishchess.org/tests/view/5f51e435ba100690c5cc5f76
LLR: 2.93 (-2.94,2.94) {0.25,1.25}
Total: 30808 W: 1564 L: 1405 D: 27839
Ptnml(0-2): 19, 1245, 12717, 1404, 19
closes https://github.com/official-stockfish/Stockfish/pull/3106
bench 3983758
2020-09-04 06:53:59 -06:00
|
|
|
if (ss->ttHit)
|
2012-12-27 04:13:31 -07:00
|
|
|
{
|
2019-06-09 07:07:36 -06:00
|
|
|
// Never assume anything about 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
|
2020-12-01 05:02:35 -07:00
|
|
|
// In case of null move search use previous static eval with a different sign
|
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)
|
Remove Tempo
The Tempo variable was introduced 10 years ago in our search because the
classical evaluation function was antisymmetrical in White and Black by design
to gain speed:
Eval(White to play) = -Eval(Black to play)
Nowadays our neural networks know which side is to play in a position when
they evaluate a position and are trained on real games, so the neural network
encodes the advantage of moving as an output of search. This patch shows that
the Tempo variable is not necessary anymore.
STC:
LLR: 2.94 (-2.94,2.94) <-2.50,0.50>
Total: 33512 W: 2805 L: 2709 D: 27998
Ptnml(0-2): 80, 2209, 12095, 2279, 93
https://tests.stockfishchess.org/tests/view/60a44ceace8ea25a3ef03d30
LTC:
LLR: 2.95 (-2.94,2.94) <-2.50,0.50>
Total: 53920 W: 1807 L: 1760 D: 50353
Ptnml(0-2): 16, 1617, 23650, 1658, 19
https://tests.stockfishchess.org/tests/view/60a477f0ce8ea25a3ef03d49
We also tried a match (20000 games) at STC using purely classical, result was neutral:
https://tests.stockfishchess.org/tests/view/60a4eebcce8ea25a3ef03db5
Note: there are two locations left in search.cpp where we assume antisymmetry
of evaluation (in relation with a speed optimization for null moves in lines
770 and 1439), but as the values are just used for heuristic pruning this
approximation should not hurt too much because the order of magnitude is still
true most of the time.
closes https://github.com/official-stockfish/Stockfish/pull/3481
Bench: 4015864
2021-05-18 17:24:51 -06:00
|
|
|
: -(ss-1)->staticEval;
|
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)
|
|
|
|
{
|
2020-12-01 05:02:35 -07:00
|
|
|
// Save gathered info in transposition table
|
Adjust penalty on refuted early quiet moves
This patch changes how previous early moves are penalized in case
search finds a best move. Here, the first quiet move that was not
a transposition table move is penalized.
passed STC
https://tests.stockfishchess.org/tests/view/5f51d839ba100690c5cc5f69
LLR: 2.94 (-2.94,2.94) {-0.25,1.25}
Total: 10088 W: 1150 L: 997 D: 7941
Ptnml(0-2): 41, 772, 3278, 899, 54
passed LTC
https://tests.stockfishchess.org/tests/view/5f51e435ba100690c5cc5f76
LLR: 2.93 (-2.94,2.94) {0.25,1.25}
Total: 30808 W: 1564 L: 1405 D: 27839
Ptnml(0-2): 19, 1245, 12717, 1404, 19
closes https://github.com/official-stockfish/Stockfish/pull/3106
bench 3983758
2020-09-04 06:53:59 -06:00
|
|
|
if (!ss->ttHit)
|
2020-03-01 01:31:17 -07:00
|
|
|
tte->save(posKey, value_to_tt(bestValue, ss->ply), false, 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
|
|
|
|
Assorted search and eval parameter tune
Search and eval parameter tune.
STC https://tests.stockfishchess.org/tests/view/5fba850a67cbf42301d6b07d
LLR: 2.94 (-2.94,2.94) {-0.25,1.25}
Total: 24312 W: 2388 L: 2228 D: 19696
Ptnml(0-2): 85, 1800, 8241, 1930, 100
LTC https://tests.stockfishchess.org/tests/view/5fbad5ea67cbf42301d6b0fa
LLR: 2.95 (-2.94,2.94) {0.25,1.25}
Total: 88376 W: 3619 L: 3351 D: 81406
Ptnml(0-2): 56, 2977, 37849, 3255, 51
closes https://github.com/official-stockfish/Stockfish/pull/3232
bench: 3600361
2020-11-24 09:06:30 -07:00
|
|
|
futilityBase = bestValue + 155;
|
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,
|
2019-10-18 07:23:00 -06:00
|
|
|
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,
|
Simplify promotion move generator
This patch removes Knight promotion checks from Captures. As a consequence,
it also removes this underpromotion from qsearch.
STC:
LLR: 2.93 (-2.94,2.94) <-2.50,0.50>
Total: 37776 W: 3113 L: 3023 D: 31640
Ptnml(0-2): 103, 2419, 13755, 2507, 104
https://tests.stockfishchess.org/tests/view/60be6a06457376eb8bcaa775
LTC:
LLR: 2.93 (-2.94,2.94) <-2.50,0.50>
Total: 39760 W: 1257 L: 1203 D: 37300
Ptnml(0-2): 11, 1079, 17646, 1133, 11
https://tests.stockfishchess.org/tests/view/60beb972457376eb8bcaa7c5
closes https://github.com/official-stockfish/Stockfish/pull/3536
Bench: 5530620
2021-06-07 12:47:37 -06:00
|
|
|
// queen promotions, and other checks (only if depth >= DEPTH_QS_CHECKS)
|
Simplify make_promotions()
Remove special case handling of QUIET_CHECKS in make_promotions()
STC https://tests.stockfishchess.org/tests/view/5f055dbb59f6f035328945fb
LLR: 2.98 (-2.94,2.94) {-1.50,0.50}
Total: 42808 W: 8177 L: 8054 D: 26577
Ptnml(0-2): 665, 4890, 10201, 4953, 695
LTC https://tests.stockfishchess.org/tests/view/5f06231a59f6f03532894661
LLR: 2.96 (-2.94,2.94) {-1.50,0.50}
Total: 9616 W: 1214 L: 1111 D: 7291
Ptnml(0-2): 53, 821, 2965, 908, 61
closes https://github.com/official-stockfish/Stockfish/pull/2800
Bench: 4576410
2020-07-05 16:17:04 -06:00
|
|
|
// 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
|
|
|
|
Prune illegal moves in qsearch earlier
The main idea is that illegal moves influencing search or
qsearch obviously can't be any sort of good. The only reason
why initially legality checks for search and qsearch were done
after they actually can influence some heuristics is because
legality check is expensive computationally. Eventually in
search it was moved to the place where it makes sure that
illegal moves can't influence search.
This patch shows that the same can be done for qsearch + it
passed STC with elo-gaining bounds + it removes 3 lines of code
because one no longer needs to increment/decrement movecount
on illegal moves.
passed STC with elo-gaining bounds
https://tests.stockfishchess.org/tests/view/60f20aefd1189bed71812da0
LLR: 2.94 (-2.94,2.94) <-0.50,2.50>
Total: 61512 W: 4688 L: 4492 D: 52332
Ptnml(0-2): 139, 3730, 22848, 3874, 165
The same version functionally but with moving condition ever earlier
passed LTC with simplification bounds.
https://tests.stockfishchess.org/tests/view/60f292cad1189bed71812de9
LLR: 2.98 (-2.94,2.94) <-2.50,0.50>
Total: 60944 W: 1724 L: 1685 D: 57535
Ptnml(0-2): 11, 1556, 27298, 1597, 10
closes https://github.com/official-stockfish/Stockfish/pull/3618
bench 4709569
2021-07-18 04:51:14 -06:00
|
|
|
// Check for legality
|
|
|
|
if (!pos.legal(move))
|
|
|
|
continue;
|
|
|
|
|
2019-03-31 02:44:55 -06:00
|
|
|
givesCheck = pos.gives_check(move);
|
2019-10-18 07:23:00 -06:00
|
|
|
captureOrPromotion = pos.capture_or_promotion(move);
|
2010-01-08 03:45:46 -07:00
|
|
|
|
2017-05-21 19:25:20 -06:00
|
|
|
moveCount++;
|
|
|
|
|
Change advanced pawn push threshold
A pawn push is now considered to be "advanced" if the relative destination
rank is > 6 (previously it was > 5). This affects the search heuristic.
Also remove an assert concerning en passant moves in qsearch().
STC:
LLR: 2.97 (-2.94,2.94) {-0.25,1.25}
Total: 46744 W: 4224 L: 4040 D: 38480
Ptnml(0-2): 165, 3206, 16451, 3380, 170
https://tests.stockfishchess.org/tests/view/604746082433018de7a3872e
LTC:
LLR: 2.94 (-2.94,2.94) {0.25,1.25}
Total: 107840 W: 4198 L: 3892 D: 99750
Ptnml(0-2): 58, 3472, 46557, 3772, 61
https://tests.stockfishchess.org/tests/view/60475eae2433018de7a38737
Closes https://github.com/official-stockfish/Stockfish/pull/3389
Bench: 4796780
2021-03-08 11:46:41 -07:00
|
|
|
// Futility pruning and moveCount pruning
|
Qsearch pruning: follow-up
This is a follow-up of the recent qsearch pruning patch in
https://github.com/official-stockfish/Stockfish/commit/a260c9a8a24a2630a900efc3821000c3481b0c5d
We now use the same guard condition (testing that we already have a defense with
a score better score than a TB loss) for all pruning heuristics in qsearch().
This allows some pruning when in check, but in a controlled way to ensure that
no wrong mate scores appear.
Tested with Elo-gaining bounds:
STC:
LLR: 2.97 (-2.94,2.94) {-0.25,1.25}
Total: 22632 W: 2433 L: 2264 D: 17935
Ptnml(0-2): 98, 1744, 7487, 1865, 122
https://tests.stockfishchess.org/tests/view/5fa59405936c54e11ec99515
LTC:
LLR: 2.94 (-2.94,2.94) {0.25,1.25}
Total: 105432 W: 4965 L: 4648 D: 95819
Ptnml(0-2): 85, 4110, 44011, 4423, 87
https://tests.stockfishchess.org/tests/view/5fa5b609936c54e11ec9952a
closes https://github.com/official-stockfish/Stockfish/pull/3221
Bench: 3578092
2020-11-06 11:20:27 -07:00
|
|
|
if ( bestValue > VALUE_TB_LOSS_IN_MAX_PLY
|
2011-04-29 08:26:48 -06:00
|
|
|
&& !givesCheck
|
2013-08-24 02:05:48 -06:00
|
|
|
&& futilityBase > -VALUE_KNOWN_WIN
|
Remove advanced_pawn_push()
Continuation of work by @topologist: we now do futility pruning and movecount
pruning in qsearch() for pawn pushes up to the 7th rank. So the condition to
avoid the pruning is if the move is a promotion or not. This allows to get rid
of the advanced_pawn_push() function in position.h alltogether.
Passed STC
https://tests.stockfishchess.org/tests/view/6048c5842433018de7a387e6
LLR: 2.93 (-2.94,2.94) {-1.25,0.25}
Total: 34424 W: 3081 L: 3015 D: 28328
Ptnml(0-2): 110, 2442, 12052, 2488, 120
Passed LTC
https://tests.stockfishchess.org/tests/view/6048f7d22433018de7a387f0
LLR: 2.94 (-2.94,2.94) {-0.75,0.25}
Total: 142024 W: 5170 L: 5202 D: 131652
Ptnml(0-2): 50, 4678, 61613, 4596, 75
Closes https://github.com/official-stockfish/Stockfish/pull/3390
Bench: 4339126
2021-03-11 04:51:20 -07:00
|
|
|
&& type_of(move) != PROMOTION)
|
2008-09-07 00:31:30 -06:00
|
|
|
{
|
2013-12-04 08:49:01 -07:00
|
|
|
|
Simplify MCP in QS
Simplify moveCount pruning in QS by removing depth dependency.
STC
LLR: 2.94 (-2.94,2.94) {-1.25,0.25}
Total: 42960 W: 4741 L: 4661 D: 33558
Ptnml(0-2): 218, 3574, 13804, 3678, 206
https://tests.stockfishchess.org/tests/view/5f42e3f75089a564a10d8493
LTC
LLR: 2.94 (-2.94,2.94) {-0.75,0.25}
Total: 66672 W: 3563 L: 3508 D: 59601
Ptnml(0-2): 71, 3064, 26996, 3149, 56
https://tests.stockfishchess.org/tests/view/5f4353285089a564a10d84d0
closes https://github.com/official-stockfish/Stockfish/pull/3067
Bench: 4074430
2020-08-25 07:10:47 -06:00
|
|
|
if (moveCount > 2)
|
Introduce movecount pruning for qsearch()
If in quiescence search, we assume that me can prune late moves when:
a) the move ordering count of the move is : moveCount > abs(depth) + 2
b) we are not in check
c) the late move does not give check
d) the late move is not an advanced pawn push
Modification of an original idea by @VoyagerOne.
STC
https://tests.stockfishchess.org/tests/view/5f40581787a5c3c63d8f535f
LLR: 2.96 (-2.94,2.94) {-0.25,1.25}
Total: 132848 W: 14999 L: 14661 D: 103188
Ptnml(0-2): 684, 11242, 42309, 11430, 759
LTC
https://tests.stockfishchess.org/tests/view/5f4226da87a5c3c63d8f5412
LLR: 2.98 (-2.94,2.94) {0.25,1.25}
Total: 12008 W: 678 L: 551 D: 10779
Ptnml(0-2): 8, 485, 4899, 596, 16
closes https://github.com/official-stockfish/Stockfish/pull/3053
Bench: 3749974
2020-08-23 05:22:32 -06:00
|
|
|
continue;
|
|
|
|
|
2013-12-04 08:49:01 -07:00
|
|
|
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
|
|
|
}
|
|
|
|
|
2020-06-24 14:19:58 -06:00
|
|
|
// Do not search moves with negative SEE values
|
Qsearch pruning: follow-up
This is a follow-up of the recent qsearch pruning patch in
https://github.com/official-stockfish/Stockfish/commit/a260c9a8a24a2630a900efc3821000c3481b0c5d
We now use the same guard condition (testing that we already have a defense with
a score better score than a TB loss) for all pruning heuristics in qsearch().
This allows some pruning when in check, but in a controlled way to ensure that
no wrong mate scores appear.
Tested with Elo-gaining bounds:
STC:
LLR: 2.97 (-2.94,2.94) {-0.25,1.25}
Total: 22632 W: 2433 L: 2264 D: 17935
Ptnml(0-2): 98, 1744, 7487, 1865, 122
https://tests.stockfishchess.org/tests/view/5fa59405936c54e11ec99515
LTC:
LLR: 2.94 (-2.94,2.94) {0.25,1.25}
Total: 105432 W: 4965 L: 4648 D: 95819
Ptnml(0-2): 85, 4110, 44011, 4423, 87
https://tests.stockfishchess.org/tests/view/5fa5b609936c54e11ec9952a
closes https://github.com/official-stockfish/Stockfish/pull/3221
Bench: 3578092
2020-11-06 11:20:27 -07:00
|
|
|
if ( bestValue > VALUE_TB_LOSS_IN_MAX_PLY
|
Less pruning in qsearch
do not prune moves that give discovery checks, even if with negative SSE.
STC https://tests.stockfishchess.org/tests/view/5f4cb5e8ba100690c5cc5d25
LLR: 2.96 (-2.94,2.94) {-0.25,1.25}
Total: 91328 W: 9940 L: 9667 D: 71721
Ptnml(0-2): 491, 7345, 29693, 7670, 465
LTC https://tests.stockfishchess.org/tests/view/5f4dbc2eba100690c5cc5dac
LLR: 2.97 (-2.94,2.94) {0.25,1.25}
Total: 52448 W: 2799 L: 2586 D: 47063
Ptnml(0-2): 53, 2220, 21459, 2445, 47
closes https://github.com/official-stockfish/Stockfish/pull/3098
bench: 4031192
2020-09-02 08:45:49 -06: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)));
|
|
|
|
|
2010-06-03 11:29:48 -06:00
|
|
|
ss->currentMove = move;
|
continuation histories when in check
If in check, don't write to continuation histories ss-4, ss-6.
Adding inCheck to the stack was needed, and might be useful for
future patches.
Passed STC:
https://tests.stockfishchess.org/tests/view/5e9ee24acaaff5d60a50b812
LLR: 2.94 (-2.94,2.94) {-0.50,1.50}
Total: 61774 W: 11725 L: 11449 D: 38600
Ptnml(0-2): 971, 7211, 14322, 7337, 1046
Passed LTC:
https://tests.stockfishchess.org/tests/view/5e9eecb7caaff5d60a50b831
LLR: 2.94 (-2.94,2.94) {0.25,1.75}
Total: 250822 W: 32067 L: 31179 D: 187576
Ptnml(0-2): 1745, 23126, 74824, 23928, 1788
closes https://github.com/official-stockfish/Stockfish/pull/2645
bench: 4808463
2020-04-21 12:55:41 -06:00
|
|
|
ss->continuationHistory = &thisThread->continuationHistory[ss->inCheck]
|
2019-10-18 07:23:00 -06:00
|
|
|
[captureOrPromotion]
|
|
|
|
[pos.moved_piece(move)]
|
|
|
|
[to_sq(move)];
|
2010-06-03 11:29:48 -06:00
|
|
|
|
2021-05-17 01:13:34 -06:00
|
|
|
// Continuation history based pruning
|
Introduce countermove based pruning for qsearch
This patch continues work of previous patch in introducing pruning heuristics in qsearch by analogy to main search, now with countermove based pruning.
Idea is that if move is late enough and is quite check (we do generate them in qsearch) and has bad enough countermove history - prune it.
passed STC
https://tests.stockfishchess.org/tests/view/5f41220287a5c3c63d8f53c5
LLR: 2.93 (-2.94,2.94) {-0.25,1.25}
Total: 35944 W: 4127 L: 3929 D: 27888
Ptnml(0-2): 196, 2970, 11459, 3134, 213
passed LTC
https://tests.stockfishchess.org/tests/view/5f41862f87a5c3c63d8f53e8
LLR: 2.95 (-2.94,2.94) {0.25,1.25}
Total: 138448 W: 7655 L: 7252 D: 123541
Ptnml(0-2): 145, 6247, 56043, 6638, 151
closes https://github.com/official-stockfish/Stockfish/pull/3058
Bench: 3610676
2020-08-23 23:04:16 -06:00
|
|
|
if ( !captureOrPromotion
|
Fix incorrect pruning in qsearch
Only do countermove based pruning in qsearch if we already have a move with a better score than a TB loss.
This patch fixes a bug (started as 843a961) that incorrectly prunes moves if in check,
and adds an assert to make sure no wrong mate scores are given in the future.
It replaces a no-op moveCount check with a check for bestValue.
Initially discussed in #3171 and later in #3199, #3198 and #3210.
This PR effectively closes #3171
It also likely fixes #3196 where this causes user visible incorrect TB scores,
which probably result from these incorrect mate scores.
Passed STC and LTC non-regression tests.
https://tests.stockfishchess.org/tests/view/5f9ef8dabca9bf35bae7f648
LLR: 2.93 (-2.94,2.94) {-1.25,0.25}
Total: 21672 W: 2339 L: 2230 D: 17103
Ptnml(0-2): 126, 1689, 7083, 1826, 112
https://tests.stockfishchess.org/tests/view/5f9f0caebca9bf35bae7f666
LLR: 2.97 (-2.94,2.94) {-0.75,0.25}
Total: 33152 W: 1551 L: 1485 D: 30116
Ptnml(0-2): 27, 1308, 13832, 1390, 19
closes https://github.com/official-stockfish/Stockfish/pull/3214
Bench: 3625915
2020-11-01 10:33:17 -07:00
|
|
|
&& bestValue > VALUE_TB_LOSS_IN_MAX_PLY
|
Introduce countermove based pruning for qsearch
This patch continues work of previous patch in introducing pruning heuristics in qsearch by analogy to main search, now with countermove based pruning.
Idea is that if move is late enough and is quite check (we do generate them in qsearch) and has bad enough countermove history - prune it.
passed STC
https://tests.stockfishchess.org/tests/view/5f41220287a5c3c63d8f53c5
LLR: 2.93 (-2.94,2.94) {-0.25,1.25}
Total: 35944 W: 4127 L: 3929 D: 27888
Ptnml(0-2): 196, 2970, 11459, 3134, 213
passed LTC
https://tests.stockfishchess.org/tests/view/5f41862f87a5c3c63d8f53e8
LLR: 2.95 (-2.94,2.94) {0.25,1.25}
Total: 138448 W: 7655 L: 7252 D: 123541
Ptnml(0-2): 145, 6247, 56043, 6638, 151
closes https://github.com/official-stockfish/Stockfish/pull/3058
Bench: 3610676
2020-08-23 23:04:16 -06:00
|
|
|
&& (*contHist[0])[pos.moved_piece(move)][to_sq(move)] < CounterMovePruneThreshold
|
|
|
|
&& (*contHist[1])[pos.moved_piece(move)][to_sq(move)] < CounterMovePruneThreshold)
|
|
|
|
continue;
|
|
|
|
|
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);
|
Introducing NodeType Root
We transform rootNode into constexpr by adding a new NodeType `Root`,
which causes a speed up.
Local test:
```
Build Tester: 1.4.7.0
Windows 10 (Version 10.0, Build 0, 64-bit Edition)
Intel(R) Core(TM) i7-8750H CPU @ 2.20GHz
SafeMode: No
Running In VM: No
HyperThreading Enabled: Yes
CPU Warmup: Yes
Command Line: bench
Tests per Build: 25
ANOVA: n/a
Engine# (NPS) Speedup Sp Conf. 95% S.S.
patch (920.179,4) ---> master (906.329,2) ---> 1,528% 20.336,5 Yes No
```
---------
STC:
LLR: 2.94 (-2.94,2.94) <-0.50,2.50>
Total: 98216 W: 8348 L: 8102 D: 81766
Ptnml(0-2): 295, 6357, 35549, 6621, 286
https://tests.stockfishchess.org/tests/view/60b797e2457376eb8bcaa0ab
Yellow LTC:
LLR: -2.95 (-2.94,2.94) <0.50,3.50>
Total: 76936 W: 2651 L: 2626 D: 71659
Ptnml(0-2): 29, 2233, 33916, 2264, 26
https://tests.stockfishchess.org/tests/view/60b80d6d457376eb8bcaa145
closes https://github.com/official-stockfish/Stockfish/pull/3522
No functional change
2021-06-03 10:52:39 -06:00
|
|
|
value = -qsearch<nodeType>(pos, ss+1, -beta, -alpha, depth - 1);
|
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
|
|
|
}
|
|
|
|
|
2020-06-24 14:19:58 -06: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.
|
continuation histories when in check
If in check, don't write to continuation histories ss-4, ss-6.
Adding inCheck to the stack was needed, and might be useful for
future patches.
Passed STC:
https://tests.stockfishchess.org/tests/view/5e9ee24acaaff5d60a50b812
LLR: 2.94 (-2.94,2.94) {-0.50,1.50}
Total: 61774 W: 11725 L: 11449 D: 38600
Ptnml(0-2): 971, 7211, 14322, 7337, 1046
Passed LTC:
https://tests.stockfishchess.org/tests/view/5e9eecb7caaff5d60a50b831
LLR: 2.94 (-2.94,2.94) {0.25,1.75}
Total: 250822 W: 32067 L: 31179 D: 187576
Ptnml(0-2): 1745, 23126, 74824, 23928, 1788
closes https://github.com/official-stockfish/Stockfish/pull/2645
bench: 4808463
2020-04-21 12:55:41 -06:00
|
|
|
if (ss->inCheck && bestValue == -VALUE_INFINITE)
|
Fix incorrect pruning in qsearch
Only do countermove based pruning in qsearch if we already have a move with a better score than a TB loss.
This patch fixes a bug (started as 843a961) that incorrectly prunes moves if in check,
and adds an assert to make sure no wrong mate scores are given in the future.
It replaces a no-op moveCount check with a check for bestValue.
Initially discussed in #3171 and later in #3199, #3198 and #3210.
This PR effectively closes #3171
It also likely fixes #3196 where this causes user visible incorrect TB scores,
which probably result from these incorrect mate scores.
Passed STC and LTC non-regression tests.
https://tests.stockfishchess.org/tests/view/5f9ef8dabca9bf35bae7f648
LLR: 2.93 (-2.94,2.94) {-1.25,0.25}
Total: 21672 W: 2339 L: 2230 D: 17103
Ptnml(0-2): 126, 1689, 7083, 1826, 112
https://tests.stockfishchess.org/tests/view/5f9f0caebca9bf35bae7f666
LLR: 2.97 (-2.94,2.94) {-0.75,0.25}
Total: 33152 W: 1551 L: 1485 D: 30116
Ptnml(0-2): 27, 1308, 13832, 1390, 19
closes https://github.com/official-stockfish/Stockfish/pull/3214
Bench: 3625915
2020-11-01 10:33:17 -07:00
|
|
|
{
|
|
|
|
assert(!MoveList<LEGAL>(pos).size());
|
|
|
|
|
2011-12-28 05:22:09 -07:00
|
|
|
return mated_in(ss->ply); // Plies to mate from the root
|
Fix incorrect pruning in qsearch
Only do countermove based pruning in qsearch if we already have a move with a better score than a TB loss.
This patch fixes a bug (started as 843a961) that incorrectly prunes moves if in check,
and adds an assert to make sure no wrong mate scores are given in the future.
It replaces a no-op moveCount check with a check for bestValue.
Initially discussed in #3171 and later in #3199, #3198 and #3210.
This PR effectively closes #3171
It also likely fixes #3196 where this causes user visible incorrect TB scores,
which probably result from these incorrect mate scores.
Passed STC and LTC non-regression tests.
https://tests.stockfishchess.org/tests/view/5f9ef8dabca9bf35bae7f648
LLR: 2.93 (-2.94,2.94) {-1.25,0.25}
Total: 21672 W: 2339 L: 2230 D: 17103
Ptnml(0-2): 126, 1689, 7083, 1826, 112
https://tests.stockfishchess.org/tests/view/5f9f0caebca9bf35bae7f666
LLR: 2.97 (-2.94,2.94) {-0.75,0.25}
Total: 33152 W: 1551 L: 1485 D: 30116
Ptnml(0-2): 27, 1308, 13832, 1390, 19
closes https://github.com/official-stockfish/Stockfish/pull/3214
Bench: 3625915
2020-11-01 10:33:17 -07:00
|
|
|
}
|
2008-08-31 23:59:13 -06:00
|
|
|
|
2020-12-01 05:02:35 -07:00
|
|
|
// Save gathered info in transposition table
|
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
|
|
|
|
Fix for incorrect VALUE_MATE_IN_MAX_PLY usage.
Fixes #2533, fixes #2543, fixes #2423.
the code that prevents false mate announcements depending on the TT
state (GHI), incorrectly used VALUE_MATE_IN_MAX_PLY. The latter
constant, however, also includes, counterintuitively, the TB win range.
This patch fixes that, by restoring the behavior for TB win scores,
while retaining the false mate correctness, and improving the mate
finding ability. In particular
no alse mates are announced with the poisened hash testcase
```
position fen 8/8/8/3k4/8/8/6K1/7R w - - 0 1
go depth 40
position fen 8/8/8/3k4/8/8/6K1/7R w - - 76 1
go depth 20
ucinewgame
```
mates are found with the testcases reported in #2543
```
position fen 4k3/3pp3/8/8/8/8/2PPP3/4K3 w - - 0 1
setoption name Hash value 1024
go depth 55
ucinewgame
```
and
```
position fen 4k3/4p3/8/8/8/8/3PP3/4K3 w - - 0 1
setoption name Hash value 1024
go depth 45
ucinewgame
```
furthermore, on the mate finding benchmark (ChestUCI_23102018.epd),
performance improves over master, roughly reaching performance with the
false mate protection reverted
```
Analyzing 6566 mate positions for best and found mates:
----------------best ---------------found
nodes master revert fixed master revert fixed
16000000 4233 4236 4235 5200 5201 5199
32000000 4583 4585 4585 5417 5424 5418
64000000 4852 4853 4855 5575 5584 5579
128000000 5071 5068 5066 5710 5720 5716
256000000 5280 5282 5279 5819 5827 5826
512000000 5471 5468 5468 5919 5935 5932
```
On a testcase with TB enabled, progress is made consistently, contrary
to master
```
setoption name SyzygyPath value ../../../syzygy/3-4-5/
setoption name Hash value 2048
position fen 1R6/3k4/8/K2p4/4n3/2P5/8/8 w - - 0 1
go depth 58
ucinewgame
```
The PR (prior to a rewrite for clarity)
passed STC:
LLR: 2.94 (-2.94,2.94) {-1.50,0.50}
Total: 65405 W: 12454 L: 12384 D: 40567
Ptnml(0-2): 920, 7256, 16285, 7286, 944
http://tests.stockfishchess.org/tests/view/5e441a3be70d848499f63d15
passed LTC:
LLR: 2.94 (-2.94,2.94) {-1.50,0.50}
Total: 27096 W: 3477 L: 3413 D: 20206
Ptnml(0-2): 128, 2215, 8776, 2292, 122
http://tests.stockfishchess.org/tests/view/5e44e277e70d848499f63d63
The incorrectly named VALUE_MATE_IN_MAX_PLY and VALUE_MATED_IN_MAX_PLY
were renamed into VALUE_TB_WIN_IN_MAX_PLY and VALUE_TB_LOSS_IN_MAX_PLY,
and correclty defined VALUE_MATE_IN_MAX_PLY and VALUE_MATED_IN_MAX_PLY
were introduced.
One further (corner case) mistake using these constants was fixed (go
mate X), which could lead to a premature return if X > MAX_PLY / 2,
but TB were present.
Thanks to @svivanov72 for one of the reports and help fixing the issue.
closes https://github.com/official-stockfish/Stockfish/pull/2552
Bench: 4932981
2020-02-11 12:42:32 -07:00
|
|
|
// value_to_tt() adjusts a mate or TB score from "plies to mate from the root" to
|
2020-06-24 14:19:58 -06:00
|
|
|
// "plies to mate from the current position". Standard 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);
|
|
|
|
|
Fix for incorrect VALUE_MATE_IN_MAX_PLY usage.
Fixes #2533, fixes #2543, fixes #2423.
the code that prevents false mate announcements depending on the TT
state (GHI), incorrectly used VALUE_MATE_IN_MAX_PLY. The latter
constant, however, also includes, counterintuitively, the TB win range.
This patch fixes that, by restoring the behavior for TB win scores,
while retaining the false mate correctness, and improving the mate
finding ability. In particular
no alse mates are announced with the poisened hash testcase
```
position fen 8/8/8/3k4/8/8/6K1/7R w - - 0 1
go depth 40
position fen 8/8/8/3k4/8/8/6K1/7R w - - 76 1
go depth 20
ucinewgame
```
mates are found with the testcases reported in #2543
```
position fen 4k3/3pp3/8/8/8/8/2PPP3/4K3 w - - 0 1
setoption name Hash value 1024
go depth 55
ucinewgame
```
and
```
position fen 4k3/4p3/8/8/8/8/3PP3/4K3 w - - 0 1
setoption name Hash value 1024
go depth 45
ucinewgame
```
furthermore, on the mate finding benchmark (ChestUCI_23102018.epd),
performance improves over master, roughly reaching performance with the
false mate protection reverted
```
Analyzing 6566 mate positions for best and found mates:
----------------best ---------------found
nodes master revert fixed master revert fixed
16000000 4233 4236 4235 5200 5201 5199
32000000 4583 4585 4585 5417 5424 5418
64000000 4852 4853 4855 5575 5584 5579
128000000 5071 5068 5066 5710 5720 5716
256000000 5280 5282 5279 5819 5827 5826
512000000 5471 5468 5468 5919 5935 5932
```
On a testcase with TB enabled, progress is made consistently, contrary
to master
```
setoption name SyzygyPath value ../../../syzygy/3-4-5/
setoption name Hash value 2048
position fen 1R6/3k4/8/K2p4/4n3/2P5/8/8 w - - 0 1
go depth 58
ucinewgame
```
The PR (prior to a rewrite for clarity)
passed STC:
LLR: 2.94 (-2.94,2.94) {-1.50,0.50}
Total: 65405 W: 12454 L: 12384 D: 40567
Ptnml(0-2): 920, 7256, 16285, 7286, 944
http://tests.stockfishchess.org/tests/view/5e441a3be70d848499f63d15
passed LTC:
LLR: 2.94 (-2.94,2.94) {-1.50,0.50}
Total: 27096 W: 3477 L: 3413 D: 20206
Ptnml(0-2): 128, 2215, 8776, 2292, 122
http://tests.stockfishchess.org/tests/view/5e44e277e70d848499f63d63
The incorrectly named VALUE_MATE_IN_MAX_PLY and VALUE_MATED_IN_MAX_PLY
were renamed into VALUE_TB_WIN_IN_MAX_PLY and VALUE_TB_LOSS_IN_MAX_PLY,
and correclty defined VALUE_MATE_IN_MAX_PLY and VALUE_MATED_IN_MAX_PLY
were introduced.
One further (corner case) mistake using these constants was fixed (go
mate X), which could lead to a premature return if X > MAX_PLY / 2,
but TB were present.
Thanks to @svivanov72 for one of the reports and help fixing the issue.
closes https://github.com/official-stockfish/Stockfish/pull/2552
Bench: 4932981
2020-02-11 12:42:32 -07:00
|
|
|
return v >= VALUE_TB_WIN_IN_MAX_PLY ? v + ply
|
|
|
|
: v <= VALUE_TB_LOSS_IN_MAX_PLY ? v - ply : v;
|
2012-10-27 06:25:31 -06:00
|
|
|
}
|
|
|
|
|
|
|
|
|
2020-06-24 14:19:58 -06:00
|
|
|
// value_from_tt() is the inverse of value_to_tt(): it adjusts a mate or TB score
|
|
|
|
// from the transposition table (which refers to the plies to mate/be mated from
|
|
|
|
// current position) to "plies to mate/be mated (TB win/loss) from the root". However,
|
|
|
|
// for mate scores, to avoid potentially false mate scores related to the 50 moves rule
|
|
|
|
// and the graph history interaction, we return an optimal TB score instead.
|
2012-10-27 06:25:31 -06:00
|
|
|
|
Fix incorrect mate score.
Current master 648c7ec25db2040c0af34dd846dfa3f57af5ad0a will generate an
incorrect mate score for:
```
setoption name Hash value 8
setoption name Threads value 1
position fen 8/1p2KP2/1p4q1/1Pp5/2P5/N1Pp1k2/3P4/1N6 b - - 76 40
go depth 49
```
even though the position is a draw. Generally, SF tries to display only
proven mate scores, so this is a bug.
This was posted http://www.talkchess.com/forum3/viewtopic.php?f=2&t=72166
by Uri Blass, with the correct analysis that this must be related to the
50 moves draw rule being ignored somewhere.
Indeed, this is possible as positions and there eval are stored in the TT,
without reference to the 50mr counter. Depending on the search path followed
a position can thus be mate or draw in the TT (GHI or Graph history interaction).
Therefore, to prove mate lines, the TT content has to be used with care. Rather
than ignoring TT content in general or for mate scores (which impact search or
mate finding), it is possible to be more selective. In particular, @WOnder93
suggested to only ignore the TT if the 50mr draw ply is closer than the mate
ply. This patch implements this idea, by clamping the eval in the TT to
+-VALUE_MATED_IN_MAX_PLY. This retains the TTmove, but causes a research of
these lines (with the current 50mr counter) as needed.
This patch hardly ever affects search (as indicated by the unchanged
bench), but fixes the testcase. As the conditions are very specific,
also mate finding will almost never be less efficient (testing welcome).
It was also shown to pass STC and LTC non-regression testing, in a form
using if/then/else instead of ternary operators:
STC:
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 93605 W: 15346 L: 15340 D: 62919
http://tests.stockfishchess.org/tests/view/5db45bb00ebc5908127538d4
LTC:
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 33873 W: 7359 L: 7261 D: 19253
http://tests.stockfishchess.org/tests/view/5db4c8940ebc5902d6b146fc
closes https://github.com/official-stockfish/Stockfish/issues/2370
Bench: 4362323
2019-10-26 08:34:19 -06:00
|
|
|
Value value_from_tt(Value v, int ply, int r50c) {
|
2012-10-27 06:25:31 -06:00
|
|
|
|
Fix for incorrect VALUE_MATE_IN_MAX_PLY usage.
Fixes #2533, fixes #2543, fixes #2423.
the code that prevents false mate announcements depending on the TT
state (GHI), incorrectly used VALUE_MATE_IN_MAX_PLY. The latter
constant, however, also includes, counterintuitively, the TB win range.
This patch fixes that, by restoring the behavior for TB win scores,
while retaining the false mate correctness, and improving the mate
finding ability. In particular
no alse mates are announced with the poisened hash testcase
```
position fen 8/8/8/3k4/8/8/6K1/7R w - - 0 1
go depth 40
position fen 8/8/8/3k4/8/8/6K1/7R w - - 76 1
go depth 20
ucinewgame
```
mates are found with the testcases reported in #2543
```
position fen 4k3/3pp3/8/8/8/8/2PPP3/4K3 w - - 0 1
setoption name Hash value 1024
go depth 55
ucinewgame
```
and
```
position fen 4k3/4p3/8/8/8/8/3PP3/4K3 w - - 0 1
setoption name Hash value 1024
go depth 45
ucinewgame
```
furthermore, on the mate finding benchmark (ChestUCI_23102018.epd),
performance improves over master, roughly reaching performance with the
false mate protection reverted
```
Analyzing 6566 mate positions for best and found mates:
----------------best ---------------found
nodes master revert fixed master revert fixed
16000000 4233 4236 4235 5200 5201 5199
32000000 4583 4585 4585 5417 5424 5418
64000000 4852 4853 4855 5575 5584 5579
128000000 5071 5068 5066 5710 5720 5716
256000000 5280 5282 5279 5819 5827 5826
512000000 5471 5468 5468 5919 5935 5932
```
On a testcase with TB enabled, progress is made consistently, contrary
to master
```
setoption name SyzygyPath value ../../../syzygy/3-4-5/
setoption name Hash value 2048
position fen 1R6/3k4/8/K2p4/4n3/2P5/8/8 w - - 0 1
go depth 58
ucinewgame
```
The PR (prior to a rewrite for clarity)
passed STC:
LLR: 2.94 (-2.94,2.94) {-1.50,0.50}
Total: 65405 W: 12454 L: 12384 D: 40567
Ptnml(0-2): 920, 7256, 16285, 7286, 944
http://tests.stockfishchess.org/tests/view/5e441a3be70d848499f63d15
passed LTC:
LLR: 2.94 (-2.94,2.94) {-1.50,0.50}
Total: 27096 W: 3477 L: 3413 D: 20206
Ptnml(0-2): 128, 2215, 8776, 2292, 122
http://tests.stockfishchess.org/tests/view/5e44e277e70d848499f63d63
The incorrectly named VALUE_MATE_IN_MAX_PLY and VALUE_MATED_IN_MAX_PLY
were renamed into VALUE_TB_WIN_IN_MAX_PLY and VALUE_TB_LOSS_IN_MAX_PLY,
and correclty defined VALUE_MATE_IN_MAX_PLY and VALUE_MATED_IN_MAX_PLY
were introduced.
One further (corner case) mistake using these constants was fixed (go
mate X), which could lead to a premature return if X > MAX_PLY / 2,
but TB were present.
Thanks to @svivanov72 for one of the reports and help fixing the issue.
closes https://github.com/official-stockfish/Stockfish/pull/2552
Bench: 4932981
2020-02-11 12:42:32 -07:00
|
|
|
if (v == VALUE_NONE)
|
|
|
|
return VALUE_NONE;
|
|
|
|
|
|
|
|
if (v >= VALUE_TB_WIN_IN_MAX_PLY) // TB win or better
|
|
|
|
{
|
|
|
|
if (v >= VALUE_MATE_IN_MAX_PLY && VALUE_MATE - v > 99 - r50c)
|
|
|
|
return VALUE_MATE_IN_MAX_PLY - 1; // do not return a potentially false mate score
|
|
|
|
|
|
|
|
return v - ply;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (v <= VALUE_TB_LOSS_IN_MAX_PLY) // TB loss or worse
|
|
|
|
{
|
|
|
|
if (v <= VALUE_MATED_IN_MAX_PLY && VALUE_MATE + v > 99 - r50c)
|
|
|
|
return VALUE_MATED_IN_MAX_PLY + 1; // do not return a potentially false mate score
|
|
|
|
|
|
|
|
return v + ply;
|
|
|
|
}
|
|
|
|
|
|
|
|
return v;
|
2012-10-27 06:25:31 -06:00
|
|
|
}
|
|
|
|
|
|
|
|
|
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
|
|
|
|
Refactor final stats updates.
This PR refactors update_quiet_stats, update_capture_stats and search to more clearly reflect what is actually done.
Effectively, all stat updates that need to be done after search is finished and a bestmove is found,
are collected in a new function ```final_stats_update()```. This shortens our main search routine, and simplifies ```update_quiet_stats```.
The latter function is now more easily reusable with fewer arguments, as the handling of ```quietsSearched``` is only needed in ```final_stats_update```.
```update_capture_stats```, which was only called once is now integrated in ```final_stats_update```, which allows for removing a branch and reusing some ```stat_bonus``` calls. The need for refactoring was also suggested by the fact that the comments of ```update_quiet_stats``` and ```update_capture_stats``` were incorrect (e.g. ```update_capture_stats``` was called, correctly, also when the bestmove was a quiet and not a capture).
passed non-regression STC:
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 75196 W: 16364 L: 16347 D: 42485
http://tests.stockfishchess.org/tests/view/5db004ec0ebc5902c06db9e1
The diff is most easily readable as ```git diff master --patience```
No functional change
2019-10-23 00:26:47 -06:00
|
|
|
// update_all_stats() updates stats at the end of search() when a bestMove is found
|
2014-01-05 06:08:26 -07:00
|
|
|
|
Refactor final stats updates.
This PR refactors update_quiet_stats, update_capture_stats and search to more clearly reflect what is actually done.
Effectively, all stat updates that need to be done after search is finished and a bestmove is found,
are collected in a new function ```final_stats_update()```. This shortens our main search routine, and simplifies ```update_quiet_stats```.
The latter function is now more easily reusable with fewer arguments, as the handling of ```quietsSearched``` is only needed in ```final_stats_update```.
```update_capture_stats```, which was only called once is now integrated in ```final_stats_update```, which allows for removing a branch and reusing some ```stat_bonus``` calls. The need for refactoring was also suggested by the fact that the comments of ```update_quiet_stats``` and ```update_capture_stats``` were incorrect (e.g. ```update_capture_stats``` was called, correctly, also when the bestmove was a quiet and not a capture).
passed non-regression STC:
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 75196 W: 16364 L: 16347 D: 42485
http://tests.stockfishchess.org/tests/view/5db004ec0ebc5902c06db9e1
The diff is most easily readable as ```git diff master --patience```
No functional change
2019-10-23 00:26:47 -06:00
|
|
|
void update_all_stats(const Position& pos, Stack* ss, Move bestMove, Value bestValue, Value beta, Square prevSq,
|
Revert 5 recent patches
Revert 5 patches which were merged, but lead to a regression test that showed negative Elo gain:
http://tests.stockfishchess.org/tests/view/5e307251ab2d69d58394fdb9
This was discussed in depth in:
https://github.com/official-stockfish/Stockfish/issues/2531
Each patch was removed and tested as a simplification, full list below, and the whole combo as well.
After the revert the regression test showed a neutral result:
http://tests.stockfishchess.org/tests/view/5e334851708b13464ceea33c
As a result of this experience, the SPRT testing bounds will be made more strict.
Reverted patches:
1 Dynamic Complexity 6d0eabd5fe2961551477820ab7619e2c31e01ffd :
STC 10+0.1 https://tests.stockfishchess.org/tests/view/5e31fcacec661e2e6a340d08 :
LLR: 2.97 (-2.94,2.94) {-1.50,0.50}
Total: 38130 W: 7326 L: 7189 D: 23615
Ptnml(0-2): 677, 4346, 8843, 4545, 646
LTC 60+0.6 https://tests.stockfishchess.org/tests/view/5e32c18fec661e2e6a340d73 :
LLR: 2.94 (-2.94,2.94) {-1.50,0.50}
Total: 38675 W: 4941 L: 4866 D: 28868
Ptnml(0-2): 270, 3556, 11429, 3584, 291
3 More bonus for bestMoves on past PV nodes 71e0b5385e2717679a57c6b77d8c7ac5fff3b89f :
STC 10+0.1 https://tests.stockfishchess.org/tests/view/5e31fe93ec661e2e6a340d10 :
LLR: 2.95 (-2.94,2.94) {-1.50,0.50}
Total: 46100 W: 8853 L: 8727 D: 28520
Ptnml(0-2): 796, 5297, 10749, 5387, 813
LTC 60+0.6 https://tests.stockfishchess.org/tests/view/5e32c187ec661e2e6a340d71 :
LLR: 2.96 (-2.94,2.94) {-1.50,0.50}
Total: 16920 W: 2161 L: 2055 D: 12704
Ptnml(0-2): 115, 1498, 5006, 1569, 130
4 Tweak Restricted Piece Bonus 0ae00454ba6928d181b46103e5c83e6d58fcebe5 :
STC 10+0.1 https://tests.stockfishchess.org/tests/view/5e31fefaec661e2e6a340d15 :
LLR: 2.94 (-2.94,2.94) {-1.50,0.50}
Total: 88328 W: 17060 L: 16997 D: 54271
Ptnml(0-2): 1536, 10446, 20169, 10422, 1581
LTC 60+0.6 https://tests.stockfishchess.org/tests/view/5e32c17aec661e2e6a340d6f :
LLR: 2.95 (-2.94,2.94) {-1.50,0.50}
Total: 34784 W: 4551 L: 4466 D: 25767
Ptnml(0-2): 255, 3279, 10061, 3345, 262
5 History update for pruned captures 01b6088af39902001d2d6844561b6a2faa549282 :
STC 10+0.1 https://tests.stockfishchess.org/tests/view/5e31ff5eec661e2e6a340d1a :
LLR: 2.94 (-2.94,2.94) {-1.50,0.50}
Total: 29541 W: 5735 L: 5588 D: 18218
Ptnml(0-2): 483, 3445, 6820, 3469, 545
LTC 60+0.6 https://tests.stockfishchess.org/tests/view/5e32c196ec661e2e6a340d75 :
LLR: 2.94 (-2.94,2.94) {-1.50,0.50}
Total: 22177 W: 2854 L: 2757 D: 16566
Ptnml(0-2): 143, 2005, 6555, 2055, 164
6 Tweak trapped rook penalty 18fc21eba0368fd5e3c4c4b8ee1000c9ac445425 :
STC 10+0.1 https://tests.stockfishchess.org/tests/view/5e31ffb1ec661e2e6a340d1c :
LLR: 2.95 (-2.94,2.94) {-1.50,0.50}
Total: 24476 W: 4727 L: 4569 D: 15180
Ptnml(0-2): 390, 2834, 5659, 2933, 417
LTC 60+0.6 https://tests.stockfishchess.org/tests/view/5e32c19eec661e2e6a340d77 :
LLR: 2.95 (-2.94,2.94) {-1.50,0.50}
Total: 97332 W: 12492 L: 12466 D: 72374
Ptnml(0-2): 690, 9107, 28738, 9034, 720
All 5 as one simplification :
LTC 60+0.6 https://tests.stockfishchess.org/tests/view/5e334098708b13464ceea330 :
LLR: 2.94 (-2.94,2.94) {-1.50,0.50}
Total: 7829 W: 1079 L: 964 D: 5786
Ptnml(0-2): 52, 690, 2281, 781, 65
Bench: 5153165
2020-01-30 13:44:04 -07:00
|
|
|
Move* quietsSearched, int quietCount, Move* capturesSearched, int captureCount, Depth depth) {
|
2016-08-23 07:57:56 -06:00
|
|
|
|
Refactor final stats updates.
This PR refactors update_quiet_stats, update_capture_stats and search to more clearly reflect what is actually done.
Effectively, all stat updates that need to be done after search is finished and a bestmove is found,
are collected in a new function ```final_stats_update()```. This shortens our main search routine, and simplifies ```update_quiet_stats```.
The latter function is now more easily reusable with fewer arguments, as the handling of ```quietsSearched``` is only needed in ```final_stats_update```.
```update_capture_stats```, which was only called once is now integrated in ```final_stats_update```, which allows for removing a branch and reusing some ```stat_bonus``` calls. The need for refactoring was also suggested by the fact that the comments of ```update_quiet_stats``` and ```update_capture_stats``` were incorrect (e.g. ```update_capture_stats``` was called, correctly, also when the bestmove was a quiet and not a capture).
passed non-regression STC:
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 75196 W: 16364 L: 16347 D: 42485
http://tests.stockfishchess.org/tests/view/5db004ec0ebc5902c06db9e1
The diff is most easily readable as ```git diff master --patience```
No functional change
2019-10-23 00:26:47 -06:00
|
|
|
int bonus1, bonus2;
|
|
|
|
Color us = pos.side_to_move();
|
|
|
|
Thread* thisThread = pos.this_thread();
|
|
|
|
CapturePieceToHistory& captureHistory = thisThread->captureHistory;
|
|
|
|
Piece moved_piece = pos.moved_piece(bestMove);
|
|
|
|
PieceType captured = type_of(pos.piece_on(to_sq(bestMove)));
|
|
|
|
|
|
|
|
bonus1 = stat_bonus(depth + 1);
|
Capping stat bonus at 2000
This patch updates the stat_bonus() function (used in the history tables to
help move ordering), keeping the same quadratic for small depths but changing
the values for depth >= 9:
The old bonus formula was increasing from zero at depth 1 to 4100 at depth 14,
then used the strange, small value of 73 for all depths >= 15.
The new bonus formula increases from 0 at depth 1 to 2000 at depth 8, then
keeps 2000 for all depths >= 8.
passed STC:
LLR: 2.94 (-2.94,2.94) <-0.50,2.50>
Total: 169624 W: 42875 L: 42454 D: 84295
Ptnml(0-2): 585, 19340, 44557, 19729, 601
https://tests.stockfishchess.org/tests/view/615bd69e9d256038a969b97c
passed LTC:
LLR: 3.07 (-2.94,2.94) <0.50,3.50>
Total: 37336 W: 9456 L: 9191 D: 18689
Ptnml(0-2): 20, 3810, 10747, 4067, 24
https://tests.stockfishchess.org/tests/view/615c75d99d256038a969b9b2
closes https://github.com/official-stockfish/Stockfish/pull/3731
Bench: 6261865
2021-10-04 12:37:26 -06:00
|
|
|
bonus2 = bestValue > beta + PawnValueMg ? bonus1 // larger bonus
|
|
|
|
: stat_bonus(depth); // smaller bonus
|
Refactor final stats updates.
This PR refactors update_quiet_stats, update_capture_stats and search to more clearly reflect what is actually done.
Effectively, all stat updates that need to be done after search is finished and a bestmove is found,
are collected in a new function ```final_stats_update()```. This shortens our main search routine, and simplifies ```update_quiet_stats```.
The latter function is now more easily reusable with fewer arguments, as the handling of ```quietsSearched``` is only needed in ```final_stats_update```.
```update_capture_stats```, which was only called once is now integrated in ```final_stats_update```, which allows for removing a branch and reusing some ```stat_bonus``` calls. The need for refactoring was also suggested by the fact that the comments of ```update_quiet_stats``` and ```update_capture_stats``` were incorrect (e.g. ```update_capture_stats``` was called, correctly, also when the bestmove was a quiet and not a capture).
passed non-regression STC:
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 75196 W: 16364 L: 16347 D: 42485
http://tests.stockfishchess.org/tests/view/5db004ec0ebc5902c06db9e1
The diff is most easily readable as ```git diff master --patience```
No functional change
2019-10-23 00:26:47 -06:00
|
|
|
|
|
|
|
if (!pos.capture_or_promotion(bestMove))
|
|
|
|
{
|
2020-12-01 05:02:35 -07:00
|
|
|
// Increase stats for the best move in case it was a quiet move
|
Improve move order near the root
Current move histories are known to work well near the leaves, whilst at
higher depths they aren't very helpful. To address this problem this
patch introduces a table dedicated for what's happening at plies 0-3.
It's structured like mainHistory with ply index instead of color.
It get cleared with each new search and is filled during iterative
deepening at higher depths when recording successful quiet moves near
the root or traversing nodes which were in the principal variation
(ttPv).
Medium TC (20+0.2):
https://tests.stockfishchess.org/tests/view/5e4d358790a0a02810d096dc
LLR: 2.94 (-2.94,2.94) {-0.50,1.50}
Total: 100910 W: 16682 L: 16376 D: 67852
Ptnml(0-2): 1177, 10983, 25883, 11181, 1231
LTC:
https://tests.stockfishchess.org/tests/view/5e4e2cb790a0a02810d09714
LLR: 2.95 (-2.94,2.94) {0.25,1.75}
Total: 80444 W: 10495 L: 10095 D: 59854
Ptnml(0-2): 551, 7479, 23803, 7797, 592
closes https://github.com/official-stockfish/Stockfish/pull/2557
Bench: 4705960
2020-02-21 06:01:59 -07:00
|
|
|
update_quiet_stats(pos, ss, bestMove, bonus2, depth);
|
Refactor final stats updates.
This PR refactors update_quiet_stats, update_capture_stats and search to more clearly reflect what is actually done.
Effectively, all stat updates that need to be done after search is finished and a bestmove is found,
are collected in a new function ```final_stats_update()```. This shortens our main search routine, and simplifies ```update_quiet_stats```.
The latter function is now more easily reusable with fewer arguments, as the handling of ```quietsSearched``` is only needed in ```final_stats_update```.
```update_capture_stats```, which was only called once is now integrated in ```final_stats_update```, which allows for removing a branch and reusing some ```stat_bonus``` calls. The need for refactoring was also suggested by the fact that the comments of ```update_quiet_stats``` and ```update_capture_stats``` were incorrect (e.g. ```update_capture_stats``` was called, correctly, also when the bestmove was a quiet and not a capture).
passed non-regression STC:
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 75196 W: 16364 L: 16347 D: 42485
http://tests.stockfishchess.org/tests/view/5db004ec0ebc5902c06db9e1
The diff is most easily readable as ```git diff master --patience```
No functional change
2019-10-23 00:26:47 -06:00
|
|
|
|
2020-12-01 05:02:35 -07:00
|
|
|
// Decrease stats for all non-best quiet moves
|
Refactor final stats updates.
This PR refactors update_quiet_stats, update_capture_stats and search to more clearly reflect what is actually done.
Effectively, all stat updates that need to be done after search is finished and a bestmove is found,
are collected in a new function ```final_stats_update()```. This shortens our main search routine, and simplifies ```update_quiet_stats```.
The latter function is now more easily reusable with fewer arguments, as the handling of ```quietsSearched``` is only needed in ```final_stats_update```.
```update_capture_stats```, which was only called once is now integrated in ```final_stats_update```, which allows for removing a branch and reusing some ```stat_bonus``` calls. The need for refactoring was also suggested by the fact that the comments of ```update_quiet_stats``` and ```update_capture_stats``` were incorrect (e.g. ```update_capture_stats``` was called, correctly, also when the bestmove was a quiet and not a capture).
passed non-regression STC:
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 75196 W: 16364 L: 16347 D: 42485
http://tests.stockfishchess.org/tests/view/5db004ec0ebc5902c06db9e1
The diff is most easily readable as ```git diff master --patience```
No functional change
2019-10-23 00:26:47 -06:00
|
|
|
for (int i = 0; i < quietCount; ++i)
|
|
|
|
{
|
|
|
|
thisThread->mainHistory[us][from_to(quietsSearched[i])] << -bonus2;
|
|
|
|
update_continuation_histories(ss, pos.moved_piece(quietsSearched[i]), to_sq(quietsSearched[i]), -bonus2);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
else
|
2020-12-01 05:02:35 -07:00
|
|
|
// Increase stats for the best move in case it was a capture move
|
Refactor final stats updates.
This PR refactors update_quiet_stats, update_capture_stats and search to more clearly reflect what is actually done.
Effectively, all stat updates that need to be done after search is finished and a bestmove is found,
are collected in a new function ```final_stats_update()```. This shortens our main search routine, and simplifies ```update_quiet_stats```.
The latter function is now more easily reusable with fewer arguments, as the handling of ```quietsSearched``` is only needed in ```final_stats_update```.
```update_capture_stats```, which was only called once is now integrated in ```final_stats_update```, which allows for removing a branch and reusing some ```stat_bonus``` calls. The need for refactoring was also suggested by the fact that the comments of ```update_quiet_stats``` and ```update_capture_stats``` were incorrect (e.g. ```update_capture_stats``` was called, correctly, also when the bestmove was a quiet and not a capture).
passed non-regression STC:
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 75196 W: 16364 L: 16347 D: 42485
http://tests.stockfishchess.org/tests/view/5db004ec0ebc5902c06db9e1
The diff is most easily readable as ```git diff master --patience```
No functional change
2019-10-23 00:26:47 -06:00
|
|
|
captureHistory[moved_piece][to_sq(bestMove)][captured] << bonus1;
|
2016-08-23 07:57:56 -06:00
|
|
|
|
2020-12-01 05:02:35 -07:00
|
|
|
// Extra penalty for a quiet early move that was not a TT move or
|
|
|
|
// main killer move in previous ply when it gets refuted.
|
Adjust penalty on refuted early quiet moves
This patch changes how previous early moves are penalized in case
search finds a best move. Here, the first quiet move that was not
a transposition table move is penalized.
passed STC
https://tests.stockfishchess.org/tests/view/5f51d839ba100690c5cc5f69
LLR: 2.94 (-2.94,2.94) {-0.25,1.25}
Total: 10088 W: 1150 L: 997 D: 7941
Ptnml(0-2): 41, 772, 3278, 899, 54
passed LTC
https://tests.stockfishchess.org/tests/view/5f51e435ba100690c5cc5f76
LLR: 2.93 (-2.94,2.94) {0.25,1.25}
Total: 30808 W: 1564 L: 1405 D: 27839
Ptnml(0-2): 19, 1245, 12717, 1404, 19
closes https://github.com/official-stockfish/Stockfish/pull/3106
bench 3983758
2020-09-04 06:53:59 -06:00
|
|
|
if ( ((ss-1)->moveCount == 1 + (ss-1)->ttHit || ((ss-1)->currentMove == (ss-1)->killers[0]))
|
Refactor final stats updates.
This PR refactors update_quiet_stats, update_capture_stats and search to more clearly reflect what is actually done.
Effectively, all stat updates that need to be done after search is finished and a bestmove is found,
are collected in a new function ```final_stats_update()```. This shortens our main search routine, and simplifies ```update_quiet_stats```.
The latter function is now more easily reusable with fewer arguments, as the handling of ```quietsSearched``` is only needed in ```final_stats_update```.
```update_capture_stats```, which was only called once is now integrated in ```final_stats_update```, which allows for removing a branch and reusing some ```stat_bonus``` calls. The need for refactoring was also suggested by the fact that the comments of ```update_quiet_stats``` and ```update_capture_stats``` were incorrect (e.g. ```update_capture_stats``` was called, correctly, also when the bestmove was a quiet and not a capture).
passed non-regression STC:
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 75196 W: 16364 L: 16347 D: 42485
http://tests.stockfishchess.org/tests/view/5db004ec0ebc5902c06db9e1
The diff is most easily readable as ```git diff master --patience```
No functional change
2019-10-23 00:26:47 -06:00
|
|
|
&& !pos.captured_piece())
|
|
|
|
update_continuation_histories(ss-1, pos.piece_on(prevSq), prevSq, -bonus1);
|
2016-08-24 08:52:05 -06:00
|
|
|
|
2020-12-01 05:02:35 -07:00
|
|
|
// Decrease stats for all non-best capture moves
|
Refactor final stats updates.
This PR refactors update_quiet_stats, update_capture_stats and search to more clearly reflect what is actually done.
Effectively, all stat updates that need to be done after search is finished and a bestmove is found,
are collected in a new function ```final_stats_update()```. This shortens our main search routine, and simplifies ```update_quiet_stats```.
The latter function is now more easily reusable with fewer arguments, as the handling of ```quietsSearched``` is only needed in ```final_stats_update```.
```update_capture_stats```, which was only called once is now integrated in ```final_stats_update```, which allows for removing a branch and reusing some ```stat_bonus``` calls. The need for refactoring was also suggested by the fact that the comments of ```update_quiet_stats``` and ```update_capture_stats``` were incorrect (e.g. ```update_capture_stats``` was called, correctly, also when the bestmove was a quiet and not a capture).
passed non-regression STC:
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 75196 W: 16364 L: 16347 D: 42485
http://tests.stockfishchess.org/tests/view/5db004ec0ebc5902c06db9e1
The diff is most easily readable as ```git diff master --patience```
No functional change
2019-10-23 00:26:47 -06:00
|
|
|
for (int i = 0; i < captureCount; ++i)
|
|
|
|
{
|
|
|
|
moved_piece = pos.moved_piece(capturesSearched[i]);
|
|
|
|
captured = type_of(pos.piece_on(to_sq(capturesSearched[i])));
|
|
|
|
captureHistory[moved_piece][to_sq(capturesSearched[i])][captured] << -bonus1;
|
|
|
|
}
|
|
|
|
}
|
2017-11-03 05:37:11 -06:00
|
|
|
|
|
|
|
|
Refactor final stats updates.
This PR refactors update_quiet_stats, update_capture_stats and search to more clearly reflect what is actually done.
Effectively, all stat updates that need to be done after search is finished and a bestmove is found,
are collected in a new function ```final_stats_update()```. This shortens our main search routine, and simplifies ```update_quiet_stats```.
The latter function is now more easily reusable with fewer arguments, as the handling of ```quietsSearched``` is only needed in ```final_stats_update```.
```update_capture_stats```, which was only called once is now integrated in ```final_stats_update```, which allows for removing a branch and reusing some ```stat_bonus``` calls. The need for refactoring was also suggested by the fact that the comments of ```update_quiet_stats``` and ```update_capture_stats``` were incorrect (e.g. ```update_capture_stats``` was called, correctly, also when the bestmove was a quiet and not a capture).
passed non-regression STC:
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 75196 W: 16364 L: 16347 D: 42485
http://tests.stockfishchess.org/tests/view/5db004ec0ebc5902c06db9e1
The diff is most easily readable as ```git diff master --patience```
No functional change
2019-10-23 00:26:47 -06:00
|
|
|
// update_continuation_histories() updates histories of the move pairs formed
|
2020-03-01 01:31:17 -07:00
|
|
|
// by moves at ply -1, -2, -4, and -6 with current move.
|
2018-07-03 17:11:54 -06:00
|
|
|
|
Refactor final stats updates.
This PR refactors update_quiet_stats, update_capture_stats and search to more clearly reflect what is actually done.
Effectively, all stat updates that need to be done after search is finished and a bestmove is found,
are collected in a new function ```final_stats_update()```. This shortens our main search routine, and simplifies ```update_quiet_stats```.
The latter function is now more easily reusable with fewer arguments, as the handling of ```quietsSearched``` is only needed in ```final_stats_update```.
```update_capture_stats```, which was only called once is now integrated in ```final_stats_update```, which allows for removing a branch and reusing some ```stat_bonus``` calls. The need for refactoring was also suggested by the fact that the comments of ```update_quiet_stats``` and ```update_capture_stats``` were incorrect (e.g. ```update_capture_stats``` was called, correctly, also when the bestmove was a quiet and not a capture).
passed non-regression STC:
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 75196 W: 16364 L: 16347 D: 42485
http://tests.stockfishchess.org/tests/view/5db004ec0ebc5902c06db9e1
The diff is most easily readable as ```git diff master --patience```
No functional change
2019-10-23 00:26:47 -06:00
|
|
|
void update_continuation_histories(Stack* ss, Piece pc, Square to, int bonus) {
|
2017-11-03 05:37:11 -06:00
|
|
|
|
Refactor final stats updates.
This PR refactors update_quiet_stats, update_capture_stats and search to more clearly reflect what is actually done.
Effectively, all stat updates that need to be done after search is finished and a bestmove is found,
are collected in a new function ```final_stats_update()```. This shortens our main search routine, and simplifies ```update_quiet_stats```.
The latter function is now more easily reusable with fewer arguments, as the handling of ```quietsSearched``` is only needed in ```final_stats_update```.
```update_capture_stats```, which was only called once is now integrated in ```final_stats_update```, which allows for removing a branch and reusing some ```stat_bonus``` calls. The need for refactoring was also suggested by the fact that the comments of ```update_quiet_stats``` and ```update_capture_stats``` were incorrect (e.g. ```update_capture_stats``` was called, correctly, also when the bestmove was a quiet and not a capture).
passed non-regression STC:
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 75196 W: 16364 L: 16347 D: 42485
http://tests.stockfishchess.org/tests/view/5db004ec0ebc5902c06db9e1
The diff is most easily readable as ```git diff master --patience```
No functional change
2019-10-23 00:26:47 -06:00
|
|
|
for (int i : {1, 2, 4, 6})
|
continuation histories when in check
If in check, don't write to continuation histories ss-4, ss-6.
Adding inCheck to the stack was needed, and might be useful for
future patches.
Passed STC:
https://tests.stockfishchess.org/tests/view/5e9ee24acaaff5d60a50b812
LLR: 2.94 (-2.94,2.94) {-0.50,1.50}
Total: 61774 W: 11725 L: 11449 D: 38600
Ptnml(0-2): 971, 7211, 14322, 7337, 1046
Passed LTC:
https://tests.stockfishchess.org/tests/view/5e9eecb7caaff5d60a50b831
LLR: 2.94 (-2.94,2.94) {0.25,1.75}
Total: 250822 W: 32067 L: 31179 D: 187576
Ptnml(0-2): 1745, 23126, 74824, 23928, 1788
closes https://github.com/official-stockfish/Stockfish/pull/2645
bench: 4808463
2020-04-21 12:55:41 -06:00
|
|
|
{
|
2020-12-01 05:02:35 -07:00
|
|
|
// Only update first 2 continuation histories if we are in check
|
continuation histories when in check
If in check, don't write to continuation histories ss-4, ss-6.
Adding inCheck to the stack was needed, and might be useful for
future patches.
Passed STC:
https://tests.stockfishchess.org/tests/view/5e9ee24acaaff5d60a50b812
LLR: 2.94 (-2.94,2.94) {-0.50,1.50}
Total: 61774 W: 11725 L: 11449 D: 38600
Ptnml(0-2): 971, 7211, 14322, 7337, 1046
Passed LTC:
https://tests.stockfishchess.org/tests/view/5e9eecb7caaff5d60a50b831
LLR: 2.94 (-2.94,2.94) {0.25,1.75}
Total: 250822 W: 32067 L: 31179 D: 187576
Ptnml(0-2): 1745, 23126, 74824, 23928, 1788
closes https://github.com/official-stockfish/Stockfish/pull/2645
bench: 4808463
2020-04-21 12:55:41 -06:00
|
|
|
if (ss->inCheck && i > 2)
|
|
|
|
break;
|
Refactor final stats updates.
This PR refactors update_quiet_stats, update_capture_stats and search to more clearly reflect what is actually done.
Effectively, all stat updates that need to be done after search is finished and a bestmove is found,
are collected in a new function ```final_stats_update()```. This shortens our main search routine, and simplifies ```update_quiet_stats```.
The latter function is now more easily reusable with fewer arguments, as the handling of ```quietsSearched``` is only needed in ```final_stats_update```.
```update_capture_stats```, which was only called once is now integrated in ```final_stats_update```, which allows for removing a branch and reusing some ```stat_bonus``` calls. The need for refactoring was also suggested by the fact that the comments of ```update_quiet_stats``` and ```update_capture_stats``` were incorrect (e.g. ```update_capture_stats``` was called, correctly, also when the bestmove was a quiet and not a capture).
passed non-regression STC:
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 75196 W: 16364 L: 16347 D: 42485
http://tests.stockfishchess.org/tests/view/5db004ec0ebc5902c06db9e1
The diff is most easily readable as ```git diff master --patience```
No functional change
2019-10-23 00:26:47 -06:00
|
|
|
if (is_ok((ss-i)->currentMove))
|
|
|
|
(*(ss-i)->continuationHistory)[pc][to] << bonus;
|
continuation histories when in check
If in check, don't write to continuation histories ss-4, ss-6.
Adding inCheck to the stack was needed, and might be useful for
future patches.
Passed STC:
https://tests.stockfishchess.org/tests/view/5e9ee24acaaff5d60a50b812
LLR: 2.94 (-2.94,2.94) {-0.50,1.50}
Total: 61774 W: 11725 L: 11449 D: 38600
Ptnml(0-2): 971, 7211, 14322, 7337, 1046
Passed LTC:
https://tests.stockfishchess.org/tests/view/5e9eecb7caaff5d60a50b831
LLR: 2.94 (-2.94,2.94) {0.25,1.75}
Total: 250822 W: 32067 L: 31179 D: 187576
Ptnml(0-2): 1745, 23126, 74824, 23928, 1788
closes https://github.com/official-stockfish/Stockfish/pull/2645
bench: 4808463
2020-04-21 12:55:41 -06:00
|
|
|
}
|
2017-11-03 05:37:11 -06:00
|
|
|
}
|
|
|
|
|
|
|
|
|
Refactor final stats updates.
This PR refactors update_quiet_stats, update_capture_stats and search to more clearly reflect what is actually done.
Effectively, all stat updates that need to be done after search is finished and a bestmove is found,
are collected in a new function ```final_stats_update()```. This shortens our main search routine, and simplifies ```update_quiet_stats```.
The latter function is now more easily reusable with fewer arguments, as the handling of ```quietsSearched``` is only needed in ```final_stats_update```.
```update_capture_stats```, which was only called once is now integrated in ```final_stats_update```, which allows for removing a branch and reusing some ```stat_bonus``` calls. The need for refactoring was also suggested by the fact that the comments of ```update_quiet_stats``` and ```update_capture_stats``` were incorrect (e.g. ```update_capture_stats``` was called, correctly, also when the bestmove was a quiet and not a capture).
passed non-regression STC:
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 75196 W: 16364 L: 16347 D: 42485
http://tests.stockfishchess.org/tests/view/5db004ec0ebc5902c06db9e1
The diff is most easily readable as ```git diff master --patience```
No functional change
2019-10-23 00:26:47 -06:00
|
|
|
// update_quiet_stats() updates move sorting heuristics
|
2016-08-24 08:52:05 -06:00
|
|
|
|
Improve move order near the root
Current move histories are known to work well near the leaves, whilst at
higher depths they aren't very helpful. To address this problem this
patch introduces a table dedicated for what's happening at plies 0-3.
It's structured like mainHistory with ply index instead of color.
It get cleared with each new search and is filled during iterative
deepening at higher depths when recording successful quiet moves near
the root or traversing nodes which were in the principal variation
(ttPv).
Medium TC (20+0.2):
https://tests.stockfishchess.org/tests/view/5e4d358790a0a02810d096dc
LLR: 2.94 (-2.94,2.94) {-0.50,1.50}
Total: 100910 W: 16682 L: 16376 D: 67852
Ptnml(0-2): 1177, 10983, 25883, 11181, 1231
LTC:
https://tests.stockfishchess.org/tests/view/5e4e2cb790a0a02810d09714
LLR: 2.95 (-2.94,2.94) {0.25,1.75}
Total: 80444 W: 10495 L: 10095 D: 59854
Ptnml(0-2): 551, 7479, 23803, 7797, 592
closes https://github.com/official-stockfish/Stockfish/pull/2557
Bench: 4705960
2020-02-21 06:01:59 -07:00
|
|
|
void update_quiet_stats(const Position& pos, Stack* ss, Move move, int bonus, int depth) {
|
2016-08-23 07:57:56 -06:00
|
|
|
|
2020-12-01 05:02:35 -07:00
|
|
|
// Update killers
|
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
|
|
|
|
2020-12-01 05:02:35 -07:00
|
|
|
// Penalty for reversed move in case of moved piece not being a pawn
|
2019-09-11 05:46:08 -06:00
|
|
|
if (type_of(pos.moved_piece(move)) != PAWN)
|
|
|
|
thisThread->mainHistory[us][from_to(reverse_move(move))] << -bonus;
|
|
|
|
|
2020-12-01 05:02:35 -07:00
|
|
|
// Update countermove history
|
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
|
|
|
}
|
Improve move order near the root
Current move histories are known to work well near the leaves, whilst at
higher depths they aren't very helpful. To address this problem this
patch introduces a table dedicated for what's happening at plies 0-3.
It's structured like mainHistory with ply index instead of color.
It get cleared with each new search and is filled during iterative
deepening at higher depths when recording successful quiet moves near
the root or traversing nodes which were in the principal variation
(ttPv).
Medium TC (20+0.2):
https://tests.stockfishchess.org/tests/view/5e4d358790a0a02810d096dc
LLR: 2.94 (-2.94,2.94) {-0.50,1.50}
Total: 100910 W: 16682 L: 16376 D: 67852
Ptnml(0-2): 1177, 10983, 25883, 11181, 1231
LTC:
https://tests.stockfishchess.org/tests/view/5e4e2cb790a0a02810d09714
LLR: 2.95 (-2.94,2.94) {0.25,1.75}
Total: 80444 W: 10495 L: 10095 D: 59854
Ptnml(0-2): 551, 7479, 23803, 7797, 592
closes https://github.com/official-stockfish/Stockfish/pull/2557
Bench: 4705960
2020-02-21 06:01:59 -07:00
|
|
|
|
2020-12-01 05:02:35 -07:00
|
|
|
// Update low ply history
|
Retuned values after eval quantize patch.
The last search tune patch was tested before the implementation of #2733 which
presumably changed the search characteristics noticeably. Another tuning run was
done, see https://tests.stockfishchess.org/tests/view/5ee5b434ca6c451633a9a08c
and the updated values passed these tests:
STC:
LLR: 2.93 (-2.94,2.94) {-0.50,1.50}
Total: 34352 W: 6600 L: 6360 D: 21392
Ptnml(0-2): 581, 3947, 7914, 4119, 615
https://tests.stockfishchess.org/tests/view/5ee62f05ca6c451633a9a15f
LTC 60+0.6 th 1 :
LLR: 2.97 (-2.94,2.94) {0.25,1.75}
Total: 11176 W: 1499 L: 1304 D: 8373
Ptnml(0-2): 69, 933, 3403, 1100, 83
https://tests.stockfishchess.org/tests/view/5ee6205bca6c451633a9a147
SMP LTC 20+0.2 th 8 :
LLR: 2.93 (-2.94,2.94) {0.25,1.75}
Total: 54032 W: 6126 L: 5826 D: 42080
Ptnml(0-2): 278, 4454, 17280, 4698, 306
https://tests.stockfishchess.org/tests/view/5ee62f25ca6c451633a9a162
Closes https://github.com/official-stockfish/Stockfish/pull/2742
Bench 4957812
2020-06-14 14:50:27 -06:00
|
|
|
if (depth > 11 && ss->ply < MAX_LPH)
|
Assorted search parameter tune
STC https://tests.stockfishchess.org/tests/view/5f31219090816720665374ec
LLR: 2.96 (-2.94,2.94) {-0.50,1.50}
Total: 3376 W: 487 L: 359 D: 2530
Ptnml(0-2): 17, 253, 1042, 337, 39
LTC https://tests.stockfishchess.org/tests/view/5f3127f79081672066537502
LLR: 2.93 (-2.94,2.94) {0.25,1.75}
Total: 8360 W: 581 L: 475 D: 7304
Ptnml(0-2): 11, 407, 3238, 513, 11
closes https://github.com/official-stockfish/Stockfish/pull/2971
bench: 4733874
2020-08-10 07:38:44 -06:00
|
|
|
thisThread->lowPlyHistory[ss->ply][from_to(move)] << stat_bonus(depth - 7);
|
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);
|
2014-12-07 16:53:33 -07:00
|
|
|
int maxScore = -VALUE_INFINITE;
|
2021-10-10 06:03:51 -06:00
|
|
|
double weakness = 120 - 2 * level;
|
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
|
2021-10-10 06:03:51 -06:00
|
|
|
int push = int(( weakness * int(topScore - rootMoves[i].score)
|
|
|
|
+ delta * (rng.rand<unsigned>() % int(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
|
|
|
|
2020-06-24 14:19:58 -06: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)
|
|
|
|
{
|
2019-12-06 02:11:45 -07:00
|
|
|
bool updated = rootMoves[i].score != -VALUE_INFINITE;
|
2011-12-14 01:21:00 -07:00
|
|
|
|
2020-08-31 14:53:20 -06:00
|
|
|
if (depth == 1 && !updated && i > 0)
|
2015-01-31 03:54:25 -07:00
|
|
|
continue;
|
2011-12-14 01:21:00 -07:00
|
|
|
|
2020-08-31 14:53:20 -06:00
|
|
|
Depth d = updated ? depth : std::max(1, depth - 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 v = updated ? rootMoves[i].score : rootMoves[i].previousScore;
|
2015-01-18 00:05:05 -07:00
|
|
|
|
2020-08-31 14:53:20 -06:00
|
|
|
if (v == -VALUE_INFINITE)
|
|
|
|
v = VALUE_ZERO;
|
|
|
|
|
Fix for incorrect VALUE_MATE_IN_MAX_PLY usage.
Fixes #2533, fixes #2543, fixes #2423.
the code that prevents false mate announcements depending on the TT
state (GHI), incorrectly used VALUE_MATE_IN_MAX_PLY. The latter
constant, however, also includes, counterintuitively, the TB win range.
This patch fixes that, by restoring the behavior for TB win scores,
while retaining the false mate correctness, and improving the mate
finding ability. In particular
no alse mates are announced with the poisened hash testcase
```
position fen 8/8/8/3k4/8/8/6K1/7R w - - 0 1
go depth 40
position fen 8/8/8/3k4/8/8/6K1/7R w - - 76 1
go depth 20
ucinewgame
```
mates are found with the testcases reported in #2543
```
position fen 4k3/3pp3/8/8/8/8/2PPP3/4K3 w - - 0 1
setoption name Hash value 1024
go depth 55
ucinewgame
```
and
```
position fen 4k3/4p3/8/8/8/8/3PP3/4K3 w - - 0 1
setoption name Hash value 1024
go depth 45
ucinewgame
```
furthermore, on the mate finding benchmark (ChestUCI_23102018.epd),
performance improves over master, roughly reaching performance with the
false mate protection reverted
```
Analyzing 6566 mate positions for best and found mates:
----------------best ---------------found
nodes master revert fixed master revert fixed
16000000 4233 4236 4235 5200 5201 5199
32000000 4583 4585 4585 5417 5424 5418
64000000 4852 4853 4855 5575 5584 5579
128000000 5071 5068 5066 5710 5720 5716
256000000 5280 5282 5279 5819 5827 5826
512000000 5471 5468 5468 5919 5935 5932
```
On a testcase with TB enabled, progress is made consistently, contrary
to master
```
setoption name SyzygyPath value ../../../syzygy/3-4-5/
setoption name Hash value 2048
position fen 1R6/3k4/8/K2p4/4n3/2P5/8/8 w - - 0 1
go depth 58
ucinewgame
```
The PR (prior to a rewrite for clarity)
passed STC:
LLR: 2.94 (-2.94,2.94) {-1.50,0.50}
Total: 65405 W: 12454 L: 12384 D: 40567
Ptnml(0-2): 920, 7256, 16285, 7286, 944
http://tests.stockfishchess.org/tests/view/5e441a3be70d848499f63d15
passed LTC:
LLR: 2.94 (-2.94,2.94) {-1.50,0.50}
Total: 27096 W: 3477 L: 3413 D: 20206
Ptnml(0-2): 128, 2215, 8776, 2292, 122
http://tests.stockfishchess.org/tests/view/5e44e277e70d848499f63d63
The incorrectly named VALUE_MATE_IN_MAX_PLY and VALUE_MATED_IN_MAX_PLY
were renamed into VALUE_TB_WIN_IN_MAX_PLY and VALUE_TB_LOSS_IN_MAX_PLY,
and correclty defined VALUE_MATE_IN_MAX_PLY and VALUE_MATED_IN_MAX_PLY
were introduced.
One further (corner case) mistake using these constants was fixed (go
mate X), which could lead to a premature return if X > MAX_PLY / 2,
but TB were present.
Thanks to @svivanov72 for one of the reports and help fixing the issue.
closes https://github.com/official-stockfish/Stockfish/pull/2552
Bench: 4932981
2020-02-11 12:42:32 -07:00
|
|
|
bool tb = TB::RootInTB && abs(v) < VALUE_MATE_IN_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"
|
2019-09-28 14:27:23 -06:00
|
|
|
<< " depth " << d
|
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
|
|
|
|
Provide WDL statistics
A number of engines, GUIs and tournaments start to report WDL estimates
along or instead of scores. This patch enables reporting of those stats
in a more or less standard way (http://www.talkchess.com/forum3/viewtopic.php?t=72140)
The model this reporting uses is based on data derived from a few million fishtest LTC games,
given a score and a game ply, a win rate is provided that matches rather closely,
especially in the intermediate range [0.05, 0.95] that data. Some data is shown at
https://github.com/glinscott/fishtest/wiki/UsefulData#win-loss-draw-statistics-of-ltc-games-on-fishtest
Making the conversion game ply dependent is important for a good fit, and is in line
with experience that a +1 score in the early midgame is more likely a win than in the late endgame.
Even when enabled, the printing of the info causes no significant overhead.
Passed STC:
LLR: 2.94 (-2.94,2.94) {-1.50,0.50}
Total: 197112 W: 37226 L: 37347 D: 122539
Ptnml(0-2): 2591, 21025, 51464, 20866, 2610
https://tests.stockfishchess.org/tests/view/5ef79ef4f993893290cc146b
closes https://github.com/official-stockfish/Stockfish/pull/2778
No functional change
2020-06-27 13:29:29 -06:00
|
|
|
if (Options["UCI_ShowWDL"])
|
|
|
|
ss << UCI::wdl(v, pos.game_ply());
|
|
|
|
|
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;
|
2021-04-19 11:50:19 -06:00
|
|
|
ASSERT_ALIGNED(&st, Eval::NNUE::CacheLineSize);
|
2020-11-03 03:23:35 -07:00
|
|
|
|
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"]);
|
2019-09-28 14:27:23 -06:00
|
|
|
ProbeDepth = int(Options["SyzygyProbeDepth"]);
|
2018-04-18 20:16:19 -06:00
|
|
|
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;
|
2019-09-28 14:27:23 -06:00
|
|
|
ProbeDepth = 0;
|
2016-06-03 23:53:29 -06:00
|
|
|
}
|
|
|
|
|
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
|
2020-08-30 19:40:49 -06:00
|
|
|
std::stable_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;
|
|
|
|
}
|
2019-06-18 15:27:34 -06:00
|
|
|
else
|
|
|
|
{
|
|
|
|
// Clean up if root_probe() and root_probe_wdl() have failed
|
|
|
|
for (auto& m : rootMoves)
|
|
|
|
m.tbRank = 0;
|
|
|
|
}
|
2016-06-03 23:53:29 -06:00
|
|
|
}
|
2021-02-26 02:02:13 -07:00
|
|
|
|
|
|
|
} // namespace Stockfish
|