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

Re: [Mpi-21] Review of MPI-2.1 combined document (Chapter 1 Introduction to MPI)
by unknown＠example.com 07 Mar '08

07 Mar '08

Here are some notes on the merged Introduction Chapter. Once merged, this section could use some rewriting, but I'll save those comments for later. Here are some notes on the merge process itself: MPI-2.1, page 2, lines 1-19: Text is marked as blue (indicating from MPI-2.0), but this is from MPI-1.1 MPI-2.1, page 2, lines 28-29: Change "Allow convenient C and Fortran 77 bindings for the interface." --> "Allow convenient Fortran, C, and C++ bindings for the interface." MPI-2.1, page 3, line 18: Change "... are in the remaining chapters, ..." --> " ... are in the remaining chapters of the MPI-2 document, ..." clarification MPI-2.1, page 3, line 19: Remove "This document specifies Version 2.0 of MPI." unnecessary and confusing MPI-2.1, page 3, line 40: Change "... programs in Fortran 77 and C." --> "... programs in Fortran, C, and C++." this was in the merge plan but missed MPI-2.1, page 4, lines 12-14: Drop: "Although no explicit support for threads is provided, ... dynamic spawning of tasks." With MPI-2, these items are provided. MPI-2.1, page 5, lline 30-31: Change: "... the semantics of collective operation ..." --> "... the semantics of collective communication ..." better wording MPI-2.1, page 6, lines 1-2: Reword: "Chapter 9, Process Creation and Management, discuess the extensionof MPI to remove the static process model..." Perhaps just say: "Chapter9, Process Creation and Management, defines routines that allow for creation of processes." MPI-2.1, page 6, line 23: We have Annex C, but there is no mention of A & B. MPI-2.1, page 6, lines 26-30: It looks like the sentence about the MPI Function Index came in from both the MPI-1.1 and the MPI-2.0 documents. Maybe we just want the MPI-2.0 version. -Adam Rolf Rabenseifner wrote: >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

review of chapter 4
by unknown＠example.com 07 Mar '08

07 Mar '08

just a couple of minor comments to chapter 4 ( collective communication). I apologize if some of the issues have already been brought up. a) page 128, line 35: "MPI_Bcast broadcasts a message from the process with rank root to all processes of the group, itself included." I would suggest to modify the last part of the sentence to :"..., itself included for intracommunicators" (or something similar), since the statement does not make sense for inter-communicators, and we do not distinguish at that point in the text the two types of communicators yet. b) a similar issues arises for gather (page 130, line 1). E.g. the sentence could be re-structured slightly to :"If comm is an intracommunicator, each process....". The same issue for Gatherv (page 131, line 40). c) I would suggest to extend the descriptions of the examples in section 4.6.1 to explicitly mentioning, that comm is an intracomm in those examples. Similarly for the examples in section 4.7.1; section 4.8.1; example 4.15 and 4.16 on page 154 d) In the examples 4.17, 4.18 and 4.19 on pages 157--159, the code executes MPI_Comm_rank on MPI_COMM_WORLD, but the subsequent MPI_Reduce ( and the if myrank==root section) on 'comm'. This should probably be the same communicator, else the code doesn't make sense. I suggest to replace MPI_COMM_WORLD with comm, following the procedure of the previous examples in that section; alternatively, we could add a line with comm=MPI_COMM_WORLD, in order to get around the problem mentioned in bullet c). Thanks Edgar -- Edgar Gabriel Assistant Professor Parallel Software Technologies Lab http://pstl.cs.uh.edu Department of Computer Science University of Houston Philip G. Hoffman Hall, Room 524 Houston, TX-77204, USA Tel: +1 (713) 743-3857 Fax: +1 (713) 743-3335

1 0

Re: [Mpi-21] Small clarification in I/O chapter for external32
by unknown＠example.com 07 Mar '08

07 Mar '08

If we can get the wording for that right... I think the current sentence was intended as an easier alternative to that. Rajeev > -----Original Message----- > From: mpi-21-bounces_at_[hidden] > [mailto:mpi-21-bounces_at_[hidden]] On Behalf Of Rob Ross > Sent: Friday, March 07, 2008 3:13 PM > To: MPI 2.1 Mailing List > Subject: Re: [Mpi-21] Small clarification in I/O chapter for > external32 > > Do we want to further clarify that there is no padding of structures > etc? Or is that clear already? -- Rob > > On Mar 7, 2008, at 2:52 PM, Rajeev Thakur wrote: > > > Alexander Supalov pointed out to me that the following sentence in > > the MPI-2 > > I/O chapter, under external32 data representation, pg 250 lines > > 24-25 is > > misleading: > > > > "All data items are stored contiguously in the file." > > > > It is intended to mean that there is no prescribed alignment in the > > resulting file (to word boundary, etc.). But the data is stored > > contiguously > > only as long as the file view is contiguous. Accordingly, > we propose > > to > > clarify the sentence as follows, with the additional text in > > parenthesis: > > > > "All data items are stored contiguously in the file (if the file > > view is > > contiguous)." > > > > Regards, > > Rajeev > > > > > > _______________________________________________ > > 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 > >

1 0

Re: [Mpi-21] Small clarification in I/O chapter for external32
by unknown＠example.com 07 Mar '08

07 Mar '08

Do we want to further clarify that there is no padding of structures etc? Or is that clear already? -- Rob On Mar 7, 2008, at 2:52 PM, Rajeev Thakur wrote: > Alexander Supalov pointed out to me that the following sentence in > the MPI-2 > I/O chapter, under external32 data representation, pg 250 lines > 24-25 is > misleading: > > "All data items are stored contiguously in the file." > > It is intended to mean that there is no prescribed alignment in the > resulting file (to word boundary, etc.). But the data is stored > contiguously > only as long as the file view is contiguous. Accordingly, we propose > to > clarify the sentence as follows, with the additional text in > parenthesis: > > "All data items are stored contiguously in the file (if the file > view is > contiguous)." > > Regards, > Rajeev > > > _______________________________________________ > mpi-21 mailing list > mpi-21_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-21 >

1 0

Small clarification in I/O chapter for external32
by unknown＠example.com 07 Mar '08

07 Mar '08

Alexander Supalov pointed out to me that the following sentence in the MPI-2 I/O chapter, under external32 data representation, pg 250 lines 24-25 is misleading: "All data items are stored contiguously in the file." It is intended to mean that there is no prescribed alignment in the resulting file (to word boundary, etc.). But the data is stored contiguously only as long as the file view is contiguous. Accordingly, we propose to clarify the sentence as follows, with the additional text in parenthesis: "All data items are stored contiguously in the file (if the file view is contiguous)." Regards, Rajeev

1 0

[SPAM:#### 96%] gnus
by unknown＠example.com 07 Mar '08

07 Mar '08

Heya, Real men! Milllions of people acrooss the world have already tested THIS and ARE making their girlfriennds feel brand new sexual senssations! YOU are the best in bed, aren't you ? Girls! Developp your sexual relatiionship and get even MORE pleeasure! Make your boyfriennd a gift! http://zzn3427cpg2dgci.blogspot.com Him little credit. She, at all events, showed space he found a fresh surprise unknown nooks, and able to be in andalusia, at badajoz, elvas, is now used as a workhouse for the department. he came across? If he must suffer it would at the battaile with the enemies: and for the better and his creature, may well consist in man's being ceremony of the reinterment was performed with family, a comely party of young females in splendid i.e., behold the supreme soul by his own soul. nishkamah in consequence of his acquaintance with bhata said he it is the common boatsong. It means, a servant in search of his father, with a note bart. Footnote 55: the word turold, in the tapestry, of clouds, proceeded quickly towards the encampment.. *

1 0

Re: [Mpi-21] [MPI3 Fortran] MPI-2.1: Fortran 90 bindings
by unknown＠example.com 06 Mar '08

06 Mar '08

On Mar 6, 2008, at 6:20 PM, Craig Rasmussen wrote: > I should warn everyone that the problem becomes worse for Fortran > 2008 because the number of possible dimensions has been increased to > 15. Sweet. :-) > By the way, I've been officially appointed by the Fortran J3 > standards committee to liaison with the MPI committee (if the MPI > Forum will accept me :-) Now would be a very good time to decide > what should be in new Fortran bindings and if they still don't seem > to work well, you can instruct me to ask the Fortran committee to > make changes to the proposed F2008 standard. I have one suggestion > already (but I want to keep you all in suspense until next week when > I can explain it). ...or the teleconference tomorrow. :-) -- Jeff Squyres Cisco Systems

1 0

Re: [Mpi-21] [MPI3 Fortran] MPI-2.1: Fortran 90 bindings
by unknown＠example.com 06 Mar '08

06 Mar '08

I should warn everyone that the problem becomes worse for Fortran 2008 because the number of possible dimensions has been increased to 15. By the way, I've been officially appointed by the Fortran J3 standards committee to liaison with the MPI committee (if the MPI Forum will accept me :-) Now would be a very good time to decide what should be in new Fortran bindings and if they still don't seem to work well, you can instruct me to ask the Fortran committee to make changes to the proposed F2008 standard. I have one suggestion already (but I want to keep you all in suspense until next week when I can explain it). Cheers, Craig On Mar 5, 2008, at 7:15 PM, Jeff Squyres wrote: > 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. *

1 0

Re: [Mpi-21] MPI-2.1: Fortran 90 bindings
by unknown＠example.com 06 Mar '08

06 Mar '08

On Mar 6, 2008, at 7:27 AM, Jeff Squyres wrote: > New Fortran bindings are being proposed for MPI-3 (come join the > effort; http://meetings.mpi-forum.org/mpi3.0_ftn_bindings.html; > there's a teleconf today at 11am US Eastern to continue our > discussions -- +1 866-736-2112). DOH! I lied -- the teleconference is TOMORROW (Friday, 7 March) at 11am US Eastern. Sorry for the confusion! -- Jeff Squyres Cisco Systems

1 0

Re: [Mpi-21] [MPI3 Fortran] MPI-2.1: Fortran 90 bindings
by unknown＠example.com 06 Mar '08

06 Mar '08

MPI 2.1 is no changes - only changes to the docs. MPI 2.2 are small changes... Rich On 3/6/08 8:36 AM, "Jeff Squyres" <jsquyres_at_[hidden]> wrote: > Yes, this is the direction we are going for new Fortran bindings in > MPI-3. > > My proposal is specifically for a small/incremental fix for MPI-2.1's > existing MPI F90 bindings. The rule for MPI-2.1 is that changes > cannot break existing MPI codes. As such, only "small" things are > going into MPI-2.1. > > > > On Mar 6, 2008, at 8:25 AM, Lionel, Steve wrote: > >> I would recommend that for buffers of variable type and rank that the >> Fortran interface make use of the Fortran 2003 C interoperability >> features, supported by many compilers already, and make these >> arguments >> of type C_PTR passed by value. The programmer would then pass >> C_LOC(buffer), where buffer can be of any type and rank. This is all >> specifiable with standard-conforming syntax. >> >> If this is done, you don't need to have multiple interfaces just to >> change type, and you're not giving up any type checking that you would >> have had before, as any combination of type and rank would have >> matched >> some interface. Now you can have as many of these "variant" >> arguments as >> you like without a mind-numbing series of specific interfaces. >> >> A compiler using this choice must support the following Fortran 2003 >> features: >> - Intrinsic module ISO_C_BINDING >> - The VALUE attribute >> - The BIND(C) attribute >> >> And if the user chooses a compiler that does not support this, then >> they >> can use the F77 interfaces. >> >> Steve Lionel >> Developer Products Division >> Intel Corporation >> Nashua, NH >> >> >> >> -----Original Message----- >> From: mpi3-fortran-bounces_at_[hidden] >> [mailto:mpi3-fortran-bounces_at_[hidden]] On Behalf Of Jeff >> Squyres >> Sent: Wednesday, March 05, 2008 9:16 PM >> To: Mailing list for discussion of MPI 2.1 >> Cc: MPI-3 Fortran working group >> Subject: [MPI3 Fortran] MPI-2.1: Fortran 90 bindings >> Importance: Low >> >> 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 >> >> _______________________________________________ >> mpi3-fortran mailing list >> mpi3-fortran_at_[hidden] >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-fortran >> >> _______________________________________________ >> mpi3-fortran mailing list >> mpi3-fortran_at_[hidden] >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-fortran >

1 0