[MPI3 Fortran] Proposing changes to Fortran 2008

Sat Apr 19 07:02:04 CDT 2008

Dear Craig,

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.

Best regards.

Alexander

________________________________

From: mpi3-fortran-bounces at lists.mpi-forum.org
[mailto:mpi3-fortran-bounces at lists.mpi-forum.org] On Behalf Of Craig
Rasmussen
Sent: Thursday, April 17, 2008 6:08 PM
To: MPI-3 Fortran working group
Subject: Re: [MPI3 Fortran] Proposing changes to Fortran 2008

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

A couple of general comments on the discussions so far:

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.

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.

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.

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.

Regards,
Craig

On Apr 16, 2008, at 10:33 AM, Hubert Ritzdorf wrote:

			I am probably looking for an extension of the
ASYNCHRONOUS (not VOLATILE)

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

	VOLATILE is different. Volatile means that other
processes/threads may change the
	data. The effect is, that the run-time system has to reload each
memory location
	directly from memory if the application program accesses a
variable.
	This kills any type of optimization and significantly increases
the memory traffic.

	MPI nonblocking communication is quite similar to asynchronous
read/write.
	Therefore, an extension of ASYNCHRONOUS  attribute for MPI or
other
	communication libraries would be most appropriate and should
cause minimal
	conflicts with the actual Fortran standard. You can take most of
the description
	of the ASYNCHRONOUS attribute and replace input/output by
communication
	(only the WAIT doesn't fit, since MPI_Wait is not know by the
Fortran standard).

	For example:
	The ASYNCHRONOUS_EXT is an extension of the ASYNCHRONOUS
attribute.

	NOTE 12.26:
	The ASYNCHRONOUS_EXT attribute species the variables that might
be associated
	with a pending sequence (the actual memory locations
	on which (asynchronous, non-blocking) communication is being
performed)
	while the scoping unit is in execution. This information could
be used
	by the compiler to disable certain code motion optimizations.

	Note 5.8:
	The constraints on actual arguments that correspond to a dummy
argument
	with ASYNCHRONOUS_EXT attribute are designed to avoid forcing a
processor
	to use the so-called copy-in/copy-out argument passing
mechanism.
	Making a copy of actual arguments whose values are likely to
change due
	to a (non-blocking, asynchronous) communication operation
completing or
	in some unpredictable manner will cause those new values to be
lost
	when a called procedure returns and the copy-out overwrites the
	actual argument or the application program aborts.

	The ASYNCHRONOUS_EXT attribute is similar to the VOLATILE and
ASYNCHRONOUS
	attribute. It is intended to facilitate traditional code motion
optimizations in the presence
	of (asynchronous, non-blocking)  communication.

---------------------------------------------------------------------
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mpi-forum.org/pipermail/mpiwg-fortran/attachments/20080419/3ddaffa3/attachment-0001.html>