[MPI3 Fortran] [Fwd: Library-based ASYNCHRONOUS I/O and SYNC MEMORY]

[Dan Nagle]

Hi,

On Sep 8, 2008, at 12:29 PM, Jeff Squyres wrote:

> Would this also apply to array subsets, e.g., if I called  
> MPI_Isend() with foo(1:20, 5:7, 27:92)?  In that case, I only care  
> about the array subset -- whether it was passed as the original  
> array or as a copy.

This is why I would prefer to apply any new attribute
to a dummy argument rather than to the name in the caller.
>
>
> Or does noopt_begin() also disable array subset copies?

That depends upon how it is defined, I guess.  :-)

The greatest difficulty I see is to link the asynchronous-ness
to the call *and then to the wait* affecting only the portion
of the caller's name actually needed.

My main concern is with things declared like buffer( ..., 2),
where buffer( ..., 1) and buffer( ..., 2) are used as double buffers
where work and transmission alternate.  I think this
case is rather common, but I haven't made a survey.
>
>
>
> On Sep 7, 2008, at 6:24 AM, Hubert Ritzdorf wrote:
>
>> Hi,
>>
>> also I think that a begin and end section is required and the  
>> compiler needs
>> full control. One possibility would be:
>>
>> !cdir noopt_begin{buffer1, buffer2, buffer3)
>> ...
>> !cdir noopt_end (buffer1)
>> ...
>> !cdir noopt_end (buffer1, buffer2)
>>
>> which simply turns off any optimization for the buffers
>> "buffer1, buffer2, buffer3" within the block defined by
>> "begin" and "end" such as the Fortran compiler knows
>> the buffers "buffer1, buffer2, buffer3". The user program
>> is responsible to provide enough Fortran internal info
>> on the buffers.
>>
>> More specific:
>>
>> !cdir noopt_begin{buffer1, buffer2, buffer3}
>>  should inform the compiler that the buffers
>>  (as the compilers knows them) are used by some other interface.
>>  The compiler should
>>    (*) all register optimiation concerning buffer1, buffer2, buffer3
>>          write back to memory
>>    (*) not move any statement into/out the begin/end block
>>         of "no optimization"
>>    (*) not remove "buffer1, buffer2 or buffer3" before the
>>         corresponding "noopt_end" directive for the corresponding
>>         buffer within the compile unit is reached
>>
>> !cdir noopt_end(buffer)
>>   should inform the compiler that
>>   (*) optimization is now allowed again
>>   (*) no code corresponding buffer (as it is known by the
>>         Fortran compiler) should be moved before the "noopt_end"
>>         directive
>>
>> The end of a compile unit implicitly specifies the end of all  
>> "noopt_begin"
>> directives which were not already finished.
>>
>> I assume that SYNC MEMORY will implicitly flush the memory or
>> perform an internal barrier which might be to expensive in general
>> case.
>>
>> Hubert
>>
>> Dan Nagle wrote:
>>> Hello,
>>>
>>> On Sep 6, 2008, at 6:40 AM, Jeff Squyres wrote:
>>>
>>>> FWIW, my $0.02 is that it would be great if Fortran allowed  
>>>> temporary aliases of buffers.  It could be clearly marked where  
>>>> aliases begin and end.
>>>
>>>
>>> How does the compiler know that one library routine
>>> is the start of an asynchronous region for one name,
>>> or sub-part of one name, and another routine marks the end?
>>> As far as the compiler is concerned, there's nothing
>>> special about the names of the library routines.
>>>
>>> At the expense of some simplification,
>>>
>>> call start_it( a, i)
>>> ...
>>> call end_it( i)
>>>
>>> and what is sought is a way to indicate that calling
>>> start_it() marks 'a' as asynchronous until end_it()
>>> is called.  But 'a' doesn't appear as an argument to end_it() !
>>> There can be several 'a's and 'i's in flight at one time.
>>>
>>>> It would also be great if these aliases could be on a per-buffer  
>>>> basis -- an all-or-nothing approach like SYNC MEM is good, but  
>>>> per-buffer granularity would be better.
>>>
>>> I suspect that some attribute for dummy arguments
>>> expressed in an interface is the way to go, rather than
>>> attributes applied to an entire scoping unit.  Perhaps
>>> we must place 'a' on the call to end_it() somehow.
>>>
>>>> I don't need to touch any compiler/RTL data -- I just want the  
>>>> compiler/runtime/whatever to let me have the user's buffer "in  
>>>> the background" for a while.
>>>
>>> We agree on the goal.
>>> How do we get there?
>>>
>>
>> _______________________________________________
>> mpi3-fortran mailing list
>> mpi3-fortran at lists.mpi-forum.org
>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-fortran
>
>
> -- 
> 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

-- 
Cheers!

Dan Nagle