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

[Erez Haba <erezh@xxxxxxxxxxxxx>]

Comments interspersed.

-----Original Message-----
From: owner-mpi-21@xxxxxxxxxxxxx [mailto:owner-mpi-21@xxxxxxxxxxxxx] On Behalf Of Jeff Squyres
Sent: Tuesday, December 04, 2007 1:31 PM
To: mpi-21@xxxxxxxxxxxxx
Subject: 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.

[erezh] see http://en.wikipedia.org/wiki/X86_calling_conventions
As I said, this probably should be defined per processor type/os type

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

[erezh] You don't define type, just the size of the parameter. For example, we can define it as 4 bytes on 32bit and 8 bytes on 64bit. The implementation can define the type as long as it matches the size.


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

[erezh] Who's <mpi.h>?
Vendor A takes a pointer as MPI_Comm the other takes an int as MPI_Comm.

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

[erezh] The application dynamically loads the library thus it specify the library name.
I'm not an expert on Fortran but I'm sure that the Fortran vendors provide a way to dynamically load an bind libraries.


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

[erezh] That could be a nice informative extension.

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

[erezh] On Windows: call LoadLibrary("mympi.dll") and then call GetProcAddress("MPI_Send") to get a pointer to the MPI_Send function. The function prototype should match your MPI_Send prototype as you cast the GetProcAddress result from void* to the MPI_Send function pointer.

[erezh] you can have your code bind to the various MPI API's on different library by switching the library name in LoadLibrary("name").

--
Jeff Squyres
Cisco Systems