2010-07-11 10:23:50 -06:00
|
|
|
/*
|
|
|
|
Stockfish, a UCI chess playing engine derived from Glaurung 2.1
|
|
|
|
Copyright (C) 2004-2008 Tord Romstad (Glaurung author)
|
2016-01-02 02:43:25 -07:00
|
|
|
Copyright (C) 2008-2015 Marco Costalba, Joona Kiiski, Tord Romstad
|
2020-01-07 13:35:47 -07:00
|
|
|
Copyright (C) 2015-2020 Marco Costalba, Joona Kiiski, Gary Linscott, Tord Romstad
|
2010-07-11 10:23:50 -06:00
|
|
|
|
|
|
|
Stockfish is free software: you can redistribute it and/or modify
|
|
|
|
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.
|
|
|
|
|
|
|
|
Stockfish is distributed in the hope that it will be useful,
|
|
|
|
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.
|
|
|
|
|
|
|
|
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>
|
2018-01-13 00:59:20 -07:00
|
|
|
#include <cfloat>
|
|
|
|
#include <cmath>
|
2010-07-11 10:23:50 -06:00
|
|
|
|
2011-04-22 07:52:03 -06:00
|
|
|
#include "search.h"
|
2010-08-03 03:10:16 -06:00
|
|
|
#include "timeman.h"
|
2014-10-26 00:09:19 -06:00
|
|
|
#include "uci.h"
|
2010-07-11 10:23:50 -06:00
|
|
|
|
Add support for playing in 'nodes as time' mode
When running more games in parallel, or simply when running a game
with a background process, due to how OS scheduling works, there is no
guarantee that the CPU resources allocated evenly between the two
players. This introduces noise in the result that leads to unreliable
result and in the worst cases can even invalidate the result. For
instance in SF test framework we avoid running from clouds virtual
machines because are a known source of very unstable CPU speed.
To overcome this issue, without requiring changes to the GUI, the idea
is to use searched nodes instead of time, and to convert time to
available nodes upfront, at the beginning of the game.
When nodestime UCI option is set at a given nodes per milliseconds
(npmsec), at the beginning of the game (and only once), the engine
reads the available time to think, sent by the GUI with 'go wtime x'
UCI command. Then it translates time in available nodes (nodes =
npmsec * x), then feeds available nodes instead of time to the time
management logic and starts the search. During the search the engine
checks the searched nodes against the available ones in such a way
that all the time management logic still fully applies, and the game
mimics a real one played on real time. When the search finishes,
before returning best move, the total available nodes are updated,
subtracting the real searched nodes. After the first move, the time
information sent by the GUI is ignored, and the engine fully relies on
the updated total available nodes to feed time management.
To avoid time losses, the speed of the engine (npms) must be set to a
value lower than real speed so that if the real TC is for instance 30
secs, and npms is half of the real speed, the game will last on
average 15 secs, so much less than the TC limit, providing for a
safety 'time buffer'.
There are 2 main limitations with this mode.
1. Engine speed should be the same for both players, and this limits
the approach to mainly parameter tuning patches.
2. Because npms is fixed while, in real engines, the speed increases
toward endgame, this introduces an artifact that is equivalent to an
altered time management. Namely it is like the time management gives
less available time than what should be in standard case.
May be the second limitation could be mitigated in a future with a
smarter 'dynamic npms' approach.
Tests shows that the standard deviation of the results with 'nodestime'
is lower than in standard TC, as is expected because now all the introduced
noise due the random speed variability of the engines during the game is
fully removed.
Original NIT idea by Michael Hoffman that shows how to play in NIT mode
without requiring changes to the GUI. This implementation goes a bit
further, the key difference is that we read TC from GUI only once upfront
instead of re-reading after every move as in Michael's implementation.
No functional change.
2015-03-22 14:15:44 -06:00
|
|
|
TimeManagement Time; // Our global time management object
|
|
|
|
|
2010-07-11 10:23:50 -06:00
|
|
|
namespace {
|
|
|
|
|
2014-04-12 04:00:37 -06:00
|
|
|
enum TimeType { OptimumTime, MaxTime };
|
2010-07-11 10:23:50 -06:00
|
|
|
|
2018-03-18 16:38:58 -06:00
|
|
|
constexpr int MoveHorizon = 50; // Plan time management at most this many moves ahead
|
|
|
|
constexpr double MaxRatio = 7.3; // When in trouble, we can step over reserved time with this ratio
|
|
|
|
constexpr double StealRatio = 0.34; // However we must not steal time from remaining moves over this ratio
|
2016-10-07 10:12:19 -06:00
|
|
|
|
|
|
|
|
2018-01-13 00:59:20 -07:00
|
|
|
// move_importance() is a skew-logistic function based on naive statistical
|
|
|
|
// analysis of "how many games are still undecided after n half-moves". Game
|
|
|
|
// is considered "undecided" as long as neither side has >275cp advantage.
|
|
|
|
// Data was extracted from the CCRL game database with some simple filtering criteria.
|
2016-10-07 10:12:19 -06:00
|
|
|
|
2018-01-13 00:59:20 -07:00
|
|
|
double move_importance(int ply) {
|
2016-10-07 10:12:19 -06:00
|
|
|
|
2018-03-18 16:38:58 -06:00
|
|
|
constexpr double XScale = 6.85;
|
|
|
|
constexpr double XShift = 64.5;
|
|
|
|
constexpr double Skew = 0.171;
|
2016-10-07 10:12:19 -06:00
|
|
|
|
2018-01-13 00:59:20 -07:00
|
|
|
return pow((1 + exp((ply - XShift) / XScale)), -Skew) + DBL_MIN; // Ensure non-zero
|
|
|
|
}
|
|
|
|
|
|
|
|
template<TimeType T>
|
2018-03-27 08:22:53 -06:00
|
|
|
TimePoint remaining(TimePoint myTime, int movesToGo, int ply, TimePoint slowMover) {
|
2017-08-18 09:44:37 -06:00
|
|
|
|
2018-03-27 08:22:53 -06:00
|
|
|
constexpr double TMaxRatio = (T == OptimumTime ? 1.0 : MaxRatio);
|
|
|
|
constexpr double TStealRatio = (T == OptimumTime ? 0.0 : StealRatio);
|
2017-10-15 08:44:29 -06:00
|
|
|
|
2018-03-27 08:22:53 -06:00
|
|
|
double moveImportance = (move_importance(ply) * slowMover) / 100.0;
|
|
|
|
double otherMovesImportance = 0.0;
|
2016-10-07 10:12:19 -06:00
|
|
|
|
2018-01-13 00:59:20 -07:00
|
|
|
for (int i = 1; i < movesToGo; ++i)
|
|
|
|
otherMovesImportance += move_importance(ply + 2 * i);
|
2017-08-18 01:38:27 -06:00
|
|
|
|
2018-01-13 00:59:20 -07:00
|
|
|
double ratio1 = (TMaxRatio * moveImportance) / (TMaxRatio * moveImportance + otherMovesImportance);
|
|
|
|
double ratio2 = (moveImportance + TStealRatio * otherMovesImportance) / (moveImportance + otherMovesImportance);
|
2017-08-18 01:38:27 -06:00
|
|
|
|
2018-03-27 08:22:53 -06:00
|
|
|
return TimePoint(myTime * std::min(ratio1, ratio2)); // Intel C++ asks for an explicit cast
|
2014-04-12 04:00:37 -06:00
|
|
|
}
|
2010-08-03 03:20:06 -06:00
|
|
|
|
2014-04-12 04:00:37 -06:00
|
|
|
} // namespace
|
2010-08-03 03:20:06 -06:00
|
|
|
|
2011-04-22 07:52:03 -06:00
|
|
|
|
2014-12-28 04:34:01 -07:00
|
|
|
/// init() is called at the beginning of the search and calculates the allowed
|
|
|
|
/// thinking time out of the time control and current game ply. We support four
|
|
|
|
/// different kinds of time controls, passed in 'limits':
|
|
|
|
///
|
|
|
|
/// inc == 0 && movestogo == 0 means: x basetime [sudden death!]
|
|
|
|
/// inc == 0 && movestogo != 0 means: x moves in y minutes
|
|
|
|
/// inc > 0 && movestogo == 0 means: x basetime + z increment
|
|
|
|
/// inc > 0 && movestogo != 0 means: x moves in y minutes + z increment
|
2010-08-02 03:34:19 -06:00
|
|
|
|
2018-01-13 00:59:20 -07:00
|
|
|
void TimeManagement::init(Search::LimitsType& limits, Color us, int ply) {
|
|
|
|
|
2018-03-27 08:22:53 -06:00
|
|
|
TimePoint minThinkingTime = Options["Minimum Thinking Time"];
|
|
|
|
TimePoint moveOverhead = Options["Move Overhead"];
|
|
|
|
TimePoint slowMover = Options["Slow Mover"];
|
|
|
|
TimePoint npmsec = Options["nodestime"];
|
|
|
|
TimePoint hypMyTime;
|
Add support for playing in 'nodes as time' mode
When running more games in parallel, or simply when running a game
with a background process, due to how OS scheduling works, there is no
guarantee that the CPU resources allocated evenly between the two
players. This introduces noise in the result that leads to unreliable
result and in the worst cases can even invalidate the result. For
instance in SF test framework we avoid running from clouds virtual
machines because are a known source of very unstable CPU speed.
To overcome this issue, without requiring changes to the GUI, the idea
is to use searched nodes instead of time, and to convert time to
available nodes upfront, at the beginning of the game.
When nodestime UCI option is set at a given nodes per milliseconds
(npmsec), at the beginning of the game (and only once), the engine
reads the available time to think, sent by the GUI with 'go wtime x'
UCI command. Then it translates time in available nodes (nodes =
npmsec * x), then feeds available nodes instead of time to the time
management logic and starts the search. During the search the engine
checks the searched nodes against the available ones in such a way
that all the time management logic still fully applies, and the game
mimics a real one played on real time. When the search finishes,
before returning best move, the total available nodes are updated,
subtracting the real searched nodes. After the first move, the time
information sent by the GUI is ignored, and the engine fully relies on
the updated total available nodes to feed time management.
To avoid time losses, the speed of the engine (npms) must be set to a
value lower than real speed so that if the real TC is for instance 30
secs, and npms is half of the real speed, the game will last on
average 15 secs, so much less than the TC limit, providing for a
safety 'time buffer'.
There are 2 main limitations with this mode.
1. Engine speed should be the same for both players, and this limits
the approach to mainly parameter tuning patches.
2. Because npms is fixed while, in real engines, the speed increases
toward endgame, this introduces an artifact that is equivalent to an
altered time management. Namely it is like the time management gives
less available time than what should be in standard case.
May be the second limitation could be mitigated in a future with a
smarter 'dynamic npms' approach.
Tests shows that the standard deviation of the results with 'nodestime'
is lower than in standard TC, as is expected because now all the introduced
noise due the random speed variability of the engines during the game is
fully removed.
Original NIT idea by Michael Hoffman that shows how to play in NIT mode
without requiring changes to the GUI. This implementation goes a bit
further, the key difference is that we read TC from GUI only once upfront
instead of re-reading after every move as in Michael's implementation.
No functional change.
2015-03-22 14:15:44 -06:00
|
|
|
|
|
|
|
// If we have to play in 'nodes as time' mode, then convert from time
|
|
|
|
// to nodes, and use resulting values in time management formulas.
|
2018-03-27 08:22:53 -06:00
|
|
|
// WARNING: to avoid time losses, the given npmsec (nodes per millisecond)
|
|
|
|
// must be much lower than the real engine speed.
|
Add support for playing in 'nodes as time' mode
When running more games in parallel, or simply when running a game
with a background process, due to how OS scheduling works, there is no
guarantee that the CPU resources allocated evenly between the two
players. This introduces noise in the result that leads to unreliable
result and in the worst cases can even invalidate the result. For
instance in SF test framework we avoid running from clouds virtual
machines because are a known source of very unstable CPU speed.
To overcome this issue, without requiring changes to the GUI, the idea
is to use searched nodes instead of time, and to convert time to
available nodes upfront, at the beginning of the game.
When nodestime UCI option is set at a given nodes per milliseconds
(npmsec), at the beginning of the game (and only once), the engine
reads the available time to think, sent by the GUI with 'go wtime x'
UCI command. Then it translates time in available nodes (nodes =
npmsec * x), then feeds available nodes instead of time to the time
management logic and starts the search. During the search the engine
checks the searched nodes against the available ones in such a way
that all the time management logic still fully applies, and the game
mimics a real one played on real time. When the search finishes,
before returning best move, the total available nodes are updated,
subtracting the real searched nodes. After the first move, the time
information sent by the GUI is ignored, and the engine fully relies on
the updated total available nodes to feed time management.
To avoid time losses, the speed of the engine (npms) must be set to a
value lower than real speed so that if the real TC is for instance 30
secs, and npms is half of the real speed, the game will last on
average 15 secs, so much less than the TC limit, providing for a
safety 'time buffer'.
There are 2 main limitations with this mode.
1. Engine speed should be the same for both players, and this limits
the approach to mainly parameter tuning patches.
2. Because npms is fixed while, in real engines, the speed increases
toward endgame, this introduces an artifact that is equivalent to an
altered time management. Namely it is like the time management gives
less available time than what should be in standard case.
May be the second limitation could be mitigated in a future with a
smarter 'dynamic npms' approach.
Tests shows that the standard deviation of the results with 'nodestime'
is lower than in standard TC, as is expected because now all the introduced
noise due the random speed variability of the engines during the game is
fully removed.
Original NIT idea by Michael Hoffman that shows how to play in NIT mode
without requiring changes to the GUI. This implementation goes a bit
further, the key difference is that we read TC from GUI only once upfront
instead of re-reading after every move as in Michael's implementation.
No functional change.
2015-03-22 14:15:44 -06:00
|
|
|
if (npmsec)
|
|
|
|
{
|
|
|
|
if (!availableNodes) // Only once at game start
|
|
|
|
availableNodes = npmsec * limits.time[us]; // Time is in msec
|
|
|
|
|
2018-03-27 08:22:53 -06:00
|
|
|
// Convert from milliseconds to nodes
|
|
|
|
limits.time[us] = TimePoint(availableNodes);
|
Add support for playing in 'nodes as time' mode
When running more games in parallel, or simply when running a game
with a background process, due to how OS scheduling works, there is no
guarantee that the CPU resources allocated evenly between the two
players. This introduces noise in the result that leads to unreliable
result and in the worst cases can even invalidate the result. For
instance in SF test framework we avoid running from clouds virtual
machines because are a known source of very unstable CPU speed.
To overcome this issue, without requiring changes to the GUI, the idea
is to use searched nodes instead of time, and to convert time to
available nodes upfront, at the beginning of the game.
When nodestime UCI option is set at a given nodes per milliseconds
(npmsec), at the beginning of the game (and only once), the engine
reads the available time to think, sent by the GUI with 'go wtime x'
UCI command. Then it translates time in available nodes (nodes =
npmsec * x), then feeds available nodes instead of time to the time
management logic and starts the search. During the search the engine
checks the searched nodes against the available ones in such a way
that all the time management logic still fully applies, and the game
mimics a real one played on real time. When the search finishes,
before returning best move, the total available nodes are updated,
subtracting the real searched nodes. After the first move, the time
information sent by the GUI is ignored, and the engine fully relies on
the updated total available nodes to feed time management.
To avoid time losses, the speed of the engine (npms) must be set to a
value lower than real speed so that if the real TC is for instance 30
secs, and npms is half of the real speed, the game will last on
average 15 secs, so much less than the TC limit, providing for a
safety 'time buffer'.
There are 2 main limitations with this mode.
1. Engine speed should be the same for both players, and this limits
the approach to mainly parameter tuning patches.
2. Because npms is fixed while, in real engines, the speed increases
toward endgame, this introduces an artifact that is equivalent to an
altered time management. Namely it is like the time management gives
less available time than what should be in standard case.
May be the second limitation could be mitigated in a future with a
smarter 'dynamic npms' approach.
Tests shows that the standard deviation of the results with 'nodestime'
is lower than in standard TC, as is expected because now all the introduced
noise due the random speed variability of the engines during the game is
fully removed.
Original NIT idea by Michael Hoffman that shows how to play in NIT mode
without requiring changes to the GUI. This implementation goes a bit
further, the key difference is that we read TC from GUI only once upfront
instead of re-reading after every move as in Michael's implementation.
No functional change.
2015-03-22 14:15:44 -06:00
|
|
|
limits.inc[us] *= npmsec;
|
|
|
|
limits.npmsec = npmsec;
|
|
|
|
}
|
2010-07-11 10:23:50 -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
|
|
|
startTime = limits.startTime;
|
2018-01-13 00:59:20 -07:00
|
|
|
optimumTime = maximumTime = std::max(limits.time[us], minThinkingTime);
|
|
|
|
|
2018-03-18 16:38:58 -06:00
|
|
|
const int maxMTG = limits.movestogo ? std::min(limits.movestogo, MoveHorizon) : MoveHorizon;
|
2018-01-13 00:59:20 -07:00
|
|
|
|
2018-03-27 08:22:53 -06:00
|
|
|
// We calculate optimum time usage for different hypothetical "moves to go" values
|
2018-01-13 00:59:20 -07:00
|
|
|
// and choose the minimum of calculated search time values. Usually the greatest
|
|
|
|
// hypMTG gives the minimum values.
|
2018-03-18 16:38:58 -06:00
|
|
|
for (int hypMTG = 1; hypMTG <= maxMTG; ++hypMTG)
|
2018-01-13 00:59:20 -07:00
|
|
|
{
|
|
|
|
// Calculate thinking time for hypothetical "moves to go"-value
|
2018-03-27 08:22:53 -06:00
|
|
|
hypMyTime = limits.time[us]
|
|
|
|
+ limits.inc[us] * (hypMTG - 1)
|
|
|
|
- moveOverhead * (2 + std::min(hypMTG, 40));
|
2018-01-13 00:59:20 -07:00
|
|
|
|
2018-03-27 08:22:53 -06:00
|
|
|
hypMyTime = std::max(hypMyTime, TimePoint(0));
|
2018-01-13 00:59:20 -07:00
|
|
|
|
2018-03-27 08:22:53 -06:00
|
|
|
TimePoint t1 = minThinkingTime + remaining<OptimumTime>(hypMyTime, hypMTG, ply, slowMover);
|
|
|
|
TimePoint t2 = minThinkingTime + remaining<MaxTime >(hypMyTime, hypMTG, ply, slowMover);
|
2018-01-13 00:59:20 -07:00
|
|
|
|
|
|
|
optimumTime = std::min(t1, optimumTime);
|
|
|
|
maximumTime = std::min(t2, maximumTime);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (Options["Ponder"])
|
|
|
|
optimumTime += optimumTime / 4;
|
2010-07-11 10:23:50 -06:00
|
|
|
}
|