Design and Implementa/on of Key Proposed MPI-3 One-Sided - - PowerPoint PPT Presentation

Design ¡and ¡Implementa/on ¡of ¡Key ¡Proposed ¡MPI-­‑3 ¡ One-­‑Sided ¡Communica/on ¡Seman/cs ¡on ¡InfiniBand ¡

Sreeram ¡Potluri, ¡Sayantan ¡Sur, ¡Devendar ¡Bureddy ¡ ¡ and ¡Dhabaleswar ¡K. ¡Panda ¡ ¡

Network-­‑Based ¡Compu2ng ¡Laboratory ¡ Department ¡of ¡Computer ¡Science ¡and ¡Engineering ¡ The ¡Ohio ¡State ¡University, ¡USA ¡ ¡

EuroMPI ¡2011 ¡

Introduction

• Reduced synchronization overheads, simultaneous use
• f powerful system resources - key on modern clusters
• Better support through one-sided communication in

MPI-2

• Optimized implementation in MVAPICH2
• Limitations in semantics – hindered its wider acceptance
• RMA working group proposed several extensions as part
• f the MPI-3 effort
• Efficient implementation is crucial – to highlight their

performance benefits, encourage their wide-spread use

• Can the new semantics be implemented with high

performance in MVAPICH2?

EuroMPI 2011 2

Overview

MPI-3 One Sided Communication Accumulate Ordering Undefined Conflicting Accesses Separate and Unified Windows Window Creation

• Win_allocate
• Win_create_dynamic,

Win_attach, Win_detach Synchronization

• Lock_all, Unlock_all
• Win_flush,

Win_flush_local, Win_flush_all, Win_flush_local_all

• Win_sync

Communication

• Get_accumulate
• Rput, Rget,

Raccumulate, Rget_accumulate

• Fetch_and_op,

Compare_and_swap

EuroMPI ¡2011 ¡ 3

Flush Operations

• Local and remote completions bundled in MPI-2 one-

sided communication model

• Handled using synchronization operations, requires

closure of an epoch

• Overhead in scenarios that require only local

completions

• Considerable overhead on networks like IB - semantics

and cost of local and remote completions are different

• RDMA Reads and Atomic Ops: CQ event means both local and

remote completions

• RDMA Writes: CQ event only means local completion. Remote

completion requires a follow up Send/Recv exchange or an atomic

• peration.
• Flush operations allow for more efficient check for

completions

EuroMPI ¡2011 ¡ 4

Flush Operations

EuroMPI ¡2011 ¡

• Local completion of Put is efficient using flush
• Completion does not require closure of the epoch

0 ¡ 2 ¡ 4 ¡ 6 ¡ 8 ¡ 10 ¡ 1 ¡ 4 ¡ 16 ¡ 64 ¡ 256 ¡ 1K ¡ 4K ¡ Time ¡(usec) ¡ Message ¡Size ¡(Bytes) ¡ 0 ¡ 2 ¡ 4 ¡ 6 ¡ 8 ¡ 10 ¡ 1 ¡ 2 ¡ 4 ¡ 8 ¡ 16 ¡ 32 ¡ 64 ¡ 128 ¡ 256 ¡ 512 ¡ 1K ¡ 2K ¡ 4K ¡ Time ¡(usec) ¡ Message ¡Size ¡(Bytes) ¡ 10" sec)% Get+Unlock% Get+Flush_local% Get+Flush%

8-core Intel Westmere Nodes connected with InfiniBand QDR IB

5

Put+Unlock% Put+Flush_local% Put+Flush%

6

Request Based Operations

EuroMPI ¡2011 ¡

• Current semantics provide bulk synchronization
• Lack of a way to request completion of individual
• perations, without closing an epoch
• Does not serve well for fine grained computation and

communication overlap

• Request based operations (MPI_Rput, MPI_Rget, and
• thers) return an MPI Request, can be polled for

completion

• Added GCP(Get-Compute-Put) Benchmarks in the OSU

suite to highlight their benefits

7 ¡ EuroMPI ¡2011 ¡

GCP ¡Benchmark ¡

MPI_Win_lock ¡ for ¡i ¡in ¡1, ¡N ¡ ¡ ¡ ¡ ¡ ¡MPI_Get ¡(ith ¡Block) ¡ end ¡for ¡ MPI_Win_unlock ¡ ¡ Compute ¡(N ¡Blocks) ¡ ¡ MPI_Win_lock ¡ for ¡i ¡in ¡1, ¡N ¡ ¡ ¡ ¡ ¡ ¡MPI_Put ¡(ith ¡Block) ¡ end ¡for ¡ MPI_Win_unlock ¡

No ¡Overlap ¡

MPI_Win_lock ¡ for ¡i ¡in ¡1, ¡N ¡ ¡ ¡ ¡ ¡ ¡MPI_Get ¡(ith ¡Block) ¡ end ¡for ¡ MPI_Win_unlock ¡

¡

MPI_Win_lock ¡ for ¡i ¡in ¡1, ¡N ¡ ¡ ¡ ¡ ¡ ¡Compute ¡(ith ¡Block) ¡ ¡ ¡ ¡ ¡ ¡MPI_Put ¡(ith ¡Block) ¡ end ¡for ¡ MPI_Win_unlock ¡ ¡

Overlap ¡using ¡Lock-­‑Unlock ¡

MPI_Win_lock ¡ for ¡i ¡in ¡1, ¡N ¡ ¡ ¡ ¡ ¡ ¡MPI_Rget ¡(ith ¡Block) ¡ end ¡for ¡ ¡ MPI_Wait_any ¡(get ¡requests) ¡ while ¡a ¡get ¡request ¡j ¡completes ¡ ¡ ¡ ¡ ¡ ¡Compute ¡(jth ¡Block) ¡ ¡ ¡ ¡ ¡ ¡MPI_Rput ¡(jth ¡Block) ¡ ¡ ¡ ¡ ¡ ¡MPI_Wait_any ¡(get ¡requests) ¡ end ¡while ¡ MPI_Wait_all ¡(put ¡requests) ¡ MPI_Win_unlock ¡ ¡

Overlap ¡using ¡Request ¡Ops ¡

Request Based Operations

8

Request Based Operations

EuroMPI ¡2011 ¡

• Request based operations provide superior overlap

8-core Intel Westmere Nodes connected with InfiniBand QDR IB

Lock6Unlock% Request%Ops% 0 ¡ 20 ¡ 40 ¡ 60 ¡ 80 ¡ 100 ¡ 2K ¡ 8K ¡ 32K ¡ 128K ¡ 512K ¡ 2M ¡ Percentage ¡Overlap ¡ Message ¡Size ¡(Bytes) ¡

Dynamic Windows

• Creation of a window is collective on communicator
• A process can attach or detach memory to the window

dynamically

• User has to manage exchange and correct use of

address information

• MPI Implementations on IB have to manage dynamic

exchange of key information to use RDMA

• MVAPICH2 uses a pull model – request-for-info sent

when the first operation is issued on a region, information is cached

• Request is piggy-backed onto the first data packet for

small and medium message sizes

9 EuroMPI ¡2011 ¡

Dynamic Windows

10 EuroMPI ¡2011 ¡

8-core Intel Westmere Nodes connected with InfiniBand QDR IB

• Dynamic windows can provide performance similar to static

windows

• Key exchange overhead is amortized

OSU Put Latency OSU Put Bandwidth 0 ¡ 2 ¡ 4 ¡ 6 ¡ 8 ¡ 0 ¡ 2 ¡ 8 ¡ 32 ¡ 128 ¡ 512 ¡ 2K ¡ Time ¡(usec) ¡ Message ¡Size ¡(Bytes) ¡ 0 ¡ 1000 ¡ 2000 ¡ 3000 ¡ 4000 ¡ 1 ¡ 16 ¡ 256 ¡ 4K ¡ 64K ¡ 1M ¡ Bandwidth ¡(MBps) ¡ Message ¡Size ¡(Bytes) ¡ Sta3c%Window% Dynamic%Window%

11

Conclusion and Future Work

EuroMPI ¡2011 ¡

• First implementation of features from the proposed one-

sided communication semantics for MPI-3

• Highlighted their benefits
• Working towards a complete implementation of the

proposed MPI-3 one-sided communication standard

• Modifying application benchmarks to show how real-

world applications can benefit from the proposed extensions

¡Thank ¡You! ¡

{potluri, ¡surs, ¡bureddy, ¡panda}@cse.ohio-­‑state.edu ¡

¡

¡

¡ ¡

¡

Network-­‑Based ¡Compu/ng ¡Laboratory ¡ h]p://nowlab.cse.ohio-­‑state.edu/ ¡ MVAPICH ¡Web ¡Page ¡ h]p://mvapich.cse.ohio-­‑state.edu/

12 ¡