1. EnerJ: Approximate Data Types for Safe and General Low-Power Computation (PLDI’2011) Adrian Sampson, Werner Dietl, Emily Fortuna Danushen Gnanapragasam, Luis Ceze, Dan Grossman University of Washington Presented by Xianwei Zhang

2. Overview  Observations o Energy is an increasing concern in computer systems (phones, data centers, etc) o Systems spend a significant amount of energy guaranteeing correctness o Many applications have high tolerance to run-time faults.  Challenge to exploit energy-accuracy tradeoff o Isolate parts of the program that must be precise from those that can be approximated so that a program functions correctly even QoS degrades.  Contributions o Propose a safe and general model for approximate programming o Present EnerJ, an extension of Java with type qualifiers o Demonstrate effectiveness using proposed approximation-aware architecture. 2/20/2016 2 Presented by Xianwei Zhang

3. Perfect Correctness is Not Always Required  No perfect answers or hard to get perfect answers o Heuristic algorithms, inherent incorrectness.  Care more about aggregate trends o Large-scale data analytics, trends instead of individual data elements. 2/20/2016 3

4. Not All Data Are Error Resilient  Non-critical portion - safely to do approximation o E.g., errors in output pixel data are tolerable and even undectable.  Critical portion - must be protected from error o Small errors in image format make the output unreadable. 2/20/2016 4 ✗ ✓

5. Type System for Approximate Computation  Safety o Separate critical and non-critical program components.  Generality o A range of approximation strategies supported with a single abstraction.  EnerJ, an extension to Java that adds approximate data types. o Type qualifiers o Endorsement o Operator overloading o Prevention of implicit flows o Objects: qualifier polymorphism 2/20/2016 5

6. Type Qualifiers @Approx int a = …; @Precise int p = …; p = a; a = p; 2/20/2016 6  Every value has an approximate or precise type  Precise types are the default, @Approx is made explicit  Illegal to assign approx into a precise-typed variable ✓ ✗

7. Endorsement: Escape Hatch @Approx int a = expensiveCal(); int p; //precise by default p = endorse (a); //legal quickChecksum (p); output (p); 2/20/2016 7  Fully isolating approx and precise parts is not very useful o Programs usually have a phase of fault-tolerant computation followed by a phase of fault-sensitive reduction or output o E.g., image manipulation phase, then a critical checksum over the result.  Programmer controls explicitly when approx data can affect precise state

8. Logic Approximation: Overloading @Approx int a = …; int p = …; p + p; +: @Precise int, @Precise int  @Precise int p + a; a + a; +: @Approx int, @Approx int  @Approx int 2/20/2016 8  Overload operators and methods based on type qualifiers o E.g., two signatures for + operator on integers.

9. Control Flow @Approx int a = …; int p = …; if (a == 10) { p = 2; } 2/20/2016 9  Disallow implicit flows that occur via control flow o While p is precise and no assignment is present, its value is affected.  The restriction is conservative o Prohibits approx conditions even when the result can affect only approx.  Work around the restriction using endorse @Approx int a = …; int p = …; if (endorse (a == 10)) { p = 2; } ✗ ✓

10. Objects @Approximable class FloatSet { @Context float[] nums = …; float mean() { calculate mean } @Approx float mean_APPROX() { take mean of first 1/2 } 2/20/2016 10  Classes also support approximation o @Approximable: enable approx or precise instances o @Context: non-static members, depends on the instance’s type o _APPROX: specialize method definitions based on class type qualifier. @Precise FloatSet pSet; pSet.mean(); //mean @Approx FloatSet aSet; aSet.mean(); //mean_APPROX

11. Architectural Approximation  Approximate storages o Registers: precise and approx are distinguished using register number o Cache and memory: distinguished by address.  Approximate operations o Approx instructions use special FUs that perform approx operations. 2/20/2016 11

12. Hardware Techniques for Saving Energy  Voltage scaling in logic circuits  Width reduction is FP operations  DRAM refresh rate  SRAM supply voltage 2/20/2016 12

13. Implementation  Annotation o Manually annotate each application using EnerJ o Focused on critical code where most of the time is spent.  Simulation o Implemented a compiler and runtime system that executes EnerJ code o Utilize instrumentation calls to inject transient faults to emulate approx.  Approximation o Reduce FP bit-width, flip bit of accesses into SRAM and DRAM o Assumption: heap data in DRAM, stack data in SRAM. 2/20/2016 13

14. Annotated Declarations  Primary approx data is in a small portion of code  Annotations are sparse and straightforward to insert 2/20/2016 14

15. Energy Savings  Save 9%-48% of total execution energy  Majority of savings come from Base to Mild 2/20/2016 15

16. Output Error  Metric: compare approx result against precise one  “Mild” configuration is a good fit for all 2/20/2016 16

17. Summary  Approximate computing is promising o A new way to save energy in large classes of applications.  Proposed type system o Variables and objects can be declared as approx or precise o Safe: guarantees precise unless given explicit programmer permission o General: unifies approx data storage, approx computation and approx algs.  Implementations and evaluations o Implemented the type system atop of Java and tested with several apps o Annotations are easy to insert o For annotated programs, the runtime system or arch can choose multi approx execution techniques o Hardware-based model shows potential energy savings in 9%-48% range. 2/20/2016 17 Presented by Xianwei Zhang