Papers for

high-performance computing developers

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.

Ozaki scheme enables faster accurate chained tensor calculations

You Only Convert Twice: Ozaki Scheme II for Chained Tensor Mode Products

Abstract: This work proposes OzII-RescaleBE, a method that enables persistent execution of chained tensor mode products in Ozaki scheme II, keeping the intermediate tensors in residue form. By performing rescaling and base extension directly on the residue representation, it requires conversion to residues only at the beginning of the chain and reconstruction only at the end. An implementation using CuTe DSL and INT8 Tensor Cores is provided for verification and evaluation. The method is compared with per-mode composition of Ozaki scheme~II (GEMMul8-Composed) and a dense Kronecker-product formulation (GEMMul8-KRON), both implemented using the GEMMul8 library. Across three datasets with different input distributions, OzII-RescaleBE achieves normwise relative errors ranging from $2.5\times10^{-16}$ to $2.6\times10^{-15}$ for chain depths $d=3$ through $7$. The corresponding errors range from $10^{-16}$ to $10^{-15}$ for GEMMul8-KRON and from $1\times10^{-16}$ to $3\times10^{-16}$ for GEMMul8-Composed and the FP64 chain. At $d=8$, the errors of OzII-RescaleBE increase to between $7\times10^{-14}$ and $6\times10^{-13}$. For mode sizes $n=8$ to $256$, OzII-RescaleBE achieves throughputs ranging from 1.47 to 4.42\,GDoF/s. Its throughput is within 12\,\% of GEMMul8-KRON at $n=8$ and $12$ and exceeds it at larger tested sizes. Compared with GEMMul8-Composed, OzII-RescaleBE achieves $2.1$--$60\times$ the throughput for $n\leq128$, but has 6--12\,\% lower throughput at $n=256$. It also uses less device memory than the GEMMul8 baselines in the measured memory comparisons. These results demonstrate that rescaling and base extension enable accurate residue-domain tensor chains while avoiding repeated intermediate conversions to floating point.

Sun 4 OctDistributed, Parallel, and Cluster Computing
The gist
Tensor calculations often involve many steps that convert data back and forth between formats, which slows things down. The authors propose a method to keep intermediate data in a special residue format during chained tensor multiplications, converting only at the start and end. This approach reduces repeated conversions, achieving speeds similar to or better than existing methods while maintaining high accuracy across multiple data sizes and chain lengths. Their implementation on specialized hardware confirms these benefits.
Open → 2610.05059v1

Gpu optimization accelerates quantum simulations of helium atom clusters

AI-Assisted GPU optimization of the Stochastic Variational Method for Few-Body Boson System

Abstract: The stochastic variational method (SVM) is one of the most powerful methods to solve quantum few-body systems precisely in various fields, such as nuclear and atomic physics. To the best of our knowledge, no SVM code optimized for GPUs has been reported. We developed a parallel SVM code for few-body clusters of $^4$He atoms and optimized it for two GPU architectures, NVIDIA GH200 and AMD Instinct MI300A, with the entire code written by an AI coding agent. On the algorithmic side, we introduce the secular-equation method with the Gu--Eisenstat prescription for solving the generalized eigenvalue problem within the SVM framework. The main part of the code tuning is to batch the many small matrices so that the GPUs are used efficiently, together with an array layout in memory optimized for coalesced addressing. For the five-body system with 4800 SVM basis states, the tuned SVM code runs 16.2 (14.7) times faster on the NVIDIA GH200 (AMD MI300A) than the same tuned code on the Intel Xeon Max CPU system, and 168 (153) times faster than the first working CPU implementation. The achieved performance brings 6-body and larger cluster systems within reach.

Fri 2 OctDistributed, Parallel, and Cluster Computing
The gist
Simulating tiny groups of helium atoms is important but very slow on regular computers. The authors created new computer code that uses graphics cards (GPUs) and artificial intelligence to speed up these simulations by more than 16 times on advanced GPUs. Their method batches many small calculations together and arranges data for efficient GPU use. This makes studying larger groups of atoms possible with much less waiting time.
Open → 2610.02745v1

Splyce boosts sparse tensor processing by removing control flow bottlenecks

Splyce: SIMD Vectorization of Sparse Coiteration

Abstract: Sparse tensor contractions are bottlenecked by sparse-sparse coiteration loops that resist standard loop vectorization. We present Splyce, an auto-vectorization framework in MLIR that overcomes this through a dual-path execution model. By decoupling coordinate intersection from pointer management via selective predication, Splyce inherently eliminates data-dependent branches as a side effect, allowing modern superscalar engines to maximize instruction-level parallelism and hide memory latency. Beyond simple branch elimination, our transformation exposes independent computation that can be executed concurrently, increasing functional-unit utilization that would otherwise be constrained by sequential dependencies. Evaluation across foundational sparse tensor kernels demonstrates performance ranging from 1.96X to 2.86X on synthetic inputs, with consistent speedups sustained across a vast majority of irregular real-world datasets from the SuiteSparse collection. Ultimately, Splyce demonstrates that by converting unpredictable control-flow into a predictable data stream, compiler-driven speculation can effectively reconcile the memory efficiency of compressed storage with the execution-unit throughput of modern superscalar architectures.

Wed 16 SeptProgramming LanguagesHardware ArchitecturePerformance
The gist
Sparse tensor operations are important but slow because they involve complex loops that are hard for computers to speed up. The authors created Splyce, a new way for compilers to turn these tricky loops into simpler code without unpredictable branches, letting the computer do many steps at once more efficiently. This approach made common sparse tensor tasks run nearly twice to almost three times faster in tests. Splyce works by translating irregular data patterns into a steady flow, so modern processors can handle them better.
Open → 2609.19410v1

Expose safe low level gpu programming to improve tensor core performance

Exo-GPU: Safe, Imperative, User-schedulable Programming for Tensor Cores

Abstract: Modern GPUs require not only SIMT-style parallelism but also software-managed concurrency between compute and data movement to reach maximum performance. Performance engineers must reason about subdividing work into the hierarchy of computation resources (threads, warps, warpgroups, blocks, clusters), and, in many cases, also must use asynchronous tensor core and memcpy instructions on different levels of the memory hierarchy (registers, tensor core accumulators, shared memory, global memory). Unlike CPUs, where out-of-order execution is managed by hardware and hidden from programmers, GPUs expose explicit instruction reordering to software through these asynchronous instructions. Well-established GPU programming languages generally offer either direct low-level control without safety guarantees (e.g., CUDA C++ inline assembly or intrinsics) or easier-to-analyze, high-level abstractions (e.g., Triton's tile-based model) that hide asynchronous instructions in the compiler backend, which may prevent performance engineers from maximizing performance by tuning critical details. We propose Exo-GPU, an imperative, low-level language that creates minimal abstraction over CUDA. Our key idea is to treat parallelism and synchronization as mere annotations on sequential code rather than as fundamental control flow primitives, enabling verification that these constructs do not alter the program semantics. The benefit is twofold: programmers can reason about code without hidden control flow or mutation, while allowing the Exo-GPU compiler to verify sequential-parallel equivalence--guaranteeing that parallel execution is functionally equivalent to its sequential interpretation. We used Exo-GPU to author GEMM kernels for the H100 GPU, using wgmma, TMA, and split-k. Our kernels achieved over 80% of theoretical peak on large problem sizes, in some cases outperforming the vendor-provided CUBLAS library.

Mon 14 SeptProgramming Languages
The gist
Using modern GPUs for fast math needs careful control of how work is split and coordinated. The authors designed Exo-GPU, a programming language that lets developers write low-level GPU code safely by marking parallelism as annotations rather than core parts of code flow. This design helps ensure parallel execution behaves the same as running steps one after another. They used Exo-GPU to build matrix multiplication programs that run very close to GPU speed limits and sometimes beat the official library.
Open → 2609.16389v1

Python framework enables fast quantum computing across CPUs GPUs and FPGAs

Python in the front, party in the Backline: compiling quantum workloads across CPUs, GPUs, and FPGAs

Abstract: Moving from quantum research and development to production-grade, fault-tolerant quantum workload execution remains one of the most significant challenges facing quantum platform builders. While Python frameworks have enabled an easy entry point for quantum algorithm design, the low-latency requirements for real-time quantum error correction (QEC) demand performance that traditional interpreted environments cannot provide. FPGAs and ASICs play a central role at these layers, but their specialized programming models make development rigid and time-consuming. CPUs, GPUs, and other accelerators introduce a different challenge: as infrastructure becomes increasingly heterogeneous, programming across different devices and their associated abstractions becomes more complex. Allowing researchers to write workloads in high-level languages that map to low-latency execution across diverse distributed target platforms will enable the development of key infrastructure for utility-scale quantum systems. For this, we introduce $\textit{Backline}$, a heterogeneous compilation and runtime framework built within PennyLane and Catalyst. Backline allows us to design and build quantum-classical workloads for high-performance and low-latency devices, with compilation directly from a Python interface through MLIR. We demonstrate the compilation and execution of several quantum workloads with low-latency data movement across a mix of CPUs, GPUs, and FPGAs, for both local and distributed remote hardware targets, all from a vendor-agnostic Python frontend. With an AMD VPK120 FPGA board as the controller, issuing each round from its hardware-handshake engine, we measured median steady-state round-trip latencies over RoCE v2 of $2.305~μ$s to an AMD Ryzen Threadripper PRO CPU and $4.5~μ$s to an AMD Instinct MI210 GPU across $10^6-1$ rounds per path, demonstrating microsecond-scale synchronous co-processing.

Tue 8 SeptDistributed, Parallel, and Cluster ComputingProgramming Languages
The gist
Quantum computers need both smart software and fast hardware to run complex calculations reliably. The authors created Backline, a tool that lets programmers write quantum tasks in Python, which then run quickly on different hardware like CPUs, GPUs, and FPGAs. This helps combine easy coding with the speed needed for real-time quantum error correction. They showed their system could send and receive data in just a few microseconds between devices, which is important for future quantum machines.
Open → 2609.09270v1

New sample-based method speeds exact Top-K sparse attention on GPU

Sample-Guided Exact Top-K Selection for Long-Context Sparse Attention

Abstract: Sparse attention bounds downstream attention work by retaining a fixed-size subset of indexed tokens, but its standalone exact Top-$K$ stage must still process materialized score rows whose length grows with context. Production radix selectors discover their first actionable boundary only after a complete-row pass, forcing another row-scale traversal before exact refinement. We observe that locating a compact upper tail requires substantially less resolution than identifying the exact rank boundary, and that fixed-stride partial views of the current row remain calibrated to the corresponding complete-row rank across ragged lengths. We present HPC-Ops Top-K, a sample-guided exact selector for ragged sparse-attention score rows. A fixed-stride view proposes a row-local coarse boundary; the mandatory complete-row pass certifies its sufficiency, forms the admitted candidate set, and initializes exact FP32 refinement over the unresolved frontier. A nested secondary boundary and exact recovery handle underfilled proposals before any output is committed, so sampling controls common-path work but never correctness. The GPU implementation fuses complete-row certification and candidate formation, and combines persistent, KV-split, and direct-exact execution behind graph-capturable ragged-row dispatch. We evaluate HPC-Ops Top-K on indexer scores from Hy4-Preview. It outperforms the fastest verified external exact baseline by $1.29$--$1.75\times$ across 20 operator configurations, with a $1.55\times$ geometric-mean speedup. It further achieves $1.36\times$ and $1.48\times$ speedups on two framework-derived sparse-attention traces. The implementation is available in HPC-Ops, Tencent's open-source high-performance operator library for LLM inference, at https://github.com/Tencent/hpc-ops.

Tue 8 SeptDistributed, Parallel, and Cluster Computing
The gist
Large language models use complex attention mechanisms that need to select the most important tokens from a long context quickly. The authors found that looking at a small, spaced sample of data first can guide the exact selection process more efficiently without losing accuracy. They implemented this method on GPUs and showed it is about 1.3 to 1.7 times faster than previous exact methods across many test cases. This improvement helps make large models work faster during inference.
Open → 2609.08450v1