1 Scaling Molecular Dynamics to 3000 Processors with Projections: A Performance Analysis Case Study Laxmikant Kale Gengbin Zheng Sameer Kumar Chee Wai Lee Parallel Programming Laboratory Dept. of Computer Science University of Illinois at Urbana Champaign

2 Motivation Performance optimization is increasingly challenging –Modern applications are complex and dynamic –Some may involve small amount of computation per step –Performance issues and obstacles change: As the number of processors change –Performance tuning on small machines isn’t enough Need very good Performance Analysis tools –Feedback at the level of applications –Analysis capabilities –Scalable views –Automatic instrucmentation

3 Projections Many performance analysis systems exist –And are very useful in their own way –Paragraph, Upshot, Pablo,.. The system we present is “Projections” –Designed for message-driven programs –Has some unique benefits compared with others The next few slides Outline: –Processor virtualization and message-driven execution –Projections: trace generation –Projections: views –Case Study: NAMD, Molecular Dynamics program that won a Gordon Bell award at SC’02 by scaling MD for biomolecules to 3,000 procs

4 Virtualization: Object-based Parallelization User View System implementation User is only concerned with interaction between objects

5 Data driven execution Scheduler Message Q

6 Charm++ and Adaptive MPI Realizations of Virtualization Approach Charm++ Parallel C++ –Asynchronous methods In development for over a decade Basis of several parallel applications Runs on all popular parallel machines and clusters AMPI A migration path for MPI codes –Allows them dynamic load balancing capabilities of Charm++ Minimal modifications to convert existing MPI programs Bindings for –C, C++, and Fortran90 Both available from

7 Benefits of Virtualization Software Engineering –Number of virtual processors can be independently controlled –Separate VPs for modules Message Driven Execution –Adaptive overlap –Modularity –Predictability: Automatic Out-of-core Dynamic mapping –Heterogeneous clusters: Vacate, adjust to speed, share –Automatic checkpointing –Change the set of processors Principle of Persistence: –Enables Runtime Optimizations –Automatic Dynamic Load Balancing –Communication Optimizations –Other Runtime Optimizations More info:

8 Measurement Based Load Balancing Principle of persistence –Object communication patterns and computational loads tend to persist over time –In spite of dynamic behavior Abrupt but infrequent changes Slow and small changes Runtime instrumentation –Measures communication volume and computation time Measurement based load balancers –Use the instrumented data-base periodically to make new decisions

9 Trace Generation Automatic instrumentation by runtime system Detailed Summary

10 Post mortem analysis: views Utilization Graph –As a function of time interval or processor –Shows processor utilization –As well as: time spent on specific parallel methods Timeline: –upshot-like, but more details –Pop-up views of method execution, message arrows, user- level events Profile: stacked graphs: –For a given period, breakdown of the time on each processor Includes idle time, and message-sending, receiving times

11 Prtojections Views: continued Animation of utilization Histogram of method execution times –How many method-execution instances had a time of 0-1 ms? 1-2 ms?.. Performance counters: –Associated with each entry method –Usual counters, interface to PAPI

12 Case Study: NAMD We illustrate the use of Projections –Using a case study –Illustrate different “views” –Show performance debugging methodology

13 NAMD: A Production MD program NAMD Fully featured program NIH-funded development Distributed free of charge (~5000 downloads so far) Binaries and source code Installed at NSF centers User training and support Large published simulations (e.g., aquaporin simulation featured in SC’02 keynote)

14 NAMD, CHARMM27, PME NpT ensemble at 310 or 298 K 1ns equilibration, 4ns production Protein:~ 15,000 atoms Lipids (POPE):~ 40,000 atoms Water:~ 51,000 atoms Total:~ 106,000 atoms 3.5 days / ns O2000 CPUs 11 days / ns - 32 Linux CPUs.35 days/ns–512 LeMieux CPUs Acquaporin Simulation F. Zhu, E.T., K. Schulten, FEBS Lett. 504, 212 (2001) M. Jensen, E.T., K. Schulten, Structure 9, 1083 (2001)

15 Molecular Dynamics in NAMD Collection of [charged] atoms, with bonds –Newtonian mechanics –Thousands of atoms (10, ,000) At each time-step –Calculate forces on each atom Bonds: Non-bonded: electrostatic and van der Waal’s –Short-distance: every timestep –Long-distance: using PME (3D FFT) –Multiple Time Stepping : PME every 4 timesteps –Calculate velocities and advance positions Challenge: femtosecond time-step, millions needed! Collaboration with K. Schulten, R. Skeel, and coworkers

16 Sizes of Simulations Over Time BPTI 3K atoms Estrogen Receptor 36K atoms (1996) ATP Synthase 327K atoms (2001)

17 F 1 F 0 ATP-Synthase (ATP-ase) CConverts the electrochemical energy of the proton gradient into the mechanical energy of the central stalk rotation, driving ATP synthesis (  G = 7.7 kcal/mol). 327,000 atoms total, 51,000 atoms -- protein and nucletoide 276,000 atoms -- water and ions The Benchmark

18 Traditional Approaches: non isoefficient Replicated Data: –All atom coordinates stored on each processor Communication/Computation ratio: P log P Partition the Atoms array across processors –Nearby atoms may not be on the same processor –C/C ratio: O(P) Distribute force matrix to processors –Matrix is sparse, non uniform, – C/C Ratio: sqrt(P)

19 Spatial Decomposition Via Charm Atoms distributed to cubes based on their location Size of each cube : Just a bit larger than cut-off radius Communicate only with neighbors Work: for each pair of nbr objects C/C ratio: O(1) However: Load Imbalance Limited Parallelism Cells, Cubes or“Patches” Charm++ is useful to handle this

20 Object Based Parallelization for MD: Force Decomposition + Spatial Decomposition Now, we have many objects to load balance: –Each diamond can be assigned to any proc. – Number of diamonds (3D): –14·Number of Patches

21 Bond Forces Multiple types of forces: –Bonds(2), Angles(3), Dihedrals (4),.. –Luckily, each involves atoms in neighboring patches only Straightforward implementation: –Send message to all neighbors, –receive forces from them –26*2 messages per patch! Instead, we do: –Send to (7) upstream nbrs –Each force calculated at one patch B CA

VPs NAMD Parallelization using Charm++ These 30,000+ Virtual Processors (VPs) are mapped to real processors by charm runtime system 9,800 VPs

23 Adding PME PME involves: –A grid of modest size (e.g. 192x144x144) –Need to distribute charge from patches to grids –3D FFT over the grid Strategy: –Use a smaller subset (non-dedicated) of processors for PME –Overlap PME with cutoff computation –Use individual processors for both PME and cutoff computations –Multiple timestepping

VPs VP s 30,000 VPs NAMD Parallelization using Charm++ : PME These 30,000+ Virtual Processors (VPs) are mapped to real processors by charm runtime system

25 Some Challenges Here, we will focus on cut-off only (no PME ) simulation –For simplicity of presentation of performance issues New parallel machine with faster processors –PSC Lemieux –1 processor performance: 57 seconds on ASCI red to 7.08 seconds on Lemieux –Makes is harder to parallelize: E.g. larger communication-to-computation ratio Each timestep is few milliseconds on 1000’s of processors

26 Overview of Performance Optimizations List the optimizations we are going to show …. Next few slides should include the projections pictures from the papers and associated stories in the text…. Use the slides after the “summary” as needed.

27 Summary and Conclusion Processor virtualization –A useful technique for complex applications –Charm++ and AMPI embody this –Can be downloaded at Projections: –Performance analysis tool especially suited for processor virtualization NAMD performance was optimized to scale to 3000 processors using projections Future: –Further automation of analysis –On-demand displays (via a query-and-display language)

28 Grainsize and Amdahls’s law A variant of Amdahl’s law, for objects: –The fastest time can be no shorter than the time for the biggest single object! –Lesson from previous efforts Splitting computation objects: –30,000 nonbonded compute objects –Instead of approx 10,000

29 Mode: 700 us Distribution of execution times of non-bonded force computation objects (over 24 steps)

30 Periodic Load Balancing Strategies Centralized strategy: –Charm RTS collects data (on one processor) about: Computational Load and Communication for each pair –Partition the graph of objects across processors Take communication into account –Pt-to-pt, as well as multicast over a subset –As you map an object, add to the load on both sending and receiving processor The red communication is free, if it is a multicast.

31 Load Balancing Steps Regular Timesteps Instrumented Timesteps Detailed, aggressive Load Balancing Refinement Load Balancing

32 Another New Challenge Jitter due small variations –On 2k processors or more –Each timestep, ideally, will be about msec for ATPase –Within that time: each processor sends and receives : Approximately messages of 4-6 KB each –Communication layer and/or OS has small “hiccups” No problem until 512 processors Small rare hiccups can lead to large performance impact –When timestep is small (10-20 msec), AND –Large number of processors are used

33 Benefits of Avoiding Barrier Problem with barriers: –Not the direct cost of the operation itself as much –But it prevents the program from adjusting to small variations E.g. K phases, separated by barriers (or scalar reductions) Load is effectively balanced. But, –In each phase, there may be slight non-determistic load imbalance –Let Li,j be the load on I’th processor in j’th phase. In NAMD, using Charm++’s message-driven execution: –The energy reductions were made asynchronous –No other global barriers are used in cut-off simulations With barrier:Without:

milliseconds

35 Substep Dynamic Load Adjustments Load balancer tells each processor its expected (predicted) load for each timestep Each processor monitors its execution time for each timestep –after executing each force-computation object If it has taken well beyond its allocated time: –Infers that it has encountered a “stretch” –Sends a fraction of its work in the next 2-3 steps to other processors Randomly selected from among the least loaded processors migrate Compute(s) away in this step

36 Performance: NAMD on Lemieux ATPase: 320,000+ atoms including water

milliseconds

38 Using all 4 processors on each Node 300 milliseconds