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