20 Dec
2013
20 Dec
'13
7:35 a.m.
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 <[email protected]> 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" <[email protected]> >> To: "Rolf Rabenseifner" <[email protected]> >> Cc: "MPI-WG Fortran working group" <[email protected]>, "longb" <[email protected]> >> 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 < >> [email protected] > 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" < [email protected] > >>> To: "Rolf Rabenseifner" < [email protected] > >>> Cc: "MPI-WG Fortran working group" < >>> [email protected] >, "longb" < [email protected] > >> >> >>> 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 < >>> [email protected] > 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" < [email protected] > >>>> To: "Rolf Rabenseifner" < [email protected] > >>>> Cc: "MPI-WG Fortran working group" < >>>> [email protected] >, "longb" < [email protected] >, >>>> "Jim Dinan" >>>> < [email protected] > >>> >>> >>>> 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 < >>>> [email protected] > 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" < [email protected] > >>>>> To: "Rolf Rabenseifner" < [email protected] > >>>>> Cc: "MPI-WG Fortran working group" < >>>>> [email protected] >, "longb" < [email protected] >>>>>> , >>>>> "Jim Dinan" >>>>> < [email protected] > >>>>> 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 < >>>>> [email protected] > 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)" < [email protected] > >>>>>> To: "< [email protected] >" < [email protected] >, "MPI-WG Fortran >>>>>> working group" < [email protected] > >>>>>> 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 < [email protected] > >>>>>> 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 >>>>>>> [email protected] >>>>>>> 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 >>>>>>> [email protected] >>>>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran >>>>>> >>>>>> >>>>>> -- >>>>>> Jeff Squyres >>>>>> [email protected] >>>>>> For corporate legal information go to: >>>>>> http://www.cisco.com/web/about/doing_business/legal/cri/ >>>>>> >>>>>> _______________________________________________ >>>>>> mpiwg-fortran mailing list >>>>>> [email protected] >>>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran >>>>> >>>>> -- >>>>> Dr. Rolf Rabenseifner . . . . . . . . . .. email >>>>> [email protected] >>>>> 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 >>>> [email protected] >>>> 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 >>> [email protected] >>> 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 [email protected] >> 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 [email protected] > 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 > [email protected] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran