July 2010 - Mpi3-bwcompat - mailman3.cels.anl.gov

Re: [Mpi3-bwcompat] Meeting notes from 7/23
by unknown＠example.com 23 Jul '10

23 Jul '10

If you couldn't tell from the notes, this was quite a lively meeting. :-) On Jul 23, 2010, at 6:03 PM, Solt, David George wrote: > Also available on https://svn.mpi-forum.org/trac/mpi-forum-web/wiki/BackCompatMeetings > > Discussion was around the continued effort around MPI_Count. The latest effort (#224) is a re-work of an early 2.2 proposal to introduce MPI_Count but allow implementations to define MPI_Count to be an int in order to retain backward compatibility. Fabian has been working through some of the details, and there are a few "boundary" cases where MPI_Count interfaces with other concepts. In particular MPI_Pack which currently looks like this: > > int MPI_Pack(void* inbuf, int incount, MPI_Datatype datatype, void* outbuf, int outsize, int *position, MPI_Comm comm) > > This API uses outsize and position, neither of which are well-defined as either an int or an MPI_Count. Several ideas were discussed around making one or other of outsize and position one of the following: MPI_Count, size_t, uint64, MPI_Aint, MPI_Size, MPI_Position. We wrestled with the exact meaning of "what is a position" and how does it relate to other uses of MPI_Aint, etc. We discussed whether there needs to be a distinction between the size of an "offset" in memory vs. within a message vs. within a file. (Notetaker's note: MPI_Offset is generally used for file positions, MPI_Aint for memory positions and MPI_Count is proposed to address positions within a message) > > MPI_Pack ties several of these concepts together because MPI_Pack creates something in memory but is also intended to be used as a message or could be used in a file operation. The "result" of MPI_Pack is currently an int (position) which represents a position in memory (therefore should have been MPI_Aint) but is used roughly as a message count in sends/recvs (thus MPI_Count). The number of bytes which can be packed can exceed the size of MPI_Count and thus could force us to make requirements about the relative sizes of MPI_Aint and MPI_Count. We did not want to do that. In the end we agreed that position, which is currently defined as "current position in buffer, in bytes" should be re-defined as a "current count of MPI_PACKED datatypes within the buffer" (something like that) and therefore can be an MPI_Count. This means that MPI_Pack is now restricted to working with buffers which are only capable of being "indexed" with MPI_Count values. The argument really represents t! > he position within a buffer, but we have re-framed it in this way to avoid introducing a new type and to ensure that position will be something we can pass as an MPI_Count to communication routines. Another option we considered here was using MPI_Offset for the position argument -- because that's pretty much what it is: an offset. But we can't do that for two reasons: 1) it would break backwards compatibility (because MPI_Offset != int in many current MPI implementations), and 2) you can't pass an MPI_Offset to the count argument of MPI_Send. We will add some text explaining that MPI_Pack is not intended to pack extremely large buffers and that extremely large messages should be pipe-lined with multiple MPI_Pack/MPI_Send operations for performance reasons. > > The outsize argument, on the other hand, cannot as easily be converted to an MPI_Count argument. We could say that the position is always in terms of how many counts of MPI_BYTE's would fit into the buffer, but that is a contorted use of MPI_Count. So, we proposed to introduce MPI_Size for use as the outsize argument to MPI_Pack/MPI_Unpack. We did not discuss it much, but I believe it will also get used for MPI_Type_size. Another option we considered here was using MPI_Offset for the position argument -- because that's pretty much what it is: an offset. But we can't do that for two reasons: 1) it would break backwards compatibility (because MPI_Offset != int in many current MPI implementations), and 2) you can't pass an MPI_Offset to the count argument of MPI_Send. MPI_Size will not need to be tied in any way to the size of MPI_Count. If on a system, MPI_Count is smaller than MPI_Size, it only means that we can pass in very large buffers to MPI_Pack, but not very large count! > s. If MPI_Count is larger than MPI_Size, it means that we may not be able to pack as large a message as we can send directly with communication routines. > > Agreed on a schedule for the next 2 weeks in which Fab will update the ticket based on today's discussion and the other attendees are encouraged to start dividing up the chapters to search for example code which should be changed to reflect the changes being proposed. > > The plan is to polish off ticket #224 and have an implementation for the October, 2010 meeting. > > _______________________________________________ > Mpi3-bwcompat mailing list > Mpi3-bwcompat_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-bwcompat > -- Jeff Squyres jsquyres_at_[hidden] For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/

1 0

Meeting notes from 7/23
by unknown＠example.com 23 Jul '10

23 Jul '10

Also available on https://svn.mpi-forum.org/trac/mpi-forum-web/wiki/BackCompatMeetings Discussion was around the continued effort around MPI_Count. The latest effort (#224) is a re-work of an early 2.2 proposal to introduce MPI_Count but allow implementations to define MPI_Count to be an int in order to retain backward compatibility. Fabian has been working through some of the details, and there are a few "boundary" cases where MPI_Count interfaces with other concepts. In particular MPI_Pack which currently looks like this: int MPI_Pack(void* inbuf, int incount, MPI_Datatype datatype, void* outbuf, int outsize, int *position, MPI_Comm comm) This API uses outsize and position, neither of which are well-defined as either an int or an MPI_Count. Several ideas were discussed around making one or other of outsize and position one of the following: MPI_Count, size_t, uint64, MPI_Aint, MPI_Size, MPI_Position. We wrestled with the exact meaning of "what is a position" and how does it relate to other uses of MPI_Aint, etc. We discussed whether there needs to be a distinction between the size of an "offset" in memory vs. within a message vs. within a file. (Notetaker's note: MPI_Offset is generally used for file positions, MPI_Aint for memory positions and MPI_Count is proposed to address positions within a message) MPI_Pack ties several of these concepts together because MPI_Pack creates something in memory but is also intended to be used as a message or could be used in a file operation. The "result" of MPI_Pack is currently an int (position) which represents a position in memory (therefore should have been MPI_Aint) but is used roughly as a message count in sends/recvs (thus MPI_Count). The number of bytes which can be packed can exceed the size of MPI_Count and thus could force us to make requirements about the relative sizes of MPI_Aint and MPI_Count. We did not want to do that. In the end we agreed that position, which is currently defined as "current position in buffer, in bytes" should be re-defined as a "current count of MPI_PACKED datatypes within the buffer" (something like that) and therefore can be an MPI_Count. This means that MPI_Pack is now restricted to working with buffers which are only capable of being "indexed" with MPI_Count values. The argument really represents the position within a buffer, but w e have re-framed it in this way to avoid introducing a new type and to ensure that position will be something we can pass as an MPI_Count to communication routines. Another option we considered here was using MPI_Offset for the position argument -- because that's pretty much what it is: an offset. But we can't do that for two reasons: 1) it would break backwards compatibility (because MPI_Offset != int in many current MPI implementations), and 2) you can't pass an MPI_Offset to the count argument of MPI_Send. We will add some text explaining that MPI_Pack is not intended to pack extremely large buffers and that extremely large messages should be pipe-lined with multiple MPI_Pack/MPI_Send operations for performance reasons. The outsize argument, on the other hand, cannot as easily be converted to an MPI_Count argument. We could say that the position is always in terms of how many counts of MPI_BYTE's would fit into the buffer, but that is a contorted use of MPI_Count. So, we proposed to introduce MPI_Size for use as the outsize argument to MPI_Pack/MPI_Unpack. We did not discuss it much, but I believe it will also get used for MPI_Type_size. Another option we considered here was using MPI_Offset for the position argument -- because that's pretty much what it is: an offset. But we can't do that for two reasons: 1) it would break backwards compatibility (because MPI_Offset != int in many current MPI implementations), and 2) you can't pass an MPI_Offset to the count argument of MPI_Send. MPI_Size will not need to be tied in any way to the size of MPI_Count. If on a system, MPI_Count is smaller than MPI_Size, it only means that we can pass in very large buffers to MPI_Pack, but not very large counts. If MPI_Count is larger than MPI _Size, it means that we may not be able to pack as large a message as we can send directly with communication routines. Agreed on a schedule for the next 2 weeks in which Fab will update the ticket based on today's discussion and the other attendees are encouraged to start dividing up the chapters to search for example code which should be changed to reflect the changes being proposed. The plan is to polish off ticket #224 and have an implementation for the October, 2010 meeting.

1 0

Re: [Mpi3-bwcompat] MPI_Count mixing with int...
by unknown＠example.com 15 Jul '10

15 Jul '10

Quincey Koziol wrote on Thu, 15 Jul 2010 at 00:50:14 > Hi Fab, > Sorry for the delay in replying... > > On Jul 9, 2010, at 2:22 PM, Fab Tillier wrote: > >> Quincey Koziol wrote on Fri, 9 Jul 2010 at 12:05:52 >> >>> I still think aliasing MPI_Size and MPI_Count will cause problems >>> down the line, since the two concepts are different. I'd be much >>> happier with separating them now rather than having to change things >>> that are switched from int to MPI_Size now to MPI_Count later. >> >> Having MPI_Size and MPI_Count different types causes > MPI_Pack/MPI_Send and MPI_Recv/MPI_Unpack to have problems, since the > count and sizes are passed between the two functions and should be > interchangeable, though. > > Well, there probably is something wrong with the definition of > MPI_Pack and MPI_Unpack then. OK, I've gone off and re-read the > definition of MPI_Pack in the standard and it looks OK to me. What is > the problem with using MPI_Count for the 'incount' parameter and > MPI_Size for the 'outsize' parameter? When you go to MPI_Send a packed buffer, you would pass the 'outsize' as the count parameter, and MPI_PACKED as the datatype. If MPI_Size has a larger range than MPI_Count, you could run into problems. The converse is true of MPI_Recv and MPI_Unpack - if the MPI_Count type is larger than the MPI_Size type, you may not be able to unpack (you could receive more than what you can express in the call to MPI_Unpack.) > (I think I would suggest > changing 'inposition' from a 'int *' to a 'void *' while we're mucking > about in here, also) The inposition is an offset from buf, it's an inout parameter thus being passed by reference so that MPI_Pack can update the position. -Fab

1 0

Re: [Mpi3-bwcompat] MPI_Count mixing with int...
by unknown＠example.com 15 Jul '10

15 Jul '10

Hi Fab, Sorry for the delay in replying... On Jul 9, 2010, at 2:22 PM, Fab Tillier wrote: > Quincey Koziol wrote on Fri, 9 Jul 2010 at 12:05:52 > >> I still think aliasing MPI_Size and MPI_Count will cause problems >> down the line, since the two concepts are different. I'd be much >> happier with separating them now rather than having to change things >> that are switched from int to MPI_Size now to MPI_Count later. > > Having MPI_Size and MPI_Count different types causes MPI_Pack/MPI_Send and MPI_Recv/MPI_Unpack to have problems, since the count and sizes are passed between the two functions and should be interchangeable, though. Well, there probably is something wrong with the definition of MPI_Pack and MPI_Unpack then. OK, I've gone off and re-read the definition of MPI_Pack in the standard and it looks OK to me. What is the problem with using MPI_Count for the 'incount' parameter and MPI_Size for the 'outsize' parameter? (I think I would suggest changing 'inposition' from a 'int *' to a 'void *' while we're mucking about in here, also) Quincey > Do we not care, and assume the compiler will flag assignments that might result in truncation? > > -Fab > > _______________________________________________ > Mpi3-bwcompat mailing list > Mpi3-bwcompat_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-bwcompat

1 0

Re: [Mpi3-bwcompat] Meeting schedule
by unknown＠example.com 15 Jul '10

15 Jul '10

On Jul 14, 2010, at 3:33 PM, Solt, David George wrote: > Thanks for the overwhelming input :). Anyone have a problem moving it to 10PST/1EST every other Friday? Current time is hard for our West Coast participant(s). Works for me. (Although y'all might have to listen to me eat ;-) Quincey > Dave > > -----Original Message----- > From: mpi3-bwcompat-bounces_at_[hidden] [mailto:mpi3-bwcompat-bounces_at_[hidden]] On Behalf Of Solt, David George > Sent: Thursday, July 08, 2010 3:41 PM > To: MPI-3 backwards compatability WG > Subject: [Mpi3-bwcompat] Meeting schedule > > Our reoccurring backwards compatibility meeting expired. It was set for every other Friday at 10am EST. I can just fire it up again, but want to check in and see if we want to keep that time. If you would attend if the meeting was at a different time or if you attend regularly but would prefer a different time, please shoot me an e-mail. If I don't hear from many people I will fire it up again starting next week. > > Dave > > _______________________________________________ > Mpi3-bwcompat mailing list > Mpi3-bwcompat_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-bwcompat > > _______________________________________________ > Mpi3-bwcompat mailing list > Mpi3-bwcompat_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-bwcompat

1 0

Re: [Mpi3-bwcompat] Meeting schedule
by unknown＠example.com 14 Jul '10

14 Jul '10

Works for me, thanks for accommodating me. -Fab Solt, David George wrote on Wed, 14 Jul 2010 at 13:33:03 > Thanks for the overwhelming input :). Anyone have a problem moving it > to 10PST/1EST every other Friday? Current time is hard for our West > Coast participant(s). > Dave > > -----Original Message----- > From: mpi3-bwcompat-bounces_at_[hidden] [mailto:mpi3-bwcompat- > bounces_at_[hidden]] On Behalf Of Solt, David George > Sent: Thursday, July 08, 2010 3:41 PM > To: MPI-3 backwards compatability WG > Subject: [Mpi3-bwcompat] Meeting schedule > > Our reoccurring backwards compatibility meeting expired. It was set for > every other Friday at 10am EST. I can just fire it up again, but want > to check in and see if we want to keep that time. If you would attend > if the meeting was at a different time or if you attend regularly but > would prefer a different time, please shoot me an e-mail. If I don't > hear from many people I will fire it up again starting next week. > > Dave > > _______________________________________________ Mpi3-bwcompat mailing > list Mpi3-bwcompat_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-bwcompat > > _______________________________________________ > Mpi3-bwcompat mailing list > Mpi3-bwcompat_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-bwcompat

1 0

Re: [Mpi3-bwcompat] Meeting schedule
by unknown＠example.com 14 Jul '10

14 Jul '10

Works for me. On Jul 14, 2010, at 4:33 PM, Solt, David George wrote: > Thanks for the overwhelming input :). Anyone have a problem moving it to 10PST/1EST every other Friday? Current time is hard for our West Coast participant(s). > Dave > > -----Original Message----- > From: mpi3-bwcompat-bounces_at_[hidden] [mailto:mpi3-bwcompat-bounces_at_[hidden]] On Behalf Of Solt, David George > Sent: Thursday, July 08, 2010 3:41 PM > To: MPI-3 backwards compatability WG > Subject: [Mpi3-bwcompat] Meeting schedule > > Our reoccurring backwards compatibility meeting expired. It was set for every other Friday at 10am EST. I can just fire it up again, but want to check in and see if we want to keep that time. If you would attend if the meeting was at a different time or if you attend regularly but would prefer a different time, please shoot me an e-mail. If I don't hear from many people I will fire it up again starting next week. > > Dave > > _______________________________________________ > Mpi3-bwcompat mailing list > Mpi3-bwcompat_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-bwcompat > > _______________________________________________ > Mpi3-bwcompat mailing list > Mpi3-bwcompat_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-bwcompat > -- Jeff Squyres jsquyres_at_[hidden] For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/

1 0

Re: [Mpi3-bwcompat] Meeting schedule
by unknown＠example.com 14 Jul '10

14 Jul '10

Thanks for the overwhelming input :). Anyone have a problem moving it to 10PST/1EST every other Friday? Current time is hard for our West Coast participant(s). Dave -----Original Message----- From: mpi3-bwcompat-bounces_at_[hidden] [mailto:mpi3-bwcompat-bounces_at_[hidden]] On Behalf Of Solt, David George Sent: Thursday, July 08, 2010 3:41 PM To: MPI-3 backwards compatability WG Subject: [Mpi3-bwcompat] Meeting schedule Our reoccurring backwards compatibility meeting expired. It was set for every other Friday at 10am EST. I can just fire it up again, but want to check in and see if we want to keep that time. If you would attend if the meeting was at a different time or if you attend regularly but would prefer a different time, please shoot me an e-mail. If I don't hear from many people I will fire it up again starting next week. Dave _______________________________________________ Mpi3-bwcompat mailing list Mpi3-bwcompat_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-bwcompat

1 0

Re: [Mpi3-bwcompat] Meeting schedule
by unknown＠example.com 14 Jul '10

14 Jul '10

Did you pick a new time based on Fab's input? I can setup webex's, if it's useful. On Jul 8, 2010, at 4:41 PM, Solt, David George wrote: > Our reoccurring backwards compatibility meeting expired. It was set for every other Friday at 10am EST. I can just fire it up again, but want to check in and see if we want to keep that time. If you would attend if the meeting was at a different time or if you attend regularly but would prefer a different time, please shoot me an e-mail. If I don't hear from many people I will fire it up again starting next week. > > Dave > > _______________________________________________ > Mpi3-bwcompat mailing list > Mpi3-bwcompat_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-bwcompat > -- Jeff Squyres jsquyres_at_[hidden] For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/

1 0

Re: [Mpi3-bwcompat] MPI_Count mixing with int...
by unknown＠example.com 09 Jul '10

09 Jul '10

Quincey Koziol wrote on Fri, 9 Jul 2010 at 12:05:52 > I still think aliasing MPI_Size and MPI_Count will cause problems > down the line, since the two concepts are different. I'd be much > happier with separating them now rather than having to change things > that are switched from int to MPI_Size now to MPI_Count later. Having MPI_Size and MPI_Count different types causes MPI_Pack/MPI_Send and MPI_Recv/MPI_Unpack to have problems, since the count and sizes are passed between the two functions and should be interchangeable, though. Do we not care, and assume the compiler will flag assignments that might result in truncation? -Fab

1 0