Re: [Mpi3-rma] [EXTERNAL] Re: Disp_unit in allocate_shared should be returned by win_shared_query?
The advice to users is not essential, and at this point, we should *only* be making essential changes. This is a standards document, not a user manual. I'm all for having man pages and tutorials say things like this, but we don't need it in the standard. Bill William Gropp Director, Parallel Computing Institute Deputy Director for Research Institute for Advanced Computing Applications and Technologies Paul and Cynthia Saylor Professor of Computer Science University of Illinois Urbana-Champaign On Jul 26, 2012, at 4:22 PM, Rolf Rabenseifner wrote:
I guess we can add this advice nevertheless. I think this would also cover Rolf's comment.
Not really. The text is orthogonal to my request.
Advice to users. If disp_unit values differ across processes in a shared memory window, the programmer may need to use the target's disp_unit value in address calculations and use different load/store operations depending on the target's disp_unit value. (End of advice to users.)
This is an advice especially for MPI_WIN_ALLOCATE_SHARED. It does not fit to MPI_WIN_ALLOCATE and the use of MPI_PUT/GET because in PUT/GET, the disp_unit works perfect.
My question was a general one at MPI_WIN_CREATE to tell the users that the major intend is that all disp_unit values (related to the processes of one window handle) represent the extent of one common datatype. And, if one is doing different, this may cause a non-scaling memory overhead.
Rolf
----- Original Message -----
From: "Torsten Hoefler" <[email protected]> To: "MPI 3.0 Remote Memory Access working group" <[email protected]> Sent: Thursday, July 26, 2012 11:05:56 PM Subject: Re: [Mpi3-rma] [EXTERNAL] Re: Disp_unit in allocate_shared should be returned by win_shared_query? On Thu, Jul 26, 2012 at 11:18:05AM -0500, James Dinan wrote:
I do have a concern that different disp_units can occur unexpectedly because of heterogeneous hardware or software -- e.g. MPMD launch with different executables or language incompatibility where both C and Fortran code are involved in creating the window.
Rather than ruling these cases out (option #1), how about including the following advice to users:
Advice to users. If disp_unit values differ across processes in a shared memory window, the programmer may need to use the target's disp_unit value in address calculations and use different load/store operations depending on the target's disp_unit value. (End of advice to users.)
If we included this, I think I would be ok with option #2. I don't object, however, we're supposed to freeze the document by today. I guess we can add this advice nevertheless. I think this would also cover Rolf's comment.
An orthogonal observation -- it would have given us a lot more flexibility to define MPI_Win_shared_query as:
int MPI_Win_shared_get_attr(MPI_Win win, int target_rank, int win_keyval, void *attribute_val, int *flag) Of course. I still like the MPI_Func(...) idea :-).
But I agree, this would also fit the current design with attributes better. Hmm, is probably too late for such a syntactic sugar change. Any opinions?
All the Best, Torsten
-- ### qreharg rug ebs fv crryF ------------- http://www.unixer.de/ ----- Torsten Hoefler | Performance Modeling and Simulation Lead Blue Waters Directorate | University of Illinois (UIUC) 1205 W Clark Street | Urbana, IL, 61801 NCSA Building | +01 (217) 244-7736 _______________________________________________ mpi3-rma mailing list [email protected] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma
-- 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: Allmandring 30) _______________________________________________ mpi3-rma mailing list [email protected] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma
participants (1)
-
William Gropp