Re: [Mpi3-rma] MPI_Win_Allocate_shared proposal draft
Sorry, it's https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/287 On Aug 29, 2011, at 1:40 PM, Rajeev Thakur wrote:
It's at the bottom of this mail
https://svn.mpi-forum.org/trac/mpi-forum-web/attachment/ticket/284/
On Aug 29, 2011, at 1:37 PM, Jeff Hammond wrote:
Can someone post a link to the ticket for MPI_Comm_split_type? Google finds me nothing on this function.
Thanks,
Jeff
On Mon, Aug 29, 2011 at 1:22 PM, Rajeev Thakur <[email protected]> wrote:
6:39 - I would like the sentence to clearly say that it is the user's responsibility to pass a communicator whose processes can share memory. How about changing it to
"It is the user's responsibility to ensure that the communicator comm represents a group of processes that can create a shared memory segment that can be accessed by all processes in the group."
Then we should say what happens if the communicator contains processes that cannot share memory.
If the new function MPI_Comm_split_type passes, we need to remember to provide a reference here to it, because it is directly relevant for this use case.
Rajeev
On Aug 29, 2011, at 1:16 PM, Rajeev Thakur wrote:
Looks good. Some comments:
6:14 - baseptrs -> baseptr
6:26 - DISP_UNIT -> SIZE
6:30 - "among all processes" -> "among all processes in comm"
6:31 - "returns" -> "and returns"
6:32 - "be target" -> "be the target"
6:33 - "accessed" -> "accesses"
6:33 - change to "remote processes; the base pointers for other processes can be queried..."
6:35 - Much of the sentence "The returned memory..." seems to be a repetition of what has been said before.
6:39 - I would like the sentence to clearly say that it is the user's responsibility to pass a communicator whose processes can share memory. How about changing it to
"It is the user's responsibility to ensure that the communicator comm represents a group of processes that can create a shared memory segment that can be accessed by all processes in the group."
Then we should say what happens if the communicator contains processes that cannot share memory.
7:10 - "as info key" -> "as an info key"
7:35 - MPI_WIN_FLAVOR_SHM is not defined in 11.2.6
Since the default allocation is supposed to be contiguous, is the intended implementation method supposed to be something like the following: * wait for everyone to call the function * gather everyone's local size; add it up * allocate single, large shared memory * return local pointers everywhere
On Aug 29, 2011, at 12:12 AM, Torsten Hoefler wrote:
Hello all,
We just posted a new update to the proposal (thanks to Bill for the comments!) to the ticket at https://svn.mpi-forum.org/trac/mpi-forum-web/attachment/ticket/284/
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 _______________________________________________ mpi3-rma mailing list [email protected] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma
_______________________________________________ mpi3-rma mailing list [email protected] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma
_______________________________________________ mpi3-rma mailing list [email protected] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma
-- Jeff Hammond Argonne Leadership Computing Facility University of Chicago Computation Institute [email protected] / (630) 252-5381 http://www.linkedin.com/in/jeffhammond https://wiki.alcf.anl.gov/index.php/User:Jhammond
_______________________________________________ mpi3-rma mailing list [email protected] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma
_______________________________________________ mpi3-rma mailing list [email protected] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma
participants (1)
-
Rajeev Thakur