On 3/29/07, Gary S. Thompson <garyt@xxxxxxxxxxxxxxx> wrote:
garyt@xxxxxxxxxxxxxxx wrote:
> Author: varioustoxins
> Date: Thu Mar 29 11:45:22 2007
> New Revision: 3243
>
> URL: http://svn.gna.org/viewcvs/relax?rev=3243&view=rev
> Log:
> First fully working multi branch with both uniprocessor and mpi4py support
> communication overhead for 18 residues (test_short.py from chris) with
> in memory io ~25%
>
Modified:
branches/multi_processor/multi/mpi4py_processor.py
branches/multi_processor/multi/uni_processor.py
branches/multi_processor/prompt/interpreter.py
branches/multi_processor/relax
branches/multi_processor/specific_fns/model_free.py
as alluded to in the commit message with a fairly simple implimentation
(each minimisation instance is sent off separately) I see an overhead of
~25% with with a small data set of 18 residues. I don't think this will
improve with the current implimentation as there are too many messages,
however, I do intend to increase the chunk size of the communication
(multiple minimises per message) as one of the next steps and see what
the results are.
That should decrease the communication overhead. How did you
determine the percentage overhead value? And which model-free model
was/were optimised?
One other comment is that I have had to alter prompt/interpreter.py
because it was exiting too early
# Quit.
- if quit:
- sys.exit()
+ # FIXME: need to drop off end of interpreter loop to exit cleanly
+ #if quit:
+ # sys.exit()
I can't see a problem with it returning rather than quitting but obviously am ope to counter claims
I really cannot for the life of me remember why I put that exit
statement there (that was so long ago). Oh well, debugging should
pick up any problems. On the topic of debugging, if you would like to
port the unit test code from the 1.3 line into your branch so you can
write unit tests for the code, the svnmerge program/script distributed
with Subversion will help a lot.
Overall I am very happy with the current results and feel that the level of change to the main relax code base is very small and that the code is relativley portable and well defined
That did touch very little of the model-free specific code base. One
question I have is will there be a separate model-free minimise()
function for normal and MPI operation? Another point is that I can't
run the code in the branch without having MPI up and running.
obviously there is consdiderable code cleanup and documentation still to be done and also implimentation of processors for threading and ssh tunnels
The code is shaping up nicely. With a good clean up it should be
relatively easy to port to the 1.3 line later on. It looks like a
great framework for the threading and grid computing via ssh tunnels.
Cheers,
Edward
Re: r3243 - in /branches/multi_processor: ./ multi/ prompt/ specific_fns/