[Mpi-forum] MPI Count proposal from today's meeting

[Jeff Squyres (jsquyres)]

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. 

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


Regards,
Nick Maclaren.


_______________________________________________
mpi-forum mailing list
mpi-forum at lists.mpi-forum.org
http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum