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 _______________________________________________ gnugo-devel mailing list gnugo-devel@gnu.org http://lists.gnu.org/mailman/listinfo/gnugo-devel
