[Top][All Lists]

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

Re: [gnugo-devel] Re: Bug report gnugo-3.3.8

From: Gunnar Farneback
Subject: Re: [gnugo-devel] Re: Bug report gnugo-3.3.8
Date: Wed, 11 Sep 2002 17:41:32 +0200
User-agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.3 Emacs/20.7 (sparc-sun-solaris2.7) (with unibyte mode)

Markus wrote:
> I already set level to 0.

I should have guessed you did.

> If you say, that GnuGo was already using its persistent reading
> cache, then there is probably not much room for gaining speed.

There are a few more things you can do.
1. Drastically reduce the value of max_nodes_connect in
2. Reduce the value of max_connect_depth2 in engine/readconnect.c
3. Make the persistent caches more aggressive in reusing read results
   by modifying the active areas computed in
   store_persistent_owl_cache() in engine/owl.c and in
   store_persistent_reading_cache() in engine/reading.c. The smaller
   the active area, the more likely the result is to be reused.

The connection limits are not yet affected by the level, but they
should be.

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

So you need a speedup of about a factor 4. But I suspect that speed
isn't everything. How much worse can you allow GNU Go to play before
it becomes useless for your purposes?


reply via email to

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