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)