self adjusting machines
play

Self-Adjusting Machines Matthew A. Hammer University of Chicago - PowerPoint PPT Presentation

Self-Adjusting Machines Matthew A. Hammer University of Chicago Max Planck Institute for Software Systems Thesis Defense July 20, 2012 Chicago, IL Static Computation Versus Dynamic Computation Static Computation: Fixed Input Compute Fixed


  1. Self-Adjusting Machines Matthew A. Hammer University of Chicago Max Planck Institute for Software Systems Thesis Defense July 20, 2012 Chicago, IL

  2. Static Computation Versus Dynamic Computation Static Computation: Fixed Input Compute Fixed Output Dynamic Computation: Changing Input Compute Changing Output Read Write Update Changes Updates Matthew A. Hammer Self-Adjusting Machines 2

  3. Dynamic Data is Everywhere Software systems often consume/produce dynamic data Reactive Systems Analysis of Internet Scientific Simulation data Matthew A. Hammer Self-Adjusting Machines 3

  4. Tractability Requires Dynamic Computations Changing Input Compute Changing Output Static Case (Re-evaluation “from scratch”) compute 1 sec # of changes 1 million Total time 11.6 days Matthew A. Hammer Self-Adjusting Machines 4

  5. Tractability Requires Dynamic Computations Changing Input Compute Changing Output Read Write Update Changes Updates Static Case Dynamic Case (Re-evaluation “from scratch”) (Uses update mechanism) compute 1 sec compute 10 sec 1 × 10 − 3 sec # of changes 1 million update Total time 11.6 days # of changes 1 million Total time 16.7 minutes Speedup 1000x Matthew A. Hammer Self-Adjusting Machines 4

  6. Dynamic Computations can be Hand-Crafted As an input sequence changes, maintain a sorted output. Changing Input Changing Output compute 1,7,3,6,5,2,4 1,2,3,4,5,6,7 1,7,3,6 / ,5,2,4 update 1,2,3,4,5,6 / ,7 Remove 6 Reinsert 6, 1,7,3, 6 ,5,2 / ,4 update 1,2 / ,3,4,5, 6 ,7 Remove 2 A binary search tree would suffice here (e.g., a splay tree) What about more exotic/complex computations? Matthew A. Hammer Self-Adjusting Machines 5

  7. Self-Adjusting Computation Offers a systematic way to program dynamic computations Domain knowledge + Library primitives Self-Adjusting Program The library primitives : 1. Compute initial output and trace from initial input 2. Change propagation updates output and trace Matthew A. Hammer Self-Adjusting Machines 6

  8. High-level versus low-level languages Existing work uses/targets high-level languages (e.g., SML) In low-level languages (e.g., C), there are new challenges Language feature High-level help Low-level gap Type system Indicates mutability Everything mutable Functions Higher-order traces Closures are manual Stack space Alters stack profile Bounded stack space Heap management Automatic GC Explicit management C is based on a low-level machine model This model lacks self-adjusting primitives Matthew A. Hammer Self-Adjusting Machines 7

  9. Thesis statement By making their resources explicit, self-adjusting machines give an operational account of self-adjusting computation suitable for interoperation with low-level languages ; via practical compilation and run-time techniques , these machines are programmable , sound and efficient . Contributions Surface language, C-based Programmable Abstact machine model Sound Compiler Realizes static aspects Run-time library Realizes dynamic aspects Empirical evaluation Efficient

  10. Example: Dynamic Expression Trees Objective : As tree changes, maintain its valuation + + − − − + + + − 0 5 6 0 5 3 4 3 4 5 6 (( 3 + 4 ) − 0 ) + ( 5 − 6 ) = 6 (( 3 + 4 ) − 0 ) + (( 5 − 6 ) + 5 ) = 11 Consistency : Output is correct valuation Efficiency : Update time is O ( # affected intermediate results ) Matthew A. Hammer Self-Adjusting Machines 9

  11. Expression Tree Evaluation in C typedef struct node s* node t; 1 struct node s { 2 enum { LEAF, BINOP } tag; 3 union { int leaf; 4 struct { enum { PLUS, MINUS } op; 5 6 node t left, right; } binop; } u; } 7 int eval (node t root) { 1 if (root->tag == LEAF) 2 return root->u.leaf; 3 else { 4 int l = eval (root->u.binop.left); 5 6 int r = eval (root->u.binop.right); 7 if (root->u.binop.op == PLUS) return (l + r); 8 else return (l - r); 9 } } Matthew A. Hammer Self-Adjusting Machines 10

  12. The Stack “Shapes” the Computation int eval (node t root) { if (root->tag == LEAF) return root->u.leaf; else { int l = eval (root->u.binop.left); int r = eval (root->u.binop.right); if (root->u.binop.op == PLUS) return (l + r); else return (l - r); } } Stack usage breaks computation into three parts : Matthew A. Hammer Self-Adjusting Machines 11

  13. The Stack “Shapes” the Computation int eval (node t root) { if (root->tag == LEAF) return root->u.leaf; else { int l = eval (root->u.binop.left); int r = eval (root->u.binop.right); if (root->u.binop.op == PLUS) return (l + r); else return (l - r); } } Stack usage breaks computation into three parts : ◮ Part A : Return value if LEAF Otherwise, evaluate BINOP , starting with left child Matthew A. Hammer Self-Adjusting Machines 11

  14. The Stack “Shapes” the Computation int eval (node t root) { if (root->tag == LEAF) return root->u.leaf; else { int l = eval (root->u.binop.left); int r = eval (root->u.binop.right); if (root->u.binop.op == PLUS) return (l + r); else return (l - r); } } Stack usage breaks computation into three parts : ◮ Part A : Return value if LEAF Otherwise, evaluate BINOP , starting with left child ◮ Part B : Evaluate the right child Matthew A. Hammer Self-Adjusting Machines 11

  15. The Stack “Shapes” the Computation int eval (node t root) { if (root->tag == LEAF) return root->u.leaf; else { int l = eval (root->u.binop.left); int r = eval (root->u.binop.right); if (root->u.binop.op == PLUS) return (l + r); else return (l - r); } } Stack usage breaks computation into three parts : ◮ Part A : Return value if LEAF Otherwise, evaluate BINOP , starting with left child ◮ Part B : Evaluate the right child ◮ Part C : Apply BINOP to intermediate results; return Matthew A. Hammer Self-Adjusting Machines 11

  16. Dynamic Execution Traces Input Tree + − − + 0 5 6 3 4 Execution Trace A + B + C + A − B − C − A − B − C − A + B + C + A 0 A 5 A 6 A 3 A 4 Matthew A. Hammer Self-Adjusting Machines 12

  17. Updating inputs, traces and outputs + + − − − + + 0 5 6 + 0 − 5 3 4 3 4 5 6 A + B + C + A − B − C − A + B + C + A + B + C + A 0 A − B − C − A 5 A 3 A 4 A 5 A 6 Matthew A. Hammer Self-Adjusting Machines 13

  18. Core self-adjusting primitives Stack operations: push & pop Trace checkpoints: memo & update points update update A + B + C + A − B − C − A + B + C + A + B + C + A 0 A − B − C − A 5 A 3 A 4 A 5 A 6 (new evaluation) memo memo Matthew A. Hammer Self-Adjusting Machines 14

  19. Abstract model: Self-adjusting machines Matthew A. Hammer Self-Adjusting Machines 15

  20. Overview of abstract machines ◮ IL: Intermediate language ◮ Uses static-single assignment representation ◮ Distinguishes local from non-local mutation ◮ Core IL constructs: ◮ Stack operations : push , pop ◮ Trace checkpoints : memo , update ◮ Additional IL constructs: ◮ Modifiable memory : alloc , read , write ◮ (Other extensions possible) Matthew A. Hammer Self-Adjusting Machines 16

  21. Abstract machine semantics Two abstract machines given by small-step transition semantics: ◮ Reference machine : defines normal semantics ◮ Self-adjusting machine : defines self-adjusting semantics Can compute an output and a trace Can update output/trace when memory changes Automatically marks garbage in memory We prove that these abstract machines are consistent i.e., updated output is always consistent with normal semantics Matthew A. Hammer Self-Adjusting Machines 17

  22. Needed property: Store agnosticism An IL program is store agnostic when each stack frame has a fixed return value; hence, not affected by update points destination-passing style (DPS) transformation: ◮ Assigns a destination in memory for each stack frame ◮ Return values are these destinations ◮ Converts stack dependencies into memory dependencies ◮ memo and update points reuse and update destinations ◮ Lemma: DPS-conversion preserves program meaning ◮ Lemma: DPS-conversion acheives store agnosticism Matthew A. Hammer Self-Adjusting Machines 18

  23. Consistency theorem, Part 1: No Reuse Trace Input Self-adj. Machine Run Output � � Input Output Reference Machine Run Self-adjusting machine is consistent with reference machine when self-adjusting machine runs “from-scratch”, with no reuse Matthew A. Hammer Self-Adjusting Machines 19

  24. Consistency theorem, Part 2: Reuse vs No Reuse Trace 0 Input Self-adj. Machine Run Trace Output � � Input Self-adj. Machine Run Trace Output Self-adjusting machine is consistent with from-scratch runs When it reuses some existing trace Trace 0 Matthew A. Hammer Self-Adjusting Machines 20

  25. Consistency theorem: Main result Trace 0 Trace Input Tracing Machine Run ( P ) Output � � Input Reference Machine Run ( P ) Output Main result uses Part 1 and Part 2 together: Self-adjusting machine is consistent with reference machine Matthew A. Hammer Self-Adjusting Machines 21

  26. Concrete Self-adjusting machines Matthew A. Hammer Self-Adjusting Machines 22

Download Presentation
Download Policy: The content available on the website is offered to you 'AS IS' for your personal information and use only. It cannot be commercialized, licensed, or distributed on other websites without prior consent from the author. To download a presentation, simply click this link. If you encounter any difficulties during the download process, it's possible that the publisher has removed the file from their server.

Recommend


More recommend