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

Re: [Mpi3-bwcompat] Teleconf tomorrow?
by unknown＠example.com 15 Oct '10

15 Oct '10

It would also be weird that alltoall takes int but ialltoall takes MPI-count. Sent from my PDA. No type good. On Oct 15, 2010, at 12:40 AM, "Fab Tillier" <ftillier_at_[hidden]> wrote: > Quincey Koziol wrote on Thu, 14 Oct 2010 at 20:44:23 > >> On Oct 14, 2010, at 2:29 PM, Jeff Squyres wrote: >> >>> On Oct 14, 2010, at 2:54 PM, Fab Tillier wrote: >>> >>>> 2. Add just the bare minimum, leverage datatypes to work around >>>> counts. Note that this requires introducing w versions of v >>>> collective APIs, to allow for different types (since the v functions >>>> allow different counts from each participant.) >>> >>> This option also includes the "output" functions, right? >> >> Yes, that's the basic idea. >> >> BTW, I think this is a perfectly acceptable solution (as much as >> I'd like a blue pony :-). Fab was talking about just doing this, along >> with introducing MPI_Count, etc. for _future_ routines and getting a >> consensus from the forum that all future routines would use MPI_Count, >> etc. Since it only duplicates a few functions now (they necessary ones >> to get the I/O and datatype routines working with large counts), it >> satisfies a lot of "agile" design guidelines and I think it might be a >> very reasonable thing to do. > > I don't know if the forum would go for defining new functions to use MPI_Count only. I think it's a brilliant idea personally, though one could make the argument that requiring something like MPI_IAlltoallv to take arrays of MPI_Count when taking arrays of int would be half the size would be detrimental to performance. > > -Fab > > _______________________________________________ > Mpi3-bwcompat mailing list > Mpi3-bwcompat_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-bwcompat

1 0

Re: [Mpi3-bwcompat] Teleconf tomorrow?
by unknown＠example.com 14 Oct '10

14 Oct '10

Quincey Koziol wrote on Thu, 14 Oct 2010 at 20:44:23 > On Oct 14, 2010, at 2:29 PM, Jeff Squyres wrote: > >> On Oct 14, 2010, at 2:54 PM, Fab Tillier wrote: >> >>> 2. Add just the bare minimum, leverage datatypes to work around >>> counts. Note that this requires introducing w versions of v >>> collective APIs, to allow for different types (since the v functions >>> allow different counts from each participant.) >> >> This option also includes the "output" functions, right? > > Yes, that's the basic idea. > > BTW, I think this is a perfectly acceptable solution (as much as > I'd like a blue pony :-). Fab was talking about just doing this, along > with introducing MPI_Count, etc. for _future_ routines and getting a > consensus from the forum that all future routines would use MPI_Count, > etc. Since it only duplicates a few functions now (they necessary ones > to get the I/O and datatype routines working with large counts), it > satisfies a lot of "agile" design guidelines and I think it might be a > very reasonable thing to do. I don't know if the forum would go for defining new functions to use MPI_Count only. I think it's a brilliant idea personally, though one could make the argument that requiring something like MPI_IAlltoallv to take arrays of MPI_Count when taking arrays of int would be half the size would be detrimental to performance. -Fab

1 0

Re: [Mpi3-bwcompat] Teleconf tomorrow?
by unknown＠example.com 14 Oct '10

14 Oct '10

Hi all, On Oct 14, 2010, at 2:29 PM, Jeff Squyres wrote: > On Oct 14, 2010, at 2:54 PM, Fab Tillier wrote: > >> I'd like to find a solution that allows mixing int and int64 (or whatever) counts in a single application (whether all in the app's source, or a mixture of app + third-party library.) This is one of the main weaknesses of the current proposal, and one of the benefits of just having a full set of suffixed functions. > > Yes, I agree -- I discussed this with Adam, Bill, and Torsten at dinner and only then did I understand the objection that Ralf raised in the room (mixing int and int64 in the same app). > >> I think what I want to see is a full set of MPI3_Send, etc functions, that fix the count, the sizes, the ranks, the tags, etc. > > This is the conclusion we came to at dinner, too. Might end up putting in piggybacking (acck!!) and other stuff in there, too. ...but we'd love to see someone else's proposal for that. ;-) > >> The goals to me are: >> 1. Support for codes that use int (can't break existing code.) >> 2. Support for modern codes (things aren't int.) >> 3. Support for mixed codes (both int and not int.) > > Agreed. The echo "MPI_Send(..., int count,...)" | sed -e 's/int count/MPI_Count count/'g proposal addresses #1 and #2. #3 was not addressed. > >> What's the best way of providing the above? What if we fix MPI_Tag and MPI_Rank at the same time, does it change the preferred solution? > > I think that having a new MPI3_Send with all the fixes in it (MPI_Count, MPI_Tag, MPI_Rank, and a blue pony) is probably the best solution. I'm sure we'll dither about the suffix for what to call this new function, though. ;-) > >> The three options are: >> 1. Suffix all APIs, fix count & size, optionally fix tag and rank. > > ...and probably some other stuff will get wedged in there, eventually (e.g., piggybacking). > >> 2. Add just the bare minimum, leverage datatypes to work around counts. Note that this requires introducing w versions of v collective APIs, to allow for different types (since the v functions allow different counts from each participant.) > > This option also includes the "output" functions, right? Yes, that's the basic idea. BTW, I think this is a perfectly acceptable solution (as much as I'd like a blue pony :-). Fab was talking about just doing this, along with introducing MPI_Count, etc. for _future_ routines and getting a consensus from the forum that all future routines would use MPI_Count, etc. Since it only duplicates a few functions now (they necessary ones to get the I/O and datatype routines working with large counts), it satisfies a lot of "agile" design guidelines and I think it might be a very reasonable thing to do. Quincey >> 3. Introduce count & size, modify existing APIs. > > Don't forget: > > 4. Ostrich (stick head in sand / do nothing). > > 5. Introduce new text that strictly disallows communicating with more than 2B count of anything. > > 6. Impose hefty fines on anyone who does. > > 7. Get the IRS involved. > > -- > 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

1 0

Re: [Mpi3-bwcompat] Teleconf tomorrow?
by unknown＠example.com 14 Oct '10

14 Oct '10

Solt, David George wrote on Thu, 14 Oct 2010 at 15:21:06 > Do you want me to leave the meeting on for tomorrow? Someone didn't read to the end of my mail... :-P I don't think we need the call. Thanks, -Fab > Dave > > -----Original Message----- > From: mpi3-bwcompat-bounces_at_[hidden] [mailto:mpi3-bwcompat- > bounces_at_[hidden]] On Behalf Of Fab Tillier > Sent: Thursday, October 14, 2010 1:55 PM > To: MPI-3 backwards compatability WG > Subject: Re: [Mpi3-bwcompat] Teleconf tomorrow? > > I'd like to find a solution that allows mixing int and int64 (or > whatever) counts in a single application (whether all in the app's > source, or a mixture of app + third-party library.) This is one of the > main weaknesses of the current proposal, and one of the benefits of > just having a full set of suffixed functions. > > I don't know if people will go for a separate section with a subset of > cross-cutting functionality. Torsten was pretty vehemently opposed. > > I think what I want to see is a full set of MPI3_Send, etc functions, > that fix the count, the sizes, the ranks, the tags, etc. Basically > define types for all of these so that we can in the future adapt > without having to do this again each time we go to the next power of > two sizes. The MPI3_Xxx functions could even be listed in the same > section as their MPI_Xxx counterparts, as the documentation will be > identical (all these types will still be some form of integer.) > Basically, just another binding, effectively. > > Yes, this doubles the API footprint, and I expect people to push back > on this just because it generates work that they don't want to do. But > the same could be said about any of the other features, like RMA, NBC, > sparse collectives, etc, so it seems like a weak argument. > > In any case, I think it would help us to have a thorough analysis of > the options we've considered, and present that side-by-side at the next > meeting. People might realize how much things suck, and then we can > all agree to do the least sucky one. The main thing is this has > dragged on for so long people don't recall why past options were > rejected. By presenting them all at the same time (again?) we can have > a presentation to reference when people weren't paying attention. > > The goals to me are: > 1. Support for codes that use int (can't break existing code.) > 2. Support for modern codes (things aren't int.) > 3. Support for mixed codes (both int and not int.) > > What's the best way of providing the above? What if we fix MPI_Tag and > MPI_Rank at the same time, does it change the preferred solution? > > In any case, I think email will be fine instead of the call. Torsten > offered to work with me to create a presentation with the various > possibilities, and a detailed analysis of the pros/cons. It would be > helpful if folks could compile their pros/cons for the different > solutions and send them to the list for discussion. The three options > are: 1. Suffix all APIs, fix count & size, optionally fix tag and rank. > 2. Add just the bare minimum, leverage datatypes to work around counts. > Note that this requires introducing w versions of v collective APIs, to > allow for different types (since the v functions allow different counts > from each participant.) 3. Introduce count & size, modify existing APIs. > > -Fab > > -----Original Message----- > From: mpi3-bwcompat-bounces_at_[hidden] [mailto:mpi3-bwcompat- > bounces_at_[hidden]] On Behalf Of Solt, David George > Sent: Thursday, October 14, 2010 9:00 AM > > Willing to cancel the meeting and discuss in e-mail. Fab? Some ideas > Fab and I discussed: > > 1) Drop it > 2) Define a minimal set of MPI_XXXXL routines (MPI_IsendL, > MPI_Get_elementsL, perhaps some of the non-blocking collectives that > can't be "solved" at the user level by wrapping the call and converting > into a series of shorter collectives) > This is NOT the same as the proposal of only fixing the output > routines. The idea here is to say that if people needed to send long > messages, they really don't need a blocking MPI_SendL or an MPI_Ibsend > or an MPI_Alltoall. We could target very specific routines and just > ask for a limited subset. We could ask outright or ask for them to be > "optional" but blessed by the forum. > 3) We could make a very precise statement about the bounds of the > current proposal and exactly what is considered compliant code. One > extreme would be to say that (for MPI3.0) an MPI implementation must > accept an int wherever an MPI_Count argument is presented, but that > someday this restriction may be relaxed and we highly recommend that > MPI-3 applications use MPI_Count. Some implementations may wish to > provide large count support by creating a library which defines > MPI_Count as 64-bit. Such a library would technically be non- > compliant, but would allow support of large counts for particular > applications. This allows applications to be written in a compliant > way and work correctly with both compliant and non-compliant libraries. > > I know Fab was discussing further with Torsten, maybe he has more ideas > since I talked with him? > > Dave > -----Original Message----- > From: mpi3-bwcompat-bounces_at_[hidden] [mailto:mpi3-bwcompat- > bounces_at_[hidden]] On Behalf Of Quincey Koziol > Sent: Thursday, October 14, 2010 10:16 AM > > On Oct 14, 2010, at 10:14 AM, Jeff Squyres wrote: > >> I have an mpi3-bwcompat meeting on my calendar tomorrow. >> >> Is that still on? > > I can't make it (still traveling). > > Quincey

1 0

Re: [Mpi3-bwcompat] Teleconf tomorrow?
by unknown＠example.com 14 Oct '10

14 Oct '10

Do you want me to leave the meeting on for tomorrow? Dave -----Original Message----- From: mpi3-bwcompat-bounces_at_[hidden] [mailto:mpi3-bwcompat-bounces_at_[hidden]] On Behalf Of Fab Tillier Sent: Thursday, October 14, 2010 1:55 PM To: MPI-3 backwards compatability WG Subject: Re: [Mpi3-bwcompat] Teleconf tomorrow? I'd like to find a solution that allows mixing int and int64 (or whatever) counts in a single application (whether all in the app's source, or a mixture of app + third-party library.) This is one of the main weaknesses of the current proposal, and one of the benefits of just having a full set of suffixed functions. I don't know if people will go for a separate section with a subset of cross-cutting functionality. Torsten was pretty vehemently opposed. I think what I want to see is a full set of MPI3_Send, etc functions, that fix the count, the sizes, the ranks, the tags, etc. Basically define types for all of these so that we can in the future adapt without having to do this again each time we go to the next power of two sizes. The MPI3_Xxx functions could even be listed in the same section as their MPI_Xxx counterparts, as the documentation will be identical (all these types will still be some form of integer.) Basically, just another binding, effectively. Yes, this doubles the API footprint, and I expect people to push back on this just because it generates work that they don't want to do. But the same could be said about any of the other features, like RMA, NBC, sparse collectives, etc, so it seems like a weak argument. In any case, I think it would help us to have a thorough analysis of the options we've considered, and present that side-by-side at the next meeting. People might realize how much things suck, and then we can all agree to do the least sucky one. The main thing is this has dragged on for so long people don't recall why past options were rejected. By presenting them all at the same time (again?) we can have a presentation to reference when people weren't paying attention. The goals to me are: 1. Support for codes that use int (can't break existing code.) 2. Support for modern codes (things aren't int.) 3. Support for mixed codes (both int and not int.) What's the best way of providing the above? What if we fix MPI_Tag and MPI_Rank at the same time, does it change the preferred solution? In any case, I think email will be fine instead of the call. Torsten offered to work with me to create a presentation with the various possibilities, and a detailed analysis of the pros/cons. It would be helpful if folks could compile their pros/cons for the different solutions and send them to the list for discussion. The three options are: 1. Suffix all APIs, fix count & size, optionally fix tag and rank. 2. Add just the bare minimum, leverage datatypes to work around counts. Note that this requires introducing w versions of v collective APIs, to allow for different types (since the v functions allow different counts from each participant.) 3. Introduce count & size, modify existing APIs. -Fab -----Original Message----- From: mpi3-bwcompat-bounces_at_[hidden] [mailto:mpi3-bwcompat-bounces_at_[hidden]] On Behalf Of Solt, David George Sent: Thursday, October 14, 2010 9:00 AM To: MPI-3 backwards compatability WG Subject: Re: [Mpi3-bwcompat] Teleconf tomorrow? Willing to cancel the meeting and discuss in e-mail. Fab? Some ideas Fab and I discussed: 1) Drop it 2) Define a minimal set of MPI_XXXXL routines (MPI_IsendL, MPI_Get_elementsL, perhaps some of the non-blocking collectives that can't be "solved" at the user level by wrapping the call and converting into a series of shorter collectives) This is NOT the same as the proposal of only fixing the output routines. The idea here is to say that if people needed to send long messages, they really don't need a blocking MPI_SendL or an MPI_Ibsend or an MPI_Alltoall. We could target very specific routines and just ask for a limited subset. We could ask outright or ask for them to be "optional" but blessed by the forum. 3) We could make a very precise statement about the bounds of the current proposal and exactly what is considered compliant code. One extreme would be to say that (for MPI3.0) an MPI implementation must accept an int wherever an MPI_Count argument is presented, but that someday this restriction may be relaxed and we highly recommend that MPI-3 applications use MPI_Count. Some implementations may wish to provide large count support by creating a library which defines MPI_Count as 64-bit. Such a library would technically be non-compliant, but would allow support of large counts for particular applications. This allows applications to be written in a compliant way and work correctly with both compliant and non-compliant libraries. I know Fab was discussing further with Torsten, maybe he has more ideas since I talked with him? Dave -----Original Message----- From: mpi3-bwcompat-bounces_at_[hidden] [mailto:mpi3-bwcompat-bounces_at_[hidden]] On Behalf Of Quincey Koziol Sent: Thursday, October 14, 2010 10:16 AM To: MPI-3 backwards compatability WG Subject: Re: [Mpi3-bwcompat] Teleconf tomorrow? On Oct 14, 2010, at 10:14 AM, Jeff Squyres wrote: > I have an mpi3-bwcompat meeting on my calendar tomorrow. > > Is that still on? I can't make it (still traveling). Quincey _______________________________________________ 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

1 0

Re: [Mpi3-bwcompat] Teleconf tomorrow?
by unknown＠example.com 14 Oct '10

14 Oct '10

On Oct 14, 2010, at 2:54 PM, Fab Tillier wrote: > I'd like to find a solution that allows mixing int and int64 (or whatever) counts in a single application (whether all in the app's source, or a mixture of app + third-party library.) This is one of the main weaknesses of the current proposal, and one of the benefits of just having a full set of suffixed functions. Yes, I agree -- I discussed this with Adam, Bill, and Torsten at dinner and only then did I understand the objection that Ralf raised in the room (mixing int and int64 in the same app). > I think what I want to see is a full set of MPI3_Send, etc functions, that fix the count, the sizes, the ranks, the tags, etc. This is the conclusion we came to at dinner, too. Might end up putting in piggybacking (acck!!) and other stuff in there, too. ...but we'd love to see someone else's proposal for that. ;-) > The goals to me are: > 1. Support for codes that use int (can't break existing code.) > 2. Support for modern codes (things aren't int.) > 3. Support for mixed codes (both int and not int.) Agreed. The echo "MPI_Send(..., int count,...)" | sed -e 's/int count/MPI_Count count/'g proposal addresses #1 and #2. #3 was not addressed. > What's the best way of providing the above? What if we fix MPI_Tag and MPI_Rank at the same time, does it change the preferred solution? I think that having a new MPI3_Send with all the fixes in it (MPI_Count, MPI_Tag, MPI_Rank, and a blue pony) is probably the best solution. I'm sure we'll dither about the suffix for what to call this new function, though. ;-) > The three options are: > 1. Suffix all APIs, fix count & size, optionally fix tag and rank. ...and probably some other stuff will get wedged in there, eventually (e.g., piggybacking). > 2. Add just the bare minimum, leverage datatypes to work around counts. Note that this requires introducing w versions of v collective APIs, to allow for different types (since the v functions allow different counts from each participant.) This option also includes the "output" functions, right? > 3. Introduce count & size, modify existing APIs. Don't forget: 4. Ostrich (stick head in sand / do nothing). 5. Introduce new text that strictly disallows communicating with more than 2B count of anything. 6. Impose hefty fines on anyone who does. 7. Get the IRS involved. -- 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] Teleconf tomorrow?
by unknown＠example.com 14 Oct '10

14 Oct '10

I'd like to find a solution that allows mixing int and int64 (or whatever) counts in a single application (whether all in the app's source, or a mixture of app + third-party library.) This is one of the main weaknesses of the current proposal, and one of the benefits of just having a full set of suffixed functions. I don't know if people will go for a separate section with a subset of cross-cutting functionality. Torsten was pretty vehemently opposed. I think what I want to see is a full set of MPI3_Send, etc functions, that fix the count, the sizes, the ranks, the tags, etc. Basically define types for all of these so that we can in the future adapt without having to do this again each time we go to the next power of two sizes. The MPI3_Xxx functions could even be listed in the same section as their MPI_Xxx counterparts, as the documentation will be identical (all these types will still be some form of integer.) Basically, just another binding, effectively. Yes, this doubles the API footprint, and I expect people to push back on this just because it generates work that they don't want to do. But the same could be said about any of the other features, like RMA, NBC, sparse collectives, etc, so it seems like a weak argument. In any case, I think it would help us to have a thorough analysis of the options we've considered, and present that side-by-side at the next meeting. People might realize how much things suck, and then we can all agree to do the least sucky one. The main thing is this has dragged on for so long people don't recall why past options were rejected. By presenting them all at the same time (again?) we can have a presentation to reference when people weren't paying attention. The goals to me are: 1. Support for codes that use int (can't break existing code.) 2. Support for modern codes (things aren't int.) 3. Support for mixed codes (both int and not int.) What's the best way of providing the above? What if we fix MPI_Tag and MPI_Rank at the same time, does it change the preferred solution? In any case, I think email will be fine instead of the call. Torsten offered to work with me to create a presentation with the various possibilities, and a detailed analysis of the pros/cons. It would be helpful if folks could compile their pros/cons for the different solutions and send them to the list for discussion. The three options are: 1. Suffix all APIs, fix count & size, optionally fix tag and rank. 2. Add just the bare minimum, leverage datatypes to work around counts. Note that this requires introducing w versions of v collective APIs, to allow for different types (since the v functions allow different counts from each participant.) 3. Introduce count & size, modify existing APIs. -Fab -----Original Message----- From: mpi3-bwcompat-bounces_at_[hidden] [mailto:mpi3-bwcompat-bounces_at_[hidden]] On Behalf Of Solt, David George Sent: Thursday, October 14, 2010 9:00 AM To: MPI-3 backwards compatability WG Subject: Re: [Mpi3-bwcompat] Teleconf tomorrow? Willing to cancel the meeting and discuss in e-mail. Fab? Some ideas Fab and I discussed: 1) Drop it 2) Define a minimal set of MPI_XXXXL routines (MPI_IsendL, MPI_Get_elementsL, perhaps some of the non-blocking collectives that can't be "solved" at the user level by wrapping the call and converting into a series of shorter collectives) This is NOT the same as the proposal of only fixing the output routines. The idea here is to say that if people needed to send long messages, they really don't need a blocking MPI_SendL or an MPI_Ibsend or an MPI_Alltoall. We could target very specific routines and just ask for a limited subset. We could ask outright or ask for them to be "optional" but blessed by the forum. 3) We could make a very precise statement about the bounds of the current proposal and exactly what is considered compliant code. One extreme would be to say that (for MPI3.0) an MPI implementation must accept an int wherever an MPI_Count argument is presented, but that someday this restriction may be relaxed and we highly recommend that MPI-3 applications use MPI_Count. Some implementations may wish to provide large count support by creating a library which defines MPI_Count as 64-bit. Such a library would technically be non-compliant, but would allow support of large counts for particular applications. This allows applications to be written in a compliant way and work correctly with both compliant and non-compliant libraries. I know Fab was discussing further with Torsten, maybe he has more ideas since I talked with him? Dave -----Original Message----- From: mpi3-bwcompat-bounces_at_[hidden] [mailto:mpi3-bwcompat-bounces_at_[hidden]] On Behalf Of Quincey Koziol Sent: Thursday, October 14, 2010 10:16 AM To: MPI-3 backwards compatability WG Subject: Re: [Mpi3-bwcompat] Teleconf tomorrow? On Oct 14, 2010, at 10:14 AM, Jeff Squyres wrote: > I have an mpi3-bwcompat meeting on my calendar tomorrow. > > Is that still on? I can't make it (still traveling). Quincey _______________________________________________ Mpi3-bwcompat mailing list Mpi3-bwcompat_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-bwcompat _______________________________________________ Mpi3-bwcompat mailing list Mpi3-bwcompat_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-bwcompat

1 0

Re: [Mpi3-bwcompat] Teleconf tomorrow?
by unknown＠example.com 14 Oct '10

14 Oct '10

Willing to cancel the meeting and discuss in e-mail. Fab? Some ideas Fab and I discussed: 1) Drop it 2) Define a minimal set of MPI_XXXXL routines (MPI_IsendL, MPI_Get_elementsL, perhaps some of the non-blocking collectives that can't be "solved" at the user level by wrapping the call and converting into a series of shorter collectives) This is NOT the same as the proposal of only fixing the output routines. The idea here is to say that if people needed to send long messages, they really don't need a blocking MPI_SendL or an MPI_Ibsend or an MPI_Alltoall. We could target very specific routines and just ask for a limited subset. We could ask outright or ask for them to be "optional" but blessed by the forum. 3) We could make a very precise statement about the bounds of the current proposal and exactly what is considered compliant code. One extreme would be to say that (for MPI3.0) an MPI implementation must accept an int wherever an MPI_Count argument is presented, but that someday this restriction may be relaxed and we highly recommend that MPI-3 applications use MPI_Count. Some implementations may wish to provide large count support by creating a library which defines MPI_Count as 64-bit. Such a library would technically be non-compliant, but would allow support of large counts for particular applications. This allows applications to be written in a compliant way and work correctly with both compliant and non-compliant libraries. I know Fab was discussing further with Torsten, maybe he has more ideas since I talked with him? Dave -----Original Message----- From: mpi3-bwcompat-bounces_at_[hidden] [mailto:mpi3-bwcompat-bounces_at_[hidden]] On Behalf Of Quincey Koziol Sent: Thursday, October 14, 2010 10:16 AM To: MPI-3 backwards compatability WG Subject: Re: [Mpi3-bwcompat] Teleconf tomorrow? On Oct 14, 2010, at 10:14 AM, Jeff Squyres wrote: > I have an mpi3-bwcompat meeting on my calendar tomorrow. > > Is that still on? I can't make it (still traveling). Quincey _______________________________________________ Mpi3-bwcompat mailing list Mpi3-bwcompat_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-bwcompat

1 0

Re: [Mpi3-bwcompat] Teleconf tomorrow?
by unknown＠example.com 14 Oct '10

14 Oct '10

On Oct 14, 2010, at 10:14 AM, Jeff Squyres wrote: > I have an mpi3-bwcompat meeting on my calendar tomorrow. > > Is that still on? I can't make it (still traveling). Quincey

1 0

Teleconf tomorrow?
by unknown＠example.com 14 Oct '10

14 Oct '10

I have an mpi3-bwcompat meeting on my calendar tomorrow. Is that still on? -- Jeff Squyres jsquyres_at_[hidden] For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/

1 0