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

Sun Jul 22 12:17:26 CDT 2012

On Sun, Jul 22, 2012 at 12:12:27PM -0500, William Gropp wrote:
> What *exactly* are the proposals?  I know in general, but some of the
> statements make me wonder if I understand the proposal.

The two options are:

1) Return disp_unit in win_shared_query.

2) Do not return disp_unit in win_shared_query.

I committed it after RMA WG and Forum approval (as part of the disp_unit
change). RMA group members started to discuss :-). I am now just waiting
for a decision from the RMA group and will then notify the Forum and
apply the change (if necessary).

Thanks,
  Torsten

> 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 22, 2012, at 10:55 AM, Torsten Hoefler wrote:
> 
> > Dear All,
> > 
> > I think we should discuss this more. Right now, we still have more votes
> > in favor of this than against. The change is still committed and part of
> > the "official release". The deadline is 7/26. 
> > 
> > Please advise what to do!
> > 
> > Thanks,
> >  Torsten
> > 
> > On Wed, Jul 18, 2012 at 08:11:23PM +0000, Barrett, Brian W wrote:
> >> I'm concerned with the change (and don't think it should happen at this point, as I want to be able to tell other people their changes are too big).  It's probably not another O(p) structure, since a process will have to know the other rank's disp_unit to do the memcpy during the communication operations, so we crossed the O(p) bridge when we added disp_unit to allocate_shared.
> >> 
> >> 
> >> Brian
> >> 
> >> --
> >>  Brian W. Barrett
> >>  Scalable System Software Group
> >>  Sandia National Laboratories
> >> ________________________________________
> >> From: mpi3-rma-bounces at lists.mpi-forum.org [mpi3-rma-bounces at lists.mpi-forum.org] on behalf of Jim Dinan [dinan at mcs.anl.gov]
> >> Sent: Wednesday, July 18, 2012 12:46 PM
> >> To: mpi3-rma at lists.mpi-forum.org
> >> Subject: [EXTERNAL] Re: [Mpi3-rma] Disp_unit in allocate_shared should be returned by win_shared_query?
> >> 
> >> It's not inherently damaging, but it requires us to maintain/provide
> >> access to another O(p) structure and suggests to users that another
> >> process' disp_unit is useful information, which is incorrect.  IIRC, we
> >> did discuss this in the working group and intentionally omitted it.
> >> 
> >>  ~Jim.
> >> 
> >> On 7/18/12 1:38 PM, Torsten Hoefler wrote:
> >>> On Wed, Jul 18, 2012 at 01:18:53PM -0500, James Dinan wrote:
> >>>> On 7/18/12 1:06 PM, Torsten Hoefler wrote:
> >>>>> On Wed, Jul 18, 2012 at 01:08:43PM -0500, Pavan Balaji wrote:
> >>>>>> 
> >>>>>> On 07/18/2012 01:02 PM, Torsten Hoefler wrote:
> >>>>>>> Jim,
> >>>>>>>> Is one process' disp_unit meaningful at another process?  I thought that
> >>>>>>>> this is not the case.  MPI provides no other routines to query another
> >>>>>>>> process' disp_unit.
> >>>>>>> It is something that the user is passing in. I don't know of a
> >>>>>>> particular use-case but we can query all other arguments that each
> >>>>>>> process passed. One more integer seemed safe to me.
> >>>>>>> 
> >>>>>>>> Also, what meaning does a disp_unit have in the context of load/store
> >>>>>>>> operations that will result from win_shared_query?
> >>>>>>> Nothing.
> >>>>>>> 
> >>>>>>>> Maybe I'm missing something, but this doesn't seem necessary.
> >>>>>>> Well, it's better to have it than to introduce it with a different name
> >>>>>>> later. That was my main motivation. One could also use it in a library
> >>>>>>> context to query. But that's weak, I know.
> >>>>>> 
> >>>>>> This doesn't seem critical, and can always be added in MPI-3.1 if we
> >>>>>> find it necessary.  No reason to rush it.
> >>>>> 
> >>>>> It cannot be added without a new function name. That was the concern
> >>>>> here. Adding it seems less risk than not adding it. In addition, it is
> >>>>> already added ;-).
> >>>> 
> >>>> I am concerned that this is a harmful change.  The disp_unit from one
> >>>> process has no meaningful use at another process.  If the user wants to
> >>>> know it for some reason, they can use a separate communication operation.
> >>> I believe the potential damage is very limited. But we can have a vote.
> >>> 
> >>> So far it's still yes: 5, no: 1
> >>> 
> >>> I'm just mediating, not making decisions.
> >>> 
> >>> Torsten
> >>> 
> >> 
> >> _______________________________________________
> >> mpi3-rma mailing list
> >> mpi3-rma at lists.mpi-forum.org
> >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma
> >> 
> >> 
> >> 
> >> _______________________________________________
> >> mpi3-rma mailing list
> >> mpi3-rma at lists.mpi-forum.org
> >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma
> >> 
> > 
> > -- 
> > ### 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
> 
> 
> _______________________________________________
> mpi3-rma mailing list
> mpi3-rma at lists.mpi-forum.org
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma
> 

-- 
### 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