[MPI3 Fortran] Deprecate mpif.h?

[Supalov, Alexander]

Thanks. I did not go into the release backend expenses yet. Once there's a global change to "use mpi3", the code will have to be revalidated on all platforms, compilers, OS the ISV uses. Oh well.

We can argue for ages here. I suggest that a more constructive way is to identify what parts of the MPI-3 may be of interest to the long time Fortran users who may not want or be able to move to Fortran 2008. NB collectives is a good starter. What else?

If we identify enough points of interest, and their addition to the mpif.h and the respective mpi module will be trivial, I reckon we'll do the standard and the user community a better service if we just extend both accordingly.

Those in the new app camp will "use mpi3". Those in the old camp (99%?) will include "mpif.h" or, if they please, "use mpi". And there will be peace.

-----Original Message-----
From: mpi3-fortran-bounces at lists.mpi-forum.org [mailto:mpi3-fortran-bounces at lists.mpi-forum.org] On Behalf Of N.M. Maclaren
Sent: Thursday, March 04, 2010 10:07 AM
To: MPI-3 Fortran working group
Subject: Re: [MPI3 Fortran] Deprecate mpif.h?

On Mar 3 2010, Supalov, Alexander wrote:
>
>Thanks. Let me sketch a sad yet very realistic artificial example.
>
> Imagine a hapless owner of 10-million lines of mostly Fortran IV code, 
> with some C inlays, whose original authors retired 25 years ago. Every 
> single change after that goes thru the ISO 9000 certification process. 
> And still they need to get the 5% performance increase the NB collectives 
> may bring.
>
>Now tell them they must "use mpi3" for that. Shudder.

That actually raises a point, where I realise that I was jumping to
conclusions.  MPI 2.1 requires interoperability between mpif.h and
module MPI.

    Is the intent to allow a single program to use modules MPI and
    module MPI3 in separately compiled parts?

If the answer is "yes", I don't see a problem.  There are two likely
possibilities:

    1) The certification rules require revalidation if anything is
changed.  In that case, adding a single non-blocking collective adds
as much revalidation effort as changing to USE MPI3 throughout.

    2) The certification rules require revalidation only of changed
code and interfaces.  In that case, it is easy to separate out the
code that uses the non-blocking collectives and just revalidate that.

I don't think that adding restrictions on mixing MPI and MPI3 would
be all that hard.  One could reasonably say that (say) constants,
communicators and groups are sharable, but requests are not.  And so
on.


Regards,
Nick Maclaren.


_______________________________________________
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.