|
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-wideport 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 ofeach 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
[Prev in Thread] | Current Thread | [Next in Thread] |