[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-gnubg] GNUbgW speedingup50%

From: Joern Thyssen
Subject: Re: [Bug-gnubg] GNUbgW speedingup50%
Date: Thu, 27 Jun 2002 21:09:25 +0000
User-agent: Mutt/

On Wed, Jun 26, 2002 at 02:19:19PM +0000, Joern Thyssen wrote
> On Wed, Jun 26, 2002 at 04:15:45PM +0200, Øystein O Johansen wrote
> > 
> > > You should be careful. Perhaps we only want to start new
> > > treads at the top level, otherwise we may end up starting
> > > 441 threads for a 2-ply evaluation.
> > 
> > Yes, exactly! We want only 21 threads. I've thought about
> > this. I'm still just playing around and I'm not sure where
> > this experiment ends up.
> > 
> > > I'm looking at multi-threading rollouts. Currently I'm just
> > > playing around with pthreads.
> > 
> > Sounds like you're at the same stage as me. Multithread
> > rollout? One thread each game?
> Yes, but at most n threads (where n is a user-defined parameter,
> typically the number of processors in the computer).

I must admit I'm new to pthreads, and my parallel computing knowledge is
limited to simple message passing with MPI, so I keep thinking in these

(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).

The limitation is the message passing and probably many others.

Anyone on the list that have other or better ideas?


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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]