University of Illinois Department of Computer Science
Performance Modeling
and Contracts
Ruth
Aydt Dan Reed
Celso Mendes
Fredrik Vraalsen
Pablo Research Group
Department of Computer Science
University
of Illinois
{aydt,reed,cmendes,vraalsen}@cs.uiuc.edu
http://www-pablo.cs.uiuc.edu
Making the Real-time
Performance Monitor a Reality
Whole-
Program
Compiler
Libraries
Dynamic
Optimizer
Real-time
Performance
Monitor
Performance
Problem
Service
Negotiator
Scheduler
Grid
Runtime
System
Source
Appli-
cation
Config-
urable
Object
Program
Software
Components
Performance
Feedback
Negotiation
Program Preparation
System
Execution
Environment
GrADS Project
Requirements
GrADS Project
Sources of Performance
Models
Compile time analysis of code Rice team - Keith Use compiler understanding of code behavior to build performance predictions
Historical data from previous runs or observed behavior of current execution 00o far00Pablo group 00earn00 from past experience Application Signature Model is one example
GrADS Project
Contract Specification
the application will
achieve a specified, measurable performance (sustain F flops/second, render R frames/second, complete iteration i in T seconds, 00 predicted by modelGrADS Project
Real-time Performance
Monitor
of the
breach of contract in determining when to report a violation
GrADS Project
00unable00Tolerance
Approach:
Use Autopilot decision procedures that are based on fuzzy logic to deal with uncertainty These support intuitive reasoning about degrees of violation 00f FLOP rate has been low for a long time the contract is violated00 what constitutes low, long, and violated can be adjusted to express different levels of uncertainty and tolerance can also set threshold on 00ow bad it must be violated00before it is actually reported many knobs to turn! Violation transitions are smooth rather than discrete as they are with decision tablesGrADS Project
Model predicts duration for each iteration An Autopilot Sensor inserted in application reports iteration number and actual duration Contract Monitor computes ratio of actual to predicted time; ratio passed to decision procedure Fuzzy rules specify contract output based on ratiovar timeRatio ( 0, 10 ) {
set trapez LOW ( 0, 1, 0, 1 );
set trapez HIGH (
2, 10, 1, 0 ); };
var contract ( -1, 2 ) {
set triangle OK ( 1, 1, 1 );
set triangle VIOLATED
( 0, 1, 1 ); };
if ( timeRatio == LOW ) { contract = OK; }
if ( timeRatio == HIGH) { contract = VIOLATED; }
ScaLAPACK Developer Model
0
1
0
2
4
6
8
10
LOW
HIGH
GrADS Project
Contract Monitoring Architecture
Contract
Monitor
register
sensor
register
sensor
locate
sensors
Resources,
Capabilities,
Program
Parameters,
Performance
Model,
Violation Policy
NWS
MDS
PPS &
Scheduler
Archive
Feedback
sensor
data
sensor
data
GrADS Project
Autopilot
Manager
application
process 0
application
process 1
N-dimensional metric space one trajectory per task correlated for data parallel codes
Application Signature
Model
GrADS Project
System Space Metrics description of resource response to application demands sample metrics FLOPS/second, I/O bytes/second, message bytes/second values are dependent on execution platform quantify actual performance System Space Signature trajectory of values throughN-dimensional metric space will vary across application
executions, even on the same
resources
System Space Signature
GrADS Project
Performance Prediction
Strategy
GrADS Project
Single Figure of Merit
Projection
Application
Intrinsic
Projection
Factor
System
Specific
Metric A
Metric B
Metric 1
Metric 2
Projection
Appliation
Space
System
Space
Instructions
FLOPS
FLOPS
Second
Instructions
Second
X
X
=
Messages
Byte
Bytes
Second
Messages
Second
=
A
B
2
1
GrADS Project
ScaLAPACK Application
Signature
of execution 00one point per iteration
GrADS Project
Projected Behavior (3
resource sets)
major
opus
major
& torc
GrADS Project
Cluster the (projected) system space points centroids define nominal predicted behavior radii define 00olerable range00of values Compare actual performance to cluster predictions If 00ar00 from cluster, report violationvar distanceFromCentroid ( 0, 100 ) {
set trapez SHORT ( 0, .3, 0, .3 );
set trapez LONG ( .6,
100, .3, 0 ); };
var contract ( -1, 2 ) {
set triangle OK ( 1, 1, 1 );
set triangle VIOLATED
( 0, 1, 1 ); };
if ( distanceFromCentroid == SHORT ) { contract = OK; }
if ( distanceFromCentroid == LONG) { contract = VIOLATED; }
Contract Implementation
GrADS Project
Experimental Verification
of Approach
ScaLAPACK Periodic Application Signature Model
Application-Intrinsic metrics captured every 60 seconds using PAPI, MPI wrappers, Autopilot Sensors Projections based on historical data Run on 3 clusters at UIUC; used 4 machines from each cluster; machine speeds vary across clusters Introduced CPU load on one machine Contract Monitor detects violationGrADS Project
Projected & Actual
Comparison:
Green 002X std deviation;
Red: 4X std deviation
Promising!
GrADS Project
Load on P3: Predicted
& Measured
GrADS Project
P3 Contract Monitor Output
GrADS Project
Load on P3: Impact on
All Processes
GrADS Project
Contract Results P0,
P11
violation
GrADS Project
Master/Worker Experiments
Results shown Application-Intrinsic metrics captured every 30 seconds Projections based on historical data from baseline execution Execute in WAN (UIUC, UCSD, UTK) Load introduced and then removed Contract monitor detects violation
MicroGrid will allow us to more easily conduct controlled experiments. Difficult on 00ive00MacroGrid resources.
GrADS Project
Projected Performance
master
slow
medium
fast
GrADS Project
Contract detects severe dip in P3 FLOP Rate Ignores small drop in P5 FLOP Rate and earlier drop in P3
Measured FLOP Rate over
Time
GrADS Project
Contract Output; load
on P3
P0 00Master
P5 00Worker
P300Worker
GrADS Project
Where we are; Where we00e
going
(Charng-da Lu)
GrADS Project
Monitoring Progress:
Are we meeting our Commitments?
Year 1:
creation of initial performance models completed gain insight into performance of existing algorithms and libraries many insights from ScaLAPACK that are guiding what is possible to predict/detect overall specify interfaces for defining and validating performance contracts initial interfaces defined; continue to refine as we learn more about what is required to support wider range of contracts specify form and semantics of performance reporting mechanisms complete from application to contract monitor; feedback from monitor to PSE and Scheduler not done.Year 2:
real-time, wide-area performance measurement tools completed sophisticated application performances models that relate performance contracts to runtime behavior in progressGrADS Project
