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

Re: [Mpi-22] Another MPI-2.2 attribute ambiguity?
by unknown＠example.com 20 May '09

20 May '09

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

1 0

Re: [Mpi-22] Another MPI-2.2 attribute ambiguity?
by unknown＠example.com 19 May '09

19 May '09

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

1 0

Re: [Mpi-22] Another MPI-2.2 attribute ambiguity?
by unknown＠example.com 19 May '09

19 May '09

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

1 0

Re: [Mpi-22] Another MPI-2.2 attribute ambiguity?
by unknown＠example.com 19 May '09

19 May '09

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

1 0

Re: [Mpi-22] Another MPI-2.2 attribute ambiguity?
by unknown＠example.com 19 May '09

19 May '09

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

1 0

Re: [Mpi-22] Another MPI-2.2 attribute ambiguity?
by unknown＠example.com 18 May '09

18 May '09

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

1 0

Re: [Mpi-22] Another MPI-2.2 attribute ambiguity?
by unknown＠example.com 14 May '09

14 May '09

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

1 0

Re: [Mpi-22] Another MPI-2.2 attribute ambiguity?
by unknown＠example.com 14 May '09

14 May '09

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

1 0

Re: [Mpi-22] [MPI Forum] #117: Define a new MPI_Count Datatype
by unknown＠example.com 11 May '09

11 May '09

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: <https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/117#comment:38> MPI Forum <https://svn.mpi-forum.org/> MPI Forum

1 0