Re: [gnugo-devel] cache interface

[Inge Wallin]

On Sun, 11 Apr 2004, Arend Bayer wrote:
>   *str = find_origin(*str);   <===============
>
> It is an understandable optimization, but it changes the variable
> somewhat behind the back of the calling function, and is thus an
> interface with bad style.

I think you are right in saying that the interface is bad, since it
changes the variable through the pointer.  The optimization as such,
though, is correct.  We want to cache the result of an attack or defense
of a string, not of a certain stone within the string.

>
> In this case, it bite me in the following way: Inge's new cache doesn't
> do this.

That is definitely a bug.  It should do it.

>Trying to track down a 2% increase in reading nodes by
> switching connection and semeai reading to the new cache, I finally
> looked at the call graph for connection.tst, and found a siginificant
> increase of activity by spread_connection_distances (without being
> called more often). Turns out that the "we have reached the
> target"-optimization there only works, due to Paul's patch there
> a while ago, if this target is given as the origin of a string, not
> any stone of it. (target is here "the other string" if we compute
> connection distances from one of the two strings.)

I was wondering myself why I got an increase in the reading nodes.  Good
work!

> But of course it is a very bad idea anyway to rely on the caching to make
> sure the target is normalized to point to the origin, e.g. as the
> optimization should still work beyond the depth where we do caching.

I am split here.  On one hand I think that the normalization is necessary,
so I think you are wrong.  On the other hand I think that maybe the
caching code is not the correct place to do it.  On the third hand it is a
catch-all of forgotten normalizations so I still think it should be kept,
or in this case, inserted.

        -Inge