April 2011 - mpiwg-rma - mailman3.cels.anl.gov

Re: [Mpi3-rma] GetAccumulate restriction needed?
by William Gropp 01 Apr '11

01 Apr '11

Agreed. We should include this restriction. Bill On Mar 31, 2011, at 10:20 PM, Rajeev Thakur wrote: > Good catch. I think we should add that restriction. MPI_Sendrecv, > for example, explicitly says the send and recv buffers must be > disjoint. > > Rajeev > > > On Mar 31, 2011, at 9:17 PM, Underwood, Keith D wrote: > >> Hi All, >> >> Brian and I were having a discussion about something else today and >> realized that we werenï¿½t sure of something very important: is >> there anywhere in the one-sided chapter that prohibits the source >> buffer of the GetAccumulate and the reply buffer of the >> GetAccumulate from being the same buffer? It seems like this >> should be prohibitedï¿½ >> >> Keith >> >> >> _______________________________________________ >> 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 William Gropp Deputy Director for Research Institute for Advanced Computing Applications and Technologies Paul and Cynthia Saylor Professor of Computer Science University of Illinois Urbana-Champaign

1 0

Re: [Mpi3-rma] GetAccumulate restriction needed?
by Pavan Balaji 01 Apr '11

01 Apr '11

On 03/31/2011 10:20 PM, Rajeev Thakur wrote: > Good catch. I think we should add that restriction. MPI_Sendrecv, for > example, explicitly says the send and recv buffers must be disjoint. No MPI_IN_PLACE for Get_accumulate? -- Pavan -- Pavan Balaji http://www.mcs.anl.gov/~balaji

1 0

Re: [Mpi3-rma] GetAccumulate restriction needed?
by Rajeev Thakur 31 Mar '11

31 Mar '11

Good catch. I think we should add that restriction. MPI_Sendrecv, for example, explicitly says the send and recv buffers must be disjoint. Rajeev On Mar 31, 2011, at 9:17 PM, Underwood, Keith D wrote: > Hi All, > > Brian and I were having a discussion about something else today and realized that we werenï¿½t sure of something very important: is there anywhere in the one-sided chapter that prohibits the source buffer of the GetAccumulate and the reply buffer of the GetAccumulate from being the same buffer? It seems like this should be prohibitedï¿½ > > Keith > > > _______________________________________________ > 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] GetAccumulate restriction needed?
by Jeff Hammond 31 Mar '11

31 Mar '11

That's sufficient for me. I have never cared enough about IB to know its fundamental limitations. Other than "accumulate with replace" for large buffers, I can't think of an application use case where it would matter to support in-place for GetAccumulate. Jeff On Thu, Mar 31, 2011 at 9:27 PM, Underwood, Keith D <keith.d.underwood(a)intel.com> wrote: > I believe that InfiniBand would have to copy the entire buffer before starting the operation. ï¿½It does not seem to be beneficial to bury that kind of performance anomaly. ï¿½It would be sort of like having MPI_Sendrecv with an "in place" option. ï¿½The best a network could ever do is to break it up into some "safe" size for the network and do it in pieces with round trips after each piece completed. > > Keith > >> -----Original Message----- >> From: Jeff Hammond [mailto:[email protected]] >> Sent: Thursday, March 31, 2011 8:25 PM >> To: MPI 3.0 Remote Memory Access working group >> Cc: Underwood, Keith D >> Subject: Re: [Mpi3-rma] GetAccumulate restriction needed? >> >> What are the use cases that make implementing this difficult? ï¿½I can >> argue both sides of this, so I'm curious what you think is the >> deal-breaker. >> >> Thanks, >> >> Jeff >> >> On Thu, Mar 31, 2011 at 9:17 PM, Underwood, Keith D >> <keith.d.underwood(a)intel.com> wrote: >> > Hi All, >> > >> > >> > >> > Brian and I were having a discussion about something else today and >> realized >> > that we weren't sure of something very important:ï¿½ is there anywhere >> in the >> > one-sided chapter that prohibits the source buffer of the >> GetAccumulate and >> > the reply buffer of the GetAccumulate from being the same buffer?ï¿½ It >> seems >> > like this should be prohibited. >> > >> > >> > >> > Keith >> > >> > >> > >> > >> > >> > _______________________________________________ >> > mpi3-rma mailing list >> > mpi3-rma(a)lists.mpi-forum.org >> > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma >> > >> > >> >> >> >> -- >> Jeff Hammond >> Argonne Leadership Computing Facility >> jhammond(a)alcf.anl.gov / (630) 252-5381 >> http://www.linkedin.com/in/jeffhammond > -- Jeff Hammond Argonne Leadership Computing Facility jhammond(a)alcf.anl.gov / (630) 252-5381 http://www.linkedin.com/in/jeffhammond

1 0

Re: [Mpi3-rma] GetAccumulate restriction needed?
by Underwood, Keith D 31 Mar '11

31 Mar '11

I believe that InfiniBand would have to copy the entire buffer before starting the operation. It does not seem to be beneficial to bury that kind of performance anomaly. It would be sort of like having MPI_Sendrecv with an "in place" option. The best a network could ever do is to break it up into some "safe" size for the network and do it in pieces with round trips after each piece completed. Keith > -----Original Message----- > From: Jeff Hammond [mailto:[email protected]] > Sent: Thursday, March 31, 2011 8:25 PM > To: MPI 3.0 Remote Memory Access working group > Cc: Underwood, Keith D > Subject: Re: [Mpi3-rma] GetAccumulate restriction needed? > > What are the use cases that make implementing this difficult? I can > argue both sides of this, so I'm curious what you think is the > deal-breaker. > > Thanks, > > Jeff > > On Thu, Mar 31, 2011 at 9:17 PM, Underwood, Keith D > <keith.d.underwood(a)intel.com> wrote: > > Hi All, > > > > > > > > Brian and I were having a discussion about something else today and > realized > > that we weren't sure of something very important:ï¿½ is there anywhere > in the > > one-sided chapter that prohibits the source buffer of the > GetAccumulate and > > the reply buffer of the GetAccumulate from being the same buffer?ï¿½ It > seems > > like this should be prohibited. > > > > > > > > Keith > > > > > > > > > > > > _______________________________________________ > > mpi3-rma mailing list > > mpi3-rma(a)lists.mpi-forum.org > > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma > > > > > > > > -- > Jeff Hammond > Argonne Leadership Computing Facility > jhammond(a)alcf.anl.gov / (630) 252-5381 > http://www.linkedin.com/in/jeffhammond

1 0

Re: [Mpi3-rma] GetAccumulate restriction needed?
by Jeff Hammond 31 Mar '11

31 Mar '11

What are the use cases that make implementing this difficult? I can argue both sides of this, so I'm curious what you think is the deal-breaker. Thanks, Jeff On Thu, Mar 31, 2011 at 9:17 PM, Underwood, Keith D <keith.d.underwood(a)intel.com> wrote: > Hi All, > > > > Brian and I were having a discussion about something else today and realized > that we werenï¿½t sure of something very important:ï¿½ is there anywhere in the > one-sided chapter that prohibits the source buffer of the GetAccumulate and > the reply buffer of the GetAccumulate from being the same buffer?ï¿½ It seems > like this should be prohibitedï¿½ > > > > Keith > > > > > > _______________________________________________ > mpi3-rma mailing list > mpi3-rma(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma > > -- Jeff Hammond Argonne Leadership Computing Facility jhammond(a)alcf.anl.gov / (630) 252-5381 http://www.linkedin.com/in/jeffhammond

1 0

[Mpi3-rma] GetAccumulate restriction needed?
by Underwood, Keith D 31 Mar '11

31 Mar '11

Hi All, Brian and I were having a discussion about something else today and realized that we weren't sure of something very important: is there anywhere in the one-sided chapter that prohibits the source buffer of the GetAccumulate and the reply buffer of the GetAccumulate from being the same buffer? It seems like this should be prohibited... Keith

1 0