THE GREAT DESK SHUFFLE / YOU CALL THE SEATS
Is that desk really free?
Drag a coworker to a desk.
Hand over the desk. Keep the work intact.
You choose seats and handovers. Work advances only when you press “Next slot”.
Follow the people and their papers first. The engineering explanation is below when you want it.
First round: a normal handover
Watch three policies ↗More scenarios / desk capacity Nine scenarios. Start with a normal handover.
Changing the scenario or desk count restarts this round. You can finish the first round before exploring.
Your office
Select a coworker → select the first desk → next slot.Or drag a coworker to a desk. Tab and Enter work too.
More actions
History is read-only. To change a decision, return to the present and press Undo.
FINAL ROUND / KPI TRAP
Boss: “Fewer desks. Can we call that faster work?”
Engineering view: what do the desks and documents represent?
In this game,one desk = one illustrative 1 KiB storage region. Coworkers represent work that needs data; document markers represent the contents. Desk numbers translate to offsets only in this explanation. This is not the article’s actual allocation.
An empty chair does not mean there are no future readers. Moving desks copies the current contents; copying damaged data cannot restore the original. The article uses a Tensor Arena with preplanned, fixed offsets. Manual moves in this game do not reproduce that executor or measure copying costs.
| Coworker / document | Desks | Offset / size | Future use / contents |
|---|
Each desk stores a content marker that is written and checked on readback. An overwrite happens first; damage is detected when the original user reads again. Work slots and deadlines are game settings, not CPU time or inference performance. The three policies use the same scenario and workload. Retention timelines are available in thepolicy demonstration.
Compare with the actual experiment: capacity, correctness, and performance
Beyond the game: what did the actual experiment show?
MEASURED · ARTICLE RESULTSThese numbers come from tiny-arena-lab. They are not outputs of the office simulation above.
About 30.4% less arena storage, within the configured 7 KiB budget.
438 / 450 for both configurations; every predicted class matched the scikit-learn reference.
Without / with reuse. The observed ranges overlap: no reliable speedup or slowdown was established.
Measurement conditions, sources, and limitations
Digits classification, batch size 16, 450 held-out samples, on an Apple M5 Pro host. The reported value is the median of six independent process medians. Amortized time is not single-request latency; it includes padded work in the final batch, work counting, and output fingerprinting. Counts and fingerprints are checked after timing.
6,144 B covers the Tensor Arena only. Weights, allocation metadata, input, and other overhead are separate. The 7 KiB budget is an experimental setting, not available RAM measured on an MCU; it does not establish MCU deployability. Coworkers, workloads, schedules, and overwrite markers are teaching constructs. Game correctness is not model classification accuracy.
Read the article: 30% less tensor memory. Why no faster inference? ↗ · Experiment code and evidence ↗