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

Re: [Mpi3-rma] New version of proposal
by Rajeev Thakur 30 Jan '11

30 Jan '11

The examples that earlier demonstrated the lockfree synchronization mode have only had their captions changed. I think they need lock-unlock calls in them so that users know that these calls are needed and where they are supposed to be placed. pg 22, ln 5: The new op MPI_NO_OP to MPI_Get_accumulate is defined as "It corresponds to the associative function f(a,b) = a; i.e., the current value in the target memory is returned in the result buffer at the origin." Well, "the current value in the target memory is returned in the result buffer at the origin" applies to any op passed to Get_accumulate (by definition). What is special about MPI_NO_OP needs to be mentioned. Therefore, I suggest saying "It corresponds to the associative function f(a,b) = a; i.e., the current value in the target memory is returned in the result buffer at the origin, and no operation is performed on the target buffer." Rajeev

1 0

Re: [Mpi3-rma] New version of proposal
by Pavan Balaji 26 Jan '11

26 Jan '11

All, I want to point out that the draft that Bill uploaded also contains the merged changes from the other proposal, that had been committed into the svn (after incorporating Brian's comments) -- so this is actually not a minor change compared to the version Torsten uploaded. I had sent the document to Torsten for initial review, and was not meant to be sent out to the entire group yet. But since it's anyway out in the open now, please go through it and let me know your comments. Thanks, -- Pavan On 01/26/2011 09:25 AM, William Gropp wrote: > I just updated the svn and the wiki with some minor fixes for the > example index and function index; I also added a comment about the > info keys accumulate_order (its not listed with the win-create info > keys). This is a very minor change from Torsten's version and you > should only get it if you use the example index. > > Bill > > On Jan 25, 2011, at 10:51 PM, Torsten Hoefler wrote: > >> Hello all, >> >> I fixed all the things we discussed in the last telecon. Some comments >> remain in the document. Most of them are simple reminders and trivial. >> Two comments are things we wanted to discuss via email. >> >> Here are the major open issues: >> >> - we wanted to discuss the relaxation of the "same op" requirement for >> accumulates >> - we also wanted to add some statements about flush, I will do this >> asap >> (later this week) >> - I think our examples need careful checks and we might want more (to >> demonstrate synch and flush). I'll think about this later this week. >> - the merge >> >> I updated marked and clean version on the Wiki. Please read the >> document again carefully. >> >> 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 >> _______________________________________________ >> 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] New version of proposal
by William Gropp 26 Jan '11

26 Jan '11

I just updated the svn and the wiki with some minor fixes for the example index and function index; I also added a comment about the info keys accumulate_order (its not listed with the win-create info keys). This is a very minor change from Torsten's version and you should only get it if you use the example index. Bill On Jan 25, 2011, at 10:51 PM, Torsten Hoefler wrote: > Hello all, > > I fixed all the things we discussed in the last telecon. Some comments > remain in the document. Most of them are simple reminders and trivial. > Two comments are things we wanted to discuss via email. > > Here are the major open issues: > > - we wanted to discuss the relaxation of the "same op" requirement for > accumulates > - we also wanted to add some statements about flush, I will do this > asap > (later this week) > - I think our examples need careful checks and we might want more (to > demonstrate synch and flush). I'll think about this later this week. > - the merge > > I updated marked and clean version on the Wiki. Please read the > document again carefully. > > 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 > _______________________________________________ > 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

[Mpi3-rma] New version of proposal
by Torsten Hoefler 25 Jan '11

25 Jan '11

Hello all, I fixed all the things we discussed in the last telecon. Some comments remain in the document. Most of them are simple reminders and trivial. Two comments are things we wanted to discuss via email. Here are the major open issues: - we wanted to discuss the relaxation of the "same op" requirement for accumulates - we also wanted to add some statements about flush, I will do this asap (later this week) - I think our examples need careful checks and we might want more (to demonstrate synch and flush). I'll think about this later this week. - the merge I updated marked and clean version on the Wiki. Please read the document again carefully. 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

[Mpi3-rma] RMA telecon, 1/31, 4pm Central
by Rajeev Thakur 25 Jan '11

25 Jan '11

We will have our next RMA telecon on Mon, Jan 31, at 4.00pm Central. Dial-in Number: 866-654-6744 International Dial-in Number: 1-517-308-8226 Participant Access code: 6086006 Rajeev

1 0

[Mpi3-rma] presentation about overhead of datatypes
by Underwood, Keith D 24 Jan '11

24 Jan '11

On the call today, somebody asked about the results that we had generated regarding the number of arguments, etc.

1 0

Re: [Mpi3-rma] RMA telecon, 1/24, noon Central
by Pavan Balaji 24 Jan '11

24 Jan '11

On 01/24/2011 11:11 AM, Barrett, Brian W wrote: > On Jan 23, 2011, at 11:22 AM, Pavan Balaji wrote: > First, I'm not entirely sure the working group reached consensus on > the addition of RMA_* functions. I know there has been significant > discussion, but I don't believe discussion was reached. I think this > merits more discussion at today's telecon; the semantics still seem > rather poorly defined and there has been discussion about a > presentation to the entire forum in a couple weeks which would > require having all the details sorted out. I don't think there were objections last time, but yes, we should definitely discuss again to make sure everyone is comfortable. Here are the changes in the draft I sent (numbers on the pages, not the PDF numbering); it was just easier to list them over email. pg. 1. lines 34-41: added the additional functions. pg. 13: completely new. pg. 14: all of the red content. pg. 20: all of the red content. pg. 23: lines 9-48. pg. 24: lines 1-2. I missed out a few more minor changes (in listing functions), which I was planning to add: pg. 9: lines 44-48. pg. 19: lines 22-24. -- Pavan -- Pavan Balaji http://www.mcs.anl.gov/~balaji

1 0

Re: [Mpi3-rma] RMA telecon, 1/24, noon Central
by Barrett, Brian W 24 Jan '11

24 Jan '11

On Jan 23, 2011, at 11:22 AM, Pavan Balaji wrote: > On 01/23/2011 12:20 PM, Barrett, Brian W wrote: >> Before you commit, it would be good to get some favorable reviews. >> >> I'm having some trouble figuring out what you merged in from >> Torsten's document - I can see the purple removes, but given that >> there was already a bunch of red and dark red, it's a bit difficult >> to pick out the additions. Would it be possible to either pick a >> different color for your additions, merge into Torsten's clean >> document, or list all the changes? > > I only merged the MPI_RMA_PUT/GET/ACCUMULATE/GET_ACCUMULATE functions > that we agreed on in the telecon last time. I can put it in a different > color if you really want, but I don't see a point of repeating the > entire exercise again. First, I'm not entirely sure the working group reached consensus on the addition of RMA_* functions. I know there has been significant discussion, but I don't believe discussion was reached. I think this merits more discussion at today's telecon; the semantics still seem rather poorly defined and there has been discussion about a presentation to the entire forum in a couple weeks which would require having all the details sorted out. Second, the diffs make it much easier to verify what the total sum of changes were. A number of people have done extremely close readings of the RMA document (what Torsten sent out a couple days ago), and fine language details are now being discussed. Once that level of discussion has been reached, making such large changes (with diffs that don't make sense - such as purple marking the addition of text that was never in the main document and shouldn't be in the main document) doesn't inspire confidence. Being able to see the exactly what was brought in would make the process much smoother. Brian -- Brian W. Barrett Dept. 1423: Scalable System Software Sandia National Laboratories

1 0

Re: [Mpi3-rma] RMA telecon, 1/24, noon Central
by Rajeev Thakur 23 Jan '11

23 Jan '11

Several examples (11.12, 11.14, 11.15, 11.16) demonstrate the lockless synchronization mode. Does that still exist? MPI_Accumulate has a couple of sentences that specify that only predefined ops are allowed. That text is missing in MPI_Get_accumulate and MPI_Fetch_and_op. Rajeev On Jan 19, 2011, at 9:51 PM, Torsten Hoefler wrote: > Hello, > > I just updated the version on the page (after more discussions with > Brian). We have one more comment to discuss at the telecon and one > change. See: > > https://svn.mpi-forum.org/trac/mpi-forum-web/attachment/wiki/mpi3-rma-propo… > > Brian also discovered that the definition of the sync call could be > misinterpreted to be blocking (if a transfer is in progress from A to B > and B calls synch, which itself might now depend on the completion of > the transfer). I think it is defined as nonblocking and thus might > return a buffer in an inconsistent state (which is now the user's > problem). Any opinions? > > Thanks & All the Best, > Torsten > > PS: The latex diff is: > > --- > @@ -2098,8 +2098,12 @@ > specifies the set of origin processes for that > epoch. > \item > -Finally, shared and exclusive locks are provided by the two functions > -\mpifunc{MPI\_WIN\_LOCK} and \mpifunc{MPI\_WIN\_UNLOCK}. > +\hreplace{Finally, shared and exclusive locks are provided by the two functions > +\mpifunc{MPI\_WIN\_LOCK} and \mpifunc{MPI\_WIN\_UNLOCK}.}{Finally, shared lock > +access is provided by the functions \mpifunc{MPI\_WIN\_LOCK}, > +\mpifunc{MPI\_WIN\_LOCKALL}, \mpifunc{MPI\_WIN\_UNLOCK}, and > +\mpifunc{MPI\_WIN\_UNLOCK}. \mpifunc{MPI\_WIN\_LOCK} and > +\mpifunc{MPI\_WIN\_UNLOCK} also provide exclusive lock capability. } > Lock synchronization > is useful for \MPI/ applications that > emulate a shared memory model via \MPI/ calls; e.g., in a ``billboard'' > @@ -3499,7 +3503,11 @@ > update becomes visible in the public window copy. There is one > exception to this rule, in the case where the same variable is updated > by two concurrent accumulates that use the same operation, with the same > -predefined datatype, on the same window. > +predefined datatype, on the same window. \hcomment{Brian and Torsten think > +that this is limiting the usefulness of the programming model > +significantly, can we relax this (remove the ``same op'' restriction? > +However, we have to be careful to still allow hardware optimizations of > +subsets of operations only. Can this be done?} > \item > A put or accumulate must not access a target window once a local update > or a put or accumulate update to another (overlapping) target window > --- > > -- > 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 > _______________________________________________ > 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] RMA telecon, 1/24, noon Central
by Pavan Balaji 23 Jan '11

23 Jan '11

Hi Brian, On 01/23/2011 12:20 PM, Barrett, Brian W wrote: > Before you commit, it would be good to get some favorable reviews. > > I'm having some trouble figuring out what you merged in from > Torsten's document - I can see the purple removes, but given that > there was already a bunch of red and dark red, it's a bit difficult > to pick out the additions. Would it be possible to either pick a > different color for your additions, merge into Torsten's clean > document, or list all the changes? I only merged the MPI_RMA_PUT/GET/ACCUMULATE/GET_ACCUMULATE functions that we agreed on in the telecon last time. I can put it in a different color if you really want, but I don't see a point of repeating the entire exercise again. We had some discussion on (1) ordering of requests, (2) user-defined accumulates, and (3) using shared memory for RMA windows, which we decided to drop (or discuss more later), which are still in purple. -- Pavan -- Pavan Balaji http://www.mcs.anl.gov/~balaji

1 0