(j3.2006) [MPI3 Fortran] Feedback from Fortran J3 meeting

[Bill Long]

Just a reminder that specifying VOLATILE for the actual and 
corresponding dummy arguments is only to prevent copy-in/copy-out of the 
argument to the MPI routine.  Preventing copy-in/copy-out is the goal 
here. The other, normal aspects of VOLATILE are not relevant for this 
example.   ASYNCHRONOUS has the same effect, but the defect that a WAIT 
statement could change its effect.

Cheers,
Bill


Craig Rasmussen wrote:
> This may not be as bad as it seems as VOLATILE can be limited to a  
> BLOCK construct (sorry, it's just BLOCK not BEGIN BLOCK as I have  
> below).  Since the caller won't reference the memory between MPI_Irecv  
> and MPI_Wait, this shouldn't be a problem for VOLATILE on the actual.   
> Plus, since the implementation will likely be in C (which can ignore  
> the VOLATILE dummy), there shouldn't be a performance hit on the  
> callee either.
>
> I was skeptical about this as well, but Aleks reminded me that the  
> effects of VOLATILE could be limited to a BLOCK construct.
>
> Cheers,
> Craig
>
>
> On May 27, 2008, at 9:55 AM, Dan Nagle wrote:
>
>   
>> Hi,
>>
>> I think we blundered with 08-185r1.
>>
>> Specifically, VOLATILE is exactly the wrong attribute.
>> VOLATILE means "always go to memory" for this variable.
>> The MPI specification says "don't touch the buf memory" between
>> the MPI async send/recv and the MPI wait.  (The other actual args
>> may be treated ordinarily.)
>>
>> What Fortran should say is "between these two subroutine references,
>> don't read/write this actual argument" and I don't think we currently
>> have a way to say that.  :-(
>>
>> It's not so much that VOLATILE is too big a hammer,
>> it's that a hammer is exactly the wrong tool for this task.
>>
>> So I think we talked ourselves into a blunder with this one.
>> Never design things quickly.  :-)
>>
>> On May 27, 2008, at 11:43 AM, Craig Rasmussen wrote:
>>
>>     
>>> Two weeks ago I attended the Fortran J3 standards meeting where I
>>> discussed with them the issues surrounding new Fortran MPI
>>> bindings.  They were very receptive to our needs and instructed me
>>> to write a J3 paper in response (attached).  In summary, J3 will try
>>> to get changes made in the Fortran standard so that we won't need to
>>> use CLOC(buffer) for a void* buffer argument.  J3 still hasn't
>>> decided the best way to do this but the likely favorite is a new
>>> type, TYPE(*), as an interoperable type with void*.
>>>
>>> J3 also decided that the way to limit copyin/copyout semantics and
>>> code motion in asynchronous MPI calls is to use the volatile
>>> attribute on both Fortran actual and dummy arguments.  The
>>> performance effects of volatile could be limited with the use of the
>>> new F2008 block construct.  For example,
>>>
>>>
>>>   real, dimension(100) :: buffer
>>>
>>>   BEGIN BLOCK
>>>       VOLATILE :: buf
>>>       err = MPI_Irecv(buf, ..., req)
>>>       .
>>>       .
>>>       err = MPI_Wait(req, ...)
>>>   END BLOCK
>>>
>>> The interface for MPI_Irecv would have something like
>>>
>>>   TYPE(*), volatile :: buf
>>>
>>> Cheers,
>>> Craig
>>>
>>> <08-185r1.txt>
>>>
>>>
>>> _______________________________________________
>>> mpi3-fortran mailing list
>>> mpi3-fortran at lists.mpi-forum.org
>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-fortran
>>>       
>> -- 
>> Cheers!
>>
>> Dan Nagle
>>
>>
>>
>>
>> _______________________________________________
>> J3 mailing list
>> J3 at j3-fortran.org
>> http://j3-fortran.org/mailman/listinfo/j3
>>     
>
> _______________________________________________
> J3 mailing list
> J3 at j3-fortran.org
> http://j3-fortran.org/mailman/listinfo/j3
>   

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