Intermittent computing

Overview

Some devices take their power from light, vibration or radio waves. The supply is weak and unstable, so the device runs in short bursts between power failures. Each burst has a fixed energy budget, and any progress must be saved to non-volatile memory and recovered after the next outage [arxiv:2407.14514 §2.1] §2.3.

The invariant all variants share: a computation is cut into pieces that fit one power-on period, and the state after each piece survives a power loss. The open design question is how to pick the network and the schedule so that the pieces fit the energy and the working memory 2407.14514 §1.

This page is based on one paper card. Other approaches are not covered yet.

Variants

Intermittent-aware neural architecture search (iNAS)

The search baseline. A controller proposes a child network. For each child, a design explorer picks how progress is preserved and how work is executed, and a performance model estimates the energy per power cycle and the end-to-end latency 2407.14514 §4.1. The paper names this method as its baseline but does not give its own card here, so it is not summarised further.

Accelerated intermittent NAS

The variant from Accelerate Intermittent Deep Inference. It keeps the iNAS search and changes three things 2407.14514 §4.2:

• Distil and shrink a teacher first. The teacher is MCUNetV1-Int2 in float16. The student is pruned by more than 80% of its parameters, its weights are shared, and its kernel, depth and channel dimensions are shrunk before the search 2407.14514 §4.2 §5.3.
• A stronger controller. The paper proposes an evolutionary or Bayesian controller in place of the RNN. It is not evaluated 2407.14514 §4.2.
• A solution dumper. After the search, one C file and one header hold the weights and the network structure, using TI's DSPLib on the MSP430 2407.14514 §4.2.

It also adds a larger batch per power cycle, called hyper-tile. Fine tiles mean more data fetches, so the paper uses bigger tiles to do more work in each power-on period 2407.14514 §3.1 §4.3. No batch size is given.

The paper also describes a real-time scheduling framework with worst-case execution time and deadline checks 2407.14514 §3.1. It gives no schedulability test, so it cannot be implemented from the text alone.

When to use which

The paper reports accuracy on a PC and latency on the MSP430, in different setups. Do not treat the two as one measurement 2407.14514 §5.4 §5.6.

Implementation sketch

Reconstructed from the paper's description of intermittent execution. The tile size is a free choice, and the paper gives no value [arxiv:2407.14514 §4.3]. The energy check is an abstraction; the paper does not say how it is measured.

# Intermittent execution loop  [arxiv:2407.14514 §2.1] [§2.3]
# Input: list of tiles (layer work pieces); non-volatile store (NVM)

def run_intermittently(tiles, nvm):
    # Resume from the last saved tile after a power loss  [§2.1]
    next_tile = nvm.load_progress()
    while next_tile < len(tiles):
        # Each power-on period has a fixed energy budget  [§2.1]
        if not energy_left_this_cycle():
            wait_for_power()
            continue
        # Compute one tile, then save its result before the next one  [§2.3]
        result = compute(tiles[next_tile])
        nvm.save(next_tile, result)
        next_tile += 1
    return nvm.load_result()

Bigger tiles (hyper-tile) do more work per power-on period and fetch less often, at the cost of more working memory 2407.14514 §3.1 §4.3.

Contradictions

None known across papers: only one card covers this concept. Within the one paper, §3.2 describes storing weights as CSV files, while §4.2 writes a single header file 2407.14514 §3.2 §4.2.

Papers

• Accelerate Intermittent Deep Inference: accelerated intermittent NAS for an MSP430 with about 2 KB of runtime SRAM. Author-reported; no official code.