Re: MPI vs PVM

["Marcelo E. Magallon" <mmagallo@debian.org>]

On Thu, Jan 09, 2003 at 03:25:54PM -0300, Rodrigo F. Baroni wrote:

 >     I have to do a choice between MPI or PVM to use to develop image
 > processing aplications .

 As you can see from the answers you've got, there's some polarization
 in this subject.  People tend to have fond memories of the first thing
 they learnt.  For many, that's PVM because PVM was designed for
 _teaching_ parallel programming concepts.  MPI on the other hand is an
 specification for message passing (Message Passing Interface).  It came
 to be at a time when porting applications from one supercomputer to
 another was a hard task because every single one used a different
 programming model for <whatever their own word for message passing
 was>.

 From the above I guess you can draw a simple conclusion on your own:
 there's exactly one PVM, but there are many things called MPI.  In
 Debian you've got LAM and MPICH.  Both of them run over TCP/IP.  Other
 MPI implementations run on shared memory, or PM or GM (read: Myrinet),
 or even on top of other message passing library.

 Which should hint another two facst: a) an MPI implementation can be
 tuned for (near) maximum performance on a given architecture; b) MPI
 buys you portability.  Most people look funny at me when I talk about
 portability across PC clusters.  "One PC cluster is the same as the
 next one, isn't it?"  No, it isn't.  The big difference is the network
 transport.  You could argue that PVM is portable across PC clusters,
 too.  The fact is that aren't TCP/IP implementations for some networks
 (e.g. Myrinet with some drivers).

 > After to do this choice and start to study a lot, could someone tell
 > me some sugestion ?  This would be very useful ..

 PVM is well documented, and so is MPI.  I'd dare say there's more
 documentation out there for MPI than for PVM.  Google for MPI tutorial
 or something along those lines, and you'll find some good
 documentation.  The last URL I've got[0] might or might not be valid, I
 don't know.
 
 One last word, if you read the MPI standard, you'll soon notice there's
 plenty of room for implementation specific details, which some vendors
 have used to their advantage, that is, a call that performs good on one
 implementation might perform poorly on another, but you have to walk
 before you run as they say.  Developing working programming experience
 with MPI is the first step.

 Oh, and yes, there's life beyond MPI.

 [0] http://pacont.ncsa.uiuc.edu:8900/Public/MPI/