Re: [Bug-gnubg] Multiprocessing and remote processing committed to CVS

[Joern Thyssen]

On Sat, May 31, 2003 at 12:28:24PM +0200, Olivier Baur wrote
> Le samedi, 31 mai 2003, à 11:34 Europe/Paris, Joern Thyssen a écrit :
> 
> >Some ideas for improvements:
> >
> >* you can use ExternalSocket in external.c for creating the socket. It
> >  understands address/port combinations, e.g., "localhost:10000" or
> >  "127.0.0.1:10000". That is a bit more general than having a 
> >world-wide
> >  port number defined by "set pu remote port 10000". Also , it allows
> >  the user to input DNS names instead of IP addresses.
> >
> >  The inAddress in pu_info has to be replaced with a, say, char(100). I
> >  can do the necessary changes if you like!
> 
> Great news! That was on my todo list!
> 
> Please note that "set pu remote port <port>" serves two purposes:
> - on masters, it defines the remote port to connect to, so that can be 
> included in the remote host address "<host>:<port>"; I think I will 
> change its meaning to be the "default remote port" to use when no port 
> is specified in the host remote address (no ":<port>" specified);
> - on slaves, it is the TCP port on which the slave listens for incoming 
> connections

You could add a parameter to "pu slave" that indicates the port. If not
specified the default port from "set pu remote port" is used.

> >* analysis might be a future target for parallelisation: the analysis 
> >of
> >  each individual moverecord can be done independently (the notable
> >  exception being MOVE_DOUBLE/MOVE_TAKE/MOVE_DROP), thus, relatively
> >  easy to parallelise.
> 
> Hmm. I thought of parallelising evals (like, divide a n-ply eval into 
> several (n-1)-ply eval tasks), but it never occured to me to 
> parallelise analysis (which nonetheless probably is the feature I use 
> the most on gnubg!) Great idea. Parallelising the individual move 
> analysises rather than parallelising the sub-plies, is probably the 
> best way to go, both for ease of implementation and efficiency.

It's probably not worthwhile to parallelise 0-ply to 2-ply evaluations,
but it may be worthwhile for higher ply. It should be easy to
parallelise at the top ply and distribute 21 tasks to slaves. However,
then you only utilise max 21 processors. 

Another place for parallelisation is FindBestMoves and
FindnSaveBestMoves (hmm, I have an TODO item to merge FindBestMove and
FindnSaveBestMoves. No need to have basically the same code twice). 

The algorithm is roughly:

generate all moves
eval all moves on 0-ply

for ( i = 1; i < nplies; ++i )

   prune list

   loop over chosen moves
      evaluate on i-ply

This is also very easily be parallelised with:

generate all moves
eval all moves on 0-ply (not worthwhile to parallelise here!)

for ( i = 1; i < nplies; ++i )

   prune list

   if ( i > mininum plies for parallisation )
      distribute each resulting position to the slaves
   else
      loop over chosen moves
          evaluate on i-ply
      
I don't think it's worthwhile to parallelise below 1-ply. But a
complicated move with a large move filter may result in 15 moves being
analysed at 2-ply. This is certainly worthwhile to parallelise.

Jørn