[MPI3 Fortran] mpi3-fortran Digest, Vol 6, Issue 7
Carlos Avila
cavila67 at yahoo.com
Tue Sep 9 07:43:34 CDT 2008
Dear friends,
Would you please let me know some references about MPMD programming paradigm.
Thanks in advance,
Carlos
--- On Tue, 9/9/08, mpi3-fortran-request at lists.mpi-forum.org <mpi3-fortran-request at lists.mpi-forum.org> wrote:
From: mpi3-fortran-request at lists.mpi-forum.org <mpi3-fortran-request at lists.mpi-forum.org>
Subject: mpi3-fortran Digest, Vol 6, Issue 7
To: mpi3-fortran at lists.mpi-forum.org
Date: Tuesday, September 9, 2008, 7:20 PM
Send mpi3-fortran mailing list submissions to
mpi3-fortran at lists.mpi-forum.org
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-fortran
or, via email, send a message with subject or body 'help' to
mpi3-fortran-request at lists.mpi-forum.org
You can reach the person managing the list at
mpi3-fortran-owner at lists.mpi-forum.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of mpi3-fortran digest..."
Today's Topics:
1. Re: [Fwd: Library-based ASYNCHRONOUS I/O and SYNC MEMORY]
(Jeff Squyres)
2. Re: [Fwd: Library-based ASYNCHRONOUS I/O and SYNC MEMORY]
(Aleksandar Donev)
3. Re: [Fwd: add TYPE(*) and DIMENSION(..) to Fortran]
(Aleksandar Donev)
4. Re: [Fwd: Library-based ASYNCHRONOUS I/O and SYNC MEMORY]
(Dan Nagle)
5. Re: [Fwd: Library-based ASYNCHRONOUS I/O and SYNC MEMORY]
(Iain Bason)
6. Re: [Fwd: Library-based ASYNCHRONOUS I/O and SYNC MEMORY]
(Dan Nagle)
----------------------------------------------------------------------
Message: 1
Date: Mon, 8 Sep 2008 12:29:42 -0400
From: Jeff Squyres <jsquyres at cisco.com>
Subject: Re: [MPI3 Fortran] [Fwd: Library-based ASYNCHRONOUS I/O and
SYNC MEMORY]
To: MPI-3 Fortran working group <mpi3-fortran at lists.mpi-forum.org>
Message-ID: <DAD44671-98C0-4B1B-85A8-5B898063B0F4 at cisco.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
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
------------------------------
Message: 2
Date: Mon, 8 Sep 2008 09:59:56 -0700
From: Aleksandar Donev <donev1 at llnl.gov>
Subject: Re: [MPI3 Fortran] [Fwd: Library-based ASYNCHRONOUS I/O and
SYNC MEMORY]
To: mpi3-fortran at lists.mpi-forum.org
Message-ID: <200809080959.56639.donev1 at llnl.gov>
Content-Type: text/plain; charset="iso-8859-1"
On Monday 08 September 2008 09:29, Jeff Squyres wrote:
> Or does noopt_begin() also disable array subset copies?
You have hit the nail here. These kinds of proposals always seem simpler at
first then they really are. You have to integrate then into the language so
they not only make sense but work with all the other language features. It is
not easy, and if you ask for too much you will get nothing (this is what
happened to interval arithmetic folks some time ago).
You are right that SYNC MEMORY is expensive, a big hammer, and one can do
better. But we did not do SYNC MEMORY(variable) for coarrays (or some similar
alternative) exactly because it was hard to figure out all the details in the
time and resources available.
Best,
Aleks
--
Aleksandar Donev, Ph.D.
Lawrence Postdoctoral Fellow @ Lawrence Livermore National Laboratory
High Performance Computational Materials Science and Chemistry
E-mail: donev1 at llnl.gov
Phone: (925) 424-6816 Fax: (925) 423-0785
Address: P.O.Box 808, L-367, Livermore, CA 94551-9900
Web: http://cherrypit.princeton.edu/donev
------------------------------
Message: 3
Date: Mon, 8 Sep 2008 10:10:02 -0700
From: Aleksandar Donev <donev1 at llnl.gov>
Subject: Re: [MPI3 Fortran] [Fwd: add TYPE(*) and DIMENSION(..) to
Fortran]
To: MPI-3 Fortran working group <mpi3-fortran at lists.mpi-forum.org>
Message-ID: <200809081010.02938.donev1 at llnl.gov>
Content-Type: text/plain; charset="iso-8859-1"
Hi,
> E.g., if I call MPI_SEND with foo(13, ?
> 10:20, 1:5), will MPI get a contiguous region of memory (which it ?
> always seems to today...?), or will we get a descriptor that a) points ?
> to the beginning of the memory, and b) has a description of the layout?
>
> I *think* you're telling me that we can have it both ways (let's ?
> assume blocking MPI_SEND for the moment, for simplicity):
Yes, you can have both ways.
> 1. an MPI_SEND that takes an explicit MPI datatype argument and ?
> returns contiguous memory (probably a copy if the original memory is ?
> not contiguous).
Declare the dummy argument in the interface to MPI_Send as:
type(*), dimension(*) :: buffer
This is how the present MPI bindings work, but without the type(*) which
avoids the problem with type matching.
> It is this case that could be problematic if the ?
> user specifies an MPI datatype that reflects the true sparseness of ?
> the memory, but the compiler has copied it into a temporary contiguous ?
> buffer.
Yes, that is a problem [also exists in present bindings unless you pass
foo(13, 10, 1) as the actual without the section subscripts].
The type(*) proposal assumes that the type is *assumed* from the actual,
rather than being some "type-map" defined externally to the language.
If you want to do type-maps, then use:
type(c_ptr), value :: buffer ! Fortran 2003
which explicitly passes the base address (C address) of the buffer to MPI.
Then inside MPI you can address memory as you wish. The buffer that is passed
must have the TARGET attribute and be of interoperable type (BIND(C) type).
> 2. an MPI_SEND that takes no MPI datatype argument but passes the ?
> Fortran descriptor to MPI, so that MPI can build up its own MPI ?
> datatype and use that instead of having the user explicitly mention ?
> it.
Yes, you can, just declare the dummy argument in the interface to MPI_Send as:
type(*), dimension(..) :: buffer
> This could be expensive if the type map is complex (e.g., non-
> contiguous), especially for short messages. ?If the type map is simple ?
> (e.g., contiguous, single pre-defined Fortran type -- not a Fortran ?
> user-defined struct), we might be able to have a simple switch/case ?
> (or a set of overloaded functions or ...) that can deduce the correct ?
> Fortran datatype -> MPI datatype mapping properly.
Yes, I was expecting something like an internal switch.
And yes, you are right that this is "building on top of MPI". You are
adding a
high-level interface on top of a work library. I don't see what is wrong
with
that. It can be external to MPI-3 document itself, i.e., it can be a Fortran
module that is added to the standard C MPI-3 bindings. Say a techical report
of some sort.
Hope this clarified. Feel free to ask more questions. Conference calls are
fine with me too but they have to be after 10am pacific time and scheduled at
least a day in advance.
Thanks.
Aleks
--
Aleksandar Donev, Ph.D.
Lawrence Postdoctoral Fellow @ Lawrence Livermore National Laboratory
High Performance Computational Materials Science and Chemistry
E-mail: donev1 at llnl.gov
Phone: (925) 424-6816 Fax: (925) 423-0785
Address: P.O.Box 808, L-367, Livermore, CA 94551-9900
Web: http://cherrypit.princeton.edu/donev
------------------------------
Message: 4
Date: Mon, 08 Sep 2008 13:55:59 -0400
From: Dan Nagle <dannagle at verizon.net>
Subject: Re: [MPI3 Fortran] [Fwd: Library-based ASYNCHRONOUS I/O and
SYNC MEMORY]
To: MPI-3 Fortran working group <mpi3-fortran at lists.mpi-forum.org>
Message-ID: <2AFD8FF1-5972-404B-A37A-12856A62FFE4 at verizon.net>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Hi,
On Sep 8, 2008, at 12:29 PM, Jeff Squyres wrote:
> 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.
This is why I would prefer to apply any new attribute
to a dummy argument rather than to the name in the caller.
>
>
> Or does noopt_begin() also disable array subset copies?
That depends upon how it is defined, I guess. :-)
The greatest difficulty I see is to link the asynchronous-ness
to the call *and then to the wait* affecting only the portion
of the caller's name actually needed.
My main concern is with things declared like buffer( ..., 2),
where buffer( ..., 1) and buffer( ..., 2) are used as double buffers
where work and transmission alternate. I think this
case is rather common, but I haven't made a survey.
>
>
>
> 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
>
> _______________________________________________
> mpi3-fortran mailing list
> mpi3-fortran at lists.mpi-forum.org
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-fortran
--
Cheers!
Dan Nagle
------------------------------
Message: 5
Date: Mon, 08 Sep 2008 15:09:53 -0400
From: Iain Bason <Iain.Bason at Sun.COM>
Subject: Re: [MPI3 Fortran] [Fwd: Library-based ASYNCHRONOUS I/O and
SYNC MEMORY]
To: MPI-3 Fortran working group <mpi3-fortran at lists.mpi-forum.org>
Message-ID: <566189E4-8221-4C6D-81DF-7E09549DD31E at sun.com>
Content-Type: text/plain; delsp=yes; format=flowed; charset=US-ASCII
[Just to introduce myself to those who don't know me, I am a member of
the Sun Fortran compiler development team. I meant to join this email
alias a while ago, but only just got around to it.]
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.
Why is that necessary? Which optimizations do you think need to be
disabled?
So far as MPI asynchronous send/receive are concerned, I don't see any
reason to disable any optimizations aside from those that move access
to the buffer across a call to MPI_ISEND/MPI_IRECV/MPI_WAIT. What you
are proposing is going to have a much bigger impact on performance.
On Sep 8, 2008, at 1:55 PM, Dan Nagle wrote:
>
> The greatest difficulty I see is to link the asynchronous-ness
> to the call *and then to the wait* affecting only the portion
> of the caller's name actually needed.
>
> My main concern is with things declared like buffer( ..., 2),
> where buffer( ..., 1) and buffer( ..., 2) are used as double buffers
> where work and transmission alternate. I think this
> case is rather common, but I haven't made a survey.
This is a case where I suspect a blunt hammer will do just as well.
For example, suppose we had a way to inhibit all code motion across a
call to MPI_WAIT. That could inhibit an optimization that the
compiler could do if it knew more about what MPI_WAIT was doing, but I
suspect you would be hard pressed to come up with an example where it
mattered.
In the particular case of these double buffers, I think you're talking
about something like this:
01: do i=1,n
02: mpi_isend(buffer(..., 1), ..., b1)
03: mpi_wait(b2)
04: do something with buffer(..., 2)
05: mpi_isend(buffer(..., 2), ..., b2)
06: mpi_wait(b1)
07: do something with buffer(..., 1)
08: end do
You can only access buffer(...,2) at line 4, because at the other
lines it is "in flight". Therefore, there's no problem with
inhibiting code motion for buffer(...,2) across the mpi_wait call on
line 6.
Likewise, you can only access buffer(...,1) at line 7, so there's no
problem with inhibiting code motion for it across line 3.
Can you come up with an example of this dual buffer usage where
performance would actually require the kind of precise control you're
talking about?
Iain
------------------------------
Message: 6
Date: Tue, 09 Sep 2008 08:19:53 -0400
From: Dan Nagle <dannagle at verizon.net>
Subject: Re: [MPI3 Fortran] [Fwd: Library-based ASYNCHRONOUS I/O and
SYNC MEMORY]
To: MPI-3 Fortran working group <mpi3-fortran at lists.mpi-forum.org>
Message-ID: <910B5814-828F-4C40-AF3B-5FF8AAF55EB6 at verizon.net>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Hello,
Look, MPI works with Fortran, and it has for years.
There's no emergency. We can take our time and
do things right to make the Fortran interface
to MPI routines easier to define, to maintain, and to use.
Doing so will also benefit Fortran interfaces to other
libraries where asynchronous modifications are expected,
and where procedures are expected to accept actual arguments
of any type, kind, rank.
On Sep 8, 2008, at 3:09 PM, Iain Bason wrote:
>
> Can you come up with an example of this dual buffer usage where
> performance would actually require the kind of precise control
> you're talking about?
Personally (and others may differ), I believe the main issue
is to better document what happens with asynchronous modifications
to actual arguments after the initiating routine has returned.
Generally, this is surprising to a standards conforming program.
If a compiler (even one at some time in the future)
can use the information profitably, so much the better.
But the main issue, to me at least, is to document,
*in the program*, what is expected to happen. Having this
information in the source file helps the applications writer,
the applications maintainer, and any code checking tools
brought to bear.
--
Cheers!
Dan Nagle
------------------------------
_______________________________________________
mpi3-fortran mailing list
mpi3-fortran at lists.mpi-forum.org
http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-fortran
End of mpi3-fortran Digest, Vol 6, Issue 7
******************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mpi-forum.org/pipermail/mpiwg-fortran/attachments/20080909/f78ea152/attachment.html>
More information about the mpiwg-fortran
mailing list