[MPIWG Fortran] MPI-3 ticket 349: Fortran question
Rolf Rabenseifner
rabenseifner at hlrs.de
Fri Dec 13 08:11:47 CST 2013
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)
More information about the mpiwg-fortran
mailing list