Pith. sign in

REVIEW 4 major objections 4 minor 40 references

Pickle: Precise, Flexible Cross-Core Last-level Cache Data Prefetching for Irregular Memory Accesses

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

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

Pith's one-line read Pickle claims a programmable engine at the last-level cache that runs software-defined kernels can prefetch irregular accesses ahead of demand with near-zero traffic overhead, showing a 1.32x BFS speedup in simulation.

desk verdict A genuine programmable-LLC-prefetcher idea with a solid BFS gem5 study, but the abstract overclaims to GAP/NAS, and the PicklePG execution engine is an unmodeled idealization that even the BFS numbers rest on. read the letter →

arxiv 2511.19973 v2 pith:I4MXP52W submitted 2025-11-25 cs.AR

Hoa Nguyen , Pongstorn Maidee , Jason Lowe-Power , Alireza Kaviani This is my paper · ORCID
classification cs.AR
keywords prefetchinglast-levelcacheirregularmemoryaccesssoftware-definedprefetchkerneldecoupledaccess/executegraphanalyticsbreadth-firstsearchmemory-sideaccelerator
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

Pickle transfers the hard part of prefetching irregular memory accesses from hardware pattern prediction to software expression. Applications write small kernels that describe how to walk their own data structures — for BFS, from the work queue to neighbor pointers to neighbors to the visited array — and a hardware engine at the last-level cache runs these kernels ahead of the cores. Because the engine is decoupled from the cores, it can issue many concurrent prefetches without stealing core resources, and its scheduler drops prefetches that would arrive too late. In full-system cycle-level simulation of an 8-core system, Pickle achieves a 1.32x geomean speedup on BFS across 12 real-world graphs while moving only 1.01x the DRAM data of the baseline. The abstract also reports 1.49x and 1.53x speedups on graph algorithms and scientific scatter/gather kernels, respectively.

What carries the argument

The PicklePG — the prefetch generator, a programmable hardware unit that executes software-loaded kernels — is the core enabler. Each kernel takes a prefetch hint (the 64-bit payload of an uncacheable store) and emits a chain of virtual addresses representing the application's next memory accesses. Supporting hardware routes and regulates that chain: a pending prefetch work queue stores hints, a priority queue schedules generated prefetch addresses by arrival order, a dedicated MMU (PickleMMU) performs virtual-to-physical translation, and a private coherent cache (Pickle Cache) holds prefetched data and feeds responses back into the kernel as new events. Together they implement the decoupled

What would settle it

A concrete falsifier would be a cycle-level implementation of the PicklePG, or an FPGA prototype running the BFS kernel, that measures kernel execution throughput and latency; if a real PicklePG cannot sustain issuing the multi-level prefetch chains fast enough to stay ahead of eight cores, or if its area/latency exceeds the modeled budget, the reported 1.32x speedup and 1.01x traffic ratio would not reproduce.

Watch

Extended reading notes

Core claim

On its own terms, the paper's discovery is that the prefetching problem for irregular accesses splits cleanly into logic and scheduling. The logic is expressed as software kernels loaded into a programmable unit (PicklePG) via memory-mapped I/O; a single uncacheable store from the core carries a hint (e.g., the current BFS queue node's address), and the kernel expands that hint into a chain of virtual addresses spanning multiple levels of indirection. The hardware's job is then just to schedule and issue those prefetches: a priority queue orders work by arrival (earliest-deadline-first), a private MMU translates virtual addresses, a private cache stores prefetched data coherently, and a drop

Load-bearing premise

The results depend on the assumption that the PicklePG can execute the software-defined kernels at 4GHz with the modeled queueing and area (about 0.4 mm²), since its physical implementation is abstracted rather than modeled in the simulation.

Editorial extensions

If this is right

  • If Pickle's simulated results hold, irregular workloads like graph BFS can be sped up by over 30% with essentially no increase in DRAM traffic, making the prefetcher a cheap, energy-efficient addition to servers that run such workloads.
  • Software-defined prefetching means the same hardware can be adapted to new access patterns by updating the kernel, potentially lengthening the useful life of a prefetcher design across workload generations.
  • Because Pickle is decoupled from core resources and shared, it should scale with core count; multiple instances can be added coherently, unlike designs that require core-private logic.
  • Composing Pickle with existing core-private prefetchers yields further speedups (1.23x-1.26x over private-prefetcher-only systems), indicating that LLC-level and core-level prefetching solve complementary problems.

Reading between the lines

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

  • The same kernel mechanism could be applied to other irregular access patterns — sparse matrix-vector multiplication, database index traversals, or pointer-chasing benchmarks — as long as the address chain can be expressed in a bounded kernel; the paper only evaluates BFS.
  • The paper's abstraction of the PicklePG's execution leaves open whether a real implementation can keep up with eight cores at 4GHz; a prototype or RTL model would be the natural next step to confirm the speedup.
  • The prefetch-drop threshold is a single software parameter; one could imagine auto-tuning it per graph or per phase of execution, or replacing the fixed distance with a latency-based measure.
  • Since the prefetcher uses its own MMU and virtual addresses, it may in principle support inter-process prefetching in shared environments, but the paper assumes a non-shared environment, so that remains an extension.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

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

Referee Report

4 major / 4 minor

Summary. The paper proposes Pickle, a software-defined LLC prefetcher that aims to prefetch irregular, data-dependent access patterns by executing user-supplied 'prefetch kernels' in a programmable hardware generator (PicklePG). Software sends prefetch hints to the prefetcher via uncacheable stores; the PicklePG then issues a chain of prefetch requests using its own MMU, TLB, pending queues, and a private coherent Pickle Cache. The design is evaluated in gem5 full-system simulation on a Zen5-like 8-core ARM system, with experiments focused on the GAPBS top-down BFS implementation on 12 real-world graphs, comparing against stride, AMPM, IMP, and combinations of these private-cache prefetchers. The abstract, however, claims evaluation across all GAP benchmark suite algorithms and NAS parallel benchmark scatter/gather kernels, with speedups of 1.49x and 1.53x, respectively; these results do not appear in the body.

Significance. If the central claim holds, the paper makes a useful contribution: moving prefetch logic to software at the LLC, decoupled from core resources, is a plausible way to handle irregular access patterns while keeping DRAM traffic low. The gem5 study is detailed in several respects: it uses a realistic CHI-based NoC, checkpointing for fair comparison, multiple graphs of varying size and degree, and analyses of prefetch timeliness, load-to-use latency, NoC utilization, and DRAM traffic. These are genuine strengths. However, the current evidence is narrower than the abstract claims, and the central speedup result rests on an unmodeled PicklePG whose execution cost is assumed away. The paper needs additional sensitivity analysis and either the missing experiments or a substantially narrowed set of claims before the contribution is fully supported.

major comments (4)
  1. [IV-B, Table I; VI-A, VI-E] The PicklePG is abstracted rather than modeled. Section IV-B states: 'we abstract the physical implementation of the PicklePG and focus on how PicklePG interacts with the rest of the prefetcher components.' Table I gives only a 4GHz clock, a 256KiB Pickle Cache, and a 1024-request queue; no cycle cost, issue width, or instruction-set model is provided for the kernel in Algorithm 2, which contains dependent loads, loops, and branches. The reported 1.32x geomean BFS speedup (Section VI-A) and 1.01x DRAM traffic (Section VI-E) therefore assume zero-cost kernel execution. A sensitivity analysis with per-event kernel latency (e.g., 10-100 cycles) is required; without it the speedup claim is not supported for the proposed hardware.
  2. [Abstract; V-C; VI] Abstract vs. body mismatch. The abstract claims evaluation 'running all GAP benchmark suite algorithms across nine real-world graphs and irregular-access dominated scientific applications from the NAS parallel benchmark suite,' and reports 1.49x graph and 1.53x NAS speedups. Section V-C and Section VI present only top-down BFS on 12 graphs; no NAS or other GAP algorithms appear. Either add these experiments or revise the abstract and Section I to the actual scope. As written, the headline claims are unverifiable.
  3. [VI-A, Fig. 6, Fig. 11] The ideal LLC prefetcher is not an upper bound. Section VI-A defines the ideal LLC prefetcher as one that 'covers the entire memory footprint...' and approximates it with a 6GiB, 1024-way LLC. Yet Figure 11 shows the 'ideal_l3' configuration with DRAM access counts approximately equal to baseline for berkstan (293.8 vs 294.5) and greater for livejournal (468.8 vs 378.2). This contradicts the definition and invalidates the 'upside captured' percentages in Figure 7. The authors should either explain the discrepancy or replace this upper bound with a prefetcher that actually supplies the requested blocks.
  4. [VI-B, Figs. 7-8] Parameter tuning on the evaluation set. The prefetch distance (32) and drop threshold (16) are introduced and tuned in Section VI-B on the same 12 graphs used for the headline speedups. Figure 7 shows that without the drop threshold several graphs slow down (twitch, pokec, orkut); with it all speed up. No sensitivity analysis or train/test separation is shown, and the kernel in Algorithm 2 is hand-written for BFS. This makes the reported geomean vulnerable to overfitting. Please report sweeps of distance/threshold and state how a user would choose these parameters in practice.
minor comments (4)
  1. [Algorithm 2] The second 'if response.vaddr ∈ neighbor ptr range' condition is almost certainly meant to be 'neighbors range'; as printed, the logic appears duplicated and unreachable for the intended step.
  2. [Abstract, I] Spacing typo 'withoutexpanding' appears in the abstract and introduction; inconsistent capitalization of 'Pickle Prefetcher' also occurs throughout.
  3. [V] No artifact or code availability statement is provided. For a gem5-based study, releasing configuration scripts, the merged BFS binary, and the prefetch-kernel source would materially improve reproducibility.
  4. [Fig. 3] The tile diagrams are difficult to read, and the meaning of the 'R' labels is not defined in the caption.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: the paper is an experimental mechanism study; the abstracted PicklePG and hand-chosen prefetch parameters are modeling/tuning concerns, not definitional reductions.

full rationale

The paper makes no formal derivation; its contribution is an evaluated hardware/software mechanism. The central claim—that a software-defined LLC prefetcher can run ahead of irregular accesses—is tested by inserting a prefetch hint into BFS and simulating the resulting prefetch engine. The prefetch kernel (Algorithm 2) and parameters (distance 32, drop threshold 16) are authored and chosen by the investigators, and the PicklePG is abstracted rather than cycle-modeled; these are validity/overfitting risks for the speedup numbers, but not circular reductions. Nothing in the paper fits a parameter and then renames that fit a 'prediction.' The abstract's 1.49x/1.53x numbers are absent from the body, but that is a reporting inconsistency, not circularity. The only notable self-citation is [24], the gem5 simulator, whose author list overlaps; that citation supplies the evaluation tool, not the paper's conclusion, and it is external and widely used, so under Rule 4 it is not load-bearing. No quoted equation, fitted parameter, or self-citation chain reduces the paper's central claim to its own inputs.

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

The central evaluation rests on a simulated, abstracted programmable hardware engine plus hand-written, workload-specific prefetch kernels with tuned distance/drop parameters. The free parameters are not derived from first principles, and the hardware entities have no independent silicon evidence. The most fragile premise is the feasibility and timing of PicklePG, which is explicitly abstracted in Section IV-B.

free parameters (3)
  • prefetch distance = 32 nodes
    Hand-selected; controls how far ahead the prefetch kernel runs. The reported results use distance 32 (Section VI-A), and the authors show that without the drop mechanism some graphs slow down, indicating sensitivity to this parameter.
  • prefetch drop threshold = 16 nodes
    Hand-selected; drops prefetch tasks closer than 16 nodes to the core's current position. Section VI-B shows the drop threshold materially changes results, so it is a fitted parameter rather than a fixed design constant.
  • prefetch kernels per workload = BFS kernel (Algorithm 2), memcpy kernel
    The prefetch logic is written by software for each access pattern. The speedup depends on these hand-authored kernels, so the kernels themselves are fitted inputs to the evaluation.
assumptions (5)
  • domain assumption gem5 with ARM CHI/RUBY models a representative 8-core cache-coherent system
    All results depend on the fidelity of gem5 v24.1.0.2 with the CHI protocol and DDR5 model described in Table I.
  • domain assumption Uncacheable stores can be used as prefetch hints without prohibitive core overhead
    The design relies on UC stores triggering the prefetcher; the write-buffer flush overhead is acknowledged in Section IV-G but not separately modeled or measured.
  • ad hoc to paper The PicklePG can execute arbitrary software-defined prefetch logic at modeled timing and area
    Section IV-B explicitly abstracts the physical implementation of PicklePG. The simulation therefore assumes the programmable engine is feasible at 4GHz, 256KiB cache, and <0.4mm2 without modeling its internals.
  • domain assumption BFS data structures are contiguous arrays of fixed-size elements
    Algorithm 2 assumes contiguous work_queue, neighbor_ptr, neighbors, and visited arrays. This holds for the CSR-based BFS implementation but not for all irregular access patterns.
  • ad hoc to paper Top-down BFS is representative of 'all GAP benchmark suite algorithms'
    The abstract claims evaluation of the full GAP benchmark suite, but the body evaluates only top-down BFS. The equivalence is assumed without evidence.
invented entities (4)
  • PicklePG (programmable prefetch generator)
    purpose: Executes software-defined prefetch kernels and generates prefetch addresses from hints and prefetch responses
    Simulated only; no hardware implementation, formal model, or measured area/timing is provided.
  • PickleMMU with dedicated TLB and page table walkers
    purpose: Translates prefetch virtual addresses without polluting core TLBs
    Simulated component; its behavior is assumed to match a core MMU with 64-entry L1 TLB and 1024-entry L2 TLB.
  • Pickle Cache (256KiB private coherent cache)
    purpose: Holds prefetched data and supports chained dependent prefetches while maintaining cache coherence
    Simulated component; coherence behavior is assumed from the gem5 CHI/MOESI model and not verified in silicon.
  • MMIO/UC-store prefetch hint interface
    purpose: Lets software send prefetch hints without ISA changes, selecting kernels by the store address
    Uses an existing UC-store mechanism, but the mapped prefetcher I/O page and address-to-kernel selection are new and only simulated.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Pickle: Precise, Flexible Cross-Core Last-level Cache Data Prefetching for Irregular Memory Accesses." pith.science (2026). https://pith.science/paper/I4MXP52W

@misc{pith2026251119973,
  author       = {Pith},
  title        = {Pith review of: Pickle: Precise, Flexible Cross-Core Last-level Cache Data Prefetching for Irregular Memory Accesses},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/I4MXP52W}},
  note         = {Machine review of arXiv:2511.19973}
}
read the original abstract

Graph analytics and sparse scientific workloads are dominated by parallel chains of data-dependent, long-latency memory accesses whose patterns are difficult for hardware to infer yet straightforward to express in software. Conventional hardware prefetchers attempt to recover this information from address streams alone, but false positives lead to substantial memory traffic overhead. Software-assisted approaches offer greater flexibility but still consume core limited resources. We propose Pickle, a software-defined, hardware-managed lastlevel cache (LLC) prefetcher that follows the decoupled access/execute philosophy. Pickle serves as an independent access engine, fully decoupled from core resources, that executes prefetch kernels sliced from the original application to bring data into the shared LLC ahead of demand. We evaluate Pickle using full-system, cycle-level simulation of a cluster of 8 high-performance cores, running all GAP benchmark suite algorithms across nine real-world graphs and irregular-access dominated scientific applications from the NAS parallel benchmark suite. Over a no-prefetching baseline, Pickle achieves 1.49x geomean speedup with only 2% DRAM traffic overhead on graph algorithms, and 1.53x with a 4.5% memory traffic reduction on NAS scatter/gather kernels. For reference, the state-of-the-art coreprivate indirect prefetcher achieves 1.40x but incurs 43% DRAM traffic overhead on graph workloads, and 1.36x at zero traffic overhead on scatter/gather kernels, illustrating the challenge of inferring irregular access patterns without application-level context. Pickle also composes transparently with private cache prefetchers: combining it with the state-of-the-art indirect or a simple stride prefetcher yields 1.65x-1.66x and 1.72x-1.84x geomean speedup on graph and NAS scatter/gather workloads, respectively.

Figures

Figures reproduced from arXiv: 2511.19973 by the authors.

Figure 1
Figure 1. An example of memory access pattern of the Breadth-first [PITH_FULL_IMAGE:figures/full_fig_p003_1.png] view at source ↗
Figure 2
Figure 2. The architecture of the Pickle Prefetcher with data paths. The [PITH_FULL_IMAGE:figures/full_fig_p003_2.png] view at source ↗
Figure 3
Figure 3. Data paths of cache accesses involving the Pickle Prefetcher. [PITH_FULL_IMAGE:figures/full_fig_p004_3.png] view at source ↗
Figures from the paper (8 more)
Figure 4
Figure 4. Figure 4: Data paths for sending a prefetch hint from the core to the [PITH_FULL_IMAGE:figures/full_fig_p004_4.png]
Figure 5
Figure 5. Figure 5: Speedup of various prefetcher configurations over the baseline system. The graphs are sorted with increasing sizes from left to right. [PITH_FULL_IMAGE:figures/full_fig_p009_5.png]
Figure 6
Figure 6. Figure 6: Speedup of the Pickle Prefetcher compared to an ideal LLC prefetcher. The graphs are sorted with increasing sizes from left to right. [PITH_FULL_IMAGE:figures/full_fig_p009_6.png]
Figure 8
Figure 8. Figure 8: Breakdown of dropped prefetch work normalized to the total [PITH_FULL_IMAGE:figures/full_fig_p009_8.png]
Figure 10
Figure 10. Figure 10: Average Utilization per Cycle of across all links connecting [PITH_FULL_IMAGE:figures/full_fig_p010_10.png]
Figure 11
Figure 11. Figure 11: Data source distribution (graph) and access latencies (table, measurement are in cycles) of demand requests from the cores excluding [PITH_FULL_IMAGE:figures/full_fig_p011_11.png]
Figure 12
Figure 12. Figure 12: Total DRAM Bandwidth across four memory channels when using different combinations of prefetchers. The result is discussed in [PITH_FULL_IMAGE:figures/full_fig_p011_12.png]
Figure 13
Figure 13. Figure 13: Total data movement between the DRAM and the cache normalized to the total data movement of the baseline system. The lower [PITH_FULL_IMAGE:figures/full_fig_p011_13.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

40 extracted references · 3 linked inside Pith

  1. [1]

    Graph prefetching using data structure knowledge,

    S. Ainsworth and T. M. Jones, “Graph prefetching using data structure knowledge,” inProceedings of the 2016 International Conference on Supercomputing, 2016, pp. 1–11

    2016

  2. [2]

    Amd64 architecture programmer’s manual volume 2: System programming,

    AMD, “Amd64 architecture programmer’s manual volume 2: System programming,” vol. 1-5, 2024

    2024

  3. [3]

    AMBA 5 CHI architecture specification,

    ARM, “AMBA 5 CHI architecture specification,” https://developer.arm. com/documentation/ihi0050/D/, accessed: 2024-11-24

    2024

  4. [4]

    Arm a-profile a64 instruction set architecture,

    Arm, “Arm a-profile a64 instruction set architecture,” accessed: 2025- 04-13

    2025

  5. [5]

    Group formation in large social networks: membership, growth, and evolution,

    L. Backstrom, D. Huttenlocher, J. Kleinberg, and X. Lan, “Group formation in large social networks: membership, growth, and evolution,” inProceedings of the 12th ACM SIGKDD international conference on Knowledge discovery and data mining, 2006, pp. 44–54

    2006

  6. [6]

    An effective on-chip preloading scheme to reduce data access penalty,

    J.-L. Baer and T.-F. Chen, “An effective on-chip preloading scheme to reduce data access penalty,” inProceedings of the 1991 ACM/IEEE conference on Supercomputing, 1991, pp. 176–186

    1991

  7. [7]

    Bingo spatial data prefetcher,

    M. Bakhshalipour, M. Shakerinava, P. Lotfi-Kamran, and H. Sarbazi- Azad, “Bingo spatial data prefetcher,” in2019 IEEE International Sym- posium on High Performance Computer Architecture (HPCA). IEEE, 2019, pp. 399–411

    2019

  8. [8]

    The gap benchmark suite,

    S. Beamer, K. Asanovi ´c, and D. Patterson, “The gap benchmark suite,” arXiv preprint arXiv:1508.03619, 2015

    arXiv 2015

Show all 40 references
  1. [9]

    The gem5 simulator,

    N. Binkert, B. Beckmann, G. Black, S. K. Reinhardt, A. Saidi, A. Basu, J. Hestness, D. R. Hower, T. Krishna, S. Sardashtiet al., “The gem5 simulator,”ACM SIGARCH computer architecture news, vol. 39, no. 2, pp. 1–7, 2011

    2011

  2. [10]

    Xuantie-910: A commercial multi-core 12- stage pipeline out-of-order 64-bit high performance risc-v processor with vector extension: Industrial product,

    C. Chen, X. Xiang, C. Liu, Y . Shang, R. Guo, D. Liu, Y . Lu, Z. Hao, J. Luo, Z. Chenet al., “Xuantie-910: A commercial multi-core 12- stage pipeline out-of-order 64-bit high performance risc-v processor with vector extension: Industrial product,” in2020 ACM/IEEE 47th Annual I...

    2020

  3. [11]

    Some results of the earliest deadline schedul- ing algorithm,

    H. Chetto and M. Chetto, “Some results of the earliest deadline schedul- ing algorithm,”IEEE Transactions on software engineering, vol. 15, no. 10, p. 1261, 1989

    1989

  4. [12]

    The anatomy of a scientific rumor,

    M. De Domenico, A. Lima, P. Mougel, and M. Musolesi, “The anatomy of a scientific rumor,”Scientific reports, vol. 3, no. 1, p. 2980, 2013

    2013

  5. [13]

    Differential- matching prefetcher for indirect memory access,

    G. Fu, T. Xia, Z. Luo, R. Chen, W. Zhao, and P. Ren, “Differential- matching prefetcher for indirect memory access,” in2024 IEEE Interna- tional Symposium on High-Performance Computer Architecture (HPCA). IEEE, 2024, pp. 439–453

    2024

  6. [14]

    A new golden age for computer architecture,

    J. L. Hennessy and D. A. Patterson, “A new golden age for computer architecture,”Communications of the ACM, vol. 62, no. 2, pp. 48–60, 2019

    2019

  7. [15]

    1.1 computing’s energy problem (and what we can do about it),

    M. Horowitz, “1.1 computing’s energy problem (and what we can do about it),” in2014 IEEE international solid-state circuits conference digest of technical papers (ISSCC). IEEE, 2014, pp. 10–14

    2014

  8. [16]

    2025, vol

    Intel,Intel 64 and IA-32 Architectures Software Developer’s Manual, Mar. 2025, vol. V olume 3 (3A, 3B, 3C & 3D): System Programming Guide, accessed: 2025-04-13. [Online]. Available: https://www.intel.com/content/dam/www/public/us/en/ documents/manuals/64-ia-32-architectures-so...

    2025

  9. [17]

    Access map pattern matching for data cache prefetch,

    Y . Ishii, M. Inaba, and K. Hiraki, “Access map pattern matching for data cache prefetch,” inProceedings of the 23rd international conference on Supercomputing, 2009, pp. 499–500

    2009

  10. [18]

    Gretch: A hardware prefetcher for graph analytics,

    A. M. Kaushik, G. Pekhimenko, and H. Patel, “Gretch: A hardware prefetcher for graph analytics,”ACM Transactions on Architecture and Code Optimization (TACO), vol. 18, no. 2, pp. 1–25, 2021

    2021

  11. [19]

    Dx100: Programmable data access accelerator for indirection,

    A. Khadem, K. Kamalakkannan, Z. Zhu, A. Poptani, Y . Gu, J. B. Dominguez-Trujillo, N. Talati, D. Fujiki, S. Mahlke, G. Shipmanet al., “Dx100: Programmable data access accelerator for indirection,” in Proceedings of the 52nd Annual International Symposium on Computer Architectu...

    2025

  12. [20]

    Using triangles to im- prove community detection in directed networks,

    C. Klymko, D. Gleich, and T. G. Kolda, “Using triangles to im- prove community detection in directed networks,”arXiv preprint arXiv:1404.5874, 2014

    2014 arXiv

  13. [21]

    Predicting positive and negative links in online social networks,

    J. Leskovec, D. Huttenlocher, and J. Kleinberg, “Predicting positive and negative links in online social networks,” inProceedings of the 19th international conference on World wide web, 2010, pp. 641–650

    2010

  14. [22]

    Signed networks in social media,

    J. Leskovec, D. Huttenlocher, and J. Kleinberg, “Signed networks in social media,” inProceedings of the SIGCHI conference on human factors in computing systems, 2010, pp. 1361–1370

    2010

  15. [23]

    Community structure in large networks: Natural cluster sizes and the absence of large well-defined clusters,

    J. Leskovec, K. J. Lang, A. Dasgupta, and M. W. Mahoney, “Community structure in large networks: Natural cluster sizes and the absence of large well-defined clusters,”Internet Mathematics, vol. 6, no. 1, pp. 29–123, 2009

    2009

  16. [24]

    The gem5 simulator: Version 20.0+,

    J. Lowe-Power, A. M. Ahmad, A. Akram, M. Alian, R. Amslinger, M. Andreozzi, A. Armejach, N. Asmussen, B. Beckmann, S. Bharad- wajet al., “The gem5 simulator: Version 20.0+,”arXiv preprint arXiv:2007.03152, 2020

    2007 arXiv

  17. [25]

    Best-offset hardware prefetching,

    P. Michaud, “Best-offset hardware prefetching,” in2016 IEEE Interna- tional Symposium on High Performance Computer Architecture (HPCA). IEEE, 2016, pp. 469–480

    2016

  18. [26]

    Amd granite ridge

    H. Mujtaba and H. Mujtaba, “Amd granite ridge ”zen 5” ccd gets beautiful & high-res die shots, reveals brand new tsv layout for 3d v-cache cpus,”Wccftech, Oct. 2024. [Online]. Available: https://wccftech.com/amd-zen-5-ccd-beautiful-high-res-die- shots-brand-new-tsv-layout-3d-v...

    2024

  19. [27]

    Vector runahead,

    A. Naithani, S. Ainsworth, T. M. Jones, and L. Eeckhout, “Vector runahead,” in2021 ACM/IEEE 48th Annual International Symposium on Computer Architecture (ISCA). IEEE, 2021, pp. 195–208

    2021

  20. [28]

    Vector runahead for indirect memory accesses,

    A. Naithani, S. Ainsworth, T. M. Jones, and L. Eeckhout, “Vector runahead for indirect memory accesses,”IEEE Micro, vol. 42, no. 4, pp. 116–123, 2022

    2022

  21. [29]

    Decoupled vector runahead,

    A. Naithani, J. Roelandts, S. Ainsworth, T. M. Jones, and L. Eeck- hout, “Decoupled vector runahead,” inProceedings of the 56th Annual IEEE/ACM International Symposium on Microarchitecture, 2023, pp. 17–31

    2023

  22. [30]

    Scalar vector runahead,

    J. Roelandts, A. Naithani, S. Ainsworth, T. M. Jones, and L. Eeckhout, “Scalar vector runahead,” in2024 57th IEEE/ACM International Sym- posium on Microarchitecture (MICRO). IEEE, 2024, pp. 1367–1381

    2024

  23. [31]

    Twitch gamers: a dataset for evaluating proximity preserving and structural role-based node embeddings,

    B. Rozemberczki and R. Sarkar, “Twitch gamers: a dataset for evaluating proximity preserving and structural role-based node embeddings,” 2021

    2021

  24. [32]

    Tsmc n3, and challenges ahead,

    D. Schor, “Tsmc n3, and challenges ahead,” May 2023. [Online]. Available: https://fuse.wikichip.org/news/7375/tsmc-n3-and-challenges- ahead/

    2023

  25. [33]

    Spatial memory streaming,

    S. Somogyi, T. F. Wenisch, A. Ailamaki, B. Falsafi, and A. Moshovos, “Spatial memory streaming,”ACM SIGARCH Computer Architecture News, vol. 34, no. 2, pp. 252–263, 2006

    2006

  26. [34]

    Data analysis in public social networks,

    L. Takac and M. Zabovsky, “Data analysis in public social networks,” in International scientific conference and international workshop present day trends of innovations, vol. 1, no. 6, 2012

    2012

  27. [35]

    Prodigy: Improving the memory latency of data-indirect irregular workloads using hardware- software co-design,

    N. Talati, K. May, A. Behroozi, Y . Yang, K. Kaszyk, C. Vasiladiotis, T. Verma, L. Li, B. Nguyen, J. Sunet al., “Prodigy: Improving the memory latency of data-indirect irregular workloads using hardware- software co-design,” in2021 IEEE International Symposium on High- 12 Perf...

    2021

  28. [36]

    Tyche: An efficient and general prefetcher for indirect memory accesses,

    F. Xue, C. Han, X. Li, J. Wu, T. Zhang, T. Liu, Y . Hao, Z. Du, Q. Guo, and F. Zhang, “Tyche: An efficient and general prefetcher for indirect memory accesses,”ACM Transactions on Architecture and Code Optimization, vol. 21, no. 2, pp. 1–26, 2024

    2024

  29. [37]

    Defining and evaluating network communities based on ground-truth,

    J. Yang and J. Leskovec, “Defining and evaluating network communities based on ground-truth,” inProceedings of the ACM SIGKDD workshop on mining data semantics, 2012, pp. 1–8

    2012

  30. [38]

    Local higher- order graph clustering,

    H. Yin, A. R. Benson, J. Leskovec, and D. F. Gleich, “Local higher- order graph clustering,” inProceedings of the 23rd ACM SIGKDD international conference on knowledge discovery and data mining, 2017, pp. 555–564

    2017

  31. [39]

    Imp: Indirect memory prefetcher,

    X. Yu, C. J. Hughes, N. Satish, and S. Devadas, “Imp: Indirect memory prefetcher,” inProceedings of the 48th International Symposium on Microarchitecture, 2015, pp. 178–190

    2015

  32. [40]

    Accelerating graph analytics using attention-based data prefetcher,

    P. Zhang, R. Kannan, A. V . Nori, and V . K. Prasanna, “Accelerating graph analytics using attention-based data prefetcher,”SN Computer Science, vol. 5, no. 5, p. 646, 2024. 13

    2024

Pith tools

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