1 / 187

Optimisation of Declarative Programs Lecture 1: Introduction

Optimisation of Declarative Programs Lecture 1: Introduction. Michael Leuschel Declarative Systems & Software Engineering Dept. Electronics & Computer Science University of Southampton http://. www.ecs.soton.ac.uk/~mal. + Morten Heine Sørensen DIKU, Copenhagen. 1. Overview

jeremy-good
Download Presentation

Optimisation of Declarative Programs Lecture 1: 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. Optimisation of Declarative Programs Lecture 1: Introduction Michael Leuschel Declarative Systems & Software Engineering Dept. Electronics & Computer Science University of Southampton http:// www.ecs.soton.ac.uk/~mal + Morten Heine Sørensen DIKU, Copenhagen

  2. 1. Overview 2. PE: 1st steps 3. Why PE 4. Issues in PE Lecture 1 • 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. 1. Overview 2. PE: 1st steps 3. Why PE 4. Issues in PE 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. 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

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

  8. Overview Partial Evaluation Program Transformation Program Specialisation ProgramOptimisation

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

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

  11. 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+ ...

  12. 1. Overview 2. PE: 1st steps 3. Why PE 4. Issues in PE Part 2:A closer look at partial evaluation: First Steps

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

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

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

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

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

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

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

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

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

  22. 1. Overview 2. PE: 1st steps 3. Why PE 4. Issues in PE Part 3:Why Partial Evaluation (and Program Optimisation)?

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

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

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

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

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

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

  29. Ray Tracing Static

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

  31. Tupling Corresponds to loop-fusion

  32. Deforestation

  33. 1. Overview 2. PE: 1st steps 3. Why PE 4. Issues in PE Part 4:Issues in Partial Evaluation and Program Optimisation Efficiency/Precision Correctness Termination Self-application

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

  35. Programming Language for Course • Lectures use mainly LP and FP • 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, …)

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

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

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

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

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

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

  42. Part 5:Overview of the course (remainder)

  43. Overview of the Course: Lecture 2 • Partial Evaluation of Logic Programs:First Steps • Topics • 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

  44. Overview of the Course: Lecture 3 • (Online) Partial Deduction: Foundations, Algorithms and Experiments • Topics • 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

  45. Overview of the Course: Lecture 4(?) • Extending Partial Deduction: • Topics • 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

  46. Overview of the Course:Other Lectures • By Morten Heine Sørensen • Context: • Functional Programming Languages • Topics: • Supercompilation • Unfold/fold • ...

  47. Summary of Lecture 1: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

  48. Optimisation of Declarative Programs Lecture 2 Michael Leuschel Declarative Systems & Software Engineering Dept. Electronics & Computer Science University of Southampton http:// www.ecs.soton.ac.uk/~mal

  49. 1. LP Refresher 2. PE of LP: 1st steps Overview of Lecture 2: • Recap of LP • First steps in PE of LP • Why is PE non-trivial ? • Generating Code: Resultants • Correctness • Independence, Non-triviality, Closedness • Results • Filtering • Small demo of the ecce system

  50. 1. LP Refresher 2. PE of LP: 1st steps Part 1:Brief Refresher onLogic Programming and Prolog

More Related