[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

On Dec 4, 2007, at 4:14 PM, Erez Haba wrote:

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.

Are those Microsoft-specific conventions? I don't recognize them. In POSIX, there's only one way to call the C MPI API functions.

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.

This is where the MPI implementors start having religious debates... :-)

(e.g., int vs. pointer)

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. 

What adaption layer?  <mpi.h> and 'mpif.h' is all you need.

Are you referring to something else, such as how to compile and link MPI applications?

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.

Can you explain how to do that? Remember that you have to be able to do it from Fortran, too.

I was thinking something simple, like a new MPI constant with an implementation-specific string (e.g., vendor name and/or version number).

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

Can you explain how to do that? Please re-read my example: I cited 2 DLLs with different names -- how do you get one executable with explicit shared library dependencies to switch linking between them without needing system-level intervention (e.g., creating a sym link to make one DLL have the same filename as the other [but it must be in a different directory])?

Am I missing something obvious?

--
Jeff Squyres
Cisco Systems