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?
UCI Engine output
Moderators: hgm, Rebel, chrisw
-
- Posts: 5106
- Joined: Tue Apr 29, 2008 4:27 pm
Re: UCI Engine output
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.Dave_N wrote: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?
-
- Posts: 5
- Joined: Mon Oct 03, 2011 4:15 pm
Re: UCI Engine output
If you are writing program at C++ you can use this code:
string "line" can be any size
Code: Select all
std::string line;
std::getline(std::cin,line);
-
- Posts: 153
- Joined: Fri Sep 30, 2011 7:48 am
Re: UCI Engine output
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"?
-
- Posts: 686
- Joined: Thu Mar 03, 2011 4:57 pm
- Location: Germany
Re: UCI Engine output
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...
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...
-
- Posts: 153
- Joined: Fri Sep 30, 2011 7:48 am
Re: UCI Engine output
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?) .
-
- Posts: 153
- Joined: Fri Sep 30, 2011 7:48 am
Re: UCI Engine output
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) ...tpetzke wrote: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...
I think if the engine has to play chess in time controls then I need to constantly poll the stdin and parse for "bestmove".
Last edited by Dave_N on Fri Oct 07, 2011 9:55 am, edited 1 time in total.
-
- Posts: 153
- Joined: Fri Sep 30, 2011 7:48 am
Re: UCI Engine output
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.
-
- Posts: 686
- Joined: Thu Mar 03, 2011 4:57 pm
- Location: Germany
Re: UCI Engine output
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...
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...
-
- Posts: 750
- Joined: Mon Mar 27, 2006 7:45 pm
- Location: Finland
Re: UCI Engine output
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.Dave_N wrote: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.