Hybrid MPI+PGAS Models Are Gradually Receiving Importance

How to Boost the Performance of Your MPI and PGAS Applications with MVAPICH2 Libraries

A Tutorial at

MVAPICH User Group 2017 by

The MVAPICH Team The Ohio State University E-mail: [email protected] http://www.cse.ohio-state.edu/~panda Parallel Programming Models Overview

P1 P2 P3 P1 P2 P3 P1 P2 P3

Logical shared memory Memory Memory Memory Shared Memory Memory Memory Memory

Shared Memory Model Distributed Memory Model Partitioned Global Address Space (PGAS) SHMEM, DSM MPI (Message Passing Interface) Global Arrays, UPC, Chapel, X10, CAF, … • Programming models provide abstract machine models • Models can be mapped on different types of systems – e.g. Distributed Shared Memory (DSM), MPI within a node, etc. • PGAS models and Hybrid MPI+PGAS models are gradually receiving importance

Network Based Computing Laboratory MVAPICH User Group Meeting (MUG) 2017 2 Supporting Programming Models for Multi-Petaflop and Exaflop Systems: Challenges

Application Kernels/Applications

Middleware Co-Design Opportunities Programming Models and Challenges MPI, PGAS (UPC, Global Arrays, OpenSHMEM), CUDA, OpenMP, across Various OpenACC, Cilk, Hadoop (MapReduce), Spark (RDD, DAG), etc. Layers

Communication Library or Runtime for Programming Models Performance

Point-to-point Collective Energy- Synchronization I/O and Fault Scalability Communication Communication Awareness and Locks File Systems Tolerance Resilience

Networking Technologies Multi-/Many-core Accelerators (InfiniBand, 40/100GigE, Architectures (GPU and MIC) Aries, and Omni-Path)

Network Based Computing Laboratory MVAPICH User Group Meeting (MUG) 2017 3 Designing (MPI+X) for Exascale • Scalability for million to billion processors – Support for highly-efficient inter-node and intra-node communication (both two-sided and one-sided) • Scalable Collective communication – Offloaded – Non-blocking – Topology-aware • Balancing intra-node and inter-node communication for next generation multi-/many-core (128-1024 cores/node) – Multiple end-points per node • Support for efficient multi-threading • Integrated Support for GPGPUs and Accelerators • Fault-tolerance/resiliency • QoS support for communication and I/O • Support for Hybrid MPI+PGAS programming • MPI + OpenMP, MPI + UPC, MPI + OpenSHMEM, CAF, MPI + UPC++… • Virtualization • Energy-Awareness

Network Based Computing Laboratory MVAPICH User Group Meeting (MUG) 2017 4 Overview of the MVAPICH2 Project • High Performance open-source MPI Library for InfiniBand, Omni-Path, Ethernet/iWARP, and RDMA over Converged Ethernet (RoCE) – MVAPICH (MPI-1), MVAPICH2 (MPI-2.2 and MPI-3.0), Started in 2001, First version available in 2002 – MVAPICH2-X (MPI + PGAS), Available since 2011 – Support for GPGPUs (MVAPICH2-GDR) and MIC (MVAPICH2-MIC), Available since 2014 – Support for Virtualization (MVAPICH2-Virt), Available since 2015 – Support for Energy-Awareness (MVAPICH2-EA), Available since 2015 – Support for InfiniBand Network Analysis and Monitoring (OSU INAM) since 2015 – Used by more than 2,800 organizations in 85 countries – More than 424,000 (> 0.4 million) downloads from the OSU site directly – Empowering many TOP500 clusters (June ‘17 ranking) • 1st, 10,649,600-core (Sunway TaihuLight) at National Supercomputing Center in Wuxi, China • 15th, 241,108-core (Pleiades) at NASA • 20th, 462,462-core (Stampede) at TACC • 44th, 74,520-core (Tsubame 2.5) at Tokyo Institute of Technology – Available with software stacks of many vendors and Linux Distros (RedHat and SuSE) – http://mvapich.cse.ohio-state.edu • Empowering Top500 systems for over a decade – System-X from Virginia Tech (3rd in Nov 2003, 2,200 processors, 12.25 TFlops) -> – Stampede at TACC (12th in Jun’16, 462,462 cores, 5.168 Plops)

Network Based Computing Laboratory MVAPICH User Group Meeting (MUG) 2017 5 Architecture of MVAPICH2 Software Family

High Performance Parallel Programming Models

Message Passing Interface PGAS Hybrid --- MPI + X (MPI) (UPC, OpenSHMEM, CAF, UPC++) (MPI + PGAS + OpenMP/Cilk)

High Performance and Scalable Communication Runtime Diverse APIs and Mechanisms

Point-to- Remote Collectives Energy- I/O and Fault Active Introspectio point Job Startup Memory Virtualization Algorithms Awareness Tolerance Messages n & Analysis Primitives Access File Systems

Support for Modern Networking Technology Support for Modern Multi-/Many-core Architectures (InfiniBand, iWARP, RoCE, Omni-Path) (Intel-Xeon, OpenPower, Xeon-Phi (MIC, KNL), NVIDIA GPGPU) Transport Protocols Modern Features Transport Mechanisms Modern Features SR- Multi Shared RC XRC UD DC UMR ODP CMA IVSHMEM MCDRAM* NVLink* CAPI* IOV Rail Memory

* Upcoming

Network Based Computing Laboratory MVAPICH User Group Meeting (MUG) 2017 6 Strong Procedure for Design, Development and Release

• Research is done for exploring new designs • Designs are first presented to conference/journal publications • Best performing designs are incorporated into the codebase • Rigorous Q&A procedure before making a release – Exhaustive unit testing – Various test procedures on diverse range of platforms and interconnects – Performance tuning – Applications-based evaluation – Evaluation on large-scale systems • Even alpha and beta versions go through the above testing

Network Based Computing Laboratory MVAPICH User Group Meeting (MUG) 2017 7 MVAPICH2 Software Family

Requirements Library

MPI with IB, iWARP and RoCE MVAPICH2

Advanced MPI, OSU INAM, PGAS and MPI+PGAS with IB and RoCE MVAPICH2-X

MPI with IB & GPU MVAPICH2-GDR

MPI with IB & MIC MVAPICH2-MIC

HPC Cloud with MPI & IB MVAPICH2-Virt

Energy-aware MPI with IB, iWARP and RoCE MVAPICH2-EA

MPI Energy Monitoring Tool OEMT

InfiniBand Network Analysis and Monitoring OSU INAM

Microbenchmarks for Measuring MPI and PGAS Performance OMB

Network Based Computing Laboratory MVAPICH User Group Meeting (MUG) 2017 8 MVAPICH2 2.3b • Released on 08/10/2017 • Major Features and Enhancements – Based on MPICH-3.2 – Enhance performance of point-to-point operations for CH3-Gen2 (InfiniBand), CH3-PSM, and CH3-PSM2 (Omni-Path) channels – Improve performance for MPI-3 RMA operations – Introduce support for Cavium ARM (ThunderX) systems – Improve support for process to core mapping on many-core systems

• New environment variable MV2_THREADS_BINDING_POLICY for multi-threaded MPI and MPI+OpenMP applications • Support `linear' and `compact' placement of threads • Warn user if over-subscription of core is detected – Improve launch time for large-scale jobs with mpirun_rsh – Add support for non-blocking Allreduce using Mellanox SHARP – Efficient support for different Intel Knight's Landing (KNL) models – Improve performance for Intra- and Inter-node communication for OpenPOWER architecture – Improve support for large processes per node and huge pages on SMP systems – Enhance collective tuning for many architectures/systems – Enhance support for MPI_T PVARs and CVARs

Network Based Computing Laboratory MVAPICH User Group Meeting (MUG) 2017 9 Presentation Overview

• Job start-up • Point-to-point Inter-node Protocol • Transport Type Selection • Multi-rail and QoS • Process Mapping and Point-to-point Intra-node Protocols • Collectives • MPI_T Support

Network Based Computing Laboratory MVAPICH User Group Meeting (MUG) 2017 10 Towards High Performance and Scalable Startup at Exascale • Near-constant MPI and OpenSHMEM a b c initialization time at any process count

On-demand P M d a Connection • 10x and 30x improvement in startup time b PMIX_Ring of MPI and OpenSHMEM respectively at

P PGAS – State of the art e c PMIX_Ibarrier 16,384 processes • Memory consumption reduced for remote M MPI – State of the art d PMIX_Iallgather

EndpointInformation endpoint information by O(processes per O PGAS/MPI – Optimized O e Shmem based PMI Memory Required to Store Memory to Store Required node)

Job Startup Performance • 1GB Memory saved per node with 1M processes and 16 processes per node

a On-demand Connection Management for OpenSHMEM and OpenSHMEM+MPI. S. Chakraborty, H. Subramoni, J. Perkins, A. A. Awan, and D K Panda, 20th International Workshop on High-level Parallel Programming Models and Supportive Environments (HIPS ’15) b PMI Extensions for Scalable MPI Startup. S. Chakraborty, H. Subramoni, A. Moody, J. Perkins, M. Arnold, and D K Panda, Proceedings of the 21st European MPI Users' Group Meeting (EuroMPI/Asia ’14) c d Non-blocking PMI Extensions for Fast MPI Startup. S. Chakraborty, H. Subramoni, A. Moody, A. Venkatesh, J. Perkins, and D K Panda, 15th IEEE/ACM International Symposium on Cluster, Cloud and Grid Computing (CCGrid ’15) e SHMEMPMI – Shared Memory based PMI for Improved Performance and Scalability. S. Chakraborty, H. Subramoni, J. Perkins, and D K Panda, 16th IEEE/ACM International Symposium on Cluster, Cloud and Grid Computing (CCGrid ’16) Network Based Computing Laboratory MVAPICH User Group Meeting (MUG) 2017 11 Startup Performance on KNL + Omni-Path

MPI_Init - TACC Stampede-KNL MPI_Init & Hello World - Oakforest-PACS 200 25

Hello World (MVAPICH2-2.3a) 21s Intel MPI 2018 beta 150 20 MVAPICH2 2.3a MPI_Init (MVAPICH2-2.3a) 8.8x 15 100 51s 10 50

MPI_Init (Seconds) MPI_Init 5 5.8s Time Taken (Seconds) Taken Time

0 0

1K 2K 4K 8K

128 256 512

16K 32K 64K Number of Processes Number of Processes

• MPI_Init takes 51 seconds on 231,956 processes on 3,624 KNL nodes (Stampede – Full scale) • 8.8 times faster than Intel MPI at 128K processes (Courtesy: TACC) • At 64K processes, MPI_Init and Hello World takes 5.8s and 21s respectively (Oakforest-PACS) • All numbers reported with 64 processes per node New designs available in MVAPICH2-2.3a and as patch for SLURM-15.08.8 and SLURM-16.05.1

Network Based Computing Laboratory MVAPICH User Group Meeting (MUG) 2017 12 Process Management Interface (PMI) over Shared Memory (SHMEMPMI)

• SHMEMPMI allows MPI processes to directly read remote endpoint (EP) information from the process manager through shared memory segments • Only a single copy per node - O(processes per node) reduction in memory usage • Estimated savings of 1GB per node with 1 million processes and 16 processes per node • Up to 1,000 times faster PMI Gets compared to default design • Available for MVAPICH2 2.2rc1 and SLURM-15.08.8

Memory Usage for Remote EP Information

Time Taken by one PMI_Get 10000 300 Fence - Default Default 1000 250 Allgather - Default 16x SHMEMPMI 100 200 Fence - Shmem

10 Allgather - Shmem 150 1 100 0.1 1000x 0.01 Actual Estimated 50 0.001

0 0.0001

Time Taken (milliseconds) Taken Time

16 32 64

1K 2K 4K 8K

Memory Usage per Node Memory(MB)per Usage

128 256 512

16K 64K

1 2 4 8 16 32 32K

256K 512K Number of Processes per Node Number of Processes per Job 128K

Network Based Computing Laboratory MVAPICH User Group Meeting (MUG) 2017 13 On-demand Connection Management for OpenSHMEM+MPI

Performance of OpenSHMEM Breakdown of OpenSHMEM Startup Initialization and Hello World 35 120 Connection Setup Hello World - Static 30 PMI Exchange 100 25 Initialization - Static Memory Registration 80 20 Hello World - On-demand Shared Memory Setup 60 15 Initialization - On-demand Other 40

10 Time Taken (Seconds) TimeTaken 5 (Seconds) Time Taken 20 0 0 32 64 128 256 512 1K 2K 4K 16 32 64 128 256 512 1K 2K 4K 8K Number of Processes Number of Processes

• Static connection establishment wastes memory and takes a lot of time • On-demand connection management improves OpenSHMEM initialization time by 29.6 times • Time taken for Hello World reduced by 8.31 times at 8,192 processes • Available since MVAPICH2-X 2.1rc1 Network Based Computing Laboratory MVAPICH User Group Meeting (MUG) 2017 14 How to Get the Best Startup Performance with MVAPICH2?

• MV2_HOMOGENEOUS_CLUSTER=1 //Set for homogenous clusters • MV2_ON_DEMAND_UD_INFO_EXCHANGE=1 //Enable UD based address exchange

Using SLURM as launcher Using mpirun_rsh as launcher • Use PMI2 • MV2_MT_DEGREE – ./configure --with-pm=slurm --with-pmi=pmi2 – degree of the hierarchical tree used by – srun --mpi=pmi2 ./a.out mpirun_rsh • Use PMI Extensions • MV2_FASTSSH_THRESHOLD – Patch for SLURM available at – #nodes beyond which hierarchical-ssh scheme is http://mvapich.cse.ohio-state.edu/download/ used – Patches available for SLURM 15, 16, and 17 • MV2_NPROCS_THRESHOLD – PMI Extensions are automatically detected by MVAPICH2 – #nodes beyond which file-based communication is used for hierarchical-ssh during start up

Network Based Computing Laboratory MVAPICH User Group Meeting (MUG) 2017 15 Presentation Overview

Network Based Computing Laboratory MVAPICH User Group Meeting (MUG) 2017 16 Inter-node Point-to-Point Tuning: Eager Thresholds Eager vs Rendezvous Impact of Eager Threshold 25 18 eager_th=1K Eager Rendezvous 16 eager_th=2K 20

14 eager_th=4K

Eager threshold 12 eager_th=8K 15 10 eager_th=16K 8 eager_th=32K

10 Latency (us) Latency Latency (us) Latency 6 5 4 2 0 0 1 2 4 8 16 32 64 128 256 512 1K 2K 4k 8k 16k 32k 0 1 2 4 8 16 32 64 128256512 1K 2K 4K 8K 16K32K64K Message Size (Bytes) Message Size (Bytes)

• Switching Eager to Rendezvous transfer • Default: Architecture dependent on common platforms, in order to achieve both best performance and memory footprint • Threshold can be modified by users to get smooth performance across message sizes • mpirun_rsh –np 2 –hostfile hostfile MV2_IBA_EAGER_THRESHOLD=32K a.out • Memory footprint can increase along with eager threshold

Network Based Computing Laboratory MVAPICH User Group Meeting (MUG) 2017 17 Analyzing Overlap Potential of Eager Protocol

• Application processes schedule communication operation • Network adapter progresses communication in the background Application Application • Application process free to perform useful compute in the foreground Process Process Network Interface Network Interface • Overlap of computation and communication => Better Overall Application Card Card Performance Schedule Schedule Receive • Increased buffer requirement Send Operation • Poor communication performance if used for all types of communication Operation operations

Check for Check for Completion Completion

Complete Complete

Computation Communication Progress Impact of changing Eager Threshold on performance of multi-pair message-rate benchmark with 32 processes on Stampede Network Based Computing Laboratory MVAPICH User Group Meeting (MUG) 2017 18 Analyzing Overlap Potential of Rendezvous Protocol Application Application Process Process Network Interface Network Interface Card Card • Application processes schedule communication operation Schedule Schedule Receive • Application process free to perform useful compute in the Send Operation Operation foreground RTS • Little communication progress in the background • All communication takes place at final synchronization Check for Completion Check for CTS Completion • Reduced buffer requirement Not Complete Not Complete • Good communication performance if used for large Check for Completion message sizes and operations where communication Check for Completion Not Complete library is progressed frequently Not Complete Check for Completion Check for • Poor overlap of computation and communication => Poor Completion Complete Overall Application Performance Complete

Computation Communication Progress

Network Based Computing Laboratory MVAPICH User Group Meeting (MUG) 2017 19 Dynamic and Adaptive MPI Point-to-point Communication Protocols

Desired Eager Threshold Eager Threshold for Example Communication Pattern with Different Designs

Default Manually Tuned Dynamic + Adaptive Process Pair Eager Threshold (KB) 4 5 6 7 4 5 6 7 4 5 6 7 0 – 4 32 1 – 5 64 16 KB 16 KB 16 KB 16 KB 128 KB 128 KB 128 KB 128 KB 32 KB 64 KB 128 KB 32 KB 2 – 6 128 0 1 2 3 0 1 2 3 0 1 2 3 3 – 7 32 Process on Node 1 Process on Node 2

Default Poor overlap; Low memory requirement Low Performance; High Productivity Manually Tuned Good overlap; High memory requirement High Performance; Low Productivity Dynamic + Adaptive Good overlap; Optimal memory requirement High Performance; High Productivity

Execution Time of Amber Relative Memory Consumption of Amber

600 9 500 8 7 400 6 5 300 4 200 3 2 100 1 Wall Clock Time (seconds) Time Clock Wall 0 0

128 256 512 1K Relative Consumption Memory 128 256 512 1K Number of Processes Number of Processes

Default Threshold=17K Threshold=64K Threshold=128K Dynamic Threshold Default Threshold=17K Threshold=64K Threshold=128K Dynamic Threshold

H. Subramoni, S. Chakraborty, D. K. Panda, Designing Dynamic & Adaptive MPI Point-to-Point Communication Protocols for Efficient Overlap of Computation & Communication, ISC'17 - Best Paper

Network Based Computing Laboratory MVAPICH User Group Meeting (MUG) 2017 20

Dynamic and Adaptive Tag Matching

Tag matching is a significant A new tag matching design Better performance than other state- overhead for receivers - Dynamically adapt to of-the art tag-matching schemes

Existing Solutions are communication patterns Minimum memory consumption Results

- Static and do not adapt dynamically Solution - Use different strategies for different Challenge to communication pattern ranks - Do not consider memory overhead - Decisions are based on the number Will be available in future MVAPICH2 of request object that must be releases traversed before hitting on the required one

Normalized Total Tag Matching Time at 512 Processes Normalized Memory Overhead per Process at 512 Processes Normalized to Default (Lower is Better) Compared to Default (Lower is Better) Adaptive and Dynamic Design for MPI Tag Matching; M. Bayatpour, H. Subramoni, S. Chakraborty, and D. K. Panda; IEEE Cluster 2016. [Best Paper Nominee] Network Based Computing Laboratory MVAPICH User Group Meeting (MUG) 2017 21 Intra-node Point-to-point Performance on ARMv8 Small Message Latency Large Message Latency 4 800 28% at 2M MVAPICH2 53% at 4K MVAPICH2 3.5 OpenMPI-v2.1.1 700

OpenMPI-v2.1.1

3 600 2.5 500 0.92 us (OpenMPI) 2 400

0.74 us (MVAPICH2) Latency (us) Latency 1.5 (us) Latency 300 (19.5% improvement at 4-byte) 1 200 0.5 100 0 0 0 1 2 4 8 16 32 64 128 256 512 1K 2K 4K 8K 16K 32K 64K 128K 256K 512K 1M 2M

Bandwidth Bi-directional Bandwidth

4500 10000

38% at 2M 4000 MVAPICH2 MVAPICH2 1.85 X at 2M 3500 8000 3000 OpenMPI-v2.1.1 OpenMPI-v2.1.1 6000 2500 2000 4000

1500 Bandwidth (MB/s) Bandwidth

1000 Bandwidth Bidirectional 2000 500

0 0

1 2 4 8

16 32 64

1K 2K 4K 8K

16 32 64

1M 2M

1K 2K 4K 8K

1M 2M 4M

128 256 512

16K 32K 64K

128 256 512

32K 64K

128K 256K 512K

128K 256K 512K ** OpenMPI version 2.2.1 used with “––mca bta self,sm”

Platform: ARMv8 (aarch64) processor with 96 cores dual-socket CPU. Each socket contains 48 cores. Available in MVAPICH2 2.3b

Network Based Computing Laboratory MVAPICH User Group Meeting (MUG) 2017 22 Presentation Overview

Network Based Computing Laboratory MVAPICH User Group Meeting (MUG) 2017 23 Hybrid (UD/RC/XRC) Mode in MVAPICH2

Performance with HPCC Random Ring • Both UD and RC/XRC have benefits UD Hybrid RC 6 • Hybrid for the best of both

26% 40% 38% 30% 4 • Enabled by configuring MVAPICH2 with the 2

Time (us) Time –enable-hybrid 0 • Available since MVAPICH2 1.7 as integrated 128 256 512 1024 interface Number of Processes

Parameter Significance Default Notes MV2_USE_UD_HYBRID • Enable / Disable use of UD transport Enabled • Always Enable in Hybrid mode MV2_HYBRID_ENABLE_THRESHOLD_SIZE • Job size in number of processes beyond which 1024 • Uses RC/XRC connection until hybrid mode will be enabled job size < threshold MV2_HYBRID_MAX_RC_CONN • Maximum number of RC or XRC 64 • Prevents HCA QP cache connections created per process thrashing • Limits the amount of connection memory • Refer to Running with Hybrid UD-RC/XRC section of MVAPICH2 user guide for more information • http://mvapich.cse.ohio-state.edu/static/media/mvapich/mvapich2-2.3a-userguide.html#x1-690006.11

Network Based Computing Laboratory MVAPICH User Group Meeting (MUG) 2017 24

Minimizing Memory Footprint by Direct Connect (DC) Transport

• Constant connection cost (One QP for any peer)

P0 P1 Node Node • Full Feature Set (RDMA, Atomics etc) • Separate objects for send (DC Initiator) and receive (DC Node 3 IB Node 1 Target) P6 Network P2 P7 P3 – DC Target identified by “DCT Number”

– Messages routed with (DCT Number, LID)

– Requires same “DC Key” to enable communication

P4 P5 Node Node • Available since MVAPICH2-X 2.2a

Memory Footprint for Alltoall NAMD - Apoa1: Large data set

1.2 RC DC-Pool UD XRC RC DC-Pool UD XRC 97 1 100 47 0.8 22 10 10 10 10 10 0.6 10 5 3 0.4 2 1 1 1 1 1 0.2

ConnectionMemory (KB) 1 0 Normalized Execution Time Execution Normalized 80 160 320 640 160 320 620 Number of Processes Number of Processes H. Subramoni, K. Hamidouche, A. Venkatesh, S. Chakraborty and D. K. Panda, Designing MPI Library with Dynamic Connected Transport (DCT) of InfiniBand : Early Experiences. IEEE International Supercomputing Conference (ISC ’14) Network Based Computing Laboratory MVAPICH User Group Meeting (MUG) 2017 25 Presentation Overview

Network Based Computing Laboratory MVAPICH User Group Meeting (MUG) 2017 26 MVAPICH2 Multi-Rail Design

• What is a rail? – HCA, Port, Queue Pair • Automatically detects and uses all active HCAs in a system – Automatically handles heterogeneity • Supports multiple rail usage policies – Rail Sharing – Processes share all available rails – Rail Binding – Specific processes are bound to specific rails

Network Based Computing Laboratory MVAPICH User Group Meeting (MUG) 2017 27 Performance Tuning on Multi-Rail Clusters

Impact of Default Message Striping on Impact of Default Rail Binding on Message Impact of Advanced Multi-rail Tuning on

Bandwidth Rate Message Rate 7000 7 8 7% Use First Single-Rail Single-Rail 7

6000 6

Round Robin Dual-Rail 6 5000 Dual-Rail 5 Scatter 98% 130% 5 Bunch 4000 4 4 3000 3 3 2000 2

Message RateMessage 2 1000 RateMessage 1

Bandwidth (MB/sec)Bandwidth 1

0 of Messages/sec)Millions 0

0 ( (Millions of Messages / / Sec) of Messages(Millions

Message Size (Bytes) Message Size (Bytes) Message Size (Bytes) Two 24-core Magny Cours nodes with two Mellanox ConnectX QDR adapters Six pairs with OSU Multi-Pair bandwidth and messaging rate benchmark Parameter Significance Default Notes MV2_IBA_HCA • Manually set the HCA to be used Unset • To get names of HCA ibstat | grep “^CA” MV2_DEFAULT_PORT • Select the port to use on a active multi port HCA 0 • Set to use different port

MV2_RAIL_SHARING_LARGE_MSG_THRESHOLD • Threshold beyond which striping will take place 16 Kbyte

MV2_RAIL_SHARING_POLICY • Choose multi-rail rail sharing / binding policy Rail Binding in • Advanced tuning can • For Rail Sharing set to USE_FIRST or ROUND_ROBIN Round Robin result in better • Set to FIXED_MAPPING for advanced rail binding options mode performance MV2_PROCESS_TO_RAIL_MAPPING • Determines how HCAs will be mapped to the rails BUNCH • Options: SCATTER and custom list

• Refer to Enhanced design for Multiple-Rail section of MVAPICH2 user guide for more information • http://mvapich.cse.ohio-state.edu/static/media/mvapich/mvapich2-2.3a-userguide.html#x1-700006.12

Network Based Computing Laboratory MVAPICH User Group Meeting (MUG) 2017 28 Presentation Overview

Network Based Computing Laboratory MVAPICH User Group Meeting (MUG) 2017 29 Process Mapping support in MVAPICH2

Process-Mapping support in MVAPICH2 (available since v1.4)

Preset Binding Policies User-defined binding

bunch Policy scatter hybrid MPI rank-to-core binding (Default)

core socket numanode Granularity (Default)

• MVAPICH2 detects processor architecture at job-launch

Network Based Computing Laboratory MVAPICH User Group Meeting (MUG) 2017 30 Preset Process-binding Policies – Bunch • “Core” level “Bunch” mapping (Default) – MV2_CPU_BINDING_POLICY=bunch

• “Socket/Numanode” level “Bunch” mapping – MV2_CPU_BINDING_LEVEL=socket MV2_CPU_BINDING_POLICY=bunch

Network Based Computing Laboratory MVAPICH User Group Meeting (MUG) 2017 31 Preset Process-binding Policies – Scatter • “Core” level “Scatter” mapping – MV2_CPU_BINDING_POLICY=scatter

• “Socket/Numanode” level “Scatter” mapping – MV2_CPU_BINDING_LEVEL=socket MV2_CPU_BINDING_POLICY=scatter

Network Based Computing Laboratory MVAPICH User Group Meeting (MUG) 2017 32 Process and thread binding policies in hybrid MPI+Threads • A new process binding policy – “hybrid” – MV2_CPU_BINDING_POLICY = hybrid • A new environment variable for co-locating Threads with MPI Processes – MV2_THREADS_PER_PROCESS = k – Automatically set to OMP_NUM_THREADS if OpenMP is being used – Provides a hint to the MPI runtime to spare resources for application threads. • New variable for threads bindings with respect to parent process and architecture – MV2_THREADS_BINDING_POLICY = {linear | compact} • Linear – binds MPI ranks and OpenMP threads sequentially (one after the other) – Recommended to be used on non-hyperthreaded systems with MPI+OpenMP • Compact – binds MPI rank to physical-core and locates respective OpenMP threads on hardware threads – Recommended to be used on multi-/many-cores e.g., KNL, POWER8, and hyper-threaded Xeon, etc.

Network Based Computing Laboratory MVAPICH User Group Meeting (MUG) 2017 33

Binding Example in Hybrid (MPI+Threads) • MPI Processes = 4, OpenMP Threads per Process = 4 • MV2_CPU_BINDING_POLICY = hybrid • MV2_THREADS_PER_PROCESS = 4 • MV2_THREADS_BINDING_POLICY = compact Rank0 Rank1

Core0 HWT Core1 HWT Core0 HWT Core1 HWT

HWT HWT HWT HWT HWT HWT HWT HWT

Core3 HWT Core2 HWT Core2 HWT Core3 HWT

HWT HWT HWT HWT HWT HWT HWT HWT

Rank2 Rank3 • Detects hardware-threads support in architecture • Assigns MPI ranks to physical cores and respective OpenMP Threads to HW threads Network Based Computing Laboratory MVAPICH User Group Meeting (MUG) 2017 34 Binding Example in Hybrid (MPI+Threads) ---- Cont’d • MPI Processes = 4, OpenMP Threads per Process = 4 • MV2_CPU_BINDING_POLICY = hybrid • MV2_THREADS_PER_PROCESS = 4 • MV2_THREADS_BINDING_POLICY = linear Rank0 Rank1

Core0 Core1 Core4 Core5 Core0 Core1 Core4 Core5

Core2 Core3 Core6 Core7 Core2 Core3 Core6 Core7

Core8 Core9 Core12 Core13 Core8 Core9 Core12 Core13

Core10 Core11 Core14 Core15 Core10 Core11 Core14 Core15

Rank2 Rank3

• MPI Rank-0 with its 4-OpenMP threads gets bound on Core-0 through Core-3, and so on

Network Based Computing Laboratory MVAPICH User Group Meeting (MUG) 2017 35 User-Defined Process Mapping • User has complete-control over process-mapping • To run 4 processes on cores 0, 1, 4, 5: – $ mpirun_rsh -np 4 -hostfile hosts MV2_CPU_MAPPING=0:1:4:5 ./a.out • Use ‘,’ or ‘-’ to bind to a set of cores: – $mpirun_rsh -np 64 -hostfile hosts MV2_CPU_MAPPING=0,2-4:1:5:6 ./a.out • Is process binding working as expected? – MV2_SHOW_CPU_BINDING=1 • Display CPU binding information • Launcher independent • Example – MV2_SHOW_CPU_BINDING=1 MV2_CPU_BINDING_POLICY=scatter ------CPU AFFINITY------RANK:0 CPU_SET: 0 RANK:1 CPU_SET: 8

• Refer to Running with Efficient CPU (Core) Mapping section of MVAPICH2 user guide for more information • http://mvapich.cse.ohio-state.edu/static/media/mvapich/mvapich2-2.3a-userguide.html#x1-600006.5

Network Based Computing Laboratory MVAPICH User Group Meeting (MUG) 2017 36 Presentation Overview

Network Based Computing Laboratory MVAPICH User Group Meeting (MUG) 2017 37 Collective Communication in MVAPICH2

Collective Algorithms in MV2

Conventional Multi-Core Aware (Flat) Designs

Inter-Node Communication Intra-Node Inter-Node Inter-Node Communication (Pt-to-Pt) (Hardware-Mcast)

Intra-Node Intra-Node Intra-Node (Pt-to-Pt) (Shared-Memory) (Kernel-Assisted)

Run-time flags: All shared-memory based collectives : MV2_USE_SHMEM_COLL (Default: ON) Hardware Mcast-based collectives : MV2_USE_MCAST (Default : OFF)

Network Based Computing Laboratory MVAPICH User Group Meeting (MUG) 2017 38 Hardware Multicast-aware MPI_Bcast on TACC Stampede

Small Messages (102,400 Cores) 85% Large Messages (102,400 Cores) 40 450 35 Default

400 Default 30 350

Multicast Multicast (us) 25 (us) 300 20 250 15 200 150

Latency Latency 10 Latency Latency 100 5 50 0 0 2 8 32 128 512 2K 8K 32K 128K Message Size (Bytes) Message Size (Bytes) 16 Byte Message 32 KByte Message

30 200

80% 25 Default 150 Default 20 Multicast Multicast 15 100

10 Latency (us) Latency

Latency (us) Latency 50 5 0 0

Number of Nodes Number of Nodes • MCAST-based designs improve latency of MPI_Bcast by up to 85% • Use MV2_USE_MCAST=1 to enable MCAST-based designs

Network Based Computing Laboratory MVAPICH User Group Meeting (MUG) 2017 39 MPI_Scatter - Benefits of using Hardware-Mcast

Scatter-Default Scatter-Mcast 512 Processes 1,024 Processes 20 30 18

16 57% 25 14 75% 12 20 10 15 8

6 10 Latency (usec) Latency 4 (usec) Latency 2 5 0 0 1 2 4 8 16 1 2 4 8 16 Message Length (Bytes) Message Length (Bytes) • Enabling MCAST-based designs for MPI_Scatter improves small message up to 75%

Parameter Description Default MV2_USE_MCAST = 1 Enables hardware Multicast features Disabled --enable-mcast Configure flag to enable Enabled Network Based Computing Laboratory MVAPICH User Group Meeting (MUG) 2017 40 Advanced Allreduce Collective Designs Using SHArP osu_allreduce (OSU Micro Benchmark) using MVAPICH2 2.3b

MVAPICH2 4 PPN*, 16 Nodes 28 PPN, 16 Nodes 12 16 MVAPICH2 14 1.5x 10 MVAPICH2-SHArP MVAPICH2-SHArP

12 2.3x 8 10 6 8

6 Latency (us) Latency Latency (us) Latency 4 4 2 2 0 0 4 8 16 32 64 128 256 4 8 16 32 64 128 256 Message Size (Bytes) Message Size (Bytes) MV2-128B 8 MV2-SHArP-128B 12 7 MV2-32B 1.4x 2.3x 10

6 MV2-SHArP-32B

5 8

4 6 MV2-128B

Latency (us) Latency 3 MV2-SHArP-128B Latency (us) Latency 4 2 MV2-32B MV2-SHArP-32B 1 2

0 0 (4,4) (8,4) (16,4) *PPN: Processes Per Node (4,28) (8,28) (16,28) (Number of Nodes, PPN) (Number of Nodes, PPN) Network Based Computing Laboratory MVAPICH User Group Meeting (MUG) 2017 41 Benefits of SHARP at Application Level Avg DDOT Allreduce time of HPCG Mesh Refinement Time of MiniAMR 0.2

0.35 12% MVAPICH2

MVAPICH2 0.3 13% 0.15 MVAPICH2-SHArP 0.25 MVAPICH2-SHArP 0.2 0.1 0.15

0.1 0.05 Latency (seconds) Latency Latency (seconds) Latency 0.05 0 0 (4,28) (8,28) (16,28) (4,28) (8,28) (16,28) (Number of Nodes, PPN) (Number of Nodes, PPN)

SHARP support available since MVAPICH2 2.3a

Parameter Description Default MV2_ENABLE_SHARP=1 Enables SHARP-based collectives Disabled --enable-sharp Configure flag to enable SHARP Disabled

• Refer to Running Collectives with Hardware based SHArP support section of MVAPICH2 user guide for more information • http://mvapich.cse.ohio-state.edu/static/media/mvapich/mvapich2-2.3b-userguide.html#x1-990006.26 Network Based Computing Laboratory MVAPICH User Group Meeting (MUG) 2017 42 Problems with Blocking Collective Operations

Application Application Application Application Process Process Process Process Computation

Communication

• Communication time cannot be used for compute – No overlap of computation and communication – Inefficient

Network Based Computing Laboratory MVAPICH User Group Meeting (MUG) 2017 43 Concept of Non-blocking Collectives Computation

Application Application Application Application Communication Process Process Process Process Communication Communication Communication Communication Support Entity Support Entity Support Entity Support Entity

Schedule Schedule Schedule Schedule Operation Operation Operation Operation

Check if Check if Check if Check if Complete Complete Complete Complete

• Application processes schedule collective operation • Check periodically if operation is complete • Overlap of computation and communication => Better Performance • Catch: Who will progress communication

Network Based Computing Laboratory MVAPICH User Group Meeting (MUG) 2017 44 Non-blocking Collective (NBC) Operations

• Enables overlap of computation with communication • Non-blocking calls do not match blocking collective calls – MPI may use different algorithms for blocking and non-blocking collectives – Blocking collectives: Optimized for latency – Non-blocking collectives: Optimized for overlap • A process calling a NBC operation – Schedules collective operation and immediately returns – Executes application computation code – Waits for the end of the collective • The communication progress by – Application code through MPI_Test – Network adapter (HCA) with hardware support – Dedicated processes / thread in MPI library • There is a non-blocking equivalent for each blocking operation – Has an “I” in the name • MPI_Bcast -> MPI_Ibcast; MPI_Reduce -> MPI_Ireduce

Network Based Computing Laboratory MVAPICH User Group Meeting (MUG) 2017 45 How do I write applications with NBC?

void main() { MPI_Init() ….. MPI_Ialltoall(…) Computation that does not depend on result of Alltoall MPI_Test(for Ialltoall) /* Check if complete (non-blocking) */ Computation that does not depend on result of Alltoall MPI_Wait(for Ialltoall) /* Wait till complete (Blocking) */ … MPI_Finalize() }

Network Based Computing Laboratory MVAPICH User Group Meeting (MUG) 2017 46 Performance of P3DFFT Kernel

Small Scale Runs Large Scale Runs 20 14 Default RDMA-Aware

Default RDMA-Aware Default-Thread 12 19%

15 10 8 10

6 (Seconds)

5 (Seconds) 4 CPU Time LoopPer CPU Time Per Loop CPU TimePer 2 0 0 128 256 512 128 256 512 1K 2K 4K 8K Number of Processes Number of Processes • Weak scaling experiments; problem size increases with job size • RDMA-Aware delivers 19% improvement over Default @ 8,192 processes • Default-Thread exhibits worst performance – Possibly because threads steal CPU cycles from P3DFFT – Do not consider for large scale experiments • Do not consider Default-Iprobe as it requires re-design of P3DFFT

Network Based Computing Laboratory MVAPICH User Group Meeting (MUG) 2017 47 Presentation Overview

Network Based Computing Laboratory MVAPICH User Group Meeting (MUG) 2017 48 MPI Tools Information Interface (MPI_T)

• Introduced in MPI 3.0 standard to expose internals of MPI to tools and applications • Generalized interface – no defined variables in the standard • Variables can differ between - MPI implementations - Compilations of same MPI library (production vs debug) - Executions of the same application/MPI library - There could be no variables provided • Control Variables (CVARS) and Performance Variables (PVARS) • More about the interface: mpi-forum.org/docs/mpi-3.0/mpi30-report.pdf

Network Based Computing Laboratory MVAPICH User Group Meeting (MUG) 2017 49 MPI_T usage semantics

Initialize MPI-T

Get #variables Performance Control Variables Query Metadata Variables

Allocate Session

Allocate Handle Allocate Handle

Read/Write/Reset Read/Write var Start/Stop var

Free Handle Free Handle

Free Session Finalize MPI-T

intint MPI_T_pvar_start(MPI_T_pvar_session MPI_T_cvar_get_info(int cvar_index, session, MPI_T_pvar_handle char *name, int handle *name_len,); int *verbosity, int MPI_T_pvar_handle_alloc(MPI_T_pvar_session session, int pvar_index, int MPI_T_pvar_read(MPI_T_pvar_sessionMPI_Datatypeint int *datatype,MPI_T_pvar_handle_free(MPI_T_pvar_session MPI_T_pvar_session_create(MPI_T_pvar_sessionint int session,MPI_T_init_thread(int intMPI_T_pvar_session_free(MPI_T_pvar_sessionMPI_T_enum MPI_T_cvar_get_num(int MPI_T_pvar_handleint * MPI_T_finalize(voidenumtype, required,handle, session, void *num_cvar int*); buf MPI_T_pvar_handle*provided); *session); *session);); );*handle); int MPI_T_pvar_reset(MPI_T_pvar_session void *obj_handle,char *desc session, MPI_T_pvar_handle, int MPI_T_pvar_handle *desc_len, int *bind,handle *handle,); int *scopeint *count); );

Network Based Computing Laboratory MVAPICH User Group Meeting (MUG) 2017 50 Co-designing Applications to use MPI-T

Example Pseudo-code: Optimizing the eager limit dynamically:

MPI_T_init_thread(..) MPI_T_cvar_get_info(MV2_EAGER_THRESHOLD) if (msg_size < MV2_EAGER_THRESHOLD + 1KB) MPI_T_cvar_write(MV2_EAGER_THRESHOLD, +1024) MPI_Send(..) MPI_T_finalize(..)

Network Based Computing Laboratory MVAPICH User Group Meeting (MUG) 2017 51 Evaluating Applications with MPI-T

Communication profile (ADCIRC) Unexpected message profile (UH3D)

5000

5000 4000 4000 3000 3000 2000 2000

1000 1000

Max. # unexp. recvs unexp. # Max. Millions of messages of Millions 0 0 1216 1824 2432 256 512 1024 #processes #processes

Intranode Internode Communication profile (WRF)

100

80 • Users can gain insights into application communication 60 characteristics! 40

20 Millions of messages of Millions 0 32 64 128 256 #processes

Intranode Internode

Network Based Computing Laboratory MVAPICH User Group Meeting (MUG) 2017 52 Performance Engineering Applications using MVAPICH2 and TAU ● Enhance existing support for MPI_T in MVAPICH2 to expose a richer set of performance and control variables ● Get and display MPI Performance Variables (PVARs) made available by the runtime in TAU ● Control the runtime’s behavior via MPI Control Variables (CVARs) ● Introduced support for new MPI_T based CVARs to MVAPICH2 ○ MPIR_CVAR_MAX_INLINE_MSG_SZ, MPIR_CVAR_VBUF_POOL_SIZE, MPIR_CVAR_VBUF_SECONDARY_POOL_SIZE ● TAU enhanced with support for setting MPI_T CVARs in a non-interactive mode for uninstrumented applications ● S. Ramesh, A. Maheo, S. Shende, A. Malony, H. Subramoni, and D. K. Panda, MPI Performance Engineering with the MPI Tool Interface: the Integration of MVAPICH and TAU, EuroMPI/USA ‘17, Best Paper Finalist ● More details in Prof. Malony’s talk today and poster presentations VBUF usage without CVAR based tuning as displayed by ParaProf VBUF usage with CVAR based tuning as displayed by ParaProf

Network Based Computing Laboratory MVAPICH User Group Meeting (MUG) 2017 53 MVAPICH2 Software Family

Requirements Library

MPI with IB, iWARP and RoCE MVAPICH2

Advanced MPI, OSU INAM, PGAS and MPI+PGAS with IB and RoCE MVAPICH2-X

MPI with IB & GPU MVAPICH2-GDR

MPI with IB & MIC MVAPICH2-MIC

HPC Cloud with MPI & IB MVAPICH2-Virt

Energy-aware MPI with IB, iWARP and RoCE MVAPICH2-EA

MPI Energy Monitoring Tool OEMT

InfiniBand Network Analysis and Monitoring OSU INAM

Microbenchmarks for Measuring MPI and PGAS Performance OMB

Network Based Computing Laboratory MVAPICH User Group Meeting (MUG) 2017 54 MVAPICH2-X for Hybrid MPI + PGAS Applications

• Current Model – Separate Runtimes for OpenSHMEM/UPC/UPC++/CAF and MPI – Possible deadlock if both runtimes are not progressed – Consumes more network resource • Unified communication runtime for MPI, UPC, UPC++, OpenSHMEM, CAF – Available with since 2012 (starting with MVAPICH2-X 1.9) – http://mvapich.cse.ohio-state.edu

Network Based Computing Laboratory MVAPICH User Group Meeting (MUG) 2017 55 UPC++ Support in MVAPICH2-X

40000 14x MPI + {UPC++} Application MPI + {UPC++} Application 35000 GASNet_MPI GASNET_IBV 30000 MV2-X UPC++ UPC++ MPI MPI Runtime 25000 Runtime Interface Interfaces 20000

Time (us) Time 15000 GASNet Interfaces MVAPICH2-X 10000 Unified Communication 5000 Runtime (UCR) 0 Conduit (MPI) 1K 2K 4K 8K 16K 32K 64K 128K 256K 512K 1M

Message Size (bytes) Network Inter-node Broadcast (64 nodes 1:ppn)

• Full and native support for hybrid MPI + UPC++ applications • Better performance compared to IBV and MPI conduits More Details in Student Poster • OSU Micro-benchmarks (OMB) support for UPC++ Presentation • Available since MVAPICH2-X (2.2rc1)

Network Based Computing Laboratory MVAPICH User Group Meeting (MUG) 2017 56 Application Level Performance with Graph500 and Sort Graph500 Execution Time Sort Execution Time 3000 35 MPI-Simple MPI Hybrid

30 2500

25 MPI-CSC 2000 20 MPI-CSR 51% 13X 1500

15 Hybrid (MPI+OpenSHMEM) Time (s) Time

10 1000 Time (seconds) Time 5 7.6X 500 0 4K 8K 16K 0 500GB-512 1TB-1K 2TB-2K 4TB-4K No. of Processes Input Data - No. of Processes • Performance of Hybrid (MPI+ OpenSHMEM) Graph500 Design • Performance of Hybrid (MPI+OpenSHMEM) Sort • 8,192 processes Application - 2.4X improvement over MPI-CSR • 4,096 processes, 4 TB Input Size - 7.6X improvement over MPI-Simple - MPI – 2408 sec; 0.16 TB/min • 16,384 processes - Hybrid – 1172 sec; 0.36 TB/min - 1.5X improvement over MPI-CSR - 51% improvement over MPI-design - 13X improvement over MPI-Simple

J. Jose, K. Kandalla, S. Potluri, J. Zhang and D. K. Panda, Optimizing Collective Communication in OpenSHMEM, Int'l Conference on Partitioned Global Address Space Programming Models (PGAS '13), October 2013. J. Jose, S. Potluri, K. Tomko and D. K. Panda, Designing Scalable Graph500 Benchmark with Hybrid MPI+OpenSHMEM Programming Models, International Supercomputing Conference (ISC’13), June 2013 J. Jose, K. Kandalla, M. Luo and D. K. Panda, Supporting Hybrid MPI and OpenSHMEM over InfiniBand: Design and Performance Evaluation, Int'l Conference on Parallel Processing (ICPP '12), September 2012

Network Based Computing Laboratory MVAPICH User Group Meeting (MUG) 2017 57 OpenSHMEM Application kernels • AVX-512 vectorization and MCDRAM based optimizations for MVAPICH2-X – Will be available in future MVAPICH2-X release Scalable Integer Sort Kernel (ISx) Single KNL and Single Broadwell node

100 KNL (Default) KNL (AVX-512) 100 KNL (68) Broadwell (28) KNL (AVX-512+MCDRAM) Broadwell +30%

10 10

-5%

1 1

Time (s) Time Time (s) Time 0.1 0.1

0.01 2 4 8 16 32 64 128 0.01 No. of processes 2DHeat HeatImg MatMul DAXPY ISx(strong) • AVX-512 vectorization showed up to 3X improvement over default • KNL showed on-par performance as Broadwell on Node-by-node comparison

Exploiting and Evaluating OpenSHMEM on KNL Architecture J. Hashmi, M. Li, H. Subramoni, D. Panda Fourth Workshop on OpenSHMEM and Related Technologies, Aug 2017.

Network Based Computing Laboratory MVAPICH User Group Meeting (MUG) 2017 58 Implicit On-Demand Paging (ODP)

• Introduced by Mellanox to avoid pinning the pages of registered memory regions • ODP-aware runtime could reduce the size of pin-down buffers while maintaining performance

Applications (256 Processes)

100 (s) Pin-down Explicit-ODP Implicit-ODP

Time

Execution 0.1 CG EP FT IS MG LU SP AWP-ODC Graph500

M. Li, X. Lu, H. Subramoni, and D. K. Panda, “Designing Registration Caching Free High-Performance MPI Library with Implicit On-Demand Paging (ODP) of InfiniBand”, Under Review

Network Based Computing Laboratory MVAPICH User Group Meeting (MUG) 2017 59

10000

10000 Pin-down ODP-Enhanced ODP-Optimal ODP-Native

10000 1000 Pin-downPin-down ODP-EnhancedODP-Enhanced ODP-OptimalODP-Optimal ODP-NativeODP-Native 10001000 Pin-down ODP-Enhanced ODP-Optimal ODP-Native 1001000 100100 10 100 1010 1 10 1 1 Execution Time (s) Execution AWP-ODC-2561 AWP-ODC-512 BT CG LU MG SP LJ EAM Boltzmann Lennard Execution Time (s) Execution AWP-ODC-256 AWP-ODC-512 BT CG LU MG SP LJ EAM Boltzmann Lennard

Execution Time (s) Execution AWP-ODC-256 AWP-ODC-512 BT CG LU MG SP LJ EAM Boltzmann Lennard

Execution Time (s) Execution AWP-ODC-256 AWP-ODC-512 BT CG LU MG SP LJ EAM Boltzmann Lennard ApplicationsApplications (64 (64 Processes) Processes) ApplicationsApplications (64 (64 Processes) Processes) MVAPICH2 Software Family

Requirements Library

MPI with IB, iWARP and RoCE MVAPICH2

Advanced MPI, OSU INAM, PGAS and MPI+PGAS with IB and RoCE MVAPICH2-X

MPI with IB & GPU MVAPICH2-GDR

MPI with IB & MIC MVAPICH2-MIC

HPC Cloud with MPI & IB MVAPICH2-Virt

Energy-aware MPI with IB, iWARP and RoCE MVAPICH2-EA

MPI Energy Monitoring Tool OEMT

InfiniBand Network Analysis and Monitoring OSU INAM

Microbenchmarks for Measuring MPI and PGAS Performance OMB

Network Based Computing Laboratory MVAPICH User Group Meeting (MUG) 2017 60 CUDA-Aware MPI: MVAPICH2-GDR 1.8-2.2 Releases

• Support for MPI communication from NVIDIA GPU device memory • High performance RDMA-based inter-node point-to-point communication (GPU-GPU, GPU-Host and Host-GPU) • High performance intra-node point-to-point communication for multi-GPU adapters/node (GPU-GPU, GPU-Host and Host-GPU) • Taking advantage of CUDA IPC (available since CUDA 4.1) in intra-node communication for multiple GPU adapters/node • Optimized and tuned collectives for GPU device buffers • MPI datatype support for point-to-point and collective communication from GPU device buffers

Network Based Computing Laboratory MVAPICH User Group Meeting (MUG) 2017 61 Presentation Overview

• Support for Efficient Small Message Communication with GPUDirect RDMA • Multi-rail Support • Support for Efficient Intra-node Communication using CUDA IPC • MPI Datatype Support • On-going Work

Network Based Computing Laboratory MVAPICH User Group Meeting (MUG) 2017 62 Enhanced MPI Design with GPUDirect RDMA

Sender Receiver • Current MPI design using GPUDirect RDMA uses rndz_start Rendezvous protocol rndz_reply • Has higher latency for small messages • Can eager protocol be supported to improve performance data for small messages? fin

• Two schemes proposed and used Rendezvous Protocol • Loopback (using network adapter to copy data) Sender Receiver • Fastcopy/GDRCOPY (using CPU to copy data) send

R. Shi, S. Potluri, K. Hamidouche M. Li, J. Perkins D. Rossetti and D. K. Panda, Designing Efficient Small Message Transfer Mechanism for Inter-node MPI Communication on InfiniBand GPU Clusters IEEE International Conference on High Performance Computing (HiPC'2014) Eager Protocol

Network Based Computing Laboratory MVAPICH User Group Meeting (MUG) 2017 63 Alternative Approaches

• Can we substitute the cudaMemcpy with a better design?

• CudaMemcpy: Default Scheme

• Big overhead for small message Host Memory • Loopback-based design: Uses GDR feature Host Buf • Process establishes self-connection HCA PCI-E • Copy H-D ⇒ RDMA write (H, D)

• Copy D-H ⇒ RDMA write (D, H) GPU Memory

• P2P bottleneck ⇒ good for small and GPU Buf medium sizes • GDRCOPY-based design: New module for fast copies • Involves GPU PCIe BAR1 mapping • CPU performing the copy ⇒ block until completion • Very good performance for H-D for small and medium sizes • Very good performance for D-H only for very small sizes

Network Based Computing Laboratory MVAPICH User Group Meeting (MUG) 2017 64 Performance of MVAPICH2-GPU with GPU-Direct RDMA (GDR) GPU-GPU Inter-node Latency GPU-GPU Inter-node Bi-Bandwidth

30 6000

25 5000 20 4000 15 3000 11X 10 10x 2000 Latency (us) Latency 5 1.91us 1000 0 (MB/s) Bandwidth 0 0 1 2 4 8 16 32 64 128 256 512 1K 2K 4K 8K 1 2 4 8 16 32 64 128 256 512 1K 2K 4K Message Size (Bytes) Message Size (Bytes) MV2-(NO-GDR) MV2-GDR-2.3a MV2-(NO-GDR) MV2-GDR-2.3a

GPU-GPU Inter-node Bandwidth

3500 3000 2500 MVAPICH2-GDR-2.3a 2000 Intel Haswell (E5-2687W) node - 20 cores 1500 9x NVIDIA Pascal P100 GPU 1000 Mellanox Connect-X5 EDR HCA 500 Bandwidth (MB/s) Bandwidth CUDA 8.0 0 Mellanox OFED 4.0 with GPU-Direct-RDMA 1 2 4 8 16 32 64 128 256 512 1K 2K 4K Message Size (Bytes) MV2-(NO-GDR) MV2-GDR-2.3a

Network Based Computing Laboratory MVAPICH User Group Meeting (MUG) 2017 65

65 MVAPICH2-GDR: Performance on OpenPOWER (NVLink + Pascal) INTRA-NODE LATENCY (SMALL) INTRA-NODE LATENCY (LARGE) INTRA-NODE BANDWIDTH 20 500 35

400

15 25 300 20 10

200 15 Latency(us) Latency(us) 5 10 100 Bandwidth(GB/sec) 5 0 0 0 1 2 4 8 16 32 64 128 256 512 1K 2K 4K 8K 16K 32K 64K 128K 256K 512K 1M 2M 4M 1 4 16 64 256 1K 4K 16K 64K 256K 1M 4M Message Size (Bytes) Message Size (Bytes) Message Size (Bytes)

INTRA-SOCKET(NVLINK) INTER-SOCKET INTRA-SOCKET(NVLINK) INTER-SOCKET INTRA-SOCKET(NVLINK) INTER-SOCKET Intra-node Latency: 16.8 us (without GPUDirectRDMA) Intra-node Bandwidth: 32 GB/sec (NVLINK)

INTER-NODE LATENCY (SMALL) INTER-NODE LATENCY (LARGE) INTER-NODE BANDWIDTH 35 900 7 800 30 6 700 25

5 600 20 500 4 15 400 3 Latency(us) 10 Latency(us) 300 2 5 200 Bandwidth(GB/sec) 0 100 1 1 2 4 8 16 32 64 128 256 512 1K 2K 4K 8K 0 0 Message Size (Bytes) 16K 32K 64K 128K 256K 512K 1M 2M 4M 1 4 16 64 256 1K 4K 16K 64K 256K 1M 4M Message Size (Bytes) Message Size (Bytes) Inter-node Latency: 22 us (without GPUDirectRDMA) Will be available in upcoming MVAPICH2-GDR Inter-node Bandwidth: 6 GB/sec (FDR) Platform: OpenPOWER (ppc64le) nodes equipped with a dual-socket CPU, 4 Pascal P100-SXM GPUs, and 4X-FDR InfiniBand Inter-connect Network Based Computing Laboratory MVAPICH User Group Meeting (MUG) 2017 66 Tuning GDRCOPY Designs in MVAPICH2-GDR

Parameter Significance Default Notes MV2_USE_GPUDIRECT_ • Enable / Disable GDRCOPY- 1 • Always enable GDRCOPY based designs (Enabled) MV2_GPUDIRECT_GDR • Controls messages size until 8 KByte • Tune for your system COPY_LIMIT which GDRCOPY is • GPU type, host architecture. used Impacts the eager performance MV2_GPUDIRECT_GDR • Path to the GDRCOPY Unset • Always set COPY_LIB library

MV2_USE_GPUDIRECT_ • Controls messages size until 16Bytes • Tune for your systems D2H_GDRCOPY_LIMIT which GDRCOPY is used at • CPU and GPU type sender

• Refer to Tuning and Usage Parameters section of MVAPICH2-GDR user guide for more information • http://mvapich.cse.ohio-state.edu/userguide/gdr/#_tuning_and_usage_parameters

Network Based Computing Laboratory MVAPICH User Group Meeting (MUG) 2017 67 Tuning Loopback Designs in MVAPICH2-GDR

Parameter Significance Default Notes MV2_USE_GPUDIRECT_ • Enable / Disable 1 • Always enable LOOPBACK LOOPBACK-based designs (Enabled) MV2_GPUDIRECT_LOO • Controls messages size until 8 KByte • Tune for your system PBACK_LIMIT which LOOPBACK is • GPU type, host architecture and used HCA. Impacts the eager performance •Sensitive to the P2P issue

• Refer to Tuning and Usage Parameters section of MVAPICH2-GDR user guide for more information • http://mvapich.cse.ohio-state.edu/userguide/gdr/#_tuning_and_usage_parameters

Network Based Computing Laboratory MVAPICH User Group Meeting (MUG) 2017 68 Tuning GPUDirect RDMA (GDR) Designs in MVAPICH2-GDR

Parameter Significance Default Notes MV2_USE_GPUDIRECT • Enable / Disable GDR-based 1 • Always enable designs (Enabled) MV2_GPUDIRECT_LIMIT • Controls messages size until 8 KByte • Tune for your system which GPUDirect RDMA is • GPU type, host architecture used and CUDA version: impact pipelining overheads and P2P bandwidth bottlenecks MV2_USE_GPUDIRECT_ • Controls messages size until 256KBytes • Tune for your system RECEIVE_LIMIT which 1 hop design is used • GPU type, HCA type and (GDR Write at the receiver) configuration

• Refer to Tuning and Usage Parameters section of MVAPICH2-GDR user guide for more information • http://mvapich.cse.ohio-state.edu/userguide/gdr/#_tuning_and_usage_parameters

Network Based Computing Laboratory MVAPICH User Group Meeting (MUG) 2017 69 Application-Level Evaluation (HOOMD-blue) 64K Particles 256K Particles 3500

2500 3000 MV2 MV2+GDR 2500 2000 2X 2000

1500 2X

1500 1000 (TPS) 1000 500 500 0 0

Average Time Steps per second per TimeSteps Average 4 8 16 32 4 8 16 32 Number of Processes (TPS) per second Steps Time Average Number of Processes

• Platform: Wilkes (Intel Ivy Bridge + NVIDIA Tesla K20c + Mellanox Connect-IB) • HoomdBlue Version 1.0.5 • GDRCOPY enabled: MV2_USE_CUDA=1 MV2_IBA_HCA=mlx5_0 MV2_IBA_EAGER_THRESHOLD=32768 MV2_VBUF_TOTAL_SIZE=32768 MV2_USE_GPUDIRECT_LOOPBACK_LIMIT=32768 MV2_USE_GPUDIRECT_GDRCOPY=1 MV2_USE_GPUDIRECT_GDRCOPY_LIMIT=16384

Network Based Computing Laboratory MVAPICH User Group Meeting (MUG) 2017 70

LENS (Oct '15) 70 Presentation Overview

Network Based Computing Laboratory MVAPICH User Group Meeting (MUG) 2017 71 Tuning Multi-rail Support in MVAPICH2-GDR

• Automatic rail and CPU binding depending on the GPU selection • User selects the GPU and MVAPICH2-GDR selects the best HCA (avoids the P2P bottleneck) • Multi-rail selection for large message size for better Bandwidth utilization (pipeline design)

Parameter Significance Default Notes MV2_RAIL_SHARING_PO • How the Rails are Shared • Sharing gives the best LICY bind/selected by processes performance for pipeline design PROCESS_TO_RAIL_MAP • Explicit binding of the HCAs First HCA • PING to the CPU

• Refer to Tuning and Usage Parameters section of MVAPICH2-GDR user guide for more information • http://mvapich.cse.ohio-state.edu/userguide/gdr/#_tuning_and_usage_parameters

Network Based Computing Laboratory MVAPICH User Group Meeting (MUG) 2017 72 Performance of MVAPICH2-GDR with GPU-Direct RDMA and Multi-Rail Support

GPU-GPU Internode MPI Uni-Directional Bandwidth GPU-GPU Internode Bi-directional Bandwidth 10000 16000 9000 MV2-GDR 2.1 8,759 14000 MV2-GDR 2.1 15,111 8000 20% 7000 MV2-GDR 2.1 RC2 12000 40% MV2-GDR 2.1 RC2 6000 10000 5000 8000 4000

3000 6000

Bandwidth (MB/s) Bandwidth Bandwidth(MB/s)

2000 - 4000 Bi 1000 2000 0 1 4 16 64 256 1K 4K 16K 64K 256K 1M 4M 0 1 4 16 64 256 1K 4K 16K 64K 256K 1M 4M Message Size (bytes) Message Size (bytes) MVAPICH2-GDR-2.2.b Intel Ivy Bridge (E5-2680 v2) node - 20 cores, NVIDIA Tesla K40c GPU Mellanox Connect-IB Dual-FDR HCA CUDA 7 Mellanox OFED 2.4 with GPU-Direct-RDMA

Network Based Computing Laboratory MVAPICH User Group Meeting (MUG) 2017 73

LENS (Oct '15) 73 Presentation Overview

Network Based Computing Laboratory MVAPICH User Group Meeting (MUG) 2017 74 Multi-GPU Configurations Process 0 Process 1

• Multi-GPU node architectures are becoming common Memory • Until CUDA 3.2 - Communication between processes staged through the host - Shared Memory (pipelined) - Network Loopback [asynchronous) CPU • CUDA 4.0 and later - Inter-Process Communication (IPC)

- Host bypass I/O Hub - Handled by a DMA Engine - Low latency and Asynchronous - Requires creation, exchange and mapping of memory handles GPU 0 GPU 1 - Overhead HCA Network Based Computing Laboratory MVAPICH User Group Meeting (MUG) 2017 75 Tuning IPC designs in MVAPICH2-GDR Intra-node Small Message Latency

• Works between GPUs within the same 30

socket or IOH 20

• Leads to significant benefits in (usec) Latency appropriate scenarios 10 SHARED-MEM IPC SMP-IPC 0 1 4 16 64 256 1024 Message Size (Bytes)

Parameter Significance Default Notes MV2_CUDA_IPC • Enable / Disable CUDA IPC- 1 (Enabled) • Always leave set to 1 based designs MV2_CUDA_SMP_IPC • Enable / Disable CUDA IPC 0 • Benefits Device-to-Device transfers fastpath design for short (Disabled) • Hurts Device-to-Host/Host-to-Device messages transfers • Always set to 1 if application involves only Device-to-Device transfers MV2_IPC_THRESHOLD • Message size where IPC code path 16 KBytes • Tune for your system will be used

Network Based Computing Laboratory MVAPICH User Group Meeting (MUG) 2017 76 Alternative Designs

• Double Buffering schemes – Uses intermediate buffers (IPC Pinned) – Control information through Host memories • Exchange the handlers through the host for IPC completion – Works for all CUDA versions (Since 5.5) – Memory Overhead • Cache based design – Rendezvous based design – Cache the IPC handlers at the source and destination (through the control messages) – With Cache hit => direct data movement – Requires CUDA 6.5 and onwards – High Performance and memory efficiency

Network Based Computing Laboratory MVAPICH User Group Meeting (MUG) 2017 77 Tuning IPC designs in MVAPICH2-GDR

• Works between GPUs within the same socket or IOH

Parameter Significance Default Notes MV2_CUDA_ENABLE_IP • Enable / Disable CUDA IPC_CACHE- 1 • Always leave set to 1 C_CACHE based designs (Enabled) • Best performance • Enables one-sided semantics MV2_CUDA_IPC_BUFFE • Enable / Disable CUDA 1 • Used for subset of operations RED IPC_BUFFERED design (Enabled) • Backup for the IPC-Cache design • Uses double buffering schemes • Used for efficient Managed support

MV2_CUDA_IPC_MAX_ • Number of entries in the cache 64 • Tuned for your application CACHE_ENTRIES • Depends on the communication patterns • Increase the value for irregular applications

MV2_CUDA_IPC_STAGE • The size of the staging buffers in _BUF_SIZE the double buffering schemes

Network Based Computing Laboratory MVAPICH User Group Meeting (MUG) 2017 78 IPC-Cache Communication Enhancement

800 70000

700 60000 MV2-2.1a 600 MV2-2.1a 50000 Enhanced 500 Enhanced 4.7X 40000 400 7.8X 30000 300

Latency Latency (us) 20000

200 Bandwidth(MB/s) 100 10000 0 0 0 8 128 2K 32K 512K 1 16 256 4K 64K 1M Message Size (bytes) Message Size (bytes)

• Two Processes sharing the same K80 GPUs • Proposed designs achieve 4.7X improvement in latency • 7.8X improvement is delivered for Bandwidth • Available with the latest release of MVAPICH2-GDR 2.2

Network Based Computing Laboratory MVAPICH User Group Meeting (MUG) 2017 79 Presentation Overview

Network Based Computing Laboratory MVAPICH User Group Meeting (MUG) 2017 80 Non-contiguous Data Exchange

Halo data exchange

• Multi-dimensional data • Row based organization • Contiguous on one dimension • Non-contiguous on other dimensions • Halo data exchange • Duplicate the boundary • Exchange the boundary in each iteration

Network Based Computing Laboratory MVAPICH User Group Meeting (MUG) 2017 81 MPI Datatype support in MVAPICH2

• Datatypes support in MPI – Operate on customized datatypes to improve productivity – Enable MPI library to optimize non-contiguous data

At Sender: MPI_Type_vector (n_blocks, n_elements, stride, old_type, &new_type); MPI_Type_commit(&new_type); … MPI_Send(s_buf, size, new_type, dest, tag, MPI_COMM_WORLD);

• Inside MVAPICH2 - Use datatype specific CUDA Kernels to pack data in chunks - Efficiently move data between nodes using RDMA - In progress - currently optimizes vector and hindexed datatypes - Transparent to the user

H. Wang, S. Potluri, D. Bureddy, C. Rosales and D. K. Panda, GPU-aware MPI on RDMA-Enabled Clusters: Design, Implementation and Evaluation, IEEE Transactions on Parallel and Distributed Systems, Accepted for Publication.

Network Based Computing Laboratory MVAPICH User Group Meeting (MUG) 2017 82 MPI Datatype Processing (Computation Optimization )

• Comprehensive support • Targeted kernels for regular datatypes - vector, subarray, indexed_block • Generic kernels for all other irregular datatypes • Separate non-blocking stream for kernels launched by MPI library • Avoids stream conflicts with application kernels • Flexible set of parameters for users to tune kernels • Vector • MV2_CUDA_KERNEL_VECTOR_TIDBLK_SIZE • MV2_CUDA_KERNEL_VECTOR_YSIZE • Subarray • MV2_CUDA_KERNEL_SUBARR_TIDBLK_SIZE • MV2_CUDA_KERNEL_SUBARR_XDIM • MV2_CUDA_KERNEL_SUBARR_YDIM • MV2_CUDA_KERNEL_SUBARR_ZDIM • Indexed_block • MV2_CUDA_KERNEL_IDXBLK_XDIM

Network Based Computing Laboratory MVAPICH User Group Meeting (MUG) 2017 83 Performance of Stencil3D (3D subarray)

Stencil3D communication kernel on 2 GPUs DT TR Enhanced with various X, Y, Z dimensions using 2.5 2 MPI_Isend/Irecv (ms) 1.5 • DT: Direct Transfer, TR: Targeted Kernel 1

• Optimized design gains up to 15%, 15% and Latency 0.5 22% compared to TR, and more than 86% 0 compared to DT on X, Y and Z respectively 1 2 4 8 16 32 64 128 256 Size of DimX, [x,16,16]

2.5 2.5

2 2 (ms) (ms) 1.5 86% 1.5

1 1

Latency Latency Latency Latency 0.5 0.5

0 0 1 2 4 8 16 32 64 128 256 1 2 4 8 16 32 64 128 256 Size of DimY, [16,y,16] Size of DimZ, [16,16,z]

Network Based Computing Laboratory MVAPICH User Group Meeting (MUG) 2017 84 MPI Datatype Processing (Communication Optimization )

Common Scenario Waste of computing resources on CPU and GPU Existing Design

MPI_Isend (A,.. Datatype,…) Isend(1) Isend(1) Isend(1) Wait CPU

MPI_Isend (B,.. Datatype,…)

l l l

e e

e Wait For Wait For Wait For

t t t

e e e

d d d

r r r

a a

n n n

i i

a a a

r r r

t t

t Progress

t t t

e e

MPI_Isend (C,.. Datatype,…) Kernel e Kernel Kernel

i i i

e e e

S S

S S S

n n n

K K K

I I MPI_Isend (D,.. Datatype,…) I (WFK) (WFK) (WFK) … GPU Kernel on Stream Kernel on Stream Kernel on Stream MPI_Waitall (…);

Proposed Design

Isend(1)Isend(2)Isend(3) Wait CPU

l l

e e

e Progress

t t

e e

a a

n t

n n

K d d

i i K K

r r

t t

F F F

i i

a a

e e

n n

K K

S S

I I

W W *A, B…contain non-contiguous MPI Datatype W

Kernel on Stream GPU Expected Benefits Kernel on Stream

Kernel on Stream

Start Time Finish Proposed Finish Existing

Network Based Computing Laboratory MVAPICH User Group Meeting (MUG) 2017 85 Application-Level Evaluation (Cosmo) and Weather Forecasting in Switzerland

Wilkes GPU Cluster CSCS GPU cluster

Default Callback-based Event-based Default Callback-based Event-based

1.2

1 1

0.8 0.8

0.6 0.6

0.4 0.4

0.2 Time Execution Normalized 0.2 Normalized Execution Time Execution Normalized 0 0 4 8 16 32 16 32 64 96

Number of GPUs Number of GPUs

• 2X improvement on 32 GPUs nodes Cosmo model: http://www2.cosmo-model.org/content • 30% improvement on 96 GPU nodes (8 GPUs/node) /tasks/operational/meteoSwiss/ On-going collaboration with CSCS and MeteoSwiss (Switzerland) in co-designing MV2-GDR and Cosmo Application C. Chu, K. Hamidouche, A. Venkatesh, D. Banerjee , H. Subramoni, and D. K. Panda, Exploiting Maximal Overlap for Non-Contiguous Data Movement Processing on Modern GPU-enabled Systems, IPDPS’16

Network Based Computing Laboratory MVAPICH User Group Meeting (MUG) 2017 86 Enhanced Support for GPU Managed Memory 2D Stencil Performance for Halowidth=1 0.8 ● CUDA Managed => no memory pin down Device ● No IPC support for intranode communication 0.7 Managed 0.6 ● No GDR support for Internode communication 0.5 ● Significant productivity benefits due to abstraction of explicit 0.4 allocation and cudaMemcpy() 0.3 ● Initial and basic support in MVAPICH2-GDR 0.2 ● For both intra- and inter-nodes use “pipeline through” (ms) Time Exchange Halo 0.1 host memory 0 1 2 4 8 16 32 64 128 256 1K 4K 8K 16K ● Enhance intranode managed memory to use IPC Total Dimension Size (Bytes) ● Double buffering pair-wise IPC-based scheme

10000 9000 Enhanced ● Brings IPC performance to Managed memory 8000 ● High performance and high productivity 7000 MV2-GDR 2.2b 2.5X 6000 ● 2.5 X improvement in bandwidth 5000 4000 ● OMB extended to evaluate the performance of point-to-point 3000

Bandwidth (MB/s) Bandwidth 2000 and collective communications using managed buffers 1000 0 D. S. Banerjee, K Hamidouche, and D. K Panda, Designing High Performance 32K 128K 512K 2M Communication Runtime for GPUManaged Memory: Early Experiences, GPGPU-9 Message Size (bytes) Workshop, held in conjunction with PPoPP ‘16 Network Based Computing Laboratory MVAPICH User Group Meeting (MUG) 2017 87 Presentation Overview

Network Based Computing Laboratory MVAPICH User Group Meeting (MUG) 2017 88 Overview of GPUDirect aSync (GDS) Feature: Current MPI+CUDA interaction GPU CPU HCA CUDA_Kernel_a<<<>>>(A…., stream1) cudaStreamSynchronize(stream1) MPI_Isend (A,…., req1) MPI_Wait (req1) CUDA_Kernel_b<<<>>>(B…., stream1)

100% CPU control • Limit the throughput of a GPU • Limit the asynchronous progress • Waste GPU cycles

Network Based Computing Laboratory MVAPICH User Group Meeting (MUG) 2017 89 MVAPICH2-GDS: Decouple GPU Control Flow from CPU

GPU CPU HCA CUDA_Kernel_a<<<>>>(A…., stream1) MPI_Isend (A,…., req1, stream1) MPI_Wait (req1, stream1) (non-blocking from CPU) CUDA_Kernel_b<<<>>>(B…., stream1)

CPU offloads the compute, communication and synchronization Kernel Launch tasks to GPU overhead hidden • CPU is out of the critical path • Tight interaction between GPU and HCA • Hide the overhead of kernel launch • Requires MPI semantics extensions • All operations are asynchronous from CPU • Extend MPI semantics with Stream-based semantics

Network Based Computing Laboratory MVAPICH User Group Meeting (MUG) 2017 90 MVAPICH2-GDS: Preliminary Results

Latency oriented: Send+kernel and Recv+kernel Throughput Oriented: back-to-back 30 35 25 30 25

20 15 15 10 Default Enhanced-GDS

Latency (us) Latency 10 Default Enhanced-GDS Latency (us) Latency 5 5 0 0 8 32 128 512 16 64 256 1024 Message Size (bytes) Message Size (bytes) • Latency Oriented: Able to hide the kernel launch overhead – 25% improvement at 256 Bytes compared to default behavior • Throughput Oriented: Asynchronously to offload queue the Communication and computation tasks – 14% improvement at 1KB message size – Requires some tuning and expect better performance for Application with different Kernels Intel Sandy Bridge, NVIDIA K20 and Mellanox FDR HCA

Network Based Computing Laboratory MVAPICH User Group Meeting (MUG) 2017 91 MVAPICH2 Software Family

Requirements Library

MPI with IB, iWARP and RoCE MVAPICH2

Advanced MPI, OSU INAM, PGAS and MPI+PGAS with IB and RoCE MVAPICH2-X

MPI with IB & GPU MVAPICH2-GDR

MPI with IB & MIC MVAPICH2-MIC

HPC Cloud with MPI & IB MVAPICH2-Virt

Energy-aware MPI with IB, iWARP and RoCE MVAPICH2-EA

MPI Energy Monitoring Tool OEMT

InfiniBand Network Analysis and Monitoring OSU INAM

Microbenchmarks for Measuring MPI and PGAS Performance OMB

Network Based Computing Laboratory MVAPICH User Group Meeting (MUG) 2017 92 Energy-Aware MVAPICH2 & OSU Energy Management Tool (OEMT)

• MVAPICH2-EA 2.1 (Energy-Aware) • A white-box approach • New Energy-Efficient communication protocols for pt-pt and collective operations • Intelligently apply the appropriate Energy saving techniques • Application oblivious energy saving

• OEMT • A library utility to measure energy consumption for MPI applications • Works with all MPI runtimes • PRELOAD option for precompiled applications • Does not require ROOT permission: • A safe kernel module to read only a subset of MSRs

Network Based Computing Laboratory MVAPICH User Group Meeting (MUG) 2017 93 Designing Energy-Aware (EA) MPI Runtime

Overall application Energy Expenditure

Energy Spent in Communication Energy Spent in Computation Routines Routines

Collective Point-to-point Routines RMA Routines Routines

MVAPICH2-EA Designs

MPI Two-sided and collectives (ex: MVAPICH2) Impact MPI-3 RMA Implementations (ex: MVAPICH2)

One-sided runtimes (ex: ComEx) Other PGAS Implementations (ex: OSHMPI)

Network Based Computing Laboratory MVAPICH User Group Meeting (MUG) 2017 94 MVAPICH2-EA: Application Oblivious Energy-Aware-MPI (EAM)

• An energy efficient runtime that provides energy savings without application knowledge • Uses automatically and transparently the best energy lever • Provides guarantees on maximum degradation with 5-

41% savings at <= 5% 1 degradation • Pessimistic MPI applies energy reduction lever to each MPI call

A Case for Application-Oblivious Energy-Efficient MPI Runtime A. Venkatesh, A. Vishnu, K. Hamidouche, N. Tallent, D. K. Panda, D. Kerbyson, and A. Hoise, Supercomputing ‘15, Nov 2015 [Best Student Paper Finalist]

Network Based Computing Laboratory MVAPICH User Group Meeting (MUG) 2017 95 MPI-3 RMA Energy Savings with Proxy-Applications

350000 Graph500 (Execution Time) Graph500 (Energy Usage) 60 300000 optimistic optimistic pessimistic 50 pessimistic 250000 46% EAM-RMA EAM-RMA 40

200000

Joules 30

150000 Seconds

100000 20

50000 10

0 0 512 256 128 512 256 128 #Processes #Processes

• MPI_Win_fence dominates application execution time in graph500 • Between 128 and 512 processes, EAM-RMA yields between 31% and 46% savings with no degradation in execution time in comparison with the default optimistic MPI runtime

Network Based Computing Laboratory MVAPICH User Group Meeting (MUG) 2017 96 MPI-3 RMA Energy Savings with Proxy-Applications

SCF (Energy Usage) SCF (Execution Time) 3000000 600 optimistic optimistic 2500000 42% pessimistic 500 pessimistic EAM-RMA EAM-RMA 2000000

400

1500000

Joules 300 Seconds 1000000 200

500000 100

0 512 256 128 0 #Processes 512 256 128 #Processes • SCF (self-consistent field) calculation spends nearly 75% total time in MPI_Win_unlock call • With 256 and 512 processes, EAM-RMA yields 42% and 36% savings at 11% degradation (close to permitted degradation ρ = 10%) • 128 processes is an exception due 2-sided and 1-sided interaction • MPI-3 RMA Energy-efficient support will be available in upcoming MVAPICH2-EA release

Network Based Computing Laboratory MVAPICH User Group Meeting (MUG) 2017 97 MVAPICH2 Software Family

Requirements Library

MPI with IB, iWARP and RoCE MVAPICH2

Advanced MPI, OSU INAM, PGAS and MPI+PGAS with IB and RoCE MVAPICH2-X

MPI with IB & GPU MVAPICH2-GDR

MPI with IB & MIC MVAPICH2-MIC

HPC Cloud with MPI & IB MVAPICH2-Virt

Energy-aware MPI with IB, iWARP and RoCE MVAPICH2-EA

MPI Energy Monitoring Tool OEMT

InfiniBand Network Analysis and Monitoring OSU INAM

Microbenchmarks for Measuring MPI and PGAS Performance OMB

Network Based Computing Laboratory MVAPICH User Group Meeting (MUG) 2017 98 Overview of OSU INAM

• A network monitoring and analysis tool that is capable of analyzing traffic on the InfiniBand network with inputs from the MPI runtime – http://mvapich.cse.ohio-state.edu/tools/osu-inam/ • Monitors IB clusters in real time by querying various subnet management entities and gathering input from the MPI runtimes • OSU INAM v0.9.1 released on 05/13/16 • Significant enhancements to user interface to enable scaling to clusters with thousands of nodes • Improve database insert times by using 'bulk inserts‘ • Capability to look up list of nodes communicating through a network link • Capability to classify data flowing over a network link at job level and process level granularity in conjunction with MVAPICH2-X 2.2rc1 • “Best practices “ guidelines for deploying OSU INAM on different clusters • Capability to analyze and profile node-level, job-level and process-level activities for MPI communication – Point-to-Point, Collectives and RMA • Ability to filter data based on type of counters using “drop down” list • Remotely monitor various metrics of MPI processes at user specified granularity • "Job Page" to display jobs in ascending/descending order of various performance metrics in conjunction with MVAPICH2-X • Visualize the data transfer happening in a “live” or “historical” fashion for entire network, job or set of nodes

Network Based Computing Laboratory MVAPICH User Group Meeting (MUG) 2017 99 OSU INAM Features

Comet@SDSC --- Clustered View Finding Routes Between Nodes (1,879 nodes, 212 switches, 4,377 network links)

• Show network topology of large clusters • Visualize traffic pattern on different links • Quickly identify congested links/links in error state • See the history unfold – play back historical state of the network

Network Based Computing Laboratory MVAPICH User Group Meeting (MUG) 2017 100 OSU INAM Features (Cont.)

Visualizing a Job (5 Nodes) Estimated Process Level Link Utilization • Job level view • Estimated Link Utilization view • Show different network metrics (load, error, etc.) for any live job • Classify data flowing over a network link at • Play back historical data for completed jobs to identify bottlenecks different granularity in conjunction with • Node level view - details per process or per node MVAPICH2-X 2.2rc1 • Job level and • CPU utilization for each rank/node • Process level • Bytes sent/received for MPI operations (pt-to-pt, collective, RMA) More Details in Tutorial/Demo • Network metrics (e.g. XmitDiscard, RcvError) per rank/node Session Tomorrow Network Based Computing Laboratory MVAPICH User Group Meeting (MUG) 2017 101 OSU Microbenchmarks • Available since 2004 • Suite of microbenchmarks to study communication performance of various programming models • Benchmarks available for the following programming models – Message Passing Interface (MPI) – Partitioned Global Address Space (PGAS) • Unified Parallel C (UPC) • Unified Parallel C++ (UPC++) • OpenSHMEM • Benchmarks available for multiple accelerator based architectures – Compute Unified Device Architecture (CUDA) – OpenACC Application Program Interface • Part of various national resource procurement suites like NERSC-8 / Trinity Benchmarks • Continuing to add support for newer primitives and features • Please visit the following link for more information – http://mvapich.cse.ohio-state.edu/benchmarks/

Network Based Computing Laboratory MVAPICH User Group Meeting (MUG) 2017 102 Applications-Level Tuning: Compilation of Best Practices

• MPI runtime has many parameters • Tuning a set of parameters can help you to extract higher performance • Compiled a list of such contributions through the MVAPICH Website – http://mvapich.cse.ohio-state.edu/best_practices/ • Initial list of applications – Amber – HoomDBlue – HPCG – Lulesh – MILC – Neuron – SMG2000 • Soliciting additional contributions, send your results to mvapich-help at cse.ohio-state.edu. • We will link these results with credits to you.

Network Based Computing Laboratory MVAPICH User Group Meeting (MUG) 2017 103 Amber: Impact of Tuning Eager Threshold

• Tuning the Eager threshold has a significant 500 impact on application performance by avoiding Default Tuned the synchronization of rendezvous protocol 400 and thus yielding better communication 300 computation overlap 19% • 19% improvement in overall execution time at 200 256 processes

100 • Library Version: MVAPICH2 2.2 Execution Time (s) Execution • MVAPICH Flags used 0 – MV2_IBA_EAGER_THRESHOLD=131072 64 128 256 – MV2_VBUF_TOTAL_SIZE=131072 Number of Processes • Input files used – Small: MDIN Data Submitted by: Dong Ju Choi @ UCSD – Large: PMTOP Network Based Computing Laboratory MVAPICH User Group Meeting (MUG) 2017 104 MiniAMR: Impact of Tuning Eager Threshold

MiniAMR • Tuning the Eager threshold has a significant

205 impact on application performance by avoiding the synchronization of rendezvous protocol 200 and thus yielding better communication 195 8% computation overlap 190 • 8% percent reduction in total communication 185 time • Library Version: MVAPICH2 2.2 180 • MVAPICH Flags used Communication Time (sec) Time Communication 175

– MV2_IBA_EAGER_THRESHOLD=32768

1K 2K 4K 8K

128 512

16K 64K

32K – MV2_VBUF_TOTAL_SIZE=32768

128K 256K 512K Eager Threshold (Bytes) Data Submitted by Karen Tomko @ OSC and Dong Ju Choi @ UCSD

Network Based Computing Laboratory MVAPICH User Group Meeting (MUG) 2017 105 SMG2000: Impact of Tuning Transport Protocol

• UD-based transport protocol selection 80

(s) Default Tuned benefits the SMG2000 application 70 22% 60 • 22% and 6% on 1,024 and 4,096 cores, Time 50 respectively 40 • Library Version: MVAPICH2 2.1 30 • MVAPICH Flags used

Execution Execution 20 – MV2_USE_ONLY_UD=1 10 • System Details 0 1024 2048 4096 – Stampede@ TACC Number of Processes – Sandybridge architecture with dual 8-cores nodes and ConnectX-3 FDR network Data Submitted by Jerome Vienne @ TACC

Network Based Computing Laboratory MVAPICH User Group Meeting (MUG) 2017 106 Neuron: Impact of Tuning Transport Protocol

• UD-based transport protocol selection

140 benefits the SMG2000 application

(s) Default Tuned 120 • 15% and 27% improvement is seen for 768 and 100 1,024 processes respectively Time Time • Library Version: MVAPICH2 2.2 80 • MVAPICH Flags used 60 27% – MV2_USE_ONLY_UD=1

40 • Input File Execution Execution 20 – YuEtAl2012 0 • System Details 384 512 768 1024 – Comet@SDSC Number of Processes – Haswell nodes with dual 12-cores socket per Data Submitted by Mahidhar Tatineni @ SDSC node and Mellanox FDR (56 Gbps) network.

Network Based Computing Laboratory MVAPICH User Group Meeting (MUG) 2017 107 HPCG: Impact of Collective Tuning for MPI+OpenMP Programming Model

1.2 • Partial subscription nature of hybrid MPI+OpenMP Default Tuned programming requires a new level of collective tuning 1 – For PPN=2 (Processes Per Node), the tuned version of MPI_Reduce shows 51% improvement on 2,048 cores 24% 0.8 • 24% improvement on 512 cores – 8 OpenMP threads per MPI processes 0.6 • Library Version: MVAPICH2 2.1 • MVAPICH Flags used 0.4 – The tuning parameters for hybrid MPI+OpenMP programming models is on by default from MVAPICH2-2.1 0.2 onward • System Details

Normalized Execution Time Execution Normalized 0 – Stampede@ TACC – Sandybridge architecture with dual 8-cores nodes and HPCG ConnectX-3 FDR network Data Submitted by Jerome Vienne and Carlos Rosales-Fernandez @ TACC

Network Based Computing Laboratory MVAPICH User Group Meeting (MUG) 2017 108 LULESH: Impact of Collective Tuning for MPI+OpenMP Programming Model

1.2 • Partial subscription nature of hybrid MPI+OpenMP Default Tuned programming requires a new level of collective tuning 1 4% – For PPN=2 (Processes Per Node), the tuned version of MPI_Reduce shows 51% improvement on 2,048 cores 0.8 • 4% improvement on 512 cores – 8 OpenMP threads per MPI processes 0.6 • Library Version: MVAPICH2 2.1 • MVAPICH Flags used 0.4 – The tuning parameters for hybrid MPI+OpenMP programming models is on by default from MVAPICH2-2.1 0.2 onward • System Details

Normalized Execution Time Execution Normalized 0 – Stampede@ TACC – Sandybridge architecture with dual 8-cores nodes and Lulesh ConnectX-3 FDR network Data Submitted by Jerome Vienne and Carlos Rosales-Fernandez @ TACC

Network Based Computing Laboratory MVAPICH User Group Meeting (MUG) 2017 109 MILC: Impact of User-mode Memory Registration (UMR) based tuning 70 • Non-contiguous data processing is very common on HPC Default Tuned 60 applications. MVAPICH2 offers efficient designs for MPI (s) Datatype support using novel hardware features such as 50 UMR

Time Time 40 • UMR-based protocol selection benefits the MILC application. 30 – 4% and 6% improvement in execution time at 512 and 640 processors, respectively 20 • Library Version: MVAPICH2-X 2.2 Execution Execution 6% 10 • MVAPICH Flags used 0 – MV2_USE_UMR=1 128 256 512 640 • System Details – The experimental cluster consists of 32 Ivy Bridge Compute nodes Number of Processes interconnected by Mellanox FDR. – The Intel Ivy Bridge processors consist of Xeon dual ten-core Data Submitted by Mingzhe Li @ OSU sockets operating at 2.80GHz with 32GB RAM and Mellanox OFED version 3.2-1.0.1.1. Network Based Computing Laboratory MVAPICH User Group Meeting (MUG) 2017 110

HOOMD-blue: Impact of GPUDirect RDMA Based Tuning 64K Particles 4000 • HOOMD-blue is a Molecular Dynamics Default Tuned simulation using a custom force field. 3000 2X • GPUDirect specific features selection and 2000 tuning significantly benefit the HOOMD-blue 1000 application. We observe a factor of 2X

per second (TPS) secondper improvement on 32 GPU nodes, with both 64K Average Time Steps Time Steps Average 0 and 256K particles 4 8 16 32 Number of Processes • Library Version: MVAPICH2-GDR 2.2 256K Particles 3000 • MVAPICH-GDR Flags used MV2 MV2+GDR – MV2_USE_CUDA=1 2000 2X – MV2_USE_GPUDIRECT=1 1000 – MV2_GPUDIRECT_GDRCOPY=1

• System Details per second (TPS) secondper Average Time Steps Time Steps Average 0 – Wilkes@Cambridge 4 8 16 32 Number of Processes – 128 Ivybridge nodes, each node is a dual 6- Data Submitted by Khaled Hamidouche @ OSU cores socket with Mellanox FDR Network Based Computing Laboratory MVAPICH User Group Meeting (MUG) 2017 111 MVAPICH2 – Plans for Exascale

• Performance and Memory scalability toward 1-10M cores • Hybrid programming (MPI + OpenSHMEM, MPI + UPC, MPI + CAF …) • MPI + Task* • Enhanced Optimization for GPU Support and Accelerators • Taking advantage of advanced features of Mellanox InfiniBand • Tag Matching* • Adapter Memory* • Enhanced communication schemes for upcoming architectures • Knights Landing with MCDRAM* • NVLINK* • CAPI* • Extended topology-aware collectives • Extended Energy-aware designs and Virtualization Support • Extended Support for MPI Tools Interface (as in MPI 3.0) • Extended FT support • Support for * features will be available in future MVAPICH2 Releases

Network Based Computing Laboratory MVAPICH User Group Meeting (MUG) 2017 112

Thank You!

Network-Based Computing Laboratory http://nowlab.cse.ohio-state.edu/

The MVAPICH2 Project http://mvapich.cse.ohio-state.edu/

Network Based Computing Laboratory MVAPICH User Group Meeting (MUG) 2017 113