Pith. sign in

REVIEW 3 major objections 5 minor 38 references

Why Do Prefetchers Fail? Let Agents Answer

T0 review · 3 major / 5 minor · reviewed 2026-08-15 · deepseek-v4-flash

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

Pith's one-line read An agent-driven loop that asks why prefetchers fail builds a 17-engine prefetcher that beats human-designed state of the art on workloads it never saw

desk verdict Genuinely novel agent-driven prefetcher discovery loop with an internally inconsistent held-out protocol; the 61.1% generalization claim is not established as written. read the letter →

arxiv 2608.13027 v1 pith:AT5YXF7I submitted 2026-08-13 cs.AR

Xiangfeng Sun , Ceyu Xu , Ningzhi Ai , Zeyu Zhu , Yiyang Yuan , Yuan Xie This is my paper · ORCID
classification cs.AR
keywords hardwareprefetchingagent-drivendesignperformanceanomaliesresidualmisslocalizationensemblecycle-accuratesimulationSPECCPU2017RTLsynthesis
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

This paper is trying to establish that hardware prefetcher design—the craft of predicting which data a processor will need and fetching it early—can be automated by language-model agents that work in a closed loop with a cycle-accurate simulator. The loop repeatedly asks why the current prefetcher still misses: it localizes high-impact residual misses to program counters, forces each agent to reproduce the failure as a runnable minimal case, groups verified causes into pattern families, and synthesizes a specialized sub-prefetcher for each family. New specialists are appended under residual gating, meaning an engine may act only where earlier engines issued nothing, so accepted improvements accumulate without regressions. The paper reports a final 17-engine 'Mixture of Prefetchers' with a 61.1% geometric-mean IPC speedup over no prefetching on 11 held-out workloads, beating three state-of-the-art human-designed prefetchers by 14.5%, 21.6%, and 23.6%, and synthesizing to 110 KB and 0.0347 mm². If correct, this matters because it replaces the bottleneck of human trace inspection with a scalable, failure-driven discovery process.

What carries the argument

The load-bearing mechanism is the closed performance-anomaly-driven loop (stages S1 through S6) wrapped around the deployed prefetcher's residual misses. Each iteration reduces the current composite's remaining misses to ranked program counters; gives each counter its own analysis agent with three aligned inputs, namely the hardware log, source code, and a sliced trace; forces the agent to produce a runnable minimal case that reproduces the failure; clusters verified diagnoses into pattern families; and evolves a sub-prefetcher for each family. Two structural ideas carry the argument: the minimal case turns every diagnosis from an assertion into an artifact that can be tested in isolation, and residual gating lets each new engine issue only when earlier engines issued nothing for that access, so accepted mechanisms accumulate without regressing existing coverage. A shared de-duplication sandbox and a ground-truth accuracy throttle protect the cache from pollution. These pieces make the composition monotone and the search failure-driven, which is what the paper claims distinguishes it from earlier generate-and-evaluate loops.

What would settle it

Re-run stages S1 through S5 using only the thirty training traces, with runtime logging proving that no held-out trace is simulated, and then measure the frozen composite once on the eleven held-out traces; if the 61.1% geomean IPC speedup does not reappear, the central generalization claim fails. The decisive check is a log showing zero held-out simulations before the final S6 run, because reproducing the paper's cumulative held-out staircase otherwise requires simulating held-out traces during integration.

Watch

Extended reading notes

Core claim

On its own terms, the paper's central claim is that a design process can be organized as a performance-anomaly-driven autoresearch loop, and that the loop, rather than any single invented mechanism, is what produces the result. The flow runs six stages: profile the current composite's residual misses; assign one analysis agent to each hot program counter, with hardware logs, source code, and a sliced trace; require a runnable minimal case that reproduces the failure; classify the verified diagnoses into pattern families; evolve one sub-prefetcher per family and integrate it under residual gating; and only after convergence measure the final composite on held-out traces. The paper reports that the resulting 17-engine MoP achieves a 61.1% geomean IPC speedup over no prefetching on eleven held-out SPEC CPU2017 traces, outperforming three state-of-the-art human-designed prefetchers by 14.5%, 21.6%, and 23.6%, with 110 KB of on-chip storage and 0.0347 mm² in 6nm synthesis. It also reports that the held-out gain over the base engines (13.74%) is more than three times the training gain (3.98%), which it interprets as out-of-distribution generalization rather than overfitting. The paper presents this as the first empirical demonstration that an agent-driven hardware-design process can outperform state-of-the-art human designs on unseen workloads while remaining practical to synthesize.

Load-bearing premise

The result rests on the premise that none of the eleven held-out traces influenced which engines were built, kept, or when the loop stopped; if any design decision followed from seeing held-out outcomes, the 61.1% would not be an independent generalization measurement.

Editorial extensions

If this is right

  • If the 61.1% held-out result reproduces, prefetcher design no longer needs to be gated on expert trace inspection: a simulator, a token budget, and the same loop can extend a strong base prefetcher to new workload distributions.
  • Because each new engine sits behind the residual gate and shares one routing table and one de-duplication sandbox, the ensemble can scale out one specialist at a time; the storage table puts most added engines at two to five KB each.
  • The held-out gain over the base engines exceeding the training gain by more than a factor of three implies the flow discovers generalizable pattern families rather than memorizing training traces, so pointing the same loop at a different workload suite is a direct corollary.
  • The discovery of a branch-history-indexed stride engine (K7) indicates the loop can surface mechanisms outside the standard prefetcher feature set, so the pattern space is not bounded by the existing textbook catalog.

Reading between the lines

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

  • A natural test is to run the same loop from a deliberately weaker starting point; if the residual-gated composition still climbs to a comparable held-out gain, the flow itself, rather than the strong base ensemble, is doing the work.
  • The reported token curve shows diminishing returns, with early cheap engines delivering most of the gain, which suggests future versions should allocate the per-PC analysis and synthesis token budget dynamically rather than uniformly across iterations.
  • Because all numbers come from one simulator's timing model, porting the discovered specialists to a different cycle-accurate simulator or to real hardware would show whether the 61.1% reflects the mechanisms themselves or the simulator's assumptions.
  • The K7 result hints that other history signals beyond branch history, such as path history or return-address behavior, might carry prefetch information; the loop itself can be used to test this by giving agents those additional input views.
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

3 major / 5 minor

Summary. The paper proposes a performance-anomaly-driven autoresearch flow in which an LLM-agent pipeline repeatedly identifies residual misses of a deployed prefetcher ensemble, requires per-program-counter agents to produce runnable minimal cases, classifies the reproduced failures into pattern families, synthesizes sub-prefetchers for each family, and integrates them under residual gating. The resulting 17-engine Mixture of Prefetchers (MoP) is claimed to achieve a 61.1% geomean IPC speedup over no prefetching on 11 held-out SPEC CPU2017 traces, outperforming Alecto, Berti, and Pythia by 14.5, 21.6, and 23.6 percentage points, respectively, while using 110 KB of storage and 0.0347 mm^2 in a 6nm synthesis. The paper also reports the discovery-flow token cost and an analysis of diminishing returns.

Significance. If the central result were established, this would be a noteworthy advance: it would be the first empirical demonstration that an agent-driven process can produce an RTL-practical prefetcher that generalizes to unseen workloads. The staged workflow is thoughtful, particularly the insistence on runnable minimal cases before accepting diagnoses, the residual-gating integration discipline, and the attempt to maintain a train/test boundary. However, the headline claim rests entirely on the integrity of that boundary, and the manuscript as written contains a direct contradiction about when held-out traces were touched. No code, data, prompts, or run logs are provided, so the protocol cannot currently be audited.

major comments (3)
  1. [Section III-S6 and Section VI-A / Figure 4a] The held-out protocol is internally inconsistent. Section III-S6 states that S6 is 'the only stage that touches held-out traces' and that stages S1 through S5 'assert at run time that no held-out trace is present.' Yet Figure 4a is titled 'Cumulative held-out speedup as sub-prefetchers integrate' and plots a held-out curve at every integration step, and Section VI-A states that 'no engine regresses either curve at any point' and reads the blue staircase as 'the direct empirical signature of residual gating.' If held-out measurements were available during S5 acceptance decisions, loop continuation, or stopping, then the final 61.1% geomean speedup and the 14.5/21.6/23.6 percentage-point margins over the baselines are a selected result, not an independent generalization measurement. The paper must clarify whether Figure 4a was produced by a post hoc replay of frozen intermediate composites after convergence; if it was, that replay must be explicitly stated, and if it was not, the central claim of the paper is invalid.
  2. [Section III-S6 and Section VI-D (availability)] The paper provides no artifact to verify the claimed train/test separation. The statement that S1–S5 'assert at run time that no held-out trace is present, so a leak fails loudly' is not backed by code, a description of the assertion mechanism, the 'single source of truth' partition file, or run logs. Given that the paper's strongest claim is a generalization measurement, the absence of an auditable artifact is a load-bearing reproducibility gap. The authors should release the partition definition, the assertion code, and at least the S5 integration decision logs so that the protocol can be checked independently.
  3. [Section VI-A and Section V-B] The interpretation that a held-out gain of 13.74% versus a training gain of 3.98% is 'the signature of superior generalization in its strongest form' is not justified by the experiment design. The training and held-out sets contain different programs with different memory behavior, so the larger held-out geomean could simply reflect that the held-out workloads have more prefetching headroom. This does not invalidate the headline result, but the out-of-distribution-generalization narrative is overreaching and should be reframed as a workload-difference observation unless the authors provide per-workload evidence that the held-out distribution is harder or that the discovered mechanisms transfer.
minor comments (5)
  1. [Figure 4a] The x-axis label 'base CPLX+CS+GS' uses 'CPLX' while Table I and the text call the first base engine 'PMP'; please make the nomenclature consistent.
  2. [Section V-B] The training list includes pop2, which is commonly classified as a memory-intensive SPECspeed2017 workload, yet the text says the training set contains the 'nine remaining compute-bound traces' of SPECspeed2017 and that the held-out set comprises 'the eleven memory-intensive traces.' Please define the memory-intensity criterion or adjust the workload description.
  3. [Section VI-A] The phrase 'in-context reinforcement learning' is nonstandard because no policy or value function is updated; the paper defines the term, but a more conservative term such as 'in-context closed-loop search' would avoid confusion with established RL terminology.
  4. [Figure 6] The caption states that the total token count and $41.66 are read from the usage export but the stage-level breakdowns are 'modeled and calibrated from completed runs'; please clarify which numbers are direct measurements and which are estimates.
  5. [Section VI-B] The performance comparison would be easier to interpret with error bars or multiple traces per benchmark; even for a deterministic simulator, the 100M-instruction window per trace leaves open the question of how sensitive the margins are to the chosen window.

Circularity Check

1 steps flagged · score 7.0 of 10

Held-out protocol is internally contradictory: Figure 4a measures held-out speedup at every integration step, while §III-S6 says held-out traces are touched only once after convergence; the final 61.1% is therefore not shown to be an independent prediction.

  1. fitted input called prediction [Section III-S6 ('Held-out Evaluation') vs Section VI-A and Figure 4a]
    "S6 is the only stage that touches held-out traces... Once the loop has converged, S6 runs the final composite on traces it never observed, and MoP's +61.1% geomean speedup of Section VI is measured here and nowhere else. ... We integrate the sub-prefetchers one engine at a time, and the figure plots the cumulative geomean IPC speedup over the base engines as each engine joins, with the held-out curve in blue and the training curve in orange."

    The paper's headline result is a generalization measurement on traces that 'took no part' in design and are 'touched' only by S6 after convergence. Figure 4a, however, reports a cumulative held-out speedup as sub-prefetchers integrate, which requires simulating held-out traces after each S5 integration step. If the blue staircase was produced during the S1–S5 loop and was visible to acceptance, continuation, or stopping decisions, then the held-out set was an input to design selection; the final 61.1% and the 14.5/21.6/23.6-point margins over Alecto/Berti/Pythia become the selected maximum of a trajectory monitored on held-out data, not an independent prediction.

full rationale

The core mechanism discovery loop (S1–S5) is not itself circular: S4's fitness is defined on training traces, S5 verifies non-interference on training traces only, and no self-citation is used to justify the prefetcher design. The circularity burden falls entirely on the held-out protocol. The paper asserts a strict train/test boundary, with S6 as the only stage touching held-out traces, but Figure 4a presents held-out speedup measured as each sub-prefetcher is integrated. That is a direct internal contradiction: either the held-out curve was measured during the design process (making the held-out set an input to acceptance/stopping decisions, so the final 61.1% is a selected result rather than an independent prediction), or Figure 4a is a post-hoc ablation that the paper does not disclose. In the absence of code, data, prompts, or run logs, the manuscript does not disambiguate these protocols. Because the 61.1% generalization claim is the paper's central load-bearing result, this ambiguity constitutes partial circularity rather than a merely cosmetic inconsistency. No other derivation step reduces by construction; the residual-gating monotonicity is structural but is presented as a design principle, not as an empirical prediction.

Assumptions & free parameters 5 free parameters · 4 assumptions · 2 invented entities

The central claim rests on a simulator, a benchmark subset, and a held-out protocol. The protocol is internally inconsistent as written: Figure 4a shows held-out measurements at each integration step, while the text says held-out traces are touched only once at the end. This makes the reported generalization number vulnerable to selection, and it is the strongest reason the paper cannot be accepted in its current form.

free parameters (5)
  • K1 confidence threshold = 3
    Section III and Figure 2: the K1 robust-stride engine promotes a stride only after the same line delta repeats past a confidence threshold of three; the value was chosen by the agent search on training traces.
  • K1 adaptive run-ahead depth range = 3 to 8 lines
    Section III: the engine escalates from a depth of three lines toward eight when its own prefetches arrive late; the schedule is fit to the late-stride family in libquantum and pop2.
  • K7 branch-history index length = 6 to 12 bits
    Section IV-B: six to twelve bits of gshare-style branch history explain 76 to 92% of deltas; the index length is an agent-searched parameter.
  • Per-engine table sizes and entry widths = 110 KB total; 16-bit partial tags, 32-bit addresses, 12-bit strides, 256-entry 4-way tables
    Table III assigns storage budgets per engine; these capacities are design choices made by the authors and agents, not derived from a first-principles bound.
  • Accuracy-throttle window and precision-collapse threshold = not reported
    Section IV-A requires a windowed ground-truth accuracy throttle that disables extension layers when precision collapses, but the window length and collapse threshold are not specified, and they affect whether engines stay enabled.
assumptions (4)
  • domain assumption ChampSim's timing model accurately represents a Zen 5-class core and memory system for prefetcher evaluation.
    All IPC, coverage, and timing conclusions are drawn from ChampSim traces; no silicon or FPGA validation is presented.
  • domain assumption The 11 memory-intensive SPECspeed2017 workloads are a fair 'unseen' distribution for the generalization claim.
    The paper generalizes from one benchmark suite subset; SPEC traces are not equivalent to production datacenter or client workloads.
  • domain assumption Held-out traces were never used in design decisions before S6.
    Section III states this, but Figure 4a is a per-integration held-out curve, creating an unresolved contradiction; if the assumption is false, the headline number is not independent.
  • domain assumption ChampSim ground-truth useful and fill signals correctly identify useful versus harmful prefetches.
    Residual gating and the accuracy throttle are built on these simulator signals to guarantee non-interference.
invented entities (2)
  • K7 GHR stride table (branch-history-indexed stride predictor) independent evidence
    purpose: Predict forward strides selected by recent data-dependent branches, a pattern outside the PC- and delta-based features of existing engines.
    The paper shows a random-key control stays at the single-stride baseline while 6-12 bit GHR keys explain 76-92% of deltas, and reports held-out gains on fotonik3d and gcc; this is a falsifiable handle, but only in simulation.
  • Residual-gated extension layer with shared deduplication sandbox
    purpose: Let multiple sub-prefetchers coexist by training on all accesses and issuing only on base-uncovered misses, with duplicate suppression and a ground-truth accuracy throttle.
    The monotonic staircase in Figure 4 is the only evidence, and it depends on the simulator's ground-truth signals; there is no independent hardware or formal guarantee.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Why Do Prefetchers Fail? Let Agents Answer." pith.science (2026). https://pith.science/paper/AT5YXF7I

@misc{pith2026260813027,
  author       = {Pith},
  title        = {Pith review of: Why Do Prefetchers Fail? Let Agents Answer},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/AT5YXF7I}},
  note         = {Machine review of arXiv:2608.13027}
}
read the original abstract

Hardware prefetchers are crucial to processor performance, yet their design remains labor-intensive and expert-driven. Architects inspect execution and memory-access traces, identify patterns, translate them into online hardware heuristics, and evaluate them in simulation, often with no guarantee of improvement. Human experts cannot systematically inspect billion-instruction traces across diverse real-world workloads. We present a performance-anomaly-driven autoresearch flow that repeatedly asks why a deployed prefetcher fails and uses the diagnoses to construct the Mixture of Prefetchers (MoP). Each iteration localizes high-impact unexplained misses to program counters, gives agents hardware logs, source code, and sliced traces, validates diagnoses through runnable minimal cases, and synthesizes specialized sub-prefetchers for recurring pattern families. Measured performance and remaining anomalies feed subsequent iterations, enabling simulator-in-the-loop discovery beyond model priors. The campaign consumes 1.91 billion DeepSeek V4 Pro tokens. On SPEC CPU2006 and SPEC CPU2017, MoP achieves a 61.1% geomean IPC speedup over no prefetching, outperforming the human-designed Alecto, Berti, and Pythia prefetchers by 14.5%, 21.6%, and 23.6%, respectively. RTL synthesis in a 6nm library reports 110 KB of on-chip storage and 0.0347 mm^2 area. To our knowledge, this is the first empirical demonstration that an agent-driven hardware-design process can produce an RTL-practical prefetcher that outperforms state-of-the-art human designs on unseen workloads.

Figures

Figures reproduced from arXiv: 2608.13027 by the authors.

Figure 1
Figure 1. Learning the organization and closing the loop. (a) Human prefetcher [PITH_FULL_IMAGE:figures/full_fig_p001_1.png] view at source ↗
Figure 2
Figure 2. A complete S2–S5 pass for pop2 PC 0x872bd4. The S2 prompt confines the agent to one PC and requires a diagnosis plus a runnable minimal case. Three aligned views show a dominant +16-byte stride (74.0%), sequential 16-byte elements, and roughly 32 cycles between line crossings, yet 86.2% of prefetches are late because a 49–74-cycle fill starts only after two crossings confirm the stride. The timeline exposes the mism… view at source ↗
Figure 3
Figure 3. The performance-anomaly-driven autoresearch loop and its train/test boundary. The upper row is training-only: S1 reduces the deployed composite’s [PITH_FULL_IMAGE:figures/full_fig_p005_3.png] view at source ↗
Figures from the paper (3 more)
Figure 4
Figure 4. Figure 4: MoP scales by composition. Panel (a) integrates the sub-prefetchers one engine at a time and plots the cumulative geomean IPC speedup over the [PITH_FULL_IMAGE:figures/full_fig_p009_4.png]
Figure 5
Figure 5. Figure 5: Held-out performance and miss coverage. The left panel (a) reports per-workload IPC speedup over no prefetching for MoP, Alecto, SPP, Pythia and [PITH_FULL_IMAGE:figures/full_fig_p010_5.png]
Figure 6
Figure 6. Figure 6: Discovery-flow token cost. The total and the metered $41.66 are [PITH_FULL_IMAGE:figures/full_fig_p011_6.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

38 extracted references · 29 canonical work pages

  1. [1]

    Effective hardware-based data prefetching for high-performance processors,

    T.-F. Chen and J.-L. Baer, “Effective hardware-based data prefetching for high-performance processors,”IEEE Transactions on Computers, vol. 44, no. 5, pp. 609–623, 1995

    work page 1995

  2. [2]

    Improving direct-mapped cache performance by the addition of a small fully-associative cache and prefetch buffers,

    N. P. Jouppi, “Improving direct-mapped cache performance by the addition of a small fully-associative cache and prefetch buffers,” inISCA, 1990

    work page 1990

  3. [3]

    Spatial memory streaming,

    S. Somogyi, T. F. Wenisch, A. Ailamaki, B. Falsafi, and A. Moshovos, “Spatial memory streaming,” inISCA, 2006

    work page 2006

  4. [4]

    Bingo spatial data prefetcher,

    M. Bakhshalipour, M. Shakerinava, P. Lotfi-Kamran, and H. Sarbazi- Azad, “Bingo spatial data prefetcher,” inHPCA, 2019

    work page 2019

  5. [5]

    Linearizing irregular memory accesses for improved correlated prefetching,

    A. Jain and C. Lin, “Linearizing irregular memory accesses for improved correlated prefetching,” inMICRO, 2013

    work page 2013

  6. [6]

    Storage efficient hard- ware prefetching using delta-correlating prediction tables,

    M. Grannæs, M. Jahre, and L. Natvig, “Storage efficient hard- ware prefetching using delta-correlating prediction tables,”Journal of Instruction-Level Parallelism, vol. 13, 2011

    work page 2011

  7. [7]

    Pythia: A customizable hardware prefetching framework using online reinforcement learning,

    R. Bera, K. Kanellopoulos, A. V . Nori, T. Shahroodi, S. Subramoney, and O. Mutlu, “Pythia: A customizable hardware prefetching framework using online reinforcement learning,” inMICRO, 2021

    work page 2021

  8. [8]

    Learning memory access patterns,

    M. Hashemi, K. Swersky, J. A. Smith, G. Ayers, H. Litz, J. Chang, C. Kozyrakis, and P. Ranganathan, “Learning memory access patterns,” inICML, 2018

    work page 2018

Show all 38 references
  1. [9]

    Chipnemo: Domain-adapted llms for chip design,

    M. Liu, T.-D. Ene, R. Kirby, C. Cheng, N. Pinckney, R. Liang, J. Alben, H. Anand, S. Banerjee, I. Bayraktaroglu, B. Bhaskaran, B. Catanzaro, A. Chaudhuri, S. Clay, B. Dally, L. Dang, P. Deshpande, S. Dhodhi, S. Halepete, E. Hill, J. Hu, S. Jain, A. Jindal, B. Khailany, G. Koka...

    2023 arXiv

  2. [10]

    Verilogeval: Evaluating large language models for verilog code generation,

    M. Liu, N. Pinckney, B. Khailany, and H. Ren, “Verilogeval: Evaluating large language models for verilog code generation,” inICCAD, 2023

    2023

  3. [11]

    Benchmarking large language models for auto- mated verilog rtl code generation,

    S. Thakur, B. Ahmad, Z. Fan, H. Pearce, B. Tan, R. Karri, B. Dolan- Gavitt, and S. Garg, “Benchmarking large language models for auto- mated verilog rtl code generation,” inDATE, 2023

    2023

  4. [12]

    Gpt4aigchip: Towards next-generation ai accelerator design automation via large language models,

    Y . Fu, Y . Zhang, Z. Yu, S. Li, Z. Ye, C. Li, C. Wan, and Y . C. Lin, “Gpt4aigchip: Towards next-generation ai accelerator design automation via large language models,” inICCAD, 2023. 12

    2023

  5. [13]

    Mathematical discoveries from program search with large language models,

    B. Romera-Paredes, M. Barekatain, A. Novikov, M. Balog, M. P. Kumar, E. Dupont, F. J. R. Ruiz, J. S. Ellenberg, P. Wang, O. Fawzi, P. Kohli, and A. Fawzi, “Mathematical discoveries from program search with large language models,”Nature, vol. 625, pp. 468–475, 2024

    2024

  6. [14]

    Alphaevolve: A coding agent for scientific and algorithmic discovery,

    A. Novikov, N. V ˜u, M. Eisenberger, E. Dupont, P.-S. Huang, A. Z. Wagner, S. Shirobokov, B. Kozlovskii, F. J. R. Ruiz, A. Mehrabian, M. P. Kumar, A. See, S. Chaudhuri, G. Holland, A. Davies, S. Nowozin, P. Kohli, and M. Balog, “Alphaevolve: A coding agent for scientific and a...

    2025

  7. [15]

    Openevolve: An open-source evolutionary coding agent,

    OpenEvolve Contributors, “Openevolve: An open-source evolutionary coding agent,” 2025

    2025

  8. [16]

    Integrating prefetcher selection with dynamic request allocation improves prefetching efficiency,

    M. Li, Q. Zhang, Y . Ren, and Z. Xie, “Integrating prefetcher selection with dynamic request allocation improves prefetching efficiency,” in HPCA, 2025

    2025

  9. [17]

    A graph placement methodology for fast chip design,

    A. Mirhoseini, A. Goldie, M. Yazgan, J. W. Jiang, E. Songhori, S. Wang, Y .-J. Lee, E. Johnson, O. Pathak, A. Nova, J. Pak, A. Tong, K. Srinivasa, W. Hang, E. Tuncer, Q. V . Le, J. Laudon, R. Ho, R. Carpenter, and J. Dean, “A graph placement methodology for fast chip design,”N...

    2021

  10. [18]

    Faster sorting algorithms discovered using deep reinforce- ment learning,

    D. J. Mankowitz, A. Michi, A. Zhernov, M. Gelmi, M. Selvi, C. Padu- raru, E. Leurent, S. Iqbal, J.-B. Lespiau, A. Ahern, T. K¨oppe, K. Millikin, S. Gaffney, S. Elster, J. Broshear, C. Gamble, K. Milan, R. Tung, M. Hwang, T. Cemgil, M. Barekatain, Y . Li, A. Mandhane, T. Hubert...

    2023

  11. [19]

    Eureka: Human-level reward design via coding large language models,

    Y . J. Ma, W. Liang, G. Wang, D.-A. Huang, O. Bastani, D. Jayaraman, Y . Zhu, L. Fan, and A. Anandkumar, “Eureka: Human-level reward design via coding large language models,” inICLR, 2024

    2024

  12. [20]

    Cache memories,

    A. J. Smith, “Cache memories,”ACM Computing Surveys, vol. 14, no. 3, pp. 473–530, 1982

    1982

  13. [21]

    Best-offset hardware prefetching,

    P. Michaud, “Best-offset hardware prefetching,” inHPCA, 2016

    2016

  14. [22]

    Path confidence based lookahead prefetching,

    J. Kim, S. H. Pugsley, P. V . Gratz, A. L. N. Reddy, C. Wilkerson, and Z. Chishti, “Path confidence based lookahead prefetching,” inMICRO, 2016

    2016

  15. [23]

    Berti: An accurate local-delta data prefetcher,

    A. Navarro-Torres, B. Panda, J. Alastruey-Bened ´e, P. Iba˜nez, V . Vi˜nals- Yufera, and A. Ros, “Berti: An accurate local-delta data prefetcher,” in MICRO, 2022

    2022

  16. [24]

    Access map pattern matching for data cache prefetch,

    Y . Ishii, M. Inaba, and K. Hiraki, “Access map pattern matching for data cache prefetch,” inICS, 2009

    2009

  17. [25]

    Data cache prefetching using a global history buffer,

    K. J. Nesbit and J. E. Smith, “Data cache prefetching using a global history buffer,” inHPCA, 2004

    2004

  18. [26]

    Prefetching using markov predictors,

    D. Joseph and D. Grunwald, “Prefetching using markov predictors,” in ISCA, 1997

    1997

  19. [27]

    Domino temporal data prefetcher,

    M. Bakhshalipour, P. Lotfi-Kamran, and H. Sarbazi-Azad, “Domino temporal data prefetcher,” inHPCA, 2018

    2018

  20. [28]

    Efficiently prefetching complex address pat- terns,

    M. Shevgoor, S. Koladiya, R. Balasubramonian, C. Wilkerson, S. H. Pugsley, and Z. Chishti, “Efficiently prefetching complex address pat- terns,” inMICRO, 2015

    2015

  21. [29]

    Imp: Indirect memory prefetcher,

    X. Yu, C. J. Hughes, N. Satish, and S. Devadas, “Imp: Indirect memory prefetcher,” inMICRO, 2015

    2015

  22. [30]

    A hierarchical neural model of data prefetching,

    Z. Shi, A. Jain, K. Swersky, M. Hashemi, P. Ranganathan, and C. Lin, “A hierarchical neural model of data prefetching,” inASPLOS, 2021

    2021

  23. [31]

    Classifying memory access patterns for prefetching,

    G. Ayers, H. Litz, C. Kozyrakis, and P. Ranganathan, “Classifying memory access patterns for prefetching,” inASPLOS, 2020

    2020

  24. [32]

    Division of labor: A more effective approach to prefetching,

    S. Kondguli and M. Huang, “Division of labor: A more effective approach to prefetching,” inISCA, 2018

    2018

  25. [33]

    Bouquet of instruction pointers: Instruction pointer classifier-based spatial hardware prefetching,

    S. Pakalapati and B. Panda, “Bouquet of instruction pointers: Instruction pointer classifier-based spatial hardware prefetching,” inISCA, 2020

    2020

  26. [34]

    Intel Corporation,Intel 64 and IA-32 Architectures Optimization Refer- ence Manual, Intel Corporation, 2023, order No. 248966

    2023

  27. [35]

    Sandbox prefetching: Safe run-time evaluation of aggressive prefetchers,

    S. H. Pugsley, Z. Chishti, C. Wilkerson, P.-f. Chuang, R. L. Scott, A. Jaleel, S.-L. Lu, K. Chow, and R. Balasubramonian, “Sandbox prefetching: Safe run-time evaluation of aggressive prefetchers,” in HPCA, 2014

    2014

  28. [36]

    B-fetch: Branch prediction directed prefetching for chip- multiprocessors,

    J. Kim, S. H. Pugsley, P. V . Gratz, A. L. N. Reddy, C. Wilkerson, and Z. Chishti, “B-fetch: Branch prediction directed prefetching for chip- multiprocessors,” inMICRO, 2014

    2014

  29. [37]

    The championship simulator: Architectural simulation for education and competition,

    N. Gober, G. Chacon, L. Wang, P. V . Gratz, D. A. Jimenez, E. Teran, S. Pugsley, and J. Kim, “The championship simulator: Architectural simulation for education and competition,” inarXiv:2210.14324, 2022

    2022 arXiv

  30. [38]

    Temporal prefetching without the off-chip metadata,

    H. Wu, K. Nathella, J. Pusdesris, D. Sunwoo, A. Jain, and C. Lin, “Temporal prefetching without the off-chip metadata,” inMICRO, 2019

    2019

Pith tools

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