Papers for

gpu software engineers

Papers whose findings have a practical use for this group, as judged from the abstract. Open a paper to read what it means in practice.

Tensor superoptimizer boosts gpu program speed by up to three times

Unleashing the Power of Equality Saturation for Tensor Program Superoptimization

Abstract: Efficient GPU implementations of tensor programs often require joint optimization of high-level algebraic formulations and low-level execution strategies. However, the resulting search space grows rapidly as transformations combine across operators, making joint optimization difficult to scale. We present EqiForge, a tensor program superoptimizer based on equality saturation. Its unified IR represents high-level tensor expressions and tiled computations in a single expression language. By composing equality rules, EqiForge derives fused implementations such as FlashAttention-style kernels directly from tensor expressions. Early compaction prunes redundant partial programs before completion, while subgraph composition extends the search to larger graphs. Across tensor-program benchmarks, EqiForge achieves a geometric mean speedup of 1.32x and a maximum of 2.74x over the fastest available baseline per configuration. Its attention kernels outperform FlashAttention by up to 1.87x in decode and approach its performance in prefill. EqiForge also discovers new implementations that outperform torch.compile on various Transformer layers, including QK-normalized MLA (3.16x) and mHC (5.84x).

Fri 11 SeptDistributed, Parallel, and Cluster Computing
The gist
Making programs that run on graphics cards faster is tricky because there are many ways to change the program, and trying them all takes too long. The authors created EqiForge, a tool that uses a special method called equality saturation to explore many program changes efficiently. EqiForge finds better ways to run tensor math, which is common in AI tasks, making programs up to three times faster than current methods. It can also discover new fast versions of parts used in popular AI models.
Open 2609.12330v1

Code generation simplified by clear computational models for gpu kernels

The Art of Closed-Formula Defaults: Search-Free Code Generation for Tensor Operators

Abstract: Agentic search and automated optimization of GPU kernels are powerful tools for large language model inference. Their effectiveness, however, depends not on the sophistication of the search itself, but on the clarity of the optimization problem being solved. We provide an application-first approach that drives a hierarchical code generation tool from operator specifi cation down to GPU instructions, and show that a clearly defined computational model makes the optimization problem tractable.

Thu 10 SeptMathematical Software
The gist
Generating efficient code for GPUs, which are computer chips used in tasks like AI, is tricky because the optimization problems can be complicated. The authors found that clearly defining the rules and structure of the computations makes it easier to generate optimized GPU code without needing expensive searching methods. They built a step-by-step tool that starts with describing math operations and ends with GPU instructions, making the whole process more straightforward and faster.
Open 2609.10937v1

Fp64 emulation gains speed on Nvidia Rubin GPUs with fp8 tensor cores

Ozaki 2.5: Engineering the Deconstruction Path of fp64-Emulated Dense Matrix Multiplication on FP8 Tensor Cores

Abstract: FP8 Ozaki II emulates FP64 matrix multiplication by tensor-core products over a CRT residue system; converting the operands into residue planes (the deconstruction term in the Tensor-Memory Equilibrium model of the companion paper "FP8 is All You Need, Part 1") costs integer-pipe and memory resources before tensor instructions issue. This paper engineers that path; every result is a model projection pending measurement. First, a deconstruction-aware model: on the NVIDIA Rubin GPU the emulated rate reaches the arithmetic roof $P_{\rm FP8}/(3r+1)$ ($\approx 473$ TFLOPS at $r=12$) only within one thread-block cluster; larger outputs are re-split on the fly and held at a floor of $\approx 235$ TFLOPS (half the roof, a ratio of three design integers, not a fit), while real solvers' tall/skinny shapes stay near the crossover, $1.6$-$1.9\times$ over simple deconstruction today. Second, the method: convert-once residue workspaces, an exact two-limb constant-reduction GEMM on integer tensor pipes (or pure-SIMT dp4a), and conversion pipelined behind the MMAs, moving the crossover from $\approx 1211$ to $\approx 480$-$730$. Third, modulus co-design: all-byte and hybrid sets, two supply bounds and a carry-corrected E4M3 split of tail moduli. Fourth and central, the closed-form floor names its hardware escape, and the prize is Rubin's: a stream-side residue-conversion mode on the asynchronous copy path (Option C), a narrow fixed-function block sized as a bill of materials, takes plane formation off the arithmetic pipes and lifts the floor from 235 TFLOPS to the full 473-TFLOPS roof at unchanged cluster reach, about doubling HPL-class FP64 per Rubin GPU, and unbinds conversion-bound sparse kernels. The NVIDIA GB300 GPU, whose 135-TFLOPS roof sits at its own floor, gains little; floor and remedy are Rubin-scale. Application traces ground the analysis; constants are script-checked.

Tue 8 SeptMathematical SoftwareHardware ArchitectureDistributed, Parallel, and Cluster Computing
The gist
Performing precise FP64 (double-precision) matrix multiplication on GPUs is slow and costly. The authors show a way to speed this up by breaking down FP64 operations into many simpler FP8 operations using the CRT (Chinese Remainder Theorem) system and careful engineering on NVIDIA Rubin GPUs. They modeled and improved the conversion steps to greatly increase computation speed, almost doubling performance for some large matrix problems. This method exploits special hardware and memory pathways to avoid bottlenecks seen on other GPUs like the NVIDIA GB300.
Open 2609.09095v1