Regarding UCI Pondering

[mkchan]

Assume engine will think for `t` time every move, it is the engine to play and engine is white
What I implemented is:

Code: Select all

engine<position....
engine<go wtime x btime y

&#91;engine thinks&#93;

engine>bestmove abc ponder xyz

engine<position .... moves .... xyz
engine<go ponder wtime x-t btime y-t

&#91;engine ponders&#93;

&#91;user plays expected move&#93;

engine<ponderhit

&#91;engine think for t more time&#93; (*)

engine>bestmove .. ponder ...

From what I understand from posts like this and Stockfish, at (*), they seem to check how much time has passed after they began pondering (say Tp). If (Tp >= t), they immediately stop and play. Otherwise they think until the same condition.
On the other hand, I'm actually starting to countdown time only _after_ i get ponderhit.
The way I am doing it seems to use the pondering time as extra time for the move while the way others are doing it seems to use it as a kind of buffer for the time spent searching for the current move thereby saving time for the rest of the game.
Any thoughts as to why one should prefer one approach over the other or even if there is any reason to show preference?

[syzygy]

After the opponent has played a move, the engine allocates time for calculating its next move, i.e. for searching the position after the opponent's move.

In case of a ponderhit, the engine has already been searching that very position for some time, so it seems to make sense to deduct that time from the allocated thinking time. The time saved can then be spent on future moves.

I think most engines allocate more time for each move in ponder mode, so the time saved is effectively spread out over all moves.

Other approaches are of course possible.

[hgm]

The point is that the quality of the moves only grows logarithmically with the thinking duration (about 50 Elo per doubling). So when you think unequally long on the various moves, the moves on which you think short lose more strength than the moves on which you thought longer have gained. E.g. for one move on which you think double the nominal time (and gain 50 Elo), you would need to half the time on two other moves to make up for it (which then both lose 50 Elo). So on average you lose -50/3 = 16 Elo compared to dividing up the time equally.

This is why it is sub-optimal to assign the time you gained because of a ponder hit just to the single move for which you happened to get the hit. It is better to divide the gained time equally over all moves that still have to follow.

Because you anticipate a certain amount of useful ponder time, you could increase the nominal time per move by a factor 1.5 or so compared to when you are not pondering.

[mkchan]

Thanks for the explanation HGM, that makes a lot of sense

[Nordlandia]

Do game duration in time increase as caused by ponder itself?

Or individual allocated time will be used more efficiently, like increased frequency of hash moves saves of lot of time than otherwice wasted (without ponder).

[syzygy]

Do game duration in time increase as caused by ponder itself?

With or without ponder, an engine would be stupid not to use the time it gets. In particular, there is no excuse for losing a game with (plenty) time left on the clock.