Re: [Mpi3-rma] [EXTERNAL] Re: Ticket for WG discussion
Instead, how about a routine that converts MPI_Aints to be relative to a common MPI_BOTTOM so they mean something on other processes. We could define: MPI_Aint_rebase(MPI_Aint in, MPI_Aint in_bottom, MPI_Aint *out, MPI_Aint out_bottom); So, one could take the address from MPI_Win_attach and perform: MPI_Aint_rebase(attach_addr, MPI_BOTTOM, &portable_addr, MPI_BOTTOM_COMMON); The recipient would reverse this operation: MPI_Aint_rebase(recv_addr, MPI_BOTTOM_COMMON, &addr, MPI_BOTTOM); ~Jim. On 3/15/13 10:16 AM, Dave Goodell wrote:
We currently require MPI_Aint to have the same size and representation in both C and Fortran. So this would be a somewhat major departure...
-Dave
On Mar 15, 2013, at 10:04 AM CDT, Jim Dinan <[email protected]> wrote:
Given this MPI_BOTTOM awfulness, it seems like we need to add MPI_Aint_f2c/c2f() in order for dynamic windows to be reasonable from Fortran. To use dynamic windows, users must send aints from one process to another (after attaching memory). Given that Fortran aints are not portable across processes and C aints are, it seems like we need a way to make this conversion. And we will have to warn Fortran users that only C aints can be interpreted correctly in a different process.
~Jim.
On 3/14/13 12:18 PM, Hubert Ritzdorf wrote:
Ok,
this was one of the questions which was open to me. If you want to create an address (better displacement to MPI_BOTTOM) for another process you have to include the id (i.e. win, rank) of this process into MPI_Aint_index(). MPI_BOTTOM may be different in each process in Fortran and the local value of MPI_BOTTOM cannot be used.
Hubert ________________________________________ From: [email protected] [[email protected]] on behalf of Barrett, Brian W [[email protected]] Sent: Thursday, March 14, 2013 6:04 PM To: MPI 3.0 Remote Memory Access working group Subject: Re: [Mpi3-rma] [EXTERNAL] Re: Ticket for WG discussion
Hubert -
The issue with MPI_Get_address() in your usage model is one of heterogeneity. If process A is 32 bit and trying to create an address to talk to process B (which is 64 bit), there's now a difference (this, of course, assumes that MPI_Aint is an int64_t in that MPI).
Brian
-- Brian W. Barrett Scalable System Software Group Sandia National Laboratories ________________________________________ From: [email protected] [[email protected]] on behalf of Hubert Ritzdorf [[email protected]] Sent: Thursday, March 14, 2013 10:56 AM To: MPI 3.0 Remote Memory Access working group Subject: [EXTERNAL] Re: [Mpi3-rma] Ticket for WG discussion
Hi Jim,
this sounds to me that
addr2 = MPI_Aint_index (base, disp)
is equivalent to
MPI_Get_Address ((char *) base + disp, &addr2)
Is this correct or where is the difference ?
Or is "base" also a displacement relative to MPI_BOTTOM (in which case it might be signed in Fortran) and
addr2 = MPI_Aint_index (base, disp)
is equivalent to
MPI_Get_address ((char *) MPI_BOTTOM + base + disp, &addr2)
Hubert ________________________________________ From: [email protected] [[email protected]] on behalf of Jim Dinan [[email protected]] Sent: Thursday, March 14, 2013 4:05 PM To: [email protected] Subject: Re: [Mpi3-rma] Ticket for WG discussion
A little clearer:
The value returned is the address, relative to MPI_BOTTOM, resulting from the sum of base and disp.
~Jim.
On 3/14/13 9:42 AM, Jim Dinan wrote:
Hi Hubert,
My apologies, the ticket is light on details. The proposed function is:
MPI_Aint MPI_Aint_index(MPI_Aint base, MPI_Aint disp);
This function interprets the base argument as an address relative to MPI_BOTTOM and the disp argument as a signed integer displacement. The value returned is the sum of these two values.
~Jim.
On 3/13/13 7:12 AM, Hubert Ritzdorf wrote:
Hi Jim,
Sorry, I have some problems with the interpretation of function MPI_Aint_index().
(*) What does MPI_Aint_index() return ? A target displacement which can be used in RMA functions such as MPI Put/Get or does it return an address such as MPI_Get_address () ?
(*) What is argument "base" ? An address returned by MPI_Get_address() of any address or a window base returned by MPI_Win_get_attr(win, MPI_WIN_BASE, &base, &flag) ? May "base" (as MPI_Aint) be transferred from a different process ?
Hubert ________________________________________ From: [email protected] [[email protected]] on behalf of Jim Dinan [[email protected]] Sent: Tuesday, March 12, 2013 9:08 PM To: [email protected] Subject: Re: [Mpi3-rma] Ticket for WG discussion
Hubert,
We have added a solution #3 to the ticket based on discussion in the working group today. That's our current proposal. Could you take a look and see if that will be Fortran compatible?
Thanks, ~Jim.
On 3/12/13 2:28 PM, Hubert Ritzdorf wrote:
Hi,
concerning Ticket 349. (*) In Fortran, the displacement for dynamic windows may be signed since MPI_BOTTOM of Fortran is not (void *) NULL.. (*) Fortran doesn't have unsigned integers, thus you cannot use a Fortran version of MPI_Disp for arithmetics (such as disp++). (*) MPI Displacements in general may be signed. They might be relative to any address.
Therefore, I can't see that the Proposed Solution 2 solves the problem.
Hubert
________________________________________ From: [email protected] [[email protected]] on behalf of Jim Dinan [[email protected]] Sent: Tuesday, March 12, 2013 5:12 PM To: MPI 3.0 Remote Memory Access working group Subject: [Mpi3-rma] Ticket for WG discussion
Hi All,
I would like to propose the following two tickets for discussion in today's WG meeting:
https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/349 https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/344
#349 is a bugfix that definitely needs to be addressed. #344 is an "elegance of the interface" ticket where I would like to poll the WG to determine the level of support and determine if this should be pursued.
I unfortunately need to duck out at 4pm today, so if possible, I propose that we discuss these at the beginning of the meeting.
Thanks! ~Jim. _______________________________________________ mpi3-rma mailing list [email protected] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma
Click https://www.mailcontrol.com/sr/kHf7UuVmhqHGX2PQPOmvUu5zZAYN1MosNz2OH0bOQrlt5... to report this email as spam.
_______________________________________________ mpi3-rma mailing list [email protected] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma
_______________________________________________ mpi3-rma mailing list [email protected] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma
_______________________________________________ mpi3-rma mailing list [email protected] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma
_______________________________________________ mpi3-rma mailing list [email protected] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma
mpi3-rma mailing list [email protected] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma
_______________________________________________ mpi3-rma mailing list [email protected] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma
_______________________________________________ mpi3-rma mailing list [email protected] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma
_______________________________________________ mpi3-rma mailing list [email protected] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma
_______________________________________________ mpi3-rma mailing list [email protected] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma
_______________________________________________ mpi3-rma mailing list [email protected] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma
participants (1)
-
Jim Dinan