[Beowulf] The Case for an MPI ABI

[Greg Lindahl]

On Thu, Feb 24, 2005 at 02:30:09PM +0100, Joachim Worringen wrote:

> This problem left apart, do you know of ISV's that would at least be 
> willing to think about giving support to an MPI ABI no matter which 
> implementation and interconnect, and not a specific MPI library? Because 
> this is what matters.

As I wrote in my talk, no. Some ISVs will balk because of the testing
issue.  However, it is much easier to test against new libraries if
there is an ABI, and no recompilation means no worrying about
recompilation bugs.

> For open source software packages alone, an ABI is not of critical 
> importance as people with a tcp/ip cluster can use pre-linkked packages, 
> and people with a high-perfomance interconnect cluster typically have 
> enough competence to compile the software themselves.

An ABI is still useful for these people. Even if you are using
ethernet and TCP/IP, if you have a queue system and have integrated
with LAM, a pre-linked package using MPICH is not so useful.
Critically important? Probably not. Important? Yes.

> I did not think of this, but more of issues like "string as an argument" 
> as the way how the string length is passed is not standardized.

Yes, but on x86 and x86-64, Intel and PGI and g77 and PathScale all
use the same convention.

> Then there are issues with getting access to global variables from
> COMMON blocks

This is not an issue, because the MPI interface does not use COMMON
blocks.

The most annoying issue is command-line args, but I am about to write
(and will give away) an Amazing Universal Fortran Command Line Arg
Fetcher (AUFCLAF).

> This does not mean that we should not continue thinking about an ABI, 
> but there's more than unifying mpi.h to be able to use a single shared 
> library.

I agree. I wasn't claiming to have a final solution for the issues.
The important thing at this stage is not to solve all the issues, but
to see if the benefits of an ABI are compelling enough to form a
committee and work on it.

-- greg