Where to put timeout() code in search?

[jswaff]

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).

Argh. That sounds really ugly to me (no offense). To my simple mind - if you enter a function, you must exit the function. Things stay nice and clean that way. Besides, the time it takes to return up the call stack is just about nil.

--
James

[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

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 - thanks. This is the remark that fired the right neuron:

"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. "

So I put this at my pv code in two places (in search() and
quiesce()):

Code: Select all

      if (!timeout())
        {
          pv[pg->ply][pg->ply] = move->m;
          for &#40;i = pg->ply + 1; i < pv_length&#91;pg->ply + 1&#93;; ++i&#41;
            pv&#91;pg->ply&#93;&#91;i&#93; = pv&#91;pg->ply + 1&#93;&#91;i&#93;;
          pv_length&#91;pg->ply&#93; = pv_length&#91;pg->ply + 1&#93;;
        &#125;

The post-change testing (a few sample games and testsuite)
came out rather well. More testing follows...

Note to self: in the timeout() routine, the total nodes
searched is sampled at an occasional basis as to whether to do
the appropriate system call (infrequently) to avoid the system
overhead... of course

Stuart

[Harald]

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).

I throw an exception to return to the main loop, but I don't know if this
is slower than the normal abort check in the search and whether it
is multi threading safe.

Harald

[Peter Fendrich]

Thank you Bob!

I was sitting with my sketchblock trying to find out what I have to do in order to introduce search threads into Alaric and this didn't occur to me.

I use setjmp/longjmp and you probably saved me a couple of hours debugging

/Peter

[bob]

Thank you Bob!

I was sitting with my sketchblock trying to find out what I have to do in order to introduce search threads into Alaric and this didn't occur to me.

I use setjmp/longjmp and you probably saved me a couple of hours debugging

/Peter

I used it very early in the Crafty development cycle, but once I knew I was going to "go parallel" at some point in time, after noticing the "not thread safe" comment in the man page, I removed it and went to the current unwind approach.