1. Center for High Performance Software
VGrADS Programming Tools Research:
Vision and Overview
Ken Kennedy
Center for High Performance Software
Rice University

2. Programming Tools Contributors
Rice University
Ken Kennedy, PI
Keith Cooper, Chuck Koelbel (co-PIs)
Rob Fowler, Mark Mazina, John Mellor-Crummey, Tim Harvey (faculty/staff)
Raj Bandyopadhyay, Adam Bordelon, Jason Eckhardt, Anshuman Das Gupta, Anirban Mandal, Gabriel Marin, Ryan Zhang (students)
University of Houston
Lennart Johnson, co-PI
Nils Smeds (staff)
Bo Liu, Mitul Patel (students)
University of California San Diego
Fran Berman, Henri Casanova, Andrew Chien (co-PIs)
Yang-Suk Kee, Ken Yocum (staff)
Jerry Chou, Richard Huang, Dennis Logothetis (students)
University of California Santa Barbara
Rich Wolski (co-PI)
Graziano Obertelli (staff)
Dan Nurmi (student)
University of North Carolina
Dan Reed (co-PI)
Lavayna Ramakrishnan (staff)
Emma Buneci, Min Lim (students)
University of Tennessee
Jack Dongarra (co-PI)
Asim YarKhan (staff)
Zhiao Shi (student)
University of Southern California
Carl Kesselman (co-PI)
Ewa Deelman, Gurang Mehta (staff)
Gurmeet Singh (student)
Note : Baylor College of Medicine collaborators not included

3. Programming Tools
Focus: Automating critical application-development steps:
Initiating and managing application execution
Optimize and launch application on heterogeneous resources
Support for fault tolerance and rescheduling/migration
Scheduling application workflows
Whole-workflow scheduling using performance models
Constructing performance models
Automatically from application binaries
Cross-platform modeling
Building workflow graphs from high-level scripts
Examples: Python (EMAN), OGRE (LEAD), Matlab
Again, very standard
Things to emphasize are the plans for tools
Much research to be done in tools for workflow
Basing much of the work on component programming paradigm (nodes in the workflow)
Major researhc questions:
Scheduling under uncertainty (fault tolerance, limited information from abstractions)
How much can we automate? When we can’t automate, what do we present to the programmer (e.g. if we can’t do app-level fault tolerance, can we at least present component-level reliability? Will programmers know what to do with it if they see this info?)

4. Managing Application Execution
Vision: Transparent to the User with Fault Tolerance
Binaries shipped or preinstalled
Reconfigured where necessary
Data moved to computations
Support for fault tolerance
Support for rescheduling, migration and restart
Research
Separation of concerns between workflow management and virtual grid
Support for fault tolerance and rescheduling/migration
Checkpointing, load projection, performance modeling
Platform-independent application representation

5. Application Initiation and Management
Abstract Workflow
Workflow Scheduler
Virtual Grid
Pegasus
Data
Discovery
Workflow
Reduction
Resource
Discovery
Mapping
Concrete Workflow
DAGMan
Virtual Grid Execution System
Virtual Grid Resources

6. Support for Fault Tolerance and Rescheduling
Workflows: Recovery via Pegasus mechanisms
Issue: support for registration of completed steps in vgES
MPI steps: Disk-free checkpointing
Dongarra talk
Checkpoint scheduling (Nurmi poster )
Rescheduling
Mechanisms for monitoring and extending virtual grids in vgES
Under development (Huang poster )
Issue: Determining whether rescheduling will be profitable
Models to project performance on current and alternative resources
 “Optimal Checkpoint Scheduling using Automatic Resource Characterization” by Dan Nurmi (UCSB)
 “Scheduling Compute Intensive Applications in Volatile, Shared Resource (Grid) Environments” by Richard Huang (UCSD)

7. Platform-Independent Applications
Supporting a Single Application Image for Different Platforms
Translation and optimization tools that map the application onto the hardware in an effective and efficient way
At the high level, resource allocation and scheduling
At the low level, optimization, scheduling, and runtime reoptimization
We are working with the LLVM system (from Illinois)
Produces good code for a variety of hardware platforms
Run-time Reoptimization
The Idea: In response to poor performance, reoptimize
The Vision: To reduce the runtime cost of reoptimization, move analysis and planning to compile time
Example: alternative blocking strategies for a loop nest, with shift triggered by excessive cache misses

8. Scheduling Workflows Vision: Research
Application includes performance models for all workflow nodes
Performance models automatically constructed
Software schedules applications onto Grid in two phases
Virtual grid requirement and acquisition
Model based scheduling on the returned vGrid
Research
Scheduling strategy: Whole workflow
Dramatic makespan reduction (see Mandal-Liu poster )
Two-phase scheduling
Exploring trade-offs
Expectation: dramatic reduction in complexity with little loss in performance
“Performance Model-Based Scheduling of EMAN Workflows” by Anirban Mandal (Rice) and Bo Liu (U Houston)

9. Workflow Scheduling Results
Dramatic makespan reduction of offline scheduling over online scheduling — Application: Montage
Value of performance models and heuristics for offline scheduling — Application: EMAN
”Scheduling Strategies for Mapping Application Workflows onto the Grid”
HPDC’05
”Resource Allocation Strategies for Workflows in Grids”
CCGrid’05

10. Performance Model Construction
Vision: Automatic performance modeling
From binary for a single resource and execution profiles
Generate a distinct model for each target resource
Research
Uniprocessor modeling
Can be extended to parallel MPI steps
Memory hierarchy behavior
Models for instruction mix
Application-specific models
Scheduling
Posters:
“Performance Model-Based Scheduling of EMAN Workflows” by Anirban Mandal (Rice) and Bo Liu (U Houston)
“Scalable Cross-Architecture Predictions of Memory Latency for Scientific Applications” by Gabriel Marin (Rice)

11. Performance Prediction Overview
Object Code
Dynamic Analysis
Binary Instrumenter
Instrumented Code
Execute
Binary Analyzer
Communication Volume & Frequency
Memory Reuse Distance
BB Counts
Our approach aims at building parameterized models of black-box applications in a semi-automatic way, in terms of architecture-neutral Application Signatures. We build models using information from both static and dynamic analysis of an application’s binary. We use static analysis to construct the control flow graph of each routine in an application and to look at the instruction mix inside the most frequently executed loops.
We use dynamic analysis to collect data about the execution frequency of basic blocks, information about synchronization among processes and reuse distance of memory accesses.
By looking at application binaries instead of source code, we are able to build language-independent tools and we can naturally analyze applications that have modules written in different languages or are linked with third party libraries. By analyzing binaries, the tool can also be useful to both application writers and to compiler developers by enabling them to validate the effectiveness of their optimizations.
Control flow graph
Loop nesting structure
BB instruction mix
Post Processing Tool
Performance Prediction for Target Architecture
Static Analysis
Architecture neutral model
Scheduler
Architecture Description
Post Processing

12. Modeling Memory Reuse Distance
- it is a histogram for a single program reference
- explain what you mean by normalized frequency
- explain that you are showing measured data then the model.
- it shows surprisingly complex behavior
- at least three qualitatively different types of behavior
- constant
- slowly growing (likely linear)
- likely quadratic behavior

13. Execution Behavior: NAS LU 2D 3.0

14. Building Workflow Graphs
Vision:
Application developer writes in scripting language
Examples: Python (EMAN), OGRE (LEAD), Matlab, S-PLUS/R
Components represent applications
Software constructs workflow and data movement
Research
Related project: Telescoping languages
Compilation of Matlab and R
Type analysis
Pre-optimization of components for different contexts
Plan: Harvest this work for Grid application development
Just getting started

15. Summary Making Grid Applications Easy to Develop
Abstract interfaces (e.g., scripts)
Effective (and easy) application scheduling
Automatic performance model construction
Building on Virtual Grid Abstraction
Easy application launch, monitoring, and management
Driven by Real Application Needs
Initial foci: EMAN, LEAD, and Montage