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

[Quincey Koziol]

Hi Fab,

On Jul 9, 2010, at 12:26 AM, Fab Tillier wrote:

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

        I still think aliasing MPI_Size and MPI_Count will cause problems down the line, since the two concepts are different.  I'd be much happier with separating them now rather than having to change things that are switched from int to MPI_Size now to MPI_Count later.

                Quincey

> 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
> 
> _______________________________________________
> Mpi3-bwcompat mailing list
> Mpi3-bwcompat_at_[hidden]
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-bwcompat