- Mpi-22 - mailman3.cels.anl.gov

Re: [Mpi-22] MPI::Grequest::Start proposal
by unknown＠example.com 04 Sep '08

04 Sep '08

I think that this is okay; when we discussed it, I thought it was a different fix. The proposal is just fine. -----Original Message----- From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Jeff Squyres Sent: Thursday, September 04, 2008 7:26 AM To: MPI 2.2 Subject: [Mpi-22] MPI::Grequest::Start proposal Regarding https://svn.mpi-forum.org/trac/mpi-forum-web/wiki/mpi22/GrequestStartFnPtrA… : I have confirmed in Open MPI that if you change this: static Grequest Start(Query_function, Free_function, Cancel_function, void *); to static Grequest Start(Query_function *, Free_function *, Cancel_function *, void *); Recompile and reinstall, both the implementation and same C++ user code compiles without warning/error. Erez raised the point that this would change the type of any implementation and user-declared variables that hold the function pointer. It does not; such a variable type must always be (Free_function*); it's only the type that is passed through a function argument that can be either (Free_function) or (Free_function*). Someone smarter than me in C++ can explain why. :-) Specifically, the following compiles and runs without warning/error: ----- #include <stdio.h> typedef int Free_function(void *); int my_function(void*) { printf("In my_function\n"); return 0; } void foo1(Free_function ptr) { Free_function *save = ptr; save(0); } void foo2(Free_function* ptr) { Free_function *save = ptr; save(0); } int main (int argc, char*argv[]) { foo1(my_function); foo2(my_function); return 0; } ----- I tried 4 different C++ compilers (gnu, intel, pgi, pathscale): ----- [23:19] svbu-mpi:~/tmp % g++ foo.cc -o foo && ./foo In my_function In my_function [23:21] svbu-mpi:~/tmp % icpc foo.cc -o foo && ./foo In my_function In my_function [23:21] svbu-mpi:~/tmp % pgCC foo.cc -o foo && ./foo In my_function In my_function [23:22] svbu-mpi:~/tmp % pathCC foo.cc -o foo && ./foo In my_function In my_function [23:22] svbu-mpi:~/tmp % ------ So I think the proposal stands as it is written. -- Jeff Squyres Cisco Systems _______________________________________________ mpi-22 mailing list mpi-22_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22

1 0

MPI::Grequest::Start proposal
by unknown＠example.com 04 Sep '08

04 Sep '08

Regarding https://svn.mpi-forum.org/trac/mpi-forum-web/wiki/mpi22/GrequestStartFnPtrA… : I have confirmed in Open MPI that if you change this: static Grequest Start(Query_function, Free_function, Cancel_function, void *); to static Grequest Start(Query_function *, Free_function *, Cancel_function *, void *); Recompile and reinstall, both the implementation and same C++ user code compiles without warning/error. Erez raised the point that this would change the type of any implementation and user-declared variables that hold the function pointer. It does not; such a variable type must always be (Free_function*); it's only the type that is passed through a function argument that can be either (Free_function) or (Free_function*). Someone smarter than me in C++ can explain why. :-) Specifically, the following compiles and runs without warning/error: ----- #include <stdio.h> typedef int Free_function(void *); int my_function(void*) { printf("In my_function\n"); return 0; } void foo1(Free_function ptr) { Free_function *save = ptr; save(0); } void foo2(Free_function* ptr) { Free_function *save = ptr; save(0); } int main (int argc, char*argv[]) { foo1(my_function); foo2(my_function); return 0; } ----- I tried 4 different C++ compilers (gnu, intel, pgi, pathscale): ----- [23:19] svbu-mpi:~/tmp % g++ foo.cc -o foo && ./foo In my_function In my_function [23:21] svbu-mpi:~/tmp % icpc foo.cc -o foo && ./foo In my_function In my_function [23:21] svbu-mpi:~/tmp % pgCC foo.cc -o foo && ./foo In my_function In my_function [23:22] svbu-mpi:~/tmp % pathCC foo.cc -o foo && ./foo In my_function In my_function [23:22] svbu-mpi:~/tmp % ------ So I think the proposal stands as it is written. -- Jeff Squyres Cisco Systems

1 0

Re: [Mpi-22] New proposal: Support for large message counts
by unknown＠example.com 03 Sep '08

03 Sep '08

Alexander, Thanx for the suggestion. 1. Maybe I'm missing something here, but without name change, we break backward compatibility with "old" binaries coded to the existing APIs with 32-bit counts, and the new MPI 2.2 compatible MPI shared library that supports 64-bit counts --- without a re-build/relink step. Or are you proposing that implementations have multiple libraries, one that supports 32 bit counts, one that supports 64 bit counts, etc.? With a single library, (1) and (2) addresses backward compatibility, but maintains status-quo on support for large message counts, and (3) and (4) requires rebuild. However, having different names will take care of this. 2. If needed, we can explore normalization to a single API that supports MPI_Count in the MPI 3.0 time frame, since MPI 3.0 is open changes that can break backward compatibility. 3. I cannot think of any use cases for a "signed" count, but I'll let others chime in here. 4. I agree that new applications will have no issues with your approach. Thanx! Kannan -----Original Message----- From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Supalov, Alexander Sent: Wednesday, September 03, 2008 11:39 AM To: MPI 2.2 Subject: Re: [Mpi-22] New proposal: Support for large message counts Thanks. We may even do without changing the MPI routine names I think. Let's consider this: 1) #define MPI_Count int will yield the current MPI interface. 2) typedef int MPI_Count will yield the new 32-bit interface, still backward binary compatible with 1). 3) typedef long MPI_Count will yield new 64-bit interface. 4) typedef long long MPI_Count will safely bring us into XXII century (or earlier). Old applications may be rebuilt using 1) without any changes, dynamically linked against MPI library built using 2), and will have to be rebuilt to use MPI library built using 3) or 4). New applications will use library with the MPI_Count definitions, and, properly rebuilt, will work in either 32-, 64-, or 128-bit mode, using MPI libraries built using MPI bindings 2), 3), or 4), respectively. By the way, should MPI_Count really be signed? -----Original Message----- From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Narasimhan, Kannan Sent: Wednesday, September 03, 2008 5:55 PM To: MPI 2.2 Subject: Re: [Mpi-22] New proposal: Support for large message counts We can certainly consider this option, since it abstracts along the same lines as MPI_Offset. Thanx! Kannan -----Original Message----- From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Supalov, Alexander Sent: Wednesday, September 03, 2008 10:19 AM To: MPI 2.2 Subject: Re: [Mpi-22] New proposal: Support for large message counts Dear Kannan, Thanks. Why don't we define MPI_Count datatype instead, and make that grow if necessary? Best regards. Alexander -----Original Message----- From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Narasimhan, Kannan Sent: Friday, August 29, 2008 6:15 PM To: mpi-22_at_[hidden] Subject: [Mpi-22] New proposal: Support for large message counts I have submitted a new 2.2 proposal to addresses the need for large message counts (i.e. counts greater than the size of 32-bit integer) for MPI calls that communicate messages. Please refer to https://svn.mpi-forum.org/trac/mpi-forum-web/wiki/mpi22/LargeMsgCounts for details. Comments and suggestions are welcome. Thanx! Kannan _______________________________________________ mpi-22 mailing list mpi-22_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 --------------------------------------------------------------------- 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-22 mailing list mpi-22_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 _______________________________________________ mpi-22 mailing list mpi-22_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 --------------------------------------------------------------------- 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-22 mailing list mpi-22_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22

1 0

Re: [Mpi-22] New proposal: Support for large message counts
by unknown＠example.com 03 Sep '08

03 Sep '08

MPI_Aint has the right number of bits to hold an address. For operations that are address space oriented, count can be the same size as an MPI_Aint MPI_Offset has the right number of bits to deal with the range in a file. For operations that are file oriented, arguments like count should be an MPI_Offset A problem is that MPI_Datatype constructors are intended to apply to both and it is common for a 32 bit address space to operate on files with 64 bit offsets. What type should "count" on the new "long" MPI_Datatype constructors be in this case? The proposal says MPI_Aint but that is awkward for datatypes as fileviews. Dick Treumann - MPI Team IBM Systems & Technology Group Dept X2ZA / MS P963 -- 2455 South Road -- Poughkeepsie, NY 12601 Tele (845) 433-7846 Fax (845) 433-8363 mpi-22-bounces_at_[hidden] wrote on 09/03/2008 12:38:35 PM: > [image removed] > > Re: [Mpi-22] New proposal: Support for large message counts > > Supalov, Alexander > > to: > > MPI 2.2, > > 09/03/2008 12:48 PM > > Sent by: > > mpi-22-bounces_at_[hidden] > > Please respond to "MPI 2.2" > > Thanks. We may even do without changing the MPI routine names I think. > Let's consider this: > > 1) #define MPI_Count int will yield the current MPI interface. > 2) typedef int MPI_Count will yield the new 32-bit interface, still > backward binary compatible with 1). > 3) typedef long MPI_Count will yield new 64-bit interface. > 4) typedef long long MPI_Count will safely bring us into XXII century > (or earlier). > > Old applications may be rebuilt using 1) without any changes, > dynamically linked against MPI library built using 2), and will have to > be rebuilt to use MPI library built using 3) or 4). > > New applications will use library with the MPI_Count definitions, and, > properly rebuilt, will work in either 32-, 64-, or 128-bit mode, using > MPI libraries built using MPI bindings 2), 3), or 4), respectively. > > By the way, should MPI_Count really be signed? > > -----Original Message----- > From: mpi-22-bounces_at_[hidden] > [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Narasimhan, > Kannan > Sent: Wednesday, September 03, 2008 5:55 PM > To: MPI 2.2 > Subject: Re: [Mpi-22] New proposal: Support for large message counts > > We can certainly consider this option, since it abstracts along the same > lines as MPI_Offset. > > Thanx! > Kannan > > -----Original Message----- > From: mpi-22-bounces_at_[hidden] > [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Supalov, > Alexander > Sent: Wednesday, September 03, 2008 10:19 AM > To: MPI 2.2 > Subject: Re: [Mpi-22] New proposal: Support for large message counts > > Dear Kannan, > > Thanks. Why don't we define MPI_Count datatype instead, and make that > grow if necessary? > > Best regards. > > Alexander > > -----Original Message----- > From: mpi-22-bounces_at_[hidden] > [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Narasimhan, > Kannan > Sent: Friday, August 29, 2008 6:15 PM > To: mpi-22_at_[hidden] > Subject: [Mpi-22] New proposal: Support for large message counts > > I have submitted a new 2.2 proposal to addresses the need for large > message counts (i.e. counts greater than the size of 32-bit integer) for > MPI calls that communicate messages. > > Please refer to > https://svn.mpi-forum.org/trac/mpi-forum-web/wiki/mpi22/LargeMsgCounts > for details. > > Comments and suggestions are welcome. > > Thanx! > Kannan > > _______________________________________________ > mpi-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 > --------------------------------------------------------------------- > 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-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 > > _______________________________________________ > mpi-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 > --------------------------------------------------------------------- > 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-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 *

1 0

Re: [Mpi-22] New proposal: Support for large message counts
by unknown＠example.com 03 Sep '08

03 Sep '08

Thanks. We may even do without changing the MPI routine names I think. Let's consider this: 1) #define MPI_Count int will yield the current MPI interface. 2) typedef int MPI_Count will yield the new 32-bit interface, still backward binary compatible with 1). 3) typedef long MPI_Count will yield new 64-bit interface. 4) typedef long long MPI_Count will safely bring us into XXII century (or earlier). Old applications may be rebuilt using 1) without any changes, dynamically linked against MPI library built using 2), and will have to be rebuilt to use MPI library built using 3) or 4). New applications will use library with the MPI_Count definitions, and, properly rebuilt, will work in either 32-, 64-, or 128-bit mode, using MPI libraries built using MPI bindings 2), 3), or 4), respectively. By the way, should MPI_Count really be signed? -----Original Message----- From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Narasimhan, Kannan Sent: Wednesday, September 03, 2008 5:55 PM To: MPI 2.2 Subject: Re: [Mpi-22] New proposal: Support for large message counts We can certainly consider this option, since it abstracts along the same lines as MPI_Offset. Thanx! Kannan -----Original Message----- From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Supalov, Alexander Sent: Wednesday, September 03, 2008 10:19 AM To: MPI 2.2 Subject: Re: [Mpi-22] New proposal: Support for large message counts Dear Kannan, Thanks. Why don't we define MPI_Count datatype instead, and make that grow if necessary? Best regards. Alexander -----Original Message----- From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Narasimhan, Kannan Sent: Friday, August 29, 2008 6:15 PM To: mpi-22_at_[hidden] Subject: [Mpi-22] New proposal: Support for large message counts I have submitted a new 2.2 proposal to addresses the need for large message counts (i.e. counts greater than the size of 32-bit integer) for MPI calls that communicate messages. Please refer to https://svn.mpi-forum.org/trac/mpi-forum-web/wiki/mpi22/LargeMsgCounts for details. Comments and suggestions are welcome. Thanx! Kannan _______________________________________________ mpi-22 mailing list mpi-22_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 --------------------------------------------------------------------- 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-22 mailing list mpi-22_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 _______________________________________________ mpi-22 mailing list mpi-22_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 --------------------------------------------------------------------- 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

Re: [Mpi-22] New proposal: Support for large message counts
by unknown＠example.com 03 Sep '08

03 Sep '08

We can certainly consider this option, since it abstracts along the same lines as MPI_Offset. Thanx! Kannan -----Original Message----- From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Supalov, Alexander Sent: Wednesday, September 03, 2008 10:19 AM To: MPI 2.2 Subject: Re: [Mpi-22] New proposal: Support for large message counts Dear Kannan, Thanks. Why don't we define MPI_Count datatype instead, and make that grow if necessary? Best regards. Alexander -----Original Message----- From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Narasimhan, Kannan Sent: Friday, August 29, 2008 6:15 PM To: mpi-22_at_[hidden] Subject: [Mpi-22] New proposal: Support for large message counts I have submitted a new 2.2 proposal to addresses the need for large message counts (i.e. counts greater than the size of 32-bit integer) for MPI calls that communicate messages. Please refer to https://svn.mpi-forum.org/trac/mpi-forum-web/wiki/mpi22/LargeMsgCounts for details. Comments and suggestions are welcome. Thanx! Kannan _______________________________________________ mpi-22 mailing list mpi-22_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 --------------------------------------------------------------------- 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-22 mailing list mpi-22_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22

1 0

Re: [Mpi-22] New proposal: Support for large message counts
by unknown＠example.com 03 Sep '08

03 Sep '08

Dear Kannan, Thanks. Why don't we define MPI_Count datatype instead, and make that grow if necessary? Best regards. Alexander -----Original Message----- From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Narasimhan, Kannan Sent: Friday, August 29, 2008 6:15 PM To: mpi-22_at_[hidden] Subject: [Mpi-22] New proposal: Support for large message counts I have submitted a new 2.2 proposal to addresses the need for large message counts (i.e. counts greater than the size of 32-bit integer) for MPI calls that communicate messages. Please refer to https://svn.mpi-forum.org/trac/mpi-forum-web/wiki/mpi22/LargeMsgCounts for details. Comments and suggestions are welcome. Thanx! Kannan _______________________________________________ mpi-22 mailing list mpi-22_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 --------------------------------------------------------------------- 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

Several new proposals / moot points
by unknown＠example.com 02 Sep '08

02 Sep '08

Just in time for the Dublin meeting, I have posted several new MPI-2.2 proposals (it looks like a bunch of others have, too!) based on my items from the following URLs: http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi-errata/mpi2-2… http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi-errata/mpi2-2… http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi-errata/mpi2-2… I numbered each of the proposals with the item number from the above URLs. Here's the resulting proposals on the wiki: https://svn.mpi-forum.org/trac/mpi-forum-web/wiki/mpi22/CxxBindingsMissingC… https://svn.mpi-forum.org/trac/mpi-forum-web/wiki/mpi22/GrequestStartFnPtrA… https://svn.mpi-forum.org/trac/mpi-forum-web/wiki/mpi22/FnPtrTypedefNames https://svn.mpi-forum.org/trac/mpi-forum-web/wiki/mpi22/TextUpdatesToLangBi… https://svn.mpi-forum.org/trac/mpi-forum-web/wiki/mpi22/MPICancelWrongArgTy… https://svn.mpi-forum.org/trac/mpi-forum-web/wiki/mpi22/NamingConventionsPr… https://svn.mpi-forum.org/trac/mpi-forum-web/wiki/mpi22/RemoveCxxDeprecated… Additionally, several of the suggestions that I made on the #squyresX URLs are now moot. Here's a listing by issue number, including brief descriptions of why they are moot: ====================================================================== 30.c ? p4: 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. Editor's comment: should be done by the Forum Editor (WDG): The historical context is important. Rather than remove this, it should be updated. --> now moot in the final 2.1 doc; the language was re-worked. ====================================================================== 30.o R2 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. (See also 35.e) ---> seems moot now -- MPI-2.1 p195:41 says "Please see Section 16.1.7 on page 455 for further discussion about the C++ bindings for Dup() and Clone()." ====================================================================== 71.c ? - MPI-2.1 p571 Examples Index: there are still a bunch of repeated names, some in all caps, some in mixed case, etc. 71.d ? - MPI-2.1 p571 Examples Index: There are some examples listed just by MPI function name (e.g., MPI_SEND and MPI_Send) -- are we listing every MPI function in every MPI example? How was the selection for these example names given? Editor's comment: I tried to pick major routines in the examples (sometimes not all). Additionally, for some examples, I defined titles for the Index. 71.e ? - MPI-2.1 p574 MPI Constant and Predefined Handle Index: The first entry is still "MPI::*_NULL" 71.f ? - MPI-2.1 p574 MPI Constant and Predefined Handle Index: Are we listing the C++ constants and Fortran constants here, too? Or just the C constants? Or just language neutral? (I only see C++ predefined datatypes listed -- should we list all or none of them?) --> these still need to be cleaned up; but I don't think they need a proposal. ====================================================================== 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... Editor's comment: Is there an exception from this rule? If yes, then the proposal is okay. --> now moot; MPI 2.1 p10:34 says "...usually..." Remember that the Forum was very careful to state that this is *not* a rule; it's a guideline. ====================================================================== 32.j' ? Which names should be visible in the Index for Dup and Clone? TODO --> MPI::Comm::Clone() and MPI::Comm::Dup() show up in MPI-2.1 Annex A. 4 (C++ bindings) and MPI_COMM_CLONE and MPI_COMM_DUP show up in the MPI Function Index. I think that this is sufficient. ====================================================================== 30.h MPI-2.1 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. --> I no longer think that this is necessary. ====================================================================== 32.k R2 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. --> Moot: it's gone. (MPI-2.1 p443:46) ====================================================================== 33.n R2 p556.bottom: Missing prototypes for the MPI::Exceptions class --> Moot: now included in MPI-2.1 A.4.12. ====================================================================== 32.r 22 p463.17-18: Delete first sentence; delete "In MPI-2," --> Moot: done in MPI-2.2. ====================================================================== Enjoy. -- Jeff Squyres Cisco Systems

1 0

MPI 2.2 at MPI Forum Meeting
by unknown＠example.com 01 Sep '08

01 Sep '08

MPI 2.2 Group, We will be discussing the current proposals that have been added to the wiki. Please look these over before the meeting; the page is https://svn.mpi-forum.org/trac/mpi-forum-web/wiki/MpiTwoTwoWikiPage . I hope to see many of you on Wednesday! Bill William Gropp Paul and Cynthia Saylor Professor of Computer Science University of Illinois Urbana-Champaign *

1 0

Re: [Mpi-22] new datatypes proposal on the wiki
by unknown＠example.com 31 Aug '08

31 Aug '08

On Aug 21, 2008, at 9:02 PM, Dave Goodell wrote: > I have submitted a new 2.2 proposal to add several new datatypes to > the C and C++ bindings, most of them in order to keep up with the > C99 standard. This proposal also adds MPI_AINT and MPI_OFFSET as > predefined datatypes. Comments are welcome. > > https://svn.mpi-forum.org/trac/mpi-forum-web/wiki/mpi22/NewPredefinedDataty… Dave -- I like the idea of [u]int[x]_t types; that would certainly be helpful to some apps. I'm a little confused on your discussion about how bool and complex may be represented differently in each language. Are you saying that MPI_BOOL may be a different thing that [the already-existing] MPI::BOOL? Also, MPI_COMPLEX and MPI_DOUBLE_COMPLEX both already exist for the corresponding Fortran types (I can't remember offhand -- MPI_LONG_DOUBLE_COMPLEX may exist already, too). How do you propose to reconcile this conflict? -- Jeff Squyres Cisco Systems

1 0