Repository navigation
A run's fixed host cost is unprofiled: 0.1–0.3 s on capillaries, about 6 s on kerr_beam_384 #347
Description
What happens
A complete run spends a fixed time outside its steps, on metadata, provenance, output and plane observation, the same for either integrator:
- Capillaries, per SEP 39: 90–190 ms (122 ms on an AMD EPYC 7763), so 0.12 s of a 0.7 s mode-averaged helium run once its steps are cheap.
- Per Native performance push #59: 0.1–0.3 s on the capillary and radial cases and about 6 s on
kerr_beam_384, on a Xeon Gold 6240 and an EPYC 7763. That is 2–9 % of a complete one-thread capillary run, and up to a third of a short completeradial_filament_256at 16 threads orkerr_beam_384. - The configuration hash, within that:
configuration_hashis computed once, at the first output write, and takes 0.07–0.27 s, or 1.7 s forkerr_beam_384's configuration.
Nobody has profiled the rest. SEP 39 left it out of scope.
Why it matters
Scans of many short runs pay it on every point, and a benchmark window can be dominated by it, as complete-run gains exceed the windows' on the A40. It does not matter for a single long simulation.
Context
- SEP 42 (SEP 42: Resuming by what matters to the run #142) replaces hash equality as the resume gate, so it may change what the hash has to be. The same hash identifies scan points. The run record also reads it.
- The run record is rewritten at every plane:
/meta/outcomeand Multistep'sorders#80 is the record rewritten per plane, which repeats. #A saved plane of a large Cartesian field costs about 3 s in copies, and a kept native save on Linux is unexplained #346 is the plane's field. Shorter start-up: optmat 0.9.1, lazy imports, no numba on the native backend #15 cut start-up, which is before this.
Read, not run.
To do
- Profile a complete
he_rdw_averaged,radial_filament_256andkerr_beam_384run outside the steps, separating construction, metadata, provenance, hash, file set-up and the first plane. - Remove what is not needed per run, and defer what is needed only if a file is written.
- Find what makes the hash cost 1.7 s on
kerr_beam_384, whose configuration should not grow with the field.
The hash's value must stay stable, and the record must not lose a field a reader needs.
Done when
The breakdown is recorded in benchmarks.md. On 2x Xeon Gold 6240, one run's fixed cost at most halves for he_rdw_averaged and kerr_beam_384, or each remaining item is named with why it stays.
Checked against commit 8a9f764. Takes over the roadmap's entry "The fixed host cost of a run."
Activity
jtravs commentedon Nov 4, 2026
Part of the fixed cost, on an Intel Xeon Gold 6240, 8 threads, free-space 768² x 512 bins,
#497's branch:Simulation.from_freewith aSpatialPulsetranslate()configuration_hash()The first is almost all
pulses.build: at 256² it's 7.7 s of 7.8 s, more than half of it inspatial.admittance, called 32 times. It scales with the transverse nodes (128²: 2.0 s; 256²: 7.2 s; 512²: 28 s). A delay scan passing a formed array doesn't pay it per point, but one passing a pulse does.jtravs commentedon Nov 5, 2026
Where #520 leaves this, at 768 x 768 x 600:
Simulation.from_freewith aSpatialPulsetranslate()The launch builds in threads and forms its admittance once. A replaced input's finiteness pass also runs on threads now, 0.72 s to 0.05 s on the H200's host, and a
Localscan on a device keeps its backend between input-only points (#298). So the items here are much smaller, but I haven't profiled the rest of a run's fixed cost as this issue asks, so it stays open.configuration_hashis #309's.