[Beowulf] LAM, MPICH, OpenMP?

[Robert G. Brown]

On Tue, 22 May 2007, Ruhollah Moussavi Baygi  wrote:

> Dear all at Beowulf,
>
> As a conceptual question in the realm of parallel programming, what is the
> difference between LAM/MPI, MPICH, and OpenMP? Could one say that all of
> these are something like 'different compilers'  for  'one programming
> language'?

No.  They are more like "different libraries" that share (more or less)
"one API".  In fact, that is indeed what they are.

Remember, things like sin(x) aren't part of the compiler per se,
although they may appear to be.  They are library functions.  I might
implement the actual computation of sin(x) one way, somebody else might
implement it another way -- all a user worries about is that when he or
she calls sin(x) for any float or double x, that the result is a float
or double that is equal in value to the (discretized) value of the sine
of the (discretized) argument, ideally to machine precision.

So the functions and operations defined in all of these MPIs are
implemented in different ways, but they are (supposedly) share a common
library reference, and code written for one "should" (within some
allowed leeway associated usually with interacting with the higher level
implementation framework) have the same result -- move data from one
node to another node, for example -- in a reproducible and well-defined
way.  One may do the movement more EFFICIENTLY than another, but the
final result should be the same.

Note that this is distinct from an ABI -- if they shared an ABI many
parallel programmers would be very happy because a binary compiled with
one of these (shared) libraries could be moved to a system with a
different (shared) library and it would still execute.  The API is
"almost" an ABI as it is, but it doesn't specify enough about how the
data is stored and moved, global variables and so on can be different,
so code compiled with one library in general is NOT so portable.

> My second doubt is about their ease of use as well as their efficiency AND
> their compatibility with different distros.

I'll let others with experience address this, because one part of this
question is theoretical and one is practical.  On the theoretical side,
they are all open source, all packaged, and all available or easy to
build on pretty much any linux distro.  Many distros currently have
anywhere from one to all three of them ready to install with an apt-get
or yum install straight from the primary distro support repos and their
mirrors, or installable/maintainable from auxiliary repos that one can
easily add post install.

Regarding efficiency, they are all different.  There are different
design trade-offs.  They are probably different per architecture as
well.  They have different things supported in terms of peripherals,
because another problem with the lack of an ABI is that "cluster
devices" e.g. advanced networking support tend to work only for one of
them at a time.  And they are likely to have only limited binary
compatibility across different distros depending on their library
support requirements, same as all the OTHER binaries or libraries in
linux because LINUX still lacks a coherent binary compatibility layer.
HOWEVER, it is very probable that source developed for and with LAM/MPI
under one distro can be cleanly recompiled and will just work for
LAM/MPI for any other distro that has roughly the same versioning, with
some code being less demanding and more portable than other code as one
might expect.

The binary probably won't move because of the lack of ABI, but the code
will almost certainly move to the same MPI on different distros without
porting, and will move to different MPIs with only fairly minimal
tweaking in a lot of cases (again depending on how much one uses calls
that aren't in the API, if any).

Is that clear enough?

The PRACTICAL side of things is that everything I just said can still be
true or false because of bugs, per specific release per specific
distributions per specific MPI program.  YMMV.  Caveat Emptor.  Don't
say I didn't warn you.  Others may have anecdotes of just where the
sleeping dog bit them.  However, there are plenty of anecdotes where it
didn't, so don't be discouraged.

    rgb

>
> Thanks for any coming guidance and explanations
>
>

-- 
Robert G. Brown	                       http://www.phy.duke.edu/~rgb/
Duke University Dept. of Physics, Box 90305
Durham, N.C. 27708-0305
Phone: 1-919-660-2567  Fax: 919-660-2525     email:rgb at phy.duke.edu