From ftillier at [hidden] Wed Mar 2 19:28:27 2011 From: ftillier at [hidden] (Fab Tillier) Date: Thu, 3 Mar 2011 01:28:27 +0000 Subject: [Mpi3-bwcompat] ticket 265 udpated Message-ID: <91B583BE4B6FCD408F53D1B8F537E0921D732906@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> Hi Folks, I've updated ticket 265 with the comments from the last meeting. Please take a look. We'll go over the PDF on Friday (right David?) and hopefully agree that it's ready to send out for wider review. TBD still (I think) is whether to split it into two tickets, one for the basic functionality, the other for the new 'w' collectives. https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/265 -Fab From jsquyres at [hidden] Thu Mar 3 10:36:28 2011 From: jsquyres at [hidden] (Jeff Squyres) Date: Thu, 3 Mar 2011 11:36:28 -0500 Subject: [Mpi3-bwcompat] ticket 265 udpated In-Reply-To: <91B583BE4B6FCD408F53D1B8F537E0921D732906@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> Message-ID: <147B7C51-20C2-4C08-B774-C3B07F135AB4@cisco.com> I have a terrible thought -- don't shoot me... What if we don't introduce MPI_Count, but instead introduce the same new functions with explicitly-sized parameters? E.g.: int MPI_Type_get_extent64(MPI_Datatype datatype, MPI_Count *lb, uint64_t *extent) int MPI_Get_elements64(MPI_Status *status, MPI_Datatype datatype, uint64_t *count) My rationale here is that we have a way to move forward with arbitrary sizes in the future, and MPI implementations don't have to make the (sometimes monumental) decision about changing the size of their MPI_Count datatype. Specifically: ABI issues are not trifling. Changing the size of MPI_Count might be a Big Deal to some implementations and (enterprise) customers. If the MPI spec needs 128-bit versions someday, we can just add MPI_Type_get_extent128 (etc.). But the 64 bit versions (and the int version) would certainly still be available with no ambiguity. The function name implies an explicitly clear size of the parameter, so developers shouldn't get confused at all. I believe there's also precent for "64" as a suffix in POSIX and other APIs...? On Mar 2, 2011, at 8:28 PM, Fab Tillier wrote: > Hi Folks, > > I've updated ticket 265 with the comments from the last meeting. Please take a look. We'll go over the PDF on Friday (right David?) and hopefully agree that it's ready to send out for wider review. > > TBD still (I think) is whether to split it into two tickets, one for the basic functionality, the other for the new 'w' collectives. > > https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/265 > > -Fab > > _______________________________________________ > 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 ftillier at [hidden] Thu Mar 3 14:30:34 2011 From: ftillier at [hidden] (Fab Tillier) Date: Thu, 3 Mar 2011 20:30:34 +0000 Subject: [Mpi3-bwcompat] ticket 265 udpated In-Reply-To: <147B7C51-20C2-4C08-B774-C3B07F135AB4@cisco.com> Message-ID: <91B583BE4B6FCD408F53D1B8F537E0921D733177@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> Jeff Squyres wrote on Thu, 3 Mar 2011 at 08:36:28 > I have a terrible thought -- don't shoot me... > > What if we don't introduce MPI_Count, but instead introduce the same new > functions with explicitly-sized parameters? E.g.: > > int MPI_Type_get_extent64(MPI_Datatype datatype, MPI_Count *lb, > uint64_t *extent) You forgot to fix 'lb'. Also, it needs to be a signed value so that sentinel values such as MPI_UNDEFINED can exist. So there. :P > int MPI_Get_elements64(MPI_Status *status, MPI_Datatype datatype, > uint64_t *count) > > My rationale here is that we have a way to move forward with arbitrary sizes > in the future, and MPI implementations don't have to make the (sometimes > monumental) decision about changing the size of their MPI_Count datatype. > Specifically: ABI issues are not trifling. Changing the size of MPI_Count might > be a Big Deal to some implementations and (enterprise) customers. Having explicit 64-bit support might be a Big Deal to some implementations that don't care about large counts. One of the goals of abstracting the count is that it allows those who don't care to define MPI_Count as int, and just have the X functions weak symbols for the non-X functions. > If the MPI spec needs 128-bit versions someday, we can just add > MPI_Type_get_extent128 (etc.). But the 64 bit versions (and the int version) > would certainly still be available with no ambiguity. > > The function name implies an explicitly clear size of the parameter, so > developers shouldn't get confused at all. I believe there's also precent for > "64" as a suffix in POSIX and other APIs...? There's also precedent for variable width parameters such as size_t (and long in Linux) that also break ABI when the type changes size, but that hasn't been a problem - if anything it has allowed programs to be more portable rather than less. Codes that use MPI_Count would have to recompile when the value of MPI_Count changes, but no source changes should be necessary. The whole issue of ABI is so much bigger than this (how do you handle string lengths, how do you handle pre-defined constants like MPI_COMM_WORLD, etc...) that MPI_Count changing size is really minor. A recompile when moving from 64-bit to 128-bit is really going to be the least of people's problems. That said, once MPI_Count is approved, I look forward to your proposal to change it from MPI_Count to int64. -Fab > On Mar 2, 2011, at 8:28 PM, Fab Tillier wrote: > >> Hi Folks, >> >> I've updated ticket 265 with the comments from the last meeting. Please > take a look. We'll go over the PDF on Friday (right David?) and hopefully > agree that it's ready to send out for wider review. >> >> TBD still (I think) is whether to split it into two tickets, one for >> the basic functionality, the other for the new 'w' collectives. >> >> https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/265 >> >> -Fab >> >> _______________________________________________ >> Mpi3-bwcompat mailing list >> Mpi3-bwcompat_at_[hidden] >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-bwcompat > > From jsquyres at [hidden] Thu Mar 3 14:54:06 2011 From: jsquyres at [hidden] (Jeff Squyres) Date: Thu, 3 Mar 2011 15:54:06 -0500 Subject: [Mpi3-bwcompat] ticket 265 udpated In-Reply-To: <91B583BE4B6FCD408F53D1B8F537E0921D733177@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> Message-ID: On Mar 3, 2011, at 3:30 PM, Fab Tillier wrote: > You forgot to fix 'lb'. Also, it needs to be a signed value so that sentinel values such as MPI_UNDEFINED can exist. So there. :P --enable-picky > Having explicit 64-bit support might be a Big Deal to some implementations that don't care about large counts. One of the goals of abstracting the count is that it allows those who don't care to define MPI_Count as int, and just have the X functions weak symbols for the non-X functions. Eh; I don't care about the weak symbol feature. I see your point about some MPI's not caring about 64 bit counts; they could just return MPI_UNDEFINED or somesuch...? > There's also precedent for variable width parameters such as size_t (and long in Linux) that also break ABI when the type changes size, but that hasn't been a problem - if anything it has allowed programs to be more portable rather than less. How so? > Codes that use MPI_Count would have to recompile when the value of MPI_Count changes, but no source changes should be necessary. The key word there being "should". > The whole issue of ABI is so much bigger than this (how do you handle string lengths, how do you handle pre-defined constants like MPI_COMM_WORLD, etc...) that MPI_Count changing size is really minor. My point is that we shouldn't add one *more* thing that makes ABI difficult. > A recompile when moving from 64-bit to 128-bit is really going to be the least of people's problems. That's not the issue here -- what if they just get an MPI that supports 128 bit filesystems (that already exist, BTW)? So it's not necessarily that the whole hardware is 128-bit capable, but rather some parts of their app may be able to use 128 bit support (although probably not in the near future). -- Jeff Squyres jsquyres_at_[hidden] For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/ From ftillier at [hidden] Thu Mar 3 15:15:04 2011 From: ftillier at [hidden] (Fab Tillier) Date: Thu, 3 Mar 2011 21:15:04 +0000 Subject: [Mpi3-bwcompat] ticket 265 udpated In-Reply-To: Message-ID: <91B583BE4B6FCD408F53D1B8F537E0921D733468@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> Jeff Squyres wrote on Thu, 3 Mar 2011 at 12:54:06 > On Mar 3, 2011, at 3:30 PM, Fab Tillier wrote: > >> Having explicit 64-bit support might be a Big Deal to some implementations >> that don't care about large counts. One of the goals of abstracting the count >> is that it allows those who don't care to define MPI_Count as int, and just >> have the X functions weak symbols for the non-X functions. > > Eh; I don't care about the weak symbol feature. > > I see your point about some MPI's not caring about 64 bit counts; they could > just return MPI_UNDEFINED or somesuch...? That would break applications that wanted to be count-aware, who would now have to special-code things depending on whether the targeted MPI implementation supported MPI_Count properly. Also, why would an implementation define MPI_Count as int64 and then fail all the calls that take it, when it is valid for them to define MPI_Count as int and alias the X calls to the non-X calls? I suppose we'd have to add another API to query whether 64-bit count was supported, and then app code would be peppered with if/else sections to handle the two cases. Seems like a really bad user experience. >> There's also precedent for variable width parameters such as size_t (and >> long in Linux) that also break ABI when the type changes size, but that hasn't >> been a problem - if anything it has allowed programs to be more portable >> rather than less. > > How so? The exact same reason we have MPI_Aint, rather than different MPI_xxx and MPI_xxx64 versions of calls that currently use MPI_Aint. >> Codes that use MPI_Count would have to recompile when the value of >> MPI_Count changes, but no source changes should be necessary. > > The key word there being "should". Any such changes are caused by improper application structure in the first place and should be fixed anyway. >> The whole issue of ABI is so much bigger than this (how do you handle >> string lengths, how do you handle pre-defined constants like >> MPI_COMM_WORLD, etc...) that MPI_Count changing size is really minor. > > My point is that we shouldn't add one *more* thing that makes ABI difficult. The ABI argument seems really weak to me, especially given the lackluster interest in ABI in the Forum, and the difficulty in defining an ABI that spans operating systems and CPU architectures. >> A recompile when moving from 64-bit to 128-bit is really going to be the >> least of people's problems. > > That's not the issue here -- what if they just get an MPI that supports 128 bit > filesystems (that already exist, BTW)? So it's not necessarily that the whole > hardware is 128-bit capable, but rather some parts of their app may be able > to use 128 bit support (although probably not in the near future). Using MPI_Count lets them use such already existing 128-bit file systems (as well as 32- and 64-bit file systems) so I don't understand how this supports your argument. If there are already 128-bit file systems, shouldn't we add both the 64 and 128 versions of these functions now if we go with explicit sizes? -Fab From jsquyres at [hidden] Thu Mar 3 15:28:20 2011 From: jsquyres at [hidden] (Jeff Squyres) Date: Thu, 3 Mar 2011 16:28:20 -0500 Subject: [Mpi3-bwcompat] ticket 265 udpated In-Reply-To: <91B583BE4B6FCD408F53D1B8F537E0921D733468@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> Message-ID: On Mar 3, 2011, at 4:15 PM, Fab Tillier wrote: > That would break applications that wanted to be count-aware, who would now have to special-code things depending on whether the targeted MPI implementation supported MPI_Count properly. Which is worse: what you mention, or having to ship 2 versions of libmpi (one with 32 bit counts and one with 64 bit counts)? > Also, why would an implementation define MPI_Count as int64 and then fail all the calls that take it, when it is valid for them to define MPI_Count as int and alias the X calls to the non-X calls? That's not what I said/meant. What I meant was having MPI_Type_get_extent64() return MPI_UNDEFINED -- with no MPI_Count type. But I can see your point -- it does seem sucky to have to if/then/else this in the app code (i.e., does this MPI support 256 bit counts, ...etc.). The app could wrapper it, of course, but... So your point is good: what to do about MPI implementations that don't care about large counts? Do they all have to support them anyway? Or is there a way that won't suck for users for some MPI's to *not* support large counts? >>> There's also precedent for variable width parameters such as size_t (and >>> long in Linux) that also break ABI when the type changes size, but that hasn't >>> been a problem - if anything it has allowed programs to be more portable >>> rather than less. >> >> How so? > > The exact same reason we have MPI_Aint, rather than different MPI_xxx and MPI_xxx64 versions of calls that currently use MPI_Aint. Yes, but my point is: is that really a good idea? I'm all for precedent when it makes sense or there's no obvious "better" choice -- but propagating a bad idea is, itself, a bad idea. >>> Codes that use MPI_Count would have to recompile when the value of >>> MPI_Count changes, but no source changes should be necessary. >> >> The key word there being "should". > > Any such changes are caused by improper application structure in the first place and should be fixed anyway. You and I can easily agree on this. But Customers don't always feel the same way. >>> The whole issue of ABI is so much bigger than this (how do you handle >>> string lengths, how do you handle pre-defined constants like >>> MPI_COMM_WORLD, etc...) that MPI_Count changing size is really minor. >> >> My point is that we shouldn't add one *more* thing that makes ABI difficult. > > The ABI argument seems really weak to me, especially given the lackluster interest in ABI in the Forum, and the difficulty in defining an ABI that spans operating systems and CPU architectures. I'm talking ABI within the scope of a single implementation -- Intel MPI, for example, makes a Big Deal about being able to upgrade to their next version without recompiling your application. We've been getting ABI-version-compatibility pressure on the Open MPI side, too. I'm specifically *not* talking about ABI compatibility between different MPI implementations. >>> A recompile when moving from 64-bit to 128-bit is really going to be the >>> least of people's problems. >> >> That's not the issue here -- what if they just get an MPI that supports 128 bit >> filesystems (that already exist, BTW)? So it's not necessarily that the whole >> hardware is 128-bit capable, but rather some parts of their app may be able >> to use 128 bit support (although probably not in the near future). > > Using MPI_Count lets them use such already existing 128-bit file systems (as well as 32- and 64-bit file systems) so I don't understand how this supports your argument. My point is that recompiling to go from 64 bit to 128 bit is not the issue (i.e., pointers may not be changing size to 128 bits). > If there are already 128-bit file systems, shouldn't we add both the 64 and 128 versions of these functions now if we go with explicit sizes? I think so...? That's really the question I'm asking. You're raising excellent points here. Let's keep this going, and/or continue this on the call tomorrow... -- Jeff Squyres jsquyres_at_[hidden] For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/ From alexander.supalov at [hidden] Fri Mar 4 00:33:38 2011 From: alexander.supalov at [hidden] (Supalov, Alexander) Date: Fri, 4 Mar 2011 06:33:38 +0000 Subject: [Mpi3-bwcompat] ticket 265 udpated In-Reply-To: Message-ID: <928CFBE8E7CB0040959E56B4EA41A77E011A5EC049@irsmsx504.ger.corp.intel.com> Let me add that specifying the bit count explicitly doesn't seem to have been done elsewhere in the standard. I think we may want to reformulate the purpose of the extension involved: we want to have, ultimately, the whole of the address space represented by a single MPI datatype. For that we, as a standard group, don't need to know exactly how big that space actually is, and it's not up to us to specify that anyway. Let implementations deal with this little detail. -----Original Message----- From: mpi3-bwcompat-bounces_at_[hidden] [mailto:mpi3-bwcompat-bounces_at_[hidden]] On Behalf Of Jeff Squyres Sent: Thursday, March 03, 2011 10:28 PM To: MPI-3 backwards compatability WG Subject: Re: [Mpi3-bwcompat] ticket 265 udpated On Mar 3, 2011, at 4:15 PM, Fab Tillier wrote: > That would break applications that wanted to be count-aware, who would now have to special-code things depending on whether the targeted MPI implementation supported MPI_Count properly. Which is worse: what you mention, or having to ship 2 versions of libmpi (one with 32 bit counts and one with 64 bit counts)? > Also, why would an implementation define MPI_Count as int64 and then fail all the calls that take it, when it is valid for them to define MPI_Count as int and alias the X calls to the non-X calls? That's not what I said/meant. What I meant was having MPI_Type_get_extent64() return MPI_UNDEFINED -- with no MPI_Count type. But I can see your point -- it does seem sucky to have to if/then/else this in the app code (i.e., does this MPI support 256 bit counts, ...etc.). The app could wrapper it, of course, but... So your point is good: what to do about MPI implementations that don't care about large counts? Do they all have to support them anyway? Or is there a way that won't suck for users for some MPI's to *not* support large counts? >>> There's also precedent for variable width parameters such as size_t (and >>> long in Linux) that also break ABI when the type changes size, but that hasn't >>> been a problem - if anything it has allowed programs to be more portable >>> rather than less. >> >> How so? > > The exact same reason we have MPI_Aint, rather than different MPI_xxx and MPI_xxx64 versions of calls that currently use MPI_Aint. Yes, but my point is: is that really a good idea? I'm all for precedent when it makes sense or there's no obvious "better" choice -- but propagating a bad idea is, itself, a bad idea. >>> Codes that use MPI_Count would have to recompile when the value of >>> MPI_Count changes, but no source changes should be necessary. >> >> The key word there being "should". > > Any such changes are caused by improper application structure in the first place and should be fixed anyway. You and I can easily agree on this. But Customers don't always feel the same way. >>> The whole issue of ABI is so much bigger than this (how do you handle >>> string lengths, how do you handle pre-defined constants like >>> MPI_COMM_WORLD, etc...) that MPI_Count changing size is really minor. >> >> My point is that we shouldn't add one *more* thing that makes ABI difficult. > > The ABI argument seems really weak to me, especially given the lackluster interest in ABI in the Forum, and the difficulty in defining an ABI that spans operating systems and CPU architectures. I'm talking ABI within the scope of a single implementation -- Intel MPI, for example, makes a Big Deal about being able to upgrade to their next version without recompiling your application. We've been getting ABI-version-compatibility pressure on the Open MPI side, too. I'm specifically *not* talking about ABI compatibility between different MPI implementations. >>> A recompile when moving from 64-bit to 128-bit is really going to be the >>> least of people's problems. >> >> That's not the issue here -- what if they just get an MPI that supports 128 bit >> filesystems (that already exist, BTW)? So it's not necessarily that the whole >> hardware is 128-bit capable, but rather some parts of their app may be able >> to use 128 bit support (although probably not in the near future). > > Using MPI_Count lets them use such already existing 128-bit file systems (as well as 32- and 64-bit file systems) so I don't understand how this supports your argument. My point is that recompiling to go from 64 bit to 128 bit is not the issue (i.e., pointers may not be changing size to 128 bits). > If there are already 128-bit file systems, shouldn't we add both the 64 and 128 versions of these functions now if we go with explicit sizes? I think so...? That's really the question I'm asking. You're raising excellent points here. Let's keep this going, and/or continue this on the call tomorrow... -- 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 -------------------------------------------------------------------------------------- Intel GmbH Dornacher Strasse 1 85622 Feldkirchen/Muenchen, Deutschland 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 a.M. (BLZ 502 109 00) 600119052 From terry.dontje at [hidden] Fri Mar 4 09:59:44 2011 From: terry.dontje at [hidden] (Terry Dontje) Date: Fri, 04 Mar 2011 10:59:44 -0500 Subject: [Mpi3-bwcompat] Fwd: Re: ticket 265 udpated Message-ID: <4D710C70.2080300@oracle.com> On 03/02/2011 08:28 PM, Fab Tillier wrote: > Hi Folks, > > I've updated ticket 265 with the comments from the last meeting. Please take a look. We'll go over the PDF on Friday (right David?) and hopefully agree that it's ready to send out for wider review. > > TBD still (I think) is whether to split it into two tickets, one for the basic functionality, the other for the new 'w' collectives. > > https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/265 > > -Fab > > _______________________________________________ > Mpi3-bwcompat mailing list > Mpi3-bwcompat_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-bwcompat Fab, a few comments on the pdf ticket265 items. 1. Page 16 line 14, should this section actually call out the *_X functions? 2. Page 103 line 35, should "MPI_GET_COUNT returns and MPI_GET_COUNT_X return..." really be "MPI_GET_COUNT and MPI_GET_COUNT_X both return..." 3. Page 125 line 5, should there be a MPI_Pack_size_X routine? 4. Page 410 line 42, Should "MPI_GET_COUNT will return..." really be "MPI_GET_COUNT and MPI_GET_COUNT_X will return..." -- Oracle Terry D. Dontje | Principal Software Engineer Developer Tools Engineering | +1.781.442.2631 Oracle *- Performance Technologies* 95 Network Drive, Burlington, MA 01803 Email terry.dontje_at_[hidden] * -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 02-part Type: application/octet-stream Size: 2059 bytes Desc: not available URL: From david.solt at [hidden] Fri Mar 4 10:19:57 2011 From: david.solt at [hidden] (Solt, David George) Date: Fri, 4 Mar 2011 16:19:57 +0000 Subject: [Mpi3-bwcompat] Fwd: Re: ticket 265 udpated In-Reply-To: <4D710C70.2080300@oracle.com> Message-ID: Sorry, pdf is not ready yet. I will work on it over the weekend. Dave From: mpi3-bwcompat-bounces_at_[hidden] [mailto:mpi3-bwcompat-bounces_at_[hidden]] On Behalf Of Terry Dontje Sent: Friday, March 04, 2011 10:00 AM To: mpi3-bwcompat_at_[hidden] Subject: [Mpi3-bwcompat] Fwd: Re: ticket 265 udpated On 03/02/2011 08:28 PM, Fab Tillier wrote: Hi Folks, I've updated ticket 265 with the comments from the last meeting. Please take a look. We'll go over the PDF on Friday (right David?) and hopefully agree that it's ready to send out for wider review. TBD still (I think) is whether to split it into two tickets, one for the basic functionality, the other for the new 'w' collectives. https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/265 -Fab _______________________________________________ Mpi3-bwcompat mailing list Mpi3-bwcompat_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-bwcompat Fab, a few comments on the pdf ticket265 items. 1. Page 16 line 14, should this section actually call out the *_X functions? 2. Page 103 line 35, should "MPI_GET_COUNT returns and MPI_GET_COUNT_X return..." really be "MPI_GET_COUNT and MPI_GET_COUNT_X both return..." 3. Page 125 line 5, should there be a MPI_Pack_size_X routine? 4. Page 410 line 42, Should "MPI_GET_COUNT will return..." really be "MPI_GET_COUNT and MPI_GET_COUNT_X will return..." -- [cid:image001.gif_at_01CBDA55.B62ABA80] Terry D. Dontje | Principal Software Engineer Developer Tools Engineering | +1.781.442.2631 Oracle - Performance Technologies 95 Network Drive, Burlington, MA 01803 Email terry.dontje_at_[hidden] * -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: application/octet-stream Size: 2059 bytes Desc: not available URL: From terry.dontje at [hidden] Fri Mar 4 10:31:09 2011 From: terry.dontje at [hidden] (Terry Dontje) Date: Fri, 04 Mar 2011 11:31:09 -0500 Subject: [Mpi3-bwcompat] Fwd: Re: ticket 265 udpated In-Reply-To: Message-ID: <4D7113CD.1060902@oracle.com> Aw man, you mean I reviewed that pdf for no good reason :-). I was wondering why it was 3 weeks old. --td On 03/04/2011 11:19 AM, Solt, David George wrote: > > Sorry, pdf is not ready yet. I will work on it over the weekend. > > Dave > > *From:*mpi3-bwcompat-bounces_at_[hidden] > [mailto:mpi3-bwcompat-bounces_at_[hidden]] *On Behalf Of > *Terry Dontje > *Sent:* Friday, March 04, 2011 10:00 AM > *To:* mpi3-bwcompat_at_[hidden] > *Subject:* [Mpi3-bwcompat] Fwd: Re: ticket 265 udpated > > > On 03/02/2011 08:28 PM, Fab Tillier wrote: > > Hi Folks, > > I've updated ticket 265 with the comments from the last meeting. Please take a look. We'll go over the PDF on Friday (right David?) and hopefully agree that it's ready to send out for wider review. > > TBD still (I think) is whether to split it into two tickets, one for the basic functionality, the other for the new 'w' collectives. > > https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/265 > > -Fab > > _______________________________________________ > Mpi3-bwcompat mailing list > Mpi3-bwcompat_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-bwcompat > > Fab, a few comments on the pdf ticket265 items. > > 1. Page 16 line 14, should this section actually call out the *_X > functions? > 2. Page 103 line 35, should "MPI_GET_COUNT returns and > MPI_GET_COUNT_X return..." > really be "MPI_GET_COUNT and MPI_GET_COUNT_X both return..." > 3. Page 125 line 5, should there be a MPI_Pack_size_X routine? > 4. Page 410 line 42, Should "MPI_GET_COUNT will return..." really be > "MPI_GET_COUNT and MPI_GET_COUNT_X will return..." > > -- > Oracle > Terry D. Dontje | Principal Software Engineer > Developer Tools Engineering | +1.781.442.2631 > Oracle *- Performance Technologies* > 95 Network Drive, Burlington, MA 01803 > Email terry.dontje_at_[hidden] > > > _______________________________________________ > Mpi3-bwcompat mailing list > Mpi3-bwcompat_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-bwcompat -- Oracle Terry D. Dontje | Principal Software Engineer Developer Tools Engineering | +1.781.442.2631 Oracle *- Performance Technologies* 95 Network Drive, Burlington, MA 01803 Email terry.dontje_at_[hidden] * -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 02-part Type: application/octet-stream Size: 2059 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 03-part Type: application/octet-stream Size: 2059 bytes Desc: not available URL: From david.solt at [hidden] Fri Mar 4 10:35:15 2011 From: david.solt at [hidden] (Solt, David George) Date: Fri, 4 Mar 2011 16:35:15 +0000 Subject: [Mpi3-bwcompat] Fwd: Re: ticket 265 udpated In-Reply-To: <4D7113CD.1060902@oracle.com> Message-ID: Sorry, we have a product deadline on Monday and this week was the last week for a class I'm teaching and grades are due tomorrow. I'm already not sleeping or I would have stayed up late last night to do it. Do we want to meet today to discuss the ticket or should I cancel today and setup a meeting for sometime next week so we can look at the pdf as well? Thanks, Dave From: mpi3-bwcompat-bounces_at_[hidden] [mailto:mpi3-bwcompat-bounces_at_[hidden]] On Behalf Of Terry Dontje Sent: Friday, March 04, 2011 10:31 AM To: mpi3-bwcompat_at_[hidden] Subject: Re: [Mpi3-bwcompat] Fwd: Re: ticket 265 udpated Aw man, you mean I reviewed that pdf for no good reason :-). I was wondering why it was 3 weeks old. --td On 03/04/2011 11:19 AM, Solt, David George wrote: Sorry, pdf is not ready yet. I will work on it over the weekend. Dave From: mpi3-bwcompat-bounces_at_[hidden] [mailto:mpi3-bwcompat-bounces_at_[hidden]] On Behalf Of Terry Dontje Sent: Friday, March 04, 2011 10:00 AM To: mpi3-bwcompat_at_[hidden] Subject: [Mpi3-bwcompat] Fwd: Re: ticket 265 udpated On 03/02/2011 08:28 PM, Fab Tillier wrote: Hi Folks, I've updated ticket 265 with the comments from the last meeting. Please take a look. We'll go over the PDF on Friday (right David?) and hopefully agree that it's ready to send out for wider review. TBD still (I think) is whether to split it into two tickets, one for the basic functionality, the other for the new 'w' collectives. https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/265 -Fab _______________________________________________ Mpi3-bwcompat mailing list Mpi3-bwcompat_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-bwcompat Fab, a few comments on the pdf ticket265 items. 1. Page 16 line 14, should this section actually call out the *_X functions? 2. Page 103 line 35, should "MPI_GET_COUNT returns and MPI_GET_COUNT_X return..." really be "MPI_GET_COUNT and MPI_GET_COUNT_X both return..." 3. Page 125 line 5, should there be a MPI_Pack_size_X routine? 4. Page 410 line 42, Should "MPI_GET_COUNT will return..." really be "MPI_GET_COUNT and MPI_GET_COUNT_X will return..." -- [cid:image001.gif_at_01CBDA57.D97D5270] Terry D. Dontje | Principal Software Engineer Developer Tools Engineering | +1.781.442.2631 Oracle - Performance Technologies 95 Network Drive, Burlington, MA 01803 Email terry.dontje_at_[hidden] _______________________________________________ Mpi3-bwcompat mailing list Mpi3-bwcompat_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-bwcompat -- [cid:image001.gif_at_01CBDA57.D97D5270] Terry D. Dontje | Principal Software Engineer Developer Tools Engineering | +1.781.442.2631 Oracle - Performance Technologies 95 Network Drive, Burlington, MA 01803 Email terry.dontje_at_[hidden] * -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: application/octet-stream Size: 2059 bytes Desc: not available URL: From ftillier at [hidden] Fri Mar 4 11:15:01 2011 From: ftillier at [hidden] (Fab Tillier) Date: Fri, 4 Mar 2011 17:15:01 +0000 Subject: [Mpi3-bwcompat] Fwd: Re: ticket 265 udpated In-Reply-To: Message-ID: <91B583BE4B6FCD408F53D1B8F537E0921D7342AF@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> I think we should meet to at least discuss Jeff's so-called "thought" of making count size explicit. :P -Fab From: mpi3-bwcompat-bounces_at_[hidden] [mailto:mpi3-bwcompat-bounces_at_[hidden]] On Behalf Of Solt, David George Sent: Friday, March 04, 2011 8:35 AM To: MPI-3 backwards compatability WG Subject: Re: [Mpi3-bwcompat] Fwd: Re: ticket 265 udpated Sorry, we have a product deadline on Monday and this week was the last week for a class I'm teaching and grades are due tomorrow. I'm already not sleeping or I would have stayed up late last night to do it. Do we want to meet today to discuss the ticket or should I cancel today and setup a meeting for sometime next week so we can look at the pdf as well? Thanks, Dave From: mpi3-bwcompat-bounces_at_[hidden] [mailto:mpi3-bwcompat-bounces_at_[hidden]] On Behalf Of Terry Dontje Sent: Friday, March 04, 2011 10:31 AM To: mpi3-bwcompat_at_[hidden] Subject: Re: [Mpi3-bwcompat] Fwd: Re: ticket 265 udpated Aw man, you mean I reviewed that pdf for no good reason :-). I was wondering why it was 3 weeks old. --td On 03/04/2011 11:19 AM, Solt, David George wrote: Sorry, pdf is not ready yet. I will work on it over the weekend. Dave From: mpi3-bwcompat-bounces_at_[hidden] [mailto:mpi3-bwcompat-bounces_at_[hidden]] On Behalf Of Terry Dontje Sent: Friday, March 04, 2011 10:00 AM To: mpi3-bwcompat_at_[hidden] Subject: [Mpi3-bwcompat] Fwd: Re: ticket 265 udpated On 03/02/2011 08:28 PM, Fab Tillier wrote: Hi Folks, I've updated ticket 265 with the comments from the last meeting. Please take a look. We'll go over the PDF on Friday (right David?) and hopefully agree that it's ready to send out for wider review. TBD still (I think) is whether to split it into two tickets, one for the basic functionality, the other for the new 'w' collectives. https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/265 -Fab _______________________________________________ Mpi3-bwcompat mailing list Mpi3-bwcompat_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-bwcompat Fab, a few comments on the pdf ticket265 items. 1. Page 16 line 14, should this section actually call out the *_X functions? 2. Page 103 line 35, should "MPI_GET_COUNT returns and MPI_GET_COUNT_X return..." really be "MPI_GET_COUNT and MPI_GET_COUNT_X both return..." 3. Page 125 line 5, should there be a MPI_Pack_size_X routine? 4. Page 410 line 42, Should "MPI_GET_COUNT will return..." really be "MPI_GET_COUNT and MPI_GET_COUNT_X will return..." -- [Oracle] Terry D. Dontje | Principal Software Engineer Developer Tools Engineering | +1.781.442.2631 Oracle - Performance Technologies 95 Network Drive, Burlington, MA 01803 Email terry.dontje_at_[hidden] _______________________________________________ Mpi3-bwcompat mailing list Mpi3-bwcompat_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-bwcompat -- [Oracle] Terry D. Dontje | Principal Software Engineer Developer Tools Engineering | +1.781.442.2631 Oracle - Performance Technologies 95 Network Drive, Burlington, MA 01803 Email terry.dontje_at_[hidden] * -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: application/octet-stream Size: 2059 bytes Desc: not available URL: From jsquyres at [hidden] Fri Mar 4 11:37:15 2011 From: jsquyres at [hidden] (Jeff Squyres) Date: Fri, 4 Mar 2011 12:37:15 -0500 Subject: [Mpi3-bwcompat] Fwd: Re: ticket 265 udpated In-Reply-To: <91B583BE4B6FCD408F53D1B8F537E0921D7342AF@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> Message-ID: Hey, Dave's the slacker here, not me! At least I came up with pseudo-formed thoughts! :-p See you in ~30 mins... Maybe we'll make this a short call if Fab convinces me that explicit sizes are Bad. On Mar 4, 2011, at 12:15 PM, Fab Tillier wrote: > I think we should meet to at least discuss Jeff’s so-called “thought” of making count size explicit. :P > > -Fab > > From: mpi3-bwcompat-bounces_at_[hidden] [mailto:mpi3-bwcompat-bounces_at_[hidden]] On Behalf Of Solt, David George > Sent: Friday, March 04, 2011 8:35 AM > To: MPI-3 backwards compatability WG > Subject: Re: [Mpi3-bwcompat] Fwd: Re: ticket 265 udpated > > Sorry, we have a product deadline on Monday and this week was the last week for a class I’m teaching and grades are due tomorrow. I’m already not sleeping or I would have stayed up late last night to do it. > > Do we want to meet today to discuss the ticket or should I cancel today and setup a meeting for sometime next week so we can look at the pdf as well? > > Thanks, > Dave > > From: mpi3-bwcompat-bounces_at_[hidden] [mailto:mpi3-bwcompat-bounces_at_[hidden]] On Behalf Of Terry Dontje > Sent: Friday, March 04, 2011 10:31 AM > To: mpi3-bwcompat_at_[hidden] > Subject: Re: [Mpi3-bwcompat] Fwd: Re: ticket 265 udpated > > Aw man, you mean I reviewed that pdf for no good reason :-). I was wondering why it was 3 weeks old. > > --td > > On 03/04/2011 11:19 AM, Solt, David George wrote: > Sorry, pdf is not ready yet. I will work on it over the weekend. > Dave > > From: mpi3-bwcompat-bounces_at_[hidden] [mailto:mpi3-bwcompat-bounces_at_[hidden]] On Behalf Of Terry Dontje > Sent: Friday, March 04, 2011 10:00 AM > To: mpi3-bwcompat_at_[hidden] > Subject: [Mpi3-bwcompat] Fwd: Re: ticket 265 udpated > > > On 03/02/2011 08:28 PM, Fab Tillier wrote: > Hi Folks, > > I've updated ticket 265 with the comments from the last meeting. Please take a look. We'll go over the PDF on Friday (right David?) and hopefully agree that it's ready to send out for wider review. > > TBD still (I think) is whether to split it into two tickets, one for the basic functionality, the other for the new 'w' collectives. > > https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/265 > > -Fab > > _______________________________________________ > Mpi3-bwcompat mailing list > Mpi3-bwcompat_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-bwcompat > Fab, a few comments on the pdf ticket265 items. > > 1. Page 16 line 14, should this section actually call out the *_X functions? > 2. Page 103 line 35, should "MPI_GET_COUNT returns and MPI_GET_COUNT_X return..." > really be "MPI_GET_COUNT and MPI_GET_COUNT_X both return..." > 3. Page 125 line 5, should there be a MPI_Pack_size_X routine? > 4. Page 410 line 42, Should "MPI_GET_COUNT will return..." really be > "MPI_GET_COUNT and MPI_GET_COUNT_X will return..." > > -- > > Terry D. Dontje | Principal Software Engineer > Developer Tools Engineering | +1.781.442.2631 > Oracle - Performance Technologies > 95 Network Drive, Burlington, MA 01803 > Email terry.dontje_at_[hidden] > > > > > > _______________________________________________ > Mpi3-bwcompat mailing list > Mpi3-bwcompat_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-bwcompat > > > -- > > Terry D. Dontje | Principal Software Engineer > Developer Tools Engineering | +1.781.442.2631 > Oracle - Performance Technologies > 95 Network Drive, Burlington, MA 01803 > Email terry.dontje_at_[hidden] > > > > _______________________________________________ > 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 david.solt at [hidden] Fri Mar 4 12:52:53 2011 From: david.solt at [hidden] (Solt, David George) Date: Fri, 4 Mar 2011 18:52:53 +0000 Subject: [Mpi3-bwcompat] MPI Backward Compatibility Working Group Message-ID: When: Friday, March 11, 2011 12:00 PM-1:00 PM (GMT-06:00) Central Time (US & Canada). Where: 866.409.2889 id 3582114059 Note: The GMT offset above does not reflect daylight saving time adjustments. *~*~*~*~*~*~*~*~*~* One-off meeting for next week to make sure MPI_ Count and collective change pdfs goes out before the deadline Virtual room info in case we need it: https://www.rooms.hp.com/attend/default.aspx?key=EPSUR7UU65 U.S. toll number 702.696.4520 U.S. toll-free dial-in number International – see attached pdf 866.409.2889 - Conference Code: 3582114059 * -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 02-part Type: text/calendar Size: 2045 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: AudioConferencingBridge1.pdf Type: application/pdf Size: 112049 bytes Desc: AudioConferencingBridge1.pdf URL: From jsquyres at [hidden] Fri Mar 4 12:58:52 2011 From: jsquyres at [hidden] (Jeff Squyres) Date: Fri, 4 Mar 2011 13:58:52 -0500 Subject: [Mpi3-bwcompat] Plan for MPI_Count Message-ID: BW Compatibility group -- On the call today, we decided: - Jeff abandoned the idea of explicitly-sized count types - Fab will split the collectives out into a separate ticket - Dave will send a final PDF to the bwcompat group to review early next week - We need to review this PDF ASAP so that it can be sent to the Forum by COB Friday, March 11, 2011 (so that it meets the 2-weeks-before-the-Forum-meeting requirement for a first reading) I'll be sending a mail shortly to the Forum mailing list asking how to (formally) review this text, because it spans 6 chapters. -- 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 Mar 4 14:46:14 2011 From: jsquyres at [hidden] (Jeff Squyres) Date: Fri, 4 Mar 2011 15:46:14 -0500 Subject: [Mpi3-bwcompat] MPI timer requests Message-ID: <9B3538E9-5523-477F-97D3-8BCEA0CCB40A@cisco.com> All -- Fab and I want to introduce the idea of "timer" MPI_Requests at the next Forum meeting. We have no ticket yet; we just want to introduce the idea to the Forum and see if it is liked. We made up a few slides about the concept -- before we throw it out to the rest of the Forum, would you (the bwcompat group) have a look and let us know your feedback? We know that this won't ultimately end up in the bwcompat group, but we don't know exactly where it will end up yet, and we wanted to get *some* feedback before presenting it to the greater Forum. https://svn.mpi-forum.org/trac/mpi-forum-web/wiki/MPI_Request_timers Thanks! -- Jeff Squyres jsquyres_at_[hidden] For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/ From ftillier at [hidden] Fri Mar 4 14:53:56 2011 From: ftillier at [hidden] (Fab Tillier) Date: Fri, 4 Mar 2011 20:53:56 +0000 Subject: [Mpi3-bwcompat] Accepted: MPI Backward Compatibility Working Group Message-ID: <91B583BE4B6FCD408F53D1B8F537E0921D735C76@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> * -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 02-part Type: text/calendar Size: 1197 bytes Desc: not available URL: From goodell at [hidden] Fri Mar 4 15:20:49 2011 From: goodell at [hidden] (Dave Goodell) Date: Fri, 4 Mar 2011 15:20:49 -0600 Subject: [Mpi3-bwcompat] MPI timer requests In-Reply-To: <9B3538E9-5523-477F-97D3-8BCEA0CCB40A@cisco.com> Message-ID: <7129A412-5829-4243-92F9-E21BCED95B59@mcs.anl.gov> I have mixed feelings about the idea. When making your case to the Forum you'll need to explain why this can't or shouldn't be done with the existing generalized request framework, or alternatively Rob Latham's greq extensions. I see the convenience to the user, but I don't have a clear view of what the impact would be on implementations. I suspect it would be modest, but it does affect progress, so sometimes tricky things show up after deeper thought or some implementation work. -Dave On Mar 4, 2011, at 2:46 PM CST, Jeff Squyres wrote: > All -- > > Fab and I want to introduce the idea of "timer" MPI_Requests at the next Forum meeting. We have no ticket yet; we just want to introduce the idea to the Forum and see if it is liked. > > We made up a few slides about the concept -- before we throw it out to the rest of the Forum, would you (the bwcompat group) have a look and let us know your feedback? We know that this won't ultimately end up in the bwcompat group, but we don't know exactly where it will end up yet, and we wanted to get *some* feedback before presenting it to the greater Forum. > > https://svn.mpi-forum.org/trac/mpi-forum-web/wiki/MPI_Request_timers > > Thanks! > > -- > 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 ftillier at [hidden] Fri Mar 4 16:14:03 2011 From: ftillier at [hidden] (Fab Tillier) Date: Fri, 4 Mar 2011 22:14:03 +0000 Subject: [Mpi3-bwcompat] Plan for MPI_Count In-Reply-To: Message-ID: <91B583BE4B6FCD408F53D1B8F537E0921D735FC0@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> Jeff Squyres wrote on Fri, 4 Mar 2011 at 10:58:52 > BW Compatibility group -- > > On the call today, we decided: > > - Jeff abandoned the idea of explicitly-sized count types > - Fab will split the collectives out into a separate ticket Done, collectives are now in their own ticket, #269: https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/269 > - Dave will send a final PDF to the bwcompat group to review early next week Are we going to have 2 PDF files, or one with both tickets worth of changes merged but properly annotated? > - We need to review this PDF ASAP so that it can be sent to the Forum by > COB Friday, March 11, 2011 (so that it meets the 2-weeks-before-the-Forum- > meeting requirement for a first reading) > > I'll be sending a mail shortly to the Forum mailing list asking how to (formally) > review this text, because it spans 6 chapters. > From jsquyres at [hidden] Fri Mar 4 16:21:09 2011 From: jsquyres at [hidden] (Jeff Squyres) Date: Fri, 4 Mar 2011 17:21:09 -0500 Subject: [Mpi3-bwcompat] Plan for MPI_Count In-Reply-To: <91B583BE4B6FCD408F53D1B8F537E0921D735FC0@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> Message-ID: On Mar 4, 2011, at 5:14 PM, Fab Tillier wrote: >> - Dave will send a final PDF to the bwcompat group to review early next week > > Are we going to have 2 PDF files, or one with both tickets worth of changes merged but properly annotated? I think one PDF with the appropriate ticket markings should be fine. -- 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 Mar 4 16:46:17 2011 From: jsquyres at [hidden] (Jeff Squyres) Date: Fri, 4 Mar 2011 17:46:17 -0500 Subject: [Mpi3-bwcompat] Fwd: [Mpi-forum] MPI_Count ticket In-Reply-To: <2273C4B4-93A5-48DE-A0FF-220D9CAF8181@illinois.edu> Message-ID: Bwcompat WG -- I'm kinda thinking that this means we won't be able to have a first reading by next meeting. Getting reviews by the chapter authors takes time... Begin forwarded message: > From: William Gropp > Date: March 4, 2011 5:41:07 PM EST > To: Main MPI Forum mailing list > Subject: Re: [Mpi-forum] MPI_Count ticket > Reply-To: Main MPI Forum mailing list > > Changes to the other chapters require at least the chapter author's review. They should do whatever they need to do to ensure that the changes make sense (so that roughly means they should review the whole ticket). > > It would be good if they're done by the first reading. If they find something that needs to be changed, other than something that meets everyone's definition of a trivial change, then you'd need to fix it and have a new first reading. > > Bill > > On Mar 4, 2011, at 1:05 PM, Jeff Squyres wrote: > >> Forum -- >> >> Sorry; I know we've discussed this a number of times, but they've all gotten jumbled in my head and I don't remember what was decided. >> >> We are bringing the MPI_Count ticket to the Forum for a first reading in Chicago. Unfortunately, this ticket will span a bunch of chapters (5 or 6, I think). >> >> Do we have to get the individual sections of text reviewed by each chapter committee? And are they expected to review the *whole* ticket, and then double check/review it in the context of *their specific chapter*? (I ask because the text in one chapter doesn't really make sense without the rest of the text in the ticket) >> >> If we do need reviews from each chapter committee, do they need to be complete by the first reading? >> >> -- >> Jeff Squyres >> jsquyres_at_[hidden] >> For corporate legal information go to: >> http://www.cisco.com/web/about/doing_business/legal/cri/ >> >> >> _______________________________________________ >> mpi-forum mailing list >> mpi-forum_at_[hidden] >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum > > 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-forum mailing list > mpi-forum_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum -- Jeff Squyres jsquyres_at_[hidden] For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/ From ftillier at [hidden] Fri Mar 4 16:50:17 2011 From: ftillier at [hidden] (Fab Tillier) Date: Fri, 4 Mar 2011 22:50:17 +0000 Subject: [Mpi3-bwcompat] Fwd: [Mpi-forum] MPI_Count ticket In-Reply-To: Message-ID: <91B583BE4B6FCD408F53D1B8F537E0921D736156@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> Only an issue if a chapter author has a non-trivial issue. We can go forward and risk having the clock reset, or wait more. The former has the same worst case latency as waiting, but a much better best case. -Fab Jeff Squyres wrote on Fri, 4 Mar 2011 at 14:46:17 > Bwcompat WG -- > > I'm kinda thinking that this means we won't be able to have a first reading by > next meeting. Getting reviews by the chapter authors takes time... > > > Begin forwarded message: > >> From: William Gropp >> Date: March 4, 2011 5:41:07 PM EST >> To: Main MPI Forum mailing list >> Subject: Re: [Mpi-forum] MPI_Count ticket >> Reply-To: Main MPI Forum mailing list >> >> Changes to the other chapters require at least the chapter author's review. > They should do whatever they need to do to ensure that the changes make > sense (so that roughly means they should review the whole ticket). >> >> It would be good if they're done by the first reading. If they find something > that needs to be changed, other than something that meets everyone's > definition of a trivial change, then you'd need to fix it and have a new first > reading. >> >> Bill >> >> On Mar 4, 2011, at 1:05 PM, Jeff Squyres wrote: >> >>> Forum -- >>> >>> Sorry; I know we've discussed this a number of times, but they've all >>> gotten jumbled in my head and I don't remember what was decided. >>> >>> We are bringing the MPI_Count ticket to the Forum for a first reading in > Chicago. Unfortunately, this ticket will span a bunch of chapters (5 or 6, I > think). >>> >>> Do we have to get the individual sections of text reviewed by each > chapter committee? And are they expected to review the *whole* ticket, > and then double check/review it in the context of *their specific chapter*? (I > ask because the text in one chapter doesn't really make sense without the > rest of the text in the ticket) >>> >>> If we do need reviews from each chapter committee, do they need to be >>> complete by the first reading? >>> >>> -- >>> Jeff Squyres >>> jsquyres_at_[hidden] >>> For corporate legal information go to: >>> http://www.cisco.com/web/about/doing_business/legal/cri/ >>> >>> >>> _______________________________________________ >>> mpi-forum mailing list >>> mpi-forum_at_[hidden] >>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum >> >> 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-forum mailing list >> mpi-forum_at_[hidden] >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum > > From wgropp at [hidden] Sat Mar 5 09:20:17 2011 From: wgropp at [hidden] (William Gropp) Date: Sat, 5 Mar 2011 09:20:17 -0600 Subject: [Mpi3-bwcompat] Fwd: [Mpi-forum] MPI_Count ticket In-Reply-To: <[Mpi3-bwcompat] Fwd: [Mpi-forum] MPI_Count ticket> Message-ID: <173BA203-C180-4379-837F-F5F722209D50@illinois.edu> Jeff, I think you should go ahead with the reading. If the chapter authors don't find anything (other than trivial items), then you are good to go. If they do, well, the reading will be useful anyway. Review by the chapter authors should not be *required* before a *reading*. It is required before the first vote. Bill On Mar 4, 2011, at 4:46 PM, Jeff Squyres wrote: > Bwcompat WG -- > > I'm kinda thinking that this means we won't be able to have a first > reading= > by next meeting. Getting reviews by the chapter authors takes time... > > > Begin forwarded message: > >> From: William Gropp >> Date: March 4, 2011 5:41:07 PM EST >> To: Main MPI Forum mailing list >> Subject: Re: [Mpi-forum] MPI_Count ticket >> Reply-To: Main MPI Forum mailing list >> =20 >> Changes to the other chapters require at least the chapter author's >> revie= > w. They should do whatever they need to do to ensure that the > changes make= > sense (so that roughly means they should review the whole ticket). >> =20 >> It would be good if they're done by the first reading. If they >> find some= > thing that needs to be changed, other than something that meets > everyone's = > definition of a trivial change, then you'd need to fix it and have a > new fi= > rst reading. >> =20 >> Bill >> =20 >> On Mar 4, 2011, at 1:05 PM, Jeff Squyres wrote: >> =20 >>> Forum -- >>> =20 >>> Sorry; I know we've discussed this a number of times, but they've >>> all go= > tten jumbled in my head and I don't remember what was decided. >>> =20 >>> We are bringing the MPI_Count ticket to the Forum for a first >>> reading in= > Chicago. Unfortunately, this ticket will span a bunch of chapters > (5 or 6= > , I think). >>> =20 >>> Do we have to get the individual sections of text reviewed by each >>> chapt= > er committee? And are they expected to review the *whole* ticket, > and then= > double check/review it in the context of *their specific chapter*? > (I ask= > because the text in one chapter doesn't really make sense without > the rest= > of the text in the ticket) >>> =20 >>> If we do need reviews from each chapter committee, do they need to >>> be co= > mplete by the first reading? >>> =20 >>> --=20 >>> Jeff Squyres >>> jsquyres_at_[hidden] >>> For corporate legal information go to: >>> http://www.cisco.com/web/about/doing_business/legal/cri/ >>> =20 >>> =20 >>> _______________________________________________ >>> mpi-forum mailing list >>> mpi-forum_at_[hidden] >>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum >> =20 >> 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 >> =20 >> =20 >> =20 >> =20 >> _______________________________________________ >> mpi-forum mailing list >> mpi-forum_at_[hidden] >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum > > > --=20 > 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 William Gropp Deputy Director for Research Institute for Advanced Computing Applications and Technologies Paul and Cynthia Saylor Professor of Computer Science University of Illinois Urbana-Champaign From alexander.supalov at [hidden] Mon Mar 7 06:04:51 2011 From: alexander.supalov at [hidden] (Supalov, Alexander) Date: Mon, 7 Mar 2011 12:04:51 +0000 Subject: [Mpi3-bwcompat] MPI timer requests In-Reply-To: <7129A412-5829-4243-92F9-E21BCED95B59@mcs.anl.gov> Message-ID: <928CFBE8E7CB0040959E56B4EA41A77E011A63BF4E@irsmsx504.ger.corp.intel.com> Hi, The idea of separating the timeout functionality from the actual request(s) that are being waited upon looks interesting to me. One could probably want to timeout on a non-blocking spawn or connect/accept, etc., as well. Or on any non-blocking collective, for that matter. Would this proposal work there? As a possible alternative, I wonder whether one can make MPI_Request an inout argument for the MPI_TIMER_CREATE or the like, and possibly "precondition" or "postcondition" a request by adding a timeout to it. E.g., for "postconditioning": MPI_Isend(..., &req); MPI_Timer_set(MPI_Wtime() + 5, &req); ... MPI_Wait(&req); Or, for "preconditioning": MPI_Timer_create(MPI_Wtime() + 5, &req); MPI_Isend(..., &req); ... MPI_Wait(&req); The benefit is that there's direct association of the timeout with the request involved, and possibly more flexibility wrt individual, per-request timeouts. The drawback is the need to modify quite a few interfaces. What do you think? Best regards. Alexander -----Original Message----- From: mpi3-bwcompat-bounces_at_[hidden] [mailto:mpi3-bwcompat-bounces_at_[hidden]] On Behalf Of Dave Goodell Sent: Friday, March 04, 2011 10:21 PM To: MPI-3 backwards compatability WG Subject: Re: [Mpi3-bwcompat] MPI timer requests I have mixed feelings about the idea. When making your case to the Forum you'll need to explain why this can't or shouldn't be done with the existing generalized request framework, or alternatively Rob Latham's greq extensions. I see the convenience to the user, but I don't have a clear view of what the impact would be on implementations. I suspect it would be modest, but it does affect progress, so sometimes tricky things show up after deeper thought or some implementation work. -Dave On Mar 4, 2011, at 2:46 PM CST, Jeff Squyres wrote: > All -- > > Fab and I want to introduce the idea of "timer" MPI_Requests at the next Forum meeting. We have no ticket yet; we just want to introduce the idea to the Forum and see if it is liked. > > We made up a few slides about the concept -- before we throw it out to the rest of the Forum, would you (the bwcompat group) have a look and let us know your feedback? We know that this won't ultimately end up in the bwcompat group, but we don't know exactly where it will end up yet, and we wanted to get *some* feedback before presenting it to the greater Forum. > > https://svn.mpi-forum.org/trac/mpi-forum-web/wiki/MPI_Request_timers > > Thanks! > > -- > 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 -------------------------------------------------------------------------------------- Intel GmbH Dornacher Strasse 1 85622 Feldkirchen/Muenchen, Deutschland 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 a.M. (BLZ 502 109 00) 600119052 From goodell at [hidden] Mon Mar 7 09:27:52 2011 From: goodell at [hidden] (Dave Goodell) Date: Mon, 7 Mar 2011 09:27:52 -0600 Subject: [Mpi3-bwcompat] MPI timer requests In-Reply-To: <928CFBE8E7CB0040959E56B4EA41A77E011A63BF4E@irsmsx504.ger.corp.intel.com> Message-ID: What would be the impact of such a proposal on message matching and ordering semantics? I suspect this would make developing an efficient receive queue implementation even more difficult than it already is. -Dave On Mar 7, 2011, at 6:04 AM CST, Supalov, Alexander wrote: > Hi, > > The idea of separating the timeout functionality from the actual request(s) that are being waited upon looks interesting to me. One could probably want to timeout on a non-blocking spawn or connect/accept, etc., as well. Or on any non-blocking collective, for that matter. Would this proposal work there? > > As a possible alternative, I wonder whether one can make MPI_Request an inout argument for the MPI_TIMER_CREATE or the like, and possibly "precondition" or "postcondition" a request by adding a timeout to it. E.g., for "postconditioning": > > MPI_Isend(..., &req); > MPI_Timer_set(MPI_Wtime() + 5, &req); > ... > MPI_Wait(&req); > > Or, for "preconditioning": > > MPI_Timer_create(MPI_Wtime() + 5, &req); > MPI_Isend(..., &req); > ... > MPI_Wait(&req); > > The benefit is that there's direct association of the timeout with the request involved, and possibly more flexibility wrt individual, per-request timeouts. The drawback is the need to modify quite a few interfaces. What do you think? > > Best regards. > > Alexander > > -----Original Message----- > From: mpi3-bwcompat-bounces_at_[hidden] [mailto:mpi3-bwcompat-bounces_at_[hidden]] On Behalf Of Dave Goodell > Sent: Friday, March 04, 2011 10:21 PM > To: MPI-3 backwards compatability WG > Subject: Re: [Mpi3-bwcompat] MPI timer requests > > I have mixed feelings about the idea. When making your case to the Forum you'll need to explain why this can't or shouldn't be done with the existing generalized request framework, or alternatively Rob Latham's greq extensions. > > I see the convenience to the user, but I don't have a clear view of what the impact would be on implementations. I suspect it would be modest, but it does affect progress, so sometimes tricky things show up after deeper thought or some implementation work. > > -Dave > > On Mar 4, 2011, at 2:46 PM CST, Jeff Squyres wrote: > >> All -- >> >> Fab and I want to introduce the idea of "timer" MPI_Requests at the next Forum meeting. We have no ticket yet; we just want to introduce the idea to the Forum and see if it is liked. >> >> We made up a few slides about the concept -- before we throw it out to the rest of the Forum, would you (the bwcompat group) have a look and let us know your feedback? We know that this won't ultimately end up in the bwcompat group, but we don't know exactly where it will end up yet, and we wanted to get *some* feedback before presenting it to the greater Forum. >> >> https://svn.mpi-forum.org/trac/mpi-forum-web/wiki/MPI_Request_timers >> >> Thanks! >> >> -- >> 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 > -------------------------------------------------------------------------------------- > Intel GmbH > Dornacher Strasse 1 > 85622 Feldkirchen/Muenchen, Deutschland > 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 a.M. (BLZ 502 109 00) 600119052 > > > _______________________________________________ > Mpi3-bwcompat mailing list > Mpi3-bwcompat_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-bwcompat From alexander.supalov at [hidden] Mon Mar 7 10:17:16 2011 From: alexander.supalov at [hidden] (Supalov, Alexander) Date: Mon, 7 Mar 2011 16:17:16 +0000 Subject: [Mpi3-bwcompat] MPI timer requests In-Reply-To: Message-ID: <928CFBE8E7CB0040959E56B4EA41A77E011A63C18A@irsmsx504.ger.corp.intel.com> Can you give an example of the impact you're indicating? On an afterthought there may be an atomicity issue with the postconditioning. Shouldn't be a big problem though: if the message has matched, attaching a timeout to it will effectively be a no-op. Is your concern going in a comparable direction? Like, what happens if the message is matched just before the timeout fires, or vice versa? -----Original Message----- From: mpi3-bwcompat-bounces_at_[hidden] [mailto:mpi3-bwcompat-bounces_at_[hidden]] On Behalf Of Dave Goodell Sent: Monday, March 07, 2011 4:28 PM To: MPI-3 backwards compatability WG Subject: Re: [Mpi3-bwcompat] MPI timer requests What would be the impact of such a proposal on message matching and ordering semantics? I suspect this would make developing an efficient receive queue implementation even more difficult than it already is. -Dave On Mar 7, 2011, at 6:04 AM CST, Supalov, Alexander wrote: > Hi, > > The idea of separating the timeout functionality from the actual request(s) that are being waited upon looks interesting to me. One could probably want to timeout on a non-blocking spawn or connect/accept, etc., as well. Or on any non-blocking collective, for that matter. Would this proposal work there? > > As a possible alternative, I wonder whether one can make MPI_Request an inout argument for the MPI_TIMER_CREATE or the like, and possibly "precondition" or "postcondition" a request by adding a timeout to it. E.g., for "postconditioning": > > MPI_Isend(..., &req); > MPI_Timer_set(MPI_Wtime() + 5, &req); > ... > MPI_Wait(&req); > > Or, for "preconditioning": > > MPI_Timer_create(MPI_Wtime() + 5, &req); > MPI_Isend(..., &req); > ... > MPI_Wait(&req); > > The benefit is that there's direct association of the timeout with the request involved, and possibly more flexibility wrt individual, per-request timeouts. The drawback is the need to modify quite a few interfaces. What do you think? > > Best regards. > > Alexander > > -----Original Message----- > From: mpi3-bwcompat-bounces_at_[hidden] [mailto:mpi3-bwcompat-bounces_at_[hidden]] On Behalf Of Dave Goodell > Sent: Friday, March 04, 2011 10:21 PM > To: MPI-3 backwards compatability WG > Subject: Re: [Mpi3-bwcompat] MPI timer requests > > I have mixed feelings about the idea. When making your case to the Forum you'll need to explain why this can't or shouldn't be done with the existing generalized request framework, or alternatively Rob Latham's greq extensions. > > I see the convenience to the user, but I don't have a clear view of what the impact would be on implementations. I suspect it would be modest, but it does affect progress, so sometimes tricky things show up after deeper thought or some implementation work. > > -Dave > > On Mar 4, 2011, at 2:46 PM CST, Jeff Squyres wrote: > >> All -- >> >> Fab and I want to introduce the idea of "timer" MPI_Requests at the next Forum meeting. We have no ticket yet; we just want to introduce the idea to the Forum and see if it is liked. >> >> We made up a few slides about the concept -- before we throw it out to the rest of the Forum, would you (the bwcompat group) have a look and let us know your feedback? We know that this won't ultimately end up in the bwcompat group, but we don't know exactly where it will end up yet, and we wanted to get *some* feedback before presenting it to the greater Forum. >> >> https://svn.mpi-forum.org/trac/mpi-forum-web/wiki/MPI_Request_timers >> >> Thanks! >> >> -- >> 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 > -------------------------------------------------------------------------------------- > Intel GmbH > Dornacher Strasse 1 > 85622 Feldkirchen/Muenchen, Deutschland > 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 a.M. (BLZ 502 109 00) 600119052 > > > _______________________________________________ > 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 -------------------------------------------------------------------------------------- Intel GmbH Dornacher Strasse 1 85622 Feldkirchen/Muenchen, Deutschland 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 a.M. (BLZ 502 109 00) 600119052 From jsquyres at [hidden] Mon Mar 7 10:57:39 2011 From: jsquyres at [hidden] (Jeff Squyres) Date: Mon, 7 Mar 2011 11:57:39 -0500 Subject: [Mpi3-bwcompat] Fwd: [Mpi-forum] MPI_Count ticket In-Reply-To: <173BA203-C180-4379-837F-F5F722209D50@illinois.edu> Message-ID: Great -- this is very helpful. Thanks for the explanation! On Mar 5, 2011, at 10:20 AM, William Gropp wrote: > Jeff, > > I think you should go ahead with the reading. If the chapter authors don't find anything (other than trivial items), then you are good to go. If they do, well, the reading will be useful anyway. Review by the chapter authors should not be *required* before a *reading*. It is required before the first vote. > > Bill > > On Mar 4, 2011, at 4:46 PM, Jeff Squyres wrote: > >> Bwcompat WG -- >> >> I'm kinda thinking that this means we won't be able to have a first reading= >> by next meeting. Getting reviews by the chapter authors takes time... >> >> >> Begin forwarded message: >> >>> From: William Gropp >>> Date: March 4, 2011 5:41:07 PM EST >>> To: Main MPI Forum mailing list >>> Subject: Re: [Mpi-forum] MPI_Count ticket >>> Reply-To: Main MPI Forum mailing list >>> =20 >>> Changes to the other chapters require at least the chapter author's revie= >> w. They should do whatever they need to do to ensure that the changes make= >> sense (so that roughly means they should review the whole ticket). >>> =20 >>> It would be good if they're done by the first reading. If they find some= >> thing that needs to be changed, other than something that meets everyone's = >> definition of a trivial change, then you'd need to fix it and have a new fi= >> rst reading. >>> =20 >>> Bill >>> =20 >>> On Mar 4, 2011, at 1:05 PM, Jeff Squyres wrote: >>> =20 >>>> Forum -- >>>> =20 >>>> Sorry; I know we've discussed this a number of times, but they've all go= >> tten jumbled in my head and I don't remember what was decided. >>>> =20 >>>> We are bringing the MPI_Count ticket to the Forum for a first reading in= >> Chicago. Unfortunately, this ticket will span a bunch of chapters (5 or 6= >> , I think). >>>> =20 >>>> Do we have to get the individual sections of text reviewed by each chapt= >> er committee? And are they expected to review the *whole* ticket, and then= >> double check/review it in the context of *their specific chapter*? (I ask= >> because the text in one chapter doesn't really make sense without the rest= >> of the text in the ticket) >>>> =20 >>>> If we do need reviews from each chapter committee, do they need to be co= >> mplete by the first reading? >>>> =20 >>>> --=20 >>>> Jeff Squyres >>>> jsquyres_at_[hidden] >>>> For corporate legal information go to: >>>> http://www.cisco.com/web/about/doing_business/legal/cri/ >>>> =20 >>>> =20 >>>> _______________________________________________ >>>> mpi-forum mailing list >>>> mpi-forum_at_[hidden] >>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum >>> =20 >>> 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 >>> =20 >>> =20 >>> =20 >>> =20 >>> _______________________________________________ >>> mpi-forum mailing list >>> mpi-forum_at_[hidden] >>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum >> >> >> --=20 >> 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 > > 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 > > > > -- Jeff Squyres jsquyres_at_[hidden] For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/ From ftillier at [hidden] Mon Mar 7 11:26:18 2011 From: ftillier at [hidden] (Fab Tillier) Date: Mon, 7 Mar 2011 17:26:18 +0000 Subject: [Mpi3-bwcompat] MPI timer requests In-Reply-To: <928CFBE8E7CB0040959E56B4EA41A77E011A63BF4E@irsmsx504.ger.corp.intel.com> Message-ID: <91B583BE4B6FCD408F53D1B8F537E0921D737559@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> Hi Alexander, Your idea of post-conditioning a request wouldn't require any changes to existing APIs - I like it. The pre-conditioning however would make the request parameter inout to all functions that currently return one, which would break backward compatibility (users would need to initialize all input requests to MPI_REQUEST_NULL if they didn't have a pre-conditioned request). If you associate a timeout with individual requests, what happens to a request when it times out? Does it complete in error? Is it complete at all, or does the wait function simply return? One of the reasons for having separate timer requests rather than adding a timeout to existing requests is that the timeout condition remains completely local and doesn't indicate anything about outstanding I/O request. This leaves it up to the application to figure out how to handle the timeout. If an error, a send request could be cancelled, for example. Thanks, -Fab -----Original Message----- From: mpi3-bwcompat-bounces_at_[hidden] [mailto:mpi3-bwcompat-bounces_at_[hidden]] On Behalf Of Supalov, Alexander Sent: Monday, March 07, 2011 4:05 AM Hi, The idea of separating the timeout functionality from the actual request(s) that are being waited upon looks interesting to me. One could probably want to timeout on a non-blocking spawn or connect/accept, etc., as well. Or on any non-blocking collective, for that matter. Would this proposal work there? As a possible alternative, I wonder whether one can make MPI_Request an inout argument for the MPI_TIMER_CREATE or the like, and possibly "precondition" or "postcondition" a request by adding a timeout to it. E.g., for "postconditioning": MPI_Isend(..., &req); MPI_Timer_set(MPI_Wtime() + 5, &req); ... MPI_Wait(&req); Or, for "preconditioning": MPI_Timer_create(MPI_Wtime() + 5, &req); MPI_Isend(..., &req); ... MPI_Wait(&req); The benefit is that there's direct association of the timeout with the request involved, and possibly more flexibility wrt individual, per-request timeouts. The drawback is the need to modify quite a few interfaces. What do you think? Best regards. Alexander -----Original Message----- From: mpi3-bwcompat-bounces_at_[hidden] [mailto:mpi3-bwcompat-bounces_at_[hidden]] On Behalf Of Dave Goodell Sent: Friday, March 04, 2011 10:21 PM To: MPI-3 backwards compatability WG Subject: Re: [Mpi3-bwcompat] MPI timer requests I have mixed feelings about the idea. When making your case to the Forum you'll need to explain why this can't or shouldn't be done with the existing generalized request framework, or alternatively Rob Latham's greq extensions. I see the convenience to the user, but I don't have a clear view of what the impact would be on implementations. I suspect it would be modest, but it does affect progress, so sometimes tricky things show up after deeper thought or some implementation work. -Dave On Mar 4, 2011, at 2:46 PM CST, Jeff Squyres wrote: > All -- > > Fab and I want to introduce the idea of "timer" MPI_Requests at the next Forum meeting. We have no ticket yet; we just want to introduce the idea to the Forum and see if it is liked. > > We made up a few slides about the concept -- before we throw it out to the rest of the Forum, would you (the bwcompat group) have a look and let us know your feedback? We know that this won't ultimately end up in the bwcompat group, but we don't know exactly where it will end up yet, and we wanted to get *some* feedback before presenting it to the greater Forum. > > > https://svn.mpi-forum.org/trac/mpi-forum-web/wiki/MPI_Request_timers > > Thanks! > > -- > 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 -------------------------------------------------------------------------------------- Intel GmbH Dornacher Strasse 1 85622 Feldkirchen/Muenchen, Deutschland 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 a.M. (BLZ 502 109 00) 600119052 _______________________________________________ Mpi3-bwcompat mailing list Mpi3-bwcompat_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-bwcompat From goodell at [hidden] Mon Mar 7 11:35:55 2011 From: goodell at [hidden] (Dave Goodell) Date: Mon, 7 Mar 2011 11:35:55 -0600 Subject: [Mpi3-bwcompat] MPI timer requests In-Reply-To: <928CFBE8E7CB0040959E56B4EA41A77E011A63C18A@irsmsx504.ger.corp.intel.com> Message-ID: <8B3F7512-65CF-4D39-AAAB-3E06AB680B5C@mcs.anl.gov> What you are proposing amounts to a built-in version of "MPI_Cancel-after-timeout". So at the very least it has all of the downsides associated with cancel (esp. for send operations). It has the additional downside of forcing the MPI implementation to check all pending requests (that contain a timeout) for expiration. Other than my general dislike of message cancellation, I don't currently have a specific concern at this point, provided that the wording is sufficiently vague to permit timeout firing to be _very_ delayed. The multithreaded receive queue design that we sometimes use on Blue Gene would not permit this sort of cancellation in a timely fashion because it uses an additional, separate "fast post" queue in order to maximize message rate. Forcing timely timeouts would likely negate most of the performance benefit from such a design. Is there a good application use case for this functionality? Or is this just something amusing that is theoretically useful? -Dave On Mar 7, 2011, at 10:17 AM CST, Supalov, Alexander wrote: > Can you give an example of the impact you're indicating? On an afterthought there may be an atomicity issue with the postconditioning. Shouldn't be a big problem though: if the message has matched, attaching a timeout to it will effectively be a no-op. Is your concern going in a comparable direction? Like, what happens if the message is matched just before the timeout fires, or vice versa? > > -----Original Message----- > From: mpi3-bwcompat-bounces_at_[hidden] [mailto:mpi3-bwcompat-bounces_at_[hidden]] On Behalf Of Dave Goodell > Sent: Monday, March 07, 2011 4:28 PM > To: MPI-3 backwards compatability WG > Subject: Re: [Mpi3-bwcompat] MPI timer requests > > What would be the impact of such a proposal on message matching and ordering semantics? I suspect this would make developing an efficient receive queue implementation even more difficult than it already is. > > -Dave > > On Mar 7, 2011, at 6:04 AM CST, Supalov, Alexander wrote: > >> Hi, >> >> The idea of separating the timeout functionality from the actual request(s) that are being waited upon looks interesting to me. One could probably want to timeout on a non-blocking spawn or connect/accept, etc., as well. Or on any non-blocking collective, for that matter. Would this proposal work there? >> >> As a possible alternative, I wonder whether one can make MPI_Request an inout argument for the MPI_TIMER_CREATE or the like, and possibly "precondition" or "postcondition" a request by adding a timeout to it. E.g., for "postconditioning": >> >> MPI_Isend(..., &req); >> MPI_Timer_set(MPI_Wtime() + 5, &req); >> ... >> MPI_Wait(&req); >> >> Or, for "preconditioning": >> >> MPI_Timer_create(MPI_Wtime() + 5, &req); >> MPI_Isend(..., &req); >> ... >> MPI_Wait(&req); >> >> The benefit is that there's direct association of the timeout with the request involved, and possibly more flexibility wrt individual, per-request timeouts. The drawback is the need to modify quite a few interfaces. What do you think? >> >> Best regards. >> >> Alexander >> >> -----Original Message----- >> From: mpi3-bwcompat-bounces_at_[hidden] [mailto:mpi3-bwcompat-bounces_at_[hidden]] On Behalf Of Dave Goodell >> Sent: Friday, March 04, 2011 10:21 PM >> To: MPI-3 backwards compatability WG >> Subject: Re: [Mpi3-bwcompat] MPI timer requests >> >> I have mixed feelings about the idea. When making your case to the Forum you'll need to explain why this can't or shouldn't be done with the existing generalized request framework, or alternatively Rob Latham's greq extensions. >> >> I see the convenience to the user, but I don't have a clear view of what the impact would be on implementations. I suspect it would be modest, but it does affect progress, so sometimes tricky things show up after deeper thought or some implementation work. >> >> -Dave >> >> On Mar 4, 2011, at 2:46 PM CST, Jeff Squyres wrote: >> >>> All -- >>> >>> Fab and I want to introduce the idea of "timer" MPI_Requests at the next Forum meeting. We have no ticket yet; we just want to introduce the idea to the Forum and see if it is liked. >>> >>> We made up a few slides about the concept -- before we throw it out to the rest of the Forum, would you (the bwcompat group) have a look and let us know your feedback? We know that this won't ultimately end up in the bwcompat group, but we don't know exactly where it will end up yet, and we wanted to get *some* feedback before presenting it to the greater Forum. >>> >>> https://svn.mpi-forum.org/trac/mpi-forum-web/wiki/MPI_Request_timers >>> >>> Thanks! >>> >>> -- >>> 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 >> -------------------------------------------------------------------------------------- >> Intel GmbH >> Dornacher Strasse 1 >> 85622 Feldkirchen/Muenchen, Deutschland >> 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 a.M. (BLZ 502 109 00) 600119052 >> >> >> _______________________________________________ >> 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 > -------------------------------------------------------------------------------------- > Intel GmbH > Dornacher Strasse 1 > 85622 Feldkirchen/Muenchen, Deutschland > 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 a.M. (BLZ 502 109 00) 600119052 > > > _______________________________________________ > Mpi3-bwcompat mailing list > Mpi3-bwcompat_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-bwcompat From jsquyres at [hidden] Mon Mar 7 14:31:41 2011 From: jsquyres at [hidden] (Jeff Squyres) Date: Mon, 7 Mar 2011 15:31:41 -0500 Subject: [Mpi3-bwcompat] MPI timer requests In-Reply-To: <928CFBE8E7CB0040959E56B4EA41A77E011A63BF4E@irsmsx504.ger.corp.intel.com> Message-ID: <9AF98BCD-9217-4609-B519-B190FD3B9572@cisco.com> On Mar 7, 2011, at 7:04 AM, Supalov, Alexander wrote: > The idea of separating the timeout functionality from the actual request(s) that are being waited upon looks interesting to me. One could probably want to timeout on a non-blocking spawn or connect/accept, etc., as well. Or on any non-blocking collective, for that matter. Would this proposal work there? Yes, timers will work anywhere -- they're requests, like any other request. So you can use them with any MPI_WAIT* / MPI_TEST* functions. As I understand it, the FT group has some internal proposals about non-blocking spawn, connect, accept, etc. Our idea here was to minimally impact other, existing parts of MPI. A timer request is a standalone item; it can complete independent of any other request (e.g., a non-blocking p2p or collective communication, spawn, accept, connect, ..etc.). As Fab stated, completion of a timer intentionally has no other connotation about other incomplete actions. Dave's point about generalized requests is a good one, though -- I need to go think about that and convince myself that what we're talking about isn't syntactic sugar and/or why it's better to be in the MPI implementation. -- Jeff Squyres jsquyres_at_[hidden] For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/ From ftillier at [hidden] Mon Mar 7 14:49:05 2011 From: ftillier at [hidden] (Fab Tillier) Date: Mon, 7 Mar 2011 20:49:05 +0000 Subject: [Mpi3-bwcompat] MPI timer requests In-Reply-To: <9AF98BCD-9217-4609-B519-B190FD3B9572@cisco.com> Message-ID: <91B583BE4B6FCD408F53D1B8F537E0921D7392AE@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> Jeff Squyres wrote on Mon, 7 Mar 2011 at 12:31:41 > > Dave's point about generalized requests is a good one, though -- I need to go > think about that and convince myself that what we're talking about isn't > syntactic sugar and/or why it's better to be in the MPI implementation. In a MPI_THREAD_SERIALIZED implementation, you can't use call MPI_GREQUEST_COMPLETE if you're already calling MPI_WAITANY. Depending on generalized requests would require MPI_THREAD_MULTIPLE support for this functionality. Note that for some implementations, making MPI_GREQUEST_COMPLETE thread-safe could be trivial, but there's no MPI_THREAD_MOSTLY_SERIALIZED option so there's no standard way of noting that some things are thread safe while others are not - it's either all or nothing. -Fab From david.solt at [hidden] Mon Mar 7 15:12:28 2011 From: david.solt at [hidden] (Solt, David George) Date: Mon, 7 Mar 2011 21:12:28 +0000 Subject: [Mpi3-bwcompat] Plan for MPI_Count In-Reply-To: Message-ID: >> - Dave will send a final PDF to the bwcompat group to review early next week I attached the pdfs to the tickets 265 and 269. I have not reviewed them much myself yet. Perhaps we can do a quick review within the WG before we publicize them to chapter authors or any wider audience? Thanks, Dave From alexander.supalov at [hidden] Tue Mar 8 12:32:04 2011 From: alexander.supalov at [hidden] (Supalov, Alexander) Date: Tue, 8 Mar 2011 18:32:04 +0000 Subject: [Mpi3-bwcompat] MPI timer requests In-Reply-To: <91B583BE4B6FCD408F53D1B8F537E0921D737559@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> Message-ID: <928CFBE8E7CB0040959E56B4EA41A77E011A63C86C@irsmsx504.ger.corp.intel.com> Thanks. It looks like Dave got me: implied cancellation is not what looks practical. Better keep timeouts orthogonal, as you originally proposed. -----Original Message----- From: mpi3-bwcompat-bounces_at_[hidden] [mailto:mpi3-bwcompat-bounces_at_[hidden]] On Behalf Of Fab Tillier Sent: Monday, March 07, 2011 6:26 PM To: MPI-3 backwards compatability WG Subject: Re: [Mpi3-bwcompat] MPI timer requests Hi Alexander, Your idea of post-conditioning a request wouldn't require any changes to existing APIs - I like it. The pre-conditioning however would make the request parameter inout to all functions that currently return one, which would break backward compatibility (users would need to initialize all input requests to MPI_REQUEST_NULL if they didn't have a pre-conditioned request). If you associate a timeout with individual requests, what happens to a request when it times out? Does it complete in error? Is it complete at all, or does the wait function simply return? One of the reasons for having separate timer requests rather than adding a timeout to existing requests is that the timeout condition remains completely local and doesn't indicate anything about outstanding I/O request. This leaves it up to the application to figure out how to handle the timeout. If an error, a send request could be cancelled, for example. Thanks, -Fab -----Original Message----- From: mpi3-bwcompat-bounces_at_[hidden] [mailto:mpi3-bwcompat-bounces_at_[hidden]] On Behalf Of Supalov, Alexander Sent: Monday, March 07, 2011 4:05 AM Hi, The idea of separating the timeout functionality from the actual request(s) that are being waited upon looks interesting to me. One could probably want to timeout on a non-blocking spawn or connect/accept, etc., as well. Or on any non-blocking collective, for that matter. Would this proposal work there? As a possible alternative, I wonder whether one can make MPI_Request an inout argument for the MPI_TIMER_CREATE or the like, and possibly "precondition" or "postcondition" a request by adding a timeout to it. E.g., for "postconditioning": MPI_Isend(..., &req); MPI_Timer_set(MPI_Wtime() + 5, &req); ... MPI_Wait(&req); Or, for "preconditioning": MPI_Timer_create(MPI_Wtime() + 5, &req); MPI_Isend(..., &req); ... MPI_Wait(&req); The benefit is that there's direct association of the timeout with the request involved, and possibly more flexibility wrt individual, per-request timeouts. The drawback is the need to modify quite a few interfaces. What do you think? Best regards. Alexander -----Original Message----- From: mpi3-bwcompat-bounces_at_[hidden] [mailto:mpi3-bwcompat-bounces_at_[hidden]] On Behalf Of Dave Goodell Sent: Friday, March 04, 2011 10:21 PM To: MPI-3 backwards compatability WG Subject: Re: [Mpi3-bwcompat] MPI timer requests I have mixed feelings about the idea. When making your case to the Forum you'll need to explain why this can't or shouldn't be done with the existing generalized request framework, or alternatively Rob Latham's greq extensions. I see the convenience to the user, but I don't have a clear view of what the impact would be on implementations. I suspect it would be modest, but it does affect progress, so sometimes tricky things show up after deeper thought or some implementation work. -Dave On Mar 4, 2011, at 2:46 PM CST, Jeff Squyres wrote: > All -- > > Fab and I want to introduce the idea of "timer" MPI_Requests at the next Forum meeting. We have no ticket yet; we just want to introduce the idea to the Forum and see if it is liked. > > We made up a few slides about the concept -- before we throw it out to the rest of the Forum, would you (the bwcompat group) have a look and let us know your feedback? We know that this won't ultimately end up in the bwcompat group, but we don't know exactly where it will end up yet, and we wanted to get *some* feedback before presenting it to the greater Forum. > > > https://svn.mpi-forum.org/trac/mpi-forum-web/wiki/MPI_Request_timers > > Thanks! > > -- > 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 -------------------------------------------------------------------------------------- Intel GmbH Dornacher Strasse 1 85622 Feldkirchen/Muenchen, Deutschland 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 a.M. (BLZ 502 109 00) 600119052 _______________________________________________ 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 -------------------------------------------------------------------------------------- Intel GmbH Dornacher Strasse 1 85622 Feldkirchen/Muenchen, Deutschland 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 a.M. (BLZ 502 109 00) 600119052 From alexander.supalov at [hidden] Tue Mar 8 12:31:03 2011 From: alexander.supalov at [hidden] (Supalov, Alexander) Date: Tue, 8 Mar 2011 18:31:03 +0000 Subject: [Mpi3-bwcompat] MPI timer requests In-Reply-To: <8B3F7512-65CF-4D39-AAAB-3E06AB680B5C@mcs.anl.gov> Message-ID: <928CFBE8E7CB0040959E56B4EA41A77E011A63C86B@irsmsx504.ger.corp.intel.com> See your point, thanks. -----Original Message----- From: mpi3-bwcompat-bounces_at_[hidden] [mailto:mpi3-bwcompat-bounces_at_[hidden]] On Behalf Of Dave Goodell Sent: Monday, March 07, 2011 6:36 PM To: MPI-3 backwards compatability WG Subject: Re: [Mpi3-bwcompat] MPI timer requests What you are proposing amounts to a built-in version of "MPI_Cancel-after-timeout". So at the very least it has all of the downsides associated with cancel (esp. for send operations). It has the additional downside of forcing the MPI implementation to check all pending requests (that contain a timeout) for expiration. Other than my general dislike of message cancellation, I don't currently have a specific concern at this point, provided that the wording is sufficiently vague to permit timeout firing to be _very_ delayed. The multithreaded receive queue design that we sometimes use on Blue Gene would not permit this sort of cancellation in a timely fashion because it uses an additional, separate "fast post" queue in order to maximize message rate. Forcing timely timeouts would likely negate most of the performance benefit from such a design. Is there a good application use case for this functionality? Or is this just something amusing that is theoretically useful? -Dave On Mar 7, 2011, at 10:17 AM CST, Supalov, Alexander wrote: > Can you give an example of the impact you're indicating? On an afterthought there may be an atomicity issue with the postconditioning. Shouldn't be a big problem though: if the message has matched, attaching a timeout to it will effectively be a no-op. Is your concern going in a comparable direction? Like, what happens if the message is matched just before the timeout fires, or vice versa? > > -----Original Message----- > From: mpi3-bwcompat-bounces_at_[hidden] [mailto:mpi3-bwcompat-bounces_at_[hidden]] On Behalf Of Dave Goodell > Sent: Monday, March 07, 2011 4:28 PM > To: MPI-3 backwards compatability WG > Subject: Re: [Mpi3-bwcompat] MPI timer requests > > What would be the impact of such a proposal on message matching and ordering semantics? I suspect this would make developing an efficient receive queue implementation even more difficult than it already is. > > -Dave > > On Mar 7, 2011, at 6:04 AM CST, Supalov, Alexander wrote: > >> Hi, >> >> The idea of separating the timeout functionality from the actual request(s) that are being waited upon looks interesting to me. One could probably want to timeout on a non-blocking spawn or connect/accept, etc., as well. Or on any non-blocking collective, for that matter. Would this proposal work there? >> >> As a possible alternative, I wonder whether one can make MPI_Request an inout argument for the MPI_TIMER_CREATE or the like, and possibly "precondition" or "postcondition" a request by adding a timeout to it. E.g., for "postconditioning": >> >> MPI_Isend(..., &req); >> MPI_Timer_set(MPI_Wtime() + 5, &req); >> ... >> MPI_Wait(&req); >> >> Or, for "preconditioning": >> >> MPI_Timer_create(MPI_Wtime() + 5, &req); >> MPI_Isend(..., &req); >> ... >> MPI_Wait(&req); >> >> The benefit is that there's direct association of the timeout with the request involved, and possibly more flexibility wrt individual, per-request timeouts. The drawback is the need to modify quite a few interfaces. What do you think? >> >> Best regards. >> >> Alexander >> >> -----Original Message----- >> From: mpi3-bwcompat-bounces_at_[hidden] [mailto:mpi3-bwcompat-bounces_at_[hidden]] On Behalf Of Dave Goodell >> Sent: Friday, March 04, 2011 10:21 PM >> To: MPI-3 backwards compatability WG >> Subject: Re: [Mpi3-bwcompat] MPI timer requests >> >> I have mixed feelings about the idea. When making your case to the Forum you'll need to explain why this can't or shouldn't be done with the existing generalized request framework, or alternatively Rob Latham's greq extensions. >> >> I see the convenience to the user, but I don't have a clear view of what the impact would be on implementations. I suspect it would be modest, but it does affect progress, so sometimes tricky things show up after deeper thought or some implementation work. >> >> -Dave >> >> On Mar 4, 2011, at 2:46 PM CST, Jeff Squyres wrote: >> >>> All -- >>> >>> Fab and I want to introduce the idea of "timer" MPI_Requests at the next Forum meeting. We have no ticket yet; we just want to introduce the idea to the Forum and see if it is liked. >>> >>> We made up a few slides about the concept -- before we throw it out to the rest of the Forum, would you (the bwcompat group) have a look and let us know your feedback? We know that this won't ultimately end up in the bwcompat group, but we don't know exactly where it will end up yet, and we wanted to get *some* feedback before presenting it to the greater Forum. >>> >>> https://svn.mpi-forum.org/trac/mpi-forum-web/wiki/MPI_Request_timers >>> >>> Thanks! >>> >>> -- >>> 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 >> -------------------------------------------------------------------------------------- >> Intel GmbH >> Dornacher Strasse 1 >> 85622 Feldkirchen/Muenchen, Deutschland >> 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 a.M. (BLZ 502 109 00) 600119052 >> >> >> _______________________________________________ >> 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 > -------------------------------------------------------------------------------------- > Intel GmbH > Dornacher Strasse 1 > 85622 Feldkirchen/Muenchen, Deutschland > 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 a.M. (BLZ 502 109 00) 600119052 > > > _______________________________________________ > 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 -------------------------------------------------------------------------------------- Intel GmbH Dornacher Strasse 1 85622 Feldkirchen/Muenchen, Deutschland 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 a.M. (BLZ 502 109 00) 600119052 From jsquyres at [hidden] Tue Mar 8 13:06:47 2011 From: jsquyres at [hidden] (Jeff Squyres) Date: Tue, 8 Mar 2011 14:06:47 -0500 Subject: [Mpi3-bwcompat] MPI timer requests In-Reply-To: <91B583BE4B6FCD408F53D1B8F537E0921D7392AE@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> Message-ID: I had to go back and read about generalized requests to remind myself how they worked... But now I agree with Fab. They won't work as timers except in THREAD_MULTIPLE + multiple threads scenarios. So I think that the timers-as-requests idea still stands... On Mar 7, 2011, at 3:49 PM, Fab Tillier wrote: > Jeff Squyres wrote on Mon, 7 Mar 2011 at 12:31:41 >> >> Dave's point about generalized requests is a good one, though -- I need to go >> think about that and convince myself that what we're talking about isn't >> syntactic sugar and/or why it's better to be in the MPI implementation. > > In a MPI_THREAD_SERIALIZED implementation, you can't use call MPI_GREQUEST_COMPLETE if you're already calling MPI_WAITANY. Depending on generalized requests would require MPI_THREAD_MULTIPLE support for this functionality. > > Note that for some implementations, making MPI_GREQUEST_COMPLETE thread-safe could be trivial, but there's no MPI_THREAD_MOSTLY_SERIALIZED option so there's no standard way of noting that some things are thread safe while others are not - it's either all or nothing. > > -Fab > > _______________________________________________ > 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 goodell at [hidden] Tue Mar 8 13:09:18 2011 From: goodell at [hidden] (Dave Goodell) Date: Tue, 8 Mar 2011 13:09:18 -0600 Subject: [Mpi3-bwcompat] MPI timer requests In-Reply-To: Message-ID: <211C9DB5-4FCD-44F9-9390-3157842C88A2@mcs.anl.gov> Sure, that sounds like a reasonable justification. I just wanted to make sure that you actually had that before you went forward to the Forum, since that's one of the things that I always ask when someone brings a new proposal to the whole group and it wasn't present on your original slides. -Dave On Mar 8, 2011, at 1:06 PM CST, Jeff Squyres wrote: > I had to go back and read about generalized requests to remind myself how they worked... > > But now I agree with Fab. They won't work as timers except in THREAD_MULTIPLE + multiple threads scenarios. > > So I think that the timers-as-requests idea still stands... > > > On Mar 7, 2011, at 3:49 PM, Fab Tillier wrote: > >> Jeff Squyres wrote on Mon, 7 Mar 2011 at 12:31:41 >>> >>> Dave's point about generalized requests is a good one, though -- I need to go >>> think about that and convince myself that what we're talking about isn't >>> syntactic sugar and/or why it's better to be in the MPI implementation. >> >> In a MPI_THREAD_SERIALIZED implementation, you can't use call MPI_GREQUEST_COMPLETE if you're already calling MPI_WAITANY. Depending on generalized requests would require MPI_THREAD_MULTIPLE support for this functionality. >> >> Note that for some implementations, making MPI_GREQUEST_COMPLETE thread-safe could be trivial, but there's no MPI_THREAD_MOSTLY_SERIALIZED option so there's no standard way of noting that some things are thread safe while others are not - it's either all or nothing. >> >> -Fab >> >> _______________________________________________ >> 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/ > > > _______________________________________________ > Mpi3-bwcompat mailing list > Mpi3-bwcompat_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-bwcompat From jsquyres at [hidden] Tue Mar 8 13:23:06 2011 From: jsquyres at [hidden] (Jeff Squyres) Date: Tue, 8 Mar 2011 14:23:06 -0500 Subject: [Mpi3-bwcompat] MPI timer requests In-Reply-To: <211C9DB5-4FCD-44F9-9390-3157842C88A2@mcs.anl.gov> Message-ID: <244A49AE-9AB6-4031-8576-9135B6B2482B@cisco.com> Yep -- I added it to my slides already. Thanks! On Mar 8, 2011, at 2:09 PM, Dave Goodell wrote: > Sure, that sounds like a reasonable justification. I just wanted to make sure that you actually had that before you went forward to the Forum, since that's one of the things that I always ask when someone brings a new proposal to the whole group and it wasn't present on your original slides. > > -Dave > > On Mar 8, 2011, at 1:06 PM CST, Jeff Squyres wrote: > >> I had to go back and read about generalized requests to remind myself how they worked... >> >> But now I agree with Fab. They won't work as timers except in THREAD_MULTIPLE + multiple threads scenarios. >> >> So I think that the timers-as-requests idea still stands... >> >> >> On Mar 7, 2011, at 3:49 PM, Fab Tillier wrote: >> >>> Jeff Squyres wrote on Mon, 7 Mar 2011 at 12:31:41 >>>> >>>> Dave's point about generalized requests is a good one, though -- I need to go >>>> think about that and convince myself that what we're talking about isn't >>>> syntactic sugar and/or why it's better to be in the MPI implementation. >>> >>> In a MPI_THREAD_SERIALIZED implementation, you can't use call MPI_GREQUEST_COMPLETE if you're already calling MPI_WAITANY. Depending on generalized requests would require MPI_THREAD_MULTIPLE support for this functionality. >>> >>> Note that for some implementations, making MPI_GREQUEST_COMPLETE thread-safe could be trivial, but there's no MPI_THREAD_MOSTLY_SERIALIZED option so there's no standard way of noting that some things are thread safe while others are not - it's either all or nothing. >>> >>> -Fab >>> >>> _______________________________________________ >>> 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/ >> >> >> _______________________________________________ >> 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 thakur at [hidden] Tue Mar 8 16:31:58 2011 From: thakur at [hidden] (Rajeev Thakur) Date: Tue, 8 Mar 2011 16:31:58 -0600 Subject: [Mpi3-bwcompat] MPI timer requests In-Reply-To: <211C9DB5-4FCD-44F9-9390-3157842C88A2@mcs.anl.gov> Message-ID: Generalized requests could still be used in single threaded mode with signals (SIGALRM) I think. Rajeev On Mar 8, 2011, at 1:09 PM, Dave Goodell wrote: > Sure, that sounds like a reasonable justification. I just wanted to make sure that you actually had that before you went forward to the Forum, since that's one of the things that I always ask when someone brings a new proposal to the whole group and it wasn't present on your original slides. > > -Dave > > On Mar 8, 2011, at 1:06 PM CST, Jeff Squyres wrote: > >> I had to go back and read about generalized requests to remind myself how they worked... >> >> But now I agree with Fab. They won't work as timers except in THREAD_MULTIPLE + multiple threads scenarios. >> >> So I think that the timers-as-requests idea still stands... >> >> >> On Mar 7, 2011, at 3:49 PM, Fab Tillier wrote: >> >>> Jeff Squyres wrote on Mon, 7 Mar 2011 at 12:31:41 >>>> >>>> Dave's point about generalized requests is a good one, though -- I need to go >>>> think about that and convince myself that what we're talking about isn't >>>> syntactic sugar and/or why it's better to be in the MPI implementation. >>> >>> In a MPI_THREAD_SERIALIZED implementation, you can't use call MPI_GREQUEST_COMPLETE if you're already calling MPI_WAITANY. Depending on generalized requests would require MPI_THREAD_MULTIPLE support for this functionality. >>> >>> Note that for some implementations, making MPI_GREQUEST_COMPLETE thread-safe could be trivial, but there's no MPI_THREAD_MOSTLY_SERIALIZED option so there's no standard way of noting that some things are thread safe while others are not - it's either all or nothing. >>> >>> -Fab >>> >>> _______________________________________________ >>> 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/ >> >> >> _______________________________________________ >> 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] Tue Mar 8 16:56:49 2011 From: ftillier at [hidden] (Fab Tillier) Date: Tue, 8 Mar 2011 22:56:49 +0000 Subject: [Mpi3-bwcompat] MPI timer requests In-Reply-To: Message-ID: <91B583BE4B6FCD408F53D1B8F537E0921D73BFA2@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> Hi Rajeev, In your example, what thread calls MPI_GREQUEST_COMPLETE? What happens to the thread that is blocked in MPI_WAITANY when the signal comes in? Thanks, -Fab Rajeev Thakur wrote on Tue, 8 Mar 2011 at 14:31:58 > Generalized requests could still be used in single threaded mode with > signals (SIGALRM) I think. > > Rajeev > > > On Mar 8, 2011, at 1:09 PM, Dave Goodell wrote: > >> Sure, that sounds like a reasonable justification. I just wanted to make > sure that you actually had that before you went forward to the Forum, since > that's one of the things that I always ask when someone brings a new > proposal to the whole group and it wasn't present on your original slides. >> >> -Dave >> >> On Mar 8, 2011, at 1:06 PM CST, Jeff Squyres wrote: >> >>> I had to go back and read about generalized requests to remind myself >>> how they worked... >>> >>> But now I agree with Fab. They won't work as timers except in >>> THREAD_MULTIPLE + multiple threads scenarios. >>> >>> So I think that the timers-as-requests idea still stands... >>> >>> >>> On Mar 7, 2011, at 3:49 PM, Fab Tillier wrote: >>> >>>> Jeff Squyres wrote on Mon, 7 Mar 2011 at 12:31:41 >>>>> >>>>> Dave's point about generalized requests is a good one, though -- I >>>>> need to go think about that and convince myself that what we're >>>>> talking about isn't syntactic sugar and/or why it's better to be in >>>>> the MPI implementation. >>>> >>>> In a MPI_THREAD_SERIALIZED implementation, you can't use call > MPI_GREQUEST_COMPLETE if you're already calling MPI_WAITANY. > Depending on generalized requests would require MPI_THREAD_MULTIPLE > support for this functionality. >>>> >>>> Note that for some implementations, making > MPI_GREQUEST_COMPLETE thread-safe could be trivial, but there's no > MPI_THREAD_MOSTLY_SERIALIZED option so there's no standard way of > noting that some things are thread safe while others are not - it's either all > or nothing. >>>> >>>> -Fab >>>> >>>> _______________________________________________ >>>> 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/ >>> >>> >>> _______________________________________________ >>> 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 goodell at [hidden] Tue Mar 8 17:08:00 2011 From: goodell at [hidden] (Dave Goodell) Date: Tue, 8 Mar 2011 17:08:00 -0600 Subject: [Mpi3-bwcompat] MPI timer requests In-Reply-To: <91B583BE4B6FCD408F53D1B8F537E0921D73BFA2@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> Message-ID: <1C01EF96-AACB-4330-8D13-24925F40D3D8@mcs.anl.gov> On Mar 8, 2011, at 4:56 PM CST, Fab Tillier wrote: > In your example, what thread calls MPI_GREQUEST_COMPLETE? What happens to the thread that is blocked in MPI_WAITANY when the signal comes in? It would be the same thread that is blocked in MPI_WAITANY, but it has just been interrupted by the signal. It would require a signal-safe MPI library that permitted MPI calls within signal handlers, which is recommended by the standard but not strictly required. See MPI-2.2, page 24, lines 24-34: ----8<---- MPI does not specify the interaction of processes with signals and does not require that MPI be signal safe. The implementation may reserve some signals for its own use. It is required that the implementation document which signals it uses, and it is strongly recommended that it not use SIGALRM, SIGFPE, or SIGIO. Implementations may also prohibit the use of MPI calls from within signal handlers. In multithreaded environments, users can avoid conflicts between signals and the MPI library by catching signals only on threads that do not execute MPI calls. High quality single-threaded implementations will be signal safe: an MPI call suspended by a signal will resume and complete normally after the signal is handled. ----8<---- -Dave > Rajeev Thakur wrote on Tue, 8 Mar 2011 at 14:31:58 > >> Generalized requests could still be used in single threaded mode with >> signals (SIGALRM) I think. From jsquyres at [hidden] Wed Mar 9 10:47:13 2011 From: jsquyres at [hidden] (Jeff Squyres) Date: Wed, 9 Mar 2011 11:47:13 -0500 Subject: [Mpi3-bwcompat] Plan for MPI_Count In-Reply-To: Message-ID: <7E8DC1E5-C819-405A-8A27-1CAF3196A46A@cisco.com> It looks like there are *many* pages missing from both of those PDFs -- the page numbering is far from consecutive. Some of the pages that remain contain no changes, so I can't figure out what the rationale was for removing some pages and not others...? On Mar 7, 2011, at 4:12 PM, Solt, David George wrote: >>> - Dave will send a final PDF to the bwcompat group to review early next week > > I attached the pdfs to the tickets 265 and 269. I have not reviewed them much myself yet. Perhaps we can do a quick review within the WG before we publicize them to chapter authors or any wider audience? > > Thanks, > 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/ From david.solt at [hidden] Wed Mar 9 10:50:37 2011 From: david.solt at [hidden] (Solt, David George) Date: Wed, 9 Mar 2011 16:50:37 +0000 Subject: [Mpi3-bwcompat] Plan for MPI_Count In-Reply-To: <7E8DC1E5-C819-405A-8A27-1CAF3196A46A@cisco.com> Message-ID: It contains (or I think it does) the full content of any chapter that was changed. Do you want a copy with just the pages that changed? Dave -----Original Message----- From: mpi3-bwcompat-bounces_at_[hidden] [mailto:mpi3-bwcompat-bounces_at_[hidden]] On Behalf Of Jeff Squyres Sent: Wednesday, March 09, 2011 10:47 AM To: MPI-3 backwards compatability WG Subject: Re: [Mpi3-bwcompat] Plan for MPI_Count It looks like there are *many* pages missing from both of those PDFs -- the page numbering is far from consecutive. Some of the pages that remain contain no changes, so I can't figure out what the rationale was for removing some pages and not others...? On Mar 7, 2011, at 4:12 PM, Solt, David George wrote: >>> - Dave will send a final PDF to the bwcompat group to review early next week > > I attached the pdfs to the tickets 265 and 269. I have not reviewed them much myself yet. Perhaps we can do a quick review within the WG before we publicize them to chapter authors or any wider audience? > > Thanks, > 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/ _______________________________________________ Mpi3-bwcompat mailing list Mpi3-bwcompat_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-bwcompat From jsquyres at [hidden] Wed Mar 9 10:52:42 2011 From: jsquyres at [hidden] (Jeff Squyres) Date: Wed, 9 Mar 2011 11:52:42 -0500 Subject: [Mpi3-bwcompat] Plan for MPI_Count In-Reply-To: Message-ID: <3E6944F2-8ADD-4C3B-9C71-2AA829363E0A@cisco.com> Those PDFs do not contain the full chapters -- download them and have a look. On Mar 9, 2011, at 11:50 AM, Solt, David George wrote: > It contains (or I think it does) the full content of any chapter that was changed. Do you want a copy with just the pages that changed? > Dave > > -----Original Message----- > From: mpi3-bwcompat-bounces_at_[hidden] [mailto:mpi3-bwcompat-bounces_at_[hidden]] On Behalf Of Jeff Squyres > Sent: Wednesday, March 09, 2011 10:47 AM > To: MPI-3 backwards compatability WG > Subject: Re: [Mpi3-bwcompat] Plan for MPI_Count > > It looks like there are *many* pages missing from both of those PDFs -- the page numbering is far from consecutive. Some of the pages that remain contain no changes, so I can't figure out what the rationale was for removing some pages and not others...? > > > > On Mar 7, 2011, at 4:12 PM, Solt, David George wrote: > >>>> - Dave will send a final PDF to the bwcompat group to review early next week >> >> I attached the pdfs to the tickets 265 and 269. I have not reviewed them much myself yet. Perhaps we can do a quick review within the WG before we publicize them to chapter authors or any wider audience? >> >> Thanks, >> 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/ > > > _______________________________________________ > 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 david.solt at [hidden] Wed Mar 9 11:24:56 2011 From: david.solt at [hidden] (Solt, David George) Date: Wed, 9 Mar 2011 17:24:56 +0000 Subject: [Mpi3-bwcompat] Plan for MPI_Count In-Reply-To: <3E6944F2-8ADD-4C3B-9C71-2AA829363E0A@cisco.com> Message-ID: I see. I uploaded a new copy. Note to self... In adobe reader, selecting the chapters you want and using right-click "print-pages" does print pages, but not a useful set of pages. Thanks, Dave -----Original Message----- From: mpi3-bwcompat-bounces_at_[hidden] [mailto:mpi3-bwcompat-bounces_at_[hidden]] On Behalf Of Jeff Squyres Sent: Wednesday, March 09, 2011 10:53 AM To: MPI-3 backwards compatability WG Subject: Re: [Mpi3-bwcompat] Plan for MPI_Count Those PDFs do not contain the full chapters -- download them and have a look. On Mar 9, 2011, at 11:50 AM, Solt, David George wrote: > It contains (or I think it does) the full content of any chapter that was changed. Do you want a copy with just the pages that changed? > Dave > > -----Original Message----- > From: mpi3-bwcompat-bounces_at_[hidden] [mailto:mpi3-bwcompat-bounces_at_[hidden]] On Behalf Of Jeff Squyres > Sent: Wednesday, March 09, 2011 10:47 AM > To: MPI-3 backwards compatability WG > Subject: Re: [Mpi3-bwcompat] Plan for MPI_Count > > It looks like there are *many* pages missing from both of those PDFs -- the page numbering is far from consecutive. Some of the pages that remain contain no changes, so I can't figure out what the rationale was for removing some pages and not others...? > > > > On Mar 7, 2011, at 4:12 PM, Solt, David George wrote: > >>>> - Dave will send a final PDF to the bwcompat group to review early next week >> >> I attached the pdfs to the tickets 265 and 269. I have not reviewed them much myself yet. Perhaps we can do a quick review within the WG before we publicize them to chapter authors or any wider audience? >> >> Thanks, >> 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/ > > > _______________________________________________ > 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/ _______________________________________________ Mpi3-bwcompat mailing list Mpi3-bwcompat_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-bwcompat From david.solt at [hidden] Fri Mar 11 17:06:25 2011 From: david.solt at [hidden] (Solt, David George) Date: Fri, 11 Mar 2011 23:06:25 +0000 Subject: [Mpi3-bwcompat] MPI Backward Compatibility Working Group In-Reply-To: <5B911F153B503347AA9732A90CA1BE813126EA047C@GVW0547EXC.americas.hpqcorp.net> Message-ID: During our meeting today we decided that MPI_Count should be at least as large as an MPI_Aint. We already had the restriction that it had to be as large as a C/Fortran integer. We want both restrictions (they cannot be combined because there is no guarantee that MPI_Aint > integer). I'll throw this out as a starting point for discussion: 2.5.8 Last sentence change to: The size of the MPI_Count type is determined by the MPI implementation with the restriction that it must be minimally capable of encoding a C int and Fortran INTEGER and any value that may be stored in an MPI_Aint type. Rational thingy: MPI_Count is used to communicate both the number of elements in a datatype and the bounds of a datatype. The number of elements in a datatype is specified at creation time using a C int or Fortran INTEGER. The bounds may be specified using an MPI_Aint. So, I was especially brief here. I did not want to get into the "new" routines vs. "old routines", but if you attempt to go into more depth than what I said, you will inevitably end up going down that path. I can think of a thousand ways not to say it, but its hard to come up with a good way. Dave * -------------- next part -------------- An HTML attachment was scrubbed... URL: From thakur at [hidden] Fri Mar 11 22:05:34 2011 From: thakur at [hidden] (Rajeev Thakur) Date: Fri, 11 Mar 2011 22:05:34 -0600 Subject: [Mpi3-bwcompat] MPI Backward Compatibility Working Group In-Reply-To: Message-ID: What was the motivation for the new MPI_Type_get_extent_x and MPI_Type_get_true_extent_x functions? If we say MPI_Count should be at least as large as MPI_Aint, why can't we just use MPI_Aint instead? The data buffer can't be larger than Aint size. I know that for I/O MPI_Offset can be larger than Aint, but this proposal does not solve the I/O problem as far as I know. https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/265 Rajeev On Mar 11, 2011, at 5:06 PM, Solt, David George wrote: > During our meeting today we decided that MPI_Count should be at least as large as an MPI_Aint. We already had the restriction that it had to be as large as a C/Fortran integer. We want both restrictions (they cannot be combined because there is no guarantee that MPI_Aint > integer). > > I’ll throw this out as a starting point for discussion: > > > > > 2.5.8 Last sentence change to: > > The size of the MPI_Count type is determined by the MPI implementation > with the restriction that it must be minimally capable of encoding a C int and Fortran INTEGER > and any value that may be stored in an MPI_Aint type. > > Rational thingy: > > MPI_Count is used to communicate both the number of elements in a datatype and the bounds of a datatype. > The number of elements in a datatype is specified at creation time using a C int or Fortran INTEGER. The bounds > may be specified using an MPI_Aint. > > > So, I was especially brief here. I did not want to get into the “new” routines vs. “old routines”, but if you attempt to go into more depth than what I said, you will inevitably end up going down that path. I can think of a thousand ways not to say it, but its hard to come up with a good way. > Dave > > _______________________________________________ > Mpi3-bwcompat mailing list > Mpi3-bwcompat_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-bwcompat From ftillier at [hidden] Fri Mar 11 23:07:44 2011 From: ftillier at [hidden] (Fab Tillier) Date: Sat, 12 Mar 2011 05:07:44 +0000 Subject: [Mpi3-bwcompat] MPI Backward Compatibility Working Group In-Reply-To: Message-ID: <91B583BE4B6FCD408F53D1B8F537E0921D7448C8@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> Hi Rajeev, A data buffer can't be larger than MPI_Aint in memory, but an MPI Datatype can be larger than what can fit in memory, and thus larger than MPI_Aint. MPI_Count allows such large datatypes to be represented and used in MPI, even if they can't be held in memory all at once. This proposal is intended to (minimally) solve the I/O problem, not just large network transfers. Does that make sense? -Fab -----Original Message----- From: mpi3-bwcompat-bounces_at_[hidden] [mailto:mpi3-bwcompat-bounces_at_[hidden]] On Behalf Of Rajeev Thakur Sent: Friday, March 11, 2011 8:06 PM To: MPI-3 backwards compatability WG Subject: Re: [Mpi3-bwcompat] MPI Backward Compatibility Working Group What was the motivation for the new MPI_Type_get_extent_x and MPI_Type_get_true_extent_x functions? If we say MPI_Count should be at least as large as MPI_Aint, why can't we just use MPI_Aint instead? The data buffer can't be larger than Aint size. I know that for I/O MPI_Offset can be larger than Aint, but this proposal does not solve the I/O problem as far as I know. https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/265 Rajeev On Mar 11, 2011, at 5:06 PM, Solt, David George wrote: > During our meeting today we decided that MPI_Count should be at least as large as an MPI_Aint. We already had the restriction that it had to be as large as a C/Fortran integer. We want both restrictions (they cannot be combined because there is no guarantee that MPI_Aint > integer). > > I'll throw this out as a starting point for discussion: > > > > > 2.5.8 Last sentence change to: > > The size of the MPI_Count type is determined by the MPI implementation > with the restriction that it must be minimally capable of encoding a C > int and Fortran INTEGER and any value that may be stored in an MPI_Aint type. > > Rational thingy: > > MPI_Count is used to communicate both the number of elements in a datatype and the bounds of a datatype. > The number of elements in a datatype is specified at creation time using a C int or Fortran INTEGER. The bounds > may be specified using an MPI_Aint. > > > So, I was especially brief here. I did not want to get into the "new" routines vs. "old routines", but if you attempt to go into more depth than what I said, you will inevitably end up going down that path. I can think of a thousand ways not to say it, but its hard to come up with a good way. > 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 From thakur at [hidden] Fri Mar 11 23:20:46 2011 From: thakur at [hidden] (Rajeev Thakur) Date: Fri, 11 Mar 2011 23:20:46 -0600 Subject: [Mpi3-bwcompat] MPI Backward Compatibility Working Group In-Reply-To: <91B583BE4B6FCD408F53D1B8F537E0921D7448C8@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> Message-ID: <47805831-BBFE-444F-A7E2-5A0B11A0482A@mcs.anl.gov> Could we say that MPI_Count should be the larger of MPI_Aint and MPI_Offset? (Anything bigger than that is not really useful.) That might help the I/O problem better. Rajeev On Mar 11, 2011, at 11:07 PM, Fab Tillier wrote: > Hi Rajeev, > > A data buffer can't be larger than MPI_Aint in memory, but an MPI Datatype can be larger than what can fit in memory, and thus larger than MPI_Aint. MPI_Count allows such large datatypes to be represented and used in MPI, even if they can't be held in memory all at once. > > This proposal is intended to (minimally) solve the I/O problem, not just large network transfers. > > Does that make sense? > -Fab > > -----Original Message----- > From: mpi3-bwcompat-bounces_at_[hidden] [mailto:mpi3-bwcompat-bounces_at_[hidden]] On Behalf Of Rajeev Thakur > Sent: Friday, March 11, 2011 8:06 PM > To: MPI-3 backwards compatability WG > Subject: Re: [Mpi3-bwcompat] MPI Backward Compatibility Working Group > > What was the motivation for the new MPI_Type_get_extent_x and MPI_Type_get_true_extent_x functions? > > If we say MPI_Count should be at least as large as MPI_Aint, why can't we just use MPI_Aint instead? The data buffer can't be larger than Aint size. I know that for I/O MPI_Offset can be larger than Aint, but this proposal does not solve the I/O problem as far as I know. > > https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/265 > > Rajeev > > > > On Mar 11, 2011, at 5:06 PM, Solt, David George wrote: > >> During our meeting today we decided that MPI_Count should be at least as large as an MPI_Aint. We already had the restriction that it had to be as large as a C/Fortran integer. We want both restrictions (they cannot be combined because there is no guarantee that MPI_Aint > integer). >> >> I'll throw this out as a starting point for discussion: >> >> >> >> >> 2.5.8 Last sentence change to: >> >> The size of the MPI_Count type is determined by the MPI implementation >> with the restriction that it must be minimally capable of encoding a C >> int and Fortran INTEGER and any value that may be stored in an MPI_Aint type. >> >> Rational thingy: >> >> MPI_Count is used to communicate both the number of elements in a datatype and the bounds of a datatype. >> The number of elements in a datatype is specified at creation time using a C int or Fortran INTEGER. The bounds >> may be specified using an MPI_Aint. >> >> >> So, I was especially brief here. I did not want to get into the "new" routines vs. "old routines", but if you attempt to go into more depth than what I said, you will inevitably end up going down that path. I can think of a thousand ways not to say it, but its hard to come up with a good way. >> 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 > > > _______________________________________________ > Mpi3-bwcompat mailing list > Mpi3-bwcompat_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-bwcompat From david.solt at [hidden] Sun Mar 13 00:19:34 2011 From: david.solt at [hidden] (Solt, David George) Date: Sun, 13 Mar 2011 06:19:34 +0000 Subject: [Mpi3-bwcompat] MPI Backward Compatibility Working Group In-Reply-To: <47805831-BBFE-444F-A7E2-5A0B11A0482A@mcs.anl.gov> Message-ID: I am on vacation this week, so I need to finish up my involvement as I can't say for sure if I will be on e-mail or not during the week. I checked in the changes I made here: https://svn.mpi-forum.org/svn/mpi-forum-docs/trunk/working-groups/mpi-3/bw-compat I uploaded new versions of the pdf's to both tickets with the changes we discussed on Friday. For the issue we are discussing here, I added "and any value that may be stored in an MPI_Aint type." but did not add the rationale. Thanks, Dave -----Original Message----- From: mpi3-bwcompat-bounces_at_[hidden] [mailto:mpi3-bwcompat-bounces_at_[hidden]] On Behalf Of Rajeev Thakur Sent: Friday, March 11, 2011 11:21 PM To: MPI-3 backwards compatability WG Subject: Re: [Mpi3-bwcompat] MPI Backward Compatibility Working Group Could we say that MPI_Count should be the larger of MPI_Aint and MPI_Offset? (Anything bigger than that is not really useful.) That might help the I/O problem better. Rajeev On Mar 11, 2011, at 11:07 PM, Fab Tillier wrote: > Hi Rajeev, > > A data buffer can't be larger than MPI_Aint in memory, but an MPI Datatype can be larger than what can fit in memory, and thus larger than MPI_Aint. MPI_Count allows such large datatypes to be represented and used in MPI, even if they can't be held in memory all at once. > > This proposal is intended to (minimally) solve the I/O problem, not just large network transfers. > > Does that make sense? > -Fab > > -----Original Message----- > From: mpi3-bwcompat-bounces_at_[hidden] [mailto:mpi3-bwcompat-bounces_at_[hidden]] On Behalf Of Rajeev Thakur > Sent: Friday, March 11, 2011 8:06 PM > To: MPI-3 backwards compatability WG > Subject: Re: [Mpi3-bwcompat] MPI Backward Compatibility Working Group > > What was the motivation for the new MPI_Type_get_extent_x and MPI_Type_get_true_extent_x functions? > > If we say MPI_Count should be at least as large as MPI_Aint, why can't we just use MPI_Aint instead? The data buffer can't be larger than Aint size. I know that for I/O MPI_Offset can be larger than Aint, but this proposal does not solve the I/O problem as far as I know. > > https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/265 > > Rajeev > > > > On Mar 11, 2011, at 5:06 PM, Solt, David George wrote: > >> During our meeting today we decided that MPI_Count should be at least as large as an MPI_Aint. We already had the restriction that it had to be as large as a C/Fortran integer. We want both restrictions (they cannot be combined because there is no guarantee that MPI_Aint > integer). >> >> I'll throw this out as a starting point for discussion: >> >> >> >> >> 2.5.8 Last sentence change to: >> >> The size of the MPI_Count type is determined by the MPI implementation >> with the restriction that it must be minimally capable of encoding a C >> int and Fortran INTEGER and any value that may be stored in an MPI_Aint type. >> >> Rational thingy: >> >> MPI_Count is used to communicate both the number of elements in a datatype and the bounds of a datatype. >> The number of elements in a datatype is specified at creation time using a C int or Fortran INTEGER. The bounds >> may be specified using an MPI_Aint. >> >> >> So, I was especially brief here. I did not want to get into the "new" routines vs. "old routines", but if you attempt to go into more depth than what I said, you will inevitably end up going down that path. I can think of a thousand ways not to say it, but its hard to come up with a good way. >> 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 > > > _______________________________________________ > 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] Sun Mar 13 09:21:16 2011 From: jsquyres at [hidden] (Jeff Squyres) Date: Sun, 13 Mar 2011 10:21:16 -0400 Subject: [Mpi3-bwcompat] MPI Backward Compatibility Working Group In-Reply-To: Message-ID: <0990AF9B-CAB6-44E0-AECA-2579BC2B0203@cisco.com> On Mar 11, 2011, at 6:06 PM, Solt, David George wrote: > 2.5.8 Last sentence change to: > > The size of the MPI_Count type is determined by the MPI implementation > with the restriction that it must be minimally capable of encoding a C int and Fortran INTEGER > and any value that may be stored in an MPI_Aint type. "...and any value that may be stored in a variable of type MPI_Aint." > Rational thingy: Rationale. Potatoes. :-) > MPI_Count is used to communicate both the number of elements in a datatype and the bounds of a datatype. > The number of elements in a datatype is specified at creation time using a C int or Fortran INTEGER. The bounds > may be specified using an MPI_Aint. This is good. I would change the wording slightly -- let's not use the verb "communicate" here: "MPI_Count explicitly specifies the number of elements in a datatype, and therefore implicitly specifies the bounds of that datatype. The number of elements in a datatype is specified at creation time using a C int or Fortran INTEGER. The extent of a datatype is expressed using an MPI_Aint. How's that? -- 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] Sun Mar 13 09:21:41 2011 From: jsquyres at [hidden] (Jeff Squyres) Date: Sun, 13 Mar 2011 10:21:41 -0400 Subject: [Mpi3-bwcompat] MPI Backward Compatibility Working Group In-Reply-To: Message-ID: <53B9D0C1-4F81-4F8C-8F20-24AB521199A4@cisco.com> Thanks Dave; we'll finish this up by Monday so that we can get the PDF out in time for a formal reading. Have a great vacation! On Mar 13, 2011, at 1:19 AM, Solt, David George wrote: > I am on vacation this week, so I need to finish up my involvement as I can't say for sure if I will be on e-mail or not during the week. > > I checked in the changes I made here: > > https://svn.mpi-forum.org/svn/mpi-forum-docs/trunk/working-groups/mpi-3/bw-compat > > I uploaded new versions of the pdf's to both tickets with the changes we discussed on Friday. For the issue we are discussing here, I added > > "and any value that may be stored in an MPI_Aint type." > > but did not add the rationale. > > Thanks, > Dave > > -----Original Message----- > From: mpi3-bwcompat-bounces_at_[hidden] [mailto:mpi3-bwcompat-bounces_at_[hidden]] On Behalf Of Rajeev Thakur > Sent: Friday, March 11, 2011 11:21 PM > To: MPI-3 backwards compatability WG > Subject: Re: [Mpi3-bwcompat] MPI Backward Compatibility Working Group > > Could we say that MPI_Count should be the larger of MPI_Aint and MPI_Offset? (Anything bigger than that is not really useful.) That might help the I/O problem better. > > Rajeev > > > On Mar 11, 2011, at 11:07 PM, Fab Tillier wrote: > >> Hi Rajeev, >> >> A data buffer can't be larger than MPI_Aint in memory, but an MPI Datatype can be larger than what can fit in memory, and thus larger than MPI_Aint. MPI_Count allows such large datatypes to be represented and used in MPI, even if they can't be held in memory all at once. >> >> This proposal is intended to (minimally) solve the I/O problem, not just large network transfers. >> >> Does that make sense? >> -Fab >> >> -----Original Message----- >> From: mpi3-bwcompat-bounces_at_[hidden] [mailto:mpi3-bwcompat-bounces_at_[hidden]] On Behalf Of Rajeev Thakur >> Sent: Friday, March 11, 2011 8:06 PM >> To: MPI-3 backwards compatability WG >> Subject: Re: [Mpi3-bwcompat] MPI Backward Compatibility Working Group >> >> What was the motivation for the new MPI_Type_get_extent_x and MPI_Type_get_true_extent_x functions? >> >> If we say MPI_Count should be at least as large as MPI_Aint, why can't we just use MPI_Aint instead? The data buffer can't be larger than Aint size. I know that for I/O MPI_Offset can be larger than Aint, but this proposal does not solve the I/O problem as far as I know. >> >> https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/265 >> >> Rajeev >> >> >> >> On Mar 11, 2011, at 5:06 PM, Solt, David George wrote: >> >>> During our meeting today we decided that MPI_Count should be at least as large as an MPI_Aint. We already had the restriction that it had to be as large as a C/Fortran integer. We want both restrictions (they cannot be combined because there is no guarantee that MPI_Aint > integer). >>> >>> I'll throw this out as a starting point for discussion: >>> >>> >>> >>> >>> 2.5.8 Last sentence change to: >>> >>> The size of the MPI_Count type is determined by the MPI implementation >>> with the restriction that it must be minimally capable of encoding a C >>> int and Fortran INTEGER and any value that may be stored in an MPI_Aint type. >>> >>> Rational thingy: >>> >>> MPI_Count is used to communicate both the number of elements in a datatype and the bounds of a datatype. >>> The number of elements in a datatype is specified at creation time using a C int or Fortran INTEGER. The bounds >>> may be specified using an MPI_Aint. >>> >>> >>> So, I was especially brief here. I did not want to get into the "new" routines vs. "old routines", but if you attempt to go into more depth than what I said, you will inevitably end up going down that path. I can think of a thousand ways not to say it, but its hard to come up with a good way. >>> 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 >> >> >> _______________________________________________ >> 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/ From ftillier at [hidden] Sun Mar 13 13:21:59 2011 From: ftillier at [hidden] (Fab Tillier) Date: Sun, 13 Mar 2011 18:21:59 +0000 Subject: [Mpi3-bwcompat] MPI Backward Compatibility Working Group In-Reply-To: <0990AF9B-CAB6-44E0-AECA-2579BC2B0203@cisco.com> Message-ID: <91B583BE4B6FCD408F53D1B8F537E0921D746A72@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> Jeff, I like your wording, looks good to me. Are you going to fix up the latex and generate new PDFs that we can send out? -Fab -----Original Message----- From: mpi3-bwcompat-bounces_at_[hidden] [mailto:mpi3-bwcompat-bounces_at_[hidden]] On Behalf Of Jeff Squyres Sent: Sunday, March 13, 2011 7:21 AM To: MPI-3 backwards compatability WG Subject: Re: [Mpi3-bwcompat] MPI Backward Compatibility Working Group On Mar 11, 2011, at 6:06 PM, Solt, David George wrote: > 2.5.8 Last sentence change to: > > The size of the MPI_Count type is determined by the MPI implementation > with the restriction that it must be minimally capable of encoding a C > int and Fortran INTEGER and any value that may be stored in an MPI_Aint type. "...and any value that may be stored in a variable of type MPI_Aint." > Rational thingy: Rationale. Potatoes. :-) > MPI_Count is used to communicate both the number of elements in a datatype and the bounds of a datatype. > The number of elements in a datatype is specified at creation time using a C int or Fortran INTEGER. The bounds > may be specified using an MPI_Aint. This is good. I would change the wording slightly -- let's not use the verb "communicate" here: "MPI_Count explicitly specifies the number of elements in a datatype, and therefore implicitly specifies the bounds of that datatype. The number of elements in a datatype is specified at creation time using a C int or Fortran INTEGER. The extent of a datatype is expressed using an MPI_Aint. How's that? -- 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] Sun Mar 13 13:32:27 2011 From: jsquyres at [hidden] (Jeff Squyres jsquyres) Date: Sun, 13 Mar 2011 14:32:27 -0400 Subject: [Mpi3-bwcompat] MPI Backward Compatibility Working Group In-Reply-To: <91B583BE4B6FCD408F53D1B8F537E0921D746A72@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> Message-ID: <8DABB8BC-441E-4266-9E8A-CF5773E46248@cisco.com> If we all like the text, sure - I'll make the latex changes. Sent from my phone. No type good. On Mar 13, 2011, at 2:22 PM, "Fab Tillier" wrote: > Jeff, I like your wording, looks good to me. Are you going to fix up the latex and generate new PDFs that we can send out? > > -Fab > > -----Original Message----- > From: mpi3-bwcompat-bounces_at_[hidden] [mailto:mpi3-bwcompat-bounces_at_[hidden]] On Behalf Of Jeff Squyres > Sent: Sunday, March 13, 2011 7:21 AM > To: MPI-3 backwards compatability WG > Subject: Re: [Mpi3-bwcompat] MPI Backward Compatibility Working Group > > On Mar 11, 2011, at 6:06 PM, Solt, David George wrote: > >> 2.5.8 Last sentence change to: >> >> The size of the MPI_Count type is determined by the MPI implementation >> with the restriction that it must be minimally capable of encoding a C >> int and Fortran INTEGER and any value that may be stored in an MPI_Aint type. > > "...and any value that may be stored in a variable of type MPI_Aint." > >> Rational thingy: > > Rationale. Potatoes. :-) > >> MPI_Count is used to communicate both the number of elements in a datatype and the bounds of a datatype. >> The number of elements in a datatype is specified at creation time using a C int or Fortran INTEGER. The bounds >> may be specified using an MPI_Aint. > > This is good. I would change the wording slightly -- let's not use the verb "communicate" here: > > "MPI_Count explicitly specifies the number of elements in a datatype, and therefore implicitly specifies the bounds of that datatype. The number of elements in a datatype is specified at creation time using a C int or Fortran INTEGER. The extent of a datatype is expressed using an MPI_Aint. > > How's that? > > -- > 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 From ftillier at [hidden] Sun Mar 13 13:55:42 2011 From: ftillier at [hidden] (Fab Tillier) Date: Sun, 13 Mar 2011 18:55:42 +0000 Subject: [Mpi3-bwcompat] MPI Backward Compatibility Working Group In-Reply-To: <8DABB8BC-441E-4266-9E8A-CF5773E46248@cisco.com> Message-ID: <91B583BE4B6FCD408F53D1B8F537E0921D746BBE@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> Only open, as far as I can tell, is Rajeev's question about making MPI_Count at least as big as the biggest of {int,MPI_Aint, MPI_Offset}. We've covered the first two, but not MPI_Offset. -Fab -----Original Message----- From: mpi3-bwcompat-bounces_at_[hidden] [mailto:mpi3-bwcompat-bounces_at_[hidden]] On Behalf Of Jeff Squyres (jsquyres) Sent: Sunday, March 13, 2011 11:32 AM To: MPI-3 backwards compatability WG Cc: MPI-3 backwards compatability WG Subject: Re: [Mpi3-bwcompat] MPI Backward Compatibility Working Group If we all like the text, sure - I'll make the latex changes. Sent from my phone. No type good. On Mar 13, 2011, at 2:22 PM, "Fab Tillier" wrote: > Jeff, I like your wording, looks good to me. Are you going to fix up the latex and generate new PDFs that we can send out? > > -Fab > > -----Original Message----- > From: mpi3-bwcompat-bounces_at_[hidden] > [mailto:mpi3-bwcompat-bounces_at_[hidden]] On Behalf Of Jeff > Squyres > Sent: Sunday, March 13, 2011 7:21 AM > To: MPI-3 backwards compatability WG > Subject: Re: [Mpi3-bwcompat] MPI Backward Compatibility Working Group > > On Mar 11, 2011, at 6:06 PM, Solt, David George wrote: > >> 2.5.8 Last sentence change to: >> >> The size of the MPI_Count type is determined by the MPI >> implementation with the restriction that it must be minimally capable >> of encoding a C int and Fortran INTEGER and any value that may be stored in an MPI_Aint type. > > "...and any value that may be stored in a variable of type MPI_Aint." > >> Rational thingy: > > Rationale. Potatoes. :-) > >> MPI_Count is used to communicate both the number of elements in a datatype and the bounds of a datatype. >> The number of elements in a datatype is specified at creation time using a C int or Fortran INTEGER. The bounds >> may be specified using an MPI_Aint. > > This is good. I would change the wording slightly -- let's not use the verb "communicate" here: > > "MPI_Count explicitly specifies the number of elements in a datatype, and therefore implicitly specifies the bounds of that datatype. The number of elements in a datatype is specified at creation time using a C int or Fortran INTEGER. The extent of a datatype is expressed using an MPI_Aint. > > How's that? > > -- > 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 _______________________________________________ Mpi3-bwcompat mailing list Mpi3-bwcompat_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-bwcompat From jsquyres at [hidden] Mon Mar 14 09:52:09 2011 From: jsquyres at [hidden] (Jeff Squyres) Date: Mon, 14 Mar 2011 10:52:09 -0400 Subject: [Mpi3-bwcompat] MPI Backward Compatibility Working Group In-Reply-To: <91B583BE4B6FCD408F53D1B8F537E0921D746BBE@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> Message-ID: <57F65508-2972-4EB8-8298-08DE9143FDB8@cisco.com> The thought on the call was that Quincey would add text about MPI_Offset (to this new section) when he does the ticket covering more IO things. Do we want to add the text about Offset now? REMINDER: We need to get this done TODAY to qualify for a formal reading at the Forum meeting. I attached section 2.5.8 with the changes I proposed -- **INCLUDING** the rationale section (but without text about Offset). Comments? On Mar 13, 2011, at 2:55 PM, Fab Tillier wrote: > Only open, as far as I can tell, is Rajeev's question about making MPI_Count at least as big as the biggest of {int,MPI_Aint, MPI_Offset}. We've covered the first two, but not MPI_Offset. > > -Fab -- Jeff Squyres jsquyres_at_[hidden] For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/ * -------------- next part -------------- A non-text attachment was scrubbed... Name: section-258-mpi-count.pdf Type: application/pdf Size: 241124 bytes Desc: section-258-mpi-count.pdf URL: From koziol at [hidden] Tue Mar 15 07:07:10 2011 From: koziol at [hidden] (Quincey Koziol) Date: Tue, 15 Mar 2011 07:07:10 -0500 Subject: [Mpi3-bwcompat] MPI Backward Compatibility Working Group In-Reply-To: <57F65508-2972-4EB8-8298-08DE9143FDB8@cisco.com> Message-ID: <05A1C93E-C85D-4D97-9D13-29B01E94A9D4@hdfgroup.org> On Mar 14, 2011, at 9:52 AM, Jeff Squyres wrote: > The thought on the call was that Quincey would add text about MPI_Offset (to this new section) when he does the ticket covering more IO things. Yup, I'm still planning to do that. Quincey > > Do we want to add the text about Offset now? > > REMINDER: We need to get this done TODAY to qualify for a formal reading at the Forum meeting. > > I attached section 2.5.8 with the changes I proposed -- **INCLUDING** the rationale section (but without text about Offset). > > Comments? > > > On Mar 13, 2011, at 2:55 PM, Fab Tillier wrote: > >> Only open, as far as I can tell, is Rajeev's question about making MPI_Count at least as big as the biggest of {int,MPI_Aint, MPI_Offset}. We've covered the first two, but not MPI_Offset. >> >> -Fab > > > -- > 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 Mar 18 12:05:49 2011 From: jsquyres at [hidden] (Jeff Squyres) Date: Fri, 18 Mar 2011 13:05:49 -0400 Subject: [Mpi3-bwcompat] bwcompat call today? Message-ID: Terry and I are on the call, but no one else is there yet...? -- 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 Mar 18 12:07:54 2011 From: jsquyres at [hidden] (Jeff Squyres) Date: Fri, 18 Mar 2011 13:07:54 -0400 Subject: [Mpi3-bwcompat] bwcompat call today? In-Reply-To: Message-ID: <204C9641-45CE-44C9-B8A0-594CF3C9F473@cisco.com> Oh ya -- Dave's on vacation this week, so we can't use his bridge. Use this instead: Please join me in a WebEx meeting: Password: 1111 https://cisco.webex.com/cisco/j.php?ED=2312058&UID=484033237 On Mar 18, 2011, at 1:05 PM, Jeff Squyres wrote: > Terry and I are on the call, but no one else is there yet...? > > -- > 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 -- Jeff Squyres jsquyres_at_[hidden] For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/ From ftillier at [hidden] Mon Mar 28 20:06:37 2011 From: ftillier at [hidden] (Fab Tillier) Date: Tue, 29 Mar 2011 01:06:37 +0000 Subject: [Mpi3-bwcompat] MPI Timer feedback Message-ID: <91B583BE4B6FCD408F53D1B8F537E0921D784DF9@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> Feedback on MPI Timer requests presentation: - MPI_Request_free is ambiguous in the standard. We should define specific requirement that MPI_Request_free actually frees timer requests, rather than leak or provide some other indeterminate behavior. - MPI_Timer_reset should take request by value, not ref, as it doesn't free the request handle. - Some folks suggested they would rather see new 'poll' functions that take a timeout as a parameter rather than as a timer request. This potentially avoids having to scan input requests looking for minimum time. However, it requires special handling for reporting timeouts. - Need text to prevent implementations ignoring MPI_Cancel. Text in standard about local operations must complete, leverage that. From ftillier at [hidden] Wed Mar 30 10:43:52 2011 From: ftillier at [hidden] (Fab Tillier) Date: Wed, 30 Mar 2011 15:43:52 +0000 Subject: [Mpi3-bwcompat] MPI_Count Ticket 265 feedback Message-ID: <91B583BE4B6FCD408F53D1B8F537E0921D78742F@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> Page numbers are Acrobat page numbers, not document page numbers. Page9_at_19: ...count values, and that type is MPI_Count... Page9_at_29: confusion about 'type map' applying to memory only, not file view Page9_at_30: For backward compatibility, many MPI routines use int in C or INTEGER in Fortran as count arguments. Page24_at_9: MPI_COUNT should be MPI_Count Page91_at_11: "value of size to" size should be a different font. Page92_at_15: Add "The Functions MPI_TYPE_GET_EXTENT" Page94_at_33: Start sentence properly, not with 'true_lb' (Ticket0 for Adam) Page120_at_38: Use similar wording to previous "limits" wording might be better (more consistent) Need to mention overflow for MPI_GET_COUNT? One could use MPI_STATUS_SET_ELEMENTS_X to overflow MPI_GET_COUNT. In MPI Forum 3.0 draft 1 document: Page455_at_32 add MPI_COUNT as width = 8 in external32 From jsquyres at [hidden] Wed Mar 30 17:42:19 2011 From: jsquyres at [hidden] (Jeff Squyres) Date: Wed, 30 Mar 2011 17:42:19 -0500 Subject: [Mpi3-bwcompat] New MPI_Count PDF Message-ID: <7A0AF67A-8F7A-47EC-856C-D903E0D99829@cisco.com> Bill fixed the latex error in short order. A better PDF (with the 2nd half of the doc not being entirely red text) is now here: http://www.open-mpi.org/~jsquyres/one-count-to-rule-them-all/ -- Jeff Squyres jsquyres_at_[hidden] For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/