Pith. sign in

REVIEW 5 major objections 6 minor 59 references

Swift: A Multi-FPGA Framework for Scaling Up Accelerated Graph Analytics

T0 review · 5 major / 6 minor · reviewed 2026-08-12 · deepseek-v4-flash

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

Pith's one-line read Swift claims that asynchronous interval-level execution of the Gather-Apply-Scatter model lets a multi-FPGA node hide inter-FPGA communication, achieving 12.8x the throughput of ForeGraph and 2.6x the energy efficiency of GPUs.

desk verdict Real multi-FPGA system with a genuinely asynchronous GAS pipeline, but the missing correctness argument for async iteration is the key gap. read the letter →

arxiv 2411.14554 v1 pith:BYGLVKEK submitted 2024-11-21 cs.AR

Oluwole Jaiyeoba , Abdullah T. Mughrabi , Morteza Baradaran , Beenish Gul , Kevin Skadron This is my paper · ORCID
classification cs.AR
keywords graphanalyticsFPGAhighbandwidthmemoryGather-Apply-Scattermulti-FPGAasynchronousexecutionaccelerationPageRank
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

The paper argues that the main barrier to scaling graph analytics across multiple FPGAs is bulk-synchronous execution, where each accelerator waits for the slowest task before the next global step begins. Swift instead runs the Gather-Apply-Scatter (GAS) graph-iteration model at the granularity of small vertex intervals, letting each interval proceed as soon as its own dependencies are met, without waiting for a global barrier. This lets edge processing, update partitioning, and active-frontier communication over PCIe overlap, keeping the FPGAs' high-bandwidth memory and on-chip resources busy. If the claim holds, a node of up to eight FPGAs can scale throughput near-linearly with added hardware, beat previous multi-FPGA frameworks by more than an order of magnitude, and beat GPUs on energy efficiency.

What carries the argument

The central mechanism is the asynchronous, decoupled GAS pipeline operating at vertex-interval granularity. Each interval is an independent unit of work that can be flagged as ready-for-process, ready-for-export, or ready-for-import; five modules (process-edge, partition-updates, apply-updates, export-frontier, import-frontier) continuously check these states and launch work without a global barrier. Partition-updates uses a recursive BRAM tree that repeatedly splits vertex updates into high-locality buckets across HBM passes, with the number of passes logarithmic in the destination-ID range. This interval-level asynchrony is what allows computation (edge processing, partitioning, applying updates) to overlap with communication (import/export frontiers) both within and across FPGAs.

What would settle it

Run PageRank on Swift in both asynchronous and synchronous modes on an irregular graph and compare the final rank vectors: if the asynchronous results differ beyond numerical tolerance, or if asynchronous mode fails to converge on a graph where synchronous mode converges, the claim that Swift computes the same algorithm at higher throughput is broken.

Watch

Extended reading notes

Core claim

Swift's central claim is that a decoupled, asynchronous execution of the edge-centric GAS scheme eliminates the global barriers that force prior multi-FPGA frameworks to wait for the slowest task. The graph is split by destination vertex IDs across FPGAs and further by source vertex IDs into intervals; each interval moves through five pipeline stages—process-edge, partition-updates, apply-updates, export-frontier, and import-frontier—and can start a stage as soon as its dependencies are satisfied. The paper reports a PageRank throughput of 13.2 and 22.4 billion edges per second on 4 and 8 FPGAs, a 12.8x improvement over ForeGraph on the Twitter graph, and a 2.6x energy-efficiency advantage over Gunrock on NVIDIA A40 GPUs.

Load-bearing premise

Running vertex intervals asynchronously must still converge to the same PageRank, SpMV, or HITS results as bulk-synchronous iteration; the paper treats this as a design principle but provides no proof or reference.

Editorial extensions

If this is right

  • If asynchronous interval execution is correct, any bulk-synchronous graph accelerator could adopt the same decoupling and gain a 2-3x throughput improvement by overlapping communication with computation, as Swift's own synchronous-versus-asynchronous comparison shows.
  • A multi-FPGA node can process graphs whose edge count exceeds the capacity of a single FPGA's HBM, because edges are distributed across channels and FPGAs; the paper reports near-linear scaling from 2 to 8 FPGAs.
  • The 2.6x energy-efficiency advantage over GPUs suggests that, for power-limited datacenter workloads, an FPGA-based scale-up node could process a given graph at lower operational cost.
  • With future 32 GB HBM modules, the same framework could hold graphs of over a billion edges per FPGA, extending the scale-up approach into the territory currently requiring scale-out clusters.

Reading between the lines

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

  • The same interval-level asynchronous scheme could be applied to other iterative irregular workloads, such as sparse linear algebra or graph neural network inference, where removing global barriers may yield similar overlap benefits.
  • The NVLink experiment reported in the paper implies that if Swift were given a faster inter-FPGA interconnect, its performance advantage over GPUs could extend from energy efficiency to raw throughput on regular graphs as well.
  • Because the paper benchmarks only PageRank, SpMV, and HITS, the correctness of the asynchronous model is untested for algorithms with global or deterministic ordering constraints; running such algorithms would reveal whether the model generalizes.
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

5 major / 6 minor

Summary. The paper presents Swift, a multi-FPGA graph processing framework built by extending the ACTS edge-centric GAS accelerator. The graph is split by destination vertex IDs across FPGAs and further divided into source-ID intervals; each interval advances through five pipeline stages (process-edge, partition-updates, apply-updates, import-frontier, export-frontier) without a global barrier. The authors report results on four Alveo U280 FPGAs for PageRank, SpMV, and HITS on real and synthetic graphs, compare throughput against Gunrock on four A40 GPUs and against ForeGraph, PowerGraph, and Hadoop, and claim up to 12x/12.8x speedup over ForeGraph, 2-3x benefit from the asynchronous decoupled execution, and roughly 2x better energy efficiency than Gunrock. HITS results on Swift were not obtained because of an out-of-memory error.

Significance. If the asynchronous interval execution is shown to preserve the results of the bulk-synchronous GAS computation, Swift would be a useful contribution: it is a real multi-FPGA scale-up system with HBM, it reports actual on-board measurements and power data, and it provides a concrete mechanism for overlapping inter-FPGA communication with intra-FPGA computation. The paper is also candid about the mixed comparison against Gunrock and about the NVLink bandwidth advantage. The unresolved correctness question, however, makes the central performance claim ambiguous, because the speedup may be measuring a different computation from the baselines. The missing HITS results and incomplete disclosure of baseline and 8-FPGA setups further prevent a reader from confirming the headline numbers.

major comments (5)
  1. [III-C and V.B.1 (Figure 6a)] The asynchronous execution model is not shown to be semantically equivalent to the bulk-synchronous GAS iteration. Section III-C allows an interval to become ready-for-process once its dependencies are met, with no global barrier; because destination vertex properties are updated in place as interval updates are applied, an interval in a later logical iteration can observe vertex values that are partially updated by other intervals. For PageRank this can change the convergence trajectory, and for HITS, whose per-iteration normalization is nonlinear, the reordering can change the final result. The paper provides no proof, no reference to asynchronous fixed-point convergence results, and no correctness validation (for example, comparing final PageRank or HITS values and iteration counts against a reference bulk-synchronous run). Since Section V.B.1 attributes a 2-3x throughput gain (Figure 6a) to the asynchronous mechanism, the authors must either prove convergence for the supported algorithms, cite applicable asynchronous-iteration results, or validate output convergence on all datasets before the speedup claim can be interpreted as a speedup for the same computation.
  2. [Abstract vs. Section V.B.1 and Figure 6c] The abstract claims Swift performs "12.8 times better than the ForeGraph," but the body (Section V.B.1) reports only "up to 12x," and Figure 6c does not give the exact MTEPS values or the measurement conditions behind the ratio. The paper should reconcile these numbers and state precisely the dataset, iteration count, baseline source, and FPGA configuration used for the headline speedup.
  3. [Table I, Section V.A.2, and Table III] Table I reports a Swift 8-FPGA throughput of 22.407 GTEPS, and Table III lists an "4, 8" configuration, but Section V.A.2 states that the implementation was carried out using four Alveo U280 cards, and the flow example in Section III-C uses a four-FPGA cluster. No 8-FPGA experiment is described in the evaluation, and Figure 6b only shows scalability up to four FPGAs. Either provide the 8-FPGA methodology and measurements or remove the 8-FPGA row from Table I and qualify the abstract's "up to 8 FPGAs" claim as a design capacity rather than an evaluated configuration.
  4. [V.A.2 and V.B.1 (Figure 6c)] The comparisons against ForeGraph, PowerGraph, and Hadoop in Figure 6c are not reproducible from the text. Section V.A.2 lists these as baselines but gives no experimental setup (hardware platform, graph preprocessing, iteration counts, or whether the reported numbers are taken from prior publications), and Table I indicates that ForeGraph's published results are simulation-based. If these comparisons are drawn from previously published measurements, the authors should state this explicitly and cite the exact source table or figure for each baseline; if they are new measurements, the setup must be fully described. The 12x claim cannot be evaluated otherwise.
  5. [IV-B vs. V.A.2] Section IV-B states that Swift allows up to 128 Processing Elements in a 4-FPGA cluster, but Section V.A.2 says Vitis was only able to synthesize up to 24 PEs, at 150 MHz. The reported throughput and resource numbers in Table III and Figures 4-6 therefore correspond to an unspecified and likely much smaller number of PEs than the claimed design capacity. The authors must state the exact PE count used in every measurement and clearly separate evaluated configurations from architectural capacity claims.
minor comments (6)
  1. [V.B.1 and Figures 4-5] The text says HITS results on Swift could not be collected due to an out-of-memory error, yet Figure 4 includes a HITS panel and Figure 5 includes a HITS efficiency panel; either report the missing Swift data explicitly in the captions or remove the HITS panels so the plots do not imply results that are absent.
  2. [V.A.2 and Table III] There are numerical inconsistencies in the bandwidth and energy-efficiency numbers: Section V.A.2 says the A40 has 768 GB/s per GPU while Table III lists 3072 GB/s for four cards, and the same section mentions 345 GB/s for the U280, although earlier text and Table III state 460 GB/s; also the abstract says 2.6x energy efficiency while Section V.B.2 says "about 2X." These values should be reconciled.
  3. [V.B.1] The NVLink-off experiment is only reported for PageRank on R8, but the following sentence extrapolates that "with a similar high-speed interconnect, the multi-FPGA system would consistently outperform Gunrock for all our algorithms and datasets." This extrapolation is not supported by the data and should be removed or qualified.
  4. [III-B and IV-A] The paper is inconsistent about whether intervals are defined by source vertex IDs or by destination-vertex ranges: Section III-B says intervals are based on source IDs, while Section IV-A defines vertex intervals by V/NUMPEs in the context of destination-partitioned edges. Clarify the interval definition, since the dependency conditions described in Section III-C depend on it.
  5. [Algorithm 1 and III-C] Algorithm 1 and the flow description do not specify the actual convergence criterion used in the experiments (residual threshold, fixed iteration count, or frontier-emptiness). State the exact termination rule, because asynchronous execution can change the number of iterations and thus the reported runtime.
  6. [Throughout] There are several typos and small inconsistencies: "bulk-synchonous" in the abstract, "interconnet" in Section II-C, "SPMV" in the Figure 5 caption, and references [55] and [56] duplicating [36] and [39]. The sentence in the import/export bullet referring to "Section III" should point to the specific subsection.

Circularity Check

0 steps flagged · score 0.0 of 10

No circularity: Swift's performance claims rest on direct measurements and external baselines; the ACTS self-citation is a transparent starting point, not load-bearing.

full rationale

The paper's central claims are empirical throughput and efficiency measurements from a working multi-FPGA system, benchmarked against its own synchronous ablation and against external systems. The async-vs-synchronous comparison in Figure 6a is an ablation of Swift's own decoupling mechanism, not a fitted parameter renamed as a prediction. Comparisons with ForeGraph, Hadoop, PowerGraph, and Gunrock use either published baseline numbers or the authors' own Gunrock runs on an A40 GPU cluster, so they are externally grounded rather than defined by Swift's own outputs. The only same-author citation is ACTS [34], which Swift explicitly adapts as its open-source starting point; that citation provides the hardware pipeline basis and is not used to prove Swift's performance advantage. The unproven assumption that asynchronous interval execution converges to the same PageRank/HITS fixed point as bulk-synchronous execution (Section III-C) is a correctness or evaluation-validity risk, not a circular derivation: nothing in the paper defines an output in terms of the claimed result, and no equation or fitted value makes the prediction equivalent to its input by construction. No uniqueness theorem, ansatz smuggled through citation, or renaming of a known result as unification is present.

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

Swift reports measured performance and does not fit any continuous parameters to data. The only tunables are design choices such as vertex interval size and the number of processing elements, which are set by hardware capacity rather than fitted to match baselines.

assumptions (3)
  • domain assumption The graph is static: topology is fixed, so partitioning is a one-time pre-processing cost that can be amortized.
    Invoked in Section IV-A as justification for excluding graph loading time and for the partitioning layout.
  • domain assumption Processing vertex intervals asynchronously, without a global barrier, produces correct and convergent results for PR, SpMV, and HITS.
    Assumed in Section III-C and Figure 2; no correctness proof or convergence argument is given.
  • domain assumption Using global vertex IDs across FPGAs avoids translation overhead without affecting workload balance.
    Stated in Section IV-B as a design choice; the paper does not compare against alternatives like vertex renumbering.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Swift: A Multi-FPGA Framework for Scaling Up Accelerated Graph Analytics." pith.science (2026). https://pith.science/paper/BYGLVKEK

@misc{pith2026241114554,
  author       = {Pith},
  title        = {Pith review of: Swift: A Multi-FPGA Framework for Scaling Up Accelerated Graph Analytics},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/BYGLVKEK}},
  note         = {Machine review of arXiv:2411.14554}
}
read the original abstract

Graph analytics are vital in fields such as social networks, biomedical research, and graph neural networks (GNNs). However, traditional CPUs and GPUs struggle with the memory bottlenecks caused by large graph datasets and their fine-grained memory accesses. While specialized graph accelerators address these challenges, they often support only moderate-sized graphs (under 500 million edges). Our paper proposes Swift, a novel scale-up graph accelerator framework that processes large graphs by leveraging the flexibility of FPGA custom datapath and memory resources, and optimizes utilization of high-bandwidth 3D memory (HBM). Swift supports up to 8 FPGAs in a node. Swift introduces a decoupled, asynchronous model based on the Gather-Apply-Scatter (GAS) scheme. It subgraphs across FPGAs, and each subgraph into intervals based on source vertex IDs. Processing on these intervals is decoupled and executed asynchronously, instead of bulk-synchonous operation, where throughput is limited by the slowest task. This enables simultaneous processing within each multi-FPGA node and optimizes the utilization of communication (PCIe), off-chip (HBM), and on-chip BRAM/URAM resources. Swift demonstrates significant performance improvements compared to prior scalable FPGA-based frameworks, performing 12.8 times better than the ForeGraph. Performance against Gunrock on NVIDIA A40 GPUs is mixed, because NVlink gives the GPU system a nearly 5X bandwidth advantage, but the FPGA system nevertheless achieves 2.6x greater energy efficiency.

Figures

Figures reproduced from arXiv: 2411.14554 by the authors.

Figure 1
Figure 1. How Swift (ACTS [34] based pipeline) handles Process Edge, Partition-Updates, and Apply Update operations. [PITH_FULL_IMAGE:figures/full_fig_p003_1.png] view at source ↗
Figure 2
Figure 2. Swift decoupled multi-FPGA graph execution flow compared to prior art - decoupled operations execute asynchronously [PITH_FULL_IMAGE:figures/full_fig_p004_2.png] view at source ↗
Figure 3
Figure 3. Swift framework ensures the graph is partitioned into load-balanced intervals distributed across FPGAs and Processing [PITH_FULL_IMAGE:figures/full_fig_p006_3.png] view at source ↗
Figures from the paper (3 more)
Figure 4
Figure 4. Figure 4: Performance Comparison of Gunrock (GPU) and Swift (FPGA) for PageRank (left), SpMV (middle), and HITS (right) [PITH_FULL_IMAGE:figures/full_fig_p007_4.png]
Figure 5
Figure 5. Figure 5: Efficiency improvement for Swift over Gunrock — PR, SPMV, and HITS. [PITH_FULL_IMAGE:figures/full_fig_p007_5.png]
Figure 6
Figure 6. Figure 6: (a) Swift PageRank (PR) performance improvement (synchronous vs asynchronous) and (b) multi-FPGA scalability. (c) [PITH_FULL_IMAGE:figures/full_fig_p007_6.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

59 extracted references · 46 canonical work pages

  1. [1]

    Introducing the Graph 500,

    J. A. Ang, B. W. Barrett, K. Wheeler, and R. C. Murphy, “Introducing the Graph 500,” 2010

    work page 2010

  2. [2]

    ExtraV: boosting graph processing near storage with a coherent accelerator,

    J. Lee, H. Kim, S. Yoo, K. Choi, H. P. Hofstee, G.-J. Nam, M. R. Nutter, and D. Jamsek, “ExtraV: boosting graph processing near storage with a coherent accelerator,” Aug. 2017. [Online]. Available: https://doi.org/10.14778/3137765.3137776

    work page arXiv 2017

  3. [3]

    Graph 500 | large-scale benchmarks,

    “Graph 500 | large-scale benchmarks,” 2020. [Online]. Available: https://graph500.org/

    work page 2020

  4. [4]

    Distributed GraphLab: a framework for machine learning and data mining in the cloud,

    Y . Low, D. Bickson, J. Gonzalez, C. Guestrin, A. Kyrola, and J. M. Hellerstein, “Distributed GraphLab: a framework for machine learning and data mining in the cloud,” Proceedings of the VLDB Endowment, vol. 5, no. 8, pp. 716–727, Apr. 2012. [Online]. Available: https://dl.acm.org/doi/10.14778/2212351.2212354

    arXiv 2012

  5. [5]

    Graph Neural Networks: A Review of Methods and Applications,

    J. Zhou, G. Cui, Z. Zhang, C. Yang, Z. Liu, L. Wang, C. Li, and M. Sun, “Graph Neural Networks: A Review of Methods and Applications,” arXiv:1812.08434 [cs, stat] , Jul. 2019, arXiv: 1812.08434. [Online]. Available: http://arxiv.org/abs/1812.08434

    arXiv 2019

  6. [6]

    Thinking Like a Vertex: a Survey of Vertex-Centric Frameworks for Distributed Graph Processing

    R. R. McCune, T. Weninger, and G. Madey, “Thinking Like a Vertex: a Survey of Vertex-Centric Frameworks for Distributed Graph Processing,” arXiv:1507.04405 [cs] , Jul. 2015, arXiv: 1507.04405. [Online]. Available: http://arxiv.org/abs/1507.04405

    work page Pith review arXiv 2015

  7. [7]

    Pregel: a system for large-scale graph processing,

    G. Malewicz, M. H. Austern, A. J. Bik, J. C. Dehnert, I. Horn, N. Leiser, and G. Czajkowski, “Pregel: a system for large-scale graph processing,” in Proceedings of the 2010 ACM SIGMOD International Conference on Management of data , ser. SIGMOD ’10. Indianapolis, Indiana, USA: Association for Computing Machinery, Jun. 2010, pp. 135–146. [Online]. Availabl...

    arXiv 2010

  8. [8]

    Towards dataflow-based graph accelerator,

    H. Jin, P. Yao, X. Liao, L. Zheng, and X. Li, “Towards dataflow-based graph accelerator,” in 2017 IEEE 37th International Conference on Distributed Computing Systems (ICDCS) , 2017, pp. 1981–1992

    work page 2017

Show all 59 references
  1. [9]

    GraphLab: a new framework for parallel machine learning,

    Y . Low, J. Gonzalez, A. Kyrola, D. Bickson, C. Guestrin, and J. Heller- stein, “GraphLab: a new framework for parallel machine learning,” in Proceedings of the Twenty-Sixth Conference on Uncertainty in Artificial Intelligence, ser. UAI’10. Arlington, Virginia, USA: AUAI Press...

  2. [10]

    Distributed graphlab: A framework for machine learning and data mining in the cloud,

    Y . Low and Gonzalez, “Distributed graphlab: A framework for machine learning and data mining in the cloud,” Proceedings of the VLDB Endowment, vol. 5, 04 2012

    2012

  3. [11]

    Accelerating PageRank using Partition-Centric Processing,

    K. Lakhotia, R. Kannan, and V . Prasanna, “Accelerating PageRank using Partition-Centric Processing,” arXiv:1709.07122 [cs], Aug. 2018, arXiv: 1709.07122. [Online]. Available: http://arxiv.org/abs/1709.07122

    2018 arXiv

  4. [12]

    Everything you always wanted to know about multicore graph processing but were afraid to ask,

    J. Malicevic, B. Lepers, and W. Zwaenepoel, “Everything you always wanted to know about multicore graph processing but were afraid to ask,” in 2017 USENIX Annual Technical Conference (USENIX ATC 17), 2017, pp. 631–643. [Online]. Available: https://www.usenix.org/ conference/at...

    2017

  5. [13]

    The GAP Benchmark Suite,

    S. Beamer, K. Asanovi ´c, and D. Patterson, “The GAP Benchmark Suite,” arXiv:1508.03619 [cs], May 2017

    2017 arXiv

  6. [14]

    Ligra: a lightweight graph processing framework for shared memory,

    J. Shun and G. E. Blelloch, “Ligra: a lightweight graph processing framework for shared memory,” in Proceedings of the 18th ACM SIGPLAN symposium on Principles and practice of parallel programming, ser. PPoPP ’13. Shenzhen, China: Association for Computing Machinery, Feb. 2013...

    2013

  7. [15]

    GridGraph: Large-Scale Graph Processing on a Single Machine Using 2-Level Hierarchical Partitioning,

    X. Zhu, W. Han, and W. Chen, “GridGraph: Large-Scale Graph Processing on a Single Machine Using 2-Level Hierarchical Partitioning,” in 2015 USENIX Annual Technical Conference (USENIX ATC 15) . USENIX Association, 2015, pp. 375–386. [Online]. Available: https: //www.usenix.org/...

    2015

  8. [16]

    Gunrock: a high-performance graph processing library on the GPU,

    Y . Wang, A. Davidson, Y . Pan, Y . Wu, A. Riffel, and J. D. Owens, “Gunrock: a high-performance graph processing library on the GPU,” in Proceedings of the 21st ACM SIGPLAN Symposium on Principles and Practice of Parallel Programming, ser. PPoPP ’16. Barcelona, Spain: Associa...

    2016

  9. [17]

    GPU-Accelerated Text Mining,

    Y . Zhang, F. Mueller, X. Cui, and T. Potok, “GPU-Accelerated Text Mining,” Mar. 2011. [Online]. Available: https://hgpu.org/?p=3174

    2011

  10. [18]

    CuSha: vertex-centric graph processing on GPUs,

    F. Khorasani, K. V ora, R. Gupta, and L. N. Bhuyan, “CuSha: vertex-centric graph processing on GPUs,” in Proceedings of the 23rd international symposium on High-performance parallel and distributed computing, ser. HPDC ’14. Vancouver, BC, Canada: Association for Computing Mach...

    2014

  11. [19]

    Graph processing on GPUs: Where are the bottlenecks?

    Q. Xu, H. Jeon, and M. Annavaram, “Graph processing on GPUs: Where are the bottlenecks?” in 2014 IEEE International Symposium on Workload Characterization (IISWC), Oct. 2014, pp. 140–149

    2014

  12. [20]

    Locality Exists in Graph Processing: Workload Characterization on an Ivy Bridge Server,

    S. Beamer, K. Asanovic, and D. Patterson, “Locality Exists in Graph Processing: Workload Characterization on an Ivy Bridge Server,” in 2015 IEEE International Symposium on Workload Characterization , Oct. 2015, pp. 56–65

    2015

  13. [21]

    Domain-specialized cache manage- ment for graph analytics,

    P. Faldu, J. Diamond, and B. Grot, “Domain-specialized cache manage- ment for graph analytics,” in 2020 IEEE International Symposium on High Performance Computer Architecture (HPCA) . IEEE, 2020, pp. 234–248

    2020

  14. [22]

    ECG: Expressing Locality and Prefetching for Optimal Caching in Graph Structures

    A. T. Mughrabi, M. Baradaran, A. Samara, and K. Skadron, “ECG: Expressing Locality and Prefetching for Optimal Caching in Graph Structures.” IEEE Computer Society, May 2024, pp. 520–

    2024

  15. [23]

    P-OPT: Practical Optimal Cache Replacement for Graph Analytics,

    V . Balaji, N. Crago, A. Jaleel, and B. Lucia, “P-OPT: Practical Optimal Cache Replacement for Graph Analytics,” in 2021 IEEE International Symposium on High-Performance Computer Architecture (HPCA) , Feb. 2021, pp. 668–681, iSSN: 2378-203X

    2021

  16. [24]

    Analysis and Optimization of the Memory Hierarchy for Graph Processing Workloads,

    A. Basak, S. Li, X. Hu, S. M. Oh, X. Xie, L. Zhao, X. Jiang, and Y . Xie, “Analysis and Optimization of the Memory Hierarchy for Graph Processing Workloads,” in 2019 IEEE International Symposium on High Performance Computer Architecture (HPCA), Feb. 2019, pp. 373–386, iSSN: 2378-203X

    2019

  17. [25]

    Energy consumption analysis of instruction cache prefetching methods,

    M. Baradaran, A. Ansari, M. Sadrosadati, and H. Sarbazi-Azad, “Energy consumption analysis of instruction cache prefetching methods,” in 2023 International Symposium on Computer Architecture and High Performance Computing Workshops (SBAC-PADW), 2023, pp. 60–67

    2023

  18. [26]

    Exploiting HBM on FPGAs for Data Processing,

    R. Shi, K. Kara, C. Hagleitner, D. Diamantopoulos, D. Syrivelis, and G. Alonso, “Exploiting HBM on FPGAs for Data Processing,” ACM Transactions on Reconfigurable Technology and Systems , vol. 15, no. 4, pp. 36:1–36:27, Dec. 2022. [Online]. Available: https://dl.acm.org/doi/10....

    2022 doi

  19. [27]

    Modular and Lean Architecture with Elasticity for Sparse Matrix Vector Multiplication on FPGAs,

    A. K. Jain, C. Ravishankar, H. Omidian, S. Kumar, M. Kulkarni, A. Tripathi, and D. Gaitonde, “Modular and Lean Architecture with Elasticity for Sparse Matrix Vector Multiplication on FPGAs,” in 2023 IEEE 31st Annual International Symposium on Field-Programmable Custom Computin...

    2023

  20. [28]

    Observed Memory Bandwidth and Power Usage on FPGA Platforms with OneAPI and Vitis HLS: A Comparison with GPUs,

    C. M. Siefert, S. L. Olivier, G. R. V oskuilen, and J. S. Young, “Observed Memory Bandwidth and Power Usage on FPGA Platforms with OneAPI and Vitis HLS: A Comparison with GPUs,” in High Performance Computing: ISC High Performance 2023 International Workshops, Hamburg, Germany,...

    2023 doi

  21. [29]

    ReGraph: Scaling Graph Processing on HBM-enabled FPGAs with Heterogeneous Pipelines,

    X. Chen, Y . Chen, F. Cheng, H. Tan, B. He, and W.-F. Wong, “ReGraph: Scaling Graph Processing on HBM-enabled FPGAs with Heterogeneous Pipelines,” in 2022 55th IEEE/ACM International Symposium on Microarchitecture (MICRO), Oct. 2022, pp. 1342–1358. [Online]. Available: https:/...

    2022

  22. [30]

    ScalaBFS2: A High Performance BFS Accelerator on an HBM-enhanced FPGA Chip,

    K. Li, S. Xu, Z. Shao, R. Zheng, X. Liao, and H. Jin, “ScalaBFS2: A High Performance BFS Accelerator on an HBM-enhanced FPGA Chip,” ACM Transactions on Reconfigurable Technology and Systems , Feb. 2024, just Accepted. [Online]. Available: https://dl.acm.org/doi/10.1145/3650037

    2024 doi

  23. [31]

    QPR: Quantizing PageRank with Coherent Shared Memory Accelerators,

    A. T. Mughrabi, M. Ibrahim, and G. T. Byrd, “QPR: Quantizing PageRank with Coherent Shared Memory Accelerators,” in 2021 IEEE International Parallel and Distributed Processing Symposium (IPDPS) , May 2021, pp. 962–972, iSSN: 1530-2075

    2021

  24. [32]

    GraphLily: Accelerating Graph Linear Algebra on HBM-Equipped FPGAs,

    Y . Hu, Y . Du, E. Ustun, and Z. Zhang, “GraphLily: Accelerating Graph Linear Algebra on HBM-Equipped FPGAs,” in 2021 IEEE/ACM International Conference On Computer Aided Design (ICCAD) , Nov. 2021, pp. 1–9, iSSN: 1558-2434. [Online]. Available: https: //ieeexplore.ieee.org/doc...

    2021

  25. [33]

    Hashmem: Pim- based hashmap accelerator,

    A. Shekar, M. Baradaran, S. Tajdari, and K. Skadron, “Hashmem: Pim- based hashmap accelerator,” 2023

    2023

  26. [34]

    ACTS: A Near-Memory FPGA Graph Processing Framework,

    W. Jaiyeoba, N. Elyasi, C. Choi, and K. Skadron, “ACTS: A Near-Memory FPGA Graph Processing Framework,” in Proceedings of the 2023 ACM/SIGDA International Symposium on Field Programmable Gate Arrays , ser. FPGA ’23. New York, NY , USA: Association for Computing Machinery, Feb....

    2023

  27. [35]

    ThunderGP: HLS-based Graph Processing Framework on FPGAs,

    X. Chen, H. Tan, Y . Chen, B. He, W.-F. Wong, and D. Chen, “ThunderGP: HLS-based Graph Processing Framework on FPGAs,” in The 2021 ACM/SIGDA International Symposium on Field-Programmable Gate Arrays , ser. FPGA ’21. New York, NY , USA: Association for Computing Machinery, Feb....

    2021

  28. [37]

    GraVF-M: Graph Processing System Generation for Multi-FPGA Platforms,

    N. Engelhardt and H. K.-H. So, “GraVF-M: Graph Processing System Generation for Multi-FPGA Platforms,” ACM Transactions on Reconfigurable Technology and Systems , vol. 12, no. 4, pp. 21:1–21:28, Nov. 2019. [Online]. Available: https://dl.acm.org/doi/10.1145/3357596

    2019 doi

  29. [38]

    GridGAS: An I/O-Efficient Heterogeneous FPGA+CPU Computing Platform for Very Large-Scale Graph Analytics,

    Y . Zou and M. Lin, “GridGAS: An I/O-Efficient Heterogeneous FPGA+CPU Computing Platform for Very Large-Scale Graph Analytics,” in 2018 International Conference on Field-Programmable Technology (FPT) , Dec. 2018, pp. 246–249. [Online]. Available: https://ieeexplore.ieee.org/ab...

    2018

  30. [39]

    FDGLib: A Communication Library for Efficient Large-Scale Graph Processing in FPGA-Accelerated Data Centers,

    Y .-W. Wu, Q.-G. Wang, L. Zheng, X.-F. Liao, H. Jin, W.-B. Jiang, R. Zheng, and K. Hu, “FDGLib: A Communication Library for Efficient Large-Scale Graph Processing in FPGA-Accelerated Data Centers,” Journal of Computer Science and Technology , vol. 36, no. 5, pp. 1051–1070, Oct...

    2021 doi

  31. [40]

    Distributed large-scale graph processing on FPGAs,

    A. Sahebi, M. Barbone, M. Procaccini, W. Luk, G. Gaydadjiev, and R. Giorgi, “Distributed large-scale graph processing on FPGAs,” Journal of Big Data , vol. 10, no. 1, p. 95, Jun. 2023. [Online]. Available: https://doi.org/10.1186/s40537-023-00756-x

    2023 doi

  32. [41]

    LightGraph: Lighten Communication in Distributed Graph-Parallel Processing,

    Y . Zhao, K. Yoshigoe, M. Xie, S. Zhou, R. Seker, and J. Bian, “LightGraph: Lighten Communication in Distributed Graph-Parallel Processing,” in 2014 IEEE International Congress on Big Data , Jun. 2014, pp. 717–724, iSSN: 2379-7703. [Online]. Available: https://ieeexplore.ieee....

    2014

  33. [42]

    The future of fpga acceleration in datacenters and the cloud,

    C. Bobda, J. M. Mbongue, P. Chow, M. Ewais, N. Tarafdar, J. C. Vega, K. Eguro, D. Koch, S. Handagala, M. Leeser, M. Herbordt, H. Shahzad, P. Hofste, B. Ringlein, J. Szefer, A. Sanaullah, and R. Tessier, “The future of fpga acceleration in datacenters and the cloud,” ACM Trans....

    2022 doi

  34. [43]

    Scale up or scale out for graph processing?

    J. Lin, “Scale up or scale out for graph processing?” IEEE Internet Computing, vol. 22, no. 3, pp. 72–78, 2018

    2018

  35. [44]

    Tegra – scaling up terascale graph processing with disaggregated computing,

    W. Shaddix, M. Samani, M. Fariborz, S. J. B. Yoo, J. Lowe- Power, and V . Akella, “Tegra – scaling up terascale graph processing with disaggregated computing,” 2024. [Online]. Available: https://arxiv.org/abs/2404.03155

    2024 arXiv

  36. [45]

    PowerGraph: Distributed Graph-Parallel Computation on Natural Graphs,

    J. E. Gonzalez, Y . Low, H. Gu, D. Bickson, and C. Guestrin, “PowerGraph: Distributed Graph-Parallel Computation on Natural Graphs,” 2012, pp. 17–30. [Online]. Available: https://www.usenix.org/ conference/osdi12/technical-sessions/presentation/gonzalez

    2012

  37. [46]

    GraphX: Graph Processing in a Distributed Dataflow Framework,

    J. E. Gonzalez, R. S. Xin, A. Dave, D. Crankshaw, M. J. Franklin, and I. Stoica, “GraphX: Graph Processing in a Distributed Dataflow Framework,” in 11th USENIX Symposium on Operating Systems Design and Implementation (OSDI 14) , 2014, pp. 599–613. [Online]. Available: https://...

    2014

  38. [47]

    X-Stream: edge- centric graph processing using streaming partitions,

    A. Roy, I. Mihailovic, and W. Zwaenepoel, “X-Stream: edge- centric graph processing using streaming partitions,” in Proceedings of the Twenty-Fourth ACM Symposium on Operating Systems Principles, ser. SOSP ’13. Farminton, Pennsylvania: Association for Computing Machinery, Nov....

    2013

  39. [48]

    “giraph: Large-scale graph processing infrastructure on hadoop,

    A. C, ““giraph: Large-scale graph processing infrastructure on hadoop,” 2011

    2011

  40. [49]

    GraphMat: High performance graph analytics made productive,

    N. Sundaram, N. R. Satish, M. M. A. Patwary, S. R. Dulloor, S. G. Vadlamudi, D. Das, and P. Dubey, “GraphMat: High performance graph analytics made productive,” Mar. 2015. [Online]. Available: https://arxiv.org/abs/1503.07241v1

    2015 arXiv

  41. [50]

    GraphGen: An FPGA Framework for Vertex- Centric Graph Computation,

    E. Nurvitadhi, G. Weisz, Y . Wang, S. Hurkat, M. Nguyen, J. C. Hoe, J. F. Mart´ınez, and C. Guestrin, “GraphGen: An FPGA Framework for Vertex- Centric Graph Computation,” in 2014 IEEE 22nd Annual International Symposium on Field-Programmable Custom Computing Machines , May 201...

    2014

  42. [51]

    HitGraph: High-throughput Graph Processing Framework on FPGA,

    S. Zhou, R. Kannan, V . K. Prasanna, G. Seetharaman, and Q. Wu, “HitGraph: High-throughput Graph Processing Framework on FPGA,” IEEE Transactions on Parallel and Distributed Systems , vol. 30, no. 10, pp. 2249–2264, Oct. 2019, conference Name: IEEE Transactions on Parallel and...

    2019

  43. [52]

    Graphicionado: A high-performance and energy-efficient accelerator for graph analytics,

    T. J. Ham, L. Wu, N. Sundaram, N. Satish, and M. Martonosi, “Graphicionado: A high-performance and energy-efficient accelerator for graph analytics,” in 2016 49th Annual IEEE/ACM International Symposium on Microarchitecture (MICRO) , Oct. 2016, pp. 1–13. [Online]. Available: h...

    2016

  44. [53]

    High-Throughput and Energy-Efficient Graph Processing on FPGA,

    S. Zhou, C. Chelmis, and V . K. Prasanna, “High-Throughput and Energy-Efficient Graph Processing on FPGA,” in 2016 IEEE 24th Annual International Symposium on Field-Programmable Custom Computing Machines (FCCM) , May 2016, pp. 103–110. [Online]. Available: https://ieeexplore.i...

    2016

  45. [54]

    Vitis Unified Software Development Platform 2023.1 Documentation • Vitis Tutorials: AI Engine (XD100) • Reader • AMD Technical Information Portal

    “Vitis Unified Software Development Platform 2023.1 Documentation • Vitis Tutorials: AI Engine (XD100) • Reader • AMD Technical Information Portal.” [Online]. Available: https://docs.amd.com/r/2023.1-English/Vitis-Tutorials-AI-Engine- Development/Vitis-Unified-Software-Develop...

    2023

  46. [55]

    Foregraph: Exploring large-scale graph processing on multi-fpga architecture,

    G. Dai, T. Huang, Y . Chi, N. Xu, Y . Wang, and H. Yang, “Foregraph: Exploring large-scale graph processing on multi-fpga architecture,” in Proceedings of the 2017 ACM/SIGDA International Symposium on Field-Programmable Gate Arrays, ser. FPGA ’17. New York, NY , USA: Associati...

    2017

  47. [56]

    Fdglib: A communication library for efficient large-scale graph processing in fpga-accelerated data centers,

    Y .-W. Wu, Q. Wang, L. Zheng, X. Liao, H. Jin, W. Jiang, R. Zheng, and K. Hu, “Fdglib: A communication library for efficient large-scale graph processing in fpga-accelerated data centers,” Journal of Computer Science and Technology, vol. 36, pp. 1051 – 1070, 2021

    2021

  48. [57]

    NVIDIA System Management Interface

    “NVIDIA System Management Interface.” [Online]. Available: https: //developer.nvidia.com/nvidia-system-management-interface

  49. [58]

    RMAT generator library,

    S.-W. J. et al, “RMAT generator library,” 06 2018. [Online]. Available: https://github.com/sangwoojun/sortreduce/tree/ master/examples/graph/utils

    2018

  50. [59]

    The university of florida sparse matrix collection,

    T. Davis and Y . Hu, “The university of florida sparse matrix collection,” ACM Trans. Math. Softw. , vol. 38, p. 1, 11 2011

    2011

  51. [525]

    Available: https://www.computer.org/csdl/proceedings- article/ipdpsw/2024/646000a520/1YTstNCnXCo

    [Online]. Available: https://www.computer.org/csdl/proceedings- article/ipdpsw/2024/646000a520/1YTstNCnXCo

    2024

Pith tools

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