PYTHON · NUMPY

The multiply is the enemy

Given a tiny edge policy, count its MACs and price them with the Horowitz @45nm energy constants to show that multiplies dominate arithmetic energy (~80%) and that a single DRAM read outweighs every add combined.

01Challenge

Edge AI is usually measured in accuracy and parameters, seldom in joules. Price the joules yourself, and the "intelligence" turns out to be nearly free — the battery is drained by two things: the floating-point multiplier and the wire between memory and the ALU. This lesson makes you an energy accountant for a 640-MAC policy, and the ledger names the enemy ternary is about to delete.

Predict firstOn a battery-powered edge policy running inference, where do most of the joules actually go?

02Model

Here is the uncomfortable arithmetic of edge intelligence. In Horowitz's canonical @45nm measurements (ISSCC 2014), an FP32 multiply costs about 3.7 pJ while an FP32 add costs about 0.9 pJ — so the multiply, one operation, is already ~4x the add. Stack them into a network where every MAC is one multiply plus one add and multiplies eat ~80% of the arithmetic budget. But arithmetic is the cheap part. Reading a single 32-bit word from on-chip SRAM costs ~5 pJ, more than any single op, and reaching out to DRAM costs ~640 pJ — that one fetch outweighs every add in this entire policy combined. This is the memory wall, the von-Neumann bottleneck stated in joules: on battery-powered hardware the energy is burned moving data and multiplying it, not 'thinking.' That reframes the whole game. If the multiply is the single most expensive arithmetic act and data movement dwarfs even that, then the highest-leverage move in physical AI is not a cleverer optimizer — it is to make the multiply disappear and to stop moving weights across the bus. Three states {-1,0,+1} do exactly that: multiply-by-{-1,0,+1} collapses to add / subtract / skip, and a log2(3)=1.585-bit weight barely has to move. You are about to see, in real numbers you compute yourself, why the frontier of edge AI is an energy-accounting frontier — and why ternary sits on the right side of it.

03Guided practice

Worked: A dense layer with i inputs and o outputs performs i*o multiply-accumulates (MACs) — every output is a dot product over all inputs. For a 16->32 layer that is 16*32 = 512 MACs; each MAC is one multiply and one add. We price a multiply at E_MUL = 3.7 pJ and an add at E_ADD = 0.9 pJ (Horowitz @45nm). So layer-1 arithmetic energy = 512*(3.7+0.9).

Your turn: Add the second layer, 32->4, which is 32*4 = 128 MACs, for a total of 640 MACs across the policy. Compute the total multiply energy mul_e = macs*E_MUL and total add energy add_e = macs*E_ADD.

Independent: Fill the gap: express the fraction of arithmetic energy spent on multiplies as arith_share = mul_e/(mul_e+add_e). Confirm it equals 3.7/4.6 ~= 0.804, then check the punchline in the code: one DRAM read (640 pJ) is greater than add_e (all 640 adds = 576 pJ). The multiplier and the memory bus, not the network's depth, are where the joules go.

04Feedback

PASS WHEN Console prints arith_share=0.804 and 'PASS'; the DRAM line reads 640pJ > 576pJ : True.

If your run fails, check:

If arith_share printed 0.000 (still FAIL), you left the placeholder in: replace `arith_share = 0.0` with `arith_share = mul_e/(mul_e+add_e)` so the fraction is computed, not hard-zero.
If arith_share printed ~0.196 instead of 0.804, you inverted the ratio (used add_e in the numerator). The question is the *multiply* share, so multiply energy goes on top: `mul_e/(mul_e+add_e)`.
If you got ~4.111 (a value greater than 1), you wrote `mul_e/add_e` and forgot the sum in the denominator. A share is part-over-whole, so the denominator must be the total: `mul_e/(mul_e+add_e)`.

05Retrieve & space

A colleague says 'our policy is cheap because it's only 640 MACs — arithmetic is nothing.' Using the numbers in this bench, name the operation that costs more energy than all 640 adds put together, and say why that fact is the whole point.
An FP32 multiply is 3.7 pJ and an add is 0.9 pJ. If ternary weights turn every multiply into an add/subtract/skip, roughly what fraction of the *arithmetic* energy could vanish, and why does deleting the multiply matter even more once you remember the DRAM number?

06Mastery & project

You can price a network in joules rather than parameters: count MACs, apply real device constants, and show quantitatively that the multiplier (~80% of arithmetic energy) and the memory bus (one DRAM read > all adds) — not model depth — are where edge energy is spent. That is the problem statement the rest of the course dismantles.

This ledger is the baseline the whole ternary arc attacks. Having proven the multiply and the memory bus are the cost centers, the next lessons show three states {-1,0,+1} turning multiply into add/subtract/skip (killing the 3.7 pJ op) and shrinking the 1.585-bit weight so it barely crosses the bus — converting this energy accounting into the frontier case for ternary edge AI.

GO FURTHER · THE LIVE PLAYGROUND

Drive the live ternary policy ↗ — FP32 vs ternary vs log, trained live
Read the whitepaper ↗ — Multiply-Free Neural Computation (TR-2026-02)

← Bits, trits, and the best radix Three states delete the multiply →

PYTHON · NUMPY

The multiply is the enemy

A tiny 16->32->4 edge policy has exactly 640 MACs. Price it with the cited Horowitz @45nm constants. Fill the one gap so arith_share is the multiply fraction of arithmetic energy; the grader checks it against 3.7/4.6 and confirms a single DRAM read beats every add combined.

You read

the arrays and values already in scope

You change

the code you write in each cell

Fixed

the dataset and the checks that grade you