[Mpi-forum] Significant discussion point with Ticket 269

Fab Tillier ftillier at microsoft.com
Thu Mar 17 01:14:31 CDT 2011

Hi Adam,

-----Original Message-----
From: mpi-forum-bounces at lists.mpi-forum.org [mailto:mpi-forum-bounces at lists.mpi-forum.org] On Behalf Of Adam T. Moody
Sent: Wednesday, March 16, 2011 5:47 PM

> The displacements in the new w functions are not semantically the same as in Alltoallw.
> See p 146, lines 41-44 vs p 169, line 26.  In alltoallw, the displacements are given in number
> of bytes from the start of the buffer, but for the new functions, they are given as an integer
> number of extents of the corresponding datatype.

The displacement parameters are identical in definition to those of the 'V' variants of those functions, only the datatype (recvtype and/or sendtype) was turned to an array and pluralized.  I had missed the difference between MPI_Alltoallv and MPI_Alltoallw, thanks for catching that.

> First, we should be consistent with alltoallw or otherwise use a suffix other than 'w'.

I don't know that we can succeed in achieving our goals of allowing users to use large datatypes if we change to byte counts without going to a different (larger) datatype - an 'int' may not be enough displacement for a single datatype.  If we are to change the suffix and use different parameters, let's not mess around with using integer counts and just go to MPI_Count too, not just the displacements.  If we consider going to MPI_Count for count parameters, we might as well just stick with a MPI_Count version of the 'v' functions and avoid the 'w' all together.

> Second, specifying the displacement in terms of datatype extents restricts some codes
> from using these functions.  For example, in gatherw, what if the root needs to receive a
> 2-byte datatype starting at byte position 1 in its receive buffer?  I don't think this can be done
> under the current definition.

Can't a user resize the datatype and set a LB so that the received datatype is offset by 1 byte?

> Third, if we decide to define the displacement in bytes, as alltoallw does, then we should really
> think about making the displacement datatype an MPI_Aint, or perhaps even MPI_Count.  Using
> an int datatype will lead to other problems.

If we change these new functions to use MPI_Aint, then we should really create a new version of Alltoallw to match.  There are other functions that use the wrong 'type' for parameters so we need to be careful about 'the slippery slope'.

Oy, the baggage we have to deal with to preserve back compat...


> -Adam
> _______________________________________________
> mpi-forum mailing list
> mpi-forum at lists.mpi-forum.org
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum

More information about the mpi-forum mailing list