The stopwatch judge
Waiting for the bowl
“I am watching the clock. I have not checked dinner.”
A noodle-shop game about speed and doing the whole job
Hold the applause.
Fast service. But where are the noodles?
One judge watches the clock. The other checks what is in the bowl.
1 Choose a recipe2 Make a guess3 See what happens
How to play
- Pick a scenario or use the three sliders. Guess whether the inspector will pass the bowl.
- Start cooking and watch both judges. You can pause, resume or skip to the result.
- After the reveal, change only the inspection rule to rejudge the same bowl. Its contents and timing stay fixed. Changing the recipe or warm-up resets the round.
Try “An empty bowl passes?” first. Compare the pass stamp with the customer’s order. Engineering notes and real article measurements are available below.
1. What is the chef making?
Everyday analogy · teaching gameThe customer ordered
A full bowl, made to the recipe.
Same bowl. Not necessarily the same dinner.
3. Who applauds first?
Not startedMake a guess, then start.
The chef
Getting ready
+ Recipe changed
Prep→Cook→Plate
Ready to try?
The inspector
Waiting for the bowl
“First, tell me what to check.”
Did the customer get the meal they ordered?
Not revealed yet
A pass stamp and a proper meal are two different things.
This is a teaching game with preset speeds, not a restaurant benchmark. No noodles are actually being cooked.
Curious about the engineering?
The meal stands for a program’s work: a 64→32→10 pipeline and 450 preset outputs. This animation loads no model weights and runs neither C BLAS nor ONNX Runtime. The speed factors, errors and warm-up distributions below are teaching data, separate from the article’s measurements.
Illustrative speed factor
—
Preset outputs shown
0 / 450
Illustrative time · median of 9 runs
—
Running maximum absolute error
—
Does the output meet the agreed requirement?
Not revealed yet
Full pipeline illustration
One output trace, shared by the chart and the inspector
Lower error means closer to the reference recipe. Yellow shows each preset error; blue shows the running maximum. Red is the inspector’s tolerance; grey is the requirement agreed for this game.
Yellow: each errorBlue: running maximumRed dashed: inspection thresholdGrey dashed: agreed requirement
No output for this round yet.
Rules and measurement boundaries
- The game requires the right output shape and a maximum absolute error of at most 1e-4 against its preset reference. This is a game contract, not a universal tolerance recommendation. Real logits and probabilities need their own requirements.
- The normal case includes a small permitted difference. These preset faults change the output; that does not mean every rewrite, skipped computation or fault necessarily changes a result.
- A shape-only check never compares values. Passing this check does not prove the whole program correct.
- Changing the recipe or warm-up resets the round. After completion, change only the tolerance to rejudge exactly the same output and timing. The check is locked while running or paused.
- In this teaching model, warm-up changes only the speed factor, with no further gain after three runs. Real systems need not behave this way. Illustrative times exclude warm-up cost; animation duration is not inference latency.
- The 1.85×, 3.2× and 8.5× factors and all errors are preset teaching values, not measured tiny-infer-lab faults. The game simulates neither accuracy, real RAM use nor a probability of missing faults.
Rehearsal for the stopwatch: time the same work repeatedly
Each dot is one illustrative timing: nine per row, with possible overlap. Left means faster; tighter grouping means less variation in these teaching data.
No warm-up
These are teaching distributions, not measurements from the article. The displayed time is the median of nine runs, excluding warm-up. Practice still will not put soup in an empty bowl.
Article measurements · separate from the game
The following results are reported in the article. The sliders do not change them.
Measured: how much memory did the process use?
Fixed article data, independent of the controls above. A shorter bar means less process memory.
C BLAS 38.9 MiB
ONNX Runtime 60.4 MiB
Both bars start at zero on the same scale. Median warm process RSS at batch size 450 includes the shared Python and NumPy environment. It is not the model’s standalone memory use.
450 held-out samples
All six backends agreed on classifications: 97.33% accuracy (438/450). Probability outputs passed checks against an independent float64 reference.
Warm process RSS
C BLAS：38.9 MiB
ONNX Runtime：60.4 MiB
Median at batch size 450, including the shared Python and NumPy environment, not just model RAM.
Batch throughput · amortized per sample
C BLAS: about 0.142 μs
ONNX Runtime: about 0.059 μs
Apple M5 Pro, batch size 450, one compute thread. Includes the Python API, input checks, probability output and result collection. Excludes loading, warm-up and correctness checks outside timing. This is not individual-request latency.