Thanks a lot! Jim. Now I make sense

Sufeng


On Fri, Jul 5, 2013 at 11:25 AM, <discuss-request@mpich.org> wrote:
Send discuss mailing list submissions to
        discuss@mpich.org

To subscribe or unsubscribe via the World Wide Web, visit
        https://lists.mpich.org/mailman/listinfo/discuss
or, via email, send a message with subject or body 'help' to
        discuss-request@mpich.org

You can reach the person managing the list at
        discuss-owner@mpich.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of discuss digest..."


Today's Topics:

   1. Re:  beginner for remote mem access (sufeng) (Pavan Balaji)
   2.  MPI Benchmark Suite (Jiri Simsa)
   3. Re:  beginner for remote mem access (sufeng) (Jim Dinan)
   4. Re:  beginner for remote mem access (sufeng) (Sufeng Niu)
   5. Re:  beginner for remote mem access (sufeng) (Pavan Balaji)
   6. Re:  MPI Benchmark Suite (Pavan Balaji)
   7. Re:  beginner for remote mem access (sufeng) (Sufeng Niu)


----------------------------------------------------------------------

Message: 1
Date: Fri, 05 Jul 2013 10:36:07 -0500
From: Pavan Balaji <balaji@mcs.anl.gov>
To: discuss@mpich.org
Cc: Sufeng Niu <sniu@hawk.iit.edu>
Subject: Re: [mpich-discuss] beginner for remote mem access (sufeng)
Message-ID: <51D6E7E7.8070306@mcs.anl.gov>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed


On 07/05/2013 10:28 AM, Sufeng Niu wrote:
> 1.
> MPI_Win_fence is not similar to MPI_Barrier in some cases.  The
> MPICH implementation can turn some calls into no-ops and others into
> MPI_Reduce_scatter.
> I am not quite sure about "turn some calls into no-ops and others into
> MPI_Reduce_scatter" Could you please give an example if possible?
> Another thing is if a process create a window for other process, but the
> data access is available after some operations. Should I use
> MPI_Win_fence or MPI_Barrier to sync? or other methods?

MPI_WIN_FENCE will make sure that all PUT/GET/ACCUMULATE operations are
complete locally and remotely.  This is probably what you need.

MPI_BARRIER is useless in this case since PUT/GET/ACCUMULATE can be
nonblocking.

> 2.
> Regarding "use MPI window as thread level", I really don't
> understand your thinking at all.  MPI RMA is not shared memory nor is
> MPI a threading model.
> Sorry for uncleared statements, right now I would like to do
> multithreads and MPI hybrid programming. let me give an example: I have
> 3 processes, each one has 8 threads. thread 0 in process 0 creates a RMA
> window. if I would like all other threads to access it, should I use
> thread 0 in process 1, thread 0 in process 2 to MPI_Get the data from
> window, then use shared memory for internal threads to load the data? i
> am not sure what is the proper way for RMA in hybrid model.

All threads within the OS process are part of the same MPI rank.  Any of
them can access the window as the same rank.

  -- Pavan

--
Pavan Balaji
http://www.mcs.anl.gov/~balaji


------------------------------

Message: 2
Date: Fri, 5 Jul 2013 11:38:13 -0400
From: Jiri Simsa <jsimsa@cs.cmu.edu>
To: discuss@mpich.org
Subject: [mpich-discuss] MPI Benchmark Suite
Message-ID:
        <CAHs9ut-=FJeUDG-T2-qqDhcDMBGfGuXPHG7VQp8_xYzXTxPAzA@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"

Hello,

Could anyone point me in the direction of programs that are representative
of MPI programs? I am looking for something like PARSEC (
http://parsec.cs.princeton.edu/) for MPI. In other words, I am interested
in macro-bechnmarks not micro-benchmarks. Thank you.

Best,

--Jiri Simsa
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mpich.org/pipermail/discuss/attachments/20130705/ab3a6a55/attachment-0001.html>

------------------------------

Message: 3
Date: Fri, 5 Jul 2013 11:43:29 -0400
From: Jim Dinan <james.dinan@gmail.com>
To: discuss@mpich.org
Subject: Re: [mpich-discuss] beginner for remote mem access (sufeng)
Message-ID:
        <CAOoEU4E1j4x7hxR6FrZMLrjsfaH31tzDTgucyiF5F3osduxY2Q@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"

On Fri, Jul 5, 2013 at 11:28 AM, Sufeng Niu <sniu@hawk.iit.edu> wrote:

> 1.
> MPI_Win_fence is not similar to MPI_Barrier in some cases.  The
> MPICH implementation can turn some calls into no-ops and others into
> MPI_Reduce_scatter.
> I am not quite sure about "turn some calls into no-ops and others into
> MPI_Reduce_scatter" Could you please give an example if possible? Another
> thing is if a process create a window for other process, but the data
> access is available after some operations. Should I use MPI_Win_fence or
> MPI_Barrier to sync? or other methods?
>

When you call MPI_Win_fence, the MPI implementation does not need to wait
for all processes to call the function before proceeding.  It does require
that all RMA operations in a given process' access epoch are complete, and
that all RMA accesses in its exposure epoch (i.e., targeting the given
process) are also complete.  If, for example, there is no preceding epoch,
the call to MPI_Win_fence is a no op.

Generally speaking, you should synchronize all accesses to data exposed in
a window using RMA synchronization operations.  Barrier does not provide
any consistency for RMA operations.


> 2.
> Regarding "use MPI window as thread level", I really don't
> understand your thinking at all.  MPI RMA is not shared memory nor is
> MPI a threading model.
> Sorry for uncleared statements, right now I would like to do multithreads
> and MPI hybrid programming. let me give an example: I have 3 processes,
> each one has 8 threads. thread 0 in process 0 creates a RMA window. if I
> would like all other threads to access it, should I use thread 0 in process
> 1, thread 0 in process 2 to MPI_Get the data from window, then use shared
> memory for internal threads to load the data? i am not sure what is the
> proper way for RMA in hybrid model.
>

The threads can all access the data in the window, provided that the MPI
process synchronizes accesses by threads in the process correctly with
respect to what other processes are doing.  Note that data consistency
across threads is outside of the MPI specification, and you should use e.g.
Pthreads or OpenMP primitives to ensure that data is consistent across
threads.

 ~Jim.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mpich.org/pipermail/discuss/attachments/20130705/d2064a55/attachment-0001.html>

------------------------------

Message: 4
Date: Fri, 5 Jul 2013 11:18:22 -0500
From: Sufeng Niu <sniu@hawk.iit.edu>
To: Pavan Balaji <balaji@mcs.anl.gov>
Cc: discuss@mpich.org
Subject: Re: [mpich-discuss] beginner for remote mem access (sufeng)
Message-ID:
        <CAFNNHkyV3k1168kYjOhX2OpeF+TcjLRsg6Oj2oL0pZ-KwHQKXw@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"

Hi Pavan,

Thanks a lot!

Now I make sense for MPI_Win_fence.

for hybrid RMA issue, did you mean in each rank, remote get the data into a
shared memory, then threads in each rank load it by thread-level operation?

Thank you!
Sufeng



On Fri, Jul 5, 2013 at 10:36 AM, Pavan Balaji <balaji@mcs.anl.gov> wrote:

>
> On 07/05/2013 10:28 AM, Sufeng Niu wrote:
>
>> 1.
>> MPI_Win_fence is not similar to MPI_Barrier in some cases.  The
>> MPICH implementation can turn some calls into no-ops and others into
>> MPI_Reduce_scatter.
>> I am not quite sure about "turn some calls into no-ops and others into
>> MPI_Reduce_scatter" Could you please give an example if possible?
>> Another thing is if a process create a window for other process, but the
>> data access is available after some operations. Should I use
>> MPI_Win_fence or MPI_Barrier to sync? or other methods?
>>
>
> MPI_WIN_FENCE will make sure that all PUT/GET/ACCUMULATE operations are
> complete locally and remotely.  This is probably what you need.
>
> MPI_BARRIER is useless in this case since PUT/GET/ACCUMULATE can be
> nonblocking.
>
>
>  2.
>> Regarding "use MPI window as thread level", I really don't
>> understand your thinking at all.  MPI RMA is not shared memory nor is
>> MPI a threading model.
>> Sorry for uncleared statements, right now I would like to do
>> multithreads and MPI hybrid programming. let me give an example: I have
>> 3 processes, each one has 8 threads. thread 0 in process 0 creates a RMA
>> window. if I would like all other threads to access it, should I use
>> thread 0 in process 1, thread 0 in process 2 to MPI_Get the data from
>> window, then use shared memory for internal threads to load the data? i
>> am not sure what is the proper way for RMA in hybrid model.
>>
>
> All threads within the OS process are part of the same MPI rank.  Any of
> them can access the window as the same rank.
>
>  -- Pavan
>
> --
> Pavan Balaji
> http://www.mcs.anl.gov/~balaji
>



--
Best Regards,
Sufeng Niu
ECASP lab, ECE department, Illinois Institute of Technology
Tel: 312-731-7219
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mpich.org/pipermail/discuss/attachments/20130705/2454c8c0/attachment-0001.html>

------------------------------

Message: 5
Date: Fri, 05 Jul 2013 11:20:41 -0500
From: Pavan Balaji <balaji@mcs.anl.gov>
To: Sufeng Niu <sniu@hawk.iit.edu>
Cc: discuss@mpich.org
Subject: Re: [mpich-discuss] beginner for remote mem access (sufeng)
Message-ID: <51D6F259.80800@mcs.anl.gov>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed


On 07/05/2013 11:18 AM, Sufeng Niu wrote:
> for hybrid RMA issue, did you mean in each rank, remote get the data
> into a shared memory, then threads in each rank load it by thread-level
> operation?

All threads are in the same process, so they all already share memory.
Perhaps its best if you try to learn how threads work before attempting
to use them with MPI.

  -- Pavan

--
Pavan Balaji
http://www.mcs.anl.gov/~balaji


------------------------------

Message: 6
Date: Fri, 05 Jul 2013 11:22:28 -0500
From: Pavan Balaji <balaji@mcs.anl.gov>
To: discuss@mpich.org
Cc: Jiri Simsa <jsimsa@cs.cmu.edu>
Subject: Re: [mpich-discuss] MPI Benchmark Suite
Message-ID: <51D6F2C4.7030002@mcs.anl.gov>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed


On 07/05/2013 10:38 AM, Jiri Simsa wrote:
> Could anyone point me in the direction of programs that are
> representative of MPI programs? I am looking for something like PARSEC
> (http://parsec.cs.princeton.edu/) for MPI. In other words, I am
> interested in macro-bechnmarks not micro-benchmarks. Thank you.

You could try the Sequoia suite.  There's also the NAS parallel
benchmarks and Graph500 benchmarks.

  -- Pavan

--
Pavan Balaji
http://www.mcs.anl.gov/~balaji


------------------------------

Message: 7
Date: Fri, 5 Jul 2013 11:24:59 -0500
From: Sufeng Niu <sniu@hawk.iit.edu>
To: Pavan Balaji <balaji@mcs.anl.gov>
Cc: discuss@mpich.org
Subject: Re: [mpich-discuss] beginner for remote mem access (sufeng)
Message-ID:
        <CAFNNHkzCaNw+gQhSriR1xUOo853bNPAtM7Z3TTOBS_XB1JD3ww@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"

Thanks a lot!

Now I got it.

Sufeng


On Fri, Jul 5, 2013 at 11:20 AM, Pavan Balaji <balaji@mcs.anl.gov> wrote:

>
> On 07/05/2013 11:18 AM, Sufeng Niu wrote:
>
>> for hybrid RMA issue, did you mean in each rank, remote get the data
>> into a shared memory, then threads in each rank load it by thread-level
>> operation?
>>
>
> All threads are in the same process, so they all already share memory.
> Perhaps its best if you try to learn how threads work before attempting to
> use them with MPI.
>
>
>  -- Pavan
>
> --
> Pavan Balaji
> http://www.mcs.anl.gov/~balaji
>



--
Best Regards,
Sufeng Niu
ECASP lab, ECE department, Illinois Institute of Technology
Tel: 312-731-7219
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mpich.org/pipermail/discuss/attachments/20130705/f0eefadd/attachment.html>

------------------------------

_______________________________________________
discuss mailing list
discuss@mpich.org
https://lists.mpich.org/mailman/listinfo/discuss

End of discuss Digest, Vol 9, Issue 10
**************************************



--
Best Regards,
Sufeng Niu
ECASP lab, ECE department, Illinois Institute of Technology
Tel: 312-731-7219