Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: overlapping tablebase lookup

Author: J. Wesley Cleveland

Date: 12:53:20 02/10/99

Go up one level in this thread


On February 09, 1999 at 13:41:10, Jay Scott wrote:

>
>On February 07, 1999 at 18:30:17, Robert Hyatt wrote:
>
>>... when I do a probe, I _know_ I will get a result.  So
>>the search will definitely terminate here, with win/lose/draw scores.  But I
>>can't really go on until I know which...  because of alpha/beta....
>
>In principle you could go on nondeterministically, the same way modern
>processors go on through a conditional branch before they've calculated
>whether the branch is taken.
>
>For tablebase lookups, the drill would be:
>
>- start the lookup; it'll take a while
>- predict the value you'll get back
>- keep on searching as if the predicted value were correct
>- when the lookup finishes:
>  - if the prediction was good, you're set
>  - if the prediction was wrong, you have to roll back and start over:
>    - reset the search to that node
>    - zap any bad hash entries you made along the way
>    - undo any other changes...
>
>I think this would be incredibly bug-prone. I wouldn't dare try it!
>But if you can get the code correct, it would definitely be faster.
>
>  Jay

A way to accomplish something like this would be to have to have multiple
threads to search different branches of the tree, but suspend all but 1 (or n
for n processor machines). While doing a TB access, start the next thread( at a
lower priority). When the result returns, suspend it again. When finished with a
branch, start the next thread at normal priority, and kill the current thread.
This could allow you to do useful work almost for free.



This page took 0 seconds to execute

Last modified: Thu, 15 Apr 21 08:11:13 -0700

Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.