From goodell at [hidden] Fri Mar 6 13:08:34 2009 From: goodell at [hidden] (Dave Goodell) Date: Fri, 6 Mar 2009 13:08:34 -0600 Subject: [Mpi-22] MPI_Aint/MPI_ADDRESS_KIND equivalence and ticket #18 Message-ID: <963BCCA3-42C3-45B2-A110-7996BD8FFDAA@mcs.anl.gov> At the last meeting in San Jose, Rolf brought up a good point w.r.t. ticket #18 [1]. Part of the proposal for ticket #18 is to add MPI_AINT and MPI_OFFSET types corresponding to MPI_Aint/ MPI_ADDRESS_KIND and MPI_Offset/MPI_OFFSET_KIND language types. Rolf's point was that it isn't defined in the standard whether or not MPI_Aint and INTEGER(KIND=MPI_ADDRESS_KIND) are exactly the same type. Obviously we cannot define a new predefined datatype corresponding to two different language types. I believe Rolf's view (correct me if I'm misrepresenting you, Rolf) was that the forum ought to make their equivalence explicit, irrespective of what happens with ticket #18. I'm ambivalent about this issue, but I need a resolution on it in order to get #18 into a final voteable state. So the larger question to the Forum is: Are these types exactly the same between the two languages? Looking at MPICH2 it seems that we try to make them the same size but there are some convoluted code paths in the build logic that might result in different sizes. I would not consider this to be a compelling argument that they are permitted to differ because the logic in question may simply be buggy or never exercised. Does anyone have an example from other MPI implementations where the types do/may differ? Do any Fortran experts out there know of instances where MPI_ADDRESS_KIND would be different from MPI_Aint? As for the impact on ticket #18, there are several ways to deal with this: 1) If the Forum decides that the types are always equivalent, add text to that effect (probably in a separate ticket) and otherwise stick with the current proposal. 2) If the Forum decides that the type equivalence is undefined, drop the new MPI_AINT/MPI_OFFSET types from the proposal. 3) If the Forum decides that the type equivalence is undefined, create four types instead of just two: MPI_AINT, MPI_OFFSET, MPI_F_AINT, MPI_F_OFFSET (or some such names). 4) If the Forum decides that the type equivalence is undefined, make MPI_AINT/MPI_OFFSET only correspond to the C types. I'm inclined towards either #1 or #2, depending on what the Forum decides about the type equivalence. I also can separate the MPI_AINT/ MPI_OFFSET types out into a separate ticket if this becomes too contentious of an issue, but I'd like to keep it together for now since the text changes are easier to describe correctly in just one place. -Dave [1] https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/18 From thakur at [hidden] Mon Mar 9 13:34:13 2009 From: thakur at [hidden] (Rajeev Thakur) Date: Mon, 9 Mar 2009 13:34:13 -0500 Subject: [Mpi-22] MPI_Aint/MPI_ADDRESS_KIND equivalence and ticket #18 In-Reply-To: <963BCCA3-42C3-45B2-A110-7996BD8FFDAA@mcs.anl.gov> Message-ID: <59C27894EADC42DAA1EE7FA662986DD4@mcs.anl.gov> Address-sized variables in MPI can be passed from C to Fortran or vice versa, and I know of no c2f or f2c conversion functions for them. So I think MPI_Aint and integer (kind=MPI_ADDRESS_KIND) are assumed to be of the same size at least implicitly. Rajeev > -----Original Message----- > From: mpi-22-bounces_at_[hidden] > [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Dave Goodell > Sent: Friday, March 06, 2009 1:09 PM > To: MPI 2.2 > Subject: [Mpi-22] MPI_Aint/MPI_ADDRESS_KIND equivalence and ticket #18 > > At the last meeting in San Jose, Rolf brought up a good point w.r.t. > ticket #18 [1]. Part of the proposal for ticket #18 is to add > MPI_AINT and MPI_OFFSET types corresponding to MPI_Aint/ > MPI_ADDRESS_KIND and MPI_Offset/MPI_OFFSET_KIND language types. > Rolf's point was that it isn't defined in the standard > whether or not > MPI_Aint and INTEGER(KIND=MPI_ADDRESS_KIND) are exactly the same > type. Obviously we cannot define a new predefined datatype > corresponding to two different language types. I believe > Rolf's view > (correct me if I'm misrepresenting you, Rolf) was that the > forum ought > to make their equivalence explicit, irrespective of what > happens with > ticket #18. I'm ambivalent about this issue, but I need a > resolution > on it in order to get #18 into a final voteable state. > > So the larger question to the Forum is: Are these types exactly the > same between the two languages? > > Looking at MPICH2 it seems that we try to make them the same > size but > there are some convoluted code paths in the build logic that might > result in different sizes. I would not consider this to be a > compelling argument that they are permitted to differ because the > logic in question may simply be buggy or never exercised. > Does anyone > have an example from other MPI implementations where the > types do/may > differ? Do any Fortran experts out there know of instances where > MPI_ADDRESS_KIND would be different from MPI_Aint? > > As for the impact on ticket #18, there are several ways to deal with > this: > > 1) If the Forum decides that the types are always equivalent, > add text > to that effect (probably in a separate ticket) and otherwise stick > with the current proposal. > 2) If the Forum decides that the type equivalence is undefined, drop > the new MPI_AINT/MPI_OFFSET types from the proposal. > 3) If the Forum decides that the type equivalence is > undefined, create > four types instead of just two: MPI_AINT, MPI_OFFSET, MPI_F_AINT, > MPI_F_OFFSET (or some such names). > 4) If the Forum decides that the type equivalence is undefined, make > MPI_AINT/MPI_OFFSET only correspond to the C types. > > I'm inclined towards either #1 or #2, depending on what the Forum > decides about the type equivalence. I also can separate the > MPI_AINT/ > MPI_OFFSET types out into a separate ticket if this becomes too > contentious of an issue, but I'd like to keep it together for now > since the text changes are easier to describe correctly in just one > place. > > -Dave > > [1] https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/18 > _______________________________________________ > mpi-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 > From jsquyres at [hidden] Mon Mar 9 14:17:21 2009 From: jsquyres at [hidden] (Jeff Squyres) Date: Mon, 9 Mar 2009 15:17:21 -0400 Subject: [Mpi-22] MPI_Aint/MPI_ADDRESS_KIND equivalence and ticket #18 In-Reply-To: <59C27894EADC42DAA1EE7FA662986DD4@mcs.anl.gov> Message-ID: On Mar 9, 2009, at 2:34 PM, Rajeev Thakur wrote: > Address-sized variables in MPI can be passed from C to Fortran or vice > versa, and I know of no c2f or f2c conversion functions for them. So > I think > MPI_Aint and integer (kind=MPI_ADDRESS_KIND) are assumed to be of > the same > size at least implicitly. > I agree. Should we state this explicitly somewhere (if we didn't already)? > > Rajeev > > > > -----Original Message----- > > From: mpi-22-bounces_at_[hidden] > > [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Dave > Goodell > > Sent: Friday, March 06, 2009 1:09 PM > > To: MPI 2.2 > > Subject: [Mpi-22] MPI_Aint/MPI_ADDRESS_KIND equivalence and ticket > #18 > > > > At the last meeting in San Jose, Rolf brought up a good point w.r.t. > > ticket #18 [1]. Part of the proposal for ticket #18 is to add > > MPI_AINT and MPI_OFFSET types corresponding to MPI_Aint/ > > MPI_ADDRESS_KIND and MPI_Offset/MPI_OFFSET_KIND language types. > > Rolf's point was that it isn't defined in the standard > > whether or not > > MPI_Aint and INTEGER(KIND=MPI_ADDRESS_KIND) are exactly the same > > type. Obviously we cannot define a new predefined datatype > > corresponding to two different language types. I believe > > Rolf's view > > (correct me if I'm misrepresenting you, Rolf) was that the > > forum ought > > to make their equivalence explicit, irrespective of what > > happens with > > ticket #18. I'm ambivalent about this issue, but I need a > > resolution > > on it in order to get #18 into a final voteable state. > > > > So the larger question to the Forum is: Are these types exactly the > > same between the two languages? > > > > Looking at MPICH2 it seems that we try to make them the same > > size but > > there are some convoluted code paths in the build logic that might > > result in different sizes. I would not consider this to be a > > compelling argument that they are permitted to differ because the > > logic in question may simply be buggy or never exercised. > > Does anyone > > have an example from other MPI implementations where the > > types do/may > > differ? Do any Fortran experts out there know of instances where > > MPI_ADDRESS_KIND would be different from MPI_Aint? > > > > As for the impact on ticket #18, there are several ways to deal with > > this: > > > > 1) If the Forum decides that the types are always equivalent, > > add text > > to that effect (probably in a separate ticket) and otherwise stick > > with the current proposal. > > 2) If the Forum decides that the type equivalence is undefined, drop > > the new MPI_AINT/MPI_OFFSET types from the proposal. > > 3) If the Forum decides that the type equivalence is > > undefined, create > > four types instead of just two: MPI_AINT, MPI_OFFSET, MPI_F_AINT, > > MPI_F_OFFSET (or some such names). > > 4) If the Forum decides that the type equivalence is undefined, make > > MPI_AINT/MPI_OFFSET only correspond to the C types. > > > > I'm inclined towards either #1 or #2, depending on what the Forum > > decides about the type equivalence. I also can separate the > > MPI_AINT/ > > MPI_OFFSET types out into a separate ticket if this becomes too > > contentious of an issue, but I'd like to keep it together for now > > since the text changes are easier to describe correctly in just one > > place. > > > > -Dave > > > > [1] https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/18 > > _______________________________________________ > > mpi-22 mailing list > > mpi-22_at_[hidden] > > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 > > > > _______________________________________________ > mpi-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 -- Jeff Squyres Cisco Systems From erezh at [hidden] Thu Mar 12 13:23:58 2009 From: erezh at [hidden] (Erez Haba) Date: Thu, 12 Mar 2009 11:23:58 -0700 Subject: [Mpi-22] Ticket #46: Add const Keyword to the C bindings - implementation Message-ID: <6B68D01C00C9994A8E150183E62A119E7B7323939F@NA-EXMSG-C105.redmond.corp.microsoft.com> Implementation for ticket #46 is now available from ANL (thanks Pavan) tarballs http://www.mcs.anl.gov/research/projects/mpich2/downloads/tarballs/nightly/const thanks, .Erez * -------------- next part -------------- An HTML attachment was scrubbed... URL: From keith.d.underwood at [hidden] Thu Mar 12 13:34:18 2009 From: keith.d.underwood at [hidden] (Underwood, Keith D) Date: Thu, 12 Mar 2009 12:34:18 -0600 Subject: [Mpi-22] Ticket #46: Add const Keyword to the C bindings - implementation In-Reply-To: <6B68D01C00C9994A8E150183E62A119E7B7323939F@NA-EXMSG-C105.redmond.corp.microsoft.com> Message-ID: <8E9963DB482E4B49AB9EF1C296936CF718E23F03@rrsmsx507.amr.corp.intel.com> Since the main purpose of an implementation for something like adding const is to see how invasive the change is, would it be possible to get a diff against the trees that these were created from? Thanks, Keith ________________________________ From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Erez Haba Sent: Thursday, March 12, 2009 12:24 PM To: MPI 2.2 Subject: [Mpi-22] Ticket #46: Add const Keyword to the C bindings - implementation Implementation for ticket #46 is now available from ANL (thanks Pavan) tarballs http://www.mcs.anl.gov/research/projects/mpich2/downloads/tarballs/nightly/const thanks, .Erez * -------------- next part -------------- An HTML attachment was scrubbed... URL: From jsquyres at [hidden] Thu Mar 12 13:34:22 2009 From: jsquyres at [hidden] (Jeff Squyres) Date: Thu, 12 Mar 2009 14:34:22 -0400 Subject: [Mpi-22] Ticket #46: Add const Keyword to the C bindings- implementation In-Reply-To: <8E9963DB482E4B49AB9EF1C296936CF718E23F03@rrsmsx507.amr.corp.intel.com> Message-ID: More importantly, how is const handled? Is it just cast away inside the MPI library? On Mar 12, 2009, at 2:34 PM, Underwood, Keith D wrote: > Since the main purpose of an implementation for something like > adding const is to see how invasive the change is, would it be > possible to get a diff against the trees that these were created from? > > Thanks, > Keith > > From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden] > ] On Behalf Of Erez Haba > Sent: Thursday, March 12, 2009 12:24 PM > To: MPI 2.2 > Subject: [Mpi-22] Ticket #46: Add const Keyword to the C bindings - > implementation > > > Implementation for ticket #46 is now available from ANL (thanks Pavan) > > > tarballs > http://www.mcs.anl.gov/research/projects/mpich2/downloads/tarballs/nightly/const > > > thanks, > .Erez > > _______________________________________________ > mpi-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 -- Jeff Squyres Cisco Systems From erezh at [hidden] Thu Mar 12 13:37:11 2009 From: erezh at [hidden] (Erez Haba) Date: Thu, 12 Mar 2009 11:37:11 -0700 Subject: [Mpi-22] Ticket #46: Add const Keyword to the C bindings - implementation In-Reply-To: <8E9963DB482E4B49AB9EF1C296936CF718E23F03@rrsmsx507.amr.corp.intel.com> Message-ID: <6B68D01C00C9994A8E150183E62A119E7B732393CE@NA-EXMSG-C105.redmond.corp.microsoft.com> See the ticket. It has a link to the svn. I'm not sure if ANL has a diff/patch on top of the trunk. Pavan? Rajeev? Thanks, .Erez From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Underwood, Keith D Sent: Thursday, March 12, 2009 11:34 AM To: MPI 2.2 Subject: Re: [Mpi-22] Ticket #46: Add const Keyword to the C bindings - implementation Since the main purpose of an implementation for something like adding const is to see how invasive the change is, would it be possible to get a diff against the trees that these were created from? Thanks, Keith ________________________________ From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Erez Haba Sent: Thursday, March 12, 2009 12:24 PM To: MPI 2.2 Subject: [Mpi-22] Ticket #46: Add const Keyword to the C bindings - implementation Implementation for ticket #46 is now available from ANL (thanks Pavan) tarballs http://www.mcs.anl.gov/research/projects/mpich2/downloads/tarballs/nightly/const thanks, .Erez * -------------- next part -------------- An HTML attachment was scrubbed... URL: From erezh at [hidden] Thu Mar 12 13:43:35 2009 From: erezh at [hidden] (Erez Haba) Date: Thu, 12 Mar 2009 11:43:35 -0700 Subject: [Mpi-22] Ticket #46: Add const Keyword to the C bindings- implementation In-Reply-To: Message-ID: <6B68D01C00C9994A8E150183E62A119E7B732393DF@NA-EXMSG-C105.redmond.corp.microsoft.com> No, it's not being cast away (although it is a quick way for you to implement it). In MPICH2 implementation it trickles down to the lower functions. There are very few places where the const is being cast away because ticket #46 does not to break backward compatibility. For example, when the user function is called (const was not added to the MPI_User_function) the implementation must cast away const from the send buffer before calling the user function. Thanks, .Erez -----Original Message----- From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Jeff Squyres Sent: Thursday, March 12, 2009 11:34 AM To: MPI 2.2 Subject: Re: [Mpi-22] Ticket #46: Add const Keyword to the C bindings- implementation More importantly, how is const handled? Is it just cast away inside the MPI library? On Mar 12, 2009, at 2:34 PM, Underwood, Keith D wrote: > Since the main purpose of an implementation for something like > adding const is to see how invasive the change is, would it be > possible to get a diff against the trees that these were created from? > > Thanks, > Keith > > From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden] > ] On Behalf Of Erez Haba > Sent: Thursday, March 12, 2009 12:24 PM > To: MPI 2.2 > Subject: [Mpi-22] Ticket #46: Add const Keyword to the C bindings - > implementation > > > Implementation for ticket #46 is now available from ANL (thanks Pavan) > > > tarballs > http://www.mcs.anl.gov/research/projects/mpich2/downloads/tarballs/nightly/const > > > thanks, > .Erez > > _______________________________________________ > mpi-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 -- Jeff Squyres Cisco Systems _______________________________________________ mpi-22 mailing list mpi-22_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 From keith.d.underwood at [hidden] Thu Mar 12 14:04:37 2009 From: keith.d.underwood at [hidden] (Underwood, Keith D) Date: Thu, 12 Mar 2009 13:04:37 -0600 Subject: [Mpi-22] Ticket #46: Add const Keyword to the C bindings- implementation In-Reply-To: <6B68D01C00C9994A8E150183E62A119E7B732393DF@NA-EXMSG-C105.redmond.corp.microsoft.com> Message-ID: <8E9963DB482E4B49AB9EF1C296936CF718E23F4B@rrsmsx507.amr.corp.intel.com> It would seem like const would eventually have to be cast away for most lower level interfaces. Portals, Elan, IB Verbs, and as best I can tell MX don't have const on their send buffers... Keith >-----Original Message----- >From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_lists.mpi- >forum.org] On Behalf Of Erez Haba >Sent: Thursday, March 12, 2009 12:44 PM >To: MPI 2.2 >Subject: Re: [Mpi-22] Ticket #46: Add const Keyword to the C bindings- >implementation > >No, it's not being cast away (although it is a quick way for you to >implement it). >In MPICH2 implementation it trickles down to the lower functions. There are >very few places where the const is being cast away because ticket #46 does >not to break backward compatibility. >For example, when the user function is called (const was not added to the >MPI_User_function) the implementation must cast away const from the send >buffer before calling the user function. > >Thanks, >.Erez > >-----Original Message----- >From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_lists.mpi- >forum.org] On Behalf Of Jeff Squyres >Sent: Thursday, March 12, 2009 11:34 AM >To: MPI 2.2 >Subject: Re: [Mpi-22] Ticket #46: Add const Keyword to the C bindings- >implementation > >More importantly, how is const handled? Is it just cast away inside >the MPI library? > > >On Mar 12, 2009, at 2:34 PM, Underwood, Keith D wrote: > >> Since the main purpose of an implementation for something like >> adding const is to see how invasive the change is, would it be >> possible to get a diff against the trees that these were created from? >> >> Thanks, >> Keith >> >> From: mpi-22-bounces_at_[hidden] [mailto:mpi-22- >bounces_at_[hidden] >> ] On Behalf Of Erez Haba >> Sent: Thursday, March 12, 2009 12:24 PM >> To: MPI 2.2 >> Subject: [Mpi-22] Ticket #46: Add const Keyword to the C bindings - >> implementation >> >> >> Implementation for ticket #46 is now available from ANL (thanks Pavan) >> >> >> tarballs >> >http://www.mcs.anl.gov/research/projects/mpich2/downloads/tarballs/nightly/ >const >> >> >> thanks, >> .Erez >> >> _______________________________________________ >> mpi-22 mailing list >> mpi-22_at_[hidden] >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 > > >-- >Jeff Squyres >Cisco Systems > >_______________________________________________ >mpi-22 mailing list >mpi-22_at_[hidden] >http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 > > >_______________________________________________ >mpi-22 mailing list >mpi-22_at_[hidden] >http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 From balaji at [hidden] Thu Mar 12 14:39:58 2009 From: balaji at [hidden] (Pavan Balaji) Date: Thu, 12 Mar 2009 14:39:58 -0500 Subject: [Mpi-22] Ticket #46: Add const Keyword to the C bindings - implementation In-Reply-To: <6B68D01C00C9994A8E150183E62A119E7B732393CE@NA-EXMSG-C105.redmond.corp.microsoft.com> Message-ID: <49B9650E.2060102@mcs.anl.gov> > I’m not sure if ANL has a diff/patch on top of the trunk. Pavan? Rajeev? Uploaded the diff to the ticket. -- Pavan -- Pavan Balaji http://www.mcs.anl.gov/~balaji From erezh at [hidden] Thu Mar 12 15:09:59 2009 From: erezh at [hidden] (Erez Haba) Date: Thu, 12 Mar 2009 13:09:59 -0700 Subject: [Mpi-22] Ticket #46: Add const Keyword to the C bindings- implementation In-Reply-To: <8E9963DB482E4B49AB9EF1C296936CF718E23F4B@rrsmsx507.amr.corp.intel.com> Message-ID: <6B68D01C00C9994A8E150183E62A119E7B7323949A@NA-EXMSG-C105.redmond.corp.microsoft.com> Possibly you'll have to cast. There are few interfaces that take const for send buffer (like sockets). In other cases you copy the buffer (like with IB) which keeps the const property. Thanks, .Erez -----Original Message----- From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Underwood, Keith D Sent: Thursday, March 12, 2009 12:05 PM To: MPI 2.2 Subject: Re: [Mpi-22] Ticket #46: Add const Keyword to the C bindings- implementation It would seem like const would eventually have to be cast away for most lower level interfaces. Portals, Elan, IB Verbs, and as best I can tell MX don't have const on their send buffers... Keith >-----Original Message----- >From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_lists.mpi- >forum.org] On Behalf Of Erez Haba >Sent: Thursday, March 12, 2009 12:44 PM >To: MPI 2.2 >Subject: Re: [Mpi-22] Ticket #46: Add const Keyword to the C bindings- >implementation > >No, it's not being cast away (although it is a quick way for you to >implement it). >In MPICH2 implementation it trickles down to the lower functions. There are >very few places where the const is being cast away because ticket #46 does >not to break backward compatibility. >For example, when the user function is called (const was not added to the >MPI_User_function) the implementation must cast away const from the send >buffer before calling the user function. > >Thanks, >.Erez > >-----Original Message----- >From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_lists.mpi- >forum.org] On Behalf Of Jeff Squyres >Sent: Thursday, March 12, 2009 11:34 AM >To: MPI 2.2 >Subject: Re: [Mpi-22] Ticket #46: Add const Keyword to the C bindings- >implementation > >More importantly, how is const handled? Is it just cast away inside >the MPI library? > > >On Mar 12, 2009, at 2:34 PM, Underwood, Keith D wrote: > >> Since the main purpose of an implementation for something like >> adding const is to see how invasive the change is, would it be >> possible to get a diff against the trees that these were created from? >> >> Thanks, >> Keith >> >> From: mpi-22-bounces_at_[hidden] [mailto:mpi-22- >bounces_at_[hidden] >> ] On Behalf Of Erez Haba >> Sent: Thursday, March 12, 2009 12:24 PM >> To: MPI 2.2 >> Subject: [Mpi-22] Ticket #46: Add const Keyword to the C bindings - >> implementation >> >> >> Implementation for ticket #46 is now available from ANL (thanks Pavan) >> >> >> tarballs >> >http://www.mcs.anl.gov/research/projects/mpich2/downloads/tarballs/nightly/ >const >> >> >> thanks, >> .Erez >> >> _______________________________________________ >> mpi-22 mailing list >> mpi-22_at_[hidden] >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 > > >-- >Jeff Squyres >Cisco Systems > >_______________________________________________ >mpi-22 mailing list >mpi-22_at_[hidden] >http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 > > >_______________________________________________ >mpi-22 mailing list >mpi-22_at_[hidden] >http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 _______________________________________________ mpi-22 mailing list mpi-22_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 From keith.d.underwood at [hidden] Thu Mar 12 16:03:15 2009 From: keith.d.underwood at [hidden] (Underwood, Keith D) Date: Thu, 12 Mar 2009 15:03:15 -0600 Subject: [Mpi-22] Ticket #46: Add const Keyword to the C bindings- implementation In-Reply-To: <6B68D01C00C9994A8E150183E62A119E7B7323949A@NA-EXMSG-C105.redmond.corp.microsoft.com> Message-ID: <8E9963DB482E4B49AB9EF1C296936CF718E24088@rrsmsx507.amr.corp.intel.com> I didn't think that typical MPI implementations over IB copied the data for large messages (as opposed to the bounce buffers for small messages). If you are going to have to cast away the const, what is the point of putting it in? In fact, if you have to cast away the const, aren't you violating your contract with the compiler? Should this change be rolled out from the bottom up? i.e. common low-level APIs first and then MPI? Keith >-----Original Message----- >From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_lists.mpi- >forum.org] On Behalf Of Erez Haba >Sent: Thursday, March 12, 2009 2:10 PM >To: MPI 2.2 >Subject: Re: [Mpi-22] Ticket #46: Add const Keyword to the C bindings- >implementation > >Possibly you'll have to cast. >There are few interfaces that take const for send buffer (like sockets). >In other cases you copy the buffer (like with IB) which keeps the const >property. > >Thanks, >.Erez > >-----Original Message----- >From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_lists.mpi- >forum.org] On Behalf Of Underwood, Keith D >Sent: Thursday, March 12, 2009 12:05 PM >To: MPI 2.2 >Subject: Re: [Mpi-22] Ticket #46: Add const Keyword to the C bindings- >implementation > >It would seem like const would eventually have to be cast away for most >lower level interfaces. Portals, Elan, IB Verbs, and as best I can tell MX >don't have const on their send buffers... > >Keith > >>-----Original Message----- >>From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_lists.mpi- >>forum.org] On Behalf Of Erez Haba >>Sent: Thursday, March 12, 2009 12:44 PM >>To: MPI 2.2 >>Subject: Re: [Mpi-22] Ticket #46: Add const Keyword to the C bindings- >>implementation >> >>No, it's not being cast away (although it is a quick way for you to >>implement it). >>In MPICH2 implementation it trickles down to the lower functions. There >are >>very few places where the const is being cast away because ticket #46 does >>not to break backward compatibility. >>For example, when the user function is called (const was not added to the >>MPI_User_function) the implementation must cast away const from the send >>buffer before calling the user function. >> >>Thanks, >>.Erez >> >>-----Original Message----- >>From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_lists.mpi- >>forum.org] On Behalf Of Jeff Squyres >>Sent: Thursday, March 12, 2009 11:34 AM >>To: MPI 2.2 >>Subject: Re: [Mpi-22] Ticket #46: Add const Keyword to the C bindings- >>implementation >> >>More importantly, how is const handled? Is it just cast away inside >>the MPI library? >> >> >>On Mar 12, 2009, at 2:34 PM, Underwood, Keith D wrote: >> >>> Since the main purpose of an implementation for something like >>> adding const is to see how invasive the change is, would it be >>> possible to get a diff against the trees that these were created from? >>> >>> Thanks, >>> Keith >>> >>> From: mpi-22-bounces_at_[hidden] [mailto:mpi-22- >>bounces_at_[hidden] >>> ] On Behalf Of Erez Haba >>> Sent: Thursday, March 12, 2009 12:24 PM >>> To: MPI 2.2 >>> Subject: [Mpi-22] Ticket #46: Add const Keyword to the C bindings - >>> implementation >>> >>> >>> Implementation for ticket #46 is now available from ANL (thanks Pavan) >>> >>> >>> tarballs >>> >>http://www.mcs.anl.gov/research/projects/mpich2/downloads/tarballs/nightly >/ >>const >>> >>> >>> thanks, >>> .Erez >>> >>> _______________________________________________ >>> mpi-22 mailing list >>> mpi-22_at_[hidden] >>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 >> >> >>-- >>Jeff Squyres >>Cisco Systems >> >>_______________________________________________ >>mpi-22 mailing list >>mpi-22_at_[hidden] >>http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 >> >> >>_______________________________________________ >>mpi-22 mailing list >>mpi-22_at_[hidden] >>http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 > >_______________________________________________ >mpi-22 mailing list >mpi-22_at_[hidden] >http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 > > >_______________________________________________ >mpi-22 mailing list >mpi-22_at_[hidden] >http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 From erezh at [hidden] Thu Mar 12 17:06:53 2009 From: erezh at [hidden] (Erez Haba) Date: Thu, 12 Mar 2009 15:06:53 -0700 Subject: [Mpi-22] Ticket #46: Add const Keyword to the C bindings- implementation In-Reply-To: <8E9963DB482E4B49AB9EF1C296936CF718E24088@rrsmsx507.amr.corp.intel.com> Message-ID: <6B68D01C00C9994A8E150183E62A119E7B732395B2@NA-EXMSG-C105.redmond.corp.microsoft.com> I urge you, please read the ticket proposal again. It discusses the merit of this proposal. As for IB; yes you'd copy small messages (which const is fine with) and some implement RDMA read or write for large messages; you might need to cast the const away if your IB interface does not expose const SGE's. As for the compiler; no you are not violating the contact; (otherwise we wouldn't have casts); as long as you guarantee that you are not changing the buffer. It's a way for the programmer to use old, non const correct, interfaces. .Erez -----Original Message----- From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Underwood, Keith D Sent: Thursday, March 12, 2009 2:03 PM To: MPI 2.2 Subject: Re: [Mpi-22] Ticket #46: Add const Keyword to the C bindings- implementation I didn't think that typical MPI implementations over IB copied the data for large messages (as opposed to the bounce buffers for small messages). If you are going to have to cast away the const, what is the point of putting it in? In fact, if you have to cast away the const, aren't you violating your contract with the compiler? Should this change be rolled out from the bottom up? i.e. common low-level APIs first and then MPI? Keith >-----Original Message----- >From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_lists.mpi- >forum.org] On Behalf Of Erez Haba >Sent: Thursday, March 12, 2009 2:10 PM >To: MPI 2.2 >Subject: Re: [Mpi-22] Ticket #46: Add const Keyword to the C bindings- >implementation > >Possibly you'll have to cast. >There are few interfaces that take const for send buffer (like sockets). >In other cases you copy the buffer (like with IB) which keeps the const >property. > >Thanks, >.Erez > >-----Original Message----- >From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_lists.mpi- >forum.org] On Behalf Of Underwood, Keith D >Sent: Thursday, March 12, 2009 12:05 PM >To: MPI 2.2 >Subject: Re: [Mpi-22] Ticket #46: Add const Keyword to the C bindings- >implementation > >It would seem like const would eventually have to be cast away for most >lower level interfaces. Portals, Elan, IB Verbs, and as best I can tell MX >don't have const on their send buffers... > >Keith > >>-----Original Message----- >>From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_lists.mpi- >>forum.org] On Behalf Of Erez Haba >>Sent: Thursday, March 12, 2009 12:44 PM >>To: MPI 2.2 >>Subject: Re: [Mpi-22] Ticket #46: Add const Keyword to the C bindings- >>implementation >> >>No, it's not being cast away (although it is a quick way for you to >>implement it). >>In MPICH2 implementation it trickles down to the lower functions. There >are >>very few places where the const is being cast away because ticket #46 does >>not to break backward compatibility. >>For example, when the user function is called (const was not added to the >>MPI_User_function) the implementation must cast away const from the send >>buffer before calling the user function. >> >>Thanks, >>.Erez >> >>-----Original Message----- >>From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_lists.mpi- >>forum.org] On Behalf Of Jeff Squyres >>Sent: Thursday, March 12, 2009 11:34 AM >>To: MPI 2.2 >>Subject: Re: [Mpi-22] Ticket #46: Add const Keyword to the C bindings- >>implementation >> >>More importantly, how is const handled? Is it just cast away inside >>the MPI library? >> >> >>On Mar 12, 2009, at 2:34 PM, Underwood, Keith D wrote: >> >>> Since the main purpose of an implementation for something like >>> adding const is to see how invasive the change is, would it be >>> possible to get a diff against the trees that these were created from? >>> >>> Thanks, >>> Keith >>> >>> From: mpi-22-bounces_at_[hidden] [mailto:mpi-22- >>bounces_at_[hidden] >>> ] On Behalf Of Erez Haba >>> Sent: Thursday, March 12, 2009 12:24 PM >>> To: MPI 2.2 >>> Subject: [Mpi-22] Ticket #46: Add const Keyword to the C bindings - >>> implementation >>> >>> >>> Implementation for ticket #46 is now available from ANL (thanks Pavan) >>> >>> >>> tarballs >>> >>http://www.mcs.anl.gov/research/projects/mpich2/downloads/tarballs/nightly >/ >>const >>> >>> >>> thanks, >>> .Erez >>> >>> _______________________________________________ >>> mpi-22 mailing list >>> mpi-22_at_[hidden] >>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 >> >> >>-- >>Jeff Squyres >>Cisco Systems >> >>_______________________________________________ >>mpi-22 mailing list >>mpi-22_at_[hidden] >>http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 >> >> >>_______________________________________________ >>mpi-22 mailing list >>mpi-22_at_[hidden] >>http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 > >_______________________________________________ >mpi-22 mailing list >mpi-22_at_[hidden] >http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 > > >_______________________________________________ >mpi-22 mailing list >mpi-22_at_[hidden] >http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 _______________________________________________ mpi-22 mailing list mpi-22_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 From jsquyres at [hidden] Fri Mar 13 08:04:39 2009 From: jsquyres at [hidden] (Jeff Squyres) Date: Fri, 13 Mar 2009 09:04:39 -0400 Subject: [Mpi-22] Ticket #46: Addconst Keyword to the C bindings- implementation In-Reply-To: <6B68D01C00C9994A8E150183E62A119E7B732395B2@NA-EXMSG-C105.redmond.corp.microsoft.com> Message-ID: Do you end up casting away the const when invoking the Windows network interfaces? On Linux, I think the following interfaces would require casting the const away: - shared memory (even using Linux vmsplice()) - MX - TCP - OpenFabrics (both verbs and udapl) These interfaces do not require casting away const: - SCTP (I *think* -- I'm not an SCTP expert, but a quick look in sctp.h showed a "const" argument for the sctp_sendmsg() function) I can't check these offhand: - Portals - Elan On Mar 12, 2009, at 6:06 PM, Erez Haba wrote: > I urge you, please read the ticket proposal again. It discusses the > merit of this proposal. > > As for IB; yes you'd copy small messages (which const is fine with) > and some implement RDMA read or write for large messages; you might > need to cast the const away if your IB interface does not expose > const SGE's. > > As for the compiler; no you are not violating the contact; > (otherwise we wouldn't have casts); as long as you guarantee that > you are not changing the buffer. It's a way for the programmer to > use old, non const correct, interfaces. > > .Erez > > -----Original Message----- > From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden] > ] On Behalf Of Underwood, Keith D > Sent: Thursday, March 12, 2009 2:03 PM > To: MPI 2.2 > Subject: Re: [Mpi-22] Ticket #46: Add const Keyword to the C > bindings- implementation > > I didn't think that typical MPI implementations over IB copied the > data for large messages (as opposed to the bounce buffers for small > messages). > > If you are going to have to cast away the const, what is the point > of putting it in? In fact, if you have to cast away the const, > aren't you violating your contract with the compiler? Should this > change be rolled out from the bottom up? i.e. common low-level APIs > first and then MPI? > > Keith > > >-----Original Message----- > >From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_lists.mpi- > >forum.org] On Behalf Of Erez Haba > >Sent: Thursday, March 12, 2009 2:10 PM > >To: MPI 2.2 > >Subject: Re: [Mpi-22] Ticket #46: Add const Keyword to the C > bindings- > >implementation > > > >Possibly you'll have to cast. > >There are few interfaces that take const for send buffer (like > sockets). > >In other cases you copy the buffer (like with IB) which keeps the > const > >property. > > > >Thanks, > >.Erez > > > >-----Original Message----- > >From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_lists.mpi- > >forum.org] On Behalf Of Underwood, Keith D > >Sent: Thursday, March 12, 2009 12:05 PM > >To: MPI 2.2 > >Subject: Re: [Mpi-22] Ticket #46: Add const Keyword to the C > bindings- > >implementation > > > >It would seem like const would eventually have to be cast away for > most > >lower level interfaces. Portals, Elan, IB Verbs, and as best I can > tell MX > >don't have const on their send buffers... > > > >Keith > > > >>-----Original Message----- > >>From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_lists.mpi- > >>forum.org] On Behalf Of Erez Haba > >>Sent: Thursday, March 12, 2009 12:44 PM > >>To: MPI 2.2 > >>Subject: Re: [Mpi-22] Ticket #46: Add const Keyword to the C > bindings- > >>implementation > >> > >>No, it's not being cast away (although it is a quick way for you to > >>implement it). > >>In MPICH2 implementation it trickles down to the lower functions. > There > >are > >>very few places where the const is being cast away because ticket > #46 does > >>not to break backward compatibility. > >>For example, when the user function is called (const was not added > to the > >>MPI_User_function) the implementation must cast away const from > the send > >>buffer before calling the user function. > >> > >>Thanks, > >>.Erez > >> > >>-----Original Message----- > >>From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_lists.mpi- > >>forum.org] On Behalf Of Jeff Squyres > >>Sent: Thursday, March 12, 2009 11:34 AM > >>To: MPI 2.2 > >>Subject: Re: [Mpi-22] Ticket #46: Add const Keyword to the C > bindings- > >>implementation > >> > >>More importantly, how is const handled? Is it just cast away inside > >>the MPI library? > >> > >> > >>On Mar 12, 2009, at 2:34 PM, Underwood, Keith D wrote: > >> > >>> Since the main purpose of an implementation for something like > >>> adding const is to see how invasive the change is, would it be > >>> possible to get a diff against the trees that these were created > from? > >>> > >>> Thanks, > >>> Keith > >>> > >>> From: mpi-22-bounces_at_[hidden] [mailto:mpi-22- > >>bounces_at_[hidden] > >>> ] On Behalf Of Erez Haba > >>> Sent: Thursday, March 12, 2009 12:24 PM > >>> To: MPI 2.2 > >>> Subject: [Mpi-22] Ticket #46: Add const Keyword to the C > bindings - > >>> implementation > >>> > >>> > >>> Implementation for ticket #46 is now available from ANL (thanks > Pavan) > >>> > >>> > >>> tarballs > >>> > >>http://www.mcs.anl.gov/research/projects/mpich2/downloads/tarballs/nightly > >/ > >>const > >>> > >>> > >>> thanks, > >>> .Erez > >>> > >>> _______________________________________________ > >>> mpi-22 mailing list > >>> mpi-22_at_[hidden] > >>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 > >> > >> > >>-- > >>Jeff Squyres > >>Cisco Systems > >> > >>_______________________________________________ > >>mpi-22 mailing list > >>mpi-22_at_[hidden] > >>http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 > >> > >> > >>_______________________________________________ > >>mpi-22 mailing list > >>mpi-22_at_[hidden] > >>http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 > > > >_______________________________________________ > >mpi-22 mailing list > >mpi-22_at_[hidden] > >http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 > > > > > >_______________________________________________ > >mpi-22 mailing list > >mpi-22_at_[hidden] > >http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 > > _______________________________________________ > mpi-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 > > > _______________________________________________ > mpi-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 -- Jeff Squyres Cisco Systems From wgropp at [hidden] Fri Mar 13 08:40:24 2009 From: wgropp at [hidden] (William Gropp) Date: Fri, 13 Mar 2009 08:40:24 -0500 Subject: [Mpi-22] Ticket #46: Add const Keyword to the C bindings- implementation In-Reply-To: <8E9963DB482E4B49AB9EF1C296936CF718E23F4B@rrsmsx507.amr.corp.intel.com> Message-ID: <51A888AB-AEA8-48C7-B1F5-146ADE9F35D5@illinois.edu> Two comments: First, this is a chicken-and-egg problem; the low level interfaces are unlikely to change to add const unless there is some application that will take advantage of that (and internally, if their semantics allows it and their compiler can support it, they'll just cast to add the const). So MPI should take the lead, particularly since using const also provides information to the user. Second, MPI also runs on systems with tighter integration with the interconnect; not all implementations are on top of other middleware layers, so the failure of those layers to make use of const (and restrict) isn't a good argument for MPI to wait on them. Finally, MPICH2 has used const (and even restrict!) internally in places where a sophisticated compiler can take advantage of it. So its not just syntactic sugar. Bill On Mar 12, 2009, at 2:04 PM, Underwood, Keith D wrote: > It would seem like const would eventually have to be cast away for > most lower level interfaces. Portals, Elan, IB Verbs, and as best I > can tell MX don't have const on their send buffers... > > Keith William Gropp Deputy Director for Research Institute for Advanced Computing Applications and Technologies Paul and Cynthia Saylor Professor of Computer Science University of Illinois Urbana-Champaign From erezh at [hidden] Fri Mar 13 11:40:22 2009 From: erezh at [hidden] (Erez Haba) Date: Fri, 13 Mar 2009 09:40:22 -0700 Subject: [Mpi-22] Ticket #46: Addconst Keyword to the C bindings- implementation In-Reply-To: Message-ID: <6B68D01C00C9994A8E150183E62A119E7B732398EA@NA-EXMSG-C105.redmond.corp.microsoft.com> Hi Jeff, The point of this ticket is to present a consistent const correct interface to the programmer and hide all the idiosyncrasies of the down-level interfaces. That said, to answer your questions: No casting is required for: * shared memory * sockets (TCP) when using 'send()' (single buffer passed in) Casting is required for interfaces that did not define their io vector buffer member as const. (an interface would need to define two io vector structures, one with const buffer for send and one with non-const for receive; most of them don't). Thus, casting is required when using the scatter/gather io vector with * sockets (TC) * Network Direct (IB and iWarp) With MPICH2 implementation, casting out the const for the send buffer when using these interfaces was there all along as (most of) MPICH2 internal functions already used const to pass the send buffer. No new cast was required in this full const implementation. Again, casting away the const to use the lower level interface does not violate any const rules as long as the semantic is preserved. Thanks, .Erez -----Original Message----- From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Jeff Squyres Sent: Friday, March 13, 2009 6:05 AM To: MPI 2.2 Subject: Re: [Mpi-22] Ticket #46: Addconst Keyword to the C bindings- implementation Do you end up casting away the const when invoking the Windows network interfaces? On Linux, I think the following interfaces would require casting the const away: - shared memory (even using Linux vmsplice()) - MX - TCP - OpenFabrics (both verbs and udapl) These interfaces do not require casting away const: - SCTP (I *think* -- I'm not an SCTP expert, but a quick look in sctp.h showed a "const" argument for the sctp_sendmsg() function) I can't check these offhand: - Portals - Elan On Mar 12, 2009, at 6:06 PM, Erez Haba wrote: > I urge you, please read the ticket proposal again. It discusses the > merit of this proposal. > > As for IB; yes you'd copy small messages (which const is fine with) > and some implement RDMA read or write for large messages; you might > need to cast the const away if your IB interface does not expose > const SGE's. > > As for the compiler; no you are not violating the contact; > (otherwise we wouldn't have casts); as long as you guarantee that > you are not changing the buffer. It's a way for the programmer to > use old, non const correct, interfaces. > > .Erez > > -----Original Message----- > From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden] > ] On Behalf Of Underwood, Keith D > Sent: Thursday, March 12, 2009 2:03 PM > To: MPI 2.2 > Subject: Re: [Mpi-22] Ticket #46: Add const Keyword to the C > bindings- implementation > > I didn't think that typical MPI implementations over IB copied the > data for large messages (as opposed to the bounce buffers for small > messages). > > If you are going to have to cast away the const, what is the point > of putting it in? In fact, if you have to cast away the const, > aren't you violating your contract with the compiler? Should this > change be rolled out from the bottom up? i.e. common low-level APIs > first and then MPI? > > Keith > > >-----Original Message----- > >From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_lists.mpi- > >forum.org] On Behalf Of Erez Haba > >Sent: Thursday, March 12, 2009 2:10 PM > >To: MPI 2.2 > >Subject: Re: [Mpi-22] Ticket #46: Add const Keyword to the C > bindings- > >implementation > > > >Possibly you'll have to cast. > >There are few interfaces that take const for send buffer (like > sockets). > >In other cases you copy the buffer (like with IB) which keeps the > const > >property. > > > >Thanks, > >.Erez > > > >-----Original Message----- > >From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_lists.mpi- > >forum.org] On Behalf Of Underwood, Keith D > >Sent: Thursday, March 12, 2009 12:05 PM > >To: MPI 2.2 > >Subject: Re: [Mpi-22] Ticket #46: Add const Keyword to the C > bindings- > >implementation > > > >It would seem like const would eventually have to be cast away for > most > >lower level interfaces. Portals, Elan, IB Verbs, and as best I can > tell MX > >don't have const on their send buffers... > > > >Keith > > > >>-----Original Message----- > >>From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_lists.mpi- > >>forum.org] On Behalf Of Erez Haba > >>Sent: Thursday, March 12, 2009 12:44 PM > >>To: MPI 2.2 > >>Subject: Re: [Mpi-22] Ticket #46: Add const Keyword to the C > bindings- > >>implementation > >> > >>No, it's not being cast away (although it is a quick way for you to > >>implement it). > >>In MPICH2 implementation it trickles down to the lower functions. > There > >are > >>very few places where the const is being cast away because ticket > #46 does > >>not to break backward compatibility. > >>For example, when the user function is called (const was not added > to the > >>MPI_User_function) the implementation must cast away const from > the send > >>buffer before calling the user function. > >> > >>Thanks, > >>.Erez > >> > >>-----Original Message----- > >>From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_lists.mpi- > >>forum.org] On Behalf Of Jeff Squyres > >>Sent: Thursday, March 12, 2009 11:34 AM > >>To: MPI 2.2 > >>Subject: Re: [Mpi-22] Ticket #46: Add const Keyword to the C > bindings- > >>implementation > >> > >>More importantly, how is const handled? Is it just cast away inside > >>the MPI library? > >> > >> > >>On Mar 12, 2009, at 2:34 PM, Underwood, Keith D wrote: > >> > >>> Since the main purpose of an implementation for something like > >>> adding const is to see how invasive the change is, would it be > >>> possible to get a diff against the trees that these were created > from? > >>> > >>> Thanks, > >>> Keith > >>> > >>> From: mpi-22-bounces_at_[hidden] [mailto:mpi-22- > >>bounces_at_[hidden] > >>> ] On Behalf Of Erez Haba > >>> Sent: Thursday, March 12, 2009 12:24 PM > >>> To: MPI 2.2 > >>> Subject: [Mpi-22] Ticket #46: Add const Keyword to the C > bindings - > >>> implementation > >>> > >>> > >>> Implementation for ticket #46 is now available from ANL (thanks > Pavan) > >>> > >>> > >>> tarballs > >>> > >>http://www.mcs.anl.gov/research/projects/mpich2/downloads/tarballs/nightly > >/ > >>const > >>> > >>> > >>> thanks, > >>> .Erez > >>> > >>> _______________________________________________ > >>> mpi-22 mailing list > >>> mpi-22_at_[hidden] > >>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 > >> > >> > >>-- > >>Jeff Squyres > >>Cisco Systems > >> > >>_______________________________________________ > >>mpi-22 mailing list > >>mpi-22_at_[hidden] > >>http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 > >> > >> > >>_______________________________________________ > >>mpi-22 mailing list > >>mpi-22_at_[hidden] > >>http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 > > > >_______________________________________________ > >mpi-22 mailing list > >mpi-22_at_[hidden] > >http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 > > > > > >_______________________________________________ > >mpi-22 mailing list > >mpi-22_at_[hidden] > >http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 > > _______________________________________________ > mpi-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 > > > _______________________________________________ > mpi-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 -- Jeff Squyres Cisco Systems _______________________________________________ mpi-22 mailing list mpi-22_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 From keith.d.underwood at [hidden] Fri Mar 13 11:46:34 2009 From: keith.d.underwood at [hidden] (Underwood, Keith D) Date: Fri, 13 Mar 2009 10:46:34 -0600 Subject: [Mpi-22] Ticket #46: Addconst Keyword to the C bindings- implementation In-Reply-To: Message-ID: <8E9963DB482E4B49AB9EF1C296936CF718E243BC@rrsmsx507.amr.corp.intel.com> Yes, you have to cast it away for Portals and Elan (http://web1.quadrics.com/downloads/documentation/ElanProgMan_5.3.pdf) Keith >-----Original Message----- >From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_lists.mpi- >forum.org] On Behalf Of Jeff Squyres >Sent: Friday, March 13, 2009 7:05 AM >To: MPI 2.2 >Subject: Re: [Mpi-22] Ticket #46: Addconst Keyword to the C bindings- >implementation > >Do you end up casting away the const when invoking the Windows network >interfaces? > >On Linux, I think the following interfaces would require casting the >const away: > >- shared memory (even using Linux vmsplice()) >- MX >- TCP >- OpenFabrics (both verbs and udapl) > >These interfaces do not require casting away const: > >- SCTP (I *think* -- I'm not an SCTP expert, but a quick look in >sctp.h showed a "const" argument for the sctp_sendmsg() function) > >I can't check these offhand: > >- Portals >- Elan > > > >On Mar 12, 2009, at 6:06 PM, Erez Haba wrote: > >> I urge you, please read the ticket proposal again. It discusses the >> merit of this proposal. >> >> As for IB; yes you'd copy small messages (which const is fine with) >> and some implement RDMA read or write for large messages; you might >> need to cast the const away if your IB interface does not expose >> const SGE's. >> >> As for the compiler; no you are not violating the contact; >> (otherwise we wouldn't have casts); as long as you guarantee that >> you are not changing the buffer. It's a way for the programmer to >> use old, non const correct, interfaces. >> >> .Erez >> >> -----Original Message----- >> From: mpi-22-bounces_at_[hidden] [mailto:mpi-22- >bounces_at_[hidden] >> ] On Behalf Of Underwood, Keith D >> Sent: Thursday, March 12, 2009 2:03 PM >> To: MPI 2.2 >> Subject: Re: [Mpi-22] Ticket #46: Add const Keyword to the C >> bindings- implementation >> >> I didn't think that typical MPI implementations over IB copied the >> data for large messages (as opposed to the bounce buffers for small >> messages). >> >> If you are going to have to cast away the const, what is the point >> of putting it in? In fact, if you have to cast away the const, >> aren't you violating your contract with the compiler? Should this >> change be rolled out from the bottom up? i.e. common low-level APIs >> first and then MPI? >> >> Keith >> >> >-----Original Message----- >> >From: mpi-22-bounces_at_[hidden] [mailto:mpi-22- >bounces_at_lists.mpi- >> >forum.org] On Behalf Of Erez Haba >> >Sent: Thursday, March 12, 2009 2:10 PM >> >To: MPI 2.2 >> >Subject: Re: [Mpi-22] Ticket #46: Add const Keyword to the C >> bindings- >> >implementation >> > >> >Possibly you'll have to cast. >> >There are few interfaces that take const for send buffer (like >> sockets). >> >In other cases you copy the buffer (like with IB) which keeps the >> const >> >property. >> > >> >Thanks, >> >.Erez >> > >> >-----Original Message----- >> >From: mpi-22-bounces_at_[hidden] [mailto:mpi-22- >bounces_at_lists.mpi- >> >forum.org] On Behalf Of Underwood, Keith D >> >Sent: Thursday, March 12, 2009 12:05 PM >> >To: MPI 2.2 >> >Subject: Re: [Mpi-22] Ticket #46: Add const Keyword to the C >> bindings- >> >implementation >> > >> >It would seem like const would eventually have to be cast away for >> most >> >lower level interfaces. Portals, Elan, IB Verbs, and as best I can >> tell MX >> >don't have const on their send buffers... >> > >> >Keith >> > >> >>-----Original Message----- >> >>From: mpi-22-bounces_at_[hidden] [mailto:mpi-22- >bounces_at_lists.mpi- >> >>forum.org] On Behalf Of Erez Haba >> >>Sent: Thursday, March 12, 2009 12:44 PM >> >>To: MPI 2.2 >> >>Subject: Re: [Mpi-22] Ticket #46: Add const Keyword to the C >> bindings- >> >>implementation >> >> >> >>No, it's not being cast away (although it is a quick way for you to >> >>implement it). >> >>In MPICH2 implementation it trickles down to the lower functions. >> There >> >are >> >>very few places where the const is being cast away because ticket >> #46 does >> >>not to break backward compatibility. >> >>For example, when the user function is called (const was not added >> to the >> >>MPI_User_function) the implementation must cast away const from >> the send >> >>buffer before calling the user function. >> >> >> >>Thanks, >> >>.Erez >> >> >> >>-----Original Message----- >> >>From: mpi-22-bounces_at_[hidden] [mailto:mpi-22- >bounces_at_lists.mpi- >> >>forum.org] On Behalf Of Jeff Squyres >> >>Sent: Thursday, March 12, 2009 11:34 AM >> >>To: MPI 2.2 >> >>Subject: Re: [Mpi-22] Ticket #46: Add const Keyword to the C >> bindings- >> >>implementation >> >> >> >>More importantly, how is const handled? Is it just cast away inside >> >>the MPI library? >> >> >> >> >> >>On Mar 12, 2009, at 2:34 PM, Underwood, Keith D wrote: >> >> >> >>> Since the main purpose of an implementation for something like >> >>> adding const is to see how invasive the change is, would it be >> >>> possible to get a diff against the trees that these were created >> from? >> >>> >> >>> Thanks, >> >>> Keith >> >>> >> >>> From: mpi-22-bounces_at_[hidden] [mailto:mpi-22- >> >>bounces_at_[hidden] >> >>> ] On Behalf Of Erez Haba >> >>> Sent: Thursday, March 12, 2009 12:24 PM >> >>> To: MPI 2.2 >> >>> Subject: [Mpi-22] Ticket #46: Add const Keyword to the C >> bindings - >> >>> implementation >> >>> >> >>> >> >>> Implementation for ticket #46 is now available from ANL (thanks >> Pavan) >> >>> >> >>> >> >>> tarballs >> >>> >> >>>http://www.mcs.anl.gov/research/projects/mpich2/downloads/tarballs/nightl >y >> >/ >> >>const >> >>> >> >>> >> >>> thanks, >> >>> .Erez >> >>> >> >>> _______________________________________________ >> >>> mpi-22 mailing list >> >>> mpi-22_at_[hidden] >> >>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 >> >> >> >> >> >>-- >> >>Jeff Squyres >> >>Cisco Systems >> >> >> >>_______________________________________________ >> >>mpi-22 mailing list >> >>mpi-22_at_[hidden] >> >>http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 >> >> >> >> >> >>_______________________________________________ >> >>mpi-22 mailing list >> >>mpi-22_at_[hidden] >> >>http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 >> > >> >_______________________________________________ >> >mpi-22 mailing list >> >mpi-22_at_[hidden] >> >http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 >> > >> > >> >_______________________________________________ >> >mpi-22 mailing list >> >mpi-22_at_[hidden] >> >http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 >> >> _______________________________________________ >> mpi-22 mailing list >> mpi-22_at_[hidden] >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 >> >> >> _______________________________________________ >> mpi-22 mailing list >> mpi-22_at_[hidden] >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 > > >-- >Jeff Squyres >Cisco Systems > >_______________________________________________ >mpi-22 mailing list >mpi-22_at_[hidden] >http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 From bwbarre at [hidden] Fri Mar 13 13:36:15 2009 From: bwbarre at [hidden] (Barrett, Brian W) Date: Fri, 13 Mar 2009 12:36:15 -0600 Subject: [Mpi-22] Ticket #46: Addconst Keyword to the C bindings- implementation In-Reply-To: <32135_1236962559_n2DGgbAN001097_6B68D01C00C9994A8E150183E62A119E7B732398EA@NA-EXMSG-C105.redmond.corp.microsoft.com> Message-ID: <2D094A28F6B31745BE7B844EA0FF609626434178F3@ES04SNLNT.srn.sandia.gov> All - I spent some time looking at what it would take to implement this proposal in Open MPI as well as the changes made in the MPICH2 implementation. I think both raise some concerns for this proposal, particularly for MPI 2.2. The diff for the proposal was almost 10,000 lines long, which is a little frightening for 2.2 change. However, the places the constness is cast away for the send buffer raises some issues. In particular, for eager, contiguous sends, the send buffer constness is cast away in MPID_Send, which is the second call in the send call stack. Since there has been much discussion about how the constness of a buffer shouldn't be cast away at the upper layers of the MPI implementation, it seems problematic that the reference implementation does just that. It seems problematic not because of the choice made by the implementors of the patch, but because it is not clear that the is really a better implementation option. Of course, the choice of how to handle non-contiguous data raises some issues for Open MPI's internals. Open MPI's low layer communication interface is based on a iovec-like interface. Like most interfaces, the iovec-like interface is shared between the send and receive calls. The iovec structure can not be const, meaning that we are faced with two choices. We can either cast away the const interface before this low-level interface or we can create two data structures, one for send and one fore receive. The const cast option obviously has its problems. The two data structure option is certainly not appealing for us from a code maintainability stand-point. This is further complicated by the fact that almost none of the transports Open MPI currently supports can be used without casting away the constness. I understand that it would be good to promote the use of const for send buffers in lower-level middleware, as well as the fact that not all MPI implementations have such middleware. However, many interfaces have a similar iovec issue to Open MPI, and they'll be unlike to change. The fact that we will permanently be casting away const is slightly bothersome to me. I think given these issues and the large size of the change, pushing this proposal to 3.0 would be appropriate. Brian ________________________________________ From: mpi-22-bounces_at_[hidden] [mpi-22-bounces_at_[hidden]] On Behalf Of Erez Haba [erezh_at_[hidden]] Sent: Friday, March 13, 2009 10:40 AM To: MPI 2.2 Subject: Re: [Mpi-22] Ticket #46: Addconst Keyword to the C bindings- implementation Hi Jeff, The point of this ticket is to present a consistent const correct interface to the programmer and hide all the idiosyncrasies of the down-level interfaces. That said, to answer your questions: No casting is required for: * shared memory * sockets (TCP) when using 'send()' (single buffer passed in) Casting is required for interfaces that did not define their io vector buffer member as const. (an interface would need to define two io vector structures, one with const buffer for send and one with non-const for receive; most of them don't). Thus, casting is required when using the scatter/gather io vector with * sockets (TC) * Network Direct (IB and iWarp) With MPICH2 implementation, casting out the const for the send buffer when using these interfaces was there all along as (most of) MPICH2 internal functions already used const to pass the send buffer. No new cast was required in this full const implementation. Again, casting away the const to use the lower level interface does not violate any const rules as long as the semantic is preserved. Thanks, .Erez -----Original Message----- From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Jeff Squyres Sent: Friday, March 13, 2009 6:05 AM To: MPI 2.2 Subject: Re: [Mpi-22] Ticket #46: Addconst Keyword to the C bindings- implementation Do you end up casting away the const when invoking the Windows network interfaces? On Linux, I think the following interfaces would require casting the const away: - shared memory (even using Linux vmsplice()) - MX - TCP - OpenFabrics (both verbs and udapl) These interfaces do not require casting away const: - SCTP (I *think* -- I'm not an SCTP expert, but a quick look in sctp.h showed a "const" argument for the sctp_sendmsg() function) I can't check these offhand: - Portals - Elan On Mar 12, 2009, at 6:06 PM, Erez Haba wrote: > I urge you, please read the ticket proposal again. It discusses the > merit of this proposal. > > As for IB; yes you'd copy small messages (which const is fine with) > and some implement RDMA read or write for large messages; you might > need to cast the const away if your IB interface does not expose > const SGE's. > > As for the compiler; no you are not violating the contact; > (otherwise we wouldn't have casts); as long as you guarantee that > you are not changing the buffer. It's a way for the programmer to > use old, non const correct, interfaces. > > .Erez > > -----Original Message----- > From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden] > ] On Behalf Of Underwood, Keith D > Sent: Thursday, March 12, 2009 2:03 PM > To: MPI 2.2 > Subject: Re: [Mpi-22] Ticket #46: Add const Keyword to the C > bindings- implementation > > I didn't think that typical MPI implementations over IB copied the > data for large messages (as opposed to the bounce buffers for small > messages). > > If you are going to have to cast away the const, what is the point > of putting it in? In fact, if you have to cast away the const, > aren't you violating your contract with the compiler? Should this > change be rolled out from the bottom up? i.e. common low-level APIs > first and then MPI? > > Keith > > >-----Original Message----- > >From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_lists.mpi- > >forum.org] On Behalf Of Erez Haba > >Sent: Thursday, March 12, 2009 2:10 PM > >To: MPI 2.2 > >Subject: Re: [Mpi-22] Ticket #46: Add const Keyword to the C > bindings- > >implementation > > > >Possibly you'll have to cast. > >There are few interfaces that take const for send buffer (like > sockets). > >In other cases you copy the buffer (like with IB) which keeps the > const > >property. > > > >Thanks, > >.Erez > > > >-----Original Message----- > >From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_lists.mpi- > >forum.org] On Behalf Of Underwood, Keith D > >Sent: Thursday, March 12, 2009 12:05 PM > >To: MPI 2.2 > >Subject: Re: [Mpi-22] Ticket #46: Add const Keyword to the C > bindings- > >implementation > > > >It would seem like const would eventually have to be cast away for > most > >lower level interfaces. Portals, Elan, IB Verbs, and as best I can > tell MX > >don't have const on their send buffers... > > > >Keith > > > >>-----Original Message----- > >>From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_lists.mpi- > >>forum.org] On Behalf Of Erez Haba > >>Sent: Thursday, March 12, 2009 12:44 PM > >>To: MPI 2.2 > >>Subject: Re: [Mpi-22] Ticket #46: Add const Keyword to the C > bindings- > >>implementation > >> > >>No, it's not being cast away (although it is a quick way for you to > >>implement it). > >>In MPICH2 implementation it trickles down to the lower functions. > There > >are > >>very few places where the const is being cast away because ticket > #46 does > >>not to break backward compatibility. > >>For example, when the user function is called (const was not added > to the > >>MPI_User_function) the implementation must cast away const from > the send > >>buffer before calling the user function. > >> > >>Thanks, > >>.Erez > >> > >>-----Original Message----- > >>From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_lists.mpi- > >>forum.org] On Behalf Of Jeff Squyres > >>Sent: Thursday, March 12, 2009 11:34 AM > >>To: MPI 2.2 > >>Subject: Re: [Mpi-22] Ticket #46: Add const Keyword to the C > bindings- > >>implementation > >> > >>More importantly, how is const handled? Is it just cast away inside > >>the MPI library? > >> > >> > >>On Mar 12, 2009, at 2:34 PM, Underwood, Keith D wrote: > >> > >>> Since the main purpose of an implementation for something like > >>> adding const is to see how invasive the change is, would it be > >>> possible to get a diff against the trees that these were created > from? > >>> > >>> Thanks, > >>> Keith > >>> > >>> From: mpi-22-bounces_at_[hidden] [mailto:mpi-22- > >>bounces_at_[hidden] > >>> ] On Behalf Of Erez Haba > >>> Sent: Thursday, March 12, 2009 12:24 PM > >>> To: MPI 2.2 > >>> Subject: [Mpi-22] Ticket #46: Add const Keyword to the C > bindings - > >>> implementation > >>> > >>> > >>> Implementation for ticket #46 is now available from ANL (thanks > Pavan) > >>> > >>> > >>> tarballs > >>> > >>http://www.mcs.anl.gov/research/projects/mpich2/downloads/tarballs/nightly > >/ > >>const > >>> > >>> > >>> thanks, > >>> .Erez > >>> > >>> _______________________________________________ > >>> mpi-22 mailing list > >>> mpi-22_at_[hidden] > >>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 > >> > >> > >>-- > >>Jeff Squyres > >>Cisco Systems > >> > >>_______________________________________________ > >>mpi-22 mailing list > >>mpi-22_at_[hidden] > >>http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 > >> > >> > >>_______________________________________________ > >>mpi-22 mailing list > >>mpi-22_at_[hidden] > >>http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 > > > >_______________________________________________ > >mpi-22 mailing list > >mpi-22_at_[hidden] > >http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 > > > > > >_______________________________________________ > >mpi-22 mailing list > >mpi-22_at_[hidden] > >http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 > > _______________________________________________ > mpi-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 > > > _______________________________________________ > mpi-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 -- Jeff Squyres Cisco Systems _______________________________________________ mpi-22 mailing list mpi-22_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 _______________________________________________ mpi-22 mailing list mpi-22_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 From jsquyres at [hidden] Fri Mar 13 14:17:34 2009 From: jsquyres at [hidden] (Jeff Squyres) Date: Fri, 13 Mar 2009 15:17:34 -0400 Subject: [Mpi-22] Ticket #46: Add const Keyword to the C bindings-implementation In-Reply-To: <51A888AB-AEA8-48C7-B1F5-146ADE9F35D5@illinois.edu> Message-ID: On Mar 13, 2009, at 9:40 AM, William Gropp wrote: > First, this is a chicken-and-egg problem; the low level > interfaces are unlikely to change to add const unless there is some > application that will take advantage of that (and internally, if their > semantics allows it and their compiler can support it, they'll just > cast to add the const). So MPI should take the lead, particularly > since using const also provides information to the user. > This is a very scary statement to me. MPI has not traditionally "taken the lead" on forcing issues with other interfaces (look where it has gotten us with Fortran...). Indeed, MPI has taken great pains to be the lowest common denominator across a variety of language, platforms, and operating systems. -- Jeff Squyres Cisco Systems From balaji at [hidden] Fri Mar 13 14:39:04 2009 From: balaji at [hidden] (Pavan Balaji) Date: Fri, 13 Mar 2009 14:39:04 -0500 Subject: [Mpi-22] Ticket #46: Addconst Keyword to the C bindings- implementation In-Reply-To: <2D094A28F6B31745BE7B844EA0FF609626434178F3@ES04SNLNT.srn.sandia.gov> Message-ID: <49BAB658.3000407@mcs.anl.gov> > The diff for the proposal was almost 10,000 lines long, which is a > little frightening for 2.2 change. FWIW, it took only a few days to implement. Though it's a long patch, most changes are trivial. > However, the places the constness is cast away for the send buffer > raises some issues. In particular, for eager, contiguous sends, the > send buffer constness is cast away in MPID_Send, which is the second MPID_Send already uses a const, so we are not actually casting away the constness. > Open MPI's low layer communication interface is based on a iovec-like > interface. Like most interfaces, the iovec-like interface is shared > between the send and receive calls. Yes, we faced similar issues in some places (mainly in ROMIO), but they were only a handful if I remember correctly. -- Pavan -- Pavan Balaji http://www.mcs.anl.gov/~balaji From erezh at [hidden] Fri Mar 13 14:39:50 2009 From: erezh at [hidden] (Erez Haba) Date: Fri, 13 Mar 2009 12:39:50 -0700 Subject: [Mpi-22] Ticket #46: Addconst Keyword to the C bindings- implementation In-Reply-To: <2D094A28F6B31745BE7B844EA0FF609626434178F3@ES04SNLNT.srn.sandia.gov> Message-ID: <6B68D01C00C9994A8E150183E62A119E7B73239AD6@NA-EXMSG-C105.redmond.corp.microsoft.com> I've implemented this complete change during the last MPI-forum meeting. It took me about 2.5h hours to implement while participating in the discussion. So I would argue that it's not a big implementation item for any MPI. (look at the diff last change, out of the 10 lines in the diff, only 1 line is changed) I would argue that casting away the const to adapt your buffer to your lower level interconnect interface is perfectly fine. The semantic for your lower level interconnect interface is simple, clear and does not modify the send buffer. (for the cases where actually you need to cast the const away) Thanks, .Erez -----Original Message----- From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Barrett, Brian W Sent: Friday, March 13, 2009 11:36 AM To: MPI 2.2 Subject: Re: [Mpi-22] Ticket #46: Addconst Keyword to the C bindings- implementation All - I spent some time looking at what it would take to implement this proposal in Open MPI as well as the changes made in the MPICH2 implementation. I think both raise some concerns for this proposal, particularly for MPI 2.2. The diff for the proposal was almost 10,000 lines long, which is a little frightening for 2.2 change. However, the places the constness is cast away for the send buffer raises some issues. In particular, for eager, contiguous sends, the send buffer constness is cast away in MPID_Send, which is the second call in the send call stack. Since there has been much discussion about how the constness of a buffer shouldn't be cast away at the upper layers of the MPI implementation, it seems problematic that the reference implementation does just that. It seems problematic not because of the choice made by the implementors of the patch, but because it is not clear that the is really a better implementation option. Of course, the choice of how to handle non-contiguous data raises some issues for Open MPI's internals. Open MPI's low layer communication interface is based on a iovec-like interface. Like most interfaces, the iovec-like interface is shared between the send and receive calls. The iovec structure can not be const, meaning that we are faced with two choices. We can either cast away the const interface before this low-level interface or we can create two data structures, one for send and one fore receive. The const cast option obviously has its problems. The two data structure option is certainly not appealing for us from a code maintainability stand-point. This is further complicated by the fact that almost none of the transports Open MPI currently supports can be used without casting away the constness. I understand that it would be good to promote the use of const for send buffers in lower-level middleware, as well as the fact that not all MPI implementations have such middleware. However, many interfaces have a similar iovec issue to Open MPI, and they'll be unlike to change. The fact that we will permanently be casting away const is slightly bothersome to me. I think given these issues and the large size of the change, pushing this proposal to 3.0 would be appropriate. Brian ________________________________________ From: mpi-22-bounces_at_[hidden] [mpi-22-bounces_at_[hidden]] On Behalf Of Erez Haba [erezh_at_[hidden]] Sent: Friday, March 13, 2009 10:40 AM To: MPI 2.2 Subject: Re: [Mpi-22] Ticket #46: Addconst Keyword to the C bindings- implementation Hi Jeff, The point of this ticket is to present a consistent const correct interface to the programmer and hide all the idiosyncrasies of the down-level interfaces. That said, to answer your questions: No casting is required for: * shared memory * sockets (TCP) when using 'send()' (single buffer passed in) Casting is required for interfaces that did not define their io vector buffer member as const. (an interface would need to define two io vector structures, one with const buffer for send and one with non-const for receive; most of them don't). Thus, casting is required when using the scatter/gather io vector with * sockets (TC) * Network Direct (IB and iWarp) With MPICH2 implementation, casting out the const for the send buffer when using these interfaces was there all along as (most of) MPICH2 internal functions already used const to pass the send buffer. No new cast was required in this full const implementation. Again, casting away the const to use the lower level interface does not violate any const rules as long as the semantic is preserved. Thanks, .Erez -----Original Message----- From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Jeff Squyres Sent: Friday, March 13, 2009 6:05 AM To: MPI 2.2 Subject: Re: [Mpi-22] Ticket #46: Addconst Keyword to the C bindings- implementation Do you end up casting away the const when invoking the Windows network interfaces? On Linux, I think the following interfaces would require casting the const away: - shared memory (even using Linux vmsplice()) - MX - TCP - OpenFabrics (both verbs and udapl) These interfaces do not require casting away const: - SCTP (I *think* -- I'm not an SCTP expert, but a quick look in sctp.h showed a "const" argument for the sctp_sendmsg() function) I can't check these offhand: - Portals - Elan On Mar 12, 2009, at 6:06 PM, Erez Haba wrote: > I urge you, please read the ticket proposal again. It discusses the > merit of this proposal. > > As for IB; yes you'd copy small messages (which const is fine with) > and some implement RDMA read or write for large messages; you might > need to cast the const away if your IB interface does not expose > const SGE's. > > As for the compiler; no you are not violating the contact; > (otherwise we wouldn't have casts); as long as you guarantee that > you are not changing the buffer. It's a way for the programmer to > use old, non const correct, interfaces. > > .Erez > > -----Original Message----- > From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden] > ] On Behalf Of Underwood, Keith D > Sent: Thursday, March 12, 2009 2:03 PM > To: MPI 2.2 > Subject: Re: [Mpi-22] Ticket #46: Add const Keyword to the C > bindings- implementation > > I didn't think that typical MPI implementations over IB copied the > data for large messages (as opposed to the bounce buffers for small > messages). > > If you are going to have to cast away the const, what is the point > of putting it in? In fact, if you have to cast away the const, > aren't you violating your contract with the compiler? Should this > change be rolled out from the bottom up? i.e. common low-level APIs > first and then MPI? > > Keith > > >-----Original Message----- > >From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_lists.mpi- > >forum.org] On Behalf Of Erez Haba > >Sent: Thursday, March 12, 2009 2:10 PM > >To: MPI 2.2 > >Subject: Re: [Mpi-22] Ticket #46: Add const Keyword to the C > bindings- > >implementation > > > >Possibly you'll have to cast. > >There are few interfaces that take const for send buffer (like > sockets). > >In other cases you copy the buffer (like with IB) which keeps the > const > >property. > > > >Thanks, > >.Erez > > > >-----Original Message----- > >From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_lists.mpi- > >forum.org] On Behalf Of Underwood, Keith D > >Sent: Thursday, March 12, 2009 12:05 PM > >To: MPI 2.2 > >Subject: Re: [Mpi-22] Ticket #46: Add const Keyword to the C > bindings- > >implementation > > > >It would seem like const would eventually have to be cast away for > most > >lower level interfaces. Portals, Elan, IB Verbs, and as best I can > tell MX > >don't have const on their send buffers... > > > >Keith > > > >>-----Original Message----- > >>From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_lists.mpi- > >>forum.org] On Behalf Of Erez Haba > >>Sent: Thursday, March 12, 2009 12:44 PM > >>To: MPI 2.2 > >>Subject: Re: [Mpi-22] Ticket #46: Add const Keyword to the C > bindings- > >>implementation > >> > >>No, it's not being cast away (although it is a quick way for you to > >>implement it). > >>In MPICH2 implementation it trickles down to the lower functions. > There > >are > >>very few places where the const is being cast away because ticket > #46 does > >>not to break backward compatibility. > >>For example, when the user function is called (const was not added > to the > >>MPI_User_function) the implementation must cast away const from > the send > >>buffer before calling the user function. > >> > >>Thanks, > >>.Erez > >> > >>-----Original Message----- > >>From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_lists.mpi- > >>forum.org] On Behalf Of Jeff Squyres > >>Sent: Thursday, March 12, 2009 11:34 AM > >>To: MPI 2.2 > >>Subject: Re: [Mpi-22] Ticket #46: Add const Keyword to the C > bindings- > >>implementation > >> > >>More importantly, how is const handled? Is it just cast away inside > >>the MPI library? > >> > >> > >>On Mar 12, 2009, at 2:34 PM, Underwood, Keith D wrote: > >> > >>> Since the main purpose of an implementation for something like > >>> adding const is to see how invasive the change is, would it be > >>> possible to get a diff against the trees that these were created > from? > >>> > >>> Thanks, > >>> Keith > >>> > >>> From: mpi-22-bounces_at_[hidden] [mailto:mpi-22- > >>bounces_at_[hidden] > >>> ] On Behalf Of Erez Haba > >>> Sent: Thursday, March 12, 2009 12:24 PM > >>> To: MPI 2.2 > >>> Subject: [Mpi-22] Ticket #46: Add const Keyword to the C > bindings - > >>> implementation > >>> > >>> > >>> Implementation for ticket #46 is now available from ANL (thanks > Pavan) > >>> > >>> > >>> tarballs > >>> > >>http://www.mcs.anl.gov/research/projects/mpich2/downloads/tarballs/nightly > >/ > >>const > >>> > >>> > >>> thanks, > >>> .Erez > >>> > >>> _______________________________________________ > >>> mpi-22 mailing list > >>> mpi-22_at_[hidden] > >>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 > >> > >> > >>-- > >>Jeff Squyres > >>Cisco Systems > >> > >>_______________________________________________ > >>mpi-22 mailing list > >>mpi-22_at_[hidden] > >>http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 > >> > >> > >>_______________________________________________ > >>mpi-22 mailing list > >>mpi-22_at_[hidden] > >>http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 > > > >_______________________________________________ > >mpi-22 mailing list > >mpi-22_at_[hidden] > >http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 > > > > > >_______________________________________________ > >mpi-22 mailing list > >mpi-22_at_[hidden] > >http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 > > _______________________________________________ > mpi-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 > > > _______________________________________________ > mpi-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 -- Jeff Squyres Cisco Systems _______________________________________________ mpi-22 mailing list mpi-22_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 _______________________________________________ mpi-22 mailing list mpi-22_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 _______________________________________________ mpi-22 mailing list mpi-22_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 From erezh at [hidden] Fri Mar 13 14:43:24 2009 From: erezh at [hidden] (Erez Haba) Date: Fri, 13 Mar 2009 12:43:24 -0700 Subject: [Mpi-22] Ticket #46: Addconst Keyword to the C bindings- implementation In-Reply-To: <6B68D01C00C9994A8E150183E62A119E7B73239AD6@NA-EXMSG-C105.redmond.corp.microsoft.com> Message-ID: <6B68D01C00C9994A8E150183E62A119E7B73239ADD@NA-EXMSG-C105.redmond.corp.microsoft.com> P.S. Take a look at sockets send function http://www.opengroup.org/onlinepubs/000095399/functions/send.html why do you think that they bothered adding const to the sockets send function? Thanks, .Erez -----Original Message----- From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Erez Haba Sent: Friday, March 13, 2009 12:40 PM To: MPI 2.2 Subject: Re: [Mpi-22] Ticket #46: Addconst Keyword to the C bindings- implementation I've implemented this complete change during the last MPI-forum meeting. It took me about 2.5h hours to implement while participating in the discussion. So I would argue that it's not a big implementation item for any MPI. (look at the diff last change, out of the 10 lines in the diff, only 1 line is changed) I would argue that casting away the const to adapt your buffer to your lower level interconnect interface is perfectly fine. The semantic for your lower level interconnect interface is simple, clear and does not modify the send buffer. (for the cases where actually you need to cast the const away) Thanks, .Erez -----Original Message----- From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Barrett, Brian W Sent: Friday, March 13, 2009 11:36 AM To: MPI 2.2 Subject: Re: [Mpi-22] Ticket #46: Addconst Keyword to the C bindings- implementation All - I spent some time looking at what it would take to implement this proposal in Open MPI as well as the changes made in the MPICH2 implementation. I think both raise some concerns for this proposal, particularly for MPI 2.2. The diff for the proposal was almost 10,000 lines long, which is a little frightening for 2.2 change. However, the places the constness is cast away for the send buffer raises some issues. In particular, for eager, contiguous sends, the send buffer constness is cast away in MPID_Send, which is the second call in the send call stack. Since there has been much discussion about how the constness of a buffer shouldn't be cast away at the upper layers of the MPI implementation, it seems problematic that the reference implementation does just that. It seems problematic not because of the choice made by the implementors of the patch, but because it is not clear that the is really a better implementation option. Of course, the choice of how to handle non-contiguous data raises some issues for Open MPI's internals. Open MPI's low layer communication interface is based on a iovec-like interface. Like most interfaces, the iovec-like interface is shared between the send and receive calls. The iovec structure can not be const, meaning that we are faced with two choices. We can either cast away the const interface before this low-level interface or we can create two data structures, one for send and one fore receive. The const cast option obviously has its problems. The two data structure option is certainly not appealing for us from a code maintainability stand-point. This is further complicated by the fact that almost none of the transports Open MPI currently supports can be used without casting away the constness. I understand that it would be good to promote the use of const for send buffers in lower-level middleware, as well as the fact that not all MPI implementations have such middleware. However, many interfaces have a similar iovec issue to Open MPI, and they'll be unlike to change. The fact that we will permanently be casting away const is slightly bothersome to me. I think given these issues and the large size of the change, pushing this proposal to 3.0 would be appropriate. Brian ________________________________________ From: mpi-22-bounces_at_[hidden] [mpi-22-bounces_at_[hidden]] On Behalf Of Erez Haba [erezh_at_[hidden]] Sent: Friday, March 13, 2009 10:40 AM To: MPI 2.2 Subject: Re: [Mpi-22] Ticket #46: Addconst Keyword to the C bindings- implementation Hi Jeff, The point of this ticket is to present a consistent const correct interface to the programmer and hide all the idiosyncrasies of the down-level interfaces. That said, to answer your questions: No casting is required for: * shared memory * sockets (TCP) when using 'send()' (single buffer passed in) Casting is required for interfaces that did not define their io vector buffer member as const. (an interface would need to define two io vector structures, one with const buffer for send and one with non-const for receive; most of them don't). Thus, casting is required when using the scatter/gather io vector with * sockets (TC) * Network Direct (IB and iWarp) With MPICH2 implementation, casting out the const for the send buffer when using these interfaces was there all along as (most of) MPICH2 internal functions already used const to pass the send buffer. No new cast was required in this full const implementation. Again, casting away the const to use the lower level interface does not violate any const rules as long as the semantic is preserved. Thanks, .Erez -----Original Message----- From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Jeff Squyres Sent: Friday, March 13, 2009 6:05 AM To: MPI 2.2 Subject: Re: [Mpi-22] Ticket #46: Addconst Keyword to the C bindings- implementation Do you end up casting away the const when invoking the Windows network interfaces? On Linux, I think the following interfaces would require casting the const away: - shared memory (even using Linux vmsplice()) - MX - TCP - OpenFabrics (both verbs and udapl) These interfaces do not require casting away const: - SCTP (I *think* -- I'm not an SCTP expert, but a quick look in sctp.h showed a "const" argument for the sctp_sendmsg() function) I can't check these offhand: - Portals - Elan On Mar 12, 2009, at 6:06 PM, Erez Haba wrote: > I urge you, please read the ticket proposal again. It discusses the > merit of this proposal. > > As for IB; yes you'd copy small messages (which const is fine with) > and some implement RDMA read or write for large messages; you might > need to cast the const away if your IB interface does not expose > const SGE's. > > As for the compiler; no you are not violating the contact; > (otherwise we wouldn't have casts); as long as you guarantee that > you are not changing the buffer. It's a way for the programmer to > use old, non const correct, interfaces. > > .Erez > > -----Original Message----- > From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden] > ] On Behalf Of Underwood, Keith D > Sent: Thursday, March 12, 2009 2:03 PM > To: MPI 2.2 > Subject: Re: [Mpi-22] Ticket #46: Add const Keyword to the C > bindings- implementation > > I didn't think that typical MPI implementations over IB copied the > data for large messages (as opposed to the bounce buffers for small > messages). > > If you are going to have to cast away the const, what is the point > of putting it in? In fact, if you have to cast away the const, > aren't you violating your contract with the compiler? Should this > change be rolled out from the bottom up? i.e. common low-level APIs > first and then MPI? > > Keith > > >-----Original Message----- > >From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_lists.mpi- > >forum.org] On Behalf Of Erez Haba > >Sent: Thursday, March 12, 2009 2:10 PM > >To: MPI 2.2 > >Subject: Re: [Mpi-22] Ticket #46: Add const Keyword to the C > bindings- > >implementation > > > >Possibly you'll have to cast. > >There are few interfaces that take const for send buffer (like > sockets). > >In other cases you copy the buffer (like with IB) which keeps the > const > >property. > > > >Thanks, > >.Erez > > > >-----Original Message----- > >From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_lists.mpi- > >forum.org] On Behalf Of Underwood, Keith D > >Sent: Thursday, March 12, 2009 12:05 PM > >To: MPI 2.2 > >Subject: Re: [Mpi-22] Ticket #46: Add const Keyword to the C > bindings- > >implementation > > > >It would seem like const would eventually have to be cast away for > most > >lower level interfaces. Portals, Elan, IB Verbs, and as best I can > tell MX > >don't have const on their send buffers... > > > >Keith > > > >>-----Original Message----- > >>From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_lists.mpi- > >>forum.org] On Behalf Of Erez Haba > >>Sent: Thursday, March 12, 2009 12:44 PM > >>To: MPI 2.2 > >>Subject: Re: [Mpi-22] Ticket #46: Add const Keyword to the C > bindings- > >>implementation > >> > >>No, it's not being cast away (although it is a quick way for you to > >>implement it). > >>In MPICH2 implementation it trickles down to the lower functions. > There > >are > >>very few places where the const is being cast away because ticket > #46 does > >>not to break backward compatibility. > >>For example, when the user function is called (const was not added > to the > >>MPI_User_function) the implementation must cast away const from > the send > >>buffer before calling the user function. > >> > >>Thanks, > >>.Erez > >> > >>-----Original Message----- > >>From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_lists.mpi- > >>forum.org] On Behalf Of Jeff Squyres > >>Sent: Thursday, March 12, 2009 11:34 AM > >>To: MPI 2.2 > >>Subject: Re: [Mpi-22] Ticket #46: Add const Keyword to the C > bindings- > >>implementation > >> > >>More importantly, how is const handled? Is it just cast away inside > >>the MPI library? > >> > >> > >>On Mar 12, 2009, at 2:34 PM, Underwood, Keith D wrote: > >> > >>> Since the main purpose of an implementation for something like > >>> adding const is to see how invasive the change is, would it be > >>> possible to get a diff against the trees that these were created > from? > >>> > >>> Thanks, > >>> Keith > >>> > >>> From: mpi-22-bounces_at_[hidden] [mailto:mpi-22- > >>bounces_at_[hidden] > >>> ] On Behalf Of Erez Haba > >>> Sent: Thursday, March 12, 2009 12:24 PM > >>> To: MPI 2.2 > >>> Subject: [Mpi-22] Ticket #46: Add const Keyword to the C > bindings - > >>> implementation > >>> > >>> > >>> Implementation for ticket #46 is now available from ANL (thanks > Pavan) > >>> > >>> > >>> tarballs > >>> > >>http://www.mcs.anl.gov/research/projects/mpich2/downloads/tarballs/nightly > >/ > >>const > >>> > >>> > >>> thanks, > >>> .Erez > >>> > >>> _______________________________________________ > >>> mpi-22 mailing list > >>> mpi-22_at_[hidden] > >>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 > >> > >> > >>-- > >>Jeff Squyres > >>Cisco Systems > >> > >>_______________________________________________ > >>mpi-22 mailing list > >>mpi-22_at_[hidden] > >>http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 > >> > >> > >>_______________________________________________ > >>mpi-22 mailing list > >>mpi-22_at_[hidden] > >>http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 > > > >_______________________________________________ > >mpi-22 mailing list > >mpi-22_at_[hidden] > >http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 > > > > > >_______________________________________________ > >mpi-22 mailing list > >mpi-22_at_[hidden] > >http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 > > _______________________________________________ > mpi-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 > > > _______________________________________________ > mpi-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 -- Jeff Squyres Cisco Systems _______________________________________________ mpi-22 mailing list mpi-22_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 _______________________________________________ mpi-22 mailing list mpi-22_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 _______________________________________________ mpi-22 mailing list mpi-22_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 _______________________________________________ mpi-22 mailing list mpi-22_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 From jsquyres at [hidden] Fri Mar 13 14:47:27 2009 From: jsquyres at [hidden] (Jeff Squyres) Date: Fri, 13 Mar 2009 15:47:27 -0400 Subject: [Mpi-22] Ticket #46: Addconst Keyword to the C bindings-implementation In-Reply-To: <49BAB658.3000407@mcs.anl.gov> Message-ID: <18FFC271-B032-4453-B61F-7587FA001FCD@cisco.com> On Mar 13, 2009, at 3:39 PM, Pavan Balaji wrote: > > The diff for the proposal was almost 10,000 lines long, which is a > > little frightening for 2.2 change. > > FWIW, it took only a few days to implement. Though it's a long patch, > most changes are trivial. > FWIW: I don't think that a 10,000 line patch is trivial. The search and replace may be simple enough. But the sheer size of the patch makes one step back and say "whoa". -- Jeff Squyres Cisco Systems From keith.d.underwood at [hidden] Fri Mar 13 14:52:35 2009 From: keith.d.underwood at [hidden] (Underwood, Keith D) Date: Fri, 13 Mar 2009 13:52:35 -0600 Subject: [Mpi-22] Ticket #46: Addconst Keyword to the C bindings- implementation In-Reply-To: <6B68D01C00C9994A8E150183E62A119E7B73239ADD@NA-EXMSG-C105.redmond.corp.microsoft.com> Message-ID: <8E9963DB482E4B49AB9EF1C296936CF718E2453B@rrsmsx507.amr.corp.intel.com> Because the semantics of sockets requires a copy in the kernel? Because changes like this should be made available from the bottom up? Because they figured out how to do it without casting away const somewhere in the middle of the stack? I must admit that I'm impressed by the rate at which you can write correct code if you made this change in 2.5h while in discussions without just casting it away as soon as you entered the library... If you cast it away immediately or already had a heavy dose of const in your library to start with, then that isn't really a fair metric. Keith >-----Original Message----- >From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_lists.mpi- >forum.org] On Behalf Of Erez Haba >Sent: Friday, March 13, 2009 1:43 PM >To: MPI 2.2 >Subject: Re: [Mpi-22] Ticket #46: Addconst Keyword to the C bindings- >implementation > >P.S. > >Take a look at sockets send function >http://www.opengroup.org/onlinepubs/000095399/functions/send.html > >why do you think that they bothered adding const to the sockets send >function? > >Thanks, >.Erez > >-----Original Message----- >From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_lists.mpi- >forum.org] On Behalf Of Erez Haba >Sent: Friday, March 13, 2009 12:40 PM >To: MPI 2.2 >Subject: Re: [Mpi-22] Ticket #46: Addconst Keyword to the C bindings- >implementation > >I've implemented this complete change during the last MPI-forum meeting. It >took me about 2.5h hours to implement while participating in the discussion. >So I would argue that it's not a big implementation item for any MPI. >(look at the diff last change, out of the 10 lines in the diff, only 1 line >is changed) > >I would argue that casting away the const to adapt your buffer to your >lower level interconnect interface is perfectly fine. The semantic for your >lower level interconnect interface is simple, clear and does not modify the >send buffer. (for the cases where actually you need to cast the const away) > >Thanks, >.Erez > >-----Original Message----- >From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_lists.mpi- >forum.org] On Behalf Of Barrett, Brian W >Sent: Friday, March 13, 2009 11:36 AM >To: MPI 2.2 >Subject: Re: [Mpi-22] Ticket #46: Addconst Keyword to the C bindings- >implementation > >All - > >I spent some time looking at what it would take to implement this proposal >in Open MPI as well as the changes made in the MPICH2 implementation. I >think both raise some concerns for this proposal, particularly for MPI 2.2. > >The diff for the proposal was almost 10,000 lines long, which is a little >frightening for 2.2 change. However, the places the constness is cast away >for the send buffer raises some issues. In particular, for eager, >contiguous sends, the send buffer constness is cast away in MPID_Send, >which is the second call in the send call stack. Since there has been much >discussion about how the constness of a buffer shouldn't be cast away at >the upper layers of the MPI implementation, it seems problematic that the >reference implementation does just that. It seems problematic not because >of the choice made by the implementors of the patch, but because it is not >clear that the is really a better implementation option. Of course, the >choice of how to handle non-contiguous data raises some issues for Open >MPI's internals. > >Open MPI's low layer communication interface is based on a iovec-like >interface. Like most interfaces, the iovec-like interface is shared >between the send and receive calls. The iovec structure can not be const, >meaning that we are faced with two choices. We can either cast away the >const interface before this low-level interface or we can create two data >structures, one for send and one fore receive. The const cast option >obviously has its problems. The two data structure option is certainly not >appealing for us from a code maintainability stand-point. This is further >complicated by the fact that almost none of the transports Open MPI >currently supports can be used without casting away the constness. > >I understand that it would be good to promote the use of const for send >buffers in lower-level middleware, as well as the fact that not all MPI >implementations have such middleware. However, many interfaces have a >similar iovec issue to Open MPI, and they'll be unlike to change. The fact >that we will permanently be casting away const is slightly bothersome to me. >I think given these issues and the large size of the change, pushing this >proposal to 3.0 would be appropriate. > >Brian > >________________________________________ >From: mpi-22-bounces_at_[hidden] [mpi-22-bounces_at_lists.mpi- >forum.org] On Behalf Of Erez Haba [erezh_at_[hidden]] >Sent: Friday, March 13, 2009 10:40 AM >To: MPI 2.2 >Subject: Re: [Mpi-22] Ticket #46: Addconst Keyword to the C bindings- >implementation > >Hi Jeff, > >The point of this ticket is to present a consistent const correct interface >to the programmer and hide all the idiosyncrasies of the down-level >interfaces. > >That said, to answer your questions: > >No casting is required for: >* shared memory >* sockets (TCP) when using 'send()' (single buffer passed in) > >Casting is required for interfaces that did not define their io vector >buffer member as const. (an interface would need to define two io vector >structures, one with const buffer for send and one with non-const for >receive; most of them don't). > >Thus, casting is required when using the scatter/gather io vector with >* sockets (TC) >* Network Direct (IB and iWarp) > >With MPICH2 implementation, casting out the const for the send buffer when >using these interfaces was there all along as (most of) MPICH2 internal >functions already used const to pass the send buffer. No new cast was >required in this full const implementation. > > >Again, casting away the const to use the lower level interface does not >violate any const rules as long as the semantic is preserved. > >Thanks, >.Erez > > >-----Original Message----- >From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_lists.mpi- >forum.org] On Behalf Of Jeff Squyres >Sent: Friday, March 13, 2009 6:05 AM >To: MPI 2.2 >Subject: Re: [Mpi-22] Ticket #46: Addconst Keyword to the C bindings- >implementation > >Do you end up casting away the const when invoking the Windows network >interfaces? > >On Linux, I think the following interfaces would require casting the >const away: > >- shared memory (even using Linux vmsplice()) >- MX >- TCP >- OpenFabrics (both verbs and udapl) > >These interfaces do not require casting away const: > >- SCTP (I *think* -- I'm not an SCTP expert, but a quick look in >sctp.h showed a "const" argument for the sctp_sendmsg() function) > >I can't check these offhand: > >- Portals >- Elan > > > >On Mar 12, 2009, at 6:06 PM, Erez Haba wrote: > >> I urge you, please read the ticket proposal again. It discusses the >> merit of this proposal. >> >> As for IB; yes you'd copy small messages (which const is fine with) >> and some implement RDMA read or write for large messages; you might >> need to cast the const away if your IB interface does not expose >> const SGE's. >> >> As for the compiler; no you are not violating the contact; >> (otherwise we wouldn't have casts); as long as you guarantee that >> you are not changing the buffer. It's a way for the programmer to >> use old, non const correct, interfaces. >> >> .Erez >> >> -----Original Message----- >> From: mpi-22-bounces_at_[hidden] [mailto:mpi-22- >bounces_at_[hidden] >> ] On Behalf Of Underwood, Keith D >> Sent: Thursday, March 12, 2009 2:03 PM >> To: MPI 2.2 >> Subject: Re: [Mpi-22] Ticket #46: Add const Keyword to the C >> bindings- implementation >> >> I didn't think that typical MPI implementations over IB copied the >> data for large messages (as opposed to the bounce buffers for small >> messages). >> >> If you are going to have to cast away the const, what is the point >> of putting it in? In fact, if you have to cast away the const, >> aren't you violating your contract with the compiler? Should this >> change be rolled out from the bottom up? i.e. common low-level APIs >> first and then MPI? >> >> Keith >> >> >-----Original Message----- >> >From: mpi-22-bounces_at_[hidden] [mailto:mpi-22- >bounces_at_lists.mpi- >> >forum.org] On Behalf Of Erez Haba >> >Sent: Thursday, March 12, 2009 2:10 PM >> >To: MPI 2.2 >> >Subject: Re: [Mpi-22] Ticket #46: Add const Keyword to the C >> bindings- >> >implementation >> > >> >Possibly you'll have to cast. >> >There are few interfaces that take const for send buffer (like >> sockets). >> >In other cases you copy the buffer (like with IB) which keeps the >> const >> >property. >> > >> >Thanks, >> >.Erez >> > >> >-----Original Message----- >> >From: mpi-22-bounces_at_[hidden] [mailto:mpi-22- >bounces_at_lists.mpi- >> >forum.org] On Behalf Of Underwood, Keith D >> >Sent: Thursday, March 12, 2009 12:05 PM >> >To: MPI 2.2 >> >Subject: Re: [Mpi-22] Ticket #46: Add const Keyword to the C >> bindings- >> >implementation >> > >> >It would seem like const would eventually have to be cast away for >> most >> >lower level interfaces. Portals, Elan, IB Verbs, and as best I can >> tell MX >> >don't have const on their send buffers... >> > >> >Keith >> > >> >>-----Original Message----- >> >>From: mpi-22-bounces_at_[hidden] [mailto:mpi-22- >bounces_at_lists.mpi- >> >>forum.org] On Behalf Of Erez Haba >> >>Sent: Thursday, March 12, 2009 12:44 PM >> >>To: MPI 2.2 >> >>Subject: Re: [Mpi-22] Ticket #46: Add const Keyword to the C >> bindings- >> >>implementation >> >> >> >>No, it's not being cast away (although it is a quick way for you to >> >>implement it). >> >>In MPICH2 implementation it trickles down to the lower functions. >> There >> >are >> >>very few places where the const is being cast away because ticket >> #46 does >> >>not to break backward compatibility. >> >>For example, when the user function is called (const was not added >> to the >> >>MPI_User_function) the implementation must cast away const from >> the send >> >>buffer before calling the user function. >> >> >> >>Thanks, >> >>.Erez >> >> >> >>-----Original Message----- >> >>From: mpi-22-bounces_at_[hidden] [mailto:mpi-22- >bounces_at_lists.mpi- >> >>forum.org] On Behalf Of Jeff Squyres >> >>Sent: Thursday, March 12, 2009 11:34 AM >> >>To: MPI 2.2 >> >>Subject: Re: [Mpi-22] Ticket #46: Add const Keyword to the C >> bindings- >> >>implementation >> >> >> >>More importantly, how is const handled? Is it just cast away inside >> >>the MPI library? >> >> >> >> >> >>On Mar 12, 2009, at 2:34 PM, Underwood, Keith D wrote: >> >> >> >>> Since the main purpose of an implementation for something like >> >>> adding const is to see how invasive the change is, would it be >> >>> possible to get a diff against the trees that these were created >> from? >> >>> >> >>> Thanks, >> >>> Keith >> >>> >> >>> From: mpi-22-bounces_at_[hidden] [mailto:mpi-22- >> >>bounces_at_[hidden] >> >>> ] On Behalf Of Erez Haba >> >>> Sent: Thursday, March 12, 2009 12:24 PM >> >>> To: MPI 2.2 >> >>> Subject: [Mpi-22] Ticket #46: Add const Keyword to the C >> bindings - >> >>> implementation >> >>> >> >>> >> >>> Implementation for ticket #46 is now available from ANL (thanks >> Pavan) >> >>> >> >>> >> >>> tarballs >> >>> >> >>>http://www.mcs.anl.gov/research/projects/mpich2/downloads/tarballs/nightl >y >> >/ >> >>const >> >>> >> >>> >> >>> thanks, >> >>> .Erez >> >>> >> >>> _______________________________________________ >> >>> mpi-22 mailing list >> >>> mpi-22_at_[hidden] >> >>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 >> >> >> >> >> >>-- >> >>Jeff Squyres >> >>Cisco Systems >> >> >> >>_______________________________________________ >> >>mpi-22 mailing list >> >>mpi-22_at_[hidden] >> >>http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 >> >> >> >> >> >>_______________________________________________ >> >>mpi-22 mailing list >> >>mpi-22_at_[hidden] >> >>http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 >> > >> >_______________________________________________ >> >mpi-22 mailing list >> >mpi-22_at_[hidden] >> >http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 >> > >> > >> >_______________________________________________ >> >mpi-22 mailing list >> >mpi-22_at_[hidden] >> >http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 >> >> _______________________________________________ >> mpi-22 mailing list >> mpi-22_at_[hidden] >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 >> >> >> _______________________________________________ >> mpi-22 mailing list >> mpi-22_at_[hidden] >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 > > >-- >Jeff Squyres >Cisco Systems > >_______________________________________________ >mpi-22 mailing list >mpi-22_at_[hidden] >http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 > > >_______________________________________________ >mpi-22 mailing list >mpi-22_at_[hidden] >http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 > > > >_______________________________________________ >mpi-22 mailing list >mpi-22_at_[hidden] >http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 > > >_______________________________________________ >mpi-22 mailing list >mpi-22_at_[hidden] >http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 > > >_______________________________________________ >mpi-22 mailing list >mpi-22_at_[hidden] >http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 From erezh at [hidden] Fri Mar 13 15:54:57 2009 From: erezh at [hidden] (Erez Haba) Date: Fri, 13 Mar 2009 13:54:57 -0700 Subject: [Mpi-22] Ticket #46: Addconst Keyword to the C bindings- implementation In-Reply-To: <8E9963DB482E4B49AB9EF1C296936CF718E2453B@rrsmsx507.amr.corp.intel.com> Message-ID: <6B68D01C00C9994A8E150183E62A119E7B732E15FA@NA-EXMSG-C105.redmond.corp.microsoft.com> It's rather a trivial change w/ MPICH2 code :) mostly adding the const keyword; not much of a code change. The change was about propagating the const to the lower function that didn't have it yet; the compiler helps you a lot with that. The necessary cast for the lower level function was already there; I had to add two more casts to deal with the MPI_User_function and MPI_Comm_spawn. Thanks, .Erez -----Original Message----- From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Underwood, Keith D Sent: Friday, March 13, 2009 12:53 PM To: MPI 2.2 Subject: Re: [Mpi-22] Ticket #46: Addconst Keyword to the C bindings- implementation Because the semantics of sockets requires a copy in the kernel? Because changes like this should be made available from the bottom up? Because they figured out how to do it without casting away const somewhere in the middle of the stack? I must admit that I'm impressed by the rate at which you can write correct code if you made this change in 2.5h while in discussions without just casting it away as soon as you entered the library... If you cast it away immediately or already had a heavy dose of const in your library to start with, then that isn't really a fair metric. Keith >-----Original Message----- >From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_lists.mpi- >forum.org] On Behalf Of Erez Haba >Sent: Friday, March 13, 2009 1:43 PM >To: MPI 2.2 >Subject: Re: [Mpi-22] Ticket #46: Addconst Keyword to the C bindings- >implementation > >P.S. > >Take a look at sockets send function >http://www.opengroup.org/onlinepubs/000095399/functions/send.html > >why do you think that they bothered adding const to the sockets send >function? > >Thanks, >.Erez > >-----Original Message----- >From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_lists.mpi- >forum.org] On Behalf Of Erez Haba >Sent: Friday, March 13, 2009 12:40 PM >To: MPI 2.2 >Subject: Re: [Mpi-22] Ticket #46: Addconst Keyword to the C bindings- >implementation > >I've implemented this complete change during the last MPI-forum meeting. It >took me about 2.5h hours to implement while participating in the discussion. >So I would argue that it's not a big implementation item for any MPI. >(look at the diff last change, out of the 10 lines in the diff, only 1 line >is changed) > >I would argue that casting away the const to adapt your buffer to your >lower level interconnect interface is perfectly fine. The semantic for your >lower level interconnect interface is simple, clear and does not modify the >send buffer. (for the cases where actually you need to cast the const away) > >Thanks, >.Erez > >-----Original Message----- >From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_lists.mpi- >forum.org] On Behalf Of Barrett, Brian W >Sent: Friday, March 13, 2009 11:36 AM >To: MPI 2.2 >Subject: Re: [Mpi-22] Ticket #46: Addconst Keyword to the C bindings- >implementation > >All - > >I spent some time looking at what it would take to implement this proposal >in Open MPI as well as the changes made in the MPICH2 implementation. I >think both raise some concerns for this proposal, particularly for MPI 2.2. > >The diff for the proposal was almost 10,000 lines long, which is a little >frightening for 2.2 change. However, the places the constness is cast away >for the send buffer raises some issues. In particular, for eager, >contiguous sends, the send buffer constness is cast away in MPID_Send, >which is the second call in the send call stack. Since there has been much >discussion about how the constness of a buffer shouldn't be cast away at >the upper layers of the MPI implementation, it seems problematic that the >reference implementation does just that. It seems problematic not because >of the choice made by the implementors of the patch, but because it is not >clear that the is really a better implementation option. Of course, the >choice of how to handle non-contiguous data raises some issues for Open >MPI's internals. > >Open MPI's low layer communication interface is based on a iovec-like >interface. Like most interfaces, the iovec-like interface is shared >between the send and receive calls. The iovec structure can not be const, >meaning that we are faced with two choices. We can either cast away the >const interface before this low-level interface or we can create two data >structures, one for send and one fore receive. The const cast option >obviously has its problems. The two data structure option is certainly not >appealing for us from a code maintainability stand-point. This is further >complicated by the fact that almost none of the transports Open MPI >currently supports can be used without casting away the constness. > >I understand that it would be good to promote the use of const for send >buffers in lower-level middleware, as well as the fact that not all MPI >implementations have such middleware. However, many interfaces have a >similar iovec issue to Open MPI, and they'll be unlike to change. The fact >that we will permanently be casting away const is slightly bothersome to me. >I think given these issues and the large size of the change, pushing this >proposal to 3.0 would be appropriate. > >Brian > >________________________________________ >From: mpi-22-bounces_at_[hidden] [mpi-22-bounces_at_lists.mpi- >forum.org] On Behalf Of Erez Haba [erezh_at_[hidden]] >Sent: Friday, March 13, 2009 10:40 AM >To: MPI 2.2 >Subject: Re: [Mpi-22] Ticket #46: Addconst Keyword to the C bindings- >implementation > >Hi Jeff, > >The point of this ticket is to present a consistent const correct interface >to the programmer and hide all the idiosyncrasies of the down-level >interfaces. > >That said, to answer your questions: > >No casting is required for: >* shared memory >* sockets (TCP) when using 'send()' (single buffer passed in) > >Casting is required for interfaces that did not define their io vector >buffer member as const. (an interface would need to define two io vector >structures, one with const buffer for send and one with non-const for >receive; most of them don't). > >Thus, casting is required when using the scatter/gather io vector with >* sockets (TC) >* Network Direct (IB and iWarp) > >With MPICH2 implementation, casting out the const for the send buffer when >using these interfaces was there all along as (most of) MPICH2 internal >functions already used const to pass the send buffer. No new cast was >required in this full const implementation. > > >Again, casting away the const to use the lower level interface does not >violate any const rules as long as the semantic is preserved. > >Thanks, >.Erez > > >-----Original Message----- >From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_lists.mpi- >forum.org] On Behalf Of Jeff Squyres >Sent: Friday, March 13, 2009 6:05 AM >To: MPI 2.2 >Subject: Re: [Mpi-22] Ticket #46: Addconst Keyword to the C bindings- >implementation > >Do you end up casting away the const when invoking the Windows network >interfaces? > >On Linux, I think the following interfaces would require casting the >const away: > >- shared memory (even using Linux vmsplice()) >- MX >- TCP >- OpenFabrics (both verbs and udapl) > >These interfaces do not require casting away const: > >- SCTP (I *think* -- I'm not an SCTP expert, but a quick look in >sctp.h showed a "const" argument for the sctp_sendmsg() function) > >I can't check these offhand: > >- Portals >- Elan > > > >On Mar 12, 2009, at 6:06 PM, Erez Haba wrote: > >> I urge you, please read the ticket proposal again. It discusses the >> merit of this proposal. >> >> As for IB; yes you'd copy small messages (which const is fine with) >> and some implement RDMA read or write for large messages; you might >> need to cast the const away if your IB interface does not expose >> const SGE's. >> >> As for the compiler; no you are not violating the contact; >> (otherwise we wouldn't have casts); as long as you guarantee that >> you are not changing the buffer. It's a way for the programmer to >> use old, non const correct, interfaces. >> >> .Erez >> >> -----Original Message----- >> From: mpi-22-bounces_at_[hidden] [mailto:mpi-22- >bounces_at_[hidden] >> ] On Behalf Of Underwood, Keith D >> Sent: Thursday, March 12, 2009 2:03 PM >> To: MPI 2.2 >> Subject: Re: [Mpi-22] Ticket #46: Add const Keyword to the C >> bindings- implementation >> >> I didn't think that typical MPI implementations over IB copied the >> data for large messages (as opposed to the bounce buffers for small >> messages). >> >> If you are going to have to cast away the const, what is the point >> of putting it in? In fact, if you have to cast away the const, >> aren't you violating your contract with the compiler? Should this >> change be rolled out from the bottom up? i.e. common low-level APIs >> first and then MPI? >> >> Keith >> >> >-----Original Message----- >> >From: mpi-22-bounces_at_[hidden] [mailto:mpi-22- >bounces_at_lists.mpi- >> >forum.org] On Behalf Of Erez Haba >> >Sent: Thursday, March 12, 2009 2:10 PM >> >To: MPI 2.2 >> >Subject: Re: [Mpi-22] Ticket #46: Add const Keyword to the C >> bindings- >> >implementation >> > >> >Possibly you'll have to cast. >> >There are few interfaces that take const for send buffer (like >> sockets). >> >In other cases you copy the buffer (like with IB) which keeps the >> const >> >property. >> > >> >Thanks, >> >.Erez >> > >> >-----Original Message----- >> >From: mpi-22-bounces_at_[hidden] [mailto:mpi-22- >bounces_at_lists.mpi- >> >forum.org] On Behalf Of Underwood, Keith D >> >Sent: Thursday, March 12, 2009 12:05 PM >> >To: MPI 2.2 >> >Subject: Re: [Mpi-22] Ticket #46: Add const Keyword to the C >> bindings- >> >implementation >> > >> >It would seem like const would eventually have to be cast away for >> most >> >lower level interfaces. Portals, Elan, IB Verbs, and as best I can >> tell MX >> >don't have const on their send buffers... >> > >> >Keith >> > >> >>-----Original Message----- >> >>From: mpi-22-bounces_at_[hidden] [mailto:mpi-22- >bounces_at_lists.mpi- >> >>forum.org] On Behalf Of Erez Haba >> >>Sent: Thursday, March 12, 2009 12:44 PM >> >>To: MPI 2.2 >> >>Subject: Re: [Mpi-22] Ticket #46: Add const Keyword to the C >> bindings- >> >>implementation >> >> >> >>No, it's not being cast away (although it is a quick way for you to >> >>implement it). >> >>In MPICH2 implementation it trickles down to the lower functions. >> There >> >are >> >>very few places where the const is being cast away because ticket >> #46 does >> >>not to break backward compatibility. >> >>For example, when the user function is called (const was not added >> to the >> >>MPI_User_function) the implementation must cast away const from >> the send >> >>buffer before calling the user function. >> >> >> >>Thanks, >> >>.Erez >> >> >> >>-----Original Message----- >> >>From: mpi-22-bounces_at_[hidden] [mailto:mpi-22- >bounces_at_lists.mpi- >> >>forum.org] On Behalf Of Jeff Squyres >> >>Sent: Thursday, March 12, 2009 11:34 AM >> >>To: MPI 2.2 >> >>Subject: Re: [Mpi-22] Ticket #46: Add const Keyword to the C >> bindings- >> >>implementation >> >> >> >>More importantly, how is const handled? Is it just cast away inside >> >>the MPI library? >> >> >> >> >> >>On Mar 12, 2009, at 2:34 PM, Underwood, Keith D wrote: >> >> >> >>> Since the main purpose of an implementation for something like >> >>> adding const is to see how invasive the change is, would it be >> >>> possible to get a diff against the trees that these were created >> from? >> >>> >> >>> Thanks, >> >>> Keith >> >>> >> >>> From: mpi-22-bounces_at_[hidden] [mailto:mpi-22- >> >>bounces_at_[hidden] >> >>> ] On Behalf Of Erez Haba >> >>> Sent: Thursday, March 12, 2009 12:24 PM >> >>> To: MPI 2.2 >> >>> Subject: [Mpi-22] Ticket #46: Add const Keyword to the C >> bindings - >> >>> implementation >> >>> >> >>> >> >>> Implementation for ticket #46 is now available from ANL (thanks >> Pavan) >> >>> >> >>> >> >>> tarballs >> >>> >> >>>http://www.mcs.anl.gov/research/projects/mpich2/downloads/tarballs/nightl >y >> >/ >> >>const >> >>> >> >>> >> >>> thanks, >> >>> .Erez >> >>> >> >>> _______________________________________________ >> >>> mpi-22 mailing list >> >>> mpi-22_at_[hidden] >> >>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 >> >> >> >> >> >>-- >> >>Jeff Squyres >> >>Cisco Systems >> >> >> >>_______________________________________________ >> >>mpi-22 mailing list >> >>mpi-22_at_[hidden] >> >>http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 >> >> >> >> >> >>_______________________________________________ >> >>mpi-22 mailing list >> >>mpi-22_at_[hidden] >> >>http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 >> > >> >_______________________________________________ >> >mpi-22 mailing list >> >mpi-22_at_[hidden] >> >http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 >> > >> > >> >_______________________________________________ >> >mpi-22 mailing list >> >mpi-22_at_[hidden] >> >http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 >> >> _______________________________________________ >> mpi-22 mailing list >> mpi-22_at_[hidden] >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 >> >> >> _______________________________________________ >> mpi-22 mailing list >> mpi-22_at_[hidden] >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 > > >-- >Jeff Squyres >Cisco Systems > >_______________________________________________ >mpi-22 mailing list >mpi-22_at_[hidden] >http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 > > >_______________________________________________ >mpi-22 mailing list >mpi-22_at_[hidden] >http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 > > > >_______________________________________________ >mpi-22 mailing list >mpi-22_at_[hidden] >http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 > > >_______________________________________________ >mpi-22 mailing list >mpi-22_at_[hidden] >http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 > > >_______________________________________________ >mpi-22 mailing list >mpi-22_at_[hidden] >http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 _______________________________________________ mpi-22 mailing list mpi-22_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 From wgropp at [hidden] Sun Mar 15 15:59:04 2009 From: wgropp at [hidden] (William Gropp) Date: Sun, 15 Mar 2009 15:59:04 -0500 Subject: [Mpi-22] Ticket #46: Add const Keyword to the C bindings-implementation In-Reply-To: Message-ID: Actually, MPI has taken the lead in a number of areas, including cross- language compatibility, to say nothing of the existence of MPI itself. And MPI has taken great pains to be the *greatest* common denominator. Const simply captures the previously required semantics of the interface in the syntax, and is consistent with the MPI spirit. Bill On Mar 13, 2009, at 2:17 PM, Jeff Squyres wrote: > On Mar 13, 2009, at 9:40 AM, William Gropp wrote: > >> First, this is a chicken-and-egg problem; the low level >> interfaces are unlikely to change to add const unless there is some >> application that will take advantage of that (and internally, if >> their >> semantics allows it and their compiler can support it, they'll just >> cast to add the const). So MPI should take the lead, particularly >> since using const also provides information to the user. >> > > This is a very scary statement to me. MPI has not traditionally > "taken the lead" on forcing issues with other interfaces (look where > it has gotten us with Fortran...). Indeed, MPI has taken great pains > to be the lowest common denominator across a variety of language, > platforms, and operating systems. > > -- > Jeff Squyres > Cisco Systems > > _______________________________________________ > mpi-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 William Gropp Deputy Director for Research Institute for Advanced Computing Applications and Technologies Paul and Cynthia Saylor Professor of Computer Science University of Illinois Urbana-Champaign From alexander.supalov at [hidden] Mon Mar 16 05:42:57 2009 From: alexander.supalov at [hidden] (Supalov, Alexander) Date: Mon, 16 Mar 2009 10:42:57 +0000 Subject: [Mpi-22] Ticket #46: Add const Keyword to the C bindings-implementation In-Reply-To: Message-ID: <928CFBE8E7CB0040959E56B4EA41A77E4A663973@irsmsx504.ger.corp.intel.com> Hi, I most respectively disagree with the "Const simply captures the previously required semantics of the interface in the syntax" statement. The standard did not prohibit a reversible in-place modification of the send buffer until the very recent change related to #45. Adding const on top will automatically make MPI not the greatest common denominator - some internal networking interfaces that were mentioned in this trail will suddenly become "obsolete". That is, most of the existing networking interfaces will. Best regards. Alexander -----Original Message----- From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of William Gropp Sent: Sunday, March 15, 2009 9:59 PM To: MPI 2.2 Subject: Re: [Mpi-22] Ticket #46: Add const Keyword to the C bindings-implementation Actually, MPI has taken the lead in a number of areas, including cross- language compatibility, to say nothing of the existence of MPI itself. And MPI has taken great pains to be the *greatest* common denominator. Const simply captures the previously required semantics of the interface in the syntax, and is consistent with the MPI spirit. Bill On Mar 13, 2009, at 2:17 PM, Jeff Squyres wrote: > On Mar 13, 2009, at 9:40 AM, William Gropp wrote: > >> First, this is a chicken-and-egg problem; the low level >> interfaces are unlikely to change to add const unless there is some >> application that will take advantage of that (and internally, if >> their >> semantics allows it and their compiler can support it, they'll just >> cast to add the const). So MPI should take the lead, particularly >> since using const also provides information to the user. >> > > This is a very scary statement to me. MPI has not traditionally > "taken the lead" on forcing issues with other interfaces (look where > it has gotten us with Fortran...). Indeed, MPI has taken great pains > to be the lowest common denominator across a variety of language, > platforms, and operating systems. > > -- > Jeff Squyres > Cisco Systems > > _______________________________________________ > mpi-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 William Gropp Deputy Director for Research Institute for Advanced Computing Applications and Technologies Paul and Cynthia Saylor Professor of Computer Science University of Illinois Urbana-Champaign _______________________________________________ mpi-22 mailing list mpi-22_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 --------------------------------------------------------------------- Intel GmbH Dornacher Strasse 1 85622 Feldkirchen/Muenchen Germany Sitz der Gesellschaft: Feldkirchen bei Muenchen Geschaeftsfuehrer: Douglas Lusk, Peter Gleissner, Hannes Schwaderer Registergericht: Muenchen HRB 47456 Ust.-IdNr. VAT Registration No.: DE129385895 Citibank Frankfurt (BLZ 502 109 00) 600119052 This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. From erezh at [hidden] Mon Mar 16 05:53:26 2009 From: erezh at [hidden] (Erez Haba) Date: Mon, 16 Mar 2009 03:53:26 -0700 Subject: [Mpi-22] Ticket #46: Add const Keyword to the C bindings-implementation In-Reply-To: <928CFBE8E7CB0040959E56B4EA41A77E4A663973@irsmsx504.ger.corp.intel.com> Message-ID: <6B68D01C00C9994A8E150183E62A119E7B732E19CD@NA-EXMSG-C105.redmond.corp.microsoft.com> Dear Alexander, Your claim that the const keyword might render some internal networking interfaces as "obsolete" is not correct. The const keyword has no effect on how relevant the network interface is. You probably mean that ticket #45 (send buffer) might render these interfaces as obsolete, and that would be a correct claim for those network interfaces that modify the send buffer. Thanks, .Erez -----Original Message----- From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Supalov, Alexander Sent: Monday, March 16, 2009 3:43 AM To: MPI 2.2 Subject: Re: [Mpi-22] Ticket #46: Add const Keyword to the C bindings-implementation Hi, I most respectively disagree with the "Const simply captures the previously required semantics of the interface in the syntax" statement. The standard did not prohibit a reversible in-place modification of the send buffer until the very recent change related to #45. Adding const on top will automatically make MPI not the greatest common denominator - some internal networking interfaces that were mentioned in this trail will suddenly become "obsolete". That is, most of the existing networking interfaces will. Best regards. Alexander -----Original Message----- From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of William Gropp Sent: Sunday, March 15, 2009 9:59 PM To: MPI 2.2 Subject: Re: [Mpi-22] Ticket #46: Add const Keyword to the C bindings-implementation Actually, MPI has taken the lead in a number of areas, including cross- language compatibility, to say nothing of the existence of MPI itself. And MPI has taken great pains to be the *greatest* common denominator. Const simply captures the previously required semantics of the interface in the syntax, and is consistent with the MPI spirit. Bill On Mar 13, 2009, at 2:17 PM, Jeff Squyres wrote: > On Mar 13, 2009, at 9:40 AM, William Gropp wrote: > >> First, this is a chicken-and-egg problem; the low level >> interfaces are unlikely to change to add const unless there is some >> application that will take advantage of that (and internally, if >> their >> semantics allows it and their compiler can support it, they'll just >> cast to add the const). So MPI should take the lead, particularly >> since using const also provides information to the user. >> > > This is a very scary statement to me. MPI has not traditionally > "taken the lead" on forcing issues with other interfaces (look where > it has gotten us with Fortran...). Indeed, MPI has taken great pains > to be the lowest common denominator across a variety of language, > platforms, and operating systems. > > -- > Jeff Squyres > Cisco Systems > > _______________________________________________ > mpi-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 William Gropp Deputy Director for Research Institute for Advanced Computing Applications and Technologies Paul and Cynthia Saylor Professor of Computer Science University of Illinois Urbana-Champaign _______________________________________________ mpi-22 mailing list mpi-22_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 --------------------------------------------------------------------- Intel GmbH Dornacher Strasse 1 85622 Feldkirchen/Muenchen Germany Sitz der Gesellschaft: Feldkirchen bei Muenchen Geschaeftsfuehrer: Douglas Lusk, Peter Gleissner, Hannes Schwaderer Registergericht: Muenchen HRB 47456 Ust.-IdNr. VAT Registration No.: DE129385895 Citibank Frankfurt (BLZ 502 109 00) 600119052 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-22 mailing list mpi-22_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 From alexander.supalov at [hidden] Mon Mar 16 06:22:23 2009 From: alexander.supalov at [hidden] (Supalov, Alexander) Date: Mon, 16 Mar 2009 11:22:23 +0000 Subject: [Mpi-22] Ticket #46: Add const Keyword to the C bindings-implementation In-Reply-To: <6B68D01C00C9994A8E150183E62A119E7B732E19CD@NA-EXMSG-C105.redmond.corp.microsoft.com> Message-ID: <928CFBE8E7CB0040959E56B4EA41A77E4A6639F0@irsmsx504.ger.corp.intel.com> Dear Erez, Thanks. Before this becomes too involved, let's untangle this a little. There are three topics here: 1. The send buffer change (#45). 2. The const pointer modifier (#46). 3. Bill's claim that 2. "simply captures the previously required semantics of the interface in the syntax". My message contained two statements: A. I said that 2. can only be understood in relation to 1. rather than the existing standard (say, MPI 2.1). I doubt this can be refuted. The old standard did allow in-place buffer changes. This would be impossible with the const buffer modifier. Hence my statement. B. Now, at least for me, 2. simply seals 1. This is why I said that this will make interfaces "obsolete". You object to this. Here's my reasoning: if I have to cast the const away on a lower level interface to make use of the MPI buffer, I surely have an issue. The issue is that the new MPI interface advanced ahead of my lower level networking interface. Thus, from the point of view of the MPI interface, the respective lower level interface becomes "obsolete". Hence my claim and hence the quotes - to point out that this is only MPI POV. Note that this is, in essence, only a negative rewording of Bill's "MPI should take the lead" clause. I doubt this can be refuted either. Finally, you added that 1. makes some networking interfaces "obsolete". Taking into account A. and B. above, I think we're in violent agreement: both 1. and 2. make MPI lead, or, in other words, make many networking interfaces "obsolete" from the MPI POV. This is very brave on part of the MPI standard. Let's see what happens next. Best regards. Alexander -----Original Message----- From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Erez Haba Sent: Monday, March 16, 2009 11:53 AM To: MPI 2.2 Subject: Re: [Mpi-22] Ticket #46: Add const Keyword to the C bindings-implementation Dear Alexander, Your claim that the const keyword might render some internal networking interfaces as "obsolete" is not correct. The const keyword has no effect on how relevant the network interface is. You probably mean that ticket #45 (send buffer) might render these interfaces as obsolete, and that would be a correct claim for those network interfaces that modify the send buffer. Thanks, .Erez -----Original Message----- From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Supalov, Alexander Sent: Monday, March 16, 2009 3:43 AM To: MPI 2.2 Subject: Re: [Mpi-22] Ticket #46: Add const Keyword to the C bindings-implementation Hi, I most respectively disagree with the "Const simply captures the previously required semantics of the interface in the syntax" statement. The standard did not prohibit a reversible in-place modification of the send buffer until the very recent change related to #45. Adding const on top will automatically make MPI not the greatest common denominator - some internal networking interfaces that were mentioned in this trail will suddenly become "obsolete". That is, most of the existing networking interfaces will. Best regards. Alexander -----Original Message----- From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of William Gropp Sent: Sunday, March 15, 2009 9:59 PM To: MPI 2.2 Subject: Re: [Mpi-22] Ticket #46: Add const Keyword to the C bindings-implementation Actually, MPI has taken the lead in a number of areas, including cross- language compatibility, to say nothing of the existence of MPI itself. And MPI has taken great pains to be the *greatest* common denominator. Const simply captures the previously required semantics of the interface in the syntax, and is consistent with the MPI spirit. Bill On Mar 13, 2009, at 2:17 PM, Jeff Squyres wrote: > On Mar 13, 2009, at 9:40 AM, William Gropp wrote: > >> First, this is a chicken-and-egg problem; the low level >> interfaces are unlikely to change to add const unless there is some >> application that will take advantage of that (and internally, if >> their >> semantics allows it and their compiler can support it, they'll just >> cast to add the const). So MPI should take the lead, particularly >> since using const also provides information to the user. >> > > This is a very scary statement to me. MPI has not traditionally > "taken the lead" on forcing issues with other interfaces (look where > it has gotten us with Fortran...). Indeed, MPI has taken great pains > to be the lowest common denominator across a variety of language, > platforms, and operating systems. > > -- > Jeff Squyres > Cisco Systems > > _______________________________________________ > mpi-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 William Gropp Deputy Director for Research Institute for Advanced Computing Applications and Technologies Paul and Cynthia Saylor Professor of Computer Science University of Illinois Urbana-Champaign _______________________________________________ mpi-22 mailing list mpi-22_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 --------------------------------------------------------------------- Intel GmbH Dornacher Strasse 1 85622 Feldkirchen/Muenchen Germany Sitz der Gesellschaft: Feldkirchen bei Muenchen Geschaeftsfuehrer: Douglas Lusk, Peter Gleissner, Hannes Schwaderer Registergericht: Muenchen HRB 47456 Ust.-IdNr. VAT Registration No.: DE129385895 Citibank Frankfurt (BLZ 502 109 00) 600119052 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-22 mailing list mpi-22_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 _______________________________________________ mpi-22 mailing list mpi-22_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 --------------------------------------------------------------------- Intel GmbH Dornacher Strasse 1 85622 Feldkirchen/Muenchen Germany Sitz der Gesellschaft: Feldkirchen bei Muenchen Geschaeftsfuehrer: Douglas Lusk, Peter Gleissner, Hannes Schwaderer Registergericht: Muenchen HRB 47456 Ust.-IdNr. VAT Registration No.: DE129385895 Citibank Frankfurt (BLZ 502 109 00) 600119052 This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. From erezh at [hidden] Mon Mar 16 12:21:48 2009 From: erezh at [hidden] (Erez Haba) Date: Mon, 16 Mar 2009 10:21:48 -0700 Subject: [Mpi-22] Ticket #46: Add const Keyword to the C bindings-implementation In-Reply-To: <928CFBE8E7CB0040959E56B4EA41A77E4A6639F0@irsmsx504.ger.corp.intel.com> Message-ID: <6B68D01C00C9994A8E150183E62A119E7B732E1B08@NA-EXMSG-C105.redmond.corp.microsoft.com> Yes, I think we agree. Let me rephrase. With ticket #45 (send buffer access) being accepted, adding the const keyword does make any network interface more "obsolete" or less "obsolete". Thanks, .Erez -----Original Message----- From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Supalov, Alexander Sent: Monday, March 16, 2009 4:22 AM To: MPI 2.2 Subject: Re: [Mpi-22] Ticket #46: Add const Keyword to the C bindings-implementation Dear Erez, Thanks. Before this becomes too involved, let's untangle this a little. There are three topics here: 1. The send buffer change (#45). 2. The const pointer modifier (#46). 3. Bill's claim that 2. "simply captures the previously required semantics of the interface in the syntax". My message contained two statements: A. I said that 2. can only be understood in relation to 1. rather than the existing standard (say, MPI 2.1). I doubt this can be refuted. The old standard did allow in-place buffer changes. This would be impossible with the const buffer modifier. Hence my statement. B. Now, at least for me, 2. simply seals 1. This is why I said that this will make interfaces "obsolete". You object to this. Here's my reasoning: if I have to cast the const away on a lower level interface to make use of the MPI buffer, I surely have an issue. The issue is that the new MPI interface advanced ahead of my lower level networking interface. Thus, from the point of view of the MPI interface, the respective lower level interface becomes "obsolete". Hence my claim and hence the quotes - to point out that this is only MPI POV. Note that this is, in essence, only a negative rewording of Bill's "MPI should take the lead" clause. I doubt this can be refuted either. Finally, you added that 1. makes some networking interfaces "obsolete". Taking into account A. and B. above, I think we're in violent agreement: both 1. and 2. make MPI lead, or, in other words, make many networking interfaces "obsolete" from the MPI POV. This is very brave on part of the MPI standard. Let's see what happens next. Best regards. Alexander -----Original Message----- From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Erez Haba Sent: Monday, March 16, 2009 11:53 AM To: MPI 2.2 Subject: Re: [Mpi-22] Ticket #46: Add const Keyword to the C bindings-implementation Dear Alexander, Your claim that the const keyword might render some internal networking interfaces as "obsolete" is not correct. The const keyword has no effect on how relevant the network interface is. You probably mean that ticket #45 (send buffer) might render these interfaces as obsolete, and that would be a correct claim for those network interfaces that modify the send buffer. Thanks, .Erez -----Original Message----- From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Supalov, Alexander Sent: Monday, March 16, 2009 3:43 AM To: MPI 2.2 Subject: Re: [Mpi-22] Ticket #46: Add const Keyword to the C bindings-implementation Hi, I most respectively disagree with the "Const simply captures the previously required semantics of the interface in the syntax" statement. The standard did not prohibit a reversible in-place modification of the send buffer until the very recent change related to #45. Adding const on top will automatically make MPI not the greatest common denominator - some internal networking interfaces that were mentioned in this trail will suddenly become "obsolete". That is, most of the existing networking interfaces will. Best regards. Alexander -----Original Message----- From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of William Gropp Sent: Sunday, March 15, 2009 9:59 PM To: MPI 2.2 Subject: Re: [Mpi-22] Ticket #46: Add const Keyword to the C bindings-implementation Actually, MPI has taken the lead in a number of areas, including cross- language compatibility, to say nothing of the existence of MPI itself. And MPI has taken great pains to be the *greatest* common denominator. Const simply captures the previously required semantics of the interface in the syntax, and is consistent with the MPI spirit. Bill On Mar 13, 2009, at 2:17 PM, Jeff Squyres wrote: > On Mar 13, 2009, at 9:40 AM, William Gropp wrote: > >> First, this is a chicken-and-egg problem; the low level >> interfaces are unlikely to change to add const unless there is some >> application that will take advantage of that (and internally, if >> their >> semantics allows it and their compiler can support it, they'll just >> cast to add the const). So MPI should take the lead, particularly >> since using const also provides information to the user. >> > > This is a very scary statement to me. MPI has not traditionally > "taken the lead" on forcing issues with other interfaces (look where > it has gotten us with Fortran...). Indeed, MPI has taken great pains > to be the lowest common denominator across a variety of language, > platforms, and operating systems. > > -- > Jeff Squyres > Cisco Systems > > _______________________________________________ > mpi-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 William Gropp Deputy Director for Research Institute for Advanced Computing Applications and Technologies Paul and Cynthia Saylor Professor of Computer Science University of Illinois Urbana-Champaign _______________________________________________ mpi-22 mailing list mpi-22_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 --------------------------------------------------------------------- Intel GmbH Dornacher Strasse 1 85622 Feldkirchen/Muenchen Germany Sitz der Gesellschaft: Feldkirchen bei Muenchen Geschaeftsfuehrer: Douglas Lusk, Peter Gleissner, Hannes Schwaderer Registergericht: Muenchen HRB 47456 Ust.-IdNr. VAT Registration No.: DE129385895 Citibank Frankfurt (BLZ 502 109 00) 600119052 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-22 mailing list mpi-22_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 _______________________________________________ mpi-22 mailing list mpi-22_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 --------------------------------------------------------------------- Intel GmbH Dornacher Strasse 1 85622 Feldkirchen/Muenchen Germany Sitz der Gesellschaft: Feldkirchen bei Muenchen Geschaeftsfuehrer: Douglas Lusk, Peter Gleissner, Hannes Schwaderer Registergericht: Muenchen HRB 47456 Ust.-IdNr. VAT Registration No.: DE129385895 Citibank Frankfurt (BLZ 502 109 00) 600119052 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-22 mailing list mpi-22_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 From david.gingold at [hidden] Mon Mar 16 16:36:17 2009 From: david.gingold at [hidden] (David Gingold) Date: Mon, 16 Mar 2009 17:36:17 -0400 Subject: [Mpi-22] Ticket #46: Addconst Keyword to the C bindings- implementation In-Reply-To: <49BAB658.3000407@mcs.anl.gov> Message-ID: <2BDDB0D7-346E-4DD4-95A0-BD4B756ECC2D@sicortex.com> Speaking for the SiCortex MPI implementation (which is a derivative of MPICH2): I expect that implementing the const proposal will be straightforward in our case. Our MPID implementation already uses const when referring to send buffers, and casting is not necessary for software layers below that. If we need to demonstrate another implementation of this, I can attempt to apply the MPICH2 patch to our sources. But I don't expect to learn anything from doing that, as all the complexity should be in getting the patch to apply. SiCortex supports this proposal for 2.2. -dg -- David Gingold Principal Software Engineer SiCortex Three Clock Tower Place, Suite 210 Maynard MA 01754 (978) 897-0214 x224 * -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander.supalov at [hidden] Mon Mar 16 16:37:03 2009 From: alexander.supalov at [hidden] (Supalov, Alexander) Date: Mon, 16 Mar 2009 21:37:03 +0000 Subject: [Mpi-22] Ticket #46: Add const Keyword to the C bindings-implementation In-Reply-To: <6B68D01C00C9994A8E150183E62A119E7B732E1B08@NA-EXMSG-C105.redmond.corp.microsoft.com> Message-ID: <928CFBE8E7CB0040959E56B4EA41A77E4A663ED3@irsmsx504.ger.corp.intel.com> Thanks. What does it mean here, "more "obsolete" or less "obsolete""? Did you mean "more "obsolete" or less "advanced""? -----Original Message----- From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Erez Haba Sent: Monday, March 16, 2009 6:22 PM To: MPI 2.2 Subject: Re: [Mpi-22] Ticket #46: Add const Keyword to the C bindings-implementation Yes, I think we agree. Let me rephrase. With ticket #45 (send buffer access) being accepted, adding the const keyword does make any network interface more "obsolete" or less "obsolete". Thanks, .Erez -----Original Message----- From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Supalov, Alexander Sent: Monday, March 16, 2009 4:22 AM To: MPI 2.2 Subject: Re: [Mpi-22] Ticket #46: Add const Keyword to the C bindings-implementation Dear Erez, Thanks. Before this becomes too involved, let's untangle this a little. There are three topics here: 1. The send buffer change (#45). 2. The const pointer modifier (#46). 3. Bill's claim that 2. "simply captures the previously required semantics of the interface in the syntax". My message contained two statements: A. I said that 2. can only be understood in relation to 1. rather than the existing standard (say, MPI 2.1). I doubt this can be refuted. The old standard did allow in-place buffer changes. This would be impossible with the const buffer modifier. Hence my statement. B. Now, at least for me, 2. simply seals 1. This is why I said that this will make interfaces "obsolete". You object to this. Here's my reasoning: if I have to cast the const away on a lower level interface to make use of the MPI buffer, I surely have an issue. The issue is that the new MPI interface advanced ahead of my lower level networking interface. Thus, from the point of view of the MPI interface, the respective lower level interface becomes "obsolete". Hence my claim and hence the quotes - to point out that this is only MPI POV. Note that this is, in essence, only a negative rewording of Bill's "MPI should take the lead" clause. I doubt this can be refuted either. Finally, you added that 1. makes some networking interfaces "obsolete". Taking into account A. and B. above, I think we're in violent agreement: both 1. and 2. make MPI lead, or, in other words, make many networking interfaces "obsolete" from the MPI POV. This is very brave on part of the MPI standard. Let's see what happens next. Best regards. Alexander -----Original Message----- From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Erez Haba Sent: Monday, March 16, 2009 11:53 AM To: MPI 2.2 Subject: Re: [Mpi-22] Ticket #46: Add const Keyword to the C bindings-implementation Dear Alexander, Your claim that the const keyword might render some internal networking interfaces as "obsolete" is not correct. The const keyword has no effect on how relevant the network interface is. You probably mean that ticket #45 (send buffer) might render these interfaces as obsolete, and that would be a correct claim for those network interfaces that modify the send buffer. Thanks, .Erez -----Original Message----- From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Supalov, Alexander Sent: Monday, March 16, 2009 3:43 AM To: MPI 2.2 Subject: Re: [Mpi-22] Ticket #46: Add const Keyword to the C bindings-implementation Hi, I most respectively disagree with the "Const simply captures the previously required semantics of the interface in the syntax" statement. The standard did not prohibit a reversible in-place modification of the send buffer until the very recent change related to #45. Adding const on top will automatically make MPI not the greatest common denominator - some internal networking interfaces that were mentioned in this trail will suddenly become "obsolete". That is, most of the existing networking interfaces will. Best regards. Alexander -----Original Message----- From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of William Gropp Sent: Sunday, March 15, 2009 9:59 PM To: MPI 2.2 Subject: Re: [Mpi-22] Ticket #46: Add const Keyword to the C bindings-implementation Actually, MPI has taken the lead in a number of areas, including cross- language compatibility, to say nothing of the existence of MPI itself. And MPI has taken great pains to be the *greatest* common denominator. Const simply captures the previously required semantics of the interface in the syntax, and is consistent with the MPI spirit. Bill On Mar 13, 2009, at 2:17 PM, Jeff Squyres wrote: > On Mar 13, 2009, at 9:40 AM, William Gropp wrote: > >> First, this is a chicken-and-egg problem; the low level >> interfaces are unlikely to change to add const unless there is some >> application that will take advantage of that (and internally, if >> their >> semantics allows it and their compiler can support it, they'll just >> cast to add the const). So MPI should take the lead, particularly >> since using const also provides information to the user. >> > > This is a very scary statement to me. MPI has not traditionally > "taken the lead" on forcing issues with other interfaces (look where > it has gotten us with Fortran...). Indeed, MPI has taken great pains > to be the lowest common denominator across a variety of language, > platforms, and operating systems. > > -- > Jeff Squyres > Cisco Systems > > _______________________________________________ > mpi-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 William Gropp Deputy Director for Research Institute for Advanced Computing Applications and Technologies Paul and Cynthia Saylor Professor of Computer Science University of Illinois Urbana-Champaign _______________________________________________ mpi-22 mailing list mpi-22_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 --------------------------------------------------------------------- Intel GmbH Dornacher Strasse 1 85622 Feldkirchen/Muenchen Germany Sitz der Gesellschaft: Feldkirchen bei Muenchen Geschaeftsfuehrer: Douglas Lusk, Peter Gleissner, Hannes Schwaderer Registergericht: Muenchen HRB 47456 Ust.-IdNr. VAT Registration No.: DE129385895 Citibank Frankfurt (BLZ 502 109 00) 600119052 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-22 mailing list mpi-22_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 _______________________________________________ mpi-22 mailing list mpi-22_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 --------------------------------------------------------------------- Intel GmbH Dornacher Strasse 1 85622 Feldkirchen/Muenchen Germany Sitz der Gesellschaft: Feldkirchen bei Muenchen Geschaeftsfuehrer: Douglas Lusk, Peter Gleissner, Hannes Schwaderer Registergericht: Muenchen HRB 47456 Ust.-IdNr. VAT Registration No.: DE129385895 Citibank Frankfurt (BLZ 502 109 00) 600119052 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-22 mailing list mpi-22_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 _______________________________________________ mpi-22 mailing list mpi-22_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 --------------------------------------------------------------------- Intel GmbH Dornacher Strasse 1 85622 Feldkirchen/Muenchen Germany Sitz der Gesellschaft: Feldkirchen bei Muenchen Geschaeftsfuehrer: Douglas Lusk, Peter Gleissner, Hannes Schwaderer Registergericht: Muenchen HRB 47456 Ust.-IdNr. VAT Registration No.: DE129385895 Citibank Frankfurt (BLZ 502 109 00) 600119052 This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. From erezh at [hidden] Mon Mar 16 16:48:18 2009 From: erezh at [hidden] (Erez Haba) Date: Mon, 16 Mar 2009 14:48:18 -0700 Subject: [Mpi-22] Ticket #46: Add const Keyword to the C bindings-implementation In-Reply-To: <928CFBE8E7CB0040959E56B4EA41A77E4A663ED3@irsmsx504.ger.corp.intel.com> Message-ID: <6B68D01C00C9994A8E150183E62A119E7B732E1D11@NA-EXMSG-C105.redmond.corp.microsoft.com> It means that adding the const keyword is not relevant to the obsoleteness of the lower level interface (ticket #45 is). -----Original Message----- From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Supalov, Alexander Sent: Monday, March 16, 2009 2:37 PM To: MPI 2.2 Subject: Re: [Mpi-22] Ticket #46: Add const Keyword to the C bindings-implementation Thanks. What does it mean here, "more "obsolete" or less "obsolete""? Did you mean "more "obsolete" or less "advanced""? -----Original Message----- From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Erez Haba Sent: Monday, March 16, 2009 6:22 PM To: MPI 2.2 Subject: Re: [Mpi-22] Ticket #46: Add const Keyword to the C bindings-implementation Yes, I think we agree. Let me rephrase. With ticket #45 (send buffer access) being accepted, adding the const keyword does make any network interface more "obsolete" or less "obsolete". Thanks, .Erez -----Original Message----- From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Supalov, Alexander Sent: Monday, March 16, 2009 4:22 AM To: MPI 2.2 Subject: Re: [Mpi-22] Ticket #46: Add const Keyword to the C bindings-implementation Dear Erez, Thanks. Before this becomes too involved, let's untangle this a little. There are three topics here: 1. The send buffer change (#45). 2. The const pointer modifier (#46). 3. Bill's claim that 2. "simply captures the previously required semantics of the interface in the syntax". My message contained two statements: A. I said that 2. can only be understood in relation to 1. rather than the existing standard (say, MPI 2.1). I doubt this can be refuted. The old standard did allow in-place buffer changes. This would be impossible with the const buffer modifier. Hence my statement. B. Now, at least for me, 2. simply seals 1. This is why I said that this will make interfaces "obsolete". You object to this. Here's my reasoning: if I have to cast the const away on a lower level interface to make use of the MPI buffer, I surely have an issue. The issue is that the new MPI interface advanced ahead of my lower level networking interface. Thus, from the point of view of the MPI interface, the respective lower level interface becomes "obsolete". Hence my claim and hence the quotes - to point out that this is only MPI POV. Note that this is, in essence, only a negative rewording of Bill's "MPI should take the lead" clause. I doubt this can be refuted either. Finally, you added that 1. makes some networking interfaces "obsolete". Taking into account A. and B. above, I think we're in violent agreement: both 1. and 2. make MPI lead, or, in other words, make many networking interfaces "obsolete" from the MPI POV. This is very brave on part of the MPI standard. Let's see what happens next. Best regards. Alexander -----Original Message----- From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Erez Haba Sent: Monday, March 16, 2009 11:53 AM To: MPI 2.2 Subject: Re: [Mpi-22] Ticket #46: Add const Keyword to the C bindings-implementation Dear Alexander, Your claim that the const keyword might render some internal networking interfaces as "obsolete" is not correct. The const keyword has no effect on how relevant the network interface is. You probably mean that ticket #45 (send buffer) might render these interfaces as obsolete, and that would be a correct claim for those network interfaces that modify the send buffer. Thanks, .Erez -----Original Message----- From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Supalov, Alexander Sent: Monday, March 16, 2009 3:43 AM To: MPI 2.2 Subject: Re: [Mpi-22] Ticket #46: Add const Keyword to the C bindings-implementation Hi, I most respectively disagree with the "Const simply captures the previously required semantics of the interface in the syntax" statement. The standard did not prohibit a reversible in-place modification of the send buffer until the very recent change related to #45. Adding const on top will automatically make MPI not the greatest common denominator - some internal networking interfaces that were mentioned in this trail will suddenly become "obsolete". That is, most of the existing networking interfaces will. Best regards. Alexander -----Original Message----- From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of William Gropp Sent: Sunday, March 15, 2009 9:59 PM To: MPI 2.2 Subject: Re: [Mpi-22] Ticket #46: Add const Keyword to the C bindings-implementation Actually, MPI has taken the lead in a number of areas, including cross- language compatibility, to say nothing of the existence of MPI itself. And MPI has taken great pains to be the *greatest* common denominator. Const simply captures the previously required semantics of the interface in the syntax, and is consistent with the MPI spirit. Bill On Mar 13, 2009, at 2:17 PM, Jeff Squyres wrote: > On Mar 13, 2009, at 9:40 AM, William Gropp wrote: > >> First, this is a chicken-and-egg problem; the low level >> interfaces are unlikely to change to add const unless there is some >> application that will take advantage of that (and internally, if >> their >> semantics allows it and their compiler can support it, they'll just >> cast to add the const). So MPI should take the lead, particularly >> since using const also provides information to the user. >> > > This is a very scary statement to me. MPI has not traditionally > "taken the lead" on forcing issues with other interfaces (look where > it has gotten us with Fortran...). Indeed, MPI has taken great pains > to be the lowest common denominator across a variety of language, > platforms, and operating systems. > > -- > Jeff Squyres > Cisco Systems > > _______________________________________________ > mpi-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 William Gropp Deputy Director for Research Institute for Advanced Computing Applications and Technologies Paul and Cynthia Saylor Professor of Computer Science University of Illinois Urbana-Champaign _______________________________________________ mpi-22 mailing list mpi-22_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 --------------------------------------------------------------------- Intel GmbH Dornacher Strasse 1 85622 Feldkirchen/Muenchen Germany Sitz der Gesellschaft: Feldkirchen bei Muenchen Geschaeftsfuehrer: Douglas Lusk, Peter Gleissner, Hannes Schwaderer Registergericht: Muenchen HRB 47456 Ust.-IdNr. VAT Registration No.: DE129385895 Citibank Frankfurt (BLZ 502 109 00) 600119052 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-22 mailing list mpi-22_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 _______________________________________________ mpi-22 mailing list mpi-22_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 --------------------------------------------------------------------- Intel GmbH Dornacher Strasse 1 85622 Feldkirchen/Muenchen Germany Sitz der Gesellschaft: Feldkirchen bei Muenchen Geschaeftsfuehrer: Douglas Lusk, Peter Gleissner, Hannes Schwaderer Registergericht: Muenchen HRB 47456 Ust.-IdNr. VAT Registration No.: DE129385895 Citibank Frankfurt (BLZ 502 109 00) 600119052 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-22 mailing list mpi-22_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 _______________________________________________ mpi-22 mailing list mpi-22_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 --------------------------------------------------------------------- Intel GmbH Dornacher Strasse 1 85622 Feldkirchen/Muenchen Germany Sitz der Gesellschaft: Feldkirchen bei Muenchen Geschaeftsfuehrer: Douglas Lusk, Peter Gleissner, Hannes Schwaderer Registergericht: Muenchen HRB 47456 Ust.-IdNr. VAT Registration No.: DE129385895 Citibank Frankfurt (BLZ 502 109 00) 600119052 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-22 mailing list mpi-22_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 From alexander.supalov at [hidden] Tue Mar 17 03:05:20 2009 From: alexander.supalov at [hidden] (Supalov, Alexander) Date: Tue, 17 Mar 2009 08:05:20 +0000 Subject: [Mpi-22] Ticket #46: Add const Keyword to the C bindings-implementation In-Reply-To: <6B68D01C00C9994A8E150183E62A119E7B732E1D11@NA-EXMSG-C105.redmond.corp.microsoft.com> Message-ID: <928CFBE8E7CB0040959E56B4EA41A77E4A663F6F@irsmsx504.ger.corp.intel.com> Thanks. Then I have to disagree for the reasons mentioned below. In my view, adding the const modifier at the MPI level does add to the obsolescence down below by basically forcing the lower level interfaces move toward the use of the const keyword, what they currently and predominantly do not do. -----Original Message----- From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Erez Haba Sent: Monday, March 16, 2009 10:48 PM To: MPI 2.2 Subject: Re: [Mpi-22] Ticket #46: Add const Keyword to the C bindings-implementation It means that adding the const keyword is not relevant to the obsoleteness of the lower level interface (ticket #45 is). -----Original Message----- From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Supalov, Alexander Sent: Monday, March 16, 2009 2:37 PM To: MPI 2.2 Subject: Re: [Mpi-22] Ticket #46: Add const Keyword to the C bindings-implementation Thanks. What does it mean here, "more "obsolete" or less "obsolete""? Did you mean "more "obsolete" or less "advanced""? -----Original Message----- From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Erez Haba Sent: Monday, March 16, 2009 6:22 PM To: MPI 2.2 Subject: Re: [Mpi-22] Ticket #46: Add const Keyword to the C bindings-implementation Yes, I think we agree. Let me rephrase. With ticket #45 (send buffer access) being accepted, adding the const keyword does make any network interface more "obsolete" or less "obsolete". Thanks, .Erez -----Original Message----- From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Supalov, Alexander Sent: Monday, March 16, 2009 4:22 AM To: MPI 2.2 Subject: Re: [Mpi-22] Ticket #46: Add const Keyword to the C bindings-implementation Dear Erez, Thanks. Before this becomes too involved, let's untangle this a little. There are three topics here: 1. The send buffer change (#45). 2. The const pointer modifier (#46). 3. Bill's claim that 2. "simply captures the previously required semantics of the interface in the syntax". My message contained two statements: A. I said that 2. can only be understood in relation to 1. rather than the existing standard (say, MPI 2.1). I doubt this can be refuted. The old standard did allow in-place buffer changes. This would be impossible with the const buffer modifier. Hence my statement. B. Now, at least for me, 2. simply seals 1. This is why I said that this will make interfaces "obsolete". You object to this. Here's my reasoning: if I have to cast the const away on a lower level interface to make use of the MPI buffer, I surely have an issue. The issue is that the new MPI interface advanced ahead of my lower level networking interface. Thus, from the point of view of the MPI interface, the respective lower level interface becomes "obsolete". Hence my claim and hence the quotes - to point out that this is only MPI POV. Note that this is, in essence, only a negative rewording of Bill's "MPI should take the lead" clause. I doubt this can be refuted either. Finally, you added that 1. makes some networking interfaces "obsolete". Taking into account A. and B. above, I think we're in violent agreement: both 1. and 2. make MPI lead, or, in other words, make many networking interfaces "obsolete" from the MPI POV. This is very brave on part of the MPI standard. Let's see what happens next. Best regards. Alexander -----Original Message----- From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Erez Haba Sent: Monday, March 16, 2009 11:53 AM To: MPI 2.2 Subject: Re: [Mpi-22] Ticket #46: Add const Keyword to the C bindings-implementation Dear Alexander, Your claim that the const keyword might render some internal networking interfaces as "obsolete" is not correct. The const keyword has no effect on how relevant the network interface is. You probably mean that ticket #45 (send buffer) might render these interfaces as obsolete, and that would be a correct claim for those network interfaces that modify the send buffer. Thanks, .Erez -----Original Message----- From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Supalov, Alexander Sent: Monday, March 16, 2009 3:43 AM To: MPI 2.2 Subject: Re: [Mpi-22] Ticket #46: Add const Keyword to the C bindings-implementation Hi, I most respectively disagree with the "Const simply captures the previously required semantics of the interface in the syntax" statement. The standard did not prohibit a reversible in-place modification of the send buffer until the very recent change related to #45. Adding const on top will automatically make MPI not the greatest common denominator - some internal networking interfaces that were mentioned in this trail will suddenly become "obsolete". That is, most of the existing networking interfaces will. Best regards. Alexander -----Original Message----- From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of William Gropp Sent: Sunday, March 15, 2009 9:59 PM To: MPI 2.2 Subject: Re: [Mpi-22] Ticket #46: Add const Keyword to the C bindings-implementation Actually, MPI has taken the lead in a number of areas, including cross- language compatibility, to say nothing of the existence of MPI itself. And MPI has taken great pains to be the *greatest* common denominator. Const simply captures the previously required semantics of the interface in the syntax, and is consistent with the MPI spirit. Bill On Mar 13, 2009, at 2:17 PM, Jeff Squyres wrote: > On Mar 13, 2009, at 9:40 AM, William Gropp wrote: > >> First, this is a chicken-and-egg problem; the low level >> interfaces are unlikely to change to add const unless there is some >> application that will take advantage of that (and internally, if >> their >> semantics allows it and their compiler can support it, they'll just >> cast to add the const). So MPI should take the lead, particularly >> since using const also provides information to the user. >> > > This is a very scary statement to me. MPI has not traditionally > "taken the lead" on forcing issues with other interfaces (look where > it has gotten us with Fortran...). Indeed, MPI has taken great pains > to be the lowest common denominator across a variety of language, > platforms, and operating systems. > > -- > Jeff Squyres > Cisco Systems > > _______________________________________________ > mpi-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 William Gropp Deputy Director for Research Institute for Advanced Computing Applications and Technologies Paul and Cynthia Saylor Professor of Computer Science University of Illinois Urbana-Champaign _______________________________________________ mpi-22 mailing list mpi-22_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 --------------------------------------------------------------------- Intel GmbH Dornacher Strasse 1 85622 Feldkirchen/Muenchen Germany Sitz der Gesellschaft: Feldkirchen bei Muenchen Geschaeftsfuehrer: Douglas Lusk, Peter Gleissner, Hannes Schwaderer Registergericht: Muenchen HRB 47456 Ust.-IdNr. VAT Registration No.: DE129385895 Citibank Frankfurt (BLZ 502 109 00) 600119052 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-22 mailing list mpi-22_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 _______________________________________________ mpi-22 mailing list mpi-22_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 --------------------------------------------------------------------- Intel GmbH Dornacher Strasse 1 85622 Feldkirchen/Muenchen Germany Sitz der Gesellschaft: Feldkirchen bei Muenchen Geschaeftsfuehrer: Douglas Lusk, Peter Gleissner, Hannes Schwaderer Registergericht: Muenchen HRB 47456 Ust.-IdNr. VAT Registration No.: DE129385895 Citibank Frankfurt (BLZ 502 109 00) 600119052 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-22 mailing list mpi-22_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 _______________________________________________ mpi-22 mailing list mpi-22_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 --------------------------------------------------------------------- Intel GmbH Dornacher Strasse 1 85622 Feldkirchen/Muenchen Germany Sitz der Gesellschaft: Feldkirchen bei Muenchen Geschaeftsfuehrer: Douglas Lusk, Peter Gleissner, Hannes Schwaderer Registergericht: Muenchen HRB 47456 Ust.-IdNr. VAT Registration No.: DE129385895 Citibank Frankfurt (BLZ 502 109 00) 600119052 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-22 mailing list mpi-22_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 _______________________________________________ mpi-22 mailing list mpi-22_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 --------------------------------------------------------------------- Intel GmbH Dornacher Strasse 1 85622 Feldkirchen/Muenchen Germany Sitz der Gesellschaft: Feldkirchen bei Muenchen Geschaeftsfuehrer: Douglas Lusk, Peter Gleissner, Hannes Schwaderer Registergericht: Muenchen HRB 47456 Ust.-IdNr. VAT Registration No.: DE129385895 Citibank Frankfurt (BLZ 502 109 00) 600119052 This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. From erezh at [hidden] Tue Mar 17 18:20:06 2009 From: erezh at [hidden] (Erez Haba) Date: Tue, 17 Mar 2009 16:20:06 -0700 Subject: [Mpi-22] Ticket #46: Add const Keyword to the C bindings-implementation In-Reply-To: <928CFBE8E7CB0040959E56B4EA41A77E4A663F6F@irsmsx504.ger.corp.intel.com> Message-ID: <6B68D01C00C9994A8E150183E62A119E7B732E23FF@NA-EXMSG-C105.redmond.corp.microsoft.com> Okay, following your logic I would say that the MPI C++ binding makes the MPI C bindings obsolete because it uses the const modifier at the C++ level where it's not at the MPI C level. (The MPI C++ implementation is using the C bindings) Does this follow your logic correctly? Thanks, .Erez -----Original Message----- From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Supalov, Alexander Sent: Tuesday, March 17, 2009 1:05 AM To: MPI 2.2 Subject: Re: [Mpi-22] Ticket #46: Add const Keyword to the C bindings-implementation Thanks. Then I have to disagree for the reasons mentioned below. In my view, adding the const modifier at the MPI level does add to the obsolescence down below by basically forcing the lower level interfaces move toward the use of the const keyword, what they currently and predominantly do not do. -----Original Message----- From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Erez Haba Sent: Monday, March 16, 2009 10:48 PM To: MPI 2.2 Subject: Re: [Mpi-22] Ticket #46: Add const Keyword to the C bindings-implementation It means that adding the const keyword is not relevant to the obsoleteness of the lower level interface (ticket #45 is). -----Original Message----- From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Supalov, Alexander Sent: Monday, March 16, 2009 2:37 PM To: MPI 2.2 Subject: Re: [Mpi-22] Ticket #46: Add const Keyword to the C bindings-implementation Thanks. What does it mean here, "more "obsolete" or less "obsolete""? Did you mean "more "obsolete" or less "advanced""? -----Original Message----- From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Erez Haba Sent: Monday, March 16, 2009 6:22 PM To: MPI 2.2 Subject: Re: [Mpi-22] Ticket #46: Add const Keyword to the C bindings-implementation Yes, I think we agree. Let me rephrase. With ticket #45 (send buffer access) being accepted, adding the const keyword does make any network interface more "obsolete" or less "obsolete". Thanks, .Erez -----Original Message----- From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Supalov, Alexander Sent: Monday, March 16, 2009 4:22 AM To: MPI 2.2 Subject: Re: [Mpi-22] Ticket #46: Add const Keyword to the C bindings-implementation Dear Erez, Thanks. Before this becomes too involved, let's untangle this a little. There are three topics here: 1. The send buffer change (#45). 2. The const pointer modifier (#46). 3. Bill's claim that 2. "simply captures the previously required semantics of the interface in the syntax". My message contained two statements: A. I said that 2. can only be understood in relation to 1. rather than the existing standard (say, MPI 2.1). I doubt this can be refuted. The old standard did allow in-place buffer changes. This would be impossible with the const buffer modifier. Hence my statement. B. Now, at least for me, 2. simply seals 1. This is why I said that this will make interfaces "obsolete". You object to this. Here's my reasoning: if I have to cast the const away on a lower level interface to make use of the MPI buffer, I surely have an issue. The issue is that the new MPI interface advanced ahead of my lower level networking interface. Thus, from the point of view of the MPI interface, the respective lower level interface becomes "obsolete". Hence my claim and hence the quotes - to point out that this is only MPI POV. Note that this is, in essence, only a negative rewording of Bill's "MPI should take the lead" clause. I doubt this can be refuted either. Finally, you added that 1. makes some networking interfaces "obsolete". Taking into account A. and B. above, I think we're in violent agreement: both 1. and 2. make MPI lead, or, in other words, make many networking interfaces "obsolete" from the MPI POV. This is very brave on part of the MPI standard. Let's see what happens next. Best regards. Alexander -----Original Message----- From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Erez Haba Sent: Monday, March 16, 2009 11:53 AM To: MPI 2.2 Subject: Re: [Mpi-22] Ticket #46: Add const Keyword to the C bindings-implementation Dear Alexander, Your claim that the const keyword might render some internal networking interfaces as "obsolete" is not correct. The const keyword has no effect on how relevant the network interface is. You probably mean that ticket #45 (send buffer) might render these interfaces as obsolete, and that would be a correct claim for those network interfaces that modify the send buffer. Thanks, .Erez -----Original Message----- From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Supalov, Alexander Sent: Monday, March 16, 2009 3:43 AM To: MPI 2.2 Subject: Re: [Mpi-22] Ticket #46: Add const Keyword to the C bindings-implementation Hi, I most respectively disagree with the "Const simply captures the previously required semantics of the interface in the syntax" statement. The standard did not prohibit a reversible in-place modification of the send buffer until the very recent change related to #45. Adding const on top will automatically make MPI not the greatest common denominator - some internal networking interfaces that were mentioned in this trail will suddenly become "obsolete". That is, most of the existing networking interfaces will. Best regards. Alexander -----Original Message----- From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of William Gropp Sent: Sunday, March 15, 2009 9:59 PM To: MPI 2.2 Subject: Re: [Mpi-22] Ticket #46: Add const Keyword to the C bindings-implementation Actually, MPI has taken the lead in a number of areas, including cross- language compatibility, to say nothing of the existence of MPI itself. And MPI has taken great pains to be the *greatest* common denominator. Const simply captures the previously required semantics of the interface in the syntax, and is consistent with the MPI spirit. Bill On Mar 13, 2009, at 2:17 PM, Jeff Squyres wrote: > On Mar 13, 2009, at 9:40 AM, William Gropp wrote: > >> First, this is a chicken-and-egg problem; the low level >> interfaces are unlikely to change to add const unless there is some >> application that will take advantage of that (and internally, if >> their >> semantics allows it and their compiler can support it, they'll just >> cast to add the const). So MPI should take the lead, particularly >> since using const also provides information to the user. >> > > This is a very scary statement to me. MPI has not traditionally > "taken the lead" on forcing issues with other interfaces (look where > it has gotten us with Fortran...). Indeed, MPI has taken great pains > to be the lowest common denominator across a variety of language, > platforms, and operating systems. > > -- > Jeff Squyres > Cisco Systems > > _______________________________________________ > mpi-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 William Gropp Deputy Director for Research Institute for Advanced Computing Applications and Technologies Paul and Cynthia Saylor Professor of Computer Science University of Illinois Urbana-Champaign _______________________________________________ mpi-22 mailing list mpi-22_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 --------------------------------------------------------------------- Intel GmbH Dornacher Strasse 1 85622 Feldkirchen/Muenchen Germany Sitz der Gesellschaft: Feldkirchen bei Muenchen Geschaeftsfuehrer: Douglas Lusk, Peter Gleissner, Hannes Schwaderer Registergericht: Muenchen HRB 47456 Ust.-IdNr. VAT Registration No.: DE129385895 Citibank Frankfurt (BLZ 502 109 00) 600119052 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-22 mailing list mpi-22_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 _______________________________________________ mpi-22 mailing list mpi-22_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 --------------------------------------------------------------------- Intel GmbH Dornacher Strasse 1 85622 Feldkirchen/Muenchen Germany Sitz der Gesellschaft: Feldkirchen bei Muenchen Geschaeftsfuehrer: Douglas Lusk, Peter Gleissner, Hannes Schwaderer Registergericht: Muenchen HRB 47456 Ust.-IdNr. VAT Registration No.: DE129385895 Citibank Frankfurt (BLZ 502 109 00) 600119052 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-22 mailing list mpi-22_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 _______________________________________________ mpi-22 mailing list mpi-22_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 --------------------------------------------------------------------- Intel GmbH Dornacher Strasse 1 85622 Feldkirchen/Muenchen Germany Sitz der Gesellschaft: Feldkirchen bei Muenchen Geschaeftsfuehrer: Douglas Lusk, Peter Gleissner, Hannes Schwaderer Registergericht: Muenchen HRB 47456 Ust.-IdNr. VAT Registration No.: DE129385895 Citibank Frankfurt (BLZ 502 109 00) 600119052 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-22 mailing list mpi-22_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 _______________________________________________ mpi-22 mailing list mpi-22_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 --------------------------------------------------------------------- Intel GmbH Dornacher Strasse 1 85622 Feldkirchen/Muenchen Germany Sitz der Gesellschaft: Feldkirchen bei Muenchen Geschaeftsfuehrer: Douglas Lusk, Peter Gleissner, Hannes Schwaderer Registergericht: Muenchen HRB 47456 Ust.-IdNr. VAT Registration No.: DE129385895 Citibank Frankfurt (BLZ 502 109 00) 600119052 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-22 mailing list mpi-22_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 From jsquyres at [hidden] Tue Mar 17 18:50:45 2009 From: jsquyres at [hidden] (Jeff Squyres) Date: Tue, 17 Mar 2009 19:50:45 -0400 Subject: [Mpi-22] Ticket #46: Add const Keyword to the C bindings-implementation In-Reply-To: <6B68D01C00C9994A8E150183E62A119E7B732E23FF@NA-EXMSG-C105.redmond.corp.microsoft.com> Message-ID: Yet another reason to drop the C++ bindings in MPI-3.0! :-D On Mar 17, 2009, at 7:20 PM, Erez Haba wrote: > Okay, following your logic I would say that the MPI C++ binding > makes the MPI C bindings obsolete because it uses the const modifier > at the C++ level where it's not at the MPI C level. (The MPI C++ > implementation is using the C bindings) > > Does this follow your logic correctly? > > Thanks, > .Erez > > -----Original Message----- > From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden] > ] On Behalf Of Supalov, Alexander > Sent: Tuesday, March 17, 2009 1:05 AM > To: MPI 2.2 > Subject: Re: [Mpi-22] Ticket #46: Add const Keyword to the C > bindings-implementation > > Thanks. Then I have to disagree for the reasons mentioned below. In > my view, adding the const modifier at the MPI level does add to the > obsolescence down below by basically forcing the lower level > interfaces move toward the use of the const keyword, what they > currently and predominantly do not do. > > -----Original Message----- > From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden] > ] On Behalf Of Erez Haba > Sent: Monday, March 16, 2009 10:48 PM > To: MPI 2.2 > Subject: Re: [Mpi-22] Ticket #46: Add const Keyword to the C > bindings-implementation > > It means that adding the const keyword is not relevant to the > obsoleteness of the lower level interface (ticket #45 is). > > -----Original Message----- > From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden] > ] On Behalf Of Supalov, Alexander > Sent: Monday, March 16, 2009 2:37 PM > To: MPI 2.2 > Subject: Re: [Mpi-22] Ticket #46: Add const Keyword to the C > bindings-implementation > > Thanks. What does it mean here, "more "obsolete" or less > "obsolete""? Did you mean "more "obsolete" or less "advanced""? > > -----Original Message----- > From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden] > ] On Behalf Of Erez Haba > Sent: Monday, March 16, 2009 6:22 PM > To: MPI 2.2 > Subject: Re: [Mpi-22] Ticket #46: Add const Keyword to the C > bindings-implementation > > Yes, I think we agree. Let me rephrase. > > With ticket #45 (send buffer access) being accepted, adding the > const keyword does make any network interface more "obsolete" or > less "obsolete". > > > Thanks, > .Erez > > > -----Original Message----- > From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden] > ] On Behalf Of Supalov, Alexander > Sent: Monday, March 16, 2009 4:22 AM > To: MPI 2.2 > Subject: Re: [Mpi-22] Ticket #46: Add const Keyword to the C > bindings-implementation > > Dear Erez, > > Thanks. Before this becomes too involved, let's untangle this a > little. > > There are three topics here: > > 1. The send buffer change (#45). > 2. The const pointer modifier (#46). > 3. Bill's claim that 2. "simply captures the previously required > semantics of the interface in the syntax". > > My message contained two statements: > > A. I said that 2. can only be understood in relation to 1. rather > than the existing standard (say, MPI 2.1). I doubt this can be > refuted. The old standard did allow in-place buffer changes. This > would be impossible with the const buffer modifier. Hence my > statement. > > B. Now, at least for me, 2. simply seals 1. This is why I said that > this will make interfaces "obsolete". You object to this. Here's my > reasoning: if I have to cast the const away on a lower level > interface to make use of the MPI buffer, I surely have an issue. The > issue is that the new MPI interface advanced ahead of my lower level > networking interface. Thus, from the point of view of the MPI > interface, the respective lower level interface becomes "obsolete". > Hence my claim and hence the quotes - to point out that this is only > MPI POV. Note that this is, in essence, only a negative rewording of > Bill's "MPI should take the lead" clause. I doubt this can be > refuted either. > > Finally, you added that 1. makes some networking interfaces > "obsolete". Taking into account A. and B. above, I think we're in > violent agreement: both 1. and 2. make MPI lead, or, in other words, > make many networking interfaces "obsolete" from the MPI POV. This is > very brave on part of the MPI standard. Let's see what happens next. > > Best regards. > > Alexander > > -----Original Message----- > From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden] > ] On Behalf Of Erez Haba > Sent: Monday, March 16, 2009 11:53 AM > To: MPI 2.2 > Subject: Re: [Mpi-22] Ticket #46: Add const Keyword to the C > bindings-implementation > > Dear Alexander, > > Your claim that the const keyword might render some internal > networking interfaces as "obsolete" is not correct. The const > keyword has no effect on how relevant the network interface is. You > probably mean that ticket #45 (send buffer) might render these > interfaces as obsolete, and that would be a correct claim for those > network interfaces that modify the send buffer. > > Thanks, > .Erez > > -----Original Message----- > From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden] > ] On Behalf Of Supalov, Alexander > Sent: Monday, March 16, 2009 3:43 AM > To: MPI 2.2 > Subject: Re: [Mpi-22] Ticket #46: Add const Keyword to the C > bindings-implementation > > Hi, > > I most respectively disagree with the "Const simply captures the > previously required semantics of the interface in the syntax" > statement. The standard did not prohibit a reversible in-place > modification of the send buffer until the very recent change related > to #45. Adding const on top will automatically make MPI not the > greatest common denominator - some internal networking interfaces > that were mentioned in this trail will suddenly become "obsolete". > That is, most of the existing networking interfaces will. > > Best regards. > > Alexander > > -----Original Message----- > From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden] > ] On Behalf Of William Gropp > Sent: Sunday, March 15, 2009 9:59 PM > To: MPI 2.2 > Subject: Re: [Mpi-22] Ticket #46: Add const Keyword to the C > bindings-implementation > > Actually, MPI has taken the lead in a number of areas, including > cross- > language compatibility, to say nothing of the existence of MPI itself. > > And MPI has taken great pains to be the *greatest* common > denominator. Const simply captures the previously required semantics > of the interface in the syntax, and is consistent with the MPI spirit. > > Bill > On Mar 13, 2009, at 2:17 PM, Jeff Squyres wrote: > > > On Mar 13, 2009, at 9:40 AM, William Gropp wrote: > > > >> First, this is a chicken-and-egg problem; the low level > >> interfaces are unlikely to change to add const unless there is some > >> application that will take advantage of that (and internally, if > >> their > >> semantics allows it and their compiler can support it, they'll just > >> cast to add the const). So MPI should take the lead, particularly > >> since using const also provides information to the user. > >> > > > > This is a very scary statement to me. MPI has not traditionally > > "taken the lead" on forcing issues with other interfaces (look where > > it has gotten us with Fortran...). Indeed, MPI has taken great > pains > > to be the lowest common denominator across a variety of language, > > platforms, and operating systems. > > > > -- > > Jeff Squyres > > Cisco Systems > > > > _______________________________________________ > > mpi-22 mailing list > > mpi-22_at_[hidden] > > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 > > William Gropp > Deputy Director for Research > Institute for Advanced Computing Applications and Technologies > Paul and Cynthia Saylor Professor of Computer Science > University of Illinois Urbana-Champaign > > > > > _______________________________________________ > mpi-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 > --------------------------------------------------------------------- > Intel GmbH > Dornacher Strasse 1 > 85622 Feldkirchen/Muenchen Germany > Sitz der Gesellschaft: Feldkirchen bei Muenchen > Geschaeftsfuehrer: Douglas Lusk, Peter Gleissner, Hannes Schwaderer > Registergericht: Muenchen HRB 47456 Ust.-IdNr. > VAT Registration No.: DE129385895 > Citibank Frankfurt (BLZ 502 109 00) 600119052 > > 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-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 > > > _______________________________________________ > mpi-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 > --------------------------------------------------------------------- > Intel GmbH > Dornacher Strasse 1 > 85622 Feldkirchen/Muenchen Germany > Sitz der Gesellschaft: Feldkirchen bei Muenchen > Geschaeftsfuehrer: Douglas Lusk, Peter Gleissner, Hannes Schwaderer > Registergericht: Muenchen HRB 47456 Ust.-IdNr. > VAT Registration No.: DE129385895 > Citibank Frankfurt (BLZ 502 109 00) 600119052 > > 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-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 > > > _______________________________________________ > mpi-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 > --------------------------------------------------------------------- > Intel GmbH > Dornacher Strasse 1 > 85622 Feldkirchen/Muenchen Germany > Sitz der Gesellschaft: Feldkirchen bei Muenchen > Geschaeftsfuehrer: Douglas Lusk, Peter Gleissner, Hannes Schwaderer > Registergericht: Muenchen HRB 47456 Ust.-IdNr. > VAT Registration No.: DE129385895 > Citibank Frankfurt (BLZ 502 109 00) 600119052 > > 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-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 > > > _______________________________________________ > mpi-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 > --------------------------------------------------------------------- > Intel GmbH > Dornacher Strasse 1 > 85622 Feldkirchen/Muenchen Germany > Sitz der Gesellschaft: Feldkirchen bei Muenchen > Geschaeftsfuehrer: Douglas Lusk, Peter Gleissner, Hannes Schwaderer > Registergericht: Muenchen HRB 47456 Ust.-IdNr. > VAT Registration No.: DE129385895 > Citibank Frankfurt (BLZ 502 109 00) 600119052 > > 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-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 > > > _______________________________________________ > mpi-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 -- Jeff Squyres Cisco Systems From alexander.supalov at [hidden] Wed Mar 18 05:57:03 2009 From: alexander.supalov at [hidden] (Supalov, Alexander) Date: Wed, 18 Mar 2009 10:57:03 +0000 Subject: [Mpi-22] Ticket #46: Add const Keyword to the C bindings-implementation In-Reply-To: Message-ID: <928CFBE8E7CB0040959E56B4EA41A77E87B74E33@irsmsx504.ger.corp.intel.com> I was not talking about C++, as #46 does not. What happened to C++ in the past and why it is incompatible with C is a different question. -----Original Message----- From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Jeff Squyres Sent: Wednesday, March 18, 2009 12:51 AM To: MPI 2.2 Subject: Re: [Mpi-22] Ticket #46: Add const Keyword to the C bindings-implementation Yet another reason to drop the C++ bindings in MPI-3.0! :-D On Mar 17, 2009, at 7:20 PM, Erez Haba wrote: > Okay, following your logic I would say that the MPI C++ binding > makes the MPI C bindings obsolete because it uses the const modifier > at the C++ level where it's not at the MPI C level. (The MPI C++ > implementation is using the C bindings) > > Does this follow your logic correctly? > > Thanks, > .Erez > > -----Original Message----- > From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden] > ] On Behalf Of Supalov, Alexander > Sent: Tuesday, March 17, 2009 1:05 AM > To: MPI 2.2 > Subject: Re: [Mpi-22] Ticket #46: Add const Keyword to the C > bindings-implementation > > Thanks. Then I have to disagree for the reasons mentioned below. In > my view, adding the const modifier at the MPI level does add to the > obsolescence down below by basically forcing the lower level > interfaces move toward the use of the const keyword, what they > currently and predominantly do not do. > > -----Original Message----- > From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden] > ] On Behalf Of Erez Haba > Sent: Monday, March 16, 2009 10:48 PM > To: MPI 2.2 > Subject: Re: [Mpi-22] Ticket #46: Add const Keyword to the C > bindings-implementation > > It means that adding the const keyword is not relevant to the > obsoleteness of the lower level interface (ticket #45 is). > > -----Original Message----- > From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden] > ] On Behalf Of Supalov, Alexander > Sent: Monday, March 16, 2009 2:37 PM > To: MPI 2.2 > Subject: Re: [Mpi-22] Ticket #46: Add const Keyword to the C > bindings-implementation > > Thanks. What does it mean here, "more "obsolete" or less > "obsolete""? Did you mean "more "obsolete" or less "advanced""? > > -----Original Message----- > From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden] > ] On Behalf Of Erez Haba > Sent: Monday, March 16, 2009 6:22 PM > To: MPI 2.2 > Subject: Re: [Mpi-22] Ticket #46: Add const Keyword to the C > bindings-implementation > > Yes, I think we agree. Let me rephrase. > > With ticket #45 (send buffer access) being accepted, adding the > const keyword does make any network interface more "obsolete" or > less "obsolete". > > > Thanks, > .Erez > > > -----Original Message----- > From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden] > ] On Behalf Of Supalov, Alexander > Sent: Monday, March 16, 2009 4:22 AM > To: MPI 2.2 > Subject: Re: [Mpi-22] Ticket #46: Add const Keyword to the C > bindings-implementation > > Dear Erez, > > Thanks. Before this becomes too involved, let's untangle this a > little. > > There are three topics here: > > 1. The send buffer change (#45). > 2. The const pointer modifier (#46). > 3. Bill's claim that 2. "simply captures the previously required > semantics of the interface in the syntax". > > My message contained two statements: > > A. I said that 2. can only be understood in relation to 1. rather > than the existing standard (say, MPI 2.1). I doubt this can be > refuted. The old standard did allow in-place buffer changes. This > would be impossible with the const buffer modifier. Hence my > statement. > > B. Now, at least for me, 2. simply seals 1. This is why I said that > this will make interfaces "obsolete". You object to this. Here's my > reasoning: if I have to cast the const away on a lower level > interface to make use of the MPI buffer, I surely have an issue. The > issue is that the new MPI interface advanced ahead of my lower level > networking interface. Thus, from the point of view of the MPI > interface, the respective lower level interface becomes "obsolete". > Hence my claim and hence the quotes - to point out that this is only > MPI POV. Note that this is, in essence, only a negative rewording of > Bill's "MPI should take the lead" clause. I doubt this can be > refuted either. > > Finally, you added that 1. makes some networking interfaces > "obsolete". Taking into account A. and B. above, I think we're in > violent agreement: both 1. and 2. make MPI lead, or, in other words, > make many networking interfaces "obsolete" from the MPI POV. This is > very brave on part of the MPI standard. Let's see what happens next. > > Best regards. > > Alexander > > -----Original Message----- > From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden] > ] On Behalf Of Erez Haba > Sent: Monday, March 16, 2009 11:53 AM > To: MPI 2.2 > Subject: Re: [Mpi-22] Ticket #46: Add const Keyword to the C > bindings-implementation > > Dear Alexander, > > Your claim that the const keyword might render some internal > networking interfaces as "obsolete" is not correct. The const > keyword has no effect on how relevant the network interface is. You > probably mean that ticket #45 (send buffer) might render these > interfaces as obsolete, and that would be a correct claim for those > network interfaces that modify the send buffer. > > Thanks, > .Erez > > -----Original Message----- > From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden] > ] On Behalf Of Supalov, Alexander > Sent: Monday, March 16, 2009 3:43 AM > To: MPI 2.2 > Subject: Re: [Mpi-22] Ticket #46: Add const Keyword to the C > bindings-implementation > > Hi, > > I most respectively disagree with the "Const simply captures the > previously required semantics of the interface in the syntax" > statement. The standard did not prohibit a reversible in-place > modification of the send buffer until the very recent change related > to #45. Adding const on top will automatically make MPI not the > greatest common denominator - some internal networking interfaces > that were mentioned in this trail will suddenly become "obsolete". > That is, most of the existing networking interfaces will. > > Best regards. > > Alexander > > -----Original Message----- > From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden] > ] On Behalf Of William Gropp > Sent: Sunday, March 15, 2009 9:59 PM > To: MPI 2.2 > Subject: Re: [Mpi-22] Ticket #46: Add const Keyword to the C > bindings-implementation > > Actually, MPI has taken the lead in a number of areas, including > cross- > language compatibility, to say nothing of the existence of MPI itself. > > And MPI has taken great pains to be the *greatest* common > denominator. Const simply captures the previously required semantics > of the interface in the syntax, and is consistent with the MPI spirit. > > Bill > On Mar 13, 2009, at 2:17 PM, Jeff Squyres wrote: > > > On Mar 13, 2009, at 9:40 AM, William Gropp wrote: > > > >> First, this is a chicken-and-egg problem; the low level > >> interfaces are unlikely to change to add const unless there is some > >> application that will take advantage of that (and internally, if > >> their > >> semantics allows it and their compiler can support it, they'll just > >> cast to add the const). So MPI should take the lead, particularly > >> since using const also provides information to the user. > >> > > > > This is a very scary statement to me. MPI has not traditionally > > "taken the lead" on forcing issues with other interfaces (look where > > it has gotten us with Fortran...). Indeed, MPI has taken great > pains > > to be the lowest common denominator across a variety of language, > > platforms, and operating systems. > > > > -- > > Jeff Squyres > > Cisco Systems > > > > _______________________________________________ > > mpi-22 mailing list > > mpi-22_at_[hidden] > > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 > > William Gropp > Deputy Director for Research > Institute for Advanced Computing Applications and Technologies > Paul and Cynthia Saylor Professor of Computer Science > University of Illinois Urbana-Champaign > > > > > _______________________________________________ > mpi-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 > --------------------------------------------------------------------- > Intel GmbH > Dornacher Strasse 1 > 85622 Feldkirchen/Muenchen Germany > Sitz der Gesellschaft: Feldkirchen bei Muenchen > Geschaeftsfuehrer: Douglas Lusk, Peter Gleissner, Hannes Schwaderer > Registergericht: Muenchen HRB 47456 Ust.-IdNr. > VAT Registration No.: DE129385895 > Citibank Frankfurt (BLZ 502 109 00) 600119052 > > 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-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 > > > _______________________________________________ > mpi-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 > --------------------------------------------------------------------- > Intel GmbH > Dornacher Strasse 1 > 85622 Feldkirchen/Muenchen Germany > Sitz der Gesellschaft: Feldkirchen bei Muenchen > Geschaeftsfuehrer: Douglas Lusk, Peter Gleissner, Hannes Schwaderer > Registergericht: Muenchen HRB 47456 Ust.-IdNr. > VAT Registration No.: DE129385895 > Citibank Frankfurt (BLZ 502 109 00) 600119052 > > 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-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 > > > _______________________________________________ > mpi-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 > --------------------------------------------------------------------- > Intel GmbH > Dornacher Strasse 1 > 85622 Feldkirchen/Muenchen Germany > Sitz der Gesellschaft: Feldkirchen bei Muenchen > Geschaeftsfuehrer: Douglas Lusk, Peter Gleissner, Hannes Schwaderer > Registergericht: Muenchen HRB 47456 Ust.-IdNr. > VAT Registration No.: DE129385895 > Citibank Frankfurt (BLZ 502 109 00) 600119052 > > 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-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 > > > _______________________________________________ > mpi-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 > --------------------------------------------------------------------- > Intel GmbH > Dornacher Strasse 1 > 85622 Feldkirchen/Muenchen Germany > Sitz der Gesellschaft: Feldkirchen bei Muenchen > Geschaeftsfuehrer: Douglas Lusk, Peter Gleissner, Hannes Schwaderer > Registergericht: Muenchen HRB 47456 Ust.-IdNr. > VAT Registration No.: DE129385895 > Citibank Frankfurt (BLZ 502 109 00) 600119052 > > 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-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 > > > _______________________________________________ > mpi-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 -- Jeff Squyres Cisco Systems _______________________________________________ mpi-22 mailing list mpi-22_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 --------------------------------------------------------------------- Intel GmbH Dornacher Strasse 1 85622 Feldkirchen/Muenchen Germany Sitz der Gesellschaft: Feldkirchen bei Muenchen Geschaeftsfuehrer: Douglas Lusk, Peter Gleissner, Hannes Schwaderer Registergericht: Muenchen HRB 47456 Ust.-IdNr. VAT Registration No.: DE129385895 Citibank Frankfurt (BLZ 502 109 00) 600119052 This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. From erezh at [hidden] Wed Mar 18 12:17:16 2009 From: erezh at [hidden] (Erez Haba) Date: Wed, 18 Mar 2009 10:17:16 -0700 Subject: [Mpi-22] Ticket #46: Add const Keyword to the C bindings-implementation In-Reply-To: <928CFBE8E7CB0040959E56B4EA41A77E87B74E33@irsmsx504.ger.corp.intel.com> Message-ID: <6B68D01C00C9994A8E150183E62A119E7B733A50A0@NA-EXMSG-C105.redmond.corp.microsoft.com> I was making an analogy, following your logic. -----Original Message----- From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Supalov, Alexander Sent: Wednesday, March 18, 2009 3:57 AM To: MPI 2.2 Subject: Re: [Mpi-22] Ticket #46: Add const Keyword to the C bindings-implementation I was not talking about C++, as #46 does not. What happened to C++ in the past and why it is incompatible with C is a different question. -----Original Message----- From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Jeff Squyres Sent: Wednesday, March 18, 2009 12:51 AM To: MPI 2.2 Subject: Re: [Mpi-22] Ticket #46: Add const Keyword to the C bindings-implementation Yet another reason to drop the C++ bindings in MPI-3.0! :-D On Mar 17, 2009, at 7:20 PM, Erez Haba wrote: > Okay, following your logic I would say that the MPI C++ binding > makes the MPI C bindings obsolete because it uses the const modifier > at the C++ level where it's not at the MPI C level. (The MPI C++ > implementation is using the C bindings) > > Does this follow your logic correctly? > > Thanks, > .Erez > > -----Original Message----- > From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden] > ] On Behalf Of Supalov, Alexander > Sent: Tuesday, March 17, 2009 1:05 AM > To: MPI 2.2 > Subject: Re: [Mpi-22] Ticket #46: Add const Keyword to the C > bindings-implementation > > Thanks. Then I have to disagree for the reasons mentioned below. In > my view, adding the const modifier at the MPI level does add to the > obsolescence down below by basically forcing the lower level > interfaces move toward the use of the const keyword, what they > currently and predominantly do not do. > > -----Original Message----- > From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden] > ] On Behalf Of Erez Haba > Sent: Monday, March 16, 2009 10:48 PM > To: MPI 2.2 > Subject: Re: [Mpi-22] Ticket #46: Add const Keyword to the C > bindings-implementation > > It means that adding the const keyword is not relevant to the > obsoleteness of the lower level interface (ticket #45 is). > > -----Original Message----- > From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden] > ] On Behalf Of Supalov, Alexander > Sent: Monday, March 16, 2009 2:37 PM > To: MPI 2.2 > Subject: Re: [Mpi-22] Ticket #46: Add const Keyword to the C > bindings-implementation > > Thanks. What does it mean here, "more "obsolete" or less > "obsolete""? Did you mean "more "obsolete" or less "advanced""? > > -----Original Message----- > From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden] > ] On Behalf Of Erez Haba > Sent: Monday, March 16, 2009 6:22 PM > To: MPI 2.2 > Subject: Re: [Mpi-22] Ticket #46: Add const Keyword to the C > bindings-implementation > > Yes, I think we agree. Let me rephrase. > > With ticket #45 (send buffer access) being accepted, adding the > const keyword does make any network interface more "obsolete" or > less "obsolete". > > > Thanks, > .Erez > > > -----Original Message----- > From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden] > ] On Behalf Of Supalov, Alexander > Sent: Monday, March 16, 2009 4:22 AM > To: MPI 2.2 > Subject: Re: [Mpi-22] Ticket #46: Add const Keyword to the C > bindings-implementation > > Dear Erez, > > Thanks. Before this becomes too involved, let's untangle this a > little. > > There are three topics here: > > 1. The send buffer change (#45). > 2. The const pointer modifier (#46). > 3. Bill's claim that 2. "simply captures the previously required > semantics of the interface in the syntax". > > My message contained two statements: > > A. I said that 2. can only be understood in relation to 1. rather > than the existing standard (say, MPI 2.1). I doubt this can be > refuted. The old standard did allow in-place buffer changes. This > would be impossible with the const buffer modifier. Hence my > statement. > > B. Now, at least for me, 2. simply seals 1. This is why I said that > this will make interfaces "obsolete". You object to this. Here's my > reasoning: if I have to cast the const away on a lower level > interface to make use of the MPI buffer, I surely have an issue. The > issue is that the new MPI interface advanced ahead of my lower level > networking interface. Thus, from the point of view of the MPI > interface, the respective lower level interface becomes "obsolete". > Hence my claim and hence the quotes - to point out that this is only > MPI POV. Note that this is, in essence, only a negative rewording of > Bill's "MPI should take the lead" clause. I doubt this can be > refuted either. > > Finally, you added that 1. makes some networking interfaces > "obsolete". Taking into account A. and B. above, I think we're in > violent agreement: both 1. and 2. make MPI lead, or, in other words, > make many networking interfaces "obsolete" from the MPI POV. This is > very brave on part of the MPI standard. Let's see what happens next. > > Best regards. > > Alexander > > -----Original Message----- > From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden] > ] On Behalf Of Erez Haba > Sent: Monday, March 16, 2009 11:53 AM > To: MPI 2.2 > Subject: Re: [Mpi-22] Ticket #46: Add const Keyword to the C > bindings-implementation > > Dear Alexander, > > Your claim that the const keyword might render some internal > networking interfaces as "obsolete" is not correct. The const > keyword has no effect on how relevant the network interface is. You > probably mean that ticket #45 (send buffer) might render these > interfaces as obsolete, and that would be a correct claim for those > network interfaces that modify the send buffer. > > Thanks, > .Erez > > -----Original Message----- > From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden] > ] On Behalf Of Supalov, Alexander > Sent: Monday, March 16, 2009 3:43 AM > To: MPI 2.2 > Subject: Re: [Mpi-22] Ticket #46: Add const Keyword to the C > bindings-implementation > > Hi, > > I most respectively disagree with the "Const simply captures the > previously required semantics of the interface in the syntax" > statement. The standard did not prohibit a reversible in-place > modification of the send buffer until the very recent change related > to #45. Adding const on top will automatically make MPI not the > greatest common denominator - some internal networking interfaces > that were mentioned in this trail will suddenly become "obsolete". > That is, most of the existing networking interfaces will. > > Best regards. > > Alexander > > -----Original Message----- > From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden] > ] On Behalf Of William Gropp > Sent: Sunday, March 15, 2009 9:59 PM > To: MPI 2.2 > Subject: Re: [Mpi-22] Ticket #46: Add const Keyword to the C > bindings-implementation > > Actually, MPI has taken the lead in a number of areas, including > cross- > language compatibility, to say nothing of the existence of MPI itself. > > And MPI has taken great pains to be the *greatest* common > denominator. Const simply captures the previously required semantics > of the interface in the syntax, and is consistent with the MPI spirit. > > Bill > On Mar 13, 2009, at 2:17 PM, Jeff Squyres wrote: > > > On Mar 13, 2009, at 9:40 AM, William Gropp wrote: > > > >> First, this is a chicken-and-egg problem; the low level > >> interfaces are unlikely to change to add const unless there is some > >> application that will take advantage of that (and internally, if > >> their > >> semantics allows it and their compiler can support it, they'll just > >> cast to add the const). So MPI should take the lead, particularly > >> since using const also provides information to the user. > >> > > > > This is a very scary statement to me. MPI has not traditionally > > "taken the lead" on forcing issues with other interfaces (look where > > it has gotten us with Fortran...). Indeed, MPI has taken great > pains > > to be the lowest common denominator across a variety of language, > > platforms, and operating systems. > > > > -- > > Jeff Squyres > > Cisco Systems > > > > _______________________________________________ > > mpi-22 mailing list > > mpi-22_at_[hidden] > > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 > > William Gropp > Deputy Director for Research > Institute for Advanced Computing Applications and Technologies > Paul and Cynthia Saylor Professor of Computer Science > University of Illinois Urbana-Champaign > > > > > _______________________________________________ > mpi-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 > --------------------------------------------------------------------- > Intel GmbH > Dornacher Strasse 1 > 85622 Feldkirchen/Muenchen Germany > Sitz der Gesellschaft: Feldkirchen bei Muenchen > Geschaeftsfuehrer: Douglas Lusk, Peter Gleissner, Hannes Schwaderer > Registergericht: Muenchen HRB 47456 Ust.-IdNr. > VAT Registration No.: DE129385895 > Citibank Frankfurt (BLZ 502 109 00) 600119052 > > 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-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 > > > _______________________________________________ > mpi-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 > --------------------------------------------------------------------- > Intel GmbH > Dornacher Strasse 1 > 85622 Feldkirchen/Muenchen Germany > Sitz der Gesellschaft: Feldkirchen bei Muenchen > Geschaeftsfuehrer: Douglas Lusk, Peter Gleissner, Hannes Schwaderer > Registergericht: Muenchen HRB 47456 Ust.-IdNr. > VAT Registration No.: DE129385895 > Citibank Frankfurt (BLZ 502 109 00) 600119052 > > 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-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 > > > _______________________________________________ > mpi-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 > --------------------------------------------------------------------- > Intel GmbH > Dornacher Strasse 1 > 85622 Feldkirchen/Muenchen Germany > Sitz der Gesellschaft: Feldkirchen bei Muenchen > Geschaeftsfuehrer: Douglas Lusk, Peter Gleissner, Hannes Schwaderer > Registergericht: Muenchen HRB 47456 Ust.-IdNr. > VAT Registration No.: DE129385895 > Citibank Frankfurt (BLZ 502 109 00) 600119052 > > 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-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 > > > _______________________________________________ > mpi-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 > --------------------------------------------------------------------- > Intel GmbH > Dornacher Strasse 1 > 85622 Feldkirchen/Muenchen Germany > Sitz der Gesellschaft: Feldkirchen bei Muenchen > Geschaeftsfuehrer: Douglas Lusk, Peter Gleissner, Hannes Schwaderer > Registergericht: Muenchen HRB 47456 Ust.-IdNr. > VAT Registration No.: DE129385895 > Citibank Frankfurt (BLZ 502 109 00) 600119052 > > 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-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 > > > _______________________________________________ > mpi-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 -- Jeff Squyres Cisco Systems _______________________________________________ mpi-22 mailing list mpi-22_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 --------------------------------------------------------------------- Intel GmbH Dornacher Strasse 1 85622 Feldkirchen/Muenchen Germany Sitz der Gesellschaft: Feldkirchen bei Muenchen Geschaeftsfuehrer: Douglas Lusk, Peter Gleissner, Hannes Schwaderer Registergericht: Muenchen HRB 47456 Ust.-IdNr. VAT Registration No.: DE129385895 Citibank Frankfurt (BLZ 502 109 00) 600119052 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-22 mailing list mpi-22_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 From alexander.supalov at [hidden] Wed Mar 18 15:09:29 2009 From: alexander.supalov at [hidden] (Supalov, Alexander) Date: Wed, 18 Mar 2009 20:09:29 +0000 Subject: [Mpi-22] Ticket #46: Add const Keyword to the C bindings-implementation In-Reply-To: <6B68D01C00C9994A8E150183E62A119E7B733A50A0@NA-EXMSG-C105.redmond.corp.microsoft.com> Message-ID: <928CFBE8E7CB0040959E56B4EA41A77E87B75280@irsmsx504.ger.corp.intel.com> Thanks, I understand. Given that C++ binding in MPI-2.1 apparently violates the spirit of the standard by disallowing in-place buffer conversions, I don't think that the implicitly suggested goodness of bringing the historical C interface in line with the currently incorrect C++ interface should play any role in this particular discussion. -----Original Message----- From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Erez Haba Sent: Wednesday, March 18, 2009 6:17 PM To: MPI 2.2 Subject: Re: [Mpi-22] Ticket #46: Add const Keyword to the C bindings-implementation I was making an analogy, following your logic. -----Original Message----- From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Supalov, Alexander Sent: Wednesday, March 18, 2009 3:57 AM To: MPI 2.2 Subject: Re: [Mpi-22] Ticket #46: Add const Keyword to the C bindings-implementation I was not talking about C++, as #46 does not. What happened to C++ in the past and why it is incompatible with C is a different question. -----Original Message----- From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Jeff Squyres Sent: Wednesday, March 18, 2009 12:51 AM To: MPI 2.2 Subject: Re: [Mpi-22] Ticket #46: Add const Keyword to the C bindings-implementation Yet another reason to drop the C++ bindings in MPI-3.0! :-D On Mar 17, 2009, at 7:20 PM, Erez Haba wrote: > Okay, following your logic I would say that the MPI C++ binding > makes the MPI C bindings obsolete because it uses the const modifier > at the C++ level where it's not at the MPI C level. (The MPI C++ > implementation is using the C bindings) > > Does this follow your logic correctly? > > Thanks, > .Erez > > -----Original Message----- > From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden] > ] On Behalf Of Supalov, Alexander > Sent: Tuesday, March 17, 2009 1:05 AM > To: MPI 2.2 > Subject: Re: [Mpi-22] Ticket #46: Add const Keyword to the C > bindings-implementation > > Thanks. Then I have to disagree for the reasons mentioned below. In > my view, adding the const modifier at the MPI level does add to the > obsolescence down below by basically forcing the lower level > interfaces move toward the use of the const keyword, what they > currently and predominantly do not do. > > -----Original Message----- > From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden] > ] On Behalf Of Erez Haba > Sent: Monday, March 16, 2009 10:48 PM > To: MPI 2.2 > Subject: Re: [Mpi-22] Ticket #46: Add const Keyword to the C > bindings-implementation > > It means that adding the const keyword is not relevant to the > obsoleteness of the lower level interface (ticket #45 is). > > -----Original Message----- > From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden] > ] On Behalf Of Supalov, Alexander > Sent: Monday, March 16, 2009 2:37 PM > To: MPI 2.2 > Subject: Re: [Mpi-22] Ticket #46: Add const Keyword to the C > bindings-implementation > > Thanks. What does it mean here, "more "obsolete" or less > "obsolete""? Did you mean "more "obsolete" or less "advanced""? > > -----Original Message----- > From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden] > ] On Behalf Of Erez Haba > Sent: Monday, March 16, 2009 6:22 PM > To: MPI 2.2 > Subject: Re: [Mpi-22] Ticket #46: Add const Keyword to the C > bindings-implementation > > Yes, I think we agree. Let me rephrase. > > With ticket #45 (send buffer access) being accepted, adding the > const keyword does make any network interface more "obsolete" or > less "obsolete". > > > Thanks, > .Erez > > > -----Original Message----- > From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden] > ] On Behalf Of Supalov, Alexander > Sent: Monday, March 16, 2009 4:22 AM > To: MPI 2.2 > Subject: Re: [Mpi-22] Ticket #46: Add const Keyword to the C > bindings-implementation > > Dear Erez, > > Thanks. Before this becomes too involved, let's untangle this a > little. > > There are three topics here: > > 1. The send buffer change (#45). > 2. The const pointer modifier (#46). > 3. Bill's claim that 2. "simply captures the previously required > semantics of the interface in the syntax". > > My message contained two statements: > > A. I said that 2. can only be understood in relation to 1. rather > than the existing standard (say, MPI 2.1). I doubt this can be > refuted. The old standard did allow in-place buffer changes. This > would be impossible with the const buffer modifier. Hence my > statement. > > B. Now, at least for me, 2. simply seals 1. This is why I said that > this will make interfaces "obsolete". You object to this. Here's my > reasoning: if I have to cast the const away on a lower level > interface to make use of the MPI buffer, I surely have an issue. The > issue is that the new MPI interface advanced ahead of my lower level > networking interface. Thus, from the point of view of the MPI > interface, the respective lower level interface becomes "obsolete". > Hence my claim and hence the quotes - to point out that this is only > MPI POV. Note that this is, in essence, only a negative rewording of > Bill's "MPI should take the lead" clause. I doubt this can be > refuted either. > > Finally, you added that 1. makes some networking interfaces > "obsolete". Taking into account A. and B. above, I think we're in > violent agreement: both 1. and 2. make MPI lead, or, in other words, > make many networking interfaces "obsolete" from the MPI POV. This is > very brave on part of the MPI standard. Let's see what happens next. > > Best regards. > > Alexander > > -----Original Message----- > From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden] > ] On Behalf Of Erez Haba > Sent: Monday, March 16, 2009 11:53 AM > To: MPI 2.2 > Subject: Re: [Mpi-22] Ticket #46: Add const Keyword to the C > bindings-implementation > > Dear Alexander, > > Your claim that the const keyword might render some internal > networking interfaces as "obsolete" is not correct. The const > keyword has no effect on how relevant the network interface is. You > probably mean that ticket #45 (send buffer) might render these > interfaces as obsolete, and that would be a correct claim for those > network interfaces that modify the send buffer. > > Thanks, > .Erez > > -----Original Message----- > From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden] > ] On Behalf Of Supalov, Alexander > Sent: Monday, March 16, 2009 3:43 AM > To: MPI 2.2 > Subject: Re: [Mpi-22] Ticket #46: Add const Keyword to the C > bindings-implementation > > Hi, > > I most respectively disagree with the "Const simply captures the > previously required semantics of the interface in the syntax" > statement. The standard did not prohibit a reversible in-place > modification of the send buffer until the very recent change related > to #45. Adding const on top will automatically make MPI not the > greatest common denominator - some internal networking interfaces > that were mentioned in this trail will suddenly become "obsolete". > That is, most of the existing networking interfaces will. > > Best regards. > > Alexander > > -----Original Message----- > From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden] > ] On Behalf Of William Gropp > Sent: Sunday, March 15, 2009 9:59 PM > To: MPI 2.2 > Subject: Re: [Mpi-22] Ticket #46: Add const Keyword to the C > bindings-implementation > > Actually, MPI has taken the lead in a number of areas, including > cross- > language compatibility, to say nothing of the existence of MPI itself. > > And MPI has taken great pains to be the *greatest* common > denominator. Const simply captures the previously required semantics > of the interface in the syntax, and is consistent with the MPI spirit. > > Bill > On Mar 13, 2009, at 2:17 PM, Jeff Squyres wrote: > > > On Mar 13, 2009, at 9:40 AM, William Gropp wrote: > > > >> First, this is a chicken-and-egg problem; the low level > >> interfaces are unlikely to change to add const unless there is some > >> application that will take advantage of that (and internally, if > >> their > >> semantics allows it and their compiler can support it, they'll just > >> cast to add the const). So MPI should take the lead, particularly > >> since using const also provides information to the user. > >> > > > > This is a very scary statement to me. MPI has not traditionally > > "taken the lead" on forcing issues with other interfaces (look where > > it has gotten us with Fortran...). Indeed, MPI has taken great > pains > > to be the lowest common denominator across a variety of language, > > platforms, and operating systems. > > > > -- > > Jeff Squyres > > Cisco Systems > > > > _______________________________________________ > > mpi-22 mailing list > > mpi-22_at_[hidden] > > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 > > William Gropp > Deputy Director for Research > Institute for Advanced Computing Applications and Technologies > Paul and Cynthia Saylor Professor of Computer Science > University of Illinois Urbana-Champaign > > > > > _______________________________________________ > mpi-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 > --------------------------------------------------------------------- > Intel GmbH > Dornacher Strasse 1 > 85622 Feldkirchen/Muenchen Germany > Sitz der Gesellschaft: Feldkirchen bei Muenchen > Geschaeftsfuehrer: Douglas Lusk, Peter Gleissner, Hannes Schwaderer > Registergericht: Muenchen HRB 47456 Ust.-IdNr. > VAT Registration No.: DE129385895 > Citibank Frankfurt (BLZ 502 109 00) 600119052 > > 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-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 > > > _______________________________________________ > mpi-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 > --------------------------------------------------------------------- > Intel GmbH > Dornacher Strasse 1 > 85622 Feldkirchen/Muenchen Germany > Sitz der Gesellschaft: Feldkirchen bei Muenchen > Geschaeftsfuehrer: Douglas Lusk, Peter Gleissner, Hannes Schwaderer > Registergericht: Muenchen HRB 47456 Ust.-IdNr. > VAT Registration No.: DE129385895 > Citibank Frankfurt (BLZ 502 109 00) 600119052 > > 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-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 > > > _______________________________________________ > mpi-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 > --------------------------------------------------------------------- > Intel GmbH > Dornacher Strasse 1 > 85622 Feldkirchen/Muenchen Germany > Sitz der Gesellschaft: Feldkirchen bei Muenchen > Geschaeftsfuehrer: Douglas Lusk, Peter Gleissner, Hannes Schwaderer > Registergericht: Muenchen HRB 47456 Ust.-IdNr. > VAT Registration No.: DE129385895 > Citibank Frankfurt (BLZ 502 109 00) 600119052 > > 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-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 > > > _______________________________________________ > mpi-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 > --------------------------------------------------------------------- > Intel GmbH > Dornacher Strasse 1 > 85622 Feldkirchen/Muenchen Germany > Sitz der Gesellschaft: Feldkirchen bei Muenchen > Geschaeftsfuehrer: Douglas Lusk, Peter Gleissner, Hannes Schwaderer > Registergericht: Muenchen HRB 47456 Ust.-IdNr. > VAT Registration No.: DE129385895 > Citibank Frankfurt (BLZ 502 109 00) 600119052 > > 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-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 > > > _______________________________________________ > mpi-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 -- Jeff Squyres Cisco Systems _______________________________________________ mpi-22 mailing list mpi-22_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 --------------------------------------------------------------------- Intel GmbH Dornacher Strasse 1 85622 Feldkirchen/Muenchen Germany Sitz der Gesellschaft: Feldkirchen bei Muenchen Geschaeftsfuehrer: Douglas Lusk, Peter Gleissner, Hannes Schwaderer Registergericht: Muenchen HRB 47456 Ust.-IdNr. VAT Registration No.: DE129385895 Citibank Frankfurt (BLZ 502 109 00) 600119052 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-22 mailing list mpi-22_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 _______________________________________________ mpi-22 mailing list mpi-22_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 --------------------------------------------------------------------- Intel GmbH Dornacher Strasse 1 85622 Feldkirchen/Muenchen Germany Sitz der Gesellschaft: Feldkirchen bei Muenchen Geschaeftsfuehrer: Douglas Lusk, Peter Gleissner, Hannes Schwaderer Registergericht: Muenchen HRB 47456 Ust.-IdNr. VAT Registration No.: DE129385895 Citibank Frankfurt (BLZ 502 109 00) 600119052 This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. From bwbarre at [hidden] Wed Mar 18 17:38:55 2009 From: bwbarre at [hidden] (Barrett, Brian W) Date: Wed, 18 Mar 2009 16:38:55 -0600 Subject: [Mpi-22] Ticket #46: Add const Keyword to the C bindings-implementation In-Reply-To: <23158_1237407146_n2IKCOVq024301_928CFBE8E7CB0040959E56B4EA41A77E87B75280@irsmsx504.ger.corp.intel.com> Message-ID: All - I agree in sentiment that the const proposal (#46) is a good idea, but I have a number of concerns with it for the 2.2 effort. While the diff style increases the patch size, the patch for MPICH is still rather large. To properly thread const through an implementation like Open MPI, which does not use const in the intermediate layers, would be even more significant. Further, to take advantage of any interfaces which do allow use of const would require significant data structure changes inside Open MPI. So in terms of work to properly implement this proposal, I have concerns about this proposal's appropriateness for MPI 2.2, which is supposed to be for items which "do not require large implementation changes." >From a procedural standpoint, choices made in this proposal worry me and set a poor precedent. Proposal #46 is incomplete - in order to be a proper change, additional proposals are necessary (#129 & #130). Those tickets are both behind in the process compared to #46 and therefore can not even have second vote in the same session as #46. I would feel more comfortable if the tickets were combined into one and started with the first reading rather than the current approach. As I understand it, there is still time for that choice to be made, and it certainly could have two meetings ago. Finally, and least significantly, I have concerns about the fact that there are lower interfaces which will always require casting away const, and will be (for all practical purposes) unable to change. The BSD socket layer when iovecs are in use is a perfect example - the interface is so deeply established that changing the interface to support const sends (which would likely require a new data structure) is not feasible. My preference would be to remove this proposal from consideration from 2.2, correct it to be a single proposal, and submit it for 3.0. By then we'll have more validation the send buffer access restrictions removed in 2.2 were the right choice, we could fix some of the corner cases in this proposal, such as user callbacks, and we give MPI implementers time to experiment with the proposal in their MPI implementations. Further, I don't believe that there's a technical reason an MPI implementation couldn't begin marking those buffers as const today - it shouldn't break user applications and would allow tightly integrated stacks to avoid some casting ugliness internally. Brian -- Brian W. Barrett Dept. 1423: Scalable System Software Sandia National Laboratories From jsquyres at [hidden] Wed Mar 18 18:34:20 2009 From: jsquyres at [hidden] (Jeff Squyres jsquyres) Date: Wed, 18 Mar 2009 19:34:20 -0400 Subject: [Mpi-22] Ticket #46: Add const Keyword to the C bindings-implementation In-Reply-To: <[Mpi-22] Ticket #46: Add const Keyword to the C bindings-implementation> Message-ID: Well said. Seconded. And let's ditch the c++ bindings, too. ;) -jms Sent from my PDA. No type good. ----- Original Message ----- From: mpi-22-bounces_at_[hidden] To: MPI 2.2 Sent: Wed Mar 18 18:38:55 2009 Subject: Re: [Mpi-22] Ticket #46: Add const Keyword to the C bindings-implementation All - I agree in sentiment that the const proposal (#46) is a good idea, but I have a number of concerns with it for the 2.2 effort. While the diff style increases the patch size, the patch for MPICH is still rather large. To properly thread const through an implementation like Open MPI, which does not use const in the intermediate layers, would be even more significant. Further, to take advantage of any interfaces which do allow use of const would require significant data structure changes inside Open MPI. So in terms of work to properly implement this proposal, I have concerns about this proposal's appropriateness for MPI 2.2, which is supposed to be for items which "do not require large implementation changes." >From a procedural standpoint, choices made in this proposal worry me and set a poor precedent. Proposal #46 is incomplete - in order to be a proper change, additional proposals are necessary (#129 & #130). Those tickets are both behind in the process compared to #46 and therefore can not even have second vote in the same session as #46. I would feel more comfortable if the tickets were combined into one and started with the first reading rather than the current approach. As I understand it, there is still time for that choice to be made, and it certainly could have two meetings ago. Finally, and least significantly, I have concerns about the fact that there are lower interfaces which will always require casting away const, and will be (for all practical purposes) unable to change. The BSD socket layer when iovecs are in use is a perfect example - the interface is so deeply established that changing the interface to support const sends (which would likely require a new data structure) is not feasible. My preference would be to remove this proposal from consideration from 2.2, correct it to be a single proposal, and submit it for 3.0. By then we'll have more validation the send buffer access restrictions removed in 2.2 were the right choice, we could fix some of the corner cases in this proposal, such as user callbacks, and we give MPI implementers time to experiment with the proposal in their MPI implementations. Further, I don't believe that there's a technical reason an MPI implementation couldn't begin marking those buffers as const today - it shouldn't break user applications and would allow tightly integrated stacks to avoid some casting ugliness internally. Brian -- Brian W. Barrett Dept. 1423: Scalable System Software Sandia National Laboratories _______________________________________________ mpi-22 mailing list mpi-22_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 * -------------- next part -------------- An HTML attachment was scrubbed... URL: From buntinas at [hidden] Wed Mar 18 20:15:25 2009 From: buntinas at [hidden] (Darius Buntinas) Date: Wed, 18 Mar 2009 20:15:25 -0500 Subject: [Mpi-22] Ticket #46: Add const Keyword to the C bindings-implementation In-Reply-To: Message-ID: <49C19CAD.6000405@mcs.anl.gov> I just want to point out that casting away the const for low-level interfaces is really a non issue. Putting a const on the send buffer parameter in an MPI function prototype indicates a contract with the user that the MPI implementation will not change the contents of the buffer referenced from that function. As long as the MPI implementor knows that a routine called by the library will not modify the buffer it's OK to cast away the const. E.g., the POSIX standard tells you that writev must not change the contents of the buffer, so casting away const is fine. Sure, that means that the MPI implementor has to be more careful when casting away const to ensure that the function being called won't modify the buffer. But the whole point of the proposal is so that the _MPI_user_ doesn't need to do this and instead can count on the compiler to do the check. -d From jsquyres at [hidden] Wed Mar 18 20:24:24 2009 From: jsquyres at [hidden] (Jeff Squyres) Date: Wed, 18 Mar 2009 21:24:24 -0400 Subject: [Mpi-22] Ticket #46: Add const Keyword to the Cbindings-implementation In-Reply-To: <49C19CAD.6000405@mcs.anl.gov> Message-ID: Can someone explain what the rush is to do this for 2.2? Is there a problem with putting this issue off until 3.0? On Mar 18, 2009, at 9:15 PM, Darius Buntinas wrote: > > I just want to point out that casting away the const for low-level > interfaces is really a non issue. Putting a const on the send buffer > parameter in an MPI function prototype indicates a contract with the > user that the MPI implementation will not change the contents of the > buffer referenced from that function. As long as the MPI implementor > knows that a routine called by the library will not modify the buffer > it's OK to cast away the const. E.g., the POSIX standard tells you > that > writev must not change the contents of the buffer, so casting away > const > is fine. > > Sure, that means that the MPI implementor has to be more careful when > casting away const to ensure that the function being called won't > modify > the buffer. But the whole point of the proposal is so that the > _MPI_user_ doesn't need to do this and instead can count on the > compiler > to do the check. > > -d > _______________________________________________ > mpi-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 -- Jeff Squyres Cisco Systems From buntinas at [hidden] Wed Mar 18 22:16:07 2009 From: buntinas at [hidden] (Darius Buntinas) Date: Wed, 18 Mar 2009 22:16:07 -0500 Subject: [Mpi-22] Ticket #46: Add const Keyword to the Cbindings-implementation In-Reply-To: Message-ID: <49C1B8F7.6030202@mcs.anl.gov> Sorry Jeff, I didn't think I was rushing anything. I'm not saying we shouldn't put it off till 3.0, but I was challenging the lack of const qualifiers on low-level interfaces as a reason to do so. For the record, I do think that the fact that it would require significant changes in the Open MPI implementation is a legitimate reason to consider postponing this to 3.0. But we shouldn't wait till POSIX changes writev to use const qualifiers. I wasn't at the last forum meeting, so maybe I missed discussion on this. So if I'm missing some context, I apologize. I'm not trying to rush this into 2.2, but I guess I'm not in a rush to push it off to 3.0 either. -d On 03/18/2009 08:24 PM, Jeff Squyres wrote: > Can someone explain what the rush is to do this for 2.2? > > Is there a problem with putting this issue off until 3.0? > > > > On Mar 18, 2009, at 9:15 PM, Darius Buntinas wrote: > >> >> I just want to point out that casting away the const for low-level >> interfaces is really a non issue. Putting a const on the send buffer >> parameter in an MPI function prototype indicates a contract with the >> user that the MPI implementation will not change the contents of the >> buffer referenced from that function. As long as the MPI implementor >> knows that a routine called by the library will not modify the buffer >> it's OK to cast away the const. E.g., the POSIX standard tells you that >> writev must not change the contents of the buffer, so casting away const >> is fine. >> >> Sure, that means that the MPI implementor has to be more careful when >> casting away const to ensure that the function being called won't modify >> the buffer. But the whole point of the proposal is so that the >> _MPI_user_ doesn't need to do this and instead can count on the compiler >> to do the check. >> >> -d >> _______________________________________________ >> mpi-22 mailing list >> mpi-22_at_[hidden] >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 > > From bronis at [hidden] Wed Mar 18 23:03:49 2009 From: bronis at [hidden] (Bronis R. de Supinski) Date: Wed, 18 Mar 2009 21:03:49 -0700 (PDT) Subject: [Mpi-22] Ticket #46: Add const Keyword to the Cbindings-implementation In-Reply-To: <49C1B8F7.6030202@mcs.anl.gov> Message-ID: All: I have been quiet on this debate but I am to the point that I feel a need to speak up. I think the "significant changes" reason is a canard (I think Brian and Jeff believe it but it is still a red herring for the most part). The changes to support it are not significant. You can implement it by casting it away early. That does NOT eliminate the benefit to the user. Moving any casting that occurs lower does not change the user benefit; it changes the implementer CONFIDENCE that they are in fact conformant. But, if you are conformant you can cast it away immediately without error. Simply put, I have seen no convincing argument that any implementation actually requires significant changes. If implementers want increased confidence, they can delay obtaining that until the time frame they would provide their mistaken level required for conformance for 3.0. Bronis On Wed, 18 Mar 2009, Darius Buntinas wrote: > > Sorry Jeff, I didn't think I was rushing anything. I'm not saying we > shouldn't put it off till 3.0, but I was challenging the lack of const > qualifiers on low-level interfaces as a reason to do so. > > For the record, I do think that the fact that it would require > significant changes in the Open MPI implementation is a legitimate > reason to consider postponing this to 3.0. But we shouldn't wait till > POSIX changes writev to use const qualifiers. > > I wasn't at the last forum meeting, so maybe I missed discussion on > this. So if I'm missing some context, I apologize. I'm not trying to > rush this into 2.2, but I guess I'm not in a rush to push it off to 3.0 > either. > > -d > > On 03/18/2009 08:24 PM, Jeff Squyres wrote: > > Can someone explain what the rush is to do this for 2.2? > > > > Is there a problem with putting this issue off until 3.0? > > > > > > > > On Mar 18, 2009, at 9:15 PM, Darius Buntinas wrote: > > > >> > >> I just want to point out that casting away the const for low-level > >> interfaces is really a non issue. Putting a const on the send buffer > >> parameter in an MPI function prototype indicates a contract with the > >> user that the MPI implementation will not change the contents of the > >> buffer referenced from that function. As long as the MPI implementor > >> knows that a routine called by the library will not modify the buffer > >> it's OK to cast away the const. E.g., the POSIX standard tells you that > >> writev must not change the contents of the buffer, so casting away const > >> is fine. > >> > >> Sure, that means that the MPI implementor has to be more careful when > >> casting away const to ensure that the function being called won't modify > >> the buffer. But the whole point of the proposal is so that the > >> _MPI_user_ doesn't need to do this and instead can count on the compiler > >> to do the check. > >> > >> -d > >> _______________________________________________ > >> mpi-22 mailing list > >> mpi-22_at_[hidden] > >> http:// lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 > > > > > _______________________________________________ > mpi-22 mailing list > mpi-22_at_[hidden] > http:// lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 > > From jsquyres at [hidden] Thu Mar 19 06:58:25 2009 From: jsquyres at [hidden] (Jeff Squyres) Date: Thu, 19 Mar 2009 07:58:25 -0400 Subject: [Mpi-22] Ticket #46: Add const Keyword tothe Cbindings-implementation In-Reply-To: <49C1B8F7.6030202@mcs.anl.gov> Message-ID: My post was not a direct reaction to Darius' post; it was more in reaction to the general sense of "we need to pass this" that I've been (perhaps incorrectly) reading into some of the replies. Brian raised several good points in his mail about both procedural and technical issues that I agree need to be addressed before this issue can be passed into law. I see no reason to rush this into 2.2. On Mar 18, 2009, at 11:16 PM, Darius Buntinas wrote: > > Sorry Jeff, I didn't think I was rushing anything. I'm not saying we > shouldn't put it off till 3.0, but I was challenging the lack of const > qualifiers on low-level interfaces as a reason to do so. > > For the record, I do think that the fact that it would require > significant changes in the Open MPI implementation is a legitimate > reason to consider postponing this to 3.0. But we shouldn't wait till > POSIX changes writev to use const qualifiers. > > I wasn't at the last forum meeting, so maybe I missed discussion on > this. So if I'm missing some context, I apologize. I'm not trying to > rush this into 2.2, but I guess I'm not in a rush to push it off to > 3.0 > either. > > -d > > On 03/18/2009 08:24 PM, Jeff Squyres wrote: > > Can someone explain what the rush is to do this for 2.2? > > > > Is there a problem with putting this issue off until 3.0? > > > > > > > > On Mar 18, 2009, at 9:15 PM, Darius Buntinas wrote: > > > >> > >> I just want to point out that casting away the const for low-level > >> interfaces is really a non issue. Putting a const on the send > buffer > >> parameter in an MPI function prototype indicates a contract with > the > >> user that the MPI implementation will not change the contents of > the > >> buffer referenced from that function. As long as the MPI > implementor > >> knows that a routine called by the library will not modify the > buffer > >> it's OK to cast away the const. E.g., the POSIX standard tells > you that > >> writev must not change the contents of the buffer, so casting > away const > >> is fine. > >> > >> Sure, that means that the MPI implementor has to be more careful > when > >> casting away const to ensure that the function being called won't > modify > >> the buffer. But the whole point of the proposal is so that the > >> _MPI_user_ doesn't need to do this and instead can count on the > compiler > >> to do the check. > >> > >> -d > >> _______________________________________________ > >> mpi-22 mailing list > >> mpi-22_at_[hidden] > >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 > > > > > _______________________________________________ > mpi-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 > -- Jeff Squyres Cisco Systems From jsquyres at [hidden] Thu Mar 19 07:19:32 2009 From: jsquyres at [hidden] (Jeff Squyres) Date: Thu, 19 Mar 2009 08:19:32 -0400 Subject: [Mpi-22] Ticket #46: Add const Keywordto the Cbindings-implementation In-Reply-To: Message-ID: On Mar 19, 2009, at 12:03 AM, Bronis R. de Supinski wrote: > I have been quiet on this debate but I am to the point > that I feel a need to speak up. I think the "significant > changes" reason is a canard (I think Brian and Jeff > believe it but it is still a red herring for the most > part). The changes to support it are not significant. > You can implement it by casting it away early. > The changes *are* significant. I count 90 top-level MPI API functions that are affected by this proposal. The bar for 2.2 is "trivial" implementation efforts, no? This is not trivial. The MPICH diff was ~10,000 lines. Apparently, they chose to go above and beyond the requirement and propagate const to lower layers (vs. casting it away immediately), but still -- if a 2.2 change can inspire a 10,000 line diff, that just seems like it doesn't meet the spirit of the "trivial" implementation requirement. Indeed, in doing the "simple" cast-it-away-immediately approach implementation, editing and testing each of the 90 functions will require a good amount of effort. Sure, the first-wave addition of "const" across all of the affected functions is probably relatively easy -- one code monkey and several hours. But how long will it take you to find the one place where you put "const" in the wrong location? How long will it take you to write new tests to verify the const-ness in all the right places? To be clear: it's a "not significant" change to a code monkey. But try to tell your QA guys that this is not significant -- they'll freak out. Hence, if you take the overall scope of both the change and the additional testing to validate this change, this is a large scale implementation effort. I just don't see what the rush is to get this into 2.2. I think Brian makes several good arguments, one of which is: those who want const can put it in today. It hypothetically shouldn't break any existing user codes (this is the code monkey in me talking, not the QA rep), and those implementors who want it for stronger contracts can have it. -- Jeff Squyres Cisco Systems From erezh at [hidden] Thu Mar 19 10:50:37 2009 From: erezh at [hidden] (Erez Haba) Date: Thu, 19 Mar 2009 08:50:37 -0700 Subject: [Mpi-22] Ticket #46: Add const Keywordto the Cbindings-implementation In-Reply-To: Message-ID: <6B68D01C00C9994A8E150183E62A119E7B733A55DD@NA-EXMSG-C105.redmond.corp.microsoft.com> Jeff, I don't understand why you ignore all the work that has been done with this ticket and suggest your own metric. Was the information I provided unreliable or untrue? As I said, it took me about 2.5h to implement the entire change on the MSMPI code base; yes there were many internal functions that had const in it, but also many that did not. I don't think that by any measure this is a significant work for any implementer. More than that, this interface change was tested using the ANL test suite and the Intel complete test suite, without a single compile or runtime error over multiple platforms and compilers. Again, this was not a significant work item; and I believe that OpenMPI has a regression suite that crosses platform and compilers which is easy to run (as you described to me many times). With this information that I have already provided before, I don't understand your claims; unless you think that they are biased and unreliable. Hence this ticket completely meets MPI 2.2 requirements in scope and backward compatibility. Thanks, .Erez -----Original Message----- From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Jeff Squyres Sent: Thursday, March 19, 2009 5:20 AM To: Bronis R. de Supinski; MPI 2.2 Subject: Re: [Mpi-22] Ticket #46: Add const Keywordto the Cbindings-implementation On Mar 19, 2009, at 12:03 AM, Bronis R. de Supinski wrote: > I have been quiet on this debate but I am to the point > that I feel a need to speak up. I think the "significant > changes" reason is a canard (I think Brian and Jeff > believe it but it is still a red herring for the most > part). The changes to support it are not significant. > You can implement it by casting it away early. > The changes *are* significant. I count 90 top-level MPI API functions that are affected by this proposal. The bar for 2.2 is "trivial" implementation efforts, no? This is not trivial. The MPICH diff was ~10,000 lines. Apparently, they chose to go above and beyond the requirement and propagate const to lower layers (vs. casting it away immediately), but still -- if a 2.2 change can inspire a 10,000 line diff, that just seems like it doesn't meet the spirit of the "trivial" implementation requirement. Indeed, in doing the "simple" cast-it-away-immediately approach implementation, editing and testing each of the 90 functions will require a good amount of effort. Sure, the first-wave addition of "const" across all of the affected functions is probably relatively easy -- one code monkey and several hours. But how long will it take you to find the one place where you put "const" in the wrong location? How long will it take you to write new tests to verify the const-ness in all the right places? To be clear: it's a "not significant" change to a code monkey. But try to tell your QA guys that this is not significant -- they'll freak out. Hence, if you take the overall scope of both the change and the additional testing to validate this change, this is a large scale implementation effort. I just don't see what the rush is to get this into 2.2. I think Brian makes several good arguments, one of which is: those who want const can put it in today. It hypothetically shouldn't break any existing user codes (this is the code monkey in me talking, not the QA rep), and those implementors who want it for stronger contracts can have it. -- Jeff Squyres Cisco Systems _______________________________________________ mpi-22 mailing list mpi-22_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 From bwbarre at [hidden] Thu Mar 19 11:11:03 2009 From: bwbarre at [hidden] (Barrett, Brian W) Date: Thu, 19 Mar 2009 10:11:03 -0600 Subject: [Mpi-22] Ticket #46: Add const Keywordto the Cbindings-implementation In-Reply-To: <13718_1237477914_n2JFOLWg013701_6B68D01C00C9994A8E150183E62A119E7B733A55DD@NA-EXMSG-C105.redmond.corp.microsoft.com> Message-ID: I believe the procedural arguments are the most worrying thing, and they haven't been commented on, which is a bit worrying. Nor has the fact that the proposal, even with *TWO* corrections which are separate proposals, still isn't complete (in that user callbacks which should be const aren't because we're rushing this through 2.2 instead of working in the 3.0 framework, where we could make minor user code changes like correcting const in the callbacks. But in response to your question, Open MPI does have a test suite, and we can use the ANL and Intel test suites. However, none of them test that we're handing const correctly. They test that the behavior according to MPI-2.1 is correct. They don't check that there are const keywords in the right place. Such a change would be fairly large (to the test suite, that is), which only adds to the "largeness" of this patch. We're not ignoring your statement of 2.5 hours. But I don't think that's a realistic metric for doing the implementation, updating/developing test cases, and properly testing on a variety of compilers. Both Jeff and I have asked essentially the same question, without a reasonable answer. Why are we pushing a proposal with known procedural issues and possibly oversized implementation into 2.2 when it can easily be pushed to 3.0? What's the rush - let's do this completely and correctly the first time, rather than looking like fools in two months when it turns out we did something wrong. Brian On 3/19/09 9:50 , "Erez Haba" wrote: > Jeff, I don't understand why you ignore all the work that has been done with > this ticket and suggest your own metric. Was the information I provided > unreliable or untrue? > > As I said, it took me about 2.5h to implement the entire change on the MSMPI > code base; yes there were many internal functions that had const in it, but > also many that did not. I don't think that by any measure this is a > significant work for any implementer. > > More than that, this interface change was tested using the ANL test suite and > the Intel complete test suite, without a single compile or runtime error over > multiple platforms and compilers. Again, this was not a significant work item; > and I believe that OpenMPI has a regression suite that crosses platform and > compilers which is easy to run (as you described to me many times). > > > With this information that I have already provided before, I don't understand > your claims; unless you think that they are biased and unreliable. > > Hence this ticket completely meets MPI 2.2 requirements in scope and backward > compatibility. > > Thanks, > .Erez > > -----Original Message----- > From: mpi-22-bounces_at_[hidden] > [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Jeff Squyres > Sent: Thursday, March 19, 2009 5:20 AM > To: Bronis R. de Supinski; MPI 2.2 > Subject: Re: [Mpi-22] Ticket #46: Add const Keywordto the > Cbindings-implementation > > On Mar 19, 2009, at 12:03 AM, Bronis R. de Supinski wrote: > >> I have been quiet on this debate but I am to the point >> that I feel a need to speak up. I think the "significant >> changes" reason is a canard (I think Brian and Jeff >> believe it but it is still a red herring for the most >> part). The changes to support it are not significant. >> You can implement it by casting it away early. >> > > > The changes *are* significant. I count 90 top-level MPI API functions > that are affected by this proposal. > > The bar for 2.2 is "trivial" implementation efforts, no? This is not > trivial. The MPICH diff was ~10,000 lines. Apparently, they chose to > go above and beyond the requirement and propagate const to lower > layers (vs. casting it away immediately), but still -- if a 2.2 change > can inspire a 10,000 line diff, that just seems like it doesn't meet > the spirit of the "trivial" implementation requirement. > > Indeed, in doing the "simple" cast-it-away-immediately approach > implementation, editing and testing each of the 90 functions will > require a good amount of effort. Sure, the first-wave addition of > "const" across all of the affected functions is probably relatively > easy -- one code monkey and several hours. But how long will it take > you to find the one place where you put "const" in the wrong > location? How long will it take you to write new tests to verify the > const-ness in all the right places? To be clear: it's a "not > significant" change to a code monkey. But try to tell your QA guys > that this is not significant -- they'll freak out. > > Hence, if you take the overall scope of both the change and the > additional testing to validate this change, this is a large scale > implementation effort. I just don't see what the rush is to get this > into 2.2. > > I think Brian makes several good arguments, one of which is: those who > want const can put it in today. It hypothetically shouldn't break any > existing user codes (this is the code monkey in me talking, not the QA > rep), and those implementors who want it for stronger contracts can > have it. > > -- > Jeff Squyres > Cisco Systems > > _______________________________________________ > mpi-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 > > > _______________________________________________ > mpi-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 > -- Brian W. Barrett Dept. 1423: Scalable System Software Sandia National Laboratories From Terry.Dontje at [hidden] Thu Mar 19 11:15:03 2009 From: Terry.Dontje at [hidden] (Terry Dontje) Date: Thu, 19 Mar 2009 12:15:03 -0400 Subject: [Mpi-22] Ticket #46: Add const Keywordto the Cbindings-implementation In-Reply-To: <6B68D01C00C9994A8E150183E62A119E7B733A55DD@NA-EXMSG-C105.redmond.corp.microsoft.com> Message-ID: <49C26F87.2080702@sun.com> I am not Jeff and I do not play him on tv but I felt the need to interject my 2 cents. Erez Haba wrote: > Jeff, I don't understand why you ignore all the work that has been done with this ticket and suggest your own metric. Was the information I provided unreliable or untrue? > > Possibly but it definitely is biased IMO. > As I said, it took me about 2.5h to implement the entire change on the MSMPI code base; yes there were many internal functions that had const in it, but also many that did not. I don't think that by any measure this is a significant work for any implementer. > > Isn't MSMPI based on MPICH? If so how much of the previous work done to support const did you leverage or did you truly reinvent the same wheel MPICH developers did? I guess I find it pretty amazing the applying 10,000 lines of changes and then validating them took you 2.5 hours. > More than that, this interface change was tested using the ANL test suite and the Intel complete test suite, without a single compile or runtime error over multiple platforms and compilers. Again, this was not a significant work item; and I believe that OpenMPI has a regression suite that crosses platform and compilers which is easy to run (as you described to me many times). > > > Do the ANL tests and any others really test const-ness without changes. Or are you saying the ANL tests already do explicit testing of const-ness on the right parameters? > With this information that I have already provided before, I don't understand your claims; unless you think that they are biased and unreliable. > > I would say your information is a useful datapoint but I am curious if what you did really was the full conversion of your MPI implementation to handle this change. > Hence this ticket completely meets MPI 2.2 requirements in scope and backward compatibility. > > For MPICH based implementations I agree it does. For Open MPI I think it is still questionable. I guess I am still interested in the reasoning why shoving this ticket into 2.2 is such a high priority? --td > Thanks, > .Erez > > -----Original Message----- > From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Jeff Squyres > Sent: Thursday, March 19, 2009 5:20 AM > To: Bronis R. de Supinski; MPI 2.2 > Subject: Re: [Mpi-22] Ticket #46: Add const Keywordto the Cbindings-implementation > > On Mar 19, 2009, at 12:03 AM, Bronis R. de Supinski wrote: > > >> I have been quiet on this debate but I am to the point >> that I feel a need to speak up. I think the "significant >> changes" reason is a canard (I think Brian and Jeff >> believe it but it is still a red herring for the most >> part). The changes to support it are not significant. >> You can implement it by casting it away early. >> >> > > > The changes *are* significant. I count 90 top-level MPI API functions > that are affected by this proposal. > > The bar for 2.2 is "trivial" implementation efforts, no? This is not > trivial. The MPICH diff was ~10,000 lines. Apparently, they chose to > go above and beyond the requirement and propagate const to lower > layers (vs. casting it away immediately), but still -- if a 2.2 change > can inspire a 10,000 line diff, that just seems like it doesn't meet > the spirit of the "trivial" implementation requirement. > > Indeed, in doing the "simple" cast-it-away-immediately approach > implementation, editing and testing each of the 90 functions will > require a good amount of effort. Sure, the first-wave addition of > "const" across all of the affected functions is probably relatively > easy -- one code monkey and several hours. But how long will it take > you to find the one place where you put "const" in the wrong > location? How long will it take you to write new tests to verify the > const-ness in all the right places? To be clear: it's a "not > significant" change to a code monkey. But try to tell your QA guys > that this is not significant -- they'll freak out. > > Hence, if you take the overall scope of both the change and the > additional testing to validate this change, this is a large scale > implementation effort. I just don't see what the rush is to get this > into 2.2. > > I think Brian makes several good arguments, one of which is: those who > want const can put it in today. It hypothetically shouldn't break any > existing user codes (this is the code monkey in me talking, not the QA > rep), and those implementors who want it for stronger contracts can > have it. > > From erezh at [hidden] Thu Mar 19 17:00:33 2009 From: erezh at [hidden] (Erez Haba) Date: Thu, 19 Mar 2009 15:00:33 -0700 Subject: [Mpi-22] Ticket #46: Add const Keyword to the C bindings-implementation In-Reply-To: <49C26F87.2080702@sun.com> Message-ID: <6B68D01C00C9994A8E150183E62A119E7B733A5917@NA-EXMSG-C105.redmond.corp.microsoft.com> Terry, I'm truly sorry that you find the information that I provide as unreliable. I know that I'm not part of the 'trusted' OpenMPI clan and I wish that there was something I could do to convince you otherwise. If you recall the last forum meeting, I did a complete implementation of the 'const' ticket during that meeting. (and did let everyone know about it). That was an implementation from scratch that did trickle down the constness to all the internal functions of MSMPI. Indeed I did not do any runtime testing at that meeting, it did happen later. However, since MSMPI is not an open source project, I asked the friends at ANL to re-implement it over MPICH2 and make the source available. Since you might not trust my word, you may ask Rajeev and other friends at ANL about this. The tests conducted were checking for regression. Hence, any program that compiled and run correctly before the const change did compile and run correctly after the const change; with multiple compiler and multiple operating systems. We did not conduct any direct tests that are checking the 'constness' of the interface. I don't really know how you check for constness? Do you check that the buffer was not modified? Well that would be testing ticket #45 (send buffer access) and not ticket #46. Do you check that you pass const in and you don't get a compiler error? that relatively simple and I don't think it buys you much (except it verifies that you put the const in all the right places on the interface API). As to rushing this in, I'm curious, this ticket is there for over a year; already implemented twice and tested by two different bodies. Is this really rushing it in? As to the procedural issues. This ticket is one of the first tickets that we had in the system, and of-course as the mpi forum body we did learn a thing or two in that process, unfortunately, first implemented with that ticket. So yes there would be issues. I think that we can resolve these 'issues' but puting dependency on passing this ticket given that we accept the other two corrections to the ticket. Thanks, .Erez -----Original Message----- From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Terry Dontje Sent: Thursday, March 19, 2009 9:15 AM To: MPI 2.2 Subject: Re: [Mpi-22] Ticket #46: Add const Keywordto the Cbindings-implementation I am not Jeff and I do not play him on tv but I felt the need to interject my 2 cents. Erez Haba wrote: > Jeff, I don't understand why you ignore all the work that has been done with this ticket and suggest your own metric. Was the information I provided unreliable or untrue? > > Possibly but it definitely is biased IMO. > As I said, it took me about 2.5h to implement the entire change on the MSMPI code base; yes there were many internal functions that had const in it, but also many that did not. I don't think that by any measure this is a significant work for any implementer. > > Isn't MSMPI based on MPICH? If so how much of the previous work done to support const did you leverage or did you truly reinvent the same wheel MPICH developers did? I guess I find it pretty amazing the applying 10,000 lines of changes and then validating them took you 2.5 hours. > More than that, this interface change was tested using the ANL test suite and the Intel complete test suite, without a single compile or runtime error over multiple platforms and compilers. Again, this was not a significant work item; and I believe that OpenMPI has a regression suite that crosses platform and compilers which is easy to run (as you described to me many times). > > > Do the ANL tests and any others really test const-ness without changes. Or are you saying the ANL tests already do explicit testing of const-ness on the right parameters? > With this information that I have already provided before, I don't understand your claims; unless you think that they are biased and unreliable. > > I would say your information is a useful datapoint but I am curious if what you did really was the full conversion of your MPI implementation to handle this change. > Hence this ticket completely meets MPI 2.2 requirements in scope and backward compatibility. > > For MPICH based implementations I agree it does. For Open MPI I think it is still questionable. I guess I am still interested in the reasoning why shoving this ticket into 2.2 is such a high priority? --td > Thanks, > .Erez > > -----Original Message----- > From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Jeff Squyres > Sent: Thursday, March 19, 2009 5:20 AM > To: Bronis R. de Supinski; MPI 2.2 > Subject: Re: [Mpi-22] Ticket #46: Add const Keywordto the Cbindings-implementation > > On Mar 19, 2009, at 12:03 AM, Bronis R. de Supinski wrote: > > >> I have been quiet on this debate but I am to the point >> that I feel a need to speak up. I think the "significant >> changes" reason is a canard (I think Brian and Jeff >> believe it but it is still a red herring for the most >> part). The changes to support it are not significant. >> You can implement it by casting it away early. >> >> > > > The changes *are* significant. I count 90 top-level MPI API functions > that are affected by this proposal. > > The bar for 2.2 is "trivial" implementation efforts, no? This is not > trivial. The MPICH diff was ~10,000 lines. Apparently, they chose to > go above and beyond the requirement and propagate const to lower > layers (vs. casting it away immediately), but still -- if a 2.2 change > can inspire a 10,000 line diff, that just seems like it doesn't meet > the spirit of the "trivial" implementation requirement. > > Indeed, in doing the "simple" cast-it-away-immediately approach > implementation, editing and testing each of the 90 functions will > require a good amount of effort. Sure, the first-wave addition of > "const" across all of the affected functions is probably relatively > easy -- one code monkey and several hours. But how long will it take > you to find the one place where you put "const" in the wrong > location? How long will it take you to write new tests to verify the > const-ness in all the right places? To be clear: it's a "not > significant" change to a code monkey. But try to tell your QA guys > that this is not significant -- they'll freak out. > > Hence, if you take the overall scope of both the change and the > additional testing to validate this change, this is a large scale > implementation effort. I just don't see what the rush is to get this > into 2.2. > > I think Brian makes several good arguments, one of which is: those who > want const can put it in today. It hypothetically shouldn't break any > existing user codes (this is the code monkey in me talking, not the QA > rep), and those implementors who want it for stronger contracts can > have it. > > _______________________________________________ mpi-22 mailing list mpi-22_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 From bwbarre at [hidden] Thu Mar 19 17:28:04 2009 From: bwbarre at [hidden] (Barrett, Brian W) Date: Thu, 19 Mar 2009 16:28:04 -0600 Subject: [Mpi-22] Ticket #46: Add const Keyword to the C bindings-implementation In-Reply-To: <25298_1237500133_n2JM2BjU027640_6B68D01C00C9994A8E150183E62A119E7B733A5917@NA-EXMSG-C105.redmond.corp.microsoft.com> Message-ID: On 3/19/09 16:00 , "Erez Haba" wrote: > As to rushing this in, I'm curious, this ticket is there for over a year; > already implemented twice and tested by two different bodies. Is this really > rushing it in? > > As to the procedural issues. This ticket is one of the first tickets that we > had in the system, and of-course as the mpi forum body we did learn a thing or > two in that process, unfortunately, first implemented with that ticket. So yes > there would be issues. I think that we can resolve these 'issues' but puting > dependency on passing this ticket given that we accept the other two > corrections to the ticket. We're not too late to submit a new proposal to 2.2, as I understand it. Why not do the right thing, pull #46, #129, and #130, bundle them into a new proposal, get comments, and remove the procedural issues? I think the hesitancy to do this only adds to my worry about this proposal, and is part of the view people have of "rushing it it". Brian -- Brian W. Barrett Dept. 1423: Scalable System Software Sandia National Laboratories From erezh at [hidden] Thu Mar 19 17:32:18 2009 From: erezh at [hidden] (Erez Haba) Date: Thu, 19 Mar 2009 15:32:18 -0700 Subject: [Mpi-22] Ticket #46: Add const Keyword to the C bindings-implementation In-Reply-To: Message-ID: <6B68D01C00C9994A8E150183E62A119E7B733A5976@NA-EXMSG-C105.redmond.corp.microsoft.com> Since we already passed first vote, there was an objection to that in the last meeting. -----Original Message----- From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Barrett, Brian W Sent: Thursday, March 19, 2009 3:28 PM To: MPI 2.2 Subject: Re: [Mpi-22] Ticket #46: Add const Keyword to the C bindings-implementation On 3/19/09 16:00 , "Erez Haba" wrote: > As to rushing this in, I'm curious, this ticket is there for over a year; > already implemented twice and tested by two different bodies. Is this really > rushing it in? > > As to the procedural issues. This ticket is one of the first tickets that we > had in the system, and of-course as the mpi forum body we did learn a thing or > two in that process, unfortunately, first implemented with that ticket. So yes > there would be issues. I think that we can resolve these 'issues' but puting > dependency on passing this ticket given that we accept the other two > corrections to the ticket. We're not too late to submit a new proposal to 2.2, as I understand it. Why not do the right thing, pull #46, #129, and #130, bundle them into a new proposal, get comments, and remove the procedural issues? I think the hesitancy to do this only adds to my worry about this proposal, and is part of the view people have of "rushing it it". Brian -- Brian W. Barrett Dept. 1423: Scalable System Software Sandia National Laboratories _______________________________________________ mpi-22 mailing list mpi-22_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 From keith.d.underwood at [hidden] Thu Mar 19 17:36:21 2009 From: keith.d.underwood at [hidden] (Underwood, Keith D) Date: Thu, 19 Mar 2009 16:36:21 -0600 Subject: [Mpi-22] Ticket #46: Add const Keyword to the C bindings-implementation In-Reply-To: <6B68D01C00C9994A8E150183E62A119E7B733A5976@NA-EXMSG-C105.redmond.corp.microsoft.com> Message-ID: <8E9963DB482E4B49AB9EF1C296936CF71EA4C582@rrsmsx507.amr.corp.intel.com> That is incorrect. There was an objection to changing #46 and claiming that it already had its first vote. Brian is proposing that you bundle the fixes in a new proposal and have a first reading again. It sounded like there were yet more additions that he was proposing. Keith >-----Original Message----- >From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_lists.mpi- >forum.org] On Behalf Of Erez Haba >Sent: Thursday, March 19, 2009 4:32 PM >To: MPI 2.2 >Subject: Re: [Mpi-22] Ticket #46: Add const Keyword to the C bindings- >implementation > >Since we already passed first vote, there was an objection to that in the >last meeting. > >-----Original Message----- >From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_lists.mpi- >forum.org] On Behalf Of Barrett, Brian W >Sent: Thursday, March 19, 2009 3:28 PM >To: MPI 2.2 >Subject: Re: [Mpi-22] Ticket #46: Add const Keyword to the C bindings- >implementation > >On 3/19/09 16:00 , "Erez Haba" wrote: > >> As to rushing this in, I'm curious, this ticket is there for over a year; >> already implemented twice and tested by two different bodies. Is this >really >> rushing it in? >> >> As to the procedural issues. This ticket is one of the first tickets that >we >> had in the system, and of-course as the mpi forum body we did learn a >thing or >> two in that process, unfortunately, first implemented with that ticket. >So yes >> there would be issues. I think that we can resolve these 'issues' but >puting >> dependency on passing this ticket given that we accept the other two >> corrections to the ticket. > >We're not too late to submit a new proposal to 2.2, as I understand it. >Why >not do the right thing, pull #46, #129, and #130, bundle them into a new >proposal, get comments, and remove the procedural issues? I think the >hesitancy to do this only adds to my worry about this proposal, and is part >of the view people have of "rushing it it". > >Brian > >-- > Brian W. Barrett > Dept. 1423: Scalable System Software > Sandia National Laboratories > > > >_______________________________________________ >mpi-22 mailing list >mpi-22_at_[hidden] >http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 > > >_______________________________________________ >mpi-22 mailing list >mpi-22_at_[hidden] >http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 From bwbarre at [hidden] Thu Mar 19 17:37:29 2009 From: bwbarre at [hidden] (Barrett, Brian W) Date: Thu, 19 Mar 2009 16:37:29 -0600 Subject: [Mpi-22] Ticket #46: Add const Keyword to the C bindings-implementation In-Reply-To: <30004_1237502004_n2JMVhKd030893_6B68D01C00C9994A8E150183E62A119E7B733A5976@NA-EXMSG-C105.redmond.corp.microsoft.com> Message-ID: No, there was an objection (rightly) to modifying a proposal that had been voted on. I'm saying remove #46, #129, and #130 from consideration, and start an entirely new proposal from day 1 that is complete. Otherwise, we're setting a horrible precedent that it's ok to vote in things that are known to be wrong, because we can just fix them later. In fact, I believe there was suggestion to do exactly that at the last meeting, but you chose to add new proposals instead. Brian On 3/19/09 16:32 , "Erez Haba" wrote: > Since we already passed first vote, there was an objection to that in the last > meeting. > > -----Original Message----- > From: mpi-22-bounces_at_[hidden] > [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Barrett, Brian W > Sent: Thursday, March 19, 2009 3:28 PM > To: MPI 2.2 > Subject: Re: [Mpi-22] Ticket #46: Add const Keyword to the C > bindings-implementation > > On 3/19/09 16:00 , "Erez Haba" wrote: > >> As to rushing this in, I'm curious, this ticket is there for over a year; >> already implemented twice and tested by two different bodies. Is this really >> rushing it in? >> >> As to the procedural issues. This ticket is one of the first tickets that we >> had in the system, and of-course as the mpi forum body we did learn a thing >> or >> two in that process, unfortunately, first implemented with that ticket. So >> yes >> there would be issues. I think that we can resolve these 'issues' but puting >> dependency on passing this ticket given that we accept the other two >> corrections to the ticket. > > We're not too late to submit a new proposal to 2.2, as I understand it. Why > not do the right thing, pull #46, #129, and #130, bundle them into a new > proposal, get comments, and remove the procedural issues? I think the > hesitancy to do this only adds to my worry about this proposal, and is part > of the view people have of "rushing it it". > > Brian > > -- > Brian W. Barrett > Dept. 1423: Scalable System Software > Sandia National Laboratories > > > > _______________________________________________ > mpi-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 > > > _______________________________________________ > mpi-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 > -- Brian W. Barrett Dept. 1423: Scalable System Software Sandia National Laboratories From jsquyres at [hidden] Thu Mar 19 18:24:18 2009 From: jsquyres at [hidden] (Jeff Squyres jsquyres) Date: Thu, 19 Mar 2009 19:24:18 -0400 Subject: [Mpi-22] Ticket #46: Add const Keyword to the C bindings-implementation In-Reply-To: <[Mpi-22] Ticket #46: Add const Keyword to the C bindings-implementation> Message-ID: Let's not invoke emotion here; there are valid tech and procedural questions that have been raised multiple times. Its always the burden of the proposer to answer such questions - this is no different than any other proposal. Indeed, I think torsten's nbc proposal received *much* more scrutiny than this. - This may have been one of the first / oldest tickets, but it sat there for a long time with no action from you until we're nearly out of time for mpi 22. Using the "its a year old" argument isn't valid. - an open source implementation is *required* for mpi 22. - testing that const is in the right places in the interface is *exactly* the right kinds of tests to write. -jms Sent from my PDA. No type good. ----- Original Message ----- From: mpi-22-bounces_at_[hidden] To: MPI 2.2 Sent: Thu Mar 19 18:00:33 2009 Subject: Re: [Mpi-22] Ticket #46: Add const Keyword to the C bindings-implementation Terry, I'm truly sorry that you find the information that I provide as unreliable. I know that I'm not part of the 'trusted' OpenMPI clan and I wish that there was something I could do to convince you otherwise. If you recall the last forum meeting, I did a complete implementation of the 'const' ticket during that meeting. (and did let everyone know about it). That was an implementation from scratch that did trickle down the constness to all the internal functions of MSMPI. Indeed I did not do any runtime testing at that meeting, it did happen later. However, since MSMPI is not an open source project, I asked the friends at ANL to re-implement it over MPICH2 and make the source available. Since you might not trust my word, you may ask Rajeev and other friends at ANL about this. The tests conducted were checking for regression. Hence, any program that compiled and run correctly before the const change did compile and run correctly after the const change; with multiple compiler and multiple operating systems. We did not conduct any direct tests that are checking the 'constness' of the interface. I don't really know how you check for constness? Do you check that the buffer was not modified? Well that would be testing ticket #45 (send buffer access) and not ticket #46. Do you check that you pass const in and you don't get a compiler error? that relatively simple and I don't think it buys you much (except it verifies that you put the const in all the right places on the interface API). As to rushing this in, I'm curious, this ticket is there for over a year; already implemented twice and tested by two different bodies. Is this really rushing it in? As to the procedural issues. This ticket is one of the first tickets that we had in the system, and of-course as the mpi forum body we did learn a thing or two in that process, unfortunately, first implemented with that ticket. So yes there would be issues. I think that we can resolve these 'issues' but puting dependency on passing this ticket given that we accept the other two corrections to the ticket. Thanks, .Erez -----Original Message----- From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Terry Dontje Sent: Thursday, March 19, 2009 9:15 AM To: MPI 2.2 Subject: Re: [Mpi-22] Ticket #46: Add const Keywordto the Cbindings-implementation I am not Jeff and I do not play him on tv but I felt the need to interject my 2 cents. Erez Haba wrote: > Jeff, I don't understand why you ignore all the work that has been done with this ticket and suggest your own metric. Was the information I provided unreliable or untrue? > > Possibly but it definitely is biased IMO. > As I said, it took me about 2.5h to implement the entire change on the MSMPI code base; yes there were many internal functions that had const in it, but also many that did not. I don't think that by any measure this is a significant work for any implementer. > > Isn't MSMPI based on MPICH? If so how much of the previous work done to support const did you leverage or did you truly reinvent the same wheel MPICH developers did? I guess I find it pretty amazing the applying 10,000 lines of changes and then validating them took you 2.5 hours. > More than that, this interface change was tested using the ANL test suite and the Intel complete test suite, without a single compile or runtime error over multiple platforms and compilers. Again, this was not a significant work item; and I believe that OpenMPI has a regression suite that crosses platform and compilers which is easy to run (as you described to me many times). > > > Do the ANL tests and any others really test const-ness without changes. Or are you saying the ANL tests already do explicit testing of const-ness on the right parameters? > With this information that I have already provided before, I don't understand your claims; unless you think that they are biased and unreliable. > > I would say your information is a useful datapoint but I am curious if what you did really was the full conversion of your MPI implementation to handle this change. > Hence this ticket completely meets MPI 2.2 requirements in scope and backward compatibility. > > For MPICH based implementations I agree it does. For Open MPI I think it is still questionable. I guess I am still interested in the reasoning why shoving this ticket into 2.2 is such a high priority? --td > Thanks, > .Erez > > -----Original Message----- > From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Jeff Squyres > Sent: Thursday, March 19, 2009 5:20 AM > To: Bronis R. de Supinski; MPI 2.2 > Subject: Re: [Mpi-22] Ticket #46: Add const Keywordto the Cbindings-implementation > > On Mar 19, 2009, at 12:03 AM, Bronis R. de Supinski wrote: > > >> I have been quiet on this debate but I am to the point >> that I feel a need to speak up. I think the "significant >> changes" reason is a canard (I think Brian and Jeff >> believe it but it is still a red herring for the most >> part). The changes to support it are not significant. >> You can implement it by casting it away early. >> >> > > > The changes *are* significant. I count 90 top-level MPI API functions > that are affected by this proposal. > > The bar for 2.2 is "trivial" implementation efforts, no? This is not > trivial. The MPICH diff was ~10,000 lines. Apparently, they chose to > go above and beyond the requirement and propagate const to lower > layers (vs. casting it away immediately), but still -- if a 2.2 change > can inspire a 10,000 line diff, that just seems like it doesn't meet > the spirit of the "trivial" implementation requirement. > > Indeed, in doing the "simple" cast-it-away-immediately approach > implementation, editing and testing each of the 90 functions will > require a good amount of effort. Sure, the first-wave addition of > "const" across all of the affected functions is probably relatively > easy -- one code monkey and several hours. But how long will it take > you to find the one place where you put "const" in the wrong > location? How long will it take you to write new tests to verify the > const-ness in all the right places? To be clear: it's a "not > significant" change to a code monkey. But try to tell your QA guys > that this is not significant -- they'll freak out. > > Hence, if you take the overall scope of both the change and the > additional testing to validate this change, this is a large scale > implementation effort. I just don't see what the rush is to get this > into 2.2. > > I think Brian makes several good arguments, one of which is: those who > want const can put it in today. It hypothetically shouldn't break any > existing user codes (this is the code monkey in me talking, not the QA > rep), and those implementors who want it for stronger contracts can > have it. > > _______________________________________________ mpi-22 mailing list mpi-22_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 _______________________________________________ mpi-22 mailing list mpi-22_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 * -------------- next part -------------- An HTML attachment was scrubbed... URL: From erezh at [hidden] Thu Mar 19 19:34:44 2009 From: erezh at [hidden] (Erez Haba) Date: Thu, 19 Mar 2009 17:34:44 -0700 Subject: [Mpi-22] Ticket #46: Add const Keyword to the C bindings-implementation In-Reply-To: Message-ID: <6B68D01C00C9994A8E150183E62A119E7B733A5A3F@NA-EXMSG-C105.redmond.corp.microsoft.com> Thanks Brian, My recollection of the last meeting is that opening tickets #129 & #130 was the forum recommendation. I don't recall anyone saying that we can't vote on #46 if there are any amendments in new tickets. However, I do see your point and I will prepare a new proposal that captures tickets #46, #129 and #130 for the next meeting, where we'll get the forum feedback if we want to proceed with the new ticket or ticket #46. (as it does reset the clock and requires some more work from the forum). I am okay with it either way. Thanks, .Erez -----Original Message----- From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Barrett, Brian W Sent: Thursday, March 19, 2009 3:37 PM To: MPI 2.2 Subject: Re: [Mpi-22] Ticket #46: Add const Keyword to the C bindings-implementation No, there was an objection (rightly) to modifying a proposal that had been voted on. I'm saying remove #46, #129, and #130 from consideration, and start an entirely new proposal from day 1 that is complete. Otherwise, we're setting a horrible precedent that it's ok to vote in things that are known to be wrong, because we can just fix them later. In fact, I believe there was suggestion to do exactly that at the last meeting, but you chose to add new proposals instead. Brian On 3/19/09 16:32 , "Erez Haba" wrote: > Since we already passed first vote, there was an objection to that in the last > meeting. > > -----Original Message----- > From: mpi-22-bounces_at_[hidden] > [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Barrett, Brian W > Sent: Thursday, March 19, 2009 3:28 PM > To: MPI 2.2 > Subject: Re: [Mpi-22] Ticket #46: Add const Keyword to the C > bindings-implementation > > On 3/19/09 16:00 , "Erez Haba" wrote: > >> As to rushing this in, I'm curious, this ticket is there for over a year; >> already implemented twice and tested by two different bodies. Is this really >> rushing it in? >> >> As to the procedural issues. This ticket is one of the first tickets that we >> had in the system, and of-course as the mpi forum body we did learn a thing >> or >> two in that process, unfortunately, first implemented with that ticket. So >> yes >> there would be issues. I think that we can resolve these 'issues' but puting >> dependency on passing this ticket given that we accept the other two >> corrections to the ticket. > > We're not too late to submit a new proposal to 2.2, as I understand it. Why > not do the right thing, pull #46, #129, and #130, bundle them into a new > proposal, get comments, and remove the procedural issues? I think the > hesitancy to do this only adds to my worry about this proposal, and is part > of the view people have of "rushing it it". > > Brian > > -- > Brian W. Barrett > Dept. 1423: Scalable System Software > Sandia National Laboratories > > > > _______________________________________________ > mpi-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 > > > _______________________________________________ > mpi-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 > -- Brian W. Barrett Dept. 1423: Scalable System Software Sandia National Laboratories _______________________________________________ mpi-22 mailing list mpi-22_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 From balaji at [hidden] Thu Mar 19 20:20:42 2009 From: balaji at [hidden] (Pavan Balaji) Date: Thu, 19 Mar 2009 20:20:42 -0500 Subject: [Mpi-22] Ticket #46: Add const Keyword to the C bindings-implementation In-Reply-To: Message-ID: <49C2EF6A.9080209@mcs.anl.gov> Hi Jeff, > - testing that const is in the right places in the interface is > *exactly* the right kinds of tests to write. Maybe I'm missing something here, but can you give some examples of tests that would fail with this change that a new and strict compiler will not be able to catch? Obviously I'm referring to cases which would work correctly if this ticket wasn't accepted, but will not work if it were. Unless there are such examples, all this ticket requires is letting the compiler find the problems for you. In fact, some tickets in 2.1 required more QA, as a compiler was useless in catching any real problems with them and new tests had to be written (e.g., the change with respect to 0-dim cartesian topologies, or any other trivial change). Now, to keep the compiler quiet, whether the implementation directly discards the const at the top-level or carries it on to the lowest possible level (e.g., network interface) is a separate discussion and IMO really a quality of implementation issue. And, obviously, pushing this to 3.0 would not ensure that implementations will make an effort to do better. So, what's the motivation to move this to 3.0? Thanks, -- Pavan -- Pavan Balaji http://www.mcs.anl.gov/~balaji From jsquyres at [hidden] Fri Mar 20 14:42:24 2009 From: jsquyres at [hidden] (Jeff Squyres) Date: Fri, 20 Mar 2009 15:42:24 -0400 Subject: [Mpi-22] Ticket #46: Add const Keyword to theC bindings-implementation In-Reply-To: <49C2EF6A.9080209@mcs.anl.gov> Message-ID: <7C8C4697-616E-4F60-B58D-EA9CA5595A3F@cisco.com> On Mar 19, 2009, at 9:20 PM, Pavan Balaji wrote: > > - testing that const is in the right places in the interface is > > *exactly* the right kinds of tests to write. > > Maybe I'm missing something here, but can you give some examples of > tests that would fail with this change that a new and strict compiler > will not be able to catch? Obviously I'm referring to cases which > would > work correctly if this ticket wasn't accepted, but will not work if > it were. > Clearly, an implementor who passed a const variable through a non- const interface would get either a compiler warning or error. If the implementor disregards those messages, well, then I guess the battle is lost. ;-) The testing that I'm talking about would be writing tests to ensure that const was put in the right place in all the interfaces -- being able to repeatably prove that (i.e., regression testing). Be creative -- perhaps you can use the MPI's mpi.h with a test code that implements MPI_Send with const in the wrong parameter location. It should fail to compile, right? Or perhaps it has const in the right parameter location but then doesn't cast it away and intentionally modifies it. That should also fail, right? Those are good QA tests. > Unless there are such examples, all this ticket requires is letting > the > compiler find the problems for you. In fact, some tickets in 2.1 > required more QA, as a compiler was useless in catching any real > problems with them and new tests had to be written (e.g., the change > with respect to 0-dim cartesian topologies, or any other trivial > change). > Sure, I wrote a few tests for this case for Open MPI. We try to write tests for most new major MPI functionality. But the 0-dim cartesian topologies creates a few tests, not 90+ tests. > So, what's the motivation to move this to 3.0? > What's the *need* to make this 2.2? Why such a strong push to get this in 2.2? What's the rush? As Brian noted, any MPI implementation can have const in their C bindings today, regardless of what happens in 2.2. -- Jeff Squyres Cisco Systems From erezh at [hidden] Fri Mar 20 15:26:11 2009 From: erezh at [hidden] (Erez Haba) Date: Fri, 20 Mar 2009 13:26:11 -0700 Subject: [Mpi-22] Ticket #46: Add const Keyword to theC bindings-implementation In-Reply-To: <7C8C4697-616E-4F60-B58D-EA9CA5595A3F@cisco.com> Message-ID: <6B68D01C00C9994A8E150183E62A119E7B733A5DD3@NA-EXMSG-C105.redmond.corp.microsoft.com> Is a test suite is part of the requirement to accept this ticket? It if so, we will work it through and make one available. -----Original Message----- From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Jeff Squyres Sent: Friday, March 20, 2009 12:42 PM To: MPI 2.2 Subject: Re: [Mpi-22] Ticket #46: Add const Keyword to theC bindings-implementation On Mar 19, 2009, at 9:20 PM, Pavan Balaji wrote: > > - testing that const is in the right places in the interface is > > *exactly* the right kinds of tests to write. > > Maybe I'm missing something here, but can you give some examples of > tests that would fail with this change that a new and strict compiler > will not be able to catch? Obviously I'm referring to cases which > would > work correctly if this ticket wasn't accepted, but will not work if > it were. > Clearly, an implementor who passed a const variable through a non- const interface would get either a compiler warning or error. If the implementor disregards those messages, well, then I guess the battle is lost. ;-) The testing that I'm talking about would be writing tests to ensure that const was put in the right place in all the interfaces -- being able to repeatably prove that (i.e., regression testing). Be creative -- perhaps you can use the MPI's mpi.h with a test code that implements MPI_Send with const in the wrong parameter location. It should fail to compile, right? Or perhaps it has const in the right parameter location but then doesn't cast it away and intentionally modifies it. That should also fail, right? Those are good QA tests. > Unless there are such examples, all this ticket requires is letting > the > compiler find the problems for you. In fact, some tickets in 2.1 > required more QA, as a compiler was useless in catching any real > problems with them and new tests had to be written (e.g., the change > with respect to 0-dim cartesian topologies, or any other trivial > change). > Sure, I wrote a few tests for this case for Open MPI. We try to write tests for most new major MPI functionality. But the 0-dim cartesian topologies creates a few tests, not 90+ tests. > So, what's the motivation to move this to 3.0? > What's the *need* to make this 2.2? Why such a strong push to get this in 2.2? What's the rush? As Brian noted, any MPI implementation can have const in their C bindings today, regardless of what happens in 2.2. -- Jeff Squyres Cisco Systems _______________________________________________ mpi-22 mailing list mpi-22_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 From balaji at [hidden] Fri Mar 20 15:32:03 2009 From: balaji at [hidden] (Pavan Balaji) Date: Fri, 20 Mar 2009 15:32:03 -0500 Subject: [Mpi-22] Ticket #46: Add const Keyword to theC bindings-implementation In-Reply-To: <7C8C4697-616E-4F60-B58D-EA9CA5595A3F@cisco.com> Message-ID: <49C3FD43.2040903@mcs.anl.gov> Hi Jeff, > The testing that I'm talking about would be writing tests to ensure that > const was put in the right place in all the interfaces -- being able to > repeatably prove that (i.e., regression testing). Be creative -- > perhaps you can use the MPI's mpi.h with a test code that implements > MPI_Send with const in the wrong parameter location. It should fail to > compile, right? Or perhaps it has const in the right parameter location > but then doesn't cast it away and intentionally modifies it. That > should also fail, right? Those are good QA tests. Thanks. With these tests are you testing the MPI implementation or the test program itself? If the application (or test program) uses a const in the wrong place, the compiler will throw a warning/error. And if the user decides to ignore it, there's nothing the MPI implementation can do about it. > What's the *need* to make this 2.2? Why such a strong push to get this > in 2.2? What's the rush? As Brian noted, any MPI implementation can > have const in their C bindings today, regardless of what happens in 2.2. Inertia :-). Since the proposal is already in 2.2, I think the onus is to show an argument to *move* it to 3.0, rather than to keep it in 2.2. -- Pavan -- Pavan Balaji http://www.mcs.anl.gov/~balaji From erezh at [hidden] Fri Mar 20 16:52:45 2009 From: erezh at [hidden] (Erez Haba) Date: Fri, 20 Mar 2009 14:52:45 -0700 Subject: [Mpi-22] Ticket #46: Add const Keyword to the C bindings-implementation In-Reply-To: <6B68D01C00C9994A8E150183E62A119E7B733A5DD3@NA-EXMSG-C105.redmond.corp.microsoft.com> Message-ID: <6B68D01C00C9994A8E150183E62A119E7B733A5E63@NA-EXMSG-C105.redmond.corp.microsoft.com> There was some confusion about what exactly I implemented in those 2.5h in the last forum meeting and how I implemented it. I would like to clarify this confusion and assure you that I am no super-dev of any sort. What I did was simple, I walked all the functions in mpi.h and added (copied) the const from ticket #45. There was scripting, awk or perl involved it was all manual. Once I was done with the header I compiled; the compiler gave me a bunch of errors, saying that the impl does not match the function prototype. In my environment I can quickly go from a compiler error to the source code. I fixed the MPI function impl to copy the same const to the function parameter and compiled again. The compiler gave me a bunch of other errors about internal functions and/or variable assignment. Again I fixed those and recompiled. In very few places I had to do something sophisticated like casting, or changing a local pointer variable to be a pointer to a const. that's it! I repeated that process until I had no errors. Indeed that was just a proof of concept; I used only one compiler in that case and only one platform. Which is why it was only 2.5h, and which is why it took longer (2d) for Pavan to implement over multiple compilers, platforms, test and submit it to the branch. Hope that this helps, .Erez From rlgraham at [hidden] Fri Mar 20 17:43:29 2009 From: rlgraham at [hidden] (Graham, Richard L.) Date: Fri, 20 Mar 2009 18:43:29 -0400 Subject: [Mpi-22] Ticket #46: Add const Keyword to theCbindings-implementation In-Reply-To: <[Mpi-22] Ticket #46: Add const Keyword to theCbindings-implementation> Message-ID: <537C6C0940C6C143AA46A88946B854170F0FC5F0@ORNLEXCHANGE.ornl.gov> There is no test suite requirement, only the availability of an implementation that can be examined. Rich ----- Original Message ----- From: mpi-22-bounces_at_[hidden] To: MPI 2.2 Sent: Fri Mar 20 16:26:11 2009 Subject: Re: [Mpi-22] Ticket #46: Add const Keyword to theCbindings-implementation Is a test suite is part of the requirement to accept this ticket? It if so, we will work it through and make one available. -----Original Message----- From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Jeff Squyres Sent: Friday, March 20, 2009 12:42 PM To: MPI 2.2 Subject: Re: [Mpi-22] Ticket #46: Add const Keyword to theC bindings-implementation On Mar 19, 2009, at 9:20 PM, Pavan Balaji wrote: > > - testing that const is in the right places in the interface is > > *exactly* the right kinds of tests to write. > > Maybe I'm missing something here, but can you give some examples of > tests that would fail with this change that a new and strict compiler > will not be able to catch? Obviously I'm referring to cases which > would > work correctly if this ticket wasn't accepted, but will not work if > it were. > Clearly, an implementor who passed a const variable through a non- const interface would get either a compiler warning or error. If the implementor disregards those messages, well, then I guess the battle is lost. ;-) The testing that I'm talking about would be writing tests to ensure that const was put in the right place in all the interfaces -- being able to repeatably prove that (i.e., regression testing). Be creative -- perhaps you can use the MPI's mpi.h with a test code that implements MPI_Send with const in the wrong parameter location. It should fail to compile, right? Or perhaps it has const in the right parameter location but then doesn't cast it away and intentionally modifies it. That should also fail, right? Those are good QA tests. > Unless there are such examples, all this ticket requires is letting > the > compiler find the problems for you. In fact, some tickets in 2.1 > required more QA, as a compiler was useless in catching any real > problems with them and new tests had to be written (e.g., the change > with respect to 0-dim cartesian topologies, or any other trivial > change). > Sure, I wrote a few tests for this case for Open MPI. We try to write tests for most new major MPI functionality. But the 0-dim cartesian topologies creates a few tests, not 90+ tests. > So, what's the motivation to move this to 3.0? > What's the *need* to make this 2.2? Why such a strong push to get this in 2.2? What's the rush? As Brian noted, any MPI implementation can have const in their C bindings today, regardless of what happens in 2.2. -- Jeff Squyres Cisco Systems _______________________________________________ mpi-22 mailing list mpi-22_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 _______________________________________________ mpi-22 mailing list mpi-22_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 From jsquyres at [hidden] Fri Mar 20 19:08:55 2009 From: jsquyres at [hidden] (Jeff Squyres) Date: Fri, 20 Mar 2009 20:08:55 -0400 Subject: [Mpi-22] Ticket #46: Add const Keywordto theC bindings-implementation In-Reply-To: <49C3FD43.2040903@mcs.anl.gov> Message-ID: <519C4DC7-6890-4EA9-84B1-B6200B1C135F@cisco.com> On Mar 20, 2009, at 4:32 PM, Pavan Balaji wrote: > > The testing that I'm talking about would be writing tests to > ensure that > > const was put in the right place in all the interfaces -- being > able to > > repeatably prove that (i.e., regression testing). Be creative -- > > perhaps you can use the MPI's mpi.h with a test code that implements > > MPI_Send with const in the wrong parameter location. It should > fail to > > compile, right? Or perhaps it has const in the right parameter > location > > but then doesn't cast it away and intentionally modifies it. That > > should also fail, right? Those are good QA tests. > > Thanks. With these tests are you testing the MPI implementation or the > test program itself? If the application (or test program) uses a const > in the wrong place, the compiler will throw a warning/error. And if > the > user decides to ignore it, there's nothing the MPI implementation > can do > about it. > I was giving a hypothetical test, probably with a big bias of my own MPI implementation. In Open MPI, the same mpi.h is used internally as externally. So a valid test could be to compile an application (or even just an object file) that "implements" MPI_Send, correctly and/or incorrectly. Since the mpi.h header file is the same as the one that is used internally, you can know that if your test MPI_Send "implementation" is wrong and still compiles ok, then your mpi.h is wrong. If your test is wrong and it doesn't compile, that's good (although it obviously doesn't necessarily mean that the mpi.h is correct). > > What's the *need* to make this 2.2? Why such a strong push to get > this > > in 2.2? What's the rush? As Brian noted, any MPI implementation > can > > have const in their C bindings today, regardless of what happens > in 2.2. > > Inertia :-). Since the proposal is already in 2.2, I think the onus is > to show an argument to *move* it to 3.0, rather than to keep it in > 2.2. > By this logic, non-blocking collectives should be in 2.2 as well -- they have plenty of inertia! :-) I think the onus should be to be careful and to get it right. We do strive for consensus in the Forum whenever possible. The procedural questions are being addressed (thanks, Erez!), but at least two technical questions remain: - I (and others) have given examples why I (we) think this fails the "trivial" 2.2 implementation criteria - I (and others) have cited the disparity of lack of "const" in the callback function typedefs -- Jeff Squyres Cisco Systems From thakur at [hidden] Sat Mar 21 12:14:55 2009 From: thakur at [hidden] (Rajeev Thakur) Date: Sat, 21 Mar 2009 12:14:55 -0500 Subject: [Mpi-22] Ticket #46: Add const Keywordto the C bindings-implementation In-Reply-To: <[Mpi-22] Ticket #46: Add const Keywordto the C bindings-implementation> Message-ID: <7683187D79AF46F5AEC9E99655D61C8C@thakurlaptop> One reason to deal with this issue in 2.2 versus 3 is that if we decide one way or the other now itself (whether const should or should not be in the MPI interface), it helps all other interfaces being defined in MPI 3 to know now itself whether they need to include const in the right places. If we delay until 3, the new interfaces will have to go back and add const at the last minute, or keep 2 sets of interfaces concurrently active until the end -- with const and without const. Regarding implementation, if you start with the mpi.h provided in the ticket and let the compiler catch you, it can be done (although it is still tedious). How far down you propagate const depends on how much time you are willing to spend. Rajeev From ritzdorf at [hidden] Mon Mar 23 06:01:03 2009 From: ritzdorf at [hidden] (Hubert Ritzdorf) Date: Mon, 23 Mar 2009 12:01:03 +0100 Subject: [Mpi-22] Ticket #46: Add const Keywordto theC bindings-implementation In-Reply-To: <519C4DC7-6890-4EA9-84B1-B6200B1C135F@cisco.com> Message-ID: <49C76BEF.5090305@it.neclab.eu> I have a stupid question: (*) Is it not required to write tests for all these interfaces (and internal protocols) where the (const) send buffer is declared and allocated as const also in the test program, so that the compiler is able to put the send buffer in special memory regions ? All other tests seem to be only compile tests (and not run tests) whether the internal interfaces are correctly declared. I think that the compiler doesn't have any possibility for optimization within the MPI library (and generating runtime problems with the const interface) since send buffer regions could be used as not const at any other location. Hubert Jeff Squyres wrote: > On Mar 20, 2009, at 4:32 PM, Pavan Balaji wrote: > >> > The testing that I'm talking about would be writing tests to ensure >> that >> > const was put in the right place in all the interfaces -- being >> able to >> > repeatably prove that (i.e., regression testing). Be creative -- >> > perhaps you can use the MPI's mpi.h with a test code that implements >> > MPI_Send with const in the wrong parameter location. It should >> fail to >> > compile, right? Or perhaps it has const in the right parameter >> location >> > but then doesn't cast it away and intentionally modifies it. That >> > should also fail, right? Those are good QA tests. >> >> Thanks. With these tests are you testing the MPI implementation or the >> test program itself? If the application (or test program) uses a const >> in the wrong place, the compiler will throw a warning/error. And if the >> user decides to ignore it, there's nothing the MPI implementation can do >> about it. >> > > I was giving a hypothetical test, probably with a big bias of my own > MPI implementation. In Open MPI, the same mpi.h is used internally as > externally. So a valid test could be to compile an application (or > even just an object file) that "implements" MPI_Send, correctly and/or > incorrectly. Since the mpi.h header file is the same as the one that > is used internally, you can know that if your test MPI_Send > "implementation" is wrong and still compiles ok, then your mpi.h is > wrong. If your test is wrong and it doesn't compile, that's good > (although it obviously doesn't necessarily mean that the mpi.h is > correct). > >> > What's the *need* to make this 2.2? Why such a strong push to get >> this >> > in 2.2? What's the rush? As Brian noted, any MPI implementation can >> > have const in their C bindings today, regardless of what happens in >> 2.2. >> >> Inertia :-). Since the proposal is already in 2.2, I think the onus is >> to show an argument to *move* it to 3.0, rather than to keep it in 2.2. >> > > > By this logic, non-blocking collectives should be in 2.2 as well -- > they have plenty of inertia! :-) > > I think the onus should be to be careful and to get it right. We do > strive for consensus in the Forum whenever possible. The procedural > questions are being addressed (thanks, Erez!), but at least two > technical questions remain: > > - I (and others) have given examples why I (we) think this fails the > "trivial" 2.2 implementation criteria > - I (and others) have cited the disparity of lack of "const" in the > callback function typedefs > > --Jeff Squyres > Cisco Systems > > _______________________________________________ > mpi-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 > * -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From erezh at [hidden] Mon Mar 23 13:51:44 2009 From: erezh at [hidden] (Erez Haba) Date: Mon, 23 Mar 2009 11:51:44 -0700 Subject: [Mpi-22] Please review ticket #140: Add const Keyword to the C bindings Message-ID: <6B68D01C00C9994A8E150183E62A119E7B74C00084@NA-EXMSG-C105.redmond.corp.microsoft.com> I opened a new ticket #140 for the "Add const Keyword to the C bindings" proposal instead of existing tickets #46, #129 & #130. Ticket #140 differs from ticket #46 only by the applied amendments in tickets #129 and #130. Chapter authors please review this ticket before the next forum meeting. Thanks, .Erez * -------------- next part -------------- An HTML attachment was scrubbed... URL: From goodell at [hidden] Mon Mar 23 14:38:02 2009 From: goodell at [hidden] (Dave Goodell) Date: Mon, 23 Mar 2009 14:38:02 -0500 Subject: [Mpi-22] MPI_Aint/MPI_ADDRESS_KIND equivalence and ticket #18 In-Reply-To: Message-ID: On Mar 9, 2009, at 2:17 PM, Jeff Squyres wrote: > On Mar 9, 2009, at 2:34 PM, Rajeev Thakur wrote: > >> Address-sized variables in MPI can be passed from C to Fortran or >> vice >> versa, and I know of no c2f or f2c conversion functions for them. >> So I think >> MPI_Aint and integer (kind=MPI_ADDRESS_KIND) are assumed to be of >> the same >> size at least implicitly. >> > > I agree. Should we state this explicitly somewhere (if we didn't > already)? FYI, I've created ticket #141 to clarify the text in this regard: https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/141 -Dave From david.solt at [hidden] Tue Mar 24 13:04:34 2009 From: david.solt at [hidden] (Solt, David George) Date: Tue, 24 Mar 2009 18:04:34 +0000 Subject: [Mpi-22] [MPI Forum] #102: MPI_TYPE_GET_EXTENT is defined via deprecated features In-Reply-To: <063.84d9a5cfa0499d3a7a6d364173bd3e8f@lists.mpi-forum.org> Message-ID: Since "upper bound" and "lower bound" still exist and therefore the concept of MPI_LB and MPI_UB still exist, it seems like we should do one of two things: 1) Retract this proposal and leave it the way it is. 2) Go through the whole chapter and carefully separate out the concept of the upper/lower bounds from the MPI_UB/MPI_LB markers. We would need to present the concept using general terms which could be then referenced in the definition of MPI_TYPE_GET_EXTENT. The presentation and references to MPI_UB/MPI_LB would need to be confined to a limited area and clearly designated at depreciated. I doubt that #2 is worth the effort or will not introduce more new errors than what it is attempting to fix. As it stands now, I still think it is a little awkward to read the chapter because MPI_LB and MPI_UB were central to the original presentation and now we have deprecated them. Still, I do not see a fix simple enough to be worthy of such a minor nit. Dave -----Original Message----- From: MPI Forum [mailto:mpi-22_at_[hidden]] Sent: Tuesday, March 24, 2009 12:02 PM Subject: Re: [MPI Forum] #102: MPI_TYPE_GET_EXTENT is defined via deprecated features #102: MPI_TYPE_GET_EXTENT is defined via deprecated features --------------------------------+--------------------------------------- --------------------------------+---- Reporter: RolfRabenseifner | Owner: dgsolt Type: Text (only) changes | Status: new Priority: Waiting for reviews | Milestone: 2009/04/06 Chicago Version: MPI 2.2 | Resolution: Keywords: | Implementation: Unnecessary --------------------------------+--------------------------------------- --------------------------------+---- Changes (by RolfRabenseifner): * implementation: => Unnecessary Comment: The current proposal does not solve any problem, because on p78 Formula (4.1), an epsilon is used, which is defined in the next three lines, which end with a pointer to page 96. The new concept has still a lb&ub-concept that seems to be identical to the previous, i.e., the formulas on page 78 do not help (they are without lb und ub). The formulas on page 96 are the only valid formulas that explain the lb in the new routines MPI_Type_get_extent and MPI_Type_create_resized. p98.3-4 clearly tell about new pait of lower bound and upper bound markers. Proposal: remove MPI_LB and MPI_UB and substitute nearly each location by "lower bound (lb) marker" and "upper bound (ub) marker". -- Ticket URL: MPI Forum MPI Forum From thakur at [hidden] Wed Mar 25 11:23:24 2009 From: thakur at [hidden] (Rajeev Thakur) Date: Wed, 25 Mar 2009 11:23:24 -0500 Subject: [Mpi-22] Ticket #33: Fix Scalability Issues in Graph Topology Interface Message-ID: <55FA6B5F346A435A9E66A7B484AB6D35@mcs.anl.gov> We need more people reviewing this ticket to see if this is the right way to fix the scalability problem with graph topologies. Among the new features proposed in 2.2, it is a significant one and is not trivial to understand and vote on unless you have studied it beforehand. Rajeev Ticket URL: Please review ticket #143: MPI_Request_free bad advice to users for MPI 2.2. I moved the original proposal (ticket #47) to deprecate MPI_Request_free for active requests to MPI 3.0. Thanks, .Erez * -------------- next part -------------- An HTML attachment was scrubbed... URL: From koziol at [hidden] Thu Mar 26 11:50:40 2009 From: koziol at [hidden] (Quincey Koziol) Date: Thu, 26 Mar 2009 11:50:40 -0500 Subject: [Mpi-22] Ticket #71: Add routine for registering callback when finalize occurs In-Reply-To: Message-ID: <15A01783-4327-4271-920C-3E557A5FD629@hdfgroup.org> Hi all, Could another two people review this ticket for specifying the order that attribute delete callbacks should be made: https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/71 Thanks, Quincey * -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2502 bytes Desc: smime.p7s URL: From treumann at [hidden] Thu Mar 26 12:24:26 2009 From: treumann at [hidden] (Richard Treumann) Date: Thu, 26 Mar 2009 13:24:26 -0400 Subject: [Mpi-22] Ticket #71: Add routine for registering callback when finalize occurs In-Reply-To: <15A01783-4327-4271-920C-3E557A5FD629@hdfgroup.org> Message-ID: Why would this be specific to MPI_COMM_SELF? If this is the right thing to do, shouldn't it apply to attribute delete functions on all disposed objects? Dick Treumann - MPI Team IBM Systems & Technology Group Dept X2ZA / MS P963 -- 2455 South Road -- Poughkeepsie, NY 12601 Tele (845) 433-7846 Fax (845) 433-8363 mpi-22-bounces_at_[hidden] wrote on 03/26/2009 12:50:40 PM: > [image removed] > > [Mpi-22] Ticket #71: Add routine for registering callback when finalize occurs > > Quincey Koziol > > to: > > mpi-22 > > 03/26/2009 12:54 PM: > > Sent by: > > mpi-22-bounces_at_[hidden] > > Please respond to "MPI 2.2" > > Hi all, > Could another two people review this ticket for specifying the order > that attribute delete callbacks should be made: > > https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/71 > > Thanks, > Quincey > > [attachment "smime.p7s" deleted by Richard Treumann/Poughkeepsie/ > IBM] _______________________________________________ > mpi-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 * -------------- next part -------------- An HTML attachment was scrubbed... URL: From buntinas at [hidden] Fri Mar 27 11:35:21 2009 From: buntinas at [hidden] (Darius Buntinas) Date: Fri, 27 Mar 2009 11:35:21 -0500 Subject: [Mpi-22] Ordering guarantees and multiple threads Message-ID: <49CD0049.5080908@mcs.anl.gov> I've just created a ticket: https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/144 to suggest that we strengthen the ordering guarantees between sends (and receives) from different threads. I think that the real question here is whether the potential benefit to the user outweighs the potential for optimization in a multithreaded implementation. Please have a look at it and feel free to comment. Thanks, -d From bronevetsky1 at [hidden] Fri Mar 27 12:25:29 2009 From: bronevetsky1 at [hidden] (Greg Bronevetsky) Date: Fri, 27 Mar 2009 10:25:29 -0700 Subject: [Mpi-22] Ordering guarantees and multiple threads In-Reply-To: <49CD0049.5080908@mcs.anl.gov> Message-ID: <7c0g87$17l1ab@nspiron-2.llnl.gov> At 09:35 AM 3/27/2009, Darius Buntinas wrote: >I've just created a ticket: > https:// svn.mpi-forum.org/trac/mpi-forum-web/ticket/144 >to suggest that we strengthen the ordering guarantees between sends (and >receives) from different threads. > >I think that the real question here is whether the potential benefit to >the user outweighs the potential for optimization in a multithreaded >implementation. > >Please have a look at it and feel free to comment. I like the spirit of this proposal but in practice it will be hard to specify. In particular, consider the sentence "two sends do not overlap if the first MPI_Send() returns before the second MPI_Send() is called". The word "before" here is only properly defined on a sequentially consistent memory. On any other memory model "before" is only defined by synchronization primitives supplied by the shared memory system. As such, I don't know how to be precise about something like "before" without talking about the shared memory system. This will be hard because we'll need to talk about concepts that all these systems share but for which they all provide different primitives and semantics. I don't know how the wider forum will react to such a specification. However, I agree that something like this is necessary. Greg Bronevetsky Post-Doctoral Researcher 1028 Building 451 Lawrence Livermore National Lab (925) 424-5756 bronevetsky1_at_[hidden] http://greg.bronevetsky.com From treumann at [hidden] Fri Mar 27 13:45:50 2009 From: treumann at [hidden] (Richard Treumann) Date: Fri, 27 Mar 2009 14:45:50 -0400 Subject: [Mpi-22] Ordering guarantees and multiple threads In-Reply-To: <7c0g87$17l1ab@nspiron-2.llnl.gov> Message-ID: The standard already says: If a sender sends two messages in succession to the same destination, and both match the same receive, then this operation cannot receive the second message if the first one is still pending. If a receiver posts two receives in succession, and both match the same message, then the second receive operation cannot be satisfied by this message, if the first one is still pending. This requirement facilitates matching of sends to receives. It guarantees that message-passing code is deterministic, I think that already provides the appropriate guarantee. Two concurrent threads making MPI calls do not provide any enforcement of "?succession" and the standard points this out to be helpful. It should not really have been necessary to say this. Explicit temporal ordering of actions on otherwise concurrent threads by an application is common and it is not the job of the MPI standard to say how this is to be done. MPI should probably only say in any situation where "?succession" is ambiguous, MPI makes no guarantee of disambiguation. Where "succession" is clear cut, MPI will reflect the succession order. Dick Treumann - MPI Team IBM Systems & Technology Group Dept X2ZA / MS P963 -- 2455 South Road -- Poughkeepsie, NY 12601 Tele (845) 433-7846 Fax (845) 433-8363 mpi-22-bounces_at_[hidden] wrote on 03/27/2009 01:25:29 PM: > [image removed] > > Re: [Mpi-22] Ordering guarantees and multiple threads > > Greg Bronevetsky > > to: > > MPI 2.2, MPI 2.2 > > 03/27/2009 01:27 PM > > Sent by: > > mpi-22-bounces_at_[hidden] > > Please respond to "MPI 2.2" > > At 09:35 AM 3/27/2009, Darius Buntinas wrote: > > >I've just created a ticket: > > https:// svn.mpi-forum.org/trac/mpi-forum-web/ticket/144 > >to suggest that we strengthen the ordering guarantees between sends (and > >receives) from different threads. > > > >I think that the real question here is whether the potential benefit to > >the user outweighs the potential for optimization in a multithreaded > >implementation. > > > >Please have a look at it and feel free to comment. > > I like the spirit of this proposal but in practice it will be hard to > specify. In particular, consider the sentence "two sends do not > overlap if the first MPI_Send() returns before the second MPI_Send() > is called". The word "before" here is only properly defined on a > sequentially consistent memory. On any other memory model "before" is > only defined by synchronization primitives supplied by the shared > memory system. As such, I don't know how to be precise about > something like "before" without talking about the shared memory > system. This will be hard because we'll need to talk about concepts > that all these systems share but for which they all provide different > primitives and semantics. I don't know how the wider forum will react > to such a specification. However, I agree that something like this is > necessary. > > Greg Bronevetsky > Post-Doctoral Researcher > 1028 Building 451 > Lawrence Livermore National Lab > (925) 424-5756 > bronevetsky1_at_[hidden] > http://greg.bronevetsky.com > > _______________________________________________ > mpi-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 * -------------- next part -------------- An HTML attachment was scrubbed... URL: From htor at [hidden] Sun Mar 29 16:28:58 2009 From: htor at [hidden] (Torsten Hoefler) Date: Sun, 29 Mar 2009 17:28:58 -0400 Subject: [Mpi-22] Ticket #33: Fix Scalability Issues in Graph Topology Interface In-Reply-To: <55FA6B5F346A435A9E66A7B484AB6D35@mcs.anl.gov> Message-ID: <20090329212858.GD18900@benten.cs.indiana.edu> Hello, > We need more people reviewing this ticket to see if this is the right way to > fix the scalability problem with graph topologies. Among the new features > proposed in 2.2, it is a significant one and is not trivial to understand > and vote on unless you have studied it beforehand. > > Ticket URL: Message-ID: <9A7F9DD0-3AEB-4E4C-9BB5-001B9377CEB4@hdfgroup.org> > Date: Thu, 26 Mar 2009 13:24:26 -0400 > From: Richard Treumann > Subject: Re: [Mpi-22] Ticket #71: Add routine for registering callback > when finalize occurs > To: "MPI 2.2" > Message-ID: > ON85257585.005F95BC-85257585.005F9F47_at_[hidden]> > Content-Type: text/plain; charset="us-ascii" > > Why would this be specific to MPI_COMM_SELF? If this is the right > thing to > do, shouldn't it apply to attribute delete functions on all disposed > objects? The ticket is oriented to what happens at MPI_Finalize, really, and not so much about MPI_COMM_SELF per se. The attribute callback on MPI_COMM_SELF was just the accepted way in the standard to "have something happen" when MPI_Finalize was called. Quincey > Dick Treumann - MPI Team > IBM Systems & Technology Group > Dept X2ZA / MS P963 -- 2455 South Road -- Poughkeepsie, NY 12601 > Tele (845) 433-7846 Fax (845) 433-8363 > > > mpi-22-bounces_at_[hidden] wrote on 03/26/2009 12:50:40 PM: > >> [image removed] >> >> [Mpi-22] Ticket #71: Add routine for registering callback when >> finalize > occurs >> >> Quincey Koziol >> >> to: >> >> mpi-22 >> >> 03/26/2009 12:54 PM: >> >> Sent by: >> >> mpi-22-bounces_at_[hidden] >> >> Please respond to "MPI 2.2" >> >> Hi all, >> Could another two people review this ticket for specifying the order >> that attribute delete callbacks should be made: >> >> https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/71 >> >> Thanks, >> Quincey >> >> [attachment "smime.p7s" deleted by Richard Treumann/Poughkeepsie/ >> IBM] _______________________________________________ >> mpi-22 mailing list >> mpi-22_at_[hidden] >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 > -------------- next part -------------- > HTML attachment scrubbed and removed > > ------------------------------ > > _______________________________________________ > mpi-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 > > > End of mpi-22 Digest, Vol 12, Issue 26 > ************************************** > * -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2502 bytes Desc: smime.p7s URL: From treumann at [hidden] Mon Mar 30 09:09:44 2009 From: treumann at [hidden] (Richard Treumann) Date: Mon, 30 Mar 2009 10:09:44 -0400 Subject: [Mpi-22] Ticket #71: Add routine for registering callback when finalize occurs In-Reply-To: <9A7F9DD0-3AEB-4E4C-9BB5-001B9377CEB4@hdfgroup.org> Message-ID: I understand that the immediate motive is associated with the use of attribute delete callbacks that occur when MPI_COMM_SELF is freed at MPI_FINALIZE. That does not alter the fact that when MPI-2 imposed an implicit free of MPI_COMM_SELF in MPI_FINALIZE to allow the use of attribute delete functions for cleanup it involved a narrow extension of a general MPI facility related to attributes and certain object types. To allow attribute delete functions for all other communicators (etc) to occur in arbitrary order while demanding that attribute delete for MPI_COMM_SELF have a standards defined order is an inelegant hack (in my opinion). Freeing MPI_COMM_SELF within MPI_FINALIZE was a relatively elegant hack because it did not introduce inconsistency. Add to that the probability that an MPI implementor is likely to use the same algorithms for all attribute management rather than write special case code for MPI_COMM_SELF leads me to argue that if a defined order for attribute delete callbacks is adopted it should be adopted broadly to maintain a consistent flavor across the standard. If an existing MPI implementation is currently deleting in some other order and an application happens to work on that MPI only because of that order, that application is at least non-portable and probably should be considered buggy. If (or when) the implementation adopts the fifo order for attribute deletes on "user_comm" it would be clear that the implementation change had not "broken the user". A general mandate that attribute deletion callbacks on all object types must occur in fifo order for an implementation to be MPI 2.2 compliant should not break any "correct" MPI application and should not be noticeably harder for implementors. It will require tracking down all places in the standard that currently say the order is arbitrary so it is harder to get all ducks in a row for the ticket. Dick Treumann - MPI Team IBM Systems & Technology Group Dept X2ZA / MS P963 -- 2455 South Road -- Poughkeepsie, NY 12601 Tele (845) 433-7846 Fax (845) 433-8363 mpi-22-bounces_at_[hidden] wrote on 03/28/2009 11:57:19 PM: > [image removed] > > Re: [Mpi-22] Ticket #71: Add routine for registering callback when > finalize occurs > > Quincey Koziol > > to: > > mpi-22 > > 03/30/2009 09:28 AM > > Sent by: > > mpi-22-bounces_at_[hidden] > > Please respond to "MPI 2.2" > > > > Date: Thu, 26 Mar 2009 13:24:26 -0400 > > From: Richard Treumann > > Subject: Re: [Mpi-22] Ticket #71: Add routine for registering callback > > when finalize occurs > > To: "MPI 2.2" > > Message-ID: > > > ON85257585.005F95BC-85257585.005F9F47_at_[hidden]> > > Content-Type: text/plain; charset="us-ascii" > > > > Why would this be specific to MPI_COMM_SELF? If this is the right > > thing to > > do, shouldn't it apply to attribute delete functions on all disposed > > objects? > > The ticket is oriented to what happens at MPI_Finalize, really, and > not so much about MPI_COMM_SELF per se. The attribute callback on > MPI_COMM_SELF was just the accepted way in the standard to "have > something happen" when MPI_Finalize was called. > > Quincey > > > Dick Treumann - MPI Team > > IBM Systems & Technology Group > > Dept X2ZA / MS P963 -- 2455 South Road -- Poughkeepsie, NY 12601 > > Tele (845) 433-7846 Fax (845) 433-8363 > > > > > > mpi-22-bounces_at_[hidden] wrote on 03/26/2009 12:50:40 PM: > > > >> [image removed] > >> > >> [Mpi-22] Ticket #71: Add routine for registering callback when > >> finalize > > occurs > >> > >> Quincey Koziol > >> > >> to: > >> > >> mpi-22 > >> > >> 03/26/2009 12:54 PM: > >> > >> Sent by: > >> > >> mpi-22-bounces_at_[hidden] > >> > >> Please respond to "MPI 2.2" > >> > >> Hi all, > >> Could another two people review this ticket for specifying the order > >> that attribute delete callbacks should be made: > >> > >> https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/71 > >> > >> Thanks, > >> Quincey > >> > >> [attachment "smime.p7s" deleted by Richard Treumann/Poughkeepsie/ > >> IBM] _______________________________________________ > >> mpi-22 mailing list > >> mpi-22_at_[hidden] > >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 > > -------------- next part -------------- > > HTML attachment scrubbed and removed > > > > ------------------------------ > > > > _______________________________________________ > > mpi-22 mailing list > > mpi-22_at_[hidden] > > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 > > > > > > End of mpi-22 Digest, Vol 12, Issue 26 > > ************************************** > > > > [attachment "smime.p7s" deleted by Richard Treumann/Poughkeepsie/ > IBM] _______________________________________________ > mpi-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 * -------------- next part -------------- An HTML attachment was scrubbed... URL: From treumann at [hidden] Mon Mar 30 13:53:04 2009 From: treumann at [hidden] (Richard Treumann) Date: Mon, 30 Mar 2009 14:53:04 -0400 Subject: [Mpi-22] Fw: Ticket #71: Add routine for registering callback when finalize occurs Message-ID: I should have said LIFO below. The proposal is to have attribute deletion callback occur in the reverse of the order in which they were placed. I have no objection to making this part of the standard but do not think it should be unique to MPI_COMM_SELF if we adopt it. Dick Treumann - MPI Team IBM Systems & Technology Group Dept X2ZA / MS P963 -- 2455 South Road -- Poughkeepsie, NY 12601 Tele (845) 433-7846 Fax (845) 433-8363 ----- Forwarded by Richard Treumann/Poughkeepsie/IBM on 03/30/2009 02:49 PM ----- From: Richard Treumann/Poughkeepsie/IBM_at_IBMUS To: "MPI 2.2" Date: 03/30/2009 10:12 AM Subject: Re: [Mpi-22] Ticket #71: Add routine for registering callback when finalize occurs I understand that the immediate motive is associated with the use of attribute delete callbacks that occur when MPI_COMM_SELF is freed at MPI_FINALIZE. That does not alter the fact that when MPI-2 imposed an implicit free of MPI_COMM_SELF in MPI_FINALIZE to allow the use of attribute delete functions for cleanup it involved a narrow extension of a general MPI facility related to attributes and certain object types. To allow attribute delete functions for all other communicators (etc) to occur in arbitrary order while demanding that attribute delete for MPI_COMM_SELF have a standards defined order is an inelegant hack (in my opinion). Freeing MPI_COMM_SELF within MPI_FINALIZE was a relatively elegant hack because it did not introduce inconsistency. Add to that the probability that an MPI implementor is likely to use the same algorithms for all attribute management rather than write special case code for MPI_COMM_SELF leads me to argue that if a defined order for attribute delete callbacks is adopted it should be adopted broadly to maintain a consistent flavor across the standard. If an existing MPI implementation is currently deleting in some other order and an application happens to work on that MPI only because of that order, that application is at least non-portable and probably should be considered buggy. If (or when) the implementation adopts the fifo order for attribute deletes on "user_comm" it would be clear that the implementation change had not "broken the user". A general mandate that attribute deletion callbacks on all object types must occur in fifo order for an implementation to be MPI 2.2 compliant should not break any "correct" MPI application and should not be noticeably harder for implementors. It will require tracking down all places in the standard that currently say the order is arbitrary so it is harder to get all ducks in a row for the ticket. Dick Treumann - MPI Team IBM Systems & Technology Group Dept X2ZA / MS P963 -- 2455 South Road -- Poughkeepsie, NY 12601 Tele (845) 433-7846 Fax (845) 433-8363 mpi-22-bounces_at_[hidden] wrote on 03/28/2009 11:57:19 PM: > [image removed] > > Re: [Mpi-22] Ticket #71: Add routine for registering callback when > finalize occurs > > Quincey Koziol > > to: > > mpi-22 > > 03/30/2009 09:28 AM > > Sent by: > > mpi-22-bounces_at_[hidden] > > Please respond to "MPI 2.2" > > > > Date: Thu, 26 Mar 2009 13:24:26 -0400 > > From: Richard Treumann > > Subject: Re: [Mpi-22] Ticket #71: Add routine for registering callback > > when finalize occurs > > To: "MPI 2.2" > > Message-ID: > > > ON85257585.005F95BC-85257585.005F9F47_at_[hidden]> > > Content-Type: text/plain; charset="us-ascii" > > > > Why would this be specific to MPI_COMM_SELF? If this is the right > > thing to > > do, shouldn't it apply to attribute delete functions on all disposed > > objects? > > The ticket is oriented to what happens at MPI_Finalize, really, and > not so much about MPI_COMM_SELF per se. The attribute callback on > MPI_COMM_SELF was just the accepted way in the standard to "have > something happen" when MPI_Finalize was called. > > Quincey > > > Dick Treumann - MPI Team > > IBM Systems & Technology Group > > Dept X2ZA / MS P963 -- 2455 South Road -- Poughkeepsie, NY 12601 > > Tele (845) 433-7846 Fax (845) 433-8363 > > > > > > mpi-22-bounces_at_[hidden] wrote on 03/26/2009 12:50:40 PM: > > > >> [image removed] > >> > >> [Mpi-22] Ticket #71: Add routine for registering callback when > >> finalize > > occurs > >> > >> Quincey Koziol > >> > >> to: > >> > >> mpi-22 > >> > >> 03/26/2009 12:54 PM: > >> > >> Sent by: > >> > >> mpi-22-bounces_at_[hidden] > >> > >> Please respond to "MPI 2.2" > >> > >> Hi all, > >> Could another two people review this ticket for specifying the order > >> that attribute delete callbacks should be made: > >> > >> https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/71 > >> > >> Thanks, > >> Quincey > >> > >> [attachment "smime.p7s" deleted by Richard Treumann/Poughkeepsie/ > >> IBM] _______________________________________________ > >> mpi-22 mailing list > >> mpi-22_at_[hidden] > >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 > > -------------- next part -------------- > > HTML attachment scrubbed and removed > > > > ------------------------------ > > > > _______________________________________________ > > mpi-22 mailing list > > mpi-22_at_[hidden] > > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 > > > > > > End of mpi-22 Digest, Vol 12, Issue 26 > > ************************************** > > > > [attachment "smime.p7s" deleted by Richard Treumann/Poughkeepsie/ > IBM] _______________________________________________ > mpi-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 _______________________________________________ mpi-22 mailing list mpi-22_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 * -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ecblank.gif Type: application/octet-stream Size: 45 bytes Desc: not available URL: From ritzdorf at [hidden] Mon Mar 30 16:20:51 2009 From: ritzdorf at [hidden] (Hubert Ritzdorf) Date: Mon, 30 Mar 2009 23:20:51 +0200 Subject: [Mpi-22] Additional Reviews for ticket #59: Clarification on MPI::FILE_NULL, MPI::WIN_NULL and MPI::COMM_NULL Message-ID: <49D137B3.9070100@it.neclab.eu> Hi, I'm looking for 2 additional reviews for Ticket #59. If there is additional interest to clarify the status of MPI::FILE_NULL and MPI::WIN_NULL and if you are interested to have the predefined C++ datatypes const-qualified again, please review ticket 59 (https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/59). Many thanks in advance Hubert * -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: