Re: [gnugo-devel] evaluation and timing / was Re: gnugo-devel Digest, Vol 42, Issue 24

[alain Baeckeroot]

Le Jeudi 1 Juin 2006 20:00, kautz a écrit :
> I made a quick-and-diry timing test generating a black move at this 
> position with levels 10 to 16 - see attachment.
> I will try on with level 15 and different random seeds to see if there 
> are significant timing changes.
> 
> Some dumb questions to the developers / good go players:
> - Is this a reasonable approach in helping track this bug down? 
> (loadsgf, then genmove) Or is it necessary to replay every move to 
> update the cache states?
This seems good way. But maybe it is not a bug, just a feature of the engine
which need exponentially increasing time when level is increased.

The full replay is needed when one suspect a persistent_cache
problem, ie the "genmove" depends on the historical of the game, and give
a different answer when asked alone or with some previous moves
(http://trac.gnugo.org/gnugo/ticket/102 shows an example of this).
I guess this is an unwanted feature (bug?) in the persistent_cache, but
hopefully seem to happen not so often.

> - What would be some good moves for black in this position?
> - What are the main problems in this game state that tend to slow down 
> GNU Go?
> - Is this a typical timing-problematic position?
dragon_status =
[...]
J4: alive               yes but needs care.
F5: critical E4 D2
D4: critical E4 E4
K2: critical L2 L2
E1: critical E2 D2
F1: critical G1 G1

As far as i understand the engine, there are 5 critical dragons in the same
area SE, with lots of cutting points and this is the cause of lots of readings.
Maybe the potential ko F1-G1 causes additional trouble ?

Nothing here seems special, GNU Go is always slow at high level

> 
> I'd envision a "incremental evaluation" for GNU Go that could be 
> interrupted almost any time giving a move reflecting best knowledge so far.
> But I don't know how that could be implemented or if GNU Go's eval could 
> at least be tweaked into this direction ...
Currently the analyse is done by steps for the whole board aprroximately like:
examine_position (make_worms, make_dragons ....)
pick_already_known_potential_moves
find_additional_moves
value_everything
find_the_best_move

Your nice table shows for example that make_worms is done once at a defined
depth. Having incremental stuff (if i understand) would mean 
- make a first pass at  level N and find top_moves(N)
- while we have enough remaining time make an additional pass at level N+1

But doing an additional pass means make_worms at level N+1 etc...
Maybe the various caches will prevent re doing already computed stuff ?

One simple implementation could be in genmove.c: 
change do_genmove to do_genmove_real and write your own do_genmove with
time control and call do_genmove_real various times with various levels :)

I think for using the cache and try to reuse the readings made at a
previous level the hash should be initialised once only, like i did in 
my ugly twin patch (http://trac.gnugo.org/gnugo/ticket/104), maybe it is
unclear, don't hesitate to ask.

> I'd like some comments on this ...
> 
> happy GO - ing
>    aquarius
> 

/Alain