[Mpi-forum] MPI_Count

[Snir, Marc]

at least 64 bits would work, but I would not worry about 128 bits. Running out of 64 bit addresses will take 64 years, if we assume memory doubling every 2 years.

On Jan 24, 2010, at 8:33 PM, Bronis R. de Supinski wrote:

> 
> Marc:
> 
> I was thinking about this before the email discussion. I
> came to the conclusion that we should require them to be
> at LEAST 64 bit integers, However, the hope was to avoid
> this type of problem in the future by using the MPI_Count
> type. That way, we do not need to change the interface in
> some many years from now when we want 128 bit integers;
> we only need to update the standard to require at LEAST
> 128 bit integers...
> 
> Bronis
> 
> 
> On Sun, 24 Jan 2010, Snir, Marc wrote:
> 
>> I can understand the decision to change only the file I/O functions -- this is where the issue is most burning.
>> I also understand the decision to replicate functions that change so that there will be on version keeps the current behavior and a new function with a changed behavior -- this provides a transition period where old codes.
>> 
>> I do not understand the advantage of using a type MPI_COUNT that could be, in some implementations, a 32 bit integer, and on others, a 64 bit integer; in some a long and in others a long long. This, rather than defining the new functions to take 64 bit integer count arguments.
>> 
>>> From the view-point of implementers, this saves little headache, since we discuss only few functions. From the viewpoint of users, this makes the new functions hard to use. Most programmers expect to run their MPI codes on different platforms, and care about portability. If MPI_COUNT is a 32 bit integer on some platforms and 64 bit integer on others, then portable code can pass only a value that is less than 2^31 as a count argument. In particular, it will be dangerous to pass a long or  long long value. It also seems gratuitous to have a type MPI_COUNT that need not correspond to any specific native type in C or Fortran.  Users expect that the arguments of a library would use types that are defined in the calling programming language -- why introduce an implementation dependence in that correspondence?
>> 
>> I would suggest to use explicitly 64 bit integers as the type of count in the new functions. I.e., int64_t in C and INTEGER(KIND=8) in Fortran. Both types are part of the (C/Fortran) standard.
>> 
>> On Jan 22, 2010, at 2:06 PM, Jeff Squyres wrote:
>> 
>>> Please note that there was a bunch of discussion about MPI_Count and other compatibility issues at the meeting in Atlanta this week.  I posted a summary of takeaways from the discussion on the bwcompat WG mailing list and wiki:
>>> 
>>>   https://*svn.mpi-forum.org/trac/mpi-forum-web/wiki/BackCompatMeetings
>>>   http://*lists.mpi-forum.org/mpi3-bwcompat/2010/01/0024.php
>>> 
>>> Although there are still some decisions to be made (e.g., about Fortran), a surprising amount of consensus emerged.  Please read up on the notes to see what was discussed -- please chime in ASAP if you have dissenting views.
>>> 
>>> Thanks!
>>> 
>>> --
>>> Jeff Squyres
>>> jsquyres at cisco.com
>>> 
>>> 
>>> _______________________________________________
>>> mpi-forum mailing list
>>> mpi-forum at lists.mpi-forum.org
>>> http://*lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum
>> 
>> Marc Snir
>> 
>> 
>> 
>> 
>> 
>> _______________________________________________
>> mpi-forum mailing list
>> mpi-forum at lists.mpi-forum.org
>> http://*lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum
>> 
>> 
> _______________________________________________
> mpi-forum mailing list
> mpi-forum at lists.mpi-forum.org
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum

Marc Snir