Re: [gnugo-devel] parallel GNU Go (was: TODO revisions)

[Gunnar Farnebäck]

> My approach is a physicist point of view:
> - a 2D phenomenon (on 19x19 grid)  so maybe we can parralelise on space

I doubt it would be useful. At the very least it would require a
radically different design of the algorithms.

> - time dependant (and time constraint).

Well, yes, but it seems to me that the concept of time is
substantially different from applications in physics.

> - very small data to transmit, (less than 500 moves)

Are you thinking strictly of the moves actually being played in a
game. I'm unsure how relevant that number is in this context.

> I noticed some points which AFAIK show problems in the code:
> - The code seems to be one big function, and not at all multi thread.

I don't know what you mean with one big function but I can confirm
that it's single-threaded.

The reasons why it's not (yet) multi-threaded are primarily code
complexity and a presumed loss of speed (due to overhead) on
single-processor machines. 

> - Thinking during opponent time (it is in TODO :)
>  This is probably linked to the persistent cache of analysis,( i read 
> something on that).

Populating the persistent cache with read results which are thought to
be likely to become useful would be a natural way to use the
opponent's time, yes.

> - gnugo wastes a lot of time: on 9x9 it take less than 30seconds of thinking.
>  At least the time manger should use all (90%) of the available time, and do 
> deeper
>  reading if necessary.

There are already options to do deeper reading and adjust with respect
to available time. They are not enabled by default, however.

> - Naive intuition says that the code should size well on a 361 CPU, but it 
> is probably not the case. I have not understood how things are managed in 
> gnugo
> but i think at least there could be one thread per color, one thread per 
> connected-group, 
> or one thread per potential move.

A farm of threads to independently do the more complex forms of
reading is probably most interesting.

> - Analysis is  not symetrical : Gnugo is stronger in attack than in defense 
> (gnugo 3.4 on 7x7 it kills itself in 10 seconds :)
>  I think that means that when Black tries to defend, it doesn't considers the 
> White attacks, at least
> with the same depth of reading. I thought that gnugo was playing both B and W 
> for its own analysis, it 
> doesnt seem to be the case.

I don't see how your conclusions follow from your observations. Of
course GNU Go plays moves for both colors in its analysis, but it
doesn't do an exhaustive search of all possibilities and if there
happens to be more mistakes in the generation of defense moves than in
the generation of attack moves, it doesn't seem surprising if a group
dies even if it shouldn't. 

/Gunnar