1
0
Fork 0
mirror of https://github.com/sockspls/badfish synced 2025-05-01 17:19:36 +00:00
Commit graph

76 commits

Author SHA1 Message Date
IIvec
aa88261a8f Revert to old time management (#1351)
As many users reported some problems with new time management,
and recent tests on longer time controls

http://tests.stockfishchess.org/tests/view/5a460e160ebc590ccbb8c35d
http://tests.stockfishchess.org/tests/view/5a462f4d0ebc590ccbb8c37a

are even little in favor of old time management, this revert seems as a logical step.

STC:
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 14060 W: 2562 L: 2430 D: 9068

LTC:
LLR: 3.44 (-2.94,2.94) [-3.00,1.00]
Total: 31611 W: 3958 L: 3827 D: 23826

bench: 5365777 (same as master)
2018-01-13 08:59:20 +01:00
Joost VandeVondele
9afa1d7330 New Year 2018
Adjust copyright headers.

No functional change.
2018-01-01 13:18:10 +01:00
IIvec
287e2e2f74 Fix premature using of all available time in x/y TC
In x/y time controls there was a theoretical possibility
to use all available time few moves before the clock will
be updated with new time. This patch fixes that issue.

Tested at 60/15 time control:

LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 113963 W: 20008 L: 20042 D: 73913

The test was done without adjudication rules!

Bench 5234652
2017-10-22 07:43:37 +02:00
Marco Costalba
3fd7e37868 Fix a warning with MSVC
warning C4244: '*=': conversion from 'double' to 'int', possible loss of data

No functional change.
2017-09-01 20:23:31 +02:00
lucasart
fe60caba94 Restore safety margin of 60ms
What this patch does is:
* increase safety margin from 40ms to 60ms. It's worth noting that the previous
  code not only used 60ms incompressible safety margin, but also an additional
  buffer of 30ms for each "move to go".
* remove a whart, integrating the extra 10ms in Move Overhead value instead.
  Additionally, this ensures that optimumtime doesn't become bigger than maximum
  time after maximum time has been artificially discounted by 10ms. So it keeps
  the code more logical.

Tested at 3 different time controls:

Standard 10+0.1
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 58008 W: 10674 L: 10617 D: 36717

Sudden death 16+0
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 59664 W: 10945 L: 10891 D: 37828

Tournament 40/10
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 16371 W: 3092 L: 2963 D: 10316

bench: 5479946
2017-08-20 20:00:31 +08:00
Marco Costalba
e10255339f Reformat time manager code
In particular clarify that 'sd'
parameter is used only in !movesToGo
case.

Verified with Ivan's check tool it is
equivalent to original code.

No functional change.
2017-08-18 08:54:38 -07:00
Joost VandeVondele
daf0fe1f57 Collect more corrections to optimum/maximum
The only call site of Time.maximum() corrected by 10.
Do this directly in remaining().

Ponder increased Time.optimum by 25% in init(). Idem.
Delete unused includes.

No functional change.
2017-08-18 08:38:40 -07:00
IIvec
01d97521fd Time management simplification
STC (http://tests.stockfishchess.org/tests/view/598188a40ebc5916ff64a21b):
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 25363 W: 4658 L: 4545 D: 16160

LTC (http://tests.stockfishchess.org/tests/view/5981d59a0ebc5916ff64a229):
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 75356 W: 9690 L: 9640 D: 56026

40/10 TC (http://tests.stockfishchess.org/tests/view/5980c5780ebc5916ff64a1ed):
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 19377 W: 3650 L: 3526 D: 12201

15+0 TC (http://tests.stockfishchess.org/tests/view/5982cb730ebc5916ff64a25d):
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 5913 W: 1217 L: 1069 D: 3627

This time management handles base time and movestogo cases separatelly. One can test one case without affecting the other. Also, increment usage can be tested separately without (necessarily) affecting sudden death or x moves in y seconds performance.

On stable machines there are no time losses on 0.1+0.001 time control (tested on i7 + Windows 10 platform).

Bench 5608839
2017-08-17 14:42:22 -07:00
Joost VandeVondele
d8f683760c Adjust copyright headers to 2017 (#965)
No functional change.
2017-01-11 08:46:29 +01:00
Stéphane Nicolet
7ae3c05795 Rename shift_bb() to shift()
Rename shift_bb() to shift(), and DELTA_S to SOUTH, etc.
to improve code readability, especially in evaluate.cpp
when they are used together:

    old b = shift_bb<DELTA_S>(pos.pieces(PAWN))
    new b = shift<SOUTH>(pos.pieces(PAWN))

While there fix some small code style issues.

No functional change.
2016-09-25 10:45:10 +02:00
Marco Costalba
7eaea3848c StateInfo is usually allocated on the stack by search()
And passed in do_move(), this ensures maximum efficiency and
speed and at the same time unlimited move numbers.

The draw back is that to handle Position init we need to
reserve a StateInfo inside Position itself and use at
init time and when copying from another Position.

After lazy SMP we don't need anymore this gimmick and we can
get rid of this special case and always pass an external
StateInfo to Position object.

Also rewritten and simplified Position constructors.

Verified it does not regress with a 3 threads SMP test:
ELO: -0.00 +-12.7 (95%) LOS: 50.0%
Total: 1000 W: 173 L: 173 D: 654

No functional change.
2016-04-17 08:29:33 +02:00
Leonid Pechenik
d5ba8e827d Revert "Remove slowMover"
This reverts commit 77fa960f89.

Resolves #590
2016-02-28 13:25:05 +00:00
IIvec
77fa960f89 Remove slowMover
Removes a slowMover and one paramater from move_importance function.

STC:
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 77023 W: 14456 L: 14433 D: 48134

LTC:
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 37175 W: 5190 L: 5092 D: 26893

Resolves #589
2016-02-21 20:16:28 +00:00
Leonid Pechenik
aedebe35cf Time management simplification
10+0.1:
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 41963 W: 7967 L: 7883 D: 26113

60+0.6:
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 132314 W: 17939 L: 17969 D: 96406

Resolves #580
2016-01-29 00:47:07 +00:00
Lyudmil Antonov
89723339d9 Assorted English grammar changes
No functional change

Resolves #567
2016-01-16 21:34:29 +00:00
Leonid Pechenik
9eceb894ac Adjust time used for move based on previous score
Use less time if evaluation is not worse than for previous move and even less time if in addition no fail low encountered for current iteration.

STC: 10+0.1
ELO: 5.37 +-2.9 (95%) LOS: 100.0%
Total: 20000 W: 3832 L: 3523 D: 12645

STC: 10+0.1
LLR: 2.96 (-2.94,2.94) [0.00,5.00]
Total: 17527 W: 3334 L: 3132 D: 11061

LTC: 60+0.6
LLR: 2.95 (-2.94,2.94) [0.00,5.00]
Total: 28233 W: 3939 L: 3725 D: 20569

LTC: 60+0.6
ELO: 2.43 +-1.4 (95%) LOS: 100.0%
Total: 60000 W: 8266 L: 7847 D: 43887

LTC: 60+0.06
LLR: 2.95 (-2.94,2.94) [-1.00,3.00]
Total: 38932 W: 5408 L: 5207 D: 28317

Resolves #547
2016-01-03 14:01:15 +00:00
ppigazzini
d4af15f682 Update AUTHORS and copyright notice
No functional change

Resolves #555
2016-01-02 09:43:51 +00:00
Marco Costalba
9742fb10fd Update Copyright year
No functional change.

Resolves #554
2016-01-01 10:17:36 +00:00
Leonid Pechenik
69240a982d Simplify time management and fix 'ponder on' bug
Simplify time management code by removing hard stops for unchanging first root moves.
Search is now stopped earlier at the end iteration if it did not have fail-lows at root.

This simplification also fixes pondering bug. Ponder flag was true by default
and cutechess-cli doesn't change it to false even though no pondering is possible.
Fix the issue by setting the default value of 'Ponder' flag to false.

10+0.1:
ELO: 3.51 +-3.0 (95%) LOS: 99.0%
Total: 20000 W: 3898 L: 3696 D: 12406

40+0.4:
ELO: 1.39 +-2.7 (95%) LOS: 84.7%
Total: 20000 W: 3104 L: 3024 D: 13872

60+0.06:
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 37231 W: 5333 L: 5236 D: 26662

Stopped run at 100+1:
LLR: 1.09 (-2.94,2.94) [-3.00,1.00]
Total: 37253 W: 4862 L: 4856 D: 27535

Resolves #523
Fixes #510
2015-12-14 18:00:52 +00:00
mbootsector
ecc5ff6693 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-20 06:58:08 +02:00
Marco Costalba
926f215061 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-04-03 04:40:55 +02:00
Marco Costalba
df722521ba Rename of TimeMgr and friends
More natural naming IMO.

No functional change.
2015-04-03 04:19:29 +02:00
Marco Costalba
5d1b92e8f9 Introduce elapsed_time()
And reformat a bit time manager code.

Note that now we set starting search time in think() and
no more in ThreadPool::start_thinking(), the added delay
is less than 1 msec, so below timer resolution (5msec) and
should not affect time lossses ratio.

No functional change.
2015-04-03 04:19:26 +02:00
Marco Costalba
42b48b08e8 Update copyright year
No functional change.
2015-01-10 11:46:28 +01:00
Marco Costalba
c150f07291 Fix a silly warning with Intel compiler
Intel compiler cries for an explicit cast

warning #2259: non-pointer conversion from "double" to "int"
may lose significant bits

No functional change.
2015-01-03 10:17:04 +01:00
Marco Costalba
2416242c96 Additional tidy up in timeman.cpp
Fixed some comments and moved/renamed some
variables.

No functional change.
2014-12-30 09:49:54 +01:00
Arjun Temurnikar
f9571e8d57 Remove some comments in timeman.cpp
Commenst are obsolete now, an updated description
would be quite obscure, so better let the code
to talk and remove them all together.

No functional change.
2014-12-28 11:58:29 +01:00
Marco Costalba
5cbcff55cc Rename ucioption.h to uci.h
We are going to add all UCI related
functions here, so first rename it
to a more proper name.

No functional change.
2014-10-26 19:39:46 +00:00
Marco Costalba
4d0a6c5a6f Rename time variable to reflect UCI parameters
On top of previous patch, rename time variables to
reflect the simplification of UCI parameters.

It is more correct to use as varibales directly the
corresponding UCI option, without intorducing redundant
intermediate variables.

This allows also to simplify the code.

No functional change.
2014-09-21 08:23:12 +08:00
lucasart
b66552fc27 Simplify Time Management UCI options
No functional change
2014-09-15 20:24:51 +01:00
Marco Costalba
9f2a64abd2 Don't need floor() in timeman.cpp
For positive numbers result is equivalent:
http://stackoverflow.com/questions/3300290/cast-to-int-vs-floor

Spotted by Joseph Ellis.

No functional change.
2014-04-27 19:10:00 +02:00
Marco Costalba
93e3b06fe2 Fix Intel compiler warnings
Fallout from previous patch: Intel compiler
is very noisy.

No functional change.
2014-04-27 12:02:36 +02:00
Marco Costalba
86c20416c8 Remove some useless casts
No functional change.
2014-04-27 11:44:16 +02:00
Marco Costalba
17cb7e7fa3 Reshuffle in timeman.cpp
Move template definitions before call site.

No functional change.
2014-04-12 12:00:37 +02:00
Leonid Pechenik
72e8640f4d Simplify time management
Tested with simplification mode SPRT[-4, 0]

Passed both short TC
LLR: 2.95 (-2.94,2.94) [-4.00,0.00]
Total: 34102 W: 6184 L: 6144 D: 21774

And long TC
LLR: 2.96 (-2.94,2.94) [-4.00,0.00]
Total: 16518 W: 2647 L: 2545 D: 11326

And also 40/10 TC
LLR: 2.95 (-2.94,2.94) [-4.00,0.00]
Total: 22406 W: 4390 L: 4312 D: 13704

bench: 8430785
2014-02-12 20:01:11 +01:00
Joona Kiiski
cabd512916 Fix +M0 score when low on time
When time remaining is less than Emergency Move Time,
we won't even complete one iteration and engine reports
a stale +M0 score.

To reproduce run "go wtime 10"

info depth 1 seldepth 1 score mate 0 upperbound nodes 2 nps 500 time 4 multipv 1 pv a2a3
info nodes 2 time 4
bestmove a2a3 ponder (none)

This patch fixes the issue.

Tested by Binky at very short TC: 0.05+0.05
ELO: 5.96 +-12.9 (95%) LOS: 81.7%
Total: 1458 W: 394 L: 369 D: 695

And at a bit longer TC:
ELO: 1.56 +-3.7 (95%) LOS: 79.8%
Total: 16511 W: 3983 L: 3909 D: 8619

bench: 7804908
2014-01-19 11:09:44 +01:00
Marco Costalba
a646f74e6a Assorted grammar fixes
Mainly from Lyudmil Antonov and
one from Henri Wiechers and Louis Zulli.

No functional change.
2014-01-07 14:30:41 +09:00
H. Felix Wittmann
8454d871ec Ensure move_importance() is non-zero
In case ply is very high, function will round
to zero (although mathematically it is always
bigger than zero). On my system this happens at
movenumber 6661.

Although 6661 moves in a game is, of course,
probably impossible, for safety and to be locally
consistent makes sense to ensure returned value
is positive.

Non functional change.
2014-01-02 13:01:24 +01:00
Marco Costalba
c9dcda6ac4 Update copyright year
No functional change.
2014-01-02 01:49:18 +01:00
Marco Costalba
29e0d8caa7 Simplify move_importance(): take 3
Use pow() of a negative number instead of 1/x

No functional change.
2014-01-01 13:43:58 +01:00
Marco Costalba
a795187c50 Further simplify move_importance()
Function move_importance() is already always
positive, so we don't need to add a constant
term to ensure it.

Becuase move_importance() is used to calculate
ratios of a linear combination (as explained in
previous patch), result is not affected. I have
also verified it directly.

No functional change.
2014-01-01 13:35:11 +01:00
H. Felix Wittmann
92faa74dfa Simplify move_importance()
Drop a useless parameter. This works because ratio1 and ratio2
are ratios of linear combinations of thisMoveImportance and
otherMovesImportance and so the yscale cancels out.

Therefore the values of ratio1 and ratio2 are independent
of yscale and yscale can be retired.

The same applies to yshift, but here we want to ensure
move_importance() > 0, so directly hard-code this safety
guard in function definition.

Actually there are some small differences due to rounding errors
and usually are at most few millisecond, that's means below 1% of
returned time, apart from very short intervals in which a difference
of just 1 msec can raise to 2-3% of total available time.

No functional change.
2014-01-01 12:58:10 +01:00
Matt Sullivan
59a9bc9351 Retire MoveImportance[]
Use a skew-logistic function to replace the
MoveImportance[] array.

Verified it does not regress at fixed number
of games both at short TC:
LLR: -2.91 (-2.94,2.94) [-1.50,4.50]
Total: 39457 W: 7539 L: 7538 D: 24380

And long TC:
ELO: -0.49 +-1.9 (95%) LOS: 31.0%
Total: 39358 W: 6135 L: 6190 D: 27033

bench: 7335588
2013-12-29 10:33:39 +01:00
Jerry Donald
a8af78c833 Another round of spelling fixes
And also renamed a loop variable while there.

No functional change.
2013-12-02 23:51:29 +01:00
Richard Lloyd
13a73f67c0 Big assorted spelling fixes
No functional change.
2013-12-02 20:29:35 +01:00
Matthew Sullivan
d454cd4216 Fix divide by zero bug in late game
If the game got late enough that move_importance(currentPly) * slowMover / 100
rounds to 0, then we ended up dividing 0 by 0 when only looking 1 move ahead.

This apparently caused the search to almost immediately abort and Stockfish
would blunder in long games. So convert thisMoveImportance to a double.

No functional change.
2013-10-27 08:03:58 +01:00
Uri Blass
bb83a417cb Increase slowmover and reduce instability
These two changes go in opposite directions and it
seems that the combination is stronger than original.

Here are the positive tests at various TC:

15+0.05
LLR: 2.96 (-2.94,2.94) [-1.50,4.50]
Total: 24561 W: 4946 L: 4772 D: 14843

60+0.05
LLR: 2.96 (-2.94,2.94) [0.00,6.00]
Total: 15259 W: 2598 L: 2423 D: 10238

40/30
LLR: 2.96 (-2.94,2.94) [-3.00,3.00]
Total: 2570 W: 527 L: 422 D: 1621

Unfortunately there is also a bad result
with one sec time increment that needs
to be further investigated:

12+1
LLR: -2.97 (-2.94,2.94) [-3.00,3.00]
Total: 2694 W: 438 L: 543 D: 1713

bench: 8340585
2013-10-08 21:24:21 +02:00
Lucas Braesch
a0cc15ccbc Use double everywhere
Rationale:

- Speed of double and float is about the same (not on the hot path anyway)

- Double makes code prettier (no need to write 1.0f, just 1.0)

- Only practical advantage of float is to use less memory, but since we never
  store large arrays of double, we don't care.

No functional change.
2013-10-05 18:12:52 +02:00
Lucas Braesch
7f142d6817 Use prefix operators wherever possible
No functional change.
2013-10-05 18:10:43 +02:00
Joona Kiiski
77b5ee0117 Fix time parameters for blitz games
The ideal setting for super-blitz might be something like:

    "Emergency Base Time" = 50
    "Emergency Move Time" = 5

This would give a total emergency time buffer of:

    50 + 40 * 5 = 250 ms

This setup replaces the previous half cooked hack
"Don't blunder under extreme time pressure".

Test results are very good at super blitz, but keep good even
at 60 secs.

At 5+0.05
ELO: 24.30 +-2.4 (95%) LOS: 100.0%
Total: 37802 W: 10060 L: 7420 D: 20322

At 15+0.05
ELO: 13.41 +-2.9 (95%) LOS: 100.0%
Total: 22271 W: 4853 L: 3994 D: 13424

At 60+0.05
ELO: 5.30 +-3.2 (95%) LOS: 99.9%
Total: 16000 W: 2897 L: 2653 D: 10450

No functional change.
2013-09-16 09:07:47 +02:00