December 2013 - mpiwg-fortran - mailman3.cels.anl.gov

Re: [MPIWG Fortran] MPI-3 ticket 349: Fortran question
by Jim Dinan 24 Dec '13

24 Dec '13

Dave, Thanks for the detailed response, and for having a much better memory than me. :) Given that MPI_Aint will be at least the same size as ptrdiff_t, do we actually have a problem with subtracting MPI_Aints to find pointer diffs? It seems like this may actually be ok. ~Jim. On Fri, Dec 20, 2013 at 11:57 AM, Dave Goodell (dgoodell) < dgoodell(a)cisco.com> wrote: > [The previous version of this was held for moderation, so I subscribed and > disabled email delivery. If you want me to participate in this thread, > please keep me CCed.] > > On Dec 20, 2013, at 8:22 AM, Jim Dinan <james.dinan(a)gmail.com> wrote: > > > Jeff, > > > > I don't think that anyone is making an argument that is specific to 32b > > architectures. The concern is that the MPI standard currently requires: > > > > (1) a two's complement architecture where overflow/underflow of signed > > arithmetic on an unsigned quantity always results in the right unsigned > > value > > I think the hardware support for two's complement requirement is probably > not a major problem, since sign-and-magnitude and one's complement machines > seem unlikely to make a resurgence outside of some weird DSPs. Though the > C standard certainly supports all three representations, this aspect is > largely academic and not a real issue for the MPI community. > > The larger issue is that the C standard explicitly declares signed integer > arithmetic overflow to be undefined. There are two reasons this is a real > concern: > > A) Compilers really do perform optimizations related to signed integer > overflow: http://www.airs.com/blog/archives/120 > > B) Some platforms/compilers can/will trap on signed integer overflow, > e.g., GCC with "-ftrapv". > > > - OR - > > (2) an MPI_Aint type that is 2x the size of an address to ensure that > > overflow/underflow never occurs (because MPI_BOTTOM is an arbitrary > address > > in Fortran) > > > > Given that every system I know of falls into category (1) and there is a > > solution (2) for all other systems, I am not trying to recall why we felt > > that this problem needs to be solved through new arithmetic routines. I > > believe there was a concern that 128-bit integers are not standard and > not > > well supported by most languages/architectures, so (2) may not be a > > workable solution. Maybe Dave G [added to cc] remembers our rationale? > > Systems don't seem to have easily-used, portable language support for > >64-bit integer math right now. Even in C11 the largest minimum sizes are > only 64-bit; anything else is an extension or a choice to define "long > long" as larger. I just checked a 64-bit x86_64 Linux system here at Cisco > and couldn't find an obvious 128-bit signed integer type in a couple of > minutes of looking. > > Also, though the MPI_BOTTOM issue is annoying, it's irrelevant. There's > nothing to prevent an operating system from giving you an address with the > most significant bit set, so you have the problem even if MPI_BOTTOM==0 > everywhere. Indeed, I just saw a bug report fly by the other day with a > such an address (0xffffffff7d3ca461) on Solaris: > http://www.open-mpi.org/community/lists/users/2013/12/23149.php > > So I agree with Jim that (2) is not a workable solution. > > -Dave > >

1 0

Re: [MPIWG Fortran] MPI-3 ticket 349: Fortran question
by Dave Goodell (dgoodell) 20 Dec '13

20 Dec '13

[The previous version of this was held for moderation, so I subscribed and disabled email delivery. If you want me to participate in this thread, please keep me CCed.] On Dec 20, 2013, at 8:22 AM, Jim Dinan <james.dinan(a)gmail.com> wrote: > Jeff, > > I don't think that anyone is making an argument that is specific to 32b > architectures. The concern is that the MPI standard currently requires: > > (1) a two's complement architecture where overflow/underflow of signed > arithmetic on an unsigned quantity always results in the right unsigned > value I think the hardware support for two's complement requirement is probably not a major problem, since sign-and-magnitude and one's complement machines seem unlikely to make a resurgence outside of some weird DSPs. Though the C standard certainly supports all three representations, this aspect is largely academic and not a real issue for the MPI community. The larger issue is that the C standard explicitly declares signed integer arithmetic overflow to be undefined. There are two reasons this is a real concern: A) Compilers really do perform optimizations related to signed integer overflow: http://www.airs.com/blog/archives/120 B) Some platforms/compilers can/will trap on signed integer overflow, e.g., GCC with "-ftrapv". > - OR - > (2) an MPI_Aint type that is 2x the size of an address to ensure that > overflow/underflow never occurs (because MPI_BOTTOM is an arbitrary address > in Fortran) > > Given that every system I know of falls into category (1) and there is a > solution (2) for all other systems, I am not trying to recall why we felt > that this problem needs to be solved through new arithmetic routines. I > believe there was a concern that 128-bit integers are not standard and not > well supported by most languages/architectures, so (2) may not be a > workable solution. Maybe Dave G [added to cc] remembers our rationale? Systems don't seem to have easily-used, portable language support for >64-bit integer math right now. Even in C11 the largest minimum sizes are only 64-bit; anything else is an extension or a choice to define "long long" as larger. I just checked a 64-bit x86_64 Linux system here at Cisco and couldn't find an obvious 128-bit signed integer type in a couple of minutes of looking. Also, though the MPI_BOTTOM issue is annoying, it's irrelevant. There's nothing to prevent an operating system from giving you an address with the most significant bit set, so you have the problem even if MPI_BOTTOM==0 everywhere. Indeed, I just saw a bug report fly by the other day with a such an address (0xffffffff7d3ca461) on Solaris: http://www.open-mpi.org/community/lists/users/2013/12/23149.php So I agree with Jim that (2) is not a workable solution. -Dave

1 0

Re: [MPIWG Fortran] MPI-3 ticket 349: Fortran question
by Dave Goodell (dgoodell) 20 Dec '13

20 Dec '13

[not sure if my email will bounce from the fortran list, since I'm not subscribed] On Dec 20, 2013, at 8:22 AM, Jim Dinan <james.dinan(a)gmail.com> wrote: > Jeff, > > I don't think that anyone is making an argument that is specific to 32b > architectures. The concern is that the MPI standard currently requires: > > (1) a two's complement architecture where overflow/underflow of signed > arithmetic on an unsigned quantity always results in the right unsigned > value I think the hardware support for two's complement requirement is probably not a major problem, since sign-and-magnitude and one's complement machines seem unlikely to make a resurgence outside of some weird DSPs. Though the C standard certainly supports all three representations, this aspect is largely academic and not a real issue for the MPI community. The larger issue is that the C standard explicitly declares signed integer arithmetic overflow to be undefined. There are two reasons this is a real concern: A) Compilers really do perform optimizations related to signed integer overflow: http://www.airs.com/blog/archives/120 B) Some platforms/compilers can/will trap on signed integer overflow, e.g., GCC with "-ftrapv". > - OR - > (2) an MPI_Aint type that is 2x the size of an address to ensure that > overflow/underflow never occurs (because MPI_BOTTOM is an arbitrary address > in Fortran) > > Given that every system I know of falls into category (1) and there is a > solution (2) for all other systems, I am not trying to recall why we felt > that this problem needs to be solved through new arithmetic routines. I > believe there was a concern that 128-bit integers are not standard and not > well supported by most languages/architectures, so (2) may not be a > workable solution. Maybe Dave G [added to cc] remembers our rationale? Systems don't seem to have easily-used, portable language support for >64-bit integer math right now. Even in C11 the largest minimum sizes are only 64-bit; anything else is an extension or a choice to define "long long" as larger. I just checked a 64-bit x86_64 Linux system here at Cisco and couldn't find an obvious 128-bit signed integer type in a couple of minutes of looking. Also, though the MPI_BOTTOM issue is annoying, it's irrelevant. There's nothing to prevent an operating system from giving you an address with the most significant bit set, so you have the problem even if MPI_BOTTOM==0 everywhere. Indeed, I just saw a bug report fly by the other day with a such an address (0xffffffff7d3ca461) on Solaris: http://www.open-mpi.org/community/lists/users/2013/12/23149.php So I agree with Jim that (2) is not a workable solution. -Dave

1 0

Re: [MPIWG Fortran] MPI-3 ticket 349: Fortran question
by Bill Long 20 Dec '13

20 Dec '13

On 12/20/13 7:35 AM, Jeff Hammond wrote: > 32b Blue Gene is dead. We are turning ours off in 2 weeks. > > The only 32b arguments should be relevant to ARM and other cell phone parts that may run MPI some day. Even the iPhone 5S has an A7 (64-bit) ARM chip. 32b may be dead sooner that we expect. Cheers, Bill > > Jeff > > Sent from my iPhone > >> On Dec 20, 2013, at 5:04 AM, Rolf Rabenseifner <rabenseifner(a)hlrs.de> wrote: >> >> Hi Jim, >> >>> I don't think that the proposal is in conflict with sections 2.5.6 or >>> 4.1.5. These sections are talking about addresses and not >>> specifically about how one can use the MPI_Aint type. We mean to >>> address only the latter item -- correct usage of the MPI address >>> integer type. >> >> I also do not see a conflict. >> But I see that the new concept must be explained within these sections. >> This is about consistency of the whole MPI document. >> >>> In terms of where to put the proposed text in the chapter, I suggest >>> we make that a separate discussion, once the technical issues have >>> been resolved. >> >> As you mentioned below, >> technically there are two solutions: >> A. require that disp=addr2-addr1 and addr2=addr1+disp can be >> calculated with the intrinsic arithmetic operations - and +. >> This would require: >> 128 bit MPI_Aint on a system that >> - uses full 64 bit absolute addresses, AND >> - does not have one-s complement arithmetic AND >> - MPI_BOTTOM is not defined in the middle >> B. require that disp=addr2-addr1 and addr2=addr1+disp >> is calculated with your two new functions to guarantee >> that always 64 bits signed MPI_Aint are enough >> to store any 64 bit unsigned absolute addresses. >> >> If we decide A, then only an advice to implementers would be fine. >> If we decide B, then several "corrections" are needed. >> >>> I do have a concern, in particular, about section 4.1.12, "Correct >>> use of Addresses", which seems to suggest that one should be able to >>> do arithmetic directly on absolute addresses stored in address >>> integers. The only way that this could be supported on some >>> platforms (e.g. one's complement integers) is to make the MPI_Aint >>> an integer that is larger than an address, so that >>> overflow/underflow cannot occur. Because of Fortran's dynamic >>> MPI_BOTTOM, address integers on such a platform would have to be >>> 128-bits to ensure that there can be no overflow. >>> >>> What's your take on that section? >> >> The notations MPI-3.0 page 115 lines 42 and 47 v+i and u-v >> need not to be interpreted as C and Fortran + and -. >> >> One could say that there is a lack of not having defined >> these operations. >> >> I principle, you are right when you expect (as all MPI-readers so far) >> that + and - on these lines are C and Fortran + and -, >> and therefore, solution A is required. >> Note that solution A is not the worst because our systems have IEEE >> data representation which has one's complements and therefore no Need >> for doubling the size of MPI_Aint, especially on the pure 32-bit Blue-Gene >> Systems. >> >> If one wants to go with B (and this is a free Forum decision) >> then one should add text to >>> MPI-3.0 Sect. 2.5.6, page 16 lines 30-37 and >>> MPI-3.0 Sect. 4.1.5, page 102 lines 28-35 >> and also to >> - MPI 3.0 Sect. 4.1.12, page 115 line 48, e.g., >> "Note that v+i and u-v need to be calculated >> with MPI_AINT_ADD and MPI_AINT_DIFF." >> And the two new routines after page 103 line 46. >> >> My mails only try to help that proposal B is fully complete >> and consistent. >> They are not about whether I would like to have A or B. >> Because A continues to stay a work-around for B, >> I would be happy with B. >> >> Best regards >> Rolf >> >> >> ----- Original Message ----- >>> From: "Jim Dinan" <james.dinan(a)gmail.com> >>> To: "Rolf Rabenseifner" <rabenseifner(a)hlrs.de> >>> Cc: "MPI-WG Fortran working group" <mpiwg-fortran(a)lists.mpi-forum.org>, "longb" <longb(a)cray.com> >>> Sent: Thursday, December 19, 2013 9:55:42 PM >>> Subject: Re: [MPIWG Fortran] MPI-3 ticket 349: Fortran question >>> >>> >>> Hi Rolf, >>> >>> >>> I don't think that the proposal is in conflict with sections 2.5.6 or >>> 4.1.5. These sections are talking about addresses and not >>> specifically about how one can use the MPI_Aint type. We mean to >>> address only the latter item -- correct usage of the MPI address >>> integer type. >>> >>> >>> In terms of where to put the proposed text in the chapter, I suggest >>> we make that a separate discussion, once the technical issues have >>> been resolved. >>> >>> >>> I do have a concern, in particular, about section 4.1.12, "Correct >>> use of Addresses", which seems to suggest that one should be able to >>> do arithmetic directly on absolute addresses stored in address >>> integers. The only way that this could be supported on some >>> platforms (e.g. one's complement integers) is to make the MPI_Aint >>> an integer that is larger than an address, so that >>> overflow/underflow cannot occur. Because of Fortran's dynamic >>> MPI_BOTTOM, address integers on such a platform would have to be >>> 128-bits to ensure that there can be no overflow. >>> >>> >>> What's your take on that section? >>> >>> >>> ~Jim. >>> >>> >>> >>> On Fri, Dec 13, 2013 at 9:11 AM, Rolf Rabenseifner < >>> rabenseifner(a)hlrs.de > wrote: >>> >>> >>> Jim, >>> >>> >>>> Could you provide a list of the specific changes that you feel are >>>> needed on these tickets? >>> >>> I expected that you are doining this. >>> I only want to mention the locations. >>> >>> Your new model differentiates beween >>> - absolute addresses generated from locations with MPI_GET_ADDRESS >>> - relative displacements as differences of two absolute addresses >>> and the needed arithmetic >>> - relative displacements with normal + - * arithmetic >>> - absolute addresses and displacments with >>> MPI_AINT_ADD and MPI_AINT_DIFF arithmetic >>> >>> Therefore: >>> MPI-3.0 Sect. 2.5.6, page 16 lines 30-37 and >>> MPI-3.0 Sect. 4.1.5, page 102 lines 28-35 >>> should reflect this differentiation. >>> >>> The proposed rationale in #349 may go at the end of page 102 lines >>> 28-35. >>> After MPI-3.0 Sect. 4.1.5, page 103 line 46, you should add >>> MPI_AINT_ADD and MPI_AINT_DIFF. >>> >>> >>> Best regards >>> Rolf >>> >>> >>> >>> ----- Original Message ----- >>>> From: "Jim Dinan" < james.dinan(a)gmail.com > >>>> To: "Rolf Rabenseifner" < rabenseifner(a)hlrs.de > >>>> Cc: "MPI-WG Fortran working group" < >>>> mpiwg-fortran(a)lists.mpi-forum.org >, "longb" < longb(a)cray.com > >>> >>> >>>> Sent: Friday, December 13, 2013 1:35:13 PM >>>> Subject: Re: [MPIWG Fortran] MPI-3 ticket 349: Fortran question >>>> >>>> >>>> Rolf, >>>> >>>> >>>> Could you provide a list of the specific changes that you feel are >>>> needed on these tickets? For reference, and to bring in feedback >>>> from others on the cc, we are discussing: >>>> >>>> >>>> MPI_Aint_add -- >>>> https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/349 >>>> Linked list example updates -- >>>> https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/402 >>>> MPI_Aint_diff -- >>>> https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/404 >>>> >>>> >>>> Let's solve the technical issues first to see where things stand, >>>> and >>>> then come back to the issue of how to handle voting on these >>>> changes. >>>> >>>> >>>> Thank you for helping to improve these tickets! >>>> >>>> >>>> Best, >>>> ~Jim. >>>> >>>> >>>> >>>> On Thu, Dec 12, 2013 at 12:34 PM, Rolf Rabenseifner < >>>> rabenseifner(a)hlrs.de > wrote: >>>> >>>> >>>> Dear Jim, >>>> >>>> I would like to disagree. >>>> Looking at #349, I see wording like "base address" etc. >>>> whereas MPI-3.0 p102.29 uses "absolute address". >>>> >>>> And, the ticket does not show the location of the new text, >>>> nor all the needed background info. >>>> >>>> MPI is a standard document and the proposed change >>>> (absolute addresses can no longer be used in >>>> normal arithmetic) should be well prepared. >>>> >>>> The current text is not ready. >>>> >>>> You start to differentiate between "absolute addresses" >>>> and "relative displacements" and their use of MPI_Aint. >>>> >>>> Please have a look at 2.5.6 on page 16. >>>> This section should be clarified. >>>> >>>> Please try to produce one proposal that is complete >>>> and fits to the standard. >>>> Voting in small pieces (several tickets) is not the best. >>>> >>>> >>>> Best regards >>>> Rolf >>>> >>>> ----- Original Message ----- >>>>> From: "Jim Dinan" < james.dinan(a)gmail.com > >>>>> To: "Rolf Rabenseifner" < rabenseifner(a)hlrs.de > >>>>> Cc: "MPI-WG Fortran working group" < >>>>> mpiwg-fortran(a)lists.mpi-forum.org >, "longb" < longb(a)cray.com >, >>>>> "Jim Dinan" >>>>> < dinan(a)mcs.anl.gov > >>>> >>>> >>>>> Sent: Thursday, December 12, 2013 5:51:30 PM >>>>> Subject: Re: [MPIWG Fortran] MPI-3 ticket 349: Fortran question >>>>> >>>>> >>>>> Hi Rolf, >>>>> >>>>> >>>>> Thanks for the corrections -- I apologize, what I had sent was a >>>>> very >>>>> rough draft of the proposal. I applied your changes to the >>>>> proposal, cleaned some things up, and added the datatypes >>>>> examples >>>>> corrections. Could you take another look when you get a chance? >>>>> >>>>> >>>>> In terms of proposal logistics, I would like to let MPI_Aint add >>>>> and >>>>> diff tickets progress independently. I agree that they need to >>>>> be >>>>> together, and I think we can rely on the chapter committee to >>>>> handle >>>>> that if add/diff end up split between two versions of the >>>>> standard. >>>>> MPI_Aint_diff should be ready for a reading at the next meeting >>>>> and >>>>> MPI_Aint_add will be ready for a first vote. Given the >>>>> discussion >>>>> about MPI 3.x/4.0 timeline yesterday, I think the risk of these >>>>> not >>>>> being in the same release of the spec is very low. Since the >>>>> Forum >>>>> has already done all of the work required to move MPI_Aint_add to >>>>> a >>>>> vote, I would prefer not to rewind this process by merging it >>>>> with >>>>> the diff ticket. >>>>> >>>>> >>>>> ~Jim. >>>>> >>>>> >>>>> >>>>> On Thu, Dec 12, 2013 at 9:14 AM, Rolf Rabenseifner < >>>>> rabenseifner(a)hlrs.de > wrote: >>>>> >>>>> >>>>> Jim and all, >>>>> >>>>> MPI_Get_address((char *) addr1 - (char *) addr2, &result) >>>>> >>>>> This is really wrong, because (char *) addr1 - (char *) addr2 >>>>> is not an address and cannot be used as input to MPI_Get_address. >>>>> >>>>> (char *) addr1 - (char *) addr2 is a displacement. >>>>> >>>>> Both tickets 349 and 404 need to be together, because they >>>>> are based on a clear distinguishing between >>>>> - Location in memory (input of MPI_GET_ADDRESS), e.g. x, y >>>>> - absolute addresses (output of MPI_GET_ADDRESS), e.g., addr_x, >>>>> addr_y >>>>> - relative displacements (diff of two absolute addresses), e.g. >>>>> dist_xy >>>>> >>>>> Your new statement is that calculations like >>>>> dist_xy = addr_y - addr_x >>>>> addr_y = addr_x + dist_xy >>>>> need to be done by subroutine calls or functions, >>>>> because absolute addresses are stored in MPI_Aint variables >>>>> through some (unknown/strange) mapping, >>>>> wheras relative displacements are normal unsigned integers >>>>> that can be used for normal arithmetic. >>>>> >>>>> The one ticket must show this clearly and must be integrated into >>>>> section 4.1.5 >>>>> >>>>> >>>>> Best regards >>>>> Rolf >>>>> >>>>> >>>>> ----- Original Message ----- >>>>> >>>>> >>>>>> From: "Jim Dinan" < james.dinan(a)gmail.com > >>>>>> To: "Rolf Rabenseifner" < rabenseifner(a)hlrs.de > >>>>>> Cc: "MPI-WG Fortran working group" < >>>>>> mpiwg-fortran(a)lists.mpi-forum.org >, "longb" < longb(a)cray.com >>>>>>> , >>>>>> "Jim Dinan" >>>>>> < dinan(a)mcs.anl.gov > >>>>>> Sent: Thursday, December 12, 2013 3:20:41 PM >>>>>> Subject: Re: [MPIWG Fortran] MPI-3 ticket 349: Fortran question >>>>>> >>>>>> >>>>>> Hi Rolf, >>>>>> >>>>>> >>>>>> Thank you very much for the feedback! Sorry if I forgot to >>>>>> respond; >>>>>> the comments definitely were not ignored. We discussed the >>>>>> Aint >>>>>> difference calculation in the working group and decided to >>>>>> create >>>>>> an >>>>>> additional ticket for MPI_Aint_disp. We did not see a clean >>>>>> way >>>>>> to >>>>>> handle this in MPI_Aint_add, because both arguments need to be >>>>>> handled as unsigned in the arithmetic. >>>>>> >>>>>> >>>>>> https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/404 >>>>>> >>>>>> >>>>>> >>>>>> I have a list of fixes the to the datatypes examples that I'll >>>>>> post >>>>>> to the ticket soon. >>>>>> >>>>>> >>>>>> Jeff Squyres is also helping us move the MPI_Aint arithmetic >>>>>> routines >>>>>> to functions in the Fortran bindings. Should be done today. >>>>>> >>>>>> >>>>>> Were there any other concerns that we missed? >>>>>> >>>>>> >>>>>> Thanks, >>>>>> ~Jim. >>>>>> >>>>>> >>>>>> >>>>>> On Thu, Dec 12, 2013 at 1:42 AM, Rolf Rabenseifner < >>>>>> rabenseifner(a)hlrs.de > wrote: >>>>>> >>>>>> >>>>>> Jeff and Bill, >>>>>> >>>>>> < >>>>>> https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/349#comment:22 >>>>>> was ignored. >>>>>> The answer seems to be yes and the clear implication is that >>>>>> we need also a routine to calculate disp := addr2-addr1 >>>>>> >>>>>> About the Fortran Interfaces: >>>>>> We should keep the old style without INTENT, because for the >>>>>> old-style >>>>>> the implementor has the freedom to add INTENT as he/she wants >>>>>> and it is still compliant with the outcome of the definition. >>>>>> >>>>>> I do not see, why we have a function in C and a subroutine >>>>>> in Fortran. >>>>>> Like MPI_Wtime, in all three languages (C, new and old >>>>>> Fortran), >>>>>> we should do the same. >>>>>> >>>>>> Best regards >>>>>> Rolf >>>>>> >>>>>> ----- Original Message ----- >>>>>>> From: "Jeff Squyres (jsquyres)" < jsquyres(a)cisco.com > >>>>>>> To: "< longb(a)cray.com >" < longb(a)cray.com >, "MPI-WG Fortran >>>>>>> working group" < mpiwg-fortran(a)lists.mpi-forum.org > >>>>>>> Sent: Thursday, December 12, 2013 12:17:40 AM >>>>>>> Subject: Re: [MPIWG Fortran] MPI-3 ticket 349: Fortran >>>>>>> question >>>>>>> >>>>>>> Sounds good to me. >>>>>>> >>>>>>> Rolf -- is there any MPI reason we would not want to do this? >>>>>>> >>>>>>> >>>>>>> On Dec 11, 2013, at 4:41 PM, Bill Long < longb(a)cray.com > >>>>>>> wrote: >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> On 12/11/13 11:27 AM, Jeff Squyres (jsquyres) wrote: >>>>>>>>> This ticket got a formal reading today at the Forum: >>>>>>>>> >>>>>>>>> http://svn.mpi-forum.org/trac/mpi-forum-web/ticket/349 >>>>>>>>> (as of this writing, there's still a BIND(C) in there, >>>>>>>>> but >>>>>>>>> it >>>>>>>>> will be removed shortly) >>>>>>>>> >>>>>>>>> The function is basically intended to perform a >>>>>>>>> mathematical >>>>>>>>> operation. As such, I think that the 2 Fortran bindings >>>>>>>>> should >>>>>>>>> be FUNCTIONs, not SUBROUTINEs (a la MPI_WTICK/MPI_WTIME). >>>>>>>>> >>>>>>>>> Do you agree? If so, the ticket author (Jim Dinan) is >>>>>>>>> amenable >>>>>>>>> to >>>>>>>>> changing the Fortran bindings to the following (and I'm >>>>>>>>> assuming >>>>>>>>> I have the syntax below correct, but feel free to correct >>>>>>>>> me >>>>>>>>> if >>>>>>>>> they're wrong): >>>>>>>> >>>>>>>> Certainly it makes more sense for these to be functions in >>>>>>>> Fortran. >>>>>>>> Particularly if the programmer prefers supply an interface >>>>>>>> and >>>>>>>> call the C form directly. If the C and Fortran versions >>>>>>>> are >>>>>>>> both >>>>>>>> functions, there is no change in the source code where the >>>>>>>> function is used. >>>>>>>> >>>>>>>>> ----- >>>>>>>>> INTEGER(KIND=MPI_ADDRESS_KIND) MPI_Aint_add(base, disp) >>>>>>>>> INTEGER(KIND=MPI_ADDRESS_KIND), INTENT(IN) :: base, >>>>>>>>> disp >>>>>>>>> >>>>>>>>> INTEGER(KIND=MPI_ADDRESS_KIND) MPI_AINT_ADD(BASE, DISP) >>>>>>>>> INTEGER(KIND=MPI_ADDRESS_KIND) BASE, DISP >>>>>>>> >>>>>>>> It is certainly an oddity that the spec has two forms like >>>>>>>> this. >>>>>>>> Any version of the Fortran standard that supports KIND= in >>>>>>>> INTEGER also supports lower case names and INTENT() >>>>>>>> attributes. >>>>>>>> Maybe there could be some clean up of this in a future >>>>>>>> revision. >>>>>>>> >>>>>>>> Cheers, >>>>>>>> Bill >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> ----- >>>>>>>> >>>>>>>> -- >>>>>>>> Bill Long >>>>>>>> longb(a)cray.com >>>>>>>> Fortran Technical Support & voice: >>>>>>>> 651-605-9024 >>>>>>>> Bioinformatics Software Development fax: >>>>>>>> 651-605-9142 >>>>>>>> Cray Inc./Cray Plaza, Suite 210/380 Jackson St./St. Paul, >>>>>>>> MN >>>>>>>> 55101 >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> mpiwg-fortran mailing list >>>>>>>> mpiwg-fortran(a)lists.mpi-forum.org >>>>>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Jeff Squyres >>>>>>> jsquyres(a)cisco.com >>>>>>> For corporate legal information go to: >>>>>>> http://www.cisco.com/web/about/doing_business/legal/cri/ >>>>>>> >>>>>>> _______________________________________________ >>>>>>> mpiwg-fortran mailing list >>>>>>> mpiwg-fortran(a)lists.mpi-forum.org >>>>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran >>>>>> >>>>>> -- >>>>>> Dr. Rolf Rabenseifner . . . . . . . . . .. email >>>>>> rabenseifner(a)hlrs.de >>>>>> High Performance Computing Center (HLRS) . phone >>>>>> ++49(0)711/685-65530 >>>>>> University of Stuttgart . . . . . . . . .. fax ++49(0)711 / >>>>>> 685-65832 >>>>>> Head of Dpmt Parallel Computing . . . >>>>>> www.hlrs.de/people/rabenseifner >>>>>> Nobelstr. 19, D-70550 Stuttgart, Germany . . . . (Office: Room >>>>>> 1.307) >>>>> >>>>> -- >>>>> Dr. Rolf Rabenseifner . . . . . . . . . .. email >>>>> rabenseifner(a)hlrs.de >>>>> High Performance Computing Center (HLRS) . phone >>>>> ++49(0)711/685-65530 >>>>> University of Stuttgart . . . . . . . . .. fax ++49(0)711 / >>>>> 685-65832 >>>>> Head of Dpmt Parallel Computing . . . >>>>> www.hlrs.de/people/rabenseifner >>>>> Nobelstr. 19, D-70550 Stuttgart, Germany . . . . (Office: Room >>>>> 1.307) >>>> >>>> -- >>>> Dr. Rolf Rabenseifner . . . . . . . . . .. email >>>> rabenseifner(a)hlrs.de >>>> High Performance Computing Center (HLRS) . phone >>>> ++49(0)711/685-65530 >>>> University of Stuttgart . . . . . . . . .. fax ++49(0)711 / >>>> 685-65832 >>>> Head of Dpmt Parallel Computing . . . >>>> www.hlrs.de/people/rabenseifner >>>> Nobelstr. 19, D-70550 Stuttgart, Germany . . . . (Office: Room >>>> 1.307) >>> >>> -- >>> Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner(a)hlrs.de >>> High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530 >>> University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832 >>> Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner >>> Nobelstr. 19, D-70550 Stuttgart, Germany . . . . (Office: Room 1.307) >> >> -- >> Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner(a)hlrs.de >> High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530 >> University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832 >> Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner >> Nobelstr. 19, D-70550 Stuttgart, Germany . . . . (Office: Room 1.307) >> _______________________________________________ >> mpiwg-fortran mailing list >> mpiwg-fortran(a)lists.mpi-forum.org >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran > _______________________________________________ > mpiwg-fortran mailing list > mpiwg-fortran(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran > -- Bill Long longb(a)cray.com Fortran Technical Support & voice: 651-605-9024 Bioinformatics Software Development fax: 651-605-9142 Cray Inc./Cray Plaza, Suite 210/380 Jackson St./St. Paul, MN 55101

1 0

Re: [MPIWG Fortran] MPI-3 ticket 349: Fortran question
by Jim Dinan 20 Dec '13

20 Dec '13

Jeff, I don't think that anyone is making an argument that is specific to 32b architectures. The concern is that the MPI standard currently requires: (1) a two's complement architecture where overflow/underflow of signed arithmetic on an unsigned quantity always results in the right unsigned value - OR - (2) an MPI_Aint type that is 2x the size of an address to ensure that overflow/underflow never occurs (because MPI_BOTTOM is an arbitrary address in Fortran) Given that every system I know of falls into category (1) and there is a solution (2) for all other systems, I am not trying to recall why we felt that this problem needs to be solved through new arithmetic routines. I believe there was a concern that 128-bit integers are not standard and not well supported by most languages/architectures, so (2) may not be a workable solution. Maybe Dave G [added to cc] remembers our rationale? ~Jim. On Fri, Dec 20, 2013 at 8:35 AM, Jeff Hammond <jeff.science(a)gmail.com>wrote: > 32b Blue Gene is dead. We are turning ours off in 2 weeks. > > The only 32b arguments should be relevant to ARM and other cell phone > parts that may run MPI some day. > > Jeff > > Sent from my iPhone > > > On Dec 20, 2013, at 5:04 AM, Rolf Rabenseifner <rabenseifner(a)hlrs.de> > wrote: > > > > Hi Jim, > > > >> I don't think that the proposal is in conflict with sections 2.5.6 or > >> 4.1.5. These sections are talking about addresses and not > >> specifically about how one can use the MPI_Aint type. We mean to > >> address only the latter item -- correct usage of the MPI address > >> integer type. > > > > I also do not see a conflict. > > But I see that the new concept must be explained within these sections. > > This is about consistency of the whole MPI document. > > > >> In terms of where to put the proposed text in the chapter, I suggest > >> we make that a separate discussion, once the technical issues have > >> been resolved. > > > > As you mentioned below, > > technically there are two solutions: > > A. require that disp=addr2-addr1 and addr2=addr1+disp can be > > calculated with the intrinsic arithmetic operations - and +. > > This would require: > > 128 bit MPI_Aint on a system that > > - uses full 64 bit absolute addresses, AND > > - does not have one-s complement arithmetic AND > > - MPI_BOTTOM is not defined in the middle > > B. require that disp=addr2-addr1 and addr2=addr1+disp > > is calculated with your two new functions to guarantee > > that always 64 bits signed MPI_Aint are enough > > to store any 64 bit unsigned absolute addresses. > > > > If we decide A, then only an advice to implementers would be fine. > > If we decide B, then several "corrections" are needed. > > > >> I do have a concern, in particular, about section 4.1.12, "Correct > >> use of Addresses", which seems to suggest that one should be able to > >> do arithmetic directly on absolute addresses stored in address > >> integers. The only way that this could be supported on some > >> platforms (e.g. one's complement integers) is to make the MPI_Aint > >> an integer that is larger than an address, so that > >> overflow/underflow cannot occur. Because of Fortran's dynamic > >> MPI_BOTTOM, address integers on such a platform would have to be > >> 128-bits to ensure that there can be no overflow. > >> > >> What's your take on that section? > > > > The notations MPI-3.0 page 115 lines 42 and 47 v+i and u-v > > need not to be interpreted as C and Fortran + and -. > > > > One could say that there is a lack of not having defined > > these operations. > > > > I principle, you are right when you expect (as all MPI-readers so far) > > that + and - on these lines are C and Fortran + and -, > > and therefore, solution A is required. > > Note that solution A is not the worst because our systems have IEEE > > data representation which has one's complements and therefore no Need > > for doubling the size of MPI_Aint, especially on the pure 32-bit > Blue-Gene > > Systems. > > > > If one wants to go with B (and this is a free Forum decision) > > then one should add text to > >> MPI-3.0 Sect. 2.5.6, page 16 lines 30-37 and > >> MPI-3.0 Sect. 4.1.5, page 102 lines 28-35 > > and also to > > - MPI 3.0 Sect. 4.1.12, page 115 line 48, e.g., > > "Note that v+i and u-v need to be calculated > > with MPI_AINT_ADD and MPI_AINT_DIFF." > > And the two new routines after page 103 line 46. > > > > My mails only try to help that proposal B is fully complete > > and consistent. > > They are not about whether I would like to have A or B. > > Because A continues to stay a work-around for B, > > I would be happy with B. > > > > Best regards > > Rolf > > > > > > ----- Original Message ----- > >> From: "Jim Dinan" <james.dinan(a)gmail.com> > >> To: "Rolf Rabenseifner" <rabenseifner(a)hlrs.de> > >> Cc: "MPI-WG Fortran working group" <mpiwg-fortran(a)lists.mpi-forum.org>, > "longb" <longb(a)cray.com> > >> Sent: Thursday, December 19, 2013 9:55:42 PM > >> Subject: Re: [MPIWG Fortran] MPI-3 ticket 349: Fortran question > >> > >> > >> Hi Rolf, > >> > >> > >> I don't think that the proposal is in conflict with sections 2.5.6 or > >> 4.1.5. These sections are talking about addresses and not > >> specifically about how one can use the MPI_Aint type. We mean to > >> address only the latter item -- correct usage of the MPI address > >> integer type. > >> > >> > >> In terms of where to put the proposed text in the chapter, I suggest > >> we make that a separate discussion, once the technical issues have > >> been resolved. > >> > >> > >> I do have a concern, in particular, about section 4.1.12, "Correct > >> use of Addresses", which seems to suggest that one should be able to > >> do arithmetic directly on absolute addresses stored in address > >> integers. The only way that this could be supported on some > >> platforms (e.g. one's complement integers) is to make the MPI_Aint > >> an integer that is larger than an address, so that > >> overflow/underflow cannot occur. Because of Fortran's dynamic > >> MPI_BOTTOM, address integers on such a platform would have to be > >> 128-bits to ensure that there can be no overflow. > >> > >> > >> What's your take on that section? > >> > >> > >> ~Jim. > >> > >> > >> > >> On Fri, Dec 13, 2013 at 9:11 AM, Rolf Rabenseifner < > >> rabenseifner(a)hlrs.de > wrote: > >> > >> > >> Jim, > >> > >> > >>> Could you provide a list of the specific changes that you feel are > >>> needed on these tickets? > >> > >> I expected that you are doining this. > >> I only want to mention the locations. > >> > >> Your new model differentiates beween > >> - absolute addresses generated from locations with MPI_GET_ADDRESS > >> - relative displacements as differences of two absolute addresses > >> and the needed arithmetic > >> - relative displacements with normal + - * arithmetic > >> - absolute addresses and displacments with > >> MPI_AINT_ADD and MPI_AINT_DIFF arithmetic > >> > >> Therefore: > >> MPI-3.0 Sect. 2.5.6, page 16 lines 30-37 and > >> MPI-3.0 Sect. 4.1.5, page 102 lines 28-35 > >> should reflect this differentiation. > >> > >> The proposed rationale in #349 may go at the end of page 102 lines > >> 28-35. > >> After MPI-3.0 Sect. 4.1.5, page 103 line 46, you should add > >> MPI_AINT_ADD and MPI_AINT_DIFF. > >> > >> > >> Best regards > >> Rolf > >> > >> > >> > >> ----- Original Message ----- > >>> From: "Jim Dinan" < james.dinan(a)gmail.com > > >>> To: "Rolf Rabenseifner" < rabenseifner(a)hlrs.de > > >>> Cc: "MPI-WG Fortran working group" < > >>> mpiwg-fortran(a)lists.mpi-forum.org >, "longb" < longb(a)cray.com > > >> > >> > >>> Sent: Friday, December 13, 2013 1:35:13 PM > >>> Subject: Re: [MPIWG Fortran] MPI-3 ticket 349: Fortran question > >>> > >>> > >>> Rolf, > >>> > >>> > >>> Could you provide a list of the specific changes that you feel are > >>> needed on these tickets? For reference, and to bring in feedback > >>> from others on the cc, we are discussing: > >>> > >>> > >>> MPI_Aint_add -- > >>> https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/349 > >>> Linked list example updates -- > >>> https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/402 > >>> MPI_Aint_diff -- > >>> https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/404 > >>> > >>> > >>> Let's solve the technical issues first to see where things stand, > >>> and > >>> then come back to the issue of how to handle voting on these > >>> changes. > >>> > >>> > >>> Thank you for helping to improve these tickets! > >>> > >>> > >>> Best, > >>> ~Jim. > >>> > >>> > >>> > >>> On Thu, Dec 12, 2013 at 12:34 PM, Rolf Rabenseifner < > >>> rabenseifner(a)hlrs.de > wrote: > >>> > >>> > >>> Dear Jim, > >>> > >>> I would like to disagree. > >>> Looking at #349, I see wording like "base address" etc. > >>> whereas MPI-3.0 p102.29 uses "absolute address". > >>> > >>> And, the ticket does not show the location of the new text, > >>> nor all the needed background info. > >>> > >>> MPI is a standard document and the proposed change > >>> (absolute addresses can no longer be used in > >>> normal arithmetic) should be well prepared. > >>> > >>> The current text is not ready. > >>> > >>> You start to differentiate between "absolute addresses" > >>> and "relative displacements" and their use of MPI_Aint. > >>> > >>> Please have a look at 2.5.6 on page 16. > >>> This section should be clarified. > >>> > >>> Please try to produce one proposal that is complete > >>> and fits to the standard. > >>> Voting in small pieces (several tickets) is not the best. > >>> > >>> > >>> Best regards > >>> Rolf > >>> > >>> ----- Original Message ----- > >>>> From: "Jim Dinan" < james.dinan(a)gmail.com > > >>>> To: "Rolf Rabenseifner" < rabenseifner(a)hlrs.de > > >>>> Cc: "MPI-WG Fortran working group" < > >>>> mpiwg-fortran(a)lists.mpi-forum.org >, "longb" < longb(a)cray.com >, > >>>> "Jim Dinan" > >>>> < dinan(a)mcs.anl.gov > > >>> > >>> > >>>> Sent: Thursday, December 12, 2013 5:51:30 PM > >>>> Subject: Re: [MPIWG Fortran] MPI-3 ticket 349: Fortran question > >>>> > >>>> > >>>> Hi Rolf, > >>>> > >>>> > >>>> Thanks for the corrections -- I apologize, what I had sent was a > >>>> very > >>>> rough draft of the proposal. I applied your changes to the > >>>> proposal, cleaned some things up, and added the datatypes > >>>> examples > >>>> corrections. Could you take another look when you get a chance? > >>>> > >>>> > >>>> In terms of proposal logistics, I would like to let MPI_Aint add > >>>> and > >>>> diff tickets progress independently. I agree that they need to > >>>> be > >>>> together, and I think we can rely on the chapter committee to > >>>> handle > >>>> that if add/diff end up split between two versions of the > >>>> standard. > >>>> MPI_Aint_diff should be ready for a reading at the next meeting > >>>> and > >>>> MPI_Aint_add will be ready for a first vote. Given the > >>>> discussion > >>>> about MPI 3.x/4.0 timeline yesterday, I think the risk of these > >>>> not > >>>> being in the same release of the spec is very low. Since the > >>>> Forum > >>>> has already done all of the work required to move MPI_Aint_add to > >>>> a > >>>> vote, I would prefer not to rewind this process by merging it > >>>> with > >>>> the diff ticket. > >>>> > >>>> > >>>> ~Jim. > >>>> > >>>> > >>>> > >>>> On Thu, Dec 12, 2013 at 9:14 AM, Rolf Rabenseifner < > >>>> rabenseifner(a)hlrs.de > wrote: > >>>> > >>>> > >>>> Jim and all, > >>>> > >>>> MPI_Get_address((char *) addr1 - (char *) addr2, &result) > >>>> > >>>> This is really wrong, because (char *) addr1 - (char *) addr2 > >>>> is not an address and cannot be used as input to MPI_Get_address. > >>>> > >>>> (char *) addr1 - (char *) addr2 is a displacement. > >>>> > >>>> Both tickets 349 and 404 need to be together, because they > >>>> are based on a clear distinguishing between > >>>> - Location in memory (input of MPI_GET_ADDRESS), e.g. x, y > >>>> - absolute addresses (output of MPI_GET_ADDRESS), e.g., addr_x, > >>>> addr_y > >>>> - relative displacements (diff of two absolute addresses), e.g. > >>>> dist_xy > >>>> > >>>> Your new statement is that calculations like > >>>> dist_xy = addr_y - addr_x > >>>> addr_y = addr_x + dist_xy > >>>> need to be done by subroutine calls or functions, > >>>> because absolute addresses are stored in MPI_Aint variables > >>>> through some (unknown/strange) mapping, > >>>> wheras relative displacements are normal unsigned integers > >>>> that can be used for normal arithmetic. > >>>> > >>>> The one ticket must show this clearly and must be integrated into > >>>> section 4.1.5 > >>>> > >>>> > >>>> Best regards > >>>> Rolf > >>>> > >>>> > >>>> ----- Original Message ----- > >>>> > >>>> > >>>>> From: "Jim Dinan" < james.dinan(a)gmail.com > > >>>>> To: "Rolf Rabenseifner" < rabenseifner(a)hlrs.de > > >>>>> Cc: "MPI-WG Fortran working group" < > >>>>> mpiwg-fortran(a)lists.mpi-forum.org >, "longb" < longb(a)cray.com > >>>>>> , > >>>>> "Jim Dinan" > >>>>> < dinan(a)mcs.anl.gov > > >>>>> Sent: Thursday, December 12, 2013 3:20:41 PM > >>>>> Subject: Re: [MPIWG Fortran] MPI-3 ticket 349: Fortran question > >>>>> > >>>>> > >>>>> Hi Rolf, > >>>>> > >>>>> > >>>>> Thank you very much for the feedback! Sorry if I forgot to > >>>>> respond; > >>>>> the comments definitely were not ignored. We discussed the > >>>>> Aint > >>>>> difference calculation in the working group and decided to > >>>>> create > >>>>> an > >>>>> additional ticket for MPI_Aint_disp. We did not see a clean > >>>>> way > >>>>> to > >>>>> handle this in MPI_Aint_add, because both arguments need to be > >>>>> handled as unsigned in the arithmetic. > >>>>> > >>>>> > >>>>> https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/404 > >>>>> > >>>>> > >>>>> > >>>>> I have a list of fixes the to the datatypes examples that I'll > >>>>> post > >>>>> to the ticket soon. > >>>>> > >>>>> > >>>>> Jeff Squyres is also helping us move the MPI_Aint arithmetic > >>>>> routines > >>>>> to functions in the Fortran bindings. Should be done today. > >>>>> > >>>>> > >>>>> Were there any other concerns that we missed? > >>>>> > >>>>> > >>>>> Thanks, > >>>>> ~Jim. > >>>>> > >>>>> > >>>>> > >>>>> On Thu, Dec 12, 2013 at 1:42 AM, Rolf Rabenseifner < > >>>>> rabenseifner(a)hlrs.de > wrote: > >>>>> > >>>>> > >>>>> Jeff and Bill, > >>>>> > >>>>> < > >>>>> https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/349#comment:22 > >>>>> was ignored. > >>>>> The answer seems to be yes and the clear implication is that > >>>>> we need also a routine to calculate disp := addr2-addr1 > >>>>> > >>>>> About the Fortran Interfaces: > >>>>> We should keep the old style without INTENT, because for the > >>>>> old-style > >>>>> the implementor has the freedom to add INTENT as he/she wants > >>>>> and it is still compliant with the outcome of the definition. > >>>>> > >>>>> I do not see, why we have a function in C and a subroutine > >>>>> in Fortran. > >>>>> Like MPI_Wtime, in all three languages (C, new and old > >>>>> Fortran), > >>>>> we should do the same. > >>>>> > >>>>> Best regards > >>>>> Rolf > >>>>> > >>>>> ----- Original Message ----- > >>>>>> From: "Jeff Squyres (jsquyres)" < jsquyres(a)cisco.com > > >>>>>> To: "< longb(a)cray.com >" < longb(a)cray.com >, "MPI-WG Fortran > >>>>>> working group" < mpiwg-fortran(a)lists.mpi-forum.org > > >>>>>> Sent: Thursday, December 12, 2013 12:17:40 AM > >>>>>> Subject: Re: [MPIWG Fortran] MPI-3 ticket 349: Fortran > >>>>>> question > >>>>>> > >>>>>> Sounds good to me. > >>>>>> > >>>>>> Rolf -- is there any MPI reason we would not want to do this? > >>>>>> > >>>>>> > >>>>>> On Dec 11, 2013, at 4:41 PM, Bill Long < longb(a)cray.com > > >>>>>> wrote: > >>>>>> > >>>>>>> > >>>>>>> > >>>>>>>> On 12/11/13 11:27 AM, Jeff Squyres (jsquyres) wrote: > >>>>>>>> This ticket got a formal reading today at the Forum: > >>>>>>>> > >>>>>>>> http://svn.mpi-forum.org/trac/mpi-forum-web/ticket/349 > >>>>>>>> (as of this writing, there's still a BIND(C) in there, > >>>>>>>> but > >>>>>>>> it > >>>>>>>> will be removed shortly) > >>>>>>>> > >>>>>>>> The function is basically intended to perform a > >>>>>>>> mathematical > >>>>>>>> operation. As such, I think that the 2 Fortran bindings > >>>>>>>> should > >>>>>>>> be FUNCTIONs, not SUBROUTINEs (a la MPI_WTICK/MPI_WTIME). > >>>>>>>> > >>>>>>>> Do you agree? If so, the ticket author (Jim Dinan) is > >>>>>>>> amenable > >>>>>>>> to > >>>>>>>> changing the Fortran bindings to the following (and I'm > >>>>>>>> assuming > >>>>>>>> I have the syntax below correct, but feel free to correct > >>>>>>>> me > >>>>>>>> if > >>>>>>>> they're wrong): > >>>>>>> > >>>>>>> Certainly it makes more sense for these to be functions in > >>>>>>> Fortran. > >>>>>>> Particularly if the programmer prefers supply an interface > >>>>>>> and > >>>>>>> call the C form directly. If the C and Fortran versions > >>>>>>> are > >>>>>>> both > >>>>>>> functions, there is no change in the source code where the > >>>>>>> function is used. > >>>>>>> > >>>>>>>> ----- > >>>>>>>> INTEGER(KIND=MPI_ADDRESS_KIND) MPI_Aint_add(base, disp) > >>>>>>>> INTEGER(KIND=MPI_ADDRESS_KIND), INTENT(IN) :: base, > >>>>>>>> disp > >>>>>>>> > >>>>>>>> INTEGER(KIND=MPI_ADDRESS_KIND) MPI_AINT_ADD(BASE, DISP) > >>>>>>>> INTEGER(KIND=MPI_ADDRESS_KIND) BASE, DISP > >>>>>>> > >>>>>>> It is certainly an oddity that the spec has two forms like > >>>>>>> this. > >>>>>>> Any version of the Fortran standard that supports KIND= in > >>>>>>> INTEGER also supports lower case names and INTENT() > >>>>>>> attributes. > >>>>>>> Maybe there could be some clean up of this in a future > >>>>>>> revision. > >>>>>>> > >>>>>>> Cheers, > >>>>>>> Bill > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>>> ----- > >>>>>>> > >>>>>>> -- > >>>>>>> Bill Long > >>>>>>> longb(a)cray.com > >>>>>>> Fortran Technical Support & voice: > >>>>>>> 651-605-9024 > >>>>>>> Bioinformatics Software Development fax: > >>>>>>> 651-605-9142 > >>>>>>> Cray Inc./Cray Plaza, Suite 210/380 Jackson St./St. Paul, > >>>>>>> MN > >>>>>>> 55101 > >>>>>>> > >>>>>>> > >>>>>>> _______________________________________________ > >>>>>>> mpiwg-fortran mailing list > >>>>>>> mpiwg-fortran(a)lists.mpi-forum.org > >>>>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran > >>>>>> > >>>>>> > >>>>>> -- > >>>>>> Jeff Squyres > >>>>>> jsquyres(a)cisco.com > >>>>>> For corporate legal information go to: > >>>>>> http://www.cisco.com/web/about/doing_business/legal/cri/ > >>>>>> > >>>>>> _______________________________________________ > >>>>>> mpiwg-fortran mailing list > >>>>>> mpiwg-fortran(a)lists.mpi-forum.org > >>>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran > >>>>> > >>>>> -- > >>>>> Dr. Rolf Rabenseifner . . . . . . . . . .. email > >>>>> rabenseifner(a)hlrs.de > >>>>> High Performance Computing Center (HLRS) . phone > >>>>> ++49(0)711/685-65530 > >>>>> University of Stuttgart . . . . . . . . .. fax ++49(0)711 / > >>>>> 685-65832 > >>>>> Head of Dpmt Parallel Computing . . . > >>>>> www.hlrs.de/people/rabenseifner > >>>>> Nobelstr. 19, D-70550 Stuttgart, Germany . . . . (Office: Room > >>>>> 1.307) > >>>> > >>>> -- > >>>> Dr. Rolf Rabenseifner . . . . . . . . . .. email > >>>> rabenseifner(a)hlrs.de > >>>> High Performance Computing Center (HLRS) . phone > >>>> ++49(0)711/685-65530 > >>>> University of Stuttgart . . . . . . . . .. fax ++49(0)711 / > >>>> 685-65832 > >>>> Head of Dpmt Parallel Computing . . . > >>>> www.hlrs.de/people/rabenseifner > >>>> Nobelstr. 19, D-70550 Stuttgart, Germany . . . . (Office: Room > >>>> 1.307) > >>> > >>> -- > >>> Dr. Rolf Rabenseifner . . . . . . . . . .. email > >>> rabenseifner(a)hlrs.de > >>> High Performance Computing Center (HLRS) . phone > >>> ++49(0)711/685-65530 > >>> University of Stuttgart . . . . . . . . .. fax ++49(0)711 / > >>> 685-65832 > >>> Head of Dpmt Parallel Computing . . . > >>> www.hlrs.de/people/rabenseifner > >>> Nobelstr. 19, D-70550 Stuttgart, Germany . . . . (Office: Room > >>> 1.307) > >> > >> -- > >> Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner(a)hlrs.de > >> High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530 > >> University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832 > >> Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner > >> Nobelstr. 19, D-70550 Stuttgart, Germany . . . . (Office: Room 1.307) > > > > -- > > Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner(a)hlrs.de > > High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530 > > University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832 > > Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner > > Nobelstr. 19, D-70550 Stuttgart, Germany . . . . (Office: Room 1.307) > > _______________________________________________ > > mpiwg-fortran mailing list > > mpiwg-fortran(a)lists.mpi-forum.org > > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran >

1 0

Re: [MPIWG Fortran] MPI-3 ticket 349: Fortran question
by Jeff Hammond 20 Dec '13

20 Dec '13

32b Blue Gene is dead. We are turning ours off in 2 weeks. The only 32b arguments should be relevant to ARM and other cell phone parts that may run MPI some day. Jeff Sent from my iPhone > On Dec 20, 2013, at 5:04 AM, Rolf Rabenseifner <rabenseifner(a)hlrs.de> wrote: > > Hi Jim, > >> I don't think that the proposal is in conflict with sections 2.5.6 or >> 4.1.5. These sections are talking about addresses and not >> specifically about how one can use the MPI_Aint type. We mean to >> address only the latter item -- correct usage of the MPI address >> integer type. > > I also do not see a conflict. > But I see that the new concept must be explained within these sections. > This is about consistency of the whole MPI document. > >> In terms of where to put the proposed text in the chapter, I suggest >> we make that a separate discussion, once the technical issues have >> been resolved. > > As you mentioned below, > technically there are two solutions: > A. require that disp=addr2-addr1 and addr2=addr1+disp can be > calculated with the intrinsic arithmetic operations - and +. > This would require: > 128 bit MPI_Aint on a system that > - uses full 64 bit absolute addresses, AND > - does not have one-s complement arithmetic AND > - MPI_BOTTOM is not defined in the middle > B. require that disp=addr2-addr1 and addr2=addr1+disp > is calculated with your two new functions to guarantee > that always 64 bits signed MPI_Aint are enough > to store any 64 bit unsigned absolute addresses. > > If we decide A, then only an advice to implementers would be fine. > If we decide B, then several "corrections" are needed. > >> I do have a concern, in particular, about section 4.1.12, "Correct >> use of Addresses", which seems to suggest that one should be able to >> do arithmetic directly on absolute addresses stored in address >> integers. The only way that this could be supported on some >> platforms (e.g. one's complement integers) is to make the MPI_Aint >> an integer that is larger than an address, so that >> overflow/underflow cannot occur. Because of Fortran's dynamic >> MPI_BOTTOM, address integers on such a platform would have to be >> 128-bits to ensure that there can be no overflow. >> >> What's your take on that section? > > The notations MPI-3.0 page 115 lines 42 and 47 v+i and u-v > need not to be interpreted as C and Fortran + and -. > > One could say that there is a lack of not having defined > these operations. > > I principle, you are right when you expect (as all MPI-readers so far) > that + and - on these lines are C and Fortran + and -, > and therefore, solution A is required. > Note that solution A is not the worst because our systems have IEEE > data representation which has one's complements and therefore no Need > for doubling the size of MPI_Aint, especially on the pure 32-bit Blue-Gene > Systems. > > If one wants to go with B (and this is a free Forum decision) > then one should add text to >> MPI-3.0 Sect. 2.5.6, page 16 lines 30-37 and >> MPI-3.0 Sect. 4.1.5, page 102 lines 28-35 > and also to > - MPI 3.0 Sect. 4.1.12, page 115 line 48, e.g., > "Note that v+i and u-v need to be calculated > with MPI_AINT_ADD and MPI_AINT_DIFF." > And the two new routines after page 103 line 46. > > My mails only try to help that proposal B is fully complete > and consistent. > They are not about whether I would like to have A or B. > Because A continues to stay a work-around for B, > I would be happy with B. > > Best regards > Rolf > > > ----- Original Message ----- >> From: "Jim Dinan" <james.dinan(a)gmail.com> >> To: "Rolf Rabenseifner" <rabenseifner(a)hlrs.de> >> Cc: "MPI-WG Fortran working group" <mpiwg-fortran(a)lists.mpi-forum.org>, "longb" <longb(a)cray.com> >> Sent: Thursday, December 19, 2013 9:55:42 PM >> Subject: Re: [MPIWG Fortran] MPI-3 ticket 349: Fortran question >> >> >> Hi Rolf, >> >> >> I don't think that the proposal is in conflict with sections 2.5.6 or >> 4.1.5. These sections are talking about addresses and not >> specifically about how one can use the MPI_Aint type. We mean to >> address only the latter item -- correct usage of the MPI address >> integer type. >> >> >> In terms of where to put the proposed text in the chapter, I suggest >> we make that a separate discussion, once the technical issues have >> been resolved. >> >> >> I do have a concern, in particular, about section 4.1.12, "Correct >> use of Addresses", which seems to suggest that one should be able to >> do arithmetic directly on absolute addresses stored in address >> integers. The only way that this could be supported on some >> platforms (e.g. one's complement integers) is to make the MPI_Aint >> an integer that is larger than an address, so that >> overflow/underflow cannot occur. Because of Fortran's dynamic >> MPI_BOTTOM, address integers on such a platform would have to be >> 128-bits to ensure that there can be no overflow. >> >> >> What's your take on that section? >> >> >> ~Jim. >> >> >> >> On Fri, Dec 13, 2013 at 9:11 AM, Rolf Rabenseifner < >> rabenseifner(a)hlrs.de > wrote: >> >> >> Jim, >> >> >>> Could you provide a list of the specific changes that you feel are >>> needed on these tickets? >> >> I expected that you are doining this. >> I only want to mention the locations. >> >> Your new model differentiates beween >> - absolute addresses generated from locations with MPI_GET_ADDRESS >> - relative displacements as differences of two absolute addresses >> and the needed arithmetic >> - relative displacements with normal + - * arithmetic >> - absolute addresses and displacments with >> MPI_AINT_ADD and MPI_AINT_DIFF arithmetic >> >> Therefore: >> MPI-3.0 Sect. 2.5.6, page 16 lines 30-37 and >> MPI-3.0 Sect. 4.1.5, page 102 lines 28-35 >> should reflect this differentiation. >> >> The proposed rationale in #349 may go at the end of page 102 lines >> 28-35. >> After MPI-3.0 Sect. 4.1.5, page 103 line 46, you should add >> MPI_AINT_ADD and MPI_AINT_DIFF. >> >> >> Best regards >> Rolf >> >> >> >> ----- Original Message ----- >>> From: "Jim Dinan" < james.dinan(a)gmail.com > >>> To: "Rolf Rabenseifner" < rabenseifner(a)hlrs.de > >>> Cc: "MPI-WG Fortran working group" < >>> mpiwg-fortran(a)lists.mpi-forum.org >, "longb" < longb(a)cray.com > >> >> >>> Sent: Friday, December 13, 2013 1:35:13 PM >>> Subject: Re: [MPIWG Fortran] MPI-3 ticket 349: Fortran question >>> >>> >>> Rolf, >>> >>> >>> Could you provide a list of the specific changes that you feel are >>> needed on these tickets? For reference, and to bring in feedback >>> from others on the cc, we are discussing: >>> >>> >>> MPI_Aint_add -- >>> https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/349 >>> Linked list example updates -- >>> https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/402 >>> MPI_Aint_diff -- >>> https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/404 >>> >>> >>> Let's solve the technical issues first to see where things stand, >>> and >>> then come back to the issue of how to handle voting on these >>> changes. >>> >>> >>> Thank you for helping to improve these tickets! >>> >>> >>> Best, >>> ~Jim. >>> >>> >>> >>> On Thu, Dec 12, 2013 at 12:34 PM, Rolf Rabenseifner < >>> rabenseifner(a)hlrs.de > wrote: >>> >>> >>> Dear Jim, >>> >>> I would like to disagree. >>> Looking at #349, I see wording like "base address" etc. >>> whereas MPI-3.0 p102.29 uses "absolute address". >>> >>> And, the ticket does not show the location of the new text, >>> nor all the needed background info. >>> >>> MPI is a standard document and the proposed change >>> (absolute addresses can no longer be used in >>> normal arithmetic) should be well prepared. >>> >>> The current text is not ready. >>> >>> You start to differentiate between "absolute addresses" >>> and "relative displacements" and their use of MPI_Aint. >>> >>> Please have a look at 2.5.6 on page 16. >>> This section should be clarified. >>> >>> Please try to produce one proposal that is complete >>> and fits to the standard. >>> Voting in small pieces (several tickets) is not the best. >>> >>> >>> Best regards >>> Rolf >>> >>> ----- Original Message ----- >>>> From: "Jim Dinan" < james.dinan(a)gmail.com > >>>> To: "Rolf Rabenseifner" < rabenseifner(a)hlrs.de > >>>> Cc: "MPI-WG Fortran working group" < >>>> mpiwg-fortran(a)lists.mpi-forum.org >, "longb" < longb(a)cray.com >, >>>> "Jim Dinan" >>>> < dinan(a)mcs.anl.gov > >>> >>> >>>> Sent: Thursday, December 12, 2013 5:51:30 PM >>>> Subject: Re: [MPIWG Fortran] MPI-3 ticket 349: Fortran question >>>> >>>> >>>> Hi Rolf, >>>> >>>> >>>> Thanks for the corrections -- I apologize, what I had sent was a >>>> very >>>> rough draft of the proposal. I applied your changes to the >>>> proposal, cleaned some things up, and added the datatypes >>>> examples >>>> corrections. Could you take another look when you get a chance? >>>> >>>> >>>> In terms of proposal logistics, I would like to let MPI_Aint add >>>> and >>>> diff tickets progress independently. I agree that they need to >>>> be >>>> together, and I think we can rely on the chapter committee to >>>> handle >>>> that if add/diff end up split between two versions of the >>>> standard. >>>> MPI_Aint_diff should be ready for a reading at the next meeting >>>> and >>>> MPI_Aint_add will be ready for a first vote. Given the >>>> discussion >>>> about MPI 3.x/4.0 timeline yesterday, I think the risk of these >>>> not >>>> being in the same release of the spec is very low. Since the >>>> Forum >>>> has already done all of the work required to move MPI_Aint_add to >>>> a >>>> vote, I would prefer not to rewind this process by merging it >>>> with >>>> the diff ticket. >>>> >>>> >>>> ~Jim. >>>> >>>> >>>> >>>> On Thu, Dec 12, 2013 at 9:14 AM, Rolf Rabenseifner < >>>> rabenseifner(a)hlrs.de > wrote: >>>> >>>> >>>> Jim and all, >>>> >>>> MPI_Get_address((char *) addr1 - (char *) addr2, &result) >>>> >>>> This is really wrong, because (char *) addr1 - (char *) addr2 >>>> is not an address and cannot be used as input to MPI_Get_address. >>>> >>>> (char *) addr1 - (char *) addr2 is a displacement. >>>> >>>> Both tickets 349 and 404 need to be together, because they >>>> are based on a clear distinguishing between >>>> - Location in memory (input of MPI_GET_ADDRESS), e.g. x, y >>>> - absolute addresses (output of MPI_GET_ADDRESS), e.g., addr_x, >>>> addr_y >>>> - relative displacements (diff of two absolute addresses), e.g. >>>> dist_xy >>>> >>>> Your new statement is that calculations like >>>> dist_xy = addr_y - addr_x >>>> addr_y = addr_x + dist_xy >>>> need to be done by subroutine calls or functions, >>>> because absolute addresses are stored in MPI_Aint variables >>>> through some (unknown/strange) mapping, >>>> wheras relative displacements are normal unsigned integers >>>> that can be used for normal arithmetic. >>>> >>>> The one ticket must show this clearly and must be integrated into >>>> section 4.1.5 >>>> >>>> >>>> Best regards >>>> Rolf >>>> >>>> >>>> ----- Original Message ----- >>>> >>>> >>>>> From: "Jim Dinan" < james.dinan(a)gmail.com > >>>>> To: "Rolf Rabenseifner" < rabenseifner(a)hlrs.de > >>>>> Cc: "MPI-WG Fortran working group" < >>>>> mpiwg-fortran(a)lists.mpi-forum.org >, "longb" < longb(a)cray.com >>>>>> , >>>>> "Jim Dinan" >>>>> < dinan(a)mcs.anl.gov > >>>>> Sent: Thursday, December 12, 2013 3:20:41 PM >>>>> Subject: Re: [MPIWG Fortran] MPI-3 ticket 349: Fortran question >>>>> >>>>> >>>>> Hi Rolf, >>>>> >>>>> >>>>> Thank you very much for the feedback! Sorry if I forgot to >>>>> respond; >>>>> the comments definitely were not ignored. We discussed the >>>>> Aint >>>>> difference calculation in the working group and decided to >>>>> create >>>>> an >>>>> additional ticket for MPI_Aint_disp. We did not see a clean >>>>> way >>>>> to >>>>> handle this in MPI_Aint_add, because both arguments need to be >>>>> handled as unsigned in the arithmetic. >>>>> >>>>> >>>>> https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/404 >>>>> >>>>> >>>>> >>>>> I have a list of fixes the to the datatypes examples that I'll >>>>> post >>>>> to the ticket soon. >>>>> >>>>> >>>>> Jeff Squyres is also helping us move the MPI_Aint arithmetic >>>>> routines >>>>> to functions in the Fortran bindings. Should be done today. >>>>> >>>>> >>>>> Were there any other concerns that we missed? >>>>> >>>>> >>>>> Thanks, >>>>> ~Jim. >>>>> >>>>> >>>>> >>>>> On Thu, Dec 12, 2013 at 1:42 AM, Rolf Rabenseifner < >>>>> rabenseifner(a)hlrs.de > wrote: >>>>> >>>>> >>>>> Jeff and Bill, >>>>> >>>>> < >>>>> https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/349#comment:22 >>>>> was ignored. >>>>> The answer seems to be yes and the clear implication is that >>>>> we need also a routine to calculate disp := addr2-addr1 >>>>> >>>>> About the Fortran Interfaces: >>>>> We should keep the old style without INTENT, because for the >>>>> old-style >>>>> the implementor has the freedom to add INTENT as he/she wants >>>>> and it is still compliant with the outcome of the definition. >>>>> >>>>> I do not see, why we have a function in C and a subroutine >>>>> in Fortran. >>>>> Like MPI_Wtime, in all three languages (C, new and old >>>>> Fortran), >>>>> we should do the same. >>>>> >>>>> Best regards >>>>> Rolf >>>>> >>>>> ----- Original Message ----- >>>>>> From: "Jeff Squyres (jsquyres)" < jsquyres(a)cisco.com > >>>>>> To: "< longb(a)cray.com >" < longb(a)cray.com >, "MPI-WG Fortran >>>>>> working group" < mpiwg-fortran(a)lists.mpi-forum.org > >>>>>> Sent: Thursday, December 12, 2013 12:17:40 AM >>>>>> Subject: Re: [MPIWG Fortran] MPI-3 ticket 349: Fortran >>>>>> question >>>>>> >>>>>> Sounds good to me. >>>>>> >>>>>> Rolf -- is there any MPI reason we would not want to do this? >>>>>> >>>>>> >>>>>> On Dec 11, 2013, at 4:41 PM, Bill Long < longb(a)cray.com > >>>>>> wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>>> On 12/11/13 11:27 AM, Jeff Squyres (jsquyres) wrote: >>>>>>>> This ticket got a formal reading today at the Forum: >>>>>>>> >>>>>>>> http://svn.mpi-forum.org/trac/mpi-forum-web/ticket/349 >>>>>>>> (as of this writing, there's still a BIND(C) in there, >>>>>>>> but >>>>>>>> it >>>>>>>> will be removed shortly) >>>>>>>> >>>>>>>> The function is basically intended to perform a >>>>>>>> mathematical >>>>>>>> operation. As such, I think that the 2 Fortran bindings >>>>>>>> should >>>>>>>> be FUNCTIONs, not SUBROUTINEs (a la MPI_WTICK/MPI_WTIME). >>>>>>>> >>>>>>>> Do you agree? If so, the ticket author (Jim Dinan) is >>>>>>>> amenable >>>>>>>> to >>>>>>>> changing the Fortran bindings to the following (and I'm >>>>>>>> assuming >>>>>>>> I have the syntax below correct, but feel free to correct >>>>>>>> me >>>>>>>> if >>>>>>>> they're wrong): >>>>>>> >>>>>>> Certainly it makes more sense for these to be functions in >>>>>>> Fortran. >>>>>>> Particularly if the programmer prefers supply an interface >>>>>>> and >>>>>>> call the C form directly. If the C and Fortran versions >>>>>>> are >>>>>>> both >>>>>>> functions, there is no change in the source code where the >>>>>>> function is used. >>>>>>> >>>>>>>> ----- >>>>>>>> INTEGER(KIND=MPI_ADDRESS_KIND) MPI_Aint_add(base, disp) >>>>>>>> INTEGER(KIND=MPI_ADDRESS_KIND), INTENT(IN) :: base, >>>>>>>> disp >>>>>>>> >>>>>>>> INTEGER(KIND=MPI_ADDRESS_KIND) MPI_AINT_ADD(BASE, DISP) >>>>>>>> INTEGER(KIND=MPI_ADDRESS_KIND) BASE, DISP >>>>>>> >>>>>>> It is certainly an oddity that the spec has two forms like >>>>>>> this. >>>>>>> Any version of the Fortran standard that supports KIND= in >>>>>>> INTEGER also supports lower case names and INTENT() >>>>>>> attributes. >>>>>>> Maybe there could be some clean up of this in a future >>>>>>> revision. >>>>>>> >>>>>>> Cheers, >>>>>>> Bill >>>>>>> >>>>>>> >>>>>>> >>>>>>>> ----- >>>>>>> >>>>>>> -- >>>>>>> Bill Long >>>>>>> longb(a)cray.com >>>>>>> Fortran Technical Support & voice: >>>>>>> 651-605-9024 >>>>>>> Bioinformatics Software Development fax: >>>>>>> 651-605-9142 >>>>>>> Cray Inc./Cray Plaza, Suite 210/380 Jackson St./St. Paul, >>>>>>> MN >>>>>>> 55101 >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> mpiwg-fortran mailing list >>>>>>> mpiwg-fortran(a)lists.mpi-forum.org >>>>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran >>>>>> >>>>>> >>>>>> -- >>>>>> Jeff Squyres >>>>>> jsquyres(a)cisco.com >>>>>> For corporate legal information go to: >>>>>> http://www.cisco.com/web/about/doing_business/legal/cri/ >>>>>> >>>>>> _______________________________________________ >>>>>> mpiwg-fortran mailing list >>>>>> mpiwg-fortran(a)lists.mpi-forum.org >>>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran >>>>> >>>>> -- >>>>> Dr. Rolf Rabenseifner . . . . . . . . . .. email >>>>> rabenseifner(a)hlrs.de >>>>> High Performance Computing Center (HLRS) . phone >>>>> ++49(0)711/685-65530 >>>>> University of Stuttgart . . . . . . . . .. fax ++49(0)711 / >>>>> 685-65832 >>>>> Head of Dpmt Parallel Computing . . . >>>>> www.hlrs.de/people/rabenseifner >>>>> Nobelstr. 19, D-70550 Stuttgart, Germany . . . . (Office: Room >>>>> 1.307) >>>> >>>> -- >>>> Dr. Rolf Rabenseifner . . . . . . . . . .. email >>>> rabenseifner(a)hlrs.de >>>> High Performance Computing Center (HLRS) . phone >>>> ++49(0)711/685-65530 >>>> University of Stuttgart . . . . . . . . .. fax ++49(0)711 / >>>> 685-65832 >>>> Head of Dpmt Parallel Computing . . . >>>> www.hlrs.de/people/rabenseifner >>>> Nobelstr. 19, D-70550 Stuttgart, Germany . . . . (Office: Room >>>> 1.307) >>> >>> -- >>> Dr. Rolf Rabenseifner . . . . . . . . . .. email >>> rabenseifner(a)hlrs.de >>> High Performance Computing Center (HLRS) . phone >>> ++49(0)711/685-65530 >>> University of Stuttgart . . . . . . . . .. fax ++49(0)711 / >>> 685-65832 >>> Head of Dpmt Parallel Computing . . . >>> www.hlrs.de/people/rabenseifner >>> Nobelstr. 19, D-70550 Stuttgart, Germany . . . . (Office: Room >>> 1.307) >> >> -- >> Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner(a)hlrs.de >> High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530 >> University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832 >> Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner >> Nobelstr. 19, D-70550 Stuttgart, Germany . . . . (Office: Room 1.307) > > -- > Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner(a)hlrs.de > High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530 > University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832 > Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner > Nobelstr. 19, D-70550 Stuttgart, Germany . . . . (Office: Room 1.307) > _______________________________________________ > mpiwg-fortran mailing list > mpiwg-fortran(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran

1 0

Re: [MPIWG Fortran] MPI-3 ticket 349: Fortran question
by Rolf Rabenseifner 20 Dec '13

20 Dec '13

Hi Jim, > I don't think that the proposal is in conflict with sections 2.5.6 or > 4.1.5. These sections are talking about addresses and not > specifically about how one can use the MPI_Aint type. We mean to > address only the latter item -- correct usage of the MPI address > integer type. I also do not see a conflict. But I see that the new concept must be explained within these sections. This is about consistency of the whole MPI document. > In terms of where to put the proposed text in the chapter, I suggest > we make that a separate discussion, once the technical issues have > been resolved. As you mentioned below, technically there are two solutions: A. require that disp=addr2-addr1 and addr2=addr1+disp can be calculated with the intrinsic arithmetic operations - and +. This would require: 128 bit MPI_Aint on a system that - uses full 64 bit absolute addresses, AND - does not have one-s complement arithmetic AND - MPI_BOTTOM is not defined in the middle B. require that disp=addr2-addr1 and addr2=addr1+disp is calculated with your two new functions to guarantee that always 64 bits signed MPI_Aint are enough to store any 64 bit unsigned absolute addresses. If we decide A, then only an advice to implementers would be fine. If we decide B, then several "corrections" are needed. > I do have a concern, in particular, about section 4.1.12, "Correct > use of Addresses", which seems to suggest that one should be able to > do arithmetic directly on absolute addresses stored in address > integers. The only way that this could be supported on some > platforms (e.g. one's complement integers) is to make the MPI_Aint > an integer that is larger than an address, so that > overflow/underflow cannot occur. Because of Fortran's dynamic > MPI_BOTTOM, address integers on such a platform would have to be > 128-bits to ensure that there can be no overflow. > > What's your take on that section? The notations MPI-3.0 page 115 lines 42 and 47 v+i and u-v need not to be interpreted as C and Fortran + and -. One could say that there is a lack of not having defined these operations. I principle, you are right when you expect (as all MPI-readers so far) that + and - on these lines are C and Fortran + and -, and therefore, solution A is required. Note that solution A is not the worst because our systems have IEEE data representation which has one's complements and therefore no Need for doubling the size of MPI_Aint, especially on the pure 32-bit Blue-Gene Systems. If one wants to go with B (and this is a free Forum decision) then one should add text to > MPI-3.0 Sect. 2.5.6, page 16 lines 30-37 and > MPI-3.0 Sect. 4.1.5, page 102 lines 28-35 and also to - MPI 3.0 Sect. 4.1.12, page 115 line 48, e.g., "Note that v+i and u-v need to be calculated with MPI_AINT_ADD and MPI_AINT_DIFF." And the two new routines after page 103 line 46. My mails only try to help that proposal B is fully complete and consistent. They are not about whether I would like to have A or B. Because A continues to stay a work-around for B, I would be happy with B. Best regards Rolf ----- Original Message ----- > From: "Jim Dinan" <james.dinan(a)gmail.com> > To: "Rolf Rabenseifner" <rabenseifner(a)hlrs.de> > Cc: "MPI-WG Fortran working group" <mpiwg-fortran(a)lists.mpi-forum.org>, "longb" <longb(a)cray.com> > Sent: Thursday, December 19, 2013 9:55:42 PM > Subject: Re: [MPIWG Fortran] MPI-3 ticket 349: Fortran question > > > Hi Rolf, > > > I don't think that the proposal is in conflict with sections 2.5.6 or > 4.1.5. These sections are talking about addresses and not > specifically about how one can use the MPI_Aint type. We mean to > address only the latter item -- correct usage of the MPI address > integer type. > > > In terms of where to put the proposed text in the chapter, I suggest > we make that a separate discussion, once the technical issues have > been resolved. > > > I do have a concern, in particular, about section 4.1.12, "Correct > use of Addresses", which seems to suggest that one should be able to > do arithmetic directly on absolute addresses stored in address > integers. The only way that this could be supported on some > platforms (e.g. one's complement integers) is to make the MPI_Aint > an integer that is larger than an address, so that > overflow/underflow cannot occur. Because of Fortran's dynamic > MPI_BOTTOM, address integers on such a platform would have to be > 128-bits to ensure that there can be no overflow. > > > What's your take on that section? > > > ~Jim. > > > > On Fri, Dec 13, 2013 at 9:11 AM, Rolf Rabenseifner < > rabenseifner(a)hlrs.de > wrote: > > > Jim, > > > > Could you provide a list of the specific changes that you feel are > > needed on these tickets? > > I expected that you are doining this. > I only want to mention the locations. > > Your new model differentiates beween > - absolute addresses generated from locations with MPI_GET_ADDRESS > - relative displacements as differences of two absolute addresses > and the needed arithmetic > - relative displacements with normal + - * arithmetic > - absolute addresses and displacments with > MPI_AINT_ADD and MPI_AINT_DIFF arithmetic > > Therefore: > MPI-3.0 Sect. 2.5.6, page 16 lines 30-37 and > MPI-3.0 Sect. 4.1.5, page 102 lines 28-35 > should reflect this differentiation. > > The proposed rationale in #349 may go at the end of page 102 lines > 28-35. > After MPI-3.0 Sect. 4.1.5, page 103 line 46, you should add > MPI_AINT_ADD and MPI_AINT_DIFF. > > > Best regards > Rolf > > > > ----- Original Message ----- > > From: "Jim Dinan" < james.dinan(a)gmail.com > > > To: "Rolf Rabenseifner" < rabenseifner(a)hlrs.de > > > Cc: "MPI-WG Fortran working group" < > > mpiwg-fortran(a)lists.mpi-forum.org >, "longb" < longb(a)cray.com > > > > > Sent: Friday, December 13, 2013 1:35:13 PM > > Subject: Re: [MPIWG Fortran] MPI-3 ticket 349: Fortran question > > > > > > Rolf, > > > > > > Could you provide a list of the specific changes that you feel are > > needed on these tickets? For reference, and to bring in feedback > > from others on the cc, we are discussing: > > > > > > MPI_Aint_add -- > > https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/349 > > Linked list example updates -- > > https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/402 > > MPI_Aint_diff -- > > https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/404 > > > > > > Let's solve the technical issues first to see where things stand, > > and > > then come back to the issue of how to handle voting on these > > changes. > > > > > > Thank you for helping to improve these tickets! > > > > > > Best, > > ~Jim. > > > > > > > > On Thu, Dec 12, 2013 at 12:34 PM, Rolf Rabenseifner < > > rabenseifner(a)hlrs.de > wrote: > > > > > > Dear Jim, > > > > I would like to disagree. > > Looking at #349, I see wording like "base address" etc. > > whereas MPI-3.0 p102.29 uses "absolute address". > > > > And, the ticket does not show the location of the new text, > > nor all the needed background info. > > > > MPI is a standard document and the proposed change > > (absolute addresses can no longer be used in > > normal arithmetic) should be well prepared. > > > > The current text is not ready. > > > > You start to differentiate between "absolute addresses" > > and "relative displacements" and their use of MPI_Aint. > > > > Please have a look at 2.5.6 on page 16. > > This section should be clarified. > > > > Please try to produce one proposal that is complete > > and fits to the standard. > > Voting in small pieces (several tickets) is not the best. > > > > > > Best regards > > Rolf > > > > ----- Original Message ----- > > > From: "Jim Dinan" < james.dinan(a)gmail.com > > > > To: "Rolf Rabenseifner" < rabenseifner(a)hlrs.de > > > > Cc: "MPI-WG Fortran working group" < > > > mpiwg-fortran(a)lists.mpi-forum.org >, "longb" < longb(a)cray.com >, > > > "Jim Dinan" > > > < dinan(a)mcs.anl.gov > > > > > > > > Sent: Thursday, December 12, 2013 5:51:30 PM > > > Subject: Re: [MPIWG Fortran] MPI-3 ticket 349: Fortran question > > > > > > > > > Hi Rolf, > > > > > > > > > Thanks for the corrections -- I apologize, what I had sent was a > > > very > > > rough draft of the proposal. I applied your changes to the > > > proposal, cleaned some things up, and added the datatypes > > > examples > > > corrections. Could you take another look when you get a chance? > > > > > > > > > In terms of proposal logistics, I would like to let MPI_Aint add > > > and > > > diff tickets progress independently. I agree that they need to > > > be > > > together, and I think we can rely on the chapter committee to > > > handle > > > that if add/diff end up split between two versions of the > > > standard. > > > MPI_Aint_diff should be ready for a reading at the next meeting > > > and > > > MPI_Aint_add will be ready for a first vote. Given the > > > discussion > > > about MPI 3.x/4.0 timeline yesterday, I think the risk of these > > > not > > > being in the same release of the spec is very low. Since the > > > Forum > > > has already done all of the work required to move MPI_Aint_add to > > > a > > > vote, I would prefer not to rewind this process by merging it > > > with > > > the diff ticket. > > > > > > > > > ~Jim. > > > > > > > > > > > > On Thu, Dec 12, 2013 at 9:14 AM, Rolf Rabenseifner < > > > rabenseifner(a)hlrs.de > wrote: > > > > > > > > > Jim and all, > > > > > > MPI_Get_address((char *) addr1 - (char *) addr2, &result) > > > > > > This is really wrong, because (char *) addr1 - (char *) addr2 > > > is not an address and cannot be used as input to MPI_Get_address. > > > > > > (char *) addr1 - (char *) addr2 is a displacement. > > > > > > Both tickets 349 and 404 need to be together, because they > > > are based on a clear distinguishing between > > > - Location in memory (input of MPI_GET_ADDRESS), e.g. x, y > > > - absolute addresses (output of MPI_GET_ADDRESS), e.g., addr_x, > > > addr_y > > > - relative displacements (diff of two absolute addresses), e.g. > > > dist_xy > > > > > > Your new statement is that calculations like > > > dist_xy = addr_y - addr_x > > > addr_y = addr_x + dist_xy > > > need to be done by subroutine calls or functions, > > > because absolute addresses are stored in MPI_Aint variables > > > through some (unknown/strange) mapping, > > > wheras relative displacements are normal unsigned integers > > > that can be used for normal arithmetic. > > > > > > The one ticket must show this clearly and must be integrated into > > > section 4.1.5 > > > > > > > > > Best regards > > > Rolf > > > > > > > > > ----- Original Message ----- > > > > > > > > > > From: "Jim Dinan" < james.dinan(a)gmail.com > > > > > To: "Rolf Rabenseifner" < rabenseifner(a)hlrs.de > > > > > Cc: "MPI-WG Fortran working group" < > > > > mpiwg-fortran(a)lists.mpi-forum.org >, "longb" < longb(a)cray.com > > > > >, > > > > "Jim Dinan" > > > > < dinan(a)mcs.anl.gov > > > > > Sent: Thursday, December 12, 2013 3:20:41 PM > > > > Subject: Re: [MPIWG Fortran] MPI-3 ticket 349: Fortran question > > > > > > > > > > > > Hi Rolf, > > > > > > > > > > > > Thank you very much for the feedback! Sorry if I forgot to > > > > respond; > > > > the comments definitely were not ignored. We discussed the > > > > Aint > > > > difference calculation in the working group and decided to > > > > create > > > > an > > > > additional ticket for MPI_Aint_disp. We did not see a clean > > > > way > > > > to > > > > handle this in MPI_Aint_add, because both arguments need to be > > > > handled as unsigned in the arithmetic. > > > > > > > > > > > > https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/404 > > > > > > > > > > > > > > > > I have a list of fixes the to the datatypes examples that I'll > > > > post > > > > to the ticket soon. > > > > > > > > > > > > Jeff Squyres is also helping us move the MPI_Aint arithmetic > > > > routines > > > > to functions in the Fortran bindings. Should be done today. > > > > > > > > > > > > Were there any other concerns that we missed? > > > > > > > > > > > > Thanks, > > > > ~Jim. > > > > > > > > > > > > > > > > On Thu, Dec 12, 2013 at 1:42 AM, Rolf Rabenseifner < > > > > rabenseifner(a)hlrs.de > wrote: > > > > > > > > > > > > Jeff and Bill, > > > > > > > > < > > > > https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/349#comment:22 > > > > > > > > > was ignored. > > > > The answer seems to be yes and the clear implication is that > > > > we need also a routine to calculate disp := addr2-addr1 > > > > > > > > About the Fortran Interfaces: > > > > We should keep the old style without INTENT, because for the > > > > old-style > > > > the implementor has the freedom to add INTENT as he/she wants > > > > and it is still compliant with the outcome of the definition. > > > > > > > > I do not see, why we have a function in C and a subroutine > > > > in Fortran. > > > > Like MPI_Wtime, in all three languages (C, new and old > > > > Fortran), > > > > we should do the same. > > > > > > > > Best regards > > > > Rolf > > > > > > > > ----- Original Message ----- > > > > > From: "Jeff Squyres (jsquyres)" < jsquyres(a)cisco.com > > > > > > To: "< longb(a)cray.com >" < longb(a)cray.com >, "MPI-WG Fortran > > > > > working group" < mpiwg-fortran(a)lists.mpi-forum.org > > > > > > Sent: Thursday, December 12, 2013 12:17:40 AM > > > > > Subject: Re: [MPIWG Fortran] MPI-3 ticket 349: Fortran > > > > > question > > > > > > > > > > Sounds good to me. > > > > > > > > > > Rolf -- is there any MPI reason we would not want to do this? > > > > > > > > > > > > > > > On Dec 11, 2013, at 4:41 PM, Bill Long < longb(a)cray.com > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > On 12/11/13 11:27 AM, Jeff Squyres (jsquyres) wrote: > > > > > >> This ticket got a formal reading today at the Forum: > > > > > >> > > > > > >> http://svn.mpi-forum.org/trac/mpi-forum-web/ticket/349 > > > > > >> (as of this writing, there's still a BIND(C) in there, > > > > > >> but > > > > > >> it > > > > > >> will be removed shortly) > > > > > >> > > > > > >> The function is basically intended to perform a > > > > > >> mathematical > > > > > >> operation. As such, I think that the 2 Fortran bindings > > > > > >> should > > > > > >> be FUNCTIONs, not SUBROUTINEs (a la MPI_WTICK/MPI_WTIME). > > > > > >> > > > > > >> Do you agree? If so, the ticket author (Jim Dinan) is > > > > > >> amenable > > > > > >> to > > > > > >> changing the Fortran bindings to the following (and I'm > > > > > >> assuming > > > > > >> I have the syntax below correct, but feel free to correct > > > > > >> me > > > > > >> if > > > > > >> they're wrong): > > > > > >> > > > > > > > > > > > > Certainly it makes more sense for these to be functions in > > > > > > Fortran. > > > > > > Particularly if the programmer prefers supply an interface > > > > > > and > > > > > > call the C form directly. If the C and Fortran versions > > > > > > are > > > > > > both > > > > > > functions, there is no change in the source code where the > > > > > > function is used. > > > > > > > > > > > >> ----- > > > > > >> INTEGER(KIND=MPI_ADDRESS_KIND) MPI_Aint_add(base, disp) > > > > > >> INTEGER(KIND=MPI_ADDRESS_KIND), INTENT(IN) :: base, > > > > > >> disp > > > > > >> > > > > > >> INTEGER(KIND=MPI_ADDRESS_KIND) MPI_AINT_ADD(BASE, DISP) > > > > > >> INTEGER(KIND=MPI_ADDRESS_KIND) BASE, DISP > > > > > > > > > > > > It is certainly an oddity that the spec has two forms like > > > > > > this. > > > > > > Any version of the Fortran standard that supports KIND= in > > > > > > INTEGER also supports lower case names and INTENT() > > > > > > attributes. > > > > > > Maybe there could be some clean up of this in a future > > > > > > revision. > > > > > > > > > > > > Cheers, > > > > > > Bill > > > > > > > > > > > > > > > > > > > > > > > >> ----- > > > > > >> > > > > > > > > > > > > -- > > > > > > Bill Long > > > > > > longb(a)cray.com > > > > > > Fortran Technical Support & voice: > > > > > > 651-605-9024 > > > > > > Bioinformatics Software Development fax: > > > > > > 651-605-9142 > > > > > > Cray Inc./Cray Plaza, Suite 210/380 Jackson St./St. Paul, > > > > > > MN > > > > > > 55101 > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > mpiwg-fortran mailing list > > > > > > mpiwg-fortran(a)lists.mpi-forum.org > > > > > > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran > > > > > > > > > > > > > > > -- > > > > > Jeff Squyres > > > > > jsquyres(a)cisco.com > > > > > For corporate legal information go to: > > > > > http://www.cisco.com/web/about/doing_business/legal/cri/ > > > > > > > > > > _______________________________________________ > > > > > mpiwg-fortran mailing list > > > > > mpiwg-fortran(a)lists.mpi-forum.org > > > > > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran > > > > > > > > > > > > > -- > > > > Dr. Rolf Rabenseifner . . . . . . . . . .. email > > > > rabenseifner(a)hlrs.de > > > > High Performance Computing Center (HLRS) . phone > > > > ++49(0)711/685-65530 > > > > University of Stuttgart . . . . . . . . .. fax ++49(0)711 / > > > > 685-65832 > > > > Head of Dpmt Parallel Computing . . . > > > > www.hlrs.de/people/rabenseifner > > > > Nobelstr. 19, D-70550 Stuttgart, Germany . . . . (Office: Room > > > > 1.307) > > > > > > > > > > > > > > -- > > > Dr. Rolf Rabenseifner . . . . . . . . . .. email > > > rabenseifner(a)hlrs.de > > > High Performance Computing Center (HLRS) . phone > > > ++49(0)711/685-65530 > > > University of Stuttgart . . . . . . . . .. fax ++49(0)711 / > > > 685-65832 > > > Head of Dpmt Parallel Computing . . . > > > www.hlrs.de/people/rabenseifner > > > Nobelstr. 19, D-70550 Stuttgart, Germany . . . . (Office: Room > > > 1.307) > > > > > > > > > > -- > > Dr. Rolf Rabenseifner . . . . . . . . . .. email > > rabenseifner(a)hlrs.de > > High Performance Computing Center (HLRS) . phone > > ++49(0)711/685-65530 > > University of Stuttgart . . . . . . . . .. fax ++49(0)711 / > > 685-65832 > > Head of Dpmt Parallel Computing . . . > > www.hlrs.de/people/rabenseifner > > Nobelstr. 19, D-70550 Stuttgart, Germany . . . . (Office: Room > > 1.307) > > > > > > -- > Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner(a)hlrs.de > High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530 > University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832 > Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner > Nobelstr. 19, D-70550 Stuttgart, Germany . . . . (Office: Room 1.307) > > -- Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner(a)hlrs.de High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530 University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832 Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner Nobelstr. 19, D-70550 Stuttgart, Germany . . . . (Office: Room 1.307)

1 0

Re: [MPIWG Fortran] MPI-3 ticket 349: Fortran question
by Jim Dinan 19 Dec '13

19 Dec '13

Hi Rolf, I don't think that the proposal is in conflict with sections 2.5.6 or 4.1.5. These sections are talking about addresses and not specifically about how one can use the MPI_Aint type. We mean to address only the latter item -- correct usage of the MPI address integer type. In terms of where to put the proposed text in the chapter, I suggest we make that a separate discussion, once the technical issues have been resolved. I do have a concern, in particular, about section 4.1.12, "Correct use of Addresses", which seems to suggest that one should be able to do arithmetic directly on absolute addresses stored in address integers. The only way that this could be supported on some platforms (e.g. one's complement integers) is to make the MPI_Aint an integer that is larger than an address, so that overflow/underflow cannot occur. Because of Fortran's dynamic MPI_BOTTOM, address integers on such a platform would have to be 128-bits to ensure that there can be no overflow. What's your take on that section? ~Jim. On Fri, Dec 13, 2013 at 9:11 AM, Rolf Rabenseifner <rabenseifner(a)hlrs.de>wrote: > Jim, > > > Could you provide a list of the specific changes that you feel are > > needed on these tickets? > > I expected that you are doining this. > I only want to mention the locations. > > Your new model differentiates beween > - absolute addresses generated from locations with MPI_GET_ADDRESS > - relative displacements as differences of two absolute addresses > and the needed arithmetic > - relative displacements with normal + - * arithmetic > - absolute addresses and displacments with > MPI_AINT_ADD and MPI_AINT_DIFF arithmetic > > Therefore: > MPI-3.0 Sect. 2.5.6, page 16 lines 30-37 and > MPI-3.0 Sect. 4.1.5, page 102 lines 28-35 > should reflect this differentiation. > > The proposed rationale in #349 may go at the end of page 102 lines 28-35. > After MPI-3.0 Sect. 4.1.5, page 103 line 46, you should add > MPI_AINT_ADD and MPI_AINT_DIFF. > > Best regards > Rolf > > > > ----- Original Message ----- > > From: "Jim Dinan" <james.dinan(a)gmail.com> > > To: "Rolf Rabenseifner" <rabenseifner(a)hlrs.de> > > Cc: "MPI-WG Fortran working group" <mpiwg-fortran(a)lists.mpi-forum.org>, > "longb" <longb(a)cray.com> > > Sent: Friday, December 13, 2013 1:35:13 PM > > Subject: Re: [MPIWG Fortran] MPI-3 ticket 349: Fortran question > > > > > > Rolf, > > > > > > Could you provide a list of the specific changes that you feel are > > needed on these tickets? For reference, and to bring in feedback > > from others on the cc, we are discussing: > > > > > > MPI_Aint_add -- > > https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/349 > > Linked list example updates -- > > https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/402 > > MPI_Aint_diff -- > > https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/404 > > > > > > Let's solve the technical issues first to see where things stand, and > > then come back to the issue of how to handle voting on these > > changes. > > > > > > Thank you for helping to improve these tickets! > > > > > > Best, > > ~Jim. > > > > > > > > On Thu, Dec 12, 2013 at 12:34 PM, Rolf Rabenseifner < > > rabenseifner(a)hlrs.de > wrote: > > > > > > Dear Jim, > > > > I would like to disagree. > > Looking at #349, I see wording like "base address" etc. > > whereas MPI-3.0 p102.29 uses "absolute address". > > > > And, the ticket does not show the location of the new text, > > nor all the needed background info. > > > > MPI is a standard document and the proposed change > > (absolute addresses can no longer be used in > > normal arithmetic) should be well prepared. > > > > The current text is not ready. > > > > You start to differentiate between "absolute addresses" > > and "relative displacements" and their use of MPI_Aint. > > > > Please have a look at 2.5.6 on page 16. > > This section should be clarified. > > > > Please try to produce one proposal that is complete > > and fits to the standard. > > Voting in small pieces (several tickets) is not the best. > > > > > > Best regards > > Rolf > > > > ----- Original Message ----- > > > From: "Jim Dinan" < james.dinan(a)gmail.com > > > > To: "Rolf Rabenseifner" < rabenseifner(a)hlrs.de > > > > Cc: "MPI-WG Fortran working group" < > > > mpiwg-fortran(a)lists.mpi-forum.org >, "longb" < longb(a)cray.com >, > > > "Jim Dinan" > > > < dinan(a)mcs.anl.gov > > > > > > > > Sent: Thursday, December 12, 2013 5:51:30 PM > > > Subject: Re: [MPIWG Fortran] MPI-3 ticket 349: Fortran question > > > > > > > > > Hi Rolf, > > > > > > > > > Thanks for the corrections -- I apologize, what I had sent was a > > > very > > > rough draft of the proposal. I applied your changes to the > > > proposal, cleaned some things up, and added the datatypes examples > > > corrections. Could you take another look when you get a chance? > > > > > > > > > In terms of proposal logistics, I would like to let MPI_Aint add > > > and > > > diff tickets progress independently. I agree that they need to be > > > together, and I think we can rely on the chapter committee to > > > handle > > > that if add/diff end up split between two versions of the standard. > > > MPI_Aint_diff should be ready for a reading at the next meeting > > > and > > > MPI_Aint_add will be ready for a first vote. Given the discussion > > > about MPI 3.x/4.0 timeline yesterday, I think the risk of these not > > > being in the same release of the spec is very low. Since the Forum > > > has already done all of the work required to move MPI_Aint_add to a > > > vote, I would prefer not to rewind this process by merging it with > > > the diff ticket. > > > > > > > > > ~Jim. > > > > > > > > > > > > On Thu, Dec 12, 2013 at 9:14 AM, Rolf Rabenseifner < > > > rabenseifner(a)hlrs.de > wrote: > > > > > > > > > Jim and all, > > > > > > MPI_Get_address((char *) addr1 - (char *) addr2, &result) > > > > > > This is really wrong, because (char *) addr1 - (char *) addr2 > > > is not an address and cannot be used as input to MPI_Get_address. > > > > > > (char *) addr1 - (char *) addr2 is a displacement. > > > > > > Both tickets 349 and 404 need to be together, because they > > > are based on a clear distinguishing between > > > - Location in memory (input of MPI_GET_ADDRESS), e.g. x, y > > > - absolute addresses (output of MPI_GET_ADDRESS), e.g., addr_x, > > > addr_y > > > - relative displacements (diff of two absolute addresses), e.g. > > > dist_xy > > > > > > Your new statement is that calculations like > > > dist_xy = addr_y - addr_x > > > addr_y = addr_x + dist_xy > > > need to be done by subroutine calls or functions, > > > because absolute addresses are stored in MPI_Aint variables > > > through some (unknown/strange) mapping, > > > wheras relative displacements are normal unsigned integers > > > that can be used for normal arithmetic. > > > > > > The one ticket must show this clearly and must be integrated into > > > section 4.1.5 > > > > > > > > > Best regards > > > Rolf > > > > > > > > > ----- Original Message ----- > > > > > > > > > > From: "Jim Dinan" < james.dinan(a)gmail.com > > > > > To: "Rolf Rabenseifner" < rabenseifner(a)hlrs.de > > > > > Cc: "MPI-WG Fortran working group" < > > > > mpiwg-fortran(a)lists.mpi-forum.org >, "longb" < longb(a)cray.com >, > > > > "Jim Dinan" > > > > < dinan(a)mcs.anl.gov > > > > > Sent: Thursday, December 12, 2013 3:20:41 PM > > > > Subject: Re: [MPIWG Fortran] MPI-3 ticket 349: Fortran question > > > > > > > > > > > > Hi Rolf, > > > > > > > > > > > > Thank you very much for the feedback! Sorry if I forgot to > > > > respond; > > > > the comments definitely were not ignored. We discussed the Aint > > > > difference calculation in the working group and decided to create > > > > an > > > > additional ticket for MPI_Aint_disp. We did not see a clean way > > > > to > > > > handle this in MPI_Aint_add, because both arguments need to be > > > > handled as unsigned in the arithmetic. > > > > > > > > > > > > https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/404 > > > > > > > > > > > > > > > > I have a list of fixes the to the datatypes examples that I'll > > > > post > > > > to the ticket soon. > > > > > > > > > > > > Jeff Squyres is also helping us move the MPI_Aint arithmetic > > > > routines > > > > to functions in the Fortran bindings. Should be done today. > > > > > > > > > > > > Were there any other concerns that we missed? > > > > > > > > > > > > Thanks, > > > > ~Jim. > > > > > > > > > > > > > > > > On Thu, Dec 12, 2013 at 1:42 AM, Rolf Rabenseifner < > > > > rabenseifner(a)hlrs.de > wrote: > > > > > > > > > > > > Jeff and Bill, > > > > > > > > < > > > > https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/349#comment:22 > > > > > > > > > was ignored. > > > > The answer seems to be yes and the clear implication is that > > > > we need also a routine to calculate disp := addr2-addr1 > > > > > > > > About the Fortran Interfaces: > > > > We should keep the old style without INTENT, because for the > > > > old-style > > > > the implementor has the freedom to add INTENT as he/she wants > > > > and it is still compliant with the outcome of the definition. > > > > > > > > I do not see, why we have a function in C and a subroutine > > > > in Fortran. > > > > Like MPI_Wtime, in all three languages (C, new and old Fortran), > > > > we should do the same. > > > > > > > > Best regards > > > > Rolf > > > > > > > > ----- Original Message ----- > > > > > From: "Jeff Squyres (jsquyres)" < jsquyres(a)cisco.com > > > > > > To: "< longb(a)cray.com >" < longb(a)cray.com >, "MPI-WG Fortran > > > > > working group" < mpiwg-fortran(a)lists.mpi-forum.org > > > > > > Sent: Thursday, December 12, 2013 12:17:40 AM > > > > > Subject: Re: [MPIWG Fortran] MPI-3 ticket 349: Fortran question > > > > > > > > > > Sounds good to me. > > > > > > > > > > Rolf -- is there any MPI reason we would not want to do this? > > > > > > > > > > > > > > > On Dec 11, 2013, at 4:41 PM, Bill Long < longb(a)cray.com > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > On 12/11/13 11:27 AM, Jeff Squyres (jsquyres) wrote: > > > > > >> This ticket got a formal reading today at the Forum: > > > > > >> > > > > > >> http://svn.mpi-forum.org/trac/mpi-forum-web/ticket/349 > > > > > >> (as of this writing, there's still a BIND(C) in there, > > > > > >> but > > > > > >> it > > > > > >> will be removed shortly) > > > > > >> > > > > > >> The function is basically intended to perform a mathematical > > > > > >> operation. As such, I think that the 2 Fortran bindings > > > > > >> should > > > > > >> be FUNCTIONs, not SUBROUTINEs (a la MPI_WTICK/MPI_WTIME). > > > > > >> > > > > > >> Do you agree? If so, the ticket author (Jim Dinan) is > > > > > >> amenable > > > > > >> to > > > > > >> changing the Fortran bindings to the following (and I'm > > > > > >> assuming > > > > > >> I have the syntax below correct, but feel free to correct me > > > > > >> if > > > > > >> they're wrong): > > > > > >> > > > > > > > > > > > > Certainly it makes more sense for these to be functions in > > > > > > Fortran. > > > > > > Particularly if the programmer prefers supply an interface > > > > > > and > > > > > > call the C form directly. If the C and Fortran versions are > > > > > > both > > > > > > functions, there is no change in the source code where the > > > > > > function is used. > > > > > > > > > > > >> ----- > > > > > >> INTEGER(KIND=MPI_ADDRESS_KIND) MPI_Aint_add(base, disp) > > > > > >> INTEGER(KIND=MPI_ADDRESS_KIND), INTENT(IN) :: base, > > > > > >> disp > > > > > >> > > > > > >> INTEGER(KIND=MPI_ADDRESS_KIND) MPI_AINT_ADD(BASE, DISP) > > > > > >> INTEGER(KIND=MPI_ADDRESS_KIND) BASE, DISP > > > > > > > > > > > > It is certainly an oddity that the spec has two forms like > > > > > > this. > > > > > > Any version of the Fortran standard that supports KIND= in > > > > > > INTEGER also supports lower case names and INTENT() > > > > > > attributes. > > > > > > Maybe there could be some clean up of this in a future > > > > > > revision. > > > > > > > > > > > > Cheers, > > > > > > Bill > > > > > > > > > > > > > > > > > > > > > > > >> ----- > > > > > >> > > > > > > > > > > > > -- > > > > > > Bill Long > > > > > > longb(a)cray.com > > > > > > Fortran Technical Support & voice: > > > > > > 651-605-9024 > > > > > > Bioinformatics Software Development fax: > > > > > > 651-605-9142 > > > > > > Cray Inc./Cray Plaza, Suite 210/380 Jackson St./St. Paul, MN > > > > > > 55101 > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > mpiwg-fortran mailing list > > > > > > mpiwg-fortran(a)lists.mpi-forum.org > > > > > > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran > > > > > > > > > > > > > > > -- > > > > > Jeff Squyres > > > > > jsquyres(a)cisco.com > > > > > For corporate legal information go to: > > > > > http://www.cisco.com/web/about/doing_business/legal/cri/ > > > > > > > > > > _______________________________________________ > > > > > mpiwg-fortran mailing list > > > > > mpiwg-fortran(a)lists.mpi-forum.org > > > > > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran > > > > > > > > > > > > > -- > > > > Dr. Rolf Rabenseifner . . . . . . . . . .. email > > > > rabenseifner(a)hlrs.de > > > > High Performance Computing Center (HLRS) . phone > > > > ++49(0)711/685-65530 > > > > University of Stuttgart . . . . . . . . .. fax ++49(0)711 / > > > > 685-65832 > > > > Head of Dpmt Parallel Computing . . . > > > > www.hlrs.de/people/rabenseifner > > > > Nobelstr. 19, D-70550 Stuttgart, Germany . . . . (Office: Room > > > > 1.307) > > > > > > > > > > > > > > -- > > > Dr. Rolf Rabenseifner . . . . . . . . . .. email > > > rabenseifner(a)hlrs.de > > > High Performance Computing Center (HLRS) . phone > > > ++49(0)711/685-65530 > > > University of Stuttgart . . . . . . . . .. fax ++49(0)711 / > > > 685-65832 > > > Head of Dpmt Parallel Computing . . . > > > www.hlrs.de/people/rabenseifner > > > Nobelstr. 19, D-70550 Stuttgart, Germany . . . . (Office: Room > > > 1.307) > > > > > > > > > > -- > > Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner(a)hlrs.de > > High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530 > > University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832 > > Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner > > Nobelstr. 19, D-70550 Stuttgart, Germany . . . . (Office: Room 1.307) > > > > > > -- > Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner(a)hlrs.de > High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530 > University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832 > Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner > Nobelstr. 19, D-70550 Stuttgart, Germany . . . . (Office: Room 1.307) >

1 0

Re: [MPIWG Fortran] MPI-3 ticket 349: Fortran question
by Hubert Ritzdorf 15 Dec '13

15 Dec '13

Hi, in Fortran, MPI_Get_address always returns displacements to MPI_BOTTOM, no absolute addresses. And the displacement might be negative. Hubert -----Original Message----- From: mpiwg-fortran [mailto:[email protected]] On Behalf Of Rolf Rabenseifner Sent: Friday, December 13, 2013 15:12 To: Jim Dinan Cc: MPI-WG Fortran working group Subject: Re: [MPIWG Fortran] MPI-3 ticket 349: Fortran question Jim, > Could you provide a list of the specific changes that you feel are > needed on these tickets? I expected that you are doining this. I only want to mention the locations. Your new model differentiates beween - absolute addresses generated from locations with MPI_GET_ADDRESS - relative displacements as differences of two absolute addresses and the needed arithmetic - relative displacements with normal + - * arithmetic - absolute addresses and displacments with MPI_AINT_ADD and MPI_AINT_DIFF arithmetic Therefore: MPI-3.0 Sect. 2.5.6, page 16 lines 30-37 and MPI-3.0 Sect. 4.1.5, page 102 lines 28-35 should reflect this differentiation. The proposed rationale in #349 may go at the end of page 102 lines 28-35. After MPI-3.0 Sect. 4.1.5, page 103 line 46, you should add MPI_AINT_ADD and MPI_AINT_DIFF. Best regards Rolf ----- Original Message ----- > From: "Jim Dinan" <james.dinan(a)gmail.com> > To: "Rolf Rabenseifner" <rabenseifner(a)hlrs.de> > Cc: "MPI-WG Fortran working group" > <mpiwg-fortran(a)lists.mpi-forum.org>, "longb" <longb(a)cray.com> > Sent: Friday, December 13, 2013 1:35:13 PM > Subject: Re: [MPIWG Fortran] MPI-3 ticket 349: Fortran question > > > Rolf, > > > Could you provide a list of the specific changes that you feel are > needed on these tickets? For reference, and to bring in feedback from > others on the cc, we are discussing: > > > MPI_Aint_add -- > https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/349 > Linked list example updates -- > https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/402 > MPI_Aint_diff -- > https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/404 > > > Let's solve the technical issues first to see where things stand, and > then come back to the issue of how to handle voting on these > changes. > > > Thank you for helping to improve these tickets! > > > Best, > ~Jim. > > > > On Thu, Dec 12, 2013 at 12:34 PM, Rolf Rabenseifner < > rabenseifner(a)hlrs.de > wrote: > > > Dear Jim, > > I would like to disagree. > Looking at #349, I see wording like "base address" etc. > whereas MPI-3.0 p102.29 uses "absolute address". > > And, the ticket does not show the location of the new text, > nor all the needed background info. > > MPI is a standard document and the proposed change > (absolute addresses can no longer be used in > normal arithmetic) should be well prepared. > > The current text is not ready. > > You start to differentiate between "absolute addresses" > and "relative displacements" and their use of MPI_Aint. > > Please have a look at 2.5.6 on page 16. > This section should be clarified. > > Please try to produce one proposal that is complete > and fits to the standard. > Voting in small pieces (several tickets) is not the best. > > > Best regards > Rolf > > ----- Original Message ----- > > From: "Jim Dinan" < james.dinan(a)gmail.com > > > To: "Rolf Rabenseifner" < rabenseifner(a)hlrs.de > > > Cc: "MPI-WG Fortran working group" < > > mpiwg-fortran(a)lists.mpi-forum.org >, "longb" < longb(a)cray.com >, > > "Jim Dinan" > > < dinan(a)mcs.anl.gov > > > > > Sent: Thursday, December 12, 2013 5:51:30 PM > > Subject: Re: [MPIWG Fortran] MPI-3 ticket 349: Fortran question > > > > > > Hi Rolf, > > > > > > Thanks for the corrections -- I apologize, what I had sent was a > > very > > rough draft of the proposal. I applied your changes to the > > proposal, cleaned some things up, and added the datatypes examples > > corrections. Could you take another look when you get a chance? > > > > > > In terms of proposal logistics, I would like to let MPI_Aint add > > and > > diff tickets progress independently. I agree that they need to be > > together, and I think we can rely on the chapter committee to > > handle > > that if add/diff end up split between two versions of the standard. > > MPI_Aint_diff should be ready for a reading at the next meeting > > and > > MPI_Aint_add will be ready for a first vote. Given the discussion > > about MPI 3.x/4.0 timeline yesterday, I think the risk of these not > > being in the same release of the spec is very low. Since the Forum > > has already done all of the work required to move MPI_Aint_add to a > > vote, I would prefer not to rewind this process by merging it with > > the diff ticket. > > > > > > ~Jim. > > > > > > > > On Thu, Dec 12, 2013 at 9:14 AM, Rolf Rabenseifner < > > rabenseifner(a)hlrs.de > wrote: > > > > > > Jim and all, > > > > MPI_Get_address((char *) addr1 - (char *) addr2, &result) > > > > This is really wrong, because (char *) addr1 - (char *) addr2 > > is not an address and cannot be used as input to MPI_Get_address. > > > > (char *) addr1 - (char *) addr2 is a displacement. > > > > Both tickets 349 and 404 need to be together, because they > > are based on a clear distinguishing between > > - Location in memory (input of MPI_GET_ADDRESS), e.g. x, y > > - absolute addresses (output of MPI_GET_ADDRESS), e.g., addr_x, > > addr_y > > - relative displacements (diff of two absolute addresses), e.g. > > dist_xy > > > > Your new statement is that calculations like > > dist_xy = addr_y - addr_x > > addr_y = addr_x + dist_xy > > need to be done by subroutine calls or functions, > > because absolute addresses are stored in MPI_Aint variables > > through some (unknown/strange) mapping, > > wheras relative displacements are normal unsigned integers > > that can be used for normal arithmetic. > > > > The one ticket must show this clearly and must be integrated into > > section 4.1.5 > > > > > > Best regards > > Rolf > > > > > > ----- Original Message ----- > > > > > > > From: "Jim Dinan" < james.dinan(a)gmail.com > > > > To: "Rolf Rabenseifner" < rabenseifner(a)hlrs.de > > > > Cc: "MPI-WG Fortran working group" < > > > mpiwg-fortran(a)lists.mpi-forum.org >, "longb" < longb(a)cray.com >, > > > "Jim Dinan" > > > < dinan(a)mcs.anl.gov > > > > Sent: Thursday, December 12, 2013 3:20:41 PM > > > Subject: Re: [MPIWG Fortran] MPI-3 ticket 349: Fortran question > > > > > > > > > Hi Rolf, > > > > > > > > > Thank you very much for the feedback! Sorry if I forgot to > > > respond; > > > the comments definitely were not ignored. We discussed the Aint > > > difference calculation in the working group and decided to create > > > an > > > additional ticket for MPI_Aint_disp. We did not see a clean way > > > to > > > handle this in MPI_Aint_add, because both arguments need to be > > > handled as unsigned in the arithmetic. > > > > > > > > > https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/404 > > > > > > > > > > > > I have a list of fixes the to the datatypes examples that I'll > > > post > > > to the ticket soon. > > > > > > > > > Jeff Squyres is also helping us move the MPI_Aint arithmetic > > > routines > > > to functions in the Fortran bindings. Should be done today. > > > > > > > > > Were there any other concerns that we missed? > > > > > > > > > Thanks, > > > ~Jim. > > > > > > > > > > > > On Thu, Dec 12, 2013 at 1:42 AM, Rolf Rabenseifner < > > > rabenseifner(a)hlrs.de > wrote: > > > > > > > > > Jeff and Bill, > > > > > > < > > > https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/349#comment:22 > > > > > > > was ignored. > > > The answer seems to be yes and the clear implication is that > > > we need also a routine to calculate disp := addr2-addr1 > > > > > > About the Fortran Interfaces: > > > We should keep the old style without INTENT, because for the > > > old-style > > > the implementor has the freedom to add INTENT as he/she wants > > > and it is still compliant with the outcome of the definition. > > > > > > I do not see, why we have a function in C and a subroutine > > > in Fortran. > > > Like MPI_Wtime, in all three languages (C, new and old Fortran), > > > we should do the same. > > > > > > Best regards > > > Rolf > > > > > > ----- Original Message ----- > > > > From: "Jeff Squyres (jsquyres)" < jsquyres(a)cisco.com > > > > > To: "< longb(a)cray.com >" < longb(a)cray.com >, "MPI-WG Fortran > > > > working group" < mpiwg-fortran(a)lists.mpi-forum.org > > > > > Sent: Thursday, December 12, 2013 12:17:40 AM > > > > Subject: Re: [MPIWG Fortran] MPI-3 ticket 349: Fortran question > > > > > > > > Sounds good to me. > > > > > > > > Rolf -- is there any MPI reason we would not want to do this? > > > > > > > > > > > > On Dec 11, 2013, at 4:41 PM, Bill Long < longb(a)cray.com > > > > > wrote: > > > > > > > > > > > > > > > > > > > On 12/11/13 11:27 AM, Jeff Squyres (jsquyres) wrote: > > > > >> This ticket got a formal reading today at the Forum: > > > > >> > > > > >> http://svn.mpi-forum.org/trac/mpi-forum-web/ticket/349 > > > > >> (as of this writing, there's still a BIND(C) in there, > > > > >> but > > > > >> it > > > > >> will be removed shortly) > > > > >> > > > > >> The function is basically intended to perform a mathematical > > > > >> operation. As such, I think that the 2 Fortran bindings > > > > >> should > > > > >> be FUNCTIONs, not SUBROUTINEs (a la MPI_WTICK/MPI_WTIME). > > > > >> > > > > >> Do you agree? If so, the ticket author (Jim Dinan) is > > > > >> amenable > > > > >> to > > > > >> changing the Fortran bindings to the following (and I'm > > > > >> assuming > > > > >> I have the syntax below correct, but feel free to correct me > > > > >> if > > > > >> they're wrong): > > > > >> > > > > > > > > > > Certainly it makes more sense for these to be functions in > > > > > Fortran. > > > > > Particularly if the programmer prefers supply an interface > > > > > and > > > > > call the C form directly. If the C and Fortran versions are > > > > > both > > > > > functions, there is no change in the source code where the > > > > > function is used. > > > > > > > > > >> ----- > > > > >> INTEGER(KIND=MPI_ADDRESS_KIND) MPI_Aint_add(base, disp) > > > > >> INTEGER(KIND=MPI_ADDRESS_KIND), INTENT(IN) :: base, > > > > >> disp > > > > >> > > > > >> INTEGER(KIND=MPI_ADDRESS_KIND) MPI_AINT_ADD(BASE, DISP) > > > > >> INTEGER(KIND=MPI_ADDRESS_KIND) BASE, DISP > > > > > > > > > > It is certainly an oddity that the spec has two forms like > > > > > this. > > > > > Any version of the Fortran standard that supports KIND= in > > > > > INTEGER also supports lower case names and INTENT() > > > > > attributes. > > > > > Maybe there could be some clean up of this in a future > > > > > revision. > > > > > > > > > > Cheers, > > > > > Bill > > > > > > > > > > > > > > > > > > > >> ----- > > > > >> > > > > > > > > > > -- > > > > > Bill Long > > > > > longb(a)cray.com > > > > > Fortran Technical Support & voice: > > > > > 651-605-9024 > > > > > Bioinformatics Software Development fax: > > > > > 651-605-9142 > > > > > Cray Inc./Cray Plaza, Suite 210/380 Jackson St./St. Paul, MN > > > > > 55101 > > > > > > > > > > > > > > > _______________________________________________ > > > > > mpiwg-fortran mailing list > > > > > mpiwg-fortran(a)lists.mpi-forum.org > > > > > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran > > > > > > > > > > > > -- > > > > Jeff Squyres > > > > jsquyres(a)cisco.com > > > > For corporate legal information go to: > > > > http://www.cisco.com/web/about/doing_business/legal/cri/ > > > > > > > > _______________________________________________ > > > > mpiwg-fortran mailing list > > > > mpiwg-fortran(a)lists.mpi-forum.org > > > > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran > > > > > > > > > > -- > > > Dr. Rolf Rabenseifner . . . . . . . . . .. email > > > rabenseifner(a)hlrs.de > > > High Performance Computing Center (HLRS) . phone > > > ++49(0)711/685-65530 > > > University of Stuttgart . . . . . . . . .. fax ++49(0)711 / > > > 685-65832 > > > Head of Dpmt Parallel Computing . . . > > > www.hlrs.de/people/rabenseifner > > > Nobelstr. 19, D-70550 Stuttgart, Germany . . . . (Office: Room > > > 1.307) > > > > > > > > > > -- > > Dr. Rolf Rabenseifner . . . . . . . . . .. email > > rabenseifner(a)hlrs.de > > High Performance Computing Center (HLRS) . phone > > ++49(0)711/685-65530 > > University of Stuttgart . . . . . . . . .. fax ++49(0)711 / > > 685-65832 > > Head of Dpmt Parallel Computing . . . > > www.hlrs.de/people/rabenseifner > > Nobelstr. 19, D-70550 Stuttgart, Germany . . . . (Office: Room > > 1.307) > > > > > > -- > Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner(a)hlrs.de > High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530 > University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832 > Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner > Nobelstr. 19, D-70550 Stuttgart, Germany . . . . (Office: Room 1.307) > > -- Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner(a)hlrs.de High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530 University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832 Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner Nobelstr. 19, D-70550 Stuttgart, Germany . . . . (Office: Room 1.307) _______________________________________________ mpiwg-fortran mailing list mpiwg-fortran(a)lists.mpi-forum.org http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran Click https://www.mailcontrol.com/sr/WOiEKpKwIF3GX2PQPOmvUpnwDS3JbRsA4j48mDqyvwR!… to report this email as spam.

1 0

Re: [MPIWG Fortran] Doodle for WG meeting next week
by Jeff Squyres (jsquyres) 13 Dec '13

13 Dec '13

Thanks everyone for filling it out. I sent out a calendar invite to each of you for next Thursday, December 19, at 1pm US Eastern time. On Dec 13, 2013, at 7:07 AM, Jeff Squyres (jsquyres) <jsquyres(a)cisco.com> wrote: > Please fill out the doodle to find a time where we can all meet: > > http://doodle.com/ryzp6wscsi3kwum3 > > -- > Jeff Squyres > jsquyres(a)cisco.com > For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/ > > _______________________________________________ > mpiwg-fortran mailing list > mpiwg-fortran(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran -- Jeff Squyres jsquyres(a)cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/

1 0