UCI ponder confusion

[Sven]

Harald,

you are quoting uci_send_stop() which, unlike uci_send_stop_sync() (the function being called when SyncStop is set), does _not_ wait for the next "bestmove" from the engine. In the second half you are quoting a part from the uci_parse() function that handles "bestmove" but uci_send_stop() does not do a uci_parse().

Sven

[BubbaTough]

expect that there must have been an important reason for Fabien to design PolyGlot this way.

Sven

Well, a single threaded program (one with no separate input thread) would have no problem the way it is without StopSynch. For example, if memory serves Fruit is like that. And the way it is is might be slightly faster for those programs. Not that it takes much time to send those messages usually, but if polyglot and the program are sharing a processor, depending on the priority scheme, one of them may be hogging things and significant time delay can be introduced by a protocol that requires both to interact because they may have to wait for both to get turns with the processor.

So basically, it seems like polyglot is being a bit disobedient in implementing UCI, in order to optimize for Fruit-like input processing. Which is an understandable thing for Fabien to do I guess. Nevertheless, I would prefer that the default behavior supported all programs better (assuming I am correct that polyglot has a minor glitch in its default behavior) with perhaps an option that improves performance for some programs, instead of doing it the other way around with StopSynch.

Of course, if polyglot was being disobedient to UCI, maybe it should ALLOW ME TO OFFER AND ACCEPT draws.

-Sam

[Sven]

expect that there must have been an important reason for Fabien to design PolyGlot this way.

Sven

Well, a single threaded program (one with no separate input thread) would have no problem the way it is without StopSynch. For example, if memory serves Fruit is like that. [...]

So basically, it seems like polyglot is being a bit disobedient in implementing UCI, in order to optimize for Fruit-like input processing. Which is an understandable thing for Fabien to do I guess.

Fruit 2.1 in ponder mode sends "bestmove" only after "stop" as far as I can see in the source, and I think that Fruit 2.1 does not require the StopSync setting. So maybe the root cause of the problem is somewhere else?

Now being confused myself a little bit,
Sven

[Sven]

After receiving "stop", my engine would block any further input from coming in until it prints out its "bestmove". I have an input thread, which would wait until the bestmove was sent, before calling fgets again (should be within a few milliseconds at most).

Not handling further input until after having sent its "bestmove" does not necessarily mean that the UCI side will understand correctly the meaning of the "bestmove" message it receives, i.e. that the UCI side will really discard that "bestmove" since it results from an obsolete search. As reported, Arena will, but in case of PolyGlot it depends on an option.

Sven

[BubbaTough]

TonyJH wrote:
After receiving "stop", my engine would block any further input from coming in until it prints out its "bestmove". I have an input thread, which would wait until the bestmove was sent, before calling fgets again (should be within a few milliseconds at most).

Fruit 2.1 in ponder mode sends "bestmove" only after "stop" as far as I can see in the source, and I think that Fruit 2.1 does not require the StopSync setting. So maybe the root cause of the problem is somewhere else?

Now being confused myself a little bit,
Sven
Back to top


Sven Schüle

I guess I was assuming TonyJH was right (since his program seems to work) and for some reason I don't understand (I know very little about input/output, just what I teach myself to get my darn program working) not reading the input somehow effects polyglot. But if its not really true, maybe it really is just an error in the polyglot standard implementation...just one that is so infrequently triggered by programs that react quickly enough to the stop command that it is rarely noticed.

-Sam

[Guetti]

Sounds to me like a bit a dirty approach in UCI itself. Before giving the engine new work after sending the stop command would it not be better to wait for a readyok or something from the engine?

[TonyJH]

After receiving "stop", my engine would block any further input from coming in until it prints out its "bestmove". I have an input thread, which would wait until the bestmove was sent, before calling fgets again (should be within a few milliseconds at most).

Not handling further input until after having sent its "bestmove" does not necessarily mean that the UCI side will understand correctly the meaning of the "bestmove" message it receives, i.e. that the UCI side will really discard that "bestmove" since it results from an obsolete search. As reported, Arena will, but in case of PolyGlot it depends on an option.

Sven

Ok, I could be wrong here. But in this case, I think the bestmove should always be interpreted correctly by polyglot as being from the obsolete search, because the new search request hasn't even been sent to the engine yet. Polyglot is trying to send it, but the engine isn't accepting it yet, and the engine shouldn't be buffering input.
Am I missing something or does this sound right?

[Harald Johnsen]

Harald,

you are quoting uci_send_stop() which, unlike uci_send_stop_sync() (the function being called when SyncStop is set), does _not_ wait for the next "bestmove" from the engine. In the second half you are quoting a part from the uci_parse() function that handles "bestmove" but uci_send_stop() does not do a uci_parse().

Sven

Right, but uci_parse will be called and will receive the bestmove sent by the engine some time after the engine received the stop command.

On parsing the bestmove we should have uci->searching == true and uci->pending_nb == 2, so we go to the else branch, ie the command is skiped.

HJ.

[Sven]

Harald,

you are quoting uci_send_stop() which, unlike uci_send_stop_sync() (the function being called when SyncStop is set), does _not_ wait for the next "bestmove" from the engine. In the second half you are quoting a part from the uci_parse() function that handles "bestmove" but uci_send_stop() does not do a uci_parse().

Sven

Right, but uci_parse will be called and will receive the bestmove sent by the engine some time after the engine received the stop command.

On parsing the bestmove we should have uci->searching == true and uci->pending_nb == 2, so we go to the else branch, ie the command is skiped.

HJ.

But in the meantime Polyglot may already have launched the new search, and that would cause the problems. Is this possible? Right now I can't look into the code again ...

Sven

[Sven]

Ok, I could be wrong here. But in this case, I think the bestmove should always be interpreted correctly by polyglot as being from the obsolete search, because the new search request hasn't even been sent to the engine yet. Polyglot is trying to send it, but the engine isn't accepting it yet, and the engine shouldn't be buffering input.
Am I missing something or does this sound right?

Will Polyglot block until the engine accepts input when it is "trying to send something"? If it will then you are right. Otherwise I think that Polyglot will already change its internal state such that it does not expect the next "bestmove" to belong to the obsolete ponder search.

If both sides of the pipe (I think we have a pipe here in this case, don't we?) are doing unbuffered output resp. input then maybe Polyglot will indeed block.

Sven