[Mpi-forum] MPI_Type_size question

Richard Treumann treumann at us.ibm.com
Mon Jun 21 07:11:08 CDT 2010






I once proposed that the standard should have something that can be used
for any integer that has a range implied by the address range.  MPI_Aint is
billed as an address but the problem goes beyond adresses.

I thought something like MPI_Sint (Size int) would have been a good idea
from day one.  I have not thought through the implications of adding
MPI_Sint now but it would be as good as MPI_Count for that role and perhaps
be applicable to some other cases too.

This is just a thought. I do not have time at this point to really dig into
what it would mean for the MPI 3 document

              Dick

Dick Treumann  -  MPI Team
IBM Systems & Technology Group
Dept X2ZA / MS P963 -- 2455 South Road -- Poughkeepsie, NY 12601
Tele (845) 433-7846         Fax (845) 433-8363


mpi-forum-bounces at lists.mpi-forum.org wrote on 06/19/2010 10:47:53 AM:

> [image removed]
>
> Re: [Mpi-forum] MPI_Type_size question
>
> William Gropp
>
> to:
>
> Main MPI Forum mailing list
>
> 06/19/2010 10:51 AM
>
> Sent by:
>
> mpi-forum-bounces at lists.mpi-forum.org
>
> Please respond to Main MPI Forum mailing list
>
> The standard doesn't say, but to me, the correct answer would be to
> return an error with class MPI_ERR_OTHER.  This follows the approach
> of providing reliable failure when there is an error, with the user
> able to set ERRORS_RETURN and check for the error.  Returning
> MPI_UNDEFINED allows the casual user to ignore the error, which is not
> the MPI approach to errors.
>
> As to how to fix this, if we insist on backward compatibility, then we
> need new routines, or we need another new type so that we can do the
> same MPI_Count trick (which doesn't fix the problem but lets
> implementations choose between backward compatibility and forward
> compatibility).
>
> Bill
>
> On Jun 18, 2010, at 11:55 AM, Fab Tillier wrote:
>
> > Hi Folks,
> >
> > Looking at putting together the MPI_Count ticket, I ran across the
> > following issue and was hoping to get some guidance.  Take the
> > following code, using the current int counts, and assume sizeof(int)
> > == 4, sizeof(MPI_DOUBLE) == 8:
> >
> > {
> >   MPI_Datatype myType;
> >   MPI_Type_contiguous( 1048576, MPI_DOUBLE, &myType );
> >
> >   int size;
> >   MPI_Type_size( myType, &size );
> > }
> >
> > Should MPI_Type_size return an error, due to overflow?  Does size
> > get set to MPI_UNDEFINED and the call succeeds?
> >
> > Similar issues exist for MPI_Pack with the outsize and position
> > parameters, MPI_Unpack with the insize and position parameters, and
> > MPI_Pack_size with the size parameter.
> >
> > Lastly, it is my belief that these parameters should really be of
> > type MPI_Aint, but changing this would break backward
> > compatibility.  They cannot be of type MPI_Count, since overflow can
> > occur if MPI_Count is defined as a C int.  How should the standard
> > handle this?
> >
> > Thoughts?
> > -Fab
> >
> > _______________________________________________
> > mpi-forum mailing list
> > mpi-forum at lists.mpi-forum.org
> > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum
>
> William Gropp
> Deputy Director for Research
> Institute for Advanced Computing Applications and Technologies
> Paul and Cynthia Saylor Professor of Computer Science
> University of Illinois Urbana-Champaign
>
>
>
>
> _______________________________________________
> mpi-forum mailing list
> mpi-forum at lists.mpi-forum.org
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mpi-forum.org/pipermail/mpi-forum/attachments/20100621/7f46951f/attachment-0001.html>


More information about the mpi-forum mailing list