[gnugo-devel] Re: gnugo-devel Digest, Vol 13, Issue 5

[david doshay]

On Wednesday, December 17, 2003, at 03:32  PM, Gunnar Farneback 
<address@hidden> wrote:

> David wrote:
> > We had been using get_initial_influence in 3.2 and now use 
> > get_influence
> > in 3.4. get_initial_influence cared very much when it was called 
> > (assert
> > failure), but get_influence seems not to be so picky.
>
> Ah, you're well into the internals, then you had better know what
> you're doing. :-)

Just now we do not. But we are learning.

> > We had first put our hook for our multiprocessor code into
> > gnugo_genmove, which is almost always the path to genmove. But
> > interface/play_gtp.c calls genmove directly, missing our hook. Why did
> > you folks do that?
>
> For various historical reasons but basically the GTP interface
> accesses so many parts of the engine that using the gnugo_*
> trampolines for a few of them is pointless. Personally I consider the
> trampolines mostly useless in general, although there are differing
> opinions about that.

It sure seemed the most sensible place to put in our hooks, until we
needed a path that skipped the wrapper.
> > We just ran into our first win by resignation, which does not give us
> > a score. Has anything changed in the resign code?
>
> It certainly has. It has been implemented at all for a start. :-)
> But by default it should be turned off so I don't know why you're
> seeing resignations.

We continue to win by resignation. Just to be sure, how do we assure 
that
it is off?

> How are you doing the multiprocessing?

We use MPI for the message passing. We have written some extra code
that allows us to do things that are not built into MPI. All of the 
CPUs except
for a master node and a pool manager sit idle in a pool until needed.

> Is it entirely at the genmove()
> level? Are you able to reuse the contents of the persistent reading
> caches?

We start out parallel search paths with the whole board position and a
call to genmove or a call to our mpi_genmove depending upon which
stage of move selection or lookahead we are in. I am guessing that the
lookahead paths (no additional branching) use the persistent caches
but the moves to select the paths (right now sent to 2 CPUs with results
gathered at the master) do not. But I am not certain.

GNU Go is quite large and we keep trying to treat it as a "black box"
move generator and evaluator. It keeps sucking us in deeper.

David