Where to put timeout() code in search?

[smcracraft]

Hi,

I've never been very satisfied with where
I put my timeout() code in search nor what
to return and at what point.

What is optimal (if that makes any sense)?

Thanks ahead,

Stuart

[hgm]

What exactly do you mean by 'timeout code'?

I have two parts:
One that reads the timer, and sets a flag if we have run out of time, and a second, that checks the flag and forces a return from the current node.

The first I have at the entry of Search(), the second in the loop over moves, between the return from the recursive call to Search() (and UnMake(), of course), and the usage of the score.

[bob]

mine is right at the top of Search(). And when time runs out, I set a global flag that says "do not use any scores returned by search from here on, as the search is "unwinding" and the values are all incomplete except for the score already returned to the root.

[smcracraft]

Bob, can you point me at a section of code in Crafty where the
old score is returned since the timeout was previously set?

My search is *ok* with fixed depth but abysmal with time. It is
in need of serious remediation.

--Stuart

[smcracraft]

Bob, I took a look at search.c and time.c from Crafty 20.9
and have a question.

When the shared->abort is set, the value returned is zero.

Why wouldn't it be alpha?

How do you avoid all timeouts returning a "draw code"?

--Stuart

[jswaff]

Bob, I took a look at search.c and time.c from Crafty 20.9
and have a question.

When the shared->abort is set, the value returned is zero.

Why wouldn't it be alpha?

How do you avoid all timeouts returning a "draw code"?

--Stuart

The returned value doesn't matter, because it won't be used. Every time you return from a search, just check the "abort" flag before doing any more processing (well, unmake your move first). If it's set, keep "returning back up" until the search unwinds all the way to the iterative loop. *Never* update the pv if this flag is set.

Eventually (well, very quickly) the search will unwind all the way to the iterative loop. After returning from the root search, if that flag is set, break out of the iterative loop and play the best move you've found so far.

Note you may have processed a few moves in an iteration before time expires. Say the second move returned a result that looked better than the
first move (which is the head of the PV of the last iteration). That's fine, as long as the second move was completely processed before time expired, it's safe to play that move.

--
James

[wgarvin]

Instead of returning up the chain you could use setjmp/longjmp, if you are able to clean up any temporary data structures used by search (repetition hash table or w/e).

[bob]

Bob, can you point me at a section of code in Crafty where the
old score is returned since the timeout was previously set?

My search is *ok* with fixed depth but abysmal with time. It is
in need of serious remediation.

--Stuart

When I back up something to the root, it is saved in the "triangular array" stuff. Once the abort flag is set, the triangular move array is never touched again. This leaves either the best score from the previous iteration if I have not yet had time to find a best move in this iteration, or else the best move from this iteration has already been backed up to ply 1 and that is what is actually played.

It isn't a matter of choosing what to do when time runs out, it is a matter of choosing to do nothing else that affects the backed up move and score once that happens... you just have to unwind the recursive calls to get back there.

[bob]

because once abort is set, the value being returned in meaningless as it doesn't get saved anywhere...

[bob]

Instead of returning up the chain you could use setjmp/longjmp, if you are able to clean up any temporary data structures used by search (repetition hash table or w/e).

You could, but it isn't SMP safe, and time is not critical. An extra few microseconds unwinding a call stack won't be noticed..