UCI Engine output

[Dave_N]

Hi,

I am writing a program to read the output from a UCI engine and need to know the maximum number of chars to expect. At the moment I am using 4096, can anyone confirm the best size?

[Don]

Hi,

I am writing a program to read the output from a UCI engine and need to know the maximum number of chars to expect. At the moment I am using 4096, can anyone confirm the best size?

4096 is surely very safe if you are talking about the maximum number of characters per line, but it may not be the maximum characters sent during a search. As far as I know there is no predefined limit.

[Dmitry Morozov]

If you are writing program at C++ you can use this code:

Code: Select all

std::string line;
std::getline(std::cin,line);

string "line" can be any size

[Dave_N]

Thanks, this is very useful information, is there a recommended time delay between process reads or any way of obtaining the most recent PV(s) after the engine sends "bestmove"?

[tpetzke]

It depends on the engine, in my engine the most recent PV is sent before the engine sends best move, because sending the best move is very much the last thing the engine does when it has searched a position.

Be aware that you cannot rely on always finding complete lines in the queue because in the moment you read the engine might still be in the process of sending

Thomas...

[Dave_N]

Actually, I can read stdin after the "bestmove" event and still receive the old engine output, so perhaps I can query the size of stdin to calculate the required buffer size and position to read from ... I suppose the GUI should update more than twice every second ... I am also considering a killProcess() command to shut down the engine in unresponsive situations (is this safe?) .

[Dave_N]

It depends on the engine, in my engine the most recent PV is sent before the engine sends best move, because sending the best move is very much the last thing the engine does when it has searched a position.

Be aware that you cannot rely on always finding complete lines in the queue because in the moment you read the engine might still be in the process of sending

Thomas...

Yes I appreciate this, although after "bestmove" the output is still available from stdin after a large time delay (in my tests up to 30 seconds) ...

I think if the engine has to play chess in time controls then I need to constantly poll the stdin and parse for "bestmove".

[Dave_N]

I suppose the time to look for input could depend on the clock increment ... If I have a time increment of 1/10th of a second then the engine will play optimally if I look every 1/20th of a second.

[tpetzke]

I'm not sure I understand what you mean.

The engines output will remain in the std out queue for ever if you don't read it.

How often the GUI reads the output from the engine out of the queue does not influence the engine at all.

It might be problematic for the GUI if the read interval is to big because you don't know when to stop the time for the engine and if you count your interval against the engines thinking time you might see time losses with engines that try to use the complete available time. But this is a problem of the GUI and not the engine.

In my GUI I poll every 100 ms and keep reading until the buffer is empty. This works ok, ultra fast time controls (where the interval should be shorter) are no fun to watch with a GUI anyway.

Thomas...

[ilari]

I suppose the time to look for input could depend on the clock increment ... If I have a time increment of 1/10th of a second then the engine will play optimally if I look every 1/20th of a second.

The better, simpler, more reliable and more efficient method is to forget about polling for input completely and use synchronized reads in a separate thread. That way you'll get any input instantly.