<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">
<div>From my point of view the discussions so far have been exceptional.  They are bringing out the precise problems we have in calling MPI from Fortran.  I would like to have a conference call next week to discuss these issues further.  Could we have a call early Tuesday morning so that both European and American continents can participate?  What would be the latest time for a call from a European perspective?</div><div><br></div><div>A couple of general comments on the discussions so far:</div><div><br></div><div>1. Regarding copyin/copyout.  The difficulty here arises from the fact that Fortran has richer array semantics than does C; in this instance it is a much higher-level language than C.  Therefore one SHOULD expect problems in calling C from Fortran if one steps outside of the bounds of the Fortran C interop standard.  It is not the fault of Fortran nor compiler implementations.</div><div><br></div><div>2. However, given the performance penalty of the target attribute, it would be appropriate for the MPI Forum to request that the Fortran committee try to fix this performance problem by changing the standard.  I'll draft a letter that Rich Graham could send to the J3 commitee.  We can discuss the letter at the next MPI Forum meeting.</div><div><br></div><div>3. Regarding the ASYNCHRONOUS extension Hubert suggests.  Bill Long (Cray) on the J3 committee has already mentioned something like this as a possibility.  Since Bill is head of the HPC subcommittee on J3, I'm sure we will discuss this at the next J3 committee meeting in May.</div><div><br></div><div>4.  It may be that the two committees (J3 and MPI Forum) can arrive at a solution that maintains performance AND clearly spells out what won't work and the Fortran MPI programmer should not attempt to do, even if it happens to work for one compiler or particular section of code.  The Fortran standard has lots of "thou shalt nots" and the MPI Fortran standard should specify constraints as well, where appropriate.  One of these constraints was already pointed out by Aleks that one is not allowed to read or modify variables while asynchronous input I/O is pending.</div><div><br></div><div>Regards,</div><div>Craig</div><div><br></div><br><div><html>On Apr 16, 2008, at 10:33 AM, Hubert Ritzdorf wrote:</html><br class="Apple-interchange-newline"><blockquote type="cite"><blockquote type="cite"><p style="margin: 0.0px 0.0px 0.0px 0.0px; min-height: 14.0px"><span class="Apple-converted-space"><font class="Apple-style-span" color="#0000DD"><span class="Apple-style-span" style="-webkit-text-stroke-width: -1;"><br></span></font>  </span><br class="khtml-block-placeholder"></p> <blockquote type="cite"><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">I am probably looking for an extension of the ASYNCHRONOUS (not VOLATILE)</div><p style="margin: 0.0px 0.0px 0.0px 0.0px; min-height: 14.0px"><span class="Apple-converted-space">    </span><br class="khtml-block-placeholder"></p> </blockquote><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">Why not VOLATILE---is there a difference? The only difference, as far as I know, is that ASYNC is restricted to Fortran async I/O, and volatile for everyting "outside of the Fortran standard". Sounds to me like VOLATILE is exactly what you want. Unless you want somewhat different semantics/constraints (which is not presently the case---the only difference I know is that ASYNC attribute is implicitly given to variables involved in async I/O, while VOLATILE must be explicit).</div><p style="margin: 0.0px 0.0px 0.0px 0.0px; min-height: 14.0px"><span class="Apple-converted-space">  </span><br class="khtml-block-placeholder"></p> </blockquote><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">VOLATILE is different. Volatile means that other processes/threads may change the</div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">data. The effect is, that the run-time system has to reload each memory location</div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">directly from memory if the application program accesses a variable.</div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">This kills any type of optimization and significantly increases the memory traffic.</div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><br></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">MPI nonblocking communication is quite similar to asynchronous read/write.</div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">Therefore, an extension of ASYNCHRONOUS<span class="Apple-converted-space">  </span>attribute for MPI or other</div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">communication libraries would be most appropriate and should cause minimal</div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">conflicts with the actual Fortran standard. You can take most of the description</div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">of the ASYNCHRONOUS attribute and replace input/output by communication</div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">(only the WAIT doesn't fit, since MPI_Wait is not know by the Fortran standard).</div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><br></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">For example:</div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">The ASYNCHRONOUS_EXT is an extension of the ASYNCHRONOUS attribute.</div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><br></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">NOTE 12.26:</div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">The ASYNCHRONOUS_EXT attribute species the variables that might be associated</div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">with a pending sequence (the actual memory locations</div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">on which (asynchronous, non-blocking) communication is being performed)</div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">while the scoping unit is in execution. This information could be used</div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">by the compiler to disable certain code motion optimizations.</div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><br></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">Note 5.8:</div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">The constraints on actual arguments that correspond to a dummy argument</div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">with ASYNCHRONOUS_EXT attribute are designed to avoid forcing a processor</div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">to use the so-called copy-in/copy-out argument passing mechanism.</div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">Making a copy of actual arguments whose values are likely to change due</div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">to a (non-blocking, asynchronous) communication operation completing or</div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">in some unpredictable manner will cause those new values to be lost</div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">when a called procedure returns and the copy-out overwrites the</div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">actual argument or the application program aborts.</div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><br></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">The ASYNCHRONOUS_EXT attribute is similar to the VOLATILE and ASYNCHRONOUS</div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">attribute. It is intended to facilitate traditional code motion optimizations in the presence</div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">of (asynchronous, non-blocking)<span class="Apple-converted-space">  </span>communication.</div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><br></div> <blockquote type="cite"><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><br></div></blockquote></blockquote></div></body></html>