Artifact: Aneto - Predicting System Performance by Exploiting Cross-Workload Regularity

Artifact for the MICRO 2026 paper "Aneto: Predicting System Performance by Exploiting Cross-Workload Regularity".

Archived at 10.5281/zenodo.21554122, mirrored at https://github.com/huawei-csl/aneto-ae.

Aneto predicts a workload's CPI at unseen memory latencies from a single baseline measurement. Its core is the Clapp decomposition CPI(MP) = CPI0 + BF * MPI * MP, where MP is the average LLC miss penalty in cycles. Measuring the slope BF classically requires a per-workload frequency or latency sweep. Aneto instead predicts BF and CPI0 from the baseline measurement alone, using a regression trained across a corpus of workloads.

This artifact regenerates every results element of the paper except the ARM use case in Section 5.4 (see the Scope section below). Each element comes out as a file you can compare against the paper directly:

Paper element	Regenerated as
Figure	experiments/<experiment>/out/<experiment>.pdf
Table	experiments/<experiment>/out/table.tex, also typeset to table.pdf
Number quoted in the text	a \res... macro in experiments/<experiment>/out/macros.tex

scripts/verify.py checks all three against the frozen reference copies in expected/, and the paper's build reads the same macros, so nothing in the text is transcribed by hand.

It uses only the measurement data included in the repository. No special hardware is needed. All measurements ship as about 4 MB of JSON, and the full run takes less than 5 minutes on a laptop.

Contents

aneto/            standalone reference implementation of the model (about 1.5k lines)
  data.py         metrics loading, per-workload line fits, quality filter
  model.py        target and features, standardized OLS, sigmoid inverse, intervals
  evaluate.py     grouped leave-one-out CV and accuracy metrics
experiments/      one directory per paper element, each main.py writes out/
  data/platform.d/  measured metrics for the 8 platforms (aneto-metrics-v1 JSON)
expected/         frozen reference outputs, plus ENVIRONMENT.txt (reference env)
scripts/          install.sh, run_all.sh, verify.py
third_party/      vendored PROFET wheel (BSD-3-Clause, pinned upstream commit)
Dockerfile        pinned environment with TeX Live (figures render text with LaTeX)

Platforms in the data set

Slug	Platform
amd-zen2-...-ryzen-9-3950x...	AMD Ryzen 9 3950X (Zen 2), DVFS sweep
amd-zen3-...-epyc-7543...	AMD EPYC 7543 (Zen 3), DVFS sweep
amd-zen4-...-threadripper-7980x...	AMD Threadripper 7980X (Zen 4), DVFS sweep
amd-zen5-...-ryzen-9-9950x3d...	AMD Ryzen 9 9950X3D (Zen 5), DVFS sweep
intel-cometlake-...-xeon-w-1270	Intel Xeon W-1270 (Comet Lake), DVFS sweep
champsim-dpc4	ChampSim, DPC-4 prefetchers, latency sweep
champsim-dpc4-nopf	ChampSim, no prefetcher, latency sweep
sniper-gainestown-interval	Sniper, interval core model, latency sweep

Quick start

Native install needs Linux, GNU Make, and a TeX Live installation that provides the libertine and newtxmath packages (scripts/install.sh prints the exact apt line). The reference interpreter is Python 3.12. If uv is on the PATH, install.sh uses it to pin that version and fetches the interpreter when the system lacks it; otherwise it falls back to python3.12 -m venv. Set PYTHON_VERSION to override. The PROFET dependency is vendored under third_party/, so installation needs network access only for PyPI.

./scripts/install.sh                  # venv, pinned deps, and the aneto package
./scripts/run_all.sh                  # regenerates all experiments (about 4 min)
.venv/bin/python3 scripts/verify.py   # compares against expected/, exits 0

Docker is recommended for a clean machine:

docker build -t aneto-ae .
docker run --rm -it aneto-ae
# inside the container:
./scripts/run_all.sh && .venv/bin/python3 scripts/verify.py

verify.py parses every generated out/macros.tex and table.tex file and compares each value against the frozen expected/ copies. Values are expected to be string identical. Numeric drift within 1e-9 relative tolerance is reported as SOFT. It also renders every figure PDF and its reference copy to PNG and compares the pixels, if pdftoppm (poppler-utils) is installed. On the reference environment all seven figures come out pixel-identical. A pixel difference is reported but does not fail, since a different TeX Live or matplotlib can move text by a pixel without any number changing. Exit code 0 means the paper's numbers were reproduced.

Experiment to paper element map

Figure and table numbers refer to the submitted paper.

Every path below is relative to experiments/. Each also writes a macros.tex holding that element's inline numbers.

Paper element	Produced by	File to compare
Table 5: Clapp LOPO vs. Aneto LOO vs. measured CPI	accuracy_vs_measured	accuracy_vs_measured/out/table.pdf
Table 6: CPI and BF error on all platforms	cpi_prediction_error	cpi_prediction_error/out/table.pdf
Table 7: minimal training-corpus size W*	training_corpus_size	training_corpus_size/out/table.pdf
Table 8: Aneto vs. PROFET on ChampSim	profet_comparison	profet_comparison/out/table.pdf
Figure 3: workloads in the (MPI*MP, CPI) plane colored by log BF	bf_across_workloads	bf_across_workloads/out/bf_across_workloads.pdf
Figure 4: metric distributions for Zen 5 and ChampSim-nopf	metric_distributions	metric_distributions/out/metric_distributions.pdf
Figure 5: CPI error vs. target latency, DDR to CXL to rack	memory_technologies	memory_technologies/out/memory_technologies.pdf
Figure 6: workload classification and ranking on Zen 5	workload_ranking	workload_ranking/out/workload_ranking.pdf
Figure 8: per-workload BF across platform pairs	bf_across_platforms	bf_across_platforms/out/bf_across_platforms.pdf
Figure 9: measured vs. predicted slowdown	slowdown_prediction	slowdown_prediction/out/slowdown_prediction.pdf
Section 5.2 prose numbers	cpi_prediction_error	cpi_prediction_error/out/macros.tex
Cross-generation BF correlation numbers in the Section 5 prose	bf_correlation	bf_correlation/out/macros.tex

Each table.tex is typeset to table.pdf in the paper's fonts, so the tables can be compared by eye like the figures rather than read as LaTeX source.

experiments/macros.tex aggregates all per-experiment macros. The paper's build inputs it, so every inline number in the text regenerates from here.

Row-key glossary

Per-workload dicts use the pipeline's established keys:

Key	Meaning
BF, CPI0, r2	slope, intercept, and R2 of the per-workload line fit (ground truth)
BF_pred, CPI0_pred	model predictions (*_lo and *_hi give the 95% prediction interval)
mpi_fit_ref	LLC misses per instruction at the baseline point
mp_ref_meas, mp_ref	memory pressure (average LLC miss penalty, in cycles) at the baseline
cpi_ref_meas	CPI at the baseline point
baseline_*	raw baseline-point values (same quantities, loader-level names)
x (points)	MPI*MP of one operating point

Metric fields in the JSON

Each operating point carries a metrics dict. The pipeline reads only the first group. The rest is measurement context kept for provenance and is never used to produce a number.

Field	Used	Meaning
cpi	yes	cycles per instruction at this point
mp (mp_bwlat on Comet Lake)	yes	average LLC miss penalty, in core cycles
mpi_fit (or mpi)	yes	LLC misses per instruction, demand plus prefetch
mpi_bw	yes	misses per instruction used for the bandwidth proxy
mr_fit, mr_bw	yes	measured miss ratios (a smoothed fallback is derived from MPI when absent)
cycles, instructions	yes	consumed by the PROFET comparison only
mem_lat_ns	yes	unloaded latency in ns, used for the memory-technology sweep when present
freq_hz	no	average core frequency observed over the run. On multi-phase runs this can sit far below the nominal setting in params.freq_khz, which is the value that defines the operating point
sys:bps, sys:rd_pct	no	system-wide memory throughput and read fraction
n_reps	no	number of repetitions aggregated into this point

Repetitions and sweep shape

Each hardware operating point aggregates at least three repetitions (n_reps records how many). Per-repetition values are not shipped. Because cpi is aggregated across repetitions independently of cycles and instructions, cpi is not exactly cycles / instructions on hardware. The median disagreement is below 1e-5 relative, a minority of points differ by more than 0.1%, and the largest single outlier is 27%. The pipeline uses cpi. Simulator points are deterministic single runs and agree to floating-point precision.

The sweep is five operating points per workload, with two exceptions: Comet Lake uses seven frequency points, and 33 of the Zen 4 workloads retain three or four points after the re-measurement described under Scope. A line fit needs at least two points and must reach R2 >= 0.9 to qualify.

Scope: the ARM use case (Section 5.4) is excluded

Section 5.4 of the paper ("When Is HBM Worth It?") demonstrates Aneto on an ARM server with DDR and multi-hop HBM tiers (Figure 7 and the ARM rows of Table 3). Those measurements were taken on pre-production vendor hardware whose data we are not permitted to redistribute. The ARM platform is therefore not part of this artifact. Every remaining result is reproducible from it. All main accuracy and generality claims (Tables 5, 6, 7, and 8, and every non-ARM figure) reproduce without it.

Note on the measurement data

The five hardware platforms ship the consolidated metrics, which fold in a later re-measurement campaign on those machines. The paper is built from experiments/macros.tex, so its tables, figures, and inline numbers are the ones this artifact regenerates. Every number is computed live from the shipped JSONs.

Contact

Raul Taranco, raul.taranco@h-partners.com

Disclaimer

This is research code accompanying a paper. It is provided as-is for reproducibility and is not intended or hardened for production use.

License

Code: see LICENSE (BSD-3-Clause Clear). Measurement data under experiments/data/ and experiments/profet_comparison/data/: CC-BY-4.0 (see the LICENSE file in each of those directories). PROFET is vendored as a wheel built from its upstream repository (BSD-3-Clause, pinned commit). See THIRD_PARTY_LICENSES.