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 12 Mar '09

12 Mar '09

Possibly you'll have to cast. There are few interfaces that take const for send buffer (like sockets). In other cases you copy the buffer (like with IB) which keeps the const property. Thanks, .Erez -----Original Message----- From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Underwood, Keith D Sent: Thursday, March 12, 2009 12:05 PM To: MPI 2.2 Subject: Re: [Mpi-22] Ticket #46: Add const Keyword to the C bindings- implementation It would seem like const would eventually have to be cast away for most lower level interfaces. Portals, Elan, IB Verbs, and as best I can tell MX don't have const on their send buffers... Keith >-----Original Message----- >From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_lists.mpi- >forum.org] On Behalf Of Erez Haba >Sent: Thursday, March 12, 2009 12:44 PM >To: MPI 2.2 >Subject: Re: [Mpi-22] Ticket #46: Add const Keyword to the C bindings- >implementation > >No, it's not being cast away (although it is a quick way for you to >implement it). >In MPICH2 implementation it trickles down to the lower functions. There are >very few places where the const is being cast away because ticket #46 does >not to break backward compatibility. >For example, when the user function is called (const was not added to the >MPI_User_function) the implementation must cast away const from the send >buffer before calling the user function. > >Thanks, >.Erez > >-----Original Message----- >From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_lists.mpi- >forum.org] On Behalf Of Jeff Squyres >Sent: Thursday, March 12, 2009 11:34 AM >To: MPI 2.2 >Subject: Re: [Mpi-22] Ticket #46: Add const Keyword to the C bindings- >implementation > >More importantly, how is const handled? Is it just cast away inside >the MPI library? > > >On Mar 12, 2009, at 2:34 PM, Underwood, Keith D wrote: > >> Since the main purpose of an implementation for something like >> adding const is to see how invasive the change is, would it be >> possible to get a diff against the trees that these were created from? >> >> Thanks, >> Keith >> >> From: mpi-22-bounces_at_[hidden] [mailto:mpi-22- >bounces_at_[hidden] >> ] On Behalf Of Erez Haba >> Sent: Thursday, March 12, 2009 12:24 PM >> To: MPI 2.2 >> Subject: [Mpi-22] Ticket #46: Add const Keyword to the C bindings - >> implementation >> >> >> Implementation for ticket #46 is now available from ANL (thanks Pavan) >> >> >> tarballs >> >http://www.mcs.anl.gov/research/projects/mpich2/downloads/tarballs/nightly/ >const >> >> >> thanks, >> .Erez >> >> _______________________________________________ >> mpi-22 mailing list >> mpi-22_at_[hidden] >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 > > >-- >Jeff Squyres >Cisco Systems > >_______________________________________________ >mpi-22 mailing list >mpi-22_at_[hidden] >http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 > > >_______________________________________________ >mpi-22 mailing list >mpi-22_at_[hidden] >http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 _______________________________________________ mpi-22 mailing list mpi-22_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22

1 0

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

12 Mar '09

> Im not sure if ANL has a diff/patch on top of the trunk. Pavan? Rajeev? Uploaded the diff to the ticket. -- Pavan -- Pavan Balaji http://www.mcs.anl.gov/~balaji

1 0

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

12 Mar '09

It would seem like const would eventually have to be cast away for most lower level interfaces. Portals, Elan, IB Verbs, and as best I can tell MX don't have const on their send buffers... Keith >-----Original Message----- >From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_lists.mpi- >forum.org] On Behalf Of Erez Haba >Sent: Thursday, March 12, 2009 12:44 PM >To: MPI 2.2 >Subject: Re: [Mpi-22] Ticket #46: Add const Keyword to the C bindings- >implementation > >No, it's not being cast away (although it is a quick way for you to >implement it). >In MPICH2 implementation it trickles down to the lower functions. There are >very few places where the const is being cast away because ticket #46 does >not to break backward compatibility. >For example, when the user function is called (const was not added to the >MPI_User_function) the implementation must cast away const from the send >buffer before calling the user function. > >Thanks, >.Erez > >-----Original Message----- >From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_lists.mpi- >forum.org] On Behalf Of Jeff Squyres >Sent: Thursday, March 12, 2009 11:34 AM >To: MPI 2.2 >Subject: Re: [Mpi-22] Ticket #46: Add const Keyword to the C bindings- >implementation > >More importantly, how is const handled? Is it just cast away inside >the MPI library? > > >On Mar 12, 2009, at 2:34 PM, Underwood, Keith D wrote: > >> Since the main purpose of an implementation for something like >> adding const is to see how invasive the change is, would it be >> possible to get a diff against the trees that these were created from? >> >> Thanks, >> Keith >> >> From: mpi-22-bounces_at_[hidden] [mailto:mpi-22- >bounces_at_[hidden] >> ] On Behalf Of Erez Haba >> Sent: Thursday, March 12, 2009 12:24 PM >> To: MPI 2.2 >> Subject: [Mpi-22] Ticket #46: Add const Keyword to the C bindings - >> implementation >> >> >> Implementation for ticket #46 is now available from ANL (thanks Pavan) >> >> >> tarballs >> >http://www.mcs.anl.gov/research/projects/mpich2/downloads/tarballs/nightly/ >const >> >> >> thanks, >> .Erez >> >> _______________________________________________ >> mpi-22 mailing list >> mpi-22_at_[hidden] >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 > > >-- >Jeff Squyres >Cisco Systems > >_______________________________________________ >mpi-22 mailing list >mpi-22_at_[hidden] >http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 > > >_______________________________________________ >mpi-22 mailing list >mpi-22_at_[hidden] >http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22

1 0

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

12 Mar '09

No, it's not being cast away (although it is a quick way for you to implement it). In MPICH2 implementation it trickles down to the lower functions. There are very few places where the const is being cast away because ticket #46 does not to break backward compatibility. For example, when the user function is called (const was not added to the MPI_User_function) the implementation must cast away const from the send buffer before calling the user function. Thanks, .Erez -----Original Message----- From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Jeff Squyres Sent: Thursday, March 12, 2009 11:34 AM To: MPI 2.2 Subject: Re: [Mpi-22] Ticket #46: Add const Keyword to the C bindings- implementation More importantly, how is const handled? Is it just cast away inside the MPI library? On Mar 12, 2009, at 2:34 PM, Underwood, Keith D wrote: > Since the main purpose of an implementation for something like > adding const is to see how invasive the change is, would it be > possible to get a diff against the trees that these were created from? > > Thanks, > Keith > > From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden] > ] On Behalf Of Erez Haba > Sent: Thursday, March 12, 2009 12:24 PM > To: MPI 2.2 > Subject: [Mpi-22] Ticket #46: Add const Keyword to the C bindings - > implementation > > > Implementation for ticket #46 is now available from ANL (thanks Pavan) > > > tarballs > http://www.mcs.anl.gov/research/projects/mpich2/downloads/tarballs/nightly/… > > > thanks, > .Erez > > _______________________________________________ > mpi-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 -- Jeff Squyres Cisco Systems _______________________________________________ mpi-22 mailing list mpi-22_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22

1 0

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

12 Mar '09

See the ticket. It has a link to the svn. I'm not sure if ANL has a diff/patch on top of the trunk. Pavan? Rajeev? Thanks, .Erez From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Underwood, Keith D Sent: Thursday, March 12, 2009 11:34 AM To: MPI 2.2 Subject: Re: [Mpi-22] Ticket #46: Add const Keyword to the C bindings - implementation Since the main purpose of an implementation for something like adding const is to see how invasive the change is, would it be possible to get a diff against the trees that these were created from? Thanks, Keith ________________________________ From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Erez Haba Sent: Thursday, March 12, 2009 12:24 PM To: MPI 2.2 Subject: [Mpi-22] Ticket #46: Add const Keyword to the C bindings - implementation Implementation for ticket #46<https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/46> is now available from ANL (thanks Pavan) tarballs http://www.mcs.anl.gov/research/projects/mpich2/downloads/tarballs/nightly/… thanks, .Erez *

1 0

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

12 Mar '09

More importantly, how is const handled? Is it just cast away inside the MPI library? On Mar 12, 2009, at 2:34 PM, Underwood, Keith D wrote: > Since the main purpose of an implementation for something like > adding const is to see how invasive the change is, would it be > possible to get a diff against the trees that these were created from? > > Thanks, > Keith > > From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden] > ] On Behalf Of Erez Haba > Sent: Thursday, March 12, 2009 12:24 PM > To: MPI 2.2 > Subject: [Mpi-22] Ticket #46: Add const Keyword to the C bindings - > implementation > > > Implementation for ticket #46 is now available from ANL (thanks Pavan) > > > tarballs > http://www.mcs.anl.gov/research/projects/mpich2/downloads/tarballs/nightly/… > > > thanks, > .Erez > > _______________________________________________ > 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 12 Mar '09

12 Mar '09

Since the main purpose of an implementation for something like adding const is to see how invasive the change is, would it be possible to get a diff against the trees that these were created from? Thanks, Keith ________________________________ From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Erez Haba Sent: Thursday, March 12, 2009 12:24 PM To: MPI 2.2 Subject: [Mpi-22] Ticket #46: Add const Keyword to the C bindings - implementation Implementation for ticket #46<https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/46> is now available from ANL (thanks Pavan) tarballs http://www.mcs.anl.gov/research/projects/mpich2/downloads/tarballs/nightly/… thanks, .Erez *

1 0

Ticket #46: Add const Keyword to the C bindings - implementation
by unknown＠example.com 12 Mar '09

12 Mar '09

Implementation for ticket #46<https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/46> is now available from ANL (thanks Pavan) tarballs http://www.mcs.anl.gov/research/projects/mpich2/downloads/tarballs/nightly/… thanks, .Erez *

1 0

Re: [Mpi-22] MPI_Aint/MPI_ADDRESS_KIND equivalence and ticket #18
by unknown＠example.com 09 Mar '09

09 Mar '09

On Mar 9, 2009, at 2:34 PM, Rajeev Thakur wrote: > Address-sized variables in MPI can be passed from C to Fortran or vice > versa, and I know of no c2f or f2c conversion functions for them. So > I think > MPI_Aint and integer (kind=MPI_ADDRESS_KIND) are assumed to be of > the same > size at least implicitly. > I agree. Should we state this explicitly somewhere (if we didn't already)? > > Rajeev > > > > -----Original Message----- > > From: mpi-22-bounces_at_[hidden] > > [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Dave > Goodell > > Sent: Friday, March 06, 2009 1:09 PM > > To: MPI 2.2 > > Subject: [Mpi-22] MPI_Aint/MPI_ADDRESS_KIND equivalence and ticket > #18 > > > > At the last meeting in San Jose, Rolf brought up a good point w.r.t. > > ticket #18 [1]. Part of the proposal for ticket #18 is to add > > MPI_AINT and MPI_OFFSET types corresponding to MPI_Aint/ > > MPI_ADDRESS_KIND and MPI_Offset/MPI_OFFSET_KIND language types. > > Rolf's point was that it isn't defined in the standard > > whether or not > > MPI_Aint and INTEGER(KIND=MPI_ADDRESS_KIND) are exactly the same > > type. Obviously we cannot define a new predefined datatype > > corresponding to two different language types. I believe > > Rolf's view > > (correct me if I'm misrepresenting you, Rolf) was that the > > forum ought > > to make their equivalence explicit, irrespective of what > > happens with > > ticket #18. I'm ambivalent about this issue, but I need a > > resolution > > on it in order to get #18 into a final voteable state. > > > > So the larger question to the Forum is: Are these types exactly the > > same between the two languages? > > > > Looking at MPICH2 it seems that we try to make them the same > > size but > > there are some convoluted code paths in the build logic that might > > result in different sizes. I would not consider this to be a > > compelling argument that they are permitted to differ because the > > logic in question may simply be buggy or never exercised. > > Does anyone > > have an example from other MPI implementations where the > > types do/may > > differ? Do any Fortran experts out there know of instances where > > MPI_ADDRESS_KIND would be different from MPI_Aint? > > > > As for the impact on ticket #18, there are several ways to deal with > > this: > > > > 1) If the Forum decides that the types are always equivalent, > > add text > > to that effect (probably in a separate ticket) and otherwise stick > > with the current proposal. > > 2) If the Forum decides that the type equivalence is undefined, drop > > the new MPI_AINT/MPI_OFFSET types from the proposal. > > 3) If the Forum decides that the type equivalence is > > undefined, create > > four types instead of just two: MPI_AINT, MPI_OFFSET, MPI_F_AINT, > > MPI_F_OFFSET (or some such names). > > 4) If the Forum decides that the type equivalence is undefined, make > > MPI_AINT/MPI_OFFSET only correspond to the C types. > > > > I'm inclined towards either #1 or #2, depending on what the Forum > > decides about the type equivalence. I also can separate the > > MPI_AINT/ > > MPI_OFFSET types out into a separate ticket if this becomes too > > contentious of an issue, but I'd like to keep it together for now > > since the text changes are easier to describe correctly in just one > > place. > > > > -Dave > > > > [1] https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/18 > > _______________________________________________ > > mpi-22 mailing list > > mpi-22_at_[hidden] > > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 > > > > _______________________________________________ > mpi-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 -- Jeff Squyres Cisco Systems

1 0

Re: [Mpi-22] MPI_Aint/MPI_ADDRESS_KIND equivalence and ticket #18
by unknown＠example.com 09 Mar '09

09 Mar '09

Address-sized variables in MPI can be passed from C to Fortran or vice versa, and I know of no c2f or f2c conversion functions for them. So I think MPI_Aint and integer (kind=MPI_ADDRESS_KIND) are assumed to be of the same size at least implicitly. Rajeev > -----Original Message----- > From: mpi-22-bounces_at_[hidden] > [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Dave Goodell > Sent: Friday, March 06, 2009 1:09 PM > To: MPI 2.2 > Subject: [Mpi-22] MPI_Aint/MPI_ADDRESS_KIND equivalence and ticket #18 > > At the last meeting in San Jose, Rolf brought up a good point w.r.t. > ticket #18 [1]. Part of the proposal for ticket #18 is to add > MPI_AINT and MPI_OFFSET types corresponding to MPI_Aint/ > MPI_ADDRESS_KIND and MPI_Offset/MPI_OFFSET_KIND language types. > Rolf's point was that it isn't defined in the standard > whether or not > MPI_Aint and INTEGER(KIND=MPI_ADDRESS_KIND) are exactly the same > type. Obviously we cannot define a new predefined datatype > corresponding to two different language types. I believe > Rolf's view > (correct me if I'm misrepresenting you, Rolf) was that the > forum ought > to make their equivalence explicit, irrespective of what > happens with > ticket #18. I'm ambivalent about this issue, but I need a > resolution > on it in order to get #18 into a final voteable state. > > So the larger question to the Forum is: Are these types exactly the > same between the two languages? > > Looking at MPICH2 it seems that we try to make them the same > size but > there are some convoluted code paths in the build logic that might > result in different sizes. I would not consider this to be a > compelling argument that they are permitted to differ because the > logic in question may simply be buggy or never exercised. > Does anyone > have an example from other MPI implementations where the > types do/may > differ? Do any Fortran experts out there know of instances where > MPI_ADDRESS_KIND would be different from MPI_Aint? > > As for the impact on ticket #18, there are several ways to deal with > this: > > 1) If the Forum decides that the types are always equivalent, > add text > to that effect (probably in a separate ticket) and otherwise stick > with the current proposal. > 2) If the Forum decides that the type equivalence is undefined, drop > the new MPI_AINT/MPI_OFFSET types from the proposal. > 3) If the Forum decides that the type equivalence is > undefined, create > four types instead of just two: MPI_AINT, MPI_OFFSET, MPI_F_AINT, > MPI_F_OFFSET (or some such names). > 4) If the Forum decides that the type equivalence is undefined, make > MPI_AINT/MPI_OFFSET only correspond to the C types. > > I'm inclined towards either #1 or #2, depending on what the Forum > decides about the type equivalence. I also can separate the > MPI_AINT/ > MPI_OFFSET types out into a separate ticket if this becomes too > contentious of an issue, but I'd like to keep it together for now > since the text changes are easier to describe correctly in just one > place. > > -Dave > > [1] https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/18 > _______________________________________________ > mpi-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 >

1 0