[MPI3 Fortran] Deprecate mpif.h?

[Supalov, Alexander]

Thank you. I think we're getting to a more balanced approach here. I hope the Fortran deprecation will never look like the C++ deprecation in MPI-2.2. There MPI had very few users (small but positive number), so this was not a big deal. Here we have the majority of the HPC apps I guess, especially in the classical domains I mentioned in my email to Jeff.

There's still one snag, though: once we deprecate the mpif.h, how can we still extend it? I think these two decision are connected: once we deprecate, we freeze. And once we freeze, we "make" people move to MPI-3. And those being "moved" may resist it indefinitely (cf. MPI-2). What's the point in deprecation then? Negative impact on adoption at the price of correctness. May be this pans out, may be it won't.

I'd rather be for "tempting" and "luring" the inquisitive users into the bright new world by showing some particularly relevant MPI-3 features to the F77 adepts thru the extended mpif.h, letting them smell the wind of the wilderness but making all advanced features available only in the "safe" F2008 environment, as dictated by the language and standard logic.

In the meantime I talked to Nick and understand now that the non-blocking collectives in particular may not be an adequate example of such a "bait": there are simply too many issues with the buffers already in the F77 binding to aggravate them by all the issues that were identified during the discussion of the non-blocking collectives (copy in/out, code movement, etc.).

Lets abstract that out for now. Still, there are some aspects that people may like. FT? Hybrid? Fast RMA?

In the meantime, the feedback I'm getting across a wide commercial ISV range is that a backward incompatible MPI-3 will be a major issue for them. Moreover, those who include mpif.h now won't move until they see MPI-3 offering compelling value. The significance of the mpi3 backward incompatible module is thus but a part of the wider backward compatibility question. I'm looking forward to more data - and to the analysis of the questionnaire results that were collected last year.

-----Original Message-----
From: mpi3-fortran-bounces at lists.mpi-forum.org [mailto:mpi3-fortran-bounces at lists.mpi-forum.org] On Behalf Of Craig Rasmussen
Sent: Friday, March 05, 2010 7:11 PM
To: MPI-3 Fortran working group
Subject: Re: [MPI3 Fortran] Deprecate mpif.h?


On Mar 5, 2010, at 3:44 AM, Supalov, Alexander wrote:

> Thanks. I like very much the balanced approach you outline,  
> understand the technical reasons for the desire to improve the  
> Fortran interface, and agree that the current interface is basically  
> broken (but it works!) and that something must be done.
>
> I just disagree with the proposed staging. Namely, I think that  
> deprecating or freezing the current binding now will send a wrong  
> signal to the masses and increase fear, uncertainty, and doubt in  
> relation to the MPI standard.

I would argue that using mpi3 will reduce fear, uncertainty, and doubt  
because the MPI-3 API will no longer be in conflict with the Fortran  
standard.  So for users this is a good thing and I believe you would  
agree.

> Instead, I argue that we should take a much smoother path into the  
> future, a path that will probably take several decades rather than  
> years, and should not start with a U-turn.
>

A couple of points:

On deprecation.  This is a statement on how the bindings are viewed by  
the standard and not on availability.  As I've been told repeatedly by  
Fortran compiler vendors, just because a feature is deprecated doesn't  
mean it will EVER be removed from the compiler.  So I think  
deprecation is the smooth path to the future that will allow codes to  
slowly migrate over several decades.  It just states that programmers  
should begin the migration path at an appropriate time and not put it  
off forever.  If mpif.h didn't break the Fortran language then I might  
feel differently.  I just don't see how it is a good idea for MPI to  
OFFICIALLY support a standard that is broken.

On freezing mpif.h.  I see this as a separate though related issue.   
New functions could be added to mpif.h although this would be kind of  
weird.  But since it will take time before all Fortran compilers in  
use will support the MPI3 module, it may be appropriate to add new  
functions to mpif.h in the short term.

In any case, I think the MPI standard can be written so that users  
clearly understand that:
1. MPI3 is the future as it will comply with the Fortran standard.
2. mpif.h is deprecated though it will remain around for some time.   
It is deprecated from the standard, not deleted.
3. There is a smooth migration path from mpif.h to using the MPI3  
module.

-craig

_______________________________________________
mpi3-fortran mailing list
mpi3-fortran at lists.mpi-forum.org
http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-fortran
---------------------------------------------------------------------
Intel GmbH
Dornacher Strasse 1
85622 Feldkirchen/Muenchen Germany
Sitz der Gesellschaft: Feldkirchen bei Muenchen
Geschaeftsfuehrer: Douglas Lusk, Peter Gleissner, Hannes Schwaderer
Registergericht: Muenchen HRB 47456 Ust.-IdNr.
VAT Registration No.: DE129385895
Citibank Frankfurt (BLZ 502 109 00) 600119052

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.