bug-gnubg
[Top][All Lists]
Advanced

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

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


From: Olivier Baur
Subject: Re: [Bug-gnubg] Multiprocessing and remote processing committed to CVS
Date: Sat, 31 May 2003 12:28:24 +0200

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


* 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.

I'll have a look at the analysis functions.


-- Olivier




reply via email to

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