Resource Analysis - Technische Universität Münchenseidl/espass/garcia.pdfResource Usage Analysis...

Resource Analysis

P. López-García2,3 M. Hermenegildo1,2 E. Mera4 J. Navas5

M. Méndez6 M. Carro1 T. Trigo1

1Technical University of Madrid – UPM, Spain2IMDEA Software, Spain

3CSIC, Spain4Complutense University of Madrid – UCM, Spain

5National University of Singapore, Republic of Singapore6University Texas at Austin – TX, USA

ES_PASS Workshop: Frontiers of Abstract Interpretation 2009Toulouse, France – Feb. 05, 2009

López, Hermenegildo, Mera, Navas, et al. () Resource Analysis ES_PASS Workshop 1 / 25

Introduction Objectives

Objectives

Build an analyzer which allows automatically inferring both upper andlower bounds on the usage that a program makes of a very generalnotion of user-definable resources.

General, flexible enough to support large class of resources:Memory, execution time, execution steps.Bits sent or received by an application over a socket.Number of SMSs sent or received, money spent.Number of files left open.Number of accesses to a database.Number of calls to a procedure.Data sizes.Energy consumption.. . .

Bounds that are safe and also as accurate as possible.Modular.


Introduction The CiaoPP Preprocessor

The CiaoPP PreprocessorError detection, verification and source-to-source transformations:

Input: program (optionally w/assertions) and libraries (interfaces).Output: error/warning messages + transformed program.

Underlying technology:Modular polyvariant abstract interpretation.Modular abstract multiple specialization.

Integrated in development environments (emacs, eclipse).


Introduction CiaoPP Language Support

CiaoPP language support

Support for several languages via intermediate representation(IR).IR is based on “blocks” (each block represented as a Horn clause).

Current analyzable programming languagesJava:

Java source.Java bytecode.

Sub-languages of the Ciao multi-paradigm language:Logic programs (ISO-Prolog).Functional programs (including HO, etc.).Constraint-based programs.



Pipeline of Data Formats for Java Bytecode

Transformation

soot + Ciao

transform.

Analysis

Nullity

Resource Usage

Fixpointalgorithm

(AI−based)

CHA Analysis

Java bytecodeIR



Example of Block Structure

Internal representation: basic block→ Horn clause.

Vector.dyn_append(this,r3,ret)

Vector.append(this,r1,ret)

Builtin.gtf(this,first,r2)

Vector.append_1_2(this,r1,r2,r3,r4,r5,ret)

Vector.append_1_2(this,r1,r2,r3,r4,r5,ret) Vector.append_1_2(this,r1,r2,r3,r4,r5,ret)

Builtin.ne(r2,null)Builtin.gtf(r2,next,r4)Vector.append_3_4(this,r1,r2,r3,r4,r5,ret)

Builtin.eq(r2,null)Builtin.gtf(r1,first,r3)Builtin.stf(r3,first,this)


Builtin.eq(r4,null)Builtin.gtf(r1,first,r5)

Builtin.stf(r5,next,r2)


Builtin.ne(r4,null)Builtin.gtf(r2,next,r2’)

Vector.append_1_2(this,r1,r2’,r3,r4,r5,ret)

Vector.add(this,i0,ret)

Element.new(r1)Element.init(r1,_)Builtin.asg(r1,r2)Builtin.stf(i0,value,r2)Vector.new(r4)Vector.init(r4,_)Builtin.asg(r4,r3)Builtin.stf(r2,first,r3)



SubVector.append(this,r1,ret)

SubVector.append(this,r3,ret)Builtin.iof(this,[SubVector])

Vector.append(this,r3,ret)Builtin.iof(this,[Vector])

...


Resource Usage Analysis Overview of the Approach

Overview of the ApproachInference of upper and lower bounds on argument sizes andprocedure cost (based on the approach by Debray et al.):

1 Perform class hierarchy analysis (CHA) and I/O mode inference,infer size measures.

2 Use data dependency graphs to determine the relative sizes ofvariable contents at different program points.

3 Set up recurrence equations representing the size of each outputargument as a function of the input data sizes.

4 Compute lower/upper bounds to the solutions of these recurrenceequations to obtain bounds on output argument sizes.

5 Use the size information to set up recurrence equationsrepresenting the computational cost of procedures and computelower/upper bounds to their solutions to obtain resource usage.


Resource Usage Analysis Overview of the Approach

User-definable / Generic:A cost model describes an upper/lower bound cost of eachprimitive operation (e.g., bytecode instruction).Such cost models can be:

Provided by the user, via a language of assertions.Some predefined in system libraries.

For platform-dependent resources such as execution time orenergy consumption model needs to consider low level factors.


Resource Usage Analysis Java Example

Generic Framework and Application

Intermediate

Representation

Resource

Usage

Analysis

Java bytecode

Data

Dependency

Analysis

Size

Analysis

Size

Rel. Equations

Solver

Recurrence

Upper−boundUpper−bound

Size Rel.




Intermediate

Representation

Resource

Usage

Analysis

Data

Dependency

Analysis

Size

Analysis

Size

Rel. Equations

Upper−bound

Size Rel.Solver

Recurrence

Upper−bound

Java bytecode

Energy ConsumptionModel




Intermediate

Representation

Resource

Usage

Analysis

Energy ConsumptionModel

Data

Dependency

Analysis

Size

Analysis

Size

Rel. Equations

Upper−bound

Size Rel.Solver

Recurrence

Upper−bound

Java bytecode

Upper−bound

Energy cons.

Energy Cons.

Equations



Example: Java Program

import java . lang . Stream ;public class SensorNet {

public S t r i n g B u f f e r co l l ec tDa ta ( Sensor sensors [ ] ) {i n t i ;i n t n= sensors . leng th ;S t r i n g B u f f e r buf = new S t r i n g B u f f e r ( ) ;for ( i =n ; i > 0 ; i −−){

S t r i n g data = sensors [ i ] . read ( ) ;buf . append ( data ) ;

}return buf ; }

in ter face Sensor { S t r i n g read ( ) ; }class TempSensor implements Sensor {

@Cost ( " 10∗ s ize ( r e t ) " )public native S t r i n g read ( ) ; }

class SeismicSensor implements Sensor {@Cost ( " 20∗ s ize ( r e t ) " )public native S t r i n g read ( ) ; }

}



Example: Upper-bound Inference of EnergyConsumption

1 Inference of size relationship equations:

Sret (sthis, si , ssensors) ≤{

1 if si = 0sdata + Sret (sthis, si − 1, ssensors) if si > 0

2 Solving size relationship equations:

Sret (sthis, si , ssensors) ≤ sdata × si

3 Inference of energy consumption equations:

EcollectData(sthis, si , ssensors) ≤

241 if si = 020× sdata + 487 + if si > 0EcollectData(sthis, si − 1, ssensors)

4 Solving energy consumption equations:

EcollectData(sthis, si , ssensors) ≤ (20× sdata × si ) + (487× si ) + 241


Resource Usage Analysis Estimating Execution Times

Interesting Resource: Execution Time

Our first proposal for estimating execution times:

Model cost at abstract machine instruction level.

Take into account the inherently variable cost of certain low-leveloperations.

Admittedly difficult in current architectures, e.g., worst-case cachebehavior [Wilhelm et al].

Certainly useful for “simple” processors (caches), or situations werecaches are turned off.Better results if we feed the analysis with more precise cost modelsof the underlying execution platform:

Complementary to accurate WCET models, which consider cachebehavior, pipeline state, etc.



Estimating Execution Times: Intuition (I)

One-Time Profiling Phase (Automatic. Done for each Processor/O.S.)

Measure execution time of each instruction of the lower-level(bytecode) language LB.Result of the profiling:

A function t(I) (the timing model),which takes a bytecode instruction I and returns another functionwhich estimates the execution time for it depending on the inputdata sizes of the bytecode.

Make information regarding instruction execution time available tostatic analyzer (using cost assertions).



Estimating Execution Times: Intuition (II)

Static (Compile-Time) Cost Analysis Phase (Automatic)Given a program P written in source/IR language LIR, compile itinto LB and record relationship between P and its compiledcounterpart.The result of compiling a block C of the form H :- L1, . . . ,Lm isexpressed as a function:

E(C) =< I1, I2, . . . , Ip >

E(C) = E(C,H)⊎

(m⊎

i=1

E(C,Li))

Analyze program P, using the instruction execution timedetermined in the profiling phase, to infer a function which returns(bounds on) the execution time of P for given input data sizes.


Resource Usage Analysis Resource Usage Equations

Resource Usage Equations for Procedures/Methods

Consider a procedure/method p defined by blocks C1, . . . ,Cm.Then, the resource usage:

for a call to p,expressed in units of resource r ,with approximation ap (upper/lower bounds),for input parameters of size n (a vector representing the sizes ofinput parameters) is:

RUpro(p,ap, r ,n) =⊙

(ap)1≤i≤m{RUblock(Ci ,p,ap, r ,n)}

where⊙

(ap) is a function that takes an approximation identifierap and returns a function which applies over allRUblock(Ci ,p,ap, r ,n).



General equation

RUpro(p,ap, r ,n) =⊙

(ap)1≤i≤m{RUblock(Ci ,p,ap, r ,n)}

Particular case: Upper bound on execution time

RUpro(p,ub,ex ,n) =∑

1≤i≤m

{RUblock(Ci ,p,ub,ex ,n)}

ap = ub (upper bound)r = ex (execution time)⊙

(ub) =∑

For mutually exclusive blocks (using type based analysis)

RUpro(p,ub,ex ,n) = max1≤i≤m

{RUblock(Ci ,p,ub,ex ,n)}



Resource Usage Equations for BlocksConsider now a block C ≡ ‘H :− L1, . . . ,Lk ’. Then, the resourceusage of block C of procedure p isRUblock(C,ap, r ,n) = closed_form(RU(p,ap, r ,n)) where:

RU(p,ap, r ,n) = δ(ap, r)(H,n) +lim(ap,C)∑

i=1(∏j≺i

SolsLj (ψj(n)))(β(ap, r)(Li , ψi(n)) + RUstm(Li ,ap, r , ψi(n)))

ψi(n) (resp. ψj(n)) represents the sizes of the input arguments toLi (resp. Lj ).SolsLj (ψj(n)) is the number of solutions statement Lj cangenerate.∏j≺i

SolsLj (ψj(n)) is the number of times the statement Li will be

executed (it depends on the number of solutions of the previousstatements, because of alternative paths).





i=1(∏j≺i


δ(ap,r)(H,n) is the resource usage of block head (e.g., parameterpassing).δ(ap, r) is a function that takes an approximation identifier ap anda resource identifier r and returns a function

∆H : block_head × n→ arith_exprwhich takes a block head and returns an arithmetic resource usageexpression < arith_expr >.





i=1(∏j≺i


β(ap,r)(Li , ψi(n)) is the resource usage of preparing the call tostatement Li .β(ap, r) is a function that takes an approximation identifier ap anda resource identifier r and returns a function

∆L : body_stm × n→ arith_exprwhich takes a body statement and returns an arithmetic resourceusage expression < arith_expr >.





i=1(∏j≺i


RUstm(Li,ap, r , ψi(n)) is:

If Li is recursive (i.e., calls a procedure q which is in thestrongly-connected component of the call graph being analyzed)then it is replaced by a symbolic expression RU(q,ap, r , ψi (n)).If Li is not recursive then it is thus replaced by the (closed form)resource usage function for q, say Φ′, applied to ψi (n) (i.e.Φ′(ψi (n))).



General equation


i=1(∏j≺i

SolsLj (ψj(n)))(β(ap, r)(Li , ψi(n) + RUstm(Li ,ap, r , ψi(n)))


δ(ap,r)(H,n) = δ(ub,ex)(H,n) is the execution time needed forthe head H (parameter passing)

δ(ub,ex)(H,n) = γ(H,n) +∑

I∈E(C,H)

t(I)(n)

γ(H,n) denotes the execution time needed to determine that theprevious blocks to C of procedure p will not yield a solution andthat C must be tried.E(C,H) is the set of bytecodes assigned to block head H.t(I) is the timing model (a cost function) of instruction I.



General equation


i=1(∏j≺i



β(ap, r)(Li , ψi(n)) = β(ub,ex)(Li , ψi(n)) is the time needed toprepare the call to statement Li

β(ub,ex)(Li , ψi(n)) =∑

I∈E(C,Li )

t(I)(ψi(n)), i = 1, · · · , k

E(C,Li) is the set of bytecodes assigned to statement Li .t(I) is the timing model (a cost function) of instruction I.lim(ap,C) = lim(ub,C) = k (the number of statements in block C).



General equation


i=1(∏j≺i



RU(p,ub,ex ,n) = γ(H,n) +∑

I∈E(C,H) t(I)(n) +k∑

i=1(∏j≺i

SolsLj (ψj(n)))((∑

I∈E(C,Li )t(I)(ψi(n))) + RUstm(Li ,ub,ex , ψi(n)))



General equation


i=1(∏j≺i


Particular case: Upper bound on execution timeIf program is deterministic (e.g., Java bytecode), then∏j≺i

SolsLj (ψj(n)) = 1

RU(p,ub,ex ,n) = γ(H,n) +∑

I∈E(C,H) t(I)(n) +k∑

i=1((∑

I∈E(C,Li )t(I)(ψi(n))) + RUstm(Li ,ub,ex , ψi(n)))


The Assertion Language Overview

The Assertion Language

It allows the user to describe resources and also other inputs tothe resource analysis such as argument sizes, size metrics, etc.It is also the language in which the resource analysis produces itsoutput.It is used additionally to state resource-related specificationswhich allows finding bugs, verifying the program, etc.It allows improving both the accuracy and scalability of our system.


The Assertion Language Grammar for Java

Grammar for Java

< primitive_assrt > ::= primitive_name(var∗)< assrt >∗

< assrt > ::= @ requires ( < prop >∗ )| @ ensures ( < prop >∗ )| @ costs ( < resource_usage >∗ )

< resource_usage > ::= res_usage(< approx >, res_name, < arith_expr >)< resource_delta > ::= res_delta(< approx >, res_name, ∆)< approx_def > ::= approx_def(< approx >, arith_function)< prop > ::= in(var) | out(var) | type

| size(var , < approx >, < sz_metric >, < arith_expr >)| size_metric(var , < sz_metric >)

< approx > ::= ub | lb | o< sz_metric > ::= value | length | size< arith_expr > ::= < sz_val > | (< sz_val >∗)< sz_val > ::= num | < sz_metric > (var)


Experimental Results Execution Times

Benchmarks

No. Program Data size1 append(+A,+,-) x=length(A)=1502 evalpol(+A,+X,-) x=length(A)=1003 fib(+N,-) x=N=164 hanoi(+N,+,+,+,-) x=N=85 nreverse(+L,-) x=length(L)=836 palindro(+A,-) x=length(A)=97 powset(+A,-) x=length(A)=118 list_diff(+L,+D,-) x=length(L)=65

y=length(D)=659 list_inters(+L,+D,-) x=length(L)=65

y=length(D)=6510 substitute(+A,+B,-) x=term_size(A)=67

y=term_size(B)=8011 derive(+E,+,-) x=term_size(E)=75



Estimated Cost Functions (Intel)

Pr. Cost. Intel (µs)No. App. Cost Function

1 E 0.73x + 0.212 E 0.69x + 0.193 E 0.69 · 1.6x + 0.21(−0.62)x − 0.724 E −0.0042 · 2x + 0.73x · 2x − 0.865 E 0.37x2 + 0.49x + 0.126 E 0.36 · 2x + 0.37x · 2x − 0.247 E 0.91 · 2x + 0.87x − 0.68 L 0.66x + 0.2

U 0.78xy + 1.7x + 0.49 L 0.83x + 0.2

U 0.78xy + 1.7x + 0.410 L 2x

U 1.4xy + 1.4y + 6.1x + 4.111 L 2.9x

U 3x + 3



Observed and Estimated Execution Time (Intel)

Pr. Cost. Intel (µs)No. App. Est. Prf. Obs. D. % Pr.D. %

1 E 110 110 113 -2.4 -2.42 E 69 69 71 -2.3 -2.33 E 1525 1525 1576 -3.3 -3.34 E 1501 1501 1589 -5.7 -5.75 E 2569 2569 2638 -2.7 -2.76 E 1875 1875 2027 -7.8 -7.87 E 1868 1868 1931 -3.3 -3.38 L 43 68 81 -67.2 -17.8

U 3414 3569 3640 -6.4 -2.09 L 54 79 91 -54.6 -14.8

U 3414 3694 4011 -16.2 -8.210 L 135 142 124 8.6 13.7

U 7922 2937 2858 120.6 2.711 L 216 138 111 72.3 22.5

U 226 216 162 34.0 29.5


Experimental Results Resource Analysis of Java

Resource Analysis of Java

Program Resource(s) t Resource Usage Func.BST Heap usage 367 O(2n) n ≡ tree depthCellPhone SMS monetary cost 386 O(n2) n ≡ packets lengthClient Bytes received and 527 O(n) n ≡ stream length

bandwidth required O(1) —Dhrystone Energy consumption 759 O(n) n ≡ int valueDivbytwo Stack usage 219 O(log2(n)) n ≡ int valueFiles Files left open and 649 O(n) n ≡ number of files

Data stored O(n ×m) m ≡ stream lengthJoin DB accesses 460 O(n ×m) n, m ≡ table recordsScreen Screen width 536 O(n) n ≡ stream length

The analysis is able to infer resource information about low-levelproperties such as:

Stack usage.Energy consumption.


Conclusions

Conclusions

We have presented a static analysis that infers upper and lowerbounds on the usage that a program makes of a quite generalnotion of user-definable resources.The inferred bounds are in general functions of input data sizes.We have also introduced the assertion language which is used todefine such resources.It allows improving both the accuracy and scalability of our system.Applied to the particular case of predicting execution times ofprograms (running on a bytecode-based abstract machine).Estimations with average deviation of 5% when analyzer infersexact cost function.Worse approximations of course when functions inferred arebounds (specially for programs performing search).


Resource Analysis - Technische Universität Münchenseidl/espass/garcia.pdfResource Usage Analysis...

Documents

Transcript of Resource Analysis - Technische Universität Münchenseidl/espass/garcia.pdfResource Usage Analysis...