Re: [gnugo-devel] large_scale_5_1.1b

[bump]

Arend wrote:

> My immediate guess (haven't checked at all) is that this is due to
> the fact that the large_scale patch uses reduced node limits, and this
> is not accounted for in the (non-persistent) cache.

I think I've confirmed this. I tried inserting a call to 
reading_cache_clear() after the call to find_large_scale_owl_attack_moves()
but before the call to find_more_owl_attack_and_defense_moves().
This causes the engine to play S17 instead of S2 in arend:9.

> Reducing the depth values (or not increasing them) in addition to reducing
> the node limit might do the trick (as the caches _do_ check for remaining
> depth). That buys horizon effects instead, of course,

and:

> Alternatively, running find_large_scale... after find_more_owl_attack...
> instead of before it might be enough. I suppose it is ok to use the
> computations done at full owl node limit when doing the reduced reading.
> It would have the added advantage of avoiding duplication of the same
> computation.

I ran the regressions that way. It actually seems to make the
engine much slower. The patch as distributed took 9676 seconds
to run the full regressions, about 5% slower. But if you switch
the order of find_large_scale_owl_attack_moves()
and find_more_owl_attack_and_defense_moves(), the full testsuite
took 12156 seconds to run. There is less breakage. (Of course
it fixes arend:9.)

Dan