[mpi-21] Intended meaning of zero blocklengths in MPI_Type_indexed/MPI_Type_create_struct
Richard Treumann
treumann at [hidden]
Tue Jan 29 12:26:04 CST 2008
How about this?
Most datatype constructors have replication count or block
length arguments. Allowed values are nonnegative integers.
If the value is zero, no elements are generated in the type map
and there is no effect on datatype bounds or extent.
I think it is bounds and extent that were questioned. I think it is self
evident that a zero value cannot affect the type signature.
Dick Treumann - MPI Team/TCEM
IBM Systems & Technology Group
Dept 0lva / MS P963 -- 2455 South Road -- Poughkeepsie, NY 12601
Tele (845) 433-7846 Fax (845) 433-8363
mpi-21-bounces_at_[hidden] wrote on 01/29/2008 12:43:02 PM:
> This is a proposal for MPI 2.1, Ballot 4.
>
> This is a follow up to:
> Block lengths of zero in MPI Datatypes
> in http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi-
> errata/index.html
> with mail discussion in
> http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi-
> errata/discuss/blklenzero/
> ___________________________________
>
> Proposal:
> Add the following paragraph in MPI 1.1, Sect. 3.12, page 62,
> after line 2 (i.e., after ... "of the types defined by Typesig."):
>
> Most datatype constructors have replication count or block
> length arguments. Allowed values are nonnegative integers.
> If the value is zero, no elements are generated in the type map
> nor in the type signature for this entry in the argument list.
>
> MPI 1.1, Sect 3.12.1, MPI_TYPE_HINDEXED, page 67, line 22-24 read:
> IN count number of blocks – also number of entries in
> array_of_displacements and array_of_blocklengths
> (integer)
> but should read:
> IN count number of blocks – also number of entries in
> array_of_displacements and array_of_blocklengths
> (nonnegative integer)
>
>
> MPI 1.1, Sect 3.12.1, MPI_TYPE_STRUCT, page 68, line 19-22 read:
> IN count number of blocks (integer) – also number
> of entries in arrays array_of_types,
> array_of_displacements and array_of_blocklengths
> IN array of blocklength number of elements in each
> block (array of integer)
> but should read:
> IN count number of blocks (nonnegative integer) – also number
> of entries in arrays array_of_types,
> array_of_displacements and array_of_blocklengths
> IN array of blocklength number of elements in each
> block (array of nonnegative integer)
>
>
> MPI 2.0, Sect 4.14.1, MPI_TYPE_CREATE_HINDEXED, page 66, line 36-38 read:
> IN count number of blocks – also number of entries in
> array_of_displacements and array_of_blocklengths
> (integer)
> but should read:
> IN count number of blocks – also number of entries in
> array_of_displacements and array_of_blocklengths
> (nonnegative integer)
>
>
> MPI 2.0, Sect 4.14.1, MPI_TYPE_CREATE_STRUCT, page 67, line 14-18 read:
> IN count number of blocks (integer) – also number
> of entries in arrays array_of_types,
> array_of_displacements and array_of_blocklengths
> IN array of blocklength number of elements in each
> block (array of integer)
> but should read:
> IN count number of blocks (nonnegative integer) – also number
> of entries in arrays array_of_types,
> array_of_displacements and array_of_blocklengths
> IN array of blocklength number of elements in each
> block (array of nonnegative integer)
> ___________________________________
>
> Rationale for this clarification and modification:
> The outcome of zero-count entries in the type map was not defined.
> For this, a clarification was needed.
> The interfaces of HINDEXED and STRUCT was inconsistent to the rest
> derived datatype routines. This was probably due to editing errors.
> A meaning of negative values was never defined not intended.
> Therefore, portable applications could not use negative values.
> These editing errors are fixed by this proposal.
> ___________________________________
>
>
> I hope, I could catch all the problems Jesper mentioned in his mail.
>
> Best regards
> Rolf
>
> On Tue, 29 Jan 2008 15:02:10 +0100
> Jesper Larsson Traeff <traff_at_it.neclab.eu> wrote:
> >
> >Dear Rolf,
> >
> >(thanks for all the work you are putting into this!)
> >
> >On Tue, Jan 29, 2008 at 12:47:14PM +0100, Rolf Rabenseifner wrote:
> >> Reply is off-line from the mailing list.
> >>
> >> Dear Jesper and Bill,
> >>
> >> I believe that this is not a topic for the one and final shot
> >> of MPI 2.1 Ballot 4 in the next (March 2008) meeting.
> >> Therefore, I would propose to handle it in MPI 2.2.
> >>
> >In the MPI-1 document (p.66, p.68) index and struct types are treated
> >differently. For index, blocklength is an array of non-negative integers
> >(p.66, line 12), for struct, just an array of integers (p. 68, line 22).
> >Same inconsistency for the new MPI-2 types, p.66 and p.67.
> >I believe that this should at least be made consistent.
> >
> >I would also be in favor of a small remark that 0 blocklengths are
allowed,
> >with the remarks that these are (of course) not included in the type
map.
> >
> >Btw, I will be coming to the meeting in March
> >
> >best regards
> >
> >Jesper
> >
> >> Jesper, you have not been at Jan meeting. Therefore a short
background.
> >> We decided, that MPI 2.1 is mainly the combining of the MPI 1.1
> >> and 2.0 documents to one MPI 2.1 standard.
> >> Additionally the existing MPI 1.1 errata, and the MPI-2 electonically
> >> voted Ballots 1 & 2, and the Jan. meeting Ballot 3 and the March
meeting
> >> Ballot 4 are included. Topics that do not get final official reading
> >> in these meetings are forwarded to MPI 2.2.
> >>
> >> Therefore I try to have mainly items in Ballot 3 and 4 that do not
> >> need longer discussions and that are mainly obvious, i.e., that can
> >> be shown on one or two slides together with needed background infos.
> >>
> >> Implication for me: I do not put your item on my MPI 2.1 agenda.
> >>
> >> Okay?
> >>
> >> Best regards
> >> Rolf
> >>
> >> On Mon, 23 Apr 2007 17:10:35 +0200
> >> Jesper Larsson Traeff <traff_at_[hidden]> wrote:
> >> >
> >> >(ps: also sent to mpi-core_at_[hidden] - did anybody get it from
there?)
> >> >
> >> >Dear MPI forum,
> >> >
> >> >an old discussion (July-September 2001) concluded that blocklengths
of
> >> >value zero are allowed in MPI indexed and struct types. Reading the
> >> >standard, both text and specification (p.66ff), such "blocks"
generate
> >> >no entries in the corresponding type maps, at least this seems to be
> >> >the idea - and implementations like mpich2 follow this
interpretation,
> >> >while the original MPICH for instance did not, and maybe with some
right?
> >> >
> >> >The question is what a derived datatype is intended to specify. If
> >> >it specifies just a type map, then clearly blocks of length zero
should
> >> >simply be treated as not being there, and the resulting type map
alone
> >> >defines the extent, lower and upper bounds of the datatype. But if a
> >> >derived datatype is intended as specifying a layout in memory, zero
> >> >length blocks could possibly have another meaning (as markers
oflocations
> >> >in the layout), and in addition to the type map affect the extent,
> >> >lower and upper bound of the datatype.
> >> >
> >> >
> >> >A concrete example
> >> >
> >> > displacements(1)=1
> >> > displacements(2)=0
> >> > lengths(1)=1
> >> > lengths(2)=0
> >> >
> >> > call
mpi_type_indexed(2,lengths,displacements,MPI_INTEGER,newtype,code)
> >> > call mpi_type_commit(newtype,code)
> >> >
> >> >In the first interpretation (datatypes specify type map) the above
has
> >> >extent 4 (assuming MPI_INTEGER is 4 bytes) and lower bound 4
> >> >
> >> >In the second interpretation (datatypes specify layout) the above
would
> >> >have lower bound 0 and extent 8
> >> >
> >> >
> >> >The point is that in the first interpretation (which is the one at
least
> >> >implicitly prescribed by the standard) the layout that was
> possibly intended
> >> >by the user ("something starting at displacement soandso" -
> irrespective of
> >> >whether there is actual data at displacement soandso) can be quite
> >> >arbitrarily collapsed. In an application where datatypes are
generated
> >> >automatically, it might be a high burden on the user to take care of
> >> >the special cases arising by some blocklenghts just happening to
> >> >be zero (either he would have to resize, or to put in explcit
> >> >MPI_LB/MPI_UB markers).
> >> >
> >> >A point could therefore be made for treating blocks of length
> >> >zero still as "markers" in the specification of a layout - as did for
> >> >instance the original MPICH implementation. Some changes in the text
> >> >would be necessary to put this interpretation on a firm foundation.
> >> >That is not the intention here, but only to see if there are opinions
> >> >on this issue? A suggestion would be to add a short paragraph stating
> >> >that zero blocklengths are allowed, and what their effects and
> side-effects
> >> >are.
> >> >
> >> >Jesper
> >> >
> >> >
> >> >Minor clarifications:
> >> >
> >> >p.63, l.39, p.66, l.12, and p.67, l.25 have "nonnegative integer"
> >> >blocklengths, but p. 68, l.22 only has "integer".
> >> >To be consistent P. 68, l.22 should also be "nonnegative integer"
> >> >(negative blocklenghts don't make sense)
> >> >
> >> >(as already pointed out by Steven Huss-Lederman) The specification
> >> >p.66, l.46ff and similarly for MPI_Type_hindexed and MPI_Type_struct
> >> >makes little sense (well, is plain wrong) when some B[i] is
> actually zero.
> >> >First, l.46 forces some elements into the type map [ (type_0,
> disp_0+D[0]) ,,,]
> >> >that shouldn't be there (blocks of length zero shouln't give rise to
any
> >> >elements in the type map), and also l.48 has no real meaning
> >> >when B[0]. Better would be to add two lines after l.48 giving the
general
> >> >case:
> >> >
> >> >(type_0,disp_0+D[i]*ex),...,(type_{n-1},disp_{n-1}+D[i]*ex),...,
> >> >(type_0,disp_0+(D[i]+B[i]-1)*ex,...,(type_{n-1},disp_{n-1}+(D[i]
> +B[i]-1)*ex,
> >> >
> >> >with the proviso that this is empty if B[i]==0 (or even more formally
> >> >precise/correct)
> >> >
> >>
> >>
> >>
> >> Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner_at_[hidden]
> >> High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530
> >> University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832
> >> Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner
> >> Nobelstr. 19, D-70550 Stuttgart, Germany . (Office: Allmandring 30)
>
>
>
> Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner_at_[hidden]
> High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530
> University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832
> Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner
> Nobelstr. 19, D-70550 Stuttgart, Germany . (Office: Allmandring 30)
> _______________________________________________
> mpi-21 mailing list
> mpi-21_at_[hidden]
> http://lists.cs.uiuc.edu/mailman/listinfo/mpi-21
*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mpi-forum.org/pipermail/mpi-21/attachments/20080129/2640732d/attachment.html>
More information about the Mpi-21
mailing list