1 / 41

The SEEC Computational Model

The SEEC Computational Model. Henry Hoffmann, Anant Agarwal PEMWS-2 April 6, 2011. In the beginning…*. Application programmers had one goal:. Performance. *The beginning, in this case, refers to the beginning of my career (1999). beat/s. Lo. Hi. Power.

jock
Download Presentation

The SEEC Computational Model

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. The SEEC Computational Model Henry Hoffmann, AnantAgarwal PEMWS-2 April 6, 2011

  2. In the beginning…* Application programmers had one goal: Performance *The beginning, in this case, refers to the beginning of my career (1999)

  3. beat/s Lo Hi Power But Modern Systems Have Increased the Burden on Application Programmers Power Resiliency Many additional constraints Quality Performance Even worse, constraints can change dynamically E.g. power cap, workload fluctuation, core failure

  4. Most Execution Models Designed for Performance Coherent Shared Memory Message Passing Global Shared Cache data Core 0 Core 1 Core 0 Core 1 Local Memory Local Memory Local Cache Local Cache data data data data Network store store load load Network Interface Network Interface RF RF RF RF Concurrency Multi-threaded Multi-process Communication Through Network Through Memory Coordination Locks Messages Control Procedural Procedural Procedural control insufficient to meet the needs of modern systems

  5. Angstrom Replaces Procedural Control with Self-Aware Control Procedural Control Self-Aware Control Observe Decide Decide Act Act • Run in closed loop • Understand user goals • Monitor the environment • Run in open loop • Assumptions made at design time • Based on guesses about future • Application optimized for system • No flexibility to adapt to changes • System optimizes for application • Flexibly adapt behavior The self-aware model allows the system to solve constrained optimization problems dynamically

  6. Outline Introduction/Motivating Example The SEEC Model and Implementation Experimental Validation Conclusions 7

  7. Angstrom’s SElf-awarE Computing (SEEC) Model • Goal: Reduce programmer burden by continuously optimizing online • Key Features: • Applications explicitly state goals and progress • System software and hardware state available actions • The SEEC runtime system dynamically selects actions to maintain goals Observe Act Decide Application Developer Systems Developer API SPI SEEC Runtime A unified decision engine adapts applications, system software, and hardware

  8. Example Self-Aware System Built from SEEC Observe Video Encoder 20 b/s 30 b/s 33 b/s Goals: 30 beat/s, Minimize Power Decide Act Control and Learning System Actuators Algorithm Cores Frequency Bandwidth

  9. Roles in the SEEC Model Observe Decide Act

  10. Lo Hi Power Registering Application Goals Observe Application SEEC Decision Engine • Performance • Goals: target heart rate and/or latency between tagged heartbeats • Progress: issue heartbeats at important intervals • Quality • Goals: distortion (distance from application defined nominal value) • Progress: distortion over last heartbeat • Power • Goals: target heart rate / Watt and/or target energy between tagged heartbeats • Progress: Power/energy over last heartbeat interval Performance Quality Power Research to date focuses on meeting performance while minimizing power/maximizing quality

  11. Registering System Actions Act Each action has the following attributes: • Estimated Speedup • Predicted benefit of taking an action • Cost • Predicted downside of taking an action (increased power, lowered quality) • Callback • A function that takes an id an implements the associated action SEEC Decision Engine Actuators Estimated Speedup Cost Algorithm Cores Callback Frequency Bandwidth

  12. Lo Hi Power Picking Actions to Meet Goals Decide Application Decisions are made to select actions given observations: • Read application goals and heartbeats • Determine speedup with control system • Translate speedup into one or more actions SEEC Decision Engine System Services Controller (Decide) Actuator (Act) Application (Observe) Performance Goal - Current Performance The control system provides predictable and analyzable behavior

  13. Optimizing Resource Allocation with SEEC • SEEC can observe, decide and act • How does this enable optimal resource allocation? • Let’s implement the video encoder example from the introduction

  14. Performance/Watt Adaptation in Video Encoding 0 2 4 80 180 70 60 170 50 160 Performance (Frame/s) 40 30 150 20 140 10 0 130 50 150 250 350 450 Time (Heartbeat) Time (s) 6 8 10 12 14 16 Performance Power Power (W) Performance goal

  15. System Models in SEEC SEEC’s control system takes actions based on models (of speedup and cost per action) associated with actions What if the models are inaccurate? 16

  16. Lo Hi Power Updating Models in SEEC Decide Adaptation Level 2 System Model (Decide) SEEC Decision Engine Application • After every action, SEEC updates application and system models • Kalman filters used to estimate true state of application and system • We are exploring a number of different alternatives here System Services Adaptation Level 1 Application Model (Decide) Adaptation Level 0 Controller (Decide) Actuator (Act) Application (Observe) Performance Goal - Current Performance SEEC combines predictability of control systems with adaptability of learning systems

  17. SEEC Online Learning of Speedup Model for Application with Local Minima

  18. Lo Lo Lo Lo Hi Hi Hi Hi Power Power Power Power Handling Multiple Applications Decide Adaptation Level 2 System Model (Decide) SEEC Decision Engine Application Application Application Application System Services Adaptation Level 1 Application Model (Decide) Adaptation Level 0 Controller (Decide) Actuator (Act) Application (Observe) Performance Goal • Control actions computed separately for each application • For finite resources, several alternatives: • Priorities (for real-time, admission control) • Weighting/Centroid method (for overall system throughput) - Current Performance 19

  19. Outline Introduction/Motivating Example The SEEC Model and Implementation Experimental Validation Conclusions 20

  20. Systems Built with SEEC 21

  21. Systems Built with SEEC 22

  22. Dynamic Knobs: Creating Adaptive Applications Turn static command line parameters into dynamic structure Application Goals Maintain performance and minimize quality loss Adjust memory locations to change application settings System Actions Benchmarks: bodytrack, swaptions, SWISH++, x264 Maintain performance when clock speed changes Experiment Detail in Hoffmann et al. “Dynamic Knobs for Power Aware Computing” ASPLOS 2011 23

  23. ResultsEnabling Dynamic Applications bodytrack Clock rises 1.6-2.4 GHz SEEC returns quality to baseline Clock drops 2.4-1.6GHz w/ SEEC perf. recovers w/o SEEC perf. drops

  24. ResultsEnabling Dynamic Applications SWISH++ swaptions x264 Maintains performance despite noise Maintains baseline performance Perfect behavior Dynamic knobs automatically enable dynamic response for a range of applications using a single mechanism

  25. Optimizing Performance per Watt for Video Encoding Adapt system behavior to needs of individual inputs Application Goals Maintain 30 frame/s while minimizing power Change cores, clock speed, and memory bandwidth System Actions Benchmark: x264 w/ 16 different 1080p inputs Compare performance/Watt w/ SEEC to best static allocation of resources for each input Experiment 26

  26. Average Performance per Watt for Video Encode

  27. Performance per Watt for All Inputs

  28. Learning Models Online Adapt system behavior when initial models are wrong Four targets: Min, Median, Max, Max+ Minimize power consumption for each target Application Goals Change cores, clock speed, and mem. bandwidth Initial models are incredibly optimistic (Assume linear speedup with any resource increase) System Actions Benchmark: STREAM Converge to within 5% of target performance, measure power and convergence time Experiment 29

  29. Complex Response to Resources Adding Cores Can Slow the App Down Adding Memory Bandwidth Can Slow Down

  30. Power Savings

  31. Convergence Time

  32. Managing Application and System Resources Concurrently Manage multiple applications when clock frequency changes bodytrack: maintain performance, minimize power x264: maintain performance, minimize quality loss Application Goals Change core allocation to both applications Change x264’s algorithms System Actions Maintain performance of both applications when clock frequency changes Experiment 33

  33. ResultsSEEC Management of Multiple Applications bodytrack x264 SEEC allocates cores to bodytrack SEEC removes cores from x264 Clock drops 2.4-1.6GHz SEEC adjusts algorithm to meet goals w/o SEEC app misses goals w/o SEEC app exceeds goals 34

  34. Summary of Case Studies

  35. Outline Introduction/Motivating Example The SEEC Framework Experimental Validation Conclusions 36

  36. Angstrom’s Hardware Support for Self-Awareness • “If you want to change something, measure it.” • We need sensors to measure everything we want to manage: • Performance (there is a rich body of work in this area) • Power • Quality • Resiliency • …

  37. Need Performance-level Support for Power Analysis • gprof -> pprof? index % time self children called name Power?? Energy??? <spontaneous> ----------------------------------------------- 0.00 0.05 1/1 main [2] [1] 100.0 0.00 0.05 1 report [3] 0.00 0.03 8/8 timelocal [6] 0.00 0.01 1/1 print [9] 0.00 0.01 9/9 fgets [12] 0.00 0.00 12/34 strncmp <cycle 1> [40] 0.00 0.00 8/8 lookup [20] 0.00 0.00 1/1 fopen [21] 0.00 0.00 8/8 chewtime [24] 0.00 0.00 8/16 skipspace [44] ----------------------------------------------- [2] 59.8 0.01 0.02 8+472 <cycle 2 as a whole> [4] 0.01 0.02 244+260 offtime <cycle 2> [7] 0.00 0.00 236+1 tzset <cycle 2> [26] -----------------------------------------------

  38. Angstrom’s Hardware Support for SEEC Low-power core for SEEC runtime system

  39. Angstrom’s System Software and Hardware Support for SEEC Enable tradeoffs wherever possible Support fine-grain allocation of resources Actuators Algorithm Cores Cache Network Bandwidth TLB Size Frequency Memory Bandwidth Registers ALU Width …

  40. SEEC is designed to help ease programmer burden Solves resource allocation problems Adapts to fluctuations in environment SEEC has three distinguishing features Incorporates goals and feedback directly from the application Allows independent specification of adaptation Uses an adaptive second order control system to manage adaptation Demonstrated the benefits of SEEC in several experiments SEEC can optimize performance per Watt for video encoding SEEC can adapt algorithms and resource allocation to meet goals in the face of power caps or other changes in environment SEEC navigates tradeoff spaces So build more tradeoffs into apps, system software, system hardware, etc. Conclusions 41

  41. SEEC References • Application Heartbeats Interface: • Hoffmann, Eastep, Santambrogio, Miller, Agarwal. Application Heartbeats: A Generic Interface for Specifying Program Performance and Goals in Autonomous Computing Environments. ICAC 2010 • Controlling Heartbeat-enabled Systems: • Maggio, Hoffmann, Santambrogio, Agarwal, Leva. Controlling software applications within the Heartbeats framework. CDC 2010 • Maggio, Hoffmann, Agarwal, Leva. Control theoretic allocation of CPU resources. FeBID 2011 • Creating Adaptive Applications: • Hoffmann, Misailovic, Sidiroglou, Agarwal, Rinard. Using Code Perforation to Improve Performance, Reduce Energy Consumption, and Respond to Failures. MIT-CSAIL-TR-2209-042. 2009 • Hoffmann, Sidiroglou, Carbin, Misailovic, Agarwal, Rinard. Dynamic Knobs for Power-Aware Computing. ASPLOS 2011. • The SEEC Framework: • Hoffmann, Maggio, Santambrogio, Leva, Agarwal. SEEC: A Framework for Self-aware Management of Multicore Resources. MIT-CSAIL-TR-2011-016 2011. • Hoffmann, Maggio, Santambrogio, Leva, Agarwal. SEEC: A Framework for Self-aware Computing. MIT-CSAIL-TR-2010-049 2010. 42

More Related