Pith. sign in

REVIEW 4 major objections 6 minor 48 references

Performance Debugging through Microarchitectural Sensitivity and Causality Analysis

T0 review · 4 major / 6 minor · reviewed 2026-08-11 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read This paper claims that the true bottleneck of an out-of-order CPU kernel can be found by propagating 'who delayed whom' constraints through a coarse simulator, so each instruction is charged only when it actually caused a stall.

desk verdict Solid tool paper with a genuinely new causality-analysis idea, but the central attribution claim is under-validated. read the letter →

arxiv 2412.13207 v1 pith:RMSKG7EH submitted 2024-12-03 cs.DC cs.PF

Alban Dutilleul , Hugo Pompougnac , Nicolas Derumigny , Gabriel Rodriguez , Valentin Trophime , Christophe Guillon , Fabrice Rastello This is my paper · ORCID
classification cs.DCcs.PF
keywords performancedebuggingbottleneckanalysisout-of-orderCPUsensitivitycausalitydynamicbinaryinstrumentationmicroarchitecturalsimulationresourcemapping
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

Modern out-of-order CPUs mislead performance tools: a saturated execution port is often a symptom, not the cause, and correlation-based profilers can point at the wrong code. This paper presents Gus, a profiler that simulates the CPU with a coarse resource-centric model and uses two analyses to find real bottlenecks. Sensitivity analysis re-runs the model with each resource's capacity changed and measures the resulting speedup, revealing which resource (latency, port throughput, cache bandwidth, retire bandwidth, ROB size) actually limits a kernel. Causality analysis propagates constraints through the model so that each dynamic instruction's delay is attributed to the instructions and resources that caused it, producing a per-instruction count of contributions to the critical path. On 1,624 transformed kernels across six microarchitectures the model predicts cycle counts with a mean absolute percentage error of roughly 19 to 39 percent, and in the paper's motivating example it finds that a loop reported as memory- and core-bound is actually limited by a fused multiply-add dependency chain.

What carries the argument

The central object is Algorithm 1, a constraint-propagation simulation of an out-of-order core. Each abstract resource (front-end decode, port groups, cache bandwidth between levels, retire bandwidth, dispatch queue) carries an earliest-available timestamp and a taint set. For each dynamic instruction, the algorithm takes the maximum of the arrival times of the resources and operands it needs, pushes the instruction into the taint set of every resource it uses, and records a lower-bound start time. The taint queue is kept at twice the ROB size, and when an old instruction $i'$ is popped, if it appears in the dispatch resource's taint set, the counter for its static PC is incremented. The model replaces detailed port scheduling with a conjunctive resource mapping, where an instruction claims a list of abstract resources (possibly several times for multi-micro-op instructions), and this simplification is what makes propagating constraints and taints well-defined.

What would settle it

Run the paper's motivating loop in a cycle-accurate out-of-order simulator that models a real scheduler and port assignment; if removing one instruction from the taint-identified dependency chain (while keeping port pressure identical by changing register allocation) does not reduce execution time by roughly its latency, then the causality attribution is wrong, and if it does, the attribution is confirmed.

Watch

Extended reading notes

Core claim

The central claim is that a resource's utilization does not tell you whether it is a bottleneck; only the effect of changing it does, and only constraint propagation can name the offending instructions. Gus's simulator keeps, for every abstract resource and in-flight instruction, an earliest-available time $t_{avail}$ and a taint set recording the dynamic instructions that constrained it. When one resource's availability constrains another, the taint set is propagated; when an instruction's dispatch is delayed, the delayed instruction's taint set is charged to the static PCs of all old instructions still in flight that contributed to the delay. The authors show that on the paper's running example this points to the vfmadd-to-vfmadd dependency chain on register ymm0 as the critical path, whereas Top-down Microarchitecture Analysis (TMA) splits the same execution between memory-bound and core-bound because it can only correlate port pressure with stalls. The intended consequence is that bottleneck analysis becomes both a ranking of constrained resources (sensitivity) and an instruction-level causal map (causality), with the causal map from Algorithm 1's taint propagation as the new element.

Load-bearing premise

The whole analysis assumes that the coarse earliest-available-time simulation, with fixed per-instruction costs and maximum constraints over a bounded dispatch queue, reproduces the real timing of an out-of-order core closely enough that its bottleneck rankings can be trusted; the paper validates cycle counts but not this timing abstraction directly.

Editorial extensions

If this is right

  • Bottleneck analysis can name the exact static instructions that delay execution, not just the saturated hardware block, so optimization effort can target a dependency chain rather than a port.
  • Sensitivity analysis makes latent bottlenecks visible: a kernel can be limited by instruction latency, retire bandwidth, or cache bandwidth even when no resource shows high utilization.
  • Because the resource tables are generated automatically, the same profiling machinery applies across microarchitectures where the low-level PMC events for TMA are unavailable or shallow, including Arm cores.
  • The correlation-kernel case study shows the sensitivity/causality loop can guide a sequence of manual transformations from 4.5 percent to 82.8 percent of peak performance, with TMA offering little guidance once the obvious memory bottleneck is gone.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • An extension the paper does not test: run causality analysis with richer event taints (cache misses, branch mispredictions, SMT contention) so events are charged only when they appear on a critical path.
  • A derived prediction: if a proposed rescheduling breaks the taint-identified critical chain, the simulated speedup should equal the sensitivity result; verifying this across kernels would test the machinery.
  • A sharper stress test: compare the taint-identified critical path against a cycle-accurate scheduler model on a few kernels; disagreement about which instruction caused the delay would localize the conjunctive-resource abstraction as the component to refine.
Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

4 major / 6 minor

Summary. The paper presents Gus, a dynamic binary instrumentation-based profiler that simulates an abstract resource-centric model of an out-of-order core. It predicts cycle counts, performs sensitivity analysis by re-running the model with perturbed resource capacities, and uses a taint-propagation mechanism ('causality analysis') to attribute execution-time contributions to static instructions. The evaluation compares cycle-count predictions against gem5 and against measurements on 1,624 PolyBench kernel variants across six microarchitectures, and presents a correlation-kernel case study in which sensitivity analysis guides a 662% speedup.

Significance. Gus's cycle-count model is validated extensively and non-circularly: instruction latencies, inverse throughputs, and front-end parameters come from external characterization tools (uops.info, PALMED, uiCA) rather than being fitted to the validation kernels. The reported MAPE of 18.6% to 39.0% across six microarchitectures, and the favorable comparison against gem5 (MAPE 14.56% vs. 87.28%, with roughly an order-of-magnitude higher simulation speed), are credible strengths. If the causality analysis worked as claimed, it would be a valuable debugging capability beyond TMA and static analyzers. However, the causality analysis is the paper's central novelty, and it is not validated against any ground truth; the current evidence (a qualitative example, a consistency check, and a single case study) does not establish the claimed ability to pinpoint the critical path. The sensitivity-based optimization case study is compelling but anecdotal.

major comments (4)
  1. [Section 4 (4.2-4.4)] The paper's central claim, causality analysis, is not validated against ground truth. Section 4.2 validates cycle-count accuracy against gem5, Section 4.3 against hardware measurements, and Section 4.4 checks only that bottlenecks found by sensitivity analysis appear less stressed in optimized variants. None of these experiments compare the taint-based attribution (Algorithm 1, lines 42-44) against a known critical path, e.g., from a cycle-accurate simulator or from per-instruction latency perturbation. Without such a test, the claimed ability to 'pinpoint how each instruction contributes to the overall execution time' and to identify the dependency chain of the critical path (Section 2.2) is unsupported.
  2. [Algorithm 1, lines 42-44] The contribution metric is a single-window, binary membership heuristic: an instruction i' is counted exactly once when it is popped from a FIFO queue of length 2×ROB and happens to be in the dispatch.taint set of the instruction processed exactly 2×ROB positions later. This does not measure the amount of delay i' imposes; an instruction that delays many successors is counted once, and a non-critical instruction present in the accumulated taint set of a saturated resource can be counted even if it is not on the true critical path. The queue-length parameter (2×ROB) is not justified and its sensitivity is not explored. The paper should either validate this scoring against ground truth or reformulate the claim to describe the heuristic as an approximation.
  3. [Section 3.1.1 and Algorithm 1, lines 31-35] The model replaces actual port scheduling, scheduler state, retire limits, and prefetch behavior with a conjunctive resource mapping and a bounded dispatch queue. The causality propagation is built on this abstraction, so any first-order effect missed by the timing model (e.g., scheduler arbitration among ready instructions) propagates directly into the taint sets. The validation in Section 4.3 confirms aggregate cycle counts, which can be accurate even when per-instruction attribution is wrong. A direct evaluation of the timing abstraction's fidelity on kernels with known dependency structures is needed before the causality conclusions can be accepted.
  4. [Section 4.4] The consistency check for sensitivity analysis is weak: it verifies a monotonicity property of the model's own predictions (faster variants stress the identified bottleneck no more) but does not compare the identified bottleneck against an independent ground truth. The case study (Section 3.3) is qualitative and single-kernel. The paper should report a quantitative validation of bottleneck identification, for example on synthetic kernels with controlled resource saturation.
minor comments (6)
  1. [Section 1] The word 'respectivelly' should be 'respectively'.
  2. [Section 2] The phrase 'thebottleneck' is missing a space, and Section 4.2 has 'buit' instead of 'but'.
  3. [Table 2] The header 'TAM (perf)' should read 'TMA (perf)', and 'ressource' should be 'resource'.
  4. [References] References [5] and [6] are the same uops.info paper; the citation numbering should be consolidated.
  5. [Section 3.2] The speedup formula does not specify the range of weights w or how many weights are tried; please clarify the sensitivity protocol.
  6. [Algorithm 1] The variables tstart and tend are used without a comment; a brief definition would improve readability.

Circularity Check

0 steps flagged · score 1.0 of 10

No material circularity: Gus's cycle predictions are checked against external simulators and hardware measurements, parameters come from independent microbenchmark characterization, and no bottleneck or causality output is fed back into the model as a fitted constant.

full rationale

The paper's derivation chain is self-contained with respect to the quantities it claims to predict. Gus's timing model is parameterized by instruction latencies, inverse throughputs, cache parameters, and resource mappings taken from uops.info, PALMED, uiCA, and Dinero IV; these are characterized independently of the PolyBench kernels used for evaluation. The validation compares predicted cycles to gem5 and to hardware measurements, so cycle accuracy is an external check rather than a fitted result. Sensitivity-based bottleneck detection is operational: a resource is flagged when increasing its capacity in the simulator reduces predicted time; no bottleneck label is used to set model constants, and the Section 4.4 consistency check (bottlenecks of B appear less stressed in optimized V) is a falsifiable property that could fail and is not guaranteed by the sensitivity definition. Causality analysis is a taint-propagation heuristic (Algorithm 1, lines 42-44) whose output is a per-PC count; the paper does not fit that count to any measured quantity, so the central claim is not equivalent to an input by construction. The main weakness is that this causality attribution is not validated against a ground-truth critical path, and the correlation case study is anecdotal; that is an evidentiary gap, not a circularity. The only notable self-citation is [20] (PALMED), used for the conjunctive resource mapping and the Cortex-A72 table; this is prior modeling infrastructure rather than a result that presupposes the paper's conclusions, so it does not make the argument circular.

Assumptions & free parameters 5 free parameters · 5 assumptions · 0 invented entities

The central claim rests on a calibrated performance model rather than a derivation. I listed the externally measured model parameters (instruction latencies, resource mappings and inverse throughputs, cache and front-end parameters) as free parameters because the paper does not give their exact values, even though they come from prior characterization tools and are not fit to the evaluation kernels. The axioms mark the places where the model could diverge from real hardware. No invented physical entities are introduced: abstract resources and taint sets are modeling constructs.

free parameters (5)
  • Instruction latency table (uops.info) = Not stated in paper; sourced from uops.info microbenchmarks
    Used in Algorithm 1 line 37 to set i.tend, and for sensitivity analysis of latencies; these per-instruction values are measured externally, not fit to PolyBench.
  • Resource mapping / inverse throughput (PALMED/uops.info) = Not stated in paper; sourced from PALMED and uops.info
    Determines how each instruction consumes abstract resources (ports, combined port groups) in lines 33-35; measured externally.
  • Cache hierarchy parameters (latencies, bandwidths, prefetch) = Not stated; configured from Dinero IV fork and architecture
    Lines 27-30 model cache levels Li with inverse throughput; PLRU and next-line prefetch are heuristics, acknowledged in Section 3.1.1 as potentially not matching commercial CPUs.
  • ROB/dispatch queue size and retire buffer width = Not stated; set per microarchitecture
    The dispatch queue size (ROB capacity) and retire slots are microarchitectural parameters; sensitivity analysis varies them and the retire buffer appears as a bottleneck in the correlation case study.
  • Front-end throughput / micro-op cache model (uiCA) = Not stated; sourced from uiCA
    Models decode and micro-op cache throughput in the front-end resource; used in lines 22-24.
assumptions (5)
  • domain assumption Earliest-available-time (tavail) constraint propagation with max over dependencies is a sufficient approximation of OoO timing.
    Algorithm 1 updates times as lower bounds and never simulates actual resource states; the paper argues this enables causality, but the accuracy depends on this approximation holding for the kernels analyzed.
  • domain assumption The conjunctive resource mapping (instructions consume abstract resources sequentially) is equivalent in effect to real port scheduling for throughput and bottleneck detection.
    Section 3.1.1 cites [20] and replaces standard port mapping with resource mapping to enable taint propagation; no proof that this preserves bottleneck identification.
  • ad hoc to paper A dispatch queue of bounded size (ROB capacity) plus taint queue of length 2x ROB captures all constraints that affect overall execution time.
    Algorithm 1 line 42 pops instructions once the queue is sufficiently large (twice the ROB size by default); this is a heuristic, not derived from microarchitecture.
  • domain assumption Cache replacement using PLRU and a next-line prefetch heuristic approximates the real cache behavior of the tested CPUs.
    Section 3.1.1 states exhaustive modeling of commercial replacement policies is out of scope; inaccurate cache modeling would directly affect memory-bound bottleneck detection.
  • domain assumption Measurements under SMT-off, base frequency, and huge pages are representative of the kernels' steady-state behavior and comparable to simulation.
    Section 4.1 lists these conditions; they are sensible but the simulation does not model frequency variation, TLB misses, or SMT, so the comparison assumes these factors are not first-order.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Performance Debugging through Microarchitectural Sensitivity and Causality Analysis." pith.science (2026). https://pith.science/paper/RMSKG7EH

@misc{pith2026241213207,
  author       = {Pith},
  title        = {Pith review of: Performance Debugging through Microarchitectural Sensitivity and Causality Analysis},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/RMSKG7EH}},
  note         = {Machine review of arXiv:2412.13207}
}
read the original abstract

Modern Out-of-Order (OoO) CPUs are complex systems with many components interleaved in non-trivial ways. Pinpointing performance bottlenecks and understanding the underlying causes of program performance issues are critical tasks to fully exploit the performance offered by hardware resources. Current performance debugging approaches rely either on measuring resource utilization, in order to estimate which parts of a CPU induce performance limitations, or on code-based analysis deriving bottleneck information from capacity/throughput models. These approaches are limited by instrumental and methodological precision, present portability constraints across different microarchitectures, and often offer factual information about resource constraints, but not causal hints about how to solve them. This paper presents a novel performance debugging and analysis tool that implements a resource-centric CPU model driven by dynamic binary instrumentation that is capable of detecting complex bottlenecks caused by an interplay of hardware and software factors. Bottlenecks are detected through sensitivity-based analysis, a sort of model parameterization that uses differential analysis to reveal constrained resources. It also implements a new technique we developed that we call causality analysis, that propagates constraints to pinpoint how each instruction contribute to the overall execution time. To evaluate our analysis tool, we considered the set of high-performance computing kernels obtained by applying a wide range of transformations from the Polybench benchmark suite and measured the precision on a few Intel CPU and Arm micro-architectures. We also took one of the benchmarks (correlation) as an illustrative example to illustrate how our tool's bottleneck analysis can be used to optimize a code.

Figures

Figures reproduced from arXiv: 2412.13207 by the authors.

Figure 1
Figure 1. An example in pseudo-asm code of a kernel com￾puting ymm0 = ymm1*ymm3 + ymm1*ymm2 iteratively. Integer operations and branches supporting pointer arithmetic and loop iteration have been removed for clarity. ymm1 and ymm2 are loaded from two non-overlapping memory arrays. ymm3 is constant. In version (b), the vmovaps to ymm2 is hoisted out of the inner loop. 2 Performance debugging: state of the art and motivation Co… view at source ↗
Figure 3
Figure 3. The four original formulas of TMA L1. On recent Intel microarchitectures, these are directly provided by ad￾hoc PMC events. Memory instructions Memory loads and stores are placed into Load and Store Buffers, respectively. The latency of Load-Store units is determined by the level of the memory hierarchy into which the retrieved data is located. A high memory latency may cause 𝜇ops depending on loaded data to backlog… view at source ↗
Figure 4
Figure 4. Port occupancy over time during the execution of version (b) of the inner loop from [PITH_FULL_IMAGE:figures/full_fig_p004_4.png] view at source ↗
Figures from the paper (2 more)
Figure 5
Figure 5. Figure 5: Untransformed correlation kernel. 4 Experiments We first demonstrate the simulation capabilities of Gus by comparing it against a cycle-level simulator over a set of numerical kernels. We then validate the portability and accuracy of Gus against measurements on several…
Figure 6
Figure 6. Figure 6: Statistical comparison (a) and corresponding error distribution (b) of accuracy and speed of Gus against the cycle-level simulator gem5. 4.3 Validation of accuracy against measurements We validate the accuracy of Gus against measurements on several microarchitectures, …

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

48 extracted references · 42 canonical work pages

  1. [1]

    https://man7.org/linux/man- pages/man1/perf.1.html

    Performance analysis tools for linux. https://man7.org/linux/man- pages/man1/perf.1.html

    work page

  2. [2]

    https://www.intel.com/ content/dam/develop/external/us/en/documents/intel-architecture- code-analyzer-3-0\-users-guide-157552.pdf , 2017

    Intel architecture code analyzer user’s guide. https://www.intel.com/ content/dam/develop/external/us/en/documents/intel-architecture- code-analyzer-3-0\-users-guide-157552.pdf , 2017

    work page 2017

  3. [3]

    Intel 64 and ia-32 architectures optimization reference manual,

    work page

  4. [4]

    https://llvm.org/docs/CommandGuide/ llvm-mca.html, 2023

    Llvm machine code analyzer. https://llvm.org/docs/CommandGuide/ llvm-mca.html, 2023

    work page 2023

  5. [6]

    uops.info: Characterizing latency, throughput, and port usage of instructions on intel microarchitectures

    Andreas Abel and Jan Reineke. uops.info: Characterizing latency, throughput, and port usage of instructions on intel microarchitectures. In ASPLOS, ASPLOS ’19, pages 673–686, New York, NY, USA, 2019. ACM

    2019

  6. [7]

    nanobench: A low-overhead tool for running microbenchmarks on x86 systems

    Andreas Abel and Jan Reineke. nanobench: A low-overhead tool for running microbenchmarks on x86 systems. In 2020 IEEE International Symposium on Performance Analysis of Systems and Software (ISPASS) , August 2020

    2020

  7. [8]

    Uica: Accurate throughput prediction of basic blocks on recent intel microarchitectures

    Andreas Abel and Jan Reineke. Uica: Accurate throughput prediction of basic blocks on recent intel microarchitectures. In Proceedings of the 36th ACM International Conference on Supercomputing , ICS ’22, New York, NY, USA, 2022. Association for Computing Machinery

    work page 2022

  8. [9]

    Facile: Fast, accurate, and interpretable basic-block throughput prediction

    Andreas Abel, Shrey Sharma, and Jan Reineke. Facile: Fast, accurate, and interpretable basic-block throughput prediction. In 2023 IEEE International Symposium on Workload Characterization (IISWC) , pages 87–99. IEEE Computer Society, 10 2023

    work page 2023

Show all 48 references
  1. [10]

    Archexplorer: Microar- chitecture exploration via bottleneck analysis

    Chen Bai, Jiayi Huang, Xuechao Wei, Yuzhe Ma, Sicheng Li, Hongzhong Zheng, Bei Yu, and Yuan Xie. Archexplorer: Microar- chitecture exploration via bottleneck analysis. In Proceedings of the 56th Annual IEEE/ACM International Symposium on Microarchitecture , MICRO ’23, page 268...

    2023

  2. [11]

    Black, Jack Donovan, Bill Bunton, and Anna Keist

    David C. Black, Jack Donovan, Bill Bunton, and Anna Keist. SystemC: From the Ground Up, Second Edition . Springer Publishing Company, Incorporated, 2nd edition, 2009

    2009

  3. [12]

    Ramanujam, and P

    Uday Bondhugula, J. Ramanujam, and P. Sadayappan. Pluto: A practi- cal and fully automatic polyhedral parallelizer and locality optimizer. Technical Report OSU-CISRC-10/07-TR70, The Ohio State University, October 2007

    2007

  4. [13]

    Browne, J

    S. Browne, J. Dongarra, N. Garner, G. Ho, and P. Mucci. A portable programming interface for performance evaluation on modern pro- cessors. Int. J. High Perform. Comput. Appl. , 14(3):189–204, August 2000

    2000

  5. [14]

    Carlson, Wim Heirman, and Lieven Eeckhout

    Trevor E. Carlson, Wim Heirman, and Lieven Eeckhout. Sniper: Explor- ing the level of abstraction for scalable and accurate parallel multi-core simulation. In SC ’11: Proceedings of 2011 International Conference for High Performance Computing, Networking, Storage and Analysis ...

    2011

  6. [15]

    Carlson, Wim Heirman, Stijn Eyerman, Ibrahim Hur, and Lieven Eeckhout

    Trevor E. Carlson, Wim Heirman, Stijn Eyerman, Ibrahim Hur, and Lieven Eeckhout. An evaluation of high-level mechanistic core models. ACM Trans. Archit. Code Optim., 11(3), aug 2014

    2014

  7. [16]

    Charif-Rubial, Emmanuel Oseret, José Noudohouenou, William Jalby, and Ghislain Lartigue

    Andres S. Charif-Rubial, Emmanuel Oseret, José Noudohouenou, William Jalby, and Ghislain Lartigue. Cqa: A code quality analyzer tool at binary level. In 2014 21st International Conference on High Performance Computing (HiPC), pages 1–10, 2014

    2014

  8. [17]

    Perfmon metrics

    Intel Corporation. Perfmon metrics. https://github.com/intel/perfmon

  9. [18]

    Charlie Curtsinger and Emery D. Berger. Coz: finding code that counts with causal profiling. In Proceedings of the 25th Symposium on Operating Systems Principles, SOSP ’15, page 184–197, New York, NY, USA, 2015. Association for Computing Machinery

    2015

  10. [19]

    The new linux ’ perf ’ tools

    Arnaldo Carvalho de Melo and Red Hat. The new linux ’ perf ’ tools. 2010

    2010

  11. [20]

    Palmed: Throughput characterization for superscalar architectures

    Nicolas Derumigny, Théophile Bastian, Fabian Gruber, Guillaume Iooss, Christophe Guillon, Louis-Noël Pouchet, and Fabrice Rastello. Palmed: Throughput characterization for superscalar architectures. In Proceedings of the 20th IEEE/ACM International Symposium on Code Generation...

    2022

  12. [21]

    Maqao: Modular assem- bler quality analyzer and optimizer for itanium 2

    Lamia Djoudi, Denis Barthou, Patrick Carribault, Christophe Lemuet, Jean-Thomas Acquaviva, and William Jalby. Maqao: Modular assem- bler quality analyzer and optimizer for itanium 2. In Workshop on Explicitly Parallel Instruction Computing Techniques , Santa Jose, Cali- fornia...

    2005

  13. [22]

    Jan Edler and Mark D. Hill. Dinero iv trace-driven uniprocessor cache simulator. https://pages.cs.wisc.edu/ markhill/DineroIV/

  14. [23]

    Amant, Karthikeyan Sankar- alingam, and Doug Burger

    Hadi Esmaeilzadeh, Emily Blem, Renée St. Amant, Karthikeyan Sankar- alingam, and Doug Burger. Dark silicon and the end of multicore scaling. In 2011 38th Annual International Symposium on Computer Architecture (ISCA), pages 365–376, 2011

    2011

  15. [24]

    Interval sim- ulation: Raising the level of abstraction in architectural simulation

    Davy Genbrugge, Stijn Eyerman, and Lieven Eeckhout. Interval sim- ulation: Raising the level of abstraction in architectural simulation. 12 Performance Debugging through Microarchitectural Sensitivity and Causality Analysis In HPCA - 16 2010 The Sixteenth International Symposi...

    2010

  16. [25]

    Dinero iv with plru replacement policy support

    Christophe Guillon. Dinero iv with plru replacement policy support. https://github.com/atos-tools/dineroIV

  17. [26]

    Kerncraft: A tool for analytic performance modeling of loop ker- nels

    Julian Hammer, Jan Eitzinger, Georg Hager, and Gerhard Wellein. Kerncraft: A tool for analytic performance modeling of loop ker- nels. In Christoph Niethammer, José Gracia, Tobias Hilbrich, Andreas Knüpfer, Michael M. Resch, and Wolfgang E. Nagel, editors, Tools for High Perfo...

    2016

  18. [27]

    Sadayappan

    Changwan Hong, Aravind Sukumaran-Rajam, Jinsung Kim, Prashant Singh Rawat, Sriram Krishnamoorthy, Louis-Noël Pouchet, Fabrice Rastello, and P. Sadayappan. Gpu code optimization using abstract kernel emulation and sensitivity analysis. In Proceedings of the 39th ACM SIGPLAN Con...

    2018

  19. [28]

    Vtune profiler

    Intel. Vtune profiler. https://www.intel.com/content/www/us/en/ developer/tools/oneapi/vtune-profiler.html, 2011

    2011

  20. [29]

    McKee, Rich Caruana, Bronis R

    Engin Ïpek, Sally A. McKee, Rich Caruana, Bronis R. de Supinski, and Martin Schulz. Efficiently exploring architectural design spaces via predictive modeling. SIGOPS Oper. Syst. Rev., 40(5):195–206, oct 2006

    2006

  21. [30]

    A new measure of rank correlation

    Maurice G Kendall. A new measure of rank correlation. Biometrika, 30(1/2):81–93, 1938

    1938

  22. [31]

    Quantifying performance bottleneck cost through differential analysis

    Souad Koliaï, Zakaria Bendifallah, Mathieu Tribalat, Cédric Valensi, Jean-Thomas Acquaviva, and William Jalby. Quantifying performance bottleneck cost through differential analysis. In Proceedings of the 27th International ACM Conference on International Conference on Supercom...

    2013

  23. [32]

    Core-level performance engineer- ing with the open-source architecture code analyzer (osaca) and the compiler explorer

    Jan Laukemann and Georg Hager. Core-level performance engineer- ing with the open-source architecture code analyzer (osaca) and the compiler explorer. In Companion of the 2023 ACM/SPEC International Conference on Performance Engineering , ICPE ’23 Companion, page 127–131, New ...

    2023

  24. [33]

    Jason Lowe-Power, Abdul Mutaal Ahmad, Ayaz Akram, Mohammad Alian, Rico Amslinger, Matteo Andreozzi, Adrià Armejach, Nils As- mussen, Brad Beckmann, Srikant Bharadwaj, Gabe Black, Gedare Bloom, Bobby R. Bruce, Daniel Rodrigues Carvalho, Jeronimo Cas- trillon, Lizhong Chen, Nico...

    2020

  25. [34]

    McKenney

    Paul E. McKenney. Differential profiling. In Proceedings of the 3rd International Workshop on Modeling, Analysis, and Simulation of Com- puter and Telecommunication Systems, MASCOTS ’95, page 237–241, USA, 1995. IEEE Computer Society

    1995

  26. [35]

    Amarasinghe, and Michael Carbin

    Charith Mendis, Saman P. Amarasinghe, and Michael Carbin. Ithemal: Accurate, portable and fast basic block throughput estimation using deep neural networks. CoRR, abs/1808.07412, 2018

    2018 arXiv

  27. [36]

    Marss: A full system simulator for multicore x86 cpus

    Avadh Patel, Furat Afram, Shunfei Chen, and Kanad Ghose. Marss: A full system simulator for multicore x86 cpus. In 2011 48th ACM/EDAC/IEEE Design Automation Conference (DAC), pages 1050– 1055, 2011

    2011

  28. [37]

    https://www.cs.colostate

    PoCC, the polyhedral compiler collection. https://www.cs.colostate. edu/~pouchet/software/pocc/

  29. [38]

    PolyBench/C: The polyhedral benchmark suite, version 4.2, 2016

    Louis-Noël Pouchet and Tomofumi Yuki. PolyBench/C: The polyhedral benchmark suite, version 4.2, 2016. http://polybench.sf.net

    2016

  30. [39]

    Pmevo: portable inference of port mappings for out-of-order processors by evolutionary optimization

    Fabian Ritter and Sebastian Hack. Pmevo: portable inference of port mappings for out-of-order processors by evolutionary optimization. In Proceedings of the 41st ACM SIGPLAN Conference on Programming Language Design and Implementation , PLDI 2020, page 608–622, New York, NY, U...

    2020

  31. [40]

    Anica: Analyzing inconsistencies in microarchitectural code analyzers

    Fabian Ritter and Sebastian Hack. Anica: Analyzing inconsistencies in microarchitectural code analyzers. Proc. ACM Program. Lang., 6(OOP- SLA2), oct 2022

    2022

  32. [41]

    Zsim: Fast and accurate mi- croarchitectural simulation of thousand-core systems

    Daniel Sanchez and Christos Kozyrakis. Zsim: Fast and accurate mi- croarchitectural simulation of thousand-core systems. In Proceedings of the 40th Annual International Symposium on Computer Architecture , ISCA ’13, page 475–486, New York, NY, USA, 2013. Association for Comput...

    2013

  33. [42]

    Carlson, Erik Hager- sten, Stefanos Kaxiras, and David Black-Schaffer

    Andreas Sandberg, Nikos Nikoleris, Trevor E. Carlson, Erik Hager- sten, Stefanos Kaxiras, and David Black-Schaffer. Full speed ahead: Detailed architectural simulation at near-native speed. In 2015 IEEE International Symposium on Workload Characterization, pages 183–192, 2015

    2015

  34. [43]

    Sykora, P

    O. Sykora, P. Phothilimthana, C. Mendis, and A. Yazdanbakhsh. Gran- ite: A graph neural network model for basic block throughput estima- tion. In 2022 IEEE International Symposium on Workload Characteri- zation (IISWC), pages 14–26, Los Alamitos, CA, USA, nov 2022. IEEE Comput...

    2022

  35. [44]

    Non- determinism and overcount on modern hardware performance counter implementations

    Vincent M Weaver, Dan Terpstra, and Shirley Moore. Non- determinism and overcount on modern hardware performance counter implementations. In 2013 IEEE International Symposium on Perfor- mance Analysis of Systems and Software (ISPASS), pages 215–224. IEEE, 2013

    2013

  36. [45]

    Roofline: an insightful visual performance model for multicore architectures

    Samuel Williams, Andrew Waterman, and David Patterson. Roofline: an insightful visual performance model for multicore architectures. Commun. ACM, 52(4):65–76, apr 2009

    2009

  37. [46]

    A top-down method for performance analysis and coun- ters architecture

    Ahmad Yasin. A top-down method for performance analysis and coun- ters architecture. In 2014 IEEE International Symposium on Performance Analysis of Systems and Software (ISPASS) , pages 35–44, 2014

    2014

  38. [47]

    On the preci- sion of precise event based sampling

    Jifei Yi, Benchao Dong, Mingkai Dong, and Haibo Chen. On the preci- sion of precise event based sampling. In Proceedings of the 11th ACM SIGOPS Asia-Pacific Workshop on Systems , APSys ’20, page 98–105, New York, NY, USA, 2020. Association for Computing Machinery. 13

    2020

  39. [2018]

    Association for Computing Machinery

  40. [2023]

    https://cdrdv2-public.intel.com/671488/248966-046A-software- optimization-manual.pdf

Pith tools

Reviewed August 11, 2026 · model on record in the stance chip above.