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

[Evan Berggren Daniel]

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.

Thanks

Evan Daniel