March 2009 - Mpi-22 - mailman3.cels.anl.gov

Re: [Mpi-22] Ticket #46: Add const Keyword to the C bindings-implementation
by unknown＠example.com 18 Mar '09

18 Mar '09

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] <mpi-22-bounces_at_[hidden]> To: MPI 2.2 <mpi-22_at_[hidden]> 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 *

1 0

Re: [Mpi-22] Ticket #46: Add const Keyword to the C bindings-implementation
by unknown＠example.com 18 Mar '09

18 Mar '09

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

1 0

Re: [Mpi-22] Ticket #46: Add const Keyword to the C bindings-implementation
by unknown＠example.com 18 Mar '09

18 Mar '09

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.

1 0

Re: [Mpi-22] Ticket #46: Add const Keyword to the C bindings-implementation
by unknown＠example.com 18 Mar '09

18 Mar '09

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

1 0

Re: [Mpi-22] Ticket #46: Add const Keyword to the C bindings-implementation
by unknown＠example.com 18 Mar '09

18 Mar '09

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.

1 0

Re: [Mpi-22] Ticket #46: Add const Keyword to the C bindings-implementation
by unknown＠example.com 17 Mar '09

17 Mar '09

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

1 0

Re: [Mpi-22] Ticket #46: Add const Keyword to the C bindings-implementation
by unknown＠example.com 17 Mar '09

17 Mar '09

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

1 0

Re: [Mpi-22] Ticket #46: Add const Keyword to the C bindings-implementation
by unknown＠example.com 17 Mar '09

17 Mar '09

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.

1 0

Re: [Mpi-22] Ticket #46: Add const Keyword to the C bindings-implementation
by unknown＠example.com 16 Mar '09

16 Mar '09

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

1 0

Re: [Mpi-22] Ticket #46: Add const Keyword to the C bindings-implementation
by unknown＠example.com 16 Mar '09

16 Mar '09

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.

1 0