Re: [gnugo-devel] Parallelizing GNU Go

[bump]

> This is just what I was thinking of doing.
> Here are a couple of methods I was considering for the master process to
> pick which moves to send to the child processes to evaluate.
> 1) Breadth search
> Evaluate *every* possible move from the current position.
> 2) Depth search
> Have the master process evaluate the position, and pick the 10 best
> moves, then pick the 10 best responses to each of those.

You should look at the metamachine. You have to configure
--enable-oracle before compiling then run GNU with the 
command line option --metamachine. It is a very crude
stab at global search, slow as molasses but if you have
64 processors you might be able to do something with it.

If you are going to work on this, I have some concrete
suggestions.

(1) Only the master process should purge the persistent caches,
and only after the opponent actually makes a move.

(2) Make sure that among the moves considered there are
one or two in the neighborhood of the opponent's last move,
since bad tenuki's are one of GNU's biggest chronic blunders.

I did some dreihirn experiments a la Ingo Althofer, choosing
myself among GNU Go's top 2 or three moves. Surprisingly
this did not seem to dramatically improve the strength of
the engine. I didn't try 10 moves. Point (2) should address
the tenuki problem to some extent.

(3) If a move is valued by GNU among the top ten moves
with a value of x, and a lower valued move y is selected, 
then deprecate the x move to the value y if it is proposed
again at a value around x in later move generation cycles.

Again, point (3) may be crucial if you are considering
the top 2 or 3 moves, but not if you are considering
the top ten.

Dan