mar wrote:Of course it shouldn't matter to abort the search and restart, you would get lots of TT hits anyway. But unless you plan to do something really clever like readjusting time allocation at that point i see absolutely no reason to abort. In fact I think that continuing the search in easier to implement anyway.
Again this will only work if you do pondering right (you don't have to worry about that if you use uci).
If not then you're actually doing the same search your opponent does and in that case you cannot continue and must abort anyway (because it's not your turn
Some engines do that and I confess I have done that in my previous engine too. This only fills up hash table but you don't save any time that way.
I see no reason to do any time allocation when starting to ponder, since the engine's clock from the external view is not running, just as in a game of human players where you analyze the position while it is the opponent's move.
Also I strongly believe that restarting the search from the root is certainly easier and safer to be implemented. When starting in the state where an engine has no pondering support at all, you can add pondering in a very simple way, without considering many different cases and without getting headache. There would be zero changes to the existing search code, apart from letting a central function that decides about signalling a timeout now return false in case the search is in "pondering mode", and from supporting a way to stop the search caused by a move made by the opponent.
I see pondering as an analysis effort that helps to improve an engine's playing strength by using resources that are available while its external clock is not running. Seeing it that way, there would be almost no difference between a "ponderhit" and a "pondermiss", both just terminate the pondering, which results in another simplification of the code at other places. Perhaps the only difference might arise from applying a different time allocation strategy after a ponderhit, I'll come back to that point further down.
It has already been made clear that doing as I proposed definitely requires a working hash table, since the improved hash table contents is the only information that the engine would keep from the whole pondering when it starts over.
Re: time control, Harm-Geert has correctly pointed out what my intention was, but I have even an extended view of it. Let's stick to his first example: 20 sec remaining on the external clock, with two moves left to make. Pondering for 19 sec, now you get the ponderhit. Without any pondering involved you would perhaps have allocated 9.5 sec for each of the two moves, leaving some buffer of 1.0 sec, that makes 2 * 9.5 + 1.0 = 20. Now why is it so obvious to assign significantly less than 9.5 seconds now in case of that ponderhit? Using 9.5 seconds from now on, where a tiny fraction is necessary to get back via TT access to the point where ponder search stopped, means that in the end you will have spent 28.5 seconds while your external clock was running for 9.5 seconds only. And you still have the other 9.5 seconds for the second move, where it is still possible to get the opportunity of a ponderhit, too.
Different models of time control are possible, of course, in case of a ponderhit. You might also use less than 9.5 seconds but more than 1.0, something in the middle, with the idea in mind that you want to take advantage of the ponderhit also by producing a faster response, not only by filling the hash table with relevant data. The faster response also helps to reduce the availability of pondering resources for the opponent, that is certainly true. But it might create some kind of imbalance in an engine's time utilization since without pondering, and assuming absence of any exceptional circumstances, each of the remaining moves would usually get assigned approximately the same amount of time on the
external clock. It is a trade-off, either you prefer a quick response and more time for the next moves, or you prefer to use the "gift" of the ponderhit and search the current move a lot deeper
right now. A dynamic decision about that seems to be the appropriate way.
Considering again the classical way of "twisting" a pondering implementation into the search, I don't say that this is inherently more complex and error-prone than the "starting over" approach in all cases. I only say it depends on the actual implementation, and I know some where understanding how and why the pondering code works can produce some headache at least.
Sven
