04/19/23

Partial Evaluation andPartial Evaluation andAutomatic Program OptimisationAutomatic Program OptimisationLecture 1 (morning): IntroductionLecture 1 (morning): Introduction

Michael Leuschel

Declarative Systems & Software EngineeringDept. Electronics & Computer ScienceUniversity of Southampton

http:// www.ecs.soton.ac.uk/~mal

Overview: First 2 hours Overview: First 2 hours

Explain what these lectures are about:– Program Optimisation in general

– Partial Evaluation in particular

– Program Transformation, Analysis, and Specialisation Explain why you should attend the lectures:

– Why are the topics interesting ?

– Why are they useful ? Overview of the whole course

Part 1:Part 1:

Program Optimisation and Partial Program Optimisation and Partial Evaluation: A first overviewEvaluation: A first overview

(Automatic) Program Optimisation(Automatic) Program Optimisation

When:– Source-to-source

– during compilation

– at link-time

– at run-time Why:

– Make existing programs faster (10 % 500 ...)

– Enable safer, high-level programming style ()

– (Program verification,…)

Program Optimisation IIProgram Optimisation II

What:– constant propagation, inlining , dead-code

elimination, eliminate redundant computations, change of algorithm or data-structures, …

Similar to highly optimising compilers: – much more aggressive,– (much) greater speedups and– much more difficult to control

How ?

Program TransformationProgram Transformation

How:– Unfold/fold approach [Burstall,Darlington 77]

– Schema-based approach

– Usually not fully automatic Why:

– Program synthesis specification executable program

– Program optimisation: Change data-structure, algorithm, … Program specialisation, ...

Program Transformation: Unfold/foldProgram Transformation: Unfold/fold

InitialProgram

P0

ProgramP1unfold/fold

step

FinalProgram

Pnunfold/fold

step

...

Under some conditions:Same semantics

Same termination propertiesBetter performance

Program AnalysisProgram Analysis

What:– Find out interesting properties of your programs:

Values produced, dependencies, usage, termination, ...

Why:– Verification, debugging

Type checking Check assertions

– Optimisation: Guide compiler (compile time gc, …) Guide source-to-source optimiser

Program Analysis IIProgram Analysis II

How:– Rice’s theorem: all non-trivial properties are

undecidable ! approximations or sufficient conditions

Techniques:– Ad hoc

– Abstract Interpretation [Cousot’77]

– Type Inference

Abstract InterpretationAbstract Interpretation

Principle:– Abstract domain

– Abstract operations: safe approximation of concrete operations

Result:– Correct

– Termination can be guaranteed Decidable approximation of undecidable properties

… -2 -1 0 1 2 3 ...

Concrete domain

N- N+

Abstract domain

0

N+ + N+ = N+

N+ + 0 = N+

...

Program SpecialisationProgram Specialisation

What:– Specialise a program for a

particular application domain How:

– Partial evaluation– Program transformation– Type specialisation– Slicing

DrawingProgram P

P’

OverviewOverview

PartialEvaluationProgram

Specialisation

ProgramTransformation

Program Optimisation

Part 2:Part 2:

A closer look at partial evaluation: A closer look at partial evaluation: First StepsFirst Steps

A closer look at PE A closer look at PE

Partial Evaluation versus Full Evaluation Why PE Issues in PE: Correctness, Precision, Termination Self-Application and Compilation

2

5

power

Full EvaluationFull Evaluation

Full input Computes full output

2

532power

2

532power

function power(b,e) is if e = 0 then 1 else b*power(b,e-1)

Partial EvaluationPartial Evaluation

Only part of the input produce part of the output ?

power(?,2)

evaluate as much as you can produce a specialized program

power_2(?)

PE: A first attemptPE: A first attempt

Small (functional) language:– constants (N), variables (a,b,c,…)

– arithmetic expressions *,/,+,-, =

– if-then-else, function definitions Basic Operations:

– Evaluate arithmetic operation if all arguments are known

– 2+3 5 5=4 false x+(2+3) x+5

– Replace if-then-else by then-part (resp. else-part) if test-part is known to be true (resp. false)

function power(power(bb,,ee)) is if e = 0 then 1 else b*power(b,e-1)

Example: powerExample: power power(?,2)

function power(power(bb,,22)) is if e = 0 then 1 else b*power(b,e-1)

function power(b,2) is ifif 22 = 0= 0 then 1 else b*power(b,e-1)

function power(b,2) is if false then 1 elseelse b*power(b,2-1)

power(?,1)function power(power(bb,,11)) is if e = 0 then 1 else b*power(b,e-1)

function power(b,1) is if false then 1 elseelse b*power(b,1-1)

function power_1(b) is b*power_0(b)

function power_2(b) is b*power_1(b)

Residual code:

Example: power (cont’d)Example: power (cont’d)

power(?,0)

function power(power(bb,,00)) is if e = 0 then 1 else b*power(b,e-1)

function power(b,0) is ifif 00 == 00 then 1 else b*power(b,e-1)

function power(b,0) is if 0 = 0 thenthen 11 else b*power(b,e-1)

function power_0(b) is 11

Residual code:

Example: power (cont’d)Example: power (cont’d)

Residual code:

function power_0(b) is 11

function power_1(b) is b*power_0(b)

function power_2(b) is b*power_1(b)

What we really, really want:

function power_2(b) is b*b

Extra Operation: UnfoldingExtra Operation: Unfolding

Replace call by definition

function power(b,2) is if 2 = 0 then 1 elseelse b*power(b,1)

function power(b,2) is if 2 = 0 then 1 elseelse b* (if 1 = 0 then 1 elseelse b*power(b,0))

function power(b,2) is if 2 = 0 then 1 elseelse b* (if 1 = 0 then 1 elseelse b* (if 0 = 0 then 1then 1 else b*power(b,-1)))

function power_2(b) is b*b*1

Residual code:

≈ evaluating thefunction call operation

≈ SQR function

PE: Not always beneficialPE: Not always beneficial

power(3,?)

Residual code:

function power(power(33,,ee)) is if e = 0 then 1 else b*power(b,e-1)

function power(power(33,,ee)) is if e = 0 then 1 else 33*power(33,e-1)

function power_3(power_3(ee)) is if e = 0 then 1 else 33*power_3(e-1)

Part 2:Part 2:

Why Partial Evaluation (and Program Why Partial Evaluation (and Program Optimisation)?Optimisation)?

Constant PropagationConstant Propagation

Static values in programs

function my_program(x) is … y := 2* power(x,33) …

function my_program(x) is … y := 2* x * x * x …

captures inlining and more

Abstract Datatypes / ModulesAbstract Datatypes / Modules

Get rid of inherent overhead by PE

function my_program(x) is … if not empty_tree(x) then y := get_value(x)…

function my_program(x) is … if x != null then if x != null then y := x->val …

+ get rid of redundant run-time tests

Higher-Order/Reusing Generic CodeHigher-Order/Reusing Generic Code

Get rid of overhead incite usage

function my_program(x,y,z) is … r := reduce(*,1,map(inc,[x,y,z])) …

function my_program(x,y,z) is … r := (x+1)*(y+1)*(z+1) …

Higher-Order IIHigher-Order II

Can generate new functions/procedures

function my_program(x) is … r := reduce(*,1,map(inc,x)) …

function my_program(x) is … r := red_map_1(x) …function red_map_1(x) is if x=nil then return 1 else return x->head* red_map_1(x->tail)

Staged InputStaged Input

Input does not arrive all at once

my_program (x , y , z) … …

5 2 2.1

42

Examples of staged inputExamples of staged input

Ray tracingcalculate_view(Scene,Lights,Viewpoint)

Interpretationinterpreter(ObjectProgram,Call)prove_theorem(FOL-Theory,Theorem)check_integrity(Db_rules,Update)schedule_crews(Rules,Facts)

Speedups– 2: you get your money back– 10: quite typical for interpretation overhead– 100-500 (and even ∞): possible

Ray TracingRay Tracing

Static

Why go beyond partial evaluationWhy go beyond partial evaluation

Improve algorithms (not necessarily PS):– Tupling

– Deforestation Superlinear speedups Non-executable executable programs Software Verification, Inversion, Model

Checking

TuplingTuplingCorresponds to

loop-fusion

DeforestationDeforestation

Part 3:Part 3:

Issues in Partial Evaluation and Issues in Partial Evaluation and Program OptimisationProgram Optimisation

Correctness Termination

Efficiency/Precision

Self-application

CorrectnessCorrectness

Language– Power/Elegance: unfolding LP easy, FP ok, C++ aargh

– Modularity: global variables, pointers Semantics

– Purely logical

– Somewhat operational (termination,…)

– Purely operational

– Informal/compilerrestrictive

admissive

Programming Language for CourseProgramming Language for Course

Lectures use mainly LP– Don’t distract from essential issues

– Nice programming paradigm

– A lot of room for speedups

– Techniques can be useful for other languages, but Correctness will be more difficult to establish Extra analyses might be required (aliasing, flow analysis, …)

Efficiency/PrecisionEfficiency/Precision

Unfold enough but not too much– Enough to propagate partial information

– But still ensure termination

– Binding-time Analysis (for offline systems): Which expressions will be definitely known Which statements can be executed

Allow enough polyvariance but not too much– Code explosion problem

– Characteristic trees

x := 2+y;p(x)

y=5 p(7)

p(7) p(9) p(11) p(13) ...

TerminationTermination

Who cares PE should terminate when the program does PE should always terminate " within reasonable time bounds

State of the art

Self-ApplicationSelf-Application

Principle:– Write a partial evaluator (program specialiser,…)

which can specialise itself Why:

– Ensures non-trivial partial evaluator

– Ensures non-trivial language

– Optimise specialisation process

– Automatic compiler generation !

Compiling by PECompiling by PE

InterpreterObject Program P

Call1Call2

Call3

Result1Result2

Result3

PE

P-Interpreter

Call1Call2

Call3

Result1Result2

Result3

Compiler Generation by PECompiler Generation by PE

Interpreter IObject Program P

PE

P-Interpreter

Object Program Q

Q-Interpreter

Object Program R

R-Interpreter

static

PE’ I-PE

Object Program PObject Program QObject Program R

= Compiler !

Useful for:Lge Extensions,Debugging,DSL,...

Cogen Generation by PECogen Generation by PE

PEInterpreter P

PE’

P-Compiler

Interpreter Q

Q-Compiler

Interpreter R

R-Compiler

static

PE’’ PE-PE

Interpreter PInterpreter QInterpreter R

= Compiler Generator !

3rd FutamuraProjection

Part 4:Part 4:

Overview of the course (remainder)Overview of the course (remainder)

Overview of the Course: Lecture 1 Overview of the Course: Lecture 1 (remainder)(remainder) Partial Evaluation of Logic Programs:

First Steps– This afternoon, April 20th:

A short (re-)introduction to Logic Programming How to do partial evaluation of logic programs

(called partial deduction): first steps

– Outcome: Enough knowledge of LP to follow the rest Concrete idea of PE for one particular language

Overview of the Course: Lecture 2Overview of the Course: Lecture 2

(Online) Partial Deduction: Foundations, Algorithms and Experiments– Next week, April 27th:

Correctness criterion and results Control Issues: Local vs. Global; Online vs. Offline Local control solutions: Termination Global control: Ch. trees, WQO's at the global level Relevance for other languages and applications Full demo of Ecce system

– Outcome: How to control program specialisers (analysers, ...) How to prove them correct

Overview of the Course: Lecture 3Overview of the Course: Lecture 3

Self-application and compiler generation– May 4th:

Principle of self-application, history Cogen by hand principle How to achieve cogen by hand for logic programs Binding-time analysis by abstract interpretation (POS) How to handle extra logical features Demo of the logen system

– Outcome: How to achieve (very) fast specialisation How to automatically generate compilers

Overview of the Course: Lecture 4Overview of the Course: Lecture 4

Extending Partial Deduction: Integrating Unfold/Fold and Abstract Interpretation– May 11th:

Unfold/Fold vs PD Going from PD to Conjunctive PD Control issues, Demo of Ecce Abstract Interpretation vs Conj. PD and Unfold/Fold Integrating Abstract Interpretation Applications (+ Demo): Infinite Model Checking

– Outcome How to do very advanced/fancy optimisations

Summary (first 2 hours):Summary (first 2 hours):What to know for the examWhat to know for the exam Terminology:

– Program Optimisation, Transformation, Analysis, Specialisation, PE

Basics of PE and Optimisation in general Uses of PE and Program Optimisation

– Common compiler optimisations

– Enabling high-level programming

– Staged input, optimising existing code

– Self-application and compiler generation