This web mail archive is frozen.
This page is part of a frozen web archive of this mailing list.
You can still navigate around this archive, but know that no new mails
have been added to it since July of 2016.
Click here to be taken to the new web archives of this list; it includes all the mails that are in this frozen archive plus all new mails that have been sent to the list since it was migrated to the new archives.
On Jul 16, 2013, at 23:11 , "David Goodell (dgoodell)" <dgoodell_at_[hidden]> wrote:
> On Jul 16, 2013, at 4:03 PM, George Bosilca <bosilca_at_[hidden]>
>> On Jul 16, 2013, at 22:29 , Jeff Squyres (jsquyres) <jsquyres_at_[hidden]> wrote:
>>> On Jul 16, 2013, at 4:22 PM, George Bosilca <bosilca_at_[hidden]> wrote:
>>>> Btw, I have a question to you fellow MPI Forum attendees. I just can't remember why the MPI forum felt there was a need for the MPI_Type_get[_true]_extent_x? MPI_Count can't be bigger than MPI_Aint,
>>> Yes, it can -- it has to be the largest integer type (i.e., it even has to be able to handle an MPI_Offset).
>> Technicalities! In the entire standard MPI_Offset is only used to access files, not to build datatypes. As such there is no way to have the extent of an datatype bigger than MPI_Aint.
> That's not true. You can obtain a datatype with an extent outside the range of an MPI_Aint by nesting types. Just create a config of size 1, then create a type a very large extent from your contig with MPI_Type_create_resized, then create a second contig of that resized with a count >1.
Sure. But the only reason you create such a nested type is to access files (otherwise you can't go over the MPI_Aint boundary safely). Thus I would have expected the limit to be similar to MPI_Offset and not a new type MPI_Count
Oh I see now. MPI_Aint is the largest difference in memory and MPI_Offset is the largest difference for files. Thus, MPI_Count is the largest of the two, so it can adapt in all cases. I'm happy with this conclusion
>> Thus, these accessors returning MPI_Count are a useless overkill, as they cannot offer more precision that what the version returning MPI_Aint is already offering.
>> PS: I hope nobody has the idea to define the MPI_Offset as a signed type
> Not sure if you're joking here... MPI_Offset must also be signed, again, for Fortran interoperability.
> devel mailing list