<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=us-ascii">
<META content="MSHTML 6.00.2900.3268" name=GENERATOR></HEAD>
<BODY
style="WORD-WRAP: break-word; webkit-nbsp-mode: space; webkit-line-break: after-white-space">
<DIV dir=ltr align=left><SPAN class=515140012-19042008><FONT face=Arial
color=#0000ff size=2>Dear Craig,</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=515140012-19042008><FONT face=Arial
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=515140012-19042008><FONT face=Arial
color=#0000ff size=2>Thanks for the summary. Could you please propose a couple
of definite time slots, to allow everybody select/deselect those he/she can
make? At the moment, having gone thru a couple of replies, I still cannot figure
out when exactly the meeting is going to be held.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=515140012-19042008><FONT face=Arial
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=515140012-19042008><FONT face=Arial
color=#0000ff size=2>Best regards.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=515140012-19042008><FONT face=Arial
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=515140012-19042008><FONT face=Arial
color=#0000ff size=2>Alexander</FONT></SPAN></DIV><BR>
<DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left>
<HR tabIndex=-1>
<FONT face=Tahoma size=2><B>From:</B> mpi3-fortran-bounces@lists.mpi-forum.org
[mailto:mpi3-fortran-bounces@lists.mpi-forum.org] <B>On Behalf Of </B>Craig
Rasmussen<BR><B>Sent:</B> Thursday, April 17, 2008 6:08 PM<BR><B>To:</B> MPI-3
Fortran working group<BR><B>Subject:</B> Re: [MPI3 Fortran] Proposing changes to
Fortran 2008<BR></FONT><BR></DIV>
<DIV></DIV>
<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>On Apr 16, 2008, at 10:33 AM, Hubert Ritzdorf wrote:<BR
class=Apple-interchange-newline>
<BLOCKQUOTE type="cite">
<BLOCKQUOTE type="cite">
<P style="MIN-HEIGHT: 14px; MARGIN: 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: 0px">I am probably looking for an extension of the
ASYNCHRONOUS (not VOLATILE)</DIV>
<P style="MIN-HEIGHT: 14px; MARGIN: 0px"><SPAN
class=Apple-converted-space> </SPAN><BR
class=khtml-block-placeholder></P></BLOCKQUOTE>
<DIV style="MARGIN: 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="MIN-HEIGHT: 14px; MARGIN: 0px"><SPAN
class=Apple-converted-space> </SPAN><BR
class=khtml-block-placeholder></P></BLOCKQUOTE>
<DIV style="MARGIN: 0px">VOLATILE is different. Volatile means that other
processes/threads may change the</DIV>
<DIV style="MARGIN: 0px">data. The effect is, that the run-time system has to
reload each memory location</DIV>
<DIV style="MARGIN: 0px">directly from memory if the application program
accesses a variable.</DIV>
<DIV style="MARGIN: 0px">This kills any type of optimization and significantly
increases the memory traffic.</DIV>
<DIV style="MIN-HEIGHT: 14px; MARGIN: 0px"><BR></DIV>
<DIV style="MARGIN: 0px">MPI nonblocking communication is quite similar to
asynchronous read/write.</DIV>
<DIV style="MARGIN: 0px">Therefore, an extension of ASYNCHRONOUS<SPAN
class=Apple-converted-space> </SPAN>attribute for MPI or other</DIV>
<DIV style="MARGIN: 0px">communication libraries would be most appropriate and
should cause minimal</DIV>
<DIV style="MARGIN: 0px">conflicts with the actual Fortran standard. You can
take most of the description</DIV>
<DIV style="MARGIN: 0px">of the ASYNCHRONOUS attribute and replace
input/output by communication</DIV>
<DIV style="MARGIN: 0px">(only the WAIT doesn't fit, since MPI_Wait is not
know by the Fortran standard).</DIV>
<DIV style="MIN-HEIGHT: 14px; MARGIN: 0px"><BR></DIV>
<DIV style="MARGIN: 0px">For example:</DIV>
<DIV style="MARGIN: 0px">The ASYNCHRONOUS_EXT is an extension of the
ASYNCHRONOUS attribute.</DIV>
<DIV style="MIN-HEIGHT: 14px; MARGIN: 0px"><BR></DIV>
<DIV style="MARGIN: 0px">NOTE 12.26:</DIV>
<DIV style="MARGIN: 0px">The ASYNCHRONOUS_EXT attribute species the variables
that might be associated</DIV>
<DIV style="MARGIN: 0px">with a pending sequence (the actual memory
locations</DIV>
<DIV style="MARGIN: 0px">on which (asynchronous, non-blocking) communication
is being performed)</DIV>
<DIV style="MARGIN: 0px">while the scoping unit is in execution. This
information could be used</DIV>
<DIV style="MARGIN: 0px">by the compiler to disable certain code motion
optimizations.</DIV>
<DIV style="MIN-HEIGHT: 14px; MARGIN: 0px"><BR></DIV>
<DIV style="MARGIN: 0px">Note 5.8:</DIV>
<DIV style="MARGIN: 0px">The constraints on actual arguments that correspond
to a dummy argument</DIV>
<DIV style="MARGIN: 0px">with ASYNCHRONOUS_EXT attribute are designed to avoid
forcing a processor</DIV>
<DIV style="MARGIN: 0px">to use the so-called copy-in/copy-out argument
passing mechanism.</DIV>
<DIV style="MARGIN: 0px">Making a copy of actual arguments whose values are
likely to change due</DIV>
<DIV style="MARGIN: 0px">to a (non-blocking, asynchronous) communication
operation completing or</DIV>
<DIV style="MARGIN: 0px">in some unpredictable manner will cause those new
values to be lost</DIV>
<DIV style="MARGIN: 0px">when a called procedure returns and the copy-out
overwrites the</DIV>
<DIV style="MARGIN: 0px">actual argument or the application program
aborts.</DIV>
<DIV style="MIN-HEIGHT: 14px; MARGIN: 0px"><BR></DIV>
<DIV style="MARGIN: 0px">The ASYNCHRONOUS_EXT attribute is similar to the
VOLATILE and ASYNCHRONOUS</DIV>
<DIV style="MARGIN: 0px">attribute. It is intended to facilitate traditional
code motion optimizations in the presence</DIV>
<DIV style="MARGIN: 0px">of (asynchronous, non-blocking)<SPAN
class=Apple-converted-space> </SPAN>communication.</DIV>
<DIV style="MIN-HEIGHT: 14px; MARGIN: 0px"><BR></DIV>
<BLOCKQUOTE type="cite">
<DIV
style="MARGIN: 0px"><BR></DIV></BLOCKQUOTE></BLOCKQUOTE></DIV><pre>---------------------------------------------------------------------
Intel GmbH
Dornacher Strasse 1
85622 Feldkirchen/Muenchen Germany
Sitz der Gesellschaft: Feldkirchen bei Muenchen
Geschaeftsfuehrer: Douglas Lusk, Peter Gleissner, Hannes Schwaderer
Registergericht: Muenchen HRB 47456 Ust.-IdNr.
VAT Registration No.: DE129385895
Citibank Frankfurt (BLZ 502 109 00) 600119052
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
</pre></BODY></HTML>