{"id":"48f878a7-517e-4842-8e10-c585a2de487e","arxiv_id":"2608.09647","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":4.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":1,"one_line_summary":"On GH200, hybrid CPU-GPU splits and managed memory become competitive for sparse conjugate gradient in more cases than on H100 PCIe, though with notable memory-mode outliers.","lead":"This paper benchmarks a CPU-GPU conjugate gradient solver on NVIDIA's GH200 integrated chip and an H100 PCIe system, testing three ways to share memory between CPU and GPU. It finds that GH200 makes mixed CPU-GPU execution and managed memory competitive more often, while H100 favors GPU-only explicit-copy runs.","discovery_kind":"extension","skeptic_critique":{"model":"deepseek-v4-flash","headline":"The GH200-vs-H100 comparison is confounded: GH200's faster CPU and different memory system could produce the observed hybrid/managed-memory benefits without the NVLink-C2C interconnect being the cause.","rationale":"The reader's weakest_assumption is exactly the confound I would stress. The paper's own Section 4.4 admits that the platforms differ in CPU architecture, host memory, GPU configuration, and software, and that the RQ3 result should be viewed as an upper bound, not a prediction. However, that caveat appears only in the interconnect analysis, while the abstract and conclusion frame the GH200 advantage as an integrated-platform effect. The proposed test disentangles CPU-compute speed from interconnect bandwidth: if normalizing CPU time collapses the difference, the central claim's causal interpretation fails; if it does not, the claim is supported. Because the paper is explicitly preliminary and already conditional in its conclusions, this concern does not change the reader's verdict; it reinforces the need for the stated condition (controlled comparison or acknowledged confound).","tokens_in":10022,"tokens_out":5151,"duration_ms":45249,"concrete_test":"Recompute RQ3 with a second scaling: after scaling H100 transfer time by 7.03x, also scale the H100 CPU-side execution time by the per-matrix ratio of GH200/H100 CPU-only run times from Table 2 (e.g., 1.035/2.669=0.388 for thermal2). If the resulting H100 'bounded' landscape reproduces GH200's hybrid optima and managed-memory-within-1.25x classification on the same matrices, then CPU speed (not NVLink-C2C) can account for the central claim. If it does not, the integrated-memory interpretation is supported.","verdict_should_be":"UNCHANGED","load_bearing_attack":"Central claim: GH200 broadens the practical coscheduling space and makes managed memory feasible for sparse CG. The evidence is a two-platform comparison, but Table 1 shows the systems differ not only in CPU-GPU interconnect: CPU (Grace 72 Arm vs 2x EPYC 96 x86), host memory bandwidth (500 vs 921.6 GB/s), GPU HBM (4.0 vs 3.35 TB/s), and CUDA/driver versions. The RQ3 analysis (Section 4.4) scales only the H100 transfer time by the peak bandwidth ratio R=900/128≈7.03, leaving CPU compute, synchronization, and memory-management overheads unchanged. Yet Table 2 shows GH200 CPU-only runs are faster on all eight matrices (e.g., thermal2 1.035s vs 2.669s), so a faster CPU alone could make intermediate splits more balanced and more competitive, independent of the interconnect. Similarly, managed-memory feasibility depends on page migration and placement, which are affected by the memory architecture, not just the link. The paper acknowledges these confounds only in the RQ3 discussion, while the abstract and conclusion state the comparative and causal claim without that caveat. Thus, the load-bearing assumption is that the observed broadening is attributable to the integrated CPU-GPU memory system rather than to the specific CPU, HBM, or software differences. The paper is not internally inconsistent, but the headline interpretation is at correctness risk.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper presents a preliminary empirical evaluation of CPU-GPU coscheduling for sparse conjugate gradient (CG) on an NVIDIA GH200 Superchip versus a discrete H100 PCIe platform. For eight SuiteSparse matrices, it sweeps GPU row fractions (0.00, 0.25, 0.50, 0.75, 1.00, plus 0.80-0.95) under three memory-management modes (explicit copy, managed memory, mapped memory) and reports mean run times over 2000 fixed CG iterations. The headline claim is that GH200 broadens the practical coscheduling space: hybrid CPU-GPU splits become competitive more often, and managed memory becomes a feasible best configuration for several matrices. An optimistic interconnect-bound analysis (RQ3) scales H100's measured transfer time by the NVLink-C2C/PCIe peak-bandwidth ratio and concludes that PCIe bandwidth alone does not explain the gap.","tokens_in":10279,"tokens_out":8957,"duration_ms":81983,"significance":"If the comparative claim were cleanly supported, the paper would be a useful data point for practitioners choosing between integrated and discrete CPU-GPU platforms for sparse iterative solvers. The work has real strengths: it covers a broad configuration grid, verifies residuals, sanity-checks the custom SpMV kernel against cuSPARSE, and explicitly labels the RQ3 bandwidth scaling as an upper bound rather than a prediction. The study is also free of circularity: it fits no model and makes no parameter-dependent prediction. However, the central claim currently overreaches the evidence because the two platforms differ in many respects beyond the interconnect, and because all runs are fixed-iteration throughput measurements rather than time-to-convergence. As written, the paper is best read as an exploratory two-system case study; the causal attribution to GH200's integrated memory system needs additional support or substantially softer language.","major_comments":[{"comment":"The headline conclusion—that GH200's integrated CPU-GPU memory system broadens the practical coscheduling space—is an attribution that the experimental design cannot support. Table 1 lists differences beyond the interconnect: Grace vs dual-EPYC CPUs, 500 vs 921.6 GB/s host memory, 4.0 vs 3.35 TB/s GPU HBM, and different CUDA/driver versions. Any of these could independently change which splits are balanced or whether managed-memory page placement is favorable. The §4.4 caveat is not reflected in the abstract, §4.2, or §6, where the results are stated as 'GH200 makes...' without qualification. I ask the authors to either re-frame the paper as a descriptive two-system case study or add an analysis that isolates the interconnect/memory-system contribution (for example, running the same workload on an H100 PCIe attached to a comparable Grace host, or fixing CPU compute time in the RQ3 bound).","section":"§4.2, Table 1, Abstract"},{"comment":"All evaluated configurations run exactly 2000 CG iterations without satisfying the convergence tolerance, so the reported run times are fixed-work throughput numbers, not time-to-solution. The 'practical coscheduling space' and 'competitive' classifications are therefore about 2000-iteration throughput. CG convergence can depend on reduction order and page placement across configurations, so a configuration that looks good on fixed work could be impractical to convergence, or vice versa. Please either run to a converged residual and report time-to-convergence, or explicitly relabel the claims as fixed-iteration throughput and avoid the word 'practical' in the abstract and conclusions.","section":"§4.1"},{"comment":"No run-to-run variability is reported. Ten measured passes are described, but Table 2 gives only means and Figure 1 gives single-point slowdowns; no standard deviations, confidence intervals, or min/max statistics are shown. The differences that drive the conclusions—for example, the 1.02x vs 1.32x managed-memory geomean slowdowns in RQ2, and whether a configuration falls within the 1.25x 'competitive' threshold—are not robust to noise without such information. Please add error bars or a dispersion table, or at least state the observed range across the ten passes for the key configurations.","section":"§4.1, Table 2, Figure 1"},{"comment":"The phrasing that managed memory is 'practical' or 'feasible' on GH200 is stronger than the reported numbers justify. The text says managed memory is best for only 3 of 8 matrices on GH200 and within 1.25x of best for 5 of 8, while on H100 it is within 1.25x for 6 of 8. The geomean hybrid-split penalty is indeed lower on GH200, but the conclusion should be tied to a clearly defined criterion and a sensitivity analysis around the 1.25x threshold; otherwise 'feasible in many cases' is hard to evaluate.","section":"§4.3, Figure 2"}],"minor_comments":[{"comment":"The column header 'Hyb.g' is not defined in the caption; please state that it is the GPU row fraction of the fastest hybrid configuration.","section":"Table 2"},{"comment":"The color-scale legend ('Best 1.10× 1.25× 2× 4× >4×') is hard to parse; use a conventional colorbar with labeled breakpoints.","section":"Figure 1"},{"comment":"The cuSPARSE validation paragraph does not state which platform the custom-kernel and cuSPARSE measurements were collected on; please specify GH200 or H100, since DRAM utilization and bandwidth figures are platform-dependent.","section":"§4.1"},{"comment":"Figure 3 shows only four of eight matrices; the text explains that these are the cases whose preferred split changes after the bound, but the caption should state this selection explicitly to avoid the impression of cherry-picking.","section":"§4.4, Figure 3"},{"comment":"The paper does not mention whether the benchmark code will be released; an artifact/availability statement would substantially improve reproducibility for this type of empirical study.","section":"General"}],"recommendation":"major_revision","confidential_remarks":"The manuscript is appropriate for a workshop venue and the preliminary framing is honest. The main barrier is the mismatch between the causal-sounding central claim and the confounded two-system comparison; if the authors can add a matched control or convincingly bound the non-interconnect differences, the paper would be a solid workshop contribution. I would not insist on time-to-convergence if the fixed-iteration framing is made consistent, but the 'practical' language should be adjusted. No concerns about citation or novelty beyond the workshop context."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Hi [Name],\n\nThis is a workshop-grade empirical study of CPU-GPU coscheduling on GH200 vs. H100 PCIe, using sparse CG with three memory modes. What's actually new: a fairly complete measurement of the split-by-split and memory-mode landscape for one iterative solver on an integrated platform, plus a clean sanity check that a simple PCIe-bandwidth scaling cannot reproduce the GH200 advantage. That is worth knowing for anyone working on heterogeneous memory systems.\n\nThe paper does a lot right. The methodology is careful: same source, same compiler, multiple splits, warm-up and measured passes, residual verification, and a reasonable attempt to isolate managed-memory overhead with profiling. The authors are also honest about the limits: they state upfront that nothing converges in 2000 iterations, so the times are fixed-work performance; they label the RQ3 analysis an upper bound; and they list the platform differences in Section 4.4 and the conclusion. The profiling evidence on hood and apache2, showing why managed memory helps or hurts, is the most valuable part.\n\nThe soft spots are not fatal but matter. The GH200 vs H100 comparison is not controlled: the systems differ in CPU, host memory bandwidth, GPU HBM, and CUDA version. The paper acknowledges this, but the abstract and intro still say the GH200 \"broadens\" the space, which reads as causal. A more accurate phrasing would be that the integrated platform exhibits a broader competitive space in this comparison; causal attribution to the interconnect requires more than one system pair. Second, there are no error bars or shared artifacts, and the 1.25x competitiveness threshold is arbitrary—though the authors do report the underlying slowdown maps, so that's a minor issue. Third, the mapped-memory mode has huge outliers (40x+); the authors explain them, but the takeaway is that mapped memory is mostly unusable for this workload, which is fine.\n\nWho is this for? People building autotuned coscheduling or studying GH200 memory management. It's a good preliminary data point, not a definitive study. I'd send it to a workshop or short-paper track with a request to soften the causal language and add at least a variance measure. It deserves referee time; it's not desk-reject material.\n\nRecommendation: accept with minor revisions if the forum is a workshop; for a full conference I'd want error bars, more matrices, and a deeper decomposition of the platform factors.\n\nBest,\n\n[Your name]","headline":"New measurements of the GH200 coscheduling landscape, with an honest but under-caveated cross-platform comparison.","tokens_in":10825,"tokens_out":3844,"would_cite":true,"duration_ms":32483,"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":"The GH200's integrated CPU-GPU design broadens the practical coscheduling space for sparse conjugate gradient, making hybrid work splits and managed memory competitive relative to a discrete H100 PCIe platform.","keywords":["CPU-GPU coscheduling","GH200 Superchip","H100 PCIe","managed memory","mapped memory","sparse conjugate gradient","hybrid execution","memory management"],"falsifier":"Run the managed-memory hybrid hood configuration on GH200 with all pages pinned to GPU HBM: if the roughly 2.45 million device-to-host operations and the SpMV spike from 0.122 ms to 21.86 ms persist, then remote access to $p$ is not the dominant cost, and the paper's coherence-based explanation for GH200's broader coscheduling space fails.","tokens_in":9826,"feed_emoji":"🖥️","tokens_out":9703,"duration_ms":85177,"temperature":0.7,"pith_summary":"This paper tries to establish that the integrated GH200 Superchip changes the economics of CPU-GPU coscheduling for sparse iterative solvers: mixed CPU-GPU row splits and managed memory become competitive on GH200, while on a discrete H100 PCIe platform the same configurations are usually uncompetitive. The evidence is a sparse conjugate-gradient solver run on eight sparse matrices under three memory modes and five GPU row fractions. On GH200 the best configuration is hybrid for six matrices and managed memory is the fastest mode for three; on H100 every best configuration uses explicit copy and favors GPU-only or CPU-only execution. The paper cares because coscheduling with managed memory removes manual data-movement code, so an integrated platform could offer both speed and programmability—but the result is preliminary, measured as fixed-work run time for 2000 iterations rather than time to convergence.","feed_headline":"Fused GH200 chip makes hybrid CPU-GPU splits competitive","feed_subtitle":"Managed memory becomes practical on an integrated chip, easing programming for sparse iterative solvers.","key_machinery":"The load-bearing object is the coscheduled sparse conjugate-gradient iteration, in which the CPU and GPU process disjoint row partitions and must make the search-direction vector $p$ visible to both sides before each sparse matrix-vector product. The paper varies the GPU row fraction $g \\in \\{0, 0.25, 0.5, 0.75, 1\\}$ and three memory modes that differ only in how $p$ is shared: explicit copy, managed memory, and mapped memory. The organizing identity is the run-time model $T_{\\text{cosched}} = \\max(T_{\\text{CPU}}, T_{\\text{GPU}}) + T_{\\text{mem}} + T_{\\text{sync}}$, which says a split pays off only when the memory and synchronization terms stay small relative to the benefit of using both processors; GH200's coherent NVLink-C2C link is what the paper credits with shrinking $T_{\\text{mem}}$. A secondary mechanism is the optimistic H100 bound, which scales only the measured transfer time by the peak bandwidth ratio $900/128 \\approx 7.03$ while holding all other costs fixed, to test whether bandwidth alone explains the gap.","core_discovery":"The paper's central claim is that the GH200 Superchip broadens the practical coscheduling space for sparse conjugate gradient relative to a discrete H100 PCIe platform: hybrid CPU-GPU row splits become competitive more often, and CUDA managed memory becomes viable where explicit copies were previously the only good option. On the eight-matrix case study, GH200's best configuration is hybrid for six matrices and managed memory is the fastest mode for three, while on H100 every optimum uses explicit copy and the landscape favors GPU-dominant or CPU-only execution. The paper also argues, via an optimistic bandwidth-scaling calculation, that the H100's disadvantage is not explained by PCIe transfer bandwidth alone; CPU architecture, memory-system behavior, synchronization, and software stack contribute. Reported times are fixed-work solve times over 2000 iterations, because no configuration satisfied the convergence tolerance within that budget.","pith_inferences":["The paper's 1.25x competitiveness threshold implicitly defines a plateau of acceptable configurations; a natural extension is to count how many configurations on each platform fall inside that plateau, which would test whether GH200's advantage is a wider flat region rather than a single better optimum.","Because all reported times are fixed-work (2000 iterations), a convergence-based study could change the rankings if managed memory alters numerical behavior through different reduction orders; the paper does not report time-to-solution or energy.","The paper states it did not measure page residency or migration, so the explanation that H100's GPU-only managed-memory speed comes from pages settling in HBM is a hypothesis that direct page-migration counters could confirm or refute.","The platform comparison varies not only the interconnect but also CPU model, host-memory bandwidth, GPU HBM bandwidth, and software versions, so a cleaner test of the integration hypothesis would compare systems that differ only in the CPU-GPU link."],"forward_implications":["On GH200, hybrid execution is the best configuration for six of eight matrices and managed memory is the fastest mode for three, so integrated platforms can make simpler memory programming competitive without sacrificing run time.","On H100 PCIe, explicit copy dominates every optimum; managed memory at hybrid splits can cost more than 100x the best time for matrices such as thermal2 and hood, and mapped memory degrades sharply as the GPU fraction rises, so discrete platforms still demand manual data movement for coscheduling.","Managed-memory overhead on GH200 is driven by cross-partition access to the shared vector: apache2 incurs only 760 host-to-device and 184 device-to-host unified-memory operations, while hood incurs roughly 1.87 million and 2.45 million, respectively, lifting average SpMV time from 0.122 ms to 21.86 ms.","Scaling H100 transfer time by the 7.03x peak-bandwidth ratio moves some preferred splits to $g = 0.75$, but H100 still does not consistently match GH200, so interconnect bandwidth alone cannot explain the platform gap.","Adding finer splits near the GPU-only endpoint ($g \\in \\{0.80, 0.85, 0.90, 0.95\\}$) did not change any best split, indicating the coarse sweep did not hide an optimum near GPU-only execution."],"supporting_citations":[{"why":"Supplies the coscheduling run-time model (max of partition times plus memory and synchronization terms) that frames the evaluation.","marker":"[10]"},{"why":"Documents NVLink-C2C as the coherent high-bandwidth CPU-GPU interconnect whose properties the GH200 results are attributed to.","marker":"[11]"},{"why":"Defines managed memory and mapped memory, the two programmability-oriented memory modes compared against explicit copy.","marker":"[8]"},{"why":"Provides the eight sparse matrices that define the case study.","marker":"[4]"},{"why":"Shows GH200 managed and system-allocated memory remain sensitive to page placement and migration, motivating the paper's memory-mode study.","marker":"[9]"},{"why":"Shows coherent CPU access to GPU memory over NVLink-C2C is not equivalent to local memory access, informing the interpretation of GH200 overheads.","marker":"[12]"},{"why":"Documents data-movement behavior in tightly coupled CPU-GPU systems, used to frame GH200's memory-system sensitivity.","marker":"[6]"},{"why":"Supports the choice of sparse irregular workloads as cases where CPU execution can compete with the GPU, motivating coscheduling.","marker":"[3]"}],"fun_headline_variants":["GH200 makes hybrid splits and managed memory practical","Fused chip turns managed memory into a real option","GH200: hybrid CPU-GPU splits get competitive","Managed memory goes practical on fused GH200"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The assumption that carries the paper is that the GH200-versus-H100 comparison isolates the CPU-GPU interconnect and coherent memory, even though the two systems also differ in CPU model, host-memory bandwidth, GPU HBM bandwidth, and software versions; if those other differences drive the observed landscape, the conclusion that integration is what broadens coscheduling would not follow.","fun_headline_variants_meta":{"raw":{"variants":["GH200 makes hybrid splits and managed memory practical","Fused chip turns managed memory into a real option","GH200: hybrid CPU-GPU splits get competitive","Managed memory goes practical on fused GH200"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000895,"raw_usage":{"total_tokens":3808,"prompt_tokens":849,"completion_tokens":2959,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":465,"completion_tokens_details":{"reasoning_tokens":2899}},"tokens_in":465,"tokens_out":2959,"duration_ms":21651,"temperature":1.0,"reasoning_tokens":2899,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-11T13:27:14.373281+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Run the managed-memory hybrid hood configuration on GH200 with all pages pinned to GPU HBM: if the roughly 2.45 million device-to-host operations and the SpMV spike from 0.122 ms to 21.86 ms persist, then remote access to $p$ is not the dominant cost, and the paper's coherence-based explanation for GH200's broader coscheduling space fails.","supporting_citations":[{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Supplies the coscheduling run-time model (max of partition times plus memory and synchronization terms) that frames the evaluation."},{"cited_title":"2026.CUDA C++ Programming Guide","cited_arxiv_id":null,"evidence_quote":"Defines managed memory and mapped memory, the two programmability-oriented memory modes compared against explicit copy."},{"cited_title":"Fusco, M","cited_arxiv_id":null,"evidence_quote":"Documents data-movement behavior in tightly coupled CPU-GPU systems, used to frame GH200's memory-system sensitivity."},{"cited_title":"Burtscher, R","cited_arxiv_id":null,"evidence_quote":"Supports the choice of sparse irregular workloads as cases where CPU execution can compete with the GPU, motivating coscheduling."}],"review_version":1}