Transcript Partial Evaluation: A Tutorial

Partial Evaluation and
Automatic Program Optimisation
Lecture 1 (morning): Introduction
Michael Leuschel
Declarative Systems & Software Engineering
Dept. Electronics & Computer Science
University of Southampton
http:// www.ecs.soton.ac.uk/~mal
7/17/2015
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:
Program Optimisation and Partial
Evaluation: A first overview
(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 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 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/fold
Initial
Program
P0
unfold/fold
step
Program
P1
unfold/fold
step
...
Under some conditions:
Same semantics
Same termination properties
Better performance
Final
Program
Pn
Program 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 II

How:
– Rice’s theorem: all non-trivial properties are
undecidable !
–  approximations or sufficient conditions

Techniques:
– Ad hoc
– Abstract Interpretation [Cousot’77]
– Type Inference
Concrete domain
Abstract Interpretation

… -2 -1 0 1 2 3 ...
Principle:
– Abstract domain
– Abstract operations:


safe approximation of concrete operations
Result:
N- 0
N+
Abstract domain
N+ + N+ = N+
N+ + 0 = N+
...
– Correct
– Termination can be guaranteed
–  Decidable approximation of undecidable properties
Program Specialisation

Drawing
Program P
What:
– Specialise a program for a
particular application domain

How:
–
–
–
–
Partial evaluation
Program transformation
Type specialisation
Slicing
P’
Overview
Program
Specialisation
Partial
Evaluation
Program Optimisation
Program
Transformation
Part 2:
A closer look at partial evaluation:
First Steps
A closer look at PE




Partial Evaluation versus Full Evaluation
Why PE
Issues in PE: Correctness, Precision, Termination
Self-Application and Compilation
Full Evaluation


Full input
Computes full output
2
power
32
5
function power(b,e) is
if e = 0 then
1
else
b*power(b,e-1)
Partial 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 attempt

Small (functional) language:
– constants (N), variables (a,b,c,…)
– arithmetic expressions *,/,+,-, =
– if-then-else, function definitions

function power(b,e) is
if e = 0 then
1
else
b*power(b,e-1)
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)
Example: power

power(?,2)
function power(b,2) is
if e
2 = 0 then
false
1
else
b*power(b,e-1)
b*power(b,2-1)

Residual code:
function power_2(b) is
b*power_1(b)
power(?,1)
function power(b,1) is
if e
false
= 0 then
1
else
b*power(b,1-1)
b*power(b,e-1)
function power_1(b) is
b*power_0(b)
Example: power (cont’d)

power(?,0)
function power(b,0) is
if e
0 = 0 then
1
else
b*power(b,e-1)
Residual code:
function power_0(b) is
1
Example: power (cont’d)
Residual code:

function power_2(b) is
b*power_1(b)
function power_1(b) is
b*power_0(b)
function power_0(b) is
1

What we really, really want:
function power_2(b) is
b*b
Extra Operation: Unfolding

≈ evaluating the
function call operation
Replace call by definition
function power(b,2) is
if 2 = 0 then
1
else
b*power(b,1)
b*
(if 1 = 0 then 1
else b*
b*power(b,0))
(if 0 = 0 then 1
else b*power(b,-1)))
Residual code:
function power_2(b) is
b*b*1
≈ SQR function
PE: Not always beneficial

power(3,?)
function power(3,e) is
if e = 0 then
1
else
3*power(3,e-1)
b*power(b,e-1)

Residual code:
function power_3(e) is
if e = 0 then
1
else
3*power_3(e-1)
Part 2:
Why Partial Evaluation (and Program
Optimisation)?
Constant Propagation

Static values in programs
function my_program(x) is
…
y := 2* power(x,3)
…
captures inlining and more
function my_program(x) is
…
y := 2* x * x * x
…
Abstract Datatypes / Modules

Get rid of inherent overhead by PE
function my_program(x) is
…
if not empty_tree(x) then
y := get_value(x)…
+ get rid of redundant run-time tests
function my_program(x) is
…
if x != null then
if x != null then
y := x->val …
Higher-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 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 Input

Input does not arrive all at once
5
2 2.1
my_program (x , y , z)
…
…
42
Examples of staged input

Ray tracing
calculate_view(Scene,Lights,Viewpoint)
Interpretation
interpreter(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 Tracing
Static
Why go beyond partial evaluation

Improve algorithms (not necessarily PS):
– Tupling
– Deforestation



Superlinear speedups
Non-executable  executable programs
Software Verification, Inversion, Model
Checking
Tupling
Corresponds to
loop-fusion
Deforestation
Part 3:
Issues in Partial Evaluation and
Program Optimisation
Efficiency/Precision
Correctness
Termination
Self-application
Correctness

Language
– Power/Elegance: unfolding LP easy, FP ok, C++ aargh
– Modularity: global variables, pointers

Semantics
–
–
–
–
admissive
Purely logical
Somewhat operational (termination,…)
Purely operational
Informal/compiler
restrictive
Programming 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, …)
x := 2+y;
p(x)
Efficiency/Precision

y=5  p(7)
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
p(7)
p(9)
p(11)
p(13) ...
Termination




Who cares
PE should terminate when the program does
PE should always terminate
State of the art
" within reasonable time bounds
Self-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 PE
Call2
Call1 Call3
Object Program P
Interpreter
PE
Result1
Result2
Result3
Call2
Call1 Call3
P-Interpreter
Result1
Result2
Result3
Compiler Generation by PE
Object
Program
Object
Program
QR
Object Program P
PE
static
Interpreter I
PE’
P-Interpreter
Q-Interpreter
R-Interpreter
Object
Program
Object
Program
QR
Object Program P
I-PE = Compiler !
Useful for:
Lge Extensions,
Debugging,
DSL,...
Cogen Generation by PE
static
Interpreter
Interpreter
QR
Interpreter P
PE
PE’
PE’’
P-Compiler
Q-Compiler
R-Compiler
Interpreter
Interpreter
QR
Interpreter P
PE-PE = Compiler
Generator !
3rd Futamura
Projection
Part 4:
Overview of the course (remainder)
Overview of the Course: Lecture 1
(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 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 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 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):
What 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