[MPI3 Fortran] Request for a straw vote.

[Supalov, Alexander]

Re 12: what if an array section is passed as an actual buffer argument (i.e., a potentially noncontiguous area), and the MPI datatype describes the data as such? Will the new interface avoid copy-in/out?

-----Original Message-----
From: mpi3-fortran-bounces at lists.mpi-forum.org [mailto:mpi3-fortran-bounces at lists.mpi-forum.org] On Behalf Of Jeff Squyres
Sent: Monday, June 22, 2009 5:44 PM
To: MPI-3 Fortran working group
Subject: Re: [MPI3 Fortran] Request for a straw vote.

Sorry for being late to the discussion.


On Jun 9, 2009, at 5:41 PM, Craig Rasmussen wrote:

> 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
> optimization).
>

Yes.

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

Yes.  Remember that MPI specifies that these are *handles* to back-end  
objects.  Implementors can put whatever they want in handles; they  
just have to observe the defined handle semantics as listed in the MPI  
spec (this usually means that the handle is separate from the back-end  
object; the handle can be copied without copying the object, etc.)

There's already good precedent for this in the MPI C++ bindings.

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

I thought Hubert was right on this one: we decided to use TYPE(*),  
DIMENSION(..) to allow anything to go through (of course, that's a  
problem if scalars can't be specified this way). Perhaps the real  
Right answer here is to do whatever is done for MPI_SEND choice  
buffers (and friends) -- then at least we only continue that debate in  
one arena, not two.

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

I prefer explicit versioning (e.g., "mpi3") since we *know* that the  
MPI-3 Fortran interface will be different and incompatible with the  
MPI-1 and MPI-2 Fortran interfaces, then having "use mpi" magically  
change to use the new interfaces will break old codes -- they'll  
refuse to compile.  I think that's extremely undesirable.

As previously mentioned, conversion functions will be provided that  
can be used to convert between C and MPI-1/MPI-2 Fortran handles and  
this new interface.

> 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
> count arguments.
>

I can see Alexander/Intel's position on this one: it has been a long- 
standing problem that users may have an MPI implementation that  
expects an INTEGER of size 4 bytes, but then the user compiled their  
application with "ifort -i8 ...", changing all the INTEGERS in their  
app to 8 bytes.  Badness ensues when they use an 8 byte INTEGER to  
call an MPI function.

But I can also see that it would be a PITA for programmers to have to  
specify *every* argument to MPI functions, and potentially have to  
translate between their MPI-argument-variables and non-MPI-argument- 
variables.  Shrug.

I think I fall on the side of "use default INTEGERs", though.  The MPI  
can provide a "regular" INTEGER library, and a "-i8" INTEGER library.   
It's not perfect, but perhaps it's best to continue this uneasy  
compromise between programmer convenience / functionality and  
completeness-of-specification...?

What does the Fortran community do for this issue in other software  
packages?

> 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/
> copyout?
>

I tried to get involved in this debate and Alexander D. jumped all  
over my syntax.  So I'll stay out.

The intent is that *any* variable -- scalar or otherwise -- can be  
passed through this argument in a portable fashion (i.e., compiler- 
independent).  If that means not specifying the actual language/ 
compiler mechanism but just specifying the mandated behavior, then so  
be it.

One point that may have gotten lost in the email chain: Craig is  
correct that there is *NO RUSH* on specifying this.  We can definitely  
wait for J3 to finalize its relevant specification(s) (e.g., TYPE(*),  
DIMENSION(..)).  The Forum agrees on this point and definitely does  
not want to specify something based on a non-official/proposed J3 draft.

> 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
> used instead?
>

Ditto with #6.

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

No.

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

Staying out of this one for the same reason as #6.

> 10. Q: Should specific Fortran interfaces be specified in the MPI-3
> standard?
>      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.
>

Yes, we should specify them because they will be different than the  
existing Fortran (77 style) bindings that are listed in the MPI-2.2  
spec.  Types will be different, etc.  Hence, they really are two  
difference interfaces and need to be delineated.

A reminder: the F90-style bindings are *not* listed anywhere in the  
MPI-2.2 spec.  I assume that's because the types are all the same as  
the F77-style bindings that are listed throughout MPI-2.2.

> 11. Q: Should the F77 and F90 interfaces be deprecated?
>      A: Yes.
>      NOTE: Old interface descriptions should be moved to an appendix.
>

Yes.

Note: "deprecated" is not "removed".  Either moving them to an  
appendix or marking them deprecated in the text (like we're about to  
do with the C++ bindings) are good solutions; they functions are still  
there, but we want everyone to use the new stuff.

I agree that both the MPI spec and MPI implementations won't be  
removing them any time soon. Perhaps we can say "deprecated" in the  
spec for the old-style interfaces with appropriate language explaining  
that it is just our intent that people use the new stuff -- we're not  
abandoning the millions of LOC of legacy MPI Fortran apps.

> 12. Q: Is it an error if the user gives a non-contiguous buffer to a
> choice argument as it is for C?
>      A: Yes.
>      Unresolved issue:  Should the vendor be required to catch the
> error as always checking the argument is a performance issue.
>

NO!!

I have seen this listed inaccurately in this thread multiple times:  
MPI does *NOT* say that it is an error to give a non-contiguous buffer  
as a choice buffer (in C or any language).  This is *why* MPI has  
datatype arguments -- to describe the type map of the buffer.

As Hubert indicated, it *must* be permissible to pass non-contiguous  
buffers as choice arguments and [somehow] have the underlying MPI do  
the Right Thing.

Staying out of type/syntax discussions on this point for the same  
reasons as #6.

> 13. Q: Should mixed MPI-3 and older MPI code be compatible within the
> same application.
>      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.
>


Yes.

I think we will need to outlaw mixing "include 'mpif.h'", "use mpi",  
and "use mpi3" (or whatever the new one is called) within the same  
block, though.  I'm guessing that the types and/or values of MPI  
constants (e.g., MPI_COMM_WORLD) will conflict between these 3  
mechanisms.

-- 
Jeff Squyres
Cisco Systems

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