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

▶
self adjusting machines
SMART_READER_LITE
LIVE PREVIEW

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

Mar 30, 2024 122 likes •573 views

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

slide-1
SLIDE 1

Self-Adjusting Machines

Matthew A. Hammer

University of Chicago Max Planck Institute for Software Systems

Thesis Defense July 20, 2012 Chicago, IL

slide-2
SLIDE 2

Static Computation Versus Dynamic Computation

Static Computation: Fixed Input Compute Fixed Output Dynamic Computation: Changing Input Compute Changing Output Read Changes Update Write Updates

Matthew A. Hammer Self-Adjusting Machines 2

slide-3
SLIDE 3

Dynamic Data is Everywhere

Software systems often consume/produce dynamic data Scientific Simulation Reactive Systems Analysis of Internet data

Matthew A. Hammer Self-Adjusting Machines 3

slide-4
SLIDE 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

slide-5
SLIDE 5

Tractability Requires Dynamic Computations

Changing Input Compute Changing Output Read Changes Update Write Updates Static Case (Re-evaluation “from scratch”) compute 1 sec # of changes 1 million Total time 11.6 days Dynamic Case (Uses update mechanism) compute 10 sec update 1 × 10−3 sec # of changes 1 million Total time 16.7 minutes Speedup 1000x

Matthew A. Hammer Self-Adjusting Machines 4

slide-6
SLIDE 6

Dynamic Computations can be Hand-Crafted

As an input sequence changes, maintain a sorted output. 1,7,3,6,5,2,4 Changing Input compute 1,2,3,4,5,6,7 Changing Output 1,7,3,6 /,5,2,4 Remove 6 update 1,2,3,4,5,6 /,7 1,7,3,6,5,2 /,4 Reinsert 6, Remove 2 update 1,2 /,3,4,5,6,7 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

slide-7
SLIDE 7

Self-Adjusting Computation

Offers a systematic way to program dynamic computations Self-Adjusting Program Domain knowledge + Library primitives 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

slide-8
SLIDE 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

slide-9
SLIDE 9

Thesis statement

By making their resources explicit, self-adjusting machines give an

  • perational 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

slide-10
SLIDE 10

Example: Dynamic Expression Trees

Objective: As tree changes, maintain its valuation

+ − + 3 4 − 5 6

((3 + 4) − 0) + (5 − 6) = 6

+ − + 3 4 + − 5 6 5

((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

slide-11
SLIDE 11

Expression Tree Evaluation in C

1 typedef struct node s* node t; 2 struct node s { 3 enum { LEAF, BINOP } tag; 4 union { int leaf; 5 struct { enum { PLUS, MINUS } op; 6 node t left, right; 7 } binop; } u; } 1 int eval (node t root) { 2 if (root->tag == LEAF) 3 return root->u.leaf; 4 else { 5 int l = eval (root->u.binop.left); 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

slide-12
SLIDE 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

slide-13
SLIDE 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

slide-14
SLIDE 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

slide-15
SLIDE 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

slide-16
SLIDE 16

Dynamic Execution Traces

Input Tree + − + 3 4 − 5 6 Execution Trace

A+ B+ C+ A− B− C− A− B− C− A+ B+ C+ A0 A5 A6 A3 A4

Matthew A. Hammer Self-Adjusting Machines 12

slide-17
SLIDE 17

Updating inputs, traces and outputs

+ − + 3 4 − 5 6 + − + 3 4 + − 5 6 5 A+ B+ C+ A− B− C− A+ B+ C+ A+ B+ C+ A0 A− B− C− A5 A3 A4 A5 A6

Matthew A. Hammer Self-Adjusting Machines 13

slide-18
SLIDE 18

Core self-adjusting primitives

Stack operations: push & pop Trace checkpoints: memo & update points memo update (new evaluation) memo update A+ B+ C+ A− B− C− A+ B+ C+ A+ B+ C+ A0 A− B− C− A5 A3 A4 A5 A6

Matthew A. Hammer Self-Adjusting Machines 14

slide-19
SLIDE 19

Abstract model: Self-adjusting machines

Matthew A. Hammer Self-Adjusting Machines 15

slide-20
SLIDE 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

slide-21
SLIDE 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

slide-22
SLIDE 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

slide-23
SLIDE 23

Consistency theorem, Part 1: No Reuse

Trace Input Self-adj. Machine Run Output

  • Input

Reference Machine Run Output 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

slide-24
SLIDE 24

Consistency theorem, Part 2: Reuse vs No Reuse

Trace0 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 Trace0

Matthew A. Hammer Self-Adjusting Machines 20

slide-25
SLIDE 25

Consistency theorem: Main result

Trace0 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

slide-26
SLIDE 26

Concrete Self-adjusting machines

Matthew A. Hammer Self-Adjusting Machines 22

slide-27
SLIDE 27

From abstract to concrete machines

Overview of design and implementation

◮ Abstract model guides design ◮ Compiler addresses static aspects ◮ Run-time (RT) addresses dynamic aspects

Phases

◮ Front-end translates CEAL surface language into IL ◮ Compiler analyses and transforms IL ◮ Compiler produces C target code, links with RT library ◮ Optional optimizations cross-cut compiler and RT library

Matthew A. Hammer Self-Adjusting Machines 23

slide-28
SLIDE 28

Compiler transformations

Destination-passing style (DPS) conversion

◮ Required by our abstract model ◮ Converts stack dependencies into memory dependencies ◮ Inserts additional memo and update points

Normalization

◮ Required by C programming model ◮ Lifts update points into top-level functions ◮ Exposes those code blocks for reevaluation by RT

Matthew A. Hammer Self-Adjusting Machines 24

slide-29
SLIDE 29

Compiler analyses

Compiler analyses

◮ guide necessary transformations ◮ guide optional optimizations

Special uses memo/update analysis selective DPS conversion live variable analysis translation of memo/update points dominator analysis normalization, spatial layout of trace

Matthew A. Hammer Self-Adjusting Machines 25

slide-30
SLIDE 30

From compiler to run-time system

Trace nodes

◮ Indivisible block of traced operations ◮ Operations share overhead (e.g., closure information) ◮ Compiler produces trace node descriptors in target code

Run-time system

◮ RT interace based on trace node descriptors (from compiler)

redo callback — code at update points undo callback — revert traced operations

◮ Change propagation incorporates garbage collection

Matthew A. Hammer Self-Adjusting Machines 26

slide-31
SLIDE 31

Optimizations

Sparser traces — avoid tracing when possible

  • 1. Stable references

Programmer uses type qualifier

  • 2. Selective DPS

Compiler analysis of update points Cheaper traces — more efficient representation

  • 3. Write-once memory

Programmer uses type qualifier

  • 4. Trace node sharing

Compiler analysis coalesces traced ops

Matthew A. Hammer Self-Adjusting Machines 27

slide-32
SLIDE 32

Evaluation

Matthew A. Hammer Self-Adjusting Machines 28

slide-33
SLIDE 33

From-scratch time: Constant overhead

0.0 0.2 0.4 0.6 0.8 1.0 1.2 1.4 1.6 250K 500K 750K Time (s) Input Size Exptrees From-Scratch Self-Adj Static

Matthew A. Hammer Self-Adjusting Machines 29

slide-34
SLIDE 34

Average update time: Constant time

0.011 0.012 0.013 0.014 0.015 0.016 0.017 0.018 0.019 0.020 0.021 0.022 250K 500K 750K Time (ms) Input Size Exptrees Ave Update Self-Adj

Matthew A. Hammer Self-Adjusting Machines 30

slide-35
SLIDE 35

Speed up = From-scratch / Update

0.0 x 100 5.0 x 103 1.0 x 104 1.5 x 104 2.0 x 104 2.5 x 104 250K 500K 750K Speedup Input Size Exptrees Speedup Self-Adj

Matthew A. Hammer Self-Adjusting Machines 31

slide-36
SLIDE 36

Evolution of our approach

Stage 1: First run-time library + Change propagation & memory management − Very high programmer burden Stage 2: First compiler + Lower programmer burden − No return values − Memo points are non-orthogonal (conflated with read and alloc primitives) − No model for consistency or optimizations Stage 3: New compiler & run-time library + Self-adjuting machine semantics guides reasoning about consistency & optimizations + Very low programmer burden

Matthew A. Hammer Self-Adjusting Machines 32

slide-37
SLIDE 37

Stage 1, RT library: vs SML library

50 100 150 50 100 150 200 250 300 Time (s) Input Size (n × 103) Quicksort From-Scratch SML+GC SML-GC C 5 10 15 50 100 150 200 250 300 Time (ms) Input Size (n × 103) Quicksort Ave. Update SML+GC SML-GC C

◮ SML-GC is comparable to C ◮ SML+GC are 10x slower

Matthew A. Hammer Self-Adjusting Machines 33

slide-38
SLIDE 38

Stage 2, Basic compiler: CEAL vs Delta-ML

Normalized Measurements [(CEAL / DeltaML) × 100] App. From-Scratch

  • Ave. Update

Max Live filter 11% 16% 23% map 11% 14% 23% reverse 13% 17% 24% minimum 22% 11% 38% sum 22% 29% 34% quicksort 4% 6% 21% quickhull 20% 30% 91% diameter 17% 23% 67% Averages 15% 18% 40%

Matthew A. Hammer Self-Adjusting Machines 34

slide-39
SLIDE 39

Stage 3, Machine model: Multiple targets

  • 1. Stable references

Programmer uses type qualifier

  • 2. Selective DPS

Compiler analysis of update points

  • 3. Write-once memory

Programmer uses type qualifier

  • 4. Trace node sharing

Compiler analysis coalesces traced ops

Matthew A. Hammer Self-Adjusting Machines 35

slide-40
SLIDE 40

Stage 3, Machine model: Average update times

0.0 0.2 0.4 0.6 0.8 1.0 exptrees map reverse filter sum minimum quicksort mergesort quickhull diameter distance mean Update Time (norm. by no−opt)

all−opt no−seldps no−share no−stable no−owcr

Matthew A. Hammer Self-Adjusting Machines 36

slide-41
SLIDE 41

Stage 3, Machine model: Maximum live space

0.0 0.2 0.4 0.6 0.8 1.0 exptrees map reverse filter sum minimum quicksort mergesort quickhull diameter distance mean Max Live Space (norm by no−opt)

all−opt no−seldps no−share no−stable no−owcr

Matthew A. Hammer Self-Adjusting Machines 37

slide-42
SLIDE 42

Stage 3, Machine model: Previous approaches

0.0 5.0 10.0 15.0 20.0 25.0 30.0 35.0 25K 50K 75K 100K Time (s) Input Size Quicksort From-Scratch ∆ML all-opt CEAL 0.000 0.200 0.400 0.600 0.800 1.000 1.200 25K 50K 75K 100K Time (ms) Input Size Quicksort Ave Update ∆ML all-opt CEAL ◮ Delta-ML: order of magnitude slower ◮ CEAL (stage 2) slightly faster than all-opt (stage 3)

CEAL uses non-orthogonal allocation primitive

Matthew A. Hammer Self-Adjusting Machines 38

slide-43
SLIDE 43

Thesis statement

By making their resources explicit, self-adjusting machines give an

  • perational 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