Next postscript will contain the new version for chapter 4. I made all the
changes we discussed (I hope), and also made a few corrections. Also, I tried
to mark clearly alternatives and items for discussion.
I made one additional signifcant change with respect to the previous version,
that brings us back closer to the version that Paul wrote: namely I assume
that the window is tiled by a basic MPI datatype. One can still specify a
target datatype in a get or put, but this datatype must be built of the basic
window datatype. Thus, we lack the ability to put or get heterogenous data,
and do pointer chasing.
The reason for this retreat is that datatypes defined with MPI_TYPE_HVECTOR,
MPI_TYPE_HINDEXED and MPI_TYPE_STRUCT, i.e., datatypes defined with byte
displacements, are not portable. It is not obvious how one should translate
the definition of a datatype when it is moved from one architecture to
another. Should we keep the same absolute byte displacements? If not, how do
we scale them? Thus, it makes not much sense to use such type as a target
datatype.
If we restrict ourselves to datatypes built with MPI_TYPE_CONTIGUOUS,
MPI_TYPE_VECTOR and MPI_TYPE_INDEXED, then the problem disappear, since all
displacements are multiples of the extent of one basic MPI datatype; when we
move to another architecture, we scale according to the extent of that same
basic datatype.
Thus, windows will be tiled with one basic MPI datatype and target datatypes
used to access such window will be built from this basic datatype using only
the last three datatype constructors.
This simplifies the text, which might please a few people. We can consider
again, at a later time, how we might still do pointer chasing in this
framework.
By the way, this problem indicates it would be nice to be able to build
datatypes for structures without using byte displacements, but just by
concatenating fileds of different datatypes. This would also slove the
problem of "hole conservation" when one transfer structures, and would
simplify the definition of datatypes for such structures.
Pls send back your comments asap, as I need to send the final version for
Super95 next week.
P.S. I asked for help re support for pointers in various Fortran 77
compilers (Cray or C like pointers). I GOT NO ANSWER SO FAR. Vendors,
implementors, please help.
-------------------
Marc Snir
IBM T.J. Watson Research Center
P.O. Box 218, Yorktown Heights, NY 10598
email: snir@watson.ibm.com
phone: 914-945-3204
fax: 914-945-4425