Travis Desell, deselt cs'rpi'edu

1
Malleable Components for Scalable High
Performance Computing
HPC-GECO 2006

• Travis Desell, deselt _at_ cs.rpi.edu
• Department of Computer Science
• Rensselaer Polytechnic Institute
• http//wcl.cs.rpi.edu/
• Kaoutar El Maghraoui, Jason LaPorte, Carlos A.
  Varela
• Paris, France
• June 19, 2006

2
Overview

• Introduction
• Current HPC Environments
• HPC Applications
• Components in HPC Environments
• Dynamic Application Reconfiguration
• Impact of Application Granularity
• Component Malleability
• Benefits of Malleability
• Types of Malleability
• Malleability Implementation

• Middleware for Autonomous Reconfiguration
• IOS
• Evaluation
• Overhead
• Malleability on Dynamic Environments
• Demo
• Conclusion Final Remarks
• Questions?

3
HPC Environment Trends
Static
Dynamic
HPC Trends

• Dynamically allocated resources
• Competing applications
• Dynamically joining/leaving processors
• Distributed/Hierarchical management

• Statically allocated resources
• Reservation scheduling
• Statically available processors
• Centralized management

4
HPC Environments

• The Rensselaer Grid
• Currently 1000 processors.
• Largest university based supercomputing system
  (upcoming CCNI grant)
• over 10,000 IBM BlueGENE processors
• Over 70 teraflops
• TeraGrid/ETF (www.teragrid.org)
• Initially was 4 geographically distributed sites
  with few users.
• Now an extensible facility with more than 150
  petabytes of storage and 102 teraflops of
  computing capability.
• iVDGL (www.ivdgl.org)
• LCG _at_ CERN (www.cern.ch)
• LHC (Large Hadron Collider) Computing Project
• Worlds Largest Computing Grid

5
Map of Rensselaer Grid Clusters
Nanotech
Multiscale
Bioscience Cluster
CS /WCL
Multipurpose Cluster
CS
CCNI Cluster
6
Extensible TeraScale Facility (ETF)
RPI
7
iVDGLInternational Virtual Data Grid Laboratory
www.ivdgl.org
8
CERN Worlds Largest Computing Grid
http//goc02.grid-support.ac.uk/googlemaps/lcg.htm
l
www.cern.ch
9
HPC Applications

• Very diverse
• Communication topologies
• Loosely/Tightly Coupled
• Farmer/Worker
• Mesh
• Data representations
• Synchrony
• Iterative/Non-Iterative

10
Twin Primes Bruns Constant

• Investigators
• P. H. Fry, J. Nesheiwat, B. Szymanski (RPI CS)
• Problem Statement
• Are there infinitely many twin primes?
• Calculating Bruns Constant (sum of inverse of
  all twin primes) to highest accuracy.
• Application Information (Twin Primes)
• Massively Parallel
• Farmer/Worker
• Non-Iterative

11
Milky Way Origin and StructureParticle Physics

• Investigators
• H. Newberg (RPI Astronomy), J. Teresco
  (Williams)
• M. Magdon-Ismail, B. Szymanski, C. Varela(RPI CS)
• J. Cummings, J. Napolitano (RPI Physics)
• Problem Statement
• How to analyze data from 10,000 square degrees of
  the north galactic cap collected in five optical
  filters over five years by the Sloan Digital Sky
  Survey?
• Do missing baryons exist? Sub-atomic particles
  that have not been observed.
• Applications/Implications
• Astrophysics origins and evolution of our
  galaxy.
• Physics particle physics, search for missing
  baryons.
• Approach
• To use photometric and spectroscopic data to
  separate and describe components of the Milky Way
• Maximum Likelihood Analysis
• Application Information (Astronomy/Physics)
• Farmer/Worker Model
• Iterative
• Loosely Coupled

12
Adaptive Partial Differential Equation Solvers

• Investigators
• J. Flaherty, M. Shephard B. Szymanski, C. Varela
  (RPI)
• J. Teresco (Williams), E. Deelman (ISI-UCI)
• Problem Statement
• How to dynamically adapt solutions to PDEs to
  account for underlying computing infrastructure?
• Applications/Implications
• Materials fabrication, biomechanics, fluid
  dynamics, aeronautical design, ecology.
• Approach
• Partition problem and dynamically map into
  computing infrastructure and balance load.
• Low communication overhead over low-latency
  connections.
• Software
• Rensselaer Partition Model (RPM)
• Algorithm Oriented Mesh Database (AOMD).
• Dynamic Resource Utilization Model) (DRUM)
• Application Information (Heat)
• Tightly coupled
• Iterative

13
Problem Statement

• How can these types applications scale and
  appropriately use resources in increasingly large
  and dynamic HPC environments?

14
Components in HPC Environments

• Reusable program building blocks
• Combine with other (possibly distributed)
  components to form an application
• Typically provide services such as
• Interface exposure and discovery
• Visible Properties
• Event handling
• Persistence
• Application builder support
• Component packaging

15
Actors as Components

• Actor Model
• A reasoning framework to model concurrent
  computations
• Programming abstractions for distributed open
  systems
• Actors as Components
• Interface exposure and discovery via Universal
  Naming.
• Define message handlers (visible properties)
• Communicate via asynchronous message passing
  (event handling)
• Application builder support and packaging
  provided by programming languages (SALSA)
• G. Agha, Actors A Model of Concurrent
  Computation in Distributed Systems. MIT Press,
  1986.

16
Dynamic Application Reconfiguration

• Migration
• Application Migration
• Moving entire applications
• Data Migration
• Moving data between components
• Component Migration
• Moving one component from one environment to
  another
• Communication needs to be redirected
• Memory (if shared) needs to be managed through
  cache coherence protocols
• Replication
• Duplicating components for QoS or fault
  tolerance.
• Communication Topology Modification
• Algorithmic Adaptation

17
Impact of Granularity on Runtime
18
Impact of Granularity on Different Machine
Architectures
19
Component Malleability

• New type of reconfiguration
• Applications can dynamically change component
  granularity
• Malleability can provide many benefits for HPC
  applications
• Can more adequately reconfigure applications in
  response to a dynamically changing environment
• Can scale application in response to dynamically
  joining resources to improve performance.
• Can provide soft fault-tolerance in response to
  dynamically leaving resources.
• Can be used to find the ideal granularity for
  different architectures.
• Easier programming of concurrent applications, as
  parallelism can be provided transparently.

20
Methodology

• How to accomplish dynamic granularity?
• Programmers define how to split and merge
  components.
• Middleware determines which components to split
  or merge, and when to perform split and merge.

21
Types of Malleability

• How can split and merge be done?
• Split 12, Merge 21
• Split 1N, Merge N1
• Split NM, Merge MN
• Split NN1, Merge N1N

22
Implementing Split/Merge

• Leveraged the SALSA programming language.
• Actor oriented programming model
• Compiled to Java
• Added language level support for malleable
  actors.
• Generic strategy used to split and merge actors
• Performed Atomically
• Allows Concurrency
• User specifies via API
• communication redirection
• data redistribution

23
Example Twin Primes Farmer

• behavior TPFarmer
• NumberSegmentGenerator nsg new
  NumberSegmentGenerator()
• void act(String args)
• numberWorkers args0
• for (int i 0 i lt numberWorkers i) new
  TPWorker(this)
• void requestWork(TPWorker t)
• if (nsg.hasMoreSegments())
• tlt-findPrimes(nsg.getNextSegment())
• void receivePrimes(Segment s)
• s.saveToDisk()

24
Example - Twin Primes Worker

• behavior TPWorker extends MalleableActor
• TPFarmer farmer
• TPWorker(TPFarmer farmer)
• this.farmer farmer
• farmerlt-requestWork(this)
• void findPrimes(Segment s)
• s.findPrimes()
• farmerlt-receivePrimes(s) _at_
• farmerlt-requestWork(this)

• boolean canSplitOrMerge()
• return true
• MalleableActor createNewActor()
• return new TPWorker(farmer)
• void handleMergeMsg(Msg m)
• if (m.name() findPrimes)
• this.process(message)

25
Middleware Implementation - IOS

• Leveraged IOS (The Internet Operating System)
• Generic middleware for distributed application
  reconfiguration.
• Works with multiple programming paradigms (MPI,
  SALSA)

26
Middleware Architecture
27
Middleware Extensions

• Extended IOS with new decision strategies to
  allow dynamic malleability along with dynamic
  migration
• Components split when new resources become
  available.
• Components merge when resources become
  unavailable.
• Malleability used to keep an even ratio of
  components to processing power available at a
  location.
• Migration used to handle load fluctuations at
  nodes.

28
Evaluation

• Overhead
• Malleability on a Dynamic Environment

29
Evaluation Overhead (Astronomy)
30
Evaluation Dynamic Environment (Heat)
8
12
16
15
Processors
10
8
13 Speedup
6 Speedup
15 Speedup
31

• DEMO

32
Conclusion

• Malleability Implementation
• Easy to use
• Minimal overhead
• Middleware masks profiling, decision making
• Allows applications to be deployed on a wide
  range of environments
• Malleability Benefits
• Transparent Parallelism
• Unbounded Scalability
• Soft fault tolerance
• Scalability and data redistribution for improved
  performance
• Architecture-aware granularity

33
Final Remarks

• Thanks!
• Visit our web pages
• SALSA http//wcl.cs.rpi.edu/salsa/
• IOS http//wcl.cs.rpi.edu/ios/
• OverView http//wcl.cs.rpi.edu/overview/
• Questions?