Time Management

[lkaufman]

I would like to ask the readers of this forum who have watched games between Stockfish and Komodo recently, whether on TCEC or anywhere else, to comment on which engine manages its time better, and whether the difference in this respect is large/obvious or not. I have an opinion on this, but I'd rather not influence your opinions by stating my own. Thank you in advance.

[jhellis3]

Just from casual observation, I would give a very small edge to SF even though it appears to have a more "naive" implementation.

This is largely due to the fact that Komodo appears to be more aggressive with reducing time spent on moves in the early phase of the game. The problem with spending less time is that often even when a time advantage has been accrued the effective available time is not significantly larger because of the same aggressive algorithm (I obviously have no idea whether or not this is the case in Komodo). Or the game is already decided one way or another (the more concrete problem).

In more abstract terms, the probability of time invested producing a return is going to be greater for earlier moves. Overall, I think Komodo has very good TM but could benefit from being slightly less aggressive.

[lkaufman]

Just from casual observation, I would give a very small edge to SF even though it appears to have a more "naive" implementation.

This is largely due to the fact that Komodo appears to be more aggressive with reducing time spent on moves in the early phase of the game. The problem with spending less time is that often even when a time advantage has been accrued the effective available time is not significantly larger because of the same aggressive algorithm (I obviously have no idea whether or not this is the case in Komodo). Or the game is already decided one way or another (the more concrete problem).

In more abstract terms, the probability of time invested producing a return is going to be greater for earlier moves. Overall, I think Komodo has very good TM but could benefit from being slightly less aggressive.

Thanks. Aside from the question of how much time to spend on early vs. late moves, do you notice any difference between them on WHICH moves in a given phase of the game get more time?

[ZirconiumX]

Just from casual observation, I would give a very small edge to SF even though it appears to have a more "naive" implementation.

This is largely due to the fact that Komodo appears to be more aggressive with reducing time spent on moves in the early phase of the game. The problem with spending less time is that often even when a time advantage has been accrued the effective available time is not significantly larger because of the same aggressive algorithm (I obviously have no idea whether or not this is the case in Komodo). Or the game is already decided one way or another (the more concrete problem).

In more abstract terms, the probability of time invested producing a return is going to be greater for earlier moves. Overall, I think Komodo has very good TM but could benefit from being slightly less aggressive.

Thanks. Aside from the question of how much time to spend on early vs. late moves, do you notice any difference between them on WHICH moves in a given phase of the game get more time?

I've always wondered how much gain there is in intelligent vs naive time control. If you're playing bullet games then there's probably no benefit to it. If you're playing TCEC, then you need to find the optimal time management.

Personally, I think the optimal time management would be normally distributed across the game (opening - not much to gain from thinking long aside from tactical shots, middlegame determines the endgame, so spend lots of time on it, endgame - not many pieces, so you search deeply pretty quickly).

JM2C.

Matthew:out

[lkaufman]

Just from casual observation, I would give a very small edge to SF even though it appears to have a more "naive" implementation.

This is largely due to the fact that Komodo appears to be more aggressive with reducing time spent on moves in the early phase of the game. The problem with spending less time is that often even when a time advantage has been accrued the effective available time is not significantly larger because of the same aggressive algorithm (I obviously have no idea whether or not this is the case in Komodo). Or the game is already decided one way or another (the more concrete problem).

In more abstract terms, the probability of time invested producing a return is going to be greater for earlier moves. Overall, I think Komodo has very good TM but could benefit from being slightly less aggressive.

Thanks. Aside from the question of how much time to spend on early vs. late moves, do you notice any difference between them on WHICH moves in a given phase of the game get more time?

I've always wondered how much gain there is in intelligent vs naive time control. If you're playing bullet games then there's probably no benefit to it. If you're playing TCEC, then you need to find the optimal time management.

Personally, I think the optimal time management would be normally distributed across the game (opening - not much to gain from thinking long aside from tactical shots, middlegame determines the endgame, so spend lots of time on it, endgame - not many pieces, so you search deeply pretty quickly).

JM2C.

Matthew:out

Regarding your first point, many people have said the opposite, that good time management is far more important in bullet chess than in slow chess. I don't see the difference; it seems to me that good time management is roughly of equal importance in bullet chess and in slow chess.
Regarding your second point, there is quite a difference of opinion among people as to whether the opening deserves more time per move, less time per move, or about the same time per move as the middlegame. I am open-minded on this question.

[ZirconiumX]

Just from casual observation, I would give a very small edge to SF even though it appears to have a more "naive" implementation.

This is largely due to the fact that Komodo appears to be more aggressive with reducing time spent on moves in the early phase of the game. The problem with spending less time is that often even when a time advantage has been accrued the effective available time is not significantly larger because of the same aggressive algorithm (I obviously have no idea whether or not this is the case in Komodo). Or the game is already decided one way or another (the more concrete problem).

In more abstract terms, the probability of time invested producing a return is going to be greater for earlier moves. Overall, I think Komodo has very good TM but could benefit from being slightly less aggressive.

Thanks. Aside from the question of how much time to spend on early vs. late moves, do you notice any difference between them on WHICH moves in a given phase of the game get more time?

I've always wondered how much gain there is in intelligent vs naive time control. If you're playing bullet games then there's probably no benefit to it. If you're playing TCEC, then you need to find the optimal time management.

Personally, I think the optimal time management would be normally distributed across the game (opening - not much to gain from thinking long aside from tactical shots, middlegame determines the endgame, so spend lots of time on it, endgame - not many pieces, so you search deeply pretty quickly).

JM2C.

Matthew:out

Regarding your first point, many people have said the opposite, that good time management is far more important in bullet chess than in slow chess. I don't see the difference; it seems to me that good time management is roughly of equal importance in bullet chess and in slow chess.
Regarding your second point, there is quite a difference of opinion among people as to whether the opening deserves more time per move, less time per move, or about the same time per move as the middlegame. I am open-minded on this question.

You tend to get more search depth from a minute of searching than 0.001 of a second searching.

BlackMamba IIRC actually allocates most of its time to the endgame IIRC, which is an interesting idea.

Matthew:out

[overlord]

Problem of almost all engines is that they spend not too much time on their first move out of book. For example: Rybka 4 was thinking approximately 9 seconds on their first move in every 5 minutes game. Sometimes it immediately got bad position. Why not to prolong this period up to 30 seconds?! Within the following moves engines are using hash so than they can play faster. In endgames deep depths can be achieved almost everytime.

[lkaufman]

You tend to get more search depth from a minute of searching than 0.001 of a second searching.

BlackMamba IIRC actually allocates most of its time to the endgame IIRC, which is an interesting idea.

Matthew:out

Your first sentence above is obviously true but not relevant. Everything in computer chess is proportional; adding say 10% to search time adds about the same fraction of a ply whether it's from 0.1" or from one hour. I don't see you point.
I'm pretty sure that spending more time in the endgame is a bad idea, since many games are pretty much decided by the endgame.

[lkaufman]

Problem of almost all engines is that they spend not too much time on their first move out of book. For example: Rybka 4 was thinking approximately 9 seconds on their first move in every 5 minutes game. Sometimes it immediately got bad position. Why not to prolong this period up to 30 seconds?! Within the following moves engines are using hash so than they can play faster. In endgames deep depths can be achieved almost everytime.

Actually my Komodo partner Mark proposed exactly the same thing for the same reason, but we failed to show a benefit from our first try at implementing it. Maybe it's just a one elo improvement, too small to measure.

[Uri Blass]

Just from casual observation, I would give a very small edge to SF even though it appears to have a more "naive" implementation.

This is largely due to the fact that Komodo appears to be more aggressive with reducing time spent on moves in the early phase of the game. The problem with spending less time is that often even when a time advantage has been accrued the effective available time is not significantly larger because of the same aggressive algorithm (I obviously have no idea whether or not this is the case in Komodo). Or the game is already decided one way or another (the more concrete problem).

In more abstract terms, the probability of time invested producing a return is going to be greater for earlier moves. Overall, I think Komodo has very good TM but could benefit from being slightly less aggressive.

Thanks. Aside from the question of how much time to spend on early vs. late moves, do you notice any difference between them on WHICH moves in a given phase of the game get more time?

I've always wondered how much gain there is in intelligent vs naive time control. If you're playing bullet games then there's probably no benefit to it. If you're playing TCEC, then you need to find the optimal time management.

Personally, I think the optimal time management would be normally distributed across the game (opening - not much to gain from thinking long aside from tactical shots, middlegame determines the endgame, so spend lots of time on it, endgame - not many pieces, so you search deeply pretty quickly).

JM2C.

Matthew:out

Your claim that there is no benfit from better time management if you play bullet is proved to be wrong because the only time control that the stockfish team use for testing is bullet and part of the improvement in stokcfish in bullet is clearly in time management.

1)Author: Uri Blass
Date: Mon Aug 26 10:29:58 2013 -0700
Timestamp: 1377538198

Time management: move faster if PV is stable

Move faster but compensate by allocating more
time when the best move changes.

Passed short TC at 15+0.05
LLR: 2.93 (-2.94,2.94)
Total: 13895 W: 3030 L: 2882 D: 798

Long TC at 60+0.05
LLR: 2.96 (-2.94,2.94)
Total: 9266 W: 1777 L: 1624 D: 5865

At time increment 30+0.5
LLR: 2.96 (-2.94,2.94)
Total: 6703 W: 1238 L: 1134 D: 4331

And at fixed game number, longer TC 120+0.05
ELO: 5.17 +-2.8 (95%) LOS: 100.0%
Total: 19306 W: 3378 L: 3091 D: 12837

bench: 4728533

2)Author: Marco Costalba
Date: Sun Sep 15 07:59:09 2013 +0200
Timestamp: 1379224749

Don't blunder under extreme time pressure

We always attempt to keep at least this emergencyBaseTime
at clock. But if available time is very low it means that
we will force ourself to play immediately to satisfy the
emergencyBaseTime constrain and so leading to blunders.

Patch is good at short and very short TC (15secs and 5secs respectively)
LLR: 2.96 (-2.94,2.94) [-1.50,4.50]
Total: 26590 W: 5426 L: 5245 D: 15919

LLR: 2.96 (-2.94,2.94) [-1.50,4.50]
Total: 5767 W: 1397 L: 1268 D: 3102

Instead seems has no influence at longer TC (60 secs)
LLR: -2.96 (-2.94,2.94) [0.00,6.00]
Total: 79862 W: 13623 L: 13339 D: 52900

So it is committed to have a broader testing but is
to be consider still EXPERIMENTAL and can be reverted
easily.

No functional change.

3)Author: Joona Kiiski
Date: Mon Sep 16 09:07:47 2013 +0200
Timestamp: 1379315267

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.

4)Author: Marco Costalba
Date: Tue Sep 17 16:32:39 2013 +0200
Timestamp: 1379428359

Increase Emergency Move Time to 10

Goes in the direction of avoiding time losses and seems
equivalent after almost 40K games at super fast TC of 10+0.05

ELO: 2.41 +-2.3 (95%) LOS: 98.1%
Total: 37222 W: 7843 L: 7585 D: 21794

No functional change.

Author: Marco Costalba
Date: Thu Sep 19 07:26:36 2013 +0200
Timestamp: 1379568396

Increase Emergency Move Time to 20

Goes in the direction of avoiding time losses and seems
equivalent after almost 40K games at super fast TC of 10+0.05

ELO: 2.61 +-2.2 (95%) LOS: 99.1%
Total: 39869 W: 8258 L: 7959 D: 23652

No functional change.

5)Author: Marco Costalba
Date: Mon Sep 23 07:59:51 2013 +0200
Timestamp: 1379915991

Final time management setup

This is an even safer setup proposed and tested
by Alexandre Meirelles.

Regression testing of 40K games at 10+0.05 show
result is stable both against current master:

ELO: -0.29 +-2.2 (95%) LOS: 39.7%
Total: 40000 W: 8010 L: 8043 D: 23947

and again original master (the one with smallest
time parameters):

ELO: 1.71 +-2.2 (95%) LOS: 93.8%
Total: 40000 W: 8325 L: 8128 D: 23547

Alexandre verified with LittleBlitzer time losses are
greately reduced with this setup:

Games Completed = 2100 of 3000 (Avg game length = 35.745 sec)

Settings = RR/128MB/15000ms+50ms/M 1000cp for 12 moves, D 150 moves/
Time = 39200 sec elapsed, 16800 sec remaining
1. Stockfish 190913 1091.5/2100 803-720-577 (L: m=313 t=1 i=0 a=406) (D: r=278 i=91 f=136 s=8 a=64) (tpm=212.5 d=14.75 nps=925427)
2. Houdini 2.0 w32 1008.5/2100 720-803-577 (L: m=250 t=299 i=0 a=254) (D: r=278 i=91 f=136 s=8 a=64) (tpm=204.1 d=12.04 nps=1326351)

No functional change.

6)Author: Uri Blass
Date: Tue Oct 8 21:24:21 2013 +0200
Timestamp: 1381260261

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

7)Author: Matthew Sullivan
Date: Sun Oct 27 08:03:58 2013 +0100
Timestamp: 1382857438

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.
8)Author: Marco Costalba
Date: Fri Nov 1 08:56:15 2013 +0100
Timestamp: 1383292575

Set timer to a fixed interval

And remove a complex (and broken) formula.

Indeed previous code was broken in case of TC with big
time increments where available_time() was too similar
to total time yielding to many time losses, so for instance:

go wtime 2600 winc 2600
info nodes 4432770 time 2601 <-- time forfeit!

maximum search time = 2530 ms
available_time = 2300 ms

For a reference and further details see:

https://groups.google.com/forum/?fromgr ... CPAvQDcm2E

Speed tested with bench disabling timer alltogheter vs timer set at
max resolution, showed we have no speed regressions both in single
core and when using all physical cores.

No functional change.
9)Author: Joona Kiiski
Date: Sat Nov 2 11:34:42 2013 +0100
Timestamp: 1383388482

Test Easy Move if no BestMoveChanges

In case we find a very good move after a
troubled start, we don't return immediately
anymore.

Tested directly at long TC where it passed:
LLR: 2.95 (-2.94,2.94) [0.00,6.00]
Total: 13910 W: 2397 L: 2228 D: 9285

bench: 7995098
10)Author: H. Felix Wittmann
Date: Wed Jan 1 12:58:10 2014 +0100
Timestamp: 1388577490

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.

Author: Marco Costalba
Date: Wed Jan 1 13:35:11 2014 +0100
Timestamp: 1388579711

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.
Author: Marco Costalba
Date: Wed Jan 1 13:43:58 2014 +0100
Timestamp: 1388580238

Simplify move_importance(): take 3

Use pow() of a negative number instead of 1/x

No functional change.
Author: H. Felix Wittmann
Date: Thu Jan 2 13:01:24 2014 +0100
Timestamp: 1388664084

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.
11)Author: Uri Blass
Date: Wed Jan 8 23:45:55 2014 +0900
Timestamp: 1389192355

Stop earlier if iteration is taking too long

If we are still at first move, without a fail-low and
current iteration is taking too long to complete then
stop the search.

Passed short TC:
LLR: 2.97 (-2.94,2.94) [-1.50,4.50]
Total: 26030 W: 4959 L: 4785 D: 16286

Long TC:
LLR: 2.95 (-2.94,2.94) [0.00,6.00]
Total: 18019 W: 2936 L: 2752 D: 12331

And performed well at 40/30
ELO: 4.33 +-2.8 (95%) LOS: 99.9%
Total: 20000 W: 3480 L: 3231 D: 13289

12)Author: Ralph Stoesser
Date: Wed Jan 8 23:57:06 2014 +0900
Timestamp: 1389193026

Retire easy move

Remove the easy move code and add the condition to
play instantly if only one legal move is available.

Verified there is no regression at 60+0.05
ELO: 0.17 +-1.9 (95%) LOS: 57.0%
Total: 40000 W: 6397 L: 6377 D: 27226

bench: 8502826

13)Author: Joona Kiiski
Date: Sun Jan 19 11:09:44 2014 +0100
Timestamp: 1390126184

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

14)Author: Leonid Pechenik
Date: Wed Feb 12 20:01:11 2014 +0100
Timestamp: 1392231671

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

15)Author: Leonid Pechenik
Date: Thu Feb 20 08:39:00 2014 +0100
Timestamp: 1392881940

Distribute part of first move time to other moves

Passed both short TC:
LLR: 2.97 (-2.94,2.94) [-1.50,4.50]
Total: 18907 W: 3475 L: 3322 D: 12110

And long TC:
LLR: 2.96 (-2.94,2.94) [0.00,6.00]
Total: 19044 W: 2997 L: 2811 D: 13236

bench: 8430785