[MPI3 Fortran] Request for a straw vote.

[Aleksandar Donev]

On Wednesday 10 June 2009 12:17, Lionel, Steve wrote:

> see that extra_state is defined in the C interface as void*, so
> perhaps what is really wanted here is "TYPE(*),DIMENSION(..)", 
What is the (Fortran) callback going to do with the TYPE(*) object? 
First, the assumed-rank feature DIMENSION(..) makes things more complex 
because it seems awfully hard to do anything useful to such an object 
(our present draft says it can be used as an argument to C_LOC but I 
have no idea what the intention is with respect to non-contiguous 
objects).

Secondly, if the only choice one has is to use C_LOC/C_F_POINTER to get 
a pointer to the object to make it useable, this still requires TARGET, 
and makes things more complex to use than a plain TYPE(C_PTR) object, 
without any apparent benefit?

> If C_PTR is to be used here then why not also
> for the BUF arguments?
Because it requires TARGET and interoperability. TARGET is completely 
unnecessary, especially for the blocking calls (no address to the 
argument is ever saved anywhere). Further, because it does not allow 
for non-contiguous sections to be passed. It does not allow INTENTs to 
be specified. Nor does it allow specifying other attributes (say 
ASYNCHRONOUS). I am 100% convinced C_PTR is not the right answer.

> 6. Q: How should type and rank be specified for buffer choice
> arguments? A: TYPE(*), DIMENSION(..)

> To the best of my knowledge, use of this syntax does not stop
> copyin/out.
Correct, although that can be changed. The present philosophy is that 
copy in/out is only disallowed in situations where it breaks something, 
and it requires special annotation (e.g., a TARGET attribute on both 
the dummy and actual). Just because something *can* in principle be 
passed without copy does not mean copy is disallowed, nor, in fact, 
that it won't happen (some compilers have switches for "always copy to 
contiguous temps even if dummy is assumed-shape" since that may be 
faster)

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

> [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.
I am with Steve but am also confused about what Craig meant.

> 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.
>
> [sl] Yes, it is an error.
I am 100% confused. Surely with the present interface one can do:

CALL MPI_Send(buffer(1:10:2),...)

and the compiler will make a temporary contiguous copy and this is legal 
and works and users use it???

Is it being proposed that this be illegal?

If you use DIMENSION(..) then it makes no sense to make it an error to 
pass a non-contiguous section. Use DIMENSION(*) instead. But that still 
allows non-contiguous actuals, only the compiler must make a copy.

>  I think it would be useful to include CONTIGUOUS in
> the list of attributes for arguments that must be contiguous.
CONTIGUOUS on a dummy does not mean the actual has to be contiguous. It 
means the dummy is contiguous. If the actual is not, a copy is by the 
compiler.

Best,
Aleks

-- 
Aleksandar Donev, Ph.D.
Lawrence Postdoctoral Fellow @ Lawrence Livermore National Laboratory
High Performance Computational Materials Science and Chemistry
E-mail: donev1 at llnl.gov
Phone: (925) 424-6816  Fax: (925) 423-0785
Address: P.O.Box 808, L-367, Livermore, CA 94551-9900
Web: http://cims.nyu.edu/~donev/