The FP64 Debate Didn't Produce a Winner. It Produced a Joint Byline.

When SCN set up the FP64 standoff on June 15, the story had a familiar shape. Satoshi Matsuoka's "FP8 is All You Need" papers argued that native double-precision silicon could be demoted to a derived accuracy guarantee, recovered through Ozaki-scheme emulation on the FP8 tensor cores the AI market is already paying for. Jack Dongarra was the credentialed skeptic. ISC was where the two positions would finally meet, and we promised the payoff once it did.

The payoff is dated June 19, (still unpublished, but readable at this link) and it is not a verdict. It is a joint byline. "Do We Still Need GPUs? Rethinking AI and Scientific Computing on Matrix-Enhanced CPUs," a revised submission to Communications of the ACM, carries three names: Dongarra, Torsten Hoefler of ETH Zurich, and Matsuoka. The two principals of the precision debate, joined by a third author whose data-movement research the paper builds on, co-authored an answer to a bigger question than the one they were supposed to be fighting over.

The collaboration was visible in the documents before it reached a byline. Matsuoka revised both solo papers in response to Dongarra's review comments. Part 1 publicly corrected its own headline number after NVIDIA's DevTech team flagged an error, cutting the emulated dense-FP64 ceiling on the B300 to about 135 TFLOPS, roughly 104 times Matsuoka's 1.3 TFLOPS datasheet reading of the native floor. Part 2's insistence on separating projected results from measured ones traces directly to Dongarra's comments. And Matsuoka told us, in remarks we quoted last month, that he "welcome[s] being proven (at least partially) wrong by my best friend Jack Dongarra." That read as a grace note in June. It reads as a paper trail now.

Note the chronology, too. The joint paper predates Dongarra's ISC closing keynote by four days. When his keynote slide argued that "AI does not fundamentally require a GPU... GPUs happen to provide that combination very well today," he was previewing a paper he had already written with Matsuoka. The question he posed from the stage was, quite literally, a title.

What the three of them argue

The paper's case runs like this. GPUs became indispensable because conventional CPUs lacked parallel arithmetic capability and memory bandwidth, and for no deeper reason. Absorb those features into the CPU itself, wide vectors through SVE or AVX, matrix engines through SME or AMX, on-package HBM, native precisions from FP64 down to FP4, and the historical justification for a discrete accelerator starts to dissolve. The thesis, in the authors' own words: "A CPU with SVE/AVX, SME/AMX, HBM, multiple precision formats, and matrix-multiply capability is no longer a conventional CPU. It is a general-purpose processor with accelerator-class numerical machinery."

The authors are careful about scope. GPUs "will remain vital for frontier-scale AI training," and the argument concerns what is fundamentally required rather than what is useless. Their preferred reframe is the one Dongarra aired at ISC: the right question "is not 'Do we need GPUs?' but rather 'What architectural features do we need?'" Bandwidth, dense linear algebra, the full precision ladder, compilers, and a programming model working scientists can use: provide those, and the label on the package is secondary.

The Next Platform's Tim Prickett Morgan, whose June 30 write-up is the coverage of record so far, called the argument heretical-sounding given NVIDIA's dominance and then granted its logic, speculating that NVIDIA's long-run answer might be to build tensor cores into its own Arm CPUs and carry the CUDA-X libraries across. That speculation is his, worth carrying as analysis.

Measured where it can be, projected where it can't

What separates this from a position paper is the empirical companion the authors summarize, with the comprehensive study in preparation for arXiv.

The choice of test is deliberate. For the memory-bound and sparse kernels that dominate traditional simulation, the authors treat the thesis as demonstrated: Fugaku's matrix-engine-poor A64FX led the Top500, HPCG, and Graph500 simultaneously in 2020. Modern AI is the regime where the GPU advantage is still perceived as decisive, so the test goes there. The workload is production long-context inference, a 256K-token context on Kimi-K2, a trillion-parameter mixture-of-experts model, with the full modern acceleration stack assumed on both sides: INT4 quantization-aware weights, INT4/INT8 KV-cache quantization, DeepSeek Sparse Attention, and EAGLE-3 speculative decoding. The authors are explicit that sparse attention enters as a projected sensitivity from DeepSeek-V3.2 rather than a result co-validated on K2.

Two real Arm CPUs bracket the argument. The A64FX is the control: wide SVE vectors and 32 GB of on-package HBM at about 1 TB/s per node, no matrix engine. The LX2, the socket inside China's new Top500 leader, adds the engine: SVE and SME on every core, 32 GB of HBM at 4 TB/s, and, on the published specifications the paper cites, 240 TF of BF16 and 960 TOPS of INT8 matrix throughput per socket.

The results split along the two halves of the thesis. Decode, the token-by-token generation phase that dominates the cost of long-context serving, is measured and already holds. The study finds K2 decode roughly 80% bound by memory bandwidth and only about 1% by floating-point throughput, and roughly 48 A64FX nodes match the decode throughput of a current GB200 NVL4 GPU node, achieved on a CPU with no matrix engine at all. Prefill, the compute-bound processing of the input prompt, is where a matrix engine earns its place, and here the paper is scrupulous: parity is a range, not a number. Against a sensibly balanced GPU baseline with sparse attention enabled, the target is about 80 TF per node, roughly a sixfold uplift over the A64FX. Against a maximal, dense, fastest-GPU baseline it climbs past 750 TF. The LX2's published 240 TF of BF16 clears the feasible bar three times over, and its INT8 figure exceeds even the maximal one. Those are specification numbers, though. The A64FX decode results are measurements; the LX2 prefill results are projections awaiting direct validation, an asymmetry the paper keeps explicit on nearly every page, and one we keep explicit here.

Three qualifiers follow, and the authors' verdict is that none overturns the result. The interconnect turns out to be a question of parallelization strategy instead of feasibility: a weak torus like Fugaku's Tofu-D (roughly 6 GB/s of achieved all-reduce) forces prefill onto pipeline parallelism, while the LX2's Ethernet-class fabric, at roughly ten times that, lets plain tensor parallelism work for both phases. Energy is a real premium, sized honestly: an all-LX2 machine draws roughly 1.75 to 2.7 times the per-user power of a fleet of the newest HBM3e GPUs. The paper's diagnosis is that the premium is generational rather than architectural. The LX2 carries HBM2-class memory against the GPUs' HBM3e and lacks an FP8 path for prefill, and an HBM3e-class CPU with FP8-capable SME, both on public roadmaps, "would erase most of the difference." The third qualifier is precision itself: whether INT8's quantization grid is fine enough for accurate long-context prefill, or whether FP8, "expected in a future generation of SME," will be required, is an open empirical question.

What happens to "FP8 is all you need"

Then there is the passage that matters most for the June debate, because the joint paper takes a position on Matsuoka's own solo thesis.

Recall the boundary the skeptics drew. Dongarra, in the ISC keynote Q&A, called Ozaki emulation "a wonderful algorithm" that wins for matrix multiply and doesn't help vector or scalar operations. Two weeks earlier, AMD's director of AI and supercomputing, Joseph George, heard Matsuoka present Part 1 at the Trillion Parameter Consortium's all-hands and drew the same line for HPCwire: "If it's matrix, I could see Ozaki working really well for something like that. But if it's anything else, there's now a question of, is the validity there." The stakes are already institutional: NVIDIA ships Ozaki in cuBLAS, and DOE's Genesis Mission has named the scheme its fallback path for FP64. Matsuoka's Part 2 was a direct assault on the skeptics' line, projecting a full-FP64 3-D FFT at essentially the memory roof by routing reconstruction through a Kulisch fixed-point accumulator. Projected, and labeled as such.

The joint paper cites Part 1 and then grades the whole program. Low-precision decomposition as a common computational primitive across AI and science is "a research hypothesis rather than an established result," likely to apply "most naturally to dense matrix operations rather than uniformly across sparse, irregular, communication-intensive, or general-purpose scientific workloads." And then comes the sentence that bounds the thesis on the very machine the paper holds up as its proof vehicle: "On the current LX2, which supports modest INT8 relative to its strong FP64, and not FP8, native FP64 remains the more appropriate path outside dense matrix multiplication. The research question concerns the capabilities of future matrix-enabled CPUs, not a claim about the present chip."

That is the boundary Dongarra drew at ISC and George drew at TPC26, now printed in a paper with Matsuoka's name on it.

Set the solo papers beside the joint one and readers will ask the obvious question: which does Matsuoka believe? Both, and he explained the structure before the joint paper surfaced. In correspondence before ISC, he framed the solo papers as upper-bound documents in the tradition of the Berkeley Dwarfs paper. They "establish the theoretical grounds saying that, if the premise is true, then FP8 is all you need," with composition overheads and corner cases staged as the next round of questions and the engineering questions after that. On that structure, the solo papers argue the maximal bound as hard as it can be argued, while the joint paper records what three careful authors will jointly sign as established in June 2026. The joint paper leaves the hypothesis standing and files it, in writing, as a hypothesis with a research program attached. Readers who want the maximal case should read Part 1 and Part 2; readers who want to know where the three authors' published common ground sits have one sentence to point to.

AMD's boundary now has establishment co-signers

AMD is the one major vendor still building up native FP64. Its forthcoming MI430X, slated for DOE's Discovery, the Frontier successor at Oak Ridge, is positioned as the coherent native-double-precision alternative, and Matsuoka's Part 1 names it as evidence that "not every vendor is convinced that emulation alone is sufficient." The numbers are firming up: HPCwire extrapolated roughly 192 to 204 TFLOPS of FP64 from AMD Fellow Nick Malaya's March remarks, and AMD has since publicly previewed the part as projected to deliver more than 200 TFLOPS of native FP64.

In June, George's stance read as a vendor holding a line against an academic wave. "Precision matters in a very, very, very big way," he told HPCwire. "You can approximate in other places in AI. When it comes to science and all the industries that we care about, precision is critically important." On seismic analysis: "We absolutely cannot get away from FP64 for things like seismic analysis. We just can't do it." His summary was a deferral to the workload: "It's not 'FP64 or nothing.' It is what the science requires."

After June 19, the same quotes read differently. Three of the field's most cited people, including the author of "FP8 is All You Need," have jointly written that on today's shipping silicon, native FP64 remains the more appropriate path outside dense matrix multiplication. That is no endorsement of AMD's roadmap, and the paper's sentence concerns a specific CPU. But George's boundary and the joint paper's sit in the same place, and AMD's stance no longer reads as swimming against the field's direction of travel.

Asked for fresh comment on the joint paper, AMD declined.

LineShine, promoted from complication to test vehicle

When China's LineShine took the Top500 crown on June 24 with no GPUs anywhere in the machine, we covered it as the complication in the FP64 story. The joint paper assigns it a more specific role: the experiment. Its LX2 socket is the hardware on which the matrix-engine half of the thesis is met on paper and awaiting measurement, and the paper describes the machine, in its own words, as "a deployed instance" of exactly the processor class the authors are arguing for. The system is the one SCN reported in June: 2.198 EFLOPS on Linpack, first on HPCG as well, ARMv9 cores with both vector and matrix extensions, HBM on every socket, a domestic interconnect and operating system, El Capitan displaced. Its co-design lineage runs through Fugaku, whose successor program has already walked away from the Top500 chase; the paper's control CPU and its test CPU are, not coincidentally, the field's two co-design exemplars. The Next Platform estimates the LX2 is likely fabbed on SMIC's 7 nm process at around 650 W per socket, and notes that roughly half the Top500 still runs CPU-only; those figures are Morgan's extrapolations, flagged as such.

On why anyone builds such a machine today, the paper is blunt. The distance to the GPU frontier is "a matter of engineering and timing, which makes the decision to build a GPU-free machine, for now, largely one of sovereignty and supply rather than of absolute energy efficiency, on current estimates." For a Chinese national center that cannot reliably buy NVIDIA parts under export controls, GPU-free is a supply-chain fact before it is an architectural preference. The same supply pressure runs the other way in the West, where commercial AI has been pre-purchasing the infrastructure scientific computing was counting on.

One number from the keynote survives the reframe intact. Dongarra noted in his spoken ISC remarks that LineShine runs at about 0.8% of theoretical peak on HPCG. The machine that tops the Top500 and HPCG and anchors the joint paper's empirical case reaches under one percent of peak on the workload-representative benchmark; his case for retiring peak-FLOPS thinking in favor of joules per trusted solution fits in that figure.

What's still unmeasured

The authors end on their own to-do list, and it reads like a news budget. Direct hardware measurement of the LX2 projections is, in their words, "the explicit next step." FP8 is "expected in a future generation of SME," and whether INT8's quantization grid suffices for accurate long-context prefill is a question the current chip cannot answer. The comprehensive companion study, with the full models, measurements, and power accounting, is in preparation for arXiv. Part 2's validation program, measured Ozaki results beyond dense matrix multiply, remains the test of the maximal thesis. And the paper names the gap hardware cannot close on its own: "The largest non-hardware gap remains software maturity," with GPU libraries deeply optimized after two decades and CPU matrix engines needing comparable compiler, kernel, and runtime support before the specifications turn into delivered performance. The question that opened in June is now jointly owned, and every item still open on it is a measurement.

Disclosure: Supercomputing News publisher Matt Walters is named in the acknowledgements of Matsuoka's revised Part 1 ("discussions that helped sharpen the framing of the thesis"). The analysis here is independent; the relationship is disclosed in the interest of transparency, consistent with our June 15 coverage.

A note on AI assistance across this story: Matsuoka's solo papers disclose that they were drafted with Anthropic's Claude (Opus 4.7) and Gemini 3 under the author's direction, and the joint Dongarra, Hoefler, and Matsuoka paper discloses that the authors used Claude (Opus 4.8) for drafting, consistency checking, and arithmetic review, with critical review comments from OpenAI's ChatGPT (GPT-5.5). Every side of a debate about numerical rigor is now itself AI-assisted, and the authors' practice of disclosing it models the transparency the field will need.

This article was prepared with AI assistance for research and drafting under the named writer's direction and editorial control, per SCN house style.