Open MPI logo

Open MPI User's Mailing List Archives

  |   Home   |   Support   |   FAQ   |  

This web mail archive is frozen.

This page is part of a frozen web archive of this mailing list.

You can still navigate around this archive, but know that no new mails have been added to it since July of 2016.

Click here to be taken to the new web archives of this list; it includes all the mails that are in this frozen archive plus all new mails that have been sent to the list since it was migrated to the new archives.

From: Jeff Squyres (jsquyres_at_[hidden])
Date: 2005-03-26 06:47:41

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

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

- it will work
- it will take far less time to implement
- it does not require a committee (there's no need to standardize its
- 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