[Mpi3-bwcompat] ticket 265 udpated

[Fab Tillier]

Jeff Squyres wrote on Thu, 3 Mar 2011 at 12:54:06

> On Mar 3, 2011, at 3:30 PM, Fab Tillier wrote:
> 
>> 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.
> 
> Eh; I don't care about the weak symbol feature.
> 
> I see your point about some MPI's not caring about 64 bit counts; they could
> just return MPI_UNDEFINED or somesuch...?

That would break applications that wanted to be count-aware, who would now have to special-code things depending on whether the targeted MPI implementation supported MPI_Count properly.  Also, why would an implementation define MPI_Count as int64 and then fail all the calls that take it, when it is valid for them to define MPI_Count as int and alias the X calls to the non-X calls?

I suppose we'd have to add another API to query whether 64-bit count was supported, and then app code would be peppered with if/else sections to handle the two cases.  Seems like a really bad user experience.

>> 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.
> 
> How so?

The exact same reason we have MPI_Aint, rather than different MPI_xxx and MPI_xxx64 versions of calls that currently use MPI_Aint.

>> Codes that use MPI_Count would have to recompile when the value of
>> MPI_Count changes, but no source changes should be necessary.
> 
> The key word there being "should".

Any such changes are caused by improper application structure in the first place and should be fixed anyway.

>> 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.
> 
> My point is that we shouldn't add one *more* thing that makes ABI difficult.

The ABI argument seems really weak to me, especially given the lackluster interest in ABI in the Forum, and the difficulty in defining an ABI that spans operating systems and CPU architectures.

>> A recompile when moving from 64-bit to 128-bit is really going to be the
>> least of people's problems.
> 
> That's not the issue here -- what if they just get an MPI that supports 128 bit
> filesystems (that already exist, BTW)?  So it's not necessarily that the whole
> hardware is 128-bit capable, but rather some parts of their app may be able
> to use 128 bit support (although probably not in the near future).

Using MPI_Count lets them use such already existing 128-bit file systems (as well as 32- and 64-bit file systems) so I don't understand how this supports your argument.  If there are already 128-bit file systems, shouldn't we add both the 64 and 128 versions of these functions now if we go with explicit sizes?

-Fab