REVIEW 4 major objections 8 minor 7 references
Investigations of multi-socket high core count RISC-V for HPC workloads
T0 review · 4 major / 8 minor · reviewed 2026-08-07 · deepseek-v4-flash
Pith's one-line read Running the same benchmarks on a second, dual-socket system confirms that the SG2042 RISC-V CPU's memory bottleneck is in the chip, not the host, while adding sockets generally helps performance.
desk verdict Useful first dual-socket SG2042 NPB data, but the paper's central 'inherent to the CPU' conclusion needs tempering because only two hosts and no direct memory measurements back it. read the letter →
The pith
A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.
The reading
What carries the argument
The central object is the SG2042, a 64-core RISC-V processor built from XuanTie C920 cores, with four DDR4-3200 memory controllers, a 64MB shared L3 cache, and 128-bit vector units. The argument's load-bearing machinery is the controlled comparison of the same NPB kernel suite across two different host systems: the earlier single-socket workstation and the new dual-socket system. Because both hosts produce the same memory-bound signature, the paper attributes the behavior to the CPU's memory controller design. The multi-socket experiments further probe whether the second socket's extra memory controllers can relieve the bottleneck.
What would settle it
Run the same NPB class-C kernels on both the single-socket workstation and the dual-socket system while measuring achieved memory bandwidth and latency with a microbenchmark such as STREAM and a pointer-chasing benchmark. If the dual-socket system delivers substantially higher peak bandwidth and the memory-bound kernels improve accordingly, the host memory subsystem is the culprit; if bandwidth differs but kernel performance stays flat, the CPU's memory controllers are the bottleneck.
Extended reading notes
Core claim
Using the five NPB kernel benchmarks (IS, EP, MG, CG, FT) at class C on a bespoke dual-socket SG2042 system, the paper reports that the memory-bound nature of the SG2042 observed in prior work on a single-socket workstation is reproduced on this different host. The authors therefore conclude that the limitation is inherent in the design of the CPU itself, not an artifact of the earlier host. They additionally find that socket one consistently outperforms socket two on the dual-socket nodes, with the gap most visible in memory-stressing kernels, and that running across a second socket improves performance for all kernels except Integer Sort, where inter-socket NUMA overhead dominates. The paper characterizes the SG2042 as delivering strong compute performance, competitive with a Marvell ThunderX2, while lagging on bandwidth- and latency-bound workloads.
Load-bearing premise
The conclusion that the memory limitation is inherent to the CPU rests on assuming the dual-socket system's memory architecture is different enough from the earlier workstation that the shared memory-bound behavior cannot be explained by common platform traits.
Editorial extensions
If this is right
- Memory-heavy HPC workloads will face a hard performance ceiling on SG2042 systems regardless of motherboard or host platform.
- Building multi-socket SG2042 nodes is worthwhile: most benchmarks improve when a second socket's memory controllers are added.
- For compute-bound codes, the SG2042 can be competitive with established HPC CPUs, and its high core count makes it attractive on a performance-per-dollar basis.
- Inter-socket NUMA effects, as seen in Integer Sort, mean that thread placement and data locality policies will be essential to realize the multi-socket benefit.
Reading between the lines
- If the CPU-inherent claim is right, then software workarounds such as cache blocking, data layout changes, and vectorization can shrink but not remove the memory gap; the four-memory-controller design is a hard physical limit.
- A direct microbenchmark of memory bandwidth and latency on both hosts would settle whether the similarity is truly CPU-inherent rather than a shared DDR4 platform trait; the paper does not report such measurements.
- The consistent socket-one-over-socket-two gap on both nodes suggests a board-level or manufacturing asymmetry that may be tunable; if confirmed on a larger sample of nodes, it would point to a concrete optimization for dual-socket SG2042 systems.
- For HPC centers, the SG2042's compute-per-dollar could make it a candidate for throughput-oriented workloads with small working sets, such as many independent embarrassingly parallel jobs, even while memory-bound applications are steered elsewhere.
Signed reviews
Editorial analysis
A structured set of objections, weighed in public.
Referee Report
Summary. Brown and Day benchmark a dual-socket E4 Computer Engineering system containing two 64-core Sophon SG2042 RISC-V CPUs using the NAS Parallel Benchmark suite (class C) for five kernels (IS, EP, MG, CG, FT). They compare performance across the two sockets and nodes of the E4 system, and in a second experiment compare thread-scaling on the SG2042 against AMD EPYC 7742, Intel Xeon Platinum 8170, and Marvell ThunderX2. The paper's central claim is that the memory-bound behaviour previously observed on the single-socket Milk-V Pioneer is reproduced on the E4 system and is therefore inherent to the SG2042 CPU design, and that multi-socket scaling is generally beneficial for this CPU.
Significance. If the central inference were fully supported, the conclusion that the SG2042's memory bottleneck is CPU-inherent would be valuable to the HPC community, as it would rule out the Pioneer host as the cause and would imply that future SG2042 systems need to address memory bandwidth and latency at the CPU level. The paper also provides one of the first published benchmark results for a dual-socket SG2042 system, which is useful in itself. The cross-architecture comparisons with EPYC, Skylake, and ThunderX2 provide context, though they are not the main contribution. However, the significance is tempered by the lack of direct memory benchmarks and statistical reporting, which leaves the key causal claim under-supported.
major comments (4)
- [Section 5] The claim that the memory-bound nature is 'inherent in the design of the CPU itself' rests on comparing only two SG2042 hosts (the Milk-V Pioneer and the E4 system). Both hosts use DDR4-style memory subsystems with the SG2042's integrated memory controllers, and the paper provides no direct memory bandwidth or latency measurements (e.g., STREAM or lat_mem_rd), no memory controller configuration details, and no BIOS or NUMA topology information for either system. Section 3's finding that socket 2 consistently underperforms socket 1 on memory-bound kernels demonstrates that motherboard-level memory routing or configuration can substantially affect performance on the E4 system itself. Common behavior across two hosts therefore does not by itself isolate the CPU package from platform-level effects. The authors should either add direct memory benchmark evidence ruling out shared platform-level explanations, or properly qualify the conclusion to state that the limitation is associated with the SG2042's integrated memory controllers without excluding platform contributions.
- [Section 3, Figure 1] All benchmark results are averaged over five runs, but no variance measures (standard deviation, min-max, or confidence intervals) are reported. The text makes strong claims of consistency, e.g., 'socket one outperforms socket two consistently across the benchmarks' and 'there is a noteworthy difference' between sockets on node two for EP, yet without variance data the statistical significance of these differences cannot be assessed. Given that the Section 5 conclusion depends on the reliability of the socket/node comparisons, the authors should report run-to-run variability and, where relevant, perform significance tests.
- [Section 4] The cross-architecture comparisons use different GCC versions: 13.2.1 on the SG2042, 11.2 on the AMD EPYC, 8.4 on the Intel Skylake, and 9.2 on the Marvell ThunderX2. Because compiler version can materially affect OpenMP code generation, auto-vectorization, and runtime behavior, the performance differences attributed to CPU characteristics may be partially confounded with compiler effects, especially for vectorization-sensitive kernels such as EP and FT. The paper does not discuss this potential confound. Please justify the compiler choices or provide a sensitivity analysis, even if limited to one or two kernels, to demonstrate that the conclusions are robust to compiler version.
- [Sections 2.1 and 4, reference [2]] The manuscript does not specify the exact software environment (NPB version, compiler, and flags) used for the earlier Milk-V Pioneer measurements reported in [2], which serve as the baseline for the 'inherent to the CPU' claim. If the compiler or optimization flags differed between the two systems, the observed similarity in memory-bound behaviour could be a software artifact. Please state the software environment for both systems explicitly.
minor comments (8)
- [Section 1] The reference to 'Section ??' in the introduction is an unresolved cross-reference.
- [Section 2.1] The phrase 'All the NBP benchmarks' should be 'All the NPB benchmarks', and 'optimization level three' should be written as '-O3'.
- [Table 1] The caption says the table is from [2], but the measurement methodology for the clock-tick and DDR-bandwidth percentages is not described here; please clarify how these values were obtained.
- [Section 4, memory controller discussion] There is a typo, 'for th SG2042', which should be 'for the SG2042'.
- [Figure 2] The figure captions do not state that higher is better (unlike Figure 1); please add this statement to the captions or the text.
- [Section 5] The claim that the SG2042 delivers impressive 'performance per dollar' is not supported by any cost data in the paper; either add supporting evidence or remove the claim.
- [Reference [1]] The bibliographic entry for the NAS Parallel Benchmarks is incomplete ('CG and IS (2006)'); please provide the full citation.
- [Section 2] The E4 system's memory is described only as '256GB of DDR memory'; specifying the DDR generation and clock speed would be helpful for interpreting the memory-bound results.
Circularity Check
No significant circularity: the new E4 dual-socket SG2042 benchmark measurements are independent of the prior SG2042 results, and the central inference, though empirically under-supported, is not a definitional reduction.
full rationale
The paper's load-bearing conclusion in Section 5 is that the memory-bound behaviour observed on the Milk-V Pioneer is also seen on the E4 system and hence is 'inherent in the design of the CPU itself.' This is an empirical inference from new benchmark runs on a different host, not a derivation from the paper's own equations or a fitted parameter renamed as a prediction. No equation in the paper reduces to an input by construction, and there is no fitted parameter whose output is then reported as a prediction. The reliance on the authors' prior work [2] is for benchmark selection, profiling context, and comparison CPUs; Table 1 is explicitly recreated from [2] as context, and the Section 4 comparisons use external CPUs. Those self-citations explain methodology and prior observations but do not force the new E4 results. The 'inherent in the CPU' claim is weakened by the absence of direct memory bandwidth or latency measurements and by the possibility that both hosts share DDR4-style memory subsystems, but that is an evidentiary or correctness limitation, not circular reasoning. The paper contains no imported uniqueness theorem, no ansatz smuggled in via citation, and no renaming of a known result as a new derivation. Therefore no circular step meets the required standard of being exhibited as a specific reduction.
Assumptions & free parameters
assumptions (4)
- domain assumption NPB class C kernels, run with OpenMP without modification, are representative of HPC workloads.
- domain assumption Compilation with different GCC versions across architectures does not materially affect the comparative conclusions.
- domain assumption Averaging five runs without reporting variance is sufficient to characterize performance.
- domain assumption The E4 and Pioneer systems share no relevant memory-subsystem weakness beyond the CPU.
Cite this review
Pith. "Pith review of Investigations of multi-socket high core count RISC-V for HPC workloads." pith.science (2026). https://pith.science/paper/XHPTRGM3
@misc{pith2026250210320,
author = {Pith},
title = {Pith review of: Investigations of multi-socket high core count RISC-V for HPC workloads},
year = {2026},
howpublished = {\url{https://pith.science/paper/XHPTRGM3}},
note = {Machine review of arXiv:2502.10320}
}
read the original abstract
Whilst RISC-V has become popular in fields such as embedded computing, it is yet to find mainstream success in High Performance Computing (HPC). However, the 64-core RISC-V Sophon SG2042 is a potential game changer as it provides a commodity available CPU with much higher core count than existing technologies. In this work we benchmark the SG2042 CPU hosted in an experimental, dual-socket, system to explore the performance properties of the CPU when running a common HPC benchmark suite across sockets. Earlier benchmarks found that, on the Milk-V Pioneer workstation, whilst the SG2042 performs well for compute bound codes, it struggles when pressure is placed on the memory subsystem. The performance results reported here confirm that, even on a different system, these memory performance limitations are still present and hence inherent in the CPU. However, a multi-socket configuration does enable the CPU to scale to a larger number of threads which, in the main, delivers an improvement in performance and-so this is a realistic system configuration for the HPC community.
Figures
Reference graph
Works this paper leans on
-
[2]
Nick Brown and Maurice Jamieson. 2025. Performance characterisation of the 64-core SG2042 RISC-V CPU for HPC. In International Conference on High Performance Computing. Springer, 354–367
work page 2025
-
[1]
NAS Parallel Benchmarks. 2006. NAS Parallel Benchmarks. CG and IS (2006)
work page 2006
-
[3]
Nick Brown, Maurice Jamieson, Joseph Lee, and Paul Wang. 2023. Is RISC-V ready for HPC prime-time: Evaluating the 64-core Sophon SG2042 RISC-V CPU. In Proceedings of the SC’23 Workshops of The International Conference on High Performance Computing, Network, Storage, and Analysis . 1566–1574
2023
-
[4]
Patrick Diehl, Panagiotis Syskakis, Gregor Daiß, Steven R Brandt, Alireza Kheirkhahan, Srinivas Yadav Singanaboina, Dominic Marcello, Chris Taylor, John Leidel, and Hartmut Kaiser. 2024. Preparing for HPC on RISC-V: Examining Vectorization and Distributed Performance of an Astrophysics Application with HPX and Kokkos. In SC24-W: Workshops of the Internati...
work page 2024
-
[5]
Joseph KL Lee, Maurice Jamieson, and Nick Brown. 2023. Backporting risc-v vector assembly. In International Conference on High Performance Computing. Springer, 433–443
work page 2023
-
[6]
Open XuanTie C906
Open chip community 2023. Open XuanTie C906. Retrieved Aug 16, 2023 from https://xrvm.com/cpu-details?id=4056751997003636736
2023
-
[7]
T-Head 2023. C920: Specifications. Retrieved Aug 16, 2023 from https://xuantie.t-head.cn/product/xuantie/4082464366237126656
Reviewed August 7, 2026 · model on record in the stance chip above.
Discussion (0). Continue with ORCID to comment.