[mpi-21] Intended meaning of zero blocklengths in MPI_Type_indexed/MPI_Type_create_struct
Rolf Rabenseifner
rabenseifner at [hidden]
Tue Jan 29 16:36:36 CST 2008
Yes, agreed, your text fits better to the clarification needs.
Rolf
On Tue, 29 Jan 2008 13:26:04 -0500
Richard Treumann <treumann_at_[hidden]> wrote:
>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
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)
More information about the Mpi-21
mailing list