March 2011 - Mpi3-bwcompat - mailman3.cels.anl.gov

Re: [Mpi3-bwcompat] Fwd: Re: ticket 265 udpated
by unknown＠example.com 04 Mar '11

04 Mar '11

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]> [mailto:mpi3-bwcompat-bounces_at_[hidden]] On Behalf Of Terry Dontje Sent: Friday, March 04, 2011 10:00 AM To: mpi3-bwcompat_at_[hidden]<mailto: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]<mailto: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]<mailto:terry.dontje_at_[hidden]> _______________________________________________ Mpi3-bwcompat mailing list Mpi3-bwcompat_at_[hidden]<mailto: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]<mailto:terry.dontje_at_[hidden]> *

1 0

Re: [Mpi3-bwcompat] Fwd: Re: ticket 265 udpated
by unknown＠example.com 04 Mar '11

04 Mar '11

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] <mailto: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] <mailto: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] <mailto:terry.dontje_at_[hidden]> *

1 0

Re: [Mpi3-bwcompat] Fwd: Re: ticket 265 udpated
by unknown＠example.com 04 Mar '11

04 Mar '11

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]<mailto: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]<mailto:terry.dontje_at_[hidden]> *

1 0

Fwd: Re: ticket 265 udpated
by unknown＠example.com 04 Mar '11

04 Mar '11

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] <mailto:terry.dontje_at_[hidden]> *

1 0

Re: [Mpi3-bwcompat] ticket 265 udpated
by unknown＠example.com 04 Mar '11

04 Mar '11

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

1 0

Re: [Mpi3-bwcompat] ticket 265 udpated
by unknown＠example.com 03 Mar '11

03 Mar '11

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/

1 0

Re: [Mpi3-bwcompat] ticket 265 udpated
by unknown＠example.com 03 Mar '11

03 Mar '11

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

1 0

Re: [Mpi3-bwcompat] ticket 265 udpated
by unknown＠example.com 03 Mar '11

03 Mar '11

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/

1 0

Re: [Mpi3-bwcompat] ticket 265 udpated
by unknown＠example.com 03 Mar '11

03 Mar '11

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 > >

1 0

Re: [Mpi3-bwcompat] ticket 265 udpated
by unknown＠example.com 03 Mar '11

03 Mar '11

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/

1 0