[Mpi-21] [MPI3 Fortran] MPI-2.1: Fortran 90 bindings

[Jeff Squyres]

Yes, this is the direction we are going for new Fortran bindings in  
MPI-3.

My proposal is specifically for a small/incremental fix for MPI-2.1's  
existing MPI F90 bindings.  The rule for MPI-2.1 is that changes  
cannot break existing MPI codes.  As such, only "small" things are  
going into MPI-2.1.

On Mar 6, 2008, at 8:25 AM, Lionel, Steve wrote:

> I would recommend that for buffers of variable type and rank that the
> Fortran interface make use of the Fortran 2003 C interoperability
> features, supported by many compilers already, and make these  
> arguments
> of type C_PTR passed by value.  The programmer would then pass
> C_LOC(buffer), where buffer can be of any type and rank.  This is all
> specifiable with standard-conforming syntax.
>
> If this is done, you don't need to have multiple interfaces just to
> change type, and you're not giving up any type checking that you would
> have had before, as any combination of type and rank would have  
> matched
> some interface. Now you can have as many of these "variant"  
> arguments as
> you like without a mind-numbing series of specific interfaces.
>
> A compiler using this choice must support the following Fortran 2003
> features:
> - Intrinsic module ISO_C_BINDING
> - The VALUE attribute
> - The BIND(C) attribute
>
> And if the user chooses a compiler that does not support this, then  
> they
> can use the F77 interfaces.
>
> Steve Lionel
> Developer Products Division
> Intel Corporation
> Nashua, NH
>
>
>
> -----Original Message-----
> From: mpi3-fortran-bounces_at_[hidden]
> [mailto:mpi3-fortran-bounces_at_[hidden]] On Behalf Of Jeff
> Squyres
> Sent: Wednesday, March 05, 2008 9:16 PM
> To: Mailing list for discussion of MPI 2.1
> Cc: MPI-3 Fortran working group
> Subject: [MPI3 Fortran] MPI-2.1: Fortran 90 bindings
> Importance: Low
>
> The current MPI-2 F90 bindings are un-implementable because they
> require almost 7 *million* interface functions: with 15 intrinsic
> Fortran types, each with 7 possible dimensions, the current F90
> interface *requires*:
>
> - 50 MPI functions with one choice buffer: 15 * 7 * 50 = 5,250  
> functions
> - 25 MPI functions with two choice buffers: (15 * 7 * 25)^2 = 6.8M
> functions
> - ...and a few hundred more MPI functions with no choice buffers
>
> This is clearly broken.
>
> An MPI-2.1-worthy solution could be to add a global statement saying
> that MPI functions with two choice buffers are explicitly not included
> in the F90 bindings.  F90 MPI applications can transparently fall back
> to the F77 bindings (although they won't get the strong type checking,
> etc.).  This idea therefore fits the requirement of not breaking any
> existing MPI codes.
>
> Specifically: if we remove the requirement to provide all MPI
> functions with two choice buffers, 5,000+ F90 interface functions is
> [a pain but] implementable.  I doubt that any current MPI
> implementation provides more than the no-choice-buffers plus one-
> choice-buffer functions anyway...
>
> If this seems like a good idea, I can write a proper proposal for it.
> Comments?
>
> -- 
> Jeff Squyres
> Cisco Systems
>
> _______________________________________________
> mpi3-fortran mailing list
> mpi3-fortran_at_[hidden]
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-fortran
>
> _______________________________________________
> mpi3-fortran mailing list
> mpi3-fortran_at_[hidden]
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-fortran


-- 
Jeff Squyres
Cisco Systems