- 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

Because that's how it's always been. We're not adding a restriction with the change, merely clarifying the existing restriction. -- 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 Graham Sent: 31 January 2008 15:51 To: Mailing list for discussion of MPI 2.1 Subject: Re: [mpi-21] Ballot 4 - MPI_THREAD_FUNNELED - was Re: Attending, topics, etc 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]] <mailto:mpi-21-bounces_at_[hidden]%5d> > 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 --------------------------------------------------------------------- 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. *

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

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 *

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

That's fine for me. On Thu, 31 Jan 2008 10:27:59 -0500 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 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

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 *

1 0

Re: [mpi-21] Ballot 4 proposal: INOUT arguments
by unknown＠example.com 31 Jan '08

31 Jan '08

Jeff, to your statement: >If we also want to specify the behavior of the object, then a) that's >a huge change (and not one that I'm convinced we need), and b) we need >to add a second IN/OUT/INOUT to every language-neutral binding >representing what happens to the object. Adding it to only a few of >the bindings doesn't seem consistent to me. The trick is, that we have this problem only with the handle/object arguments. In most cases we have - IN/IN which is abbreviated with IN, e.g., MPI_Send(IN comm), or - OUT/OUT which is abbreviated with OUT, e.g., in MPI_Isend(OUT rq), or - INOUT/INOUT which is abbreviated with INOUT, e.g. in MPI_Type_commit(INOUT datatype) The change, I'm proposing is based on your wish to see the IN for the handles that are kept constant. Changing no words would continue to show the INOUT for the objects itself (that's the way MPI-2 was written). I would not say, that it is a huge change to add the handle IN information to all the interfaces. It is not huge, although there are more routines affected (also many MPI_FILE routines) as you have mentioned in your first mails. Okay? Best regards Rolf On Thu, 31 Jan 2008 09:56:48 -0500 Jeff Squyres <jsquyres_at_[hidden]> wrote: >On Jan 31, 2008, at 8:46 AM, Rolf Rabenseifner wrote: > >>> 1. Why do we need to indicate the INOUT status of the back-end MPI >>> object in the language neutral bindings? All the bindings -- >>> regardless of language -- only deal with the MPI handles, not the >>> back- >>> end MPI objects. >>> >>> 2. Adding qualifiers on what is supposed to happen to the back-end >>> MPI >>> object would seem to require additional semantics on the back-end MPI >>> object. Should we really be specifying what the implementation must/ >>> must not do with the back-end MPI object? Who benefits from that? >> >> After all the MPI_BOTTOM discussion and not knowing what future >> languages will bring, I didn't want to remove existing information >> from the standard. An opaque object in MPI consists always >> of two things: the handle and the object itself. >> >> The language independent interface should reflect this. >> >> I thought that especially for the const discussion it would be good >> to see the IN for the handle. > >I agree. > >> For future HPCS languages, it may be >> also necessary see the INOUT for the object itself. > >I guess my point is that the language bindings don't specify anything >about the object itself anywhere else. > >If we also want to specify the behavior of the object, then a) that's >a huge change (and not one that I'm convinced we need), and b) we need >to add a second IN/OUT/INOUT to every language-neutral binding >representing what happens to the object. Adding it to only a few of >the bindings doesn't seem consistent to me. > >-- >Jeff Squyres >Cisco Systems > >_______________________________________________ >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 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 *

1 0

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

31 Jan '08

Rolf: Re: > Sorry, that was my fault. > Here again the full proposal including your sentence > (and nothing else changed): Still fine with me although there is aminor grammar issue that needs to be fixed. The "which" should be "that" - the correct difference between the two is to use "that" for "required" clauses (i.e., clauses withouth which the sentence no longer makes sense, essentially) and "which" preceded by a comma for others (typically apository clauses). See below. Bronis > ___________________________________ > > 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 Change the above to: Each MPI function that 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. > > 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. > ___________________________________ > > Best regards > Rolf > > On Thu, 31 Jan 2008 13:43:04 -0000 > "Cownie, James H" <james.h.cownie_at_[hidden]> wrote: > >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. > > > > 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 - MPI_File_get_info
by unknown＠example.com 31 Jan '08

31 Jan '08

Rolf: Re: > This is a proposal for MPI 2.1, Ballot 4. Minor wording tweak suggested below. > 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_get_info > in http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi-errata/index.… > with mail discussion not yet existing > ___________________________________ > > Proposal: > MPI-2.0 Sect. 9.2.8, File Info, page 219, lines 11-13 read: > > MPI_FILE_GET_INFO returns a new info object containing the hints > of the file associated with fh. The current setting of all hints > actually used by the system related to this open file is returned > in info_used. > The user is responsible for freeing info_used via MPI_INFO_FREE. > > but should read (" or an abort(errorcode)" removed): > > MPI_FILE_GET_INFO returns a new info object containing the hints > of the file associated with fh. The current setting of all hints > actually used by the system related to this open file is returned > in info_used. > If there does not exist such a hint, MPI_INFO_NULL is returned. Change above to: MPI_INFO_NULL is returned if no such hint exists. Bronis > The user is responsible for freeing info_used via MPI_INFO_FREE > if info_used is not MPI_INFO_NULL. > ___________________________________ > Rationale for this clarification: > This text was missing. It was not clear, whether a MPI_Info handle > would be returned that would return nkeys=0 from MPI_INFO_GET_NKEYS. > From user's point of view, this behavior might have been expected > without this clarification. > ___________________________________ > > As far as I understand, ROMIO is using for all filesystems some default > hints and therefore "no-hints" is never returned. > MPI_File_set_view and MPI_File_set_info are only modifying values > but do not remove keys. > Therefore, the info handle cannot become empty. > > Best regards > Rolf > > > Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner_at_[hidden] > High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530 > University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832 > Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner > Nobelstr. 19, D-70550 Stuttgart, Germany . (Office: Allmandring 30) > _______________________________________________ > mpi-21 mailing list > mpi-21_at_[hidden] > http://lists.cs.uiuc.edu/mailman/listinfo/mpi-21 >

1 0

Re: [mpi-21] Ballot 4 proposal: INOUT arguments
by unknown＠example.com 31 Jan '08

31 Jan '08

On Jan 31, 2008, at 8:46 AM, Rolf Rabenseifner wrote: >> 1. Why do we need to indicate the INOUT status of the back-end MPI >> object in the language neutral bindings? All the bindings -- >> regardless of language -- only deal with the MPI handles, not the >> back- >> end MPI objects. >> >> 2. Adding qualifiers on what is supposed to happen to the back-end >> MPI >> object would seem to require additional semantics on the back-end MPI >> object. Should we really be specifying what the implementation must/ >> must not do with the back-end MPI object? Who benefits from that? > > After all the MPI_BOTTOM discussion and not knowing what future > languages will bring, I didn't want to remove existing information > from the standard. An opaque object in MPI consists always > of two things: the handle and the object itself. > > The language independent interface should reflect this. > > I thought that especially for the const discussion it would be good > to see the IN for the handle. I agree. > For future HPCS languages, it may be > also necessary see the INOUT for the object itself. I guess my point is that the language bindings don't specify anything about the object itself anywhere else. If we also want to specify the behavior of the object, then a) that's a huge change (and not one that I'm convinced we need), and b) we need to add a second IN/OUT/INOUT to every language-neutral binding representing what happens to the object. Adding it to only a few of the bindings doesn't seem consistent to me. -- Jeff Squyres Cisco Systems

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

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.

1 0