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

Re: [Mpi-21] Review of MPI-2.1 combined document
by unknown＠example.com 05 Mar '08

05 Mar '08

On Feb 23, 2008, at 4:19 PM, Rolf Rabenseifner wrote: > The first draft of the combined document MPI 1.x plus MPI 2.0 > is ready for review !!! A few general comments on the document: - I love the new items in the index (constants, typedefs, etc.). Very useful! - I see a few EXAMPLES items in the index. But this is clearly not *all* the examples. What's the intent for these items? - p568 in the index has a whole series of lower-case CONST items in the second column that appear to be mistakes (e.g., column headings and the like). Ditto for both columns on page 565 (first page of the index). It looks like a macro is being mis-used throughout the latex...? - It would be really, Really, REALLY nice if the printed page numbers agreed with the PDF page numbers. :-) E.g., the first page of the index has "565" on the bottom of the page, but my PDF viewer tells me that it's really page 583. - How about adding a list of tables and list of figures to the beginning of the document (after the TOC)? How about possibly a list of examples? (I don't know if that's as trivial to generate as LOF/LOT) - In the credits on pages xvi and xvii, should institutions participating in MPI-2.1 be listed? (I can't remember if we discussed this at the last meeting) I.e., there are organizations contributing to the 2.1 document who are not being given credit (e.g., Cisco :-) ). - page 3: "MPI-2 compliance will mean compliance with all of MPI-2." The statement right above that says "MPI-1 compliance will mean compliance with MPI-1.2.", but the credits (page xviii) cite MPI-1.3 and MPI-2.1. - page 5: I see "MPI-2" are in the wrong font twice (there may be more?). - I still have a problem with the wording in section 2.3 about IN / OUT / INOUT, particularly because in section 2.3 we say that IN/OUT/ INOUT does *not* correspond to language bindings, but section 2.6.4 (pages 21-22) specifically states that IN arguments were made "const" in the C++ bindings. I also still have a problem with the special exception for INOUT. Are these topics covered in a ballot somewhere? (those are on my to-do list to examine; haven't gotten there yet...). -- Jeff Squyres Cisco Systems

1 0

MPI-2.1: Fortran 90 bindings
by unknown＠example.com 05 Mar '08

05 Mar '08

The current MPI-2 F90 bindings are un-implementable because they require almost 7 *million* interface functions: with 15 intrinsic Fortran types, each with 7 possible dimensions, the current F90 interface *requires*: - 50 MPI functions with one choice buffer: 15 * 7 * 50 = 5,250 functions - 25 MPI functions with two choice buffers: (15 * 7 * 25)^2 = 6.8M functions - ...and a few hundred more MPI functions with no choice buffers This is clearly broken. An MPI-2.1-worthy solution could be to add a global statement saying that MPI functions with two choice buffers are explicitly not included in the F90 bindings. F90 MPI applications can transparently fall back to the F77 bindings (although they won't get the strong type checking, etc.). This idea therefore fits the requirement of not breaking any existing MPI codes. Specifically: if we remove the requirement to provide all MPI functions with two choice buffers, 5,000+ F90 interface functions is [a pain but] implementable. I doubt that any current MPI implementation provides more than the no-choice-buffers plus one- choice-buffer functions anyway... If this seems like a good idea, I can write a proper proposal for it. Comments? -- Jeff Squyres Cisco Systems

1 0

Re: [Mpi-21] Review of MPI-2.1 combined document
by unknown＠example.com 05 Mar '08

05 Mar '08

On Feb 23, 2008, at 4:19 PM, Rolf Rabenseifner wrote: > Dear reviewer: > Please print your chapter with colors (!) and check all merging > decisions. > The colors will help to identify MPI 1.1-1.3 (black), > MPI-2.0 (magenta) and new text that was necessary for the merge (red). Is there a way to use different colors, perchance? The language bindings chapter is all MPI-2 (magenta); it is nearly impossible to tell if there is any merge text in it (red). -- Jeff Squyres Cisco Systems

1 0

Re: [Mpi-21] [mpi-21] problem with MPI_Get_count and MPI_Probe
by unknown＠example.com 05 Mar '08

05 Mar '08

I did not notice this until I was going over the Ballot 4 slides. I would prefer not to vote in the currently proposed wording The correction is for page 22, not 222 I propose: MPI 1.1, page 22, line 48 reads used after a call to MPI_PROBE. (End of rationale.) but should read used after a call to MPI_PROBE or MPI_IPROBE. In this case the call to MPI_GET_COUNT should use the same datatype as will be used in the MPI_RECV. (End of rationale.) (Advice to users.) The buffer size required for the receive can be affected by data conversions and by the stride of the receive datatype. Calling MP_GET_COUNT with MPI_BYTE to calculate the receive buffer size may not be portable unless the MPI_RECV uses MPI_BYTE. (End of advice to users.) 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/18/2008 12:55:09 PM: > This is a proposal for MPI 2.1, Ballot 4. > > This is a follow up to: > Datatypes and MPI_PROBE > 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/probedatatype/ > > > Proposal for MPI 2.1, Ballot 4: > ------------------------------- > MPI 1.1, page 222, line 48 reads > used after a call to MPI_PROBE. (End of rationale.) > but should read > used after a call to MPI_PROBE or MPI_IPROBE. > With a status returned from MPI_PROBE or MPI_IPROBE, the same > dataypes are allowed as in a call to MPI_RECV to receive this message. > (End of rationale.) > > Advice to users. To allocate the appropriate amount of memory as receive > buffer, the same datatype as in the following receive call should be used > to determine the needed space. In portable programs due to possible data > conversions, it is not guaranteed that the count returned by MPI_GET_COUNT > with datatype MPI_BYTE is the correct amount of needed memory space in > the receive buffer (although MPI_BYTE is matching every datatype). > (End of advice to users.) > ------------------------------- > > Reason for the first part: The current MPI-1.1 text says "The > datatype argument > should match the argument provided by the receive call that set the status > variable." With MPI_PROBE, there isn't such a receive call. > > Reason for the advice to users: It helps to write portable code. > Because malloc needs a byte count, users may write wrong programs > by using MPI_BYTE. > > ------------------------------- > > Discussion should be done through the new mailing list > mpi-21_at_cs.uiuc.edu. > > I have sent out this mail with CC through the old general list > mpi-21_at_[hidden] > > 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) > _______________________________________________ > mpi-21 mailing list > mpi-21_at_[hidden] > http://lists.cs.uiuc.edu/mailman/listinfo/mpi-21 *

1 0

Re: [Mpi-21] [mpi-21] problem with MPI_Get_count and MPI_Probe
by unknown＠example.com 05 Mar '08

05 Mar '08

I did not notice this until I was going over the Ballot 4 slides. I would prefer not to vote in the currently proposed wording The correction is for page 22, not 222 I propose: MPI 1.1, page 22, line 48 reads used after a call to MPI_PROBE. (End of rationale.) but should read used after a call to MPI_PROBE or MPI_IPROBE. In this case the call to MPI_GET_COUNT should use the same datatype as will be used in the MPI_RECV. (End of rationale.) (Advice to users.) The buffer size required for the receive can be affected by data conversions and by the stride of the receive datatype. Calling MP_GET_COUNT with MPI_BYTE to calculate the receive buffer size may not be portable unless the MPI_RECV uses MPI_BYTE. (End of advice to users.) 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 "Rolf Rabenseifner" <rabenseifner_at_hlr To s.de> mpi-21_at_[hidden] Sent by: cc mpi-21-bounces_at_cs mpi-21_at_[hidden] .uiuc.edu Subject Re: [mpi-21] problem with MPI_Get_count and MPI_Probe 01/18/2008 12:55 PM Please respond to "Mailing list for discussion of MPI 2.1" <mpi-21_at_cs.uiuc.e du> This is a proposal for MPI 2.1, Ballot 4. This is a follow up to: Datatypes and MPI_PROBE in http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi-errata/index.… with mail discussion in http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi-errata/discus… Proposal for MPI 2.1, Ballot 4: ------------------------------- MPI 1.1, page 222, line 48 reads used after a call to MPI_PROBE. (End of rationale.) but should read used after a call to MPI_PROBE or MPI_IPROBE. With a status returned from MPI_PROBE or MPI_IPROBE, the same dataypes are allowed as in a call to MPI_RECV to receive this message. (End of rationale.) Advice to users. To allocate the appropriate amount of memory as receive buffer, the same datatype as in the following receive call should be used to determine the needed space. In portable programs due to possible data conversions, it is not guaranteed that the count returned by MPI_GET_COUNT with datatype MPI_BYTE is the correct amount of needed memory space in the receive buffer (although MPI_BYTE is matching every datatype). (End of advice to users.) ------------------------------- Reason for the first part: The current MPI-1.1 text says "The datatype argument should match the argument provided by the receive call that set the status variable." With MPI_PROBE, there isn't such a receive call. Reason for the advice to users: It helps to write portable code. Because malloc needs a byte count, users may write wrong programs by using MPI_BYTE. ------------------------------- Discussion should be done through the new mailing list mpi-21_at_cs.uiuc.edu. I have sent out this mail with CC through the old general list mpi-21_at_[hidden] 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) _______________________________________________ mpi-21 mailing list mpi-21_at_[hidden] http://lists.cs.uiuc.edu/mailman/listinfo/mpi-21 *

1 0

MPI 1.3 Review
by unknown＠example.com 05 Mar '08

05 Mar '08

Dear Bill, Adam, and Puri, (and all who are also interested,) you have volontiered for the MPI-1.3 review. I'm sorry that we could not finish MPI-1.3 earlier. It is now available (see attached email). Please, control whether all the clarifications and decisions from (you'll find all input via the doc-directory mentioned below) - MPI 1.2 pages in MPI-2 document - Additional Errata from MPI 1.1 errata document - Some Ballot 3 items from Jan. meeting - MPI 1.3 decisions from Jan. meeting (see protocol slides) are exactly put into the MPI-1.1 document. The rest of MPI-1.1 was not touched by Rainer and should be okay therefore. Based on my impression from an earlier version, I want to thank Rainer for this important initial step to the future of combined MPI documents. Thank you for the reviews in advance and best regards, see you in Chicago 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) --- the forwarded message follows --- <strong>attached mail follows:</strong> Because MPI-1.3 and MPI-2.1 review at March meeting is the preparation of the final "reading" at June meeting, I want to inform the whole Forum that the files are available at http://www.hlrs.de/mpi/mpi21/ You need mpi21 as user and password when you klick on the doc link. There, you can find all necessary information. 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] Review of MPI-2.1 combined document
by unknown＠example.com 05 Mar '08

05 Mar '08

Comments on Chapter 5 of the 2.1 MPI standard (Robert Blackmore & Dick Treumann) Page 175, line 37-39 should be removed because it says there is no CC on intercommunicators Page 176, lines 1-6 also indicate there is no CC on intercommunicators page 177, line 10 indicate there is no CC on intercommunicators page 177, line 36 - should say MPI_INIT or MPI_INIT_THREAD page 178 line2 - Should say "Therefore, MPI_COMM_WORLD may simultaneously represent disjoint groups in different processes" page 186, line 19-22 - needs to be rephrased or removed. At least change "currenty apply" to "In MPI-1, applied" The last bullet at line 48 on page 200, "An inter-communicator cannot be used for collective communication" should be removed. The comment in parenthesis at line 24 on page 203 should be deleted along with the line before it. These two sentences contradict the sentence at line 23. (This conflict predates the merge and perhaps fixing this belongs to an erratta process - We do think it should be fixed) page 203, lines 38-42 are not consistent with how MPI-2 defined spawn. These lines should be removed Optionally, the description of MPI_Keyval_free should be moved to MPI_Comm_free_keyval and the routine MPI_Keyval_free function should refer to MPI_Comm_free_keyval description. Optionally, the description of MPI_Attr_put should be moved to MPI_Comm_set_attr and the routine MPI_Attr_put function should refer to MPI_Comm_set_attr description. Optionally, the description of MPI_Attr_get should be moved to MPI_Comm_get_attr and the routine MPI_Attr_get function should refer to MPI_Comm_get_attr description. Optionally, the description of MPI_Attr_delete should be moved to MPI_Comm_delete_attr and the routine MPI_Attr_delete function should refer to MPI_Comm_delete_attr description. On page 226 line 36, MPI_Keyval_create should be replaced by MPI_comm_create_keval On page 226 line 47 MPI_Attr_get should be replaced by MPI_Comm_get_attr. On page 227 line 22 MPI_Attr_put should be replaced by MPI_Comm_set_attr. 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 *

1 0

Review of topology chapter 6
by unknown＠example.com 04 Mar '08

04 Mar '08

In general this section needs updating. It often reads like its trying to convince the reader that the functionality is worthwhile. Would also benefit from an update to citations in support of capabilities and features. Some text is clunky. Suggestions, corrections, observations, based on MPI 2.1, draft 2008-02-23. 1. p231, line 41: The citation supporting the performance potential of graph defined topologies is from 1989. Are there more recent citations to supplement? Similar question for other citations throughout the chapter. 2. p231, line 47: ³with tremendous benefits for program readability². I appreciate the optimistic tone, but perhaps a little less hype: ³with potential benefits² 3. p232, line 6: ³The nodes stand for². How about, ³represent²? 4. p232, line 7: ³MPI provides message-passing between any pair of processes in a group.² This seems to imply that topologies are only applicable to point-to-point communication. If so, we should clearly say so, earlier. 5. p232, line 17: Citation [9] is listed as ³To appear.² 6. p232, Lines 23-29. This seems like unnecessary rationalization. Unless it can be substantiated (with a citation), it should be removed. How about, ³When the graph structure is regular and can be completely defined by the number of dimensions and the number of processes in each coordinate direction, such as rings, two- or higher dimensional grids, or tori, a simpler description can be made² or the like. And then talk about support for Cartesian topologies, which suddenly is mentioned on 6.4, line 3 7. p233, line 5. How about, ³are collective, and therefore must adhere to that category¹s requirements.² Clunky, but the idea 8. p233, line 19: ³Similar functions are contained in EXPRESS and PARMACS.² Can we update (or eliminate) this? Sounds like, ³All the other kids are doing it.² :) 9. p233, line 22-33. Reads clunky. In particular, ³foo can be used to² Implies they are designed primarily for something else. And perhaps provide a high level sentence regarding the content of the paragraph: ³A variety of inquiry functions are provided.² (Which then calls for a bit of a reorganization of the paragraph, since sub-setting functionality is discussed as well. 10. p234, line 27. ³choose a beneficial² rather than ³good². (Could be great! Or ok, or) 11. p237, line 19-20. ³If a topology has been defined with one of the above functions² How else? Instead: ³Information regarding a process topology can be returned using inquiry functions.² Or something like that. 12. p238, line 6. Is ³dimension² a verb? 13. p241, line 15. I prefer, ³Suppose this topology is associated with communicator comm...² 14. p241, line 34. ³an MPI_SENDRECV², since a¹ and an¹ are selected based on the vowel or consonant sound. Or are these fightin¹ words? :) Errata: 1. pg 237, line 26: (choice) s/b (status). 2. The other errata seems to have been satisfied. Long example, p246. Any verification of correctness available? No complaints in the errata. Richard -- Richard Barrett Future Technologies Group, Computer Science and Mathematics Division, and Scientific Computing Group, National Center for Computational Science Oak Ridge National Laboratory http://ft.ornl.gov/~rbarrett

1 0

Re: [Mpi-21] Review of MPI-2.1 combined document
by unknown＠example.com 04 Mar '08

04 Mar '08

The MPI standard has several references to ANSI C and on page 15 of the combined doc we say to read ANSI C as ISO C. Does it make sense to fix this and just refer to ISO C? We might want to mention that the original books said ANSI C and the combined book has rectified that 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 *

1 0

Re: [Mpi-21] Review of MPI-2.1 combined document
by unknown＠example.com 04 Mar '08

04 Mar '08

What about the usage of deprecated functions? (for example, the old attribute functions, old datatype constructors, ...) Since the code examples were not modified, they often still use versions that were deprecated in later versions of the standard. (see pg. 17 in the merged document) Examples (by no means complete list): (pg. number in merged document) MPI_Attr_get: 309, 229, 244 MPI_Attr_put: 409, 227 MPI_Keyval_create : 244, 227 ... Greetings, Dries * Rolf Rabenseifner <rabenseifner_at_[hidden]> [2008-02-23 22:19:18]: > The first draft of the combined document MPI 1.x plus MPI 2.0 > is ready for review !!! > All necessary files can be found via > http://www.hlrs.de/mpi/mpi21/ > The files are stored in a restricted directory to prohibit that > search engines can find the drafts. > Dear reviewer: > Please print your chapter with colors (!) and check all merging decisions. > The colors will help to identify MPI 1.1-1.3 (black), > MPI-2.0 (magenta) and new text that was necessary for the merge (red). > The review should be finished a few days before the March meeting. > Please post your review results on mpi-21_at_[hidden] as reply to this > mail. > Please note, which chapter you reviewed. > Please refer with all comments exactly to page and line numbers of > - MPI 1.1, the official Postscript version > - MPI 2.0, the official Postscript version > - MPI 2.1, draft 2008-02-23 from http://www.hlrs.de/mpi/mpi21/ > - and the merging plan 2008-02-23, that you can find at same directory > If you detect a problem, it is necessary that you try to propose > a solution in similar notation as used in the merging plan. > I have finished all except the merging of the MPI-1 C++ bindings > into the chapters' text, and except of merging the Annexes. > The Ballots 1-4 are also not included. > In the moment, you need to review only the "merging". Nothing more. > If you detect errors in the original standards, then please > go through normal procedure, i.e., through the MPI 2.1 and MPI 2.2 > ballots. > And now, thank you very much that you have registered to do a > review (if you are on the list below, done in Jan.2008 meeting). > Good luck. > Best regards > Rolf > ---------------------------------------------------- > Frontmatter: (I've done a new proposal for the abstract, please check) > - Rusty Lusk, Bill Gropp > Chap. 1: Introduction to MPI > - Rusty Lusk, Bill Gropp, Karl Feind, Adam Moody > Chap. 2: MPI-2 Terms and Conventions > - Tony Skjellum, Bill Gropp, Richard Barrett > Chap. 3: Point-to-Point Communication (incl. sections from MPI-2 Misc. + 8.9) > - Rich Graham, Jespar Larsson Traeff, George Bosilca, > Steve Poole, Kannan Narasimhan, David Solt, B. Gropp, Matt Koop > Chap. 4: Collective Communication (incl. sections from MPI-2 Ext. Collect.) > - Steven Ericsson-Zenith, Edgar Gabriel, Rajeev Thakur, > Bill Gropp, Adam Moody, Georg Bosilca > Chap. 5: Groups, Context, and Communicators > (incl. sections from MPI-2 Ext.Col. + 8.8) > - Steven Ericsson-Zenith, Edgar Gabriel, > Bill Gropp, Georg Bosilca, Robert Blackmore > Chap. 6: Process Topologies > - Rusty Lusk, Bill Gropp, Richard Barrett > Chap. 7: MPI Environmental Management (incl. sections from MPI-2 Misc.) > - Rich Graham, Jespar Larsson Traeff, George Bosilca, > Steve Poole, Kannan Narasimhan, David Solt, B. Gropp > Chap. 8: Miscellany > - Rich Graham, George Bosilca, > Steve Poole, Kannan Narasimhan, B. Gropp > Chap. 9: Process Creation and Management > - Dries Kimpe, Rusty Lusk, Georg Bosilca, Bill Gropp, > Kalem Karian > Chap. 10: One-Sided Communication > - Ericsson-Zenith, Jespar Larsson Traeff, Martin Schulz, > Bill Gropp, Darius Buntinas > Chap. 11: External Interfaces > - Bronis de Supinski, Bill Gropp > Chap. 12: I/O > - Rajeev Thakur, Joachim Worringen, Bill Gropp > Chap. 13: Language Bindings > - Jeff Squyres, Steve Poole, Purushotham Bangalore, > Bill Gropp, Erez Haba, Alexander Supalov > Chap. 14: Profiling Interface > - Bronis de Supinski, Bill Gropp, Jeff Brown > Bibliography: (is done automatically) > - Rusty Lusk, Bill Gropp > Annex A: (this chapter is not yet done - therefore no review for this) > - Jeff Squyres, Steve Poole, Purushotham Bangalore, > Bill Gropp, Alexander Supalov > Index: (is done automatically) > - Rusty Lusk, Bill Gropp > 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 *

1 0