[O-MPI users] Re: [Beowulf] Alternative to MPI ABI

[Jeff Squyres]

On Mar 25, 2005, at 6:26 PM, Greg Lindahl wrote:

>> Making even 2 MPI implementations agree on an ABI is an enormous 
>> amount
>> of work.  Given that two major MPI implementations take opposite sides
>> on the pointers-vs.integers for MPI handles debate (and I suspect that
>> neither is willing to change), just getting them to agree on one of
>> them will be a major amount of work.  Then changing the internals of
>> one of those MPIs to match the other is another enormous amount of 
>> work
>> (death by a million cuts).
>
> You yourself said how MPI implementers would actually implement this
> without needing to change any internals: Make the C interface routines
> do the same thing that F77 does today. Elapsed time: a few months,
> same as MorphMPI. No internals need to be changed.
>
> I suppose the good news is that if this is your main objection,
> then it's gone.

Er... no.

Interesting: it seems that you are assuming that mpi.h should use 
integers for MPI handles.

Regardless of which way you choose, your statement "No internals have 
to change" is inaccurate.   At a minimum, *EVERY* MPI API function in 
somebody's implementation will have to change.  I'm not splitting hairs 
on what "internals" means; what I'm saying is that code in the MPI 
implementations [who have chosen "wrong"] have to change.  It doesn't 
matter whether it's code in the API calls or down in the progress 
engine;  a lot of code has to change.  And potentially a bunch of other 
infrastructure has to be changed to match (depending on how the MPI 
works).

And let's not forget that this issue is actually one of the essential 
elements of the pointers-vs-integers debate.  Some MPI implementations 
(both of mine included) have very good reasons for not having the C API 
calls do the same thing as the Fortran API calls.  But that's a 
different conversation (one that I unfortunately do not have time to 
have via e-mail).

>> Also, as I pointed out in my original alternate proposal, with
>> PatrickMPI, only those who want to use an ABI will use it.  Those who
>> do *not* want an ABI do not have to have it forced upon them.
>
> I missed where anyone was being forced to do anything. MPI
> implementers can support the ABI alongside their current interface or
> not, it's their choice.

Er... no.

Well, let's think about this for a minute.  For an MPI implementation 
to support two interfaces, it will need 2 mpi.h's, 2 sets of MPI API 
functions, and 2 corresponding sets of infrastructure to match.  I have 
difficulty seeing MPI implementors wanting to support this -- the 
software engineering issues alone are tremendously unattractive (e.g., 
the testing scenarios have -- at least -- doubled).

It'll also lead to user confusion.  "Oh, yes, our product supports ABC 
MPI." / "But I'm using ABC MPI, and it doesn't work." / "Oh, you need 
to use the MPI ABI of ABC MPI..."  To have a single MPI implementation 
support multiple instances of its API, it [at least effectively] needs 
to be installed twice.  Users therefore have to choose which to 
compile/link against, etc.  So from the user's perspective, MPI ABC API 
is effectively Yet Another MPI (as compared to MPI ABC non-ABI).

In short: if an MPI implementation wants to support an MPI ABI, I have 
difficulty believing that it will be anything other than its 
one-and-only main interface.  So, sure, I guess an MPI implementation 
isn't *forced* to only support an MPI ABI, it's just *strongly 
recommended*.  ;-)

-----

I guess I don't understand your reluctance to accept a MorphMPI-like 
solution:

- it will work
- it will take far less time to implement
- it does not require a committee (there's no need to standardize its 
mpi.h)
- no MPI implementors have to agree on anything
- no existing MPI implementations need to change
- no software engineering issues or practices for existing MPI 
implementations need to change
- people who want it will use it (and those who don't, won't)

Are you trying to jump start MPI-3?

-----

Sidenote: I'll try to keep up with this conversation, but I can't 
promise anything -- it's reaching a frequency that is difficult for me 
to match.

-- 
{+} Jeff Squyres
{+} The Open MPI Project
{+} http://www.open-mpi.org/