[MPI3 Fortran] Summary of items on the table
Bill Long
longb at cray.com
Mon Apr 28 14:51:41 CDT 2008
Craig Rasmussen wrote:
> There has been quite a lot of traffic in the past couple of months
> regarding possible directions for a new MPI binding for Fortran. I
> thought now would be a good time to summarize and try to get a
> consensus on what direction we should pursue. Some choices will
> require changes to the Fortran standard and this input we need to get
> to the Fortran standards committee within the next two weeks.
>
> The major choice we need to make is how to declare an MPI "choice
> buffer" (void *) in a Fortran interface. I'll list the options below
> with advantages and disadvantages as I see them. Please rank these
> options (they all will use F2003 BIND(C)).
>
> 1. Map void* to C_PTR. Upside: this will work now in most compilers
> and likely all soon. Downside: users must change the call site to use
> C_LOC to obtain the C address; C_LOC requires the POINTER or TARGET
> attribute and may reduce performance and require additional code changes.
>
Changing the actual argument to a C_LOC reference also has the side
effect of making the actual argument an expression whose value is not a
Fortran pointer. Thus, the corresponding dummy argument cannot be
defined. A problem for about half of the interesting MPI cases.
> 2. Map void* to a new Fortran type C_VOID. Upside: no changes to
> current code (I think). Downside: would require a change in the
> Fortran standard and couldn't be done until Fortran 20xx (a long time
> before we see it in compilers).
I think the downside here is significant. Adding a new intrinsic type
has significant ramifications for compiler internals. I think chances
for this to be added even in 20xx are slim.
>
> 3. Map void* to type(C_VOID) defined in the ISO_C_BINDING intrinsic
> module and add LANG=C to the Fortran standard. Upside: no changes to
> current code other than to USE the MPI3 module. Downside: it will
> require changes to the Fortran standard but can get to users
> relatively soon (before F2008 appears in compilers).
>
> 4. Add an IGNORE attribute with parameters T (type) K (kind) R (rank)
> for BIND(C) interfaces. This pretty much (as I understand it) does
> the same thing as #3, just with different syntax and with slightly
> more flexibility (partial type checking). Upside: see #3. Downside:
> see #3.
Option 3 is basically a subset of 4 that allows only IGNORE(TKR) and
restricts the usage to BIND(C) procedures that are written in C. Option
4 is more general, and does not require breaking the F/C symmetry in the
current rules. Perhaps a more compelling case for 4 is that many
compilers already support this functionality through compiler
directives. (How do you think we implement our MPI modules today?)
Use of 4 would not have to be limited to BIND(C) interfaces. Because of
existing directives, I think 4 will be easy for most vendors to accept.
One of the J3 alternates from Intel has already stated this is his
preferred choice.
>
> Aleks has submitted a proposal to the Fortran J3 committee to improve
> on the ASYNCHRONOUS attribute. Hopefully this can make it into the
> F2008 standard and fix problems associated with copyin/copyout
> semantics and with code motion associated with asynchronous MPI
> calls. A question I have is there a problem with copyin/copyout for
> synchronous MPI?
At least there is a performance degradation. For codes that use a lot
of memory already, you increase the risk of going over some limit.
Cheers,
Bill
>
> I'm currently at the April MPI Forum where I'll collect votes. Others
> please add your feedback (rank the options) in email (actually it
> would be helpful for the record to get email from everyone within
> shouting distance).
>
> A question just came up about passing CHARACTER parameters. Comments?
>
> Regards,
> Craig
>
--
Bill Long longb at cray.com
Fortran Technical Support & voice: 651-605-9024
Bioinformatics Software Development fax: 651-605-9142
Cray Inc., 1340 Mendota Heights Rd., Mendota Heights, MN, 55120
More information about the mpiwg-fortran
mailing list