PART 12 / Advanced

Neuromorphic computing

Which workloads benefit from moving events instead of repeatedly moving dense tensors?

Illustrated introduction

What you will learn

Write a hardware-neutral workload specification and compare measured whole-system costs.

Before you begin: Spiking neural networks; Connectome programming

Count movement as well as arithmetic

A computation consumes resources when it moves data, stores state and communicates, not only when it multiplies numbers. Event-driven hardware attempts to make activity-dependent work useful. CPUs and GPUs can still be strong choices when dense, regular operations dominate or when software maturity matters more than sparsity.

Architecture before brand names

A neuromorphic processor must place state somewhere, route events, represent weights and handle finite fan-in/fan-out. Quantization and partitioning can alter dynamics. Official Intel research material describes neuromorphic platforms, but hardware access and measured advantages are workload-specific. An architecture diagram should show the host and sensor interfaces alongside the neural cores.

Neural-network perspective

A sparse model is not automatically a sparse execution. A framework might still update every cell on every tick. Conversely, event scheduling has overhead that can exceed dense arithmetic when activity is high. Benchmark spike-rate sweeps and include the costs of encoding, decoding and moving data across the device boundary.

An energy budget you can audit

Energy is average power multiplied by elapsed time over a stated measurement boundary. A fast high-power system may use less energy per task than a slow low-power one. Compare accuracy and task completion first, then explain exactly which components were measured. The calculation below is illustrative, not a hardware claim.

SEE THE RELATIONSHIPS

From structure to behavior.

Hardware: a labelled conceptual diagram
Figure 12.1 · Hardware. Original educational diagram; synthetic, not a measured result.
The reasoning pathModel & workload then Placement & routing then Sensor + host + device then Task energy measurement1. Model & workload2. Placement & routing3. Sensor + host + device4. Task energy measurement
A learning flow for this part. Follow the assumptions through to an observable result.

MAKE THE IDEA PRECISE

The mathematics.

E = P t
Symbols and units
SymbolMeaning
EEnergy, joules
PAverage power over the chosen system boundary, watts
tTask duration, seconds

Build the equation, step by step

  1. Power is energy per unit time. Multiply constant power in watts by duration in seconds to obtain energy in joules.
  2. When power varies, integrate it over the task interval or sum sampled power times the sampling interval.
  3. Measure the same completed workload at comparable output quality. Include acquisition, host processing, transfers and decoding when claiming system-level energy improvement.

WORK THROUGH THE NUMBERS

Worked example

A hypothetical 2 W system running for 0.05 s uses 0.1 J. A hypothetical 0.2 W system running for 1 s uses 0.2 J. Lower instantaneous power does not guarantee lower energy per completed task.

A small Python experiment.

Python 3 · Standard library only · Synthetic educational example. Run this in your own notebook or a local file.

systems = [(2.0, 0.05), (0.2, 1.0)]
for power, seconds in systems:
    print(f"{power*seconds:.2f} J")

Expected output

0.10 J
0.20 J

Change one quantity, predict the result, and then run the code again. Explain any difference before adding complexity.

Test your understanding.

Try it: Add a 1 W host that runs for the same duration. Recompute both whole-system budgets.

Self-check: Can a lower-power device consume more energy for a task?

Yes. A device consuming half the power but taking three times as long uses 1.5 times the energy under the constant-power approximation. Idle time, startup and batching also matter; state the measurement boundary.

Where this model stops: No neuromorphic hardware benchmark or deployment is claimed by this book.

A research question: At what activity rate does event-routing overhead erase a sparse model’s advantage?

Record evidence in your mastery worksheet →

THE NEXT LAYER

Chapter depth map.

This introduction provides a first model. The following chapters are outlines for deeper future editions; their full treatments have not yet been published.

Architecture before chip names

12.1 Events, memory and compute · Outline
  1. 12.1.1 CPU/GPU memory traffic and irregular workloads
  2. 12.1.2 Sparse updates and event routing
  3. 12.1.3 Asynchronous and clocked implementations
  4. 12.1.4 Local memory, fan-in and fan-out limits
  5. 12.1.5 Cases where dense accelerators remain competitive
12.2 Platforms and constraints · Outline
  1. 12.2.1 CPU, GPU, FPGA and ASIC design tradeoffs
  2. 12.2.2 Intel Loihi research architecture and access constraints
  3. 12.2.3 Fixed-point arithmetic and parameter quantization
  4. 12.2.4 Placement, routing and communication congestion
  5. 12.2.5 Toolchain portability and hardware availability checks

Measurement and deployment

12.3 Map a model to hardware · Outline
  1. 12.3.1 Separate model semantics from implementation
  2. 12.3.2 Quantize and test spike timing drift
  3. 12.3.3 Memory estimates and partition boundaries
  4. 12.3.4 Input/output conversion overhead
  5. 12.3.5 Fallback behavior when the platform is unavailable
12.4 Benchmark honestly · Outline
  1. 12.4.1 Latency, throughput and idle power
  2. 12.4.2 Energy per task with sensing and host overhead
  3. 12.4.3 Accuracy and batch-size normalization
  4. 12.4.4 Programmability and deployment effort
  5. 12.4.5 Performance extensions: C++, CUDA, Rust and FPGA concepts after profiling the Python baseline
  6. 12.4.6 Evidence required for any efficiency claim

Read with the original sources.

These readings support the concepts and deeper investigation. The worked numbers and illustrations above are teaching examples.

Official hardware research resource

Intel — neuromorphic computing research ↗

Study event processing, memory and mapping constraints. Do not assume public hardware access or transfer platform-specific energy claims to a new task.

Complete source register →

Where next?