Partial Evaluation and Automatic Program Optimisation Lecture 1 (morning): Introduction

1. Partial Evaluation andAutomatic Program OptimisationLecture 1 (morning): Introduction Michael Leuschel Declarative Systems & Software Engineering Dept. Electronics & Computer Science University of Southampton http:// www.ecs.soton.ac.uk/~mal

2. 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

3. Part 1:Program Optimisation and Partial Evaluation: A first overview

4. (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,…)

5. 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 ?

6. 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, ...

7. unfold/fold step unfold/fold step Program Transformation: Unfold/fold Final Program Pn Initial Program P0 Program P1 ... Under some conditions: Same semantics Same termination properties Better performance

8. 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

9. 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

10. N- 0 N+ Abstract domain Concrete domain Abstract Interpretation … -2 -101 2 3 ... • Principle: • Abstract domain • Abstract operations: • safe approximation of concrete operations • Result: • Correct • Termination can be guaranteed •  Decidable approximation of undecidable properties N+ +N+ =N+ N+ +0=N+ ...

11. Drawing Program P Program Specialisation • What: • Specialise a program for aparticular application domain • How: • Partial evaluation • Program transformation • Type specialisation • Slicing P’

12. Overview Partial Evaluation Program Transformation Program Specialisation ProgramOptimisation

13. Part 2:A closer look at partial evaluation: First Steps

14. A closer look at PE • Partial Evaluation versus Full Evaluation • Why PE • Issues in PE: Correctness, Precision, Termination • Self-Application and Compilation

15. Full Evaluation • Full input • Computes full output function power(b,e) is if e = 0 then 1 else b*power(b,e-1)

16. 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(?)

17. PE: A first attempt function power(b,e) is if e = 0 then 1 else b*power(b,e-1) • 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)

18. Example: power • power(?,2) function power(b,2) is if e = 0 then 1 else b*power(b,e-1) function power(b,2) is if2= 0 then 1 else b*power(b,e-1) function power(b,2) is iffalsethen 1 else 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 = 0 then 1 else b*power(b,e-1) function power(b,1) is iffalsethen 1 else b*power(b,1-1) function power_1(b) is b*power_0(b)

19. Example: power (cont’d) • power(?,0) function power(b,0) is if e = 0 then 1 else b*power(b,e-1) function power(b,0) is if0=0 then 1 else b*power(b,e-1) function power(b,0) is if0=0then 1 else b*power(b,e-1) Residual code: function power_0(b) is 1

20. 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

21. Extra Operation: Unfolding ≈ evaluating the function call operation • Replace call by definition function power(b,2) is if2= 0then 1 else b*power(b,1) function power(b,2) is if2= 0then 1 else b* (if1= 0then 1 elseb*power(b,0)) function power(b,2) is if2= 0then 1 else b*(if1= 0then 1 elseb* (if0 = 0then 1 else b*power(b,-1))) Residual code: function power_2(b) is b*b*1 ≈ SQR function

22. PE: Not always beneficial • power(3,?) • Residual code: function power(3,e) is if e = 0 then 1 else 3*power(3,e-1) function power(3,e) is if e = 0 then 1 else b*power(b,e-1) function power_3(e) is if e = 0 then 1 else 3*power_3(e-1)

23. Part 2:Why Partial Evaluation (and Program Optimisation)?

24. 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 …

25. 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 …

26. 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) …

27. 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)

28. Staged Input • Input does not arrive all at once 5 2 2.1 my_program (x , y , z) … … 42

29. Examples 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

30. Ray Tracing Static

31. Improve algorithms (not necessarily PS): Tupling Deforestation Superlinear speedups Non-executable  executable programs Software Verification, Inversion, Model Checking Why go beyond partial evaluation

32. Tupling Corresponds to loop-fusion

33. Deforestation

34. Part 3:Issues in Partial Evaluation and Program Optimisation Efficiency/Precision Correctness Termination Self-application

35. Correctness • Language • Power/Elegance: unfolding LP easy, FP ok, C++ aargh • Modularity: global variables, pointers • Semantics • Purely logical • Somewhat operational (termination,…) • Purely operational • Informal/compiler admissive restrictive

36. 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, …)

37. x := 2+y;p(x) y=5 p(7) Efficiency/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 p(7) p(9) p(11) p(13) ...

38. Termination • Who cares • PE should terminate when the program does • PE should always terminate • " within reasonable time bounds State of the art

39. 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 !

40. Compiling by PE Call2 Call1 Call3 Result1 Object Program P Interpreter Result2 Result3 Call2 Call1 Call3 PE Result1 P-Interpreter Result2 Result3

41. Compiler Generation by PE Object Program R static Object Program Q Object Program R Object Program P Object Program Q Object Program P Interpreter I PE PE’ I-PE = Compiler ! Useful for: Lge Extensions, Debugging, DSL,... P-Interpreter Q-Interpreter R-Interpreter

42. Cogen Generation by PE Interpreter R static Interpreter Q Interpreter R Interpreter P Interpreter Q Interpreter P PE PE’ PE’’ PE-PE = Compiler Generator ! 3rd Futamura Projection P-Compiler Q-Compiler R-Compiler

43. Part 4:Overview of the course (remainder)

44. 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

45. 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

46. 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

47. 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

48. 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