[gnugo-devel] cache interface

[Arend Bayer]

Sorry for this rant, but...

I think this line in get_read_result(), and the corresponding ones in
get_read_result2, have caused me more debugging troubles than any other
3 lines among the 50000 in gnugo:
[I actually don't quit remember where I had hit this before, but it was
more than once.]

int
get_read_result_hash_modified(enum routine_id routine,
                              int komaster, int kom_pos,
                              int *str, Hash_data *hashmodifier,
                              Read_result **read_result)

  /* Find the origin of the string in order to make the caching of read
   * results work better.
   */
  *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.

In this case, it bite me in the following way: Inge's new cache doesn't
do this. 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.)

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.

Once we kill the code of the old cache, my only regret will be
that the above line will continue to exist in CVS history.

Arend