Re: [gnugo-devel] more top-level search results

[Evan Daniel]

On Tue, 14 Sep 2004 20:48:47 -0600 (MDT), Douglas Ridgway
<address@hidden> wrote:
> > The GNU Go persistent caching should take care of some of this,
> > particularly if you use the same GNU Go process for all variations.
> > You might try increasing the size of the persistent caches and see if
> > that helps.
> 
> I did some quick tests, on a fairly early position (move 14) with topwidth
> 5, subwidths up to 5, depths up to 4, and found slight increases in run
> time going from -M 8 to -M 24, and a larger increase going to -M 96, i.e.
> no benefit from increased cache size. The same GNU Go process is used for
> all variations, and the code uses the GNU Go GTP commands gg_genmove,
> top_moves, is_legal, play, estimate_score, and undo. Might one of these
> wipe the cache, or perhaps there's just nothing useful in the cache for
> searches near that particular position? I should probably try some other
> positions too. For what kind of position should I see a big effect?

IIRC, this is the non-persistent cache (ie hashtable) which is not
used across moves; increasing its size is probably going to have the
same effect as in normal games, ie increase runtime due to decreased
data locality.

I believe you need to change the #define's in persistent.c and
recompile to change the persistent cache.

I would expect the changes to be most relevant when the position is
somewhat complex and there is a lot of reading to do, particularly if
there is more than one independent problem on the board.  That's just
my best guess, though, and I'd be interested to know what sorts of
positions are actually different.

If you want to do a bit more work, you could probably change things to
not clear the non-persistent cache by default, and then expose that to
GTP, and implement your own cache clearing policy (eg after every move
your engine makes); that might or might not help; just a random
thought.

HTH

Evan Daniel