[Mpi3-bwcompat] Teleconf tomorrow?

[Fab Tillier]

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