hardware-counters

Literature survey: performance projection and hardware modelling

Where this project sits in the published literature on performance modelling, hardware-counter-driven prediction, and cross-workload generalisation.

Companion to methodology.md (data collection) and modelling.md (models and results). A raw, annotated citation dump with one-line summaries of every paper screened lives at ../../../analysis/review/lit_corpus.md.

Scope and method

Databases searched. Crossref REST API (api.crossref.org, bibliographic queries), OpenAlex (api.openalex.org, title-search and DOI resolution), the arXiv Atom API (export.arxiv.org/api/query), and the Semantic Scholar Graph API. All four were queried programmatically; web search engines were not used, and no citation appears below that was not returned by one of those APIs during the survey. Abstracts were retrieved for every paper in the summary table so that dataset sizes, validation protocols and reported accuracies could be quoted rather than guessed.

Query strategy. Nine Crossref batches, four arXiv batches and one OpenAlex batch, covering: analytic/mechanistic models (Roofline, ECM, LogP, CPI stacks, Top-Down); counter-based ML prediction; cross-platform and cross-architecture prediction; proxy/mini-app fidelity; empirical scaling extrapolation (Extra-P lineage); sampling and transfer learning for small budgets; and RAPL/PMC-based power and energy modelling.

Volume. 332 Crossref records, 221 arXiv records and 123 OpenAlex records were returned and title-screened. After removing duplicates and off-topic hits (Crossref bibliographic search is noisy and returns a great deal of unrelated biomedical and materials work for generic queries), roughly 60 papers were read at abstract level and 38 are cited here.

Date range. Primarily 2013–2026, with seminal older work retained where it is still the standard reference: Amdahl (1967), Gustafson (1988), LogP (1993), LogGP (1997), PAPI (2000), LINPACK (2003), CPI stacks (2006), Roofline (2009), Mantevo (2009).

Deliberate exclusions. Simulator-based prediction (gem5, GPGPU-Sim, SST) is out of scope except where a simulation-reduction paper reports cross-architecture error rates directly comparable to ours. Job-queue runtime prediction from scheduler logs is a distinct problem (features are user and queue metadata, not hardware counters) and is not surveyed.

A note on comparability. Reported accuracies below are not directly comparable to each other. Different papers use MAPE, median relative error, R², or a multiplicative factor; they hold out different things; and they predict different targets (runtime, speedup, power, scaling exponent). Where a number is quoted, the protocol that produced it is quoted alongside. The positioning section at the end takes that heterogeneity seriously.

1. Analytical and mechanistic performance models

Synthesis. The analytic tradition predicts performance from a small number of machine and code parameters rather than from data. Roofline [Williams2009] bounds attainable FLOP/s by min(peak, bandwidth x arithmetic intensity); it is a ceiling, not a runtime predictor, and deliberately so. The Execution-Cache-Memory (ECM) model [Hager2013, Stengel2015] refines this by modelling data transfer times through each level of the hierarchy and adding them up, which lets it predict the saturation point of a bandwidth-limited kernel — something Roofline cannot do. ECM is highly accurate but operates at loop-kernel granularity and requires per-architecture calibration [Hofmann2020]; Kerncraft [Hammer2017] automates the calibration from source. The communication-side analogue is LogP [Culler1993] and LogGP [Alexandrov1997]; the scaling-side analogues are Amdahl [Amdahl1967] and Gustafson [Gustafson1988].

Relation to our eta. Our decomposition runtime = cycles / (f_peak * eta) makes eta a dimensionless, single-number efficiency: the fraction of peak issue rate that rank 0 actually sustains. This is, honestly, a maximally coarse CPI stack. The proper version of this idea is Eyerman et al.’s CPI stack work [Eyerman2006, Eyerman2007], which decomposes cycles into a baseline plus attributable miss-event components using interval analysis, and Yasin’s Top-Down Microarchitecture Analysis [Yasin2014], which does the same hierarchically with about eight counters and is now in production tooling on Intel parts. Our eta collapses everything those methods separate — front-end stalls, bad speculation, memory bound, core bound, and additionally load imbalance and MPI wait, which CPI stacks do not cover — into one scalar, and then learns it from behavioural ratios rather than attributing it.

The nearest published relative of what we actually do is Eyerman, Hoste and Eeckhout’s mechanistic-empirical (grey-box) modelling [Eyerman2011]: start from a mechanistically motivated functional form, then fit its unknown coefficients by regression on measured data. They report 9–13% average prediction error for Pentium 4, Core 2 and Core i7 on SPEC CPU2000/2006. Our framing is the same species — mechanistic skeleton (cycles / f_peak), empirical correction (learned eta) — at a much coarser granularity, on parallel rather than single-thread workloads. This is the single most important methodological ancestor for the dissertation and should be cited as such.

On the energy side, Ilić et al. [Ilic2014, Ilic2017] extend Roofline with cache-awareness and then with power/energy ceilings decomposed into cores, uncore and package domains — validated with hardware counters and on-chip power monitors. That core-versus-uncore split is precisely the physical quantity core_energy_frac = PP0/PACKAGE measures. The analytic connection stands on its own. What our data support is the weaker and still useful statement that the core/uncore power split is physically interpretable, and that our data do not show it carrying independent predictive value for runtime once run length and instruction mix are in the model.

Finally, Afzal, Hager and Wellein [Afzal2025] build a per-hot-spot Roofline model of LULESH on Ice Lake and Sapphire Rapids, validate it against hardware-counter measurements, and add power, energy-to-solution and EDP analysis. This is the closest existing study to our experimental setup for one of our proxy codes, and it is white-box where we are grey-box. It is a natural head-to-head comparison and also a source of expected values.

Key papers.

• Williams, Waterman & Patterson, Roofline: an insightful visual performance model for multicore architectures, CACM 52(4), 2009, doi:10.1145/1498765.1498785
• Hager, Treibig, Habich & Wellein, Exploring performance and power properties of modern multicore chips via simple machine models, CCPE 28(2), 2013, doi:10.1002/cpe.3180 (arXiv:1208.2908)
• Stengel, Treibig, Hager & Wellein, Quantifying performance bottlenecks of stencil computations using the ECM model, ICS ‘15, doi:10.1145/2751205.2751240
• Hammer, Eitzinger, Hager & Wellein, Kerncraft, Tools for HPC 2016, doi:10.1007/978-3-319-56702-0_1
• Hofmann, Alappat, Hager, Fey & Wellein, Bridging the architecture gap, Supercomputing Frontiers and Innovations 7(2), 2020, doi:10.14529/jsfi200204
• Eyerman, Eeckhout, Karkhanis & Smith, A performance counter architecture for computing accurate CPI components, ASPLOS ‘06, doi:10.1145/1168918.1168880
• Eyerman, Hoste & Eeckhout, Mechanistic-empirical processor performance modeling for constructing CPI stacks on real hardware, ISPASS 2011, doi:10.1109/ispass.2011.5762738
• Yasin, A top-down method for performance analysis and counters architecture, ISPASS 2014, doi:10.1109/ispass.2014.6844459
• Ilić, Pratas & Sousa, Cache-aware Roofline model: upgrading the loft, IEEE CAL 13(1), 2014, doi:10.1109/l-ca.2013.6
• Ilić, Pratas & Sousa, Beyond the Roofline: cache-aware power and energy-efficiency modeling for multi-cores, IEEE TC 66(1), 2017, doi:10.1109/tc.2016.2582151
• Afzal, Hager & Wellein, Analytic roofline modeling and energy analysis of the LULESH proxy application on multi-core clusters, IJHPCA 40(1), 2025, doi:10.1177/10943420251363711 (arXiv:2412.08792)
• Culler et al., LogP, PPoPP ‘93, doi:10.1145/155332.155333
• Alexandrov, Ionescu, Schauser & Scheiman, LogGP, JPDC 44(1), 1997, doi:10.1006/jpdc.1997.1346
• Amdahl, AFIPS ‘67, doi:10.1145/1465482.1465560; Gustafson, CACM 31(5), 1988, doi:10.1145/42411.42415

2. Hardware-counter-based prediction and machine learning

Synthesis. Using PAPI [Browne2000] counters as ML features is a well-established practice, but the literature splits sharply by target. Counters -> power/energy is a mature, high-accuracy field (Section 7). Counters -> runtime is much rarer and much less accurate, for the obvious reason that cycle count already almost determines runtime, so the counters have to explain the residual — exactly the problem our eta framing formalises.

The closest published system is APMT [Ding2020], an automatic counter-based performance modelling tool that profiles at small scale, identifies key and non-scalable kernels, and — significantly — offers an optional refinement framework built around cycles-per-instruction as the key metric. It reports ~15% average error at 3% profiling overhead across NAS Parallel Benchmarks and CESM components, improving on analytic and empirical baselines by 25–52% in strong-scaling tests. That an independent group converged on CPI-refinement plus counters is good evidence the framing is sound; it also means our framing is not novel.

For general ML-over-counters practice, Malakar et al. [Malakar2018] is the reference benchmark study: eleven ML methods, four applications, four leadership-class platforms, with explicit study of feature engineering, training-set size, transfer learning and extrapolation. Bagging, boosting and DNNs reach median R² > 0.95 and need no feature engineering. Sun et al. [Sun2020] build random forests over domain-independent instrumented runtime features (variable values, branch/loop/MPI counters) for Graph500, GalaxSee and SMG2000 across three systems, reporting under 20% mean error, with transfer learning used to port a model to a platform lacking historical data.

Two practical cautions from the literature are directly relevant to our measurement setup. First, Das et al. [Das2019] catalogue the systematic hazards of trusting hardware counters — non-determinism, overcounting, and poor cross-platform portability — which is a strong argument for our decision to report counter-derived ratios rather than raw magnitudes. Second, Hackenberg et al. [Hackenberg2015] document that on modern parts every clock above the AVX frequency is opportunistic and unreliable, which “vastly decreases performance predictability”. That is a published, independent explanation for the very effect our project is built around: our EPYC 7742 effective clock ranges from 1.98 GHz down to 0.23 GHz against a 2.25 GHz nominal peak.

On the 5-counter budget. Our A–E counter-set rotation is a workaround for a hardware limit, and one 2026 paper attacks exactly this. Orteu Aubach et al. [OrteuAubach2026] propose heuristic trace merging: run the same workload several times with different counter sets, then match computation bursts across runs using MPI structure, timing and communication patterns to synthesise a single trace with all counters, avoiding multiplexing. They validate on MareNostrum5 and train ML models on the resulting wider feature space. This is a more principled version of the merge our parse_craypat.py performs by simply joining on (app, ncore), and it is the obvious citation for that design decision — including its risk, since they note merged-counter fidelity is application-dependent.

Which counters others find predictive. The consensus across [Contreras2005, Nagasaka2010, Tiwari2012, Shahid2020] is that instruction-retirement rate, cache-miss counts at each level, and memory-access counts dominate.

Our data agree with that consensus. On the 191-configuration dataset the leading features are log_t_analytic (0.376 impurity importance), flops_per_instr (0.134), log_instr_per_rank (0.112) and stall_fp_frac (0.077); core_energy_frac carries 0.008 (rank 15 of 21) and is rank 13 by held-out permutation importance. Instruction mix and cache behaviour dominate once a scale term is present, so the literature above serves as corroboration rather than contrast. docs/modelling.md shows how a 40-row table with one problem size per application and no run-length covariate pushes the same energy feature to 0.509 and the top of the ranking, and analysis/importance_artefact.py reproduces it.

Arguably more useful is the negative methodological result: rotating counter sets to beat a small hardware register budget creates structurally missing feature columns, and impurity importance computed on such a matrix measures observation frequency rather than signal. Any counter that sits on a separate register and is therefore recorded in every set (RAPL energy being the common case) will absorb the importance mass and look like a discovery. We could find no paper in this literature that flags the hazard, which makes it worth reporting in its own right.

Key papers.

• Browne, Dongarra, Garner, Ho & Mucci, A portable programming interface for performance evaluation on modern processors (PAPI), IJHPCA 14(3), 2000, doi:10.1177/109434200001400303
• Ding, Lee, Xue & Zheng, APMT: an automatic hardware counter-based performance modeling tool for HPC applications, CCF THPC 2, 2020, doi:10.1007/s42514-020-00035-8
• Malakar, Balaprakash, Vishwanath, Morozov & Kumaran, Benchmarking machine learning methods for performance modeling of scientific applications, PMBS @ SC 2018, doi:10.1109/pmbs.2018.8641686
• Sun, Sun, Zhan, Zhang & Chen, Automated performance modeling of HPC applications using machine learning, IEEE TC 69(5), 2020, doi:10.1109/tc.2020.2964767
• Orteu Aubach, Banchelli, Clascà Ramírez & Garcia-Gasulla, Heuristic-based merging of HPC traces to extend hardware counter coverage, arXiv:2605.15832, 2026
• Das, Werner, Antonakakis, Polychronakis & Monrose, SoK: the challenges, pitfalls, and perils of using hardware performance counters for security, IEEE S&P 2019, doi:10.1109/sp.2019.00021
• Hackenberg, Schöne, Ilsche, Molka, Schuchart & Geyer, An energy efficiency feature survey of the Intel Haswell processor, IPDPSW 2015, doi:10.1109/ipdpsw.2015.70
• Wang, Lee, Wei & Brooks, Predicting new workload or CPU performance by analyzing public datasets, ACM TACO 15(4), 2018, doi:10.1145/3284127

3. Cross-application and cross-platform generalisation

Synthesis. This is the section that decides whether our headline claim is interesting. The finding is: holding out an entire application is rare, and holding out an entire application for a counter-based runtime model on a single node appears to be unattested in the literature we could retrieve. What is common is holding out an entire platform or an entire architecture, which is a different and in some respects easier shift, because the workload is fixed and only the machine changes.

The canonical cross-architecture work is XAPP [Ardalani2015]: predict GPU performance from single-threaded CPU code features using ML. Yang, Ma and Mueller [Yang2005] predict cross-platform performance from short partial executions, exploiting the iterative structure of parallel codes; Mahdavi [Mahdavi2024] modernises exactly that idea, predicting performance ratios between platforms from brief partial executions on a reference platform using an ensemble cluster-classify-regress kernel. Marathe et al. [Marathe2017] use deep transfer learning to combine exhaustive small-scale observations with sparse large-scale ones, identifying best-performing configurations from as little as 1% of target-scale observations.

The most theoretically useful paper here is Jamshidi et al. [Jamshidi2017], which asks when transfer works. Their answer: under mild environmental change a simple linear correction to the performance model suffices, but under severe change only structural knowledge (which options matter, how to sample) transfers, not the model itself. Framed that way, our leave-one-application-out setting is the severe-change regime — a new algorithm with a different bottleneck is not a mild perturbation — and the literature’s prior is therefore that a learned mapping should transfer poorly. That our models transfer at all is the interesting part; that they transfer only modestly better than a constant is exactly what Jamshidi et al. would predict.

What error levels count as good? This is where the comparison gets uncomfortable, and the honest reading is that the numbers are not directly commensurable:

• Ferrerón et al. [Ferreron2017] predict full-application behaviour from representative regions across Intel and ARM with error below 2.3% for cycles and instructions. But they predict a fixed application’s full execution from its own sampled regions — no unseen workload.
• Barnes et al. [Barnes2010] report median error under 13% across seven applications for time-constrained scaling using grey-box focused regression, with per-application training runs.
• Ding et al. [Ding2020] report ~15% average error for counter-based kernel models on unseen scales.
• Sun et al. [Sun2020] report under 20% mean error for unseen inputs, with a transfer step for unseen platforms.
• Malakar et al. [Malakar2018] report median R² > 0.95 — but for within-application configuration prediction, which is the interpolation regime our LOAO protocol was specifically designed to avoid.

Our numbers (~1.07–1.16x median factor, i.e. roughly 7–16% median relative error) therefore sit in the same band as the counter-based cross-scale literature (Ding, Sun, Barnes) and well behind the region-sampling literature (Ferrerón) — but under a harder split than any of them use. The correct framing for the dissertation is not “we are more accurate” (we are not) but “we obtain comparable error under a strictly harder generalisation test”. That claim only holds if the baseline is specified correctly: the constant must predict the median of the target, not its mean, because the error metric is minimised by the median.

Hoefler and Belli [Hoefler2015] is the methodological authority for how to report all of this: their stratified sample of 120 papers across three top HPC conferences found it frequently unclear whether reported improvements were deterministic or chance. Our use of paired Wilcoxon signed-rank tests against an explicit baseline, and our reporting of per-fold rather than only aggregate numbers, follow their recommendations and should cite them.

Key papers.

• Ardalani, Lestourgeon, Sankaralingam & Zhu, Cross-architecture performance prediction (XAPP), MICRO-48, 2015, doi:10.1145/2830772.2830780
• Yang, Ma & Mueller, Cross-platform performance prediction of parallel applications using partial execution, SC ‘05, doi:10.1109/sc.2005.20
• Mahdavi, A hybrid machine learning method for cross-platform performance prediction of parallel applications, ICPP 2024, doi:10.1145/3673038.3673059
• Marathe et al., Performance modeling under resource constraints using deep transfer learning, SC ‘17, doi:10.1145/3126908.3126969
• Jamshidi, Siegmund, Velez, Kästner, Patel & Agarwal, Transfer learning for performance modeling of configurable systems: an exploratory analysis, ASE 2017, doi:10.1109/ase.2017.8115661
• Ferrerón, Jagtap, Bischoff & Rusitoru, Crossing the architectural barrier, ISPASS 2017, doi:10.1109/ispass.2017.7975275
• Barnes, Rountree, Lowenthal, Reeves, de Supinski & Schulz, A regression-based approach to scalability prediction, ICS ‘08, doi:10.1145/1375527.1375580
• Barnes, Garren, Lowenthal, Reeves, de Supinski, Schulz & Rountree, Using focused regression for accurate time-constrained scaling of scientific applications, IPDPS 2010, doi:10.1109/ipdps.2010.5470431
• Hoefler & Belli, Scientific benchmarking of parallel computing systems, SC ‘15, doi:10.1145/2807591.2807644

4. Proxy and mini-applications as predictors of full applications

Synthesis. Our design implicitly assumes benchmarks and proxies can stand in for real applications. The evidence for that assumption is real but qualified, and the field’s own confidence in it has declined over the last decade.

The Mantevo project [Heroux2009] introduced the mini-application concept, and Barrett et al. [Barrett2015] is the canonical fidelity assessment, examining whether mini-apps predict key performance characteristics of the engineering codes they abstract. The ECP-era successor line is Aaziz et al. [Aaziz2018], which builds a data-driven correspondence methodology from LDMS hardware-counter and mpiP data across two platforms and four ECP proxy/parent pairs. Their headline is positive: each proxy analysed is representative of its parent with respect to computation and memory behaviour, and communication patterns are similar too.

But the follow-up [Aaziz2019] is the more instructive citation. Looking at dynamic communication behaviour rather than aggregate statistics, they find that some proxy/parent pairs need this extra scrutiny and others do not — and in the process they identify a genuine parent/proxy mismatch and change the proxy as a result. The ECP project institutionalised this as an annual milestone series [Richards2020, Richards2021, Richards2022]. The lesson is that proxy fidelity is an empirical, pair-specific property that must be re-established, not a standing guarantee.

The strongest positive quantitative result we found is Owenson et al. [Owenson2019]: MG-CFD, an unstructured-CFD mini-app built to represent Rolls-Royce’s production HYDRA code, together with an associated performance model, predicts HYDRA’s strong-scaling behaviour with a mean error of 9.2%. That is a clean existence proof that a proxy plus a model can predict a parent it was designed for.

The strongest sceptical position is Matsuoka et al. [Matsuoka2022], who argue that proxy suites push centres and vendors into rigidity and are increasingly a poor match for heterogeneous hardware. McKinsey, Brink and Pearce [McKinsey2026] respond to the scaling problem by automating the fidelity question: hardware-usage-based similarity metrics that match proxy kernels to parent kernels without manual analysis, validated between Kripke and the RAJA Performance Suite on CPU and GPU.

Implications for us. Three points are directly actionable.

1. Our workload set — STREAM, HPCG, HPL, GROMACS, OpenFOAM, plus miniFE, LULESH, CoMD — is a mixture of pure benchmarks (STREAM [McCalpin1995], HPL [Dongarra2003], HPCG [Dongarra2015]), proxies (miniFE, LULESH [Karlin2013], CoMD [Pearce2019]) and real applications (GROMACS, OpenFOAM). That is a strength: unlike most of this literature, we have parents and proxies in the same dataset under identical instrumentation.
2. The proxy-fidelity literature validates on behavioural similarity (counters, communication patterns), which is precisely the feature space our eta model lives in. Our LOAO folds are, in effect, an unusual test of proxy fidelity: can a model trained on proxies plus benchmarks predict GROMACS or OpenFOAM?
3. That test is one we should run and report explicitly. Grouping the folds into “predict a real application from proxies and benchmarks” versus “predict a proxy from everything else” turns a modelling result into a contribution to the proxy-fidelity literature, at zero additional compute cost.

Key papers.

• Heroux, Crozier, Thornquist, Numrich, Williams, Edwards, Keiter et al., Improving performance via mini-applications (Mantevo), Sandia Report SAND2009-5574, doi:10.2172/993908
• Barrett, Crozier, Doerfler, Heroux, Lin, Thornquist, Trucano & Vaughan, Assessing the role of mini-applications in predicting key performance characteristics of scientific and engineering applications, JPDC 75, 2015, doi:10.1016/j.jpdc.2014.09.006
• Aaziz, Cook, Cook, Juedeman, Richards & Vaughan, A methodology for characterizing the correspondence between real and proxy applications, IEEE Cluster 2018, doi:10.1109/cluster.2018.00037
• Aaziz, Vaughan, Cook, Cook, Kuehn & Richards, Fine-grained analysis of communication similarity between real and proxy applications, PMBS @ SC 2019, doi:10.1109/pmbs49563.2019.00016
• Richards, Aaziz, Cook, Kuehn, Moore, Pruitt et al., Quantitative performance assessment of proxy apps and parents, ECP milestone ADCD-504-9, 2020, doi:10.2172/1617284 (see also doi:10.2172/1860797, doi:10.2172/2432204)
• Owenson, Wright, Bunt, Ho, Street & Jarvis, An unstructured CFD mini-application for the performance prediction of a production CFD code, CCPE 32(10), 2019, doi:10.1002/cpe.5443
• Matsuoka, Domke, Wahib, Drozd, Chien, Bair, Vetter & Shalf, Preparing for the future — rethinking proxy applications, CiSE 24(2), 2022, doi:10.1109/mcse.2022.3153105 (arXiv:2204.07336)
• McKinsey, Brink & Pearce, On similarity of computational kernels in our codes and proxies, arXiv:2605.06968, 2026
• Karlin et al., Exploring traditional and emerging parallel programming models using a proxy application (LULESH), IPDPS 2013, doi:10.1109/ipdps.2013.115
• Pearce, Ahmed, Larsen, Pirkelbauer & Richards, Exploring dynamic load imbalance solutions with the CoMD proxy application, FGCS 92, 2019, doi:10.1016/j.future.2017.12.010
• Dongarra, Heroux & Łuszczek, High-performance conjugate-gradient benchmark, IJHPCA 30(1), 2015, doi:10.1177/1094342015593158
• Dongarra, Łuszczek & Petitet, The LINPACK benchmark: past, present and future, CCPE 15(9), 2003, doi:10.1002/cpe.728

5. Small-sample machine learning in systems research

Synthesis. The reassuring finding is that our n is not unusual for this field, and in some subfields it is generous. HPC performance data is expensive: every sample is a job on a shared machine. The literature has responded not by collecting more data but by three strategies — smarter sampling, transfer, and models with strong inductive bias.

Sampling. The Extra-P group has made experiment-design cost a first-class research object. Ritter et al. [Ritter2020] replace an exponential number of experiments per model parameter with a polynomial number, cutting average modelling cost by 85% while retaining 92% of model accuracy. The 2026 journal extension [Ritter2026] selects points individually per modelling task using Gaussian process regression. Extra-Deep [Ritter2023] reduces profiling time by 94.9% while reaching 93.6% average prediction accuracy. In configurable-software research the same concern appears as sampling-strategy design [Kaltenecker2019, Kaltenecker2020], with the finding that most sampling strategies fail to cover the performance-value space even when they cover the configuration space — a warning that applies directly to our powers-of-two core sweep.

Sample sizes actually used.

• De Sensi [DeSensi2016] achieves 96% average accuracy for execution time and power on PARSEC using multiple linear regression trained on 1% of the configuration space.
• Marathe et al. [Marathe2017] identify best configurations from 1% of target-scale observations.
• Nagasaka et al. [Nagasaka2010] build their GPU power model from 49 kernels.
• Tiwari et al. [Tiwari2012] train neural networks on three kernels.
• Eyerman et al. [Eyerman2011] fit mechanistic-empirical models per processor from SPEC suites — tens of benchmarks.
• DeepPerf [Ha2019] is explicitly designed to need less training data than prior approaches, across eleven public datasets.

Against that, our 191 configurations across 8 applications is a respectable, not embarrassing, dataset.

The measured learning curve (docs/modelling.md) sharpens this comparison in a way that is worth carrying back into the literature framing. On the configuration axis our dataset is saturated: subsampling training rows and returning to full size buys 0.0037 in the final quarter, with overlapping confidence intervals. On the application axis it is not: going from five to seven training codes buys 0.0223, six times as much, with disjoint intervals and no plateau. The right comparison against this literature is therefore not row count but application count, where eight is modest against Eyerman et al.’s SPEC suites and generous against Tiwari et al.’s three kernels, and it is the axis on which any successor study should spend first.

Models with strong inductive bias. The two most relevant negative results are worth taking seriously. First, Shahid et al. [Shahid2020] find that for counter-based energy prediction, theory-guided linear regression beats random forest by 5.09x and neural networks by 4.37x at platform level. Second, DeepPerf [Ha2019] shows a deep model can win at small n — but only with aggressive L1 sparsity and automated hyperparameter search. Both point the same way: at small n, what matters is not model family but how much structure you impose. That is a direct external corroboration of our own ablation finding that the largest single gain came from the regularisation strength (alpha 10 -> 1), not from changing solver or architecture.

A caution about our H3 result. Our finding that missingness indicators leaked application identity and wrecked the STREAM fold is, in the vocabulary of [Jamshidi2017], a case of transferring model structure rather than transferable knowledge. It is a small but genuinely reportable methodological result: with per-application structural missingness, indicator features become a one-hot application label and must be validated per-application, never in aggregate.

Key papers.

• Ritter, Calotoiu, Rinke, Reimann, Hoefler & Wolf, Learning cost-effective sampling strategies for empirical performance modeling, IPDPS 2020, doi:10.1109/ipdps47924.2020.00095
• Ritter, Naumann, Calotoiu, Rinke, Reimann, Hoefler & Wolf, Cost-effective empirical performance modeling, IEEE TPDS 37(3), 2026, doi:10.1109/tpds.2025.3646119
• Ritter & Wolf, Extra-Deep: automated empirical performance modeling for distributed deep learning, SC ‘23 Workshops, doi:10.1145/3624062.3624204
• Ha & Zhang, DeepPerf: performance prediction for configurable software with deep sparse neural network, ICSE 2019, doi:10.1109/icse.2019.00113
• Kaltenecker, Grebhahn, Siegmund, Guo & Apel, Distance-based sampling of software configuration spaces, ICSE 2019, doi:10.1109/icse.2019.00112
• Kaltenecker, Grebhahn, Siegmund & Apel, The interplay of sampling and machine learning for software performance prediction, IEEE Software 37(4), 2020, doi:10.1109/ms.2020.2987024
• De Sensi, Predicting performance and power consumption of parallel applications, PDP 2016, doi:10.1109/pdp.2016.41

6. Extrapolation versus interpolation

Synthesis. Extrapolating to larger scales than were measured is the best-developed subfield here, and it is dominated by the Extra-P line of work from Wolf’s group. Calotoiu et al. [Calotoiu2013] generate an empirical scaling model automatically for every part of a parallel program from small-scale runs, and use divergence between the model and expectation to find scalability bugs — demonstrating with a climate simulation that such bugs are not confined to the routines one would have chosen as kernels. Extra-P fits models within a restricted hypothesis space, the Performance Model Normal Form, of terms c * p^i * log^j(p); this strong structural prior is what makes extrapolation from very few points tractable at all.

The line then extends to multiple parameters [Calotoiu2016, Calotoiu2020], noise resilience via deep networks [Ritter2021], cheaper experiment design [Ritter2020, Ritter2026], and a current consolidated overview [Calotoiu2026]. Two adjacent papers reframe extrapolation as validation rather than point prediction: Shudler et al. [Shudler2015] check whether a library’s measured asymptotic scaling matches its theoretical expectation, as an automated regression test; and Shudler et al. [Shudler2017] recover an empirical isoefficiency function binding efficiency, core count and input size in one expression.

Relation to us. Two contrasts matter.

First, Extra-P extrapolates in scale; we extrapolate in workload. Extra-P fits t(p) for a fixed code and evaluates at larger p. We fit eta(counters) across codes and evaluate on a code never seen. These are orthogonal generalisation axes, and combining them is an obvious opening (Section “Gaps”).

Second, [Shudler2017] is the closest published relative of our eta. Their isoefficiency work makes a dimensionless efficiency the modelled quantity and binds it to core count and input size analytically. Ours makes a dimensionless efficiency the learned quantity and binds it to behavioural counter ratios. The dissertation should position eta explicitly against isoefficiency, and should acknowledge that “regress a dimensionless efficiency rather than a raw time” is a known good idea, not an invention of this project.

There is also an empirical point our data speaks to. Our STREAM fold is a true extrapolation case: 0% of its rows fall inside the training range for stall_load_frac and l3_miss_per_instr. Our observation that tree ensembles are structurally clamped to the training range (a forest prediction is an average of leaf values) while a smooth MLP can extend the trend is a textbook property, but demonstrating it on a real HPC counter dataset with an explicit in-range/out-of-range diagnostic is a useful, publishable-quality small result, and it aligns with why Extra-P uses a parametric hypothesis space rather than a non-parametric learner.

Key papers.

• Calotoiu, Hoefler, Poke & Wolf, Using automated performance modeling to find scalability bugs in complex codes, SC ‘13, doi:10.1145/2503210.2503277
• Calotoiu, Beckinsale, Earl, Hoefler, Karlin, Schulz & Wolf, Fast multi-parameter performance modeling, IEEE Cluster 2016, doi:10.1109/cluster.2016.57
• Calotoiu, Copik, Hoefler, Ritter, Shudler & Wolf, ExtraPeak: advanced automatic performance modeling for HPC applications, LNCSE, 2020, doi:10.1007/978-3-030-47956-5_15
• Calotoiu, Copik, Czappa, Geiss, de Morais, Ritter, Shudler, Hoefler & Wolf, Extra-P — empirical performance modeling made easy, Frontiers in High Performance Computing 3, 2026, doi:10.3389/fhpcp.2025.1714042
• Ritter, Geis, Wehrstein, Calotoiu, Reimann, Hoefler & Wolf, Noise-resilient empirical performance modeling with deep neural networks, IPDPS 2021, doi:10.1109/ipdps49936.2021.00012
• Shudler, Calotoiu, Hoefler, Strube & Wolf, Exascaling your library, ICS ‘15, doi:10.1145/2751205.2751216
• Shudler, Calotoiu, Hoefler & Wolf, Isoefficiency in practice, PPoPP ‘17, doi:10.1145/3018743.3018770
• Vetter & McCracken, Statistical scalability analysis of communication operations in distributed applications, PPoPP ‘01, doi:10.1145/379539.379590

7. Energy and power modelling

Synthesis. Counter-based power modelling is older, better validated and substantially more accurate than counter-based runtime modelling. Contreras and Martonosi [Contreras2005] established the template — a linear model with per-event power weights — reaching within 4% of measured average CPU power on the Intel XScale. Nagasaka et al. [Nagasaka2010] carry this to GPUs with 49 kernels and 4.7% average error, while candidly noting that kernels whose dominant activity has no counter (texture reads) are badly underestimated: a reminder that counter coverage bounds model quality, which is exactly the constraint our 5-counter budget imposes. Huang et al. [Huang2012] implement a per-core power proxy in production firmware at 1.8% mean unsigned error over 32 ms windows. Tiwari et al. [Tiwari2012] use neural networks for CPU and DIMM power and energy with average absolute error below 5.5%.

The most rigorous recent treatment is the Lastovetsky group’s series. Shahid et al. [Shahid2021] propose a theory of PMC-based energy models derived from energy conservation, yielding selection criteria — notably additivity — for model variables, intercept and coefficients; applying those criteria improves state-of-the-art linear model error from 31.2% to 18%. Their comparative study [Shahid2020] then finds theory-selected linear regression beats random forest by 5.09x and neural networks by 4.37x at platform level, and [Shahid2019jpdc] shows combining utilisation variables with highly-additive PMCs gives the best linear models. Fahad et al. [Fahad2019] compare measurement methodologies themselves.

RAPL specifically. Khan et al. [Khan2018] is the standard validation: RAPL readings are highly correlated with wall-socket power, accurate enough for modelling, and impose negligible overhead — established with microbenchmarks, STREAM, Stress-ng and ParFullCMS plus production datasets from a real cluster and EC2. Desrochers, Paradis and Weaver [Desrochers2016] validate the DRAM domain specifically, which is more error-prone than the package domain. Hackenberg et al. [Hackenberg2015] document the transition of RAPL from a model to a genuine measurement in the Haswell generation. Together these justify treating our PACKAGE_ENERGY and PP0_ENERGY readings as measurements rather than estimates — a claim the dissertation currently makes implicitly and should make explicitly with citations.

The direction of the arrow. Almost all of this work predicts energy from counters. We do something the literature has largely not tried: use energy as a counter to predict time. The physical justification comes from the analytic side — Ilić et al. [Ilic2017] show core/uncore/package power ratios are structurally informative about where a code is bottlenecked, and Hager et al. [Hager2013] pair ECM with a phenomenological power model to explain saturation. The learned counterpart of that analytic insight does not appear in our data: core_energy_frac carries 0.008 importance, rank 15 of 21, and the intersection ablation in docs/crossplatform.md independently shows that removing both energy features costs 0.4% of accuracy.

That is worth stating precisely. Ilić et al.’s physics is not in question: the core/uncore power split does track memory-boundedness. Our data simply show that on a single node, once run length and instruction mix are in the model, that split adds no measurable independent information about how far a code sits below peak issue rate. A defensible sentence is therefore “the core share of package power is physically interpretable but empirically redundant here”, which is a genuine, if modest, negative result about a plausible feature, and it survives both impurity and held-out permutation importance.

Key papers.

• Contreras & Martonosi, Power prediction for Intel XScale processors using performance monitoring unit events, ISLPED ‘05, doi:10.1145/1077603.1077657
• Nagasaka, Maruyama, Nukada, Endo & Matsuoka, Statistical power modeling of GPU kernels using performance counters, Int. Green Computing Conf. 2010, doi:10.1109/greencomp.2010.5598315
• Huang, Lefurgy, Kuk, Buyuktosunoglu, Floyd, Rajamani, Allen-Ware & Brock, Accurate fine-grained processor power proxies, MICRO-45, 2012, doi:10.1109/micro.2012.29
• Tiwari, Laurenzano, Carrington & Snavely, Modeling power and energy usage of HPC kernels, IPDPSW 2012, doi:10.1109/ipdpsw.2012.121
• Khan, Hirki, Niemi, Nurminen & Ou, RAPL in action: experiences in using RAPL for power measurements, ACM TOMPECS 3(2), 2018, doi:10.1145/3177754
• Desrochers, Paradis & Weaver, A validation of DRAM RAPL power measurements, MEMSYS ‘16, doi:10.1145/2989081.2989088
• Shahid, Fahad, Manumachu & Lastovetsky, Energy predictive models of computing: theory, practical implications and experimental analysis on multicore processors, IEEE Access 9, 2021, doi:10.1109/access.2021.3075139
• Shahid, Fahad, Manumachu & Lastovetsky, A comparative study of techniques for energy predictive modeling using performance monitoring counters on modern multicore CPUs, IEEE Access 8, 2020, doi:10.1109/access.2020.3013812
• Shahid, Fahad, Manumachu & Lastovetsky, Improving the accuracy of energy predictive models for multicore CPUs by combining utilization and performance events model variables, JPDC 151, 2021, doi:10.1016/j.jpdc.2021.01.007
• Fahad, Shahid, Manumachu & Lastovetsky, A comparative study of methods for measurement of energy of computing, Energies 12(11), 2019, doi:10.3390/en12112204
• Hofmann, Hager & Fey, On the accuracy and usefulness of analytic energy models for contemporary multicore processors, ISC 2018, doi:10.1007/978-3-319-92040-5_2 (arXiv:1803.01618)
• Wu, Taylor, Cook & Mucci, Using performance-power modeling to improve energy efficiency of HPC applications, Computer 49(10), 2016, doi:10.1109/mc.2016.311
• Fan, Cosenza & Juurlink, Accurate energy and performance prediction for frequency-scaled GPU kernels, Computation 8(2), 2020, doi:10.3390/computation8020037
• Patki, Lowenthal, Sasidharan, Maiterth, Rountree, Schulz & de Supinski, Practical resource management in power-constrained, high performance computing, HPDC ‘15, doi:10.1145/2749246.2749262

Summary table of the most relevant work

Accuracies are as reported by the authors; metrics differ and are named explicitly. “Dataset” is the unit the authors train on. Blank cells mean the abstract did not state the figure and the full text was not accessible without a paywall.

Where this project sits

This section is deliberately blunt. An MSc dissertation is worth more with an honest positioning than with an inflated one, and an examiner who knows this literature will find the inflation.

What is derivative

The overall framing is not new. “Profile with hardware counters, regress a model, predict performance” is a well-populated research area with at least two decades of history and a dedicated workshop series (PMBS). Specifically:

• Decomposing runtime into a mechanistic term plus a learned correction is mechanistic-empirical modelling, published by Eyerman, Hoste and Eeckhout in 2011 [Eyerman2011] at 9–13% error. Our eta framing is the same idea at coarser granularity. We should present it as an application of a known technique, not an invention.
• Making a dimensionless efficiency the modelled quantity is what isoefficiency analysis does, and Shudler et al. [Shudler2017] did it empirically and automatically in 2017.
• Counter-based runtime prediction with CPI refinement is APMT [Ding2020], which reports ~15% average error — squarely in our band, on a larger and more varied workload set, with an extrapolation protocol.
• Merging multiple runs with rotating counter sets to escape the hardware counter limit is a known technique, and Orteu Aubach et al. [OrteuAubach2026] have since done it far more carefully than our join-on-(app, ncore).
• Comparing Ridge/Lasso/RF/GBM/MLP on HPC performance data is precisely Malakar et al. [Malakar2018], with eleven methods rather than five.
• “Neural networks need care at small n” is DeepPerf [Ha2019] and the configurable-systems sampling literature.

What is genuinely novel

Four things survive scrutiny, and they are modest but real.

1. Leave-one-application-out validation for a counter-based runtime model. We could not find a paper that holds out an entire application as the test fold for hardware-counter-driven runtime prediction on a single node. Cross-platform and cross-architecture holdouts are common; cross-* workload* holdout is not. Almost all the ML-over-counters literature we found validates within an application (unseen inputs, unseen scales, unseen configurations), which is interpolation on a smooth surface. This is our strongest methodological contribution, and its value is that it produces worse numbers than the field’s convention — it is a harder, more honest test. It should be argued that way, explicitly, with the point that a random split over our own data would leak adjacent core counts.

2. Feature importance is not interpretable under counter multiplexing. A 40-row table with one problem size per application and no run-length covariate scores core_energy_frac = PP0/PACKAGE at 0.509 random forest importance, which would read as a novel energy -> time result against a literature that runs counters -> energy; on the 191 merged configurations the same feature is 0.008, rank 15 of 21.

   The diagnosis generalises. A small hardware register budget forces rotating counter sets, which produce a feature matrix with structurally missing columns; median imputation collapses those columns to constants, a constant cannot reduce impurity, and the importance mass migrates to whatever is observed. RAPL sits on separate registers and is therefore recorded in every set, which is precisely what made it look dominant. We demonstrate this by re-imposing the multiplexed missingness pattern on the merged data, where it reproduces the inflated ranking (Spearman rho = +0.74) from data known to carry the true signal.

   The prescription is concrete: merge to one row per configuration before interpreting importance, include an explicit scale covariate, vary problem size within application, and confirm with held-out permutation importance. We could find no counter-based performance-modelling paper that flags this, despite multiplexing being near-universal in the field. This is the finding most likely to be of interest outside the dissertation.

3. A costed answer to “do the counters earn their keep?” Feature groups added in order of measurement cost rather than in order of statistical convenience, each compared against a zero-parameter constant under leave-one-application-out with multiple-comparison control. The result is sharp and, unusually for this literature, negative for the cheap options: the full five-counter-set rotation is the only configuration that beats the constant (Holm p = 1.4e-04), free configuration metadata is significantly worse than the constant, and the two intermediate rungs are indistinguishable from it. Most counter-based modelling papers report the accuracy of a chosen feature set without establishing that any cheaper set would have failed, which is the question a practitioner deciding whether to run a profiling campaign actually has.

4. Two negative results with methodological content. (a) Missingness indicators leaked application identity because pat_report omits zero-valued counters in an application-specific pattern, and this only became visible under per-application validation — a concrete instance of the “structure-not-knowledge” failure Jamshidi et al. [Jamshidi2017] describe. (b) The extrapolation asymmetry between tree ensembles and MLPs, demonstrated on a real fold (STREAM) where 0% of test rows lie inside the training range of two key features. Both are small; both are the kind of thing that is under-reported and useful.

How our accuracy actually compares

Uncomfortably. The honest statement:

• A zero-parameter constant-efficiency model achieves ~1.08x median. That is the number to beat, and it is a strong number. Our learned models are “roughly comparable on median, better in the tail”. Under the metric-matched baseline (median, not mean, of log-eta), the counter features buy tail robustness rather than typical-case accuracy.
• Against the literature, ~1.07–1.16x (7–16% median relative error) is in the same band as APMT’s ~15% [Ding2020], Barnes et al.’s < 13% [Barnes2010], Sun et al.’s < 20% [Sun2020], and Owenson et al.’s 9.2% [Owenson2019]. It is well behind Ferrerón et al.’s < 2.3% [Ferreron2017] and behind the best-in-class energy models (1.8–5.5%).
• But those comparisons are not like-for-like. Ferrerón et al. predict a fixed application’s full run from its own sampled regions. The energy models predict a quantity that is far more directly a linear function of counters. Only Ding et al. and Barnes et al. are testing anything close to generalisation, and neither generalises across applications.

The defensible claim is therefore: comparable error to the counter-based HPC performance-prediction literature, obtained under a strictly harder generalisation protocol (unseen application) than that literature uses, with a correctly-specified zero-parameter baseline reported alongside. The claim that does not survive is any headline of the form “we predict unseen-application runtime to X%, better than prior work”. We do not beat prior work on accuracy, and the margin over doing nothing clever at all is small.

A related honesty point. Because a constant-efficiency model gets to ~1.08x, the interesting scientific question shifts. It is no longer “can we predict runtime from counters” — mostly, cycles already do that. It is “what does the residual eta depend on, and does that dependence transfer across workloads?” Framed that way, the counter-value ablation, the multiplexing artefact and the extrapolation result (only smooth models leave the training hull) are the substance of the dissertation, and the point predictions are supporting evidence. That is a better story and it is also the true one.

Gaps and directions

Concrete, grounded in what the surveyed literature has not done, ordered by effort against payoff.

1. Report the LOAO folds as a proxy-fidelity experiment (zero compute). Our dataset uniquely contains benchmarks, ECP/Mantevo proxies and real applications under identical instrumentation. Partition the folds: “predict a real application (GROMACS, OpenFOAM) from proxies and benchmarks” versus “predict a proxy from everything else”. If eta transfers from proxies to parents, that is a quantitative, behaviour-space contribution to the fidelity question that [Barrett2015, Aaziz2018, Aaziz2019] pursue with descriptive statistics rather than predictive tests. If it does not, that is a negative result the ECP proxy community would want. This is a re-analysis of data already on disk.

2. Compare eta against a proper CPI stack rather than treating it as one. Our eta is a scalar; Top-Down [Yasin2014] and CPI stacks [Eyerman2006] are vectors. On Zen 2 a partial Top-Down decomposition is achievable within the 5-counter budget across a couple of rotating sets. Asking “does a 4-component Top-Down vector predict eta better than 20 ad-hoc ratios?” turns a coarse approximation into a controlled comparison against the standard method, and would materially strengthen Section 1’s positioning.

3. The core-energy-fraction finding was attacked, and it did not survive. This item is retained as a record of the check rather than as future work, because it was carried out and returned a negative. (a) It is not a proxy for log_ncore but it was a proxy for missing run length: adding log_t_analytic to the same 40 rows removes 72% of the claimed importance. (b) It does not survive a second platform, because Cirrus has no RAPL at all, and the intersection ablation shows dropping it costs 0.4%. (c) The RAPL caveats in [Khan2018] and [Desrochers2016] turned out to be moot, since the measurement was sound and the inference was not. The feature-ablation table suggested here was run (docs/crossplatform.md, finding 2) and is what first made the claim look doubtful. The lesson is that the check should have preceded the claim.

4. Combine the two orthogonal generalisation axes. Extra-P [Calotoiu2013, Calotoiu2026] extrapolates in scale for a fixed code; we generalise across codes at fixed scales. Nobody appears to have done both: train on codes A–G at 1–32 cores, predict code H at 128 cores. Our data already supports the experiment — train on the low-core rows of seven applications and test on the high-core rows of the eighth. It is a genuinely novel protocol and costs one more retrain2.py variant.

5. Impose Extra-P-style structure on the eta model. Extra-P’s success at tiny n comes from restricting the hypothesis space to the Performance Model Normal Form. Our MLP has no such prior. Fitting eta(p) = 1 / (1 + sum_k c_k * p^{i_k} log^{j_k} p) with counter-derived coefficients would be a hybrid nobody has published: PMNF structure in the scale variable, learned coefficients in the counter space. This directly addresses the small-n problem the way the literature says to address it — inductive bias, not more data [Ritter2020, Ha2019].

6. Fix the multi-run merge properly. Our A–E merge joins on (app, ncore) and assumes runs are interchangeable. [OrteuAubach2026] shows this assumption is application-dependent and offers a burst-matching alternative. At minimum, quantify the run-to-run variance of the counters that are common across sets (TOT_CYC appears in A, B, D, E) and report the implied error floor on eta. This is a threat-to-validity our current modelling.md does not quantify.

7. Move beyond rank 0. Every counter we have is rank-0-only, so load imbalance is invisible and appears only implicitly inside eta. The proxy literature [Aaziz2019] found that dynamic rather than aggregate behaviour was where proxy/parent mismatches hid; the same is likely true here. Even a coarse imbalance proxy from CrayPat’s per-function MPI timings, added as a feature, would test whether the residual eta variance we cannot explain is load imbalance.

8. Second platform, or say clearly that we cannot claim hardware transfer. The dissertation is titled “Modelling Hardware”, but every measurement is from one EPYC 7742. What is demonstrated is transfer across workload, not across hardware. Either add a second machine (the ARCHER2 budget position makes this unlikely) or make the scoping explicit and cite [Jamshidi2017] on why cross-hardware transfer is a different and harder problem. The current framing risks over-claiming in the title.

BibTeX

@article{Williams2009,
  author  = {Williams, Samuel and Waterman, Andrew and Patterson, David},
  title   = {Roofline: An Insightful Visual Performance Model for Multicore Architectures},
  journal = {Communications of the ACM}, volume = {52}, number = {4},
  pages   = {65--76}, year = {2009}, doi = {10.1145/1498765.1498785}
}

@article{Hager2013,
  author  = {Hager, Georg and Treibig, Jan and Habich, Johannes and Wellein, Gerhard},
  title   = {Exploring performance and power properties of modern multicore chips via simple machine models},
  journal = {Concurrency and Computation: Practice and Experience},
  volume  = {28}, number = {2}, pages = {189--210}, year = {2013},
  doi     = {10.1002/cpe.3180}, note = {arXiv:1208.2908}
}

@inproceedings{Stengel2015,
  author    = {Stengel, Holger and Treibig, Jan and Hager, Georg and Wellein, Gerhard},
  title     = {Quantifying Performance Bottlenecks of Stencil Computations Using the Execution-Cache-Memory Model},
  booktitle = {Proceedings of the 29th ACM International Conference on Supercomputing (ICS '15)},
  pages     = {207--216}, year = {2015}, doi = {10.1145/2751205.2751240}
}

@incollection{Hammer2017,
  author    = {Hammer, Julian and Eitzinger, Jan and Hager, Georg and Wellein, Gerhard},
  title     = {Kerncraft: A Tool for Analytic Performance Modeling of Loop Kernels},
  booktitle = {Tools for High Performance Computing 2016},
  year      = {2017}, doi = {10.1007/978-3-319-56702-0_1}
}

@article{Hofmann2020,
  author  = {Hofmann, Johannes and Alappat, Christie L. and Hager, Georg and Fey, Dietmar and Wellein, Gerhard},
  title   = {Bridging the Architecture Gap: Abstracting Performance-Relevant Properties of Modern Server Processors},
  journal = {Supercomputing Frontiers and Innovations}, volume = {7}, number = {2},
  year    = {2020}, doi = {10.14529/jsfi200204}
}

@inproceedings{Eyerman2006,
  author    = {Eyerman, Stijn and Eeckhout, Lieven and Karkhanis, Tejas and Smith, James E.},
  title     = {A performance counter architecture for computing accurate {CPI} components},
  booktitle = {Proceedings of ASPLOS XII}, series = {ACM SIGPLAN Notices 41(11)},
  pages     = {175--184}, year = {2006}, doi = {10.1145/1168918.1168880}
}

@article{Eyerman2007,
  author  = {Eyerman, Stijn and Eeckhout, Lieven and Karkhanis, Tejas and Smith, James E.},
  title   = {A Top-Down Approach to Architecting {CPI} Component Performance Counters},
  journal = {IEEE Micro}, volume = {27}, number = {1}, year = {2007},
  doi     = {10.1109/mm.2007.3}
}

@inproceedings{Eyerman2011,
  author    = {Eyerman, Stijn and Hoste, Kenneth and Eeckhout, Lieven},
  title     = {Mechanistic-empirical processor performance modeling for constructing {CPI} stacks on real hardware},
  booktitle = {IEEE International Symposium on Performance Analysis of Systems and Software (ISPASS)},
  pages     = {216--226}, year = {2011}, doi = {10.1109/ispass.2011.5762738}
}

@inproceedings{Yasin2014,
  author    = {Yasin, Ahmad},
  title     = {A Top-Down method for performance analysis and counters architecture},
  booktitle = {IEEE International Symposium on Performance Analysis of Systems and Software (ISPASS)},
  pages     = {35--44}, year = {2014}, doi = {10.1109/ispass.2014.6844459}
}

@article{Ilic2014,
  author  = {Ili\'{c}, Aleksandar and Pratas, Frederico and Sousa, Leonel},
  title   = {Cache-aware Roofline model: Upgrading the loft},
  journal = {IEEE Computer Architecture Letters}, volume = {13}, number = {1},
  pages   = {21--24}, year = {2014}, doi = {10.1109/l-ca.2013.6}
}

@article{Ilic2017,
  author  = {Ili\'{c}, Aleksandar and Pratas, Frederico and Sousa, Leonel},
  title   = {Beyond the Roofline: Cache-Aware Power and Energy-Efficiency Modeling for Multi-Cores},
  journal = {IEEE Transactions on Computers}, volume = {66}, number = {1},
  pages   = {52--58}, year = {2017}, doi = {10.1109/tc.2016.2582151}
}

@article{Afzal2025,
  author  = {Afzal, Ayesha and Hager, Georg and Wellein, Gerhard},
  title   = {Analytic roofline modeling and energy analysis of the {LULESH} proxy application on multi-core clusters},
  journal = {The International Journal of High Performance Computing Applications},
  volume  = {40}, number = {1}, pages = {123--141}, year = {2025},
  doi     = {10.1177/10943420251363711}, note = {arXiv:2412.08792}
}

@inproceedings{Culler1993,
  author    = {Culler, David and Karp, Richard and Patterson, David and Sahay, Abhijit
               and Schauser, Klaus Erik and Santos, Eunice and Subramonian, Ramesh
               and von Eicken, Thorsten},
  title     = {{LogP}: towards a realistic model of parallel computation},
  booktitle = {Proceedings of the 4th ACM SIGPLAN Symposium on Principles and Practice of Parallel Programming (PPoPP '93)},
  year      = {1993}, doi = {10.1145/155332.155333}
}

@article{Alexandrov1997,
  author  = {Alexandrov, Albert and Ionescu, Mihai F. and Schauser, Klaus E. and Scheiman, Chris},
  title   = {{LogGP}: Incorporating Long Messages into the {LogP} Model for Parallel Computation},
  journal = {Journal of Parallel and Distributed Computing}, volume = {44}, number = {1},
  pages   = {71--79}, year = {1997}, doi = {10.1006/jpdc.1997.1346}
}

@inproceedings{Amdahl1967,
  author    = {Amdahl, Gene M.},
  title     = {Validity of the single processor approach to achieving large scale computing capabilities},
  booktitle = {AFIPS Spring Joint Computer Conference}, pages = {483--485},
  year      = {1967}, doi = {10.1145/1465482.1465560}
}

@article{Gustafson1988,
  author  = {Gustafson, John L.},
  title   = {Reevaluating {Amdahl's} law},
  journal = {Communications of the ACM}, volume = {31}, number = {5},
  pages   = {532--533}, year = {1988}, doi = {10.1145/42411.42415}
}

@article{Browne2000,
  author  = {Browne, Shirley and Dongarra, Jack and Garner, Nicole and Ho, George and Mucci, Philip},
  title   = {A Portable Programming Interface for Performance Evaluation on Modern Processors},
  journal = {The International Journal of High Performance Computing Applications},
  volume  = {14}, number = {3}, pages = {189--204}, year = {2000},
  doi     = {10.1177/109434200001400303}
}

@article{Ding2020,
  author  = {Ding, Nan and Lee, Victor W. and Xue, Wei and Zheng, Weimin},
  title   = {{APMT}: an automatic hardware counter-based performance modeling tool for {HPC} applications},
  journal = {CCF Transactions on High Performance Computing}, volume = {2},
  pages   = {135--148}, year = {2020}, doi = {10.1007/s42514-020-00035-8}
}

@inproceedings{Malakar2018,
  author    = {Malakar, Preeti and Balaprakash, Prasanna and Vishwanath, Venkatram
               and Morozov, Vitali and Kumaran, Kalyan},
  title     = {Benchmarking Machine Learning Methods for Performance Modeling of Scientific Applications},
  booktitle = {IEEE/ACM Performance Modeling, Benchmarking and Simulation of High Performance Computer Systems (PMBS)},
  pages     = {33--44}, year = {2018}, doi = {10.1109/pmbs.2018.8641686}
}

@article{Sun2020,
  author  = {Sun, Jingwei and Sun, Guangzhong and Zhan, Shiyan and Zhang, Jiepeng and Chen, Yong},
  title   = {Automated Performance Modeling of {HPC} Applications Using Machine Learning},
  journal = {IEEE Transactions on Computers}, volume = {69}, number = {5},
  pages   = {749--763}, year = {2020}, doi = {10.1109/tc.2020.2964767}
}

@misc{OrteuAubach2026,
  author = {Orteu Aubach, J\'{u}lia and Banchelli, Fabio and Clasc\`{a} Ram\'{i}rez, Marc
            and Garcia-Gasulla, Marta},
  title  = {Heuristic-Based Merging of {HPC} Traces to Extend Hardware Counter Coverage},
  year   = {2026}, eprint = {2605.15832}, archivePrefix = {arXiv}
}

@inproceedings{Das2019,
  author    = {Das, Sanjeev and Werner, Jan and Antonakakis, Manos
               and Polychronakis, Michalis and Monrose, Fabian},
  title     = {{SoK}: The Challenges, Pitfalls, and Perils of Using Hardware Performance Counters for Security},
  booktitle = {IEEE Symposium on Security and Privacy}, year = {2019},
  doi       = {10.1109/sp.2019.00021}
}

@inproceedings{Hackenberg2015,
  author    = {Hackenberg, Daniel and Sch\"{o}ne, Robert and Ilsche, Thomas
               and Molka, Daniel and Schuchart, Joseph and Geyer, Robin},
  title     = {An Energy Efficiency Feature Survey of the {Intel Haswell} Processor},
  booktitle = {IEEE International Parallel and Distributed Processing Symposium Workshop (IPDPSW)},
  pages     = {896--904}, year = {2015}, doi = {10.1109/ipdpsw.2015.70}
}

@article{Wang2018,
  author  = {Wang, Yu and Lee, Victor and Wei, Gu-Yeon and Brooks, David},
  title   = {Predicting New Workload or {CPU} Performance by Analyzing Public Datasets},
  journal = {ACM Transactions on Architecture and Code Optimization},
  volume  = {15}, number = {4}, pages = {1--21}, year = {2018},
  doi     = {10.1145/3284127}
}

@inproceedings{Ardalani2015,
  author    = {Ardalani, Newsha and Lestourgeon, Clint and Sankaralingam, Karthikeyan and Zhu, Xiaojin},
  title     = {Cross-architecture performance prediction ({XAPP}) using {CPU} code to predict {GPU} performance},
  booktitle = {Proceedings of the 48th International Symposium on Microarchitecture (MICRO-48)},
  pages     = {725--737}, year = {2015}, doi = {10.1145/2830772.2830780}
}

@inproceedings{Yang2005,
  author    = {Yang, Laurence T. and Ma, Xiaosong and Mueller, Frank},
  title     = {Cross-Platform Performance Prediction of Parallel Applications Using Partial Execution},
  booktitle = {Proceedings of the ACM/IEEE Conference on Supercomputing (SC '05)},
  year      = {2005}, doi = {10.1109/sc.2005.20}
}

@inproceedings{Mahdavi2024,
  author    = {Mahdavi, Kaveh},
  title     = {A Hybrid Machine Learning Method for Cross-Platform Performance Prediction of Parallel Applications},
  booktitle = {Proceedings of the 53rd International Conference on Parallel Processing (ICPP)},
  pages     = {669--678}, year = {2024}, doi = {10.1145/3673038.3673059}
}

@inproceedings{Marathe2017,
  author    = {Marathe, Aniruddha and Anirudh, Rushil and Jain, Nikhil and Bhatele, Abhinav
               and Thiagarajan, Jayaraman and Kailkhura, Bhavya and Yeom, Jae-Seung
               and Rountree, Barry and Gamblin, Todd},
  title     = {Performance modeling under resource constraints using deep transfer learning},
  booktitle = {Proceedings of the International Conference for High Performance Computing,
               Networking, Storage and Analysis (SC '17)},
  year      = {2017}, doi = {10.1145/3126908.3126969}
}

@inproceedings{Jamshidi2017,
  author    = {Jamshidi, Pooyan and Siegmund, Norbert and Velez, Miguel
               and K\"{a}stner, Christian and Patel, Akshay and Agarwal, Yuvraj},
  title     = {Transfer learning for performance modeling of configurable systems: An exploratory analysis},
  booktitle = {32nd IEEE/ACM International Conference on Automated Software Engineering (ASE)},
  pages     = {497--508}, year = {2017}, doi = {10.1109/ase.2017.8115661}
}

@inproceedings{Ferreron2017,
  author    = {Ferrer\'{o}n, Alexandra and Jagtap, Radhika and Bischoff, Sascha and Rusitoru, Roxana},
  title     = {Crossing the architectural barrier: Evaluating representative regions of parallel {HPC} applications},
  booktitle = {IEEE International Symposium on Performance Analysis of Systems and Software (ISPASS)},
  pages     = {109--120}, year = {2017}, doi = {10.1109/ispass.2017.7975275}
}

@inproceedings{Barnes2008,
  author    = {Barnes, Bradley J. and Rountree, Barry and Lowenthal, David K.
               and Reeves, Jaxk and de Supinski, Bronis and Schulz, Martin},
  title     = {A regression-based approach to scalability prediction},
  booktitle = {Proceedings of the 22nd Annual International Conference on Supercomputing (ICS '08)},
  pages     = {368--377}, year = {2008}, doi = {10.1145/1375527.1375580}
}

@inproceedings{Barnes2010,
  author    = {Barnes, Brad and Garren, Jeonifer and Lowenthal, David K. and Reeves, Jaxk
               and de Supinski, Bronis R. and Schulz, Martin and Rountree, Barry},
  title     = {Using focused regression for accurate time-constrained scaling of scientific applications},
  booktitle = {IEEE International Symposium on Parallel and Distributed Processing (IPDPS)},
  year      = {2010}, doi = {10.1109/ipdps.2010.5470431}
}

@inproceedings{Hoefler2015,
  author    = {Hoefler, Torsten and Belli, Roberto},
  title     = {Scientific benchmarking of parallel computing systems},
  booktitle = {Proceedings of the International Conference for High Performance Computing,
               Networking, Storage and Analysis (SC '15)},
  year      = {2015}, doi = {10.1145/2807591.2807644}
}

@techreport{Heroux2009,
  author      = {Heroux, Michael A. and Crozier, Paul and Thornquist, Heidi and Numrich, Robert
                 and Williams, Alan and Edwards, H. Carter and Keiter, Eric},
  title       = {Improving Performance via Mini-applications},
  institution = {Sandia National Laboratories}, number = {SAND2009-5574},
  year        = {2009}, doi = {10.2172/993908}
}

@article{Barrett2015,
  author  = {Barrett, Richard F. and Crozier, Paul S. and Doerfler, Douglas W.
             and Heroux, Michael A. and Lin, Paul T. and Thornquist, Heidi K.
             and Trucano, Timothy G. and Vaughan, Courtenay T.},
  title   = {Assessing the role of mini-applications in predicting key performance
             characteristics of scientific and engineering applications},
  journal = {Journal of Parallel and Distributed Computing}, volume = {75},
  pages   = {107--122}, year = {2015}, doi = {10.1016/j.jpdc.2014.09.006}
}

@inproceedings{Aaziz2018,
  author    = {Aaziz, Omar and Cook, Jeanine and Cook, Jonathan and Juedeman, Tanner
               and Richards, David F. and Vaughan, Courtenay},
  title     = {A Methodology for Characterizing the Correspondence Between Real and Proxy Applications},
  booktitle = {IEEE International Conference on Cluster Computing (CLUSTER)},
  pages     = {190--200}, year = {2018}, doi = {10.1109/cluster.2018.00037}
}

@inproceedings{Aaziz2019,
  author    = {Aaziz, Omar and Vaughan, Courtenay and Cook, Jonathan and Cook, Jeanine
               and Kuehn, Jeffery A. and Richards, David F.},
  title     = {Fine-Grained Analysis of Communication Similarity between Real and Proxy Applications},
  booktitle = {IEEE/ACM Performance Modeling, Benchmarking and Simulation of High Performance
               Computer Systems (PMBS)},
  pages     = {93--102}, year = {2019}, doi = {10.1109/pmbs49563.2019.00016}
}

@techreport{Richards2020,
  author      = {Richards, David and Aaziz, Omar and Cook, Jeanine and Kuehn, Jeffrey
                 and Moore, Shirley and Pruitt, David},
  title       = {Quantitative Performance Assessment of Proxy Apps and Parents
                 ({ECP} Proxy App Project Milestone ADCD-504-9)},
  institution = {U.S. Department of Energy}, year = {2020}, doi = {10.2172/1617284}
}

@article{Owenson2019,
  author  = {Owenson, Andrew M. B. and Wright, Steven A. and Bunt, Richard and Ho, Y. K.
             and Street, M. J. and Jarvis, Stephen A.},
  title   = {An unstructured {CFD} mini-application for the performance prediction of a production {CFD} code},
  journal = {Concurrency and Computation: Practice and Experience}, volume = {32}, number = {10},
  year    = {2019}, doi = {10.1002/cpe.5443}
}

@article{Matsuoka2022,
  author  = {Matsuoka, Satoshi and Domke, Jens and Wahib, Mohamed and Drozd, Aleksandr
             and Chien, Andrew A. and Bair, Raymond A. and Vetter, Jeffrey S. and Shalf, John},
  title   = {Preparing for the Future---Rethinking Proxy Applications},
  journal = {Computing in Science \& Engineering}, volume = {24}, number = {2},
  pages   = {85--90}, year = {2022}, doi = {10.1109/mcse.2022.3153105}
}

@misc{McKinsey2026,
  author = {McKinsey, Michael and Brink, Stephanie and Pearce, Olga},
  title  = {On Similarity of Computational Kernels in our Codes and Proxies},
  year   = {2026}, eprint = {2605.06968}, archivePrefix = {arXiv}
}

@inproceedings{Karlin2013,
  author    = {Karlin, Ian and Bhatele, Abhinav and Keasler, Jeff and Chamberlain, Bradford L.
               and Cohen, Jonathan and DeVito, Zachary and Haque, Riyaz and Laney, Dan
               and Luke, Edward and Wang, Felix and Richards, David and Schulz, Martin
               and Still, Charles H.},
  title     = {Exploring Traditional and Emerging Parallel Programming Models Using a Proxy Application},
  booktitle = {IEEE 27th International Symposium on Parallel and Distributed Processing (IPDPS)},
  pages     = {919--932}, year = {2013}, doi = {10.1109/ipdps.2013.115}
}

@article{Pearce2019,
  author  = {Pearce, Olga and Ahmed, Hadia and Larsen, Rasmus W. and Pirkelbauer, Peter
             and Richards, David F.},
  title   = {Exploring dynamic load imbalance solutions with the {CoMD} proxy application},
  journal = {Future Generation Computer Systems}, volume = {92}, pages = {920--932},
  year    = {2019}, doi = {10.1016/j.future.2017.12.010}
}

@article{Dongarra2015,
  author  = {Dongarra, Jack and Heroux, Michael A. and {\L}uszczek, Piotr},
  title   = {High-performance conjugate-gradient benchmark: A new metric for ranking
             high-performance computing systems},
  journal = {The International Journal of High Performance Computing Applications},
  volume  = {30}, number = {1}, pages = {3--10}, year = {2015},
  doi     = {10.1177/1094342015593158}
}

@article{Dongarra2003,
  author  = {Dongarra, Jack J. and {\L}uszczek, Piotr and Petitet, Antoine},
  title   = {The {LINPACK} Benchmark: past, present and future},
  journal = {Concurrency and Computation: Practice and Experience},
  volume  = {15}, number = {9}, pages = {803--820}, year = {2003},
  doi     = {10.1002/cpe.728}
}

@misc{McCalpin1995,
  author = {McCalpin, John D.},
  title  = {{STREAM}: Sustainable Memory Bandwidth in High Performance Computers},
  year   = {1995},
  note   = {Technical report, University of Virginia.
            \url{https://www.cs.virginia.edu/stream/}. No DOI could be resolved
            for this report via Crossref or OpenAlex; cited as a technical report.}
}

@inproceedings{Ritter2020,
  author    = {Ritter, Marcus and Calotoiu, Alexandru and Rinke, Sebastian and Reimann, Thorsten
               and Hoefler, Torsten and Wolf, Felix},
  title     = {Learning Cost-Effective Sampling Strategies for Empirical Performance Modeling},
  booktitle = {IEEE International Parallel and Distributed Processing Symposium (IPDPS)},
  pages     = {884--895}, year = {2020}, doi = {10.1109/ipdps47924.2020.00095}
}

@article{Ritter2026,
  author  = {Ritter, Marcus and Naumann, Benedikt and Calotoiu, Alexandru and Rinke, Sebastian
             and Reimann, Thorsten and Hoefler, Torsten and Wolf, Felix},
  title   = {Cost-Effective Empirical Performance Modeling},
  journal = {IEEE Transactions on Parallel and Distributed Systems},
  volume  = {37}, number = {3}, pages = {575--592}, year = {2026},
  doi     = {10.1109/tpds.2025.3646119}
}

@inproceedings{Ritter2021,
  author    = {Ritter, Marcus and Geis, Alexander B. U. and Wehrstein, Johannes
               and Calotoiu, Alexandru and Reimann, Thorsten and Hoefler, Torsten and Wolf, Felix},
  title     = {Noise-Resilient Empirical Performance Modeling with Deep Neural Networks},
  booktitle = {IEEE International Parallel and Distributed Processing Symposium (IPDPS)},
  pages     = {23--34}, year = {2021}, doi = {10.1109/ipdps49936.2021.00012}
}

@inproceedings{Ritter2023,
  author    = {Ritter, Marcus and Wolf, Felix},
  title     = {Extra-Deep: Automated Empirical Performance Modeling for Distributed Deep Learning},
  booktitle = {Proceedings of the SC '23 Workshops of the International Conference on High
               Performance Computing, Network, Storage, and Analysis},
  pages     = {1345--1356}, year = {2023}, doi = {10.1145/3624062.3624204}
}

@inproceedings{Ha2019,
  author    = {Ha, Huong and Zhang, Hongyu},
  title     = {{DeepPerf}: Performance Prediction for Configurable Software with Deep Sparse Neural Network},
  booktitle = {IEEE/ACM 41st International Conference on Software Engineering (ICSE)},
  pages     = {1095--1106}, year = {2019}, doi = {10.1109/icse.2019.00113}
}

@inproceedings{Kaltenecker2019,
  author    = {Kaltenecker, Christian and Grebhahn, Alexander and Siegmund, Norbert
               and Guo, Jianmei and Apel, Sven},
  title     = {Distance-Based Sampling of Software Configuration Spaces},
  booktitle = {IEEE/ACM 41st International Conference on Software Engineering (ICSE)},
  pages     = {1084--1094}, year = {2019}, doi = {10.1109/icse.2019.00112}
}

@article{Kaltenecker2020,
  author  = {Kaltenecker, Christian and Grebhahn, Alexander and Siegmund, Norbert and Apel, Sven},
  title   = {The Interplay of Sampling and Machine Learning for Software Performance Prediction},
  journal = {IEEE Software}, volume = {37}, number = {4}, pages = {58--66},
  year    = {2020}, doi = {10.1109/ms.2020.2987024}
}

@inproceedings{DeSensi2016,
  author    = {De Sensi, Daniele},
  title     = {Predicting Performance and Power Consumption of Parallel Applications},
  booktitle = {24th Euromicro International Conference on Parallel, Distributed,
               and Network-Based Processing (PDP)},
  pages     = {200--207}, year = {2016}, doi = {10.1109/pdp.2016.41}
}

@inproceedings{Calotoiu2013,
  author    = {Calotoiu, Alexandru and Hoefler, Torsten and Poke, Marius and Wolf, Felix},
  title     = {Using automated performance modeling to find scalability bugs in complex codes},
  booktitle = {Proceedings of the International Conference on High Performance Computing,
               Networking, Storage and Analysis (SC '13)},
  year      = {2013}, doi = {10.1145/2503210.2503277}
}

@inproceedings{Calotoiu2016,
  author    = {Calotoiu, Alexandru and Beckinsale, David and Earl, Christopher W.
               and Hoefler, Torsten and Karlin, Ian and Schulz, Martin and Wolf, Felix},
  title     = {Fast Multi-parameter Performance Modeling},
  booktitle = {IEEE International Conference on Cluster Computing (CLUSTER)},
  pages     = {172--181}, year = {2016}, doi = {10.1109/cluster.2016.57}
}

@incollection{Calotoiu2020,
  author    = {Calotoiu, Alexandru and Copik, Marcin and Hoefler, Torsten and Ritter, Marcus
               and Shudler, Sergei and Wolf, Felix},
  title     = {{ExtraPeak}: Advanced Automatic Performance Modeling for {HPC} Applications},
  booktitle = {Lecture Notes in Computational Science and Engineering},
  pages     = {453--482}, year = {2020}, doi = {10.1007/978-3-030-47956-5_15}
}

@article{Calotoiu2026,
  author  = {Calotoiu, Alexandru and Copik, Marcin and Czappa, Fabian and Geiss, Alexander
             and de Morais, Gustavo and Ritter, Marcus and Shudler, Sergei
             and Hoefler, Torsten and Wolf, Felix},
  title   = {{Extra-P}---Empirical performance modeling made easy},
  journal = {Frontiers in High Performance Computing}, volume = {3}, year = {2026},
  doi     = {10.3389/fhpcp.2025.1714042}
}

@inproceedings{Shudler2015,
  author    = {Shudler, Sergei and Calotoiu, Alexandru and Hoefler, Torsten
               and Strube, Alexandre and Wolf, Felix},
  title     = {Exascaling Your Library: Will Your Implementation Meet Your Expectations?},
  booktitle = {Proceedings of the 29th ACM International Conference on Supercomputing (ICS '15)},
  pages     = {165--175}, year = {2015}, doi = {10.1145/2751205.2751216}
}

@inproceedings{Shudler2017,
  author    = {Shudler, Sergei and Calotoiu, Alexandru and Hoefler, Torsten and Wolf, Felix},
  title     = {Isoefficiency in Practice: Configuring and Understanding the Performance
               of Task-based Applications},
  booktitle = {Proceedings of the 22nd ACM SIGPLAN Symposium on Principles and Practice
               of Parallel Programming (PPoPP '17)},
  pages     = {131--143}, year = {2017}, doi = {10.1145/3018743.3018770}
}

@inproceedings{Vetter2001,
  author    = {Vetter, Jeffrey S. and McCracken, Michael O.},
  title     = {Statistical scalability analysis of communication operations in distributed applications},
  booktitle = {Proceedings of the 8th ACM SIGPLAN Symposium on Principles and Practices
               of Parallel Programming (PPoPP '01)},
  year      = {2001}, doi = {10.1145/379539.379590}
}

@inproceedings{Contreras2005,
  author    = {Contreras, Gilberto and Martonosi, Margaret},
  title     = {Power prediction for {Intel XScale} processors using performance monitoring unit events},
  booktitle = {Proceedings of the International Symposium on Low Power Electronics and Design (ISLPED '05)},
  year      = {2005}, doi = {10.1145/1077603.1077657}
}

@inproceedings{Nagasaka2010,
  author    = {Nagasaka, Hitoshi and Maruyama, Naoya and Nukada, Akira and Endo, Toshio
               and Matsuoka, Satoshi},
  title     = {Statistical power modeling of {GPU} kernels using performance counters},
  booktitle = {International Conference on Green Computing}, pages = {115--122},
  year      = {2010}, doi = {10.1109/greencomp.2010.5598315}
}

@inproceedings{Huang2012,
  author    = {Huang, Wei and Lefurgy, Charles and Kuk, William and Buyuktosunoglu, Alper
               and Floyd, Michael and Rajamani, Karthick and Allen-Ware, Malcolm and Brock, Bishop},
  title     = {Accurate Fine-Grained Processor Power Proxies},
  booktitle = {45th Annual IEEE/ACM International Symposium on Microarchitecture (MICRO)},
  pages     = {224--234}, year = {2012}, doi = {10.1109/micro.2012.29}
}

@inproceedings{Tiwari2012,
  author    = {Tiwari, Ananta and Laurenzano, Michael A. and Carrington, Laura and Snavely, Allan},
  title     = {Modeling Power and Energy Usage of {HPC} Kernels},
  booktitle = {IEEE 26th International Parallel and Distributed Processing Symposium
               Workshops \& PhD Forum (IPDPSW)},
  pages     = {990--998}, year = {2012}, doi = {10.1109/ipdpsw.2012.121}
}

@article{Khan2018,
  author  = {Khan, Kashif Nizam and Hirki, Mikael and Niemi, Tapio
             and Nurminen, Jukka K. and Ou, Zhonghong},
  title   = {{RAPL} in Action: Experiences in Using {RAPL} for Power Measurements},
  journal = {ACM Transactions on Modeling and Performance Evaluation of Computing Systems},
  volume  = {3}, number = {2}, pages = {1--26}, year = {2018}, doi = {10.1145/3177754}
}

@inproceedings{Desrochers2016,
  author    = {Desrochers, Spencer and Paradis, Chad and Weaver, Vincent M.},
  title     = {A Validation of {DRAM} {RAPL} Power Measurements},
  booktitle = {Proceedings of the Second International Symposium on Memory Systems (MEMSYS '16)},
  year      = {2016}, doi = {10.1145/2989081.2989088}
}

@article{Shahid2021,
  author  = {Shahid, Arsalan and Fahad, Muhammad and Manumachu, Ravi Reddy and Lastovetsky, Alexey},
  title   = {Energy Predictive Models of Computing: Theory, Practical Implications and
             Experimental Analysis on Multicore Processors},
  journal = {IEEE Access}, volume = {9}, pages = {63149--63172}, year = {2021},
  doi     = {10.1109/access.2021.3075139}
}

@article{Shahid2020,
  author  = {Shahid, Arsalan and Fahad, Muhammad and Manumachu, Ravi Reddy and Lastovetsky, Alexey},
  title   = {A Comparative Study of Techniques for Energy Predictive Modeling Using
             Performance Monitoring Counters on Modern Multicore {CPUs}},
  journal = {IEEE Access}, volume = {8}, pages = {143306--143332}, year = {2020},
  doi     = {10.1109/access.2020.3013812}
}

@article{Shahid2019jpdc,
  author  = {Shahid, Arsalan and Fahad, Muhammad and Manumachu, Ravi Reddy and Lastovetsky, Alexey},
  title   = {Improving the accuracy of energy predictive models for multicore {CPUs} by
             combining utilization and performance events model variables},
  journal = {Journal of Parallel and Distributed Computing}, volume = {151},
  pages   = {38--51}, year = {2021}, doi = {10.1016/j.jpdc.2021.01.007}
}

@article{Fahad2019,
  author  = {Fahad, Muhammad and Shahid, Arsalan and Manumachu, Ravi Reddy and Lastovetsky, Alexey},
  title   = {A Comparative Study of Methods for Measurement of Energy of Computing},
  journal = {Energies}, volume = {12}, number = {11}, pages = {2204}, year = {2019},
  doi     = {10.3390/en12112204}
}

@incollection{Hofmann2018,
  author    = {Hofmann, Johannes and Hager, Georg and Fey, Dietmar},
  title     = {On the Accuracy and Usefulness of Analytic Energy Models for
               Contemporary Multicore Processors},
  booktitle = {High Performance Computing (ISC 2018)}, series = {Lecture Notes in Computer Science},
  year      = {2018}, doi = {10.1007/978-3-319-92040-5_2}, note = {arXiv:1803.01618}
}

@article{Wu2016,
  author  = {Wu, Xingfu and Taylor, Valerie and Cook, Jeanine and Mucci, Philip J.},
  title   = {Using Performance-Power Modeling to Improve Energy Efficiency of {HPC} Applications},
  journal = {Computer}, volume = {49}, number = {10}, pages = {20--29}, year = {2016},
  doi     = {10.1109/mc.2016.311}
}

@article{Fan2020,
  author  = {Fan, Kaijie and Cosenza, Biagio and Juurlink, Ben},
  title   = {Accurate Energy and Performance Prediction for Frequency-Scaled {GPU} Kernels},
  journal = {Computation}, volume = {8}, number = {2}, pages = {37}, year = {2020},
  doi     = {10.3390/computation8020037}
}

@inproceedings{Patki2015,
  author    = {Patki, Tapasya and Lowenthal, David K. and Sasidharan, Anjana and Maiterth, Matthias
               and Rountree, Barry L. and Schulz, Martin and de Supinski, Bronis R.},
  title     = {Practical Resource Management in Power-Constrained, High Performance Computing},
  booktitle = {Proceedings of the 24th International Symposium on High-Performance
               Parallel and Distributed Computing (HPDC '15)},
  year      = {2015}, doi = {10.1145/2749246.2749262}
}

Bibliographic details for the citations above (authors, titles, venues, years, DOIs and arXiv identifiers) were taken from the Crossref, OpenAlex, arXiv and Semantic Scholar APIs rather than transcribed by hand. The single exception is McCalpin1995 (STREAM), for which no DOI could be resolved through any of those services; it is cited as a technical report with a URL rather than with a fabricated identifier. The working corpus, including a one-line note on why each screened paper is relevant and a record of searches that returned nothing, is at literature_corpus.md.