[Mpi3-bwcompat] call minutes 2010.5.28

[Quincey Koziol]

On May 28, 2010, at 5:02 PM, Jeff Squyres wrote:

> The short version here is: the Forum has hated all other approaches so far.  So this is the returning to the "rip off the band aid" proposal.  It puts us in the best position for the future and, all things being equal, may well be the proposal that sucks the least.  I believe that we can have reasonable answers to all the negative points that have previously been raised against this proposal.
> 
> We're not fixing the underlying problem (e.g., what do we do for the next MPI_COUNT-like issue that comes along), but it is a solid proposal for moving forward with MPI_COUNT.

        Works for me.  We just need to fix it - I'm getting more bug reports about this issue lately... :-/

        Quincey

> On May 28, 2010, at 5:18 PM, Fab Tillier wrote:
> 
>> Attendees: Dave Goodell, Jeff Squyres, Fab Tillier
>> 
>> - Failbook, Lamebook, and @BPGlobalPR good time sinks while waiting for folks to call in.
>> - Forum keeps going in circles on how to handle MPI_COUNT, enough so that David Solt gave up.
>> - Discussing this issue for quite some time (started in Portland last November as far as I know, maybe earlier.)
>> - No proposed solution has been satisfactory to the majority of forum members.
>> 
>> Summary of proposed solutions to date (please help flush this out, as I am lacking context):
>> 1. Define MPI_COUNT only for MPI-IO functions.  Rejected: needs some changes in MPI_Get_count, etc, which have ramifications on other APIs, or introduce new MPI_Get_count_xxx.
>> 2. Define MPI_COUNT for all functions.  Rejected: why touch functions were a need hasn't been demonstrated (you can send more than 2^31 elements by creating datatypes.)
>> 3. Define MPI_COUNT for new functions that have some kind of suffix.  Rejected: what is the proper suffix, how do you handle exponential growth when you introduce the next suffix, blows up API surface area.
>> 
>> Action Items:
>> - Fab: Put together slides for June meeting (short on time, if everyone can send me or point me to slides related to this that were previously presented, please do.)
>> - Quincey, and everyone else: Make sure this is palatable to you
>> - Everyone: help Fab make a good presentation. :)
>> 
>> Plan:
>> Propose MPI_COUNT for all functions, define MPI_COUNT as >= int, allowing backward compatibility while also allowing moving forward.  No requirement to support either int or >int - that's an implementation choice.
>> 
>> Benefits:
>> - lets implementers respond to customer demand without breaking backward compatibility for existing codes (ABI can be kept identical if MPI_COUNT defined as int.)
>> - keeps API surface area manageable for implementers that don't support MPI_COUNT > int.
>> 
>> Disadvantages:
>> - doubles test surface area for implementers providing both int and > int implementations
>> - MPI_COUNT > int breaks F77?  Jeff says we don't care, as there aren't any F77 compilers anymore, and the F90 and newer compilers are fine with this.
>> - doesn't set precedent for how to handle changes like this in the future.
>> 
>> Questions:
>> - Do we allow implementations to provide both int and > int support simultaneously for Fortran using polymorphism?
>> 
>> Jeff, Dave, please fill in if I've missed something.
>> -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/
> 
> 
> _______________________________________________
> Mpi3-bwcompat mailing list
> Mpi3-bwcompat_at_[hidden]
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-bwcompat