[Mpi3-bwcompat] MPI Backward Compatibility Working Group
Rajeev Thakur
thakur at [hidden]
Fri Mar 11 23:20:46 CST 2011
Could we say that MPI_Count should be the larger of MPI_Aint and MPI_Offset? (Anything bigger than that is not really useful.) That might help the I/O problem better.
Rajeev
On Mar 11, 2011, at 11:07 PM, Fab Tillier wrote:
> Hi Rajeev,
>
> A data buffer can't be larger than MPI_Aint in memory, but an MPI Datatype can be larger than what can fit in memory, and thus larger than MPI_Aint. MPI_Count allows such large datatypes to be represented and used in MPI, even if they can't be held in memory all at once.
>
> This proposal is intended to (minimally) solve the I/O problem, not just large network transfers.
>
> Does that make sense?
> -Fab
>
> -----Original Message-----
> From: mpi3-bwcompat-bounces_at_[hidden] [mailto:mpi3-bwcompat-bounces_at_[hidden]] On Behalf Of Rajeev Thakur
> Sent: Friday, March 11, 2011 8:06 PM
> To: MPI-3 backwards compatability WG
> Subject: Re: [Mpi3-bwcompat] MPI Backward Compatibility Working Group
>
> What was the motivation for the new MPI_Type_get_extent_x and MPI_Type_get_true_extent_x functions?
>
> If we say MPI_Count should be at least as large as MPI_Aint, why can't we just use MPI_Aint instead? The data buffer can't be larger than Aint size. I know that for I/O MPI_Offset can be larger than Aint, but this proposal does not solve the I/O problem as far as I know.
>
> https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/265
>
> Rajeev
>
>
>
> On Mar 11, 2011, at 5:06 PM, Solt, David George wrote:
>
>> During our meeting today we decided that MPI_Count should be at least as large as an MPI_Aint. We already had the restriction that it had to be as large as a C/Fortran integer. We want both restrictions (they cannot be combined because there is no guarantee that MPI_Aint > integer).
>>
>> I'll throw this out as a starting point for discussion:
>>
>>
>>
>>
>> 2.5.8 Last sentence change to:
>>
>> The size of the MPI_Count type is determined by the MPI implementation
>> with the restriction that it must be minimally capable of encoding a C
>> int and Fortran INTEGER and any value that may be stored in an MPI_Aint type.
>>
>> Rational thingy:
>>
>> MPI_Count is used to communicate both the number of elements in a datatype and the bounds of a datatype.
>> The number of elements in a datatype is specified at creation time using a C int or Fortran INTEGER. The bounds
>> may be specified using an MPI_Aint.
>>
>>
>> So, I was especially brief here. I did not want to get into the "new" routines vs. "old routines", but if you attempt to go into more depth than what I said, you will inevitably end up going down that path. I can think of a thousand ways not to say it, but its hard to come up with a good way.
>> Dave
>>
>> _______________________________________________
>> Mpi3-bwcompat mailing list
>> Mpi3-bwcompat_at_[hidden]
>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-bwcompat
>
>
> _______________________________________________
> Mpi3-bwcompat mailing list
> Mpi3-bwcompat_at_[hidden]
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-bwcompat
>
>
> _______________________________________________
> Mpi3-bwcompat mailing list
> Mpi3-bwcompat_at_[hidden]
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-bwcompat
More information about the Mpi3-bwcompat
mailing list