Open MPI logo

Open MPI User's Mailing List Archives

  |   Home   |   Support   |   FAQ   |  

This web mail archive is frozen.

This page is part of a frozen web archive of this mailing list.

You can still navigate around this archive, but know that no new mails have been added to it since July of 2016.

Click here to be taken to the new web archives of this list; it includes all the mails that are in this frozen archive plus all new mails that have been sent to the list since it was migrated to the new archives.

From: Patrick Geoffray (patrick_at_[hidden])
Date: 2005-03-25 14:59:18

Hi Greg,

Greg Lindahl wrote:
> I think this overall idea falls short of the benefit of an ABI for a
> couple of reasons. The first is that it's unlikely to get wide
> distribution if it doesn't come with MPI implementations. The second
> is that it's harder to maintain "out of tree"; the minute that an MPI
> implementation changes something, MorphMPI is going to be broken.

I don't see it that way. First, the implementations of the translation
layers will be done by each MPI implementations. MorphMPI (no offense
Jeff but we got to choose a somewhat cooler name) just define the common
interface, nothing more. If the common layer does not change, the
translation does not have to change unless something in the side of the
MPI implementation changes, and its maintainer should then keep its
local translation layer up to date.

> Was there a big fight over the Fortran interface? It nails down the
> types because it has to. All the ABI does is make C look like Fortran;
> no internals need change in any implementation.

You don't change internals, you translate them. Let say you use pointers
in your MPI implementation and the common layer specifies integers. In
your translation layer, you translate pointers into integers by putting
them in a table. You have as much work as your internals are far from
the common interface and, hopefully, it will be a midpoint for everybody.


Patrick Geoffray
Myricom, Inc.