Interface for Sparse Linear Algebra Operations

Ahmad Abdelfattah; Willow Ahrens; Hartwig Anzt; Chris Armstrong; Ben Brock; Aydin Buluc; Federico Busato; Terry Cojean; Tim Davis; Jim Demmel; Grace Dinh; David Gardener; Jan Fiala; Mark Gates; Azzam Haider; Toshiyuki Imamura; Pedro Valero Lara; Jose Moreira; Sherry Li; Piotr Luszczek; Max Melichenko; Jose Moeira; Yvan Mokwinski; Riley Murray; Spencer Patty; Slaven Peles; Tobias Ribizel; Jason Riedy; Siva Rajamanickam; Piyush Sao; Manu Shantharam; Keita Teranishi; Stan Tomov; Yu-Hsiang Tsai; Heiko Weichelt

arXiv · 2411.13259

Interface for Sparse Linear Algebra Operations

View original source ↗Read source document ↗Export metadata ↓

Abstract

The standardization of an interface for dense linear algebra operations in the BLAS standard has enabled interoperability between different linear algebra libraries, thereby boosting the success of scientific computing, in particular in scientific HPC. Despite numerous efforts in the past, the community has not yet agreed on a standardization for sparse linear algebra operations due to numerous reasons. One is the fact that sparse linear algebra objects allow for many different storage formats, and different hardware may favor different storage formats. This makes the definition of a FORTRAN-style all-circumventing interface extremely challenging. Another reason is that opposed to dense linear algebra functionality, in sparse linear algebra, the size of the sparse data structure for the operation result is not always known prior to the information. Furthermore, as opposed to the standardization effort for dense linear algebra, we are late in the technology readiness cycle, and many production-ready software libraries using sparse linear algebra routines have implemented and committed to their own sparse BLAS interface. At the same time, there exists a demand for standardization that would improve interoperability, and sustainability, and allow for easier integration of building blocks. In an inclusive, cross-institutional effort involving numerous academic institutions, US National Labs, and industry, we spent two years designing a hardware-portable interface for basic sparse linear algebra functionality that serves the user needs and is compatible with the different interfaces currently used by different vendors. In this paper, we present a C++ API for sparse linear algebra functionality, discuss the design choices, and detail how software developers preserve a lot of freedom in terms of how to implement functionality behind this API.

Explore related subjects

cs.MS

Keep this discovery

BibTeX RIS

Ahmad Abdelfattah, Willow Ahrens, Hartwig Anzt, Chris Armstrong, Ben Brock, Aydin Buluc, Federico Busato, Terry Cojean, Tim Davis, Jim Demmel, Grace Dinh, David Gardener, Jan Fiala, Mark Gates, Azzam Haider, Toshiyuki Imamura, Pedro Valero Lara, Jose Moreira, Sherry Li, Piotr Luszczek, Max Melichenko, Jose Moeira, Yvan Mokwinski, Riley Murray, Spencer Patty, Slaven Peles, Tobias Ribizel, Jason Riedy, Siva Rajamanickam, Piyush Sao, Manu Shantharam, Keita Teranishi, Stan Tomov, Yu-Hsiang Tsai, Heiko Weichelt. 2024-11-20. Interface for Sparse Linear Algebra Operations. https://arxiv.org/abs/2411.13259

Cite the original work for its findings. Save a collection to share your selection of sources.

KEEP EXPLORING

Related papers

arXiv2026

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

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.

cs.MS↗

arXiv2026

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

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.

cs.MS↗

arXiv2026

Geometric Function Atlas: certified computing for geometric function theory in Python

We describe geometric-function-atlas, our open-source Python package for the sharp extremal problems of geometric function theory. We organise it around a catalogue of thirty-nine Ma--Minda starlike generators. From this catalogue we compute exact Taylor coefficients, closed-form Fekete--Szeg\H{o} constants, exact coefficients of the Ma--Minda extremal function, and admissibility screens. Our verifier answers membership questions for normalised polynomials at three levels of evidence: a floating-point grid screen, an exact sufficient condition decided in rational arithmetic, and a certified interval enclosure at the worst screened point. Every answer names the level at which we obtained it. We ship a checksummed artifact snapshot with three hundred and six coefficient certificates and seven hundred and two directed inclusion radii. Eight reviewed radius lanes carry certificates whose proof chains we replay symbolically, and we re-execute every coefficient certificate through our exact Schur-parameter machinery on request. We emit all results through one versioned envelope that records the method, the evidence status, the assumptions, and the artifact identifiers. Two optional laboratories apply the same discipline to cryptographic S-box metrics and to image-quality metrics. We present our design, state as propositions what each tier establishes, follow one radius lane from screen to replayed certificate, report measured timings, and place our package among symbolic-algebra, rigorous-numerics, and mathematical-database software. We release geometric-function-atlas under the MIT licence on the Python Package Index and at https://github.com/Prasanna28Devadiga/geometric-function-atlas.

cs.MS↗