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

Call for agenda items for MPI 2.2 at the next MPI Forum Meeting
by unknown＠example.com 10 Apr '08

10 Apr '08

Please let me know if you have agenda items for MPI 2.2. To date, we have Remove Send Buffer Access Restriction http://svn.mpi-forum.org/trac/mpi-forum-web/wiki/SendBufferAccess Adding const Correctness to the C Bindings http://svn.mpi-forum.org/trac/mpi-forum-web/wiki/ConstCorrectness Miscellaneous items moved to 2.2 from the 2.1 discussions. I've also received a heads up about issues with globalization and making MPI APIs secure (this latter is probably an MPI-3 item). If those are ready, they can be added. Bill William Gropp Paul and Cynthia Saylor Professor of Computer Science University of Illinois Urbana-Champaign

1 0

Revisiting C++ Language binding sections in MPI-standard
by unknown＠example.com 07 Apr '08

07 Apr '08

Moved to MPI-2.2 mailing list - reasons see below. Jeff and Bronis, yes, I agree that language binding should stay at the end. I put PMPI behind, because Chap.1-13 describe all MPI-routines and Chap.14 (Profiling) translates all into MPI+PMPI. I agree with Jeff, that > If stuff is wrong/outdated in Chapter 2, then it should be fixed. This was mainly job of Ballots 1-4 in MPI-2.1 and will be job of Ballot 5 in MPI-2.2 I do not agree to: > If stuff in Chapter 2 really belongs in a Language Bindings chapter, > then it should be moved. because there are, e.g., 20 lines on C-binding - the only 20 lines! They should not be moved to the end of the standard. I would really like to move this discussion to MPI-2.2 because it transforms a consistent MPI standard into another consistent MPI standard, with one exception: If there are bugs in 2.6.4, then they should be fixed. But those bugs are not caused by the merge because Sect. 2.6.4 and Chap. 13 are all MPI-2 texts. Therefore it would have been a Ballot 4 discussion. And because Ballot 4 is finished, this is a MPI-2.2 discussion. Therefore I changed the mailing-list to MPI-2.2. I also believe, it will be an MPI-2.2 decision whether to keep all C++ binding stuff together in Chap. 13.1 or whether to move all the things into diverse locations in the other chapters. These location are currently not defined, because there is no special wording on C and Fortran. Fortran is mainly mentioned in datatype stuff and the caching callback functions. Best regards Rolf On Mon, 7 Apr 2008 11:22:47 -0700 (PDT) "Bronis R. de Supinski" <bronis_at_[hidden]> 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 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-22] 2.1 cleanup or MPI 2.2?
by unknown＠example.com 07 Apr '08

07 Apr '08

Dick, if I'm right, then 23.r is not similar. 23.r OK p183, lines 5-8. This advice to implementors on reference counts for groups should include MPI_COMM_GROUP as a routine that increments the reference count. I've put yours as 29.a in http://www.hlrs.de/mpi/mpi21/doc/MPI-2.1draft-2008-02-23-review.txt 23.r I made an OK, but for your 29.a I would recommend to go to MPI-2.2. Best regards Rolf On Mon, 7 Apr 2008 10:54:00 -0400 Richard Treumann <treumann_at_[hidden]> wrote: > > > In the description of MPI_COMM_FREE we presently give the following advise > to implementors. > > A reference-count mechanism may be used: the reference count is > incremented by each call to \func{MPI\_COMM\_DUP}, and decremented by > each call to \func{MPI\_COMM\_FREE}. The object is ultimately > deallocated when the count reaches zero. > > I do not think it can ever be valid to implement MPI_COMM_DUP by simply > returning a new handle for an existing communicator object while bumping > its reference count because the output communicator must have a different > context than the original. Assuming I have not missed something, it seems > this advise is nonsense. > > Is removing this the kind of change that should go on the MPI 2.2 list? I > will be surprised if anyone offers a rationale for keeping the advise but I > am also not quite comfortable that it fits within the "clean up" rules for > MPI 2.1 at this late stage. > > Thoughts? > > Dick > > > > 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 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

catalog of issues
by unknown＠example.com 07 Apr '08

07 Apr '08

Is there a catalog of issues that will be considered as part of MPI 2.2? The WIKI has something about send buffer access and about C bindings const correctness but I am not aware of a place where I can see whether some issue has been listed as an MPI 2.2 topic. There are assorted suggestions from MPI 2.1 that were deemed too controversial or complex and got moved to MPI 2.2 but I do not have a list. There are topics like MPI_ALLTOALLX that I assume are to be considered. There are others we have discussed in the past like what it means with MPI_ERRORS_ARE_FATAL if MPI_ALLOC_MEM cannot provide the requested space. (Do we add MPI_TRY_ALLOC_MEM(size, info, baseptr, av_flag and deprecate MPI_ALLOC_MEM? Mem not available would still return MPI_SUCCESS and the app would test av_flag to be sure the memory was actually provided.) There are some that may have not been mentioned before (or maybe they have and I do not recall). For example should there be an MPI_GROUP_DUP? There are more I could think of and many I would not think of off hand. It would be helpful to be able to check somewhere and see if an issue that does cross my mind has already been recognized as an MPI 2.2 topic. Dick 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

MPI 2.2 comments on 1 April document
by unknown＠example.com 07 Apr '08

07 Apr '08

While reviewing Rolf's April document, I came up with a list of MPI 2.2 issues that I thought I'd bring up: Sections: - Miscellaneous - IO (long itemization) - Language bindings --------------------------------------- Based on 1 April 2008 document Miscellaneous ============= - We need to update the Fortran renferences throughout the document (F90 -> F?03?). IO chapter ========== fh parameter should be IN (not INOUT) - p381.5 - p381.44 - p384.31 - p387.6 - p394.6 - p394.31 - p395.31 - p396.22 - p397.27 - p398.2 - p398.25 - p399.2 - p400.2 - p400.22 - p402.18 - p402.40 - p403.15 - p403:36 - p404.33 - p405.8 - p405.38 - p409.2 - p409.22 - p409.38 - p410.9 - p410.25 - p410.43 - p411.10 - p411.28 - p412.2 - p412.20 - p423.39 - p424.37 C++ bindings functions should be const - p381.14 - p382.4 - p384.39 - p387.24 - p393.19,21 - p393.44,46 - p394.23,25 - p394.48 - p395.2 - p395.25 - p395.48 - p396.36,38 - p397.42,45 - p398.17,19 - p398.39,42 - p399.17 - p400.17 - p400.32 - p401.11 - p401.35 - p402.32,35 - p403.7,9 - p403.29 - p404.3 - p404.48 - p405.2 - p405.23,25 - p405.48 - p408.22 - p408.37,38 - p409.18 - p409.32,33 - p410.4 - p410.19,20 - p410.38 - p411.4,5 - p411.23 - p411.38,39 - p412.15 - p412.30,31 - p424.1 - p424.44 Language bindings chapter ========================= - p441.31-33: Replace entire paragraph with: "Constants Constants are singleton objects and are declared const. The only exception is MPI::BOTTOM, which cannot be const because it can be passed as a receive buffer argument, which is not const." >>> Need to fix various C++ binding methods to be const (e.g., Set_name, Set_errhandler, etc.) >>> Same arguments I've raised for a while: all MPI predefined C++ handles should be const except BOTTOM. Short argument: - have to be able to use MPI::COMM_WORLD for initialization before MPI::Init, so they *are* const because they're initialized before main() - the "const" refers to the C++ handle, not the back-end MPI object - the handle does not change (just like MPI_SEND where "comm" argument is IN and the method is const) -- Jeff Squyres Cisco Systems

1 0

2.1 cleanup or MPI 2.2?
by unknown＠example.com 07 Apr '08

07 Apr '08

In the description of MPI_COMM_FREE we presently give the following advise to implementors. A reference-count mechanism may be used: the reference count is incremented by each call to \func{MPI\_COMM\_DUP}, and decremented by each call to \func{MPI\_COMM\_FREE}. The object is ultimately deallocated when the count reaches zero. I do not think it can ever be valid to implement MPI_COMM_DUP by simply returning a new handle for an existing communicator object while bumping its reference count because the output communicator must have a different context than the original. Assuming I have not missed something, it seems this advise is nonsense. Is removing this the kind of change that should go on the MPI 2.2 list? I will be surprised if anyone offers a rationale for keeping the advise but I am also not quite comfortable that it fits within the "clean up" rules for MPI 2.1 at this late stage. Thoughts? Dick 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