Pith. sign in

REVIEW 4 major objections 5 minor 14 references

A Preliminary Study on Simultaneous Coscheduling for Discrete GPU vs. Fused GPU

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

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

Pith's one-line read 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.

desk verdict New measurements of the GH200 coscheduling landscape, with an honest but under-caveated cross-platform comparison. read the letter →

arxiv 2608.09647 v1 pith:JOYOAC4L submitted 2026-08-10 cs.DC

Poorna Gunathilaka , Nabayan Chaudhury , Kirshanthan Sundararajah , Wu-chun Feng This is my paper · ORCID
classification cs.DC
keywords CPU-GPUcoschedulingGH200SuperchipH100PCIemanagedmemorymappedsparseconjugategradienthybridexecutionmanagement
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

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.

What carries the argument

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.

What would settle it

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.

Watch

Extended reading notes

Core claim

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.

Load-bearing premise

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.

Editorial extensions

If this is right

  • 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.

Reading between the lines

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

  • 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.
Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

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

Referee Report

4 major / 5 minor

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.

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 (4)
  1. [§4.2, Table 1, Abstract] 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).
  2. [§4.1] 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.
  3. [§4.1, Table 2, Figure 1] 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.
  4. [§4.3, Figure 2] 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.
minor comments (5)
  1. [Table 2] 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.
  2. [Figure 1] The color-scale legend ('Best 1.10× 1.25× 2× 4× >4×') is hard to parse; use a conventional colorbar with labeled breakpoints.
  3. [§4.1] 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.
  4. [§4.4, Figure 3] 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.
  5. [General] 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.

Circularity Check

0 steps flagged · score 0.0 of 10

No circularity: the paper is an empirical comparative benchmark; the only derived quantity, the RQ3 transfer-bandwidth bound, is explicitly labeled an upper bound and does not feed back into the central measurement-based claims.

full rationale

The paper's central claim—that the GH200 broadens the practical sparse CG coscheduling space relative to the H100 PCIe platform—is a summary of direct measurements across two real systems (Table 2, Figures 1 and 2). No fitted parameter, self-consistency condition, or author-defined construct is used to produce the claimed result. The RQ3 interconnect-bound analysis (Section 4.4) scales only measured H100 transfer time by a vendor peak-bandwidth ratio R = 900/128 and is explicitly described as an 'optimistic' and 'upper-bound' analysis, not a prediction; the paper even lists the uncontrolled platform differences (CPU architecture, host memory, GPU configuration, software environment) and says the result 'should be interpreted as an upper-bound rather than a prediction.' Thus the analysis does not smuggle the conclusion into its assumptions. The classification of configurations as 'competitive' uses a stated 1.25x threshold relative to the best measured run time for the same matrix and platform; this is a reporting convention, not a derivation. The cited prior work on GH200 memory behavior, NVLink-C2C, and coscheduling frameworks provides context and is not load-bearing in the sense of forcing the paper's empirical conclusions. The GH200-vs-H100 comparison is not fully controlled (the systems differ in CPU, memory bandwidth, and software), but that is a threat to external validity or attribution, not circularity. There is no equation in the paper that is equivalent to its own input, and no fitted quantity is renamed as a prediction. Therefore, no significant circularity is present.

Assumptions & free parameters 1 free parameters · 4 assumptions · 0 invented entities

No fitted model parameters beyond the hand-set competitiveness threshold. The paper's claims rest on measurement assumptions about platform comparability and fixed-work benchmarking, not on invented entities or fitted constants.

free parameters (1)
  • Competitiveness threshold = 1.25x
    Configurations within 1.25x of the best run time are labeled 'competitive' or 'practical.' This threshold is chosen by hand, not justified, and directly determines the headline counts of matrices for which managed memory is considered practical.
assumptions (4)
  • domain assumption Cost model: T_cosched = max(T_CPU, T_GPU) + T_mem + T_sync
    Introduced in Section 2.1, Eq. (1). The paper uses this as a conceptual model for why platform differences matter; it assumes memory and synchronization costs add to the slower partition time and do not overlap with compute.
  • domain assumption Fixed-work comparison is valid
    Section 4.1 states all configurations run 2000 iterations without satisfying the convergence tolerance. The paper assumes fixed-work run time is a valid basis for comparing coscheduling practicality rather than time-to-solution.
  • domain assumption Platform comparability of GH200 and H100
    RQ1 and RQ2 compare GH200 and H100 as though the interconnect and coherence behavior are the main variables, but Table 1 also varies CPU architecture, host memory bandwidth, GPU HBM bandwidth, and software versions. The paper acknowledges this only in the RQ3 discussion.
  • domain assumption Ideal inverse bandwidth scaling in RQ3 bound
    Section 4.4 assumes transfer time scales inversely with the peak bandwidth ratio R = 900/128 and that all non-transfer costs remain unchanged. The paper labels this an optimistic upper bound, and it does not model latency, protocol overhead, coherence, or page placement.

how reviews work

0 comments
Cite this review

Pith. "Pith review of A Preliminary Study on Simultaneous Coscheduling for Discrete GPU vs. Fused GPU." pith.science (2026). https://pith.science/paper/JOYOAC4L

@misc{pith2026260809647,
  author       = {Pith},
  title        = {Pith review of: A Preliminary Study on Simultaneous Coscheduling for Discrete GPU vs. Fused GPU},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/JOYOAC4L}},
  note         = {Machine review of arXiv:2608.09647}
}
read the original abstract

CPU-GPU coscheduling enables simultaneous execution of an application across both processing units, but its efficiency depends on workload partitioning and memory architecture. This preliminary study evaluates coscheduling on the NVIDIA GH200 Superchip compared to a discrete H100 PCIe platform. Using sparse conjugate gradient (CG) as a case study, we assess various work divisions across three memory-management paradigms: explicit copy, managed memory, and mapped memory. Our evaluation highlights the run time and programmability tradeoffs of reducing manual CPU-GPU data movement. The results show that compared with the H100 PCIe platform, GH200 makes several hybrid CPU-GPU work divisions competitive and makes managed memory practical for several matrices. These results suggest that integrated CPU-GPU platforms such as GH200 can improve both performance and programmability for coscheduled workloads.

Figures

Figures reproduced from arXiv: 2608.09647 by the authors.

Figure 1
Figure 1. Normalized CG run time landscape on GH200 and H100 PCIe Platform. Each cell reports slowdown relative to the [PITH_FULL_IMAGE:figures/full_fig_p005_1.png] view at source ↗
Figure 2
Figure 2. Geomean run time penalty of managed and mapped [PITH_FULL_IMAGE:figures/full_fig_p005_2.png] view at source ↗
Figure 3
Figure 3. Measured GH200 and H100 explicit-copy run times [PITH_FULL_IMAGE:figures/full_fig_p006_3.png] view at source ↗

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

14 extracted references · 8 canonical work pages

  1. [1]

    Bagchi, S

    S. Bagchi, S. Srivastava, R. Levine, T. Sorensen, R. Stutsman, and V. Nagarajan

    work page

  2. [2]

    Banchelli, J

    F. Banchelli, J. Vinyals-Ylla-Catala, and J. Pocurull. 2024. NVIDIA Grace Superchip Early Evaluation for HPC Applications. InInternational Conference on High Performance Computing in Asia-Pacific Region Workshops (HPCAsiaWS). ACM, 45–54. doi:10.1145/3636480.3637284

    work page arXiv 2024

  3. [3]

    Burtscher, R

    M. Burtscher, R. Nasre, and K. Pingali. 2012. A quantitative study of irregular programs on GPUs. InProceedings of the 2012 IEEE International Symposium on Workload Characterization (IISWC) (IISWC ’12). IEEE Computer Society, USA, 141–151. doi:10.1109/IISWC.2012.6402918

    work page arXiv 2012

  4. [4]

    Davis and Yifan Hu

    Timothy A. Davis and Yifan Hu. 2011. The University of Florida Sparse Matrix Collection.ACM Trans. Math. Software38, 1 (2011), 1–25. doi:10.1145/2049662. 2049663

    doi:10.1145/2049662 2011

  5. [5]

    Fujita, T

    N. Fujita, T. Boku, T. Yoshida, T. Shirai, and M. Tsuji. 2025. GPU-CPU Shared Memory Performance Analysis on NVIDIA GH200. In2025 IEEE International Conference on Cluster Computing Workshops (CLUSTER Workshops). IEEE. doi:10. 1109/CLUSTERWorkshops65972.2025.11164213

    work page arXiv 2025

  6. [6]

    Fusco, M

    L. Fusco, M. Khalilov, M. Chrapek, G. Chukkapalli, T. Schulthess, and T. Hoefler

    work page

  7. [7]

    J. Li, Y. Wang, X. Liang, and H. Liu. 2024. Automatic BLAS Offloading on Unified Memory Architecture: A Study on NVIDIA Grace-Hopper. InPractice and Expe- rience in Advanced Research Computing. ACM, 1–5. doi:10.1145/3626203.3670561

    arXiv 2024

  8. [8]

    2026.CUDA C++ Programming Guide

    NVIDIA Corporation. 2026.CUDA C++ Programming Guide. NVIDIA Corporation. https://docs.nvidia.com/cuda/cuda-c-programming-guide/

    work page 2026

Show all 14 references
  1. [9]

    Schieffer, J

    G. Schieffer, J. Wahlgren, J. Ren, J. Faj, and I. Peng. 2024. Harnessing Integrated CPU-GPU System Memory for HPC: A First Look into Grace Hopper. InPro- ceedings of the 53rd International Conference on Parallel Processing (ICPP). ACM, 199–209. doi:10.1145/3673038.3673110

    2024

  2. [10]

    T. R. W. Scogland, W. Feng, B. Rountree, and B. R. De Supinski. 2014. CoreTSAR: adaptive worksharing for heterogeneous systems. InInternational Supercomput- ing Conference. Springer, 172–186

    2014

  3. [11]

    Y. Wei, Y. C. Huang, H. Tang, N. Sankaran, I. Chadha, D. Dai, O. Oluwole, and V. Balan. 2023. NVLink-C2C: A Coherent Off Package Chip-to-Chip Interconnect with 40Gbps/pin Single-ended Signaling. In2023 IEEE International Solid-State Circuits Conference (ISSCC). 160–162. doi:10...

    2023

  4. [12]

    Werner, M

    F. Werner, M. Weisgut, and T. Rabl. 2025. Towards Memory Disaggregation via NVLink C2C: Benchmarking CPU-Requested GPU Memory Access. InProceedings of the 4th Workshop on Heterogeneous Composable and Disaggregated Systems (HCDS). ACM, 8–14. doi:10.1145/3723851.3723853

    2025

  5. [2024]

    Understanding Data Movement in Tightly Coupled Heterogeneous Systems: A Case Study with the Grace Hopper Superchip.arXiv preprint arXiv:2408.11556 (2024)

    2024 arXiv

  6. [2026]

    InProceedings of the 2026 ACM SIGPLAN International Symposium on Memory Management (ISMM)

    Consistency and Coherence of the NVIDIA Grace-Hopper Superchip. InProceedings of the 2026 ACM SIGPLAN International Symposium on Memory Management (ISMM). ACM, 66–79. doi:10.1145/3814942.3816134

    2026

Pith tools

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