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

Re: [Mpi-21] Chapter 5
by unknown＠example.com 09 Apr '08

09 Apr '08

Someone also suggested that object naming move to join caching. If we take Jesper's suggestion then object naming would become part of this new chapter too. It all makes sense to me but I do not know who has the cycles to do the work. I do not 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 mpi-21-bounces_at_[hidden] wrote on 04/09/2008 02:50:22 AM: > > Dick, Rolf, all, > > On Tue, Apr 08, 2008 at 07:46:27PM -0400, Richard Treumann wrote: > > > > 4) The discussion of attribute caching needs significant rework. It has > > paragraphs from when only communicators supported caching and paragraphs > > about adding caching support to windows and datatypes. It should be > > reworded to describe caching as it applies to all three object types and > > explain who there is no WIN_DUP while there is a TYPE_DUP and a COMM_DUP. > > (and therefore no attribute copy functions for windows.) > > > I agree with that. A not so modest proposal (requiring work) would be > to have a seperate chapter on object caching, and merge that with the > chapter on the info object (which is too short on its own, and still has > the hopeless "miscellany" title)? > > Jesper > > [attachment "smime.p7s" deleted by Richard > Treumann/Poughkeepsie/IBM] _______________________________________________ > mpi-21 mailing list > mpi-21_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-21 *

1 0

Re: [Mpi-21] Rest of MPI-2.1 External interfaces into other chapters.
by unknown＠example.com 09 Apr '08

09 Apr '08

I can't build the language bindings appendix because the new scripts assume new GNU versions of some standard Unix commands (like sort), and my Mac doesn't have those versions. Can we stick with the more portable versions (e.g., in MAKE-APPLANG, don't use --key, which my sort command does not recognize and is, I believe, a GNU extension)? While we're at it, pdfinfo isn't standard either - is this really necessary for the Make (which for me always fails at this step)? There's a pdfinfo command for Macs, but it pops up a GUI and that's probably not intended (and certainly not appropriate). Bill William Gropp Paul and Cynthia Saylor Professor of Computer Science University of Illinois Urbana-Champaign *

1 0

Re: [Mpi-21] Chapter 5
by unknown＠example.com 09 Apr '08

09 Apr '08

Dick, Rolf, all, On Tue, Apr 08, 2008 at 07:46:27PM -0400, Richard Treumann wrote: > > 4) The discussion of attribute caching needs significant rework. It has > paragraphs from when only communicators supported caching and paragraphs > about adding caching support to windows and datatypes. It should be > reworded to describe caching as it applies to all three object types and > explain who there is no WIN_DUP while there is a TYPE_DUP and a COMM_DUP. > (and therefore no attribute copy functions for windows.) > I agree with that. A not so modest proposal (requiring work) would be to have a seperate chapter on object caching, and merge that with the chapter on the info object (which is too short on its own, and still has the hopeless "miscellany" title)? Jesper *

1 0

Language bindings
by unknown＠example.com 09 Apr '08

09 Apr '08

I have committed the changes to the language bindings chapter (r75). ------------- I had two questions about Rolf's list for chapter 13: JMS WHY IS THIS AN MPI-2.2 ISSUE? 32.r 22 p463.17-18: Delete first sentence; delete "In MPI-2," JMS WHY IS THIS A QUESTION MARK? 32.v ? 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). ------------- One answer to a question in Rolf's list: JMS THE NAMES THAT ARE THERE ARE GOOD 32.j' ? Which names should be visible in the Index for Dup and Clone? ------------- And here's the items that I completed: JMS DONE 32.a R2 p437.18: Delete first sentence of paragraph Editor's comment: Please check the "this interface" in the next sentence. This is a backward reference to the first sentence. JMS DONE 32.b R2 p437.22: Delete "original" Editor's comment: Please check "original ... was based". Removing "original" may need further corrections. JMS DONE 32.c R2 p437.24-29: Delete first and last sentences of paragraph Editor's comment: See also Review item 28.q JMS DONE 32.d R2 p437.29: New last sentence, "See Annex A.4.19 for a function cross reference." JMS DONE 32.e R2 p438.11: Delete "for MPI-1" JMS DONE 32.f R2 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. JMS DONE 32.g R2 p439.2: Delete last sentence ("To maintain ... in [23].") JMS DONE 32.k R2 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. JMS DONE 32.p *NO* p459.11-15: Delete paragraph Editor's comment: The first MPI-1 should be substituted by MPI, the second MPI-1 should be removed. The paragraph is still valid. JMS CHANGED MPI-1 to MPI 32.q *NO* p462.43-45: Delete paragraph Editor's comment: The paragraph is still valid. -- Jeff Squyres Cisco Systems

1 0

Chapter 5
by unknown＠example.com 08 Apr '08

08 Apr '08

Rolf - My attempt to check in the file did not work and since I am not familiar with svn I did not try very long to debug the failure. The file is attached to this email. If you can get it into the repository you have the write token. (See attached file: context.tex) Chapter 5 - items needing Forum feedback (references are to April 1 draft) 1) 171:28-29 We point to a couple 15 year old papers to give background on using MPI to write libraries. It seems to me the concepts no longer require this backup. They have been around for long enough to be current practice. Is there a reason to keep the pointers? 2) 192:8-13 Bogus advise about just playing with the reference count to implement MPI_COMM_DUP (I think Rolf has already captured this for MPI 2.2) 3) 202:31-35 The wierd suggestion that intercommunicator groups may not be required to be disjoint should come out. Everything else is pretty clear that they ARE disjoint. As far as I can see this statement falls into the catagory of "We could have made a different choice when we wrote MPI-1". The decision was made that the groups are disjoint so this editorial aside should be removed. 4) The discussion of attribute caching needs significant rework. It has paragraphs from when only communicators supported caching and paragraphs about adding caching support to windows and datatypes. It should be reworded to describe caching as it applies to all three object types and explain who there is no WIN_DUP while there is a TYPE_DUP and a COMM_DUP. (and therefore no attribute copy functions for windows.) 5) Jeff Squires has pointed out a need for explanation of the C++ clone functions on 186:1-5 and to me it looks like a sentence or two from a C++ guru along with a pointer to section 13.1.7 would do. Perhaps add: Please see section ____ page ___ for further discussion about the C++ bindings for Dup() and Clone(). where ____ page ___ is a link to 13.1.7. (I did not want to try to add a LaTex link so I did not do any of this change) The changes I have made are pretty straightforward. 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

Re: [Mpi-21] Newest updates
by unknown＠example.com 08 Apr '08

08 Apr '08

The new indexes are a good idea, but they seem a bit inconsistent: - The examples index is a mix of upper and lower case MPI function names - The MPI constant index has only 1 C++ constant listed - I see weird entries in the MPI constant index, such as: MPI_ERR_... (I'm not abbreviating -- there's actually an "MPI_ERR_..." entry) MPI_Delete_function MPI_Copy_function MPI_Aint ...and others - I'm not sure what the MPI C++ index is; the only item listed that does not have an equivalent in C is MPI::ERRORS_THROW_EXCEPTIONS - The MPI function index has weird entries, similar to the constant index, such as: MPI_ MPI_*_FREE MPI_{TYPE,COMM,WIN}_CREATE_KEYVAL MPI_Comm_delete_attr_function ...and others - The MPI function index also has a mix of upper and lower case MPI function names On Apr 8, 2008, at 11:03 AM, Rolf Rabenseifner wrote: > Please have a look at the last pages of > http://www.hlrs.de/mpi/mpi21/doc/mpi-report.pdf > > At the end, all Index data is now separated into 4 Indexes. > - The entries in the C++ index should be corrected that > they go directly into the const index. > - The Callback index is not complete. > > 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.mpi-forum.org/mailman/listinfo.cgi/mpi-21 -- Jeff Squyres Cisco Systems

1 0

Re: [Mpi-21] Rest of MPI-2.1 External interfaces into other chapters.
by unknown＠example.com 08 Apr '08

08 Apr '08

Rolf: Re: > Have already implemented the merge? No. > Decoding a Datatype is already moved to Datatypes. Yes. > Naming Objects, I would move it after 5.7 Caching. Works for me. > And the rest, I expect you have done a nice merge. Not yet. Too busy with the SC deadline, the EuroPVM/MPI deadline and an internal proposal deadline. Frankly, I don't expect to get back to this until next week. > As you know, I would like to get the write-token this evening. > Please svn commit you current status this evening and send > me an email with the files for wich I get the right to write > from you. You've got the token as far as I am concerned. > Any comments on the new Indexes? They look nice. Bronis > > Best regards > Rolf > > > On Thu, 3 Apr 2008 15:19:55 -0400 > George Bosilca <bosilca_at_[hidden]> 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. > > > > 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

Rest of MPI-2.1 External interfaces into other chapters.
by unknown＠example.com 08 Apr '08

08 Apr '08

Bronis, George, Dick (and Rich), Have already implemented the merge? Decoding a Datatype is already moved to Datatypes. Naming Objects, I would move it after 5.7 Caching. And the rest, I expect you have done a nice merge. As you know, I would like to get the write-token this evening. Please svn commit you current status this evening and send me an email with the files for wich I get the right to write from you. Any comments on the new Indexes? Best regards Rolf On Thu, 3 Apr 2008 15:19:55 -0400 George Bosilca <bosilca_at_[hidden]> 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. 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

pt2pt chapter - split into 2 chapters?
by unknown＠example.com 08 Apr '08

08 Apr '08

>>> please do not forget to svn commit your current chapter pt2pt.tex and credits.tex source this evening and give me back the write-token. <<< Rich, I'm not sure wether you are doing this already: Chapter 3 to 14 have each 38 pages in average, but Chapter 3 has 100 pages. The last 50 pages are 3.12-3.14, the derived datatypes together with pack and unpack. These 50 pages are independent from normal pt2pt communication, because needed also in all other communication. I would recommend to spilt it into 2 chapters. (It was already proposed from someone else.) If nobody is against, and you have not done already, I would do it tomorrow together with the corrections based on the last reviews. Please do not forget to svn commit and to send me an email, giving me back the allowance to write (write-token). (If you have done nothing, then I need only the email.) ASAP I'll transfer the token back to you. Have you already looked at the new Indexes? My next mail looks at Chapter 11. 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] Newest updates
by unknown＠example.com 08 Apr '08

08 Apr '08

Please have a look at the last pages of http://www.hlrs.de/mpi/mpi21/doc/mpi-report.pdf At the end, all Index data is now separated into 4 Indexes. - The entries in the C++ index should be corrected that they go directly into the const index. - The Callback index is not complete. 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