[Mpi3-bwcompat] ticket 265 udpated

[Jeff Squyres]

On Mar 3, 2011, at 3:30 PM, Fab Tillier wrote:

> 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

--enable-picky

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

> 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?

> 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".

> 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.

> 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).


-- 
Jeff Squyres
jsquyres_at_[hidden]
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/