MPI code error raises a question
Gib Bogle
that was bedeviling me with Heisenbugs. One of the arguments to
MPI_RECV is an integer array status(MPI_STATUS_SIZE). In one place I'd
forgotten to make it an array, and just declared it as integer.
Interested consequences followed from this little mistake.
I'm wondering if this is the kind of error that a compiler might be able
to detect.
Steve Lionel
wrote:
If an explicit interface for the called routine was provided, absolutely. The
standard prohibits passing a scalar variable to an array argument (with a
minor exception for CHARACTER variables passed to arrays of CHARACTER(1)).
--
Steve Lionel
Developer Products Division
Intel Corporation
Nashua, NH
For email address, replace "invalid" with "com"
User communities for Intel Software Development Products
http://softwareforums.intel.com/
Intel Fortran Support
http://support.intel.com/support/performancetools/fortran
My Fortran blog
http://www.intel.com/software/drfortran
Gib Bogle
> On Thu, 08 May 2008 08:42:32 +1200, Gib Bogle <bo...@ihug.too.much.spam.co.nz>
> wrote:
>
>> With a little help from my friends I have found the error in my MPI code
>> that was bedeviling me with Heisenbugs. One of the arguments to
>> MPI_RECV is an integer array status(MPI_STATUS_SIZE). In one place I'd
>> forgotten to make it an array, and just declared it as integer.
>> Interested consequences followed from this little mistake.
>>
>> I'm wondering if this is the kind of error that a compiler might be able
>> to detect.
>
> If an explicit interface for the called routine was provided, absolutely. The
> standard prohibits passing a scalar variable to an array argument (with a
> minor exception for CHARACTER variables passed to arrays of CHARACTER(1)).
Since the MPI library is accessed via a USE statement, doesn't this
imply that the same information is available to the compiler as an
explicit interface would provide?
Richard Maine
> Since the MPI library is accessed via a USE statement, doesn't this
> imply that the same information is available to the compiler as an
> explicit interface would provide?
No, that doesn't follow. It might happen to be true for MPI in specific;
I don't know. But it does not follow from being accessed via a USE
statement.
It is perfectly possible to access implicit-interface procedures via
USE. Admitedly, the most common type of procedure to access via use
would be a module procedure, in which case the USE does provide an
explicit interface. But "Access via USE" does not directly imply "module
procedure".
For a trivial example, consider
module some_module
external some_procedure
end module
This is a perfectly fine module that provides access to the external
procedure some_procedure. USEing this module will give you an implicit
interface to the procedure, as there sure isn't any information here to
provide anything else.
Yes, by the way, there are occasionally reasons to do things like that.
They aren't common, but they do come up. And it is even vaguely possible
that MPI might sit in one of the corners where such a thing is useful
(in particular, if there is type cheating going on that would cause
compilers to bitch if they noticed).
--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain
Greg Lindahl
Richard Maine <nos...@see.signature> wrote:
>Yes, by the way, there are occasionally reasons to do things like that.
>They aren't common, but they do come up. And it is even vaguely possible
>that MPI might sit in one of the corners where such a thing is useful
>(in particular, if there is type cheating going on that would cause
>compilers to bitch if they noticed).
I'm kind of astonished that you're unaware of the huge problems MPI
has with the way Fortran modules are specified.
-- greg
Richard Maine
Why would you be astonished? I have never in my life used MPI. Although
I occasionally see discussions about it here and elsewhere, it certainly
isn't something I'm intimately involved in... or have used at all.
I actually have no clue what you are talking about in terms of it having
problems with the way modules are specified. I'm not saying that you are
incorrect in saying that there are such problems. I am simply saying
that I have never heard of them.
If, perhaps, you are talking about problems relating to TKR-cheating,
I've heard about that, but I don't consider that to be a problem with
"the way modules are specified", as it has to do with explicit
interfaces, independent of modules. That's what I was alluding to in the
quote above.
If it isn't that, well... all I can say is that I'm astonished that you
would assume that I have identical interests and expertise to you. Do
you assume that anyone who does Fortran is necessarily into MPI?
Gib Bogle
Thanks Richard, my understanding was deficient. If I understand you correctly, this seems to imply
that I need to create explicit interfaces for all the MPI procedures I'm using, or, better, persuade
the MPICH2 developers that it would be useful to provide, in the Fortran distribution, a file
containing explicit interfaces to all the MPI procedures. I wasted an enormous amount of time
trying to track down my error, and I hate to think of others having to go through the same process.
Janne Blomqvist
> If, perhaps, you are talking about problems relating to TKR-cheating,
Yes, this is essentially it. From
http://www.open-mpi.org/papers/euro-pvmmpi-2005-fortran/euro-pvm-mpi-2005-fortran.pdf
"""
Not only must interfaces be defined for arrays of each intrinsic data
type, but for each array dimension as well. Depending on the compiler,
there may be approximately 15 type / size combinations.1 Each of these
combinations can be paired with up to a maximum of seven array
dimensions. With approximately 50 MPI functions that have one choice
buffer, this means that 5,250 interface declarations must be specified
(i.e., 15 types × 7 dimensions × 50 functions). Note that this does
not include the approximately 25 MPI functions with two choice
buffers. This leads to an additional 6.8M interface declarations
(i.e., (15× 7 × 25)2).
"""
In practice, implementations either resort to implicit interfaces in
the MPI module, or provide a subset of explicit interfaces and expect
the programmer to change to the old
INCLUDE 'mpif.h'
thing in case they do something outside the subset defined in the mpi
module. Or something like that.
For MPI 3, there is an effort underway to implement the kind of
bindings with ISO_C_BINDING as is described in the paper. See
http://svn.mpi-forum.org/trac/mpi-forum-web/wiki/FtnWikiPage
--
Janne Blomqvist
Greg Lindahl
Richard Maine <nos...@see.signature> wrote:
>If it isn't that, well... all I can say is that I'm astonished that you
>would assume that I have identical interests and expertise to you. Do
>you assume that anyone who does Fortran is necessarily into MPI?
Uh, no. I just thought it was a well-known example.
-- greg
Dan Nagle
On 2008-05-08 03:02:00 -0400, Janne Blomqvist <f...@bar.invalid> said:
> On 2008-05-08, Richard Maine <nos...@see.signature> wrote:
>> If, perhaps, you are talking about problems relating to TKR-cheating,
>
> Yes, this is essentially it.
There is also the problem that there is no concept
in the standard today to allow a procedure to inform
the compiler that, due to the procedure, memory might
change *outside the proceudre* in the caller or elsewhere
up the call chain.
J3 has a liaison with the MPI Forum, and is trying
to get a grip on these issues.
--
Cheers!
Dan Nagle
Herman D. Knoble
http://ftp.aset.psu.edu/pub/ger/fortran/mpiSim/mpiSim.html
What was the result?
Thanks.
Skip (h...@psu.edu)
On Thu, 08 May 2008 08:42:32 +1200, Gib Bogle <bo...@ihug.too.much.spam.co.nz> wrote:
-|With a little help from my friends I have found the error in my MPI code
-|that was bedeviling me with Heisenbugs. One of the arguments to
-|MPI_RECV is an integer array status(MPI_STATUS_SIZE). In one place I'd
-|forgotten to make it an array, and just declared it as integer.
-|Interested consequences followed from this little mistake.
-|
-|I'm wondering if this is the kind of error that a compiler might be able
-|to detect.
glen herrmannsfeldt
(snip)
> There is also the problem that there is no concept
> in the standard today to allow a procedure to inform
> the compiler that, due to the procedure, memory might
> change *outside the proceudre* in the caller or elsewhere
> up the call chain.
There is the ASYNCHRONOUS attribute which indicates that
a variable may change due to asynchronous I/O.
-- glen
Herman D. Knoble
http://people.scs.fsu.edu/~burkardt/html/mpi_glossary.html
in particular:
http://people.scs.fsu.edu/~burkardt/html/mpi_glossary.html#MPI_Recv
The first argument (data) to MPI_RECV "may be a scalar or a vector."
Skip
On Thu, 08 May 2008 07:40:20 -0400, Herman D. Knoble <SkipKno...@SPAMpsu.DOT.edu>
wrote:
-|Gib: Did you try using the debug bindiings in mpiSim:
-|http://ftp.aset.psu.edu/pub/ger/fortran/mpiSim/mpiSim.html
-|
-|What was the result?
-|
-|Thanks.
-|Skip (h...@psu.edu)
-|
-|
-|On Thu, 08 May 2008 08:42:32 +1200, Gib Bogle <bo...@ihug.too.much.spam.co.nz> wrote:
-|
-|-|With a little help from my friends I have found the error in my MPI code
-|-|that was bedeviling me with Heisenbugs. One of the arguments to
-|-|MPI_RECV is an integer array status(MPI_STATUS_SIZE). In one place I'd
-|-|forgotten to make it an array, and just declared it as integer.
-|-|Interested consequences followed from this little mistake.
-|-|
-|-|I'm wondering if this is the kind of error that a compiler might be able
-|-|to detect.
Gordon Sande
> On 2008-05-08, Richard Maine <nos...@see.signature> wrote:
>> If, perhaps, you are talking about problems relating to TKR-cheating,
>
> Yes, this is essentially it. From
>
> http://www.open-mpi.org/papers/euro-pvmmpi-2005-fortran/euro-pvm-mpi-2005-fortran.pdf
"""
Not
>
> only must interfaces be defined for arrays of each intrinsic data
> type, but for each array dimension as well. Depending on the compiler,
> there may be approximately 15 type / size combinations.1 Each of these
> combinations can be paired with up to a maximum of seven array
> dimensions. With approximately 50 MPI functions that have one choice
> buffer, this means that 5,250 interface declarations must be specified
> (i.e., 15 types × 7 dimensions × 50 functions). Note that this does
> not include the approximately 25 MPI functions with two choice
> buffers. This leads to an additional 6.8M interface declarations
> (i.e., (15× 7 × 25)2).
> """
Most arguments of that type are followed by a comment "and then I
implemented a trivial text processing program to produce all of them".
Sounds like a marvelous project for a student in need of a practical
problem. A bit of clever use of generic forms may be called for.
Dan Nagle
On 2008-05-08 07:57:33 -0400, glen herrmannsfeldt <g...@ugcs.caltech.edu> said:
>
> There is the ASYNCHRONOUS attribute which indicates that
> a variable may change due to asynchronous I/O.
Which applies in the routine where it is declared,
but does *not* propagate *up* the call-tree.
That is the problem.
--
Cheers!
Dan Nagle
glen herrmannsfeldt
(I wrote)
>> There is the ASYNCHRONOUS attribute which indicates that
>> a variable may change due to asynchronous I/O.
> Which applies in the routine where it is declared,
> but does *not* propagate *up* the call-tree.
> That is the problem.
I would expect to declare the attribute in all routines where
the variable is used and could possibly change asynchronously.
-- glen
Dick Hendrickson
Dick Hendrickson
Dan Nagle
On 2008-05-08 08:44:48 -0400, glen herrmannsfeldt <g...@ugcs.caltech.edu> said:
>
> I would expect to declare the attribute in all routines where
> the variable is used and could possibly change asynchronously.
That is the problem.
--
Cheers!
Dan Nagle
Dan Nagle
>> I would expect to declare the attribute in all routines where
>> the variable is used and could possibly change asynchronously.
>>
>> -- glen
>>
> Wouldn't VOLATILE be better?
>
> Dick Hendrickson
Volatile has the same scoping issue as asychronous.
There was a long thread on the j3 list about this
since 183.
--
Cheers!
Dan Nagle
Dick Hendrickson
better attribute to use. I don't think of MPI as being
an I/O thingo and volatile was designed, more or less,
to allow for surprising changes to variables.
Dick Hendrickson
glen herrmannsfeldt
(snip on ASYNCHRONOUS and VOLATILE attribute with MPI)
>> Volatile has the same scoping issue as asychronous.
>> There was a long thread on the j3 list about this
>> since 183.
> Yes, it has the same scoping issue. It just seemed like a
> better attribute to use. I don't think of MPI as being
> an I/O thingo and volatile was designed, more or less,
> to allow for surprising changes to variables.
The MPI system I worked with for a little while had
four processors connected with a special high-speed
I/O system. Each had its own memory and the ability to
pass data to any other.
When we had a processor more than four times faster than
the MPI processors, I stopped working with MPI.
With multi-core processors, it may seem less obvious that
it is I/O, though.
For VOLATILE, F2003 5.2.1.16 says:
"A pointer with the VOLATILE attribute may additionally
have its association status and array bounds changed by
means not specified by the program."
also:
"An allocatable object with the VOLATILE attribute may
additionally have its allocation status, dynamic type
and type parameters, and array bounds changed by means
not specified by the program."
Those seem to me things that MPI wouldn't do, but I might
be wrong on that. One thing that ASYNCHRONOUS should do is
avoid a copy on a subroutine call. (Most likely both the called
and calling routine should use the attribute on the appropriate
variables.)
As to Dan, I would say that ASYNCHRONOUS variables should only
change between the I/O operation and the appropriate WAIT
statement. It seems unreasonable to expect a compiler to
figure that out, so the attribute needs to be specified in
all places where the variable could change asynchronously
and the code would fail if the compiler didn't take that
into account.
-- glen
Dan Nagle
On 2008-05-08 16:15:17 -0400, Dick Hendrickson <dick.hen...@att.net> said:
> Dan Nagle wrote:
> Volatile has the same scoping issue as asychronous.
>> There was a long thread on the j3 list about this
>> since 183.
>>
> Yes, it has the same scoping issue. It just seemed like a
> better attribute to use. I don't think of MPI as being
> an I/O thingo and volatile was designed, more or less,
> to allow for surprising changes to variables.
Yea, sure, ok, I agree. :-)
OTOH, using MPI and being surprised sorta go together. :-)
--
Cheers!
Dan Nagle
Dan Nagle
On 2008-05-08 16:40:23 -0400, glen herrmannsfeldt <g...@ugcs.caltech.edu> said:
>
> As to Dan, I would say that ASYNCHRONOUS variables should only
> change between the I/O operation and the appropriate WAIT
> statement. It seems unreasonable to expect a compiler to
> figure that out, so the attribute needs to be specified in
> all places where the variable could change asynchronously
> and the code would fail if the compiler didn't take that
> into account.
That's the point.
It's swell approach with a toy program of a few kilo-lines
all in a file or two. But try chasing an intermittent bug
through 100ks of lines and thousands of files.
Dumping on the applications programmer is a little less
attractive under those circumstances. That's why J3 has
a liaison with the MPI forum to see what we can do to address
the issue.
"You knew the job was dangerous when you took it."
--
Cheers!
Dan Nagle
GaryScott
> Dick Hendrickson wrote:
>
<snip>
> As to Dan, I would say that ASYNCHRONOUS variables should only
> change between the I/O operation and the appropriate WAIT
> statement.
I probably don't understand something, but I would think that an
unacceptable restriction. If this is a fixed memory address used by
some asynchronous external processor such as an analog signal input
(lets say a 16-bit analog), that processor probably has a regular
sample frequency, but is possibly asynchronous with the CPU let alone
this asynchronous I/O operation.
glen herrmannsfeldt
(snip, I wrote)
>>As to Dan, I would say that ASYNCHRONOUS variables should only
>>change between the I/O operation and the appropriate WAIT
>>statement.
> I probably don't understand something, but I would think that an
> unacceptable restriction. If this is a fixed memory address used by
> some asynchronous external processor such as an analog signal input
> (lets say a 16-bit analog), that processor probably has a regular
> sample frequency, but is possibly asynchronous with the CPU let alone
> this asynchronous I/O operation.
Well, I presume it is to be used with asynchronous READ and
WRITE statements. That would not normally include a 16 bit
ADC, such as might be on the processors data bus, but maybe
through a data stream available to READ. That allows the
program to overlap processing with I/O operations, something like:
READ(1,*,ASYNCHRONOUS='YES') I,J,K
C do complicated calculations here not using I, J, or K.
WAIT(1)
C now use I, J, and K.
The standard seems to indicate that I, J, and K will automatically
have the ASYNCHRONOUS attribute in the scoping unit. It will need
to be added to such variables in other scoping units. That would
be true, for example, if variables were passed to a subroutine
that did the READ, and another subroutine or a later call to the
same one did the WAIT.
I guess I still don't understand Dan's point. It takes some
work to use asynchronous I/O, but it is entirely up to the
programmer to make that decision. One needs to know at which
point a variable might not yet have the appropriate value and
the points where it will have the appropriate value. That is
for the programmer to determine and put the WAIT in the
right place.
-- glen
Richard Maine
> On May 8, 3:40 pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
> > Dick Hendrickson wrote:
>
> > As to Dan, I would say that ASYNCHRONOUS variables should only
> > change between the I/O operation and the appropriate WAIT
> > statement.
>
> I probably don't understand something, but I would think that an
> unacceptable restriction. If this is a fixed memory address used by
> some asynchronous external processor such as an analog signal input
> (lets say a 16-bit analog), that processor probably has a regular
> sample frequency, but is possibly asynchronous with the CPU let alone
> this asynchronous I/O operation.
That's not the kind of situation that ASYNCHRONOUS is about. I think
Glenn threw people off with mentioning that MPI was sort of like I/O.
While in some sense, that is so, it is irrelevant. ASYNCRONOUS is about
Fortran read/write statements. It is not about other random ways that
variables mught change values asynchronously, and it doesn't matter
whether those other ways are or are not sort of like I/O. If it isn't
Fortran read/write statements, then the asynchronous attribute is
irrelevant.
What you are looking for is the VOLATILE attribute. Memory addresses
that get updated via means independent of the Fortran program are
exactly the kind of thing VOLATILE is about.
glen herrmannsfeldt
(snip)
> What you are looking for is the VOLATILE attribute. Memory addresses
> that get updated via means independent of the Fortran program are
> exactly the kind of thing VOLATILE is about.
That is the way it looks to me, for VOLATILE:
"An allocatable object with the VOLATILE attribute may
additionally have its allocation status, dynamic type
and type parameters, and array bounds changed by means
not specified by the program."
I thought for MPI that only the data would change, and that
(even though intended for Fortran ASYNCHRONOUS I/O) that
ASYNCHRONOUS might be more appropriate.
But yes, as far as the standard it only applies when used
in the ways specified by the standard.
-- glen
Richard Maine
> Richard Maine wrote:
> (snip)
>
> > What you are looking for is the VOLATILE attribute. Memory addresses
> > that get updated via means independent of the Fortran program are
> > exactly the kind of thing VOLATILE is about.
>
> That is the way it looks to me, for VOLATILE:
>
> "An allocatable object with the VOLATILE attribute may
> additionally have its allocation status, dynamic type
> and type parameters, and array bounds changed by means
> not specified by the program."
>
> I thought for MPI that only the data would change,
Most likely, but that seems irrelevant. Something doesn't actually
*HAVE* to do every single thing that VOLATILE allows in order to be
appropriate for VOLATILE. Many things can use VOLATILE MPI is one of
them.
> and that
> (even though intended for Fortran ASYNCHRONOUS I/O) that
> ASYNCHRONOUS might be more appropriate.
So MPI doesn't fit VOLATILE because it doesn't use every possible arcane
part of VOLATILE, but it does fit ASYNCHRONOUS even though it doesn't
have anything to do with any of the statements that relate to
ASYNCRONOUS? The logic here escapes me.
Gary Scott
> GaryScott <garyl...@sbcglobal.net> wrote:
>
>
>>On May 8, 3:40 pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
>>
>>>Dick Hendrickson wrote:
>>
>>>As to Dan, I would say that ASYNCHRONOUS variables should only
>>>change between the I/O operation and the appropriate WAIT
>>>statement.
>>
>>I probably don't understand something, but I would think that an
>>unacceptable restriction. If this is a fixed memory address used by
>>some asynchronous external processor such as an analog signal input
>>(lets say a 16-bit analog), that processor probably has a regular
>>sample frequency, but is possibly asynchronous with the CPU let alone
>>this asynchronous I/O operation.
>
>
> That's not the kind of situation that ASYNCHRONOUS is about. I think
> Glenn threw people off with mentioning that MPI was sort of like I/O.
> While in some sense, that is so, it is irrelevant. ASYNCRONOUS is about
> Fortran read/write statements. It is not about other random ways that
> variables mught change values asynchronously, and it doesn't matter
> whether those other ways are or are not sort of like I/O. If it isn't
> Fortran read/write statements, then the asynchronous attribute is
> irrelevant.
>
> What you are looking for is the VOLATILE attribute. Memory addresses
> that get updated via means independent of the Fortran program are
> exactly the kind of thing VOLATILE is about.
Yes, I was aware of the I/O meaning for asynchronous. I was thinking of
asynchronous I/O of a volatile variable. In that case, I'd expect the
volatile variable to continue to be volatile right up to the point that
it is written. He indicated that it was (or should be or something)
prohibited from changing (I thought he was referring to a volatile
variable) between the initiation of the write sequence and a wait (or
status test?). Anyway I'm familiar with asynch I/O with bufferin/out
that retained "volatility" right up to the point of the transfer.
That's the way I think it should work.
>
--
Gary Scott
mailto:garylscott@sbcglobal dot net
Fortran Library: http://www.fortranlib.com
Support the Original G95 Project: http://www.g95.org
-OR-
Support the GNU GFortran Project: http://gcc.gnu.org/fortran/index.html
If you want to do the impossible, don't hire an expert because he knows
it can't be done.
-- Henry Ford
Ron Shepard
<pbJUj.176928$D_3....@bgtnsc05-news.ops.worldnet.att.net>,
Dick Hendrickson <dick.hen...@att.net> wrote:
> I don't think of MPI as being
> an I/O thingo and volatile was designed, more or less,
> to allow for surprising changes to variables.
I personally think that I/O *is* an appropriate way to think of
message passing (including MPI). The device happens to be another
computer rather than a simple I/O device (card reader, tape drive,
etc.), but as far as abstractions and how the code should behave,
passing or receiving a message is very close to writing or reading
data from some device.
The problem with nonblocking message passing and f90 is, I think,
twofold. First, there is the asynchronous/volatile aspect where the
compiler must not cache values into registers, or precompute values
in one place and expect them to be the same as computing them later.
Then there is the other problem involving possible copy-in/copy-out
of dummy arguments (usually arrays) with local copies. At some
point in the calling sequence, if a local copy is made of such an
argument, and that address is eventually used in the
asynchronous/volatile way to receive data from a remote node, then
that data will not appear in the actual array but rather in the
local copy (which is unknown to the high-level calling routine). It
would seem that some combination of target/pointer attributes would
be sufficient to prevent such unwanted local copies.
The other problem mentioned, needing millions of interface routines,
I think is not so serious. The system could be designed to always
accept data of some type (say integer arrays), and conversion
routines could be written to coerce any user type into that message
type. In fortran, this could be done with transfer(), for example.
This might require an extra buffer to be used, but memory is cheap
and plentiful in modern computers, so I don't think this is a
serious practical problem.
$.02 -Ron Shepard
Richard Maine
> The other problem mentioned, needing millions of interface routines,
> I think is not so serious. The system could be designed to always
> accept data of some type (say integer arrays), and conversion
> routines could be written to coerce any user type into that message
> type. In fortran, this could be done with transfer(), for example.
> This might require an extra buffer to be used, but memory is cheap
> and plentiful in modern computers, so I don't think this is a
> serious practical problem.
I think a simpler solution is to use C void pointers... aka type C_PTR
in f2003. There are some limitations in what kind of thing you can point
at with these, but for the most part, the things one is most interested
in doing MPI stuff on are probably interoperable types (and even basic
intrinsic types). Discontiguous arrays do need copying, but that's
pretty inherent in things like MPI, as far as I know.
This is basically what C uses in the comparable situation and, although
I think there are lots of things C screws up, I don't think this is one
of them. I think the void pointer matches well with the basic
functionality here - that you are just pointing to a block of memory,
without paying much attention to the type of the contents.
A similar option is f2003 unlimitted polymorphic pointers, but I'm not
sure those will fit the purpose as well; would have to check details.
Dick Hendrickson
> glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
>
>> Richard Maine wrote:
>> (snip)
>>
>>> What you are looking for is the VOLATILE attribute. Memory addresses
>>> that get updated via means independent of the Fortran program are
>>> exactly the kind of thing VOLATILE is about.
>> That is the way it looks to me, for VOLATILE:
>>
>> "An allocatable object with the VOLATILE attribute may
>> additionally have its allocation status, dynamic type
>> and type parameters, and array bounds changed by means
>> not specified by the program."
>>
>> I thought for MPI that only the data would change,
>
> Most likely, but that seems irrelevant. Something doesn't actually
> *HAVE* to do every single thing that VOLATILE allows in order to be
> appropriate for VOLATILE. Many things can use VOLATILE MPI is one of
> them.
>
>> and that
>> (even though intended for Fortran ASYNCHRONOUS I/O) that
>> ASYNCHRONOUS might be more appropriate.
I think people, especially Glen?, are confused about what
ASYNCHRONOUS means. It basically provides a set of restrictions
on the user and hardly any restrictions on the compiler. If
a variable is in a pending input/output sequence (meaning it
has the ASYNCHRONOUS attribute and is in an unWAITed for
I/O transfer) then the user is not allowed to reference or define
it if it's in an input transfer and not allowed to define it if
it's in an output transfer. (F2003 page 195, around line 10,
gives the gory details.)
This means that in a code snippet like
asynchronous :: x,y
...
x = y + y
the compiler doesn't have to do anything special. It is the
users responsibility to guarantee that x and y aren't in an
active i/o statement of the wrong kind.
This is totally different from VOLATILE where the compiler is
encouraged to fetch variables from memory and store them back
as soon as it can.
About the only compiler restrictions for ASYNCHRONOUS is
prevention of code motion across WAIT statements (and this
applies to any call statement where the compiler can't
analyze the callee well enough) and an effective prohibition
of copy-in/copy-out argument passing of asynchronous variables.
Dick Hendrickson
glen herrmannsfeldt
(snip)
> I think people, especially Glen?, are confused about what
> ASYNCHRONOUS means. It basically provides a set of restrictions
> on the user and hardly any restrictions on the compiler. If
> a variable is in a pending input/output sequence (meaning it
> has the ASYNCHRONOUS attribute and is in an unWAITed for
> I/O transfer) then the user is not allowed to reference or define
> it if it's in an input transfer and not allowed to define it if
> it's in an output transfer. (F2003 page 195, around line 10,
> gives the gory details.)
It might be better to give the chapter/section/subsection numbers.
> This means that in a code snippet like
> asynchronous :: x,y
> ...
> x = y + y
> the compiler doesn't have to do anything special. It is the
> users responsibility to guarantee that x and y aren't in an
> active i/o statement of the wrong kind.
> This is totally different from VOLATILE where the compiler is
> encouraged to fetch variables from memory and store them back
> as soon as it can.
> About the only compiler restrictions for ASYNCHRONOUS is
> prevention of code motion across WAIT statements (and this
> applies to any call statement where the compiler can't
> analyze the callee well enough) and an effective prohibition
> of copy-in/copy-out argument passing of asynchronous variables.
I had first noticed ASYNCHRONOUS on a previous discussion
of MPI when copy-in/copy-out was being done for an array
used by MPI. The result of that copy was that the needed
data wasn't available until after the copy. My belief is
that this is exactly the restrictions needed for MPI.
If more restriction is needed then VOLATILE should be used.
The first MPI machine I used was a cluster of four separate
processors and a high-speed communication system. As far
as I know, that is the type of system MPI was designed for.
Today it might be that shared memory (multi-core) systems
are more commonly used. The important difference is that
for shared memory systems pointers could be passed between
systems, in which case it seems that VOLATILE is needed.
I believe, though, that within the design of MPI, that pointers
should not be passed around. That is, that the restrictions of
ASYNCHRONOUS are enough. I consider MPI really as a system
for doing asynchronous I/O between systems to pass data
around, and to synchronize the data passing process.
(I have done asynchronous I/O in other languages, but
not in Fortran.)
-- glen
Gib Bogle
> Gib: Did you try using the debug bindiings in mpiSim:
> http://ftp.aset.psu.edu/pub/ger/fortran/mpiSim/mpiSim.html
>
> What was the result?
>
> Thanks.
> Skip (h...@psu.edu)
Hi Skip,
I just downloaded the mpiSim files and compiled my code with mpiSim.f90. I got the following messages:
1>D:\MPI\mpich\test\mpiSim.f90(1304) : Warning: This name has not been given an explicit type. [TESTR]
1>D:\MPI\mpich\test\mpiSim.f90(3319) : Warning: This name has not been given an explicit type. [TESTR]
1>D:\MPI\mpich\test\mpiSim.f90(3835) : Warning: This name has not been given an explicit type. [I]
1>D:\MPI\mpich\test\mpiSim.f90(4296) : Warning: This name has not been given an explicit type. [TESTR]
1>D:\MPI\mpich\test\mpiSim.f90(4385) : Warning: This name has not been given an explicit type. [TESTR]
1>transfer.f90
1>D:\MPI\mpich\test\transfer.f90(333) : Error: There is no matching specific subroutine for this
generic subroutine call. [MPI_SEND]
1>D:\MPI\mpich\test\transfer.f90(361) : Error: There is no matching specific subroutine for this
generic subroutine call. [MPI_RECV]
1>D:\MPI\mpich\test\transfer.f90(446) : Error: There is no matching specific subroutine for this
generic subroutine call. [MPI_SEND]
1>D:\MPI\mpich\test\transfer.f90(451) : Error: There is no matching specific subroutine for this
generic subroutine call. [MPI_SEND]
1>D:\MPI\mpich\test\transfer.f90(478) : Error: There is no matching specific subroutine for this
generic subroutine call. [MPI_RECV]
1>D:\MPI\mpich\test\transfer.f90(500) : Error: There is no matching specific subroutine for this
generic subroutine call. [MPI_RECV]
1>D:\MPI\mpich\test\transfer.f90(573) : Error: There is no matching specific subroutine for this
generic subroutine call. [MPI_SEND]
1>D:\MPI\mpich\test\transfer.f90(587) : Error: There is no matching specific subroutine for this
generic subroutine call. [MPI_SEND]
1>D:\MPI\mpich\test\transfer.f90(606) : Error: There is no matching specific subroutine for this
generic subroutine call. [MPI_SEND]
1>D:\MPI\mpich\test\transfer.f90(662) : Error: There is no matching specific subroutine for this
generic subroutine call. [MPI_RECV]
1>D:\MPI\mpich\test\transfer.f90(684) : Error: There is no matching specific subroutine for this
generic subroutine call. [MPI_RECV]
1>D:\MPI\mpich\test\transfer.f90(700) : Error: There is no matching specific subroutine for this
generic subroutine call. [MPI_RECV]
1>D:\MPI\mpich\test\transfer.f90(745) : Error: There is no matching specific subroutine for this
generic subroutine call. [MPI_SEND]
1>D:\MPI\mpich\test\transfer.f90(755) : Error: There is no matching specific subroutine for this
generic subroutine call. [MPI_SEND]
1>compilation aborted for D:\MPI\mpich\test\transfer.f90 (code 1)
I can supply the declarations for TESTR (double precision?) and I, but I don't know what to do about
the MPI_SEND and MPI_RECV errors. Any suggestions?
Thanks
Gib
Herman D. Knoble
Thanks.
skip
On Tue, 13 May 2008 17:10:25 +1200, Gib Bogle <g.b...@auckland.no.spam.ac.nz> wrote:
-|Herman D. Knoble wrote:
-|> Gib: Did you try using the debug bindiings in mpiSim:
-|> http://ftp.aset.psu.edu/pub/ger/fortran/mpiSim/mpiSim.html
-|>
-|> What was the result?
-|>
-|> Thanks.
-|> Skip (h...@psu.edu)
-|
-|Hi Skip,
-|
-|I just downloaded the mpiSim files and compiled my code with mpiSim.f90. I got the
following messages:
-|
-|1>D:\MPI\mpich\test\mpiSim.f90(1304) : Warning: This name has not been given an explicit
type. [TESTR]
-|1>D:\MPI\mpich\test\mpiSim.f90(3319) : Warning: This name has not been given an explicit
type. [TESTR]
-|1>D:\MPI\mpich\test\mpiSim.f90(3835) : Warning: This name has not been given an explicit
type. [I]
-|1>D:\MPI\mpich\test\mpiSim.f90(4296) : Warning: This name has not been given an explicit
type. [TESTR]
-|1>D:\MPI\mpich\test\mpiSim.f90(4385) : Warning: This name has not been given an explicit
type. [TESTR]
-|1>transfer.f90
-|1>D:\MPI\mpich\test\transfer.f90(333) : Error: There is no matching specific subroutine
for this
-|generic subroutine call. [MPI_SEND]
-|1>D:\MPI\mpich\test\transfer.f90(361) : Error: There is no matching specific subroutine
for this
-|generic subroutine call. [MPI_RECV]
-|1>D:\MPI\mpich\test\transfer.f90(446) : Error: There is no matching specific subroutine
for this
-|generic subroutine call. [MPI_SEND]
-|1>D:\MPI\mpich\test\transfer.f90(451) : Error: There is no matching specific subroutine
for this
-|generic subroutine call. [MPI_SEND]
-|1>D:\MPI\mpich\test\transfer.f90(478) : Error: There is no matching specific subroutine
for this
-|generic subroutine call. [MPI_RECV]
-|1>D:\MPI\mpich\test\transfer.f90(500) : Error: There is no matching specific subroutine
for this
-|generic subroutine call. [MPI_RECV]
-|1>D:\MPI\mpich\test\transfer.f90(573) : Error: There is no matching specific subroutine
for this
-|generic subroutine call. [MPI_SEND]
-|1>D:\MPI\mpich\test\transfer.f90(587) : Error: There is no matching specific subroutine
for this
-|generic subroutine call. [MPI_SEND]
-|1>D:\MPI\mpich\test\transfer.f90(606) : Error: There is no matching specific subroutine
for this
-|generic subroutine call. [MPI_SEND]
-|1>D:\MPI\mpich\test\transfer.f90(662) : Error: There is no matching specific subroutine
for this
-|generic subroutine call. [MPI_RECV]
-|1>D:\MPI\mpich\test\transfer.f90(684) : Error: There is no matching specific subroutine
for this
-|generic subroutine call. [MPI_RECV]
-|1>D:\MPI\mpich\test\transfer.f90(700) : Error: There is no matching specific subroutine
for this
-|generic subroutine call. [MPI_RECV]
-|1>D:\MPI\mpich\test\transfer.f90(745) : Error: There is no matching specific subroutine
for this
-|generic subroutine call. [MPI_SEND]
-|1>D:\MPI\mpich\test\transfer.f90(755) : Error: There is no matching specific subroutine
for this
-|generic subroutine call. [MPI_SEND]
-|1>compilation aborted for D:\MPI\mpich\test\transfer.f90 (code 1)
-|
-|I can supply the declarations for TESTR (double precision?) and I, but I don't know what
to do about
-|the MPI_SEND and MPI_RECV errors. Any suggestions?
-|
-|Thanks
-|Gib