From james.h.cownie at [hidden] Fri Feb 1 04:47:51 2008 From: james.h.cownie at [hidden] (Cownie, James H) Date: Fri, 1 Feb 2008 10:47:51 -0000 Subject: [mpi-21] Ballot 4 - Re: Request for interpretation In-Reply-To: Message-ID: I'm happy with Dick's statement, and I think we want "undefined" (as he has) rather than "implementation defined". If I recall correctly undefined == any behavior is possible and there's no need to document that behavior. implementation defined == any behavior is possible, but the implementation should document what it will do. So they have the same property that the code is non-conforming and can behave in any way, but "implementation defined" requires more work from the library implementer's documentation department. In this case defining the behavior may not be trivial, since there can be many functions involved and an arbitrarily large set of possible erroneous inputs. So it's reasonable, taking Dick's example, MPI_File_open accepts a "buffer_size" hint with range "32K" to "16M" we may want to define the behavior of hints that are out of range. to say "if the buffer_size is > 16M it is treated as 16M", but that doesn't address what happens if the "buffer_size" is "monkey". Neither "undefined" nor "implementation defined" prevent implementations from defining the behavior, rather they both warn users that what they're doing is non-portable, and the standard doesn't say what will happen... -- Jim James Cownie SSG/DPD/PAT Tel: +44 117 9071438 > -----Original Message----- > From: mpi-21-bounces_at_[hidden] [mailto:mpi-21-bounces_at_[hidden]] On > Behalf Of Rolf Rabenseifner > Sent: 31 January 2008 20:55 > To: Mailing list for discussion of MPI 2.1 > Subject: Re: [mpi-21] Ballot 4 - Re: Request for interpretation > > Do we mean "implementation defined" instead of "undefined"? > > On Thu, 31 Jan 2008 14:16:20 -0500 > Richard Treumann wrote: > >Jim > > > >The sense I get from the phrase "the behavior is undefined" is that > >defining the behavior is beyond the scope of the standard. > > > >The MPI standard does have some predefined keys and requires an > >implementation that supports any predefined key to support it as > described > >by the standard. That can lead to one place in the standard saying "the > >behavior is undefined" and another saying "here is the definition of the > >behavior". > > > >Maybe I am reading more than others into the phrase "the behavior is > >undefined" but it does have this strong implication in my mind. > > > >How is this ? > > > >An implementation must support info objects as caches for arbitrary > >key, value) pairs, regardless of whether it recognizes the key. > >Each function that takes hints in the form of an MPI_Info must > >be prepared to ignore any key it does not recognize. This description > >of info objects does not attempt to define how a particular function > >should react if it recognizes a key but not the associated value. > > > >note: > >I also changed MPI function to simply function because with this free > form > >approach to the info object, it seems to me a third party library that is > >intended to work as part of an MPI program may want to use MPI_Info > objects > >too. If someone authors a parallel math library and wants the > >initialization routine to look like: > > init_pmath( MPI_Info info) > >why not? They should understand that init_pmath must ignore keys it does > >not recognize even if i is not an MPI_ routine. > > > > > > Dick > > > >Dick Treumann - MPI Team/TCEM > >IBM Systems & Technology Group > >Dept 0lva / MS P963 -- 2455 South Road -- Poughkeepsie, NY 12601 > >Tele (845) 433-7846 Fax (845) 433-8363 > > > > > >mpi-21-bounces_at_[hidden] wrote on 01/31/2008 09:39:52 AM: > > > >> As you are saying, there are two different classes of errors here. > >> > >> 1) Keys which are not understood and need to be ignored by functions > >> which don't grok them ("JIMS_SECRET_TAG","99") > >> 2) Keys which are understood by a function, but with a value which > >> is not ("buffer_size", "Hello") > >> > >> I think allowing the second type to have undefined behavior is the > >> right thing to do, since it's the most general. > >> If your implementation wants to define the behavior of some out-of- > >> range values, that's fine and doesn't make you non-conforming, it > >> just means you defined the previously undefined behavior for some > >> set of values. > >> > >> Having that undefined-ness explicit here (in one central place) > >> seems to make sense (if only because it may be omitted in one of the > >> other places where it should appear). > >> > >> My addition does not alter the existing change which guarantees case > >> 1, it's only concerned with case 2. > >> -- Jim > >> > >> James Cownie > >> SSG/DPD/PAT > >> Tel: +44 117 9071438 > >> > >> From: mpi-21-bounces_at_[hidden] [mailto:mpi-21-bounces_at_[hidden]] > >> On Behalf Of Richard Treumann > >> Sent: 31 January 2008 14:20 > >> To: Mailing list for discussion of MPI 2.1 > >> Subject: Re: [mpi-21] Ballot 4 - Re: Request for interpretation > >> > >> Jim - > >> > >> I was taking the view that the description of what to do for a > >> recognized key but dubious value belongs to the function that > >> recognizes the specific key. For example if MPI_File_open accepts a > >> "buffer_size" hint with range "32K" to "16M" we may want to define > >> the behavior of hints that are out of range. > >> > >> Once we say an info can have arbitrary keys we need to state that > >> every info consumer must be prepared to ignore keys it does not > >> recognize because we have made unrecognizable keys legitimate. > >> > >> Dick > >> Dick Treumann - MPI Team/TCEM > >> IBM Systems & Technology Group > >> Dept 0lva / MS P963 -- 2455 South Road -- Poughkeepsie, NY 12601 > >> Tele (845) 433-7846 Fax (845) 433-8363 > >> > >> > >> mpi-21-bounces_at_[hidden] wrote on 01/31/2008 08:43:04 AM: > >> > >> > However, you have apparently lost the liberty to have undefined > >> > behavior which was there in the previous version. > >> > > >> > Maybe you should keep that, something like > >> > An implementation must support info objects as caches for arbitrary > >> > (key, value) pairs, regardless of whether it recognizes the keys. > >> > Each MPI function which takes hints in the form of an MPI_Info must > >> > be prepared to ignore any key it does not recognize. However if a > >> > function recognizes a key but not the associated value, then the > >> > behavior is undefined. > >> > (Modifications in italics) > >> > -- Jim > >> > > >> > James Cownie > >> > SSG/DPD/PAT > >> > Tel: +44 117 9071438 > >> > > >> > From: mpi-21-bounces_at_[hidden] [mailto:mpi-21-bounces_at_[hidden]] > >> > On Behalf Of Richard Treumann > >> > Sent: 31 January 2008 13:29 > >> > To: Mailing list for discussion of MPI 2.1 > >> > Subject: Re: [mpi-21] Ballot 4 - Re: Request for interpretation > >> > > >> > Your wording works for me Rolf. -- Thanks > >> > > >> > > >> > Dick Treumann - MPI Team/TCEM > >> > IBM Systems & Technology Group > >> > Dept 0lva / MS P963 -- 2455 South Road -- Poughkeepsie, NY 12601 > >> > Tele (845) 433-7846 Fax (845) 433-8363 > >> > > >> > > >> > mpi-21-bounces_at_[hidden] wrote on 01/31/2008 05:25:46 AM: > >> > > >> > > I try to summarize all 3 replies in one proposal: > >> > > > >> > > ___________________________________ > >> > > > >> > > Proposal: > >> > > MPI 2.0, Sect. 4.10 Info Objects, page 43, line 38-40 read: > >> > > If a function does not recognize a key, > >> > > it will ignore it, unless otherwise specified. > >> > > If an implementation recognizes a key but does not recognize > >> > > the format of the corresponding value, the result is undefined. > >> > > but should read: > >> > > An implementation must support info objects as caches for > >arbitrary > >> > > (key, value) pairs, regardless of whether it recognizes the > pairs. > >> > > Each MPI function which takes hints in the form of an MPI_Info > >must > >> > > be prepared to ignore any key it does not recognize. > >> > > > >> > > Add after MPI 2.0, Sect. 4.10 Info Objects, page 44, line 22 a new > >> > > paragraph: > >> > > Advice to implementors. > >> > > Although in MPI functions that take hints in form of an MPI_Info > >> > > (e.g., in process creation and management, one-sided > >communication, > >> > > or parallel file I/O), an implementation must be prepared to > >ignore > >> > > keys that it does not recognize, for the purpose of > >> MPI_INFO_GET_NKEYS, > >> > > MPI_INFO_GET_NTHKEY, MPI_INFO_GET_VALUELEN, and MPI_INFO_GET, > the > >> > > implementation must retain all (key,value) pairs so that layered > >> > > functionality can also use the Info object. > >> > > (End of advice to implementors.) > >> > > _____________________________ > >> > > Rationale for this clarification: > >> > > > >> > > The MPI-2.0 text allowed that also MPI_INFO_DELETE, > MPI_INFO_SET, > >> > > MPI_INFO_GET, and MPI_INFO_DUP could ignore (key,value) pairs > >> > > that are not recognized in routines in other chapters that > >> > > take hints with info arguments. > >> > > The proposed clarification is necessary when we assume, that > >> > > layered implementation of parts of the MPI-2 standard should > >> > > be possible and may use the MPI_Info objects for their needs. > >> > > This was a goal of the MPI-2 Forum and the MPI-2.0 > specification. > >> > > ___________________________________ > >> > > > >> > > Bronis, for me, your wording "an MPI implementation may restrict" > was > >> > > in conflict with the rest of the advice. I hope the formulation > above > >> > > is also okay. It is based on the new wording from you and Dick in > >first > >> > > part of the proposal. > >> > > > >> > > Best regards > >> > > Rolf > >> > > > >> > > > >> > > Dr. Rolf Rabenseifner . . . . . . . . . .. email > rabenseifner_at_[hidden] > >> > > High Performance Computing Center (HLRS) . phone ++49(0)711/685- > 65530 > >> > > University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685- > 65832 > >> > > Head of Dpmt Parallel Computing . . . > www.hlrs.de/people/rabenseifner > >> > > Nobelstr. 19, D-70550 Stuttgart, Germany . (Office: Allmandring 30) > >> > > _______________________________________________ > >> > > mpi-21 mailing list > >> > > mpi-21_at_[hidden] > >> > > http://lists.cs.uiuc.edu/mailman/listinfo/mpi-21 > >> > --------------------------------------------------------------------- > >> > Intel Corporation (UK) Limited > >> > Registered No. 1134945 (England) > >> > Registered Office: Pipers Way, Swindon SN3 1RJ > >> > VAT No: 860 2173 47 > >> > > >> > 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. > >> > _______________________________________________ > >> > mpi-21 mailing list > >> > mpi-21_at_[hidden] > >> > http://lists.cs.uiuc.edu/mailman/listinfo/mpi-21 > >> --------------------------------------------------------------------- > >> Intel Corporation (UK) Limited > >> Registered No. 1134945 (England) > >> Registered Office: Pipers Way, Swindon SN3 1RJ > >> VAT No: 860 2173 47 > >> > >> 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. > >> _______________________________________________ > >> mpi-21 mailing list > >> mpi-21_at_[hidden] > >> http://lists.cs.uiuc.edu/mailman/listinfo/mpi-21 > > > > Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner_at_[hidden] > High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530 > University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832 > Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner > Nobelstr. 19, D-70550 Stuttgart, Germany . (Office: Allmandring 30) > _______________________________________________ > mpi-21 mailing list > mpi-21_at_[hidden] > http://lists.cs.uiuc.edu/mailman/listinfo/mpi-21 --------------------------------------------------------------------- Intel Corporation (UK) Limited Registered No. 1134945 (England) Registered Office: Pipers Way, Swindon SN3 1RJ VAT No: 860 2173 47 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. From jsquyres at [hidden] Mon Feb 4 20:15:13 2008 From: jsquyres at [hidden] (Jeff Squyres) Date: Mon, 4 Feb 2008 21:15:13 -0500 Subject: [mpi-21] Ballot 4 proposal: INOUT arguments In-Reply-To: Message-ID: <7F8F9D8C-E592-4E99-B4F7-BFB725CA4A17@cisco.com> On Jan 31, 2008, at 10:26 AM, Rolf Rabenseifner wrote: >> If we also want to specify the behavior of the object, then a) that's >> a huge change (and not one that I'm convinced we need), and b) we >> need >> to add a second IN/OUT/INOUT to every language-neutral binding >> representing what happens to the object. Adding it to only a few of >> the bindings doesn't seem consistent to me. > > The trick is, that we have this problem only with the > handle/object arguments. > In most cases we have > - IN/IN which is abbreviated with IN, e.g., MPI_Send(IN comm), or > - OUT/OUT which is abbreviated with OUT, e.g., in MPI_Isend(OUT rq), > or > - INOUT/INOUT which is abbreviated with INOUT, > e.g. in MPI_Type_commit(INOUT datatype) > > The change, I'm proposing is based on your wish to see the IN for > the handles that are kept constant. > Changing no words would continue to show the INOUT > for the objects itself (that's the way MPI-2 was written). > > I would not say, that it is a huge change to add the handle IN > information to all the interfaces. > It is not huge, although there are more routines affected > (also many MPI_FILE routines) as you have mentioned in your > first mails. I'm not sure that this is right, though -- my point is that there are many functions with IN handles that *do* [implicitly] change the underlying object (e.g., MPI_SEND can change the communicator object). Specifically: I do not agree that everywhere we see "IN" in the current standard means that the object cannot change. Aside from the exception statement, we have not stipulated the behavior of the back-end MPI objects. I think that's a good thing. I guess what I don't understand is: why is it useful to specify the implementation of the back-end MPI objects? FWIW: the only thing that matters to the bindings is the behavior of the handle. > > Okay? > > Best regards > Rolf > > On Thu, 31 Jan 2008 09:56:48 -0500 > Jeff Squyres wrote: >> On Jan 31, 2008, at 8:46 AM, Rolf Rabenseifner wrote: >> >>>> 1. Why do we need to indicate the INOUT status of the back-end MPI >>>> object in the language neutral bindings? All the bindings -- >>>> regardless of language -- only deal with the MPI handles, not the >>>> back- >>>> end MPI objects. >>>> >>>> 2. Adding qualifiers on what is supposed to happen to the back-end >>>> MPI >>>> object would seem to require additional semantics on the back-end >>>> MPI >>>> object. Should we really be specifying what the implementation >>>> must/ >>>> must not do with the back-end MPI object? Who benefits from that? >>> >>> After all the MPI_BOTTOM discussion and not knowing what future >>> languages will bring, I didn't want to remove existing information >>> from the standard. An opaque object in MPI consists always >>> of two things: the handle and the object itself. >>> >>> The language independent interface should reflect this. >>> >>> I thought that especially for the const discussion it would be good >>> to see the IN for the handle. >> >> I agree. >> >>> For future HPCS languages, it may be >>> also necessary see the INOUT for the object itself. >> >> I guess my point is that the language bindings don't specify anything >> about the object itself anywhere else. >> >> If we also want to specify the behavior of the object, then a) that's >> a huge change (and not one that I'm convinced we need), and b) we >> need >> to add a second IN/OUT/INOUT to every language-neutral binding >> representing what happens to the object. Adding it to only a few of >> the bindings doesn't seem consistent to me. >> >> -- >> Jeff Squyres >> Cisco Systems >> >> _______________________________________________ >> mpi-21 mailing list >> mpi-21_at_[hidden] >> http://lists.cs.uiuc.edu/mailman/listinfo/mpi-21 > > > > Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner_at_[hidden] > High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530 > University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832 > Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner > Nobelstr. 19, D-70550 Stuttgart, Germany . (Office: Allmandring 30) > _______________________________________________ > mpi-21 mailing list > mpi-21_at_[hidden] > http://lists.cs.uiuc.edu/mailman/listinfo/mpi-21 -- Jeff Squyres Cisco Systems From rabenseifner at [hidden] Tue Feb 5 03:40:29 2008 From: rabenseifner at [hidden] (Rolf Rabenseifner) Date: Tue, 05 Feb 2008 10:40:29 +0100 Subject: [mpi-21] Ballot 4 proposal: INOUT arguments In-Reply-To: <7F8F9D8C-E592-4E99-B4F7-BFB725CA4A17@cisco.com> Message-ID: Jeff, the currently existing INOUT for the handle/object arguments in the routine listed in a previous mail from me indicates a change of the object that can be inquired later on by an MPI inquiry function. What an MPI implementation is doing internally is not shown by these interface definitions. I'm reporting only the obviouus background of the wording in the current MPI 1.1 and MPI 2.0 standard. And there is an inconsistency with the three MPI 1.1 definitions: MPI_ATTR_PUT, MPI_ATTR_DELETE, MPI_ERRHANDLER_SET There are three options to solve it: (all proposal will change the language independent routine definitions but none of the language bindings, and therefore, they do not have any real impact on the existing implementations nor on MPI applications) - modify all such definitions into OUT (will change the MPI 1.1 routine language independent definitions) - modify all such definitions into IN/INOUT (wiil change in MPI 1.1 and 2.0) - modify all such definitions into IN (will change the MPI 2.0 routine language independent definitions) I will prpose all three options to the MPI Forum and the Forum has to decide which options is the best. Best regards Rolf On Mon, 4 Feb 2008 21:15:13 -0500 Jeff Squyres wrote: >On Jan 31, 2008, at 10:26 AM, Rolf Rabenseifner wrote: > >>> If we also want to specify the behavior of the object, then a) that's >>> a huge change (and not one that I'm convinced we need), and b) we >>> need >>> to add a second IN/OUT/INOUT to every language-neutral binding >>> representing what happens to the object. Adding it to only a few of >>> the bindings doesn't seem consistent to me. >> >> The trick is, that we have this problem only with the >> handle/object arguments. >> In most cases we have >> - IN/IN which is abbreviated with IN, e.g., MPI_Send(IN comm), or >> - OUT/OUT which is abbreviated with OUT, e.g., in MPI_Isend(OUT rq), >> or >> - INOUT/INOUT which is abbreviated with INOUT, >> e.g. in MPI_Type_commit(INOUT datatype) >> >> The change, I'm proposing is based on your wish to see the IN for >> the handles that are kept constant. >> Changing no words would continue to show the INOUT >> for the objects itself (that's the way MPI-2 was written). >> >> I would not say, that it is a huge change to add the handle IN >> information to all the interfaces. >> It is not huge, although there are more routines affected >> (also many MPI_FILE routines) as you have mentioned in your >> first mails. > >I'm not sure that this is right, though -- my point is that there are >many functions with IN handles that *do* [implicitly] change the >underlying object (e.g., MPI_SEND can change the communicator >object). Specifically: I do not agree that everywhere we see "IN" in >the current standard means that the object cannot change. > >Aside from the exception statement, we have not stipulated the >behavior of the back-end MPI objects. I think that's a good thing. > >I guess what I don't understand is: why is it useful to specify the >implementation of the back-end MPI objects? > >FWIW: the only thing that matters to the bindings is the behavior of >the handle. > >> >> Okay? >> >> Best regards >> Rolf >> >> On Thu, 31 Jan 2008 09:56:48 -0500 >> Jeff Squyres wrote: >>> On Jan 31, 2008, at 8:46 AM, Rolf Rabenseifner wrote: >>> >>>>> 1. Why do we need to indicate the INOUT status of the back-end MPI >>>>> object in the language neutral bindings? All the bindings -- >>>>> regardless of language -- only deal with the MPI handles, not the >>>>> back- >>>>> end MPI objects. >>>>> >>>>> 2. Adding qualifiers on what is supposed to happen to the back-end >>>>> MPI >>>>> object would seem to require additional semantics on the back-end >>>>> MPI >>>>> object. Should we really be specifying what the implementation >>>>> must/ >>>>> must not do with the back-end MPI object? Who benefits from that? >>>> >>>> After all the MPI_BOTTOM discussion and not knowing what future >>>> languages will bring, I didn't want to remove existing information >>>> from the standard. An opaque object in MPI consists always >>>> of two things: the handle and the object itself. >>>> >>>> The language independent interface should reflect this. >>>> >>>> I thought that especially for the const discussion it would be good >>>> to see the IN for the handle. >>> >>> I agree. >>> >>>> For future HPCS languages, it may be >>>> also necessary see the INOUT for the object itself. >>> >>> I guess my point is that the language bindings don't specify anything >>> about the object itself anywhere else. >>> >>> If we also want to specify the behavior of the object, then a) that's >>> a huge change (and not one that I'm convinced we need), and b) we >>> need >>> to add a second IN/OUT/INOUT to every language-neutral binding >>> representing what happens to the object. Adding it to only a few of >>> the bindings doesn't seem consistent to me. >>> >>> -- >>> Jeff Squyres >>> Cisco Systems >>> >>> _______________________________________________ >>> mpi-21 mailing list >>> mpi-21_at_[hidden] >>> http://lists.cs.uiuc.edu/mailman/listinfo/mpi-21 >> >> >> >> Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner_at_[hidden] >> High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530 >> University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832 >> Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner >> Nobelstr. 19, D-70550 Stuttgart, Germany . (Office: Allmandring 30) >> _______________________________________________ >> mpi-21 mailing list >> mpi-21_at_[hidden] >> http://lists.cs.uiuc.edu/mailman/listinfo/mpi-21 > > >-- >Jeff Squyres >Cisco Systems > >_______________________________________________ >mpi-21 mailing list >mpi-21_at_[hidden] >http://lists.cs.uiuc.edu/mailman/listinfo/mpi-21 Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner_at_[hidden] High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530 University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832 Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner Nobelstr. 19, D-70550 Stuttgart, Germany . (Office: Allmandring 30) From erezh at [hidden] Tue Feb 5 11:23:57 2008 From: erezh at [hidden] (Erez Haba) Date: Tue, 5 Feb 2008 09:23:57 -0800 Subject: [mpi-21] Ballot 4 proposal: INOUT arguments In-Reply-To: Message-ID: <6B68D01C00C9994A8E150183E62A119E6F9D31BD05@NA-EXMSG-C105.redmond.corp.microsoft.com> Who is the "user" of the language independent IN OUT attributes? Don't you end-up looking at the lang dependent binding? -----Original Message----- From: mpi-21-bounces_at_[hidden] [mailto:mpi-21-bounces_at_[hidden]] On Behalf Of Rolf Rabenseifner Sent: Tuesday, February 05, 2008 1:40 AM To: Mailing list for discussion of MPI 2.1 Subject: Re: [mpi-21] Ballot 4 proposal: INOUT arguments Jeff, the currently existing INOUT for the handle/object arguments in the routine listed in a previous mail from me indicates a change of the object that can be inquired later on by an MPI inquiry function. What an MPI implementation is doing internally is not shown by these interface definitions. I'm reporting only the obviouus background of the wording in the current MPI 1.1 and MPI 2.0 standard. And there is an inconsistency with the three MPI 1.1 definitions: MPI_ATTR_PUT, MPI_ATTR_DELETE, MPI_ERRHANDLER_SET There are three options to solve it: (all proposal will change the language independent routine definitions but none of the language bindings, and therefore, they do not have any real impact on the existing implementations nor on MPI applications) - modify all such definitions into OUT (will change the MPI 1.1 routine language independent definitions) - modify all such definitions into IN/INOUT (wiil change in MPI 1.1 and 2.0) - modify all such definitions into IN (will change the MPI 2.0 routine language independent definitions) I will prpose all three options to the MPI Forum and the Forum has to decide which options is the best. Best regards Rolf On Mon, 4 Feb 2008 21:15:13 -0500 Jeff Squyres wrote: >On Jan 31, 2008, at 10:26 AM, Rolf Rabenseifner wrote: > >>> If we also want to specify the behavior of the object, then a) that's >>> a huge change (and not one that I'm convinced we need), and b) we >>> need >>> to add a second IN/OUT/INOUT to every language-neutral binding >>> representing what happens to the object. Adding it to only a few of >>> the bindings doesn't seem consistent to me. >> >> The trick is, that we have this problem only with the >> handle/object arguments. >> In most cases we have >> - IN/IN which is abbreviated with IN, e.g., MPI_Send(IN comm), or >> - OUT/OUT which is abbreviated with OUT, e.g., in MPI_Isend(OUT rq), >> or >> - INOUT/INOUT which is abbreviated with INOUT, >> e.g. in MPI_Type_commit(INOUT datatype) >> >> The change, I'm proposing is based on your wish to see the IN for >> the handles that are kept constant. >> Changing no words would continue to show the INOUT >> for the objects itself (that's the way MPI-2 was written). >> >> I would not say, that it is a huge change to add the handle IN >> information to all the interfaces. >> It is not huge, although there are more routines affected >> (also many MPI_FILE routines) as you have mentioned in your >> first mails. > >I'm not sure that this is right, though -- my point is that there are >many functions with IN handles that *do* [implicitly] change the >underlying object (e.g., MPI_SEND can change the communicator >object). Specifically: I do not agree that everywhere we see "IN" in >the current standard means that the object cannot change. > >Aside from the exception statement, we have not stipulated the >behavior of the back-end MPI objects. I think that's a good thing. > >I guess what I don't understand is: why is it useful to specify the >implementation of the back-end MPI objects? > >FWIW: the only thing that matters to the bindings is the behavior of >the handle. > >> >> Okay? >> >> Best regards >> Rolf >> >> On Thu, 31 Jan 2008 09:56:48 -0500 >> Jeff Squyres wrote: >>> On Jan 31, 2008, at 8:46 AM, Rolf Rabenseifner wrote: >>> >>>>> 1. Why do we need to indicate the INOUT status of the back-end MPI >>>>> object in the language neutral bindings? All the bindings -- >>>>> regardless of language -- only deal with the MPI handles, not the >>>>> back- >>>>> end MPI objects. >>>>> >>>>> 2. Adding qualifiers on what is supposed to happen to the back-end >>>>> MPI >>>>> object would seem to require additional semantics on the back-end >>>>> MPI >>>>> object. Should we really be specifying what the implementation >>>>> must/ >>>>> must not do with the back-end MPI object? Who benefits from that? >>>> >>>> After all the MPI_BOTTOM discussion and not knowing what future >>>> languages will bring, I didn't want to remove existing information >>>> from the standard. An opaque object in MPI consists always >>>> of two things: the handle and the object itself. >>>> >>>> The language independent interface should reflect this. >>>> >>>> I thought that especially for the const discussion it would be good >>>> to see the IN for the handle. >>> >>> I agree. >>> >>>> For future HPCS languages, it may be >>>> also necessary see the INOUT for the object itself. >>> >>> I guess my point is that the language bindings don't specify anything >>> about the object itself anywhere else. >>> >>> If we also want to specify the behavior of the object, then a) that's >>> a huge change (and not one that I'm convinced we need), and b) we >>> need >>> to add a second IN/OUT/INOUT to every language-neutral binding >>> representing what happens to the object. Adding it to only a few of >>> the bindings doesn't seem consistent to me. >>> >>> -- >>> Jeff Squyres >>> Cisco Systems >>> >>> _______________________________________________ >>> mpi-21 mailing list >>> mpi-21_at_[hidden] >>> http://lists.cs.uiuc.edu/mailman/listinfo/mpi-21 >> >> >> >> Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner_at_[hidden] >> High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530 >> University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832 >> Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner >> Nobelstr. 19, D-70550 Stuttgart, Germany . (Office: Allmandring 30) >> _______________________________________________ >> mpi-21 mailing list >> mpi-21_at_[hidden] >> http://lists.cs.uiuc.edu/mailman/listinfo/mpi-21 > > >-- >Jeff Squyres >Cisco Systems > >_______________________________________________ >mpi-21 mailing list >mpi-21_at_[hidden] >http://lists.cs.uiuc.edu/mailman/listinfo/mpi-21 Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner_at_[hidden] High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530 University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832 Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner Nobelstr. 19, D-70550 Stuttgart, Germany . (Office: Allmandring 30) _______________________________________________ mpi-21 mailing list mpi-21_at_[hidden] http://lists.cs.uiuc.edu/mailman/listinfo/mpi-21 From ritzdorf at [hidden] Tue Feb 5 12:35:47 2008 From: ritzdorf at [hidden] (Hubert Ritzdorf) Date: Tue, 05 Feb 2008 19:35:47 +0100 Subject: [mpi-21] Ballot 4 - User defined datarep - was Re: Question toMPI/IO In-Reply-To: <008a01c8642f$f8cbde90$860add8c@mcs.anl.gov> Message-ID: <47A8AC83.3040406@it.neclab.eu> Rajeev Thakur wrote: >> Then in subsequent calls to the conversion function, >> MPI will increment the value in position by the count of items >> converted in the previous call, and userbuf is kept unchanged. >> > > Maybe we should be more clear and say that "the userbuf pointer is left > unchanged" > > Rajeev > I agree to Rajeev. This was the original point of my question. Hubert > > >> -----Original Message----- >> From: mpi-21-bounces_at_[hidden] >> [mailto:mpi-21-bounces_at_[hidden]] On Behalf Of Rolf Rabenseifner >> Sent: Thursday, January 31, 2008 10:49 AM >> To: mpi-21_at_[hidden] >> Subject: [mpi-21] Ballot 4 - User defined datarep - was Re: >> Question toMPI/IO >> >> This is a proposal for MPI 2.1, Ballot 4. >> >> I'm asking especially >> Hubert Ritzdorf, Jean-Pierre Prost, John May, Bill Nitzberg, >> the participants of the email-discussion in 1999, to review >> this proposal. >> >> This is a follow up to: >> Interpretation of user defined datarep >> in >> http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi- >> errata/index.html >> with mail discussion in >> >> http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi- >> errata/discuss/datarep/ >> ___________________________________ >> >> Proposal: >> MPI-2.0 Sect. 9.5.3 User-defined Data Representations, page 254, >> lines 13-15 read: >> Then in subsequent calls to the conversion function, >> MPI will increment the value in position by the count of items >> converted in the previous call. >> >> but should read: >> Then in subsequent calls to the conversion function, >> MPI will increment the value in position by the count of items >> converted in the previous call, and userbuf is kept unchanged. >> >> ___________________________________ >> Rationale for this clarification: >> It was not clear, whether the userbuf pointer must also be moved >> in the subsequent calls. This clarification was already done in >> 1999 and should already be implemented in existing implementations >> of user-defined data representations. >> ___________________________________ >> Total text page 254 lines 8-15: >> If MPI cannot allocate a buffer large enough to hold all the >> data to be converted from a read operation, it may call the >> conversion function repeatedly using the same datatype and >> userbuf, and reading successive chunks of data to be converted >> in filebuf. For the first call (and in the case when all the data >> to be converted fits into filebuf), MPI will call the function >> with position set to zero. Data converted during this call will >> be stored in the userbuf according to the first count data items >> in datatype. Then in subsequent calls to the conversion function, >> MPI will increment the value in position by the count of items >> converted in the previous call, >> (new text added:) >> and userbuf is kept unchanged. >> ___________________________________ >> >> Best regards >> Rolf >> >> >> Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner_at_[hidden] >> High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530 >> University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832 >> Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner >> Nobelstr. 19, D-70550 Stuttgart, Germany . (Office: Allmandring 30) >> _______________________________________________ >> mpi-21 mailing list >> mpi-21_at_[hidden] >> http://lists.cs.uiuc.edu/mailman/listinfo/mpi-21 >> >> >> > > _______________________________________________ > mpi-21 mailing list > mpi-21_at_[hidden] > http://lists.cs.uiuc.edu/mailman/listinfo/mpi-21 > > * -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From jsquyres at [hidden] Tue Feb 5 19:55:41 2008 From: jsquyres at [hidden] (Jeff Squyres) Date: Tue, 5 Feb 2008 20:55:41 -0500 Subject: [mpi-21] Ballot 4 proposal: INOUT arguments In-Reply-To: <6B68D01C00C9994A8E150183E62A119E6F9D31BD05@NA-EXMSG-C105.redmond.corp.microsoft.com> Message-ID: <32A9E6A4-50FE-44F4-B34A-6D6A2240F039@cisco.com> On Feb 5, 2008, at 12:23 PM, Erez Haba wrote: > Who is the "user" of the language independent IN OUT attributes? > Don't you end-up looking at the lang dependent binding? Exactly! The *bindings* are dealing with the handle, not the object. There is no point in having the bindings imply what happens to the back-end object. Denoting an MPI handle as INOUT because you can test the handle later for an observable change (what I have been calling an "explicit" change) is already stated explicitly in the description of all the functions in question (e.g., MPI_COMM_SET_NAME). It doesn't seem that marking the handle INOUT adds any value to the explanation of these functions. In short: I think that this handle exception language should go away, and the IN, OUT, INOUT descriptors should only pertain to the behavior of the handles. This has the added benefit of making mapping to the language-specific bindings much more clear. > > > -----Original Message----- > From: mpi-21-bounces_at_[hidden] [mailto:mpi-21-bounces_at_[hidden]] > On Behalf Of Rolf Rabenseifner > Sent: Tuesday, February 05, 2008 1:40 AM > To: Mailing list for discussion of MPI 2.1 > Subject: Re: [mpi-21] Ballot 4 proposal: INOUT arguments > > Jeff, > > the currently existing INOUT for the handle/object arguments > in the routine listed in a previous mail from me indicates > a change of the object that can be inquired later on by > an MPI inquiry function. What an MPI implementation > is doing internally is not shown by these interface definitions. > > I'm reporting only the obviouus background of the wording > in the current MPI 1.1 and MPI 2.0 standard. > > And there is an inconsistency with the three MPI 1.1 definitions: > MPI_ATTR_PUT, MPI_ATTR_DELETE, MPI_ERRHANDLER_SET > > There are three options to solve it: > (all proposal will change the language independent routine definitions > but none of the language bindings, and therefore, they do not have > any real impact on the existing implementations nor on MPI > applications) > > - modify all such definitions into OUT (will change the MPI 1.1 > routine > language independent definitions) > - modify all such definitions into IN/INOUT (wiil change in MPI 1.1 > and 2.0) > - modify all such definitions into IN (will change the MPI 2.0 routine > language independent definitions) > > I will prpose all three options to the MPI Forum and the Forum has > to decide > which options is the best. > > Best regards > Rolf > > > On Mon, 4 Feb 2008 21:15:13 -0500 > Jeff Squyres wrote: >> On Jan 31, 2008, at 10:26 AM, Rolf Rabenseifner wrote: >> >>>> If we also want to specify the behavior of the object, then a) >>>> that's >>>> a huge change (and not one that I'm convinced we need), and b) we >>>> need >>>> to add a second IN/OUT/INOUT to every language-neutral binding >>>> representing what happens to the object. Adding it to only a few >>>> of >>>> the bindings doesn't seem consistent to me. >>> >>> The trick is, that we have this problem only with the >>> handle/object arguments. >>> In most cases we have >>> - IN/IN which is abbreviated with IN, e.g., MPI_Send(IN comm), or >>> - OUT/OUT which is abbreviated with OUT, e.g., in MPI_Isend(OUT rq), >>> or >>> - INOUT/INOUT which is abbreviated with INOUT, >>> e.g. in MPI_Type_commit(INOUT datatype) >>> >>> The change, I'm proposing is based on your wish to see the IN for >>> the handles that are kept constant. >>> Changing no words would continue to show the INOUT >>> for the objects itself (that's the way MPI-2 was written). >>> >>> I would not say, that it is a huge change to add the handle IN >>> information to all the interfaces. >>> It is not huge, although there are more routines affected >>> (also many MPI_FILE routines) as you have mentioned in your >>> first mails. >> >> I'm not sure that this is right, though -- my point is that there are >> many functions with IN handles that *do* [implicitly] change the >> underlying object (e.g., MPI_SEND can change the communicator >> object). Specifically: I do not agree that everywhere we see "IN" in >> the current standard means that the object cannot change. >> >> Aside from the exception statement, we have not stipulated the >> behavior of the back-end MPI objects. I think that's a good thing. >> >> I guess what I don't understand is: why is it useful to specify the >> implementation of the back-end MPI objects? >> >> FWIW: the only thing that matters to the bindings is the behavior of >> the handle. >> >>> >>> Okay? >>> >>> Best regards >>> Rolf >>> >>> On Thu, 31 Jan 2008 09:56:48 -0500 >>> Jeff Squyres wrote: >>>> On Jan 31, 2008, at 8:46 AM, Rolf Rabenseifner wrote: >>>> >>>>>> 1. Why do we need to indicate the INOUT status of the back-end >>>>>> MPI >>>>>> object in the language neutral bindings? All the bindings -- >>>>>> regardless of language -- only deal with the MPI handles, not the >>>>>> back- >>>>>> end MPI objects. >>>>>> >>>>>> 2. Adding qualifiers on what is supposed to happen to the back- >>>>>> end >>>>>> MPI >>>>>> object would seem to require additional semantics on the back-end >>>>>> MPI >>>>>> object. Should we really be specifying what the implementation >>>>>> must/ >>>>>> must not do with the back-end MPI object? Who benefits from >>>>>> that? >>>>> >>>>> After all the MPI_BOTTOM discussion and not knowing what future >>>>> languages will bring, I didn't want to remove existing information >>>>> from the standard. An opaque object in MPI consists always >>>>> of two things: the handle and the object itself. >>>>> >>>>> The language independent interface should reflect this. >>>>> >>>>> I thought that especially for the const discussion it would be >>>>> good >>>>> to see the IN for the handle. >>>> >>>> I agree. >>>> >>>>> For future HPCS languages, it may be >>>>> also necessary see the INOUT for the object itself. >>>> >>>> I guess my point is that the language bindings don't specify >>>> anything >>>> about the object itself anywhere else. >>>> >>>> If we also want to specify the behavior of the object, then a) >>>> that's >>>> a huge change (and not one that I'm convinced we need), and b) we >>>> need >>>> to add a second IN/OUT/INOUT to every language-neutral binding >>>> representing what happens to the object. Adding it to only a few >>>> of >>>> the bindings doesn't seem consistent to me. >>>> >>>> -- >>>> Jeff Squyres >>>> Cisco Systems >>>> >>>> _______________________________________________ >>>> mpi-21 mailing list >>>> mpi-21_at_[hidden] >>>> http://lists.cs.uiuc.edu/mailman/listinfo/mpi-21 >>> >>> >>> >>> Dr. Rolf Rabenseifner . . . . . . . . . .. email >>> rabenseifner_at_[hidden] >>> High Performance Computing Center (HLRS) . phone + >>> +49(0)711/685-65530 >>> University of Stuttgart . . . . . . . . .. fax ++49(0)711 / >>> 685-65832 >>> Head of Dpmt Parallel Computing . . . www.hlrs.de/people/ >>> rabenseifner >>> Nobelstr. 19, D-70550 Stuttgart, Germany . (Office: Allmandring 30) >>> _______________________________________________ >>> mpi-21 mailing list >>> mpi-21_at_[hidden] >>> http://lists.cs.uiuc.edu/mailman/listinfo/mpi-21 >> >> >> -- >> Jeff Squyres >> Cisco Systems >> >> _______________________________________________ >> mpi-21 mailing list >> mpi-21_at_[hidden] >> http://lists.cs.uiuc.edu/mailman/listinfo/mpi-21 > > > > Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner_at_[hidden] > High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530 > University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832 > Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner > Nobelstr. 19, D-70550 Stuttgart, Germany . (Office: Allmandring 30) > _______________________________________________ > mpi-21 mailing list > mpi-21_at_[hidden] > http://lists.cs.uiuc.edu/mailman/listinfo/mpi-21 > > _______________________________________________ > mpi-21 mailing list > mpi-21_at_[hidden] > http://lists.cs.uiuc.edu/mailman/listinfo/mpi-21 -- Jeff Squyres Cisco Systems From Terry.Dontje at [hidden] Wed Feb 6 06:03:22 2008 From: Terry.Dontje at [hidden] (Terry Dontje) Date: Wed, 06 Feb 2008 07:03:22 -0500 Subject: [mpi-21] Two MPI I/O questions In-Reply-To: <00da01c86446$8ef3f4a0$860add8c@mcs.anl.gov> Message-ID: <47A9A20A.10303@sun.com> I talked with Len and we believe topic one has already been addressed previously and the second topic does not need to be clarified. --td Rajeev Thakur wrote: > I don't think any clarification is needed for the second topic. > > Rajeev > > >> -----Original Message----- >> From: Rolf Rabenseifner [mailto:rabenseifner_at_[hidden]] >> Sent: Tuesday, January 29, 2008 6:22 AM >> To: mpi-21_at_[hidden] >> Cc: Leonard F. Wisniewski; Rajeev Thakur >> Subject: Re: Two MPI I/O questions >> >> Mainly to Leonard Wisniewski and Rajeev Thakur >> who have contributed to this mail-discussion thread. >> >> This is a follow up to: >> Shared File Pointers >> in >> http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi- >> errata/index.html >> with mail discussion in >> >> http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi- >> errata/discuss/sharedfile/ >> >> and here only to the second topic in the mails. >> (The first topic is handled in the thread >> "MPI C++ Constants conflict with stdio") >> >> _________________________________________ >> >> When I understand correctly, then a clarification is not needed >> in the MPI standard. >> >> If somebody wants a clarification to be included into the standard >> and therefore in Ballot 4, please send me your wording >> with the page and line references included. >> >> If all agree, that no clarification is needed, then I would finish >> this discussion-thread. >> >> Best regards >> Rolf >> >> >> >> Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner_at_[hidden] >> High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530 >> University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832 >> Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner >> Nobelstr. 19, D-70550 Stuttgart, Germany . (Office: Allmandring 30) >> >> >> > > _______________________________________________ > mpi-21 mailing list > mpi-21_at_[hidden] > http://lists.cs.uiuc.edu/mailman/listinfo/mpi-21 > From rabenseifner at [hidden] Wed Feb 6 11:37:20 2008 From: rabenseifner at [hidden] (Rolf Rabenseifner) Date: Wed, 06 Feb 2008 18:37:20 +0100 Subject: [mpi-21] Ballot 4 - Re: [mpi-forum] MPI_Startall / MPI_Waitall / MPI_Testall clarification? In-Reply-To: <20080204152403.GA1582@mhdmobile.lan> Message-ID: Dries, Sounds fine. Nobody raised problems with this clarification up to now. Please can you write a full proposal of exactly what to change/add/... I would put it to MPI 2.1 Ballot 4. Best regards Rolf On Mon, 4 Feb 2008 16:24:03 +0100 Dries Kimpe wrote: >>From the standard: (same for MPI_Startall, MPI_Testall) > >The error-free execution of MPI_WAITALL(count, array_of_requests, >array_of_statuses) has the same effect as the execution of >MPI_WAIT(&array_of_request[i], &array_of_statuses[i]), for i=0 ,..., >count-1, in some arbitrary order. > >What about count==0? > >1) Is it allowed? > >2) If it is allowed, should a valid pointer be provided as the >array_of_requests argument? > >Looking at mpich-1.0.6p1, I see the following: > > >Function Allows count==0 Allows bufptr=0 when count==0 >MPI_Testall Y Y >MPI_Testsome Y Y >MPI_Testany Y Y >MPI_Waitsome Y Y >MPI_Waitall Y Y >MPI_Waitany Y Y >MPI_Startall Y N > >For MPI_Startall: > >Fatal error in MPI_Startall: Invalid argument, error stack: >MPI_Startall(147): MPI_Startall(count=0, req_array=(nil)) failed >MPI_Startall(80).: Null pointer in parameter array_of_requests[0]0:Return code = 0, signaled with Interrupt > >Considering the other ...all functions allow count==0 and ignore the array >in this case, the behaviour of MPI_Startall is probably just an oversight >in mpich. > >For some reason, OpenMPI has exactly the same behavior; >MPI_Startall doesn't allow req_array==0 even if count==0 >(MPI_ERR_REQUEST is raised/returned) > >There is also an issue: progress. For example, in OpenMPI, calling >MPI_Testall with count==0 doesn't do anything at all. More specific, it >doesn't call the progress engine. > >Mpich however, does call the progress engine, even if count==0. >(On the other hand, MPI_Waitall does NOT try to make progress if count==0) > >I propose to clarify where needed, and explicitly allow count==0; >Also, if count==0, then 0 should be accepted as pointer for the request >array, and no guarantee of progress should be made. > >If count==0, the returned error code should be MPI_SUCCESS (unless of >course, an asynchronous error is detected). > >It would suffice to add "When count is zero, this call has no effect." >(For MPI_Startall, MPI_Testall, MPI_Waitall this can be right after the >text quoted on top of this message; For MPI_Waitany, MPI_Testany, >MPI_Waitsome, MPI_Testsome, the addition should be at the end of the >paragraph.) > > > Greetings, > Dries > >_______________________________________________ >mpi-forum mailing list >mpi-forum_at_[hidden] >http://lists.cs.uiuc.edu/mailman/listinfo/mpi-forum Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner_at_[hidden] High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530 University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832 Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner Nobelstr. 19, D-70550 Stuttgart, Germany . (Office: Allmandring 30) From treumann at [hidden] Wed Feb 6 12:22:51 2008 From: treumann at [hidden] (Richard Treumann) Date: Wed, 6 Feb 2008 13:22:51 -0500 Subject: [mpi-21] Ballot 4 - Re: [mpi-forum] MPI_Startall / MPI_Waitall / MPI_Testall clarification? In-Reply-To: Message-ID: One comment - the clarification should not mention the progress engine. We have a general requirement in the standard that MPI make progress and there is debate about what that requires. (Must there be an asynchronous progress engine). In general we do not attach a progress semantic to specific MPI calls. Even for something like MPI_Wait, there is no statement that MPI_Wait drives a progress engine. Only that MPI_Wait returns when the request is complete. It is not a part of MPI_Wait semantic to say that the MPI_Wait call runs a progress engine or does not run one. I assume almost every MPI implementation does run its progress engine within a blocked MPI_Wait and probably no MPI gives the progress engine a time limited kick in a MPI_Comm_rank call. Either way it is an impementation decision, not part of the standard. (Of course something like MPI_Comm_rank could not block but if an MPI implementor wanted to run the progress engine for a max of 50 microseconds on every single MPI call, the standard would not forbid it.) Dick Dick Treumann - MPI Team/TCEM IBM Systems & Technology Group Dept 0lva / MS P963 -- 2455 South Road -- Poughkeepsie, NY 12601 Tele (845) 433-7846 Fax (845) 433-8363 mpi-21-bounces_at_[hidden] wrote on 02/06/2008 12:37:20 PM: > Dries, > > Sounds fine. Nobody raised problems with this clarification up to now. > > Please can you write a full proposal of exactly what to change/add/... > > I would put it to MPI 2.1 Ballot 4. > > Best regards > Rolf > > On Mon, 4 Feb 2008 16:24:03 +0100 > Dries Kimpe wrote: > >>From the standard: (same for MPI_Startall, MPI_Testall) > > > >The error-free execution of MPI_WAITALL(count, array_of_requests, > >array_of_statuses) has the same effect as the execution of > >MPI_WAIT(&array_of_request[i], &array_of_statuses[i]), for i=0 ,..., > >count-1, in some arbitrary order. > > > >What about count==0? > > > >1) Is it allowed? > > > >2) If it is allowed, should a valid pointer be provided as the > >array_of_requests argument? > > > >Looking at mpich-1.0.6p1, I see the following: > > > > > >Function Allows count==0 Allows bufptr=0 when count==0 > >MPI_Testall Y Y > >MPI_Testsome Y Y > >MPI_Testany Y Y > >MPI_Waitsome Y Y > >MPI_Waitall Y Y > >MPI_Waitany Y Y > >MPI_Startall Y N > > > >For MPI_Startall: > > > >Fatal error in MPI_Startall: Invalid argument, error stack: > >MPI_Startall(147): MPI_Startall(count=0, req_array=(nil)) failed > >MPI_Startall(80).: Null pointer in parameter array_of_requests[0]0: > Return code = 0, signaled with Interrupt > > > >Considering the other ...all functions allow count==0 and ignore the array > >in this case, the behaviour of MPI_Startall is probably just an oversight > >in mpich. > > > >For some reason, OpenMPI has exactly the same behavior; > >MPI_Startall doesn't allow req_array==0 even if count==0 > >(MPI_ERR_REQUEST is raised/returned) > > > >There is also an issue: progress. For example, in OpenMPI, calling > >MPI_Testall with count==0 doesn't do anything at all. More specific, it > >doesn't call the progress engine. > > > >Mpich however, does call the progress engine, even if count==0. > >(On the other hand, MPI_Waitall does NOT try to make progress if count==0) > > > >I propose to clarify where needed, and explicitly allow count==0; > >Also, if count==0, then 0 should be accepted as pointer for the request > >array, and no guarantee of progress should be made. > > > >If count==0, the returned error code should be MPI_SUCCESS (unless of > >course, an asynchronous error is detected). > > > >It would suffice to add "When count is zero, this call has no effect." > >(For MPI_Startall, MPI_Testall, MPI_Waitall this can be right after the > >text quoted on top of this message; For MPI_Waitany, MPI_Testany, > >MPI_Waitsome, MPI_Testsome, the addition should be at the end of the > >paragraph.) > > > > > > Greetings, > > Dries > > > >_______________________________________________ > >mpi-forum mailing list > >mpi-forum_at_[hidden] > >http://lists.cs.uiuc.edu/mailman/listinfo/mpi-forum > > > > Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner_at_[hidden] > High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530 > University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832 > Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner > Nobelstr. 19, D-70550 Stuttgart, Germany . (Office: Allmandring 30) > _______________________________________________ > mpi-21 mailing list > mpi-21_at_[hidden] > http://lists.cs.uiuc.edu/mailman/listinfo/mpi-21 * -------------- next part -------------- An HTML attachment was scrubbed... URL: From rabenseifner at [hidden] Thu Feb 7 09:42:06 2008 From: rabenseifner at [hidden] (Rolf Rabenseifner) Date: Thu, 07 Feb 2008 16:42:06 +0100 Subject: [mpi-21] Ballot 4 - all proposal now on the web Message-ID: Hi all interested in MPI 2.1! all proposals are now on the Web: http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi-errata/index.html Please, check whether I've done something wrong. Although I've written the details of some of these proposals, I try to be the moderator of the discussion. In some cases, when I saw that several options are possible, and none of these seemed to me technically obvious or perfect, I've put all these options on the web page to allow that the MPI Forum can make those decisions at the March meeting. Please check, whether I've done something wrong or whether I have to add an additional alternative proposal (in this case, please write the proposal with all necessary details (as text) that I can make a cut&paste to the web page plus additional HTML formatting). Please check for the RED flag Ballot 4 topics and help that the missing proposals are written. Best regards Rolf Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner_at_[hidden] High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530 University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832 Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner Nobelstr. 19, D-70550 Stuttgart, Germany . (Office: Allmandring 30) From Terry.Dontje at [hidden] Thu Feb 7 09:49:12 2008 From: Terry.Dontje at [hidden] (Terry Dontje) Date: Thu, 07 Feb 2008 10:49:12 -0500 Subject: [mpi-21] Ballot 4 proposal: fix attribute example 4.13 In-Reply-To: <0367FBAD-2ACE-4BBD-99D8-9D2FB6E0F92B@cisco.com> Message-ID: <47AB2878.8060102@sun.com> Sorry I didn't send this out sooner but in reading the discussion for the errata item "Interlaguage use of Attributes" I think the below proposal has a potential hole that never was resolved in the mail discussion in: http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi-errata/discuss/getattr/ The specific hole pointed out by Nick Nevin in the following paragraph from the email discussion: This might work for predefined attributes where the address can point to the integer value in static storage, but won't work for attributes set by the user in Fortran code. If you store a pointer to the integer as the attribute it may point to a temporary which might no longer exist when you try and access it later. So I think relying on the address passed in for the attribute as opposed to the value could cause some issues with Fortran. --td Jeff Squyres wrote: > Per > http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi-errata/, > the errata item entitled "Error in Example 4.13 in MPI-2 (Use of > Attributes in C and Fortran)". I believe that this errata item > supersedes the errata item "Interlanguage use of Attributes". > > See the mail discussing: > > http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi-errata/discuss/attrcandf/ > > > Proposal: > > Change MPI-2:4.12, p58:36 from: > IF (val.NE.5) THEN CALL ERROR > to > IF (val.NE.address_of_i) THEN CALL ERROR > > Rationale: > > MPI-2:4.12 p58:12-13 and 16-18 clearly state that if an attribute is > set by C, retrieving it in Fortran will obtain the address of the > attribute. > > See the mails for more discussion, including an exhaustive list of > what happens for each of the 9 possibilities of setting and getting > attribute values between the different languages. > From rabenseifner at [hidden] Thu Feb 7 10:28:30 2008 From: rabenseifner at [hidden] (Rolf Rabenseifner) Date: Thu, 07 Feb 2008 17:28:30 +0100 Subject: [mpi-21] Ballot 4 proposal: fix attribute example 4.13 In-Reply-To: <47AB2878.8060102@sun.com> Message-ID: Yes, we should make the following proposal (A) MPI 2.0 Sect.4.12.7 Attributes, page 58 lines 14-16 read: When an integer valued attribute is accessed from C or C++, then MPI xxx get attr will return the address of (a pointer to) the integer valued attribute. but should read: When an integer valued attribute is accessed from C or C++, then MPI xxx get attr will return the address of (a pointer to) the integer valued attribute; the address is only valid as long the attribute is not changed or the object on which the attribute is cached is not freed. Additional proposal (B): Add at the end of the previous text: The application must not change this integer valued attribute at the returned address. Comment: I know, that this proposal has limited value in multithreaded execution when one thread tries to get an attribute and another thread is modifying it, but this must be handled by locks on application level. Proposal A requires that for each call to C routine MPI_xxx_get_attr() with a integer-valued attribute argument, a new location is produced in the object where the attribute is copied and from which the address is returned. Proposal A+B allows that the address of the originally stored integer is returned by MPI_xxx_get_attr(). Therefore A+B requires smallest implementation effort. Is this a good solution? Best regards Rolf On Thu, 07 Feb 2008 10:49:12 -0500 Terry Dontje wrote: >Sorry I didn't send this out sooner but in reading the discussion for >the errata item "Interlaguage use of Attributes" I think the below >proposal has a potential hole that never was resolved in the mail >discussion in: >http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi-errata/discuss/getattr/ > >The specific hole pointed out by Nick Nevin in the following paragraph >from the email discussion: > >This might work for predefined attributes where the address can >point to the integer value in static storage, but won't work for >attributes set by the user in Fortran code. If you store a pointer >to the integer as the attribute it may point to a temporary which >might no longer exist when you try and access it later. > > >So I think relying on the address passed in for the attribute as opposed >to the value could cause some >issues with Fortran. > >--td >Jeff Squyres wrote: >> Per >> http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi-errata/, >> the errata item entitled "Error in Example 4.13 in MPI-2 (Use of >> Attributes in C and Fortran)". I believe that this errata item >> supersedes the errata item "Interlanguage use of Attributes". >> >> See the mail discussing: >> >> http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi-errata/discuss/attrcandf/ >> >> >> Proposal: >> >> Change MPI-2:4.12, p58:36 from: >> IF (val.NE.5) THEN CALL ERROR >> to >> IF (val.NE.address_of_i) THEN CALL ERROR >> >> Rationale: >> >> MPI-2:4.12 p58:12-13 and 16-18 clearly state that if an attribute is >> set by C, retrieving it in Fortran will obtain the address of the >> attribute. >> >> See the mails for more discussion, including an exhaustive list of >> what happens for each of the 9 possibilities of setting and getting >> attribute values between the different languages. >> > >_______________________________________________ >mpi-21 mailing list >mpi-21_at_[hidden] >http://lists.cs.uiuc.edu/mailman/listinfo/mpi-21 Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner_at_[hidden] High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530 University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832 Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner Nobelstr. 19, D-70550 Stuttgart, Germany . (Office: Allmandring 30) From Terry.Dontje at [hidden] Thu Feb 7 11:04:06 2008 From: Terry.Dontje at [hidden] (Terry Dontje) Date: Thu, 07 Feb 2008 12:04:06 -0500 Subject: [mpi-21] Ballot 4 proposal: fix attribute example 4.13 In-Reply-To: <47AB2878.8060102@sun.com> Message-ID: <47AB3A06.7050603@sun.com> After talking with Jeff and reading the spec further I retract my concern because the spec does explicitly cover my concern in the verbage above example 4.13. --td Terry Dontje wrote: > Sorry I didn't send this out sooner but in reading the discussion for > the errata item "Interlaguage use of Attributes" I think the below > proposal has a potential hole that never was resolved in the mail > discussion in: > http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi-errata/discuss/getattr/ > > > The specific hole pointed out by Nick Nevin in the following paragraph > from the email discussion: > > This might work for predefined attributes where the address can > point to the integer value in static storage, but won't work for > attributes set by the user in Fortran code. If you store a pointer > to the integer as the attribute it may point to a temporary which > might no longer exist when you try and access it later. > > > So I think relying on the address passed in for the attribute as > opposed to the value could cause some > issues with Fortran. > > --td > Jeff Squyres wrote: >> Per >> http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi-errata/, >> the errata item entitled "Error in Example 4.13 in MPI-2 (Use of >> Attributes in C and Fortran)". I believe that this errata item >> supersedes the errata item "Interlanguage use of Attributes". >> >> See the mail discussing: >> >> http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi-errata/discuss/attrcandf/ >> >> >> Proposal: >> >> Change MPI-2:4.12, p58:36 from: >> IF (val.NE.5) THEN CALL ERROR >> to >> IF (val.NE.address_of_i) THEN CALL ERROR >> >> Rationale: >> >> MPI-2:4.12 p58:12-13 and 16-18 clearly state that if an attribute is >> set by C, retrieving it in Fortran will obtain the address of the >> attribute. >> >> See the mails for more discussion, including an exhaustive list of >> what happens for each of the 9 possibilities of setting and getting >> attribute values between the different languages. >> > > From jsquyres at [hidden] Thu Feb 7 11:22:27 2008 From: jsquyres at [hidden] (Jeff Squyres) Date: Thu, 7 Feb 2008 12:22:27 -0500 Subject: [mpi-21] Ballot 4 proposal: fix attribute example 4.13 In-Reply-To: Message-ID: On Feb 7, 2008, at 11:28 AM, Rolf Rabenseifner wrote: > MPI 2.0 Sect.4.12.7 Attributes, page 58 lines 14-16 read: > > When an integer valued attribute is accessed from C or C++, > then MPI xxx get attr will return the address of (a pointer to) > the integer valued attribute. > > but should read: > > When an integer valued attribute is accessed from C or C++, > then MPI xxx get attr will return the address of (a pointer to) > the integer valued attribute; the address is only valid as long > the attribute is not changed or the object on which the attribute > is cached is not freed. Shouldn't the "or" in the last phrase be "and"? > Additional proposal (B): Add at the end of the previous text: > The application must not change this integer valued attribute > at the returned address. I had to think about this quite a bit before I "got it" -- you're saying that when an integer-valued attribute is set (from fortran), the MPI implementation must be caching the value internally and then returning a pointer to that internally cached value. Hence, the address is only valid as long as the MPI object is valid. However, I'm not sure about the requirement of not changing the value (for integer-valued attributes). If you MPI_xxx_get_attr from C and change the value, it'll be changed for any subsequent MPI_xxx_get_attr calls from C or Fortran. However, if you MPI_xxx_get_attr from Fortran and change the value, the next call to MPI_xxx_get_attr will have the original value. Are you just trying to avoid this disparity? > Comment: > I know, that this proposal has limited value in multithreaded > execution when one thread tries to get an attribute and another > thread is modifying it, but this must be handled by locks on > application level. > > Proposal A requires that for each call to C routine MPI_xxx_get_attr() > with a integer-valued attribute argument, a new location is > produced in the object where the attribute is copied and from > which the address is returned. > > Proposal A+B allows that the address of the originally stored > integer is returned by MPI_xxx_get_attr(). > > Therefore A+B requires smallest implementation effort. > > Is this a good solution? > > Best regards > Rolf > > On Thu, 07 Feb 2008 10:49:12 -0500 > Terry Dontje wrote: >> Sorry I didn't send this out sooner but in reading the discussion for >> the errata item "Interlaguage use of Attributes" I think the below >> proposal has a potential hole that never was resolved in the mail >> discussion in: >> http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi-errata/discuss/getattr/ >> >> The specific hole pointed out by Nick Nevin in the following >> paragraph >> from the email discussion: >> >> This might work for predefined attributes where the address can >> point to the integer value in static storage, but won't work for >> attributes set by the user in Fortran code. If you store a pointer >> to the integer as the attribute it may point to a temporary which >> might no longer exist when you try and access it later. >> >> >> So I think relying on the address passed in for the attribute as >> opposed >> to the value could cause some >> issues with Fortran. >> >> --td >> Jeff Squyres wrote: >>> Per >>> http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi-errata/ >>> , >>> the errata item entitled "Error in Example 4.13 in MPI-2 (Use of >>> Attributes in C and Fortran)". I believe that this errata item >>> supersedes the errata item "Interlanguage use of Attributes". >>> >>> See the mail discussing: >>> >>> http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi-errata/discuss/attrcandf/ >>> >>> >>> Proposal: >>> >>> Change MPI-2:4.12, p58:36 from: >>> IF (val.NE.5) THEN CALL ERROR >>> to >>> IF (val.NE.address_of_i) THEN CALL ERROR >>> >>> Rationale: >>> >>> MPI-2:4.12 p58:12-13 and 16-18 clearly state that if an attribute is >>> set by C, retrieving it in Fortran will obtain the address of the >>> attribute. >>> >>> See the mails for more discussion, including an exhaustive list of >>> what happens for each of the 9 possibilities of setting and getting >>> attribute values between the different languages. >>> >> >> _______________________________________________ >> mpi-21 mailing list >> mpi-21_at_[hidden] >> http://lists.cs.uiuc.edu/mailman/listinfo/mpi-21 > > > > Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner_at_[hidden] > High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530 > University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832 > Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner > Nobelstr. 19, D-70550 Stuttgart, Germany . (Office: Allmandring 30) > _______________________________________________ > mpi-21 mailing list > mpi-21_at_[hidden] > http://lists.cs.uiuc.edu/mailman/listinfo/mpi-21 -- Jeff Squyres Cisco Systems From jsquyres at [hidden] Thu Feb 7 11:25:05 2008 From: jsquyres at [hidden] (Jeff Squyres) Date: Thu, 7 Feb 2008 12:25:05 -0500 Subject: [mpi-21] Ballot 4 proposal: fix attribute example 4.13 In-Reply-To: <47AB3A06.7050603@sun.com> Message-ID: <755EC143-AFFE-41BC-B543-FA1F9D1AFE99@cisco.com> Terry and I further noticed that there appears to be another minor problem in example 4.13. So here's an addendum to the proposal: MPI-2:4.12.7 p59 line 1 reads: int *p But should read MPI_Aint *p Rationale: The value that is set from fortran is an INTEGER(kind=MPI_ADDRESS_KIND). Hence, to dereference it properly, the corresponding C pointer type needs to be an (MPI_Aint*), not (int*). On Feb 7, 2008, at 12:04 PM, Terry Dontje wrote: > After talking with Jeff and reading the spec further I retract my > concern because the spec does explicitly cover my concern in the > verbage > above example 4.13. > > --td > > Terry Dontje wrote: >> Sorry I didn't send this out sooner but in reading the discussion for >> the errata item "Interlaguage use of Attributes" I think the below >> proposal has a potential hole that never was resolved in the mail >> discussion in: >> http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi-errata/discuss/getattr/ >> >> >> The specific hole pointed out by Nick Nevin in the following >> paragraph >> from the email discussion: >> >> This might work for predefined attributes where the address can >> point to the integer value in static storage, but won't work for >> attributes set by the user in Fortran code. If you store a pointer >> to the integer as the attribute it may point to a temporary which >> might no longer exist when you try and access it later. >> >> >> So I think relying on the address passed in for the attribute as >> opposed to the value could cause some >> issues with Fortran. >> >> --td >> Jeff Squyres wrote: >>> Per >>> http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi-errata/ >>> , >>> the errata item entitled "Error in Example 4.13 in MPI-2 (Use of >>> Attributes in C and Fortran)". I believe that this errata item >>> supersedes the errata item "Interlanguage use of Attributes". >>> >>> See the mail discussing: >>> >>> http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi-errata/discuss/attrcandf/ >>> >>> >>> Proposal: >>> >>> Change MPI-2:4.12, p58:36 from: >>> IF (val.NE.5) THEN CALL ERROR >>> to >>> IF (val.NE.address_of_i) THEN CALL ERROR >>> >>> Rationale: >>> >>> MPI-2:4.12 p58:12-13 and 16-18 clearly state that if an attribute is >>> set by C, retrieving it in Fortran will obtain the address of the >>> attribute. >>> >>> See the mails for more discussion, including an exhaustive list of >>> what happens for each of the 9 possibilities of setting and getting >>> attribute values between the different languages. >>> >> >> > > _______________________________________________ > mpi-21 mailing list > mpi-21_at_[hidden] > http://lists.cs.uiuc.edu/mailman/listinfo/mpi-21 -- Jeff Squyres Cisco Systems From rabenseifner at [hidden] Thu Feb 7 11:51:14 2008 From: rabenseifner at [hidden] (Rolf Rabenseifner) Date: Thu, 07 Feb 2008 18:51:14 +0100 Subject: [mpi-21] Ballot 4 proposal: fix attribute example 4.13 In-Reply-To: Message-ID: On Thu, 7 Feb 2008 12:22:27 -0500 Jeff Squyres wrote: >On Feb 7, 2008, at 11:28 AM, Rolf Rabenseifner wrote: > >> MPI 2.0 Sect.4.12.7 Attributes, page 58 lines 14-16 read: >> >> When an integer valued attribute is accessed from C or C++, >> then MPI xxx get attr will return the address of (a pointer to) >> the integer valued attribute. >> >> but should read: >> >> When an integer valued attribute is accessed from C or C++, >> then MPI xxx get attr will return the address of (a pointer to) >> the integer valued attribute; the address is only valid as long >> the attribute is not changed or the object on which the attribute >> is cached is not freed. > >Shouldn't the "or" in the last phrase be "and"? Yes, "and" is what I wanted to say. >> Additional proposal (B): Add at the end of the previous text: >> The application must not change this integer valued attribute >> at the returned address. > >I had to think about this quite a bit before I "got it" -- you're >saying that when an integer-valued attribute is set (from fortran), >the MPI implementation must be caching the value internally and then >returning a pointer to that internally cached value. Hence, the >address is only valid as long as the MPI object is valid. > >However, I'm not sure about the requirement of not changing the value >(for integer-valued attributes). If you MPI_xxx_get_attr from C and >change the value, it'll be changed for any subsequent MPI_xxx_get_attr >calls from C or Fortran. However, if you MPI_xxx_get_attr from >Fortran and change the value, the next call to MPI_xxx_get_attr will >have the original value. > >Are you just trying to avoid this disparity? Normally, MPI never gives the application the right to change anything in a opaque object without calling an MPI routine. C-routine MPI_xxx_get_attr is called with a handle to a opaque object that has stored a Fortran integer-valued attribute. IF we allow, that MPI_xxx_get_attr returns a pointer to foo and foo contains the value of such fortran-integer-attribute, AND IF we allow that a subsequent same call to MPI_xxx_get_attr returns the same pointer to same foo, AND IF we allow that the application may change the value of foo, THEN I would report: foo is part of the opaque object and we allowed that the application has changed the value without calling MPI_xxx_set_attr. If we do not want this, then there are two solutions: - restrictive: to forbid changing the value from C directly; - memory wasting: producing always a new foo in each call to MPI_xxx_get_attr. Restrictive solution is also faster! Nevertheless - ugly ;-) Kind regards Rolf >> Comment: >> I know, that this proposal has limited value in multithreaded >> execution when one thread tries to get an attribute and another >> thread is modifying it, but this must be handled by locks on >> application level. >> >> Proposal A requires that for each call to C routine MPI_xxx_get_attr() >> with a integer-valued attribute argument, a new location is >> produced in the object where the attribute is copied and from >> which the address is returned. >> >> Proposal A+B allows that the address of the originally stored >> integer is returned by MPI_xxx_get_attr(). >> >> Therefore A+B requires smallest implementation effort. >> >> Is this a good solution? >> >> Best regards >> Rolf >> >> On Thu, 07 Feb 2008 10:49:12 -0500 >> Terry Dontje wrote: >>> Sorry I didn't send this out sooner but in reading the discussion for >>> the errata item "Interlaguage use of Attributes" I think the below >>> proposal has a potential hole that never was resolved in the mail >>> discussion in: >>> http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi-errata/discuss/getattr/ >>> >>> The specific hole pointed out by Nick Nevin in the following >>> paragraph >>> from the email discussion: >>> >>> This might work for predefined attributes where the address can >>> point to the integer value in static storage, but won't work for >>> attributes set by the user in Fortran code. If you store a pointer >>> to the integer as the attribute it may point to a temporary which >>> might no longer exist when you try and access it later. >>> >>> >>> So I think relying on the address passed in for the attribute as >>> opposed >>> to the value could cause some >>> issues with Fortran. >>> >>> --td >>> Jeff Squyres wrote: >>>> Per >>>> http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi-errata/ >>>> , >>>> the errata item entitled "Error in Example 4.13 in MPI-2 (Use of >>>> Attributes in C and Fortran)". I believe that this errata item >>>> supersedes the errata item "Interlanguage use of Attributes". >>>> >>>> See the mail discussing: >>>> >>>> http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi-errata/discuss/attrcandf/ >>>> >>>> >>>> Proposal: >>>> >>>> Change MPI-2:4.12, p58:36 from: >>>> IF (val.NE.5) THEN CALL ERROR >>>> to >>>> IF (val.NE.address_of_i) THEN CALL ERROR >>>> >>>> Rationale: >>>> >>>> MPI-2:4.12 p58:12-13 and 16-18 clearly state that if an attribute is >>>> set by C, retrieving it in Fortran will obtain the address of the >>>> attribute. >>>> >>>> See the mails for more discussion, including an exhaustive list of >>>> what happens for each of the 9 possibilities of setting and getting >>>> attribute values between the different languages. >>>> >>> >>> _______________________________________________ >>> mpi-21 mailing list >>> mpi-21_at_[hidden] >>> http://lists.cs.uiuc.edu/mailman/listinfo/mpi-21 >> >> >> >> Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner_at_[hidden] >> High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530 >> University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832 >> Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner >> Nobelstr. 19, D-70550 Stuttgart, Germany . (Office: Allmandring 30) >> _______________________________________________ >> mpi-21 mailing list >> mpi-21_at_[hidden] >> http://lists.cs.uiuc.edu/mailman/listinfo/mpi-21 > > >-- >Jeff Squyres >Cisco Systems > >_______________________________________________ >mpi-21 mailing list >mpi-21_at_[hidden] >http://lists.cs.uiuc.edu/mailman/listinfo/mpi-21 Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner_at_[hidden] High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530 University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832 Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner Nobelstr. 19, D-70550 Stuttgart, Germany . (Office: Allmandring 30) From jsquyres at [hidden] Thu Feb 7 12:23:53 2008 From: jsquyres at [hidden] (Jeff Squyres) Date: Thu, 7 Feb 2008 13:23:53 -0500 Subject: [mpi-21] Ballot 4 proposal: fix attribute example 4.13 In-Reply-To: Message-ID: <1F98DFE5-B0F0-4427-8CB0-F8ECA5614426@cisco.com> On Feb 7, 2008, at 12:51 PM, Rolf Rabenseifner wrote: >>> Additional proposal (B): Add at the end of the previous text: >>> The application must not change this integer valued attribute >>> at the returned address. >> >> I had to think about this quite a bit before I "got it" -- you're >> saying that when an integer-valued attribute is set (from fortran), >> the MPI implementation must be caching the value internally and then >> returning a pointer to that internally cached value. Hence, the >> address is only valid as long as the MPI object is valid. >> >> However, I'm not sure about the requirement of not changing the value >> (for integer-valued attributes). If you MPI_xxx_get_attr from C and >> change the value, it'll be changed for any subsequent >> MPI_xxx_get_attr >> calls from C or Fortran. However, if you MPI_xxx_get_attr from >> Fortran and change the value, the next call to MPI_xxx_get_attr will >> have the original value. >> >> Are you just trying to avoid this disparity? > > Normally, MPI never gives the application the right to change > anything in a opaque object without calling an MPI routine. > > C-routine MPI_xxx_get_attr is called with a handle to a opaque object > that has stored a Fortran integer-valued attribute. > IF we allow, that MPI_xxx_get_attr returns a pointer to foo > and foo contains the value of such fortran-integer-attribute, > AND IF we allow that a subsequent same call to MPI_xxx_get_attr > returns > the same pointer to same foo, > AND IF we allow that the application may change the value of foo, > THEN I would report: > foo is part of the opaque object > and we allowed that the application has changed the value without > calling MPI_xxx_set_attr. Ah, I can see this rationale. Good point. It might be helpful to have some synopsis of your above text should be part of a "Rationale" block in the official text, because that's not immediately obvious. What I have difficulty resolving, though, is that this would be an asymmetrical exception: 1. set attribute in fortran, get attribute in fortran: allowed to change 2. set attribute in fortran, get attribute in C: *NOT* allowed to change 3. set attribute in C, get attribute in C: allowed to change 4. set attribute in C, get attribute in fortran: allowed to change I can see your rationale; it's just that this asymmetry makes me... uncomfortable. Indeed, case 2 is the only case where the life of the MPI object is related to the life of the attribute. That's just weird to me. But I could probably be convinced that this is ok -- after all, who really cares about attributes! ;-) (e.g., the set-in-C-get-in- fortran case is almost useless...) > If we do not want this, then there are two solutions: > - restrictive: to forbid changing the value from C directly; > - memory wasting: producing always a new foo in each call to > MPI_xxx_get_attr. The memory wasting solution is no good -- we'd either have to say that the caller is reponsible for free()'ing the returned pointer or accept a memory leak, because there's no way for the caller to give the pointer back to MPI and say "I'm done with this". -- Jeff Squyres Cisco Systems From Terry.Dontje at [hidden] Thu Feb 7 12:30:21 2008 From: Terry.Dontje at [hidden] (Terry Dontje) Date: Thu, 07 Feb 2008 13:30:21 -0500 Subject: [mpi-21] Ballot 4 - all proposal now on the web In-Reply-To: Message-ID: <47AB4E3C.9060201@sun.com> Can you clarify the difference between a topic marked "Selected for MPI 2.X Ballot Y" and "Proposed for MPI 2.X Ballot Y"? --td "selected for Rolf Rabenseifner wrote: > Hi all interested in MPI 2.1! > > all proposals are now on the Web: > http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi-errata/index.html > > Please, check whether I've done something wrong. > > Although I've written the details of some of these proposals, > I try to be the moderator of the discussion. > In some cases, when I saw that several options are possible, > and none of these seemed to me technically obvious or perfect, > I've put all these options on the web page to allow that the > MPI Forum can make those decisions at the March meeting. > > Please check, whether I've done something wrong or whether > I have to add an additional alternative proposal > (in this case, please write the proposal with all necessary > details (as text) that I can make a cut&paste to the web page > plus additional HTML formatting). > > Please check for the RED flag Ballot 4 topics > and help that the missing proposals are written. > > Best regards > Rolf > > > Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner_at_[hidden] > High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530 > University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832 > Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner > Nobelstr. 19, D-70550 Stuttgart, Germany . (Office: Allmandring 30) > _______________________________________________ > mpi-21 mailing list > mpi-21_at_[hidden] > http://lists.cs.uiuc.edu/mailman/listinfo/mpi-21 > From rabenseifner at [hidden] Thu Feb 7 13:53:50 2008 From: rabenseifner at [hidden] (Rolf Rabenseifner) Date: Thu, 07 Feb 2008 20:53:50 +0100 Subject: [mpi-21] Ballot 4 - all proposal now on the web In-Reply-To: <47AB4E3C.9060201@sun.com> Message-ID: Not best wording. I used - Selected for MPI 2.1 Ballot x if I would like to have it done in Ballot x but there is no proposal -- may be because there is no need, i.e., this topic is finished -- may be we are waiting for somebody who is writing the final proposal - Proposed for MPI 2.1 Ballot x means, somebody has written a proposal that ready for voting. At least in one case, the wrong word isused on the errata page. On March meeting, we can vote only on proposals that are really existing. I hope, somebody (not limited to discussion members) will write some of the pending proposals. Best regards Rolf PS: Selected for MPI 2.2 meant that the topic was on Bill's slide at Jan. 2008 meeting. On Thu, 07 Feb 2008 13:30:21 -0500 Terry Dontje wrote: >Can you clarify the difference between a topic marked "Selected for MPI >2.X Ballot Y" and "Proposed for MPI 2.X Ballot Y"? > >--td Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner_at_[hidden] High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530 University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832 Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner Nobelstr. 19, D-70550 Stuttgart, Germany . (Office: Allmandring 30) From rabenseifner at [hidden] Sun Feb 10 03:17:47 2008 From: rabenseifner at [hidden] (Rolf Rabenseifner) Date: Sun, 10 Feb 2008 10:17:47 +0100 Subject: [mpi-21] MPI 1.3 - errata from Ballot 3 and 4 Message-ID: Proposal: The following topics on http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi-errata/index.html hould be marked with "To be included also in MPI 1.3" ----------------------------------------------------- Error in MPI_Scan Example Error in MPI-1, Example 3.12 Error in MPI-1, Example 3.12, continued Error in MPI-1, Example 3.13 Error in MPI-1, Examples 3.17 and 3.18 Error in MPI-1, Example 3.34 Use of strlen in MPI-1, chapter 3 Formatting error in discussion of persistent communication in MPI-1 Datatypes and MPI_PROBE MPI_Abort Error handler for multiple completions (if ready for March meeting) Not marked and therefore not included in MPI1.3 should be: ---------------------------------------------------------- Questions about Graph_create, Cart_create, and Cart_coords (not included, because it may require Impl.Effort, i.e. new version number 2.1) Error handler for multiple completions (if ready for March meeting) (not included or included, --- must be decided when proposal available) MPI_FINALIZE in MPI-2 (with spawn) (if ready for March meeting) (not included, because MPI&Threads is MPI 2) MPI_GET_PROCESSOR_NAME and Fortran (not included, because it may require Impl.Effort, i.e. new version number 2.1) Change "INOUT" to "IN" for MPI Handle Parameters in several routines (not included, because related to new MPI-2 Chapter 2 Terms&... Text) I hope I captured all currently proposed MPI-1.1 clarifications in Ballot 3 and 4. Best regards Rolf Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner_at_[hidden] High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530 University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832 Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner Nobelstr. 19, D-70550 Stuttgart, Germany . (Office: Allmandring 30) From rabenseifner at [hidden] Sat Feb 23 15:19:18 2008 From: rabenseifner at [hidden] (Rolf Rabenseifner) Date: Sat, 23 Feb 2008 22:19:18 +0100 Subject: [Mpi-21] Review of MPI-2.1 combined document In-Reply-To: Message-ID: The first draft of the combined document MPI 1.x plus MPI 2.0 is ready for review !!! All necessary files can be found via http://www.hlrs.de/mpi/mpi21/ The files are stored in a restricted directory to prohibit that search engines can find the drafts. Dear reviewer: Please print your chapter with colors (!) and check all merging decisions. The colors will help to identify MPI 1.1-1.3 (black), MPI-2.0 (magenta) and new text that was necessary for the merge (red). The review should be finished a few days before the March meeting. Please post your review results on mpi-21_at_[hidden] as reply to this mail. Please note, which chapter you reviewed. Please refer with all comments exactly to page and line numbers of - MPI 1.1, the official Postscript version - MPI 2.0, the official Postscript version - MPI 2.1, draft 2008-02-23 from http://www.hlrs.de/mpi/mpi21/ - and the merging plan 2008-02-23, that you can find at same directory If you detect a problem, it is necessary that you try to propose a solution in similar notation as used in the merging plan. I have finished all except the merging of the MPI-1 C++ bindings into the chapters' text, and except of merging the Annexes. The Ballots 1-4 are also not included. In the moment, you need to review only the "merging". Nothing more. If you detect errors in the original standards, then please go through normal procedure, i.e., through the MPI 2.1 and MPI 2.2 ballots. And now, thank you very much that you have registered to do a review (if you are on the list below, done in Jan.2008 meeting). Good luck. Best regards Rolf ---------------------------------------------------- Frontmatter: (I've done a new proposal for the abstract, please check) - Rusty Lusk, Bill Gropp Chap. 1: Introduction to MPI - Rusty Lusk, Bill Gropp, Karl Feind, Adam Moody Chap. 2: MPI-2 Terms and Conventions - Tony Skjellum, Bill Gropp, Richard Barrett Chap. 3: Point-to-Point Communication (incl. sections from MPI-2 Misc. + 8.9) - Rich Graham, Jespar Larsson Traeff, George Bosilca, Steve Poole, Kannan Narasimhan, David Solt, B. Gropp, Matt Koop Chap. 4: Collective Communication (incl. sections from MPI-2 Ext. Collect.) - Steven Ericsson-Zenith, Edgar Gabriel, Rajeev Thakur, Bill Gropp, Adam Moody, Georg Bosilca Chap. 5: Groups, Context, and Communicators (incl. sections from MPI-2 Ext.Col. + 8.8) - Steven Ericsson-Zenith, Edgar Gabriel, Bill Gropp, Georg Bosilca, Robert Blackmore Chap. 6: Process Topologies - Rusty Lusk, Bill Gropp, Richard Barrett Chap. 7: MPI Environmental Management (incl. sections from MPI-2 Misc.) - Rich Graham, Jespar Larsson Traeff, George Bosilca, Steve Poole, Kannan Narasimhan, David Solt, B. Gropp Chap. 8: Miscellany - Rich Graham, George Bosilca, Steve Poole, Kannan Narasimhan, B. Gropp Chap. 9: Process Creation and Management - Dries Kimpe, Rusty Lusk, Georg Bosilca, Bill Gropp, Kalem Karian Chap. 10: One-Sided Communication - Ericsson-Zenith, Jespar Larsson Traeff, Martin Schulz, Bill Gropp, Darius Buntinas Chap. 11: External Interfaces - Bronis de Supinski, Bill Gropp Chap. 12: I/O - Rajeev Thakur, Joachim Worringen, Bill Gropp Chap. 13: Language Bindings - Jeff Squyres, Steve Poole, Purushotham Bangalore, Bill Gropp, Erez Haba, Alexander Supalov Chap. 14: Profiling Interface - Bronis de Supinski, Bill Gropp, Jeff Brown Bibliography: (is done automatically) - Rusty Lusk, Bill Gropp Annex A: (this chapter is not yet done - therefore no review for this) - Jeff Squyres, Steve Poole, Purushotham Bangalore, Bill Gropp, Alexander Supalov Index: (is done automatically) - Rusty Lusk, Bill Gropp Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner_at_[hidden] High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530 University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832 Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner Nobelstr. 19, D-70550 Stuttgart, Germany . (Office: Allmandring 30)