michiguel wrote:Very simple: Arena steals time from the engines and it may not be the only GUI who do that in windows (Ilari said he needed to replace some libraries to avoid similar problems with cutechess in windows). I measured it and posted about it some time ago. On average, in one computer I tested Arena steals from 0.2 to 0.4 seconds / move, and for some reason, that gets much bigger when the engine is probing the hard drive. In some cases, I measured a delay of 4 seconds, but it was not so rare to see delays of 0.5 to 2 seconds. You just need one event like that once in a while, and the engine loses on time.
More specifically, I had to reimplement a class in the Qt library to make Cute Chess react to new input from an engine immediately. The problem was that Qt on Windows polls for input every x milliseconds. If x is too high, there's a lot of lag (stolen time); if it's too low, a lot of CPU cycles are wasted. That kind of compromise is not suitable for computer chess at fast time controls, so I switched from asynchronous reads (polling) to synchronous reads in a separate PipeReader thread.
It was just a wild guess that Arena's bug could also be caused by polling, but it could be something else. I'd be surprised if the Arena developers didn't know the source of the bug, but it may simply be too tedious to fix. If the design is bad enough, they may have to rewrite a lot of code.
Edmund wrote:Am I right to assume using GetProcessTimes() instead of any wall-time meassures solves the problem?
Even if the time-stealing bug could be fixed by having the GUI know exactly how much time the engines spent thinking, the lag would still be there, and testing under very fast time controls would still be too slow.
