[mpi-21] Reading of Chapter 4

Wed Jan 30 08:39:17 CST 2008

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_at_[hidden]

On Wed, 9 Jan 2008 12:07:24 +0100
 Jesper Larsson Traeff <traff_at_it.neclab.eu> 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_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)