Dann Corbit wrote: It was not obvious to me that this was the case.
Strange, then, that SF loses on time.
Default move overhead of SF is set at 30msecs, nevertheless it _is_ strange that SF lost on time becuase it happens only on TCEC machine so far.
For superfinal move overhead will be set at 1000msec.
It is actually strange that SF does not lose on time for you on other platforms.
The lags are almost unrelated to inaccuracy of sleep (which will respond within its stated resolution range for Sleep) but rather are caused by the lag between signalling a thread for the ready state and when it actually begins to run.
When the machine is jugged, this lag can be surprisingly substantial.
If you have every CPU on the machine pegged doing chess calculations, then thread startup time becomes less and less deterministic.
Dann Corbit wrote: What I proposed solves both issues (thousands of timer calls in one search and running over time).
The fact that is easy and obvious is irrelevant.
I do not think that doing it the way other people do it is better.
Do you realize that your solution to fix time lose is exactly equivalent (but uglier) to increase move overhead at 200 msecs?
Do you realize that your solution to reduce check time overhead fixes a non-issue?
I have only tried to explain that five times or so
And you have done so quite well. Thread unblock / schedule-to-run delay is completely unrelated to how long a thread is blocked due to any sort of sleep or anything else. And changing how often you sample the clock and how long you sleep has zero effect on this either. Once you block, the delay will happen.
