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

Re: [mpi-21] Ballot 4 proposal: fix attribute example 4.13
by unknown＠example.com 07 Feb '08

07 Feb '08

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/discus… 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/discus… > > > 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. >

1 0

Ballot 4 - all proposal now on the web
by unknown＠example.com 07 Feb '08

07 Feb '08

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

1 0

Re: [mpi-21] Ballot 4 - Re: [mpi-forum] MPI_Startall / MPI_Waitall / MPI_Testall clarification?
by unknown＠example.com 06 Feb '08

06 Feb '08

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 <Dries.Kimpe_at_[hidden]> 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 *

1 0

Ballot 4 - Re: [mpi-forum] MPI_Startall / MPI_Waitall / MPI_Testall clarification?
by unknown＠example.com 06 Feb '08

06 Feb '08

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 <Dries.Kimpe_at_[hidden]> 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)

1 0

Re: [mpi-21] Two MPI I/O questions
by unknown＠example.com 06 Feb '08

06 Feb '08

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 >

1 0

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