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/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
