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 Dave Goodell 24 Jul '12

24 Jul '12

I think Jim's point (correct me if I'm wrong, Jim) is that there is a third option, which is to allow processes to query their own disp_unit with the MPI_WIN_DISP_UNIT attr and then communicate that information manually. -Dave On Jul 24, 2012, at 1:40 PM CDT, William Gropp wrote: > Hi Jim, > > What it comes down to is this: If we want to allow a process to replace a PUT/GET/ACCUMULATE/etc call with direct access to shared memory in the Allocate_shared case, it will need to know the displacement unit at the remote process (since that's how the remote address is computed). While it is *likely* to be the same as at the origin process, there is (currently) no such requirement. For consistency we should either > > 1) require that the displacement unit be the same at all processes in the Allocate_shared case, or > 2) allow the process to determine the displacement unit at the remote process. > > 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 24, 2012, at 1:09 PM, Jim Dinan wrote: > >> Hi Bill, >> >> My point was with respect to including the disp_unit query in MPI_Win_shared_query() -- this would be the first routine that provides a way for a process to query the disp_unit of another process. For other window types, the user would have to explicitly communicate this information. >> >> If all disp_units are the same -- which is the common case we're expecting (especially for win_shared) -- there doesn't seem to be any value in adding the disp_unit query. The use case that I'm aware of for disp_units being different across processes is heterogeneous systems. This seems like a highly unlikely (maybe impossible from a coherence point-of-view?) design for a shared memory system. >> >> So, I don't think this is doing any technical harm, but I also don't think it's useful. If anything, including a disp_unit query seems misleading to users. >> >> ~Jim. >> >> >> On 7/24/12 11:03 AM, William Gropp wrote: >>> Actually, the primary use of disp_unit is to simplify indexing - most of the examples set the disp_unit to the "natural" size, then index in units of that size, without converting offsets to bytes. It does have the nice side effect that in the heterogeneous case, everything still works. Most RMA codes that I've seen use the disp_unit in this way - not for support for heterogeneity. Note that in the typical case, all processes will provide the same disp_unit, and implementations that wanted to cache the disp_unit could optimize for that. >>> >>> 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 24, 2012, at 10:24 AM, Jim Dinan wrote: >>> >>>> Hi Bill, >>>> >>>> I suppose this is fine. As I understand it, the intended use of each process providing their own disp_unit is to deal with heterogeneity, i.e. when basic type sizes are heterogeneous across processes. If this were to happen in a shared memory window setting, the programmer would need to query the disp_unit in order to do do address calculations correctly. >>>> >>>> I don't think we ever had such a situation in mind, but I can't think of a good reason to omit support for it. >>>> >>>> ~Jim. >>>> >>>> On 7/24/12 10:01 AM, William Gropp wrote: >>>>> There is a difference with the allocate_shared memory - the "remote" memory is accessible through load-store accesses, and hence understanding the computation of the address from the offset as used at the remote process could be relevant. I vote to leave this in. >>>>> >>>>> 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 2:09 PM, Rajeev Thakur wrote: >>>>> >>>>>> There is no way to query the disp_unit passed to other window creation functions, Win_create and Win_allocate, right? If so, is there any use in returning it just for Win_allocate_shared? And the returned value is the disp_unit passed by the calling process itself, which the user would need to communicate to other processes for it to be useful at all. It is not useful on the calling process except for doing local puts and gets. >>>>>> >>>>>> Rajeev >>>>>> >>>>>> >>>>>> 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(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 >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> 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 >>>>> >>>> _______________________________________________ >>>> 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 >>> >> _______________________________________________ >> 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

1 0

Re: [Mpi3-rma] [EXTERNAL] Re: Disp_unit in allocate_shared should be returned by win_shared_query?
by William Gropp 24 Jul '12

24 Jul '12

Hi Jim, What it comes down to is this: If we want to allow a process to replace a PUT/GET/ACCUMULATE/etc call with direct access to shared memory in the Allocate_shared case, it will need to know the displacement unit at the remote process (since that's how the remote address is computed). While it is *likely* to be the same as at the origin process, there is (currently) no such requirement. For consistency we should either 1) require that the displacement unit be the same at all processes in the Allocate_shared case, or 2) allow the process to determine the displacement unit at the remote process. 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 24, 2012, at 1:09 PM, Jim Dinan wrote: > Hi Bill, > > My point was with respect to including the disp_unit query in MPI_Win_shared_query() -- this would be the first routine that provides a way for a process to query the disp_unit of another process. For other window types, the user would have to explicitly communicate this information. > > If all disp_units are the same -- which is the common case we're expecting (especially for win_shared) -- there doesn't seem to be any value in adding the disp_unit query. The use case that I'm aware of for disp_units being different across processes is heterogeneous systems. This seems like a highly unlikely (maybe impossible from a coherence point-of-view?) design for a shared memory system. > > So, I don't think this is doing any technical harm, but I also don't think it's useful. If anything, including a disp_unit query seems misleading to users. > > ~Jim. > > > On 7/24/12 11:03 AM, William Gropp wrote: >> Actually, the primary use of disp_unit is to simplify indexing - most of the examples set the disp_unit to the "natural" size, then index in units of that size, without converting offsets to bytes. It does have the nice side effect that in the heterogeneous case, everything still works. Most RMA codes that I've seen use the disp_unit in this way - not for support for heterogeneity. Note that in the typical case, all processes will provide the same disp_unit, and implementations that wanted to cache the disp_unit could optimize for that. >> >> 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 24, 2012, at 10:24 AM, Jim Dinan wrote: >> >>> Hi Bill, >>> >>> I suppose this is fine. As I understand it, the intended use of each process providing their own disp_unit is to deal with heterogeneity, i.e. when basic type sizes are heterogeneous across processes. If this were to happen in a shared memory window setting, the programmer would need to query the disp_unit in order to do do address calculations correctly. >>> >>> I don't think we ever had such a situation in mind, but I can't think of a good reason to omit support for it. >>> >>> ~Jim. >>> >>> On 7/24/12 10:01 AM, William Gropp wrote: >>>> There is a difference with the allocate_shared memory - the "remote" memory is accessible through load-store accesses, and hence understanding the computation of the address from the offset as used at the remote process could be relevant. I vote to leave this in. >>>> >>>> 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 2:09 PM, Rajeev Thakur wrote: >>>> >>>>> There is no way to query the disp_unit passed to other window creation functions, Win_create and Win_allocate, right? If so, is there any use in returning it just for Win_allocate_shared? And the returned value is the disp_unit passed by the calling process itself, which the user would need to communicate to other processes for it to be useful at all. It is not useful on the calling process except for doing local puts and gets. >>>>> >>>>> Rajeev >>>>> >>>>> >>>>> 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(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 >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 >>>> >>> _______________________________________________ >>> 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 >> > _______________________________________________ > 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 Jim Dinan 24 Jul '12

24 Jul '12

Hi Bill, My point was with respect to including the disp_unit query in MPI_Win_shared_query() -- this would be the first routine that provides a way for a process to query the disp_unit of another process. For other window types, the user would have to explicitly communicate this information. If all disp_units are the same -- which is the common case we're expecting (especially for win_shared) -- there doesn't seem to be any value in adding the disp_unit query. The use case that I'm aware of for disp_units being different across processes is heterogeneous systems. This seems like a highly unlikely (maybe impossible from a coherence point-of-view?) design for a shared memory system. So, I don't think this is doing any technical harm, but I also don't think it's useful. If anything, including a disp_unit query seems misleading to users. ~Jim. On 7/24/12 11:03 AM, William Gropp wrote: > Actually, the primary use of disp_unit is to simplify indexing - most of the examples set the disp_unit to the "natural" size, then index in units of that size, without converting offsets to bytes. It does have the nice side effect that in the heterogeneous case, everything still works. Most RMA codes that I've seen use the disp_unit in this way - not for support for heterogeneity. Note that in the typical case, all processes will provide the same disp_unit, and implementations that wanted to cache the disp_unit could optimize for that. > > 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 24, 2012, at 10:24 AM, Jim Dinan wrote: > >> Hi Bill, >> >> I suppose this is fine. As I understand it, the intended use of each process providing their own disp_unit is to deal with heterogeneity, i.e. when basic type sizes are heterogeneous across processes. If this were to happen in a shared memory window setting, the programmer would need to query the disp_unit in order to do do address calculations correctly. >> >> I don't think we ever had such a situation in mind, but I can't think of a good reason to omit support for it. >> >> ~Jim. >> >> On 7/24/12 10:01 AM, William Gropp wrote: >>> There is a difference with the allocate_shared memory - the "remote" memory is accessible through load-store accesses, and hence understanding the computation of the address from the offset as used at the remote process could be relevant. I vote to leave this in. >>> >>> 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 2:09 PM, Rajeev Thakur wrote: >>> >>>> There is no way to query the disp_unit passed to other window creation functions, Win_create and Win_allocate, right? If so, is there any use in returning it just for Win_allocate_shared? And the returned value is the disp_unit passed by the calling process itself, which the user would need to communicate to other processes for it to be useful at all. It is not useful on the calling process except for doing local puts and gets. >>>> >>>> Rajeev >>>> >>>> >>>> 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(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 >>>> >>>> >>>> _______________________________________________ >>>> 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 >>> >> _______________________________________________ >> 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 >

1 0

Re: [Mpi3-rma] [EXTERNAL] Re: Disp_unit in allocate_shared should be returned by win_shared_query?
by William Gropp 24 Jul '12

24 Jul '12

Actually, the primary use of disp_unit is to simplify indexing - most of the examples set the disp_unit to the "natural" size, then index in units of that size, without converting offsets to bytes. It does have the nice side effect that in the heterogeneous case, everything still works. Most RMA codes that I've seen use the disp_unit in this way - not for support for heterogeneity. Note that in the typical case, all processes will provide the same disp_unit, and implementations that wanted to cache the disp_unit could optimize for that. 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 24, 2012, at 10:24 AM, Jim Dinan wrote: > Hi Bill, > > I suppose this is fine. As I understand it, the intended use of each process providing their own disp_unit is to deal with heterogeneity, i.e. when basic type sizes are heterogeneous across processes. If this were to happen in a shared memory window setting, the programmer would need to query the disp_unit in order to do do address calculations correctly. > > I don't think we ever had such a situation in mind, but I can't think of a good reason to omit support for it. > > ~Jim. > > On 7/24/12 10:01 AM, William Gropp wrote: >> There is a difference with the allocate_shared memory - the "remote" memory is accessible through load-store accesses, and hence understanding the computation of the address from the offset as used at the remote process could be relevant. I vote to leave this in. >> >> 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 2:09 PM, Rajeev Thakur wrote: >> >>> There is no way to query the disp_unit passed to other window creation functions, Win_create and Win_allocate, right? If so, is there any use in returning it just for Win_allocate_shared? And the returned value is the disp_unit passed by the calling process itself, which the user would need to communicate to other processes for it to be useful at all. It is not useful on the calling process except for doing local puts and gets. >>> >>> Rajeev >>> >>> >>> 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(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 >>> >>> >>> _______________________________________________ >>> 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 >> > _______________________________________________ > 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 Jim Dinan 24 Jul '12

24 Jul '12

Hi Bill, I suppose this is fine. As I understand it, the intended use of each process providing their own disp_unit is to deal with heterogeneity, i.e. when basic type sizes are heterogeneous across processes. If this were to happen in a shared memory window setting, the programmer would need to query the disp_unit in order to do do address calculations correctly. I don't think we ever had such a situation in mind, but I can't think of a good reason to omit support for it. ~Jim. On 7/24/12 10:01 AM, William Gropp wrote: > There is a difference with the allocate_shared memory - the "remote" memory is accessible through load-store accesses, and hence understanding the computation of the address from the offset as used at the remote process could be relevant. I vote to leave this in. > > 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 2:09 PM, Rajeev Thakur wrote: > >> There is no way to query the disp_unit passed to other window creation functions, Win_create and Win_allocate, right? If so, is there any use in returning it just for Win_allocate_shared? And the returned value is the disp_unit passed by the calling process itself, which the user would need to communicate to other processes for it to be useful at all. It is not useful on the calling process except for doing local puts and gets. >> >> Rajeev >> >> >> 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(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 >> >> >> _______________________________________________ >> 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 >

1 0

Re: [Mpi3-rma] [EXTERNAL] Re: Disp_unit in allocate_shared should be returned by win_shared_query?
by William Gropp 24 Jul '12

24 Jul '12

There is a difference with the allocate_shared memory - the "remote" memory is accessible through load-store accesses, and hence understanding the computation of the address from the offset as used at the remote process could be relevant. I vote to leave this in. 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 2:09 PM, Rajeev Thakur wrote: > There is no way to query the disp_unit passed to other window creation functions, Win_create and Win_allocate, right? If so, is there any use in returning it just for Win_allocate_shared? And the returned value is the disp_unit passed by the calling process itself, which the user would need to communicate to other processes for it to be useful at all. It is not useful on the calling process except for doing local puts and gets. > > Rajeev > > > 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(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 > > > _______________________________________________ > 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] adam's comment on chapter 11
by William Gropp 22 Jul '12

22 Jul '12

Fixed (sort of). The underlying problem is bugs/limitations in the \color macro. 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 12:53 PM, Torsten Hoefler wrote: >> Funny formatting also occurring on page 456 lines 13,14 for the table >> of error classes. > Hmm, this seems to be an issue with the \MPIupdate macro :-(. Bill, do > you have any idea?

1 0

Re: [Mpi3-rma] adam's comment on chapter 11
by Torsten Hoefler 22 Jul '12

22 Jul '12

Thanks Bill! Torsten On Sun, Jul 22, 2012 at 04:08:55PM -0500, William Gropp wrote: > Fixed (sort of). The underlying problem is bugs/limitations in the \color > macro. > 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 12:53 PM, Torsten Hoefler wrote: > > Funny formatting also occurring on page 456 lines 13,14 for the table > > of error classes. > > Hmm, this seems to be an issue with the \MPIupdate macro :-(. Bill, do > you have any idea? > _______________________________________________ > 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] [EXTERNAL] Re: Disp_unit in allocate_shared should be returned by win_shared_query?
by Rajeev Thakur 22 Jul '12

22 Jul '12

There is no way to query the disp_unit passed to other window creation functions, Win_create and Win_allocate, right? If so, is there any use in returning it just for Win_allocate_shared? And the returned value is the disp_unit passed by the calling process itself, which the user would need to communicate to other processes for it to be useful at all. It is not useful on the calling process except for doing local puts and gets. Rajeev 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(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] [Mpi-forum] [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 08:30:26PM +0200, Rolf Rabenseifner wrote: > Torsten and Bill, > > Torsten: > > I would agree to Bill. We should have an info argument allowing the user > > to state that all displ_units are the same like we have for count :-). > > A topic for MPI-3.1! > > Yes, it is not needed for MPI-3.0, because with two Allreduces with > MIN and MAX of disp_unit, all processes know in O(log(p)) whether > it is the same value in all processes. Sure, this is trivial but I still like an O(1) (zero communication) info argument better :-). > Bill, yes, here a draft: > > Advice to users. If an application should scale to a large > number of processes, then it is recommended for scalability reasons > that all processes provide the same disp_unit argument > on all processes. End of advice to users. I think this does not belong into the standard. If we start those things then we need to add the same for the size and dozens of other "collective" arguments (think compressibility of graphs etc.). I also think that we're digressing :-). We still didn't decide if the WG likes the displ in the query function or not. 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

1 0