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

modeling checking approximate computing
SMART_READER_LITE
LIVE PREVIEW

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:


slide-1
SLIDE 1

Modeling/Checking Approximate Computing

Sara Achour, David Bindel, Luis Ceze, Eva Darulova, Andreas Gerstlauer, Karthik Pattabiraman, Ulya Karpuzcu, Subhasish Mitra

slide-2
SLIDE 2

Goal overview

slide-3
SLIDE 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
slide-4
SLIDE 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
slide-5
SLIDE 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.

slide-6
SLIDE 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)
slide-7
SLIDE 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?
slide-8
SLIDE 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?)

slide-9
SLIDE 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?

slide-10
SLIDE 10

Case study: Iterative solvers

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?

(optimizations, physics simulations, graph analytics)

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