Hi Michael!
Michael Yee wrote:I noticed something strange while trying to benchmark/compare your old cygwin build and Dann's new build.
Do you have any numbers? It would be interesting to see how much faster Dann's build is.
It appears that Dann's windows build doesn't respond to "stop" during infinite analysis when run from the commandline, even though it seems to work fine under arena. In fact, in arena's engine debug, you can clearly see glaurung responding to "stop".
Here are the steps I used:
uci
position startpos
go infinite
(wait until depth 12 or so)
stop
But ultimately I just had to kill the program since it wouldn't stop.
Interestingly, I observed similar behavior when compiling fruit with a couple windows compilers (mingw, vctoolkit). Fruit also wouldn't respond to "stop" from the commandline.
Any thoughts? Maybe I'm just misunderstanding the UCI protocol?
Very strange. You are not misunderstanding the UCI protocol, the engine is really supposed to stop thinking immediately when receiving the 'stop' command. The Linux and Mac OS X versions of Glaurung do respond to the 'stop' command when running from the command line, and if I understand you correctly the Cygwin executable for Windows also does. This makes me believe that the behaviour you observed is caused by the different code used for input polling during the search in Dann's compile. The OS X, Linux and Cygwin executables uses the select() function for polling, and this function does not exist in Windows (IIRC). Dann has therefore replaced my polling code with some Windows-specific code which I don't understand at all in his Glaurung binary. Perhaps this Windows-specific code for some reason behaves differently when running from the command line than when running from a GUI like Arena.
This is nothing more than a guess, however, and it is very possible that I am entirely wrong. I think we need an explanation from someone with greater Windows expertize before we can say something definite about the strange behaviour you observe.
Tord