AndrewGrant wrote: ↑Sat Aug 11, 2018 3:47 amAssuming the catalyst for this is the chess.com tournament.
I've told them I won't be supporting pondering, and that they should use real cores and not hyperthreads if they want good chess.
Any particular reason you don't want to support pondering?
And isn't there any way that the engine can detect how many real cores the machine on which it is running has, and refrain from using more than that even if the option setting allows it? E.g. you could make the maximum setting of the Threads option dependent on the machine you run on. Note that 'Threads' is not a standard UCI option. You are free to have it mean whatever you want it to mean.
And isn't there any way that the engine can detect how many real cores the machine on which it is running has, and refrain from using more than that even if the option setting allows it?
jdart wrote: ↑Wed Aug 08, 2018 11:28 pm
Using cutechess-cli in UCI mode with pondering on, I see quite a few instances in the debug log where "go ponder" is immediately followed by a "ponderhit" command, with no intervening commands from cutechess or either engine.
As I understand it, this is really equivalent to a foreground (non-pondering) search because "ponderhit" is informing the engine that the predicted move was actually made, and so it is the engine's turn to move, and if it has not completed the ponder search, it should continue it but only up to a time or depth limit. Is there any reason in this case to not just send a "go" command (w/o ponder) and omit the "ponderhit"?
(I am not sure if UCI programs other than cutechess-cli have this issue).
--Jon
Looking at the log it looks like a bug in cutechess.
Normally the pattern is when cutechess sent position command to engine1 it will follow it with go ponder to same engine1.
Once it receives bestmove from engine2, it will send ponderhit or stop to engine1.
Deuterium received position command but has not received the go ponder immediately.
It seems cutechess does this if there is successive ponderhit for both engines. But perhaps the pattern,
After further log examination, cutechess will only send go ponder command if the engine will respond to isready with readyok. Also cutechess will always send isready after position command to same engine.
Cutechess' use of isready seemed abusive, it is sending isready all the time . Of course it is a design choice to completely control the engines. "If you don't give me the readyok I won't give you a go"
From uci protocol.
* isready
this is used to synchronize the engine with the GUI. When the GUI has sent a command or
multiple commands that can take some time to complete,
this command can be used to wait for the engine to be ready again or
to ping the engine to find out if it is still alive.
E.g. this should be sent after setting the path to the tablebases as this can take some time.
This command is also required once before the engine is asked to do any search
to wait for the engine to finish initializing.
This command must always be answered with "readyok" and can be sent also when the engine is calculating
in which case the engine should also immediately answer with "readyok" without stopping the search.