{"id":"d999df51-9fcb-48c5-ae3b-0a4129833f0a","arxiv_id":"2501.19004","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":4.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":9,"one_line_summary":"A tuned multicore CPU implementation of Louvain is claimed to beat leading CPU and GPU implementations on billion-edge graphs, with a GPU version only matching it.","lead":"GVE-Louvain is a fast multicore CPU implementation of the Louvain community detection algorithm, and the report also builds a GPU version called ν-Louvain. On graphs with up to 3.8 billion edges, the CPU code is reported to run several times faster than NVIDIA's cuGraph GPU implementation, suggesting that CPUs may be a better hardware choice for this workload.","discovery_kind":"extension","skeptic_critique":{"model":"deepseek-v4-flash","headline":"Abstract/Table 1 claim 5.8x vs cuGraph, but Section 5.2.1, Figure 11(b), and the conclusion all report 3.2x; the headline speedup is internally inconsistent.","rationale":"The reader's weakest assumption is parameter overfitting on the evaluation set, which is a legitimate generalizability concern. My stress-test identified a more direct and load-bearing issue: the headline speedup for cuGraph is internally inconsistent (5.8x in the abstract/Table 1 versus 3.2x in Section 5.2.1, Figure 11(b), and the conclusion). This discrepancy is concrete, verifiable from the paper itself, and undermines the central performance claim without requiring speculation about tuning. The paper otherwise has strengths: detailed pseudocode, public datasets, multiple baselines, and honest notes about modularity loss and out-of-memory exclusions. The reader's CONDITIONAL verdict remains appropriate because the discrepancy can plausibly be resolved by correction or clarification, but until then the headline numbers should not be treated as established. I agree with the reader that the parameter-overfitting risk matters, but the numeric inconsistency is the single most load-bearing concern for the central claim, so my agreement is partial.","tokens_in":27607,"tokens_out":4577,"duration_ms":38202,"concrete_test":"Extract the per-graph speedups for cuGraph from the data behind Figure 11(b) and recompute the average over exactly the graphs where cuGraph succeeds, using both arithmetic and geometric means; check which, if either, equals 3.2x or 5.8x. Also attempt to run cuGraph on the five out-of-memory graphs to see how the average changes when they are included. If the 5.8x cannot be reproduced, the abstract/Table 1 numbers must be corrected or a precise methodology (graph subset, averaging scheme) must be supplied.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The paper's central quantitative claim is the set of speedups in the abstract and Table 1: 50x, 22x, 20x, and 5.8x over Vite, Grappolo, NetworKit, and cuGraph. However, Section 5.2.1 states 'on average 50x, 22x, 20x, and 3.2x faster' and Figure 11(b) is labeled with average speedups matching 3.2x; the conclusion repeats 3.2x. No explanation is given for the abstract's 5.8x. The averaging methodology is not specified (arithmetic vs geometric, which graphs are included), and cuGraph only runs on 8 of 13 graphs because of out-of-memory failures on arabic-2005, uk-2005, webbase-2001, it-2004, and sk-2005. Thus the headline 'CPU better suited' claim rests on a number that the paper itself contradicts, making the reported advantage impossible to verify as stated. This is a correctness risk, not merely a presentation issue, because the central contribution is a performance comparison.","agreement_with_reader":"partial"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper presents two Louvain implementations: GVE-Louvain, a multicore OpenMP code, and ν-Louvain, a CUDA GPU code. The headline claim is that GVE-Louvain is the fastest or one of the fastest Louvain implementations: the abstract and Table 1 report speedups of 50×, 22×, 20×, and 5.8× over Vite, Grappolo, NetworKit, and cuGraph, with a processing rate of 560M edges/s on the 3.8B-edge sk-2005 graph, while Section 5.2.1 and the Conclusion report 3.2× instead of 5.8× for cuGraph. ν-Louvain is reported to be only on par with GVE-Louvain (1.03× speedup), which is taken to suggest that CPUs may be better suited for community detection. The evaluation uses 13 SuiteSparse graphs, includes phase/pass breakdowns, and reports strong scaling.","tokens_in":27896,"tokens_out":6539,"duration_ms":56578,"significance":"If correct, GVE-Louvain would be a leading practical multicore Louvain implementation, and the comparison would be a useful data point against the common assumption that GPUs dominate graph analytics. The paper provides detailed pseudocode (Algorithms 1–7), public repository links, and per-graph runtime/modularity figures, which are concrete strengths. The analysis of phase-level bottlenecks and the observation that later Louvain passes are poorly parallelized on the GPU are useful and likely to transfer to other Louvain implementations. However, the central quantitative claims currently rest on an internally inconsistent headline number, a parameter-selection protocol that uses the same graphs later used for evaluation, and a one-implementation-per-architecture comparison. These issues are close enough to the paper's main message that they must be fixed before the results can be taken at face value.","major_comments":[{"comment":"The cuGraph speedup is internally inconsistent: the abstract and Table 1 report 5.8×, while §5.2.1, Figure 11(b), and the Conclusion report 3.2×. No explanation or reconciliation is given, and the averaging method (arithmetic vs. geometric mean, and which graphs are included) is not specified. Because this number is part of the central CPU-versus-GPU claim, the paper as written cannot be verified. The speedup should be recomputed, the averaging rule stated, and the abstract/table aligned with the body. The comparison is also incomplete: cuGraph fails with out-of-memory on arabic-2005, uk-2005, webbase-2001, it-2004, and sk-2005, so the average is computed only over the remaining 8 graphs.","section":"Abstract, Table 1, §5.2.1, Fig. 11(b), Conclusion"},{"comment":"The parameter settings that drive the headline results are tuned and evaluated on the same graphs. Section 4.1 (OpenMP schedule, maximum iterations, tolerance drop, initial tolerance, aggregation tolerance) and Section 4.3 (switch degrees, Pick-Less step, probing strategy, hashtable value type) describe experiments performed on 'large graphs from Table 2', and the final speedups in Section 5.2 are then reported on those same Table 2 graphs. There is no held-out set, no cross-validation, and no sensitivity analysis for the chosen values. If the selected settings are overfit to these 13 inputs, the reported speedups and the CPU/GPU conclusion will not transfer to new graphs. Please add a validation protocol (for example, tuning on a subset and testing on a disjoint subset) or demonstrate robustness of the conclusions to parameter perturbations.","section":"§4.1, §4.3, Table 2, §5.2"},{"comment":"The architectural conclusion is drawn from a lopsided comparison. cuGraph Louvain cannot run on the five largest web graphs, so on exactly those graphs where GVE-Louvain looks best (e.g., 560M edges/s on sk-2005) there is no GPU baseline at all. In addition, the statement that CPUs 'may be better suited for community detection' is based primarily on GVE-Louvain versus ν-Louvain, two implementations by the same author, plus cuGraph and Nido, both of which also fail or underperform on the largest graphs. Implementation maturity and engineering effort are not controlled across platforms. The data support a claim about these particular implementations, not about CPU and GPU architectures generally. Please limit the conclusion accordingly or broaden the baseline set.","section":"§5.2.1, §5.2.3, Fig. 11, Fig. 13"},{"comment":"The 'on par' characterization of ν-Louvain is not adequately qualified. The average speedup over GVE-Louvain is only 1.03×, with per-graph values ranging from 0.6× to 7.1×, and on kmer_V1r the modularity falls from 0.9437 (GVE-Louvain) to 0.8722 (ν-Louvain) — a substantial quality loss that is acknowledged in §5.2.2 but omitted from the unqualified 'on par' statement in the abstract and conclusion. Please report confidence intervals and per-graph quality differences, and state explicitly that 'on par' refers only to runtime and only on the graphs where the comparison was possible.","section":"§5.2.3, §5.3.2, Conclusion"}],"minor_comments":[{"comment":"The text says 'Nido (Louvain) [45]', but reference [45] is the author's GVE-Louvain report; the Nido paper is reference [10]. This appears to be a citation error and should be fixed.","section":"§5.2.2"},{"comment":"The sentence 'we adopt a thread-per-vertex approach how low-degree vertices [63]' appears to be missing a word (likely 'for') and is not grammatical.","section":"§4.3.4"},{"comment":"The description '1 MB L1 cache per core' is not plausible for the Intel Xeon Gold 6226R; please verify the cache hierarchy details (the Gold 6226R has 32 KB L1 data and 32 KB L1 instruction per core).","section":"§5.1.1"},{"comment":"The text provides average speedups '50×, 22×, 20×, and 3.2×' without stating the mean type or the graph subset used for the average; a small table with per-graph ratios and the averaging method would make the results reproducible.","section":"§5.2.1"},{"comment":"The Conclusion states that GVE-Louvain is 'the most efficient implementation on multicore CPUs', which is stronger than the Abstract's 'one of the most efficient'; given that only four baselines are compared, the stronger claim is not supported. Please use the qualified phrasing.","section":"Conclusion"},{"comment":"The text says each measurement was repeated five times, but no error bars or variance information is shown. Adding standard deviations or equivalent would help the reader judge whether the 1–13% differences used for parameter choices are meaningful.","section":"Figures 2, 5, 7–13"}],"recommendation":"major_revision","confidential_remarks":"The manuscript is essentially a performance study built on the author's prior GVE-Louvain and ν-LPA work, with the main incremental contribution being the systematic comparison and the CPU/GPU conclusion. The apparent citation error for Nido ([45] instead of [10]) should be checked; I do not see evidence of deliberate citation manipulation, but the paper's self-citations are heavy and the novelty relative to [45] and [46] should be made explicit. The most serious correctness issues are the 5.8× / 3.2× inconsistency and the absence of any held-out evaluation after parameter tuning. Both are fixable within the scope of a revision, which is why I recommend major revision rather than rejection."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Short version: this is a useful engineering report—the nu-Louvain GPU implementation is genuinely new, with sensible design choices and detailed pseudocode—but the central speedup claim is internally inconsistent (5.8x in the abstract and Table 1, 3.2x in Section 5.2.1, Figure 11(b), and the conclusion), and the paper tunes parameters on the same graphs it evaluates on. Both need to be fixed before the headline numbers are usable.\n\nWhat is actually new: GVE-Louvain overlaps the author's earlier report [45], but nu-Louvain is a new GPU implementation with per-vertex open-addressing hashtables sized by degree, hybrid quadratic-double probing, and a Pick-Less mode to break community swaps. The pseudocode is detailed enough to reimplement, the datasets are public SuiteSparse graphs, and the comparison covers five baselines with modularity plus runtime. The paper also gives phase-wise and pass-wise breakdowns and honest notes about modularity loss and out-of-memory failures. That is real work, and the engineering choices are worth studying.\n\nWhere it gets shaky. The abstract and Table 1 promise 5.8x over cuGraph; Section 5.2.1, Figure 11(b), and the conclusion all say 3.2x. No explanation is offered. Since the central message is that CPUs are competitive or better for Louvain, this inconsistency directly undermines the headline. Second, the parameter settings in Sections 4.1 and 4.3 (schedule, tolerances, switch degrees, Pick-Less step) are chosen by running on \"large graphs from Table 2\" and then the same graphs are used to report final speedups. There is no held-out set, so overfitting to these 13 graphs is a real possibility. Third, no error bars are given despite five runs, and the averaging methodology is under-specified (arithmetic vs geometric; which graphs are included). cuGraph fails on 5 of 13 graphs due to OOM; those exclusions shape the averages but are not analyzed.\n\nThe CPU-vs-GPU conclusion is plausible but not established. GVE-Louvain and nu-Louvain are both by the same author; one implementation pair is a weak basis for a hardware-level claim. That said, this is a legitimate, detailed engineering data point, not a toy.\n\nWho it is for: anyone working on parallel Louvain implementations or choosing hardware for graph analytics will get value from the implementation details and the benchmark methodology, once the discrepancy is fixed. I would send it to a serious referee; it deserves engagement, but with a request to correct the inconsistent numbers, specify the averaging, and either add held-out tuning or report sensitivity to the chosen parameters.","headline":"Useful engineering report with a new GPU Louvain and detailed pseudocode, but the central speedup claim is internally inconsistent (5.8x vs 3.2x) and the tuning is not held out.","tokens_in":28430,"tokens_out":2938,"would_cite":true,"duration_ms":27016,"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":"GVE-Louvain, a multicore CPU implementation of the Louvain algorithm, outperforms established CPU and GPU implementations by 20–50×, reaching 560M edges/s on a 3.8-billion-edge graph.","keywords":["community detection","Louvain algorithm","modularity optimization","multicore CPU","GPU benchmarking","parallel graph algorithms","hash tables","super-vertex aggregation"],"falsifier":"Run GVE-Louvain on a graph not in Table 2 using the exact published parameters, and compare against cuGraph Louvain (with RMM pool) and Grappolo on the same hardware; if the speedup over cuGraph falls far below the reported 3.2–5.8×, or the 560M edges/s rate is not reproducible on sk-2005 with the stated hardware, the general claim would be falsified.","tokens_in":27345,"feed_emoji":"⚡","tokens_out":6266,"duration_ms":55924,"temperature":0.7,"pith_summary":"This report argues that a carefully engineered multicore CPU implementation of the Louvain community-detection algorithm can beat established CPU and GPU implementations, including one running on an NVIDIA A100. The author presents GVE-Louvain, which they report as 50×, 22×, 20×, and 5.8× faster than Vite, Grappolo, NetworKit Louvain, and cuGraph Louvain, respectively, and 560M edges/s on the 3.8B-edge sk-2005 graph. The same optimizations were ported to a GPU implementation, ν-Louvain, which performed only on par with the CPU version, with the author attributing this to reduced parallelism in later passes. The larger claim is that CPUs, with their flexibility on irregular workloads, may be better suited for community detection than GPUs.","feed_headline":"CPU Louvain beats A100 GPU Louvain, hitting 560M edges/s","feed_subtitle":"A 32-core implementation outruns Vite, Grappolo, NetworKit, cuGraph; the GPU port only ties it.","key_machinery":"The key mechanism is the pair of per-thread collision-free hash tables (a keys list with a full-size values array, placed far apart in memory to avoid false sharing) used in GVE-Louvain's local-moving and aggregation phases, combined with preallocated CSR data structures and parallel prefix sums to build the super-vertex graph without repeated allocation. On the GPU side, the machinery is per-vertex open-addressing hash tables sized to twice the degree, using a hybrid quadratic-double probing scheme and a Pick-Less rule that breaks symmetric community-swap cycles. Both implementations use asynchronous parallel vertex moves, vertex pruning, a 20-iteration cap per pass, threshold scaling with drop rate 10, and an aggregation tolerance of 0.8.","core_discovery":"The paper's central claim is that the Louvain algorithm's performance is gated not only by the local-moving phase, which most prior work optimizes, but also by the aggregation phase; GVE-Louvain addresses both with collision-free per-thread hash tables, CSR-based aggregation with parallel prefix sums, vertex pruning, and tolerance tuning. On a dual 16-core Intel Xeon Gold 6226R, it processes 560M edges/s on the 3.8B-edge sk-2005 web graph and scales 1.6× per thread doubling. The GPU port, ν-Louvain, uses per-vertex open-addressing hash tables and a Pick-Less swap-prevention mechanism; on an A100 it is only 1.03× faster on average than GVE-Louvain, has 0.5% lower modularity, and cannot process the largest graph due to memory limits. The paper concludes from this that multicore CPUs may be better suited for community detection than GPUs.","pith_inferences":["The cuGraph speedup is averaged only over the eight graphs where cuGraph ran without out-of-memory; a GPU implementation with batched processing could perform differently, so the CPU-versus-GPU conclusion is specific to the compared implementations and graphs.","Because parameters were selected by experiments on the same graphs used for the final numbers, a held-out evaluation would be needed to confirm the speedups generalize; this is my own assessment, not the paper's.","The conclusion that CPUs 'may be better suited' for community detection is an inference from one pair of implementations; the paper presents no energy or cost-per-edge comparison, which would be needed to fully support that practical conclusion."],"forward_implications":["If the measurements hold, GVE-Louvain is the fastest reported multicore Louvain implementation, and other implementations can adopt its aggregation-phase optimizations.","The 1.6× per-thread-doubling scaling means the algorithm remains efficient up to 32 threads on this dual-socket server.","The near-parity of ν-Louvain with GVE-Louvain implies that for this workload, GPU memory capacity and reduced parallelism in later passes offset GPU throughput advantages.","The aggregation phase, not just local-moving, must be optimized to make Louvain fast; this is a direct engineering lesson."],"supporting_citations":[{"why":"Supplies the original Louvain algorithm that GVE-Louvain implements and optimizes.","marker":"[7]"},{"why":"Vite is the multi-node baseline that GVE-Louvain is compared against.","marker":"[21]"},{"why":"Grappolo is the multicore baseline that GVE-Louvain is compared against.","marker":"[25]"},{"why":"NetworKit Louvain is the multicore baseline that GVE-Louvain is compared against.","marker":"[53]"},{"why":"cuGraph Louvain is the GPU baseline that GVE-Louvain and ν-Louvain are compared against.","marker":"[28]"},{"why":"SuiteSparse Matrix Collection supplies the 13 graphs used in all performance measurements.","marker":"[30]"}],"fun_headline_variants":["CPU Louvain beats A100 GPU, 560M edges/s","CPU Louvain outruns A100 GPU port, 560M edges/s","CPU Louvain beats GPU Louvain: 560M edges/s","GVE-Louvain CPU beats A100 GPU, 560M edges/s","CPU Louvain hits 560M edges/s, beats A100 GPU"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The reported speedups rest on parameter settings (iteration cap, tolerances, switch degrees, probing strategy) that were tuned on the same 13 graphs later used to measure the speedups; if that tuning is overfitted, the results will not transfer to new graphs.","fun_headline_variants_meta":{"raw":{"variants":["CPU Louvain beats A100 GPU, 560M edges/s","CPU Louvain outruns A100 GPU port, 560M edges/s","CPU Louvain beats GPU Louvain: 560M edges/s","GVE-Louvain CPU beats A100 GPU, 560M edges/s","CPU Louvain hits 560M edges/s, beats A100 GPU"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000764,"raw_usage":{"total_tokens":3411,"prompt_tokens":985,"completion_tokens":2426,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":601,"completion_tokens_details":{"reasoning_tokens":2323}},"tokens_in":601,"tokens_out":2426,"duration_ms":15878,"temperature":1.0,"reasoning_tokens":2323,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-09T21:39:51.204245+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Run GVE-Louvain on a graph not in Table 2 using the exact published parameters, and compare against cuGraph Louvain (with RMM pool) and Grappolo on the same hardware; if the speedup over cuGraph falls far below the reported 3.2–5.8×, or the 560M edges/s rate is not reproducible on sk-2005 with the stated hardware, the general claim would be falsified.","supporting_citations":[{"cited_title":"Blondel, J","cited_arxiv_id":null,"evidence_quote":"Supplies the original Louvain algorithm that GVE-Louvain implements and optimizes."},{"cited_title":"Ghosh, M","cited_arxiv_id":null,"evidence_quote":"Vite is the multi-node baseline that GVE-Louvain is compared against."},{"cited_title":"Halappanavar, H","cited_arxiv_id":null,"evidence_quote":"Grappolo is the multicore baseline that GVE-Louvain is compared against."},{"cited_title":"Staudt, A","cited_arxiv_id":null,"evidence_quote":"NetworKit Louvain is the multicore baseline that GVE-Louvain is compared against."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"cuGraph Louvain is the GPU baseline that GVE-Louvain and ν-Louvain are compared against."},{"cited_title":"Kolodziej, M","cited_arxiv_id":null,"evidence_quote":"SuiteSparse Matrix Collection supplies the 13 graphs used in all performance measurements."}],"review_version":1}