From ftillier at [hidden] Tue Oct 5 00:00:23 2010 From: ftillier at [hidden] (Fab Tillier) Date: Tue, 5 Oct 2010 05:00:23 +0000 Subject: [Mpi3-bwcompat] MPI_Size and non-count int parameters Message-ID: <91B583BE4B6FCD408F53D1B8F537E092129B6E0D@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> Should MPI_Size be used where one would likely use size_t? For example, MPI_Type_create_struct (page 86), should the count parameter be MPI_Size? Likewise, should the three integers output by MPI_Type_get_envelope (page 105) be MPI_Size? Or is this yet another distinct type, and if so, should we try to cover it in this ticket? Thanks, -Fab From david.solt at [hidden] Tue Oct 5 00:45:42 2010 From: david.solt at [hidden] (Solt, David George) Date: Tue, 5 Oct 2010 05:45:42 +0000 Subject: [Mpi3-bwcompat] MPI_Size and non-count int parameters In-Reply-To: <91B583BE4B6FCD408F53D1B8F537E092129B6E0D@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> Message-ID: For MPI_Type_create_struct, I really think that int is the correct type for a count. When we want to store some arbitrary integer value on a computer, we use an int to do that. To start saying that we expect structures to have so many fields that they won't fit into an int, then I think we are basically saying that int is useless and should never be used anywhere. When that is the case, its int's fault for not being large enough to hold anything useful, not our fault. The other argument is that I think MPI_Size was supposed to be a number of bytes, which wouldn't fit the use here. MPI_Type_get_envelope.... I think this should be easy. Is there any datatype creation call to create MYTYPE such that MPI_Type_get_envelope(MYTYPE,...) could possibly cause one of the 3 output's to overflow. If you look at the list of possible values for ni, na and nd (i.e max_integers, max_addresses, max_datatypes), these are often constants, but sometimes are dynamic, such as: If combiner is MPI_COMBINER_INDEXED then ni = 2*count+1. If we look at MPI_Type_indexed, we see that count is only an int, so this case does not require max_integers to be anything but an int. But we have to look at every case... If combiner is MPI_COMBINER_HINDEXED_INTEGER or MPI_COMBINER_HINDEXED than ni = count+1, na = count, but count for both of these routines is also an int. If combiner is MPI_COMBINER_INDEXED_BLOCK then ni = count+2, but count for this routine is an int. If combiner is MPI_COMBINER_STRUCT_INTEGER or MPI_COMBINER_STRUCT then ni = count+1, na = count, nd = count, which I recommend count=int in this case. If combiner is MPI_COMBINER_SUBARRAY then ni = 3*ndims+2. Ndims is an int. If combiner is MPI_COMBINER_DARRAY then ni = 4*ndims+4. Ndims is an int. So in all cases where these values are not constants, they are formed from datatype creation functions taking int's in the associated parameter location. Dave -----Original Message----- From: mpi3-bwcompat-bounces_at_[hidden] [mailto:mpi3-bwcompat-bounces_at_[hidden]] On Behalf Of Fab Tillier Sent: Tuesday, October 05, 2010 12:00 AM To: MPI-3 backwards compatability WG Subject: [Mpi3-bwcompat] MPI_Size and non-count int parameters Should MPI_Size be used where one would likely use size_t? For example, MPI_Type_create_struct (page 86), should the count parameter be MPI_Size? Likewise, should the three integers output by MPI_Type_get_envelope (page 105) be MPI_Size? Or is this yet another distinct type, and if so, should we try to cover it in this ticket? Thanks, -Fab _______________________________________________ Mpi3-bwcompat mailing list Mpi3-bwcompat_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-bwcompat From david.solt at [hidden] Tue Oct 5 10:43:43 2010 From: david.solt at [hidden] (Solt, David George) Date: Tue, 5 Oct 2010 15:43:43 +0000 Subject: [Mpi3-bwcompat] MPI Backward Compatibility Working Group In-Reply-To: Message-ID: > BTW, why are we using a ginormous CC list rather than the listserv address? That would be my fault and have something to do with replying to my outlook meeting which had individual e-mails stored for some unknown reason. > A different day. Don't you have some fancy website that does all the work for us and picks a good time? Dave -----Original Message----- From: Jeff Squyres [mailto:jsquyres_at_[hidden]] Sent: Tuesday, October 05, 2010 10:38 AM To: Quincey Koziol Cc: Solt, David George; Alexander Supalov; Fab Tillier; Graham, Richard L.; William Gropp; Terry Dontje; Darius Buntinas; Dave Goodell; Torsten Hoefler; MPI-3 backwards compatability WG Subject: Re: MPI Backward Compatibility Working Group We could pick a different day. BTW, why are we using a ginormous CC list rather than the listserv address? On Oct 5, 2010, at 11:24 AM, Quincey Koziol wrote: > > On Oct 5, 2010, at 10:04 AM, Solt, David George wrote: > >> I can do 9 PDT as long as we shift a week (for example, if our first meeting at this time was Oct 22). I don't want to mess up the regular attendees though, so only if it is not an issue for Quincey, Terry and Jeff. > > Hmm, 9PDT doesn't work for me, I've got a weekly meeting at that time. I can usually go to 8PDT or 10PDT though. > > Quincey > >> Thanks, >> Dave >> >> -----Original Message----- >> From: Supalov, Alexander [mailto:alexander.supalov_at_[hidden]] >> Sent: Tuesday, October 05, 2010 7:18 AM >> To: Fab Tillier; Solt, David George; Graham, Richard L.; Quincey Koziol; William Gropp; Terry D. Dontje; Jeff Squyres; Darius Buntinas; Dave Goodell; 'Torsten Hoefler' >> Subject: RE: MPI Backward Compatibility Working Group >> >> Thanks. 9 am PDT could work for me, too. >> >> -----Original Message----- >> From: Fab Tillier [mailto:ftillier_at_[hidden]] >> Sent: Friday, October 01, 2010 5:32 PM >> To: Supalov, Alexander; Solt, David George; Graham, Richard L.; Quincey Koziol; William Gropp; Terry D. Dontje; Jeff Squyres; Darius Buntinas; Dave Goodell; 'Torsten Hoefler' >> Subject: RE: MPI Backward Compatibility Working Group >> >> Hi Alexander, >> >> Supalov, Alexander wrote on Fri, 1 Oct 2010 at 01:56:00 >> >>> Hi, >>> >>> Have been watching this intently, but the new slot is way too late (7 >>> pm Friday) for me to attend regularly. We had an earlier slot in the >>> past. Why did this change? >> >> I can't make the 7AM meetings, it conflicts with getting the kids fed and off to school. >> >> I can certainly do 9AM if that would help in the future. >> >> -Fab >> >>> >>> Best regards. >>> >>> Alexander >>> >>> -----Original Message----- >>> From: Solt, David George [mailto:david.solt_at_[hidden]] >>> Sent: Thursday, September 30, 2010 10:58 PM >>> To: Supalov, Alexander; Graham, Richard L.; Quincey Koziol; William >>> Gropp; Terry D. Dontje; Jeff Squyres; Darius Buntinas; Dave Goodell; >>> 'Torsten Hoefler'; 'ftillier_at_[hidden]' >>> Subject: MPI Backward Compatibility Working Group >>> >>> We are meeting tomorrow. It is our last scheduled meeting before >>> Chicago, so hopefully it will be productive. Until MPI_Count is signed >>> off, it is our focus for now. You may want to look over the MPI_Count >>> ticket (https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/224) if you >>> haven't already been watching it. >>> >>> Thanks, >>> Dave >> -------------------------------------------------------------------------------------- >> 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 >> > -- 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] Tue Oct 5 10:58:36 2010 From: jsquyres at [hidden] (Jeff Squyres) Date: Tue, 5 Oct 2010 11:58:36 -0400 Subject: [Mpi3-bwcompat] MPI Backward Compatibility Working Group In-Reply-To: Message-ID: <02ED1393-CFC5-403F-917A-7B6A7D62C53A@cisco.com> On Oct 5, 2010, at 11:43 AM, Solt, David George wrote: >> A different day. > > Don't you have some fancy website that does all the work for us and picks a good time? Sure; I setup a web poll for the week of Oct 18. Answer this poll with "in general" in your mind -- like "in general, I can attend at 8am US Eastern time on Mondays" (even if you have a specific conflict in the week of Oct 18): http://www.doodle.com/epimhhs43n7w89a9 -- 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] Wed Oct 6 19:37:47 2010 From: ftillier at [hidden] (Fab Tillier) Date: Thu, 7 Oct 2010 00:37:47 +0000 Subject: [Mpi3-bwcompat] Ticket 224 updated Message-ID: <91B583BE4B6FCD408F53D1B8F537E092129B93B3@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> Hi Folks, Could someone with more experience in Fortran (i.e. any experience at all) please look at examples 5.15, 5.21, 13.9.2 and validate that I fixed them properly? I have no idea how you declare variables in Fortran... Other than that, the ticket is complete as far as I know. Let me know if you see issues. Thanks! -Fab From jsquyres at [hidden] Thu Oct 7 07:25:27 2010 From: jsquyres at [hidden] (Jeff Squyres) Date: Thu, 7 Oct 2010 08:25:27 -0400 Subject: [Mpi3-bwcompat] Ticket 224 updated In-Reply-To: <91B583BE4B6FCD408F53D1B8F537E092129B93B3@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> Message-ID: Looks good to me! On Oct 6, 2010, at 8:37 PM, Fab Tillier wrote: > Hi Folks, > > Could someone with more experience in Fortran (i.e. any experience at all) please look at examples 5.15, 5.21, 13.9.2 and validate that I fixed them properly? I have no idea how you declare variables in Fortran... > > Other than that, the ticket is complete as far as I know. Let me know if you see issues. > > Thanks! > -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 jsquyres at [hidden] Thu Oct 14 10:14:00 2010 From: jsquyres at [hidden] (Jeff Squyres) Date: Thu, 14 Oct 2010 11:14:00 -0400 Subject: [Mpi3-bwcompat] Teleconf tomorrow? Message-ID: <1B5A5874-D2A7-4713-B35E-C935D4BA270D@cisco.com> 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/ From koziol at [hidden] Thu Oct 14 10:15:40 2010 From: koziol at [hidden] (Quincey Koziol) Date: Thu, 14 Oct 2010 10:15:40 -0500 Subject: [Mpi3-bwcompat] Teleconf tomorrow? In-Reply-To: <1B5A5874-D2A7-4713-B35E-C935D4BA270D@cisco.com> Message-ID: 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 From david.solt at [hidden] Thu Oct 14 11:00:09 2010 From: david.solt at [hidden] (Solt, David George) Date: Thu, 14 Oct 2010 16:00:09 +0000 Subject: [Mpi3-bwcompat] Teleconf tomorrow? In-Reply-To: Message-ID: 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 From ftillier at [hidden] Thu Oct 14 13:54:43 2010 From: ftillier at [hidden] (Fab Tillier) Date: Thu, 14 Oct 2010 18:54:43 +0000 Subject: [Mpi3-bwcompat] Teleconf tomorrow? In-Reply-To: Message-ID: <91B583BE4B6FCD408F53D1B8F537E092129BD4A0@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> 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 From jsquyres at [hidden] Thu Oct 14 14:29:23 2010 From: jsquyres at [hidden] (Jeff Squyres) Date: Thu, 14 Oct 2010 15:29:23 -0400 Subject: [Mpi3-bwcompat] Teleconf tomorrow? In-Reply-To: <91B583BE4B6FCD408F53D1B8F537E092129BD4A0@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> Message-ID: <084DCCD9-01DE-4074-9830-4DB0EF5BD13C@cisco.com> 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/ From david.solt at [hidden] Thu Oct 14 17:21:06 2010 From: david.solt at [hidden] (Solt, David George) Date: Thu, 14 Oct 2010 22:21:06 +0000 Subject: [Mpi3-bwcompat] Teleconf tomorrow? In-Reply-To: <91B583BE4B6FCD408F53D1B8F537E092129BD4A0@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> Message-ID: 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 From ftillier at [hidden] Thu Oct 14 18:06:25 2010 From: ftillier at [hidden] (Fab Tillier) Date: Thu, 14 Oct 2010 23:06:25 +0000 Subject: [Mpi3-bwcompat] Teleconf tomorrow? In-Reply-To: Message-ID: <91B583BE4B6FCD408F53D1B8F537E092129BD68D@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> 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 From koziol at [hidden] Thu Oct 14 22:44:23 2010 From: koziol at [hidden] (Quincey Koziol) Date: Thu, 14 Oct 2010 22:44:23 -0500 Subject: [Mpi3-bwcompat] Teleconf tomorrow? In-Reply-To: <084DCCD9-01DE-4074-9830-4DB0EF5BD13C@cisco.com> Message-ID: 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 From ftillier at [hidden] Thu Oct 14 23:40:10 2010 From: ftillier at [hidden] (Fab Tillier) Date: Fri, 15 Oct 2010 04:40:10 +0000 Subject: [Mpi3-bwcompat] Teleconf tomorrow? In-Reply-To: Message-ID: <91B583BE4B6FCD408F53D1B8F537E092129BD8B3@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> 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 From jsquyres at [hidden] Fri Oct 15 05:32:04 2010 From: jsquyres at [hidden] (Jeff Squyres jsquyres) Date: Fri, 15 Oct 2010 06:32:04 -0400 Subject: [Mpi3-bwcompat] Teleconf tomorrow? In-Reply-To: <91B583BE4B6FCD408F53D1B8F537E092129BD8B3@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> Message-ID: 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" 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