[Mpi3-bwcompat] MPI_Count mixing with int...

[Fab Tillier]

Rajeev Thakur wrote on Thu, 8 Jul 2010 at 22:06:24

> Yes, that is a long standing problem -- that datatypes use MPI_Aint
> (wherever they do), but they really need to use the larger of MPI_Aint
> or MPI_Offset.

So an 'optimal' implementation would be one where MPI_Aint, MPI_Offset, MPI_Count, and MPI_Size all map to the same underlying type.

Ugh, this is getting messy quickly.  I think I'll just deal with the MPI_Count and MPI_Size issues, ignoring the MPI_Aint/MPI_Offset issues.  Some poor soul a decade from now will likely curse me for it, but I don't want to get into deprecating a bunch of functions (those with Aint) to normalize them too.

So to summarize, my plan is as follows:
1. Define MPI_Size (instead of MPI_Count)
2. Use MPI_Size as the type for all size, count, and position variables.
3. Ignore MPI_Aint and MPI_Offset inconsistencies.

If anyone has issues with this, please holler sooner than later.

Thanks,
-Fab

> 
>> -----Original Message-----
>> From: Fab Tillier
>> Sent: Thursday, July 08, 2010 11:20 PM
>> 
>> Rajeev Thakur wrote on Thu, 8 Jul 2010 at 18:24:16
>> 
>>> You can define a filetype that is many Gbytes and read only a small
>>> part of it. The filetype is specified in MPI_File_set_view and is not
>>> passed in the read/write calls. The datatype passed in the read/write
>>> calls refers to the buffer passed to that call.
>> 
>> Perfect, thanks for the example!  Does this imply that
>> MPI_Type_get_extent, which returns an MPI_Aint, might
>> overflow the extent parameter on a 32-bit platform on which a
>> user defines a many Gbyte filetype?  How should we address
>> this (there are probably other APIs affected similarly)?
>> 
>> -Fab
>> 
>>>> -----Original Message-----
>>>> From: Fab Tillier
>>>> Sent: Thursday, July 08, 2010 3:32 PM
>>>> 
>>>> Rajeev Thakur wrote on Thu, 8 Jul 2010 at 12:52:58
>>>> 
>>>>>> As an aside, can count ever be larger than size_t?
>>>>> 
>>>>> Probably not in the communication or I/O functions since count
>>>>> refers to the number of items in the memory buffer, but it could be
>>>>> for the datatype constructor functions since datatypes can
>>>> represent file layout.
>>>> 
>>>> How would you use a datatype that is larger than your address space?
>>>> You can't read or write it, you can't send or receive it, you can't
>>>> pack/unpack it...
>>>> 
>>>> Am I missing something and a datatype like this would be useful?
>>>> 
>>>> -Fab