Pith. sign in

REVIEW 4 major objections 7 minor 65 references

Profile-Guided Temporal Prefetching

T0 review · 4 major / 7 minor · reviewed 2026-08-06 · deepseek-v4-flash

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

Pith's one-line read Profile-guided hints beat Triangel temporal prefetching by 14.23%

desk verdict A serious profile-guided temporal prefetcher with real measured gains, but the 14.23% speedup rests on an unvalidated assumption about profiling under a simplified configuration. read the letter →

arxiv 2506.15985 v1 pith:QZVIDFTE submitted 2025-06-19 cs.AR

Mengming Li , Qijun Zhang , Yichuan Gao , Wenji Fang , Yao Lu , Yongqing Ren , Zhiyao Xie This is my paper · ORCID
classification cs.AR
keywords TemporalprefetchingProfile-guidedoptimizationMetadatatablemanagementHardware-softwareco-designPMUcountershintsIrregularmemoryaccessMulti-pathvictimbuffer
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

Prophet claims that the metadata table of an on-chip temporal prefetcher can be managed far more effectively when the program itself is profiled and the resulting hints are injected into the binary. The paper argues that a short profiling run using performance counters, rather than traces, reveals which memory instructions produce useful temporal prefetches, and that encoding this signal as a few bits per instruction lets the prefetcher decide what metadata to insert, what to evict, and how much cache space to give the table. This matters because existing hardware schemes rely on short-term runtime heuristics that misclassify interleaved useful and useless metadata accesses, while existing software prefetching only handles stride-like indirect accesses. If the claim is right, Prophet outperforms Triangel by 14.23% and RPG2 by 34.48% on irregular workloads, with roughly 392 KB of extra storage and a 1.6% memory-hierarchy energy overhead, and a single optimized binary adapts to many different program inputs.

What carries the argument

The load-bearing mechanism is the profile-guided hint: a 3-bit per-PC value derived from prefetching accuracy, delivered through a hint buffer or instruction-prefix bits, and consumed by three metadata-table policies. Insertion drops a PC entirely when its accuracy falls below an extremely low threshold $\mathit{EL\_ACC}$; replacement assigns $2n$ priority levels by accuracy and applies LRU within the lowest level; resizing sets the metadata table to the peak number of allocated entries, rounded to a power of two. The Multi-path Victim Buffer keeps evicted Markov targets with a counter per target, and only buffers targets whose priority level is above zero, giving a single address multiple prefetch candidates. The learning step merges old and new counters with a weighted update $o + \frac{1}{\min(l+1,L)}(n-o)$, and takes the maximum for table size, so hints from several inputs coexist in one binary.

What would settle it

Re-profile every evaluated workload across its SimPoint checkpoints and inputs with the simplified profiler configuration, and check whether the per-PC useful/issued ratio that determines hints is stable; if a PC filtered out by $\mathit{EL\_ACC}$ under one input becomes highly accurate under another, the injected hints would be wrong and the 14.23% gain would shrink. The paper currently demonstrates this stability for omnetpp only, so the experiment would settle whether the claim generalizes.

Watch

Extended reading notes

Core claim

The central discovery is that per-instruction temporal-prefetch accuracy, the ratio of useful prefetches to issued prefetches for each PC, is a stable and sufficient signal for metadata-table management even though individual metadata accesses vary widely. Prophet profiles with PMU counters under a simplified temporal prefetcher, then derives a threshold-based insertion decision ($acc \ge \mathit{EL\_ACC}$), a multi-level replacement priority with $2n$ levels, and a table size based on peak allocated entries, and injects these as hints of at most 3 bits per memory instruction. A Multi-path Victim Buffer stores evicted Markov targets with per-target counters so that an address with several possible successors still yields correct prefetches. The paper's assertion is that this profile-guided management, not aggressive prefetching, drives the gains: Prophet reduces demand misses by 42.75% versus 28.08% for Triangel while keeping prefetching accuracy comparable, and its learning step merges counters from multiple inputs so one binary performs well across all of them.

Load-bearing premise

The hints stay correct only if the prefetch accuracy of each memory instruction measured during profiling remains roughly the same in later runs and on other program inputs.

Editorial extensions

If this is right

  • Prophet's 14.23% speedup over Triangel comes from metadata management rather than aggressive prefetching, so the same table with better hints can raise coverage without sacrificing accuracy.
  • A single optimized binary reaches near-optimal performance across multiple inputs after a few learning rounds; four rounds suffice for nine gcc inputs.
  • The design generalizes from irregular SPEC CPU workloads to CRONO graph workloads, where Prophet beats both Triangel and RPG2.
  • Prophet coexists with existing hardware temporal prefetchers, so rarely executed workloads can keep the original runtime scheme while hot workloads use profile-guided hints.
  • The overheads are small in deployment terms: under 2% profiling overhead, under one second of offline analysis, at most 128 extra hint instructions, about 392 KB of storage, and 1.6% energy overhead over Triangel.

Reading between the lines

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

  • The paper implicitly treats per-PC accuracy as phase-stable; a natural extension is phase-aware hints that re-learn or switch when a workload's temporal behavior changes mid-execution.
  • Counter-based multi-input learning could be carried over to other profile-guided hardware optimizations, such as cache replacement or branch prediction, where trace collection is currently the main cost.
  • The Multi-path Victim Buffer suggests that storing a few evicted successors per address is cheaper than enlarging the metadata table; the same buffering idea could be tested on spatial prefetchers or TLB prefetchers.
  • The performance gap over RPG2 narrows on graph workloads where RPG2 finds stride-like prefetch kernels, so the claimed advantage over software prefetching is likely workload-dependent rather than universal.
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 / 7 minor

Summary. The paper proposes Prophet, a hardware-software co-designed temporal prefetching framework. Prophet profiles programs using PMU counters rather than traces, runs the counters through offline analysis to generate per-PC and application-level hints for metadata-table insertion policy, replacement policy, and resizing, and learns from multiple program inputs to adapt a single optimized binary across inputs. It also adds a Multi-path Victim Buffer for addresses with multiple Markov targets. The evaluation uses gem5 in FS mode with SimPoint checkpoints on SPEC CPU and CRONO workloads, comparing against Triangel and RPG2, and reports that Prophet outperforms Triangel by 14.23% and RPG2 by 34.48%, with roughly 392 KB of additional storage and 1.6% memory-hierarchy energy overhead.

Significance. If the results are robust, Prophet makes a useful contribution by showing that counter-based profiling can guide on-chip temporal metadata management without trace collection, that hints can be learned across multiple inputs, and that the approach can coexist with existing hardware temporal prefetchers. The paper is also commendable for measuring speedups rather than deriving them from the profiled counters, for providing an open-source implementation, and for reporting storage, energy, sensitivity, and ablation results. However, the central claim depends on the transferability of per-PC accuracy from a simplified profiler configuration to the full Prophet configuration, and on the fairness of the Triangel and RPG2 baselines; these points are not yet fully established.

major comments (4)
  1. [Section 3.2, Section 4.1, Figure 6] The entire hint-generation pipeline in Steps 1 and 2 is based on per-PC prefetching accuracy collected under the simplified temporal prefetcher: insertion policy disabled, a fixed 1 MB metadata table, and prefetching degree 1. The resulting hints are then consumed by the full Prophet configuration, where the insertion policy, replacement policy, Multi-path Victim Buffer, and potentially the prefetching degree are all different. The paper validates stability of accuracy classes only for omnetpp in Figure 6 and does not demonstrate that accuracy measured under the simplified configuration predicts accuracy under the full configuration for the other workloads or for the different inputs used in the learning experiments. A concrete test would be to compare hint decisions generated under the simplified profiler with those generated under the full Prophet configuration across all evaluated workloads. Without such evidence, the 14.23% gain reported in Section 5.2 cannot be confidently attributed to the proposed metadata management.
  2. [Section 5.1, Section 5.2] The comparison with Triangel uses a different checkpoint methodology than the original paper: the manuscript uses SimPoint checkpoints, while Triangel's original evaluation uses evenly sampled checkpoints, and the paper itself acknowledges that the overall Triangel speedup is not identical under the two methods. Because the headline result is a 14.23% margin, the comparison should be re-run under Triangel's original sampling methodology or reported for both methodologies. Similarly, RPG2 is evaluated by simulating prefetch instruction insertion through the hint buffer rather than running RPG2's actual compiler pass, which may understate RPG2's performance; a compiler-based implementation or a sensitivity analysis of this choice is needed before claiming a 34.48% advantage.
  3. [Section 5.6, Section 4.2] The principal parameters of Prophet — EL_ACC for the insertion policy, n for the replacement policy, and the number of Multi-path Victim Buffer candidates per entry — are selected through sensitivity sweeps on the same workloads whose aggregate speedup is then reported as the headline result. Since the same evaluation workloads are used both for parameter selection and final reporting, the reported 14.23% speedup is optimistically biased. Please add a held-out workload or input split, or otherwise quantify the leakage from parameter selection, so that the reported gain reflects genuine generalization rather than tuning on the evaluation set.
  4. [Section 5.10, Section 5.11] The manuscript repeatedly describes Prophet's overhead as negligible, but the storage numbers in Section 5.10 show roughly 392 KB of additional on-chip storage (344 KB Multi-path Victim Buffer, 48 KB replacement states, 0.19 KB hint buffer) against a 1 MB metadata table. It is also unclear whether this storage is dedicated on-chip SRAM or carved from the LLC. Please clarify the physical implementation and quantify the resulting area and LLC-capacity effects, and note that the 1.6% energy overhead covers only the memory hierarchy, not the full processor.
minor comments (7)
  1. [Section 5.1] The text contains a typo: 'indirect indirect prefetching scheme' should read 'indirect prefetching scheme'.
  2. [Table 1] The cache hierarchy description lists the L2 as 'mostly_inclusive' and the L3 as 'mostly_exclusive'; please clarify how these two policies interact, since the inclusivity semantics affect both demand traffic and prefetch metadata placement.
  3. [Section 4.1] The claim that the two PEBS events can be implemented with minor modifications to MEM_LOAD_RETIRED.L2_MISS should be supported by a concrete description of the required hardware changes or by a reference to an existing implementation.
  4. [Section 5.4.1] The profiling overhead of less than 2% is taken from reference [15] and is not measured for Prophet's specific event set; please add a direct measurement or clearly state that this is an estimate from prior work.
  5. [Section 5.9, Figure 19] The ablation baseline label 'Triage4 + Triangel Meta' is not defined in the caption; please state the prefetching degree, metadata format, and whether any runtime insertion or resizing policy is active at that point.
  6. [Section 5.6, Figure 16] The green bars indicating the parameters used in other experiments are not explained in the text; please add a sentence defining the green-bar configuration in the caption or body.
  7. [Section 5.2, Figure 11] The DRAM traffic numbers in the text ('18.67%', '0.07%', '10.33%') should be explicitly tied to the normalization baseline (e.g., no temporal prefetcher) to avoid ambiguity.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: Prophet's speedups are measured against external baselines, and its hints are derived from profiled counters rather than from the reported performance targets.

full rationale

Prophet's derivation chain is: Step 1 profiles per-PC prefetching accuracy and metadata allocation using a simplified temporal prefetcher (Section 4.1); Step 2 maps those counters into insertion/replacement hints via Equations 1-2 and sizing hints via Equation 3; Step 3 merges counters across inputs via Equations 4-5. The reported gains (14.23% vs Triangel, 34.48% vs RPG2, Section 5.2) are simulated speedups measured after applying these hints, not quantities computed from the counters by definition. Triangel is evaluated from its open-source implementation [4] and RPG2 from its own published methodology, so the comparison is against external baselines rather than a self-citation chain. The only self-citation, reference [39], appears in the related-work enumeration and is not load-bearing. Parameter choices for EL_ACC, n, and Multi-path Victim Buffer candidates are tuned on the evaluation workloads in Section 5.6, which raises a generalization/overfitting concern but does not make the headline result definitionally equal to its inputs. Likewise, the resizing hint is the profiled allocated-entry count, which is profile-guided configuration rather than a prediction that reduces to its own outcome. The paper's assumption that per-PC accuracy measured under the simplified profiler (insertion disabled, fixed 1 MB table, degree 1) transfers to the full Prophet configuration is empirically supported only for omnetpp in Figure 6; this is a threat to external validity, not a circular derivation. No step satisfies the quoted-reduction standard required for a circularity finding.

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

The central design relies on per-PC prefetching accuracy as a stable signal, PMU/PEBS event availability, and simulation fidelity. Several design parameters (EL_ACC, n, MVB candidates, hint buffer size) are tuned empirically on the evaluated workloads. The Multi-path Victim Buffer is a new hardware structure validated only in simulation.

free parameters (5)
  • EL_ACC insertion threshold = 0.15 (implied by Figure 16's green bar; text does not state the value)
    Used in Eq. 1 to filter PCs below this prefetching accuracy; chosen from a sensitivity sweep on the evaluated workloads.
  • n replacement priority levels = 2 (2-bit replacement state)
    Used in Eq. 2 to assign replacement priorities; sensitivity study tested n=1,2,3 and selected n=2 for the final configuration.
  • Multi-path Victim Buffer candidates per entry = 1
    Section 5.6 tested 1, 2, and 4 candidates and chose 1 as the best performance/storage trade-off.
  • Hint buffer size = 128 entries
    Section 4.4 states 128 entries are empirically sufficient; this bounds instruction and storage overhead.
  • Learning rate schedule cap L = unspecified
    Eq. 4 uses a designer-defined L to cap the denominator min(l+1,L); the paper never reports the value used in Figure 13.
assumptions (5)
  • domain assumption Per-PC prefetching accuracy is stable enough to be classified into a few distinct levels.
    Section 4.1, Figure 6 shows this for omnetpp; insertion and replacement policies depend on this stability.
  • domain assumption MEM_LOAD_RETIRED.L2_Prefetch_Issue and L2_Prefetch_Useful events can be implemented with minor modifications to the existing L2_MISS event.
    Section 4.1 claims this without a hardware implementation or validation.
  • domain assumption The simplified temporal prefetcher (insertion disabled, 1 MB table, degree 1) gives an unbiased measure of each PC's temporal prefetching behavior.
    Section 3.2 defines the profiling configuration; the transfer of these counters to the full Prophet configuration is assumed.
  • domain assumption gem5 full-system simulation with the stated configuration faithfully represents a real processor with a temporal prefetcher.
    All performance claims are based on this simulator (Section 5.1).
  • domain assumption The counter merging formula (Eq. 4) converges to near-optimal hints across inputs.
    Section 4.3 provides only an informal argument, not a proof; Figure 13 offers empirical support.
invented entities (1)
  • Multi-path Victim Buffer
    purpose: Stores evicted Markov targets so a single history address can produce multiple prefetch candidates.
    Validated only in gem5 simulation; no independent implementation or hardware measurement. Adds 344 KB storage (Section 5.10).

how reviews work

0 comments
Cite this review

Pith. "Pith review of Profile-Guided Temporal Prefetching." pith.science (2026). https://pith.science/paper/QZVIDFTE

@misc{pith2026250615985,
  author       = {Pith},
  title        = {Pith review of: Profile-Guided Temporal Prefetching},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/QZVIDFTE}},
  note         = {Machine review of arXiv:2506.15985}
}
read the original abstract

Temporal prefetching shows promise for handling irregular memory access patterns, which are common in data-dependent and pointer-based data structures. Recent studies introduced on-chip metadata storage to reduce the memory traffic caused by accessing metadata from off-chip DRAM. However, existing prefetching schemes struggle to efficiently utilize the limited on-chip storage. An alternative solution, software indirect access prefetching, remains ineffective for optimizing temporal prefetching. In this work, we propose Prophet--a hardware-software co-designed framework that leverages profile-guided methods to optimize metadata storage management. Prophet profiles programs using counters instead of traces, injects hints into programs to guide metadata storage management, and dynamically tunes these hints to enable the optimized binary to adapt to different program inputs. Prophet is designed to coexist with existing hardware temporal prefetchers, delivering efficient, high-performance solutions for frequently executed workloads while preserving the original runtime scheme for less frequently executed workloads. Prophet outperforms the state-of-the-art temporal prefetcher, Triangel, by 14.23%, effectively addressing complex temporal patterns where prior profile-guided solutions fall short (only achieving 0.1% performance gain). Prophet delivers superior performance across all evaluated workload inputs, introducing negligible profiling, analysis, and instruction overhead.

Figures

Figures reproduced from arXiv: 2506.15985 by the authors.

Figure 1
Figure 1. The bottom figure shows a metadata access pat￾tern: 1) Blue/Red dots are metadata accesses that result in useful/useless prefetches; 2) Blue/Red stars represent first metadata access with/without temporal patterns. Their cor￾responding metadata should/should not be inserted in the metadata table. The top figure shows how Triangel [7] applies its PatternConf to the highlighted metadata access pattern. [57]) or incorr… view at source ↗
Figure 3
Figure 3. A general framework of temporal prefetching. (2) it is readily applicable to current architectures without requiring additional memory trace systems. • Compatible. Prophet can co-exist with existing hardware temporal prefetchers. Prophet offers high-performance yet efficient solutions for frequently executed workloads while maintaining the original runtime solution (e.g., Triangel [7]) for rarely executed workloads.… view at source ↗
Figure 4
Figure 4. Prophet architecture overview. Prophet coexists with hardware temporal prefetchers by sharing the same metadata [PITH_FULL_IMAGE:figures/full_fig_p005_4.png] view at source ↗
Figures from the paper (13 more)
Figure 5
Figure 5. Figure 5: Prophet process overview. Step1: Prophet lever [PITH_FULL_IMAGE:figures/full_fig_p005_5.png]
Figure 6
Figure 6. Figure 6: The prefetching accuracy of temporal prefetching across different memory instructions in omnetpp. program inputs. Through repeated learning, Prophet innovatively enables a single optimized binary to achieve optimal performance across a wide range of program inputs. 4 D…
Figure 7
Figure 7. Figure 7: Challenges of traditional profile-guided optimiza [PITH_FULL_IMAGE:figures/full_fig_p007_7.png]
Figure 9
Figure 9. Figure 9: The Multi-path Victim Buffer. • Replacement. We reuse Prophet Replacement Policy to maintain frequently used Markov targets. As shown in Fig￾ure 9, we add a counter for each Markov target, incrementing the counter value each time the target is accessed. We set the prio…
Figure 10
Figure 10. Figure 10: IPC speedup compared to RPG2 and Triangel. astar_biglakes gcc_166 mcf omnetpp soplex_pds-50 sphinx3 xalancbmk Geomean 1.0 1.1 1.2 1.3 Normalized DRAM Traffic RPG2 Triangel Prophet [PITH_FULL_IMAGE:figures/full_fig_p009_10.png]
Figure 12
Figure 12. Figure 12: Prefetching coverage and accuracy6 . additional memory traffic. The workload-specific performance im￾provements are comparable to those reported in the original Tri￾angel paper [7]. However, the overall speedup for Triangel in our experiments is not identical because …
Figure 13
Figure 13. Figure 13: Prophet learns counters from gcc’s inputs. [PITH_FULL_IMAGE:figures/full_fig_p010_13.png]
Figure 14
Figure 14. Figure 14: Prophet’s learning feature can be generalized to other workloads, such as astar and soplex. Triangel metadata (Section 5.9), indicating the status where no in￾put is fed to Prophet (shown as “Disable”). Then, we provide the inputs in the following order: gcc_166, gcc_…
Figure 5
Figure 5. Figure 5: Across all evaluated workloads, Prophet’s analysis over [PITH_FULL_IMAGE:figures/full_fig_p010_5.png]
Figure 17
Figure 17. Figure 17: IPC speedup with varying L1 prefetcher. achieves the best trade-off between performance gain and storage overhead. While prefetching more candidates improves prefetch￾ing coverage, it can negatively impact performance. For example, prefetching additional Markov target…
Figure 16
Figure 16. Figure 16: Sensitivity study. and 8.41% for Triangel. Unlike SPEC CPU benchmarks, CRONO features more prefetch kernels with stride patterns, aligning with RPG2 ’s strengths. As a result, RPG2 delivers greater performance gains on CRONO. Prophet outperforms RPG2 by handling more …
Figure 18
Figure 18. Figure 18: IPC speedup with varying DRAM channels. 11 [PITH_FULL_IMAGE:figures/full_fig_p011_18.png]
Figure 19
Figure 19. Figure 19: Prophet Features Breakdown [PITH_FULL_IMAGE:figures/full_fig_p012_19.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

65 extracted references · 65 canonical work pages

  1. [1]

    [n. d.]. Intel’s PerfMon Events. https://perfmon-events.intel.com

    work page

  2. [2]

    Hot Chips 2023: arm’s neoverse v2

    2023. Hot Chips 2023: arm’s neoverse v2. https://hc2023.hotchips.org/assets/ program/conference/day1/CPU1/HC2023.Arm.MagnusBruce.v04.FINAL.pdf

    work page 2023

  3. [3]

    Intel®64 and IA-32 Architectures Software Developer’s Man- ual

    2023. Intel®64 and IA-32 Architectures Software Developer’s Man- ual. https://www.intel.com/content/www/us/en/developer/articles/technical/ intel-sdm.html

    work page 2023

  4. [4]

    Github: gem5-triangel

    2024. Github: gem5-triangel. https://github.com/SamAinsworth/gem5-triangel

    work page 2024

  5. [5]

    Masab Ahmad, Farrukh Hijaz, Qingchuan Shi, and Omer Khan. 2015. Crono: A benchmark suite for multithreaded graph algorithms executing on futuristic multicores. In2015 IEEE International Symposium on Workload Characterization. 44–55

    work page 2015

  6. [6]

    Sam Ainsworth and Timothy M Jones. 2017. Software prefetching for indirect memory accesses. InCGO. 305–317

    work page 2017

  7. [7]

    Sam Ainsworth and Lev Mukhanov. 2024. Triangel: A High-Performance, Accu- rate, Timely On-Chip Temporal Prefetcher. InISCA

    work page 2024

  8. [8]

    Grant Ayers, Heiner Litz, Christos Kozyrakis, and Parthasarathy Ranganathan

    work page

Show all 65 references
  1. [9]

    Jean-Loup Baer and Tien-Fu Chen. 1991. An effective on-chip preloading scheme to reduce data access penalty. InProceedings of the 1991 ACM/IEEE conference on Supercomputing. 176–186

    1991

  2. [10]

    Mohammad Bakhshalipour, Pejman Lotfi-Kamran, and Hamid Sarbazi-Azad. 2018. Domino temporal data prefetcher. InHPCA. 131–142

    2018

  3. [11]

    Mohammad Bakhshalipour, Mehran Shakerinava, Pejman Lotfi-Kamran, and Hamid Sarbazi-Azad. 2019. Bingo spatial data prefetcher. InHPCA. 399–411

    2019

  4. [12]

    Mohammad Bakhshalipour, Seyedali Tabaeiaghdaei, Pejman Lotfi-Kamran, and Hamid Sarbazi-Azad. 2019. Evaluation of hardware data prefetchers on server processors.CSUR(2019), 1–29

    2019

  5. [13]

    Rahul Bera, Anant V Nori, Onur Mutlu, and Sreenivas Subramoney. 2019. Dspatch: Dual spatial pattern prefetcher. InMICRO. 531–544

    2019

  6. [14]

    Nathan Binkert, Bradford Beckmann, Gabriel Black, Steven K Reinhardt, Ali Saidi, Arkaprava Basu, Joel Hestness, Derek R Hower, Tushar Krishna, Somayeh Sardashti, et al. 2011. The gem5 simulator.ACM SIGARCH computer architecture news(2011)

    2011

  7. [15]

    Georgios Bitzes and Andrzej Nowak. 2014. The overhead of profiling using PMU hardware counters.CERN openlab report(2014), 1–16

    2014

  8. [16]

    Burton H Bloom. 1970. Space/time trade-offs in hash coding with allowable errors.Commun. ACM(1970), 422–426

    1970

  9. [17]

    David Callahan, Ken Kennedy, and Allan Porterfield. 1991. Software prefetching. ACM SIGARCH Computer Architecture News19, 2 (1991), 40–52

    1991

  10. [18]

    Mainak Chaudhuri, Jayesh Gaur, Nithiyanandan Bashyam, Sreenivas Subra- money, and Joseph Nuzman. 2012. Introducing hierarchy-awareness in replace- ment and bypass algorithms for last-level caches. InPACT. 293–304

    2012

  11. [19]

    William Y Chen, Scott A Mahlke, Pohua P Chang, and Wen-mei W Hwu. 1991. Data access microarchitectures for superscalar processors with compiler-assisted data prefetching. InMICRO. 69–73

    1991

  12. [20]

    Fredrik Dahlgren and Per Stenstrom. 1995. Effectiveness of hardware-based stride and sequential prefetching in shared-memory multiprocessors. InHPCA. 68–77

    1995

  13. [21]

    Arnaldo Carvalho De Melo. 2010. The new linux’perf’tools. InSlides from Linux Kongress. 1–42

    2010

  14. [22]

    Edward H Gornish, Elana D Granston, and Alexander V Veidenbaum. 1990. Compiler-directed data prefetching in multiprocessors with memory hierarchies. InICS. 128–142

    1990

  15. [23]

    Mingjian He, Hua Wang, Ke Zhou, Kaichao Cui, Huabing Yan, Chang Guo, and Rongfeng He. 2022. DSDP: Dual Stream Data Prefetcher. InPACT. 372–383

    2022

  16. [24]

    Ibrahim Hur and Calvin Lin. 2006. Memory prefetching using adaptive stream detection. InMICRO. 397–408

    2006

  17. [25]

    Yasuo Ishii, Mary Inaba, and Kei Hiraki. 2009. Access map pattern matching for data cache prefetch. InICS. 499–500

    2009

  18. [26]

    Akanksha Jain and Calvin Lin. 2013. Linearizing irregular memory accesses for improved correlated prefetching. InMICRO. 247–259

    2013

  19. [27]

    Akanksha Jain and Calvin Lin. 2016. Back to the future: Leveraging Belady’s algorithm for improved cache replacement.ACM SIGARCH Computer Architecture News(2016), 78–89

    2016

  20. [28]

    Aamer Jaleel, Kevin B Theobald, Simon C Steely Jr, and Joel Emer. 2010. High performance cache replacement using re-reference interval prediction (RRIP). ACM SIGARCH computer architecture news38, 3 (2010), 60–71

    2010

  21. [29]

    Saba Jamilan, Tanvir Ahmed Khan, Grant Ayers, Baris Kasikci, and Heiner Litz

  22. [30]

    Shizhi Jiang, Qiusong Yang, and Yiwei Ci. 2022. Merging similar patterns for hardware prefetching. InMICRO. 1012–1026

    2022

  23. [31]

    Norman P Jouppi. 1990. Improving direct-mapped cache performance by the addition of a small fully-associative cache and prefetch buffers.ACM SIGARCH Computer Architecture News18, 2SI (1990), 364–373

    1990

  24. [32]

    Tanvir Ahmed Khan, Nathan Brown, Akshitha Sriraman, Niranjan K Soundarara- jan, Rakesh Kumar, Joseph Devietti, Sreenivas Subramoney, Gilles A Pokam, 13 Heiner Litz, and Baris Kasikci. 2021. Twig: Profile-guided btb prefetching for data center applications. InMICRO. 816–829

    2021

  25. [33]

    Tanvir Ahmed Khan, Ian Neal, Gilles Pokam, Barzan Mozafari, and Baris Kasikci

  26. [34]

    Tanvir Ahmed Khan, Akshitha Sriraman, Joseph Devietti, Gilles Pokam, Heiner Litz, and Baris Kasikci. 2020. I-spy: Context-driven conditional instruction prefetching with coalescing. InMICRO. IEEE, 146–159

    2020

  27. [35]

    Tanvir Ahmed Khan, Muhammed Ugur, Krishnendra Nathella, Dam Sunwoo, Heiner Litz, Daniel A Jiménez, and Baris Kasikci. 2022. Whisper: Profile-guided branch misprediction elimination for data center applications. InMCIRO. 19–34

    2022

  28. [36]

    Tanvir Ahmed Khan, Dexin Zhang, Akshitha Sriraman, Joseph Devietti, Gilles Pokam, Heiner Litz, and Baris Kasikci. 2021. Ripple: Profile-guided instruction cache replacement for data center applications. InISCA. 734–747

    2021

  29. [37]

    Jinchun Kim, Seth H Pugsley, Paul V Gratz, AL Narasimha Reddy, Chris Wilkerson, and Zeshan Chishti. 2016. Path confidence based lookahead prefetching. In MICRO. 1–12

    2016

  30. [38]

    Sunil Kim and Alexander V Veidenbaum. 1997. Stride-directed prefetching for secondary caches. InICPP. 314–321

    1997

  31. [39]

    Mengming Li, Qijun Zhang, Yongqing Ren, and Zhiyao Xie. 2025. Integrating Prefetcher Selection with Dynamic Request Allocation Improves Prefetching Efficiency. InHPCA

    2025

  32. [40]

    Heiner Litz, Grant Ayers, and Parthasarathy Ranganathan. 2022. CRISP: critical slice prefetching. InASPLOS. 300–313

    2022

  33. [41]

    Pierre Michaud. 2016. Best-offset hardware prefetching. InHPCA. 469–480

    2016

  34. [42]

    Sparsh Mittal. 2016. A survey of recent prefetching techniques for processor caches.CSUR(2016), 1–35

    2016

  35. [43]

    Naveen Muralimanohar, Rajeev Balasubramonian, and Norman P Jouppi. 2009. CACTI 6.0: A tool to model large caches.HP laboratories27 (2009), 28

    2009

  36. [44]

    Arun A Nair and Lizy K John. 2008. Simulation points for SPEC CPU 2006. In ICCD. 397–403

    2008

  37. [45]

    Agustín Navarro-Torres, Biswabandan Panda, Jesús Alastruey-Benedé, Pablo Ibáñez, Víctor Viñals-Yúfera, and Alberto Ros. 2022. Berti: an accurate local-delta data prefetcher. InMICRO. 975–991

    2022

  38. [46]

    Kyle J Nesbit and James E Smith. 2004. Data cache prefetching using a global history buffer. InHPCA. 96–96

    2004

  39. [47]

    Samuel Pakalapati and Biswabandan Panda. 2020. Bouquet of instruction pointers: Instruction pointer classifier-based spatial hardware prefetching. InISCA

    2020

  40. [48]

    Maksim Panchenko, Rafael Auler, Bill Nell, and Guilherme Ottoni. 2019. Bolt: a practical binary optimizer for data centers and beyond. InCGO. 2–14

    2019

  41. [49]

    Biswabandan Panda. 2023. CLIP: Load Criticality based Data Prefetching for Bandwidth-constrained Many-core Systems. InMICRO. 714–727

    2023

  42. [50]

    Seth H Pugsley, Zeshan Chishti, Chris Wilkerson, Peng-fei Chuang, Robert L Scott, Aamer Jaleel, Shih-Lien Lu, Kingsum Chow, and Rajeev Balasubramonian

  43. [51]

    Timothy Sherwood, Erez Perelman, Greg Hamerly, and Brad Calder. 2002. Auto- matically characterizing large scale program behavior.ACM SIGPLAN Notices (2002), 45–57

    2002

  44. [52]

    Manjunath Shevgoor, Sahil Koladiya, Rajeev Balasubramonian, Chris Wilkerson, Seth H Pugsley, and Zeshan Chishti. 2015. Efficiently prefetching complex address patterns. InMICRO. 141–152

    2015

  45. [53]

    Stephen Somogyi, Thomas F Wenisch, Anastassia Ailamaki, Babak Falsafi, and Andreas Moshovos. 2006. Spatial memory streaming.ACM SIGARCH Computer Architecture News(2006), 252–263

    2006

  46. [54]

    Shixin Song, Tanvir Ahmed Khan, Sara Mahdizadeh Shahri, Akshitha Sriraman, Niranjan K Soundararajan, Sreenivas Subramoney, Daniel A Jiménez, Heiner Litz, and Baris Kasikci. 2022. Thermometer: profile-guided btb replacement for data center applications. InISCA. 742–756

    2022

  47. [55]

    Thomas F Wenisch, Michael Ferdman, Anastasia Ailamaki, Babak Falsafi, and Andreas Moshovos. 2009. Practical off-chip meta-data for temporal memory streaming. InHPCA. 79–90

    2009

  48. [56]

    Hao Wu, Krishnendra Nathella, Matthew Pabst, Dam Sunwoo, Akanksha Jain, and Calvin Lin. 2021. Practical temporal prefetching with compressed on-chip metadata.IEEE Trans. Comput.(2021), 2858–2871

    2021

  49. [57]

    Hao Wu, Krishnendra Nathella, Joseph Pusdesris, Dam Sunwoo, Akanksha Jain, and Calvin Lin. 2019. Temporal prefetching without the off-chip metadata. In MICRO. 996–1008

    2019

  50. [58]

    Hao Wu, Krishnendra Nathella, Dam Sunwoo, Akanksha Jain, and Calvin Lin

  51. [59]

    Wm A Wulf and Sally A McKee. 1995. Hitting the memory wall: Implications of the obvious.ACM SIGARCH computer architecture news23, 1 (1995), 20–24

    1995

  52. [60]

    Yuxuan Zhang, Nathan Sobotka, Soyoon Park, Saba Jamilan, Tanvir Ahmed Khan, Baris Kasikci, Gilles A Pokam, Heiner Litz, and Joseph Devietti. 2024. RPG2: Robust Profile-Guided Runtime Prefetch Generation. InASPLOS. 999–1013. 14

    2024

  53. [2014]

    Sandbox prefetching: Safe run-time evaluation of aggressive prefetchers. InHPCA. 626–637

  54. [2019]

    Efficient metadata management for irregular data prefetching. InISCA. 449–461

  55. [2020]

    InASPLOS

    Classifying memory access patterns for prefetching. InASPLOS. 513–526

  56. [2021]

    Dmon: Efficient detection and correction of data locality problems using selective profiling. InOSDI. 163–181

  57. [2022]

    InEurosys

    Apt-get: Profile-guided timely software prefetching. InEurosys. 747–764

Pith tools

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