From jsquyres at [hidden] Fri Jan 7 11:45:29 2011 From: jsquyres at [hidden] (Jeff Squyres) Date: Fri, 7 Jan 2011 12:45:29 -0500 Subject: [Mpi3-bwcompat] meeting today? Message-ID: <638C0D1D-EF47-439D-8C04-27E89461A083@cisco.com> My calendar just beeped at me that we're having a bwcompat meeting in 15 mins (1pm US Eastern). Are we having it today? -- Jeff Squyres jsquyres_at_[hidden] For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/ From david.solt at [hidden] Fri Jan 7 12:00:58 2011 From: david.solt at [hidden] (Solt, David George) Date: Fri, 7 Jan 2011 18:00:58 +0000 Subject: [Mpi3-bwcompat] meeting today? In-Reply-To: <638C0D1D-EF47-439D-8C04-27E89461A083@cisco.com> Message-ID: I'm running late, but will dialin shortly. Dave -----Original Message----- From: mpi3-bwcompat-bounces_at_[hidden] [mailto:mpi3-bwcompat-bounces_at_[hidden]] On Behalf Of Jeff Squyres Sent: Friday, January 07, 2011 11:45 AM To: MPI-3 backwards compatability WG Subject: [Mpi3-bwcompat] meeting today? My calendar just beeped at me that we're having a bwcompat meeting in 15 mins (1pm US Eastern). Are we having it today? -- Jeff Squyres jsquyres_at_[hidden] For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/ _______________________________________________ Mpi3-bwcompat mailing list Mpi3-bwcompat_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-bwcompat From david.solt at [hidden] Fri Jan 7 12:00:58 2011 From: david.solt at [hidden] (Solt, David George) Date: Fri, 7 Jan 2011 18:00:58 +0000 Subject: [Mpi3-bwcompat] meeting today? In-Reply-To: <638C0D1D-EF47-439D-8C04-27E89461A083@cisco.com> Message-ID: <1294423314.0000@hypermail.dummy> I'm running late, but will dialin shortly. Dave -----Original Message----- From: mpi3-bwcompat-bounces_at_[hidden] [mailto:mpi3-bwcompat-bounces_at_[hidden]] On Behalf Of Jeff Squyres Sent: Friday, January 07, 2011 11:45 AM To: MPI-3 backwards compatability WG Subject: [Mpi3-bwcompat] meeting today? My calendar just beeped at me that we're having a bwcompat meeting in 15 mins (1pm US Eastern). Are we having it today? -- Jeff Squyres jsquyres_at_[hidden] For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/ _______________________________________________ Mpi3-bwcompat mailing list Mpi3-bwcompat_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-bwcompat From jsquyres at [hidden] Fri Jan 7 12:07:22 2011 From: jsquyres at [hidden] (Jeff Squyres) Date: Fri, 7 Jan 2011 13:07:22 -0500 Subject: [Mpi3-bwcompat] meeting today? In-Reply-To: Message-ID: Is this still relevant? 866.409.2889 - Conference Code: 3582114059 On Jan 7, 2011, at 1:00 PM, Solt, David George wrote: > I'm running late, but will dialin shortly. > Dave > > -----Original Message----- > From: mpi3-bwcompat-bounces_at_[hidden] [mailto:mpi3-bwcompat-bounces_at_[hidden]] On Behalf Of Jeff Squyres > Sent: Friday, January 07, 2011 11:45 AM > To: MPI-3 backwards compatability WG > Subject: [Mpi3-bwcompat] meeting today? > > My calendar just beeped at me that we're having a bwcompat meeting in 15 mins (1pm US Eastern). > > Are we having it today? > > -- > Jeff Squyres > jsquyres_at_[hidden] > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/ > > > _______________________________________________ > 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/ From jsquyres at [hidden] Fri Jan 21 11:45:35 2011 From: jsquyres at [hidden] (Jeff Squyres jsquyres) Date: Fri, 21 Jan 2011 12:45:35 -0500 Subject: [Mpi3-bwcompat] Mtg today? Message-ID: Sent from my PDA. No type good. From ftillier at [hidden] Fri Jan 21 12:02:53 2011 From: ftillier at [hidden] (Fab Tillier) Date: Fri, 21 Jan 2011 18:02:53 +0000 Subject: [Mpi3-bwcompat] Mtg today? In-Reply-To: Message-ID: <91B583BE4B6FCD408F53D1B8F537E0921D6C70FD@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> I am expecting so, though am woefully unprepared... How fast two weeks go by. -----Original Message----- From: mpi3-bwcompat-bounces_at_[hidden] [mailto:mpi3-bwcompat-bounces_at_[hidden]] On Behalf Of Jeff Squyres (jsquyres) Sent: Friday, January 21, 2011 9:46 AM To: MPI-3 Backwards Compat WG Subject: [Mpi3-bwcompat] Mtg today? Sent from my PDA. No type good. _______________________________________________ Mpi3-bwcompat mailing list Mpi3-bwcompat_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-bwcompat From koziol at [hidden] Fri Jan 21 12:37:23 2011 From: koziol at [hidden] (Quincey Koziol) Date: Fri, 21 Jan 2011 12:37:23 -0600 Subject: [Mpi3-bwcompat] Mtg today? In-Reply-To: <91B583BE4B6FCD408F53D1B8F537E0921D6C70FD@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> Message-ID: <4E978362-3BFC-44AC-8F4A-619365C603E6@hdfgroup.org> On Jan 21, 2011, at 12:02 PM, Fab Tillier wrote: > I am expecting so, though am woefully unprepared... How fast two weeks go by. I was hoping to call in, but a previous meeting overran its schedule by ~30 minutes. :-/ Fab - you asked me to work on something at the last forum meeting, but I've forgotten what that was now. Can you refresh my memory, so I can get it done? Thanks, Quincey > > -----Original Message----- > From: mpi3-bwcompat-bounces_at_[hidden] [mailto:mpi3-bwcompat-bounces_at_[hidden]] On Behalf Of Jeff Squyres (jsquyres) > Sent: Friday, January 21, 2011 9:46 AM > To: MPI-3 Backwards Compat WG > Subject: [Mpi3-bwcompat] Mtg today? > > > > Sent from my PDA. No type good. > _______________________________________________ > 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 From ftillier at [hidden] Fri Jan 21 13:08:47 2011 From: ftillier at [hidden] (Fab Tillier) Date: Fri, 21 Jan 2011 19:08:47 +0000 Subject: [Mpi3-bwcompat] Mtg today? In-Reply-To: <4E978362-3BFC-44AC-8F4A-619365C603E6@hdfgroup.org> Message-ID: <91B583BE4B6FCD408F53D1B8F537E0921D6C84B9@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> Quincey Koziol wrote on Fri, 21 Jan 2011 at 10:37:23 > On Jan 21, 2011, at 12:02 PM, Fab Tillier wrote: > >> I am expecting so, though am woefully unprepared... How fast two >> weeks go by. > > I was hoping to call in, but a previous meeting overran its > schedule by ~30 minutes. :-/ > > Fab - you asked me to work on something at the last forum > meeting, but I've forgotten what that was now. Can you refresh my > memory, so I can get it done? You were going to create a new ticket to extend the datatype creation functions to take MPI_Count as input, so that creating large datatypes is easier for your code. I would recommend showing your use case, to help explain why creating a bunch of smaller datatypes is nasty. -Fab > > Thanks, > Quincey > > >> >> -----Original Message----- >> From: mpi3-bwcompat-bounces_at_[hidden] [mailto:mpi3- > bwcompat-bounces_at_[hidden]] On Behalf Of Jeff Squyres > (jsquyres) >> Sent: Friday, January 21, 2011 9:46 AM >> To: MPI-3 Backwards Compat WG >> Subject: [Mpi3-bwcompat] Mtg today? >> >> >> >> Sent from my PDA. No type good. >> _______________________________________________ >> 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 > > > _______________________________________________ > Mpi3-bwcompat mailing list > Mpi3-bwcompat_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-bwcompat From ftillier at [hidden] Fri Jan 21 13:10:25 2011 From: ftillier at [hidden] (Fab Tillier) Date: Fri, 21 Jan 2011 19:10:25 +0000 Subject: [Mpi3-bwcompat] Hot off the press, ticket 265 Message-ID: <91B583BE4B6FCD408F53D1B8F537E0921D6C84CB@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> Hey folks, I've started on the (hopefully) last ticket to add support for large counts. It's not finished, but thought I'd send this out to show folks what I'm doing and get comments early if I'm doing something horrendous. https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/265 -Fab From ftillier at [hidden] Wed Jan 26 15:38:32 2011 From: ftillier at [hidden] (Fab Tillier) Date: Wed, 26 Jan 2011 21:38:32 +0000 Subject: [Mpi3-bwcompat] Ticket 265 ready for review Message-ID: <91B583BE4B6FCD408F53D1B8F537E0921D6D4C76@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> Ok folks, not a whole lot of time before the meeting, so it would be great if we could get everyone to read through the ticket and make sure I didn't miss something. I'd like to have David Solt generate a PDF sometime next week, in time for me to read it at the forum the following week (our time slot for this is 'working lunch' on Tuesday. https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/265 Thanks for your help, -Fab From thakur at [hidden] Wed Jan 26 16:31:06 2011 From: thakur at [hidden] (Rajeev Thakur) Date: Wed, 26 Jan 2011 16:31:06 -0600 Subject: [Mpi3-bwcompat] Ticket 265 ready for review In-Reply-To: <91B583BE4B6FCD408F53D1B8F537E0921D6D4C76@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> Message-ID: <1856B081-7B87-4805-AD80-88476BB990CB@mcs.anl.gov> I wasn't at the last Forum meeting, so may have missed some of the background. Is ticket #224 obsolete now? If so, you may want to indicate that in 224. Do MPI_Send/Recv etc. remain unchanged, i.e., no MPI_Count in them? If so, why do we need a new MPI_Get_count? Are the new "w" versions of the collectives specifically related to this ticket (i.e. to address the 64-bit count requirement) or are they a separate issue (i.e. a general need for array of datatypes instead of one datatype)? Minor typos: Two of the prototypes for Scatterw say Scatterv instead. Rajeev On Jan 26, 2011, at 3:38 PM, Fab Tillier wrote: > Ok folks, not a whole lot of time before the meeting, so it would be great if we could get everyone to read through the ticket and make sure I didn't miss something. I'd like to have David Solt generate a PDF sometime next week, in time for me to read it at the forum the following week (our time slot for this is 'working lunch' on Tuesday. > > https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/265 > > Thanks for your help, > -Fab > > _______________________________________________ > Mpi3-bwcompat mailing list > Mpi3-bwcompat_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-bwcompat From gpaulsen at [hidden] Wed Jan 26 16:32:55 2011 From: gpaulsen at [hidden] (Geoffrey Paulsen) Date: Wed, 26 Jan 2011 17:32:55 -0500 Subject: [Mpi3-bwcompat] Ticket 265 ready for review In-Reply-To: <91B583BE4B6FCD408F53D1B8F537E0921D6D4C76@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> Message-ID: <0B503E76919828489362F1FA50483508E5568B@catoexm07.noam.corp.platform.com> I reviewed this document and I found two type-o's: 1) MPI_Scatterw - two of the function prototypes that was cut and paste from MPI_Scatterv didn't have the v changed to w. 2) MPI_Iallgatherw - page 192, line 48, needs to have an "MPI_I" prepended to "Allgatherw" at the very beginning of that section. -----Original Message----- From: mpi3-bwcompat-bounces_at_[hidden] [mailto:mpi3-bwcompat-bounces_at_[hidden]] On Behalf Of Fab Tillier Sent: Wednesday, January 26, 2011 3:39 PM To: MPI-3 backwards compatability WG Subject: [Mpi3-bwcompat] Ticket 265 ready for review Ok folks, not a whole lot of time before the meeting, so it would be great if we could get everyone to read through the ticket and make sure I didn't miss something. I'd like to have David Solt generate a PDF sometime next week, in time for me to read it at the forum the following week (our time slot for this is 'working lunch' on Tuesday. https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/265 Thanks for your help, -Fab _______________________________________________ Mpi3-bwcompat mailing list Mpi3-bwcompat_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-bwcompat From ftillier at [hidden] Wed Jan 26 16:56:02 2011 From: ftillier at [hidden] (Fab Tillier) Date: Wed, 26 Jan 2011 22:56:02 +0000 Subject: [Mpi3-bwcompat] Ticket 265 ready for review In-Reply-To: <1856B081-7B87-4805-AD80-88476BB990CB@mcs.anl.gov> Message-ID: <91B583BE4B6FCD408F53D1B8F537E0921D6D5F65@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> Hi Rajeev, Rajeev Thakur wrote on Wed, 26 Jan 2011 at 14:31:06 > I wasn't at the last Forum meeting, so may have missed some of the > background. > > Is ticket #224 obsolete now? If so, you may want to indicate that in 224. Sorry, I've resolved it as withdrawn, with a comment that it was supersceded by 265. > Do MPI_Send/Recv etc. remain unchanged, i.e., no MPI_Count in them? If > so, why do we need a new MPI_Get_count? MPI_Send/Recv remain unchanged, and users are expected to create derived datatypes to express data structures that are larger than 2^31 basic elements. Now that you point it out, though, I would think MPI_Get_elements is sufficient, as MPI_Get_count should be using the same datatype as used in the operation that transferred the data. Hoping that Jeff, Quincy, or David can chime in here and clarify why we need it. > Are the new "w" versions of the collectives specifically related to > this ticket (i.e. to address the 64-bit count requirement) or are they > a separate issue (i.e. a general need for array of datatypes instead of > one datatype)? By addressing the need for large counts via derived datatypes, we effectively encapsulate the 'count' in the 'datatype' parameters. As an example, if you want to gather different 'counts' from different ranks where there is no common denominator, you would need to derive a datatype for each source rank, and specify those individual datatypes. That can't be done today, we can only specify different counts, but are limited by the 2^31 range of the count fields. So the missing 'w' functions allow the datatype to be used to encapsulate the count. > Minor typos: Two of the prototypes for Scatterw say Scatterv instead. Fixed, thanks. -Fab > > Rajeev > > > > > On Jan 26, 2011, at 3:38 PM, Fab Tillier wrote: > >> Ok folks, not a whole lot of time before the meeting, so it would be > great if we could get everyone to read through the ticket and make sure > I didn't miss something. I'd like to have David Solt generate a PDF > sometime next week, in time for me to read it at the forum the > following week (our time slot for this is 'working lunch' on Tuesday. >> >> https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/265 >> >> Thanks for your help, >> -Fab >> >> _______________________________________________ >> 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 From ftillier at [hidden] Wed Jan 26 16:59:50 2011 From: ftillier at [hidden] (Fab Tillier) Date: Wed, 26 Jan 2011 22:59:50 +0000 Subject: [Mpi3-bwcompat] Ticket 265 ready for review In-Reply-To: <0B503E76919828489362F1FA50483508E5568B@catoexm07.noam.corp.platform.com> Message-ID: <91B583BE4B6FCD408F53D1B8F537E0921D6D5F90@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> Geoffrey Paulsen wrote on Wed, 26 Jan 2011 at 14:32:55 > I reviewed this document and I found two type-o's: > > 1) MPI_Scatterw - two of the function prototypes that was cut and paste > from MPI_Scatterv didn't have the v changed to w. > > 2) MPI_Iallgatherw - page 192, line 48, needs to have an "MPI_I" > prepended to "Allgatherw" at the very beginning of that section. Fixed, thanks! -Fab > -----Original Message----- > From: Fab Tillier > Sent: Wednesday, January 26, 2011 3:39 PM > > Ok folks, not a whole lot of time before the meeting, so it would be > great if we could get everyone to read through the ticket and make sure > I didn't miss something. I'd like to have David Solt generate a PDF > sometime next week, in time for me to read it at the forum the following > week (our time slot for this is 'working lunch' on Tuesday. > > https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/265 > > Thanks for your help, > -Fab From thakur at [hidden] Wed Jan 26 23:59:33 2011 From: thakur at [hidden] (Rajeev Thakur) Date: Wed, 26 Jan 2011 23:59:33 -0600 Subject: [Mpi3-bwcompat] Ticket 265 ready for review In-Reply-To: <91B583BE4B6FCD408F53D1B8F537E0921D6D5F65@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> Message-ID: OK, thanks for the explanation. If count is encapsulated in derived datatypes, we might need new datatype constructor functions that take MPI_Count, or at least a new MPI_Type_contiguous. Let's say the user wants to send an array of size X integers, where X is some weird number greater than 2G. If there is a new Type_contiguous, we have to see how it affects Type_get_envelope and Type_get_contents. Rajeev On Jan 26, 2011, at 4:56 PM, Fab Tillier wrote: > Hi Rajeev, > > Rajeev Thakur wrote on Wed, 26 Jan 2011 at 14:31:06 > >> I wasn't at the last Forum meeting, so may have missed some of the >> background. >> >> Is ticket #224 obsolete now? If so, you may want to indicate that in 224. > > Sorry, I've resolved it as withdrawn, with a comment that it was supersceded by 265. > >> Do MPI_Send/Recv etc. remain unchanged, i.e., no MPI_Count in them? If >> so, why do we need a new MPI_Get_count? > > MPI_Send/Recv remain unchanged, and users are expected to create derived datatypes to express data structures that are larger than 2^31 basic elements. Now that you point it out, though, I would think MPI_Get_elements is sufficient, as MPI_Get_count should be using the same datatype as used in the operation that transferred the data. Hoping that Jeff, Quincy, or David can chime in here and clarify why we need it. > >> Are the new "w" versions of the collectives specifically related to >> this ticket (i.e. to address the 64-bit count requirement) or are they >> a separate issue (i.e. a general need for array of datatypes instead of >> one datatype)? > > By addressing the need for large counts via derived datatypes, we effectively encapsulate the 'count' in the 'datatype' parameters. As an example, if you want to gather different 'counts' from different ranks where there is no common denominator, you would need to derive a datatype for each source rank, and specify those individual datatypes. That can't be done today, we can only specify different counts, but are limited by the 2^31 range of the count fields. So the missing 'w' functions allow the datatype to be used to encapsulate the count. > >> Minor typos: Two of the prototypes for Scatterw say Scatterv instead. > > Fixed, thanks. > > -Fab > >> >> Rajeev >> >> >> >> >> On Jan 26, 2011, at 3:38 PM, Fab Tillier wrote: >> >>> Ok folks, not a whole lot of time before the meeting, so it would be >> great if we could get everyone to read through the ticket and make sure >> I didn't miss something. I'd like to have David Solt generate a PDF >> sometime next week, in time for me to read it at the forum the >> following week (our time slot for this is 'working lunch' on Tuesday. >>> >>> https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/265 >>> >>> Thanks for your help, >>> -Fab >>> >>> _______________________________________________ >>> 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 > > _______________________________________________ > Mpi3-bwcompat mailing list > Mpi3-bwcompat_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-bwcompat From ftillier at [hidden] Thu Jan 27 11:33:29 2011 From: ftillier at [hidden] (Fab Tillier) Date: Thu, 27 Jan 2011 17:33:29 +0000 Subject: [Mpi3-bwcompat] Ticket 265 ready for review In-Reply-To: Message-ID: <91B583BE4B6FCD408F53D1B8F537E0921D6D61A9@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> Hi Rajeev, Rajeev Thakur wrote on Wed, 26 Jan 2011 at 21:59:33 > OK, thanks for the explanation. > > If count is encapsulated in derived datatypes, we might need new > datatype constructor functions that take MPI_Count, or at least a new > MPI_Type_contiguous. Let's say the user wants to send an array of size > X integers, where X is some weird number greater than 2G. If there is a > new Type_contiguous, we have to see how it affects Type_get_envelope > and Type_get_contents. We shouldn't need new datatype creator functions for this to work - a user can nest types, for example by creating a struct type of contiguous types to achieve the length desired. In this case, the MPI_Type_get_envelope/contents would still work as currently defined. Does that make sense? Do we want to capture this discussion as comments on the ticket? Thanks for the feedback! -Fab > Rajeev > > > On Jan 26, 2011, at 4:56 PM, Fab Tillier wrote: > >> Hi Rajeev, >> >> Rajeev Thakur wrote on Wed, 26 Jan 2011 at 14:31:06 >> >>> I wasn't at the last Forum meeting, so may have missed some of the >>> background. >>> >>> Is ticket #224 obsolete now? If so, you may want to indicate that in > 224. >> >> Sorry, I've resolved it as withdrawn, with a comment that it was >> supersceded by 265. >> >>> Do MPI_Send/Recv etc. remain unchanged, i.e., no MPI_Count in them? If >>> so, why do we need a new MPI_Get_count? >> >> MPI_Send/Recv remain unchanged, and users are expected to create > derived datatypes to express data structures that are larger than 2^31 > basic elements. Now that you point it out, though, I would think > MPI_Get_elements is sufficient, as MPI_Get_count should be using the > same datatype as used in the operation that transferred the data. > Hoping that Jeff, Quincy, or David can chime in here and clarify why we > need it. >> >>> Are the new "w" versions of the collectives specifically related to >>> this ticket (i.e. to address the 64-bit count requirement) or are they >>> a separate issue (i.e. a general need for array of datatypes instead >>> of one datatype)? >> >> By addressing the need for large counts via derived datatypes, we > effectively encapsulate the 'count' in the 'datatype' parameters. As > an example, if you want to gather different 'counts' from different > ranks where there is no common denominator, you would need to derive a > datatype for each source rank, and specify those individual datatypes. > That can't be done today, we can only specify different counts, but are > limited by the 2^31 range of the count fields. So the missing 'w' > functions allow the datatype to be used to encapsulate the count. >> >>> Minor typos: Two of the prototypes for Scatterw say Scatterv > instead. >> >> Fixed, thanks. >> >> -Fab >> >>> >>> Rajeev >>> >>> >>> >>> >>> On Jan 26, 2011, at 3:38 PM, Fab Tillier wrote: >>> >>>> Ok folks, not a whole lot of time before the meeting, so it would > be >>> great if we could get everyone to read through the ticket and make >>> sure I didn't miss something. I'd like to have David Solt generate a >>> PDF sometime next week, in time for me to read it at the forum the >>> following week (our time slot for this is 'working lunch' on > Tuesday. >>>> >>>> https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/265 >>>> >>>> Thanks for your help, >>>> -Fab >>>> >>>> _______________________________________________ >>>> 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 >> >> _______________________________________________ >> 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 From thakur at [hidden] Fri Jan 28 10:09:29 2011 From: thakur at [hidden] (Rajeev Thakur) Date: Fri, 28 Jan 2011 10:09:29 -0600 Subject: [Mpi3-bwcompat] Ticket 265 ready for review In-Reply-To: <91B583BE4B6FCD408F53D1B8F537E0921D6D61A9@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> Message-ID: <82638737-A98B-43D4-9B29-9394C5E5B35E@mcs.anl.gov> Yes, it is not absolutely required, but becomes a convenience feature. Rajeev On Jan 27, 2011, at 11:33 AM, Fab Tillier wrote: > Hi Rajeev, > > Rajeev Thakur wrote on Wed, 26 Jan 2011 at 21:59:33 > >> OK, thanks for the explanation. >> >> If count is encapsulated in derived datatypes, we might need new >> datatype constructor functions that take MPI_Count, or at least a new >> MPI_Type_contiguous. Let's say the user wants to send an array of size >> X integers, where X is some weird number greater than 2G. If there is a >> new Type_contiguous, we have to see how it affects Type_get_envelope >> and Type_get_contents. > > We shouldn't need new datatype creator functions for this to work - a user can nest types, for example by creating a struct type of contiguous types to achieve the length desired. In this case, the MPI_Type_get_envelope/contents would still work as currently defined. > > Does that make sense? > > Do we want to capture this discussion as comments on the ticket? > > Thanks for the feedback! > -Fab > >> Rajeev >> >> >> On Jan 26, 2011, at 4:56 PM, Fab Tillier wrote: >> >>> Hi Rajeev, >>> >>> Rajeev Thakur wrote on Wed, 26 Jan 2011 at 14:31:06 >>> >>>> I wasn't at the last Forum meeting, so may have missed some of the >>>> background. >>>> >>>> Is ticket #224 obsolete now? If so, you may want to indicate that in >> 224. >>> >>> Sorry, I've resolved it as withdrawn, with a comment that it was >>> supersceded by 265. >>> >>>> Do MPI_Send/Recv etc. remain unchanged, i.e., no MPI_Count in them? If >>>> so, why do we need a new MPI_Get_count? >>> >>> MPI_Send/Recv remain unchanged, and users are expected to create >> derived datatypes to express data structures that are larger than 2^31 >> basic elements. Now that you point it out, though, I would think >> MPI_Get_elements is sufficient, as MPI_Get_count should be using the >> same datatype as used in the operation that transferred the data. >> Hoping that Jeff, Quincy, or David can chime in here and clarify why we >> need it. >>> >>>> Are the new "w" versions of the collectives specifically related to >>>> this ticket (i.e. to address the 64-bit count requirement) or are they >>>> a separate issue (i.e. a general need for array of datatypes instead >>>> of one datatype)? >>> >>> By addressing the need for large counts via derived datatypes, we >> effectively encapsulate the 'count' in the 'datatype' parameters. As >> an example, if you want to gather different 'counts' from different >> ranks where there is no common denominator, you would need to derive a >> datatype for each source rank, and specify those individual datatypes. >> That can't be done today, we can only specify different counts, but are >> limited by the 2^31 range of the count fields. So the missing 'w' >> functions allow the datatype to be used to encapsulate the count. >>> >>>> Minor typos: Two of the prototypes for Scatterw say Scatterv >> instead. >>> >>> Fixed, thanks. >>> >>> -Fab >>> >>>> >>>> Rajeev >>>> >>>> >>>> >>>> >>>> On Jan 26, 2011, at 3:38 PM, Fab Tillier wrote: >>>> >>>>> Ok folks, not a whole lot of time before the meeting, so it would >> be >>>> great if we could get everyone to read through the ticket and make >>>> sure I didn't miss something. I'd like to have David Solt generate a >>>> PDF sometime next week, in time for me to read it at the forum the >>>> following week (our time slot for this is 'working lunch' on >> Tuesday. >>>>> >>>>> https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/265 >>>>> >>>>> Thanks for your help, >>>>> -Fab >>>>> >>>>> _______________________________________________ >>>>> 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 >>> >>> _______________________________________________ >>> 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 > > _______________________________________________ > Mpi3-bwcompat mailing list > Mpi3-bwcompat_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-bwcompat From ftillier at [hidden] Fri Jan 28 11:07:00 2011 From: ftillier at [hidden] (Fab Tillier) Date: Fri, 28 Jan 2011 17:07:00 +0000 Subject: [Mpi3-bwcompat] Ticket 265 ready for review In-Reply-To: <82638737-A98B-43D4-9B29-9394C5E5B35E@mcs.anl.gov> Message-ID: <91B583BE4B6FCD408F53D1B8F537E0921D6D74D1@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> Rajeev Thakur wrote on Fri, 28 Jan 2011 at 08:09:29 > Yes, it is not absolutely required, but becomes a convenience feature. I believe Quincy will be bringing forth a proposal to address this, but we wanted to get the minimum functionality to provide full support for large datatypes captured in a single ticket without adding convenience features. -Fab > > Rajeev > > On Jan 27, 2011, at 11:33 AM, Fab Tillier wrote: > >> Hi Rajeev, >> >> Rajeev Thakur wrote on Wed, 26 Jan 2011 at 21:59:33 >> >>> OK, thanks for the explanation. >>> >>> If count is encapsulated in derived datatypes, we might need new >>> datatype constructor functions that take MPI_Count, or at least a new >>> MPI_Type_contiguous. Let's say the user wants to send an array of size >>> X integers, where X is some weird number greater than 2G. If there is a >>> new Type_contiguous, we have to see how it affects Type_get_envelope >>> and Type_get_contents. >> >> We shouldn't need new datatype creator functions for this to work - a user > can nest types, for example by creating a struct type of contiguous types to > achieve the length desired. In this case, the > MPI_Type_get_envelope/contents would still work as currently defined. >> >> Does that make sense? >> >> Do we want to capture this discussion as comments on the ticket? >> >> Thanks for the feedback! >> -Fab >> >>> Rajeev >>> >>> >>> On Jan 26, 2011, at 4:56 PM, Fab Tillier wrote: >>> >>>> Hi Rajeev, >>>> >>>> Rajeev Thakur wrote on Wed, 26 Jan 2011 at 14:31:06 >>>> >>>>> I wasn't at the last Forum meeting, so may have missed some of the >>>>> background. >>>>> >>>>> Is ticket #224 obsolete now? If so, you may want to indicate that in >>> 224. >>>> >>>> Sorry, I've resolved it as withdrawn, with a comment that it was >>>> supersceded by 265. >>>> >>>>> Do MPI_Send/Recv etc. remain unchanged, i.e., no MPI_Count in them? >>>>> If so, why do we need a new MPI_Get_count? >>>> >>>> MPI_Send/Recv remain unchanged, and users are expected to create >>> derived datatypes to express data structures that are larger than 2^31 >>> basic elements. Now that you point it out, though, I would think >>> MPI_Get_elements is sufficient, as MPI_Get_count should be using the >>> same datatype as used in the operation that transferred the data. >>> Hoping that Jeff, Quincy, or David can chime in here and clarify why we >>> need it. >>>> >>>>> Are the new "w" versions of the collectives specifically related to >>>>> this ticket (i.e. to address the 64-bit count requirement) or are they >>>>> a separate issue (i.e. a general need for array of datatypes instead >>>>> of one datatype)? >>>> >>>> By addressing the need for large counts via derived datatypes, we >>> effectively encapsulate the 'count' in the 'datatype' parameters. As >>> an example, if you want to gather different 'counts' from different >>> ranks where there is no common denominator, you would need to derive a >>> datatype for each source rank, and specify those individual datatypes. >>> That can't be done today, we can only specify different counts, but >>> are limited by the 2^31 range of the count fields. So the missing 'w' >>> functions allow the datatype to be used to encapsulate the count. >>>> >>>>> Minor typos: Two of the prototypes for Scatterw say Scatterv >>> instead. >>>> >>>> Fixed, thanks. >>>> >>>> -Fab >>>> >>>>> >>>>> Rajeev >>>>> >>>>> >>>>> >>>>> >>>>> On Jan 26, 2011, at 3:38 PM, Fab Tillier wrote: >>>>> >>>>>> Ok folks, not a whole lot of time before the meeting, so it would >>> be >>>>> great if we could get everyone to read through the ticket and make >>>>> sure I didn't miss something. I'd like to have David Solt generate a >>>>> PDF sometime next week, in time for me to read it at the forum the >>>>> following week (our time slot for this is 'working lunch' on >>> Tuesday. >>>>>> >>>>>> https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/265 >>>>>> >>>>>> Thanks for your help, >>>>>> -Fab >>>>>> >>>>>> _______________________________________________ >>>>>> 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 >>>> >>>> _______________________________________________ >>>> 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 >> >> _______________________________________________ >> 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 From jsquyres at [hidden] Fri Jan 28 15:33:03 2011 From: jsquyres at [hidden] (Jeff Squyres) Date: Fri, 28 Jan 2011 16:33:03 -0500 Subject: [Mpi3-bwcompat] Ticket 265 ready for review In-Reply-To: <91B583BE4B6FCD408F53D1B8F537E0921D6D74D1@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> Message-ID: Rajeev -- The problem with your proposal is that it very, very quickly becomes a slippery slope of making a new MPI_() with an MPI_Count argument for every value of . The Forum has soundly rejected every form of that. This proposal is a (return to) just proposing absolute minimal functionality that is required for correctness. On Jan 28, 2011, at 12:07 PM, Fab Tillier wrote: > Rajeev Thakur wrote on Fri, 28 Jan 2011 at 08:09:29 > >> Yes, it is not absolutely required, but becomes a convenience feature. > > I believe Quincy will be bringing forth a proposal to address this, but we wanted to get the minimum functionality to provide full support for large datatypes captured in a single ticket without adding convenience features. > > -Fab > >> >> Rajeev >> >> On Jan 27, 2011, at 11:33 AM, Fab Tillier wrote: >> >>> Hi Rajeev, >>> >>> Rajeev Thakur wrote on Wed, 26 Jan 2011 at 21:59:33 >>> >>>> OK, thanks for the explanation. >>>> >>>> If count is encapsulated in derived datatypes, we might need new >>>> datatype constructor functions that take MPI_Count, or at least a new >>>> MPI_Type_contiguous. Let's say the user wants to send an array of size >>>> X integers, where X is some weird number greater than 2G. If there is a >>>> new Type_contiguous, we have to see how it affects Type_get_envelope >>>> and Type_get_contents. >>> >>> We shouldn't need new datatype creator functions for this to work - a user >> can nest types, for example by creating a struct type of contiguous types to >> achieve the length desired. In this case, the >> MPI_Type_get_envelope/contents would still work as currently defined. >>> >>> Does that make sense? >>> >>> Do we want to capture this discussion as comments on the ticket? >>> >>> Thanks for the feedback! >>> -Fab >>> >>>> Rajeev >>>> >>>> >>>> On Jan 26, 2011, at 4:56 PM, Fab Tillier wrote: >>>> >>>>> Hi Rajeev, >>>>> >>>>> Rajeev Thakur wrote on Wed, 26 Jan 2011 at 14:31:06 >>>>> >>>>>> I wasn't at the last Forum meeting, so may have missed some of the >>>>>> background. >>>>>> >>>>>> Is ticket #224 obsolete now? If so, you may want to indicate that in >>>> 224. >>>>> >>>>> Sorry, I've resolved it as withdrawn, with a comment that it was >>>>> supersceded by 265. >>>>> >>>>>> Do MPI_Send/Recv etc. remain unchanged, i.e., no MPI_Count in them? >>>>>> If so, why do we need a new MPI_Get_count? >>>>> >>>>> MPI_Send/Recv remain unchanged, and users are expected to create >>>> derived datatypes to express data structures that are larger than 2^31 >>>> basic elements. Now that you point it out, though, I would think >>>> MPI_Get_elements is sufficient, as MPI_Get_count should be using the >>>> same datatype as used in the operation that transferred the data. >>>> Hoping that Jeff, Quincy, or David can chime in here and clarify why we >>>> need it. >>>>> >>>>>> Are the new "w" versions of the collectives specifically related to >>>>>> this ticket (i.e. to address the 64-bit count requirement) or are they >>>>>> a separate issue (i.e. a general need for array of datatypes instead >>>>>> of one datatype)? >>>>> >>>>> By addressing the need for large counts via derived datatypes, we >>>> effectively encapsulate the 'count' in the 'datatype' parameters. As >>>> an example, if you want to gather different 'counts' from different >>>> ranks where there is no common denominator, you would need to derive a >>>> datatype for each source rank, and specify those individual datatypes. >>>> That can't be done today, we can only specify different counts, but >>>> are limited by the 2^31 range of the count fields. So the missing 'w' >>>> functions allow the datatype to be used to encapsulate the count. >>>>> >>>>>> Minor typos: Two of the prototypes for Scatterw say Scatterv >>>> instead. >>>>> >>>>> Fixed, thanks. >>>>> >>>>> -Fab >>>>> >>>>>> >>>>>> Rajeev >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Jan 26, 2011, at 3:38 PM, Fab Tillier wrote: >>>>>> >>>>>>> Ok folks, not a whole lot of time before the meeting, so it would >>>> be >>>>>> great if we could get everyone to read through the ticket and make >>>>>> sure I didn't miss something. I'd like to have David Solt generate a >>>>>> PDF sometime next week, in time for me to read it at the forum the >>>>>> following week (our time slot for this is 'working lunch' on >>>> Tuesday. >>>>>>> >>>>>>> https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/265 >>>>>>> >>>>>>> Thanks for your help, >>>>>>> -Fab >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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 >>>>> >>>>> _______________________________________________ >>>>> 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 >>> >>> _______________________________________________ >>> 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 > > _______________________________________________ > 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/