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

[Jeff Squyres]

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.

Or does noopt_begin() also disable array subset copies?


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