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 <thakur(a)mcs.anl.gov> 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
>>>>> 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
>>>
>>>
>>> _______________________________________________
>>> 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
>> University of Chicago Computation Institute
>> jhammond(a)alcf.anl.gov / (630) 252-5381
>> http://www.linkedin.com/in/jeffhammond
>> https://wiki.alcf.anl.gov/index.php/User:Jhammond
>>
>> _______________________________________________
>> 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
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 <thakur(a)mcs.anl.gov> 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
>>>> 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
>>
>>
>> _______________________________________________
>> 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
> University of Chicago Computation Institute
> jhammond(a)alcf.anl.gov / (630) 252-5381
> http://www.linkedin.com/in/jeffhammond
> https://wiki.alcf.anl.gov/index.php/User:Jhammond
>
> _______________________________________________
> mpi3-rma mailing list
> mpi3-rma(a)lists.mpi-forum.org
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma
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 <thakur(a)mcs.anl.gov> 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
>>> 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
>
>
> _______________________________________________
> 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
University of Chicago Computation Institute
jhammond(a)alcf.anl.gov / (630) 252-5381
http://www.linkedin.com/in/jeffhammondhttps://wiki.alcf.anl.gov/index.php/User:Jhammond
> 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
>> 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
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
> mpi3-rma(a)lists.mpi-forum.org
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma
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
Hi all,
Jim and I updated the MPI_Win_Allocate_shared proposal draft with the
feedback from the last Forum. We will discuss if the draft satisfies the
needs of the hybrid WG tomorrow at the Hybrid telecon. However, we would
also like the RMA group to check the draft, and it's integration in the
One Sided Chapter, carefully.
Today's draft is at
https://svn.mpi-forum.org/trac/mpi-forum-web/attachment/wiki/MPI3Hybrid/win…
You can find the changes quickly if you search for ticket 284 in the
draft.
Thank you very much,
Jim & 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
