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

["William Yu" <wyu@xxxxxxxxxx>]

Of course, it would be nice to just have standard shared object libraries and do away with wrapper compilers too ;-)

But seriously, why can't we standardize stuff like parameter size and const values? I can't seem to find the historical discussions. 

I am however aware of the int/long versus pointer argument which is present in a things C.

________________ Reply Header ________________
Subject:	Re: [mpi-21] ABI (was: Call for MPI 2.2 and 3.0...)
Author:	Jeff Squyres <jsquyres@xxxxxxxxx>
Date:		December 04th 2007 10:14 pm

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