PaperlayerView exact revision on arXiv

Source-linked AI summary

Top-Down Microarchitecture Analysis Without Causal Modelling Is Dangerous!

Chenxi Wang, Lei Wang, Wanling Gao, Guoxin Kang, Fanda Fan, Jianfeng Zhan

arXiv:2610.21387v1cs.PF

TL;DR

Traditional TMA treats workload configuration as static, leaving causal paths through instruction counts unmodeled. CTMA uses the object causal model and workload and hardware treatments to examine those paths. Its evaluation reports counterintuitive workload and hardware interactions, including the Ghost State performance artifact.

  • Problem

    Traditional TMA treats workload configuration as static and cannot trace performance variation to changes in input data or algorithmic adaptation, while two causal paths through retired instructions are overlooked.

    Source: A. Traditional Benchmarking and… · p. 4, A. The Causal Blindness of TMA · p. 5

  • Method

    CTMA uses an object causal model and workload and hardware treatments, including SMT resource partitioning and frequency scaling, validated across Intel, AMD, and ARM platforms.

    Source: §I · p. 3, C. Causal Inference and the Object… · p. 4, §VI · p. 12

  • Results

    CTMA revealed over-speculation congestion, shifts from capacity-bound to fill-rate-bound execution, and Op-cache-dependent SMT overlap, alongside a 42.20% average Ghost State performance boost.

    Source: §VI · p. 12

  • Takeaways & Limitations

    CTMA aims to prevent architects from falling into correlational traps and optimizing the wrong bottlenecks.

    Source: §VI · p. 12

Abstract

from arXiv · show

Top-Down Microarchitecture Analysis (TMA) is the standard for identifying CPU bottlenecks. However, TMA implicitly models performance via a single causal path: Workload(dataset, algorithm) => CPU(CPI) => System(Performance) (microarchitectural efficiency path). It overlooks two hidden causal paths: Workload(dataset, algorithm) => Instructions(Retired) => System(Performance) (algorithmic efficiency path) and Workload(dataset, algorithm) => Instructions(Retired) => CPU(CPI) => System(Performance) (microarchitecture-algorithm efficiency path). This causal blindness often misleads architects into futile hardware optimizations. To address this, we propose Causal Top-Down Microarchitecture Analysis (CTMA). Utilizing the object causal model, CTMA explicitly models these three causal paths among the workload, instructions, CPU, and system. We validate CTMA across Intel, AMD, and ARM platforms. Our experiments reveal counterintuitive insights: (1) CPI Profiling Blindness: Algorithmic instruction bloat can double elapsed time while the CPI profile remains frozen. (2) Over-Speculation Congestion: Throttling the Frontend paradoxically improves performance in pointer-chasing algorithms. (3) ILP Window Collapse: Extreme data topologies shift bottlenecks from Backend ROB capacity to Frontend fill-rate starvation. (4) Op-Cache SMT Overlap: Ultra-small footprints yield SMT speedups on Intel but cause severe thrashing on AMD. (5) "Ghost State" Artifact: Stale pipeline mitigations on Intel Xeon Gold 5120T artificially boost performance by 22.75% on SPEC CPU2017 and 42.2% on SPEC CPU2026. Based on this, we propose a dynamic speculation throttling mechanism.

TECHNICAL REPORT NO. BENCHCOUNCIL-CTMA-2026

Traditional TMA attributes performance variation to CPU efficiency, but CTMA models how workload changes affect instructions, the CPU, and system performance. Across Intel, AMD, and ARM, the paper reports counterintuitive workload and hardware interactions and proposes dynamic speculation throttling.

I. INTRODUCTION

  • CTMA models the workload, instructions, CPU, and system to address causal paths that traditional TMA overlooks.Traditional TMA treats workload configuration as static, while CTMA mutates algorithmic traits and applies hardware treatments to validate causal paths.Source: §I · pp. 2–3
  • CTMA mutates workload traits such as graph randomness, recursion depth, and spatial locality, and uses non-invasive hardware treatments across Intel, AMD, and ARM.The treatments include SMT resource partitioning and core frequency scaling.Source: §I · pp. 2–3
  • More than 100% elapsed-time variation with a frozen CPI profile appeared when spatial locality changed in leela r, alongside 2.06× instruction inflation in cross-ISA validation.The authors describe this as algorithmic instruction bloat, against which microarchitectural tuning is futile.Source: §I · p. 3
  • In mcf r, highly regular data improved branch prediction but halved performance as speculative memory requests congested the backend; injecting NOPs slightly improved performance.The authors attribute the congestion to overflowing Line Fill Buffers and memory-controller traffic.Source: §I · p. 3
  • In cactuBSSN r, ROB partitioning degraded perfect-topology datasets by ∼23% on Intel and ∼12% on AMD, versus ∼9% and ∼10% for distorted datasets.The authors interpret this as distortion shifting the bottleneck from ROB capacity to dynamic fill-rate, making deep out-of-order backend resources less useful.Source: §I · p. 3
  • For xalancbmk r with an extremely small recursive instruction footprint, SMT yielded speedups on Intel through DSB overlap, while AMD Zen3 suffered more than 50% degradation.The paper attributes the contrast to rigid Op-cache sharing policies on AMD Zen3.Source: §I · p. 3
  • 22.75% artificial performance boost on SPEC CPU2017 and 42.20% on SPEC CPU2026 followed forceful termination of an SMT sibling without an OS-level microarchitectural flush on Intel Xeon Gold 5120T.The authors link this “Ghost State” artifact to spectre v2 mitigation toggles on specific unbalanced-designed CPUs.Source: §I · p. 3
  • The authors propose dynamic speculation throttling for real-time congestion control and describe the report's remaining sections as background, motivation, methodology, evaluation, and conclusion.The proposed mechanism is based on the Ghost State and over-speculation findings.Source: §I · pp. 3–4

II. BACKGROUND AND RELATED WORK

This section sets out foundational concepts for performance analysis and causal inference, introduces terminology, and identifies systemic causal gaps in current benchmarking methods.

II. BACKGROUND AND RELATED WORK

  • The section establishes foundational concepts in modern performance analysis and causal inference.These concepts provide the stated foundation for understanding workload and hardware interactions.Source: §II · p. 4
  • The section introduces terminology for discussing performance analysis and causal inference.Source: §II · p. 4
  • The section highlights systemic causal gaps in current benchmarking methodologies.Source: §II · p. 4

A. Traditional Benchmarking and Top-Down Analysis

Traditional benchmarking aggregates outcomes from static configurations, while TMA profiles pipeline efficiency without tracing changes back to input data or algorithmic adaptation. The section bridges algorithmic and microarchitectural performance concepts and introduces an object-based causal model.

A. Traditional Benchmarking and Top-Down Analysis

  • TMA classifies pipeline stalls into four categories and measures pipeline efficiency, but its static-workload snapshot cannot trace performance changes to input data or algorithmic adaptation.The categories are Frontend Bound, Backend Bound, Bad Speculation, and Retiring.Source: A. Traditional Benchmarking and… · p. 4

B. Bridging Algorithm and Microarchitecture

  • Algorithmic instruction bloat occurs when dataset changes lengthen an algorithm’s execution path, increasing retired instructions and elapsed time even when CPI stays stable.The section also contrasts capacity-bound pipelines, sensitive to ROB size, with fill-rate-bound pipelines, where changing ROB capacity has minimal effect.Source: B. Bridging Algorithm and… · p. 4

C. Causal Inference and the Object Causal Model

  • The object causal model tracks interactions among Workload, Instructions, CPU, and System objects through their mechanisms and observable properties.The objects expose dataset configuration, retired-instruction count, CPI and Branch MPKI, and elapsed time, respectively.Source: C. Causal Inference and the Object… · p. 4

III. MOTIVATION: THE PITFALLS OF TRADITIONAL TMA

TMA treats workload configurations as static and attributes performance variation to CPU efficiency, overlooking paths through instruction count. In leela r, locality treatments change elapsed time and retired instructions while the TMA profile remains nearly unchanged.

A. The Causal Blindness of TMA

  • TMA models performance through workload-to-CPU CPI-to-system performance, but changing data can also affect performance through retired instructions.The section identifies an algorithmic path through instructions and a microarchitecture-algorithm path through instructions and CPU CPI.Source: A. The Causal Blindness of TMA · p. 5

B. The Microarchitectural Freeze (leela r)

  • 630s to 1293s elapsed time (> 100% variation) accompanies retired instructions rising from 76.8T to 158.3T, while CPI stays approximately 1.17 across leela r treatments.The TMA pipeline breakdown remains virtually identical despite the workload’s substantially larger instruction count.Source: B. The Microarchitectural Freeze… · pp. 5–6, Figure 2 · p. 6

A. The Causal Blindness of TMA

  • In mcf r, as graph edges become more structured, CPI drastically worsens, yet overall elapsed time counter-intuitively drops, showing the two measures move in opposite directions.Source: Figure 3 · p. 6

C. The Pointer-Chasing Paradox (mcf r)

The mcf r comparison shows CPI worsening as elapsed time falls, while the supplied cactuBSSN r result describes algorithmic pruning masking a branch-prediction penalty.

C. The Pointer-Chasing Paradox (mcf r)

  • The mcf r experiment holds graph scale at 15,000 nodes and 117,202 edges while shifting edge costs from random values toward a predictable linear pattern.Source: C. The Pointer-Chasing Paradox (mcf r) · p. 6
  • For cactuBSSN r, Fig. 4 reports that algorithmic pruning causes elapsed time to drop, completely hiding an exponential surge in Branch MPKI.Source: Figure 4 · p. 6
  • CPI worsens from 3.4 to 3.9 while elapsed time falls from 550s to 350s in the Grad-0.6 and Grad-0.8 datasets.The predictable edge costs are associated with accurate branch predictions, deep dependent-pointer fetching, and Line Fill Buffer congestion; shorter routing paths reduce instructions from 22.6T to 12.5T.Source: C. The Pointer-Chasing Paradox (mcf r) · p. 6

D. The Hidden Bottleneck Shift (cactuBSSN r)

Changing cactuBSSN’s spatial topology can reduce elapsed time while shifting the pipeline from capacity-bound to fill-rate-bound; in xalancbmk, more retired instructions coincide with faster completion. CTMA addresses such cases by modeling workload, instruction, CPU, and system interactions across three causal paths.

D. The Hidden Bottleneck Shift (cactuBSSN r)

  • 70% fewer retired instructions (1.47T to 0.45T) accompany a shift from capacity-bound to fill-rate-bound execution under extreme spatial distortion.The 10 × 10 innermost loops disrupt prefetcher strides, and Branch MPKI rises from 1.84 to 6.05 as branch flushes stall the pipeline.Source: D. The Hidden Bottleneck Shift… · p. 7
  • From Q1 to Gradient-0.5, elapsed time rises from 422.6s to 424.4s even as instructions fall from 1.49T to 1.40T and CPI increases from 1.21 to 1.42.The passage attributes the CPI increase to a Frontend threshold effect that outweighs the instruction reduction.Source: D. The Hidden Bottleneck Shift… · p. 7

E. The Workload Anomaly (xalancbmk r)

F. Summary: The Need for Causal TMA

  • Traditional TMA’s causal blindness can lead architects to pursue hardware changes for software-driven anomalies, such as expanding ROB capacity when execution is fill-rate-bound.Source: F. Summary: The Need for Causal TMA · p. 7
  • CTMA models three causal paths among workload, instructions, CPU, and system to capture bottleneck migration and cross-validate performance models.Its framework uses workload treatments and hardware probes, and can accommodate real silicon or cycle-accurate simulators.Source: F. Summary: The Need for Causal TMA · p. 7, §IV · pp. 7–8

IV. THE CAUSAL TOP-DOWN MICROARCHITECTURE ANALYSIS (CTMA)

A. Phase I: The Software Interface (Intervening on the Workload Object)

CTMA intervenes on workload properties, models interactions among workload, instructions, CPU, and system, then uses hardware probes to cross-validate causal predictions. Its interfaces support workload treatments and probes on real processors or cycle-accurate simulators.

A. Phase I: The Software Interface (Intervening on the Workload Object)

  • CTMA mutates workload properties around a default anchor while holding other properties constant, creating treatments that can expose algorithmic and microarchitectural changes.The reference implementation preserves total data scale while changing topology to isolate algorithmic adaptation rather than raw input size.Source: A. Phase I: The Software Interface… · p. 8

B. Phase II: Dynamic Bottleneck Analysis (Using OCM for Causal Modeling and Performance Profiling)

  • The object causal model tracks Workload, Instructions, CPU, and System interactions and distinguishes three paths linking workload changes to performance.The paths represent microarchitectural efficiency, algorithmic efficiency, and their combined interaction.Source: B. Phase II: Dynamic Bottleneck… · p. 8

C. Phase III: The Hardware Interface (Cross-Validation on the CPU Object)

  • CTMA cross-validates modeled causal paths by intervening on the CPU object with hardware probes, including real silicon or cycle-accurate simulators,,,,,.Its hardware interface is designed to accept mechanisms that probe or constrain the CPU object.Source: C. Phase III: The Hardware Interface… · p. 8, Figure 6 · p. 9
  • SMT resource partitioning uses a sibling-core pause process to partition ROB and queue resources without consuming dynamic fetch bandwidth.Source: C. Phase III: The Hardware Interface… · p. 8
  • Co-running identical workloads on sibling cores tests whether fetch bandwidth overlaps smoothly or performance regresses under Op-cache capacity partitioning.Source: C. Phase III: The Hardware Interface… · pp. 8–9
  • Manual speculation throttling inserts NOPs into hot functions to test whether slowing the Frontend alleviates Backend memory-queue congestion.Comparing workload-treatment shifts with hardware-probe responses is described as closed-loop causal verification.Source: C. Phase III: The Hardware Interface… · p. 9

V. EVALUATION

The evaluation applies CTMA’s hardware probes across three commercial processor platforms. The setup isolates testing cores to reduce operating-system scheduling noise and background interrupts.

V. EVALUATION

  • The evaluation deploys the methodology’s hardware probes across three microarchitectures to cross-validate causal bottleneck models.Source: §V · p. 9

A. Experimental Setup

  • The evaluation spans Intel Xeon Gold 5120T (Skylake-SP), AMD EPYC 7543 (Zen 3), and ARM Kunpeng 920 (ARMv8).Source: A. Experimental Setup · p. 9
  • Testing cores are isolated with GRUB kernel parameters to reduce OS scheduling noise and background interrupts.Baseline and treatment processes are pinned to isolated logical cores, and events are collected with Linux perf and Intel VTune.Source: A. Experimental Setup · p. 9

B. Validating Algorithmic Instruction Bloat via Frequency Clamping (leela r)

On leela r, spatial-locality treatments leave CPI static while instruction bloat changes elapsed time, and frequency clamping supports a compute-bound interpretation. On cactuBSSN r, topology changes shift execution from capacity-bound to fill-rate-bound, as tested with SMT resource partitioning.

B. Validating Algorithmic Instruction Bloat via Frequency Clamping (leela r)

C. Isolating Backend Vulnerabilities via SMT Slicing (cactuBSSN r)

  • On cactuBSSN r, extreme spatial distortion reduces elapsed time but raises Branch MPKI and backend stalls, shifting execution from capacity-bound to fill-rate-bound.Intel Branch MPKI rises from 1.84 to 6.05; AMD rises from 0.11 to 0.19.Source: C. Isolating Backend Vulnerabilities… · pp. 9–10
  • Figure 7 describes the leela r microarchitectural freeze across three commercial platforms, with elapsed time doubling while TMA pipeline slots and CPI remain unchanged.Source: B. Validating Algorithmic Instruction… · p. 9, Figure 7 · p. 10
  • Table III is identified as the frequency-clamping validation for pure instruction bloat on leela r.Source: Table III · p. 10
  • On Intel, ROB partitioning degrades Q1 by ∼23% versus ∼9% for Q2; AMD shows a similar ∼12% versus ∼10% trend.Q2’s branch flushes prevent it from filling even a partitioned ROB; Kunpeng 920 lacks SMT.Source: C. Isolating Backend Vulnerabilities… · p. 10

D. The Architectural Divide of Op-Cache Sharing (xalancbmk r)

Op-cache behavior and speculative memory traffic produce counterintuitive performance effects: SMT can help or hurt depending on platform, while throttling the frontend can relieve backend congestion.

D. The Architectural Divide of Op-Cache Sharing (xalancbmk r)

  • Deep recursion in xalancbmk r sharply increases instruction counts, while dense CALL/RET operations constrain fetch bandwidth despite negligible ICache misses.The execution becomes trapped in a tiny code footprint inside the Op-cache.Source: D. The Architectural Divide of… · p. 10
  • 53% of µops come from Intel’s DSB on Q2, enabling constructive SMT overlap and faster completion, while AMD Zen 3 suffers severe resource thrashing.The small code footprint and frontend stalls let one process use otherwise idle fetch and execution slots while the other stalls.Source: D. The Architectural Divide of… · p. 10, Figure 8 · p. 11

E. Throttling Over-Speculation Congestion via NOP Injection (mcf r)

  • The mcf r treatments preserve graph scale and pair scattered or clustered locality with either random or linearly predictable edge costs.Injected NOP loops in price_out_impl() consume fetch and decode cycles without issuing data-memory requests, throttling frontend commit and speculative backend traffic.Source: E. Throttling Over-Speculation… · pp. 10–11
  • Predictable-cost treatments Q2 and Q4 run slower than random-cost Q1 and Q3 across all three platforms, alongside increased LFB congestion and backend-bound ratios.On Intel, FB Full rises from 42.5% (Q1) to 59.2% (Q2) and from 6.4% (Q3) to 100% (Q4); Backend Bound rises from 28.2% to 30.0% and from 17.2% to 32.7%, respectively.Source: E. Throttling Over-Speculation… · p. 11, Table IV · p. 11
  • NOP injection slows frontend delivery without generating data-memory requests, yet elapsed time remains stable or slightly decreases across all three platforms.The authors interpret this as evidence that restricting speculative memory operations relieves backend memory congestion.Source: E. Throttling Over-Speculation… · p. 11, Table V · p. 11

F. Case Study: The Microarchitectural Ghost State and Pipeline Balancing on the Intel Xeon Gold 5120T

On an Intel Xeon Gold 5120T, Ghost State and coarse-grained SMT throttling are associated with benchmark speedups. The authors trace Ghost State to stale pipeline configuration and recommend dynamically balancing speculation against backend congestion.

F. Case Study: The Microarchitectural Ghost State and Pipeline Balancing on the Intel Xeon Gold 5120T

VI. CONCLUSION AND FUTURE WORK

The conclusion frames TMA’s static-workload focus as causal blindness to instruction-count growth and bottleneck migration. CTMA uses causal treatments and hardware probes to study these effects, while future work targets simulator integration and dynamic throttling.

VI. CONCLUSION AND FUTURE WORK

  • TMA profiles static workloads and attributes performance variation to microarchitectural efficiency, overlooking algorithmic instruction growth and changing bottlenecks.Source: §VI · p. 12
  • CTMA pairs software treatments with hardware probes across Intel, AMD, and ARM to address TMA’s neglect of instruction bloat and dynamic bottleneck migration.Reported findings include predictable-data over-speculation congestion, topology-driven shifts from capacity-bound to fill-rate-bound behavior, and platform-dependent Op-cache SMT effects.Source: §VI · p. 12
  • The authors plan simulator integration for register-level causal interventions and closed-loop throttling that regulates frontend dispatch according to backend congestion.The stated aim is pipeline balance without expanding pipeline buffers.Source: §VI · p. 13
Loading 2610.21387v1…