[MPICH] About extent and size of datatype?
Ruini Xue
xueruini at gmail.com
Tue Dec 11 00:52:52 CST 2007
hello,
I am a little confused by the *extent* and *size* of derived datatypes. In
my opinion, `*extent*' includes the additional `padding spaces' introduced
by non-continuous displacements of blocks in the datatype, while
*`size'*only counts the `useful' bytes which do not include the
padding spaces.
Generally, the `*extent*' of a datatype is not smaller then its `*size*'. As
far as I know, some blocks in derived datatypes have negative displacements,
thus their `*extents*' might be smaller than their `*sizes*'.
So the questions are "*how many bytes does MPI_Send() really send out if the
datatype has a bigger extent than its size?*" and "*how does the
corresponding MPI_Recv() place the received data?*" I goes through the
MPICH2 code, and got a blur big picture. It seems that MPI_Send() sends the
datetype in compacted format, in other word, only *MPI_Type_size(datatype) *
count* bytes are sent, but not *MPI_Type_extent(datatype) * count.
*Accordingly,
MPI_Recv() only receives *MPI_Type_size(datatype) * count* bytes from the
sender, and these bytes are unpacked to the receive buffer according to the
definition of the datatype. In other words, padding spaces are inserted in
the receive buffer if necessary while unpacking the received data. This
optimization is reasonable: to reduce the amount of transfer data, while
holding the semantics of derived types.
To conclude, only useful bytes are transfered, while both the send and
receive buff should be big enough to hold the 'whole datatype'.
Is my understanding right? Please let me know any mistake I made.
Thanks in advance!
Best
Andrew
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/mpich-discuss/attachments/20071211/983c9b56/attachment.htm>
More information about the mpich-discuss
mailing list