[Mpi3-bwcompat] ticket 265 udpated

[Fab Tillier]

Jeff Squyres wrote on Thu, 3 Mar 2011 at 08:36:28

> I have a terrible thought -- don't shoot me...
> 
> What if we don't introduce MPI_Count, but instead introduce the same new
> functions with explicitly-sized parameters?  E.g.:
> 
> int MPI_Type_get_extent64(MPI_Datatype datatype, MPI_Count *lb,
> uint64_t *extent)

You forgot to fix 'lb'.  Also, it needs to be a signed value so that sentinel values such as MPI_UNDEFINED can exist.  So there.  :P

> int MPI_Get_elements64(MPI_Status *status, MPI_Datatype datatype,
> uint64_t *count)
> 
> My rationale here is that we have a way to move forward with arbitrary sizes
> in the future, and MPI implementations don't have to make the (sometimes
> monumental) decision about changing the size of their MPI_Count datatype.
> Specifically: ABI issues are not trifling.  Changing the size of MPI_Count might
> be a Big Deal to some implementations and (enterprise) customers.

Having explicit 64-bit support might be a Big Deal to some implementations that don't care about large counts.  One of the goals of abstracting the count is that it allows those who don't care to define MPI_Count as int, and just have the X functions weak symbols for the non-X functions.

> If the MPI spec needs 128-bit versions someday, we can just add
> MPI_Type_get_extent128 (etc.).  But the 64 bit versions (and the int version)
> would certainly still be available with no ambiguity.
> 
> The function name implies an explicitly clear size of the parameter, so
> developers shouldn't get confused at all.  I believe there's also precent for
> "64" as a suffix in POSIX and other APIs...?

There's also precedent for variable width parameters such as size_t (and long in Linux) that also break ABI when the type changes size, but that hasn't been a problem - if anything it has allowed programs to be more portable rather than less.

Codes that use MPI_Count would have to recompile when the value of MPI_Count changes, but no source changes should be necessary.  The whole issue of ABI is so much bigger than this (how do you handle string lengths, how do you handle pre-defined constants like MPI_COMM_WORLD, etc...) that MPI_Count changing size is really minor.  A recompile when moving from 64-bit to 128-bit is really going to be the least of people's problems.

That said, once MPI_Count is approved, I look forward to your proposal to change it from MPI_Count to int64.

-Fab

> On Mar 2, 2011, at 8:28 PM, Fab Tillier wrote:
> 
>> Hi Folks,
>> 
>> I've updated ticket 265 with the comments from the last meeting.  Please
> take a look.  We'll go over the PDF on Friday (right David?) and hopefully
> agree that it's ready to send out for wider review.
>> 
>> TBD still (I think) is whether to split it into two tickets, one for
>> the basic functionality, the other for the new 'w' collectives.
>> 
>> https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/265
>> 
>> -Fab
>> 
>> _______________________________________________
>> Mpi3-bwcompat mailing list
>> Mpi3-bwcompat_at_[hidden]
>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-bwcompat
> 
>