Open MPI logo

Open MPI User's Mailing List Archives

  |   Home   |   Support   |   FAQ   |   all Open MPI User's mailing list

From: Jeff Squyres (jsquyres_at_[hidden])
Date: 2005-03-22 10:46:28

I have tried to reply to Greg's answer to my long-winded prior post
about my thoughts on an MPI ABI
(, but I
simply have not had the time to compose a suitably-detailed/precise

Instead, I would like to propose an alternative to an MPI ABI.

Create a new software project (preferably open source, preferably with
an BSD-like license so that ISV's can incorporate this software into
their products) that provides a compatibility layer for all the
different MPI implementations out there. Let's call it MorphMPI. It
would contain the following main components:

1. its own mpi.h / mpif.h
2. its own wrapper compilers (mpicc et al.)
3. its own library (perhaps named libmpi.*)

mpi.h contains all the normal mpi.h things (prototypes for all the MPI
and PMPI functions, declarations of all the MPI constants, etc.), and
then potentially a remapping from MPI functions to MorphMPI functions
(e.g., "#define MPI_Send morph_mpi.mpi_send", where morph_mpi is a
struct full of function pointers).

The wrapper compilers do the standard wrapper compiler things, enabling
finding mpi.h / mpif.h, automatically finding and linking to MorphMPI's
library(ies), etc.

The library is where the bulk of the work will be. In MorphMPI's
equivalent to MPI_INIT (perhaps named Morph_MPI_Init()), it dlopen's a
back-end MPI implementation and sets oodles of internal tables to point
to the back-end MPI functions and constants. For example,
morph_mpi.mpi_send is set equal to the result of a dlsym to find the
symbol for "MPI_Send".

Morph_MPI_Init() can do some clever / user friendly things to pick
which back-end MPI to dlopen, what dependent libraries also need to be
dlopen'ed, etc. This can be arbitrarily feature-ized.

There's still some technical issues to solve, but an industrious
developer can figure them out. For example, how to handle MPI
compile-time constants (e.g., "MPI_Comm mycomm = MPI_COMM_WORLD;")?
One possible solution is to have MorphMPI have a wrapper function for
each MPI function (e.g., "#define MPI_Send Morph_MPI_Send"). The
wrapper function does a translation of the MorphMPI MPI handles to the
back-end MPI handles. If MorphMPI's handles are integers, this can be
relatively straightforward, something along the lines of:

int Morph_MPI_Send(...dtype, ..., comm) {
   return morph_mpi.mpi_send(..., Morph_MPI_datatypes[dtype], ...,

You get the idea.

There's a slight performance penalty for the translation layer, but for
those who want an MPI ABI, this might well be an acceptable price to


Of course, such a compatibility layer doesn't have to be *exactly* like
this. I simply proposed one possible implementation -- there's several
other, similar ways to do it. S/He who implements, wins. :-)

The main ideas of this proposal are:

1. A 3rd party project can provide MPI ABI-like functionality (with all
the benefits and drawbacks therein)

2. Cancel the MPI Implementor's Ultimate Prize Fighting Cage Match on
pay-per-view (read: no need for time-consuming, potentially fruitless
attempts to get MPI implementors to agree on anything)

3. With an appropriate FOSS license, anyone who wants ABI-like
functionality can have it, but those who don't want it don't have it
forced upon them

4. MPI implementors can keep doing what they do best: working on making
their software great

This seems like a perfect project for a bright Master's student.
Anyone care to open up a SourceForge project for it? :-)

{+} Jeff Squyres
{+} The Open MPI Project