{"id":"fef96104-1b25-45ec-a418-d356a4752e5a","arxiv_id":"2605.22831","paper_version":2,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":4.0,"correctness_risk":"unknown","formal_verification":"none","parameter_count":0,"one_line_summary":"The SOPHGO SG2044 RISC-V processor achieves 3.08 GFLOPs/W and narrows the HPC performance gap with Intel and Arm to within 1.11× when normalized by vector width at peak efficiency.","lead":"This paper benchmarks the third iteration of the Monte Cimone RISC-V HPC cluster (MCv3), powered by the SOPHGO SG2044 processor, against Intel and NVIDIA Arm platforms. It finds that RISC-V is closing the performance gap, achieving 3.08 GFLOPs/W and reaching 91% of NVIDIA Grace's performance when normalized by vector width at 16 cores.","discovery_kind":"unclear","skeptic_critique":{"model":"glm-5.2","headline":"The OpenBLAS-on-all-platforms choice is the load-bearing concern: vendor BLAS can improve HPL by 1.5–3× on Intel/NVIDIA, which would substantially erode both the normalized performance ratios and the energy-efficiency comparison.","rationale":"The reader correctly identified the most load-bearing concern. The OpenBLAS choice is a systematic bias that the paper acknowledges but does not quantify, and the magnitude of the effect (potentially 1.5–3× on Intel) is large enough to materially affect both the energy-efficiency and normalized-performance comparisons that constitute the paper's central claims. The CONDITIONAL verdict is appropriate: the paper is a valuable characterization of new RISC-V hardware, and the within-architecture results (SG2044 vs SG2042 vs MCv1, L2-aware pinning, scaling curves) are not affected by this concern. But the cross-architecture comparative claims — which are the ones highlighted in the abstract — remain unverified without either (a) running vendor BLAS on the competitors or (b) providing a quantitative bound on the OpenBLAS penalty. I note one additional concern the reader did not raise: the vector-width × frequency normalization assumes equal FMA-unit counts per core across architectures, which is not confirmed in the paper. However, this is a secondary issue compared to the BLAS software-stack effect, which directly scales the absolute performance numbers feeding every comparison. The verdict remains CONDITIONAL with moderate confidence; the paper would move toward ACCEPT if the authors either ran vendor BLAS on the baselines or provided a defensible upper bound on the OpenBLAS gap.","tokens_in":4268,"tokens_out":3569,"duration_ms":84466,"concrete_test":"Run HPL on the Intel Xeon 8480+ and NVIDIA Grace platforms with their vendor-optimized BLAS (Intel oneMKL and NVIDIA's Grace-optimized BLAS respectively) using the same HPL problem size and thread/MPI configuration as the OpenBLAS runs. Compare the resulting GFLOP/s against the OpenBLAS numbers. If the vendor library improves HPL throughput by more than ~20% on either platform, recompute the normalized performance ratios (Figure 4) and the GFLOPs/W table (Table 2). If the normalized ratios shift such that MCv3 falls below 30% of Intel or below 70% of NVIDIA at 16 cores, the 'closing the gap' headline claim would need qualification.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The paper's two headline comparative claims — (1) 3.08 GFLOPs/W being 68% of NVIDIA and 80% of Intel, and (2) 91% / 46% normalized performance at 16 cores — both derive from HPL performance numbers obtained with OpenBLAS 0.3.29 on all platforms. The paper acknowledges this choice but dismisses the impact as 'slightly higher' without quantification. This is the soft spot: Intel MKL (now oneAPI Math Kernel Library) routinely delivers 1.5–3× higher HPL throughput than OpenBLAS on Sapphire Rapids-class hardware, because MKL exploits architecture-specific microarchitectural features (AMX tiles, cache-aware blocking, NUMA topology) that OpenBLAS does not. If MKL yields even a 2× improvement on the Intel platform, the Intel HPL score rises from ~4928 to ~9856 GFLOP/s, the energy efficiency rises from 4.08 to ~8.16 GFLOPs/W, and MCv3's relative efficiency drops from 80% to ~38%. Similarly, the normalized performance ratio at 16 cores would shift from 46% to ~23% of Intel. The NVIDIA Grace platform may also benefit from vendor-optimized libraries, though potentially by a smaller margin. The paper's central narrative — that RISC-V is 'closing the gap' — is conditional on the magnitude of this software-stack effect, which the paper neither measures nor bounds. A secondary concern: the normalization by vector width × clock frequency implicitly assumes equal numbers of FMA units per core across architectures, which the paper does not verify. If Intel or NVIDIA cores have more FMA units per vector lane than SG2044, the normalization understates their advantage.","agreement_with_reader":"agree"},"referee_report":{"model":"glm-5.2","summary":"This paper presents Monte Cimone v3 (MCv3), a RISC-V HPC testbed built around the SOPHGO SG2044 processor, and benchmarks it against Intel Sapphire Rapids and NVIDIA Grace CPU Superchip using HPL and STREAM with power measurements. The SG2044 more than doubles per-core performance over the SG2042 (MCv2) and achieves 3.08 GFLOPs/W, which the authors position as comparable to x86-64 and Arm servers. The paper's central comparative claim is that, when normalized by vector width and clock frequency at the 16-core peak-efficiency point, MCv3 reaches 91% of NVIDIA Grace and 46% of Intel Sapphire Rapids performance. The work provides useful empirical data on a current-generation RISC-V server processor and its integration into a production SLURM-managed cluster environment.","tokens_in":5158,"tokens_out":1079,"duration_ms":65620,"significance":"The paper contributes timely empirical benchmarking data for a commercially available RISC-V HPC processor (SG2044) that has not been widely characterized in the literature. The integration into a production cluster with SPACK-based modules and SLURM scheduling adds practical value beyond synthetic benchmarking. The STREAM pinning-strategy analysis (Figure 2) showing that L2-cache-aware pinning achieves near-peak bandwidth with only 16 threads is a concrete, actionable finding. The cross-architecture normalization by vector width and frequency, while requiring caveats (see major comments), provides a useful per-FMA-unit lens for comparing architecturally disparate platforms. The 10× efficiency improvement over MCv1 documents real generational progress in the RISC-V HPC space.","major_comments":[{"comment":"§Benchmark setup and measurements: The use of OpenBLAS 0.3.29 on all platforms, including Intel Sapphire Rapids and NVIDIA Grace, is the load-bearing methodological choice for the paper's headline comparative claims (Table 2 GFLOPs/W ratios of 68%/80%, and the 91%/46% normalized performance figures). The paper acknowledges that 'vendor libraries on Intel and NVIDIA systems may provide slightly higher HPL performance' but does not quantify or bound this effect. Published data consistently show that Intel MKL/oneAPI MKL can deliver 1.5–3× higher HPL throughput than OpenBLAS on Sapphire Rapids-class hardware by exploiting AMX tiles, cache-aware blocking, and NUMA topology. If MKL yields even a 2× improvement on Intel, the HPL score rises from ~4928 to ~9856 GFLOP/s, the energy efficiency rises from 4.08 to ~8.16 GFLOPs/W, and MCv3's relative efficiency drops from 80% to ~38%. This would not","section":null},{"comment":"§HPL, Figure 4 and surrounding text: The normalization by vector width × clock frequency implicitly assumes an equal number of FMA units per core across all three architectures. The paper does not state or verify the FMA-unit counts for SG2044, Sapphire Rapids, or Grace. If Intel or NVIDIA cores have more FMA units per vector lane, the normalization understates their per-core compute capability and inflates MCv3's relative position. The paper should either (a) confirm equal FMA-unit counts with citations or microarchitectural documentation, or (b) include FMA units per core in the normalization denominator and recompute the ratios. Without this, the 91%/46% figures are not adequately supported.","section":null}],"minor_comments":[{"comment":"Abstract: 'High-Performacne' → 'High-Performance'.","section":null},{"comment":"§Benchmark setup: 'measureemnt' → 'measurement'.","section":null},{"comment":"Abstract: 'improves of 10x' → 'improves by 10×'.","section":null},{"comment":"§HPL: 'NVIDIA 5.3×, Intel 12.9×' — specify whether these are per-core or per-MPI-process ratios and at what thread/process count.","section":null},{"comment":"Table 2: The MCv1 average power of 5.9 W is inconsistent with the 83.9 W for MCv3; clarify whether the MCv1 figure is package-only or board-level, given the text states MCv1 used board instrumentation.","section":null},{"comment":"Figure 4: The log-scale y-axis makes it difficult to distinguish the SG2044 and SG2042 curves at higher core counts; consider clearer legend placement.","section":null},{"comment":"The paper would benefit from citing prior SG2044 evaluations (e.g., [3] is cited for STREAM but not for HPL cross-comparison) to contextualize the 'slightly higher' claim.","section":null}],"recommendation":"major_revision","confidential_remarks":"The paper is a short conference-style contribution (2 pages, RISC-V Summit Europe), which may limit the scope for additional experiments. However, the OpenBLAS confound is serious enough that the headline comparative claims need at minimum a quantified sensitivity bound, even if full vendor-library re-benchmarking is not feasible within the page limit. The authors could reframe the contribution as an absolute-performance and intra-RISC-V-generational comparison, with the cross-architecture ratios presented as lower bounds rather than headline claims."},"author_rebuttal":{"model":"glm-5.2","summary":"We thank the referee for the careful reading and the two substantive methodological points. Both are legitimate, and we address each below.","responses":[{"response":"The referee is correct that our use of OpenBLAS across all platforms was a deliberate methodological choice for software-stack consistency, but the language describing the potential gap as 'slightly higher' understates the effect and we will revise it. We agree that published data show Intel MKL/oneAPI can deliver substantially higher HPL throughput on Sapphire Rapids, particularly when AMX tiles are exploited. We will make the following changes in the revision: (1) Replace 'slightly higher' with a quantitative bound drawn from published Sapphire Rapids HPL results, explicitly noting that MKL with AMX can yield 1.5–3× improvement over OpenBLAS. (2) Add a sensitivity analysis showing how the GFLOPs/W ratios in Table 2 and the normalized figures in Figure 4 change under a conservative 2× MKL scaling factor for Intel (e.g., MCv3's relative efficiency to Intel would drop from 80% to ~38%). (3) Retain the OpenBLAS-based comparison as the primary result for cross-platform software consistency, but clearly label it as a same-software-stack comparison and add a secondary discussion noting the vendor-optimized upper bounds. We believe the same-software-stack comparison retains scientific value—it isolates architectural differences from software-maturity effects—but we agree it must not be presented without this caveat. We will also attempt to run oneAPI MKL on the Intel platform during the revision period to provide a direct measurement; if this is not possible within the revision window, we will include the bounded sensitivity analysis as described.","revision_made":"yes","referee_comment":"OpenBLAS on all platforms may understate Intel/NVIDIA HPL performance by 1.5–3×, undermining the headline comparative ratios (68%/80% efficiency, 91%/46% normalized). The paper's characterization of vendor-library gains as 'slightly higher' is not supported."},{"response":"This is a valid concern. Our normalization by vector width × frequency is a first-order approximation that implicitly assumes one FMA unit per vector lane per core. We will address this in the revision as follows. First, we will document the FMA-unit counts per core for each architecture from available microarchitectural references: SG2044 (XuanTie C920) has one 128-bit RVV FMA pipe per core; Intel Sapphire Rapids has two 512-bit FMA units per core (which the '2×512 bits' vector-width entry in Table 1 already captures, so the normalization is approximately correct for Intel); NVIDIA Grace (Neoverse V2) has two 128-bit SVE pipes per core, giving 256 bits of effective vector width per core, whereas our Table 1 lists '4×128 bits' (512 bits), which appears to overcount. If the Grace figure should be 256 bits rather than 512 bits, the normalization denominator for Grace is too large, meaning MCv3's 91% figure relative to Grace would actually be overstated and should be revised downward. We will verify the Neoverse V2 SVE pipe configuration against ARM documentation and recompute the normalized ratios accordingly. We will also add an explicit column in Table 1 for 'FMA units per core' and 'effective FMA width per core' to make the normalization transparent and auditable. We note that the SG2044's exact microarchitectural details (FMA pipe count, whether the 128-bit vector unit can sustain one FMA per cycle) are not fully documented in public sources; we will state this limitation explicitly. If we cannot confirm the SG2044 FMA-unit count, we will add a caveat that the normalization for MCv3 assumes one FMA per cycle per core and that this assumption is based on the C920 architecture but not independently verified by microbenchmarking.","revision_made":"partial","referee_comment":"Normalization by vector width × clock frequency assumes equal FMA units per core across all three architectures. The paper does not state or verify FMA-unit counts. If Intel or NVIDIA have more FMA units per vector lane, the normalization understates their per-core compute capability and inflates MCv3's relative position."}],"tokens_in":4046,"tokens_out":2138,"duration_ms":59672,"standing_objections":[]},"desk_editor":{"model":"glm-5.2","letter":"The headline: this is the first HPC characterization of the SOPHGO SG2044, and it shows genuine progress — 10x efficiency improvement over MCv1, 2x single-core gains over SG2042, and a useful L2-cache-aware pinning finding for STREAM. But the paper's comparative claims against Intel and NVIDIA are conditional on a software-stack choice that it doesn't adequately bound, and that undercuts the headline narrative about RISC-V 'closing the gap.'","headline":"RISC-V SG2044 HPC benchmark: real progress, but comparative claims rest on a debatable software-stack choice","tokens_in":5079,"tokens_out":652,"would_cite":false,"duration_ms":22339,"reading_group":"no","serious_thinker":"no","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"glm-5.2","headline":"RISC-V HPC Node Reaches 91% of NVIDIA Grace Efficiency","keywords":[],"falsifier":"If vendor-optimized BLAS on Intel and NVIDIA systems delivers substantially more than 'slightly higher' HPL performance, the normalized gap between RISC-V and competitors would widen, undermining the claim that RISC-V is closing the gap.","tokens_in":4412,"feed_emoji":"","tokens_out":945,"duration_ms":81546,"temperature":0.7,"pith_summary":"This paper presents the third iteration of the Monte Cimone RISC-V HPC cluster (MCv3), built around the SOPHGO SG2044 processor, and benchmarks it against contemporary Intel Xeon Sapphire Rapids and NVIDIA Grace CPU Superchip systems using HPL and STREAM with power measurements. The SG2044 more than doubles per-core performance over its SG2042 predecessor and achieves 3.08 GFLOPs/W energy efficiency — a 10x improvement over the first-generation Monte Cimone node and within the range of mainstream x86-64 and Arm servers. When HPL performance is normalized by vector width and clock frequency at the RISC-V node's peak efficiency point (16 cores), the SG2044 reaches 91% of NVIDIA Grace performance and 46% of Intel Sapphire Rapids performance. The paper argues that commercially available RISC-V compute nodes are closing the gap with established HPC architectures, with the remaining deficits attributable primarily to narrower vector units and memory-subsystem scalability rather than fundamental architectural limitations.","feed_headline":"RISC-V HPC Node Hits 91% of NVIDIA Grace on Normalized Basis","feed_subtitle":"Third-generation Monte Cimone cluster shows commercially available RISC-V processors reaching mainstream energy efficiency, trailing mainly","key_machinery":"SG2044 processor with RVV 1.0 (128-bit vectors), 32 LPDDR5X memory channels, L2-cache-aware OpenMP thread pinning, HPL and STREAM benchmarks, IPMI power measurements","core_discovery":"The central finding is that the SG2044-based RISC-V node, when compared on a normalized basis (vector width and clock frequency), reaches within 9% of NVIDIA Grace CPU Superchip performance and within 54% of Intel Sapphire Rapids at its peak operating efficiency point of 16 cores, while achieving 68-80% of the energy efficiency of those platforms. The SG2044 processor itself more than doubles single-core HPL performance compared to its SG2042 predecessor, and an L2-cache-aware thread pinning strategy allows the redesigned memory subsystem to reach near-peak STREAM bandwidth with only 16 threads. The paper identifies the two remaining bottlenecks for RISC-V in HPC as vector unit width and the","pith_inferences":["If vendor-optimized BLAS libraries were developed for the SG2044, the absolute HPL performance gap could narrow further, though the direction and magnitude of this effect remain unquantified in the paper.","The LPDDR5X memory choice on SG2044 (shared with NVIDIA Grace) versus DDR5 on Intel Sapphire Rapids may partially explain why the RISC-V node compares more favorably to Grace than to Sapphire Rapids, suggesting memory technology selection matters as much as ISA for HPC workloads.","The steep improvement from SG2042 to SG2044 across only one generation implies that RISC-V HPC competitiveness may arrive faster than the x86 ecosystem's historical evolution, since RISC-V can leverage mature process nodes and established design patterns from competitors."],"forward_implications":["RISC-V server processors with wider vector units (e.g., 256-bit or 512-bit RVV) could close the remaining raw-performance gap to x86-64 and Arm HPC nodes, making RISC-V a viable drop-in architecture for HPC data centers.","The 10x energy-efficiency improvement across three Monte Cimone generations suggests RISC-V HPC silicon is on a steep improvement curve that may continue as more vendors enter the server-class RISC-V space.","The finding that 16 threads saturate the SG2044 memory subsystem implies that per-core memory bandwidth, not core count, is the current limiting factor for RISC-V HPC scaling — guiding future chip design priorities.","Normalized performance comparisons (by vector width and clock) may become a standard reporting method for cross-architecture HPC benchmarks, complementing absolute-performance rankings."],"fun_headline_variants":["RISC-V SG2044 doubles single-core HPL, approaches Grace on normalized basis","Monte Cimone v3 reaches 3.08 GFLOPs/W with 10x gain over first-gen RISC-V","RISC-V HPC node hits 91% of NVIDIA Grace when normalized for vector width","SG2044 reaches near-peak STREAM bandwidth with cache-aware 16-thread pinning","Monte Cimone v3 trails Intel Sapphire Rapids by 54% on normalized HPL"],"cache_read_input_tokens":0,"weakest_assumption_plain":"The comparison uses OpenBLAS 0.3.29 on all platforms — including Intel and NVIDIA — rather than their vendor-optimized BLAS libraries, because no such library exists yet for the SG2044. This means the competitor baselines may be understated, though the paper asserts the difference is slight without quantifying it.","fun_headline_variants_meta":{"raw":{"variants":["RISC-V SG2044 doubles single-core HPL, approaches Grace on normalized basis","Monte Cimone v3 reaches 3.08 GFLOPs/W with 10x gain over first-gen RISC-V","RISC-V HPC node hits 91% of NVIDIA Grace when normalized for vector width","SG2044 reaches near-peak STREAM bandwidth with cache-aware 16-thread pinning","Monte Cimone v3 trails Intel Sapphire Rapids by 54% on normalized HPL"]},"model":"glm-5.2","effort":"high","cost_usd":0.0,"raw_usage":{"total_tokens":708,"prompt_tokens":585,"completion_tokens":123,"prompt_tokens_details":null},"tokens_in":585,"tokens_out":123,"duration_ms":13010,"temperature":1.0,"reasoning_tokens":null,"cache_read_input_tokens":0,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-07-05T03:13:41.340467+00:00","model_set":{"reader":"glm-5.2"},"falsifier":"If vendor-optimized BLAS on Intel and NVIDIA systems delivers substantially more than 'slightly higher' HPL performance, the normalized gap between RISC-V and competitors would widen, undermining the claim that RISC-V is closing the gap.","supporting_citations":[],"review_version":2}