From: "Rolf Rabenseifner" Date: January 30, 2008 8:39:17 AM CST To: mpi-21@XXXXXXXXXXX Subject: Re: [mpi-21] Reading of Chapter 4 Reply-To: "Mailing list for discussion of MPI 2.1" Thank you for your detailed reading of MPI 2.0 Chapter 4. Some comments and answers are inline below. Most will be for MPI 2.1 Ballot 4. Therefore, I switched the mail distribution to mpi-21@XXXXXXXXXXX On Wed, 9 Jan 2008 12:07:24 +0100 Jesper Larsson Traeff wrote:> > Dear all, > > I have read Chapter 4 - here are my corrections, comments and > suggestions > (only things not already in the errata sheet from Jan 30, 2002). > There is > little of great substance. > > I have prefixed the comments as follows: > (typo) - uncontroversial typo/misspelling, should be corrected > (suggestion) - suggestion for alternative wording/extra comment > (addition) - suggestion for addition > (comment) - my comment, not intended for standard document > > General typo: is "implementor" (with an "o") a word in US English? > Shouldn't it be "Implementers"? (as in "Advice to implementers") > > General comments: the chapter is quite awful, and in the longer run I > would be in favor of having the parts (e.g. on datatypes) moved to > the chapters where they belong properly. I think Rolf will be doing > some > of this. > I would also suggest having a special chapter in the new 2.1 > document summarizing all deprecated functionality (with a short > rationale > as to why the function was deprecated) > > For mnemonic reasons, I would suggest having all datatype constructors > being of the form > > MPI_TYPE_CREATE_XXX > > and thus deprecate MPI_TYPE_CONTIGUOUS and MPI_TYPE_VECTOR as well. > It could also be argued to have an MPI_TYPE_CREATE_HINDEXED_BLOCK as > counterpart to MPI_TYPE_CREATE_INDEXED_BLOCK (but I am not making a > strong suggestion). > > best regards > > Jesper > > Chapter 4: > ---------- > > Page 37, line 44-46: > (suggestion) drop, since this is largely a repetition of lines 34-36 > (except the statement "It is not suggested that this be the only > way..." --> Ballot 4 > Page 43, line 33-34: > (suggestion) change "It consists of (key,value) pairs" to > "It stores a(n unordered) set of (key,value) pairs" to emphasize > that the > info object is a kind of dictionary (data structure) --> Ballot 4 > > Page 43, line 34: > (suggestion) replace "may have only one value" by "can have only > one value" --> Ballot 4 > > Page 43, line 37: > > (addition) "An empty info object is denoted by MPI_INFO_NULL." --> Ballot 4 Page 43, line 37: > (comment/discussion) The default is that the "null handle" is not > allowed as an IN argument (see MPI 1, Page 8, line 28), unless > explicitly allowed. This explicit permission is missing at some > places in MPI-2 (I found two): MPI_WIN_CREATE, page 111, and > MPI_FILE_SET_INFO, page 218. Is this default interpretation also > intended > for MPI_INFO_NULL? A sentence on this would be in order, since the > info object is introduced here:" It is erroneous to pass MPI_INFO_NULL > as an IN argument, unless where explicitly allowed" (or whatever > appropriate > depending on the intended interpretation). No, because MPI-1.1, Sect. 2.4.1, Page 8, line 28 is no longer valid. Whole Chapter 2 is substituted by MPI 2.0, Chapter 2. And in MPI 2.0, Sect. 2.5.1, Pages 8-9 the cited paragraph is removed. > Page 47, line 1: > (suggestion) change "Keys are numbered..." to > "At any point in time, keys are numbered consecutively from 0 to > N-1, where..." If it is okay, I would ignore this, because it isn't a clarification. > Page 47, line 32: > (addition) > "Advice to implementers: The info object is a dictionary, and can be > implemented by a suitable data structure. Since the number of > (key,value) > pairs can normally be assumed to be small a linear list implementation > will often suffice." This must be handled in the discussion thread "What info keys can be set?" on the errata page and http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi-errata/ discuss/infoset/ I will continue on that thread with a ballot 4 proposal. > Page 49, line 21: > (addition) to align with the Fortran example 4.7, add C comment > "/* no memory is allocated */" --> Ballot 4 > > Page 49, line 22: > (addition) to make consistent with Fortran example, add line: > /* memory allocated */ --> Ballot 4 > > Page 50, line 9: > (type) remove first "in" --> Ballot 4 > > Page 55, line 26: > (comment) is this good Fortran style - scalars, e.g. 5 and MPI_REAL, > as implicit arrays of size 1? For a C programmer this is hurtful, and > some Fortran compilers do complain. I would suggest declaring the > proper arrays, so as to make the example more readily understandable, > also to the Fortran non-expert. Same goes for the similar Example 4.14 > on Page 60. --> Ballot 4 with following details: MPI 2.0, Sect. 4.12.6, Exa. 4.12, page 55, line 21-22 read: INTEGER TYPE, IERR INTEGER (KIND=MPI_ADDRESS_KIND) ADDR but should read: INTEGER TYPE, IERR, AOBLEN(1), AOTYPE(1) INTEGER (KIND=MPI_ADDRESS_KIND) AODISP(1) MPI 2.0, Sect. 4.12.6, Exa. 4.12, page 55, line 25-26 read: CALL MPI_GET_ADDRESS( R, ADDR, IERR) CALL MPI_TYPE_CREATE_STRUCT(1, 5, ADDR, MPI_REAL, TYPE, IERR) but should read: AOBLEN(1) = 5 CALL MPI_GET_ADDRESS( R, AODISP(1), IERR) AOTYPE(1) = MPI_REAL CALL MPI_TYPE_CREATE_STRUCT(1, AOBLEN(1),AODISP(1),AOTYPE(1), TYPE, IERR) MPI 2.0, Sect. 4.12.10, Exa. 4.14, page 60, line 31-32 read: INTEGER TYPE, IERR, MYRANK INTEGER (KIND=MPI_ADDRESS_KIND) ADDR but should read: INTEGER TYPE, IERR, MYRANK, AOBLEN(1), AOTYPE(1) INTEGER (KIND=MPI_ADDRESS_KIND) AODISP(1) MPI 2.0, Sect. 4.12.10, Exa. 4.14, page 55, line 35-36 read: CALL MPI_GET_ADDRESS( R, ADDR, IERR) CALL MPI_TYPE_CREATE_STRUCT(1, 5, ADDR, MPI_REAL, TYPE, IERR) but should read: AOBLEN(1) = 5 CALL MPI_GET_ADDRESS( R, AODISP(1), IERR) AOTYPE(1) = MPI_REAL CALL MPI_TYPE_CREATE_STRUCT(1, AOBLEN(1),AODISP(1),AOTYPE(1), TYPE, IERR) > > Page 56, line 29: > (typo) "assciated" should be "associated" --> Ballot 4 > > Page 67, line 18: > (suggestion) change "array of integer" to "array of nonnegative > integer" > (shouldn't it be "integers"?) - to make consistent with HVECTOR and > HINDEXED. > (comment) There was an email discussion about 0-blocklengths, and > although it did not go very far, I think the conclusion was that > 0-blocklengths are allowed and give rise to no element in the type > map. I think that some changes in the MPI-1 rules for how type maps > are generated by the INDEXED and STRUCT constructors are needed to > make this precise and correct. I have put this into the thread "Block lengths of zero in MPI Datatypes" http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi-errata/ discuss/blklenzero/ > Page 70-77: > (comment) Two pictures illustrating the subarray and distributed array > constructors would be really helpful. May be nice to have. > > Page 74, line 9: > (typo) "is" missing in "it erroneous" --> Ballot 4 > > Chapter 5: > ---------- > > Page 85, line 25: > (typo) "as the as the" should be "as the" --> Ballot 4 > Best regards Rolf 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