RE: [mpi-21] ABI (was: Call for MPI 2.2 and 3.0...)

[Erez Haba <erezh@xxxxxxxxxxxxx>]

Thanks Jeff,

Comments interspersed.

-----Original Message-----
From: owner-mpi-21@xxxxxxxxxxxxx [mailto:owner-mpi-21@xxxxxxxxxxxxx] On Behalf Of Jeff Squyres
Sent: Tuesday, December 04, 2007 10:31 AM
To: mpi-21@xxxxxxxxxxxxx
Subject: [mpi-21] ABI (was: Call for MPI 2.2 and 3.0...)

On Dec 4, 2007, at 12:00 PM, Erez Haba wrote:

> The feedback I am getting back from ISV's is that the two most
> important issues for the C ABI are
> 1.       Calling convention

I'm not sure what you mean by this...?  The MPI API is the same in all
MPI implementations.

[erezh] __cdecl vs __stdcall vs __fastall vs your parameter passing convention.

> 2.       Size of input parameters (e.g., what's the size of MPI_Comm)

Isn't that kinda useless without standardized values for the pre-
defined constants?  :-)

[erezh] Yes, you need the predefined constants and defining the size of the parameters.
This is a significant issue for customers. I think we can do that for "C" without limiting implementations.


> It would be ideal to define this across processor architectures, like
> x86, x64 etc. but it would be okay to define the ABI across OS/
> Processor architecture. These two issues simplify ISV's testing
> matrix,

No they don't!  This is the Big Lie of an ABI.  ISV's *STILL* need to
test against every MPI implementation.  Fine; you don't have to
compile the application against each MPI implementation, and ISV's can
have one executable that supports multiple MPI's -- I see the "win" in
this.  But ISV's still have to *test* the application against each MPI
implementation.  And that's the much more time-consuming step (vs.
recompiling against each MPI).

[erezh] Yes, I agree. They still need to test against different MPI implementations. However, they don't have to test their code "marshaling" the interface for every different flavor of MPI implementation.

[erezh] The barrier to move to another MPI implementation on a tested platform is much lower. Authoring a new adaptation layer with new bugs, re-compile and test is a high barrier.

If an ABI is inevitable, I would strongly opt for:

1. it is optional for an MPI implementation to support it (e.g., for
the already-cited cases where ABI conformance doesn't make sense, and
also for MPI implementations who simply choose not to support it).
I.e., an MPI implementation can be "MPI conformant" and choose not to
support the ABI.

2. provide a mechanism for MPI applications to optionally identify (at
run-time) which MPI they are using (e.g., so that they can choose not
to run, or display a warning that this MPI implementation has not been
QA tested with the application, etc.)

[erezh] I think that this is already achieved today by identifying the binary that you're dynamically binding to.

> and support ISV's that are trying to dynamically bind to multiple
> MPI implementations.
>
> I didn't hear any ISV ask for unified binary name, and think that
> this would be unwise to do so. Having binaries clash with each other
> is a deployment nightmare.

This is my own ignorance here, but can you dynamically change the name
of a shared library dependency in an executable?  E.g., if MPI
implementation A provides libmpi.so and MPI implementation B provides
libAmpi.so, can you have a single executable that can shift between
the two at run-time?

[erezh] Yes you can. Using dynamically linked libraries (DLL's).

> Re certification program, I think that it would be wise to have some
> mechanism to validate MPI implementations. It is necessary for
> validating that an implementation is actually implementing the
> standard. Test suite compliance result information would benefit
> implementers and users.
> However, I am not sure that an ABI certification program is required
> at this time.


--
Jeff Squyres
Cisco Systems