The world’s first workshop—that I know of!—on approximate computing was this week. WACAS 2014 was a great success. We had a fantastic program of 19 papers and dozens of spectators in attendance.
Here are a few notes on some topics that came up during the workshop. (This isn’t meant to be my “best papers” list; just a list of those moments I had thoughts worth writing about.)
Infrastructure
Approximate computing as a research topic is picking up steam. As it gains popularity, the need for reusable research tools—compilers, simulators, benchmarks, and the like—will grow.
There were two projects that reused the EnerJ infrastructure for experimental evaluation: ExpAX from Georgia Tech and load value approximation from Toronto. My heart goes out to those poor souls who had to cope with the duct-tape-and-baling-twine monstrosity that I produced as a first- and second-year grad student.
There’s also a new infrastructure on the block: iACT from Intel is an LLVM-based system for expressing and simulating some approximation strategies.
Customers
Lakshmi’s paper was partially about finding “customers” for approximation within IBM and the predictably frustrating challenges involved in convincing people to take it on. Asit, in the context of the iACT paper, mentioned disheartening survey results suggesting that programmers respond conservatively when confronted with the idea of approximate programming.
Definitions
The discussion (a “panel” with no panelists) at the end of the day was varied, entropic, and fascinating. Predictably, the topic turned at one point to definitions: what is approximate computing, anyway?
Definitional disagreements are not worth spending too much time on, but I thought I’d try my hand at a succinct description in light of that discussion:
Approximate computing is about abstractions that include error. In approximate computing, systems hope to improve efficiency by propagating error to other layers. (This includes hardware exposing errors to software or software to other software.) Those other layers then need to deal with error—either by suppressing it or passing it down the line, possibly all the way to the end user.
If your interface promises that errors effectively never happen—if it encapsulates any potential misbehavior—then you’re not doing approximate computing.
Connection to Resilience
An important challenge in approximate computing is understanding quality degradations at run time. It would be useful for many reasons to raise an exception when things fall outside of a prescribed error bound. Beayna’s paper brought this issue up. Sarita suggested that we take inspiration from hardware resilience techniques like symptom-based detection.