[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:48 PM, Erez Haba wrote:

[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 

Ah, thanks!

As I said, this probably should be defined per processor type/os type

Why wouldn't we use whatever the default convention is for calling standard C functions on a given platform (e.g., printf)? Isn't that what we do today?

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.

For an ABI, you need to standardize both the size and the value. It may not be difficult to agree on the sizes: sizeof(void*)/64 bits because you can treat it as an int or a pointer. But the value is where the religious debates come in. For example: MPI_COMM_WORLD -- it is "0" or is it a pointer resolved at compile/link time?

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.

But if the size and values of these things are standardized (which they must be for an ABI), why is this an issue?

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.

Ah -- you're talking about having applications be responsible for dynamically loading the Right libraries, resolving all symbols and constants at run-time, and using indirect methods for invocation and usage (e.g., you cited LoadLibrary() and GetProcAddress()). I understand your point of view now. I believe that some of the derivative language bindings may have used this approach (Python, Perl, etc.)...?

1. Why not hide all that gorp in an MPI implementation that can front other MPI implementations? (i.e., try explaining loading DLLs and function pointers to physicists/engineers/those who are not computer scientists and just want to write their MPI apps and run) MorphMPI has been proposed in various forms throughout the years. Someone even implemented a MorphMPI recently -- see http://www.clustermonkey.net//content/view/213/1/ . Job done -- no ABI needed. :-)

I honestly don't remember the arguments against using a MorphMPI approach (instead of doing an ABI)...

2. There is no standardization on the names of DLLs across MPI implementations. Some MPI's require only one DLL; others require more. Indeed, in both LAM and Open MPI, we have changed the names of the underlying DLLs over the course of different releases (and hide all these details in wrapper compilers). Having customers chase these DLL names across different releases seems like a difficult idea. Implementors certainly *could* be forced to fix their DLL names across releases, but it certainly is convenient having the freedom to change things under the covers.

--
Jeff Squyres
Cisco Systems