UCI pondering done right

[lucasart]

I find the UCI pondering spec truly horrible. It violate both UCI key principles, to the point that it feels like a piece of Winboard grafted on UCI:
(1) statelessness.
(2) simplicity for engine developers.

Instead, I propose a better way to handle pondering, without any change to the protocol. The advantage is that all engines will be able to ponder, even if they don't implement this ghastly UCI pondering spec.

Very simple:
* GUI knows the ponder move already, because it receives PVs from the engine. So keep the last 2nd move received as ponder move.
* go ponder is useless. Just use go infinite.
* instead of ponderhit/stop, just use stop and start a new search. if the engine was pondering the move that the opponent played, the hash table contains good info, so the new search will almost immediately resume from where it was (as hash table hits make it blaze through the low depths).

Is there a GUI that does that ?

[noobpwnftw]

I find that making pondering rely on the behavior of hash table on a new search of a different position is even more horrible.

[lucasart]

I find that making pondering rely on the behavior of hash table on a new search of a different position is even more horrible.

What do you mean by "the behavior of hash table on a new search" ?

There is only 1 possible behavior, which is to do nothing.

Unless, of course, you are debugging your engine, and you need to clear the hash table between moves, to make every search reproductible from scratch.

[jdart]

I implement both UCI and CECP (Winboard protocol) and I assure you, UCI is not nearly as horrible as CECP. I have recently stomped some race condition bugs in the latter.

--Jon

[noobpwnftw]

I find that making pondering rely on the behavior of hash table on a new search of a different position is even more horrible.

What do you mean by "the behavior of hash table on a new search" ?

There is only 1 possible behavior, which is to do nothing.

Unless, of course, you are debugging your engine, and you need to clear the hash table between moves, to make every search reproductible from scratch.

Here is how I see it:
It is stateless, because when you issue "go ponder" it means that the last move in your FEN is not on board yet, and the engine searches as if the move is made, but the engine won't stop on its time management unless either "ponderhit" or "stop" happened, when "ponderhit" kicks in the engine then enables time management again, and that means it is not as hard as you imagine to support such behavior.

Also it is important to know that the search you launched with "go ponder" explicitly told the engine to search on the position which the ponder move has been made, so it does not rely on any hash behavior to support it, which is different from "go infinite" unless you also set the position as if the ponder move is made, and then you may figure that upon a ponder hit, you lose the advantage of using time management from the engine, rather, you would make the engine launch a new search, without the information about how much time it had spent on pondering and depend on its hash table being kept across searches, in other words, more stateful.

[lucasart]

I find that making pondering rely on the behavior of hash table on a new search of a different position is even more horrible.

What do you mean by "the behavior of hash table on a new search" ?

There is only 1 possible behavior, which is to do nothing.

Unless, of course, you are debugging your engine, and you need to clear the hash table between moves, to make every search reproductible from scratch.

Here is how I see it:
It is stateless, because when you issue "go ponder" it means that the last move in your FEN is not on board yet, and the engine searches as if the move is made, but the engine won't stop on its time management unless either "ponderhit" or "stop" happened, when "ponderhit" kicks in the engine then enables time management again, and that means it is not as hard as you imagine to support such behavior.

Also it is important to know that the search you launched with "go ponder" explicitly told the engine to search on the position which the ponder move has been made, so it does not rely on any hash behavior to support it, which is different from "go infinite" unless you also set the position as if the ponder move is made, and then you may figure that upon a ponder hit, you lose the advantage of using time management from the engine, rather, you would make the engine launch a new search, without the information about how much time it had spent on pondering and depend on its hash table being kept across searches, in other words, more stateful.

You make a good point about time management.

Still that does not explain why my forced pondering mode can't be supported. There is no disadvantage: engines capable of pondering will be pondering as currently. But the advantage is that all other engines will be able to ponder (instead of not at all), and the logic needs to be coded only once in the GUI, as opposed to every single engine.

[noobpwnftw]

Of course, as a workaround you can implement such pondering solely from the GUI side without any UCI support from the engine side, just it would become more assumption driven. For engines that are no longer active in development and didn't support pondering, it seems to be a good alternative, but if one could support the feature by implementing UCI standards, I see no reason not to do it "right".

[mar]

I find the UCI pondering spec truly horrible. It violate both UCI key principles, to the point that it feels like a piece of Winboard grafted on UCI:
(1) statelessness.
(2) simplicity for engine developers.

Instead, I propose a better way to handle pondering, without any change to the protocol. The advantage is that all engines will be able to ponder, even if they don't implement this ghastly UCI pondering spec.

Very simple:
* GUI knows the ponder move already, because it receives PVs from the engine. So keep the last 2nd move received as ponder move.
* go ponder is useless. Just use go infinite.
* instead of ponderhit/stop, just use stop and start a new search. if the engine was pondering the move that the opponent played, the hash table contains good info, so the new search will almost immediately resume from where it was (as hash table hits make it blaze through the low depths).

Is there a GUI that does that ?

I don't see much of extra state. You get the position you are supposed to ponder on before go ponder, so the only real state is ponder+ponderhit flags (perhaps something more clever than that).

I don't understand how your approach should work on a simulated ponderhit wrt time management.
(what I do is I still continue to search after ponderhit until I hit the current time limit I'd otherwise allocate before the ponder search)
Do you stop the search and play the ponder move immediately? This may be too fast.
Or if you plan to continue the search after ponderhit, how do you plan to solve time management?
A workaround would be to use standard go wtime ... btime... instead of go ponder, then use go infinite when it's done, but this already seems very hacky even to me.

One thing I find dumb about UCI pondering though is having to wait for stop or ponderhit at the end of the ponder search (in cases where you finish max depth before phit/stop).

[jdart]

I don't think the spec is that complex. I have thought about making a test driver that would exercise all the various cases and verify that everything's ok. That would be a nice tool for engine authors. I am probably not going to get to that anytime soon, but it would be a nice project if someone wanted to take it on.

--Jon

[elcabesa]

The uci spec is rather simple for ponder: start a search on the move given by position command, then you shall stop if stop is received or continue and stop when you want if ponder hit is received.
It simply need an uci state machine and a searcher that are independent and not too much coupled.

Your proposal need 2 searches and it 's worst than the uci spec. It could be used for engines that doesn't support the spec correctly or very old engines that are not developed anymore.

I have seen a lot of claim against uci because it's stateless, but never because it is stateful