Open ISA Supercomputing: SG2044 Reaches 294 GFLOP/s at 64 Cores, Beats Xeon on LLM Decode

RISC-V's HPC story has suffered from a measurement problem: every paper used a different board, a different software stack and rarely reported energy at all, so "RISC-V is 5x slower" and "RISC-V is competitive" could both be published about the same year. A preprint submitted to Future Generation Computer Systems on 23 October 2026 fixes the methodology first and the conclusion second — one software stack, one methodology, nine benchmarks, three architectures, and wall power measured properly.

What Was Measured, and Against What

Twelve authors from the University of Bologna and ETH Zurich (Emanuele Venieri, Giacomo Madella, Gabriele Ceccolini, Simone Manoni, Federico Ficarelli, Filippo Barbari, Jenny Lynn Almerol, Elisabetta Boella, Nitin Shukla, Simone Bnà, Luca Benini, Andrea Bartolini) characterise the Sophgo SG2044 — the 64-core RISC-V server SoC — and compare it with two incumbent platforms.

Four HPC benchmarks and four real applications, all built from a common stack:

One methodological detail is worth flagging because it is the difference between a fair test and a benchmark-shaped one: the authors built a version of HPL-MxP linked against OpenBLAS for this work and released it as open source. Without OpenBLAS the RISC-V run would have had no competitive BLAS to sit on, and the mixed-precision number would have been meaningless.

The Numbers

Two of those lines deserve to be read together, because they look contradictory and are not. 294 GFLOP/s across 64 cores is roughly 4.6 GFLOP/s per core at scale against 8.02 GFLOP/s measured for a single core: 57% parallel efficiency by FP64 peak. That is not a bad number for a first-generation 64-core open-ISA part, and it is consistent with the paper's own diagnosis — scaling stops being near-linear after 16 cores because 107 GB/s of shared memory bandwidth saturates, not because the cores are slow. Bandwidth is the wall, not compute.

Monte Cimone: Three RISC-V Generations, One Line

The most useful part of the paper is not the cross-architecture comparison at all — it is the within-RISC-V comparison across the Monte Cimone (MC) cluster generations, an Italian RISC-V HPC testbed. Because these are successive RISC-V systems measured with the same stack, the deltas are pure generational progress, unpolluted by ISA differences.

The MCv1→MCv3 numbers are not a chip refresh, they are a category change — two orders of magnitude in bandwidth and 158× in node FP64 inside one project's lifetime. Anyone planning a three-to-five year RISC-V roadmap should treat those as the observed slope rather than assuming the current part is what they will be competing against.

Where RISC-V Actually Wins Today: LLM Decode

The result that will get quoted is this one: on llama.cpp LLM decode, 64-core SG2044 execution delivered the highest relative scaling and the highest energy efficiency of the three platforms, and exceeded the Intel Xeon 8480+ in throughput.

It is worth being precise about why that is plausible rather than surprising. Autoregressive decode at batch 1 is memory-bound: every token requires streaming the weights, so throughput tracks memory bandwidth and capacity, not FP64 peak or vector width. The SG2044's weakness — narrow vector resources on an older node — is exactly the thing decode does not care about, while its 64 general-purpose cores and aggregate bandwidth are the things it does. That is also exactly the workload profile the authors of a separate study would call a new rather than existing market: decode and agent-style serving are loads without twenty years of x86-tuned legacy software behind them.

The Three Things the Paper Says Are Still Missing

The authors are explicit about attribution: the 8–15× absolute gap reflects narrower vector resources and a less advanced technology node — the first is an ISA-implementation choice, the second is a fab choice. Neither is a property of RISC-V itself, and both are addressable within the same architecture. Their conclusion is correspondingly measured: RISC-V processors are closing the gap, not that they have closed it.

Builder Takeaways

• Use this paper as your neutral baseline. It is the first cross-architecture HPC comparison on one software stack that also reports energy. If a vendor quotes a RISC-V HPC speedup against x86 without a stack description and a watt figure, this is the number to check it against.
• Bandwidth, not TOPS, is the design constraint. 57% FP64 parallel efficiency and a 16-core scaling knee say the same thing: for a 64-core RISC-V design, memory subsystem budget is where the next 2× lives.
• Pick the workload before the ISA. A part that is 8–15× down on FP64 is simultaneously ahead on LLM decode throughput. Neither fact is useful in isolation.
• The MCv1→MCv3 delta (100× bandwidth, 158× FP64, 10× energy) is the real planning input. RISC-V HPC in 2029 will not be this chip with bug fixes.
• OpenBLAS and open-sourced test harnesses matter. The authors shipped the OpenBLAS-linked HPL-MxP they built; that kind of artefact is what makes a benchmark reproducible instead of rhetorical.