- Mpi-21 - mailman3.cels.anl.gov

Re: [mpi-21] Ballot 4 proposal: INOUT arguments
by unknown＠example.com 05 Feb '08

05 Feb '08

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 <jsquyres_at_[hidden]> 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 <jsquyres_at_[hidden]> 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

1 0

Re: [mpi-21] Ballot 4 - User defined datarep - was Re: Question toMPI/IO
by unknown＠example.com 05 Feb '08

05 Feb '08

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

1 0

Re: [mpi-21] Ballot 4 proposal: INOUT arguments
by unknown＠example.com 05 Feb '08

05 Feb '08

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 <jsquyres_at_[hidden]> 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 <jsquyres_at_[hidden]> 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

1 0

Re: [mpi-21] Ballot 4 proposal: INOUT arguments
by unknown＠example.com 05 Feb '08

05 Feb '08

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 <jsquyres_at_[hidden]> 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 <jsquyres_at_[hidden]> 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)

1 0

Re: [mpi-21] Ballot 4 proposal: INOUT arguments
by unknown＠example.com 04 Feb '08

04 Feb '08

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 <jsquyres_at_[hidden]> 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

1 0

Re: [mpi-21] Ballot 4 - Re: Request for interpretation
by unknown＠example.com 01 Feb '08

01 Feb '08

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 <james.h.cownie_at_[hidden]> 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 <treumann_at_[hidden]> 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 <james.h.cownie_at_[hidden]> > >> 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 <james.h.cownie_at_[hidden]> > >> > 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.

1 0

Re: [mpi-21] Ballot 4 - MPI_THREAD_FUNNELED - was Re: Attending, topics, etc
by unknown＠example.com 31 Jan '08

31 Jan '08

Greg - you are correct and I am a bit embarassed by my word choice. To "insure" can mean "to join with others to distribute or smooth risk". To "ensure" is to "make certain it will be so". 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:56:55 PM: > On Thu, Jan 31, 2008 at 09:26:07PM +0100, Rolf Rabenseifner wrote: > > > Dick, I fully agree. I withdraw my proposals with OpenMP and come > > back to your text, adding the forward reference to MPI_IS_THREAD_MAIN: > > > > >> >>> MPI_THREAD_FUNNELED The process may be multi-threaded, but the > > >> >>> application > > >> >>> must insure that only the main thread makes MPI calls > > (for the definition of main thread, see MPI_IS_THREAD_MAIN). > > > > By the way, this clarification is independent of any > > additional level of thread support taht may be specified in > > further MPI versions. > > I also agree with this version of the clarification. > > BTW, it should be "ensure", not "insure". The current MPI 2.0 doc has > "ensure" 28 times and "insure" 0 times. > > -- greg > > _______________________________________________ > mpi-21 mailing list > mpi-21_at_[hidden] > http://lists.cs.uiuc.edu/mailman/listinfo/mpi-21 *

1 0

Re: [mpi-21] Ballot 4 - MPI_THREAD_FUNNELED - was Re: Attending, topics, etc
by unknown＠example.com 31 Jan '08

31 Jan '08

On Thu, Jan 31, 2008 at 09:26:07PM +0100, Rolf Rabenseifner wrote: > Dick, I fully agree. I withdraw my proposals with OpenMP and come > back to your text, adding the forward reference to MPI_IS_THREAD_MAIN: > > >> >>> MPI_THREAD_FUNNELED The process may be multi-threaded, but the > >> >>> application > >> >>> must insure that only the main thread makes MPI calls > (for the definition of main thread, see MPI_IS_THREAD_MAIN). > > By the way, this clarification is independent of any > additional level of thread support taht may be specified in > further MPI versions. I also agree with this version of the clarification. BTW, it should be "ensure", not "insure". The current MPI 2.0 doc has "ensure" 28 times and "insure" 0 times. -- greg

1 0

Re: [mpi-21] Ballot 4 - Re: Request for interpretation
by unknown＠example.com 31 Jan '08

31 Jan '08

Not quite; For example the standard offers: { cb_buffer_size} (integer) {SAME}: This hint specifies the total buffer space that can be used for collective buffering on each target node, usually a multiple of cb_block_size. The standard says a program is "erroneous" if the value is not the same at all callers. That is not exactly the same as the standard defining behavior for MPI_FILE_OPEN with a valid key and garbage value but pretty close. If MPI 3 adds new defined keys for new specific functions it may or may not want to go into defining behavior for some kinds of bad input. 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 03:55:15 PM: > Do we mean "implementation defined" instead of "undefined"? > > On Thu, 31 Jan 2008 14:16:20 -0500 > Richard Treumann <treumann_at_[hidden]> 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 <james.h.cownie_at_[hidden]> > >> 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 <james.h.cownie_at_[hidden]> > >> > 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 *

1 0

Re: [mpi-21] Ballot 4 - Re: MPI-2 thread safety and collectives
by unknown＠example.com 31 Jan '08

31 Jan '08

Rolf, Karl's original mail in this thread asked a simpler question, namely, what is considered as conflicting calls when using the same communicator. His scenario 1 is Thread 1: MPI_Allreduce(..., comm) Thread 2: MPI_File_open(..., comm, ...) His scenario 2 is Thread 1: MPI_Allreduce(..., MPI_SUM, comm) Thread 2: MPI_Allreduce(..., MPI_MAX, comm) I don't think there is any doubt about scenario 2 being conflicting. In my opinion, even scenario 1 is conflicting because they are 2 MPI collective calls explicitly on the same communicator (the file handle is not yet created). He is asking for some clarification on scenario 1. Your proposed advice to users is for collective calls on different objects (file handles, window objects) derived from the same communicator. (It is nonetheless useful to have it in addition.) Rajeev > -----Original Message----- > From: owner-mpi-21_at_[hidden] > [mailto:owner-mpi-21_at_[hidden]] On Behalf Of Rolf Rabenseifner > Sent: Monday, January 21, 2008 11:26 AM > To: mpi-21_at_[hidden] > Cc: mpi-21_at_[hidden] > Subject: [mpi-21] Ballot 4 - Re: MPI-2 thread safety and collectives > > This is a proposal for MPI 2.1, Ballot 4. > > This is a follow up to: > Thread safety and collective communication > 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/thread-safety/index.htm > > After checking the e-mails and looking at > - MPI-2 8.7.2 page 195 lines 6-9 > Collective calls Matching of collective calls on a communicator, > window, or file handle is done according to the order in > which the > calls are issued at each process. If concurrent threads > issue such > calls on the same communicator, window or file handle, it > is up to > the user to make sure the calls are correctly ordered, using > interthread synchronization. > - MPI-2 6.2.1 Window Creation, page 110, lines 10-12: > The call returns an opaque object that represents the group of > processes that own and access the set of windows, and the > attributes > of each window, as specified by the initialization call. > - MPI-2 9.2. Opening a File, page 211, line 46 - page 212, line 2: > Note that the communicator comm is unaffected by MPI FILE OPEN > and continues to be usable in all MPI routines (e.g., MPI SEND). > Furthermore, the use of comm will not interfere with I/O behavior. > it seems that the standard should be clarified. > > > Proposal for MPI 2.1, Ballot 4: > ------------------------------- > Add new paragraphs after MPI-2, 8.7.2 page 195 line 9 (the > end of the clarification on "Collective calls"): > > Advice to users. > With three concurrent threads in each MPI process of a > communicator comm, > it is allowed that thread A in each MPI process calls a collective > operation on comm, thread B calls a file operation on an existing > filehandle that was formerly opened on comm, and thread C > invokes one-sided > operations on an existing window handle that was also > formerly created > on comm. > (End of advice to users.) > > Rationale. > As already specified in MP_FILE_OPEN and MI_WIN_CREATE, a > file handle and > a window handle inherit only the group of processes of the > underlying > communicator, but not the communicator itself. Accesses to > communicators, > window handles and file handles cannot affect one another. > (End of rationale.) > > Advice to implementors. > If the implementation of file or window operations wants to > internally > use MPI communication then a duplicated communicator handle > may be cached > on the file or window handle. > (End of advice to implementors.) > ------------------------------- > > Reason: The emails have shown, that the current MPI-2 text can be > well misunderstood. > ------------------------------- > > Discussion should be done through the new mailing list > mpi-21_at_cs.uiuc.edu. > > I have sent out this mail with CC through the old general list > mpi-21_at_[hidden] > > 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) > >

1 0