Newsgroups: comp.parallel.mpi From: jlebak@ll.mit.edu (James Lebak) Subject: Re: MPI vs. shmem Organization: MIT Lincoln Laboratory Date: Tue, 31 Mar 1998 08:16:43 -0500 Message-ID: Hi Tom, In article <351FDB7B.41C67EA6@ucsd.edu>, Tom Impelluso wrote: > I would like to state that it is better to code in that > native message passing, shmem, for this reason: > > By learning shmem: > 1) My code runs faster than using MPI; > 2) I learned a great deal more about how the machine works; > 3) I had quite a bit more fun; > 4) Likely, it will be easier to learn other native message > passing from other libraries, because I spent the time > with shmem. If one is only implementing an application to run on a single platform and is interested in the best performance possible, it does make sense to use the native libraries (if they exist). The primary reasons to use MPI are (1) in many cases that's all the platform provides and (2) one may wish to port to some other platform eventually. > The argument one could make is that MPI is a standard and shmem > is only for Cray. > > However, I could respond that by taking time to learn shmem, > I gained an intuitive feel for message passing which could make > learning the native libraries for other architectures easier. That wasn't my experience. The various vendors really did manage to come up with libraries which, while not totally incompatible, were sufficiently different in subtle ways to make coding difficult. Notice I said "coding" not programming. You can get an "intuitive feel" for message passing programming from either SHMEM or MPI: the concepts invovled are very similar, and you're right that they will apply to most other libraries. But the details of writing the message-passing code under the different libraries can get extremely tedious. > If I code well, it should not really take that much time to > port over, right? Yes. I was able to do this in the work I did for my Ph.D thesis, and eventually I was able to port between the Paragon and the SP2 rather easily. However, it's not something that's easy to design until you've written code for each platform that you plan to port to. It's much easier to start from an MPI implementation of your code. > And besides... > Basically, I want to do SIMPLE parallelization... > I am not sure if creating process groups is really necessary > (this could be the cause of my ignorance... maybe some people > are doing work with process groups, and that could be the place > where using just shmem could be a liability which MPI overcomes) Process groups are very important for a MIMD or a pipelined style application, where one group works on one stage of the problem while another group works on a different stage. As you guessed, SHMEM does make this style of programming very difficult, because of the restrictions on stride between processors in the group communication operations. > Continuing.. > > Yes, MPI is a standard (and, by the way, my argument will hold > for any "global" library, not just MPI), but eventually all standards > will pass on... Yes? no? So, why not spend the time w/ the native > stuff. Standards may pass on, but vendors do too. I think MPI has probably already outlived some of the vendors who took part in the original initiative ... and the "native" message-passing libraries from those vendors are probably not in use anywhere else. So I would argue that MPI is actually a better investment of someone's learning time. > Could people share their thoughts about this? > Again, this is not meant to bait or flame, so please do not be > hostile. Hopefully nothing that I wrote above will be taken that way. -- James Lebak jlebak@ll.mit.edu