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

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

03 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? > Not yet, I agree that it could make sense though -- we should discuss > this tomorrow. Could you perhaps provide a use case? Otherwise, it looks like an implementation nightmare with potentially unexpected performance characteristics associated with any working implementation choice. Do we have a call tomorrow? I thought Rajeev's note said 4/11...

1 0

Re: [Mpi3-rma] GetAccumulate restriction needed?
by Torsten Hoefler 03 Apr '11

03 Apr '11

On Fri, Apr 01, 2011 at 07:01:46AM -0500, Pavan Balaji wrote: > > 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? Not yet, I agree that it could make sense though -- we should discuss this tomorrow. Thanks, Torsten -- bash$ :(){ :|:&};: --------------------- 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] Unified model discussion
by Torsten Hoefler 03 Apr '11

03 Apr '11

On Sat, Apr 02, 2011 at 12:19:43PM -0600, Underwood, Keith D wrote: > Does Win_sync currently have to be called during an epoch on the local > processor? Would we want to relax that restriction? Right now, WIN_SYNC can be called at anytime and has to do the synchronization. However, access is restricted to epochs. I second Pavan's proposal. Torsten -- bash$ :(){ :|:&};: --------------------- 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] Unified model discussion
by Underwood, Keith D 02 Apr '11

02 Apr '11

Does Win_sync currently have to be called during an epoch on the local processor? Would we want to relax that restriction? Keith > -----Original Message----- > From: mpi3-rma-bounces(a)lists.mpi-forum.org [mailto:mpi3-rma- > bounces(a)lists.mpi-forum.org] On Behalf Of Pavan Balaji > Sent: Saturday, April 02, 2011 11:37 AM > To: MPI 3.0 Remote Memory Access working group > Subject: Re: [Mpi3-rma] Unified model discussion > > > In the case of SEPARATE, Win_sync will be required to do two things: > (1) > order load/stores, and (2) synchronize public/private windows. > > We can as well use Win_sync for unified too, and just get it to do the > first part. > > -- Pavan > > On 04/02/2011 12:35 PM, William Gropp wrote: > > Would that call also complete/order local memory operations (e.g., we > > could use the same routine)? > > > > Bill > > > > On Apr 2, 2011, at 11:50 AM, Underwood, Keith D wrote: > > > >> That is an important point. What if we allow unified to work for > >> this use case without additional calls, but add a call to force > >> synchronization when the local and remote accesses would conflict? > >> > >> Keith > >> > >>> -----Original Message----- > >>> From: mpi3-rma-bounces(a)lists.mpi-forum.org [mailto:mpi3-rma- > >>> bounces(a)lists.mpi-forum.org] On Behalf Of Pavan Balaji > >>> Sent: Thursday, March 31, 2011 3:52 PM > >>> To: mpi3-rma(a)lists.mpi-forum.org > >>> Subject: [Mpi3-rma] Unified model discussion > >>> > >>> > >>> When we were having the discussion on the unified model during the > >>> last > >>> working group meeting, I forgot to point out one important use > case: > >>> > >>> Process 0 > >>> ---------- > >>> Win_lock(shared, P0) > >>> load(A) > >>> store(B) > >>> Win_unlock > >>> > >>> Process 1 > >>> --------- > >>> Win_lock(shared, P0) > >>> Put(C) > >>> Get(D) > >>> Win_unlock > >>> > >>> That is, two processes are reading/writing to different parts of > the > >>> window. This is an important model and can only be supported in > >>> unified, > >>> not separate (because of potential cache-line false sharing). > >>> > >>> So, basically, no we cannot remove the unified model in spite of > all > >>> its > >>> nonsense with load/store ordering. > >>> > >>> -- Pavan > >>> > >>> -- > >>> Pavan Balaji > >>> http://www.mcs.anl.gov/~balaji > >>> _______________________________________________ > >>> 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 > > > > > > > > > > _______________________________________________ > > mpi3-rma mailing list > > mpi3-rma(a)lists.mpi-forum.org > > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma > > -- > Pavan Balaji > http://www.mcs.anl.gov/~balaji > _______________________________________________ > mpi3-rma mailing list > mpi3-rma(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma

1 0

[Mpi3-rma] next RMA telecon, Mon April 11, 3pm Central
by Rajeev Thakur 02 Apr '11

02 Apr '11

The next RMA working group telecon will be on Monday, April 11, at 3.00pm Central. Please mark your calendars. Dial-in Number: 866-654-6744 International Dial-in Number: 1-517-308-8226 Participant Access code: 6086006 Rajeev

1 0

Re: [Mpi3-rma] Unified model discussion
by William Gropp 02 Apr '11

02 Apr '11

That's a good idea. Bill On Apr 2, 2011, at 12:37 PM, Pavan Balaji wrote: > > In the case of SEPARATE, Win_sync will be required to do two things: > (1) > order load/stores, and (2) synchronize public/private windows. > > We can as well use Win_sync for unified too, and just get it to do the > first part. > > -- Pavan > > On 04/02/2011 12:35 PM, William Gropp wrote: >> Would that call also complete/order local memory operations (e.g., we >> could use the same routine)? >> >> Bill >> >> On Apr 2, 2011, at 11:50 AM, Underwood, Keith D wrote: >> >>> That is an important point. What if we allow unified to work for >>> this use case without additional calls, but add a call to force >>> synchronization when the local and remote accesses would conflict? >>> >>> Keith >>> >>>> -----Original Message----- >>>> From: mpi3-rma-bounces(a)lists.mpi-forum.org [mailto:mpi3-rma- >>>> bounces(a)lists.mpi-forum.org] On Behalf Of Pavan Balaji >>>> Sent: Thursday, March 31, 2011 3:52 PM >>>> To: mpi3-rma(a)lists.mpi-forum.org >>>> Subject: [Mpi3-rma] Unified model discussion >>>> >>>> >>>> When we were having the discussion on the unified model during the >>>> last >>>> working group meeting, I forgot to point out one important use >>>> case: >>>> >>>> Process 0 >>>> ---------- >>>> Win_lock(shared, P0) >>>> load(A) >>>> store(B) >>>> Win_unlock >>>> >>>> Process 1 >>>> --------- >>>> Win_lock(shared, P0) >>>> Put(C) >>>> Get(D) >>>> Win_unlock >>>> >>>> That is, two processes are reading/writing to different parts of >>>> the >>>> window. This is an important model and can only be supported in >>>> unified, >>>> not separate (because of potential cache-line false sharing). >>>> >>>> So, basically, no we cannot remove the unified model in spite of >>>> all >>>> its >>>> nonsense with load/store ordering. >>>> >>>> -- Pavan >>>> >>>> -- >>>> Pavan Balaji >>>> http://www.mcs.anl.gov/~balaji >>>> _______________________________________________ >>>> 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 >> >> >> >> >> _______________________________________________ >> mpi3-rma mailing list >> mpi3-rma(a)lists.mpi-forum.org >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma > > -- > Pavan Balaji > http://www.mcs.anl.gov/~balaji 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] Unified model discussion
by Pavan Balaji 02 Apr '11

02 Apr '11

In the case of SEPARATE, Win_sync will be required to do two things: (1) order load/stores, and (2) synchronize public/private windows. We can as well use Win_sync for unified too, and just get it to do the first part. -- Pavan On 04/02/2011 12:35 PM, William Gropp wrote: > Would that call also complete/order local memory operations (e.g., we > could use the same routine)? > > Bill > > On Apr 2, 2011, at 11:50 AM, Underwood, Keith D wrote: > >> That is an important point. What if we allow unified to work for >> this use case without additional calls, but add a call to force >> synchronization when the local and remote accesses would conflict? >> >> Keith >> >>> -----Original Message----- >>> From: mpi3-rma-bounces(a)lists.mpi-forum.org [mailto:mpi3-rma- >>> bounces(a)lists.mpi-forum.org] On Behalf Of Pavan Balaji >>> Sent: Thursday, March 31, 2011 3:52 PM >>> To: mpi3-rma(a)lists.mpi-forum.org >>> Subject: [Mpi3-rma] Unified model discussion >>> >>> >>> When we were having the discussion on the unified model during the >>> last >>> working group meeting, I forgot to point out one important use case: >>> >>> Process 0 >>> ---------- >>> Win_lock(shared, P0) >>> load(A) >>> store(B) >>> Win_unlock >>> >>> Process 1 >>> --------- >>> Win_lock(shared, P0) >>> Put(C) >>> Get(D) >>> Win_unlock >>> >>> That is, two processes are reading/writing to different parts of the >>> window. This is an important model and can only be supported in >>> unified, >>> not separate (because of potential cache-line false sharing). >>> >>> So, basically, no we cannot remove the unified model in spite of all >>> its >>> nonsense with load/store ordering. >>> >>> -- Pavan >>> >>> -- >>> Pavan Balaji >>> http://www.mcs.anl.gov/~balaji >>> _______________________________________________ >>> 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 > > > > > _______________________________________________ > mpi3-rma mailing list > mpi3-rma(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma -- Pavan Balaji http://www.mcs.anl.gov/~balaji

1 0

Re: [Mpi3-rma] Unified model discussion
by William Gropp 02 Apr '11

02 Apr '11

Would that call also complete/order local memory operations (e.g., we could use the same routine)? Bill On Apr 2, 2011, at 11:50 AM, Underwood, Keith D wrote: > That is an important point. What if we allow unified to work for > this use case without additional calls, but add a call to force > synchronization when the local and remote accesses would conflict? > > Keith > >> -----Original Message----- >> From: mpi3-rma-bounces(a)lists.mpi-forum.org [mailto:mpi3-rma- >> bounces(a)lists.mpi-forum.org] On Behalf Of Pavan Balaji >> Sent: Thursday, March 31, 2011 3:52 PM >> To: mpi3-rma(a)lists.mpi-forum.org >> Subject: [Mpi3-rma] Unified model discussion >> >> >> When we were having the discussion on the unified model during the >> last >> working group meeting, I forgot to point out one important use case: >> >> Process 0 >> ---------- >> Win_lock(shared, P0) >> load(A) >> store(B) >> Win_unlock >> >> Process 1 >> --------- >> Win_lock(shared, P0) >> Put(C) >> Get(D) >> Win_unlock >> >> That is, two processes are reading/writing to different parts of the >> window. This is an important model and can only be supported in >> unified, >> not separate (because of potential cache-line false sharing). >> >> So, basically, no we cannot remove the unified model in spite of all >> its >> nonsense with load/store ordering. >> >> -- Pavan >> >> -- >> Pavan Balaji >> http://www.mcs.anl.gov/~balaji >> _______________________________________________ >> 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] MPI_WIN_GET_ATTR and Window attributes
by William Gropp 02 Apr '11

02 Apr '11

Agreed; the text should match. Bill On Mar 28, 2011, at 6:10 PM, Rolf Rabenseifner wrote: > MPI-2.2 p.338:30-31 > > write "pointers to integer" without further information. > Because size is an MPI_Aint integer, it should be a pointer to > MPI_Aint. > Because disp_unit is an "int" integer, it should be a pointer to int. > > You write in > https://svn.mpi-forum.org/trac/mpi-forum-web/attachment/ticket/270/one-side… > from ~March 15, 2011 at p.10:16 "pointers to integers (of size > MPI_Aint)" > > This is a change of an existing interface. > Hopefully unintended. > It should be fixed. > > Best regards > Rolf > > -- > Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner(a)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) > _______________________________________________ > 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] Unified model discussion
by Underwood, Keith D 02 Apr '11

02 Apr '11

That is an important point. What if we allow unified to work for this use case without additional calls, but add a call to force synchronization when the local and remote accesses would conflict? Keith > -----Original Message----- > From: mpi3-rma-bounces(a)lists.mpi-forum.org [mailto:mpi3-rma- > bounces(a)lists.mpi-forum.org] On Behalf Of Pavan Balaji > Sent: Thursday, March 31, 2011 3:52 PM > To: mpi3-rma(a)lists.mpi-forum.org > Subject: [Mpi3-rma] Unified model discussion > > > When we were having the discussion on the unified model during the last > working group meeting, I forgot to point out one important use case: > > Process 0 > ---------- > Win_lock(shared, P0) > load(A) > store(B) > Win_unlock > > Process 1 > --------- > Win_lock(shared, P0) > Put(C) > Get(D) > Win_unlock > > That is, two processes are reading/writing to different parts of the > window. This is an important model and can only be supported in > unified, > not separate (because of potential cache-line false sharing). > > So, basically, no we cannot remove the unified model in spite of all > its > nonsense with load/store ordering. > > -- Pavan > > -- > Pavan Balaji > http://www.mcs.anl.gov/~balaji > _______________________________________________ > mpi3-rma mailing list > mpi3-rma(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma

1 0