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

Re: [mpi-21] Ballot 4 - MPI_THREAD_FUNNELED - was Re: Attending, topics, etc
by unknown＠example.com 31 Jan '08

31 Jan '08

On Thu, Jan 31, 2008 at 09:26:07PM +0100, Rolf Rabenseifner wrote: > Dick, I fully agree. I withdraw my proposals with OpenMP and come > back to your text, adding the forward reference to MPI_IS_THREAD_MAIN: > > >> >>> MPI_THREAD_FUNNELED The process may be multi-threaded, but the > >> >>> application > >> >>> must insure that only the main thread makes MPI calls > (for the definition of main thread, see MPI_IS_THREAD_MAIN). > > By the way, this clarification is independent of any > additional level of thread support taht may be specified in > further MPI versions. I also agree with this version of the clarification. BTW, it should be "ensure", not "insure". The current MPI 2.0 doc has "ensure" 28 times and "insure" 0 times. -- greg

1 0

Re: [mpi-21] Ballot 4 - Re: Request for interpretation
by unknown＠example.com 31 Jan '08

31 Jan '08

Not quite; For example the standard offers: { cb_buffer_size} (integer) {SAME}: This hint specifies the total buffer space that can be used for collective buffering on each target node, usually a multiple of cb_block_size. The standard says a program is "erroneous" if the value is not the same at all callers. That is not exactly the same as the standard defining behavior for MPI_FILE_OPEN with a valid key and garbage value but pretty close. If MPI 3 adds new defined keys for new specific functions it may or may not want to go into defining behavior for some kinds of bad input. 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 01/31/2008 03:55:15 PM: > Do we mean "implementation defined" instead of "undefined"? > > On Thu, 31 Jan 2008 14:16:20 -0500 > Richard Treumann <treumann_at_[hidden]> wrote: > >Jim > > > >The sense I get from the phrase "the behavior is undefined" is that > >defining the behavior is beyond the scope of the standard. > > > >The MPI standard does have some predefined keys and requires an > >implementation that supports any predefined key to support it as described > >by the standard. That can lead to one place in the standard saying "the > >behavior is undefined" and another saying "here is the definition of the > >behavior". > > > >Maybe I am reading more than others into the phrase "the behavior is > >undefined" but it does have this strong implication in my mind. > > > >How is this ? > > > >An implementation must support info objects as caches for arbitrary > >key, value) pairs, regardless of whether it recognizes the key. > >Each function that takes hints in the form of an MPI_Info must > >be prepared to ignore any key it does not recognize. This description > >of info objects does not attempt to define how a particular function > >should react if it recognizes a key but not the associated value. > > > >note: > >I also changed MPI function to simply function because with this free form > >approach to the info object, it seems to me a third party library that is > >intended to work as part of an MPI program may want to use MPI_Info objects > >too. If someone authors a parallel math library and wants the > >initialization routine to look like: > > init_pmath( MPI_Info info) > >why not? They should understand that init_pmath must ignore keys it does > >not recognize even if i is not an MPI_ routine. > > > > > > 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 01/31/2008 09:39:52 AM: > > > >> As you are saying, there are two different classes of errors here. > >> > >> 1) Keys which are not understood and need to be ignored by functions > >> which donât grok them (âJIMS_SECRET_TAGâ,â99â) > >> 2) Keys which are understood by a function, but with a value which > >> is not (âbuffer_sizeâ, âHelloâ) > >> > >> I think allowing the second type to have undefined behavior is the > >> right thing to do, since itâs the most general. > >> If your implementation wants to define the behavior of some out-of- > >> range values, thatâs fine and doesnât make you non-conforming, it > >> just means you defined the previously undefined behavior for some > >> set of values. > >> > >> Having that undefined-ness explicit here (in one central place) > >> seems to make sense (if only because it may be omitted in one of the > >> other places where it should appear). > >> > >> My addition does not alter the existing change which guarantees case > >> 1, itâs only concerned with case 2. > >> -- Jim > >> > >> James Cownie <james.h.cownie_at_[hidden]> > >> SSG/DPD/PAT > >> Tel: +44 117 9071438 > >> > >> From: mpi-21-bounces_at_[hidden] [mailto:mpi-21-bounces_at_[hidden]] > >> On Behalf Of Richard Treumann > >> Sent: 31 January 2008 14:20 > >> To: Mailing list for discussion of MPI 2.1 > >> Subject: Re: [mpi-21] Ballot 4 - Re: Request for interpretation > >> > >> Jim - > >> > >> I was taking the view that the description of what to do for a > >> recognized key but dubious value belongs to the function that > >> recognizes the specific key. For example if MPI_File_open accepts a > >> "buffer_size" hint with range "32K" to "16M" we may want to define > >> the behavior of hints that are out of range. > >> > >> Once we say an info can have arbitrary keys we need to state that > >> every info consumer must be prepared to ignore keys it does not > >> recognize because we have made unrecognizable keys legitimate. > >> > >> 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 01/31/2008 08:43:04 AM: > >> > >> > However, you have apparently lost the liberty to have undefined > >> > behavior which was there in the previous version. > >> > > >> > Maybe you should keep that, something like > >> > An implementation must support info objects as caches for arbitrary > >> > (key, value) pairs, regardless of whether it recognizes the keys. > >> > Each MPI function which takes hints in the form of an MPI_Info must > >> > be prepared to ignore any key it does not recognize. However if a > >> > function recognizes a key but not the associated value, then the > >> > behavior is undefined. > >> > (Modifications in italics) > >> > -- Jim > >> > > >> > James Cownie <james.h.cownie_at_[hidden]> > >> > SSG/DPD/PAT > >> > Tel: +44 117 9071438 > >> > > >> > From: mpi-21-bounces_at_[hidden] [mailto:mpi-21-bounces_at_[hidden]] > >> > On Behalf Of Richard Treumann > >> > Sent: 31 January 2008 13:29 > >> > To: Mailing list for discussion of MPI 2.1 > >> > Subject: Re: [mpi-21] Ballot 4 - Re: Request for interpretation > >> > > >> > Your wording works for me Rolf. -- Thanks > >> > > >> > > >> > 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/31/2008 05:25:46 AM: > >> > > >> > > I try to summarize all 3 replies in one proposal: > >> > > > >> > > ___________________________________ > >> > > > >> > > Proposal: > >> > > MPI 2.0, Sect. 4.10 Info Objects, page 43, line 38-40 read: > >> > > If a function does not recognize a key, > >> > > it will ignore it, unless otherwise specified. > >> > > If an implementation recognizes a key but does not recognize > >> > > the format of the corresponding value, the result is undefined. > >> > > but should read: > >> > > An implementation must support info objects as caches for > >arbitrary > >> > > (key, value) pairs, regardless of whether it recognizes the pairs. > >> > > Each MPI function which takes hints in the form of an MPI_Info > >must > >> > > be prepared to ignore any key it does not recognize. > >> > > > >> > > Add after MPI 2.0, Sect. 4.10 Info Objects, page 44, line 22 a new > >> > > paragraph: > >> > > Advice to implementors. > >> > > Although in MPI functions that take hints in form of an MPI_Info > >> > > (e.g., in process creation and management, one-sided > >communication, > >> > > or parallel file I/O), an implementation must be prepared to > >ignore > >> > > keys that it does not recognize, for the purpose of > >> MPI_INFO_GET_NKEYS, > >> > > MPI_INFO_GET_NTHKEY, MPI_INFO_GET_VALUELEN, and MPI_INFO_GET, the > >> > > implementation must retain all (key,value) pairs so that layered > >> > > functionality can also use the Info object. > >> > > (End of advice to implementors.) > >> > > _____________________________ > >> > > Rationale for this clarification: > >> > > > >> > > The MPI-2.0 text allowed that also MPI_INFO_DELETE, MPI_INFO_SET, > >> > > MPI_INFO_GET, and MPI_INFO_DUP could ignore (key,value) pairs > >> > > that are not recognized in routines in other chapters that > >> > > take hints with info arguments. > >> > > The proposed clarification is necessary when we assume, that > >> > > layered implementation of parts of the MPI-2 standard should > >> > > be possible and may use the MPI_Info objects for their needs. > >> > > This was a goal of the MPI-2 Forum and the MPI-2.0 specification. > >> > > ___________________________________ > >> > > > >> > > Bronis, for me, your wording "an MPI implementation may restrict" was > >> > > in conflict with the rest of the advice. I hope the formulation above > >> > > is also okay. It is based on the new wording from you and Dick in > >first > >> > > part of the proposal. > >> > > > >> > > 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 > >> > --------------------------------------------------------------------- > >> > Intel Corporation (UK) Limited > >> > Registered No. 1134945 (England) > >> > Registered Office: Pipers Way, Swindon SN3 1RJ > >> > VAT No: 860 2173 47 > >> > > >> > This e-mail and any attachments may contain confidential material for > >> > the sole use of the intended recipient(s). Any review or distribution > >> > by others is strictly prohibited. If you are not the intended > >> > recipient, please contact the sender and delete all copies. > >> > _______________________________________________ > >> > mpi-21 mailing list > >> > mpi-21_at_[hidden] > >> > http://lists.cs.uiuc.edu/mailman/listinfo/mpi-21 > >> --------------------------------------------------------------------- > >> Intel Corporation (UK) Limited > >> Registered No. 1134945 (England) > >> Registered Office: Pipers Way, Swindon SN3 1RJ > >> VAT No: 860 2173 47 > >> > >> This e-mail and any attachments may contain confidential material for > >> the sole use of the intended recipient(s). Any review or distribution > >> by others is strictly prohibited. If you are not the intended > >> recipient, please contact the sender and delete all copies. > >> _______________________________________________ > >> mpi-21 mailing list > >> mpi-21_at_[hidden] > >> http://lists.cs.uiuc.edu/mailman/listinfo/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.cs.uiuc.edu/mailman/listinfo/mpi-21 *

1 0

Re: [mpi-21] Ballot 4 - Re: MPI-2 thread safety and collectives
by unknown＠example.com 31 Jan '08

31 Jan '08

Rolf, Karl's original mail in this thread asked a simpler question, namely, what is considered as conflicting calls when using the same communicator. His scenario 1 is Thread 1: MPI_Allreduce(..., comm) Thread 2: MPI_File_open(..., comm, ...) His scenario 2 is Thread 1: MPI_Allreduce(..., MPI_SUM, comm) Thread 2: MPI_Allreduce(..., MPI_MAX, comm) I don't think there is any doubt about scenario 2 being conflicting. In my opinion, even scenario 1 is conflicting because they are 2 MPI collective calls explicitly on the same communicator (the file handle is not yet created). He is asking for some clarification on scenario 1. Your proposed advice to users is for collective calls on different objects (file handles, window objects) derived from the same communicator. (It is nonetheless useful to have it in addition.) Rajeev > -----Original Message----- > From: owner-mpi-21_at_[hidden] > [mailto:owner-mpi-21_at_[hidden]] On Behalf Of Rolf Rabenseifner > Sent: Monday, January 21, 2008 11:26 AM > To: mpi-21_at_[hidden] > Cc: mpi-21_at_[hidden] > Subject: [mpi-21] Ballot 4 - Re: MPI-2 thread safety and collectives > > This is a proposal for MPI 2.1, Ballot 4. > > This is a follow up to: > Thread safety and collective communication > 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/thread-safety/index.htm > > After checking the e-mails and looking at > - MPI-2 8.7.2 page 195 lines 6-9 > Collective calls Matching of collective calls on a communicator, > window, or file handle is done according to the order in > which the > calls are issued at each process. If concurrent threads > issue such > calls on the same communicator, window or file handle, it > is up to > the user to make sure the calls are correctly ordered, using > interthread synchronization. > - MPI-2 6.2.1 Window Creation, page 110, lines 10-12: > The call returns an opaque object that represents the group of > processes that own and access the set of windows, and the > attributes > of each window, as specified by the initialization call. > - MPI-2 9.2. Opening a File, page 211, line 46 - page 212, line 2: > Note that the communicator comm is unaffected by MPI FILE OPEN > and continues to be usable in all MPI routines (e.g., MPI SEND). > Furthermore, the use of comm will not interfere with I/O behavior. > it seems that the standard should be clarified. > > > Proposal for MPI 2.1, Ballot 4: > ------------------------------- > Add new paragraphs after MPI-2, 8.7.2 page 195 line 9 (the > end of the clarification on "Collective calls"): > > Advice to users. > With three concurrent threads in each MPI process of a > communicator comm, > it is allowed that thread A in each MPI process calls a collective > operation on comm, thread B calls a file operation on an existing > filehandle that was formerly opened on comm, and thread C > invokes one-sided > operations on an existing window handle that was also > formerly created > on comm. > (End of advice to users.) > > Rationale. > As already specified in MP_FILE_OPEN and MI_WIN_CREATE, a > file handle and > a window handle inherit only the group of processes of the > underlying > communicator, but not the communicator itself. Accesses to > communicators, > window handles and file handles cannot affect one another. > (End of rationale.) > > Advice to implementors. > If the implementation of file or window operations wants to > internally > use MPI communication then a duplicated communicator handle > may be cached > on the file or window handle. > (End of advice to implementors.) > ------------------------------- > > Reason: The emails have shown, that the current MPI-2 text can be > well misunderstood. > ------------------------------- > > 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) > >

1 0

Re: [mpi-21] Ballot 4 - Re: Request for interpretation
by unknown＠example.com 31 Jan '08

31 Jan '08

Do we mean "implementation defined" instead of "undefined"? On Thu, 31 Jan 2008 14:16:20 -0500 Richard Treumann <treumann_at_[hidden]> wrote: >Jim > >The sense I get from the phrase "the behavior is undefined" is that >defining the behavior is beyond the scope of the standard. > >The MPI standard does have some predefined keys and requires an >implementation that supports any predefined key to support it as described >by the standard. That can lead to one place in the standard saying "the >behavior is undefined" and another saying "here is the definition of the >behavior". > >Maybe I am reading more than others into the phrase "the behavior is >undefined" but it does have this strong implication in my mind. > >How is this ? > >An implementation must support info objects as caches for arbitrary >key, value) pairs, regardless of whether it recognizes the key. >Each function that takes hints in the form of an MPI_Info must >be prepared to ignore any key it does not recognize. This description >of info objects does not attempt to define how a particular function >should react if it recognizes a key but not the associated value. > >note: >I also changed MPI function to simply function because with this free form >approach to the info object, it seems to me a third party library that is >intended to work as part of an MPI program may want to use MPI_Info objects >too. If someone authors a parallel math library and wants the >initialization routine to look like: > init_pmath( MPI_Info info) >why not? They should understand that init_pmath must ignore keys it does >not recognize even if i is not an MPI_ routine. > > > 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 01/31/2008 09:39:52 AM: > >> As you are saying, there are two different classes of errors here. >> >> 1) Keys which are not understood and need to be ignored by functions >> which donât grok them (âJIMS_SECRET_TAGâ,â99â) >> 2) Keys which are understood by a function, but with a value which >> is not (âbuffer_sizeâ, âHelloâ) >> >> I think allowing the second type to have undefined behavior is the >> right thing to do, since itâs the most general. >> If your implementation wants to define the behavior of some out-of- >> range values, thatâs fine and doesnât make you non-conforming, it >> just means you defined the previously undefined behavior for some >> set of values. >> >> Having that undefined-ness explicit here (in one central place) >> seems to make sense (if only because it may be omitted in one of the >> other places where it should appear). >> >> My addition does not alter the existing change which guarantees case >> 1, itâs only concerned with case 2. >> -- Jim >> >> James Cownie <james.h.cownie_at_[hidden]> >> SSG/DPD/PAT >> Tel: +44 117 9071438 >> >> From: mpi-21-bounces_at_[hidden] [mailto:mpi-21-bounces_at_[hidden]] >> On Behalf Of Richard Treumann >> Sent: 31 January 2008 14:20 >> To: Mailing list for discussion of MPI 2.1 >> Subject: Re: [mpi-21] Ballot 4 - Re: Request for interpretation >> >> Jim - >> >> I was taking the view that the description of what to do for a >> recognized key but dubious value belongs to the function that >> recognizes the specific key. For example if MPI_File_open accepts a >> "buffer_size" hint with range "32K" to "16M" we may want to define >> the behavior of hints that are out of range. >> >> Once we say an info can have arbitrary keys we need to state that >> every info consumer must be prepared to ignore keys it does not >> recognize because we have made unrecognizable keys legitimate. >> >> 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 01/31/2008 08:43:04 AM: >> >> > However, you have apparently lost the liberty to have undefined >> > behavior which was there in the previous version. >> > >> > Maybe you should keep that, something like >> > An implementation must support info objects as caches for arbitrary >> > (key, value) pairs, regardless of whether it recognizes the keys. >> > Each MPI function which takes hints in the form of an MPI_Info must >> > be prepared to ignore any key it does not recognize. However if a >> > function recognizes a key but not the associated value, then the >> > behavior is undefined. >> > (Modifications in italics) >> > -- Jim >> > >> > James Cownie <james.h.cownie_at_[hidden]> >> > SSG/DPD/PAT >> > Tel: +44 117 9071438 >> > >> > From: mpi-21-bounces_at_[hidden] [mailto:mpi-21-bounces_at_[hidden]] >> > On Behalf Of Richard Treumann >> > Sent: 31 January 2008 13:29 >> > To: Mailing list for discussion of MPI 2.1 >> > Subject: Re: [mpi-21] Ballot 4 - Re: Request for interpretation >> > >> > Your wording works for me Rolf. -- Thanks >> > >> > >> > 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/31/2008 05:25:46 AM: >> > >> > > I try to summarize all 3 replies in one proposal: >> > > >> > > ___________________________________ >> > > >> > > Proposal: >> > > MPI 2.0, Sect. 4.10 Info Objects, page 43, line 38-40 read: >> > > If a function does not recognize a key, >> > > it will ignore it, unless otherwise specified. >> > > If an implementation recognizes a key but does not recognize >> > > the format of the corresponding value, the result is undefined. >> > > but should read: >> > > An implementation must support info objects as caches for >arbitrary >> > > (key, value) pairs, regardless of whether it recognizes the pairs. >> > > Each MPI function which takes hints in the form of an MPI_Info >must >> > > be prepared to ignore any key it does not recognize. >> > > >> > > Add after MPI 2.0, Sect. 4.10 Info Objects, page 44, line 22 a new >> > > paragraph: >> > > Advice to implementors. >> > > Although in MPI functions that take hints in form of an MPI_Info >> > > (e.g., in process creation and management, one-sided >communication, >> > > or parallel file I/O), an implementation must be prepared to >ignore >> > > keys that it does not recognize, for the purpose of >> MPI_INFO_GET_NKEYS, >> > > MPI_INFO_GET_NTHKEY, MPI_INFO_GET_VALUELEN, and MPI_INFO_GET, the >> > > implementation must retain all (key,value) pairs so that layered >> > > functionality can also use the Info object. >> > > (End of advice to implementors.) >> > > _____________________________ >> > > Rationale for this clarification: >> > > >> > > The MPI-2.0 text allowed that also MPI_INFO_DELETE, MPI_INFO_SET, >> > > MPI_INFO_GET, and MPI_INFO_DUP could ignore (key,value) pairs >> > > that are not recognized in routines in other chapters that >> > > take hints with info arguments. >> > > The proposed clarification is necessary when we assume, that >> > > layered implementation of parts of the MPI-2 standard should >> > > be possible and may use the MPI_Info objects for their needs. >> > > This was a goal of the MPI-2 Forum and the MPI-2.0 specification. >> > > ___________________________________ >> > > >> > > Bronis, for me, your wording "an MPI implementation may restrict" was >> > > in conflict with the rest of the advice. I hope the formulation above >> > > is also okay. It is based on the new wording from you and Dick in >first >> > > part of the proposal. >> > > >> > > 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 >> > --------------------------------------------------------------------- >> > Intel Corporation (UK) Limited >> > Registered No. 1134945 (England) >> > Registered Office: Pipers Way, Swindon SN3 1RJ >> > VAT No: 860 2173 47 >> > >> > This e-mail and any attachments may contain confidential material for >> > the sole use of the intended recipient(s). Any review or distribution >> > by others is strictly prohibited. If you are not the intended >> > recipient, please contact the sender and delete all copies. >> > _______________________________________________ >> > mpi-21 mailing list >> > mpi-21_at_[hidden] >> > http://lists.cs.uiuc.edu/mailman/listinfo/mpi-21 >> --------------------------------------------------------------------- >> Intel Corporation (UK) Limited >> Registered No. 1134945 (England) >> Registered Office: Pipers Way, Swindon SN3 1RJ >> VAT No: 860 2173 47 >> >> This e-mail and any attachments may contain confidential material for >> the sole use of the intended recipient(s). Any review or distribution >> by others is strictly prohibited. If you are not the intended >> recipient, please contact the sender and delete all copies. >> _______________________________________________ >> mpi-21 mailing list >> mpi-21_at_[hidden] >> http://lists.cs.uiuc.edu/mailman/listinfo/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] Ballot 4 - MPI_File_set_info update or replacement
by unknown＠example.com 31 Jan '08

31 Jan '08

I do like specifiy better - thx 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/31/2008 02:59:24 PM: > Looks ok. Maybe use "specify" instead of "mention". > > When an info object that specifies a subset of valid hints > is passed to MPI_FILE_SET_VIEW or MPI_FILE_SET_INFO, there > will be no effect on previously set or defaulted hints that > the info does not specify. > > Rajeev > > From: mpi-21-bounces_at_[hidden] [mailto:mpi-21-bounces_at_[hidden]] > On Behalf Of Richard Treumann > Sent: Thursday, January 31, 2008 1:04 PM > To: Mailing list for discussion of MPI 2.1 > Subject: Re: [mpi-21] Ballot 4 - MPI_File_set_info update or replacement > Rajeev > > I think you just agreed with the interpretation I advocated. Neither > the proposal or rationale made this at all clear to me. How about? > > Proposal: > Add in MPI-2.0 Sect. 9.2.8, File Info, page 218, after line 18 the > following sentences: > > When an info object that mentions a subset of valid hints > is passed to MPI_FILE_SET_VIEW or MPI_FILE_SET_INFO, there > will be no effect on previously set or defaulted hints that > the info does not mention. > > ___________________________________ > Rationale for this clarification: > This text was missing. It was not clear, whether an info object > in MPI_FILE_SET_VIEW and MPI_FILE_SET_INFO was intended to > replace only the mentioned hints or was intended to substitute > a complete new set of hints for the prior set. > ___________________________________ > > 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/31/2008 12:29:41 PM: > > > The intent is that if the user calls MPI_File_set_info (or > > MPI_File_set_view) twice, the 2nd call will only update (if > > possible) the key-vals passed in the 2nd call; others are > > unmodified. If the 2nd call passes MPI_INFO_NULL, nothing will > > change -- it won't nullify previously passed hints. > > > > Rajeev > > > > > > From: mpi-21-bounces_at_[hidden] [mailto:mpi-21-bounces_at_[hidden]] > > On Behalf Of Richard Treumann > > Sent: Thursday, January 31, 2008 9:23 AM > > To: Mailing list for discussion of MPI 2.1 > > Subject: Re: [mpi-21] Ballot 4 - MPI_File_set_info update or replacement > > > I think we have an overall ambiguity about what the "current set of > > hints" is. This ambiguity is evident in the question about what > > MPI_FILE_INFO_GET returns and in this discussion too. If an > > implementation supports 5 file hints then it must select a value for > > each of these hints an MPI_FILE_OPEN. If there is an MPI_Info that > > stipulates 2 of the hints then how many hints are in the "current > > set of hints"? 2 or 5? I would say there are 5 and I think it makes > > sense for MPI_FILE_GET_INFO to return all 5 (key,value) pairs. > > > > Two more specific points - > > > > 1) I would expect that if at MPI_FILE_OPEN the implementation is > > given non-default hints ("A","yes") and ("B","no") and then at > > MPI_FILE_INFO_SET is given ("B","yes") the net effect is that hint > > "A" remains as set and hint "B" is altered (if possible). If there > > is a hint "C" which has never been mentioned it will have received a > > default value at MPI_FILE_OPEN and the MPI_FILE_INFO_SET which does > > not mention "C" will leave that default unchanged. > > > > Is the "clarification" saying hint "A" must return to default when > > MPI_FILE_INFO_SET fails to mention it? If that is the intent then I > > need to be convinced. If we decide this is to be blessed then we > > probably need to say that any use of MPI_FILE_SET_INFO must first > > call MPI_FILE_GET_INFO, tweek the INFO it gets back from > > MPI_FILE_GET_INFO and pass that to MPI_FILE_SET_INFO to avoid > > unexpected changes to the set of hints that is "in effect". > > > > 2) Since a hint is a hint, not a command, it can be rejected. It is > > possible that some hint can be honored at MPI_FILE_OPEN but once it > > has been honored, cannot be altered at reasonable cost. > > > > For example, maybe somebody's MPI_FILE_OPEN could accept a hint > > ("buffer_size", "dynamic-64MB") meaning "start with a 64MB buffer > > but be prepared to accept changes to buffer size". If the user has > > set hint ("buffer_size", "64MB") at FILE_OPEN, the implelentation > > would omit whatever synchs are needed to preserve the ability to > > change on the fly. Passing ("buffer_size", "dynamic-16MB") to > > MPI_FILE_SET_INFO could be honored if the user had chosen "dynamic" > > at FILE_OPEN but would need to be ignored if he had not. > > > > For most implementations, a hint like "buffer_size" could not be > > honored at all after the first file read or write had been done. > > > > 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/31/2008 08:24:51 AM: > > > > > This is a proposal for MPI 2.1, Ballot 4. > > > > > > I'm asking especially the implementors to check, whether > > > this interpretation is implemented in their MPI implementations, > > > or does not contradict to the existing implementation. > > > > > > This is a follow up to: > > > MPI_File_set_info > > > in http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi- > > > errata/index.html > > > with mail discussion not yet existing > > > ___________________________________ > > > > > > Proposal: > > > Add in MPI-2.0 Sect. 9.2.8, File Info, page 218, after line 18 the > > > following sentences: > > > > > > With MPI_FILE_SET_VIEW and MPI_FILE_SET_INFO the current setting > > > of all hints used by the system to this open file is updated by > > > the (key,value) pairs in the info argument. > > > ___________________________________ > > > Rationale for this clarification: > > > This text was missing. It was not clear, whether a info handles > > > in MPI_FILE_SET_VIEW and MPI_FILE_SET_INFO are updating or replacing > > > the current set of used hints. > > > The developers from ROMIO decided to update the current set of > used hints. > > > Therefore, this behavior should be the expected behavior of a majority > > > of users. > > > ___________________________________ > > > > > > 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 > > _______________________________________________ > > mpi-21 mailing list > > mpi-21_at_[hidden] > > http://lists.cs.uiuc.edu/mailman/listinfo/mpi-21 > _______________________________________________ > mpi-21 mailing list > mpi-21_at_[hidden] > http://lists.cs.uiuc.edu/mailman/listinfo/mpi-21 *

1 0

Re: [mpi-21] Ballot 4 - RE: clarification text for MPI_Reduce_scatter
by unknown＠example.com 31 Jan '08

31 Jan '08

The only change needed here is that the following sentence on ln 19, pg 163, MPI 2.0 should be deleted: "Note that the area occupied by the input data may be either longer or shorter than the data filled by the output data." The sentence makes no sense because the input data can never be shorter than the output data. The output, determined by recvcounts[i], is a subset of the input. Rajeev > -----Original Message----- > From: Rolf Rabenseifner [mailto:rabenseifner_at_[hidden]] > Sent: Tuesday, January 29, 2008 4:44 AM > To: mpi-21_at_[hidden] > Cc: Rajeev Thakur > Subject: Ballot 4 - RE: clarification text for MPI_Reduce_scatter > > This is a follow-up for MPI 2.1, Ballot 4. > > I'm asking especially > Rajeev Thakur, > the participant of the email-discussion in 2002, to review > this proposal. > > I would finish the following track without any proposed > clarification, because the text is already clear when the MPI-1.1 > part of MPI_Reduce_scatter is put in front of the MPI-2.0 part, > i.e., in the upcoming combined document MPI-2.1. > > This is a follow up to: > MPI_IN_PLACE for MPI_Reduce_scatter > 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/redscat/ > ___________________________________ > > The currently text in > http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi- > errata/index.html > should not be accepted, because it is a significant modification of > the MPI-2.0 standard and would break user code: > > Proposed text to replace lines 16-20, pg 163 > The "in place" option for intracommunicators is specified by > passing MPI_IN_PLACE in the sendbuf argument. In this case, on > each process, the input data is taken from recvbuf. Process i gets > the ith segment of the result, and it is stored at the location > corresponding to segment i in recvbuf. > ___________________________________ > > 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] Ballot 4 - MPI_File_set_info update or replacement
by unknown＠example.com 31 Jan '08

31 Jan '08

Dick and Rajeev, that's fine. My word "updating" was not clear enough. But that is what I wanted to say. I'll put your text into the Ballot 4. On Thu, 31 Jan 2008 13:59:24 -0600 "Rajeev Thakur" <thakur_at_[hidden]> wrote: >Looks ok. Maybe use "specify" instead of "mention". > > When an info object that specifies a subset of valid hints > is passed to MPI_FILE_SET_VIEW or MPI_FILE_SET_INFO, there > will be no effect on previously set or defaulted hints that > the info does not specify. > >Rajeev > > > > _____ > >From: mpi-21-bounces_at_[hidden] [mailto:mpi-21-bounces_at_[hidden]] On >Behalf Of Richard Treumann >Sent: Thursday, January 31, 2008 1:04 PM >To: Mailing list for discussion of MPI 2.1 >Subject: Re: [mpi-21] Ballot 4 - MPI_File_set_info update or replacement > > > >Rajeev > >I think you just agreed with the interpretation I advocated. Neither the >proposal or rationale made this at all clear to me. How about? > >Proposal: >Add in MPI-2.0 Sect. 9.2.8, File Info, page 218, after line 18 the >following sentences: > > When an info object that mentions a subset of valid hints > is passed to MPI_FILE_SET_VIEW or MPI_FILE_SET_INFO, there > will be no effect on previously set or defaulted hints that > the info does not mention. > >___________________________________ >Rationale for this clarification: > This text was missing. It was not clear, whether an info object > in MPI_FILE_SET_VIEW and MPI_FILE_SET_INFO was intended to > replace only the mentioned hints or was intended to substitute > a complete new set of hints for the prior set. >___________________________________ > >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/31/2008 12:29:41 PM: > >> The intent is that if the user calls MPI_File_set_info (or >> MPI_File_set_view) twice, the 2nd call will only update (if >> possible) the key-vals passed in the 2nd call; others are >> unmodified. If the 2nd call passes MPI_INFO_NULL, nothing will >> change -- it won't nullify previously passed hints. >> >> Rajeev >> >> >> From: mpi-21-bounces_at_[hidden] [mailto:mpi-21-bounces_at_[hidden]] >> On Behalf Of Richard Treumann >> Sent: Thursday, January 31, 2008 9:23 AM >> To: Mailing list for discussion of MPI 2.1 >> Subject: Re: [mpi-21] Ballot 4 - MPI_File_set_info update or replacement > >> I think we have an overall ambiguity about what the "current set of >> hints" is. This ambiguity is evident in the question about what >> MPI_FILE_INFO_GET returns and in this discussion too. If an >> implementation supports 5 file hints then it must select a value for >> each of these hints an MPI_FILE_OPEN. If there is an MPI_Info that >> stipulates 2 of the hints then how many hints are in the "current >> set of hints"? 2 or 5? I would say there are 5 and I think it makes >> sense for MPI_FILE_GET_INFO to return all 5 (key,value) pairs. >> >> Two more specific points - >> >> 1) I would expect that if at MPI_FILE_OPEN the implementation is >> given non-default hints ("A","yes") and ("B","no") and then at >> MPI_FILE_INFO_SET is given ("B","yes") the net effect is that hint >> "A" remains as set and hint "B" is altered (if possible). If there >> is a hint "C" which has never been mentioned it will have received a >> default value at MPI_FILE_OPEN and the MPI_FILE_INFO_SET which does >> not mention "C" will leave that default unchanged. >> >> Is the "clarification" saying hint "A" must return to default when >> MPI_FILE_INFO_SET fails to mention it? If that is the intent then I >> need to be convinced. If we decide this is to be blessed then we >> probably need to say that any use of MPI_FILE_SET_INFO must first >> call MPI_FILE_GET_INFO, tweek the INFO it gets back from >> MPI_FILE_GET_INFO and pass that to MPI_FILE_SET_INFO to avoid >> unexpected changes to the set of hints that is "in effect". >> >> 2) Since a hint is a hint, not a command, it can be rejected. It is >> possible that some hint can be honored at MPI_FILE_OPEN but once it >> has been honored, cannot be altered at reasonable cost. >> >> For example, maybe somebody's MPI_FILE_OPEN could accept a hint >> ("buffer_size", "dynamic-64MB") meaning "start with a 64MB buffer >> but be prepared to accept changes to buffer size". If the user has >> set hint ("buffer_size", "64MB") at FILE_OPEN, the implelentation >> would omit whatever synchs are needed to preserve the ability to >> change on the fly. Passing ("buffer_size", "dynamic-16MB") to >> MPI_FILE_SET_INFO could be honored if the user had chosen "dynamic" >> at FILE_OPEN but would need to be ignored if he had not. >> >> For most implementations, a hint like "buffer_size" could not be >> honored at all after the first file read or write had been done. >> >> 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/31/2008 08:24:51 AM: >> >> > This is a proposal for MPI 2.1, Ballot 4. >> > >> > I'm asking especially the implementors to check, whether >> > this interpretation is implemented in their MPI implementations, >> > or does not contradict to the existing implementation. >> > >> > This is a follow up to: >> > MPI_File_set_info >> > in http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi- >> > errata/index.html >> > with mail discussion not yet existing >> > ___________________________________ >> > >> > Proposal: >> > Add in MPI-2.0 Sect. 9.2.8, File Info, page 218, after line 18 the >> > following sentences: >> > >> > With MPI_FILE_SET_VIEW and MPI_FILE_SET_INFO the current setting >> > of all hints used by the system to this open file is updated by >> > the (key,value) pairs in the info argument. >> > ___________________________________ >> > Rationale for this clarification: >> > This text was missing. It was not clear, whether a info handles >> > in MPI_FILE_SET_VIEW and MPI_FILE_SET_INFO are updating or replacing >> > the current set of used hints. >> > The developers from ROMIO decided to update the current set of used >hints. >> > Therefore, this behavior should be the expected behavior of a majority >> > of users. >> > ___________________________________ >> > >> > 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 >> _______________________________________________ >> mpi-21 mailing list >> mpi-21_at_[hidden] >> http://lists.cs.uiuc.edu/mailman/listinfo/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] Ballot 4 - MPI_THREAD_FUNNELED - was Re: Attending, topics, etc
by unknown＠example.com 31 Jan '08

31 Jan '08

Dick, I fully agree. I withdraw my proposals with OpenMP and come back to your text, adding the forward reference to MPI_IS_THREAD_MAIN: >> >>> MPI_THREAD_FUNNELED The process may be multi-threaded, but the >> >>> application >> >>> must insure that only the main thread makes MPI calls (for the definition of main thread, see MPI_IS_THREAD_MAIN). By the way, this clarification is independent of any additional level of thread support taht may be specified in further MPI versions. Best regards Rolf On Thu, 31 Jan 2008 14:13:17 -0500 Richard Treumann <treumann_at_[hidden]> wrote: >See MPI_IS_THREAD_MAIN on page 198. The definition of "main thread" is >there. Maybepage 198 is not the best place for a definition of a term that >is used on page 196 but the standard does provide one. > >I am reluctant to mention OpenMP in the context of defining >MPI_THREAD_FUNNELED because then we would need to discuss other ways an >application could become multi threaded too. > >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/31/2008 12:58:59 PM: > >> What is the definition of a "main thread" ? The OpenMP example is >> still vague. >> >> I think we should clarify what we expect the "main thread" to be. From >> my perspective, this "main thread" is the one that called the >> MPI_Init_thread function, as the MPI library is then allowed to attach >> some kind of private key(s) to it (pthread_key_create). >> >> Thanks, >> george. >> >> On Jan 31, 2008, at 11:09 AM, Rolf Rabenseifner wrote: >> >> > Sorry Rich, >> > >> > but MPI 2.0 has defined "main thread", and not less! >> > >> > The open question was only, who is responsible for guaranteing this. >> > >> > Dicks text is fine: >> >>> MPI_THREAD_FUNNELED The process may be multi-threaded, but the >> >>> application >> >>> must insure that only the main thread makes MPI calls. >> > >> > My first proposal >> >>>>>>> MPI_THREAD_FUNNELED The process may be multi-threaded, but only >> >>>>>>> the main thread will make MPI calls (all MPI calls are >> >>>>>>> "funneled" >> >>>>>>> to the main thread, e.g., by using the OpenMP directive >> >>>>>>> "master" >> >>>>>>> in the application program). >> > has the advantage, that "main thread" is defined by refering to >> > the OpenMP-Standard where "OpenMP master thread" is defined (and not >> > "main"). >> > >> > We can combine this to: >> > MPI_THREAD_FUNNELED The process may be multi-threaded, but the >> > application >> > must insure that only the main thread makes MPI calls, e.g., by >> > using the >> > OpenMP directive "master". >> > >> > (This clearly tells that OpenMP single directive is not enough.) >> > >> > Best regards >> > Rolf >> > >> > >> > On Thu, 31 Jan 2008 10:50:35 -0500 >> > Richard Graham <rlgraham_at_[hidden]> wrote: >> >> Why restrict this to a standard specified thread (main thread), why >> >> not word >> >> it >> >> as a singe thread, and let the app decide what thread this is, >> >> based on >> >> what >> >> ever criteria it wants to use to select this thread ? >> >> >> >> Rich >> >> >> >> >> >> On 1/31/08 10:27 AM, "Richard Treumann" <treumann_at_[hidden]> wrote: >> >> >> >>> How about:: >> >>> MPI_THREAD_FUNNELED The process may be multi-threaded, but the >> >>> application >> >>> must insure that only the main thread makes MPI calls. >> >>> >> >>> >> >>> 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/31/2008 09:44:08 AM: >> >>> >> >>>>> A simpler change which would seem to achieve the desired >> >>>>> clarification >> >>>>> would be :- >> >>>>> >> >>>>> MPI_THREAD_FUNNELED The process may be multi-threaded, but >> >>>>> only the >> >>>>> main >> >>>>> thread is allowed to make MPI calls. >> >>>>> >> >>>>> (and you could add >> >>>>> If other threads make MPI calls the behavior is undefined. >> >>>>> if you want to be verbose about it). >> >>>>> >> >>>>> -- Jim >> >>>>> >> >>>>> James Cownie <james.h.cownie_at_[hidden]> >> >>>>> SSG/DPD/PAT >> >>>>> Tel: +44 117 9071438 >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>>>> -----Original Message----- >> >>>>>>> From: mpi-21-bounces_at_[hidden] >[mailto:mpi-21-bounces_at_[hidden] >> >>>>>>> ] >> >>>>> On >> >>>>>>> Behalf Of Rolf Rabenseifner >> >>>>>>> Sent: 31 January 2008 14:31 >> >>>>>>> To: mpi-21_at_[hidden] >> >>>>>>> Subject: [mpi-21] Ballot 4 - MPI_THREAD_FUNNELED - was Re: >> >>>>>>> Attending, >> >>>>>>> topics, etc >> >>>>>>> >> >>>>>>> This is a proposal for MPI 2.1, Ballot 4. >> >>>>>>> >> >>>>>>> I'm asking especially >> >>>>>>> Greg Lindahl, >> >>>>>>> the participants of the email-discussion in 2007, to review this >> >>>>> proposal. >> >>>>>>> >> >>>>>>> This is a follow up to: >> >>>>>>> Which thread is the funneled thread? >> >>>>>>> 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/funneled/ >> >>>>>>> ___________________________________ >> >>>>>>> >> >>>>>>> Proposal: >> >>>>>>> MPI-2.0 Sect. 8.7.3, MPI_Init_thread, page 196, lines 25-26 >> >>>>>>> read: >> >>>>>>> >> >>>>>>> MPI_THREAD_FUNNELED The process may be multi-threaded, but only >> >>>>>>> the main thread will make MPI calls (all MPI calls are >> >>>>>>> "funneled" >> >>>>>>> to the main thread). >> >>>>>>> >> >>>>>>> but should read: >> >>>>>>> >> >>>>>>> MPI_THREAD_FUNNELED The process may be multi-threaded, but only >> >>>>>>> the main thread will make MPI calls (all MPI calls are >> >>>>>>> "funneled" >> >>>>>>> to the main thread, e.g., by using the OpenMP directive >> >>>>>>> "master" >> >>>>>>> in the application program). >> >>>>>>> ___________________________________ >> >>>>>>> Rationale for this clarification from the email from Greg >> >>>>>>> Lindahl: >> >>>>>>> The existing document doesn't make it clear that >> >>>>>>> the MPI user has to funnel the calls to the main thread; >> >>>>>>> it's not the job of the MPI library. I have seen multiple >> >>>>>>> MPI users confused by this issue, and when I first read >> >>>>>>> this section, I was confused by it, too. >> >>>>>>> ___________________________________ >> >>>>>>> >> >>>>>>> >> >>>>>>> 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 >> >>>>> >--------------------------------------------------------------------- >> >>>>> Intel Corporation (UK) Limited >> >>>>> Registered No. 1134945 (England) >> >>>>> Registered Office: Pipers Way, Swindon SN3 1RJ >> >>>>> VAT No: 860 2173 47 >> >>>>> >> >>>>> This e-mail and any attachments may contain confidential >> >>>>> material for >> >>>>> the sole use of the intended recipient(s). Any review or >> >>>>> distribution >> >>>>> by others is strictly prohibited. If you are not the intended >> >>>>> recipient, please contact the sender and delete all copies. >> >>>>> >> >>>>> >> >>>>> _______________________________________________ >> >>>>> mpi-21 mailing list >> >>>>> mpi-21_at_[hidden] >> >>>>> http://lists.cs.uiuc.edu/mailman/listinfo/mpi-21 >> >>> >> >>> >> >>> _______________________________________________ >> >>> mpi-21 mailing list >> >>> mpi-21_at_[hidden] >> >>> http://lists.cs.uiuc.edu/mailman/listinfo/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.cs.uiuc.edu/mailman/listinfo/mpi-21 >> >> [attachment "smime.p7s" deleted by Richard >> Treumann/Poughkeepsie/IBM] >_______________________________________________ >> mpi-21 mailing list >> mpi-21_at_[hidden] >> http://lists.cs.uiuc.edu/mailman/listinfo/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] Two MPI I/O questions
by unknown＠example.com 31 Jan '08

31 Jan '08

I don't think any clarification is needed for the second topic. Rajeev > -----Original Message----- > From: Rolf Rabenseifner [mailto:rabenseifner_at_[hidden]] > Sent: Tuesday, January 29, 2008 6:22 AM > To: mpi-21_at_[hidden] > Cc: Leonard F. Wisniewski; Rajeev Thakur > Subject: Re: Two MPI I/O questions > > Mainly to Leonard Wisniewski and Rajeev Thakur > who have contributed to this mail-discussion thread. > > This is a follow up to: > Shared File Pointers > 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/sharedfile/ > > and here only to the second topic in the mails. > (The first topic is handled in the thread > "MPI C++ Constants conflict with stdio") > > _________________________________________ > > When I understand correctly, then a clarification is not needed > in the MPI standard. > > If somebody wants a clarification to be included into the standard > and therefore in Ballot 4, please send me your wording > with the page and line references included. > > If all agree, that no clarification is needed, then I would finish > this discussion-thread. > > 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] Ballot 4 - MPI_File_set_info update or replacement
by unknown＠example.com 31 Jan '08

31 Jan '08

Looks ok. Maybe use "specify" instead of "mention". When an info object that specifies a subset of valid hints is passed to MPI_FILE_SET_VIEW or MPI_FILE_SET_INFO, there will be no effect on previously set or defaulted hints that the info does not specify. Rajeev _____ From: mpi-21-bounces_at_[hidden] [mailto:mpi-21-bounces_at_[hidden]] On Behalf Of Richard Treumann Sent: Thursday, January 31, 2008 1:04 PM To: Mailing list for discussion of MPI 2.1 Subject: Re: [mpi-21] Ballot 4 - MPI_File_set_info update or replacement Rajeev I think you just agreed with the interpretation I advocated. Neither the proposal or rationale made this at all clear to me. How about? Proposal: Add in MPI-2.0 Sect. 9.2.8, File Info, page 218, after line 18 the following sentences: When an info object that mentions a subset of valid hints is passed to MPI_FILE_SET_VIEW or MPI_FILE_SET_INFO, there will be no effect on previously set or defaulted hints that the info does not mention. ___________________________________ Rationale for this clarification: This text was missing. It was not clear, whether an info object in MPI_FILE_SET_VIEW and MPI_FILE_SET_INFO was intended to replace only the mentioned hints or was intended to substitute a complete new set of hints for the prior set. ___________________________________ 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/31/2008 12:29:41 PM: > The intent is that if the user calls MPI_File_set_info (or > MPI_File_set_view) twice, the 2nd call will only update (if > possible) the key-vals passed in the 2nd call; others are > unmodified. If the 2nd call passes MPI_INFO_NULL, nothing will > change -- it won't nullify previously passed hints. > > Rajeev > > > From: mpi-21-bounces_at_[hidden] [mailto:mpi-21-bounces_at_[hidden]] > On Behalf Of Richard Treumann > Sent: Thursday, January 31, 2008 9:23 AM > To: Mailing list for discussion of MPI 2.1 > Subject: Re: [mpi-21] Ballot 4 - MPI_File_set_info update or replacement > I think we have an overall ambiguity about what the "current set of > hints" is. This ambiguity is evident in the question about what > MPI_FILE_INFO_GET returns and in this discussion too. If an > implementation supports 5 file hints then it must select a value for > each of these hints an MPI_FILE_OPEN. If there is an MPI_Info that > stipulates 2 of the hints then how many hints are in the "current > set of hints"? 2 or 5? I would say there are 5 and I think it makes > sense for MPI_FILE_GET_INFO to return all 5 (key,value) pairs. > > Two more specific points - > > 1) I would expect that if at MPI_FILE_OPEN the implementation is > given non-default hints ("A","yes") and ("B","no") and then at > MPI_FILE_INFO_SET is given ("B","yes") the net effect is that hint > "A" remains as set and hint "B" is altered (if possible). If there > is a hint "C" which has never been mentioned it will have received a > default value at MPI_FILE_OPEN and the MPI_FILE_INFO_SET which does > not mention "C" will leave that default unchanged. > > Is the "clarification" saying hint "A" must return to default when > MPI_FILE_INFO_SET fails to mention it? If that is the intent then I > need to be convinced. If we decide this is to be blessed then we > probably need to say that any use of MPI_FILE_SET_INFO must first > call MPI_FILE_GET_INFO, tweek the INFO it gets back from > MPI_FILE_GET_INFO and pass that to MPI_FILE_SET_INFO to avoid > unexpected changes to the set of hints that is "in effect". > > 2) Since a hint is a hint, not a command, it can be rejected. It is > possible that some hint can be honored at MPI_FILE_OPEN but once it > has been honored, cannot be altered at reasonable cost. > > For example, maybe somebody's MPI_FILE_OPEN could accept a hint > ("buffer_size", "dynamic-64MB") meaning "start with a 64MB buffer > but be prepared to accept changes to buffer size". If the user has > set hint ("buffer_size", "64MB") at FILE_OPEN, the implelentation > would omit whatever synchs are needed to preserve the ability to > change on the fly. Passing ("buffer_size", "dynamic-16MB") to > MPI_FILE_SET_INFO could be honored if the user had chosen "dynamic" > at FILE_OPEN but would need to be ignored if he had not. > > For most implementations, a hint like "buffer_size" could not be > honored at all after the first file read or write had been done. > > 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/31/2008 08:24:51 AM: > > > This is a proposal for MPI 2.1, Ballot 4. > > > > I'm asking especially the implementors to check, whether > > this interpretation is implemented in their MPI implementations, > > or does not contradict to the existing implementation. > > > > This is a follow up to: > > MPI_File_set_info > > in http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi- > > errata/index.html > > with mail discussion not yet existing > > ___________________________________ > > > > Proposal: > > Add in MPI-2.0 Sect. 9.2.8, File Info, page 218, after line 18 the > > following sentences: > > > > With MPI_FILE_SET_VIEW and MPI_FILE_SET_INFO the current setting > > of all hints used by the system to this open file is updated by > > the (key,value) pairs in the info argument. > > ___________________________________ > > Rationale for this clarification: > > This text was missing. It was not clear, whether a info handles > > in MPI_FILE_SET_VIEW and MPI_FILE_SET_INFO are updating or replacing > > the current set of used hints. > > The developers from ROMIO decided to update the current set of used hints. > > Therefore, this behavior should be the expected behavior of a majority > > of users. > > ___________________________________ > > > > 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 > _______________________________________________ > mpi-21 mailing list > mpi-21_at_[hidden] > http://lists.cs.uiuc.edu/mailman/listinfo/mpi-21 *

1 0