[Mpi3-rma] [EXTERNAL] Re: Disp_unit in allocate_shared should be returned by win_shared_query?

[Rolf Rabenseifner]

> 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" <htor at illinois.edu>
> To: "MPI 3.0 Remote Memory Access working group" <mpi3-rma at lists.mpi-forum.org>
> 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
> mpi3-rma at lists.mpi-forum.org
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma

-- 
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: Allmandring 30)