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 <[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
> _______________________________________________
> mpiwg-fortran mailing list
> [email protected]
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran
>

-- 
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