[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [gnugo-devel] parallel GNU Go (was: TODO revisions)
From: |
Alain Baeckeroot |
Subject: |
Re: [gnugo-devel] parallel GNU Go (was: TODO revisions) |
Date: |
Mon, 13 Sep 2004 14:32:49 +0200 |
User-agent: |
KMail/1.6.2 |
Le mardi 7 Septembre 2004 04:42, David G Doshay a écrit :
> On Sep 6, 2004, at 10:38 AM, Arend Bayer wrote:
>
> > On Wed, 25 Aug 2004, David G Doshay wrote:
> >
> >> As per my previous offer, if anyone wants to think about how to
> >> parallelize the engine we may be able to offer part of our cluster
> >> for testing and development. We are open to suggestions and
> >> proposals.
> >
Hello gnugo world
Thanks for the nice program.
I m a rather weak go player (6k) and i just discover gnugo code, but i
am interested in parrallel/cluster code, i practiced some years ago
for fluid dynamics (2d + time like gnugo :). I ll soon have a dual-CPU available
for testing, and i plan to put on a tiny 3 machines mosix-cluster for testing :)
My approach is a physicist point of view:
- a 2D phenomenon (on 19x19 grid) so maybe we can parralelise on space
- time dependant (and time constraint).
- very small data to transmit, (less than 500 moves)
I think that some changes (not necessarily big) are needed:
- on time use
- on threads (spacial threads or functionals threads?)
For the moment i just dicover the code, but i noticed few points concerning
parrallelization:
- My first idea is that the go programmers should take care of go, and let the
Operating System do the job (multi thread, SMP or NUMA or cluster or
grid-computing ...)
But i know that a code doesn't behave well on multiCPU machines if it wasn't
written
for that !
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.
- Thinking during opponent time (it is in TODO :)
This is probably linked to the persistent cache of analysis,( i read something
on that).
- 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.
- 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.
- 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.
Well , maybe my mail is a bit confused for the moment, but if i can help ...
Regards
Alain