[MPI3 Fortran] Deprecate mpif.h?

[Jeff Squyres]

These are good questions; I hope you don't mind, Rolf -- I took the liberty of replying to the MPI3 Fortran list so that the conversation can be shared.


On Mar 3, 2010, at 5:20 AM, Rolf Rabenseifner wrote:

> Question Block A:
> 
> As far as I understand, the MPI standard never defines
> that mpif.h must not contain prototypes for MPI routines.

I think you're right, but I think most people would be surprised if their mpif.h started strictly enforcing prototypes.

> As far as I understand, it is valid that an MPI implementation
> defines mpif.h with exactly one line:
>       use mpi
> because all compilers are Fortran 90 compilers
> and use mpi is allowed in free and fixed form sources.

Yes, I think that's right, too.

So I've been calling them the "implicit interfaces" -- I guess that's wrong, too.  Sigh.  Now I'll have to think of a better name.  :-)

> As far as I know, IBM and NEC are doing argument checking with
> "use mpi" and also with "include 'mpif.h'".

What do you mean -- that they have an mpif.h that just does "use mpi"?

Question: if you "implicit none", doesn't that change where you can include an mpif.h, depending on whether it has "use mpi" or one that doesn't?  That seems to be unportable to me.

> Based on this, I expect that you want to deprecate
> "use mpi" and  "include 'mpif.h'"?

Yes.  We know that "use mpi" is broken in many ways.  Yes, you can use compiler-specific extensions to make it work, but the fact that we *require* compiler-specific extensions to the language (which not all compilers have, right?) makes it pretty icky.

> Are there any changes in the API between routine MPI_Xxxxx
>  - in "use mpi" and  "include 'mpif.h'" 
>  - and in use mpi3 ?
> 
> If yes, then pleas explain the details.
> If now, then I do not understand why we want to introduce
> "use mpi3".

Yes -- MPI handles will no longer be required to be INTEGERs.  ierr will also be optional.

> As far as I understand, the differences can be in handling MPI datatypes.
> Is there any MPI-2.2 defined usage or well known existing portable
> meaning of the MPI derived datatypes together with some
> Fortran memory data specification (such as arrays, contiguous
> subarrays, non-contiguous subarrays, Fortran derived types with
> sequence attribute, common blocks, ...) that will work
> different between "use mpi" and "use mpi3"?

I'm not sure what you mean here...?

> If there is a difference between "use mpi" and "use mpi3" for
> buffer arguments, then argument checking together with "use mpi"
> must implement the buf arguments as "unchecked" arguments,
> and not with the new features coming in Fortran 2008.

I thought that J3 gave us a format to use for un-typed buffers, and even though full F08 compilers won't be available for a while, this feature was likely to start becoming available in the near future...?

> In this case I would strongly recommend
>  - not to deprecate "use mpi" nor "include mpif.h", and
>  - all vendors add the IBM/NEC hack (void arguments) to their
>    Fortran compiler, and
>  - they implement mpif.h as "use mpi", and
>  - they define all mpi routines with Fortran 90 interfaces
>    and all buffer in their argument list as void.
>    (i.e. current IBM/NEC quality).
>  - The new "use mpi3" has a different meaning for the buffers,
>    nothing else.
>  - There is no need to deprecate "use mpi" nor "include mpif.h".

I don't understand this proposal at all; it seems to disregard several months worth of discussion.

> Question block B:
> 
> If there are differences, can we handle the new definition on
> a per-subroutine-basis together with a preprocessor?
> That would mean, keeping both interfaces is possible.

I don't quite understand.  Can you provide an example?

What about Fortran codes that don't use a preprocessor?

> That would also mean, that inside of one Fortran program block,
> some MPI routines are using the old interface and some the new one.

That seems risky to me -- I'm assuming that would be fairly confusing to an end user.

> In this case, an optional feature would be to have an
> additional "use mpi3" with the additional feature, that
> argument checking for all MPI routines is a must.
> 
> As mentioned in block A, it is still allowed that an
> implementation has implemented "include mpif.h"
> as "use mpi" together with fortran 77 compatible
> interface definitions (i.e., with void buffers).
> 
> Kind regards
> Rolf
> 
> ----- "Jeff Squyres" <jsquyres at cisco.com> schrieb:
> 
> > Rolf --
> >
> > Have you commented yet on the idea of deprecating mpif.h?  I'm
> > interested to hear your opinion; I don't recall if I've heard you say
> > anything about it yet.
> >
> >   
> > http://blogs.cisco.com/ciscotalk/performance/comments/...but_what_about_mpif.h/#more
> >
> > --
> > Jeff Squyres
> > jsquyres at cisco.com
> > For corporate legal information go to:
> > http://www.cisco.com/web/about/doing_business/legal/cri/
> 
> --
> Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner at hlrs.de
> High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530
> University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832
> Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner
> Nobelstr. 19, D-70550 Stuttgart, Germany . (Office: Allmandring 30)
> 


-- 
Jeff Squyres
jsquyres at cisco.com
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/