[Mpi-forum] MPI Count proposal from today's meeting
Jeff Squyres (jsquyres)
jsquyres at cisco.com
Thu Jun 17 12:00:05 CDT 2010
So there might be some confusion; I can't tell from your text. The intent is that the mpi spec will only say that sizeof(mpi_count) is >= sizeof(int). An implementation can choose what the real size is. Some may choose to ship 2 libs: one with int and one with a 64 bit integer.
Sent from my PDA. No type good.
----- Original Message -----
From: mpi-forum-bounces at lists.mpi-forum.org <mpi-forum-bounces at lists.mpi-forum.org>
To: Main MPI Forum mailing list <mpi-forum at lists.mpi-forum.org>
Sent: Thu Jun 17 02:43:53 2010
Subject: Re: [Mpi-forum] MPI Count proposal from today's meeting
On Jun 16 2010, Jeff Squyres wrote:
>> I hope nobody is insane enough to define it as a 64-bit integer in ANY
>> implementation. The alternative to 'int' should be the integer suitable
>> for array indexing, which might be of any size from 16 bits (due to MPI
>> tag and other constraints) upwards. This is not just a nit-pick.
>Can you explain why?
Portability. Fixing sizes is a catastrophic idea, as one would have hoped
that people would have learnt over the past 40 years. Competently written
portable code is almost entirely word-size independent, and has been since
people started to write it. The Fortran standard has people that understand
that. The modern assumption that the industry has settled on 64-bit sizes
for all time is as deluded as all of its predecessors, though I agree that
I shall be retired when the next change comes.
A significant number of embedded systems use 16-bit indices and will
continue to do so for the forseeable future - advancing technology will not
ALWAYS be used to increase functionality, but often to reduce size (e.g.
wearable devices). I should sincerely hope that MPI code will run on those,
as well as on conventional supercomputers; mine will. And, no, that is not
purely a joke!
In particular, many hardware architectures, operating systems and other
environments have a simple switch to flick between rebuilding for different
sizes, and may not even have first-class support for 64-bit on all of them
(i.e. address addition mmay be native, and not handle 64-bit values
correctly). ALL that should be needed for a clean MPI application is to
recompile it, and currently is; let's not break that.
> I ask because the primary purpose for "count" arguments is not for array
> indexing. One of the use cases that users have asked for is to be able to
> send more than 2B elements without needing to build a datatype.
In all of the languages that MPI supports, the maximum size of an array
and the maximum value of an index are more-or-less required to be the same.
Except for I/O, MPI does not support an indexless streaming facility.
mpi-forum mailing list
mpi-forum at lists.mpi-forum.org
More information about the mpi-forum