k4bench.benchmark.k4run¶
k4bench.benchmark.k4run ¶
Benchmark a k4run job and its variants.
The k4run counterpart of :mod:k4bench.benchmark.ddsim. k4Bench knows nothing
about the job: the options files, the directory to stage and the job's own
arguments come from the caller, and everything measured comes from the Gaudi
layer (see :func:k4bench.runner.k4run.run_k4run).
A benchmark is the baseline job plus one run per variant, a named set of
arguments appended to the job's own (label variant_<name>). Runs are
sequential, for the same reason as the ddsim sweep: parallel runs would skew
each other's wall time and memory.
Every run gets a fresh working directory, removed after the run: a writable copy of the stage directory when one is given (reconstruction configurations such as CLDConfig must run from their own directory), otherwise an empty one. A job's outputs therefore never land in the caller's directory, and one run's outputs are never read by the next. Paths in the job's arguments are read from that working directory, so give them as absolute paths.
Each run is preceded by a warm-up: the same job for one event, unmeasured and discarded. A job loads its libraries, geometry and conditions from CVMFS, and on a host whose CVMFS cache does not hold them yet, fetching them dominates its initialization (tens of seconds for CLD reconstruction, against a few seconds from a warm cache), which would measure the host's cache rather than the job. The warm-up event also reads in the code the first measured event runs.
With memory_events set, each run that succeeds is followed by a memory pass:
the same job again for that many events, recording which component allocated
each heap block, into <label>_heap.json (:mod:k4bench.analysis.heap).
Recording owners makes every allocation several times dearer, so the pass is
never timed; it runs from a fresh working directory, and everything it writes
but the heap file is discarded. A run that failed gets none, as its job would
most likely fail again, slower.
After the last run, each run's data flow (:mod:k4bench.analysis.dataflow) is
built from what its job recorded, with Marlin -x of the stack saved beside
it when a job ran Marlin processors.
Given the job's input file (source_input), what went into the events, the
file's generator particles and collections event by event, is recorded once
before the first run as event_source.json.gz
(:mod:k4bench.analysis.event_source); each measured run records what each
event of its own outputs holds.
K4runConfig
dataclass
¶
K4runConfig(options: list[str], n_events: int, log_dir: Path, stage_dir: Path | None = None, extra_args: list[str] = list(), variants: dict[str, list[str]] = dict(), setup_script: Path | None = None, verbose: bool = False, warm_up: bool = True, memory_events: int | None = None, source_input: Path | None = None)
All parameters needed to benchmark a k4run job.
Parameters:
| Name | Type | Description | Default |
|---|---|---|---|
options
|
list[str]
|
Gaudi options files, loaded in order. Relative paths are relative to stage_dir when it is given, otherwise to the current directory. |
required |
n_events
|
int
|
Number of events per run. |
required |
log_dir
|
Path
|
Directory where per-run logs and the auditor's files are written. |
required |
stage_dir
|
Path | None
|
Directory copied into every run's working directory, for jobs that read files relative to where they run. |
None
|
extra_args
|
list[str]
|
Job arguments passed verbatim to every run. |
list()
|
variants
|
dict[str, list[str]]
|
|
dict()
|
setup_script
|
Path | None
|
Optional shell script sourced before each k4run invocation. A relative path is relative to the current directory. |
None
|
verbose
|
bool
|
If True, print k4run output in real time instead of only logging it. |
False
|
warm_up
|
bool
|
If True, precede each run with the same job for
:data: |
True
|
memory_events
|
int | None
|
Events of the untimed memory pass after each run that succeeds,
which records the heap each component held; |
None
|
source_input
|
Path | None
|
The job's input file, from whose first n_events entries what went
into the events is recorded; |
None
|
planned_k4run_labels ¶
The result labels a k4run benchmark with these variants produces, in
run order: baseline, then variant_<name> for each variant.
Source code in k4bench/benchmark/k4run.py
run_k4run_benchmark ¶
run_k4run_benchmark(config: K4runConfig) -> list[RunResult]
Run the baseline job and every variant, and return all results.
A run that fails is marked with a non-zero return code and included in the results; the benchmark always continues to the last variant.