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

[Jeff Squyres <jsquyres@xxxxxxxxx>]

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.

> 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?  :-)

> It would be idle 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).

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.)

> 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?

> 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