From david.solt at [hidden] Mon May 11 00:54:24 2009 From: david.solt at [hidden] (Solt, David George) Date: Mon, 11 May 2009 05:54:24 +0000 Subject: [Mpi-22] [MPI Forum] #117: Define a new MPI_Count Datatype In-Reply-To: <053.b63bec7758ea0a42cb199dae3b9e79e5@lists.mpi-forum.org> Message-ID: I want to make everyone on the 2.2 list aware of this update to ticket #117: Thanks, Dave Solt -----Original Message----- From: MPI Forum [mailto:mpi-22_at_[hidden]] Sent: Monday, May 11, 2009 12:52 AM Subject: Re: [MPI Forum] #117: Define a new MPI_Count Datatype #117: Define a new MPI_Count Datatype ----------------------------+------------------------------------------- ----------------------------+---- Reporter: kannan | Owner: davesolt Type: New routine(s) | Status: new Priority: Had 1st reading | Milestone: 2009/06/08 California Version: MPI 2.2 | Resolution: Keywords: | Implementation: Waiting ----------------------------+------------------------------------------- ----------------------------+---- Changes (by davesolt): * owner: kannan => davesolt Comment: I have reassigned this to me as my colleague, Kannan, has moved on to a different role within HP. I have been working to come up to speed on this ticket and provide a reference implementation with Open MPI, which I have made available at: http://bitbucket.org/jsquyres/mpi-count/ Thanks to Jeff S. for his help on setting this up. The implementation is for C and Fortran 90. It does not include C++, although I have manually verified that C++ does work in the same way. The goal of this prototype is to demonstrate that applications can be compiled with a header file that uses the previous interface definitions and then dynamically linked against an MPI that uses the new interfaces. However, this implementation reflexively demonstrates the feasibility because only the header files where changed. Therefore, an application compiled with this implementation will be compiled against a different header file than the associated library uses for its own definitions. For example, the mpi.h header file defines MPI_Send with an MPI_Count argument. Internally, the library defines MPI_Send using an int argument. Applications compiled against this header file will run with this implementation, proving that the header file difference does not actually change the signatures in a significant way. In addition, an application compiled with the "old" header file will run against this implementation. There are example files in the 117 directory to test with. In the course of this work I did come to wrestle with some of the same issues brought up on this list: 1) MPI_Type_size, etc. >> What about MPI_Type_size now that all the datatype constructors take MPI_Count? > >My rationale -- I'd left out converting size arguments/return values on other APIs >since I targetted MPI_Count to represent only the count type, and not get into the >promotion of sizes. I agree that logically MPI_Type_size has to be promoted, but >that would mean that we would now have to go thru every API that takes in/ returns >sizes and look for candidates. I also found it difficult to draw a line at what other arguments need to be converted to account for the fact that the proposal allows for large datatypes. In retrospect, I wish that the proposal had not attempted to allow for large datatypes and had limited itself to communicating calls. Some other calls such as MPI_Unpack and MPI_Type_size are clearly incompatible with the proposed changes. 2) MPI_Type_get_envelope, MPI_Type_get_contents I believe that since these return values that were set by creation routines, some of these arguments need to be MPI_Count sized as well. In the prototype implemenation, I did change these arguments, but have not yet made any changes to this proposal 3) MPI_Type_create_struct The proposal is to change argument #1, but I believe this is incorrect. Argument #1 is the number of items in the struct, which is likely to not be > 2GB. However, the 2nd argument is the size of individual elements, which I believe is the argument we intend to change. 4) MPI_Status_set_elements This is not included in the proposal, but I believe that argument #3 should clearly be MPI_Count sized since the proposal is that the count field of status can be > 2GB. 5) MPI_Type_create_darray I believe this was an oversight and this datatype creation routine should have argument #3 changed to MPI_Count. I would appreciate some other input on this one as I do not have a lot of experience with this particular function. -- Ticket URL: MPI Forum MPI Forum From jsquyres at [hidden] Thu May 14 12:05:07 2009 From: jsquyres at [hidden] (Jeff Squyres) Date: Thu, 14 May 2009 13:05:07 -0400 Subject: [Mpi-22] Another MPI-2.2 attribute ambiguity? In-Reply-To: Message-ID: Another question about this issue... Since all fortran values are passed by reference, does the MPI care if the callback function changes the EXTRA_STATE value? I see 2 choices: 1. The MPI copies the value of extra_state when MPI_*_CREATE_KEVAL is invoked to internal storage. This internal storage is passed to all the callbacks when invoked. If any of the callbacks change the value, then subsequent invocations of the callback get the changed value. 2. The MPI copies the value of extra_state when MPI_*_CREATE_KEVAL is invoked to internal storage. This internal storage is copied any time a callback is invoked; the copy is passed to the callback (and freed when the callback returns). In this way, the same EXTRA_STATE value that was originally passed to the keyval constructor will always be passed to any callbacks. What do current MPI implementations do? OMPI's development trunk has been updated to do #1; I'm wondering if it should do #2. On Apr 17, 2009, at 10:21 AM, Jeff Squyres (jsquyres) wrote: > Ok, I'll file an MPI-3 ticket for this. > > (for everyone else on the 2.2 list wondering why you just got > blitzkrieged with a whole pile of emails on this topic: the listserver > sent all these mails to moderation because of the lengthy CC list. IU > just approved all the mails to go through this morning) > > > On Apr 17, 2009, at 9:40 AM, William Gropp wrote: > > > Yes, this is worth an ATI - the fact that we traded this much mail > on > > it is proof of that :) > > > > Thanks, Jeff. > > > > Bill > > > > On Apr 17, 2009, at 8:14 AM, Jeff Squyres wrote: > > > > > Someone pointed out to me this morning that there's no restriction > > on > > > the value of EXTRA_STATE when CREATE_KEYVAL is invoked -- it may > > be an > > > expression, for example. I think that pretty much seals the deal > > that > > > #2 is the correct way. > > > > > > I think that this is worth an ATI in the text; does anyone > disagree? > > > I volunteer to write it up/make a 3.0 ticket (hey, first ticket > for > > > the Misc WG! :-) ) if no one disagrees. > > > > > > > > > On Apr 17, 2009, at 8:59 AM, Supalov, Alexander wrote: > > > > > >> Hi, > > >> > > >> Intel MPI (and most likely other MPICH2 derivatives) appears to > use > > >> method #2. > > >> > > >> Best regards. > > >> > > >> Alexander > > >> > > >> -----Original Message----- > > >> From: Jeff Squyres [mailto:jsquyres_at_[hidden]] > > >> Sent: Thursday, April 16, 2009 4:19 PM > > >> To: MPI 2.2; Rajeev Thakur; William Gropp; Rolf Rabenseifner; > > Hubert > > >> Ritzdorf; Terry Dontje; Dave Goodell; Darius Buntinas; Pavan > > Balaji; > > >> Supalov, Alexander; Bronis de Supinski; David Solt; Hans > Westgaard > > >> Ry; Håkon Bugge > > >> Subject: Another MPI-2.2 attribute ambiguity? > > >> > > >> 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 > > >> > > >> > > > --------------------------------------------------------------------- > > >> 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. > > >> > > >> > > > > > > > > > -- > > > Jeff Squyres > > > Cisco Systems > > > > > > > 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 > > > > > > > > > > > -- > Jeff Squyres > Cisco Systems > > > _______________________________________________ > mpi-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 -- Jeff Squyres Cisco Systems From jsquyres at [hidden] Mon May 18 10:24:57 2009 From: jsquyres at [hidden] (Jeff Squyres) Date: Mon, 18 May 2009 11:24:57 -0400 Subject: [Mpi-22] Another MPI-2.2 attribute ambiguity? In-Reply-To: Message-ID: <0036D9F3-9421-4EF3-8119-16ECD8A480AC@cisco.com> I'm most curious to know what current MPI implementations do in this scenario. On May 14, 2009, at 1:05 PM, Jeff Squyres wrote: > Another question about this issue... > > Since all fortran values are passed by reference, does the MPI care > if the callback function changes the EXTRA_STATE value? I see 2 > choices: > > 1. The MPI copies the value of extra_state when MPI_*_CREATE_KEVAL > is invoked to internal storage. This internal storage is passed to > all the callbacks when invoked. If any of the callbacks change the > value, then subsequent invocations of the callback get the changed > value. > > 2. The MPI copies the value of extra_state when MPI_*_CREATE_KEVAL > is invoked to internal storage. This internal storage is copied any > time a callback is invoked; the copy is passed to the callback (and > freed when the callback returns). In this way, the same EXTRA_STATE > value that was originally passed to the keyval constructor will > always be passed to any callbacks. > > What do current MPI implementations do? > > OMPI's development trunk has been updated to do #1; I'm wondering if > it should do #2. > > > > On Apr 17, 2009, at 10:21 AM, Jeff Squyres (jsquyres) wrote: > >> Ok, I'll file an MPI-3 ticket for this. >> >> (for everyone else on the 2.2 list wondering why you just got >> blitzkrieged with a whole pile of emails on this topic: the >> listserver >> sent all these mails to moderation because of the lengthy CC list. >> IU >> just approved all the mails to go through this morning) >> >> >> On Apr 17, 2009, at 9:40 AM, William Gropp wrote: >> >> > Yes, this is worth an ATI - the fact that we traded this much >> mail on >> > it is proof of that :) >> > >> > Thanks, Jeff. >> > >> > Bill >> > >> > On Apr 17, 2009, at 8:14 AM, Jeff Squyres wrote: >> > >> > > Someone pointed out to me this morning that there's no >> restriction >> > on >> > > the value of EXTRA_STATE when CREATE_KEYVAL is invoked -- it may >> > be an >> > > expression, for example. I think that pretty much seals the deal >> > that >> > > #2 is the correct way. >> > > >> > > I think that this is worth an ATI in the text; does anyone >> disagree? >> > > I volunteer to write it up/make a 3.0 ticket (hey, first ticket >> for >> > > the Misc WG! :-) ) if no one disagrees. >> > > >> > > >> > > On Apr 17, 2009, at 8:59 AM, Supalov, Alexander wrote: >> > > >> > >> Hi, >> > >> >> > >> Intel MPI (and most likely other MPICH2 derivatives) appears >> to use >> > >> method #2. >> > >> >> > >> Best regards. >> > >> >> > >> Alexander >> > >> >> > >> -----Original Message----- >> > >> From: Jeff Squyres [mailto:jsquyres_at_[hidden]] >> > >> Sent: Thursday, April 16, 2009 4:19 PM >> > >> To: MPI 2.2; Rajeev Thakur; William Gropp; Rolf Rabenseifner; >> > Hubert >> > >> Ritzdorf; Terry Dontje; Dave Goodell; Darius Buntinas; Pavan >> > Balaji; >> > >> Supalov, Alexander; Bronis de Supinski; David Solt; Hans >> Westgaard >> > >> Ry; Håkon Bugge >> > >> Subject: Another MPI-2.2 attribute ambiguity? >> > >> >> > >> 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 >> > >> >> > >> >> > >> --------------------------------------------------------------------- >> > >> 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. >> > >> >> > >> >> > > >> > > >> > > -- >> > > Jeff Squyres >> > > Cisco Systems >> > > >> > >> > 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 >> > >> > >> > >> > >> >> >> -- >> Jeff Squyres >> Cisco Systems >> >> >> _______________________________________________ >> 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 -- Jeff Squyres Cisco Systems From wgropp at [hidden] Tue May 19 12:16:17 2009 From: wgropp at [hidden] (William Gropp) Date: Tue, 19 May 2009 12:16:17 -0500 Subject: [Mpi-22] Another MPI-2.2 attribute ambiguity? In-Reply-To: <0036D9F3-9421-4EF3-8119-16ECD8A480AC@cisco.com> Message-ID: <626A5D3B-CD9C-4972-82BB-77DB0ABCFC14@illinois.edu> MPICH2 passes the value of the extra_state that was saved in the internal storage to the callback routine, which is case 2 (the copy is implicit as the value is passed to the routine and C semantics ensures that the value isn't changed). Bill On May 18, 2009, at 10:24 AM, Jeff Squyres wrote: > I'm most curious to know what current MPI implementations do in this > scenario. > > > On May 14, 2009, at 1:05 PM, Jeff Squyres wrote: > >> Another question about this issue... >> >> Since all fortran values are passed by reference, does the MPI care >> if the callback function changes the EXTRA_STATE value? I see 2 >> choices: >> >> 1. The MPI copies the value of extra_state when MPI_*_CREATE_KEVAL >> is invoked to internal storage. This internal storage is passed to >> all the callbacks when invoked. If any of the callbacks change the >> value, then subsequent invocations of the callback get the changed >> value. >> >> 2. The MPI copies the value of extra_state when MPI_*_CREATE_KEVAL >> is invoked to internal storage. This internal storage is copied any >> time a callback is invoked; the copy is passed to the callback (and >> freed when the callback returns). In this way, the same EXTRA_STATE >> value that was originally passed to the keyval constructor will >> always be passed to any callbacks. >> >> What do current MPI implementations do? >> >> OMPI's development trunk has been updated to do #1; I'm wondering if >> it should do #2. >> >> >> >> On Apr 17, 2009, at 10:21 AM, Jeff Squyres (jsquyres) wrote: >> >>> Ok, I'll file an MPI-3 ticket for this. >>> >>> (for everyone else on the 2.2 list wondering why you just got >>> blitzkrieged with a whole pile of emails on this topic: the >>> listserver >>> sent all these mails to moderation because of the lengthy CC list. >>> IU >>> just approved all the mails to go through this morning) >>> >>> >>> On Apr 17, 2009, at 9:40 AM, William Gropp wrote: >>> >>>> Yes, this is worth an ATI - the fact that we traded this much >>> mail on >>>> it is proof of that :) >>>> >>>> Thanks, Jeff. >>>> >>>> Bill >>>> >>>> On Apr 17, 2009, at 8:14 AM, Jeff Squyres wrote: >>>> >>>>> Someone pointed out to me this morning that there's no >>> restriction >>>> on >>>>> the value of EXTRA_STATE when CREATE_KEYVAL is invoked -- it may >>>> be an >>>>> expression, for example. I think that pretty much seals the deal >>>> that >>>>> #2 is the correct way. >>>>> >>>>> I think that this is worth an ATI in the text; does anyone >>> disagree? >>>>> I volunteer to write it up/make a 3.0 ticket (hey, first ticket >>> for >>>>> the Misc WG! :-) ) if no one disagrees. >>>>> >>>>> >>>>> On Apr 17, 2009, at 8:59 AM, Supalov, Alexander wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> Intel MPI (and most likely other MPICH2 derivatives) appears >>> to use >>>>>> method #2. >>>>>> >>>>>> Best regards. >>>>>> >>>>>> Alexander >>>>>> >>>>>> -----Original Message----- >>>>>> From: Jeff Squyres [mailto:jsquyres_at_[hidden]] >>>>>> Sent: Thursday, April 16, 2009 4:19 PM >>>>>> To: MPI 2.2; Rajeev Thakur; William Gropp; Rolf Rabenseifner; >>>> Hubert >>>>>> Ritzdorf; Terry Dontje; Dave Goodell; Darius Buntinas; Pavan >>>> Balaji; >>>>>> Supalov, Alexander; Bronis de Supinski; David Solt; Hans >>> Westgaard >>>>>> Ry; Håkon Bugge >>>>>> Subject: Another MPI-2.2 attribute ambiguity? >>>>>> >>>>>> 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 >>>>>> >>>>>> >>>> >>> --------------------------------------------------------------------- >>>>>> 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. >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Jeff Squyres >>>>> Cisco Systems >>>>> >>>> >>>> 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 >>>> >>>> >>>> >>>> >>> >>> >>> -- >>> Jeff Squyres >>> Cisco Systems >>> >>> >>> _______________________________________________ >>> 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 > > > -- > 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 From wgropp at [hidden] Tue May 19 15:39:18 2009 From: wgropp at [hidden] (William Gropp) Date: Tue, 19 May 2009 15:39:18 -0500 Subject: [Mpi-22] Another MPI-2.2 attribute ambiguity? In-Reply-To: <88646F38-A594-4DDC-8772-09BFEBF74A19@Sun.COM> Message-ID: Silly me, I missed that. In Fortran (particularly thinking in terms of Fortran 77, since that was the original design), the Fortran callback should be able to do things like increment the "extra data" - i.e., if the extra data is a counter, the Fortran callback should be able to increment it. Since Fortran 77 has no pointers (and pointers in Fortran 90 aren't the same as addresses), having an address is worthless in a Fortran 77 program. So if the MPI implementation stores the address of the extra data and passes that to the call back (by value, so Fortran sees the address of the extra data), users should get what they expect in Fortran. Bill On May 19, 2009, at 12:22 PM, Iain Bason wrote: > > On May 19, 2009, at 1:16 PM, William Gropp wrote: > >> MPICH2 passes the value of the extra_state that was saved in the >> internal storage to the callback routine, which is case 2 (the copy >> is implicit as the value is passed to the routine and C semantics >> ensures that the value isn't changed). > > But this is the Fortran interface, not the C interface. > > Iain > 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 From jsquyres at [hidden] Tue May 19 19:55:01 2009 From: jsquyres at [hidden] (Jeff Squyres) Date: Tue, 19 May 2009 20:55:01 -0400 Subject: [Mpi-22] Another MPI-2.2 attribute ambiguity? In-Reply-To: Message-ID: So then you're in favor of #1 from my original post, right? http://lists.mpi-forum.org/mpi-22/2009/05/0407.php On May 19, 2009, at 4:39 PM, William Gropp wrote: > Silly me, I missed that. > > In Fortran (particularly thinking in terms of Fortran 77, since that > was the original design), the Fortran callback should be able to do > things like increment the "extra data" - i.e., if the extra data is a > counter, the Fortran callback should be able to increment it. Since > Fortran 77 has no pointers (and pointers in Fortran 90 aren't the same > as addresses), having an address is worthless in a Fortran 77 > program. So if the MPI implementation stores the address of the extra > data and passes that to the call back (by value, so Fortran sees the > address of the extra data), users should get what they expect in > Fortran. > > Bill > > On May 19, 2009, at 12:22 PM, Iain Bason wrote: > > > > > On May 19, 2009, at 1:16 PM, William Gropp wrote: > > > >> MPICH2 passes the value of the extra_state that was saved in the > >> internal storage to the callback routine, which is case 2 (the copy > >> is implicit as the value is passed to the routine and C semantics > >> ensures that the value isn't changed). > > > > But this is the Fortran interface, not the C interface. > > > > Iain > > > > 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 From jsquyres at [hidden] Wed May 20 09:53:52 2009 From: jsquyres at [hidden] (Jeff Squyres) Date: Wed, 20 May 2009 10:53:52 -0400 Subject: [Mpi-22] Another MPI-2.2 attribute ambiguity? In-Reply-To: Message-ID: <5FD0FE23-BE81-43E1-B98C-727ACF61589D@cisco.com> On May 19, 2009, at 8:55 PM, Jeff Squyres (jsquyres) wrote: > So then you're in favor of #1 from my original post, right? > > http://lists.mpi-forum.org/mpi-22/2009/05/0407.php > To be even more clear: - Open MPI's upcoming v1.3.3 currently does #1 - Platform (Scali) MPI does #1 - HP MPI does #2 - I *think* MPICH2 is doing #1 (Bill's text can be interpreted 2 ways, but we already discussed that it's not valid to keep the address of the value passed through MPI_*_CREATE_KEYVAL) - Alexander said that Intel MPI does the same thing as Bill's original reply, but I'm not sure what that means (because Bill's original reply was about C) I don't know what IBM MPI, NEC MPI, or others do (I assume MS MPI and MVAPICH do the same thing as MPICH2). > On May 19, 2009, at 4:39 PM, William Gropp wrote: > > > Silly me, I missed that. > > > > In Fortran (particularly thinking in terms of Fortran 77, since that > > was the original design), the Fortran callback should be able to do > > things like increment the "extra data" - i.e., if the extra data > is a > > counter, the Fortran callback should be able to increment it. Since > > Fortran 77 has no pointers (and pointers in Fortran 90 aren't the > same > > as addresses), having an address is worthless in a Fortran 77 > > program. So if the MPI implementation stores the address of the > extra > > data and passes that to the call back (by value, so Fortran sees the > > address of the extra data), users should get what they expect in > > Fortran. > > > > Bill > > > > On May 19, 2009, at 12:22 PM, Iain Bason wrote: > > > > > > > > On May 19, 2009, at 1:16 PM, William Gropp wrote: > > > > > >> MPICH2 passes the value of the extra_state that was saved in the > > >> internal storage to the callback routine, which is case 2 (the > copy > > >> is implicit as the value is passed to the routine and C semantics > > >> ensures that the value isn't changed). > > > > > > But this is the Fortran interface, not the C interface. > > > > > > Iain > > > > > > > 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 > > _______________________________________________ > mpi-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 > -- Jeff Squyres Cisco Systems From jsquyres at [hidden] Wed May 20 12:33:50 2009 From: jsquyres at [hidden] (Jeff Squyres) Date: Wed, 20 May 2009 13:33:50 -0400 Subject: [Mpi-22] Another MPI-2.2 attribute ambiguity? In-Reply-To: <5FD0FE23-BE81-43E1-B98C-727ACF61589D@cisco.com> Message-ID: <980B5A87-7D71-4619-938C-66DF222D98EE@cisco.com> On May 20, 2009, at 10:53 AM, Jeff Squyres (jsquyres) wrote: > - Open MPI's upcoming v1.3.3 currently does #1 > - Platform (Scali) MPI does #1 > - HP MPI does #2 > - I *think* MPICH2 is doing #1 (Bill's text can be interpreted 2 ways, > but we already discussed that it's not valid to keep the address of > the value passed through MPI_*_CREATE_KEYVAL) > - Alexander said that Intel MPI does the same thing as Bill's original > reply, but I'm not sure what that means (because Bill's original reply > was about C) > - NEC MPI does #1. -- Jeff Squyres Cisco Systems From wgropp at [hidden] Thu May 21 15:41:37 2009 From: wgropp at [hidden] (William Gropp) Date: Thu, 21 May 2009 15:41:37 -0500 Subject: [Mpi-22] Another MPI-2.2 attribute ambiguity? In-Reply-To: Message-ID: I'm not sure what "change the value" means in #1. I think that you mean "if we interpret extra_data as a pointer to a Fortran data item, the MPI implementation will pass this pointer (by value) to the callback. If the callback stores through this pointer, then (naturally) the afore mentioned data item will be changed. If that's what #1 means, then yes, that's the right answer. Note that the extra_data could be a pointer to an array of arbitrary size, and the call back could update any part of the array. Saving a copy of what extra_data points at (is that what #2 is doing?) is going to be tricky, since you don't know the size of the thing to copy (without a lot of help from the compiler in Fortran). Bill On May 19, 2009, at 7:55 PM, Jeff Squyres wrote: > So then you're in favor of #1 from my original post, right? > > http://lists.mpi-forum.org/mpi-22/2009/05/0407.php > > > On May 19, 2009, at 4:39 PM, William Gropp wrote: > >> Silly me, I missed that. >> >> In Fortran (particularly thinking in terms of Fortran 77, since that >> was the original design), the Fortran callback should be able to do >> things like increment the "extra data" - i.e., if the extra data is a >> counter, the Fortran callback should be able to increment it. Since >> Fortran 77 has no pointers (and pointers in Fortran 90 aren't the >> same >> as addresses), having an address is worthless in a Fortran 77 >> program. So if the MPI implementation stores the address of the >> extra >> data and passes that to the call back (by value, so Fortran sees the >> address of the extra data), users should get what they expect in >> Fortran. >> >> Bill >> >> On May 19, 2009, at 12:22 PM, Iain Bason wrote: >> >>> >>> On May 19, 2009, at 1:16 PM, William Gropp wrote: >>> >>>> MPICH2 passes the value of the extra_state that was saved in the >>>> internal storage to the callback routine, which is case 2 (the copy >>>> is implicit as the value is passed to the routine and C semantics >>>> ensures that the value isn't changed). >>> >>> But this is the Fortran interface, not the C interface. >>> >>> Iain >>> >> >> 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 > > _______________________________________________ > 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 From jsquyres at [hidden] Fri May 22 07:39:01 2009 From: jsquyres at [hidden] (Jeff Squyres) Date: Fri, 22 May 2009 08:39:01 -0400 Subject: [Mpi-22] Another MPI-2.2 attribute ambiguity? In-Reply-To: Message-ID: Imagine a Fortran communicator keyval copy function callback like this (typed off the top of my head; pardon typos): SUBROUTINE COPY_FUNCTION1(OLDCOMM, KEYVAL, EXTRA_STATE, AVALIN, AVALOUT, FLAG, IERR) ... INTEGER EXTRA_STATE INTEGER IERR EXTRA_STATE = EXTRA_STATE + 1 WRITE *, "Extra state is: ", EXTRA_STATE IERR = MPI_SUCCESS END Now suppose MPI_COMM_CREATE_KEYVAL is invoked like this: INTEGER EV = 7 CALL MPI_COMM_KEYVAL_CREATE(COPY_FUNCTION1, ..., EV, IERR) I think we all agree that the output the first time that COPY_FUNCTION1 is invoked should be 7. But what is the output the second time it is invoked -- 7 or 8? That is the question. I think Iain has conclusively show that in this case: INTEGER EV = 7 CALL MPI_COMM_KEYVAL_CREATE(COPY_FUNCTION1, ..., EV + 3, IERR) EV = 42 the output from the first call to COPY_FUNCTION1 still needs to be 10. The point is that the MPI implementation needs to *copy* the INTEGER value into internal storage and use *that* storage when calling COPY_FUNCTION1. If for no other reason than the value may be the result of an expression, and that storage disappears after the call to MPI_COMM_KEYVAL_CREATE completes (as in the above example). I'm not sure what you're referring to with the array stuff -- the Fortran prototype for the callback function says that the extra value can only be a single INTEGER...? On May 21, 2009, at 4:41 PM, William Gropp wrote: > I'm not sure what "change the value" means in #1. I think that you > mean "if we interpret extra_data as a pointer to a Fortran data item, > the MPI implementation will pass this pointer (by value) to the > callback. If the callback stores through this pointer, then > (naturally) the afore mentioned data item will be changed. If that's > what #1 means, then yes, that's the right answer. Note that the > extra_data could be a pointer to an array of arbitrary size, and the > call back could update any part of the array. Saving a copy of what > extra_data points at (is that what #2 is doing?) is going to be > tricky, since you don't know the size of the thing to copy (without a > lot of help from the compiler in Fortran). > > Bill > > On May 19, 2009, at 7:55 PM, Jeff Squyres wrote: > > > So then you're in favor of #1 from my original post, right? > > > > http://lists.mpi-forum.org/mpi-22/2009/05/0407.php > > > > > > On May 19, 2009, at 4:39 PM, William Gropp wrote: > > > >> Silly me, I missed that. > >> > >> In Fortran (particularly thinking in terms of Fortran 77, since > that > >> was the original design), the Fortran callback should be able to do > >> things like increment the "extra data" - i.e., if the extra data > is a > >> counter, the Fortran callback should be able to increment it. > Since > >> Fortran 77 has no pointers (and pointers in Fortran 90 aren't the > >> same > >> as addresses), having an address is worthless in a Fortran 77 > >> program. So if the MPI implementation stores the address of the > >> extra > >> data and passes that to the call back (by value, so Fortran sees > the > >> address of the extra data), users should get what they expect in > >> Fortran. > >> > >> Bill > >> > >> On May 19, 2009, at 12:22 PM, Iain Bason wrote: > >> > >>> > >>> On May 19, 2009, at 1:16 PM, William Gropp wrote: > >>> > >>>> MPICH2 passes the value of the extra_state that was saved in the > >>>> internal storage to the callback routine, which is case 2 (the > copy > >>>> is implicit as the value is passed to the routine and C semantics > >>>> ensures that the value isn't changed). > >>> > >>> But this is the Fortran interface, not the C interface. > >>> > >>> Iain > >>> > >> > >> 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 > > > > _______________________________________________ > > 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 From wgropp at [hidden] Fri May 22 09:08:20 2009 From: wgropp at [hidden] (William Gropp) Date: Fri, 22 May 2009 09:08:20 -0500 Subject: [Mpi-22] Another MPI-2.2 attribute ambiguity? In-Reply-To: Message-ID: <452B79CB-D849-4FC0-8D19-8EE0B274B8F3@illinois.edu> Remember, the primary definition of the MPI routine is the language- neutral form. That specifies a pointer to some extra state, but does says nothing about the size of the data to which that points. I'm *sure* that the intention of the language-neutral design was that extra state would often be either null or a pointer to a structure containing more than one item; the Fortran equivalent to this is an array. In Fortran 77, there is no way to specify what in C is a void pointer, so the binding says "pass an address-sized integer" (e.g., something that could be a pointer) and hope for the best. The point about expressions being passed also applies to C - if you pass, as extra state, an address to data that may go out of scope, you have a similar problem to passing an expression as extra state in Fortran. More specifically, it is already the case that everything which is syntactically allowed is not semantically allowed. Just because it will compile doesn't make it correct MPI code. There is certainly ambiguity here. My preference is to start with the intent of the language neutral specification and make that work. That may require additional advice to users and implementors about what is valid and what is invalid (note that expressions are semantically invalid in other places, such as buffers to the non-blocking routines in Fortran). Bill On May 22, 2009, at 7:39 AM, Jeff Squyres wrote: > Imagine a Fortran communicator keyval copy function callback like this > (typed off the top of my head; pardon typos): > > SUBROUTINE COPY_FUNCTION1(OLDCOMM, KEYVAL, EXTRA_STATE, AVALIN, > AVALOUT, FLAG, IERR) > ... > INTEGER EXTRA_STATE > INTEGER IERR > EXTRA_STATE = EXTRA_STATE + 1 > WRITE *, "Extra state is: ", EXTRA_STATE > IERR = MPI_SUCCESS > END > > Now suppose MPI_COMM_CREATE_KEYVAL is invoked like this: > > INTEGER EV = 7 > CALL MPI_COMM_KEYVAL_CREATE(COPY_FUNCTION1, ..., EV, IERR) > > I think we all agree that the output the first time that > COPY_FUNCTION1 is invoked should be 7. But what is the output the > second time it is invoked -- 7 or 8? That is the question. > > I think Iain has conclusively show that in this case: > > INTEGER EV = 7 > CALL MPI_COMM_KEYVAL_CREATE(COPY_FUNCTION1, ..., EV + 3, IERR) > EV = 42 > > the output from the first call to COPY_FUNCTION1 still needs to be 10. > > The point is that the MPI implementation needs to *copy* the INTEGER > value into internal storage and use *that* storage when calling > COPY_FUNCTION1. If for no other reason than the value may be the > result of an expression, and that storage disappears after the call to > MPI_COMM_KEYVAL_CREATE completes (as in the above example). > > I'm not sure what you're referring to with the array stuff -- the > Fortran prototype for the callback function says that the extra value > can only be a single INTEGER...? > > > > On May 21, 2009, at 4:41 PM, William Gropp wrote: > >> I'm not sure what "change the value" means in #1. I think that you >> mean "if we interpret extra_data as a pointer to a Fortran data item, >> the MPI implementation will pass this pointer (by value) to the >> callback. If the callback stores through this pointer, then >> (naturally) the afore mentioned data item will be changed. If that's >> what #1 means, then yes, that's the right answer. Note that the >> extra_data could be a pointer to an array of arbitrary size, and the >> call back could update any part of the array. Saving a copy of what >> extra_data points at (is that what #2 is doing?) is going to be >> tricky, since you don't know the size of the thing to copy (without a >> lot of help from the compiler in Fortran). >> >> Bill >> >> On May 19, 2009, at 7:55 PM, Jeff Squyres wrote: >> >>> So then you're in favor of #1 from my original post, right? >>> >>> http://lists.mpi-forum.org/mpi-22/2009/05/0407.php >>> >>> >>> On May 19, 2009, at 4:39 PM, William Gropp wrote: >>> >>>> Silly me, I missed that. >>>> >>>> In Fortran (particularly thinking in terms of Fortran 77, since >> that >>>> was the original design), the Fortran callback should be able to do >>>> things like increment the "extra data" - i.e., if the extra data >> is a >>>> counter, the Fortran callback should be able to increment it. >> Since >>>> Fortran 77 has no pointers (and pointers in Fortran 90 aren't the >>>> same >>>> as addresses), having an address is worthless in a Fortran 77 >>>> program. So if the MPI implementation stores the address of the >>>> extra >>>> data and passes that to the call back (by value, so Fortran sees >> the >>>> address of the extra data), users should get what they expect in >>>> Fortran. >>>> >>>> Bill >>>> >>>> On May 19, 2009, at 12:22 PM, Iain Bason wrote: >>>> >>>>> >>>>> On May 19, 2009, at 1:16 PM, William Gropp wrote: >>>>> >>>>>> MPICH2 passes the value of the extra_state that was saved in the >>>>>> internal storage to the callback routine, which is case 2 (the >> copy >>>>>> is implicit as the value is passed to the routine and C semantics >>>>>> ensures that the value isn't changed). >>>>> >>>>> But this is the Fortran interface, not the C interface. >>>>> >>>>> Iain >>>>> >>>> >>>> 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 >>> >>> _______________________________________________ >>> 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 > > _______________________________________________ > 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 From jsquyres at [hidden] Fri May 22 09:51:27 2009 From: jsquyres at [hidden] (Jeff Squyres) Date: Fri, 22 May 2009 10:51:27 -0400 Subject: [Mpi-22] Another MPI-2.2 attribute ambiguity? In-Reply-To: <452B79CB-D849-4FC0-8D19-8EE0B274B8F3@illinois.edu> Message-ID: Bill and I chatted on the phone a bit -- this is rapidly evolving into a complex issue. :-) Let me chat with Iain about this a bit more and get back to the group -- this may turn into a topic of discussion at the next Forum meeting. On May 22, 2009, at 10:08 AM, William Gropp wrote: > Remember, the primary definition of the MPI routine is the language- > neutral form. That specifies a pointer to some extra state, but does > says nothing about the size of the data to which that points. I'm > *sure* that the intention of the language-neutral design was that > extra state would often be either null or a pointer to a structure > containing more than one item; the Fortran equivalent to this is an > array. In Fortran 77, there is no way to specify what in C is a void > pointer, so the binding says "pass an address-sized integer" (e.g., > something that could be a pointer) and hope for the best. > > The point about expressions being passed also applies to C - if you > pass, as extra state, an address to data that may go out of scope, you > have a similar problem to passing an expression as extra state in > Fortran. More specifically, it is already the case that everything > which is syntactically allowed is not semantically allowed. Just > because it will compile doesn't make it correct MPI code. > > There is certainly ambiguity here. My preference is to start with the > intent of the language neutral specification and make that work. That > may require additional advice to users and implementors about what is > valid and what is invalid (note that expressions are semantically > invalid in other places, such as buffers to the non-blocking routines > in Fortran). > > Bill > > On May 22, 2009, at 7:39 AM, Jeff Squyres wrote: > > > Imagine a Fortran communicator keyval copy function callback like > this > > (typed off the top of my head; pardon typos): > > > > SUBROUTINE COPY_FUNCTION1(OLDCOMM, KEYVAL, EXTRA_STATE, > AVALIN, > > AVALOUT, FLAG, IERR) > > ... > > INTEGER EXTRA_STATE > > INTEGER IERR > > EXTRA_STATE = EXTRA_STATE + 1 > > WRITE *, "Extra state is: ", EXTRA_STATE > > IERR = MPI_SUCCESS > > END > > > > Now suppose MPI_COMM_CREATE_KEYVAL is invoked like this: > > > > INTEGER EV = 7 > > CALL MPI_COMM_KEYVAL_CREATE(COPY_FUNCTION1, ..., EV, IERR) > > > > I think we all agree that the output the first time that > > COPY_FUNCTION1 is invoked should be 7. But what is the output the > > second time it is invoked -- 7 or 8? That is the question. > > > > I think Iain has conclusively show that in this case: > > > > INTEGER EV = 7 > > CALL MPI_COMM_KEYVAL_CREATE(COPY_FUNCTION1, ..., EV + 3, IERR) > > EV = 42 > > > > the output from the first call to COPY_FUNCTION1 still needs to be > 10. > > > > The point is that the MPI implementation needs to *copy* the INTEGER > > value into internal storage and use *that* storage when calling > > COPY_FUNCTION1. If for no other reason than the value may be the > > result of an expression, and that storage disappears after the > call to > > MPI_COMM_KEYVAL_CREATE completes (as in the above example). > > > > I'm not sure what you're referring to with the array stuff -- the > > Fortran prototype for the callback function says that the extra > value > > can only be a single INTEGER...? > > > > > > > > On May 21, 2009, at 4:41 PM, William Gropp wrote: > > > >> I'm not sure what "change the value" means in #1. I think that you > >> mean "if we interpret extra_data as a pointer to a Fortran data > item, > >> the MPI implementation will pass this pointer (by value) to the > >> callback. If the callback stores through this pointer, then > >> (naturally) the afore mentioned data item will be changed. If > that's > >> what #1 means, then yes, that's the right answer. Note that the > >> extra_data could be a pointer to an array of arbitrary size, and > the > >> call back could update any part of the array. Saving a copy of what > >> extra_data points at (is that what #2 is doing?) is going to be > >> tricky, since you don't know the size of the thing to copy > (without a > >> lot of help from the compiler in Fortran). > >> > >> Bill > >> > >> On May 19, 2009, at 7:55 PM, Jeff Squyres wrote: > >> > >>> So then you're in favor of #1 from my original post, right? > >>> > >>> http://lists.mpi-forum.org/mpi-22/2009/05/0407.php > >>> > >>> > >>> On May 19, 2009, at 4:39 PM, William Gropp wrote: > >>> > >>>> Silly me, I missed that. > >>>> > >>>> In Fortran (particularly thinking in terms of Fortran 77, since > >> that > >>>> was the original design), the Fortran callback should be able > to do > >>>> things like increment the "extra data" - i.e., if the extra data > >> is a > >>>> counter, the Fortran callback should be able to increment it. > >> Since > >>>> Fortran 77 has no pointers (and pointers in Fortran 90 aren't the > >>>> same > >>>> as addresses), having an address is worthless in a Fortran 77 > >>>> program. So if the MPI implementation stores the address of the > >>>> extra > >>>> data and passes that to the call back (by value, so Fortran sees > >> the > >>>> address of the extra data), users should get what they expect in > >>>> Fortran. > >>>> > >>>> Bill > >>>> > >>>> On May 19, 2009, at 12:22 PM, Iain Bason wrote: > >>>> > >>>>> > >>>>> On May 19, 2009, at 1:16 PM, William Gropp wrote: > >>>>> > >>>>>> MPICH2 passes the value of the extra_state that was saved in > the > >>>>>> internal storage to the callback routine, which is case 2 (the > >> copy > >>>>>> is implicit as the value is passed to the routine and C > semantics > >>>>>> ensures that the value isn't changed). > >>>>> > >>>>> But this is the Fortran interface, not the C interface. > >>>>> > >>>>> Iain > >>>>> > >>>> > >>>> 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 > >>> > >>> _______________________________________________ > >>> 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 > > > > _______________________________________________ > > 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 From Iain.Bason at [hidden] Thu May 14 12:33:33 2009 From: Iain.Bason at [hidden] (Iain Bason) Date: Thu, 14 May 2009 13:33:33 -0400 Subject: [Mpi-22] Another MPI-2.2 attribute ambiguity? In-Reply-To: Message-ID: On May 14, 2009, at 1:05 PM, Jeff Squyres wrote: > Another question about this issue... > > Since all fortran values are passed by reference, does the MPI care > if the callback function changes the EXTRA_STATE value? I see 2 > choices: > > 1. The MPI copies the value of extra_state when MPI_*_CREATE_KEVAL > is invoked to internal storage. This internal storage is passed to > all the callbacks when invoked. If any of the callbacks change the > value, then subsequent invocations of the callback get the changed > value. > > 2. The MPI copies the value of extra_state when MPI_*_CREATE_KEVAL > is invoked to internal storage. This internal storage is copied any > time a callback is invoked; the copy is passed to the callback (and > freed when the callback returns). In this way, the same EXTRA_STATE > value that was originally passed to the keyval constructor will > always be passed to any callbacks. > > What do current MPI implementations do? > > OMPI's development trunk has been updated to do #1; I'm wondering if > it should do #2. I wondered about that too. I don't think that the Fortran standard has anything to say about it, so it's really a matter of what would be most useful to MPI users. Of course, if the MPI spec said that EXTRA_STATE was INTENT(IN) then there would be no ambiguity. Iain From Iain.Bason at [hidden] Tue May 19 12:22:45 2009 From: Iain.Bason at [hidden] (Iain Bason) Date: Tue, 19 May 2009 13:22:45 -0400 Subject: [Mpi-22] Another MPI-2.2 attribute ambiguity? In-Reply-To: <626A5D3B-CD9C-4972-82BB-77DB0ABCFC14@illinois.edu> Message-ID: <88646F38-A594-4DDC-8772-09BFEBF74A19@Sun.COM> On May 19, 2009, at 1:16 PM, William Gropp wrote: > MPICH2 passes the value of the extra_state that was saved in the > internal storage to the callback routine, which is case 2 (the copy > is implicit as the value is passed to the routine and C semantics > ensures that the value isn't changed). But this is the Fortran interface, not the C interface. Iain From jsquyres at [hidden] Tue May 26 11:47:06 2009 From: jsquyres at [hidden] (Jeff Squyres) Date: Tue, 26 May 2009 12:47:06 -0400 Subject: [Mpi-22] Another MPI-2.2 attribute ambiguity? In-Reply-To: Message-ID: <90879B63-989F-4FFC-AE6B-871B5154E9BB@cisco.com> This got even more complex when I talked to Iain on the phone. We're going to move this conversation to the MPI Fortran working group list (mpi3-fortran). In case you didn't catch it before, this is quite definitely an MPI-3 item. On May 22, 2009, at 10:51 AM, Jeff Squyres wrote: > Bill and I chatted on the phone a bit -- this is rapidly evolving > into a complex issue. :-) > > Let me chat with Iain about this a bit more and get back to the > group -- this may turn into a topic of discussion at the next Forum > meeting. > > > On May 22, 2009, at 10:08 AM, William Gropp wrote: > >> Remember, the primary definition of the MPI routine is the language- >> neutral form. That specifies a pointer to some extra state, but does >> says nothing about the size of the data to which that points. I'm >> *sure* that the intention of the language-neutral design was that >> extra state would often be either null or a pointer to a structure >> containing more than one item; the Fortran equivalent to this is an >> array. In Fortran 77, there is no way to specify what in C is a void >> pointer, so the binding says "pass an address-sized integer" (e.g., >> something that could be a pointer) and hope for the best. >> >> The point about expressions being passed also applies to C - if you >> pass, as extra state, an address to data that may go out of scope, >> you >> have a similar problem to passing an expression as extra state in >> Fortran. More specifically, it is already the case that everything >> which is syntactically allowed is not semantically allowed. Just >> because it will compile doesn't make it correct MPI code. >> >> There is certainly ambiguity here. My preference is to start with >> the >> intent of the language neutral specification and make that work. >> That >> may require additional advice to users and implementors about what is >> valid and what is invalid (note that expressions are semantically >> invalid in other places, such as buffers to the non-blocking routines >> in Fortran). >> >> Bill >> >> On May 22, 2009, at 7:39 AM, Jeff Squyres wrote: >> >> > Imagine a Fortran communicator keyval copy function callback like >> this >> > (typed off the top of my head; pardon typos): >> > >> > SUBROUTINE COPY_FUNCTION1(OLDCOMM, KEYVAL, EXTRA_STATE, >> AVALIN, >> > AVALOUT, FLAG, IERR) >> > ... >> > INTEGER EXTRA_STATE >> > INTEGER IERR >> > EXTRA_STATE = EXTRA_STATE + 1 >> > WRITE *, "Extra state is: ", EXTRA_STATE >> > IERR = MPI_SUCCESS >> > END >> > >> > Now suppose MPI_COMM_CREATE_KEYVAL is invoked like this: >> > >> > INTEGER EV = 7 >> > CALL MPI_COMM_KEYVAL_CREATE(COPY_FUNCTION1, ..., EV, IERR) >> > >> > I think we all agree that the output the first time that >> > COPY_FUNCTION1 is invoked should be 7. But what is the output the >> > second time it is invoked -- 7 or 8? That is the question. >> > >> > I think Iain has conclusively show that in this case: >> > >> > INTEGER EV = 7 >> > CALL MPI_COMM_KEYVAL_CREATE(COPY_FUNCTION1, ..., EV + 3, >> IERR) >> > EV = 42 >> > >> > the output from the first call to COPY_FUNCTION1 still needs to >> be 10. >> > >> > The point is that the MPI implementation needs to *copy* the >> INTEGER >> > value into internal storage and use *that* storage when calling >> > COPY_FUNCTION1. If for no other reason than the value may be the >> > result of an expression, and that storage disappears after the >> call to >> > MPI_COMM_KEYVAL_CREATE completes (as in the above example). >> > >> > I'm not sure what you're referring to with the array stuff -- the >> > Fortran prototype for the callback function says that the extra >> value >> > can only be a single INTEGER...? >> > >> > >> > >> > On May 21, 2009, at 4:41 PM, William Gropp wrote: >> > >> >> I'm not sure what "change the value" means in #1. I think that >> you >> >> mean "if we interpret extra_data as a pointer to a Fortran data >> item, >> >> the MPI implementation will pass this pointer (by value) to the >> >> callback. If the callback stores through this pointer, then >> >> (naturally) the afore mentioned data item will be changed. If >> that's >> >> what #1 means, then yes, that's the right answer. Note that the >> >> extra_data could be a pointer to an array of arbitrary size, and >> the >> >> call back could update any part of the array. Saving a copy of >> what >> >> extra_data points at (is that what #2 is doing?) is going to be >> >> tricky, since you don't know the size of the thing to copy >> (without a >> >> lot of help from the compiler in Fortran). >> >> >> >> Bill >> >> >> >> On May 19, 2009, at 7:55 PM, Jeff Squyres wrote: >> >> >> >>> So then you're in favor of #1 from my original post, right? >> >>> >> >>> http://lists.mpi-forum.org/mpi-22/2009/05/0407.php >> >>> >> >>> >> >>> On May 19, 2009, at 4:39 PM, William Gropp wrote: >> >>> >> >>>> Silly me, I missed that. >> >>>> >> >>>> In Fortran (particularly thinking in terms of Fortran 77, since >> >> that >> >>>> was the original design), the Fortran callback should be able >> to do >> >>>> things like increment the "extra data" - i.e., if the extra data >> >> is a >> >>>> counter, the Fortran callback should be able to increment it. >> >> Since >> >>>> Fortran 77 has no pointers (and pointers in Fortran 90 aren't >> the >> >>>> same >> >>>> as addresses), having an address is worthless in a Fortran 77 >> >>>> program. So if the MPI implementation stores the address of the >> >>>> extra >> >>>> data and passes that to the call back (by value, so Fortran sees >> >> the >> >>>> address of the extra data), users should get what they expect in >> >>>> Fortran. >> >>>> >> >>>> Bill >> >>>> >> >>>> On May 19, 2009, at 12:22 PM, Iain Bason wrote: >> >>>> >> >>>>> >> >>>>> On May 19, 2009, at 1:16 PM, William Gropp wrote: >> >>>>> >> >>>>>> MPICH2 passes the value of the extra_state that was saved in >> the >> >>>>>> internal storage to the callback routine, which is case 2 (the >> >> copy >> >>>>>> is implicit as the value is passed to the routine and C >> semantics >> >>>>>> ensures that the value isn't changed). >> >>>>> >> >>>>> But this is the Fortran interface, not the C interface. >> >>>>> >> >>>>> Iain >> >>>>> >> >>>> >> >>>> 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 >> >>> >> >>> _______________________________________________ >> >>> 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 >> > >> > _______________________________________________ >> > 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 > > _______________________________________________ > mpi-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 -- Jeff Squyres Cisco Systems From treumann at [hidden] Wed May 27 08:52:58 2009 From: treumann at [hidden] (Richard Treumann) Date: Wed, 27 May 2009 09:52:58 -0400 Subject: [Mpi-22] The const proposal - Ticket 140 Message-ID: All - The signatories of this letter represent the majority of MPI implementors participating in the MPI Forum. We are concerned that proposal #140 ("Add const Keyword to the C bindings") has a number of issues which suggest delaying to MPI-3 would be appropriate. In particular, the proposal: - Is likely to pass a simple majority vote, but does not carry the support of the majority of MPI implementors, suggesting consensus has not been reached. - Changes 90+ MPI API interfaces, which is not a "trivial" change and therefore does not meet the intent of the MPI-2.2 process. - Is not needed to fix any serious bug in the standard text or to solve an issue that cannot easily be avoided by the MPI application. - Does not offer any demonstrable optimization opportunities for implementation or application, but may constrain future implementation opportunities. Therefore, we ask for your assistance in deferring proposal #140 to the MPI-3 process, where more time can be spent assessing its impact. Thank you, - Cisco: Jeff Squires - Intel: Alexander Supalov & Keith Underwood - Sandia: Brian Barrett - IBM: Richard Treumann - QLogic: Avneesh Pant - UTenn: George Bosilca - HP: David George Solt - UHouston: Edgar Gabriel - Myricom: Patrick Geoffray - ORNL: Richard Graham - Sun: Terry Dontje - NEC: Hubert Ritzdorf & Jesper Traeff 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 * -------------- next part -------------- An HTML attachment was scrubbed... URL: From erezh at [hidden] Wed May 27 12:48:28 2009 From: erezh at [hidden] (Erez Haba) Date: Wed, 27 May 2009 10:48:28 -0700 Subject: [Mpi-22] [Mpi-forum] The const proposal - Ticket 140 In-Reply-To: Message-ID: <6B68D01C00C9994A8E150183E62A119E819BEEBC40@NA-EXMSG-C105.redmond.corp.microsoft.com> Hi all, I'm not really sure how to respond to this email. I will just note that this proposal has passed 1st vote last September with the following results. 4. Vote topic: MPI-2.2 const for C bindings, 1st vote: YES: 17 NO: 4 ABSTAIN: 6 MISSED: 0 Result: Ballot passed http://meetings.mpi-forum.org/secretary/2008/09/votes.php ince then we decided to postpone the 1st vote to add very few minor correction to ticket #46 (the original proposal) and thus created ticket #140. I believe that all the points you mention below have been discussed in the forum meeting(s). Thanks, .Erez From: mpi-forum-bounces_at_[hidden] [mailto:mpi-forum-bounces_at_[hidden]] On Behalf Of Richard Treumann Sent: Wednesday, May 27, 2009 6:53 AM To: Main MPI Forum mailing list Cc: mpi-22_at_[hidden] Subject: [Mpi-forum] The const proposal - Ticket 140 All - The signatories of this letter represent the majority of MPI implementors participating in the MPI Forum. We are concerned that proposal #140 ("Add const Keyword to the C bindings") has a number of issues which suggest delaying to MPI-3 would be appropriate. In particular, the proposal: - Is likely to pass a simple majority vote, but does not carry the support of the majority of MPI implementors, suggesting consensus has not been reached. - Changes 90+ MPI API interfaces, which is not a "trivial" change and therefore does not meet the intent of the MPI-2.2 process. - Is not needed to fix any serious bug in the standard text or to solve an issue that cannot easily be avoided by the MPI application. - Does not offer any demonstrable optimization opportunities for implementation or application, but may constrain future implementation opportunities. Therefore, we ask for your assistance in deferring proposal #140 to the MPI-3 process, where more time can be spent assessing its impact. Thank you, - Cisco: Jeff Squires - Intel: Alexander Supalov & Keith Underwood - Sandia: Brian Barrett - IBM: Richard Treumann - QLogic: Avneesh Pant - UTenn: George Bosilca - HP: David George Solt - UHouston: Edgar Gabriel - Myricom: Patrick Geoffray - ORNL: Richard Graham - Sun: Terry Dontje - NEC: Hubert Ritzdorf & Jesper Traeff 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 * -------------- next part -------------- An HTML attachment was scrubbed... URL: From wgropp at [hidden] Wed May 27 13:37:23 2009 From: wgropp at [hidden] (William Gropp) Date: Wed, 27 May 2009 13:37:23 -0500 Subject: [Mpi-22] [Mpi-forum] The const proposal - Ticket 140 In-Reply-To: <6B68D01C00C9994A8E150183E62A119E819BEEBC40@NA-EXMSG-C105.redmond.corp.microsoft.com> Message-ID: <12B00F4B-6D9F-4292-8E72-08B0ACF054F9@illinois.edu> This is an example of why we have two votes - to give everyone a chance to take a second look at the issues. I'll note that the 17-10 (counting no's and abstains together) is worrisome; while a majority vote is the rule, a good standard will make a compelling argument for each feature. The process here would normally be to have a debate and then the second vote. However, for MPI 2.2, we have the additional requirements of limited scope of change to implementations - we didn't define what that meant precisely (and that is a good thing), but there is a strong argument that limited scope of change would require at least a majority of implementations to agree that the change is minor. Bill On May 27, 2009, at 12:48 PM, Erez Haba wrote: > Hi all, I’m not really sure how to respond to this email. I will > just note that this proposal has passed 1st vote last September with > the following results. > > 4. Vote topic: MPI-2.2 const for C bindings, 1st vote: > YES: > 17 > NO: > 4 > ABSTAIN: > 6 > MISSED: > 0 > Result: > Ballot passed > > http://meetings.mpi-forum.org/secretary/2008/09/votes.php > > since then we decided to postpone the 1st vote to add very few minor > correction to ticket #46 (the original proposal) and thus created > ticket #140. > > I believe that all the points you mention below have been discussed > in the forum meeting(s). > > Thanks, > .Erez > > From: mpi-forum-bounces_at_[hidden] [mailto:mpi-forum-bounces_at_[hidden] > ] On Behalf Of Richard Treumann > Sent: Wednesday, May 27, 2009 6:53 AM > To: Main MPI Forum mailing list > Cc: mpi-22_at_[hidden] > Subject: [Mpi-forum] The const proposal - Ticket 140 > > All - > > The signatories of this letter represent the majority of MPI > implementors participating in the MPI Forum. We are concerned that > proposal #140 ("Add const Keyword to the C bindings") has a number > of issues which suggest delaying to MPI-3 would be appropriate. > > In particular, the proposal: > > - Is likely to pass a simple majority vote, but does not carry the > support of the majority of MPI implementors, suggesting consensus > has not been reached. > - Changes 90+ MPI API interfaces, which is not a "trivial" change > and therefore does not meet the intent of the MPI-2.2 process. > - Is not needed to fix any serious bug in the standard text or to > solve an issue that cannot easily be avoided by the MPI application. > - Does not offer any demonstrable optimization opportunities for > implementation or application, but may constrain future > implementation opportunities. > > Therefore, we ask for your assistance in deferring proposal #140 to > the MPI-3 process, where more time can be spent assessing its impact. > > Thank you, > > - Cisco: Jeff Squires > - Intel: Alexander Supalov & Keith Underwood > - Sandia: Brian Barrett > - IBM: Richard Treumann > - QLogic: Avneesh Pant > - UTenn: George Bosilca > - HP: David George Solt > - UHouston: Edgar Gabriel > - Myricom: Patrick Geoffray > - ORNL: Richard Graham > - Sun: Terry Dontje > - NEC: Hubert Ritzdorf & Jesper Traeff > > > > 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 > > 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 * -------------- next part -------------- An HTML attachment was scrubbed... URL: From pashash at [hidden] Wed May 27 14:42:37 2009 From: pashash at [hidden] (Pavel Shamis Pasha) Date: Wed, 27 May 2009 22:42:37 +0300 Subject: [Mpi-22] [Mpi-forum] The const proposal - Ticket 140 In-Reply-To: Message-ID: <4A1D97AD.5000008@dev.mellanox.co.il> I would like to add Mellanox to the list of organizations that support this letter. Pasha. Richard Treumann wrote: > > All - > > The signatories of this letter represent the majority of MPI > implementors participating in the MPI Forum. We are concerned that > proposal #140 ("Add const Keyword to the C bindings") has a number of > issues which suggest delaying to MPI-3 would be appropriate. > > In particular, the proposal: > > - Is likely to pass a simple majority vote, but does not carry the > support of the majority of MPI implementors, suggesting consensus has > not been reached. > - Changes 90+ MPI API interfaces, which is not a "trivial" change and > therefore does not meet the intent of the MPI-2.2 process. > - Is not needed to fix any serious bug in the standard text or to > solve an issue that cannot easily be avoided by the MPI application. > - Does not offer any demonstrable optimization opportunities for > implementation or application, but may constrain future implementation > opportunities. > > Therefore, we ask for your assistance in deferring proposal #140 to > the MPI-3 process, where more time can be spent assessing its impact. > > Thank you, > > - Cisco: Jeff Squires > - Intel: Alexander Supalov & Keith Underwood > - Sandia: Brian Barrett > - IBM: Richard Treumann > - QLogic: Avneesh Pant > - UTenn: George Bosilca > - HP: David George Solt > - UHouston: Edgar Gabriel > - Myricom: Patrick Geoffray > - ORNL: Richard Graham > - Sun: Terry Dontje > - NEC: Hubert Ritzdorf & Jesper Traeff > > > > 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-forum mailing list > mpi-forum_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum >