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

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

31 Jan '08

This is excellent. -- Rob On Jan 31, 2008, at 4:25 AM, Rolf Rabenseifner wrote: > 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 >

1 0

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

31 Jan '08

Rolf: Your new wording works for me. Bronis On Thu, 31 Jan 2008, Rolf Rabenseifner wrote: > 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 >

1 0

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

31 Jan '08

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)

1 0

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

30 Jan '08

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? On Jan 29, 2008, at 12:07 PM, Rolf Rabenseifner wrote: > Proposal: > The current text in MPI 2.0 Sect. 2.3 Procedure Specification, > page 6 lines 30-34 read: > > There is one special case  if an argument is a handle to an > opaque object (these terms are defined in Section 2.5.1), and > the object is updated by the procedure call, then the argument > is marked OUT. It is marked this way even though the handle > itself is not modified  we use the OUT attribute to denote > that what the handle references is updated. Thus, in C++, > IN arguments are either references or pointers to const objects. > > but should read: > > There is one special case  if an argument is a handle to an > opaque object (these terms are defined in Section 2.5.1), and > the object is updated by the procedure call > but the handle itself is not modified , then the argument > is marked IN/INOUT. > We use the first part (IN) to specify the use of the handle > and the second part (INOUT) to specify the use of the opaque > object. > Thus, in C++, > IN arguments are either references or pointers to const objects, > IN/INOUT arguments are references to const handles to non-const > objects. > > In all reoutines mentioned in the clarification below, > the INOUT handle declaration (in MPI-2.0) and the IN handle > declaration > (in MPI-1.1) ist modified into a IN/INOUT handle declaaration. > ____________________________ > > Rationale for this proposal: > > I have checked the total MPI 1.1 and 2.0 standard to find > all routines with an argument specification according to > the following declaration pattern: > > Language independent interface: > INOUT handle > C interface > MPI_handletype handle > > We can find this pattern only in MPI-2.0 at following > routines: > > MPI_INFO_SET / _DELETE > MPI_xxxx_SET_ERRHANDLER with xxxx=COMM / TYPE / WIN > MPI_GREQUEST_COMPLETE > MPI_xxxx_SET_NAME with xxxx=COMM / TYPE / WIN > MPI_xxxx_SET_ATTR with xxxx=COMM / TYPE / WIN > MPI_xxxx_DELETE_ATTR with xxxx=COMM / TYPE / WIN > MPI_FILE_SET_SIZE / _PREALLOCATE / _SET_INFO / _SET_VIEW > MPI_FILE_WRITE_AT / _WRITE_AT_ALL / _IWRITE_AT > MPI_FILE_READ / _READ_ALL / _WRITE / _WRITE_ALL > MPI_FILE_IREAD / _IWRITE > MPI_FILE_SEEK > MPI_FILE_READ_SHARED / _WRITE_SHARED > MPI_FILE_IREAD_SHARED / _IWRITE_SHARED > MPI_FILE_READ_ORDERED / _WRITE_ORDERED > MPI_FILE_SEEK_SHARED > MPI_FILE_WRITE_AT_ALL_BEGIN / MPI_FILE_WRITE_AT_ALL_END > MPI_FILE_READ_ALL_BEGIN / MPI_FILE_READ_ALL_END > MPI_FILE_WRITE_ALL_BEGIN / MPI_FILE_WRITE_ALL_END > MPI_FILE_READ_ORDERED_BEGIN / MPI_FILE_READ_ORDERED_END > MPI_FILE_WRITE_ORDERED_BEGIN / MPI_FILE_WRITE_ORDERED_END > MPI_FILE_SET_ATOMICITY / _SYNC > > All these routines keep the handle itself unchanged, but the > opaque object is modified in a way, that with oother MPI routines > this change can be detected. > For example, an attribute is cached or changed, a file pointer > is moved, the content of a file was modified. > > The current text in MPI 2.0 Sect. 2.3 Procedure Specification, > page 6 lines 30-34 read: > > There is one special case  if an argument is a handle to an > opaque object (these terms are defined in Section 2.5.1), and > the object is updated by the procedure call, then the argument > is marked OUT. It is marked this way even though the handle > itself is not modified  we use the OUT attribute to denote > that what the handle references is updated. Thus, in C++, > IN arguments are either references or pointers to const objects. > > With this definition (that I want to change later on) the use > of INOUT is correct. > > In MPI-1.1 we have several of such routines, but in all cases, > the handle is declared only as IN. > > I hope, I could find all of them: > > MPI_ATTR_PUT / _ DELETE > MPI_ERRHANDLER_SET > (these routines are now deprecated, but compare with use of > INOUT in MPI_COMM_SET_ATTR and MPI_COMM_DELETE_ATTR in MPI-2.0) > > The following proposal should remove this inconsistency and > should be a basis for correct definition of const. > ____________________________ > > I hope, with this proposal, the INOUT handle problem can be really > solved. > > 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 -- Jeff Squyres Cisco Systems

1 0

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

30 Jan '08

Dick: Re: > IBM long ago chose the real-politic approach of supporting both > interpretations. By default we restrict INFO objects to key:value pairs > that mean something to our functions that take INFO arguments and quietly > discard key:value pairs we do not recognize. As far as I know this has not > been a problem for anyone writing portable MPI applications. > > I can see that hint filtering would restrict someone who wants to use an > INFO for layered libraries. For that reason, any user who wishes to use an > INFO object as a general purpose cache for key:value pairs that mean > nothing to our MPI implementation can set an environment variable or > command line option (MP_HINTS_FILTERED/-hints_filtered = no) and get the > behavior Linda was expecting. > > I do have any problem with clarifying the standard to say that an MPI_Info Did you mean "do not have any problem"? Otherwise the sentence is hard to parse. > object should be prepared to manage unrecognized key:value string pairs. I > suggest changing: > > ============== > 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. > > to > > An info object is a cache for arbitrary ( key, value) 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. Minor grammar tweak: An info object is a cache for arbitrary ( key, value) pairs. Each MPI function that takes hints in the form of an MPI_Info must be prepared to ignore any key it does not recognize. I think I see what you mean. I'm a little worried that this could still be considered ambiguous. Perhaps changing the first sentence to: An implementation must support info objects as caches for arbitrary (key, value) pairs, regardless of whether the it recognizes the pairs. Bronis > ============ > > I think this approach implies that any statements about what happens when a > recognized key has a garbage value belong with the function that recognizes > the key. By insulating the info description from the descriptions of > particular MPI functions that take MPI_Info hints, we leave people the > option of using info objects as hints for third party libraries that work > with MPI but are not part of the MPI API. > > 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/30/2008 12:33:34 PM: > > > This is a proposal for MPI 2.1, Ballot 4. > > > > I'm asking especially > > Linda Stanberry, Bill Gropp, rajeev Thakur, Dick Treumann, Raja Daoud, > > the participants of the email-discussion in 1999, to review this > proposal. > > > > This is a follow up to: > > What info keys can be set? > > 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/infoset/ > > ___________________________________ > > Background: > > The sentence MPI 2.0, Sect. 4.10 Info Objects, page 43, line 38 > > > > "If a function does not recognize a key, it will ignore it, > > unless otherwise specified." > > > > was interpreted in two different ways: > > 1. This sentence is only valid in the routines in other chapters > > (e.g. processs creation and management, one-sided communication, > > parallel file I/O) where infos may be used to specify portable > > and implementation defined hints. > > 2. This interpretation is also valid for MPI_INFO_DELETE, MPI_INFO_SET, > > MPI_INFO_GET, and MPI_INFO_DUP. > > The following proposal ist based on Option 1. > > Option 2 is rejected due to the reason shown after the proposal. > > ___________________________________ > > > > Proposal: > > MPI 2.0, Sect. 4.10 Info Objects, page 43, line 38 read: > > If a function does not recognize a key, > > it will ignore it, unless otherwise specified. > > but should read: > > If a function in another section of the MPI standard > > does not recognize a key, > > it will ignore it, unless otherwise specified. > > The routines in this section. > > The functions in this section must not ignore any (key,value) pair. > > > > Add after MPI 2.0, Sect. 4.10 Info Objects, page 44, line 22 a new > > paragraph: > > Advice to implementors. > > For optimization, an MPI implementation may already sort out > > which (key,value) pair can be recognized for use in other chapters > > (e.g., in processs creation and management, one-sided communication, > > parallel file I/O) to guarantee a fast access to the appropriate > > information when used in routines of those chapters. > > For porpose of MPI_INFO_GET_NKEYS, MPI_INFO_GET_NTHKEY, > > MPI_INFO_GET_VALUELEN, and MPI_INFO_GET, the implementation > > must still keep also all other (key,value) pairs that cannot be > > recognized by that MPI implementation. > > (End of advice to implementors.) > > ________________________________ > > Rationale for this clarification: > > > > The first of the two interpretation options mentioned in the > > background information is the only valid interpretation > > when we assume, that layered implementation of parts of > > the MPI-2 standard should be possible. > > This was a goal of the MPI-2 Forum and the MPI-2.0 specification. > > ___________________________________ > > > > Comment: > > In the discussion (see the mails from 1999) > > one can clearly see, that an implementation of option 2 (done by IBM) > > cannot coexist with a layered implementation of MPI parallel > > file I/O, because MPI parallel file I/O routine need a different > > implementation of the INFO routines. Other chapters of MPI (e.g. 1-sided) > > need the original INF implementation. > > Two different INFO implementations cannot coexist in the same MPI > library. > > > > We could see the ouutcome of such problems with MPI_Wait & co. > > as long as a generalized request concept was not available. > > ROMIO had to define non-standard MPIO_Wait & co. routines. > > And they persist for a long time! > > > > Without the clarification above, we have the same problem with the > > INFO handling. > > > > 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 30 Jan '08

30 Jan '08

IBM long ago chose the real-politic approach of supporting both interpretations. By default we restrict INFO objects to key:value pairs that mean something to our functions that take INFO arguments and quietly discard key:value pairs we do not recognize. As far as I know this has not been a problem for anyone writing portable MPI applications. I can see that hint filtering would restrict someone who wants to use an INFO for layered libraries. For that reason, any user who wishes to use an INFO object as a general purpose cache for key:value pairs that mean nothing to our MPI implementation can set an environment variable or command line option (MP_HINTS_FILTERED/-hints_filtered = no) and get the behavior Linda was expecting. I do have any problem with clarifying the standard to say that an MPI_Info object should be prepared to manage unrecognized key:value string pairs. I suggest changing: ============== 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. to An info object is a cache for arbitrary ( key, value) 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. ============ I think this approach implies that any statements about what happens when a recognized key has a garbage value belong with the function that recognizes the key. By insulating the info description from the descriptions of particular MPI functions that take MPI_Info hints, we leave people the option of using info objects as hints for third party libraries that work with MPI but are not part of the MPI API. 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/30/2008 12:33:34 PM: > This is a proposal for MPI 2.1, Ballot 4. > > I'm asking especially > Linda Stanberry, Bill Gropp, rajeev Thakur, Dick Treumann, Raja Daoud, > the participants of the email-discussion in 1999, to review this proposal. > > This is a follow up to: > What info keys can be set? > 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/infoset/ > ___________________________________ > Background: > The sentence MPI 2.0, Sect. 4.10 Info Objects, page 43, line 38 > > "If a function does not recognize a key, it will ignore it, > unless otherwise specified." > > was interpreted in two different ways: > 1. This sentence is only valid in the routines in other chapters > (e.g. processs creation and management, one-sided communication, > parallel file I/O) where infos may be used to specify portable > and implementation defined hints. > 2. This interpretation is also valid for MPI_INFO_DELETE, MPI_INFO_SET, > MPI_INFO_GET, and MPI_INFO_DUP. > The following proposal ist based on Option 1. > Option 2 is rejected due to the reason shown after the proposal. > ___________________________________ > > Proposal: > MPI 2.0, Sect. 4.10 Info Objects, page 43, line 38 read: > If a function does not recognize a key, > it will ignore it, unless otherwise specified. > but should read: > If a function in another section of the MPI standard > does not recognize a key, > it will ignore it, unless otherwise specified. > The routines in this section. > The functions in this section must not ignore any (key,value) pair. > > Add after MPI 2.0, Sect. 4.10 Info Objects, page 44, line 22 a new > paragraph: > Advice to implementors. > For optimization, an MPI implementation may already sort out > which (key,value) pair can be recognized for use in other chapters > (e.g., in processs creation and management, one-sided communication, > parallel file I/O) to guarantee a fast access to the appropriate > information when used in routines of those chapters. > For porpose of MPI_INFO_GET_NKEYS, MPI_INFO_GET_NTHKEY, > MPI_INFO_GET_VALUELEN, and MPI_INFO_GET, the implementation > must still keep also all other (key,value) pairs that cannot be > recognized by that MPI implementation. > (End of advice to implementors.) > ________________________________ > Rationale for this clarification: > > The first of the two interpretation options mentioned in the > background information is the only valid interpretation > when we assume, that layered implementation of parts of > the MPI-2 standard should be possible. > This was a goal of the MPI-2 Forum and the MPI-2.0 specification. > ___________________________________ > > Comment: > In the discussion (see the mails from 1999) > one can clearly see, that an implementation of option 2 (done by IBM) > cannot coexist with a layered implementation of MPI parallel > file I/O, because MPI parallel file I/O routine need a different > implementation of the INFO routines. Other chapters of MPI (e.g. 1-sided) > need the original INF implementation. > Two different INFO implementations cannot coexist in the same MPI library. > > We could see the ouutcome of such problems with MPI_Wait & co. > as long as a generalized request concept was not available. > ROMIO had to define non-standard MPIO_Wait & co. routines. > And they persist for a long time! > > Without the clarification above, we have the same problem with the > INFO handling. > > 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 30 Jan '08

30 Jan '08

Rolf: Re: > This is a proposal for MPI 2.1, Ballot 4. > > I'm asking especially > Linda Stanberry, Bill Gropp, rajeev Thakur, Dick Treumann, Raja Daoud, > the participants of the email-discussion in 1999, to review this proposal. Linda has retired. I do remember this issue. Our position is unchanged - your option 1, which you suggest adopting, is clearly the right behavior to standardize. A couple minor tweaks to the proposed wording below. > This is a follow up to: > What info keys can be set? > in http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi-errata/index.… > with mail discussion in > http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi-errata/discus… > ___________________________________ > Background: > The sentence MPI 2.0, Sect. 4.10 Info Objects, page 43, line 38 > > "If a function does not recognize a key, it will ignore it, > unless otherwise specified." > > was interpreted in two different ways: > 1. This sentence is only valid in the routines in other chapters > (e.g. processs creation and management, one-sided communication, > parallel file I/O) where infos may be used to specify portable > and implementation defined hints. > 2. This interpretation is also valid for MPI_INFO_DELETE, MPI_INFO_SET, > MPI_INFO_GET, and MPI_INFO_DUP. > The following proposal ist based on Option 1. > Option 2 is rejected due to the reason shown after the proposal. > ___________________________________ > > Proposal: > MPI 2.0, Sect. 4.10 Info Objects, page 43, line 38 read: > If a function does not recognize a key, > it will ignore it, unless otherwise specified. > but should read: > If a function in another section of the MPI standard > does not recognize a key, > it will ignore it, unless otherwise specified. > The routines in this section. > The functions in this section must not ignore any (key,value) pair. Something was garbled. Change to: If a function in any other section of the MPI standard does not recognize a key, it will ignore it, unless otherwise specified. The functions in this section must not ignore any (key,value) pair. I'm not sure that "section" is well defined. Perhaps it would be best to list the functions that cannot ignore unrecognized pairs explicitly. Opinions? > Add after MPI 2.0, Sect. 4.10 Info Objects, page 44, line 22 a new > paragraph: > Advice to implementors. > For optimization, an MPI implementation may already sort out > which (key,value) pair can be recognized for use in other chapters > (e.g., in processs creation and management, one-sided communication, > parallel file I/O) to guarantee a fast access to the appropriate > information when used in routines of those chapters. > For porpose of MPI_INFO_GET_NKEYS, MPI_INFO_GET_NTHKEY, > MPI_INFO_GET_VALUELEN, and MPI_INFO_GET, the implementation > must still keep also all other (key,value) pairs that cannot be > recognized by that MPI implementation. > (End of advice to implementors.) Tweaking: Advice to implementors. An MPI implementation may restrict (key,value) pairs that are valid for use in routines from other chapters (e.g., in processs creation and management, one-sided communication, or parallel file I/O) to guarantee fast access to the appropriate information. 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.) "For optimization" and "fast access" are redundant. Added rationalization for retaining the others pairs. Various other grammar and spelling changes suggested. Bronis > ________________________________ > Rationale for this clarification: > > The first of the two interpretation options mentioned in the > background information is the only valid interpretation > when we assume, that layered implementation of parts of > the MPI-2 standard should be possible. > This was a goal of the MPI-2 Forum and the MPI-2.0 specification. > ___________________________________ > > Comment: > In the discussion (see the mails from 1999) > one can clearly see, that an implementation of option 2 (done by IBM) > cannot coexist with a layered implementation of MPI parallel > file I/O, because MPI parallel file I/O routine need a different > implementation of the INFO routines. Other chapters of MPI (e.g. 1-sided) > need the original INF implementation. > Two different INFO implementations cannot coexist in the same MPI library. > > We could see the ouutcome of such problems with MPI_Wait & co. > as long as a generalized request concept was not available. > ROMIO had to define non-standard MPIO_Wait & co. routines. > And they persist for a long time! > > Without the clarification above, we have the same problem with the > INFO handling. > > 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

Ballot 4 - Re: Request for interpretation
by unknown＠example.com 30 Jan '08

30 Jan '08

This is a proposal for MPI 2.1, Ballot 4. I'm asking especially Linda Stanberry, Bill Gropp, rajeev Thakur, Dick Treumann, Raja Daoud, the participants of the email-discussion in 1999, to review this proposal. This is a follow up to: What info keys can be set? in http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi-errata/index.… with mail discussion in http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi-errata/discus… ___________________________________ Background: The sentence MPI 2.0, Sect. 4.10 Info Objects, page 43, line 38 "If a function does not recognize a key, it will ignore it, unless otherwise specified." was interpreted in two different ways: 1. This sentence is only valid in the routines in other chapters (e.g. processs creation and management, one-sided communication, parallel file I/O) where infos may be used to specify portable and implementation defined hints. 2. This interpretation is also valid for MPI_INFO_DELETE, MPI_INFO_SET, MPI_INFO_GET, and MPI_INFO_DUP. The following proposal ist based on Option 1. Option 2 is rejected due to the reason shown after the proposal. ___________________________________ Proposal: MPI 2.0, Sect. 4.10 Info Objects, page 43, line 38 read: If a function does not recognize a key, it will ignore it, unless otherwise specified. but should read: If a function in another section of the MPI standard does not recognize a key, it will ignore it, unless otherwise specified. The routines in this section. The functions in this section must not ignore any (key,value) pair. Add after MPI 2.0, Sect. 4.10 Info Objects, page 44, line 22 a new paragraph: Advice to implementors. For optimization, an MPI implementation may already sort out which (key,value) pair can be recognized for use in other chapters (e.g., in processs creation and management, one-sided communication, parallel file I/O) to guarantee a fast access to the appropriate information when used in routines of those chapters. For porpose of MPI_INFO_GET_NKEYS, MPI_INFO_GET_NTHKEY, MPI_INFO_GET_VALUELEN, and MPI_INFO_GET, the implementation must still keep also all other (key,value) pairs that cannot be recognized by that MPI implementation. (End of advice to implementors.) ________________________________ Rationale for this clarification: The first of the two interpretation options mentioned in the background information is the only valid interpretation when we assume, that layered implementation of parts of the MPI-2 standard should be possible. This was a goal of the MPI-2 Forum and the MPI-2.0 specification. ___________________________________ Comment: In the discussion (see the mails from 1999) one can clearly see, that an implementation of option 2 (done by IBM) cannot coexist with a layered implementation of MPI parallel file I/O, because MPI parallel file I/O routine need a different implementation of the INFO routines. Other chapters of MPI (e.g. 1-sided) need the original INF implementation. Two different INFO implementations cannot coexist in the same MPI library. We could see the ouutcome of such problems with MPI_Wait & co. as long as a generalized request concept was not available. ROMIO had to define non-standard MPIO_Wait & co. routines. And they persist for a long time! Without the clarification above, we have the same problem with the INFO handling. 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

MPI 2.1 protocol from Jan. 2008 meeting of the MPI Forum
by unknown＠example.com 30 Jan '08

30 Jan '08

Dear all, I have done the protocol of the MPI 2.1 sessions of the Jan. 2008 meeting in form of a copy of the slides. I modified the slides in the way that they already reflect the decisions made by the Forum, e.g., names are now MPI 2.1 and MPI 1.3. Bill has stored the protocol on the web-pages at http://mpi-forum.cs.uiuc.edu/meetings/2008/JAN-14/mpi_21_at_MPIforum_2008-0… 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] Reading of Chapter 4
by unknown＠example.com 30 Jan '08

30 Jan '08

Thank you for your detailed reading of MPI 2.0 Chapter 4. Some comments and answers are inline below. Most will be for MPI 2.1 Ballot 4. Therefore, I switched the mail distribution to mpi-21_at_[hidden] On Wed, 9 Jan 2008 12:07:24 +0100 Jesper Larsson Traeff <traff_at_it.neclab.eu> wrote: > >Dear all, > >I have read Chapter 4 - here are my corrections, comments and suggestions >(only things not already in the errata sheet from Jan 30, 2002). There is >little of great substance. > >I have prefixed the comments as follows: >(typo) - uncontroversial typo/misspelling, should be corrected >(suggestion) - suggestion for alternative wording/extra comment >(addition) - suggestion for addition >(comment) - my comment, not intended for standard document > >General typo: is "implementor" (with an "o") a word in US English? >Shouldn't it be "Implementers"? (as in "Advice to implementers") > >General comments: the chapter is quite awful, and in the longer run I >would be in favor of having the parts (e.g. on datatypes) moved to >the chapters where they belong properly. I think Rolf will be doing some >of this. >I would also suggest having a special chapter in the new 2.1 >document summarizing all deprecated functionality (with a short rationale >as to why the function was deprecated) > >For mnemonic reasons, I would suggest having all datatype constructors >being of the form > >MPI_TYPE_CREATE_XXX > >and thus deprecate MPI_TYPE_CONTIGUOUS and MPI_TYPE_VECTOR as well. >It could also be argued to have an MPI_TYPE_CREATE_HINDEXED_BLOCK as >counterpart to MPI_TYPE_CREATE_INDEXED_BLOCK (but I am not making a >strong suggestion). > >best regards > >Jesper > >Chapter 4: >---------- > >Page 37, line 44-46: >(suggestion) drop, since this is largely a repetition of lines 34-36 >(except the statement "It is not suggested that this be the only way..." --> Ballot 4 > Page 43, line 33-34: >(suggestion) change "It consists of (key,value) pairs" to >"It stores a(n unordered) set of (key,value) pairs" to emphasize that the >info object is a kind of dictionary (data structure) --> Ballot 4 > >Page 43, line 34: >(suggestion) replace "may have only one value" by "can have only one value" --> Ballot 4 > >Page 43, line 37: > >(addition) "An empty info object is denoted by MPI_INFO_NULL." --> Ballot 4 Page 43, line 37: >(comment/discussion) The default is that the "null handle" is not >allowed as an IN argument (see MPI 1, Page 8, line 28), unless >explicitly allowed. This explicit permission is missing at some >places in MPI-2 (I found two): MPI_WIN_CREATE, page 111, and >MPI_FILE_SET_INFO, page 218. Is this default interpretation also intended >for MPI_INFO_NULL? A sentence on this would be in order, since the >info object is introduced here:" It is erroneous to pass MPI_INFO_NULL >as an IN argument, unless where explicitly allowed" (or whatever appropriate >depending on the intended interpretation). No, because MPI-1.1, Sect. 2.4.1, Page 8, line 28 is no longer valid. Whole Chapter 2 is substituted by MPI 2.0, Chapter 2. And in MPI 2.0, Sect. 2.5.1, Pages 8-9 the cited paragraph is removed. >Page 47, line 1: >(suggestion) change "Keys are numbered..." to >"At any point in time, keys are numbered consecutively from 0 to N-1, where..." If it is okay, I would ignore this, because it isn't a clarification. >Page 47, line 32: >(addition) >"Advice to implementers: The info object is a dictionary, and can be >implemented by a suitable data structure. Since the number of (key,value) >pairs can normally be assumed to be small a linear list implementation >will often suffice." This must be handled in the discussion thread "What info keys can be set?" on the errata page and http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi-errata/discus… I will continue on that thread with a ballot 4 proposal. >Page 49, line 21: >(addition) to align with the Fortran example 4.7, add C comment >"/* no memory is allocated */" --> Ballot 4 > >Page 49, line 22: >(addition) to make consistent with Fortran example, add line: >/* memory allocated */ --> Ballot 4 > >Page 50, line 9: >(type) remove first "in" --> Ballot 4 > >Page 55, line 26: >(comment) is this good Fortran style - scalars, e.g. 5 and MPI_REAL, >as implicit arrays of size 1? For a C programmer this is hurtful, and >some Fortran compilers do complain. I would suggest declaring the >proper arrays, so as to make the example more readily understandable, >also to the Fortran non-expert. Same goes for the similar Example 4.14 >on Page 60. --> Ballot 4 with following details: MPI 2.0, Sect. 4.12.6, Exa. 4.12, page 55, line 21-22 read: INTEGER TYPE, IERR INTEGER (KIND=MPI_ADDRESS_KIND) ADDR but should read: INTEGER TYPE, IERR, AOBLEN(1), AOTYPE(1) INTEGER (KIND=MPI_ADDRESS_KIND) AODISP(1) MPI 2.0, Sect. 4.12.6, Exa. 4.12, page 55, line 25-26 read: CALL MPI_GET_ADDRESS( R, ADDR, IERR) CALL MPI_TYPE_CREATE_STRUCT(1, 5, ADDR, MPI_REAL, TYPE, IERR) but should read: AOBLEN(1) = 5 CALL MPI_GET_ADDRESS( R, AODISP(1), IERR) AOTYPE(1) = MPI_REAL CALL MPI_TYPE_CREATE_STRUCT(1, AOBLEN(1),AODISP(1),AOTYPE(1), TYPE, IERR) MPI 2.0, Sect. 4.12.10, Exa. 4.14, page 60, line 31-32 read: INTEGER TYPE, IERR, MYRANK INTEGER (KIND=MPI_ADDRESS_KIND) ADDR but should read: INTEGER TYPE, IERR, MYRANK, AOBLEN(1), AOTYPE(1) INTEGER (KIND=MPI_ADDRESS_KIND) AODISP(1) MPI 2.0, Sect. 4.12.10, Exa. 4.14, page 55, line 35-36 read: CALL MPI_GET_ADDRESS( R, ADDR, IERR) CALL MPI_TYPE_CREATE_STRUCT(1, 5, ADDR, MPI_REAL, TYPE, IERR) but should read: AOBLEN(1) = 5 CALL MPI_GET_ADDRESS( R, AODISP(1), IERR) AOTYPE(1) = MPI_REAL CALL MPI_TYPE_CREATE_STRUCT(1, AOBLEN(1),AODISP(1),AOTYPE(1), TYPE, IERR) > >Page 56, line 29: >(typo) "assciated" should be "associated" --> Ballot 4 > >Page 67, line 18: >(suggestion) change "array of integer" to "array of nonnegative integer" >(shouldn't it be "integers"?) - to make consistent with HVECTOR and >HINDEXED. >(comment) There was an email discussion about 0-blocklengths, and >although it did not go very far, I think the conclusion was that >0-blocklengths are allowed and give rise to no element in the type >map. I think that some changes in the MPI-1 rules for how type maps >are generated by the INDEXED and STRUCT constructors are needed to >make this precise and correct. I have put this into the thread "Block lengths of zero in MPI Datatypes" http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi-errata/discus… >Page 70-77: >(comment) Two pictures illustrating the subarray and distributed array >constructors would be really helpful. May be nice to have. > >Page 74, line 9: >(typo) "is" missing in "it erroneous" --> Ballot 4 > >Chapter 5: >---------- > >Page 85, line 25: >(typo) "as the as the" should be "as the" --> Ballot 4 > 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