Re: [Bug-gnubg] GNUbgW speedingup50%

[Joern Thyssen]

On Fri, Jun 28, 2002 at 01:21:52PM -0400, Gary Wong wrote
> On Thu, Jun 27, 2002 at 09:09:25PM +0000, Joern Thyssen wrote:
> > (1) have a master-process that distributes a task to a slave
> >     (a task: a game in a rollout, a background analysis, a roll in a
> >     multi-ply evaluation etc etc)
> > (2) the slave does some computing, and return the result to the master
> > (3) when all tasks have been processed: "kill" the slaves
> > 
> > The advantage is that this can be implemented with many different
> > libraries (pthreads, MPI, probably beowulf libs etc), so basically the
> > same code could run on many different multi-processor platforms (both
> > SMP and distributed systems).
> 
> Yes, I think this approach is very good.  Personally I think there is
> a lot of value in keeping the model abstract enough to allow multiple
> implementations in this case, as you suggest.
> 
> Since the slaves are performing relatively simple tasks (i.e. no user
> or system interaction), there should be minimal issues regarding the
> concurrency between slaves (there will be a few, such as multiple
> slaves sharing access to one evaluation cache, but those should be
> relatively easy to spot and to deal with).

For MPI (and beowulf) there would be no problems as gnubg would run as
separate processes on each computer on the distributed system. 

For implementation with threads we would have to introduce a write lock
on the cache, or give each thread its own cache.

It may also be possible to our own message passing using the external
player interface (suitably expanded). A number of slaves start listening
to port x, x+1, x+2 etc etc. The master distributes tasks to each of the
slaves.

> If the master is allowed to run in parallel with the slaves (accepting
> new commands from the user while slaves are still running, rather than
> just waiting for all slaves to complete first), there will be far more
> scope for concern.  This sort of parallelism would be required for
> "background" auto-analysis, however.

The background analysis can be performed with threads. One way to solve
these problems would be to add a lock to all moverecords, so only one
thread at a time could write to that particular moverecord.

All processes that wants to write (and read?) a particular moverecord
would have to acquire the lock first. 

Jørn

-- 
Joern Thyssen, PhD
Vendsysselgade 3, 3., 9000 Aalborg
+45 9813 2791 (private) / +45 2077 2689 (mobile) / +45 9633 7010 (work)