[MPI3 Fortran] Request for a straw vote.

[Craig Rasmussen]

On Jun 11, 2009, at 12:53 PM, Aleksandar Donev wrote:

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

Drat, I thought copy-in/copy-out was solved.  If the compiler does  
copy-in/copy-out what does the dope vector look like?  This will be in  
a BIND(C) interface so I think the compiler should know it can't  
control optimizations and shouldn't do copy-in/copy-out, it should  
just pass the original dope vector.

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

I meant the choice between the following:

1.
      subroutine MPI_Send(buf, ...)
          <type> :: buf

2.
      subroutine MPI_Send(buf, ...)
          TYPE(*), DIMENSION(..) :: buf

I think a real Fortran interface should be provided in the MPI  
standard (one per procedure).

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

We can't use generic resolution for DIMENSION(*) (my proposal to do so  
two J3 meetings ago went down in spectacular flames), thus,  
DIMENSION(..) is the choice.  Now the MPI vendor must deal with non- 
contiguous buffers as in your example

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

Since the C semantics don't allow for non-contiguous buffers, the MPI  
standard could decide to say this is an error and have the MPI vendor  
return an error condition.  It seems the vendors are at least thinking  
about doing the "right" thing and essentially doing the copy-in/copy- 
out into an MPI internal buffer, taking into account the strided  
nature of the request.

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

No, as I hoped I explained above, this is an MPI thing and the MPI  
vendors are going to deal with array descriptors, so we don't want the  
CONTIGUOUS attribute.

-craig