[MPI3 Fortran] Request for a straw vote.
alexander.supalov at intel.com
Fri Jun 12 04:52:30 CDT 2009
Complementing Steve's reply that represents Intel's position, there may be two additional aspects to consider, namely:
1. We may want to decide what flavor of the new Fortran interface we're striving at. There are at least two extremes:
a. As close as possible to the C interface with all its low level efficiency
b. As natural as possible for Fortran with all its modern expressive power
We may even want to formulate two different interfaces according to these extremes, and see what they look like, both in theory and in practice. I would even propose a usability review with the application programmers. Then we may be better equipped to find a golden middle between the extremes, or at least consistently go for one of the extremes if it proves superior to the other.
2. As soon as the MPI standard allows certain features to be expressed in a compiler dependent way, even for a while (the any-type-and-shape comes to mind here first and foremost), one is exposed to the possible subtle semantical variations between different compilers, as well as between the compiler ways and the final standard. This may lead to dissatisfied customers who will notice that when they change the compiler/MPI implementation, the behavior of their applications may change as well.
Note that even if we try to specify very precisely what we want from the Fortran standard, and then, for any reason, the Fortran standard committee decides to go a different way, we may be basically left with an MPI interface that is difficult to impossible to represent faithfully in a Fortran standard compliant manner.
Hence, it may be advisable to wait until the respective Fortran standard syntax and semantics are cast in stone. As we're talking about MPI-3 here, we may have some time for this slower, safer approach I hope.
From: mpi3-fortran-bounces at lists.mpi-forum.org [mailto:mpi3-fortran-bounces at lists.mpi-forum.org] On Behalf Of Lionel, Steve
Sent: Wednesday, June 10, 2009 9:17 PM
To: MPI-3 Fortran working group
Subject: Re: [MPI3 Fortran] Request for a straw vote.
Here's my take on the various questions, with input from Alexander Supalov (Intel).
Intel Developer Support
Issues to straw vote:
1. Q: Should intents be specified in the MPI-3 interfaces?
A: Yes, specifying intent in the Fortran interfaces helps the user
to understand the call (it may also help the compiler with
[sl] Yes, but care must be taken that the INTENT specifiers accurately map to how MPI treats the argument (and also making sure that the Fortran meaning of INTENT matches!)
2. Q: Should derived types be used in place of some MPI handles that
are currently integers? For example, TYPE(MPI_Comm).
A: Yes, the use of specific types enhances type safety.
[sl] Yes, as an "opaque" type (with PRIVATE component(s))
3. Q: What type should be specified for the extra_state and value
parameters in MPI_Comm_create_keyval and MPI_Comm_attr_set?
A: TYPE(C_PTR). Use of C_PTR allows the MPI implementation to
store the address of the Fortran type and the user to subsequently
associate a Fortran pointer with the stored C_PTR with a call to
NOTE: C addresses are to be obtained using C_LOC which requires
the target attribute on the actual argument. This warns the compiler
that MPI may store (alias) the extra_state or value parameters.
[sl] I think more evaluation from an MPI usage perspective needs to be applied to this one. From a Fortran perspective, I'm not in favor of a direct use of C_PTR, but the alternatives don't feel better. I see that extra_state is defined in the C interface as void*, so perhaps what is really wanted here is "TYPE(*),DIMENSION(..)", but we get into that later. If C_PTR is to be used here then why not also for the BUF arguments?
4. Q: What should the name of the MPI-3 module be?
A: MPI3 to distinguish it from the current MPI module.
Unresolved Issue: A consensus was not reached on this question.
An alternative is to use module names MPI2, MPI3, ..., as well as
MPI. If "USE MPI" is used, the MPI vendor will allow the module to be
chosen with a compile time option specifying the location of the MPI
5. Q: Should default integer kinds be used for most integer parameters?
A: Yes, this has not caused problems in the past and will have the
least impact on existing code.
NOTE: A specified kind, MPI_COUNT_KIND will be used for buffer
[sl] Yes, but there seems to be a misunderstanding among some. I think what we are discussing is how the arguments should be documented in the spec. This documentation needs to include the kind the same way that the C programmer needs to know whether to use int, long or whatever. The lazy Fortran programmer can often get away with using default integer if that kind happens to match what is expected, but many compilers allow the default integer kind to be changed (-i8, etc.), which can wreak havoc.
I feel that the spec should specify the kind. It could be done with specific MPI_KIND values or those taken from ISO_C_BINDING. The actual module must use the correct kind values and the programmer will be encouraged to do so as well. Old code that matches the kinds will still work - programmers will not be forced to add explicit kinds except when it's not default.
6. Q: How should type and rank be specified for buffer choice arguments?
A: TYPE(*), DIMENSION(..)
NOTE: This has been vetted by the Fortran J3 standards committee.
MPI vendors will use the Fortran descriptor interface.
Unresolved Issue 1: Will this block the compiler from using copyin/
[sl] You need some notation in the spec to explain to the programmer what she should put in her code. No matter what you say here, you're going to have to explain it because there is no current Fortran standard syntax for this concept. TYPE(*), DIMENSION(..) is not even in an approved TR yet - I would not call it "vetted", though it has gone through several reviews and committee votes. The risk of using syntax not yet in a published standard or TR is that it MIGHT change. We (former DEC) have been burned by this in the past: the no-parentheses form of PARAMETER in F77 which changed right at the end, after we had already implemented it.
To the best of my knowledge, use of this syntax does not stop copyin/out. That should be dealt with separately.
Personally, I lean towards a <any-type-and-shape> notation as it won't lead readers to start with their Fortran documentation to figure out what this means. That said, it is not a strong lean and if this usage perhaps encourages vendors to support it early, recognizing the risks, that is goodness.
7. Q: Are vendors allowed to provide a different actual interface in
the MPI-3 module for TYPE(*), DIMENSION(..) as a workaround until
compilers catch up.
A: Yes, if possible.
Unresolved issue: Can existing IGNORE TKR compiler directives be
[sl] Again, we are (I think) discussing the spec. The nuts and bolts of how it is implemented by vendors should be left unspecified, as long as a program written to the spec works.
8. Q: Should the value attribute be given to some parameters?
A: No, it would be different from current semantics (though more
true to the C interface) and there is no need to make the change.
Specify intent instead.
[sl] VALUE and INTENT are different concepts. If this is a pure Fortran interface, I see no value in VALUE. If we're writing interfaces to C routines, then VALUE might be required.
9. Q: What syntax should be specified to inhibit aggresive compiler
optimizations associated with asynchronous MPI calls.
A: Used the Fortran asynchronous attribute on dummy variables.
NOTE: The MPI-3 standard will need to make clear that there are
requirements on the user to get this correct.
[sl] Yes, given that we have no other tool for the purpose, but I know there are strong feelings about this one.
10. Q: Should specific Fortran interfaces be specified in the MPI-3
A: Yes, this is preferable to use of <type> in the current
standard. While <type> is shorted, specific Fortran interfaces
provide greater clarity for users.
[sl] No, if what you mean is spelling out all the combinations of type and shape that can be used for a given routine. That will be overwhelming and ultimately LESS clear.
11. Q: Should the F77 and F90 interfaces be deprecated?
NOTE: Old interface descriptions should be moved to an appendix.
[sl] As long as the reader can find the old interfaces, that's fine. I am not in favor of "deleting" old interfaces.
12. Q: Is it an error if the user gives a non-contiguous buffer to a
choice argument as it is for C?
Unresolved issue: Should the vendor be required to catch the
error as always checking the argument is a performance issue.
[sl] Yes, it is an error. It would be nice for compilers to diagnose this, but Fortran 2003 does not provide a "hook" for them to do so. Fortran 2008 includes a CONTIGUOUS attribute which can be used for this purpose. I think it would be useful to include CONTIGUOUS in the list of attributes for arguments that must be contiguous. It would be implementation-dependent if such an attribute actually got used.
Note that CONTIGUOUS can't be used with C_PTR, but note that Fortran 2008 allows C_LOC of a POINTER array that has the CONTIGUOUS attribute.
13. Q: Should mixed MPI-3 and older MPI code be compatible within the
A: Yes, this allows a gentler transition path to MPI-3 if the
user doesn't have to convert all of this code at once.
NOTE: This will require conversion routines between, for example,
integer handles and MPI-3 typed handles. This would allow a
TYPE(MPI_Comm) to be converted to an integer and passed to code in a
user's older Fortran library.
mpi3-fortran mailing list
mpi3-fortran at lists.mpi-forum.org
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.
More information about the mpiwg-fortran