What we are asking for
Name each run directory for its config, its device and a timestamp, so runs accumulate rather
than replace each other. Something along the lines of:
results/
asc_object_detection_classification__gpu__2026-08-31T14-22-05/
asc_object_detection_classification__cpu__2026-08-31T15-04-41/
The exact scheme is engineering's call. What matters is that the three facts a reader needs to
tell two runs apart are in the name.
Acceptance criteria
- Two consecutive runs with different devices both exist on disk afterwards.
- A run directory name identifies its config, its device and when it ran.
- Nothing downstream depends on the fixed
benchmark/ path, or the ones that do are updated.
Context
What we found
Every run lands in benchmark/ and the next run overwrites the last. A CPU run and a GPU run
cannot both exist on disk at the same time. Earlier versions of the tooling wrote a folder per
accelerator.
Why it matters
The benchmark's main use is comparing accelerators, or comparing the same accelerator across
two builds. Both require two runs to survive at once. Today the second run destroys the
evidence for the first, so anyone doing a comparison is copying directories out by hand between
runs and hoping they labelled them correctly.
This is also the prerequisite for #249, the multi-run comparison report.
Verified against performance-tools @ 144d3b6, read 31 Aug 2026.
What we are asking for
Name each run directory for its config, its device and a timestamp, so runs accumulate rather
than replace each other. Something along the lines of:
The exact scheme is engineering's call. What matters is that the three facts a reader needs to
tell two runs apart are in the name.
Acceptance criteria
benchmark/path, or the ones that do are updated.Context
What we found
Every run lands in
benchmark/and the next run overwrites the last. A CPU run and a GPU runcannot both exist on disk at the same time. Earlier versions of the tooling wrote a folder per
accelerator.
Why it matters
The benchmark's main use is comparing accelerators, or comparing the same accelerator across
two builds. Both require two runs to survive at once. Today the second run destroys the
evidence for the first, so anyone doing a comparison is copying directories out by hand between
runs and hoping they labelled them correctly.
This is also the prerequisite for #249, the multi-run comparison report.
Verified against
performance-tools@144d3b6, read 31 Aug 2026.