[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [gnugo-devel] GnuGo trains NeuroGo (was: Bug report gnugo-3.3.8)

From: Evan Berggren Daniel
Subject: Re: [gnugo-devel] GnuGo trains NeuroGo (was: Bug report gnugo-3.3.8)
Date: Mon, 18 Nov 2002 11:30:20 -0500 (EST)

On Mon, 18 Nov 2002, Arend Bayer wrote:

> Markus Enzenberger wrote:
> (quite a while ago...)
> > I already set level to 0. If you say, that GnuGo was already using
> > its persistent reading cache, then there is probably not much room
> > for gaining speed.
> >
> > Right now, GnuGo does less than 3-5 examine_positions per second
> > at level 0 on my 1GHz Duron. To make a NeuroGo training possible
> > I would need at least 10-20 evaluations per second.
> In case you are still interested in doing this:
> 1. The speed-ups by Dave to accumulate_influece() should have a big
> impact on level 0. (In GNU Go since version 3.3.9.)
> 2. You should complie GNU Go with MAX_BOARD = 9 (because all our
> data structures and board loops etc. are optimized for the common case
> where the board size is really equal to MAX_BOARD).
> 3. I only now realized that GNU Go does not fully benefit from the
> persistent caching the way you are using it. What you should do is
> eliminate all calls to purge_persistent_reading_cache() and
> purge_persistent_owl_cache() (they are called during examine_position).
> And instead you should call them yourself once you make a move for real.
> The reason for this is that purge_persistent_..._cache throws out entries
> that are currently invalid, but could become valid again once you undo
> the move.

It would also make sense to increase the size of the cache a good deal
then, since your keeping more entries.  Speaking of which, I did some
tests that showed that increasing the persistent reading cache from 150
to 200 entries got about a 2% time improvement (on a game replay) but I
don't have the exact details around.

I can repeat the tests for that and the owl cache if people want detailed
numbers, but I think the change is a good idea for general use.


Evan Daniel

reply via email to

[Prev in Thread] Current Thread [Next in Thread]