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

Re: [Mpi-21] MPI-2.1 April 1 document comments
by unknown＠example.com 07 Apr '08

07 Apr '08

Jeff: The PDF and physical page numbers do agree. That does not require numbering the frontage material from 1. When I view page xvi, my PDF reader says "xvi (16 of 603)". Perhaps your reader is broken? Bronis On Mon, 7 Apr 2008, Jeff Squyres wrote: > While reading the April 1 MPI-2.1 document for C++ and chapter 13 > issues, I itemized a list of other issues that I found. Some may want > to be pushed off to 2.2 (I have noted all of these with "--> This will > require a vote") -- I leave these up to the Forum to decide -- but > others should be fixed in 2.1. > > Enjoy. > > ----- > > April 7 2008 > Comments on MPI-2.1 April 1, 2008 document > > (notation: pX.Y = page X, line Y) > > Overall > ======= > > - Frontage numbering is still roman numerals -- I thought we agreed to > have the physical and PDF page numbers agree. > > - Some function pointer typedefs are "_function", others are "_fn" > We should be consistent throughout the text. > > Intro chapter > ============= > > - p5.2: Two open source MPI implementations are cited that are no > longer relevant. This entire sentence should be removed. Indeed, > the language in the overall paragraph is forward-looking -- it > should probably be re-worked to be in the present tense. > > - p6.46: Chapter 13 discusses Fortran issues (not Fortran 90 issues), > and also discusses language interoperability issues. > > - p7.11: Looks like a broken LaTeX reference. > > Terms and Conventions > ===================== > > - p9.40-10.10: The C and Fortran language neutral name do not include > the prefix "MPI_", but the C++ bindings include the prefix "MPI::". > Shouldn't the C/Fortran bindings be "MPI_CLASS_ACTION_SUBSET" > (etc.)? > > - p10.35: due to the decision from last meeting (sort out the > IN/OUT/INOUT mess in MPI-2.2), the language should be softened in > this paragraph and the full paragraph following this one (because > they contradict each other). Specifically, I propose changing: > > 10.35: Thus, in C++, IN aguments are either references... > to > Thus, in C++, IN arguments are usually either references... > > - p11.22: "Fortran in this document refers to Fortran 90". For > MPI-2.1, it is probably suitable to leave this, but we might want to > make a statement (footnote or parenthetical) that it is expected to > be updated in future MPI spec revisions. > > > Point-to-Point Communication > ============================ > > - p66.33: Why is the request argument to the C bindings MPI_CANCEL > take a pointer? The language neutral binding is IN, and the C++ > binding is const. This seems to be a contradiction. > --> This cannot be changed easily because every MPI implementation > uses (MPI_Request *) as the type. > > - p83.29: extra space: "( int count," > > - p92.43: mising "const" before "void* location". Adding "const" > will not break any user codes or MPI implementations. > --> This will require a vote. > > - p95.47-48: remove "const" before lb an extent arguments. > Removing "const" will not break any user codes or MPI > implementations. > --> This will require a vote. > > Collective Communications > ========================= > > - p123.32: "relaxed" uses quote marks in the wrong direction > > - p123.27: should say "MPI-1" instead of "MPI-1.2" > > Groups, Contexts, and Communicators > =================================== > > - p186.5: Descriptions for the C++ bindings need to be included here, > since they are different than the C bindings. The text from 13.1.7 > would seem to be sufficient. > > - p214.32: Missing "const" before "void* attribute_val_in" (datatype > callback argument is const) > --> This will require a vote. > > - p214.36: Delete function comm argument should be const (?) > --> This will require a vote. > > - p219.5: Missing "const" before "void* attribute_val_in" (datatype > callback argument is const) > --> This will require a vote. > > - p219.9: Delete function win argument should be const (?) > --> This will require a vote. > > - p221.44: Delete function type argument should be const (?) > --> This will require a vote. > > MPI Environmental Management > ============================ > > - p248.3: Earlier in the document, references are made to v1.3. Is > that not a valid tuple to return from MPI_GET_VERSION? > > - p249.45: Remove duplicate C++ binding > > - p254.21: Remove erroneous MPI::Intracomm::Create C++ binding > > - p255.2: First argument (comm handle reference) to errhandler > function should be const. > --> This will require a vote. > > - p256.27: First argument (win handle reference) to errhandler > function should be const. > --> This will require a vote. > > - p257.41: First argument (file handle reference) to errhandler > function should be const. > --> This will require a vote. > > - p258.39: Delete duplicate C++ binding > > - p259.13: Delete duplicate C++ binding > > - p260.36-43: First letter of description should be capitolized to be > consistent with rest of list. > > - p261.42: Delete duplicate C++ binding > > - p263.21-23: Delete duplicate C++ bindings > > - p264.22: Delete duplicate C++ binding > > - p267.24: Delete duplicate C++ binding > > - p267.42: Delete duplicate C++ binding > > Process Creation and Management > =============================== > > - p288.11: Function should be const. > --> This will require a vote. > > - p288.15: Function should be const. > --> This will require a vote. > > External Interfaces > =================== > > - p344.39: Arguments of query_fn, free_fn, and cancel_fn need to have > *'s. This is a consistency issue (the rest of the standard uses > "*" for function pointer parameters), not a correctness issue -- > works both ways. Should not break any user code or MPI > implementations. > > I/O > === > > - p419.43: datatype argument should be const > > Language Bindings > ================= > > - p437.18: Delete first sentence of paragraph > > - p437.22: Delete "original" > > - p437.24-29: Delete first and last sentences of paragraph > > - p437.29: New last sentence, "See Annex A.4.19 for a function cross > reference." > > - p438.11: Delete "for MPI-1" > > - p438.14-37: Join the two namespaces together and delete the > "Additionally, the following classes defined for MPI-2:" text. > Re-sort the class names as appropriate. > > - p439.2: Delete last sentence ("To maintain ... in [23].") > > - p442: Table 13.1 is redundant with Annex A.1. However, the > following C++ types are missing from Annex A.1: > > MPI::SIGNED_CHAR > MPI::BOOL > MPI::COMPLEX > MPI::DOUBLE_COMPLEX > MPI::LONG_DOUBLE_COMPLES > > - p442: Table 13.2 is redundant with Annex A.1 > > - p445.5-11: These functions are not listed in Annex A > > - p445.36-38: Remove this entire paragraph ("Compilers that do not > support..."). This feature has been a part of C++ since C++98, and > exists in all modern C++ compilers. > > - p446.7-17: Declarations for the MPI::Exceptions class are missing > from Annex A > > - p448.47: Remove trailing "/" from "OUT/" > > - p450.26-44: The bullet list is wholly redundant with section 2.6.2. > > - p456.27-29: VOLATILE is in Fortran 200x; reword first sentence from: > "In the longer term, the attribute VOLATILE is under > consideration for Fortran 2000 and would give the buffer or > variable the properties needed, but it would inhibit > optimization of any code containing the buffer or variable." > to > "The VOLATILE attribute, available in later versions of Fortran, > would give the buffer or variable the properties needed, but it > would inhibit optimization of any code containing the buffer or > variable." > > - p459.11-15: Delete paragraph > > - p462.43-45: Delete paragraph > > - p463.17-18: Delete first sentence; delete "In MPI-2," > > - p467.23: There is an extra space before "MPI_FINALIZE" > > - p468.16-39: None of these functions appear in Annex A (they > should!) > > - p469.41 and 44: These functions do not appear in Annex A (they > should!) > > - p470.46: Change sentence from: > "It is important to note that all C++ objects and their > corresponding C handles..." > to > "It is important to note that all C++ objects with > corresponding C handles..." > I.e., this sentence is referring only to C++ handles that actually > have corresponding C handles (e.g., not > MPI::ERRORS_THROW_EXCEPTIONS). > > Profiling Interface > =================== > > - p481.4: Delete "const" > --> This may require a vote. > > Annex A > ======= > > - p494.15: s/Fortran/Fortran only > > - p494.30: Missing MPI::ERRORS_THROW_EXCEPTIONS > > - p495.18-19 and 33-34: MPI_BYTE and MPI_PACKED are listed in two > separate tables. > > - p495.30: MPI::COMPLEX should be MPI::F_COMPLEX > > - p495.38: Looks like a blank extra 3rd column is in this table > > - p495.bottom: Missing table for "C++ only" datatypes: > MPI::BOOL > MPI::COMPLEX > MPI::DOUBLE_COMPLEX > MPI::LONG_DOUBLE_COMPLEX > MPI::SIGNED_CHAR > > - p496.1: Add ", no Fortran" before the ")" > > - p496.10, s/Fortran/Fortran only/ > > - p496.27-30: Alignment of table entries should be to the left, not > centered. > > - p544.13: Many of the prototypes for Clone() and Dup() are missing > > - p547.all: Many doubles of C++ bindings; likely because of errors in > the chapter text. > > - p554.41: Do we need an empty deprecated functions section? > > - p555.45-46: Forgot to mention MPI_ERRCODES_IGNORE, > MPI_F_STATUSES_IGNORE, and MPI_F_STATUS_IGNORE > > - p556.bottom: Missing prototypes for the MPI::Exceptions class > > -- > Jeff Squyres > Cisco Systems > > _______________________________________________ > mpi-21 mailing list > mpi-21_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-21 >

1 0

Re: [Mpi-21] TODO - AUTHORS of MPI-2.1 - Workplan
by unknown＠example.com 07 Apr '08

07 Apr '08

Jeff: I agree with most of your proposal. If stuff is wrong/outdated in Chapter 2, then it should be fixed. If stuff in Chapter 2 really belongs in a Language Bindings chapter, then it should be moved. However, I see no reason to make the language bindings chapter so early in the standard. In fact, I agree with Rolf's suggestion that it would be most appropriate as the last chapter, right before the appendix that lists the actual bindings. As Rolf suggested, we should make it chapter 14 and make the profiling interface chapter 13. Making it chapter 3 does not make sense. Bronis On Mon, 7 Apr 2008, Jeff Squyres wrote: > The problem is that the text about language bindings is fairly > disjoint between chapters 2 and 13. Indeed, chapter 13 is redundant > and out of order / inconsistent with regards to MPI-1 text in some > places *because* MPI-2 was a separate document. > > What about a slightly different proposal: > > 1. Move some of the existing Chapter 13/Language Bindings text into > the relevant parts in the rest of the 2.1 doc (e.g., move the C++ > communicators discussion to the Right place in Chapter 5/Groups, > Contexts, Comms). > > 2. Make a new chapter 3: Language Bindings. Put in it: > - All C/Fortran language bindings text from Chapter 2/Terms&Conv > - All remaining text from Chapter 13/Language bindings > > 3. Remove the [now empty] Chapter 13 > > > On Apr 4, 2008, at 7:48 AM, Rolf Rabenseifner wrote: > > About Chap. 13, especially C++. > > > > I'm proposing (referencec to MPI-2.1 Draft Apr.1, 2008): > > > > - The MPI-2 Forum decided to put only small overview stuff into > > Chap. 2 Terms. > > (I want to recall, that in MPI-2 the Terms are rewritten for whole > > MPI, > > i.e., still valid in MPI-2.1) > > - The MPI-2 Forum decided to put all deeper information into > > extra sections of an additionally last chapter on Bindings. > > - The MPI-2 Forum already decided that normal C++ bindings > > should be after the Fortran bindings. > > > > - Terms, page 18, lines 36-39 clearly expresses, that all constants > > are > > given only in MPI_ notation and that C++ names (with MPI::) > > are given in Annex A. > > I.e., MPI_COMM_WORLD, MPI_FLOAT, MPI_PROC_NULL, ... should not > > to be translated everywhere in the chapters. > > Same for Table 3.2 on page 27. > > > > - There are important things were C++ clearly differs from C, > > e.g. the handling of the Status. > > I have already added the Status handling, see page 31 lines 23-32. > > (By the way, this information was missing in Chap. 13.1 and only > > available in the Annex A.) > > > > - I'm not aware, whether there are more such stuff, that is explained > > for C and Fortran and should be also explained for C++. > > Do you see an additional stuff like status? > > > > - I do not expect that it would be a good idee to move all the ugly > > Fortran problems (17 pages) to the beginning of thee book into > > Chap. 2 Terms. > > I would recommend same rule for C++ (12 pages). > > Chap.2 terms has only 16 pages - with 2 pages dedicated to Fortran, > > 1/2 page to C, and 3 pages to C++. > > > > Best regards > > Rolf > > > > On Thu, 3 Apr 2008 15:13:10 -0400 > > Jeff Squyres <jsquyres_at_[hidden]> wrote: > >> On Apr 3, 2008, at 12:09 PM, Rolf Rabenseifner wrote: > > ... > >>> For me, the answer may have implications on how separate or > >>> integrated additional bindings should be integrated into the > >>> language independent text of the MPI standard. > >> > >> I don't quite understand. All officially-supported language bindings > >> should be listed consistently in the standard. In MPI-2.1, for > >> example, that means alongside the language neutral bindings in the > >> text and in Annex A. > > > > > > ------------- > > > > On Thu, 3 Apr 2008 15:27:08 -0400 > > Jeff Squyres <jsquyres_at_[hidden]> wrote: > >> What about the C++/Fortran language bindings text? Should the > >> majority of chapter 13 be merged into Terms and Conventions (and > >> elsewhere)? > >> > >> It's not really a "problem", per se -- but it is a little awkward. > >> There are sections in chapter 13 that could definitely fit in > >> existing > >> text elsewhere. Some of it is redundant, too. > >> > >> > >> > >> On Apr 3, 2008, at 3:19 PM, George Bosilca wrote: > >>> Bronis, > >>> > >>> If the data-type section get moved into the chapter 3 it make sense > >>> to merge the leftover of the chapter 11 with chapter 7, as long as > >>> we choose a right name. "MPI Environmental Management" is not the > >>> right chapter for "Generalized Requests". But of course these are > >>> just details. > >>> > >>> I'll get in touch with you asap to see how we can coordinate. > >>> > >>> Thanks, > >>> george. > >>> > >>> On Apr 3, 2008, at 12:58 PM, Bronis R. de Supinski wrote: > >>>> > >>>> Rolf: > >>>> > >>>> Re: > >>>>> my general statements do not answer you initial question: > >>>> > >>>> My opinion is that leaving obvious problems unfixed based > >>>> on an expected future version is a bad idea. However, I > >>>> don't want to argue over this since I think the best > >>>> approach is just to remove them now and then we don't > >>>> have to worry about them. Others have more concerns over > >>>> the time that they can devote to this (not that I have an > >>>> abundance) and might want to delay in any event in order > >>>> to get it right (at least mostly). > >>>> > >>>>> If you decide to move parts from Chap.11 to Chap.7, > >>>>> then you both mus discuss this. You both are responsible > >>>>> for these chapters. > >>>>> And you should first convince your reviewers: > >>>>> - Chap. 7: Rich, Jesper, Steve, Kannan, David, Bill > >>>>> - Chap.11: Bill and Rainer > >>>>> My recommendation: > >>>>> Express clearly which parts should be moved exactly to wich line > >>>>> (all based on page/line numbers as **printed** in Draft Apr. 1, > >>>>> 2008). > >>>> > >>>> I have discussed moving the datatype decoding stuff > >>>> with Rich and Bill. I will move those sections as I > >>>> suggested, with an initial pass for the current review. > >>>> This works well for Rich since he does not have time > >>>> to do this for another couple of weeks. I hope to get > >>>> that done today. > >>>> > >>>> For the remainder, I will look over the two chapters > >>>> (7 & 11) and propose an initial merge strategy. George > >>>> can react to that; I don't know how long it will take > >>>> me to get that done... > >>>> > >>>> Bronis > >>>> > >>>> _______________________________________________ > >>>> mpi-21 mailing list > >>>> mpi-21_at_[hidden] > >>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-21 > >>> > >>> _______________________________________________ > >>> mpi-21 mailing list > >>> mpi-21_at_[hidden] > >>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-21 > >> > >> > >> -- > >> Jeff Squyres > >> Cisco Systems > >> > >> _______________________________________________ > >> mpi-21 mailing list > >> mpi-21_at_[hidden] > >> http://lists.mpi-forum.org/mailman/listinfo.cgi/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.mpi-forum.org/mailman/listinfo.cgi/mpi-21 > > > -- > Jeff Squyres > Cisco Systems > > _______________________________________________ > mpi-21 mailing list > mpi-21_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-21 >

1 0

MPI-2.1 April 1 document comments
by unknown＠example.com 07 Apr '08

07 Apr '08

While reading the April 1 MPI-2.1 document for C++ and chapter 13 issues, I itemized a list of other issues that I found. Some may want to be pushed off to 2.2 (I have noted all of these with "--> This will require a vote") -- I leave these up to the Forum to decide -- but others should be fixed in 2.1. Enjoy. ----- April 7 2008 Comments on MPI-2.1 April 1, 2008 document (notation: pX.Y = page X, line Y) Overall ======= - Frontage numbering is still roman numerals -- I thought we agreed to have the physical and PDF page numbers agree. - Some function pointer typedefs are "_function", others are "_fn" We should be consistent throughout the text. Intro chapter ============= - p5.2: Two open source MPI implementations are cited that are no longer relevant. This entire sentence should be removed. Indeed, the language in the overall paragraph is forward-looking -- it should probably be re-worked to be in the present tense. - p6.46: Chapter 13 discusses Fortran issues (not Fortran 90 issues), and also discusses language interoperability issues. - p7.11: Looks like a broken LaTeX reference. Terms and Conventions ===================== - p9.40-10.10: The C and Fortran language neutral name do not include the prefix "MPI_", but the C++ bindings include the prefix "MPI::". Shouldn't the C/Fortran bindings be "MPI_CLASS_ACTION_SUBSET" (etc.)? - p10.35: due to the decision from last meeting (sort out the IN/OUT/INOUT mess in MPI-2.2), the language should be softened in this paragraph and the full paragraph following this one (because they contradict each other). Specifically, I propose changing: 10.35: Thus, in C++, IN aguments are either references... to Thus, in C++, IN arguments are usually either references... - p11.22: "Fortran in this document refers to Fortran 90". For MPI-2.1, it is probably suitable to leave this, but we might want to make a statement (footnote or parenthetical) that it is expected to be updated in future MPI spec revisions. Point-to-Point Communication ============================ - p66.33: Why is the request argument to the C bindings MPI_CANCEL take a pointer? The language neutral binding is IN, and the C++ binding is const. This seems to be a contradiction. --> This cannot be changed easily because every MPI implementation uses (MPI_Request *) as the type. - p83.29: extra space: "( int count," - p92.43: mising "const" before "void* location". Adding "const" will not break any user codes or MPI implementations. --> This will require a vote. - p95.47-48: remove "const" before lb an extent arguments. Removing "const" will not break any user codes or MPI implementations. --> This will require a vote. Collective Communications ========================= - p123.32: "relaxed" uses quote marks in the wrong direction - p123.27: should say "MPI-1" instead of "MPI-1.2" Groups, Contexts, and Communicators =================================== - p186.5: Descriptions for the C++ bindings need to be included here, since they are different than the C bindings. The text from 13.1.7 would seem to be sufficient. - p214.32: Missing "const" before "void* attribute_val_in" (datatype callback argument is const) --> This will require a vote. - p214.36: Delete function comm argument should be const (?) --> This will require a vote. - p219.5: Missing "const" before "void* attribute_val_in" (datatype callback argument is const) --> This will require a vote. - p219.9: Delete function win argument should be const (?) --> This will require a vote. - p221.44: Delete function type argument should be const (?) --> This will require a vote. MPI Environmental Management ============================ - p248.3: Earlier in the document, references are made to v1.3. Is that not a valid tuple to return from MPI_GET_VERSION? - p249.45: Remove duplicate C++ binding - p254.21: Remove erroneous MPI::Intracomm::Create C++ binding - p255.2: First argument (comm handle reference) to errhandler function should be const. --> This will require a vote. - p256.27: First argument (win handle reference) to errhandler function should be const. --> This will require a vote. - p257.41: First argument (file handle reference) to errhandler function should be const. --> This will require a vote. - p258.39: Delete duplicate C++ binding - p259.13: Delete duplicate C++ binding - p260.36-43: First letter of description should be capitolized to be consistent with rest of list. - p261.42: Delete duplicate C++ binding - p263.21-23: Delete duplicate C++ bindings - p264.22: Delete duplicate C++ binding - p267.24: Delete duplicate C++ binding - p267.42: Delete duplicate C++ binding Process Creation and Management =============================== - p288.11: Function should be const. --> This will require a vote. - p288.15: Function should be const. --> This will require a vote. External Interfaces =================== - p344.39: Arguments of query_fn, free_fn, and cancel_fn need to have *'s. This is a consistency issue (the rest of the standard uses "*" for function pointer parameters), not a correctness issue -- works both ways. Should not break any user code or MPI implementations. I/O === - p419.43: datatype argument should be const Language Bindings ================= - p437.18: Delete first sentence of paragraph - p437.22: Delete "original" - p437.24-29: Delete first and last sentences of paragraph - p437.29: New last sentence, "See Annex A.4.19 for a function cross reference." - p438.11: Delete "for MPI-1" - p438.14-37: Join the two namespaces together and delete the "Additionally, the following classes defined for MPI-2:" text. Re-sort the class names as appropriate. - p439.2: Delete last sentence ("To maintain ... in [23].") - p442: Table 13.1 is redundant with Annex A.1. However, the following C++ types are missing from Annex A.1: MPI::SIGNED_CHAR MPI::BOOL MPI::COMPLEX MPI::DOUBLE_COMPLEX MPI::LONG_DOUBLE_COMPLES - p442: Table 13.2 is redundant with Annex A.1 - p445.5-11: These functions are not listed in Annex A - p445.36-38: Remove this entire paragraph ("Compilers that do not support..."). This feature has been a part of C++ since C++98, and exists in all modern C++ compilers. - p446.7-17: Declarations for the MPI::Exceptions class are missing from Annex A - p448.47: Remove trailing "/" from "OUT/" - p450.26-44: The bullet list is wholly redundant with section 2.6.2. - p456.27-29: VOLATILE is in Fortran 200x; reword first sentence from: "In the longer term, the attribute VOLATILE is under consideration for Fortran 2000 and would give the buffer or variable the properties needed, but it would inhibit optimization of any code containing the buffer or variable." to "The VOLATILE attribute, available in later versions of Fortran, would give the buffer or variable the properties needed, but it would inhibit optimization of any code containing the buffer or variable." - p459.11-15: Delete paragraph - p462.43-45: Delete paragraph - p463.17-18: Delete first sentence; delete "In MPI-2," - p467.23: There is an extra space before "MPI_FINALIZE" - p468.16-39: None of these functions appear in Annex A (they should!) - p469.41 and 44: These functions do not appear in Annex A (they should!) - p470.46: Change sentence from: "It is important to note that all C++ objects and their corresponding C handles..." to "It is important to note that all C++ objects with corresponding C handles..." I.e., this sentence is referring only to C++ handles that actually have corresponding C handles (e.g., not MPI::ERRORS_THROW_EXCEPTIONS). Profiling Interface =================== - p481.4: Delete "const" --> This may require a vote. Annex A ======= - p494.15: s/Fortran/Fortran only - p494.30: Missing MPI::ERRORS_THROW_EXCEPTIONS - p495.18-19 and 33-34: MPI_BYTE and MPI_PACKED are listed in two separate tables. - p495.30: MPI::COMPLEX should be MPI::F_COMPLEX - p495.38: Looks like a blank extra 3rd column is in this table - p495.bottom: Missing table for "C++ only" datatypes: MPI::BOOL MPI::COMPLEX MPI::DOUBLE_COMPLEX MPI::LONG_DOUBLE_COMPLEX MPI::SIGNED_CHAR - p496.1: Add ", no Fortran" before the ")" - p496.10, s/Fortran/Fortran only/ - p496.27-30: Alignment of table entries should be to the left, not centered. - p544.13: Many of the prototypes for Clone() and Dup() are missing - p547.all: Many doubles of C++ bindings; likely because of errors in the chapter text. - p554.41: Do we need an empty deprecated functions section? - p555.45-46: Forgot to mention MPI_ERRCODES_IGNORE, MPI_F_STATUSES_IGNORE, and MPI_F_STATUS_IGNORE - p556.bottom: Missing prototypes for the MPI::Exceptions class -- Jeff Squyres Cisco Systems

1 0

Re: [Mpi-21] [Mpi-22] 2.1 cleanup or MPI 2.2?
by unknown＠example.com 07 Apr '08

07 Apr '08

Dick, if I'm right, then 23.r is not similar. 23.r OK p183, lines 5-8. This advice to implementors on reference counts for groups should include MPI_COMM_GROUP as a routine that increments the reference count. I've put yours as 29.a in http://www.hlrs.de/mpi/mpi21/doc/MPI-2.1draft-2008-02-23-review.txt 23.r I made an OK, but for your 29.a I would recommend to go to MPI-2.2. Best regards Rolf On Mon, 7 Apr 2008 10:54:00 -0400 Richard Treumann <treumann_at_[hidden]> wrote: > > > In the description of MPI_COMM_FREE we presently give the following advise > to implementors. > > A reference-count mechanism may be used: the reference count is > incremented by each call to \func{MPI\_COMM\_DUP}, and decremented by > each call to \func{MPI\_COMM\_FREE}. The object is ultimately > deallocated when the count reaches zero. > > I do not think it can ever be valid to implement MPI_COMM_DUP by simply > returning a new handle for an existing communicator object while bumping > its reference count because the output communicator must have a different > context than the original. Assuming I have not missed something, it seems > this advise is nonsense. > > Is removing this the kind of change that should go on the MPI 2.2 list? I > will be surprised if anyone offers a rationale for keeping the advise but I > am also not quite comfortable that it fits within the "clean up" rules for > MPI 2.1 at this late stage. > > Thoughts? > > 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 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] TODO - AUTHORS of MPI-2.1 - Workplan
by unknown＠example.com 07 Apr '08

07 Apr '08

The problem is that the text about language bindings is fairly disjoint between chapters 2 and 13. Indeed, chapter 13 is redundant and out of order / inconsistent with regards to MPI-1 text in some places *because* MPI-2 was a separate document. What about a slightly different proposal: 1. Move some of the existing Chapter 13/Language Bindings text into the relevant parts in the rest of the 2.1 doc (e.g., move the C++ communicators discussion to the Right place in Chapter 5/Groups, Contexts, Comms). 2. Make a new chapter 3: Language Bindings. Put in it: - All C/Fortran language bindings text from Chapter 2/Terms&Conv - All remaining text from Chapter 13/Language bindings 3. Remove the [now empty] Chapter 13 On Apr 4, 2008, at 7:48 AM, Rolf Rabenseifner wrote: > About Chap. 13, especially C++. > > I'm proposing (referencec to MPI-2.1 Draft Apr.1, 2008): > > - The MPI-2 Forum decided to put only small overview stuff into > Chap. 2 Terms. > (I want to recall, that in MPI-2 the Terms are rewritten for whole > MPI, > i.e., still valid in MPI-2.1) > - The MPI-2 Forum decided to put all deeper information into > extra sections of an additionally last chapter on Bindings. > - The MPI-2 Forum already decided that normal C++ bindings > should be after the Fortran bindings. > > - Terms, page 18, lines 36-39 clearly expresses, that all constants > are > given only in MPI_ notation and that C++ names (with MPI::) > are given in Annex A. > I.e., MPI_COMM_WORLD, MPI_FLOAT, MPI_PROC_NULL, ... should not > to be translated everywhere in the chapters. > Same for Table 3.2 on page 27. > > - There are important things were C++ clearly differs from C, > e.g. the handling of the Status. > I have already added the Status handling, see page 31 lines 23-32. > (By the way, this information was missing in Chap. 13.1 and only > available in the Annex A.) > > - I'm not aware, whether there are more such stuff, that is explained > for C and Fortran and should be also explained for C++. > Do you see an additional stuff like status? > > - I do not expect that it would be a good idee to move all the ugly > Fortran problems (17 pages) to the beginning of thee book into > Chap. 2 Terms. > I would recommend same rule for C++ (12 pages). > Chap.2 terms has only 16 pages - with 2 pages dedicated to Fortran, > 1/2 page to C, and 3 pages to C++. > > Best regards > Rolf > > On Thu, 3 Apr 2008 15:13:10 -0400 > Jeff Squyres <jsquyres_at_[hidden]> wrote: >> On Apr 3, 2008, at 12:09 PM, Rolf Rabenseifner wrote: > ... >>> For me, the answer may have implications on how separate or >>> integrated additional bindings should be integrated into the >>> language independent text of the MPI standard. >> >> I don't quite understand. All officially-supported language bindings >> should be listed consistently in the standard. In MPI-2.1, for >> example, that means alongside the language neutral bindings in the >> text and in Annex A. > > > ------------- > > On Thu, 3 Apr 2008 15:27:08 -0400 > Jeff Squyres <jsquyres_at_[hidden]> wrote: >> What about the C++/Fortran language bindings text? Should the >> majority of chapter 13 be merged into Terms and Conventions (and >> elsewhere)? >> >> It's not really a "problem", per se -- but it is a little awkward. >> There are sections in chapter 13 that could definitely fit in >> existing >> text elsewhere. Some of it is redundant, too. >> >> >> >> On Apr 3, 2008, at 3:19 PM, George Bosilca wrote: >>> Bronis, >>> >>> If the data-type section get moved into the chapter 3 it make sense >>> to merge the leftover of the chapter 11 with chapter 7, as long as >>> we choose a right name. "MPI Environmental Management" is not the >>> right chapter for "Generalized Requests". But of course these are >>> just details. >>> >>> I'll get in touch with you asap to see how we can coordinate. >>> >>> Thanks, >>> george. >>> >>> On Apr 3, 2008, at 12:58 PM, Bronis R. de Supinski wrote: >>>> >>>> Rolf: >>>> >>>> Re: >>>>> my general statements do not answer you initial question: >>>> >>>> My opinion is that leaving obvious problems unfixed based >>>> on an expected future version is a bad idea. However, I >>>> don't want to argue over this since I think the best >>>> approach is just to remove them now and then we don't >>>> have to worry about them. Others have more concerns over >>>> the time that they can devote to this (not that I have an >>>> abundance) and might want to delay in any event in order >>>> to get it right (at least mostly). >>>> >>>>> If you decide to move parts from Chap.11 to Chap.7, >>>>> then you both mus discuss this. You both are responsible >>>>> for these chapters. >>>>> And you should first convince your reviewers: >>>>> - Chap. 7: Rich, Jesper, Steve, Kannan, David, Bill >>>>> - Chap.11: Bill and Rainer >>>>> My recommendation: >>>>> Express clearly which parts should be moved exactly to wich line >>>>> (all based on page/line numbers as **printed** in Draft Apr. 1, >>>>> 2008). >>>> >>>> I have discussed moving the datatype decoding stuff >>>> with Rich and Bill. I will move those sections as I >>>> suggested, with an initial pass for the current review. >>>> This works well for Rich since he does not have time >>>> to do this for another couple of weeks. I hope to get >>>> that done today. >>>> >>>> For the remainder, I will look over the two chapters >>>> (7 & 11) and propose an initial merge strategy. George >>>> can react to that; I don't know how long it will take >>>> me to get that done... >>>> >>>> Bronis >>>> >>>> _______________________________________________ >>>> mpi-21 mailing list >>>> mpi-21_at_[hidden] >>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-21 >>> >>> _______________________________________________ >>> mpi-21 mailing list >>> mpi-21_at_[hidden] >>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-21 >> >> >> -- >> Jeff Squyres >> Cisco Systems >> >> _______________________________________________ >> mpi-21 mailing list >> mpi-21_at_[hidden] >> http://lists.mpi-forum.org/mailman/listinfo.cgi/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.mpi-forum.org/mailman/listinfo.cgi/mpi-21 -- Jeff Squyres Cisco Systems

1 0

2.1 cleanup or MPI 2.2?
by unknown＠example.com 07 Apr '08

07 Apr '08

In the description of MPI_COMM_FREE we presently give the following advise to implementors. A reference-count mechanism may be used: the reference count is incremented by each call to \func{MPI\_COMM\_DUP}, and decremented by each call to \func{MPI\_COMM\_FREE}. The object is ultimately deallocated when the count reaches zero. I do not think it can ever be valid to implement MPI_COMM_DUP by simply returning a new handle for an existing communicator object while bumping its reference count because the output communicator must have a different context than the original. Assuming I have not missed something, it seems this advise is nonsense. Is removing this the kind of change that should go on the MPI 2.2 list? I will be surprised if anyone offers a rationale for keeping the advise but I am also not quite comfortable that it fits within the "clean up" rules for MPI 2.1 at this late stage. Thoughts? Dick Dick Treumann - MPI Team/TCEM IBM Systems & Technology Group Dept 0lva / MS P963 -- 2455 South Road -- Poughkeepsie, NY 12601 Tele (845) 433-7846 Fax (845) 433-8363 *

1 0

AUTHORS of MPI-2.1 - SVN rules
by unknown＠example.com 04 Apr '08

04 Apr '08

Dear author, please commit with the following command (if your working directory is MPI-2.1): svn commit chap-xxx/xxx.tex -m 'MPI-2.1 - your-fiirst+last-name - summary, what you have done' svn update Please, inform also all via the mailing list, what you have done. Do we need any further rule? I'll try to put periodically copies of mpi-report.pdf on the web: http://www.hlrs.de/mpi/mpi21/doc/mpi-report.pdf Username and password as usual: mpi21 and mpi21 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

AUTHORS of MPI-2.1 - New directory structure
by unknown＠example.com 04 Apr '08

04 Apr '08

Dear author, for preparing write-access, I have moved (not changed) the sources. please be absolutely careful when makeing svn update Please be sure that if you have modified your source, that it is not overwritten (okay, i know that svn is itself very careful :-) * General structure _ mpi-report.tex _______________ Rolf Rabenseifner mpi-macs.tex * Frontmatter _______ chap-frontm/abstract-cpy.tex _ Bill Gropp chap-frontm/history.tex * Acknowledgements __ chap-frontm/credits.tex ______ Rich Graham(text) + Rolf(emails-auth.) * 1. Introduction ___ chap-intro/intro.tex _________ Bill Gropp - 2. Terms __________ chap-terms/terms-2.tex _______ Tony Skjellum * 3. Point-to-point _ chap-pt2pt/pt2pt.tex _________ Rich Graham * 4. Collectives ____ chap-coll/coll.tex ___________ Adam Moody * 5. Groups, etc. ___ chap-context/context.tex _____ Dick Treumann - 6. Toplogies ______ chap-topol/topol.tex _________ Jesper Traeff * 7. Environment ____ chap-inquiry/inquiry.tex _____ George Bosilca - 8. Miscellany _____ chap-misc/misc-2.tex _________ Jesper Traeff - 9. Process Crea.... chap-dynamic/dynamic-2.tex ___ David Solt - 10. One-sided Comm. chap-one-side/one-side-2.tex _ Jepser Traeff - 11. External Inter. chap-ei/ei-2.tex _____________ Bronis de Supinski - 12. IO ____________ chap-io/io-2.tex _____________ Rajeev Thakur - 13. Lang.Binding __ chap-binding/binding-2.tex ___ Jeff Squyres - 14. Profiling _____ chap-prof/prof.tex ___________ Bronis de Supinski - 15. Deprecated ____ chap-deprecated/deprecated.tex Rolf Rabenseifner - Annex A Lang.Bindi. chap-appLang/appLang-Const.tex Alexander Supalov MAKE-APPLANG & appLang*.tex __ Rolf Rabenseifner - Annex B Change-log. chap-changes/changes.tex _____ Rolf Rabenseifner - Bibliography ______ refs.bib _____________________ Bill Gropp - Index _____________ MAKE-FUNC-INDEX ______________ Rolf Rabenseifner Please make the svn update and check that make still produces mpi-report.pdf 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] TODO - AUTHORS of MPI-2.1 - Workplan
by unknown＠example.com 04 Apr '08

04 Apr '08

Hallo Rolf, ich habe mit svn die sourcen geholt, soweit funktioniert alles. meine kapitel sind ja nicht gross, und auch nicht schweirig. Ich werde versuchen montag/dienstag fertig zu werden Eine bitte: mein nachnamen ist (in LaTeX): Tr\"aff - kannst du das in den acks a"ndern? Scho"nes wochenende Jesper On Wed, Apr 02, 2008 at 06:25:45PM +0200, Rolf Rabenseifner wrote: > Dear Bill, Tony, Rich, Adam, Dick, Jesper, George, David, Bronis, > Rajeev, Jeff, and Alexander, > > you are responsible for one ore more chapters of MPI-2.1 until the > meeting. > > It is a tough schedule: > ----------------------- > > * Tues, April 1, my ROUND ONE is finished and the write token is > logically passed to all chapter authors: > - You have read access to the source (via SVN) and the pdf. > - You have write access to your local SVN copy. > - You will get write access to the SVN in a few days. > * Fri., April 11, chapter authors have finished ROUND TWO. > - This is a hard deadline (because I've to go on travel) > * Sat., April 12, I will produce mpi-report.pdf as basis for review > (I cannot do later, because April 14-17, I'm on travel) > * Mon.-Thu., April 14-17, strong review by the reviewer group > * Fri., April 18, reviews - if necessary must be included - > by the chapter authors > * Sat., April 19, I will produce final mpi-report.pdf > which is basis for > - final reviews through the reviewer group > - official reading at the April 28-30, 2008 meeting. > (I cannot do later because I'm on travel April 20-26) > > The goals of your work as chapter author: > ----------------------------------------- > > - Remove references to MPI-1 and MPI-2. > - Substitute by MPI. > - Necessary modifications to achieve this goal. > > With this, we should have a single MPI-2.1 standard that does > not "know" the MPI-1 or MPI-2 history of individual functions. > > ** This should be mainly a task in the area of chapter-introductions. > ** Please, never change the wording of function definitions. > > Exceptions: > - There are routines that are deprecated and that are > already referenced in a consistent way. > My recommendation: > Current wording: > There are *new* function, and existing are now deprecated. > Proposal: > There are functions, and there exist also deprecated functions > with (nearly) same functionality but deprecated due to some lack > in the bindings (or functionality) > - There is history information in the frontmatter. > - there is a change-log annex with limited memory (only previous version) > > Technical editing rule: > ----------------------- > > You must identify all of your changes: > > a) new/modified wording - you are highlighting your new/modified wording with: > > \mpiiidotiMergeNEWforSINGLEbegin% MPI-2.1 round-two - begin of modification > .... your modified / new wording .... > \mpiiidotiMergeNEWforSINGLEendI% MPI-2.1 round-two - end of modification > > b) Moved paragraphs, sentences, ... - you are highlighting the first word > of the moved text with: > > \mpiiidotiMergeNEWforSINGLEbegin% MPI-2.1 round-two - begin of text-move > First-word > \mpiiidotiMergeNEWforSINGLEendI% MPI-2.1 round-two - ongoing text-move > ... rest of the moved text.... > % MPI-2.1 round-two - end of text-move > > Caution: These macros work only in black parts of the text. > > In blue parts you must substitute > \mpiiidotiMergeNEWforSINGLEendI% > by > \mpiiidotiMergeNEWforSINGLEendII% > > The highlighting is done with red color. > (There are only a few other sentences from me magenta. > Therefore red should be the best to highlight the round-two modifications.) > > Rsponsibilities: > ---------------- > > * Frontmatter mpi-report.tex Bill Gropp > * Acknowledgements credits.tex Rich Graham(text) + Rolf(emails-auth.) > * 1. Introduction intro.tex Bill Gropp > - 2. Terms terms-2.tex Tony Skjellum > * 3. Point-to-point pt2pt.tex Rich Graham > * 4. Collectives coll.tex Adam Moody > * 5. Groups, etc. context.tex Dick Treumann > - 6. Toplogies topol.tex Jesper Traeff > * 7. Environment inquiry.tex George Bosilca > - 8. Miscellany misc-2.tex Jesper Traeff > - 9. Process Crea... dynamic-2.tex David Solt > - 10. One-sided Comm one-sided-2.tex Jepser Traeff > - 11. External Int. ei-2.tex Bronis de Supinski > - 12. IO io-2.tex Rajeev Thakur > - 13. Lang.Binding binding-2.tex Jeff Squyres > - 14. Profiling prof.tex Bronis de Supinski > - 15. Deprecated deprecated.tex Rolf Rabenseifner > - Annex A Lang.Bind. appLang*.tex, MAKE-APPLANG Alexander Supalov > - Annex B Change-log changes.tex Rolf Rabenseifner > - Bibliography refs.bib Bill Gropp > - Index MAKE-FUNC-INDEX Rolf Rabenseifner > > Legende: - Chapter is mainly taken from MPI-1.1 or MPI-2.0, > only small work expected > * There was a significant merge, or new text, or ..., > more work expected > > I wish you a good start and good luck with your chapter. > > 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] TODO - AUTHORS of MPI-2.1 - Workplan
by unknown＠example.com 04 Apr '08

04 Apr '08

Thanks. What I mean mostly is that the appendix can only be finalized, verified, and signed off on after all other chapters. This means we need to target April 10 to have the document really ready by April 11. The time zone difference plays against us here. -----Original Message----- From: mpi-21-bounces_at_[hidden] [mailto:mpi-21-bounces_at_[hidden]] On Behalf Of Rolf Rabenseifner Sent: Friday, April 04, 2008 5:10 PM To: MPI 2.1 Mailing List Subject: Re: [Mpi-21] TODO - AUTHORS of MPI-2.1 - Workplan Alexander, this isn't a problem: Annex A.1 is about constants: These must not change, because in this round-two, it is absolutly forbidden to change the standard content. Annex A.2-4 is done automatically, with one exception: If a whole chapter is removed or added, we must remove/add a line in MAKE-APPLANG (in lines 6-18). If a chapter title is changed, we have to modify such a line. That is all and easy, because Denis and his predecessor had made a good job. Best regards Rolf On Thu, 3 Apr 2008 20:23:46 +0100 "Supalov, Alexander" <alexander.supalov_at_[hidden]> wrote: > Hi guys, > > As soon as we start moving chapters, the binding annex may change as > well. I need your updates soon to make sense of the annex. > > Best regards. > > Alexander > > -----Original Message----- > From: mpi-21-bounces_at_[hidden] > [mailto:mpi-21-bounces_at_[hidden]] On Behalf Of George Bosilca > Sent: Thursday, April 03, 2008 9:20 PM > To: MPI 2.1 Mailing List > Subject: Re: [Mpi-21] TODO - AUTHORS of MPI-2.1 - Workplan > > Bronis, > > If the data-type section get moved into the chapter 3 it make sense to > merge the leftover of the chapter 11 with chapter 7, as long as we > choose a right name. "MPI Environmental Management" is not the right > chapter for "Generalized Requests". But of course these are just > details. > > I'll get in touch with you asap to see how we can coordinate. > > Thanks, > george. > > On Apr 3, 2008, at 12:58 PM, Bronis R. de Supinski wrote: > > > > Rolf: > > > > Re: > >> my general statements do not answer you initial question: > > > > My opinion is that leaving obvious problems unfixed based > > on an expected future version is a bad idea. However, I > > don't want to argue over this since I think the best > > approach is just to remove them now and then we don't > > have to worry about them. Others have more concerns over > > the time that they can devote to this (not that I have an > > abundance) and might want to delay in any event in order > > to get it right (at least mostly). > > > >> If you decide to move parts from Chap.11 to Chap.7, > >> then you both mus discuss this. You both are responsible > >> for these chapters. > >> And you should first convince your reviewers: > >> - Chap. 7: Rich, Jesper, Steve, Kannan, David, Bill > >> - Chap.11: Bill and Rainer > >> My recommendation: > >> Express clearly which parts should be moved exactly to wich line > >> (all based on page/line numbers as **printed** in Draft Apr. 1, > >> 2008). > > > > I have discussed moving the datatype decoding stuff > > with Rich and Bill. I will move those sections as I > > suggested, with an initial pass for the current review. > > This works well for Rich since he does not have time > > to do this for another couple of weeks. I hope to get > > that done today. > > > > For the remainder, I will look over the two chapters > > (7 & 11) and propose an initial merge strategy. George > > can react to that; I don't know how long it will take > > me to get that done... > > > > Bronis > > > > _______________________________________________ > > mpi-21 mailing list > > mpi-21_at_[hidden] > > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-21 > > --------------------------------------------------------------------- > Intel GmbH > Dornacher Strasse 1 > 85622 Feldkirchen/Muenchen Germany > Sitz der Gesellschaft: Feldkirchen bei Muenchen > Geschaeftsfuehrer: Douglas Lusk, Peter Gleissner, Hannes Schwaderer > Registergericht: Muenchen HRB 47456 Ust.-IdNr. > VAT Registration No.: DE129385895 > Citibank Frankfurt (BLZ 502 109 00) 600119052 > > 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.mpi-forum.org/mailman/listinfo.cgi/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.mpi-forum.org/mailman/listinfo.cgi/mpi-21 --------------------------------------------------------------------- Intel GmbH Dornacher Strasse 1 85622 Feldkirchen/Muenchen Germany Sitz der Gesellschaft: Feldkirchen bei Muenchen Geschaeftsfuehrer: Douglas Lusk, Peter Gleissner, Hannes Schwaderer Registergericht: Muenchen HRB 47456 Ust.-IdNr. VAT Registration No.: DE129385895 Citibank Frankfurt (BLZ 502 109 00) 600119052 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