April 2008 - Mpi-21 - mailman3.cels.anl.gov

Newest updates
by unknown＠example.com 08 Apr '08

08 Apr '08

Updated chapters: 6. Process Topologies (by Jesper Traeff) 8. Miscellany (by Jesper Traeff) 10. One-sided (by Jesper Traeff) A. Annex Language Bindings (Jeff's comments implemented) Annex A.4 is now sorted again by the routines names. See http://www.hlrs.de/mpi/mpi21/doc/mpi-report.pdf (should be used only for controling) (Review references should be done normally to Draft Apr. 1, 2008) and http://www.hlrs.de/mpi/mpi21/doc/MPI-2.1draft-2008-02-23-review.txt 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)

1 0

Re: [Mpi-21] MPI-2.1 April 1 document comments
by unknown＠example.com 08 Apr '08

08 Apr '08

Hi Jeff, as with all reviews, I've put it into http://www.hlrs.de/mpi/mpi21/doc/MPI-2.1draft-2008-02-23-review.txt User / Password as usual: mpi21 / mpi21 Most of your proposals in Binding, I commented with R2 to give it back to you for implementing it. Best regards Rolf On Mon, 7 Apr 2008 11:18:32 -0700 Jeff Squyres <jsquyres_at_[hidden]> wrote: > While reading the April 1 MPI-2.1 document for C++ and chapter 13 > issues, I itemized a list of other issues that I found. Some may want > to be pushed off to 2.2 (I have noted all of these with "--> This will > require a vote") -- I leave these up to the Forum to decide -- but > others should be fixed in 2.1. > > Enjoy. > > ----- > > April 7 2008 > Comments on MPI-2.1 April 1, 2008 document > > (notation: pX.Y = page X, line Y) > > Overall > ======= > > - Frontage numbering is still roman numerals -- I thought we agreed to > have the physical and PDF page numbers agree. > > - Some function pointer typedefs are "_function", others are "_fn" > We should be consistent throughout the text. > > Intro chapter > ============= > > - p5.2: Two open source MPI implementations are cited that are no > longer relevant. This entire sentence should be removed. Indeed, > the language in the overall paragraph is forward-looking -- it > should probably be re-worked to be in the present tense. > > - p6.46: Chapter 13 discusses Fortran issues (not Fortran 90 issues), > and also discusses language interoperability issues. > > - p7.11: Looks like a broken LaTeX reference. > > Terms and Conventions > ===================== > > - p9.40-10.10: The C and Fortran language neutral name do not include > the prefix "MPI_", but the C++ bindings include the prefix "MPI::". > Shouldn't the C/Fortran bindings be "MPI_CLASS_ACTION_SUBSET" > (etc.)? > > - p10.35: due to the decision from last meeting (sort out the > IN/OUT/INOUT mess in MPI-2.2), the language should be softened in > this paragraph and the full paragraph following this one (because > they contradict each other). Specifically, I propose changing: > > 10.35: Thus, in C++, IN aguments are either references... > to > Thus, in C++, IN arguments are usually either references... > > - p11.22: "Fortran in this document refers to Fortran 90". For > MPI-2.1, it is probably suitable to leave this, but we might want to > make a statement (footnote or parenthetical) that it is expected to > be updated in future MPI spec revisions. > > > Point-to-Point Communication > ============================ > > - p66.33: Why is the request argument to the C bindings MPI_CANCEL > take a pointer? The language neutral binding is IN, and the C++ > binding is const. This seems to be a contradiction. > --> This cannot be changed easily because every MPI implementation > uses (MPI_Request *) as the type. > > - p83.29: extra space: "( int count," > > - p92.43: mising "const" before "void* location". Adding "const" > will not break any user codes or MPI implementations. > --> This will require a vote. > > - p95.47-48: remove "const" before lb an extent arguments. > Removing "const" will not break any user codes or MPI > implementations. > --> This will require a vote. > > Collective Communications > ========================= > > - p123.32: "relaxed" uses quote marks in the wrong direction > > - p123.27: should say "MPI-1" instead of "MPI-1.2" > > Groups, Contexts, and Communicators > =================================== > > - p186.5: Descriptions for the C++ bindings need to be included here, > since they are different than the C bindings. The text from 13.1.7 > would seem to be sufficient. > > - p214.32: Missing "const" before "void* attribute_val_in" (datatype > callback argument is const) > --> This will require a vote. > > - p214.36: Delete function comm argument should be const (?) > --> This will require a vote. > > - p219.5: Missing "const" before "void* attribute_val_in" (datatype > callback argument is const) > --> This will require a vote. > > - p219.9: Delete function win argument should be const (?) > --> This will require a vote. > > - p221.44: Delete function type argument should be const (?) > --> This will require a vote. > > MPI Environmental Management > ============================ > > - p248.3: Earlier in the document, references are made to v1.3. Is > that not a valid tuple to return from MPI_GET_VERSION? > > - p249.45: Remove duplicate C++ binding > > - p254.21: Remove erroneous MPI::Intracomm::Create C++ binding > > - p255.2: First argument (comm handle reference) to errhandler > function should be const. > --> This will require a vote. > > - p256.27: First argument (win handle reference) to errhandler > function should be const. > --> This will require a vote. > > - p257.41: First argument (file handle reference) to errhandler > function should be const. > --> This will require a vote. > > - p258.39: Delete duplicate C++ binding > > - p259.13: Delete duplicate C++ binding > > - p260.36-43: First letter of description should be capitolized to be > consistent with rest of list. > > - p261.42: Delete duplicate C++ binding > > - p263.21-23: Delete duplicate C++ bindings > > - p264.22: Delete duplicate C++ binding > > - p267.24: Delete duplicate C++ binding > > - p267.42: Delete duplicate C++ binding > > Process Creation and Management > =============================== > > - p288.11: Function should be const. > --> This will require a vote. > > - p288.15: Function should be const. > --> This will require a vote. > > External Interfaces > =================== > > - p344.39: Arguments of query_fn, free_fn, and cancel_fn need to have > *'s. This is a consistency issue (the rest of the standard uses > "*" for function pointer parameters), not a correctness issue -- > works both ways. Should not break any user code or MPI > implementations. > > I/O > === > > - p419.43: datatype argument should be const > > Language Bindings > ================= > > - p437.18: Delete first sentence of paragraph > > - p437.22: Delete "original" > > - p437.24-29: Delete first and last sentences of paragraph > > - p437.29: New last sentence, "See Annex A.4.19 for a function cross > reference." > > - p438.11: Delete "for MPI-1" > > - p438.14-37: Join the two namespaces together and delete the > "Additionally, the following classes defined for MPI-2:" text. > Re-sort the class names as appropriate. > > - p439.2: Delete last sentence ("To maintain ... in [23].") > > - p442: Table 13.1 is redundant with Annex A.1. However, the > following C++ types are missing from Annex A.1: > > MPI::SIGNED_CHAR > MPI::BOOL > MPI::COMPLEX > MPI::DOUBLE_COMPLEX > MPI::LONG_DOUBLE_COMPLES > > - p442: Table 13.2 is redundant with Annex A.1 > > - p445.5-11: These functions are not listed in Annex A > > - p445.36-38: Remove this entire paragraph ("Compilers that do not > support..."). This feature has been a part of C++ since C++98, and > exists in all modern C++ compilers. > > - p446.7-17: Declarations for the MPI::Exceptions class are missing > from Annex A > > - p448.47: Remove trailing "/" from "OUT/" > > - p450.26-44: The bullet list is wholly redundant with section 2.6.2. > > - p456.27-29: VOLATILE is in Fortran 200x; reword first sentence from: > "In the longer term, the attribute VOLATILE is under > consideration for Fortran 2000 and would give the buffer or > variable the properties needed, but it would inhibit > optimization of any code containing the buffer or variable." > to > "The VOLATILE attribute, available in later versions of Fortran, > would give the buffer or variable the properties needed, but it > would inhibit optimization of any code containing the buffer or > variable." > > - p459.11-15: Delete paragraph > > - p462.43-45: Delete paragraph > > - p463.17-18: Delete first sentence; delete "In MPI-2," > > - p467.23: There is an extra space before "MPI_FINALIZE" > > - p468.16-39: None of these functions appear in Annex A (they > should!) > > - p469.41 and 44: These functions do not appear in Annex A (they > should!) > > - p470.46: Change sentence from: > "It is important to note that all C++ objects and their > corresponding C handles..." > to > "It is important to note that all C++ objects with > corresponding C handles..." > I.e., this sentence is referring only to C++ handles that actually > have corresponding C handles (e.g., not > MPI::ERRORS_THROW_EXCEPTIONS). > > Profiling Interface > =================== > > - p481.4: Delete "const" > --> This may require a vote. > > Annex A > ======= > > - p494.15: s/Fortran/Fortran only > > - p494.30: Missing MPI::ERRORS_THROW_EXCEPTIONS > > - p495.18-19 and 33-34: MPI_BYTE and MPI_PACKED are listed in two > separate tables. > > - p495.30: MPI::COMPLEX should be MPI::F_COMPLEX > > - p495.38: Looks like a blank extra 3rd column is in this table > > - p495.bottom: Missing table for "C++ only" datatypes: > MPI::BOOL > MPI::COMPLEX > MPI::DOUBLE_COMPLEX > MPI::LONG_DOUBLE_COMPLEX > MPI::SIGNED_CHAR > > - p496.1: Add ", no Fortran" before the ")" > > - p496.10, s/Fortran/Fortran only/ > > - p496.27-30: Alignment of table entries should be to the left, not > centered. > > - p544.13: Many of the prototypes for Clone() and Dup() are missing > > - p547.all: Many doubles of C++ bindings; likely because of errors in > the chapter text. > > - p554.41: Do we need an empty deprecated functions section? > > - p555.45-46: Forgot to mention MPI_ERRCODES_IGNORE, > MPI_F_STATUSES_IGNORE, and MPI_F_STATUS_IGNORE > > - p556.bottom: Missing prototypes for the MPI::Exceptions class > > -- > Jeff Squyres > Cisco Systems > > _______________________________________________ > mpi-21 mailing list > mpi-21_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/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)

1 0

Re: [Mpi-21] MPI-2.1 April 1 document comments
by unknown＠example.com 07 Apr '08

07 Apr '08

Please do not change any interfaces. All "const" discussion is moved to MPI-2.2. This was a decision of the Forum at March meeting. Best regards Rolf On Mon, 7 Apr 2008 11:32:40 -0700 (PDT) "Bronis R. de Supinski" <bronis_at_[hidden]> wrote: > > Jeff: > > You should send the individual issues to the chapter owners. > > I will try to look over the issues for chapters 11 and 14. > I don't have a strong opinon on either of them and will > certainly delete the "const" in chapter 14 if others agree. > > Bronis > > > > > On Mon, 7 Apr 2008, Jeff Squyres wrote: > > > While reading the April 1 MPI-2.1 document for C++ and chapter 13 > > issues, I itemized a list of other issues that I found. Some may want > > to be pushed off to 2.2 (I have noted all of these with "--> This will > > require a vote") -- I leave these up to the Forum to decide -- but > > others should be fixed in 2.1. > > > > Enjoy. > > > > ----- > > > > April 7 2008 > > Comments on MPI-2.1 April 1, 2008 document > > > > (notation: pX.Y = page X, line Y) > > > > Overall > > ======= > > > > - Frontage numbering is still roman numerals -- I thought we agreed to > > have the physical and PDF page numbers agree. > > > > - Some function pointer typedefs are "_function", others are "_fn" > > We should be consistent throughout the text. > > > > Intro chapter > > ============= > > > > - p5.2: Two open source MPI implementations are cited that are no > > longer relevant. This entire sentence should be removed. Indeed, > > the language in the overall paragraph is forward-looking -- it > > should probably be re-worked to be in the present tense. > > > > - p6.46: Chapter 13 discusses Fortran issues (not Fortran 90 issues), > > and also discusses language interoperability issues. > > > > - p7.11: Looks like a broken LaTeX reference. > > > > Terms and Conventions > > ===================== > > > > - p9.40-10.10: The C and Fortran language neutral name do not include > > the prefix "MPI_", but the C++ bindings include the prefix "MPI::". > > Shouldn't the C/Fortran bindings be "MPI_CLASS_ACTION_SUBSET" > > (etc.)? > > > > - p10.35: due to the decision from last meeting (sort out the > > IN/OUT/INOUT mess in MPI-2.2), the language should be softened in > > this paragraph and the full paragraph following this one (because > > they contradict each other). Specifically, I propose changing: > > > > 10.35: Thus, in C++, IN aguments are either references... > > to > > Thus, in C++, IN arguments are usually either references... > > > > - p11.22: "Fortran in this document refers to Fortran 90". For > > MPI-2.1, it is probably suitable to leave this, but we might want to > > make a statement (footnote or parenthetical) that it is expected to > > be updated in future MPI spec revisions. > > > > > > Point-to-Point Communication > > ============================ > > > > - p66.33: Why is the request argument to the C bindings MPI_CANCEL > > take a pointer? The language neutral binding is IN, and the C++ > > binding is const. This seems to be a contradiction. > > --> This cannot be changed easily because every MPI implementation > > uses (MPI_Request *) as the type. > > > > - p83.29: extra space: "( int count," > > > > - p92.43: mising "const" before "void* location". Adding "const" > > will not break any user codes or MPI implementations. > > --> This will require a vote. > > > > - p95.47-48: remove "const" before lb an extent arguments. > > Removing "const" will not break any user codes or MPI > > implementations. > > --> This will require a vote. > > > > Collective Communications > > ========================= > > > > - p123.32: "relaxed" uses quote marks in the wrong direction > > > > - p123.27: should say "MPI-1" instead of "MPI-1.2" > > > > Groups, Contexts, and Communicators > > =================================== > > > > - p186.5: Descriptions for the C++ bindings need to be included here, > > since they are different than the C bindings. The text from 13.1.7 > > would seem to be sufficient. > > > > - p214.32: Missing "const" before "void* attribute_val_in" (datatype > > callback argument is const) > > --> This will require a vote. > > > > - p214.36: Delete function comm argument should be const (?) > > --> This will require a vote. > > > > - p219.5: Missing "const" before "void* attribute_val_in" (datatype > > callback argument is const) > > --> This will require a vote. > > > > - p219.9: Delete function win argument should be const (?) > > --> This will require a vote. > > > > - p221.44: Delete function type argument should be const (?) > > --> This will require a vote. > > > > MPI Environmental Management > > ============================ > > > > - p248.3: Earlier in the document, references are made to v1.3. Is > > that not a valid tuple to return from MPI_GET_VERSION? > > > > - p249.45: Remove duplicate C++ binding > > > > - p254.21: Remove erroneous MPI::Intracomm::Create C++ binding > > > > - p255.2: First argument (comm handle reference) to errhandler > > function should be const. > > --> This will require a vote. > > > > - p256.27: First argument (win handle reference) to errhandler > > function should be const. > > --> This will require a vote. > > > > - p257.41: First argument (file handle reference) to errhandler > > function should be const. > > --> This will require a vote. > > > > - p258.39: Delete duplicate C++ binding > > > > - p259.13: Delete duplicate C++ binding > > > > - p260.36-43: First letter of description should be capitolized to be > > consistent with rest of list. > > > > - p261.42: Delete duplicate C++ binding > > > > - p263.21-23: Delete duplicate C++ bindings > > > > - p264.22: Delete duplicate C++ binding > > > > - p267.24: Delete duplicate C++ binding > > > > - p267.42: Delete duplicate C++ binding > > > > Process Creation and Management > > =============================== > > > > - p288.11: Function should be const. > > --> This will require a vote. > > > > - p288.15: Function should be const. > > --> This will require a vote. > > > > External Interfaces > > =================== > > > > - p344.39: Arguments of query_fn, free_fn, and cancel_fn need to have > > *'s. This is a consistency issue (the rest of the standard uses > > "*" for function pointer parameters), not a correctness issue -- > > works both ways. Should not break any user code or MPI > > implementations. > > > > I/O > > === > > > > - p419.43: datatype argument should be const > > > > Language Bindings > > ================= > > > > - p437.18: Delete first sentence of paragraph > > > > - p437.22: Delete "original" > > > > - p437.24-29: Delete first and last sentences of paragraph > > > > - p437.29: New last sentence, "See Annex A.4.19 for a function cross > > reference." > > > > - p438.11: Delete "for MPI-1" > > > > - p438.14-37: Join the two namespaces together and delete the > > "Additionally, the following classes defined for MPI-2:" text. > > Re-sort the class names as appropriate. > > > > - p439.2: Delete last sentence ("To maintain ... in [23].") > > > > - p442: Table 13.1 is redundant with Annex A.1. However, the > > following C++ types are missing from Annex A.1: > > > > MPI::SIGNED_CHAR > > MPI::BOOL > > MPI::COMPLEX > > MPI::DOUBLE_COMPLEX > > MPI::LONG_DOUBLE_COMPLES > > > > - p442: Table 13.2 is redundant with Annex A.1 > > > > - p445.5-11: These functions are not listed in Annex A > > > > - p445.36-38: Remove this entire paragraph ("Compilers that do not > > support..."). This feature has been a part of C++ since C++98, and > > exists in all modern C++ compilers. > > > > - p446.7-17: Declarations for the MPI::Exceptions class are missing > > from Annex A > > > > - p448.47: Remove trailing "/" from "OUT/" > > > > - p450.26-44: The bullet list is wholly redundant with section 2.6.2. > > > > - p456.27-29: VOLATILE is in Fortran 200x; reword first sentence from: > > "In the longer term, the attribute VOLATILE is under > > consideration for Fortran 2000 and would give the buffer or > > variable the properties needed, but it would inhibit > > optimization of any code containing the buffer or variable." > > to > > "The VOLATILE attribute, available in later versions of Fortran, > > would give the buffer or variable the properties needed, but it > > would inhibit optimization of any code containing the buffer or > > variable." > > > > - p459.11-15: Delete paragraph > > > > - p462.43-45: Delete paragraph > > > > - p463.17-18: Delete first sentence; delete "In MPI-2," > > > > - p467.23: There is an extra space before "MPI_FINALIZE" > > > > - p468.16-39: None of these functions appear in Annex A (they > > should!) > > > > - p469.41 and 44: These functions do not appear in Annex A (they > > should!) > > > > - p470.46: Change sentence from: > > "It is important to note that all C++ objects and their > > corresponding C handles..." > > to > > "It is important to note that all C++ objects with > > corresponding C handles..." > > I.e., this sentence is referring only to C++ handles that actually > > have corresponding C handles (e.g., not > > MPI::ERRORS_THROW_EXCEPTIONS). > > > > Profiling Interface > > =================== > > > > - p481.4: Delete "const" > > --> This may require a vote. > > > > Annex A > > ======= > > > > - p494.15: s/Fortran/Fortran only > > > > - p494.30: Missing MPI::ERRORS_THROW_EXCEPTIONS > > > > - p495.18-19 and 33-34: MPI_BYTE and MPI_PACKED are listed in two > > separate tables. > > > > - p495.30: MPI::COMPLEX should be MPI::F_COMPLEX > > > > - p495.38: Looks like a blank extra 3rd column is in this table > > > > - p495.bottom: Missing table for "C++ only" datatypes: > > MPI::BOOL > > MPI::COMPLEX > > MPI::DOUBLE_COMPLEX > > MPI::LONG_DOUBLE_COMPLEX > > MPI::SIGNED_CHAR > > > > - p496.1: Add ", no Fortran" before the ")" > > > > - p496.10, s/Fortran/Fortran only/ > > > > - p496.27-30: Alignment of table entries should be to the left, not > > centered. > > > > - p544.13: Many of the prototypes for Clone() and Dup() are missing > > > > - p547.all: Many doubles of C++ bindings; likely because of errors in > > the chapter text. > > > > - p554.41: Do we need an empty deprecated functions section? > > > > - p555.45-46: Forgot to mention MPI_ERRCODES_IGNORE, > > MPI_F_STATUSES_IGNORE, and MPI_F_STATUS_IGNORE > > > > - p556.bottom: Missing prototypes for the MPI::Exceptions class > > > > -- > > Jeff Squyres > > Cisco Systems > > > > _______________________________________________ > > mpi-21 mailing list > > mpi-21_at_[hidden] > > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-21 > > > _______________________________________________ > mpi-21 mailing list > mpi-21_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/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)

1 0

Re: [Mpi-21] MPI-2.1 April 1 document comments
by unknown＠example.com 07 Apr '08

07 Apr '08

Yes it was 10.d on the long list. We keep roman for frontmatter. Now pdf has correct numbering (My acroread under Windows works really fine) (My acroread under Linux is a little bit ugly, it computes and shows also the global numbering :-( ) On Mon, 7 Apr 2008 13:37:20 -0500 William Gropp <gropp_at_[hidden]> wrote: > The numbers do agree - we changed the LaTeX options so that the PDF knows the real numbers, which include roman for front matter. It would be wrong to number the pages sequentially from 1, abandoning long-established practice with documents. And at least on a Mac, both Preview and Acrobat both display the correct page number and will goto that page (including going to "xi"). Before we fixed this, those display programs did not know how the pages were numbered, and just (incorrectly) counted forward from one. Now the document meets standard page numbering conventions, and the PDF display programs are aware of the true page numbers. > > Bill > > On Apr 7, 2008, at 1:18 PM, Jeff Squyres wrote: > > > Overall > > ======= > > > > - Frontage numbering is still roman numerals -- I thought we agreed to > > have the physical and PDF page numbers agree. > > > > William Gropp > Paul and Cynthia Saylor Professor of Computer Science > University of Illinois Urbana-Champaign > > 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)

1 0

Re: [Mpi-21] MPI-2.1 April 1 document comments
by unknown＠example.com 07 Apr '08

07 Apr '08

Ahh... I see. There's a non-default option in OS X Preview that you have to enable ("Use logical page numbers"), and then it all works fine. Thanks, Apple. ;-) Thanks! On Apr 7, 2008, at 11:37 AM, William Gropp wrote: > The numbers do agree - we changed the LaTeX options so that the PDF > knows the real numbers, which include roman for front matter. It > would be wrong to number the pages sequentially from 1, abandoning > long-established practice with documents. And at least on a Mac, > both Preview and Acrobat both display the correct page number and > will goto that page (including going to "xi"). Before we fixed > this, those display programs did not know how the pages were > numbered, and just (incorrectly) counted forward from one. Now the > document meets standard page numbering conventions, and the PDF > display programs are aware of the true page numbers. > > Bill > > On Apr 7, 2008, at 1:18 PM, Jeff Squyres wrote: >> Overall >> ======= >> >> - Frontage numbering is still roman numerals -- I thought we agreed >> to >> have the physical and PDF page numbers agree. >> > > William Gropp > Paul and Cynthia Saylor Professor of Computer Science > University of Illinois Urbana-Champaign > > > _______________________________________________ > mpi-21 mailing list > mpi-21_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-21 -- Jeff Squyres Cisco Systems

1 0

Re: [Mpi-21] MPI-2.1 April 1 document comments
by unknown＠example.com 07 Apr '08

07 Apr '08

On Apr 7, 2008, at 11:32 AM, Bronis R. de Supinski wrote: > > You should send the individual issues to the chapter owners. Aren't all of them on this list? :-) > I will try to look over the issues for chapters 11 and 14. > I don't have a strong opinon on either of them and will > certainly delete the "const" in chapter 14 if others agree. Thanks. -- Jeff Squyres Cisco Systems

1 0

Re: [Mpi-21] MPI-2.1 April 1 document comments
by unknown＠example.com 07 Apr '08

07 Apr '08

On Apr 7, 2008, at 11:29 AM, Bronis R. de Supinski wrote: > > The PDF and physical page numbers do agree. That does not > require numbering the frontage material from 1. When I view > page xvi, my PDF reader says "xvi (16 of 603)". > > Perhaps your reader is broken? Perhaps it is; I'm using Preview in Mac/OS X 10.5.2. Does gv show the Roman numerals? -- Jeff Squyres Cisco Systems

1 0

Re: [Mpi-21] MPI-2.1 April 1 document comments
by unknown＠example.com 07 Apr '08

07 Apr '08

The numbers do agree - we changed the LaTeX options so that the PDF knows the real numbers, which include roman for front matter. It would be wrong to number the pages sequentially from 1, abandoning long-established practice with documents. And at least on a Mac, both Preview and Acrobat both display the correct page number and will goto that page (including going to "xi"). Before we fixed this, those display programs did not know how the pages were numbered, and just (incorrectly) counted forward from one. Now the document meets standard page numbering conventions, and the PDF display programs are aware of the true page numbers. Bill On Apr 7, 2008, at 1:18 PM, Jeff Squyres wrote: > Overall > ======= > > - Frontage numbering is still roman numerals -- I thought we agreed to > have the physical and PDF page numbers agree. > William Gropp Paul and Cynthia Saylor Professor of Computer Science University of Illinois Urbana-Champaign *

1 0

Re: [Mpi-21] TODO - AUTHORS of MPI-2.1 - Workplan
by unknown＠example.com 07 Apr '08

07 Apr '08

MPI-1 included the bindings issues / rationale information in an early chapter because it provides the basis behind the bindings presented in the rest of the document. I still think that that's a good idea (e.g., all of functions are MPI_<foo>, in C++ we have these basic classes, etc.). I think it would read pretty weird if you read the whole MPI-2.1 document and then in the last chapter you see "here's why all the bindings are the way that they are". That's why I proposed that this stuff be moved into a [new] chapter 3 -- keep the information at the beginning of the document, but it's now big enough to be its own chapter. My $0.02. :-) On Apr 7, 2008, at 11:22 AM, Bronis R. de Supinski wrote: > > Jeff: > > I agree with most of your proposal. > > If stuff is wrong/outdated in Chapter 2, then it should be fixed. > > If stuff in Chapter 2 really belongs in a Language Bindings chapter, > then it should be moved. > > However, I see no reason to make the language bindings chapter so > early in the standard. In fact, I agree with Rolf's suggestion > that it would be most appropriate as the last chapter, right > before the appendix that lists the actual bindings. As Rolf > suggested, we should make it chapter 14 and make the profiling > interface chapter 13. Making it chapter 3 does not make sense. > > Bronis > > > > On Mon, 7 Apr 2008, Jeff Squyres wrote: > >> The problem is that the text about language bindings is fairly >> disjoint between chapters 2 and 13. Indeed, chapter 13 is redundant >> and out of order / inconsistent with regards to MPI-1 text in some >> places *because* MPI-2 was a separate document. >> >> What about a slightly different proposal: >> >> 1. Move some of the existing Chapter 13/Language Bindings text into >> the relevant parts in the rest of the 2.1 doc (e.g., move the C++ >> communicators discussion to the Right place in Chapter 5/Groups, >> Contexts, Comms). >> >> 2. Make a new chapter 3: Language Bindings. Put in it: >> - All C/Fortran language bindings text from Chapter 2/Terms&Conv >> - All remaining text from Chapter 13/Language bindings >> >> 3. Remove the [now empty] Chapter 13 >> >> >> On Apr 4, 2008, at 7:48 AM, Rolf Rabenseifner wrote: >>> About Chap. 13, especially C++. >>> >>> I'm proposing (referencec to MPI-2.1 Draft Apr.1, 2008): >>> >>> - The MPI-2 Forum decided to put only small overview stuff into >>> Chap. 2 Terms. >>> (I want to recall, that in MPI-2 the Terms are rewritten for whole >>> MPI, >>> i.e., still valid in MPI-2.1) >>> - The MPI-2 Forum decided to put all deeper information into >>> extra sections of an additionally last chapter on Bindings. >>> - The MPI-2 Forum already decided that normal C++ bindings >>> should be after the Fortran bindings. >>> >>> - Terms, page 18, lines 36-39 clearly expresses, that all constants >>> are >>> given only in MPI_ notation and that C++ names (with MPI::) >>> are given in Annex A. >>> I.e., MPI_COMM_WORLD, MPI_FLOAT, MPI_PROC_NULL, ... should not >>> to be translated everywhere in the chapters. >>> Same for Table 3.2 on page 27. >>> >>> - There are important things were C++ clearly differs from C, >>> e.g. the handling of the Status. >>> I have already added the Status handling, see page 31 lines 23-32. >>> (By the way, this information was missing in Chap. 13.1 and only >>> available in the Annex A.) >>> >>> - I'm not aware, whether there are more such stuff, that is >>> explained >>> for C and Fortran and should be also explained for C++. >>> Do you see an additional stuff like status? >>> >>> - I do not expect that it would be a good idee to move all the ugly >>> Fortran problems (17 pages) to the beginning of thee book into >>> Chap. 2 Terms. >>> I would recommend same rule for C++ (12 pages). >>> Chap.2 terms has only 16 pages - with 2 pages dedicated to Fortran, >>> 1/2 page to C, and 3 pages to C++. >>> >>> Best regards >>> Rolf >>> >>> On Thu, 3 Apr 2008 15:13:10 -0400 >>> Jeff Squyres <jsquyres_at_[hidden]> wrote: >>>> On Apr 3, 2008, at 12:09 PM, Rolf Rabenseifner wrote: >>> ... >>>>> For me, the answer may have implications on how separate or >>>>> integrated additional bindings should be integrated into the >>>>> language independent text of the MPI standard. >>>> >>>> I don't quite understand. All officially-supported language >>>> bindings >>>> should be listed consistently in the standard. In MPI-2.1, for >>>> example, that means alongside the language neutral bindings in the >>>> text and in Annex A. >>> >>> >>> ------------- >>> >>> On Thu, 3 Apr 2008 15:27:08 -0400 >>> Jeff Squyres <jsquyres_at_[hidden]> wrote: >>>> What about the C++/Fortran language bindings text? Should the >>>> majority of chapter 13 be merged into Terms and Conventions (and >>>> elsewhere)? >>>> >>>> It's not really a "problem", per se -- but it is a little awkward. >>>> There are sections in chapter 13 that could definitely fit in >>>> existing >>>> text elsewhere. Some of it is redundant, too. >>>> >>>> >>>> >>>> On Apr 3, 2008, at 3:19 PM, George Bosilca wrote: >>>>> Bronis, >>>>> >>>>> If the data-type section get moved into the chapter 3 it make >>>>> sense >>>>> to merge the leftover of the chapter 11 with chapter 7, as long as >>>>> we choose a right name. "MPI Environmental Management" is not the >>>>> right chapter for "Generalized Requests". But of course these are >>>>> just details. >>>>> >>>>> I'll get in touch with you asap to see how we can coordinate. >>>>> >>>>> Thanks, >>>>> george. >>>>> >>>>> On Apr 3, 2008, at 12:58 PM, Bronis R. de Supinski wrote: >>>>>> >>>>>> Rolf: >>>>>> >>>>>> Re: >>>>>>> my general statements do not answer you initial question: >>>>>> >>>>>> My opinion is that leaving obvious problems unfixed based >>>>>> on an expected future version is a bad idea. However, I >>>>>> don't want to argue over this since I think the best >>>>>> approach is just to remove them now and then we don't >>>>>> have to worry about them. Others have more concerns over >>>>>> the time that they can devote to this (not that I have an >>>>>> abundance) and might want to delay in any event in order >>>>>> to get it right (at least mostly). >>>>>> >>>>>>> If you decide to move parts from Chap.11 to Chap.7, >>>>>>> then you both mus discuss this. You both are responsible >>>>>>> for these chapters. >>>>>>> And you should first convince your reviewers: >>>>>>> - Chap. 7: Rich, Jesper, Steve, Kannan, David, Bill >>>>>>> - Chap.11: Bill and Rainer >>>>>>> My recommendation: >>>>>>> Express clearly which parts should be moved exactly to wich line >>>>>>> (all based on page/line numbers as **printed** in Draft Apr. 1, >>>>>>> 2008). >>>>>> >>>>>> I have discussed moving the datatype decoding stuff >>>>>> with Rich and Bill. I will move those sections as I >>>>>> suggested, with an initial pass for the current review. >>>>>> This works well for Rich since he does not have time >>>>>> to do this for another couple of weeks. I hope to get >>>>>> that done today. >>>>>> >>>>>> For the remainder, I will look over the two chapters >>>>>> (7 & 11) and propose an initial merge strategy. George >>>>>> can react to that; I don't know how long it will take >>>>>> me to get that done... >>>>>> >>>>>> Bronis >>>>>> >>>>>> _______________________________________________ >>>>>> mpi-21 mailing list >>>>>> mpi-21_at_[hidden] >>>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-21 >>>>> >>>>> _______________________________________________ >>>>> mpi-21 mailing list >>>>> mpi-21_at_[hidden] >>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-21 >>>> >>>> >>>> -- >>>> Jeff Squyres >>>> Cisco Systems >>>> >>>> _______________________________________________ >>>> mpi-21 mailing list >>>> mpi-21_at_[hidden] >>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/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) >>> _______________________________________________ >>> mpi-21 mailing list >>> mpi-21_at_[hidden] >>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-21 >> >> >> -- >> Jeff Squyres >> Cisco Systems >> >> _______________________________________________ >> mpi-21 mailing list >> mpi-21_at_[hidden] >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-21 >> > _______________________________________________ > mpi-21 mailing list > mpi-21_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-21 -- Jeff Squyres Cisco Systems

1 0

Re: [Mpi-21] MPI-2.1 April 1 document comments
by unknown＠example.com 07 Apr '08

07 Apr '08

Jeff: You should send the individual issues to the chapter owners. I will try to look over the issues for chapters 11 and 14. I don't have a strong opinon on either of them and will certainly delete the "const" in chapter 14 if others agree. Bronis On Mon, 7 Apr 2008, Jeff Squyres wrote: > While reading the April 1 MPI-2.1 document for C++ and chapter 13 > issues, I itemized a list of other issues that I found. Some may want > to be pushed off to 2.2 (I have noted all of these with "--> This will > require a vote") -- I leave these up to the Forum to decide -- but > others should be fixed in 2.1. > > Enjoy. > > ----- > > April 7 2008 > Comments on MPI-2.1 April 1, 2008 document > > (notation: pX.Y = page X, line Y) > > Overall > ======= > > - Frontage numbering is still roman numerals -- I thought we agreed to > have the physical and PDF page numbers agree. > > - Some function pointer typedefs are "_function", others are "_fn" > We should be consistent throughout the text. > > Intro chapter > ============= > > - p5.2: Two open source MPI implementations are cited that are no > longer relevant. This entire sentence should be removed. Indeed, > the language in the overall paragraph is forward-looking -- it > should probably be re-worked to be in the present tense. > > - p6.46: Chapter 13 discusses Fortran issues (not Fortran 90 issues), > and also discusses language interoperability issues. > > - p7.11: Looks like a broken LaTeX reference. > > Terms and Conventions > ===================== > > - p9.40-10.10: The C and Fortran language neutral name do not include > the prefix "MPI_", but the C++ bindings include the prefix "MPI::". > Shouldn't the C/Fortran bindings be "MPI_CLASS_ACTION_SUBSET" > (etc.)? > > - p10.35: due to the decision from last meeting (sort out the > IN/OUT/INOUT mess in MPI-2.2), the language should be softened in > this paragraph and the full paragraph following this one (because > they contradict each other). Specifically, I propose changing: > > 10.35: Thus, in C++, IN aguments are either references... > to > Thus, in C++, IN arguments are usually either references... > > - p11.22: "Fortran in this document refers to Fortran 90". For > MPI-2.1, it is probably suitable to leave this, but we might want to > make a statement (footnote or parenthetical) that it is expected to > be updated in future MPI spec revisions. > > > Point-to-Point Communication > ============================ > > - p66.33: Why is the request argument to the C bindings MPI_CANCEL > take a pointer? The language neutral binding is IN, and the C++ > binding is const. This seems to be a contradiction. > --> This cannot be changed easily because every MPI implementation > uses (MPI_Request *) as the type. > > - p83.29: extra space: "( int count," > > - p92.43: mising "const" before "void* location". Adding "const" > will not break any user codes or MPI implementations. > --> This will require a vote. > > - p95.47-48: remove "const" before lb an extent arguments. > Removing "const" will not break any user codes or MPI > implementations. > --> This will require a vote. > > Collective Communications > ========================= > > - p123.32: "relaxed" uses quote marks in the wrong direction > > - p123.27: should say "MPI-1" instead of "MPI-1.2" > > Groups, Contexts, and Communicators > =================================== > > - p186.5: Descriptions for the C++ bindings need to be included here, > since they are different than the C bindings. The text from 13.1.7 > would seem to be sufficient. > > - p214.32: Missing "const" before "void* attribute_val_in" (datatype > callback argument is const) > --> This will require a vote. > > - p214.36: Delete function comm argument should be const (?) > --> This will require a vote. > > - p219.5: Missing "const" before "void* attribute_val_in" (datatype > callback argument is const) > --> This will require a vote. > > - p219.9: Delete function win argument should be const (?) > --> This will require a vote. > > - p221.44: Delete function type argument should be const (?) > --> This will require a vote. > > MPI Environmental Management > ============================ > > - p248.3: Earlier in the document, references are made to v1.3. Is > that not a valid tuple to return from MPI_GET_VERSION? > > - p249.45: Remove duplicate C++ binding > > - p254.21: Remove erroneous MPI::Intracomm::Create C++ binding > > - p255.2: First argument (comm handle reference) to errhandler > function should be const. > --> This will require a vote. > > - p256.27: First argument (win handle reference) to errhandler > function should be const. > --> This will require a vote. > > - p257.41: First argument (file handle reference) to errhandler > function should be const. > --> This will require a vote. > > - p258.39: Delete duplicate C++ binding > > - p259.13: Delete duplicate C++ binding > > - p260.36-43: First letter of description should be capitolized to be > consistent with rest of list. > > - p261.42: Delete duplicate C++ binding > > - p263.21-23: Delete duplicate C++ bindings > > - p264.22: Delete duplicate C++ binding > > - p267.24: Delete duplicate C++ binding > > - p267.42: Delete duplicate C++ binding > > Process Creation and Management > =============================== > > - p288.11: Function should be const. > --> This will require a vote. > > - p288.15: Function should be const. > --> This will require a vote. > > External Interfaces > =================== > > - p344.39: Arguments of query_fn, free_fn, and cancel_fn need to have > *'s. This is a consistency issue (the rest of the standard uses > "*" for function pointer parameters), not a correctness issue -- > works both ways. Should not break any user code or MPI > implementations. > > I/O > === > > - p419.43: datatype argument should be const > > Language Bindings > ================= > > - p437.18: Delete first sentence of paragraph > > - p437.22: Delete "original" > > - p437.24-29: Delete first and last sentences of paragraph > > - p437.29: New last sentence, "See Annex A.4.19 for a function cross > reference." > > - p438.11: Delete "for MPI-1" > > - p438.14-37: Join the two namespaces together and delete the > "Additionally, the following classes defined for MPI-2:" text. > Re-sort the class names as appropriate. > > - p439.2: Delete last sentence ("To maintain ... in [23].") > > - p442: Table 13.1 is redundant with Annex A.1. However, the > following C++ types are missing from Annex A.1: > > MPI::SIGNED_CHAR > MPI::BOOL > MPI::COMPLEX > MPI::DOUBLE_COMPLEX > MPI::LONG_DOUBLE_COMPLES > > - p442: Table 13.2 is redundant with Annex A.1 > > - p445.5-11: These functions are not listed in Annex A > > - p445.36-38: Remove this entire paragraph ("Compilers that do not > support..."). This feature has been a part of C++ since C++98, and > exists in all modern C++ compilers. > > - p446.7-17: Declarations for the MPI::Exceptions class are missing > from Annex A > > - p448.47: Remove trailing "/" from "OUT/" > > - p450.26-44: The bullet list is wholly redundant with section 2.6.2. > > - p456.27-29: VOLATILE is in Fortran 200x; reword first sentence from: > "In the longer term, the attribute VOLATILE is under > consideration for Fortran 2000 and would give the buffer or > variable the properties needed, but it would inhibit > optimization of any code containing the buffer or variable." > to > "The VOLATILE attribute, available in later versions of Fortran, > would give the buffer or variable the properties needed, but it > would inhibit optimization of any code containing the buffer or > variable." > > - p459.11-15: Delete paragraph > > - p462.43-45: Delete paragraph > > - p463.17-18: Delete first sentence; delete "In MPI-2," > > - p467.23: There is an extra space before "MPI_FINALIZE" > > - p468.16-39: None of these functions appear in Annex A (they > should!) > > - p469.41 and 44: These functions do not appear in Annex A (they > should!) > > - p470.46: Change sentence from: > "It is important to note that all C++ objects and their > corresponding C handles..." > to > "It is important to note that all C++ objects with > corresponding C handles..." > I.e., this sentence is referring only to C++ handles that actually > have corresponding C handles (e.g., not > MPI::ERRORS_THROW_EXCEPTIONS). > > Profiling Interface > =================== > > - p481.4: Delete "const" > --> This may require a vote. > > Annex A > ======= > > - p494.15: s/Fortran/Fortran only > > - p494.30: Missing MPI::ERRORS_THROW_EXCEPTIONS > > - p495.18-19 and 33-34: MPI_BYTE and MPI_PACKED are listed in two > separate tables. > > - p495.30: MPI::COMPLEX should be MPI::F_COMPLEX > > - p495.38: Looks like a blank extra 3rd column is in this table > > - p495.bottom: Missing table for "C++ only" datatypes: > MPI::BOOL > MPI::COMPLEX > MPI::DOUBLE_COMPLEX > MPI::LONG_DOUBLE_COMPLEX > MPI::SIGNED_CHAR > > - p496.1: Add ", no Fortran" before the ")" > > - p496.10, s/Fortran/Fortran only/ > > - p496.27-30: Alignment of table entries should be to the left, not > centered. > > - p544.13: Many of the prototypes for Clone() and Dup() are missing > > - p547.all: Many doubles of C++ bindings; likely because of errors in > the chapter text. > > - p554.41: Do we need an empty deprecated functions section? > > - p555.45-46: Forgot to mention MPI_ERRCODES_IGNORE, > MPI_F_STATUSES_IGNORE, and MPI_F_STATUS_IGNORE > > - p556.bottom: Missing prototypes for the MPI::Exceptions class > > -- > Jeff Squyres > Cisco Systems > > _______________________________________________ > mpi-21 mailing list > mpi-21_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-21 >

1 0