lkaufman wrote:bob wrote:lkaufman wrote:I would like to ask the readers of this forum who have watched games between Stockfish and Komodo recently, whether on TCEC or anywhere else, to comment on which engine manages its time better, and whether the difference in this respect is large/obvious or not. I have an opinion on this, but I'd rather not influence your opinions by stating my own. Thank you in advance.
Larry:
Don and I had some LONG offline discussions about this very idea last year. I had disliked the old "easy move" approach (move quickly for obvious moves, although defining "obvious" was always tricky) and the idea of "move slow on hard moves (where we have failed low)" is really almost a case of too little, too late.
I don't know where Don ended up, but for me, I decided to use a simple idea that was not very effective back in the old days of 8 ply searches, but which works pretty well today, namely that after any iteration where the best move does not change, the time limit is reduced, down to some lower limit that I hand-tuned with testing. Each time an iteration sees a best move change, the time is incrementally ramped up to some upper bound also hand-tuned.
This has actually proven to be pretty workable. The gain was less than 10 Elo, but it was a gain. Only oddity is that Crafty is now very inconsistent in how long it takes to make a move, but it does seem to spend more time in more appropriate places...
There are other cases I handle, but all are in Crafty's source and easy to understand with the comments...
We already have some variant of that idea in Komodo, for at least 2 years now. One question: When you speak of "the time" or "the time limit" do you mean goal time or maximum time?
A simple explanation.
I set a target time about like I always have. remaining_time / constant (which can vary if ponder=on or off, or increment/no-increment, etc). This is the ultimate goal time.
I have a difficulty factor that starts at 100%. Each iteration where the best move does not change sees difficulty reduced by 10%. To some lower bound (I think 60%). A PV change (new best move) has two cases.
(1) current difficulty < 100%. Set it back to 100% and add a 20% increment to that. For each pv change from here on in this iteration, difficulty gets bumped by 20%, up to a max of 200%.
(2) current difficult >= 100%, just add 20% of current, up to 200%.
I have an absolute time limit of 6x the normal target time that can't be exceeded, ever. The 6x might be adjusted if that would take us beyond the actual remaining time on the clock, but that seems pretty obvious.
So something like this, algebraically:
time used = T:
60%target < target < 200%target < 600% target.
T fits somewhere in that range...
Once I get to target * difficulty time used, Crafty will stop when the current iteration ends, or if we are still searching the fist move at the current iteration, assuming we have not failed low...