(j3.2006) [MPI3 Fortran] Effect of volatile

Bill Long longb
Mon Dec 22 19:27:02 EST 2008



Craig Rasmussen wrote:
> At the MPI Forum meeting this week there was a discussion on the 
> effects of volatile (the subject has come up on the WG5 list as well) 
> on performance.  MPI users are very concerned about performance and 
> are worried that providing the volatile attribute to an array will 
> substantially affect performance.  However, I think the following 
> should work with minimal  performance implications:
>
> ---------------------
>
>     buf(1) = 1
>     call MPI_Irecv(buf, ...., request,...)
>
>     ! .... do work without buf
>
>     BLOCK
>         volatile :: buf
>         call MPI_Wait(request, ...)
>     END BLOCK
>
>    ! now buf is ready to use
>
>    x = buf(1)
>
> ---------------------
>
> I believe that the effects of the volatile statement within the block 
> is AS IF MPI_Wait were called with buf as a parameter and the dummy 
> variable was INTENT(INOUT): any registers containing values associated 
> with buf will be flushed and code motion will be restricted.  Volatile 
> would only be in effect within the block construct and would not have 
> any performance implications otherwise.  At the assignment statement, 
> x = buf(1), the value assigned to x would have to be retrieved from 
> memory and could not be obtained from a register.

Interesting idea.  I'm a bit concerned about the last sentence above.  
Buf is not (declared to be) volatile at the point of the x = buf(1) 
statement.  Are you suggesting that the volatility specified in the 
BLOCK "leaks" out to subsequent statements?  If so, how far does the 
leakage extend?  To the end of the program unit?  If so, you may have 
lost some of the performance you were hoping to keep.   Actually,  I 
would expect that the volatility of buf is only inside the block, and 
there is no leakage outside the block.  While this might work as a 
practical matter, I don't think the language semantics requires that.  
The construct also fails to meet the goal of avoiding user source code 
changes, though I see that as a secondary issue.

Cheers,
Bill

>
> I should note that buf can't actually be passed as a parameter to 
> MPI_Wait as the request handle could be associated with any number of 
> variables, not just buf.
>
> Regards,
> Craig
>
>
>
>
>
>
>
>  
>   _______________________________________________
> mpi3-fortran mailing list
> mpi3-fortran at lists.mpi-forum.org
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-fortran

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

            




More information about the J3 mailing list