Martin on the SF loss on time

Discussion of anything and everything relating to chess playing software and machines.

Moderators: hgm, Rebel, chrisw

User avatar
Eelco de Groot
Posts: 4561
Joined: Sun Mar 12, 2006 2:40 am
Full name:   

Re: Martin on the SF loss on time

Post by Eelco de Groot »

There is no time for a real time fix, at least, Joona does not have the time and he wrote this version, so he would be the best person and he may be the only one who really understands his code. But he also made a mistake he said, in the old time code there was a little reserve that Stockfish would always try to keep, handy for move lag on a server etc, or time for an operator. He thought that 'minimal thinking time' still did that and that was my interpretation too just looking at the names. So maybe it had better been called something else. It is just 80 miliseconds extra that you need, and if Stockfish spends 80 miliseconds more than the engine anticipated and still made the time control (the reserve time ensures that), Stockfish would with the reserve time in place in the code, at least start to play faster to build up the reserve a bit, because it was now 80 miliseconds too low. But increasing 'move overhead' should be enough and serve a similar purpose, and that is just a UCI parameter. Joona already asked Martin if the parameters could be set at higher values but it was not allowed halfway. They were at very silly low levels, optimized for Fishtest and that came together with an unusual slowdown in Lazy SMP shutting down all threads on Martin's machine.

'Easy move' seems to have had problems too but that really does not matter in my opinion, even in a 'ponder on' match it is largely cosmetic. I am exaggerating and probably not precise enough, but that is my "kitchen table" interpretation of things, I have not followed the real discussions though.
Debugging is twice as hard as writing the code in the first
place. Therefore, if you write the code as cleverly as possible, you
are, by definition, not smart enough to debug it.
-- Brian W. Kernighan