July 2012 - mpiwg-rma - mailman3.cels.anl.gov

Re: [Mpi3-rma] [EXTERNAL] Re: Disp_unit in allocate_shared should be returned by win_shared_query?
by Bronis R. de Supinski 22 Jul '12

22 Jul '12

Internal consensus cannot include changes to the approved branch. On Sun, 22 Jul 2012, Torsten Hoefler wrote: > Bronis, >> I do not recall the discussion and your choice to >> omit the forum list is arbitrary and unnecessary. > Your choice was to not be in the room at that time :-). The RMA working > group is trying to achieve internal consensus before getting to the > Forum. This has been the most successful modus operandi so far. The > working group is open to anyone. You are welcome to contribute to the > technical discussion. > > 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 >

1 0

Re: [Mpi3-rma] [EXTERNAL] Re: Disp_unit in allocate_shared should be returned by win_shared_query?
by Torsten Hoefler 22 Jul '12

22 Jul '12

On Sun, Jul 22, 2012 at 10:10:36AM -0700, Bronis R. de Supinski wrote: > > Internal consensus cannot include changes to the approved branch. Again, the changes were approved by the Forum and they are still committed. 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

1 0

Re: [Mpi3-rma] [EXTERNAL] Re: Disp_unit in allocate_shared should be returned by win_shared_query?
by Bronis R. de Supinski 22 Jul '12

22 Jul '12

Torsten: I do not recall the discussion and your choice to omit the forum list is arbitrary and unnecessary. Bronis On Sun, 22 Jul 2012, Torsten Hoefler wrote: > Bronis, > >> It is too large of a change for a chapter committee just to add. >> In the least, you need to poll the full forum list. > I disagree, this is part of a change that we discussed at the Forum and > the Forum agreed. However, after that, the WG started to discuss > internally. So we have the Forum's approval but are not sure what to do > :-). > > I have really no strong opinion one way or another, just waiting for > instructions. > > 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 >

1 0

Re: [Mpi3-rma] [EXTERNAL] Re: Disp_unit in allocate_shared should be returned by win_shared_query?
by Torsten Hoefler 22 Jul '12

22 Jul '12

Bronis, > I do not recall the discussion and your choice to > omit the forum list is arbitrary and unnecessary. Your choice was to not be in the room at that time :-). The RMA working group is trying to achieve internal consensus before getting to the Forum. This has been the most successful modus operandi so far. The working group is open to anyone. You are welcome to contribute to the technical discussion. 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

1 0

Re: [Mpi3-rma] [EXTERNAL] Re: Disp_unit in allocate_shared should be returned by win_shared_query?
by Torsten Hoefler 22 Jul '12

22 Jul '12

Bronis, > It is too large of a change for a chapter committee just to add. > In the least, you need to poll the full forum list. I disagree, this is part of a change that we discussed at the Forum and the Forum agreed. However, after that, the WG started to discuss internally. So we have the Forum's approval but are not sure what to do :-). I have really no strong opinion one way or another, just waiting for instructions. 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

1 0

Re: [Mpi3-rma] [EXTERNAL] Re: Disp_unit in allocate_shared should be returned by win_shared_query?
by Bronis R. de Supinski 22 Jul '12

22 Jul '12

Torsten: It is too large of a change for a chapter committee just to add. In the least, you need to poll the full forum list. Bronis On Sun, 22 Jul 2012, 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(a)lists.mpi-forum.org [mpi3-rma-bounces(a)lists.mpi-forum.org] on behalf of Jim Dinan [dinan(a)mcs.anl.gov] >> Sent: Wednesday, July 18, 2012 12:46 PM >> To: mpi3-rma(a)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(a)lists.mpi-forum.org >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma >> >> >> >> _______________________________________________ >> mpi3-rma mailing list >> mpi3-rma(a)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(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma >

1 0

Re: [Mpi3-rma] [EXTERNAL] Re: Disp_unit in allocate_shared should be returned by win_shared_query?
by Torsten Hoefler 22 Jul '12

22 Jul '12

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(a)lists.mpi-forum.org [mpi3-rma-bounces(a)lists.mpi-forum.org] on behalf of Jim Dinan [dinan(a)mcs.anl.gov] > Sent: Wednesday, July 18, 2012 12:46 PM > To: mpi3-rma(a)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(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma > > > > _______________________________________________ > mpi3-rma mailing list > mpi3-rma(a)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

1 0

Re: [Mpi3-rma] adam's comment on chapter 11
by Howard Pritchard 19 Jul '12

19 Jul '12

Chapter 11 review things to fix: -----Original Message----- From: Kathryn Mohror [mailto:[email protected]] Sent: Thursday, July 19, 2012 9:04 AM To: Howard Pritchard Subject: adam's comment on chapter 11 4) The Window Info section 11.2.7 lists calls that assign info to windows, but it is missing the new creation routines, i.e., MPI_WIN_ALLOCATE, MPI_WIN_ALLOCATE_SHARED, MPI_WIN_DYNAMIC. These should be included in the list that starts with "Hints are specified on a per window basis, in ..." Thanks! Kathryn _____________________________________________________________________ Kathryn Mohror, kathryn(a)llnl.gov, http://people.llnl.gov/mohror1 CASC @ Lawrence Livermore National Laboratory, Livermore, CA, USA It would be nice if the latex formatting of the MPI_Get_accumulate on page 430. It would be nice if the latex formatting of the MPI_Rget_accumulate on page 437. Funny formatting also occurring on page 456 lines 13,14 for the table of error classes. Need to review lines 15-19 on page 462 because statement about polling on X is not correct in the separate memory model. The example links on page 465 lines 37 and 41 aren't really correct, they're linked to the section numbers not the examples. That's all I could find. I didn't go closely through the examples At the end as I was running out of time. Howard

1 0

Re: [Mpi3-rma] notes from 5pm Tuesday meeting @ July 2012 Forum
by Pavan Balaji 19 Jul '12

19 Jul '12

On 07/17/2012 06:14 PM, Dave Goodell wrote: > Double-check that C++ is not referenced in the RMA chapter (Pavan): https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/281 > > Think unaffected, but slim chance of Rput/Rget being affected (Pavan): https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/317 Reviewed both these. They look good. -- Pavan Balaji http://www.mcs.anl.gov/~balaji

1 0

Re: [Mpi3-rma] [EXTERNAL] Re: Disp_unit in allocate_shared should be returned by win_shared_query?
by Barrett, Brian W 18 Jul '12

18 Jul '12

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(a)lists.mpi-forum.org [mpi3-rma-bounces(a)lists.mpi-forum.org] on behalf of Jim Dinan [dinan(a)mcs.anl.gov] Sent: Wednesday, July 18, 2012 12:46 PM To: mpi3-rma(a)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(a)lists.mpi-forum.org http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma

1 0