Re: [gnugo-devel] Parallelizing GNU Go

[Dave Denholm]

John Paul Rodman <address@hidden> writes:

> Hello,
> 
> I am taking a parallel programing class at UT Austin, and I was
> considering parallelizing GNU Go for my class project.
> 
> I have a lot of thoughts on how to go about doing this, but first I wanted
> to see what people thought of the idea in general.
> How difficult would it be?


It has been mentioned in the past...

First question is whether to address

a) multi cpu machines

b) network of single-cpu machines

c) Intel's new scheme (hyper threading..?) for scaling up single cpu.


Or are you more interested in specialist parallel architectures
(eg SIMD, MISD, vector processor, etc)

( I used to work with a transputer system (MIMD), FWIW. I have
 no idea if they are still around.)




My own opinion would be that

a) multi-cpu machines are sufficiently rare that the benefit
 is limited. A factor-of-2 speedup doesn't seem big enough
 to go after.

 
 IIRC, gnugo has various caches and many globals which have to
 be made thread safe, if a threading model is taken.


 An alternative approach on unix is to fork() a child process to investigate
 some detailed problem and report back : that way, the os gives each
 child a private copy of all the globals.
 The main process could, say, build a list of moves to consider, and
 spawn a child process to look at each one. No point having more
 active children than cpu's.

 But windows doesn't offer  a simple way to clone a process.


b) is an opportunity to scale up to a large extent, provided the
 comms overhead is not too great. ie when asking a remote machine to
 answer a question, the compute effort needs to justify the
 round-trip cost.


 And of course, (b) would also work on a multi-cpu machine : just
 run as many copies of the server process as there are cpus.


c) presumably means adding multiple threads, so the problem of
  the globals needs to be sorted out. My concern is that gnugo
  is, or would become, memory bound rather than cpu bound. But
  if hyperthreading cpu has a correspondingly larger cache, it
  might be okay.



dd
-- 
address@hidden          http://www.insignia.com