modeling checking approximate computing
play

Modeling/Checking Approximate Computing Sara Achour, David Bindel, - PowerPoint PPT Presentation

Modeling/Checking Approximate Computing Sara Achour, David Bindel, Luis Ceze, Eva Darulova, Andreas Gerstlauer, Karthik Pattabiraman, Ulya Karpuzcu, Subhasish Mitra Goal overview Paper 1: Modeling Approximation Errors at the ISA - Goal:


  1. Modeling/Checking Approximate Computing Sara Achour, David Bindel, Luis Ceze, Eva Darulova, Andreas Gerstlauer, Karthik Pattabiraman, Ulya Karpuzcu, Subhasish Mitra

  2. Goal overview

  3. Paper 1: Modeling Approximation Errors at the ISA - Goal: Generic Interface for Modeling Error Propagation from H/w to S/w - Inputs: Hardware Error Model (function of the approximation technique and the design specifics) - Output: Error map at the instruction granularity, or at level of data variables, or at the accelerator level - Challenge: Level of accuracy needed Vs. Complexity Vs. Scalability - Method: Given a model validator (e.g., fault injection at the RTL level), and an approximation driver, sample the outcome and test fidelity of model. Iterate. Counter-example guided refinement of the model - Use1: Program uses model to drive approximation decisions, or to verify the approximate version of the program without going through the simulation loop - Use2: Approx. HW + Precise SW vs. Approx. HW + Approx. SW

  4. Paper 2: Novel Iterative Linear Solvers for Approximate Hardware - Goal: Time/energy/memory efficient methods for solving linear systems - Inputs: Hardware error model - deterministic and non-deterministic errors, high level solver knowledge - Output: Tolerant method with probabilistic execution times (+ high probability eventual correctness) - Challenge: Balancing numerical stability vs recovery, overall cost efficiency

  5. Abstract In domains from scientific computing to graph analytics, the solution of large, sparse linear systems of equations is a common building block for many methods. The goal of this paper is to adapt state-of-the art iterative solvers to run on approximate hardware, and to explore the tradeoffs between time, energy, and memory usage when using this hardware. Our approach assumes that an informed user provides an appropriate preconditioner (approximate solver) that can be computed with deterministic and non-deterministic approximations at the hardware level. Given a model of the nature and frequency of deterministic and non-deterministic errors, along with assurances that we can compute a precise residual to the system, we describe a solver approach that converges with high probability, with faster convergence when there are fewer errors. We emphasize a novel tradeoff between numerical stability in the method and ability to detect and recover from memory errors.

  6. Approximation Types and Abstractions - 1 - Logic Modifications (e.g., reduced precision, accelerators) - Yes - Logic: Electrical effects - V_dd (yes, http://lava.cs.virginia.edu/VoltSpot/) - Timing (yes, if the hardware was designed appropriately) - Use of defective chips (yes) - Functional but non-deterministic (yes) - Mixed mode (noise) - Memories - Refresh rate (DRAM): Yes - MLC: Yes - V_dd and timing (SRAM): Yes - Density (???) - Relaxed access (yes) - Selective ECC (yes)

  7. Approximation Types and Abstractions - 2 - Sensors - Compressed sensing (yes) - Arrays (yes) - Imprecise sampling (yes) - - Displays - Pixels off (yes) - Color shift (yes) - Back Light (yes) - - For each of the above: consider cost, energy, performance, density, errors - Big question: How much accuracy do we need for the model to be useful?

  8. QoR discussion QoR definition is application-dependent Specs for: (1) what is catastrophic, (2) score for acceptable outputs, (3) average-case/worst-case QoR Components: actual bits, variance Detection is application-dependent Correction is application-dependent Re-execution (complete or partial), extra iterations, redundancy Checkpointing (what granularity?)

  9. Tolerance Specification Define what statistic is more important (time, energy, cost) x (average, worst-case) Define boundaries of allowed “regions” in the trade-off Aspects of the output that are not covered by QoR (variance, probability of catastrophic output) “Worst-case” QoR?

  10. Case study: Iterative solvers (optimizations, physics simulations, graph analytics) QoR spec: how close to satisfying equations? number of mismatches? largest mismatch? Cost: number of iterations, convergence Relevant approximations: variable bitwidth support (det/non-det), voltage scaling general reliability), memory (abstracted as arithmetic errors), communication (SGD) QoR checking process: natural check (solved equations?), predict number of extra iterations?

  11. References Var Bit Width http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=845894 Minerva: Certainty tracking can be turned off http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=6176987 https://homes.cs.washington.edu/~luisceze/approx-darpa-report.pdf

Recommend


More recommend