Edward d'Auvergne wrote:
>> > As MPI
>> > is solely for those who are very serious and have access to
clusters,
>>
>> not true! mpi can run over ssh as well. For example lam has an ssh
>> backend and this is what i am using for testing on my computer!
>
>
> MPI can be used for grid computing but that is not what it is designed
> for and hence isn't optimal
why?
That what all the documentation I've read about MPI's limitations have
said. By quickly checking on Wikipedia
(http://en.wikipedia.org/wiki/Message_Passing_Interface), I just found
the following text:
4. Grid computing, and virtual grid computing offer MPIs way of
handling static and dynamic process management with particular 'fits'.
While it is possible for force the MPI model into working on a grid,
the idea of a fault-free, long-running virtual machine under the MPI
program is a forced on in a grid environment. Grids may want to
instantiate MPI APIs between sets of running processes, but
multi-level middleware that addresses concurrency, faults, and message
traffic are needed. Fault tolerant MPI's and Grid MPIs have been
attempted, but the original design of MPI itself impacts what can be
done.
Clearly there are problems if you expect nodes on you cluster to die
regularily then maybe not the one for you ;-) Though I haven't looked at
mpi 2 The other thing to bear in mind is that description they give here
for grid computing is considerably more sophisticated than is present in
the threads model at present (and may even be overkill)
My personal experience with the coding of the grid computing code, I
would assume that there are a number of differences. For example the
algorithm relax currently uses to handle computers of different
speeds.
This should not make a difference you just divide more finely and weight
the size of the job by computer (you can even send off the finer grained
task one at a time and then send new ones as tasks are completed... the
same way as you do in the thread code)
Grid computing is designed for a heterogeneous environment
whereas MPI is not. I'm not saying one is superior to the other but
that they have different applications in different computing
environments.
mpi can cope with a hetrogeneous environment as explained above
Cheers,
Edward
.
Anyway we don't need to worry to much on whixh implimentation is best if
we use a generic interface as proposed, swap and chnage what you use as
you need it ;-)
regards
gary
--
-------------------------------------------------------------------
Dr Gary Thompson
Astbury Centre for Structural Molecular Biology,
University of Leeds, Astbury Building,
Leeds, LS2 9JT, West-Yorkshire, UK Tel. +44-113-3433024
email: garyt@xxxxxxxxxxxxxxx Fax +44-113-2331407
-------------------------------------------------------------------
Re: r3237 - in /branches/multi_processor: multi/mpi4py_processor.py relax