From: "Rolf Rabenseifner" Date: January 29, 2008 4:36:36 PM CST To: "Mailing list for discussion of MPI 2.1" Subject: Re: [mpi-21] Intended meaning of zero blocklengths in MPI_Type_indexed/MPI_Type_create_struct Reply-To: "Mailing list for discussion of MPI 2.1" Yes, agreed, your text fits better to the clarification needs. Rolf On Tue, 29 Jan 2008 13:26:04 -0500 Richard Treumann 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@XXXXXXXXXXX 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 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 wrote:>>>>> >>>>> (ps: also sent to mpi-core@mpi-forum.org - 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@XXXXXXX >>>> 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@XXXXXXX >> 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@XXXXXXXXXXX >> http://lists.cs.uiuc.edu/mailman/listinfo/mpi-21 Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner@XXXXXXX 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@XXXXXXXXXXX http://lists.cs.uiuc.edu/mailman/listinfo/mpi-21