{"id":"89ba65b4-c4f7-4e15-88e2-5732d2a4d08e","arxiv_id":"2411.14554","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":6.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":0,"one_line_summary":"Swift uses a decoupled, asynchronous Gather-Apply-Scatter pipeline to scale graph analytics across multiple FPGAs in one node, reporting up to 12x speedup over the ForeGraph framework and 2.6x better energy efficiency than Gunrock on A40 GPUs.","lead":"Swift is a framework for running large graph algorithms across multiple FPGAs in a single machine. It hides the slow communication between FPGAs by overlapping computation and data transfer, and the authors report better throughput and energy efficiency than earlier FPGA systems on several benchmarks.","discovery_kind":"new_method","skeptic_critique":{"model":"deepseek-v4-flash","headline":"Unproven async equivalence is the load-bearing gap: Section III-C's per-interval scheduling can change PageRank/HITS results, making Swift's 2-3x speedup a comparison of different computations.","rationale":"The reader's weakest_assumption identifies the most load-bearing point: Swift's novel mechanism is asynchronous GAS, and Section V.B.1 attributes 2-3x throughput to it. That comparison licenses a performance claim only if both modes compute the same algorithm. Section III-C describes scheduling but never gives conditions under which chaotic interval execution converges, nor does the evaluation validate final vectors against Gunrock or a reference. This matters specifically because edge-centric GAS with in-place vertex updates is not order-insensitive: partition/apply stages can read destination properties that are stale or partially updated, and HITS's normalization makes it nonlinear. The 12.8x versus 12x discrepancy and the missing 8-FPGA configuration are real reporting problems, but they are correctable without changing the architecture; a semantic output mismatch would invalidate the main contribution. A direct head-to-head output comparison between Swift async, Swift synchronous, and a reference implementation would settle the question. Since the reader already flagged this assumption and made the verdict conditional, the stress-test does not change the verdict.","tokens_in":15261,"tokens_out":7956,"duration_ms":78629,"concrete_test":"Run Swift's HLS implementation (or its simulation) on IND, TW, SK, and RMAT8 for PageRank and HITS in both the default asynchronous mode and the bulk-synchronous mode used for Figure 6a, with identical convergence criteria (same fixed iteration count or same active-frontier threshold). Save the final vertex property vectors and compute the maximum L1 or max-relative difference against a trusted reference (e.g., Gunrock on CPU/GPU or a Python implementation). If any relative difference exceeds the algorithm's convergence tolerance on any dataset, the async model is not computing the same result as the synchronous baseline, and the claimed throughput advantage is not for the same computation.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The paper's central contribution is the decoupled asynchronous GAS model, and Section V.B.1 attributes a 2-3x throughput improvement to it. Section III-C defines interval states and lets each interval start its next operation once dependencies are met, with no global barrier. The paper never proves or cites a theorem that such chaotic interval execution converges to the same fixed point as the bulk-synchronous GAS iteration used by the baselines. For edge-centric PageRank and HITS, destination vertex properties are updated in place as partitioned updates are applied; without a barrier, an interval can read a property that is stale, partially updated, or updated more than once per logical iteration. HITS's per-iteration normalization is nonlinear, so reordering can change the result. SpMV is less affected, but PR/HITS results could be a different computation. The missing HITS results and the absence of any correctness validation make this gap untested. If the async mode changes outputs on any dataset, the 2-3x improvement in Figure 6a and the ForeGraph/Gunrock comparisons are not measuring the same algorithm.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","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.","tokens_in":15423,"tokens_out":9440,"duration_ms":88422,"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":[{"comment":"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.","section":"III-C and V.B.1 (Figure 6a)"},{"comment":"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.","section":"Abstract vs. Section V.B.1 and Figure 6c"},{"comment":"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.","section":"Table I, Section V.A.2, and Table III"},{"comment":"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.","section":"V.A.2 and V.B.1 (Figure 6c)"},{"comment":"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.","section":"IV-B vs. V.A.2"}],"minor_comments":[{"comment":"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.","section":"V.B.1 and Figures 4-5"},{"comment":"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.","section":"V.A.2 and Table III"},{"comment":"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.","section":"V.B.1"},{"comment":"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.","section":"III-B and IV-A"},{"comment":"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.","section":"Algorithm 1 and III-C"},{"comment":"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.","section":"Throughout"}],"recommendation":"major_revision","confidential_remarks":"The paper builds directly on the authors' prior ACTS work, so the incremental contribution is the decoupled multi-FPGA execution layer. The main barriers to publication are the missing semantic-equivalence evidence for the asynchronous mode, the incomplete experimental disclosure for the 8-FPGA configuration and external baselines, and the mismatch between stated PE capacity and what was synthesized. These issues are fixable in a revision, so I recommend major revision rather than rejection."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Swift is a real multi-FPGA graph processing system built on the authors' earlier ACTS work, and the genuinely new piece is the decoupled asynchronous GAS pipeline: vertex intervals move through process-edge, partition-updates, apply-updates, and frontier import/export independently, with no global barrier. That is a sensible way to hide PCIe latency, and the paper's own synchronous-vs-asynchronous comparison shows a 2-3x throughput gain. The measurements are on actual Alveo U280 hardware and include energy efficiency versus Gunrock on A40s. Credit where due: this is the first place I know of that demonstrates interval-level state machines for decoupled graph execution on multi-FPGA, and the system description is detailed enough to be reconstructed.\n\nThe main soft spot is exactly the one you'd expect. Relaxing bulk synchronization changes the iteration order for PageRank and HITS, and the paper gives no proof or empirical validation that the asynchronous execution converges to the same result as the bulk-synchronous baseline. HITS results are absent because of an out-of-memory error, so the algorithm most sensitive to reordering is untested. For linear iterations like PageRank, chaotic asynchronous iteration can converge under conditions, but the paper needs to state those conditions or at least compare final scores against a synchronous run. Until that is shown, the central 2-3x speedup claim may be comparing two different computations. That is a load-bearing gap, not a cosmetic one.\n\nThere are also smaller inconsistencies. The abstract says 12.8x over ForeGraph; the body Figure 6c says up to 12x. The abstract says 2.6x energy efficiency; the body says about 2x. Table I and Figure 6 include an 8-FPGA configuration, but the methods section says the full implementation was carried out on four cards. Also, no artifacts are released, and some baseline numbers come from simulations (ForeGraph), which makes the comparison less direct. None of these individually sink the paper, but together they need cleaning up. One confusing detail: the architecture describes up to 128 PEs across four FPGAs, but the tools could only synthesize 24 PEs; the paper should clarify what configuration produced the reported numbers.\n\nAll of this is addressable. The hardware results are real and the idea is worth a serious referee. I'd send this to review with a request for a correctness argument or validation for the async execution, and for consistent reporting. Reading group: maybe, mostly to discuss whether asynchronous GAS is worth the verification burden.","headline":"Real multi-FPGA system with a genuinely asynchronous GAS pipeline, but the missing correctness argument for async iteration is the key gap.","tokens_in":16000,"tokens_out":3158,"would_cite":true,"duration_ms":29610,"reading_group":"maybe","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"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.","keywords":["graph analytics","FPGA","high bandwidth memory","Gather-Apply-Scatter","multi-FPGA","asynchronous execution","graph acceleration","PageRank"],"falsifier":"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.","tokens_in":15030,"feed_emoji":"⚡","tokens_out":10458,"duration_ms":85430,"temperature":0.7,"pith_summary":"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.","feed_headline":"Asynchronous GAS lets multi-FPGA nodes run graphs 12.8x faster","feed_subtitle":"Decoupled execution hides PCIe latency, beating GPUs on energy efficiency by 2.6x.","key_machinery":"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.","core_discovery":"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.","pith_inferences":["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."],"forward_implications":["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."],"supporting_citations":[{"why":"The single-FPGA graph accelerator that Swift extends; it supplies the process-edge and partition-updates stages that Swift decouples and makes asynchronous.","marker":"[34]"},{"why":"The prior multi-FPGA framework that supplies the main performance baseline; the paper's headline 12.8x throughput improvement is measured against it.","marker":"[36]"},{"why":"Defines the edge-centric Gather-Apply-Scatter model with streaming partitions that Swift's interval-based execution is built on.","marker":"[47]"},{"why":"The open-source GPU graph processing library used as the energy-efficiency and throughput baseline; the 2.6x energy claim is against this system.","marker":"[16]"}],"fun_headline_variants":["Async GAS on multi-FPGA nodes boosts graph speed 12.8x","Decoupled async graph processing on FPGAs beats GPUs 2.6x energy","Multi-FPGA framework runs huge graphs with async GAS, 12.8x faster","Swift uses async GAS to scale graph analytics across 8 FPGAs"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"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.","fun_headline_variants_meta":{"raw":{"variants":["Async GAS on multi-FPGA nodes boosts graph speed 12.8x","Decoupled async graph processing on FPGAs beats GPUs 2.6x energy","Multi-FPGA framework runs huge graphs with async GAS, 12.8x faster","Swift uses async GAS to scale graph analytics across 8 FPGAs"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000512,"raw_usage":{"total_tokens":2516,"prompt_tokens":996,"completion_tokens":1520,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":612,"completion_tokens_details":{"reasoning_tokens":1428}},"tokens_in":612,"tokens_out":1520,"duration_ms":10837,"temperature":1.0,"reasoning_tokens":1428,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-12T15:08:14.470433+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"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.","supporting_citations":[],"review_version":1}