How to Boost the Performance of Your MPI and PGAS Applications with MVAPICH2 Libraries
A Tutorial at the MVAPICH User Group (MUG) Meeting ’18 by
The MVAPICH Team The Ohio State University E-mail: [email protected] http://mvapich.cse.ohio-state.edu/ 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 (MUG) Meeting’18 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 Awareness File Systems Communication Communication and Locks Tolerance Resilience
Networking Technologies Multi-/Many-core Accelerators (InfiniBand, 40/100GigE, Aries, and Omni-Path) Architectures (GPU and MIC)
Network Based Computing Laboratory MVAPICH User Group (MUG) Meeting’18 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 (MUG) Meeting’18 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.1), 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,925 organizations in 86 countries – More than 484,000 (> 0.48 million) downloads from the OSU site directly – Empowering many TOP500 clusters (Jul ‘18 ranking) • 2nd ranked 10,649,640-core cluster (Sunway TaihuLight) at NSC, Wuxi, China • 12th, 556,104 cores (Oakforest-PACS) in Japan • 15th, 367,024 cores (Stampede2) at TACC • 24th, 241,108-core (Pleiades) at NASA and many others – 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
Network Based Computing Laboratory MVAPICH User Group (MUG) Meeting’18 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 Primitives Algorithms Awareness Access File Systems Tolerance Messages n & Analysis
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 XPMEM* NVLink* CAPI* IOV Rail Memory
* Upcoming
Network Based Computing Laboratory MVAPICH User Group (MUG) Meeting’18 6 MVAPICH2 Software Family
Requirements Library
MPI with IB, iWARP, Omni-Path, and RoCE MVAPICH2
MPI with IB, RoCE & GPU and Support for Deep Learning MVAPICH2-GDR
InfiniBand Network Analysis and Monitoring OSU INAM Microbenchmarks for Measuring MPI and PGAS Performance OMB
Network Based Computing Laboratory MVAPICH User Group (MUG) Meeting’18 7 MVAPICH2 2.3-GA • Released on 07/23/2018 • Major Features and Enhancements – Based on MPICH v3.2.1 – Enhancements to process mapping strategies and automatic architecture/network – Introduce basic support for executing MPI jobs in Singularity detection – Improve performance for MPI-3 RMA operations • Improve performance of architecture detection on high core-count systems – Enhancements for Job Startup • Enhanced architecture detection for OpenPOWER, Intel Skylake and Cavium ARM (ThunderX) systems • Improved job startup time for OFA-IB-CH3, PSM-CH3, and PSM2-CH3 • New environment variable MV2_THREADS_BINDING_POLICY for multi-threaded MPI and • On-demand connection management for PSM-CH3 and PSM2-CH3 channels MPI+OpenMP applications • Enhance PSM-CH3 and PSM2-CH3 job startup to use non-blocking PMI calls • Support 'spread', 'bunch', 'scatter', 'linear' and 'compact' placement of threads • Introduce capability to run MPI jobs across multiple InfiniBand subnets – Warn user if oversubscription of core is detected – Enhancements to point-to-point operations • Enhance MV2_SHOW_CPU_BINDING to enable display of CPU bindings on all nodes • Enhance performance of point-to-point operations for CH3-Gen2 (InfiniBand), CH3-PSM, and • Added support for MV2_SHOW_CPU_BINDING to display number of OMP threads CH3-PSM2 (Omni-Path) channels • Added logic to detect heterogeneous CPU/HFI configurations in PSM-CH3 and PSM2-CH3 • Improve performance for Intra- and Inter-node communication for OpenPOWER architecture channels • Enhanced tuning for OpenPOWER, Intel Skylake and Cavium ARM (ThunderX) systems – Thanks to Matias Cabral@Intel for the report • Improve performance for host-based transfers when CUDA is enabled • Enhanced HFI selection logic for systems with multiple Omni-Path HFIs • Improve support for large processes per node and hugepages on SMP systems • Introduce run time parameter MV2_SHOW_HCA_BINDING to show process to HCA
– Enhancements to collective operations bindings • Enhanced performance for Allreduce, Reduce_scatter_block, Allgather, Allgatherv – Miscellaneous enhancements and improved debugging and tools support – Thanks to Danielle Sikich and Adam Moody @ LLNL for the patch • Enhance support for MPI_T PVARs and CVARs
• Add support for non-blocking Allreduce using Mellanox SHARP • Enhance debugging support for PSM-CH3 and PSM2-CH3 channels – Enhance tuning framework for Allreduce using SHArP • Update to hwloc version 1.11.9
• Enhanced collective tuning for IBM POWER8, IBM POWER9, Intel Skylake, Intel KNL, Intel • Tested with CLANG v5.0.0 Broadwell
Network Based Computing Laboratory MVAPICH User Group (MUG) Meeting’18 8 Presentation Overview
• Job start-up • Point-to-point Inter-node Protocol • Transport Type Selection • Multi-rail • Process Mapping and Point-to-point Intra-node Protocols • Collectives
• MPI_T Support
Network Based Computing Laboratory MVAPICH User Group (MUG) Meeting’18 9 Towards High Performance and Scalable Startup at Exascale • Near-constant MPI and OpenSHMEM a b c initialization time at any process count P M d On-demand a Connection • 10x and 30x improvement in startup time b PMIX_Ring of MPI and OpenSHMEM respectively at 16,384 processes P PGAS – State of the art e c PMIX_Ibarrier • Memory consumption reduced for remote M MPI – State of the art d PMIX_Iallgather endpoint information by O(processes per Endpoint Information Endpoint O e Shmem based PMI Memory Required to Store O PGAS/MPI – Optimized node) • 1GB Memory saved per node with 1M Job Startup Performance 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 (MUG) Meeting’18 10 Startup Performance on KNL + Omni-Path
MPI_Init - TACC Stampede-KNL MPI_Init & Hello World - Oakforest-PACS 200 25 Intel MPI 2018 beta Hello World (MVAPICH2-2.3a) 21s 20 150 MVAPICH2 2.3a MPI_Init(MVAPICH2-2.3a) 8.8x 15 100 10 51s 50 MPI_Init (Seconds) MPI_Init 5 5.8s Time Taken (Seconds) Taken Time
0 0 64 1K 2K 4K 8K
64 1K 2K 4K 8K 128 256 512 128 256 512 16K 32K 64K 16K 32K 64K 128K 181K 232K 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 (MUG) Meeting’18 11 On-demand Connection Management for OpenSHMEM+MPI
Performance of OpenSHMEM Breakdown of OpenSHMEM Startup Initialization and Hello World 35 120 Co nnect ion Set up Hello World - Static 30 PM I Exchange 100 25 Initialization - Static Memory Registration 80 20 Hello World - On-demand Shared Mem ory Setup 60 15 Initialization - On-d eman d Other 40 10 Time Taken (Seconds) Taken Time 5 (Seconds) Taken Time 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 (MUG) Meeting’18 12 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 (MUG) Meeting’18 13 Presentation Overview
• Job start-up • Point-to-point Inter-node Protocol • Transport Type Selection • Multi-rail • Process Mapping and Point-to-point Intra-node Protocols • Collectives
• MPI_T Support
Network Based Computing Laboratory MVAPICH User Group (MUG) Meeting’18 14 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 12 8 25 6 51 2 1K 2K 4k 8k 16 k 32 k 0 1 2 4 8 16 32 64 12 825 651 2 1K 2K 4K 8K 16 K32 K64 K 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 (MUG) Meeting’18 15 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 (MUG) Meeting’18 16 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 message sizes and operations where communication Completion Check for library is progressed frequently Completion Not Complete
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 (MUG) Meeting’18 17 Dynamic and Adaptive MPI Point-to-point Communication Protocols
Desired Eager Threshold Eager Threshold for Example Communication Pattern with Different Designs Dynamic + Adaptive Process Pair Eager Threshold (KB) Default Manually Tuned 0 – 4 32 4 5 6 7 4 5 6 7 4 5 6 7 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
Design Metrics: Overlap & Memory Requirement Metrics: Performance & Productivity 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 Consumption Memory Relative 128 256 512 1K Number of Processes Number of Processes
Def a ul t Thr eshol d=17K Thr eshol d=64K Thr eshol d=128K Dy na m i cThr es hol d Def a ul t Thr eshol d=17K Thr eshol d=64K Thr eshol d=128K Dy na m i cThr es hol d 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 (MUG) Meeting’18 18 Dynamic and Adaptive Tag Matching
Tag matching is a significant A new tag matching design Better performance than other state- overhead for receivers of-the art tag-matching schemes - Dynamically adapt to 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 (MUG) Meeting’18 19 Presentation Overview
• Job start-up • Point-to-point Inter-node Protocol • Transport Type Selection • Multi-rail • Process Mapping and Point-to-point Intra-node Protocols • Collectives
• MPI_T Support
Network Based Computing Laboratory MVAPICH User Group (MUG) Meeting’18 20 Hybrid (UD/RC/XRC) Mode in MVAPICH2
Performance with HPCC Random Ring • Both UD and RC/XRC have benefits UD Hy brid 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 Number of Processes interface
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 (MUG) Meeting’18 21 Minimizing Memory Footprint by Direct Connect (DC) Transport
• Constant connection cost (One QP for any peer) 0 P0 P1 Node • Full Feature Set (RDMA, Atomics etc) • Separate objects for send (DC Initiator) and receive (DC Node 3 Node 1 IB 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 2 P4 P5
Node • Available since MVAPICH2-X 2.2a Memory Footprint for Alltoall NAMD - Apoa1: Large data set 1. 2 RC DC-Pool UD XR C RC DC-Pool UD XR C 97 1 10 0 47 0. 8 22 10 10 10 10 10 0. 6 10 5 3 0. 4 2 1 1 1 1 1 0. 2
Connection Memory (KB) 1
Normalized Execution Time 0 80 16 0 32 0 64 0 16 0 32 0 62 0 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 (MUG) Meeting’18 22 Presentation Overview
• Job start-up • Point-to-point Inter-node Protocol • Transport Type Selection • Multi-rail • Process Mapping and Point-to-point Intra-node Protocols • Collectives
• MPI_T Support
Network Based Computing Laboratory MVAPICH User Group (MUG) Meeting’18 23 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 (MUG) Meeting’18 24 Performance Tuning on Multi-Rail Clusters
Impact of Default Message Striping on Bandwidth Impact of Default Rail Binding on Message Rate Impact of Advanced Multi-rail Tuning on Message Rate 70 00 7 8 Use First Si n g l e - Ra il Si n g l e - Ra il 7 7% 60 00 6 Rou nd Robi n Dual-Rail 6 50 00 Dual-Rail 5 Sc a t t e r 5 Bun ch 40 00 98% 4 130% 4 30 00 3 3 Message Rate Rate Message 20 00 Rate Message 2 2
Bandwidth (MB/sec) Bandwidth 100 0 1 1 (Millionsof Messages/sec) 0 (Millionsof Messages /Sec) 0 0
1 4 1 1 4 16 1K 4 16 1K 64 4K 1M 4M 16 64 1K 4K 1M 64 4K 1M 4M 25 6 16K 64 K 25 6 16K 64 K 4M 25 6 16K 64 K 25 6K 25 6K 25 6K 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 (MUG) Meeting’18 25 Presentation Overview
• Job start-up • Point-to-point Inter-node Protocol • Transport Type Selection • Multi-rail • Process Mapping and Point-to-point Intra-node Protocols • Collectives
• MPI_T Support
Network Based Computing Laboratory MVAPICH User Group (MUG) Meeting’18 26 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 (MUG) Meeting’18 27 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 (MUG) Meeting’18 28 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 (MUG) Meeting’18 29 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-hyper threaded 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 (MUG) Meeting’18 30 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
HWT Core2 HWT Core3 Core2 HWT Core3 HWT
HWT HWT HWT HWT HWT HWT HWT HWT
• Detects hardware-threads support in architecture Rank2 Rank3 • Assigns MPI ranks to physical cores and respective OpenMP Threads to HW threads Network Based Computing Laboratory MVAPICH User Group (MUG) Meeting’18 31 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 (MUG) Meeting’18 32 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.3rc1-userguide.html#x1-600006.5
Network Based Computing Laboratory MVAPICH User Group (MUG) Meeting’18 33 Presentation Overview
• Job start-up • Point-to-point Inter-node Protocol • Transport Type Selection • Multi-rail • Process Mapping and Point-to-point Intra-node Protocols • Collectives
• MPI_T Support
Network Based Computing Laboratory MVAPICH User Group (MUG) Meeting’18 34 Collective Communication in MVAPICH2
Blocking and Non-Blocking Collective Algorithms in MV2
Conventional Multi/Many-Core (Flat) Aware Designs
Inter-Node Intra-Node Communication Communication
Point to Hardware Point to Point Direct Kernel SHARP RDMA Point Multicast (SHMEM, Direct Shared Assisted LiMIC, CMA, Memory (CMA, XPMEM, XPMEM) LiMIC) Designed for Performance & Overlap Run-time flags: All shared-memory based collectives : MV2_USE_SHMEM_COLL (Default: ON) Hardware Mcast-based collectives : MV2_USE_MCAST (Default : OFF) CMA-based collectives : MV2_USE_CMA_COLL (Default : ON) Network Based Computing Laboratory MVAPICH User Group (MUG) Meeting’18 35 Hardware Multicast-aware MPI_Bcast on TACC Stampede
Small Messages (102,400 Cores) 85% Large Messages (102,400 Cores) 40 450 35 Defa ult 400 Defa ult 30 350 Multicast Multicast 25 300 20 250 15 200 10 150 Latency (us) Latency Latency (us) Latency 100 5 50 0 0 2 8 32 128 512 2K 8K 32K 128K Message Size (Bytes) Message Size (Bytes) 32 KByte Message 16 Byte Message 200 30 80% 25 Defa ult 150 Defa ult 20 Multicast Multicast 15 100 10
Latency (us) Latency 50 Latency (us) Latency 5 0 0
16 32 64 1K 2K 4K 6K 16 32 64 1K 2K 4K 6K 128 256 512 128 256 512 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 (MUG) Meeting’18 36 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 (MUG) Meeting’18 37 Advanced Allreduce Collective Designs Using SHArP osu_allreduce (OSU Micro Benchmark) using MVAPICH2 2.3b 4 PPN*, 16 Nodes 28 PPN, 16 Nodes MV A PI CH 2 MV A PI CH 2 12 16 1.5x 10 MV A PI CH 2 - SH Ar P 14 MV A PI CH 2 - SH Ar P 2.3x 12 8 10 6 8 6 Latency (us) Latency
Latency (us) Latency 4 4 2 2 0 0 4 8 16 32 64 12 8 25 6 4 8 16 32 64 12 8 25 6 Message Size (Bytes) Message Size (Bytes) MV 2- 128B 8 MV 2- SHA r P- 128 B 12 7 MV 2- 32B 1.4x 2.3x 10 6 MV 2- SHA r P- 32B 5 8
4 6 MV2 -128B
Latency (us) Latency 3 MV2 -SH ArP-12 8B Latency (us) Latency 4 MV2 -32B 2 MV2 -SH ArP-32 B 1 2
0 0 (4,4) (8,4) (16,4) (4,28) (8,28) (16,28) *PPN: Processes Per Node (Number of Nodes, PPN) (Number of Nodes, PPN) Network Based Computing Laboratory MVAPICH User Group (MUG) Meeting’18 38 Benefits of SHARP at Application Level
Avg DDOT Allreduce time of HPCG Mesh Refinement Time of MiniAMR 0.35 12% 0.2 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 (MUG) Meeting’18 39 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 (MUG) Meeting’18 40 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
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 (MUG) Meeting’18 41 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 (MUG) Meeting’18 42 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 (MUG) Meeting’18 43 P3DFFT Performance with Non-Blocking Alltoall using RDMA Primitives
Small Scale Runs Large Scale Runs 16 14 Default RDMA-Aware Default-Thread Default RDMA-Aware 19% 14 12 12 10 10 8 8 6 6 4 4 2 2 0 CPU Time Per Loop (Seconds) Loop Per Time CPU CPU Time Per Loop (Seconds) Loop Per Time CPU 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 procs • Default-Thread exhibits worst performance – Possibly because threads steal CPU cycles from P3DFFT Will be available in future – Do not consider for large scale experiments
Network Based Computing Laboratory MVAPICH User Group (MUG) Meeting’18 44 Offloading with Scalable Hierarchical Aggregation Protocol (SHArP)
§ Management and execution of MPI operations in the network by using SHArP § Manipulation of data while it is being transferred in the switch network § SHArP provides an abstraction to realize the reduction operation Physical Network Topology* § Defines Aggregation Nodes (AN), Aggregation Tree, and Aggregation Groups § AN logic is implemented as an InfiniBand Target Channel Adapter (TCA) integrated into the switch ASIC * § Uses RC for communication between ANs and between AN and hosts in the Aggregation Tree *
* Bloch et al. Scalable Hierarchical Aggregation Protocol (SHArP): A Hardware Architecture for Efficient Data Reduction Logical SHArP Tree*
Network Based Computing Laboratory MVAPICH User Group (MUG) Meeting’18 45 Evaluation of SHArP based Non Blocking Allreduce
MPI_Iallreduce Benchmark
1 PPN*, 8 Nodes 1 PPN, 8 Nodes MV AP IC H2 MVAPICH2 MVAPICH2 -SH ArP 9 2.3x 50 8 MV AP IC H2 - SHA r P 45 40 Lower is Better Lower 7 6 35 Computation Overlap (%) Overlap Computation
- 30 5 25 4 20 3 15 2 Communication 10 Higher is Better is Higher 1 5
Pure Pure Communication Latency (us) 0 0 4 8 16 32 64 12 8 4 8 16 32 64 128 Message Size (Bytes) Message Size (Bytes)
• Complete offload of Allreduce collective operation to Switch helps to have much higher overlap of communication and computation Available since MVAPICH2 2.3a *PPN: Processes Per Node Network Based Computing Laboratory MVAPICH User Group (MUG) Meeting’18 46 Collective Offload in ConnectX-2, ConnectX-3, Connect-IB and ConnectX-4, ConnectX-5
• Mellanox’s ConnectX-2, ConnectX-3, ConnectIB, ConnectX-4, and ConnectX-5 adapters feature “task-list” offload interface – Extension to existing InfiniBand APIs • Collective communication with `blocking’ feature is usually a scaling bottleneck – Matches with the need for non-blocking collective in MPI • Accordingly MPI software stacks need to be re-designed to leverage offload in a comprehensive manner • Can applications be modified to take advantage of non-blocking collectives and what will be the benefits?
Network Based Computing Laboratory MVAPICH User Group (MUG) Meeting’18 47 Collective Offload Support in ConnectX InfiniBand Adapter (Recv followed by Multi- Send)
Application • Sender creates a task-list consisting of only send and wait WQEs – One send WQE is created for each registered receiver and is Task List Send Wait Send Send Send Wait appended to the rear of a singly linked task-list – A wait WQE is added to make the ConnectX-2 HCA wait for ACK packet from the receiver InfiniBand HCA MQ Send Q MCQ
Send CQ Physical Link Data
Recv Q
Recv CQ
Network Based Computing Laboratory MVAPICH User Group (MUG) Meeting’18 48 Co-designing HPL with Core-Direct and Performance Benefits
HPL-Offload HPL-1ring HPL-Host HPL -Offlo ad HPL -1ri ng HPL -Host
HPL -Offlo ad HPL -1ri ng HPL -Host 4.5% 1. 2 90 5000 1 80 4500 70 4000 0. 8 60 3500 3000 0. 6 50 2500 0. 4 40 2000 Throughput (GFlops) Memory Consumption (%) 30 1500 0. 2 20 Normalized HPL Performance 1000 0 10 500 10 20 30 40 50 60 70 0 0 HPL Problem Size (N) as % of Total Memory 64 128 256 512 System Size (Number of Processes) Available in MVAPICH2-X HPL Performance Comparison with 512 Processes HPL-Offload consistently offers higher throughput than HPL-1ring and HPL- HPL-Offload surpasses the peak throughput of HPL-1ring with Host. Improves peak throughput by up to 4.5 % for large problem sizes significantly smaller problem sizes and run-times!
K. Kandalla, H. Subramoni, J. Vienne, S. Pai Raikar, K. Tomko, S. Sur, and D K Panda, Designing Non-blocking Broadcast with Collective Offload on InfiniBand Clusters: A Case Study with HPL, (HOTI 2011)
Network Based Computing Laboratory MVAPICH User Group (MUG) Meeting’18 49 Presentation Overview
• Job start-up • Point-to-point Inter-node Protocol • Transport Type Selection • Multi-rail • Process Mapping and Point-to-point Intra-node Protocols • Collectives
• MPI_T Support
Network Based Computing Laboratory MVAPICH User Group (MUG) Meeting’18 50 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 (MUG) Meeting’18 51 MPI_T usage semantics
Initialize MPI-T
Get #variables Performance Control Variables Variables Query Metadata
Allocate Session
Allocate Handle Allocate Handle
Read/Write/Reset Start/Stop var Read/Write var
Free Handle Free Handle
Free Session Finalize MPI-T
int MPI_T_cvar_get_info(int cvar_index, char *name, int *name_len, int *verbosity, intint MPI_T_pvar_start(MPI_T_pvar_session MPI_T_pvar_handle_alloc(MPI_T_pvar_session session, MPI_T_pvar_handle session, handle); 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 MPI_T_pvar_session_free(MPI_T_pvar_sessionMPI_T_enum MPI_T_pvar_handle *enumtype, required,handle, session,void* int buf); MPI_T_pvar_handle*provided); *session); *session); *handle); void *obj_handle,int MPI_T_pvar_handle MPI_T_cvar_get_num(intint MPI_T_finalize(void); *handle, *num_cvar); int *count); int MPI_T_pvar_reset(MPI_T_pvar_sessionchar *desc, session, int MPI_T_pvar_handle *desc_len, int *bind,handle); int *scope);
Network Based Computing Laboratory MVAPICH User Group (MUG) Meeting’18 52 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 (MUG) Meeting’18 53 Evaluating Applications with MPI-T
Communication profile (ADCIRC) Unexpected message profile (UH3D) 50 00 50 00 40 00 40 00 30 00 30 00 20 00 20 00 10 00 10 00 Max. # unexp. recvs Millions of messages 0 0 12 16 18 24 24 32 25 6 51 2 10 24 #processes #processes
Intranode Internode Communication profile (WRF) 10 0 80 • Users can gain insights into application communication 60 characteristics! 40 20 Millions of messages 0 32 64 12 8 25 6 #processes
Intranode Internode
Network Based Computing Laboratory MVAPICH User Group (MUG) Meeting’18 54 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 Available in MVAPICH2
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 (MUG) Meeting’18 55 Enhancing MPI_T Support ● Introduced support for new MPI_T based CVARs to MVAPICH2 ○ MPIR_CVAR_MAX_INLINE_MSG_SZ ■ Controls the message size up to which “inline” transmission of data is supported by MVAPICH2 ○ MPIR_CVAR_VBUF_POOL_SIZE ■ Controls the number of internal communication buffers (VBUFs) MVAPICH2 allocates initially. Also, MPIR_CVAR_VBUF_POOL_REDUCED_VALUE[1] ([2…n]) ○ MPIR_CVAR_VBUF_SECONDARY_POOL_SIZE ■ Controls the number of VBUFs MVAPICH2 allocates when there are no more free VBUFs available ○ MPIR_CVAR_IBA_EAGER_THRESHOLD ■ Controls the message size where MVAPICH2 switches from eager to rendezvous protocol for large messages ● TAU enhanced with support for setting MPI_T CVARs in a non-interactive mode for uninstrumented applications
Network Based Computing Laboratory MVAPICH User Group (MUG) Meeting’18 56 PVARs Exposed by MVAPICH2
Courtesy: The TAU Team Network Based Computing Laboratory MVAPICH User Group (MUG) Meeting’18 57 CVARs Exposed by MVAPICH2
Courtesy: The TAU Team Network Based Computing Laboratory MVAPICH User Group (MUG) Meeting’18 58 Using MVAPICH2 and TAU
● To set CVARs or read PVARs using TAU for an uninstrumented binary: % export TAU_TRACK_MPI_T_PVARS=1 % export TAU_MPI_T_CVAR_METRICS= MPIR_CVAR_VBUF_POOL_REDUCED_VALUE[1], MPIR_CVAR_IBA_EAGER_THRESHOLD % export TAU_MPI_T_CVAR_VALUES=32,64000 % export PATH=/path/to/tau/x86_64/bin:$PATH % mpirun -np 1024 tau_exec -T mvapich2,mpit ./a.out % paraprof
Courtesy: The TAU Team Network Based Computing Laboratory MVAPICH User Group (MUG) Meeting’18 59 VBUF usage without CVARs
Courtesy: The TAU Team Network Based Computing Laboratory MVAPICH User Group (MUG) Meeting’18 60 VBUF usage with CVARs
Total memory used by VBUFs is reduced from 3,313,056 to 1,815,056
Courtesy: The TAU Team Network Based Computing Laboratory MVAPICH User Group (MUG) Meeting’18 61 VBUF Memory Usage Without CVAR
Courtesy: The TAU Team Network Based Computing Laboratory MVAPICH User Group (MUG) Meeting’18 62 VBUF Memory Usage With CVAR
% export TAU_TRACK_MPI_T_PVARS=1 % export TAU_MPI_T_CVAR_METRICS=MPIR_CVAR_VBUF_POOL_SIZE % export TAU_MPI_T_CVAR_VALUES=16 % mpirun -np 1024 tau_exec -T mvapich2 ./a.out Courtesy: The TAU Team Network Based Computing Laboratory MVAPICH User Group (MUG) Meeting’18 63 MVAPICH2 Software Family
Requirements Library
MPI with IB, iWARP, Omni-Path, and RoCE MVAPICH2
MPI with IB, RoCE & GPU and Support for Deep Learning MVAPICH2-GDR
InfiniBand Network Analysis and Monitoring OSU INAM Microbenchmarks for Measuring MPI and PGAS Performance OMB
Network Based Computing Laboratory MVAPICH User Group (MUG) Meeting’18 64 GPU-Aware (CUDA-Aware) MPI Library: MVAPICH2-GPU
• Standard MPI interfaces used for unified data movement • Takes advantage of Unified Virtual Addressing (>= CUDA 4.0) • Overlaps data movement from GPU with RDMA transfers
At Sender:
MPI_Send(s_devbuf, size, …); inside MVAPICH2 At Receiver: MPI_Recv(r_devbuf, size, …);
High Performance and High Productivity
Network Based Computing Laboratory MVAPICH User Group (MUG) Meeting’18 65 CUDA-Aware MPI: MVAPICH2-GDR 1.8-2.3 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 • Unified memory
Network Based Computing Laboratory MVAPICH User Group (MUG) Meeting’18 66 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
Network Based Computing Laboratory MVAPICH User Group (MUG) Meeting’18 67 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 (MUG) Meeting’18 68 Optimized MVAPICH2-GDR Design
GPU-GPU Inter-node Latency GPU-GPU Inter-node Bi-Bandwidth 30 6000 25 5000 20 4000 15 3000 10 11X
Latency (us) Latency 10x 5 1.88us 2000
0 Bandwidth (MB/s) 1000 0 1 2 4 8 16 32 64 128 256 512 1K 2K 4K 8K 0 1 2 4 8 16 32 64 1K 2K 4K Message Size (Bytes) 12 8 25 6 51 2 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 2000 MVAPICH2-GDR-2.3a 1500 9x Intel Haswell (E5-2687W @ 3.10 GHz) node - 20 cores Bandwidth (MB/s) 1000 500 NVIDIA Volta V100 GPU 0 Mellanox Connect-X4 EDR HCA 1 2 4 8 16 32 64 128 256 512 1K 2K 4K CUDA 9.0 Mellanox OFED 4.0 with GPU-Direct-RDMA Message Size (Bytes)
MV2-(NO-GDR) MV2-GDR-2.3a
Network Based Computing Laboratory MVAPICH User Group (MUG) Meeting’18 69
69 MVAPICH2-GDR: Performance on OpenPOWER (NVLink + Pascal) INTRA-NODE LATENCY (SMALL) INTRA-NODE LATENCY (LARGE) INTRA-NODE BANDWIDTH 30 500 40 35 25 400 30 20 300 25 15 20 200 15 10 Latency (us) Latency (us) Latency 10 100 5 (GB/sec) Bandwidth 5 0 0 0 1 2 4 8 16 32 64 128 256 512 1K 2K 4K 8K 16K 32K 64K 128 K 256 K 512 K 1M 2M 4M 1 4 16 64 256 1K 4K 16K 64K 256 K 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: 14.6 us (without GPUDirectRDMA) Intra-node Bandwidth: 33.9 GB/sec (NVLINK)
INTER-NODE LATENCY (SMALL) INTER-NODE LATENCY (LARGE) INTER-NODE BANDWIDTH 29 500 14 28 450 12 27 400 350 10 26 300 25 8 250 24 6
Latency (us) Latency 200
23 (us) Latency 150 4
22 100 (GB/sec) Bandwidth 2 21 50 1 2 4 8 16 32 64 128 256 512 1K 2K 4K 8K 0 0 Message Size (Bytes) 16K 32K 64K 128 K 256 K 512 K 1M 2M 4M 1 4 16 64 256 1K 4K 16K 64K 256 K 1M 4M Message Size (Bytes) Message Size (Bytes) Inter-node Latency: 23.8 us (without GPUDirectRDMA) Available in MVAPICH2-GDR 2.3a Inter-node Bandwidth: 11.9 GB/sec (EDR) Platform: OpenPOWER (ppc64le) nodes equipped with a dual-socket CPU, 4 Pascal P100-SXM GPUs, and EDR InfiniBand Inter-connect
Network Based Computing Laboratory MVAPICH User Group (MUG) Meeting’18 70 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 (MUG) Meeting’18 71 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 (MUG) Meeting’18 72 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 (MUG) Meeting’18 73 Application-Level Evaluation (HOOMD-blue) 64K Particles 256K Particles
350 0 250 0 300 0 MV2 MV2+GDR 250 0 200 0 2X 200 0 150 0 2X 150 0 100 0 (TPS) 100 0 500 500
0 0
AverageTime Steps per second 4 8 16 32 4 8 16 32 Number of Processes Average Time Steps per second (TPS) 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 (MUG) Meeting’18 74
LENS (Oct '15) 74 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
Network Based Computing Laboratory MVAPICH User Group (MUG) Meeting’18 75 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_POLICY • How the Rails are Shared • Sharing gives the best performance bind/selected by for pipeline design processes MV2_PROCESS_TO_RAIL_MAPP • Explicit binding of the First HCA • Use this parameter to manually ING HCAs to the CPU select a different parameter only if default binding seems to perform poorly
• 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 (MUG) Meeting’18 76 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-GDR2.1 8,759 14000 MV2-GDR2.1 15,111 8000 20% MV2-GDR2.1 RC2 7000 40% 12000 MV2-GDR2.1 RC2 6000 10000 5000 8000 4000 3000 6000 Bandwidth Bandwidth (MB/s) (MB/s) Bandwidth 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.1 and MVAPICH2-GDR 2.1 RC2 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 (MUG) Meeting’18 77
LENS (Oct '15) 77 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
Network Based Computing Laboratory MVAPICH User Group (MUG) Meeting’18 78 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 (MUG) Meeting’18 79 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 (MUG) Meeting’18 80 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 (MUG) Meeting’18 81 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 based designs (Enabled) • Best performance C_CACHE • Enables one-sided semantics MV2_CUDA_IPC_BUFFE • Enable / Disable CUDA 1 • Used for subset of operations IPC_BUFFERED design (Enabled) • Backup for the IPC-Cache design RED • Uses double buffering schemes • Used for efficient Managed support
MV2_CUDA_IPC_MAX_ • Number of entries in the cache 64 • Tuned for your application • Depends on the communication patterns CACHE_ENTRIES • Increase the value for irregular applications
MV2_CUDA_IPC_STAGE • The size of the staging buffers in • Tune this value only if degradation is _BUF_SIZE the double buffering schemes observed with IPC transfers
Network Based Computing Laboratory MVAPICH User Group (MUG) Meeting’18 82 IPC-Cache Communication Enhancement
800 70000
700 60000 MV2-2.1a 600 MV2-2.1a Enhanced 50000 Enhanced 500 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 (MUG) Meeting’18 83 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
Network Based Computing Laboratory MVAPICH User Group (MUG) Meeting’18 84 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 (MUG) Meeting’18 85 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 (MUG) Meeting’18 86 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 (MUG) Meeting’18 87 Performance of Stencil3D (3D subarray)
DT TR Enhanced Stencil3D communication kernel on 2 GPUs 2.5 with various X, Y, Z dimensions using 2 MPI_Isend/Irecv 1.5 • DT: Direct Transfer, TR: Targeted Kernel 1
• Optimized design gains up to 15%, 15% and (ms)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
1.5 86% 1.5 1 1
Latency (ms)Latency 0.5 (ms)Latency 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 (MUG) Meeting’18 88 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 t t t e e e d d d r r r a a a n n n n n n i i i a a a r r r t t MPI_Isend (C,.. Datatype,…) t Progress t t t e e Kernel e Kernel Kernel i i i e e e S 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 l e e e Progress t t t e e e
a a a t n n n t t d i d K d i i K K r r r r r r t t t n F F F n n i i i a a a e e e t t t e e e n n n K K K S S S S S S I I I W *A, B…contain non-contiguous MPI Datatype W 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 (MUG) Meeting’18 89 Application-Level Evaluation (Cosmo) and Weather Forecasting in Switzerland
Wilkes GPU Cluster CSCS GPU cluster
Defa ult Callback-based Ev en t - ba sed Defa ult Callback-based Ev en t - ba sed
1. 2 1. 2 1 1 0. 8 0. 8 0. 6 0. 6 0. 4 0. 4
0. 2 Normalized Execution Time 0. 2 Normalized Execution Time 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 (MUG) Meeting’18 90 Enhanced Support for GPU Managed Memory 2D Stencil Performance for Halowidth=1 ● CUDA Managed => no memory pin down 0. 8 Device ● No IPC support for intranode communication 0. 7 Ma na ge d ● No GDR support for Internode communication 0. 6 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” Halo Exchange Time (ms) 0. 1 host memory 0 1 2 4 8 16 32 64 12 8 25 6 1K 4K 8K 16 K ● Enhance intranode managed memory to use IPC Total Dimension Size (Bytes)
● Double buffering pair-wise IPC-based scheme 10000 ● Brings IPC performance to Managed memory 9000 Enhanced 8000 ● High performance and high productivity 7000 MV2-GDR2.2b 6000 2.5X ● 2.5 X improvement in bandwidth 5000 4000 ● OMB extended to evaluate the performance of point-to-point 3000 and collective communications using managed buffers (MB/s) Bandwidth 2000 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 (MUG) Meeting’18 91 MVAPICH2 Software Family
Requirements Library
MPI with IB, iWARP, Omni-Path, and RoCE MVAPICH2
MPI with IB, RoCE & GPU and Support for Deep Learning MVAPICH2-GDR
InfiniBand Network Analysis and Monitoring OSU INAM Microbenchmarks for Measuring MPI and PGAS Performance OMB
Network Based Computing Laboratory MVAPICH User Group (MUG) Meeting’18 92 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.3 released on 03/06/18 – Enhance INAMD to query end nodes based on command line option – Add a web page to display size of the database in real-time – Enhance interaction between the web application and SLURM job launcher for increased portability – Improve packaging of web application and daemon to ease installation – Enhance web interface to improve the user experience – Improve debugging and logging support in daemon and web application • 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 (MUG) Meeting’18 93 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 (MUG) Meeting’18 94 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 • CPU utilization for each rank/node • Job level and • Process level • Bytes sent/received for MPI operations (pt-to-pt, collective, RMA) • Network metrics (e.g. XmitDiscard, RcvError) per rank/node
Network Based Computing Laboratory MVAPICH User Group (MUG) Meeting’18 95 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 (MUG) Meeting’18 96 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 – Cloverleaf – SPEC (LAMMPS, POP2, TERA_TF, WRF2) • 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 (MUG) Meeting’18 97 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% improvement in overall execution time at 200 19% 256 processes 100 • Library Version: MVAPICH2 2.2 Execution Execution Time (s) • 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 (MUG) Meeting’18 98 MiniAMR: Impact of Tuning Eager Threshold
MiniAMR • Tuning the Eager threshold has a significant 20 5 impact on application performance by avoiding the synchronization of rendezvous protocol 20 0 and thus yielding better communication 19 5 8% computation overlap 19 0 • 8% percent reduction in total communication time 18 5 • Library Version: MVAPICH2 2.2 18 0 • MVAPICH Flags used Communication Communication Time (sec) 17 5 – MV2_IBA_EAGER_THRESHOLD=32768 1K 2K 4K 8K 1M 12 8 51 2 16 K 32 K 64 K – MV2_VBUF_TOTAL_SIZE=32768 12 8K 25 6K 51 2K Eager Threshold (Bytes) Data Submitted by Karen Tomko @ OSC and Dong Ju Choi @ UCSD
Network Based Computing Laboratory MVAPICH User Group (MUG) Meeting’18 99 SMG2000: Impact of Tuning Transport Protocol
• UD-based transport protocol selection 80 Default Tuned benefits the SMG2000 application 70 22% 60 • 22% and 6% on 1,024 and 4,096 cores, 50 respectively 40 • Library Version: MVAPICH2 2.1 30 • MVAPICH Flags used
Execution Execution Time (s) 20 – MV2_USE_ONLY_UD=1 10 • System Details 0 – Stampede@ TACC 1024 2048 4096 – Sandybridge architecture with dual 8-cores Number of Processes nodes and ConnectX-3 FDR network Data Submitted by Jerome Vienne @ TACC
Network Based Computing Laboratory MVAPICH User Group (MUG) Meeting’18 100 Neuron: Impact of Tuning Transport Protocol
• UD-based transport protocol selection 140 benefits the SMG2000 application Default Tuned 120 • 15% and 27% improvement is seen for 768 and 100 1,024 processes respectively 80 • Library Version: MVAPICH2 2.2 • MVAPICH Flags used 60 27% – MV2_USE_ONLY_UD=1 40 • Input File Execution Execution Time (s) 20 – YuEtAl2012 0 • System Details 384 512 768 1024 – Comet@SDSC Number of Processes – Haswell nodes with dual 12-cores socket per node and Mellanox FDR (56 Gbps) network. Data Submitted by Mahidhar Tatineni @ SDSC
Network Based Computing Laboratory MVAPICH User Group (MUG) Meeting’18 101 HPCG: Impact of Collective Tuning for MPI+OpenMP Programming Model
1.2 • Partial subscription nature of hybrid MPI+OpenMP Def ault Tune d 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 onward 0.2 • System Details – Stampede@ TACC Normalized Execution Time 0 – 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 (MUG) Meeting’18 102 LULESH: Impact of Collective Tuning for MPI+OpenMP Programming Model
1.2 • Partial subscription nature of hybrid MPI+OpenMP Def ault Tune d programming requires a new level of collective tuning 1 – For PPN=2 (Processes Per Node), the tuned version of MPI_Reduce 4% 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 onward 0.2 • System Details – Stampede@ TACC Normalized Execution Time 0 – 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 (MUG) Meeting’18 103 MILC: Impact of User-mode Memory Registration (UMR) based tuning 70 Default Tuned • Non-contiguous data processing is very common on HPC 60 applications. MVAPICH2 offers efficient designs for MPI Datatype support using novel hardware features such as 50 UMR 40 • UMR-based protocol selection benefits the MILC application. 30 – 4% and 6% improvement in execution time at 512 and 640 20 processors, respectively • Library Version: MVAPICH2-X 2.2 Execution Execution Time (s) 10 6% • MVAPICH Flags used 0 – MV2_USE_UMR=1 • System Details 128 256 512 640 – 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 (MUG) Meeting’18 104 HOOMD-blue: Impact of GPUDirect RDMA Based Tuning 64K Particles 400 0 • HOOMD-blue is a Molecular Dynamics Default Tun ed simulation using a custom force field. 300 0 2X • GPUDirect specific features selection and 200 0 tuning significantly benefit the HOOMD-blue 100 0 application. We observe a factor of 2X
per second (TPS) second per improvement on 32 GPU nodes, with both 64K
AverageTime Steps 0 and 256K particles 4 8 16 32 Number of Processes • Library Version: MVAPICH2-GDR 2.2 256K Particles 300 0 • MVAPICH-GDR Flags used MV2 MV2+GDR – MV2_USE_CUDA=1 200 0 – MV2_USE_GPUDIRECT=1 2X – MV2_GPUDIRECT_GDRCOPY=1 100 0 • System Details per second (TPS) second per
AverageTime Steps 0 – Wilkes@Cambridge 4 8 16 32 – 128 Ivybridge nodes, each node is a dual 6- Number of Processes Data Submitted by Khaled Hamidouche @ OSU cores socket with Mellanox FDR Network Based Computing Laboratory MVAPICH User Group (MUG) Meeting’18 105 Application Scalability on Skylake and KNL with Omni-Path Cloverleaf (bm64) MPI+OpenMP, MiniFE (1300x1300x1300 ~ 910 GB) NEURON (YuEtAl2012) NUM_OMP_THREADS = 2 60 12 00 2000 50 MVA PICH2 10 00 MVA PICH2 MVA PICH2 1500 40 80 0 30 60 0 1000 20 40 0 500 10 20 0 Execution Execution Time (s) 0 0 0 20 48 40 96 81 92 48 96 19 2 38 4 76 8 48 96 19 2 38 4 76 8 15 36 30 72 No. of Processes (Skylake: 48ppn) No. of Processes (Skylake: 48ppn) No. of Processes (Skylake: 48ppn) 14 0 35 00 1500 12 0 MVA PICH2 30 00 MVA PICH2 MVA PICH2 10 0 25 00 1000 80 20 00 60 15 00 500
Execution Execution Time (s) 40 10 00 20 50 0 0 0 0 20 48 40 96 81 92 64 12 8 25 6 51 2 10 24 20 48 40 96 68 13 6 27 2 54 4 10 88 21 76 43 52 No. of Processes (KNL: 64ppn) No. of Processes (KNL: 64ppn) No. of Processes (KNL: 68ppn) Courtesy: Mahidhar Tatineni @SDSC, Dong Ju (DJ) Choi@SDSC, and Samuel Khuvis@OSC ---- Testbed: TACC Stampede2 using MVAPICH2-2.3b Runtime parameters: MV2_SMPI_LENGTH_QUEUE=524288 PSM2_MQ_RNDV_SHM_THRESH=128K PSM2_MQ_RNDV_HFI_THRESH=128K Network Based Computing Laboratory MVAPICH User Group (MUG) Meeting’18 106 Performance of SPEC MPI 2007 Benchmarks (KNL + Omni-Path)
400 6% Intel MPI 18.0.0 350 1% MVAPICH2 2.3 rc1 300
250 448 processes
200 10% on 7 KNL nodes of 2% TACC Stam pede2 6% 150 (64 ppn)
Execution Time in (S) in Time Execution 100 4% 2% 50
0 mi lc leslie3d po p2 lammps wrf2 tera_tf lu
Mvapich2 outperforms Intel MPI by up to 10%
Network Based Computing Laboratory MVAPICH User Group (MUG) Meeting’18 107 Performance of SPEC MPI 2007 Benchmarks (Skylake + Omni-Path)
120
0% 1% Intel MPI 18.0.0
100 MVAPICH2 2.3 rc1 4% 80 480 processes on 10 Skylake nodes 60 -4% of TACC Stampede2 38% (48 ppn) 40
Execution Time in (S) in Time Execution 2% -3% 20 0%
0 mi l c leslie3d pop2 lammps wrf2 GaP tera _tf lu
MVAPICH2 outperforms Intel MPI by up to 38%
Network Based Computing Laboratory MVAPICH User Group (MUG) Meeting’18 108 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 • 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 (MUG) Meeting’18 109 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 (MUG) Meeting’18 110