On Jul 16, 2013, at 23:11 , "David Goodell (dgoodell)" <dgood...@cisco.com> wrote:
> On Jul 16, 2013, at 4:03 PM, George Bosilca <bosi...@icl.utk.edu> > wrote: > >> On Jul 16, 2013, at 22:29 , Jeff Squyres (jsquyres) <jsquy...@cisco.com> >> wrote: >> >>> On Jul 16, 2013, at 4:22 PM, George Bosilca <bosi...@icl.utk.edu> 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 … Thanks everyone. George. > >> 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. >> >> George. >> >> 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. > > -Dave > > > _______________________________________________ > devel mailing list > de...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/devel
