September 2011 - mpiwg-hybridpm - mailman3.cels.anl.gov

Re: [Mpi3-hybridpm] [Mpi3-rma] Fix for win_allocate_shared
by Pavan Balaji 23 Sep '11

23 Sep '11

On 09/23/2011 12:32 PM, Torsten Hoefler wrote: > On Fri, 2011-09-23 at 12:25 -0500, Pavan Balaji wrote: >> On 09/23/2011 02:39 AM, Torsten Hoefler wrote: >>> "The semantic rules for shared memory windows in the MPI_RMA_SEPARATE >>> model allow concurrent load/store accesses from two distinct processes >>> to the same target window that is remote to both processes. An >>> implementation cannot expose shared memory windows on hardware that does >>> not support this access mode." >> >> This seems to suggest that it won't work for non-cache-coherent systems. >> Didn't we decide against that? > Brian probably wants to comment on this :-). > > Here's my recap: The issue was that many architectures may not be able > to support UNIFIED. So we don't want to limit the SEPARATE model too > much in order to still make it useful. If we later, based on our > experience, find that we need this limitation to support existing > architectures, then we can add the restriction. However, if we add it > now, it may limiting the programming model unnecessarily. I'm not sure how this is better than my original suggestion of leaving this as "undefined" for SEPARATE. That way, it is possible to define it in the later MPI standards. But Jim and you didn't want to do that. -- Pavan -- Pavan Balaji http://www.mcs.anl.gov/~balaji

1 0

Re: [Mpi3-hybridpm] [Mpi3-rma] Fix for win_allocate_shared
by Torsten Hoefler 23 Sep '11

23 Sep '11

On Fri, 2011-09-23 at 12:25 -0500, Pavan Balaji wrote: > On 09/23/2011 02:39 AM, Torsten Hoefler wrote: > > "The semantic rules for shared memory windows in the MPI_RMA_SEPARATE > > model allow concurrent load/store accesses from two distinct processes > > to the same target window that is remote to both processes. An > > implementation cannot expose shared memory windows on hardware that does > > not support this access mode." > > This seems to suggest that it won't work for non-cache-coherent systems. > Didn't we decide against that? Brian probably wants to comment on this :-). Here's my recap: The issue was that many architectures may not be able to support UNIFIED. So we don't want to limit the SEPARATE model too much in order to still make it useful. If we later, based on our experience, find that we need this limitation to support existing architectures, then we can add the restriction. However, if we add it now, it may limiting the programming model unnecessarily. All the Best, Torsten

1 0

Re: [Mpi3-hybridpm] [Mpi3-rma] Fix for win_allocate_shared
by Pavan Balaji 23 Sep '11

23 Sep '11

On 09/23/2011 02:39 AM, Torsten Hoefler wrote: > "The semantic rules for shared memory windows in the MPI_RMA_SEPARATE > model allow concurrent load/store accesses from two distinct processes > to the same target window that is remote to both processes. An > implementation cannot expose shared memory windows on hardware that does > not support this access mode." This seems to suggest that it won't work for non-cache-coherent systems. Didn't we decide against that? -- Pavan Balaji http://www.mcs.anl.gov/~balaji

1 0

[Mpi3-hybridpm] Fix for win_allocate_shared
by Torsten Hoefler 23 Sep '11

23 Sep '11

Hi all, So to fix the recently discovered problem in the separate model and win_allocate_shared, the formed ad-hoc working group proposes the following: Add the following sentence to https://svn.mpi-forum.org/trac/mpi-forum-web/raw-attachment/ticket/284/one-… page 46 line 47 after ".. obey the following rules.": "For shared memory windows (cf. Section~\ref{sec:alloc_shared}), a store/load that accesses a memory region that is logically associated with a remote process is equivalent to a put/get in the following rules." And add the following advice to implementors on page 47 line 33 after "... made visible to the other).": "The semantic rules for shared memory windows in the MPI_RMA_SEPARATE model allow concurrent load/store accesses from two distinct processes to the same target window that is remote to both processes. An implementation cannot expose shared memory windows on hardware that does not support this access mode." I'm sure the wording can be tweaked (please propose changes here) but this is what we came up with. Please comment! We plan to discuss this later in the full forum because there are some trade-offs involved here. All the Best, 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-hybridpm] Hybrid WG meeting tomorrow
by Torsten Hoefler 21 Sep '11

21 Sep '11

Hi all, Sorry for the cross-post. For some reason, the schedule for the Hybrid stuff wasn't changed as we discussed in the last WG telecon. There is a FT working group meeting from 1-3pm. It would be great if we could have a spontaneous parallel Hybrid/One-Sided WG meeting between 1-3pm. We should discuss a new issue in the shared memory proposal which will lead to postponing the first reading. It's going to be fun -- trying to fiddle with local/remote load/store accesses in shared and non-shared and overlapping windows :-). All the Best, Torsten

1 0

Re: [Mpi3-hybridpm] Hey everyone
by Rajeev Thakur 14 Sep '11

14 Sep '11

I am not aware of an existing prototype implementation. Rajeev On Sep 12, 2011, at 11:09 AM, Emil Rosik wrote: > My Name is Emil Rosik and i'm writting my diploma thesis in this direction "mixed mode" programming. I've read your PDF and Presentation and i see your "Endpoints" approach for (OpenMP / MPI). My Question ist, does a prototype implementation exists? or something in that way that i can obtain, or is the only way to use that approach to implement it for myself ? > > Best regards, > > Emil > > > > > Schon gehï¿½rt? WEB.DE hat einen genialen Phishing-Filter in die > Toolbar eingebaut! http://produkte.web.de/go/toolbar > _______________________________________________ > Mpi3-hybridpm mailing list > Mpi3-hybridpm(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-hybridpm

1 0

[Mpi3-hybridpm] Fw: [MPI Forum] #217: MPI3 Hybrid Programming: Proposal for Helper Threads
by Douglas Miller 13 Sep '11

13 Sep '11

I've added a comment to ticket #217 that contains a couple straw votes. Since we've not be able to discuss the Helper Teams proposal for some time, I'd like to see if we can get this done online. Please review the proposal, and contact me or the working group for answers to questions, and cast a straw vote as to whether you think this proposal should be brought before the Forum for formal readings and votes. You will need to login to the wiki (authenticate) in order to see and cast votes. Also, if you vote "No" please provide some information (in a separate post/comment) about what your objections are. thanks, P.S. I was able to get a Trac Wiki Macro installed that provides this "Poll" functionality. More information is at http://trac-hacks.org/wiki/PollMacro _______________________________________________ Douglas Miller BlueGene Messaging Development IBM Corp., Rochester, MN USA Bldg 030-2 A401 dougmill(a)us.ibm.com Douglas Miller/Rochester/IBM ----- Forwarded by Douglas Miller/Rochester/IBM on 09/13/2011 07:52 AM ----- "MPI Forum" <mpi-22(a)lists.mpi -forum.org> To undisclosed-recipients:; 09/13/2011 07:50 cc AM Subject Re: [MPI Forum] #217: MPI3 Hybrid Programming: Proposal for Helper Threads #217: MPI3 Hybrid Programming: Proposal for Helper Threads -------------------------------------+------------------------------------- Reporter: | Owner: dougmill@… | dougmill Type: | Status: Enhancements to standard | assigned Priority: Forum | Milestone: feedback requested | 2010/05/03 Chicago, USA Version: MPI | Resolution: 3.0 | Implementation status: Keywords: | Unnecessary Author: Bill Gropp: 0 | Author: Rich Graham: 0 Author: Adam Moody: 0 | Author: Torsten Hoefler: 0 Author: Dick Treumann: 0 | Author: Jesper Larsson Traeff: 0 Author: George Bosilca: 0 | Author: David Solt: 0 Author: Bronis de Supinski: 0 | Author: Rajeev Thakur: 0 Author: Jeff Squyres: 0 | Author: Alexander Supalov: 0 Author: Rolf Rabenseifner: 0 | -------------------------------------+------------------------------------- Comment (by dougmill): Since we have not been able to discuss this in a meeting, I've setup a Straw Vote to decide if we should carry forward this proposal. Please review the latest attachment (mpi3-ticket217-ei-2.pdf) and vote accordingly. Especially if you vote "No", please post why you object or what it is you object to. Thanks. Note, you will need to login to the wiki before you can see, or cast, votes. [[Poll(Should the "Teams" (Helper Threads) proposal be carried forward to a Forum reading and vote?; Yes; No)]] Also, please take a look at the "alternate" proposal that makes the JOIN team size dynamic, and give a quick Yes/No on that as well. [[Poll(Is the dynamic team size proposal worth considering?; Yes; No)]] -- Ticket URL: < https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/217#comment:9> MPI Forum <https://svn.mpi-forum.org/> MPI Forum

1 0

[Mpi3-hybridpm] Hey everyone
by Emil Rosik 12 Sep '11

12 Sep '11

1 0

Re: [Mpi3-hybridpm] Next telecon
by Pavan Balaji 06 Sep '11

06 Sep '11

Reminder for the call today. On 09/02/2011 08:40 PM, Pavan Balaji wrote: > All, > > The next telecon will be on 09/06 at 2pm central. The telecon > information is on the wiki. > > Agenda items: > > 1. Final run through the two shared memory drafts. > > 2. Helper team proposal discussion and straw vote. > > 3. Discussion on the second part of the endpoints proposal (communicator > merging). > > -- Pavan > -- Pavan Balaji http://www.mcs.anl.gov/~balaji

1 0

[Mpi3-hybridpm] Next telecon
by Pavan Balaji 02 Sep '11

02 Sep '11

All, The next telecon will be on 09/06 at 2pm central. The telecon information is on the wiki. Agenda items: 1. Final run through the two shared memory drafts. 2. Helper team proposal discussion and straw vote. 3. Discussion on the second part of the endpoints proposal (communicator merging). -- Pavan -- Pavan Balaji http://www.mcs.anl.gov/~balaji

1 0