[MPIWG Fortran] MPI-3 ticket 349: Fortran question
Jeff Hammond
jeff.science at gmail.com
Fri Dec 20 07:35:21 CST 2013
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 at 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 at gmail.com>
>> To: "Rolf Rabenseifner" <rabenseifner at hlrs.de>
>> Cc: "MPI-WG Fortran working group" <mpiwg-fortran at lists.mpi-forum.org>, "longb" <longb at 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 at 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 at gmail.com >
>>> To: "Rolf Rabenseifner" < rabenseifner at hlrs.de >
>>> Cc: "MPI-WG Fortran working group" <
>>> mpiwg-fortran at lists.mpi-forum.org >, "longb" < longb at 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 at 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 at gmail.com >
>>>> To: "Rolf Rabenseifner" < rabenseifner at hlrs.de >
>>>> Cc: "MPI-WG Fortran working group" <
>>>> mpiwg-fortran at lists.mpi-forum.org >, "longb" < longb at cray.com >,
>>>> "Jim Dinan"
>>>> < dinan at 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 at 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 at gmail.com >
>>>>> To: "Rolf Rabenseifner" < rabenseifner at hlrs.de >
>>>>> Cc: "MPI-WG Fortran working group" <
>>>>> mpiwg-fortran at lists.mpi-forum.org >, "longb" < longb at cray.com
>>>>>> ,
>>>>> "Jim Dinan"
>>>>> < dinan at 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 at 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 at cisco.com >
>>>>>> To: "< longb at cray.com >" < longb at cray.com >, "MPI-WG Fortran
>>>>>> working group" < mpiwg-fortran at 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 at 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 at 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 at lists.mpi-forum.org
>>>>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Jeff Squyres
>>>>>> jsquyres at cisco.com
>>>>>> For corporate legal information go to:
>>>>>> http://www.cisco.com/web/about/doing_business/legal/cri/
>>>>>>
>>>>>> _______________________________________________
>>>>>> mpiwg-fortran mailing list
>>>>>> mpiwg-fortran at lists.mpi-forum.org
>>>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran
>>>>>
>>>>> --
>>>>> Dr. Rolf Rabenseifner . . . . . . . . . .. email
>>>>> rabenseifner at 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 at 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 at 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 at 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 at 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 at lists.mpi-forum.org
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran
More information about the mpiwg-fortran
mailing list