- In 4.3.1, MPI_PUT, argument target_datatype
I think that there is a little error in page 28, line 45:
Correct is
The origin_datatype and the target_datatype ...
instead of only
The target_type ...
- In 4.3.1, MPI_PUT, argument target_datatype
I think that the following clarification is necessary:
I propose to append after page 29, line 2:
The target_datatype handle must be a constant or must be
derived on the origin process although the target_datatype is
used to receive the data on the target process.
Reasons:
Reading page 28, lines 41+42 "and the target process executes
a receive operation with the arguments target_addr,
target_count, target_datatype" the application programmer can
think that he must compute the target_datatype handle on the
target process and then he must send its value to the origin
process where it can be used then in the MPI_PUT argument list.
- The following proposal addresses the following parts:
In 4.2, MPI_RMA_INIT
- page 24, lines 40+41: "... where type is a basic MPI datatype."
- page 25, lines 26-38: Discussion 2. Window type is basic.
and in 4.3.1, MPI_PUT
- page 28, lines 45ff:
"the target_type argument can be a basic datatype identical
to the window type; it can be a derived datatype constructed
from this basic datatype, using the type constructors
MPI_TYPE_CONTIGUOUS, MPI_TYPE_VECTOR and MPI_TYPE_INDEXED;
i.e. ..."
and in 9.3.1, Contiguous Struct Types:
- definition of MPI_TYPE_CONTIGOUS_STRUCT
and the posting from Marc Snir, Sat, 25 Nov 1995 22:46:05 -0500
> 3. general datatype in the definition of windows.
>
> The window type is specified by the target process. The
> target_datatype argument is defined by the origin process, and
> provided as argument in the put/get call.
> We need to specify which buffer in the target memory is specified by
> the target datatype argument, and what it means for that argument to
> be compatible with the window type. There is no obvious way of doing so,
> for datatypes that carry absolute displacements, since there is no
> obvious way of "converting" general datatypes, in a heterogeneous
> environment. We clearly do not want to preserve the absolute value
> of the displacement, but we do not have enough information to translate
> them. Therefore, we need to restrict ourselves
> and use only "portable" datatypes as target datatype arguments in put/get
> calls. A datatype is portable if it was defined using only
> MPI_TYPE_CONTIGOUS, MPI_TYPE_VECTOR and MPI_TYPE_INDEXED. I.e., if all fields
> are of the same basic datatype, and all displacements are multiples of that
> same basic datatype extent.
>
> If the window type is also a "portable" datatype, then we have gained
> no generality as compared to defining the window to be of the base
> datatype from which this gneral datatype is derived.
> Suppose now that the window type is "non-portable", e.g., defined by
> MPI_TYPE_STRUCT. Then, each put/get operation will still only be able to
> access a "homogeneous" part of the target window -- an area where all
> elements accessed have the same basic type and all displacements
> between these elements are multiples of that basic type extent.
> Furthermore, we shall now need a byte displacement to start of
> the target buffer, rather than an element count. Thus, we have gained
> little additional power, at the expense of more complexity in
> definition and implementation.
New ideas for the discussion:
(parts of this were discussed in Vienna, but I think not all)
-- With the new MPI_TYPE_CONTIGOUS_STRUCT there is a new
possibility to define portable mixed-typed datatypes.
In a heterogeneous environment the processes had only
to communicate the extend and alignment information of
the basic datatypes at the initialization of MPI or RMC.
-- There is no reason to forbid typical Fortran programming:
Equivalencing an INTEGER, REAL and DOUBLEPRECISION array.
In RMC this means:
The window datatype is e.g. INTEGER and the positioning
is done at the target by defining a displacement in
multiples of INTEGER, but then DOUBLEPRECISION values
are stored there.
-- There is no reason to restrict the datatype in PUT/GET
to one basic datatype in a window.
But there is a good reason that the application programmer
must not be involved in byte displacements because e.g. in
the PUT operation he had to compute the displacements of the
target host on the origin host.
Therefore I propose:
In MPI_RMA_INIT, MPI_RMA_MALLOC, ..., MPI_PUT, MPI_GET, ...
all datatypes are allowed to be basic MPI datatypes and
derived datatypes constructed with MPI_TYPE_CONTIGUOUS,
MPI_TYPE_CONTIGOUS_STRUCT, MPI_TYPE_VECTOR and
MPI_TYPE_INDEXED.
Because I started my MPI-2 activities with the forum meeting in
Vienna, it can be that some of my proposals are discussed already,
then I'm sorry that I have not read the whole history of that
chapter.
Rolf
Rolf Rabenseifner (Computer Center )
Rechenzentrum Universitaet Stuttgart (University of Stuttgart)
Allmandring 30 Phone: ++49 711 6855530
D-70550 Stuttgart 80 FAX: ++49 711 6787626
Germany rabenseifner@rus.uni-stuttgart.de