THE GREAT DESK SHUFFLE
Fewer desks. Same work?
Watch the office share desks. Can everyone finish without losing their work?
Your office
Changes stop playback and reset this round.
More actions
You are reviewing the same deterministic schedule. Pause, stepping, and replay do not change the policy or quietly repair damaged documents.
FINAL ROUND / KPI TRAP
Boss: “Fewer desks. Can we call that faster work?”
Engineering view: desks, documents, and memory
Each desk represents a workspace. Larger documents need consecutive desk numbers; counting empty desks alone is not enough. In this illustrative model,one desk maps to one 1 KiB storage region, and several desks form a larger contiguous range. Rows of four are only a visual wrap: 4 + 5 are consecutive addresses and can hold one document.
Coworkers represent work that needs data, and document markers represent the contents. A person being away is separate from a document having future readers. Private desks reserve a fixed range per person; safe handover waits for the last read; empty-chair reuse can overwrite documents still needed. Private allocation finds never-assigned consecutive desks on arrival; a larger job that cannot fit does not block a smaller job that can. Allocated desks are never handed over under that policy. Anyone without a suitable range waits; work never runs outside capacity.
Arrivals, workloads, waiting, and moves are teaching settings. Animation speed is not inference performance, and the game does not reproduce the article’s fixed tensor schedule. Actual measurements appear separately below. Desk savings cannot be converted into a speedup percentage.
| Coworker / document | Desks | Offset / size | Future use / contents |
|---|
Document retention in this round
From the first seat assignment and write until work and review finish. Undelivered documents extend to the end of the round.
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 ↗