1 / 48

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

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. Overview: First 2 hours.

lana-hoover
Download Presentation

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

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related