REVIEW 4 major objections 4 minor 2 references
RISC-V for HPC: An update of where we are and main action points
T0 review · 4 major / 4 minor · reviewed 2026-08-06 · deepseek-v4-flash
Pith's one-line read The paper claims RISC-V is not yet realistic for large-scale HPC, identifies missing high-performance networking as the top priority, and argues that application portability is not the main problem.
desk verdict A sensible SIG position statement with one small new measurement; the load-bearing generalization from a single CPU is the main soft spot. 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 load-bearing mechanism is a gap analysis built on two comparisons. First, the previously published performance characterisation of the 64-core SG2042 separates compute-bound from memory-bound workloads and shows that the CPU matches server-class performance on the former and loses on the latter; this turns 'RISC-V is slow' into a specific memory-subsystem deficit. Second, Table 1 compares Fortran and C versions of the NPB benchmarks (class C, GCC v13, single core) on the SG2042 and an x86 baseline; the comparable ratios are used to rule out Fortran compiler maturity as a blocker. The paper's prioritisation of action points is then inferred by matching each observed gap to a community effort: networking, memory subsystems, tooling ports, and a vectorisation dialect.
What would settle it
Run NPB class C memory-bound benchmarks on a newer RISC-V CPU with a redesigned memory subsystem; if it matches or beats x86 at comparable core count, the paper's memory-subsystem blocker would no longer hold. Separately, deploy a small RISC-V cluster with a working high-performance interconnect and run distributed-memory benchmarks; if communication bandwidth and latency reach x86 levels, the claim that networking makes RISC-V unrealistic for large-scale HPC would need revision.
Extended reading notes
Core claim
The author's core discovery is that RISC-V's path to HPC is blocked by ecosystem infrastructure, not by the ability to compile and run scientific code. In testing driven by the most popular HPC applications, libraries, and benchmarks, the majority built and ran without issue on RISC-V CPUs, and the NPB Fortran-versus-C speedup ratios on a single core of a current RISC-V CPU were broadly comparable to an x86 server, with the BT benchmark actually substantially better on RISC-V. The same body of work found that the 64-core SG2042 processor performs well on compute-bound workloads, matching a previous-generation server CPU core-for-core and beating lower-core-count x86 chips at full core count, but falls far behind on memory-bandwidth- and latency-bound workloads. The paper also identifies performance-analysis tooling as nearly missing and hardware performance counters as incomplete. Taken together, the diagnosis is that until high-performance networking matures, RISC-V cannot realistically support distributed-memory parallelism at scale, and that memory-subsystem and tooling improvements are the other high-value action points.
Load-bearing premise
The claim that RISC-V is not yet ready for large-scale HPC rests on treating the SG2042 as representative of current RISC-V hardware and on reading Fortran-versus-C speedup ratios as a measure of compiler maturity.
Editorial extensions
If this is right
- If the paper's diagnosis is right, adding mature high-performance networking support is a necessary condition for RISC-V to enter large-scale HPC, and no amount of CPU performance or application portability can substitute for it.
- Next-generation RISC-V CPUs that improve memory bandwidth and latency will matter more for HPC than increased vector width alone, because the current bottleneck is memory, not vectorisation.
- The 'Fortran support is behind' assumption should drop out of the community's priority list; efforts are better spent on tooling and infrastructure.
- Porting existing performance-analysis tools and adding complete hardware performance counters would immediately help HPC developers evaluate RISC-V systems.
- A RISC-V vectorisation dialect in the compiler-framework stack would enable optimisations analogous to those already available for other target architectures.
Reading between the lines
- Editorial inference: the paper's conclusions rest on a single current-generation CPU, the SG2042, and one compiler-benchmark comparison; a broader sweep across newer RISC-V chips with different memory subsystems could change the priority ordering.
- Editorial inference: Fortran-versus-C speedup ratios on a handful of NPB benchmarks measure compiler differences but not absolute Fortran maturity; a fuller test suite with different compiler flags and optimisation levels would be needed to confirm the 'adequate support' conclusion.
- Editorial inference: the paper implies, without testing, that accelerating RISC-V adoption via pragma-based porting will follow the GPU route; this is testable by porting a real GPU-oriented HPC code to a RISC-V accelerator and measuring the developer cost.
- Editorial inference: if networking becomes mature, the next bottleneck could shift to parallel filesystems and system-administration tooling, which the paper lists as secondary but does not measure.
Signed reviews
Editorial analysis
A structured set of objections, weighed in public.
Referee Report
Summary. This extended abstract, submitted on behalf of the RISC-V HPC SIG, argues that RISC-V is not yet ready for large-scale HPC deployment. It identifies three main blockers: memory-subsystem performance on current RISC-V CPUs (specifically the Sophon SG2042), lack of mature high-performance networking, and sparse performance-analysis tooling. It reports that common HPC applications port without difficulty and that Fortran compiler support is not noticeably worse than on x86, using a small NPB benchmark comparison (Table 1). The paper concludes with action points for the community, prioritizing high-performance networking and memory-subsystem improvements.
Significance. The paper's value is that it frames an ecosystem-level assessment with specific, actionable recommendations and is honest about current limitations. If the SG2042 is representative of RISC-V server-class hardware, the identified blockers would indeed be the right priorities for the HPC community. The paper also contributes a useful data point in Table 1 to an ongoing debate about Fortran support. However, the evidence presented in the written artifact is narrow: the core generalizations rest on one CPU and a single small benchmark table with no experimental protocol, so the significance of the claims is currently limited by lack of a transparent sampling frame and methodology.
major comments (4)
- [The state of RISC-V for HPC] The central generalization that RISC-V is 'not yet a realistic proposition for large-scale HPC' is inferred from a characterization of a single CPU, the Sophon SG2042, cited from the author's own prior paper [2]. No evidence is given that the SG2042 is representative of the RISC-V server-class parts that the HPC community would deploy, nor is any list provided of other RISC-V CPUs that were considered and rejected. This matters because the priority ordering of the action points (memory subsystem before networking, tooling) depends on the generality of the SG2042 results. Please either provide a survey of current RISC-V HPC-capable CPUs with a comparison of their memory subsystems, or explicitly scope the claims to the SG2042.
- [Software tooling, Table 1] Table 1 is the only quantitative support for the claim that Fortran compiler support on RISC-V is not a concern, but it is presented without any experimental protocol: there are no repetition counts, no error bars or other variance measures, no statement of compiler flags or optimization levels, and only one baseline (AMD Rome) and one problem class (NPB class C) on a single core. As a result, the per-benchmark ratios (e.g., BT 3.35 on RISC-V versus 1.30 on x86) cannot be distinguished from noise or compiler-flag artifacts. The paper should either provide a documented methodology with enough repetitions to support the ratios, or soften the conclusion from 'Fortran support is comparable' to 'preliminary indications do not show a large gap'.
- [Infrastructure] The claim that high-performance networking is a 'major limitation' and that 'until we address this RISC-V will always be limited when it comes to large-scale HPC deployment' is asserted with only a single example (a prototype Infiniband driver) and no references to the current state of RISC-V networking support across vendors or interconnect technologies. This is a strong, falsifiable claim, but the written artifact provides no survey scope, deployment status, or citations. Please provide a documented overview of what networking support exists (e.g., Ethernet, Infiniband, Omni-Path, custom interconnects) on RISC-V hardware and in Linux drivers, and state how this was assessed.
- [Application support] The statement that 'the majority of these built without issue on RISC-V CPUs and could run common use-cases' is a load-bearing part of the paper's claim that application portability is adequate, yet no data are shown: no list of applications, libraries, or benchmarks considered, no build results, and no description of what 'common use-cases' were run. This evidence would need to be at least summarized in the written artifact (or in an appendix) for the claim to be assessable, given that it is one of the few positive conclusions in the abstract.
minor comments (4)
- [Throughout] Typographical issues: 'maximimise' should be 'maximise', 'belif' should be 'belief', and 'and-so' appears with missing spaces in the Infrastructure section; 'T able 1' has a stray space.
- [Table 1 caption] The caption should specify that times are wall-clock, the exact GCC v13 version, and the optimization flags used, and should indicate whether the ratios are means over repetitions or single-run values.
- [Software tooling] The references for Extrae and the claim about performance tooling are missing; please add citations so readers can verify the state of RISC-V tooling.
- [Introduction] The paper would benefit from a short statement of methodology for the HPC SIG analysis, even in an appendix, so that the reader understands how the conclusions were assembled (e.g., number of systems surveyed, time period, criteria for inclusion).
Circularity Check
No significant circularity: the paper's self-citations are independent measurements, and Table 1 is an original benchmark.
full rationale
This extended abstract is a position/survey piece, not a derivation. Its central claims are supported by prior performance characterisations ([1], [2]) and by an in-house NPB comparison (Table 1). The self-citations are not circular: [2] is an externally falsifiable benchmark study of the SG2042 against x86/ARM baselines, and [1] is an accelerator evaluation against a Xeon CPU. Neither is fitted to the paper's conclusions. Table 1 is an original measurement whose interpretation ('the numbers are fairly comparable') is a direct observation, not a parameter fitted to a predicted outcome. The move from 'SG2042 memory subsystem limits' to 'RISC-V not yet realistic for large-scale HPC' is an inductive generalization that may be under-supported without a stated sampling frame, but that is a correctness/evidence concern, not circularity. No equation reduces to an input, no fitted value is renamed as a prediction, and no uniqueness theorem is imported from the authors' prior work. Under the hard rules, the honest finding is no significant circularity, score 0.
Assumptions & free parameters
assumptions (4)
- domain assumption NPB benchmarks (class C) are representative of typical HPC workloads for assessing compiler and CPU maturity.
- domain assumption HPC community priorities are performance, hardware availability, energy efficiency, cost, and risk.
- domain assumption Data gathered from the world's supercomputers identifies the most popular HPC applications, libraries and benchmarks.
- domain assumption Comparing Fortran-versus-C speedup ratios between RISC-V and x86 is a valid probe of Fortran compiler maturity.
Cite this review
Pith. "Pith review of RISC-V for HPC: An update of where we are and main action points." pith.science (2026). https://pith.science/paper/NPEWPNK6
@misc{pith2026250615418,
author = {Pith},
title = {Pith review of: RISC-V for HPC: An update of where we are and main action points},
year = {2026},
howpublished = {\url{https://pith.science/paper/NPEWPNK6}},
note = {Machine review of arXiv:2506.15418}
}
read the original abstract
This extended abstract is submitted on behalf of the RISC-V HPC SIG who have been undertaking an analysis to explore the current state and limitations of the RISC-V ecosystem for HPC. Whilst it is right to celebrate that there has been great progress made in recent years, we also highlight limitations and where effort should be focussed.
Reference graph
Works this paper leans on
-
[2]
Performance characterisation of the 64-core SG2042 RISC-V CPU for HPC
Nick Brown. “Performance characterisation of the 64-core SG2042 RISC-V CPU for HPC”. In:International Confer- ence on High Performance Computing . 2 RISC-V Summit Europe, Paris, 12-15th May 2025
work page 2025
-
[1]
Accelerating stencils on the Tenstorrent Grayskull RISC-V accelerator
Nick Brown. “Accelerating stencils on the Tenstorrent Grayskull RISC-V accelerator”. In:SC24-W: Workshops of the International Conference for High Performance Computing, Networking, Storage and Analysis
Reviewed August 6, 2026 · model on record in the stance chip above.
Discussion (0). Continue with ORCID to comment.