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

Another MPI-2.2 attribute ambiguity?
by unknown＠example.com 16 Apr '09

16 Apr '09

This is related to -- but different from -- MPI 2.2 ticket #55 ("MPI-2.1 Cross-language attribute example is wrong"). Explicitly adding all the #55 CC members to this mail, plus a few others. I cannot find any text in MPI-2.1 (e.g., p223-225) describing specific behavior regarding the EXTRA_STATE arguments passed to the Fortran keyval copy and delete functions (both the ADDRESS_KIND and deprecated flavors). I see two choices: 1. pass the user's original EXTRA_STATE argument by reference to the callbacks, or 2. copy the user's original EXTRA_STATE into internal MPI storage and pass *that* value by reference to the callbacks ==> Open MPI currently does #1. What do other implementations do? I raise this issue because the text does not indicate which way is right. And I just ran across an old Sun test that assumed #2. But our internal copy of the Intel MPI tests assume #1 (to be fair: I have no idea if the Intel tests originally assumed #2 and we changed them to #1 over time). Indeed, #2 is actually in-line with the philosophy of storing attribute values in internal MPI storage. E.g.: INTEGER foo = 4 INTEGER bar CALL MPI_COMM_SET_ATTR(comm, keyval, foo, ierr) foo = 5 CALL MPI_COMM_GET_ATTR(comm, keyval, bar, flag, ierr) bar should equal 4, not 5 (right?). So what does that mean (or imply) about the EXTRA_STATE value passed to the Fortran callbacks? -- Jeff Squyres Cisco Systems

1 0

Re: [Mpi-22] MPI-2.2 -- change ABI or not?
by unknown＠example.com 07 Apr '09

07 Apr '09

Hi, Thanks. Let me add that there's quite vocal opposition to changing C++ ABI either. Best regards. Alexander -----Original Message----- From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Jeff Squyres Sent: Tuesday, April 07, 2009 1:19 PM To: MPI 2.2 Subject: Re: [Mpi-22] MPI-2.2 -- change ABI or not? Dick -- Following a round of discussion here in Chicago, there is general consensus on your point. The have decided to give a little leeway on the C++ bindings, though. That is, the C++ ABI may change (e.g., it *has* changed between 2.0 and 2.1) because most MPI's implement the C++ layer as inline functions and therefore don't usually affect the run-time ABI. For example #59 will definitely change the ABI. But right now, those methods *won't compile* in the C++ bindings (because they are wrong), so we can't possibly be breaking any real/user applications. On Apr 6, 2009, at 7:15 AM, Richard Treumann wrote: > Changing the ABI strikes me as a disaster. ( I did not notice this > discussion until just now ) > > If anyone is thinking it is OK for the Forum to cause a 2.1 > application compiled against MPI 2.1 headers to fail on an MPI 2.2 > version of the same implementation or the reverse (2.1 application > compiled with 2.2 headers fails on a 2.1 implementation) then I need > to hear a really good reason. And I mean really, awesomely, > spectacularly, bodacious ) good. > > The user of a parallel application does not always have control over > the level of MPI installed on the systems he uses and does not > always have the source code to recompile. Some people use multiple > systems (same architecture but maybe different MPI version) > > It seems like a very bad idea to tell the user of MPI that he must > upgrade all MPI software he uses on the same day the system admin > installs the MPI 2.2 version of the MPI implementation. > > It seems like an equally bad idea to be telling system admins they > are forbidden to upgrade to the MPI 2.2 version because one of more > critical applications used on the system cannot be easily rebuilt in > MPI 2.2 compatible form. > > If a shop uses only one ISV application then perhaps they can use > the MPI level the ISV specifies but what does a shop that uses > assorted ISV applications do if some vendors stick with MPI 2.1 > headers and others compile for 2.2? > > Dick > > > 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 04/04/2009 12:20:59 PM: > > > [image removed] > > > > [Mpi-22] MPI-2.2 -- change ABI or not? > > > > Jeff Squyres > > > > to: > > > > MPI 2.2 > > > > 04/04/2009 12:25 PM > > > > Sent by: > > > > mpi-22-bounces_at_[hidden] > > > > Please respond to "MPI 2.2" > > > > On Apr 4, 2009, at 9:53 AM, Jeff Squyres (jsquyres) wrote: > > > > > But the general point may need broad discussion next week -- > have we > > > been sure to adhere to the "must be ABI compatible" rule for all > > > MPI-2.2 issues? > > > > > (changed the subjet to be more accurate) > > > > > > I notice that ticket #5 has already had a 1st reading; it will > > certainly change the ABI. > > > > My point: if we are taking a hard line to make it possible for any > > existing MPI-2.1 application to be able to run against MPI-2.1 and > > MPI-2.2 versions of the same implementation, we will need to review > > all MPI-2.2 tickets. > > > > -- > > Jeff Squyres > > Cisco Systems > > > > _______________________________________________ > > 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 -- Jeff Squyres Cisco Systems _______________________________________________ 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] MPI-2.2 -- change ABI or not?
by unknown＠example.com 07 Apr '09

07 Apr '09

Dick -- Following a round of discussion here in Chicago, there is general consensus on your point. The have decided to give a little leeway on the C++ bindings, though. That is, the C++ ABI may change (e.g., it *has* changed between 2.0 and 2.1) because most MPI's implement the C++ layer as inline functions and therefore don't usually affect the run-time ABI. For example #59 will definitely change the ABI. But right now, those methods *won't compile* in the C++ bindings (because they are wrong), so we can't possibly be breaking any real/user applications. On Apr 6, 2009, at 7:15 AM, Richard Treumann wrote: > Changing the ABI strikes me as a disaster. ( I did not notice this > discussion until just now ) > > If anyone is thinking it is OK for the Forum to cause a 2.1 > application compiled against MPI 2.1 headers to fail on an MPI 2.2 > version of the same implementation or the reverse (2.1 application > compiled with 2.2 headers fails on a 2.1 implementation) then I need > to hear a really good reason. And I mean really, awesomely, > spectacularly, bodacious ) good. > > The user of a parallel application does not always have control over > the level of MPI installed on the systems he uses and does not > always have the source code to recompile. Some people use multiple > systems (same architecture but maybe different MPI version) > > It seems like a very bad idea to tell the user of MPI that he must > upgrade all MPI software he uses on the same day the system admin > installs the MPI 2.2 version of the MPI implementation. > > It seems like an equally bad idea to be telling system admins they > are forbidden to upgrade to the MPI 2.2 version because one of more > critical applications used on the system cannot be easily rebuilt in > MPI 2.2 compatible form. > > If a shop uses only one ISV application then perhaps they can use > the MPI level the ISV specifies but what does a shop that uses > assorted ISV applications do if some vendors stick with MPI 2.1 > headers and others compile for 2.2? > > Dick > > > 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 04/04/2009 12:20:59 PM: > > > [image removed] > > > > [Mpi-22] MPI-2.2 -- change ABI or not? > > > > Jeff Squyres > > > > to: > > > > MPI 2.2 > > > > 04/04/2009 12:25 PM > > > > Sent by: > > > > mpi-22-bounces_at_[hidden] > > > > Please respond to "MPI 2.2" > > > > On Apr 4, 2009, at 9:53 AM, Jeff Squyres (jsquyres) wrote: > > > > > But the general point may need broad discussion next week -- > have we > > > been sure to adhere to the "must be ABI compatible" rule for all > > > MPI-2.2 issues? > > > > > (changed the subjet to be more accurate) > > > > > > I notice that ticket #5 has already had a 1st reading; it will > > certainly change the ABI. > > > > My point: if we are taking a hard line to make it possible for any > > existing MPI-2.1 application to be able to run against MPI-2.1 and > > MPI-2.2 versions of the same implementation, we will need to review > > all MPI-2.2 tickets. > > > > -- > > Jeff Squyres > > Cisco Systems > > > > _______________________________________________ > > 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 -- Jeff Squyres Cisco Systems

1 0

Re: [Mpi-22] latex errors
by unknown＠example.com 06 Apr '09

06 Apr '09

[22:03] rtp-jsquyres-8716:~ % echo '\bib' \bib On Apr 6, 2009, at 10:30 AM, William Gropp wrote: > Argh. There are two problems which I'll work on fixing: > 1. It doesn't import the aux file from a full build. > 2. echo has unspecified behavior when the first character is a \ (some > echo's want this to be an escape into an extended character set, and > some don't). > Does echo '\bib' give \bib or ^hib on your system? > > Bill > > On Apr 6, 2009, at 5:59 AM, Jeff Squyres wrote: > > > Bill -- > > > > I get latex errors in any "chap-*" subdirectory when trying to build > > with a vanilla "make". Example: > > > > [6:58] rtp-jsquyres-8716:~/svn/mpi-forum-docs/MPI-2.2 % cd chap- > intro/ > > [6:58] rtp-jsquyres-8716:~/svn/mpi-forum-docs/MPI-2.2/chap-intro % > > make > > rm -f temp.tex > > cat ../chapter-head.tex intro.tex > temp.tex > > if grep \\cite intro.tex ; then \ > > ....etc....... > > LaTeX Warning: Reference `sec:lang' on page 7 undefined on input > line > > 818. > > > > > > LaTeX Warning: Reference `chap:change' on page 7 undefined on input > > line 834. > > > > ! Text line contains an invalid character. > > l.916 ^^H > > ibliographystyle{plain} > > ? > > > > > > > > > > On Apr 5, 2009, at 2:30 PM, MPI Forum wrote: > > > >> #148: Missing entries in the Index pages. > >> --------------------------------- > >> +------------------------------------------ > >> Reporter: RolfRabenseifner | Owner: > >> RolfRabenseifner > >> Type: Trivial text changes | Status: new > >> Priority: Waiting for reviews | Milestone: 2009/04/06 > >> Chicago > >> Version: MPI 2.2 | Resolution: > >> Keywords: | Implementation: Unnecessary > >> --------------------------------- > >> +------------------------------------------ > >> > >> Comment(by gropp): > >> > >> For the chapter authors, there is now a Makefile in each chapter's > >> directory. Running "make" (no options) will built that chapter, > >> including > >> a basic index. This index includes all items for which some index > >> entry > >> will be created; it isn't separated into constant, function, etc. > >> indices. > >> This should make it easier to check your chapter - just print out > the > >> index, then go through each page and make sure that all relevant > >> items > >> appear. > >> > >> -- > >> Ticket URL: <https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/ > >> 148#comment:3 > >>> > >> MPI Forum <https://svn.mpi-forum.org/> > >> MPI Forum > > > > > > -- > > Jeff Squyres > > Cisco Systems > > > > _______________________________________________ > > mpi-22 mailing list > > mpi-22_at_[hidden] > > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 > > William Gropp > Deputy Director for Research > Institute for Advanced Computing Applications and Technologies > Paul and Cynthia Saylor Professor of Computer Science > University of Illinois Urbana-Champaign > > > > > _______________________________________________ > mpi-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 > -- Jeff Squyres Cisco Systems

1 0

MPI 2.2 lists of participants and organizations (front matter for MPI 2.2)
by unknown＠example.com 06 Apr '09

06 Apr '09

Please have a look at https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/77 . This list the participants and their institutions; it is your responsibility to make sure that you and your organization are correctly listed. We will be giving this a first reading at this meeting. Thanks! Bill William Gropp Deputy Director for Research Institute for Advanced Computing Applications and Technologies Paul and Cynthia Saylor Professor of Computer Science University of Illinois Urbana-Champaign

1 0

Re: [Mpi-22] latex errors
by unknown＠example.com 06 Apr '09

06 Apr '09

Argh. There are two problems which I'll work on fixing: 1. It doesn't import the aux file from a full build. 2. echo has unspecified behavior when the first character is a \ (some echo's want this to be an escape into an extended character set, and some don't). Does echo '\bib' give \bib or ^hib on your system? Bill On Apr 6, 2009, at 5:59 AM, Jeff Squyres wrote: > Bill -- > > I get latex errors in any "chap-*" subdirectory when trying to build > with a vanilla "make". Example: > > [6:58] rtp-jsquyres-8716:~/svn/mpi-forum-docs/MPI-2.2 % cd chap-intro/ > [6:58] rtp-jsquyres-8716:~/svn/mpi-forum-docs/MPI-2.2/chap-intro % > make > rm -f temp.tex > cat ../chapter-head.tex intro.tex > temp.tex > if grep \\cite intro.tex ; then \ > ....etc....... > LaTeX Warning: Reference `sec:lang' on page 7 undefined on input line > 818. > > > LaTeX Warning: Reference `chap:change' on page 7 undefined on input > line 834. > > ! Text line contains an invalid character. > l.916 ^^H > ibliographystyle{plain} > ? > > > > > On Apr 5, 2009, at 2:30 PM, MPI Forum wrote: > >> #148: Missing entries in the Index pages. >> --------------------------------- >> +------------------------------------------ >> Reporter: RolfRabenseifner | Owner: >> RolfRabenseifner >> Type: Trivial text changes | Status: new >> Priority: Waiting for reviews | Milestone: 2009/04/06 >> Chicago >> Version: MPI 2.2 | Resolution: >> Keywords: | Implementation: Unnecessary >> --------------------------------- >> +------------------------------------------ >> >> Comment(by gropp): >> >> For the chapter authors, there is now a Makefile in each chapter's >> directory. Running "make" (no options) will built that chapter, >> including >> a basic index. This index includes all items for which some index >> entry >> will be created; it isn't separated into constant, function, etc. >> indices. >> This should make it easier to check your chapter - just print out the >> index, then go through each page and make sure that all relevant >> items >> appear. >> >> -- >> Ticket URL: <https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/ >> 148#comment:3 >>> >> MPI Forum <https://svn.mpi-forum.org/> >> MPI Forum > > > -- > Jeff Squyres > Cisco Systems > > _______________________________________________ > mpi-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 William Gropp Deputy Director for Research Institute for Advanced Computing Applications and Technologies Paul and Cynthia Saylor Professor of Computer Science University of Illinois Urbana-Champaign

1 0

Re: [Mpi-22] MPI-2.2 -- change ABI or not?
by unknown＠example.com 06 Apr '09

06 Apr '09

Changing the ABI strikes me as a disaster. ( I did not notice this discussion until just now ) If anyone is thinking it is OK for the Forum to cause a 2.1 application compiled against MPI 2.1 headers to fail on an MPI 2.2 version of the same implementation or the reverse (2.1 application compiled with 2.2 headers fails on a 2.1 implementation) then I need to hear a really good reason. And I mean really, awesomely, spectacularly, bodacious ) good. The user of a parallel application does not always have control over the level of MPI installed on the systems he uses and does not always have the source code to recompile. Some people use multiple systems (same architecture but maybe different MPI version) It seems like a very bad idea to tell the user of MPI that he must upgrade all MPI software he uses on the same day the system admin installs the MPI 2.2 version of the MPI implementation. It seems like an equally bad idea to be telling system admins they are forbidden to upgrade to the MPI 2.2 version because one of more critical applications used on the system cannot be easily rebuilt in MPI 2.2 compatible form. If a shop uses only one ISV application then perhaps they can use the MPI level the ISV specifies but what does a shop that uses assorted ISV applications do if some vendors stick with MPI 2.1 headers and others compile for 2.2? Dick 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 04/04/2009 12:20:59 PM: > [image removed] > > [Mpi-22] MPI-2.2 -- change ABI or not? > > Jeff Squyres > > to: > > MPI 2.2 > > 04/04/2009 12:25 PM > > Sent by: > > mpi-22-bounces_at_[hidden] > > Please respond to "MPI 2.2" > > On Apr 4, 2009, at 9:53 AM, Jeff Squyres (jsquyres) wrote: > > > But the general point may need broad discussion next week -- have we > > been sure to adhere to the "must be ABI compatible" rule for all > > MPI-2.2 issues? > > > (changed the subjet to be more accurate) > > > I notice that ticket #5 has already had a 1st reading; it will > certainly change the ABI. > > My point: if we are taking a hard line to make it possible for any > existing MPI-2.1 application to be able to run against MPI-2.1 and > MPI-2.2 versions of the same implementation, we will need to review > all MPI-2.2 tickets. > > -- > Jeff Squyres > Cisco Systems > > _______________________________________________ > mpi-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 *

1 0

latex errors
by unknown＠example.com 06 Apr '09

06 Apr '09

Bill -- I get latex errors in any "chap-*" subdirectory when trying to build with a vanilla "make". Example: [6:58] rtp-jsquyres-8716:~/svn/mpi-forum-docs/MPI-2.2 % cd chap-intro/ [6:58] rtp-jsquyres-8716:~/svn/mpi-forum-docs/MPI-2.2/chap-intro % make rm -f temp.tex cat ../chapter-head.tex intro.tex > temp.tex if grep \\cite intro.tex ; then \ ....etc....... LaTeX Warning: Reference `sec:lang' on page 7 undefined on input line 818. LaTeX Warning: Reference `chap:change' on page 7 undefined on input line 834. ! Text line contains an invalid character. l.916 ^^H ibliographystyle{plain} ? On Apr 5, 2009, at 2:30 PM, MPI Forum wrote: > #148: Missing entries in the Index pages. > --------------------------------- > +------------------------------------------ > Reporter: RolfRabenseifner | Owner: RolfRabenseifner > Type: Trivial text changes | Status: new > Priority: Waiting for reviews | Milestone: 2009/04/06 > Chicago > Version: MPI 2.2 | Resolution: > Keywords: | Implementation: Unnecessary > --------------------------------- > +------------------------------------------ > > Comment(by gropp): > > For the chapter authors, there is now a Makefile in each chapter's > directory. Running "make" (no options) will built that chapter, > including > a basic index. This index includes all items for which some index > entry > will be created; it isn't separated into constant, function, etc. > indices. > This should make it easier to check your chapter - just print out the > index, then go through each page and make sure that all relevant > items > appear. > > -- > Ticket URL: <https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/148#comment:3 > > > MPI Forum <https://svn.mpi-forum.org/> > MPI Forum -- Jeff Squyres Cisco Systems

1 0

Re: [Mpi-22] [MPI Forum] #59: Clarification on MPI::FILE_NULL, MPI::WIN_NULL and MPI::COMM_NULL
by unknown＠example.com 05 Apr '09

05 Apr '09

Hi, There are some big shrink-wrapped HPC apps that use C++ extensively. They may be unavailable under Windows yet. One would have to ask their authors whether the MPI C++ interface is used directly or abstracted away via an internal layer talking to C. Applications that are deployed over a tightly controlled OS like Windows would probably recompile after some grumbling, or migrate to a less tightly controlled OS. Under that less centrally controlled OS, like Linux, a change in the ABI would basically add another tree to the MPI forest, instead of consolidating all of them in one bundle. And then ISVs would have a problem, and us, implementors, would have a problem, too. Do we want to create a standard with a built-in set of problems? I don't think so. Best regards. Alexander -----Original Message----- From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Erez Haba Sent: Saturday, April 04, 2009 8:48 PM To: MPI 2.2 Subject: Re: [Mpi-22] [MPI Forum] #59: Clarification on MPI::FILE_NULL, MPI::WIN_NULL and MPI::COMM_NULL Its not always the choice of the MPI Application provider. In many cases there's an upgrade path for the infrastructure (like upgrading from Windows Compute Cluster Server to the newer version of Windows HPC Server) that includes an upgrade to the MPI implementation, any already deployed application that is not compatible with the new version would break. That would be a blocker for an upgrade and an important scenario for us. Another example is the impact on the application provider. Because of the release of the incompatible MPI 2.2 impl, the app provider has to re-ship an already shipped version of their app just to cope with the new installations of of MPI 2.2. (in those cases, yes, they don't ship the MPI implementation). That said, I didn't see any commercial app that depends on the C++ bindings. Thanks, .Erez -----Original Message----- From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Jeff Squyres Sent: Saturday, April 04, 2009 6:54 AM To: MPI 2.2 Subject: Re: [Mpi-22] [MPI Forum] #59: Clarification on MPI::FILE_NULL, MPI::WIN_NULL and MPI::COMM_NULL Regardless of this point, note that the C++ bindings are *broken* in MPI-2.1 with regards to #55. You can't compile C++ MPI-2.1 applications that use MPI::FILE_NULL, MPI::WIN_NULL as specified in #55, so the point may be moot for this ticket. But the general point may need broad discussion next week -- have we been sure to adhere to the "must be ABI compatible" rule for all MPI-2.2 issues? My $0.02: why would ISV's (or any MPI application provider) upgrade to an MPI-2.2 implementation? They would only upgrade if there are features or bug fixes that they want. They would not upgrade for the sake of upgrading to 2.2. In such cases, I think it's ok for any MPI application developer (ISV or not) to re-compile. Indeed, most ISV's bundle/ship their own MPI implementation, so they tightly control the MPI anyway. If they don't want to upgrade to an MPI-2.2 implementation, they won't. On Apr 3, 2009, at 4:04 PM, Supalov, Alexander wrote: > Right. This is why I'm not sure whether changing the const status > may break existing apps: only compiler writers know for sure what > kind of repercussions this change may have in a C++ program. We > should probably ask them, at least in order to make data based > decisions. > > Semantic changes are also important and should be reduced only to > clean extensions. If an application expects a certain outcome, and > this outcome changes, the application may break, defeating MPI-2.2 > charter. > > -----Original Message----- > From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden] > ] On Behalf Of Erez Haba > Sent: Friday, April 03, 2009 9:58 PM > To: MPI 2.2 > Subject: Re: [Mpi-22] [MPI Forum] #59: Clarification on > MPI::FILE_NULL, MPI::WIN_NULL and MPI::COMM_NULL > > I think it's both; > Any compiled application that is running against any specific > implementation does not have to recompile/rebuild to continue and > run against an updated implementation that is compliant with MPI 2.2. > i.e., MPI 2.2 does not mandate any runtime incompatibility. An > example for such incompatibility would be to for a change of the > rank parameter from int to MPI_Aint. > > Plus - any application that recompiles with the new MPI 2.2 headers > should not incur any (new) compiler errors. > > The first rule is significant to ISV's that release binary > implementation. Without this requirement, MPI 2.2 would create a > significant backward compatibility to those implementing. > > Thanks, > .Erez > -----Original Message----- > From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden] > ] On Behalf Of Jeff Squyres > Sent: Friday, April 03, 2009 11:07 AM > To: MPI Forum > Subject: Re: [Mpi-22] [MPI Forum] #59: Clarification on > MPI::FILE_NULL, MPI::WIN_NULL and MPI::COMM_NULL > > This is worth raising to the list. > > What is the rule for 2.2 -- that existing MPI applications must be > able to run with no changes against an MPI-2.2 library? Or is it that > existing MPI applications must be able to compile and run with no > source code changes against an MPI-2.2 implementation? > > I hope it's the latter; this change is relatively important. > > > > On Apr 3, 2009, at 5:56 AM, MPI Forum wrote: > > > #59: Clarification on MPI::FILE_NULL, MPI::WIN_NULL and > MPI::COMM_NULL > > ----------------------------------- > > +---------------------------------------- > > Reporter: hubertritzdorf | Owner: > hubertritzdorf > > Type: Correction to standard | Status: new > > Priority: Waiting for reviews | Milestone: 2009/04/06 > > Chicago > > Version: MPI 2.2 | Resolution: > > Keywords: | Implementation: Completed > > ----------------------------------- > > +---------------------------------------- > > Changes (by asupalov): > > > > * cc: alexander.supalov_at_[hidden] (added) > > > > > > Comment: > > > > Aren't we changing C++ ABI herewith? If so, we may want to postpone > > this > > change till MPI-3. > > > > -- > > Ticket URL: <https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/ > 59#comment:33 > > > > > MPI Forum <https://svn.mpi-forum.org/> > > MPI Forum > > > -- > Jeff Squyres > Cisco Systems > > _______________________________________________ > 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 -- Jeff Squyres Cisco Systems _______________________________________________ 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] [MPI Forum] #59: Clarification on MPI::FILE_NULL, MPI::WIN_NULL and MPI::COMM_NULL
by unknown＠example.com 05 Apr '09

05 Apr '09

Hi, This sort of puts the argument upon its head. It reads almost like "let's define a standard as we please, and those who don't like it may not upgrade". I bet there will be some who won't, as currently MPI-2.2 does not seem to provide an overwhelming set of new features to justify ABI incompatibility. What's the point in defining such a standard? I'm about to propose to scuttle an ABI-incompatible MPI-2.2 altogether then. Let's collect a critical mass of new features in the MPI-3, and then we'll be able to fix ABI issues in due order. Full disclaimer: written upon a 10-hour flight, running into 3 am by the old time zone. Best regards. Alexander -----Original Message----- From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Jeff Squyres Sent: Saturday, April 04, 2009 3:54 PM To: MPI 2.2 Subject: Re: [Mpi-22] [MPI Forum] #59: Clarification on MPI::FILE_NULL, MPI::WIN_NULL and MPI::COMM_NULL Regardless of this point, note that the C++ bindings are *broken* in MPI-2.1 with regards to #55. You can't compile C++ MPI-2.1 applications that use MPI::FILE_NULL, MPI::WIN_NULL as specified in #55, so the point may be moot for this ticket. But the general point may need broad discussion next week -- have we been sure to adhere to the "must be ABI compatible" rule for all MPI-2.2 issues? My $0.02: why would ISV's (or any MPI application provider) upgrade to an MPI-2.2 implementation? They would only upgrade if there are features or bug fixes that they want. They would not upgrade for the sake of upgrading to 2.2. In such cases, I think it's ok for any MPI application developer (ISV or not) to re-compile. Indeed, most ISV's bundle/ship their own MPI implementation, so they tightly control the MPI anyway. If they don't want to upgrade to an MPI-2.2 implementation, they won't. On Apr 3, 2009, at 4:04 PM, Supalov, Alexander wrote: > Right. This is why I'm not sure whether changing the const status > may break existing apps: only compiler writers know for sure what > kind of repercussions this change may have in a C++ program. We > should probably ask them, at least in order to make data based > decisions. > > Semantic changes are also important and should be reduced only to > clean extensions. If an application expects a certain outcome, and > this outcome changes, the application may break, defeating MPI-2.2 > charter. > > -----Original Message----- > From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden] > ] On Behalf Of Erez Haba > Sent: Friday, April 03, 2009 9:58 PM > To: MPI 2.2 > Subject: Re: [Mpi-22] [MPI Forum] #59: Clarification on > MPI::FILE_NULL, MPI::WIN_NULL and MPI::COMM_NULL > > I think it's both; > Any compiled application that is running against any specific > implementation does not have to recompile/rebuild to continue and > run against an updated implementation that is compliant with MPI 2.2. > i.e., MPI 2.2 does not mandate any runtime incompatibility. An > example for such incompatibility would be to for a change of the > rank parameter from int to MPI_Aint. > > Plus - any application that recompiles with the new MPI 2.2 headers > should not incur any (new) compiler errors. > > The first rule is significant to ISV's that release binary > implementation. Without this requirement, MPI 2.2 would create a > significant backward compatibility to those implementing. > > Thanks, > .Erez > -----Original Message----- > From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden] > ] On Behalf Of Jeff Squyres > Sent: Friday, April 03, 2009 11:07 AM > To: MPI Forum > Subject: Re: [Mpi-22] [MPI Forum] #59: Clarification on > MPI::FILE_NULL, MPI::WIN_NULL and MPI::COMM_NULL > > This is worth raising to the list. > > What is the rule for 2.2 -- that existing MPI applications must be > able to run with no changes against an MPI-2.2 library? Or is it that > existing MPI applications must be able to compile and run with no > source code changes against an MPI-2.2 implementation? > > I hope it's the latter; this change is relatively important. > > > > On Apr 3, 2009, at 5:56 AM, MPI Forum wrote: > > > #59: Clarification on MPI::FILE_NULL, MPI::WIN_NULL and > MPI::COMM_NULL > > ----------------------------------- > > +---------------------------------------- > > Reporter: hubertritzdorf | Owner: > hubertritzdorf > > Type: Correction to standard | Status: new > > Priority: Waiting for reviews | Milestone: 2009/04/06 > > Chicago > > Version: MPI 2.2 | Resolution: > > Keywords: | Implementation: Completed > > ----------------------------------- > > +---------------------------------------- > > Changes (by asupalov): > > > > * cc: alexander.supalov_at_[hidden] (added) > > > > > > Comment: > > > > Aren't we changing C++ ABI herewith? If so, we may want to postpone > > this > > change till MPI-3. > > > > -- > > Ticket URL: <https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/ > 59#comment:33 > > > > > MPI Forum <https://svn.mpi-forum.org/> > > MPI Forum > > > -- > Jeff Squyres > Cisco Systems > > _______________________________________________ > 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 -- Jeff Squyres Cisco Systems _______________________________________________ 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