Pith. sign in

REVIEW 3 major objections 7 minor 1 cited by

Interface for Sparse Linear Algebra Operations

T0 review · 3 major / 7 minor · reviewed 2026-08-12 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read Proposed C++ Sparse BLAS interface targets portability across vendors and accelerators.

desk verdict A serious standards proposal with a genuinely useful multi-stage API design, but the output-allocation workflow is underspecified and the portability claims are unvalidated. read the letter →

arxiv 2411.13259 v1 pith:PG2FIV4P submitted 2024-11-20 cs.MS

Ahmad Abdelfattah , Willow Ahrens , Hartwig Anzt , Chris Armstrong , Ben Brock , Aydin Buluc , Federico Busato , Terry Cojean
show 27 more authors
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
This is my paper · ORCID
classification cs.MS MSC 65F50
keywords sparselinearalgebraBLASC++APIhardwareportabilityCSR/CSC/COOstorageSpGEMMmulti-stageexecutionnumericalreproducibility
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

The paper argues that the lack of an agreed interface for sparse linear algebra is fixable: it presents a C++ API, designed over two years by a cross-institutional group, that standardizes access to sparse matrix operations the way the dense BLAS standard did for dense linear algebra. The proposal's central idea is to separate operations whose output sparsity is known in advance (single-stage calls such as sparse matrix-vector multiplication, triangular solve, and sampled dense-dense multiplication) from operations whose output sparsity is unknown (multi-stage calls such as sparse-sparse multiplication, addition, conversion, and filtering). Around that split it builds non-owning view objects over CSR, CSC, and COO data, an opaque matrix handle that can hold vendor optimization data, an optional inspect phase, and a state object that reports the result size so the user can allocate the output. If the proposal is adopted, applications could become portable across vendor libraries and accelerator architectures, lowering integration and maintenance costs for scientific computing and AI frameworks.

What carries the argument

The load-bearing mechanism is the distinction between single-stage and multi-stage APIs, implemented through a small set of C++ objects: csr_view (and CSC and COO views) plus mdspan for dense operands; matrix_handle, an opaque wrapper holding the view plus library-owned optimization data; policy and state objects that carry execution and per-operation information; and the multi-stage sequence compute, state.get_result_nnz(), user allocation, and fill. The state object is the piece that makes the unknown-output problem tractable: it carries the computed result size and any reusable internal buffers, so a developer can repack work between stages without breaking the interface.

What would settle it

Run the proposed API against a corpus of large sparse matrices from real applications on a GPU, comparing default calls without the inspect phase, inspect-then-call sequences, and each vendor's native sparse kernels; if the API's default path falls far behind native performance, or if the inspect phase rarely recovers its cost, the high-performance portability claim fails.

Watch

Extended reading notes

Core claim

On the paper's own terms, the central claim is that a hardware-portable, high-performance, flexible, and extensible Sparse BLAS interface is achievable in C++ by combining four design commitments: non-owning views for transparency and zero-copy access; optional opaque matrix handles for vendor-specific optimization; a single-stage API for operations with known output sparsity and a multi-stage API for operations with unknown output sparsity; and user-side allocation of sparse outputs after a stage that reports the required size. The multi-stage API follows the classic inspect-compute-allocate-fill pattern, with the paper deliberately leaving implementers free to decide how much work happens in each stage. This is an extension of earlier sparse BLAS proposals rather than a new mathematical discovery, and its success is measured by adoption, not by a theorem.

Load-bearing premise

The proposal requires the library user to allocate the output sparse structure after querying its size from the state object; if application developers reject this user-driven allocation as too burdensome, the API is unlikely to be adopted even though the technical design is coherent.

Editorial extensions

If this is right

  • If adopted as a standard, a single application code using the API could run on CPU, GPU, and accelerator libraries from different vendors without source-level rewrites.
  • Vendor libraries could continue to choose their best internal matrix formats and algorithms behind the handle, with the optional inspect phase amortizing setup cost in repeated iterative-solver loops.
  • Sparse-sparse matrix multiplication, addition, format conversion, and predicate filtering would get a common multi-stage interface, replacing today's divergent vendor-specific SpGEMM workflows.
  • The numerical section's framework for error bounds and consistent exception handling gives implementers a shared target for mixed- and low-precision formats, which matters for AI workloads.
  • C and Fortran bindings to a subset of the functionality would let legacy scientific codes interoperate without a full rewrite.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • I infer the multi-stage compute-allocate-fill structure could generalize naturally to sparse tensor contractions such as MTTKRP, whose output sparsity is also unknown; the paper lists sparse tensors as future work but does not draw this connection.
  • I infer that the proposal's success hinges on whether the user-driven allocation model survives contact with real applications; a testable alternative would be an optional library-managed allocation mode that keeps the same compute-fill split.
  • I infer that the inspect phase creates a measurable trade-off: benchmark users could quantify, per kernel and matrix, how many repeated calls are needed before the inspect cost is recovered, and such numbers would guide default-policy decisions.
  • I infer that the acceptance of both plain views and handles means semantic differences in exception handling (implicit versus explicit zeros) must be pinned down per operation; the paper allows implementations freedom here, so two conforming libraries could produce different NaN and Inf behavior.
Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

3 major / 7 minor

Summary. The paper proposes a C++ interface for sparse linear algebra operations, presented as a candidate standard in the spirit of the dense BLAS and std::linalg. The design centers on non-owning view types (csr_view, csc_view, coo_view) over user-owned arrays, an optional inspect phase for optimization, single-stage APIs for operations whose output sparsity is known a priori, and multi-stage compute/allocate/fill APIs for operations whose output sparsity is unknown. The manuscript also discusses execution policies, numerical exception handling, error bounds, reproducibility, and test-suite plans. The central claim is that this design enables portability across vendors while providing high-performance, flexible, and extensible interfaces for sparse linear algebra.

Significance. If completed and validated, this proposal addresses a genuine community need for a vendor-neutral sparse BLAS interface that works on CPUs and accelerators. The paper's strengths include a thorough review of prior and concurrent efforts (dense BLAS, GraphBLAS, and vendor APIs), a coherent separation of single- and multi-stage workflows, and a useful discussion of numerical considerations such as error bounds, exception handling, and conditional numerical reproducibility. The multi-institutional author list gives the proposal practical weight. However, the manuscript currently lacks a reference implementation and conformance tests, and the multi-stage workflow has an underspecified step that is central to the API's usability. These gaps prevent the paper, in its current form, from substantiating the full central claim.

major comments (3)
  1. [Section 5.6, Listings 9-12] The multi-stage workflow instructs the user to read state.get_result_nnz(), then 'allocate C arrays and put in C' before calling the fill routine. However, the paper never specifies how a preexisting csr_view object, such as `csr_view<float> C(m, n);` in Listing 11, is rebound to newly allocated arrays. Section 5.1 describes views as lightweight wrappers over user-owned pointer arrays analogous to std::mdspan, and no setter, assignment operator, or rebind operation is defined anywhere in the paper. As written, the examples are not expressible in the API, because the fill routine cannot see buffers that were never attached to C. Please specify the mutability and rebinding semantics of the view classes (including ownership and aliasing rules), or restructure the workflow so that the user constructs a fresh view after allocation.
  2. [Section 1 and Section 7.5] The paper claims that the API 'enable[s] portability across vendors, and provide[s] high-performance, flexible and extensible interfaces' and that the design 'serves the user needs'. These claims are not backed by an implementation, conformance tests, benchmarks, or user studies. The test suite described in Section 7.5 is presented as a plan ('we will deploy a unit test framework'), not as delivered evidence. For a design proposal, such statements should be framed as goals or evaluation criteria rather than demonstrated properties; otherwise the central claims are unverifiable from the manuscript.
  3. [Section 5.6 and overall API presentation] The API is presented only through usage examples, with no complete set of function signatures, constraints, or semantics for the state, policy, and scaled/view wrapper objects. This makes the proposal difficult to implement or evaluate. For example, the symbolic/numeric split uses multiply_inspect, multiply_symbolic_compute, multiply_symbolic_fill, multiply_numeric_compute, and multiply_numeric_fill, whereas the preceding single-stage variant uses sparse_multiply_inspect/sparse_multiply_compute/sparse_multiply_fill; the paper does not state which names are canonical or how overloads are disambiguated. The authors should provide at least a compact formal specification of the core functions and types, or explicitly reframe the paper as a design rationale for a future specification.
minor comments (7)
  1. [Listing 12] Listing 12 declares `auto pred` twice with two different predicates, so the listing does not compile and it is unclear which predicate is intended for the filter operation.
  2. [Listing 12] In Listing 12, the output view `B` is constructed with the same values, rowptr, colind, shape, and nnz arguments as the input view `A_view`; this would make the output share the input's storage, which contradicts the multi-stage output pattern shown in Listings 10 and 11.
  3. [Section 5.1] The sentence 'In Section 5.1 we give an example how a CSR matrix structure is passed as a light-weight view' should refer to Listing 1, not Section 5.1.
  4. [Section 2.1] The phrase 'when integrating the functionality into the C++-26 standard library' appears twice in the first paragraph; one occurrence should be removed.
  5. [Section 7.2] The notation in the error-bound derivation is confusing: `z`, `\hat{z}`, and `\hat{\hat{z}}` are not defined consistently, and the inequality chains mix three and four terms without clear labels for the conversion, dot-product, and output-conversion errors.
  6. [Listing 13] The `cnrProperty` enum gives the same value 0 to both `default` and `none`; if this is intentional, state so explicitly, otherwise remove one of the aliases.
  7. [Listings 5-6] The `scaled` wrapper used in Listing 6 is never defined or referenced to an external specification; please clarify whether it is part of this proposal or adopted from std::linalg.

Circularity Check

0 steps flagged · score 0.0 of 10

No circularity: the paper is an interface-design proposal that builds transparently on prior standards; no prediction or derivation reduces to its own inputs.

full rationale

This manuscript is not a derivation or prediction exercise; it is a C++ API design proposal. The central claim—that the proposed Sparse BLAS interface enables portability, flexibility, extensibility, and high performance—is presented as a design objective informed by prior public work (dense BLAS, GraphBLAS, std::linalg, and earlier Sparse BLAS proposals). The paper explicitly says it "learn[s] from and base[s] our standard proposal upon the previous efforts," which is transparent borrowing rather than circular reasoning. The GraphBLAS and std::linalg citations do involve overlapping authors, but those cited specifications are public, externally defined, and implemented independently, so they are real evidence rather than load-bearing self-citation. No fitted parameter is renamed as a prediction, no uniqueness theorem is imported from the authors' prior work, and no known result is repackaged as novel. The most notable technical concern is in Section 5.6, where the multi-stage examples instruct the user to allocate output arrays and "put in C" without specifying how a non-owning csr_view can be rebound to newly allocated storage; this is a specification-completeness and implementability issue, not a circularity issue. Since the paper's claims are not derived by definition from their inputs, the circularity score is 0.

Assumptions & free parameters 0 free parameters · 4 assumptions · 0 invented entities

The proposal relies on several unproved design assumptions: C++/mdspan as the base, CSR/CSC/COO as core formats, the compute-allocate-fill multi-stage pattern with user allocation, and the benefit of an optional inspect phase. None are empirically validated in the paper. No free parameters are fitted; no new physical entities are introduced.

assumptions (4)
  • domain assumption C++ and std::mdspan are the right foundation for a cross-vendor sparse linear algebra interface.
    The paper assumes the C++26 std::linalg model and mdspan views should anchor the API (Sections 2.1, 4, 5.4), rather than a Fortran-style interface.
  • domain assumption CSR, CSC, and COO together cover the dominant sparse matrix input formats.
    Section 4 declares these the supported input formats, excluding block and ELLPACK variants from the first version. If users require block formats as inputs, the standard would not serve them.
  • domain assumption The compute-allocate-fill multi-stage pattern is appropriate for operations with unknown output structure.
    Section 5.6 adopts the 1997 Duff et al. pattern, requiring the user to allocate output memory after querying nnz. If users find this burdensome, adoption may fail.
  • ad hoc to paper An optional inspect phase can improve performance on repeated operations without breaking the lightweight view model.
    Section 5.4 introduces inspect and matrix_handle to recover optimization opportunities lost with non-owning views; this is a design bet unique to this proposal.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Interface for Sparse Linear Algebra Operations." pith.science (2026). https://pith.science/paper/PG2FIV4P

@misc{pith2026241113259,
  author       = {Pith},
  title        = {Pith review of: Interface for Sparse Linear Algebra Operations},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/PG2FIV4P}},
  note         = {Machine review of arXiv:2411.13259}
}
read the original 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.

Discussion (0). Continue with ORCID to comment.

Forward citations

Cited by 1 Pith paper

Reviewed papers in the Pith corpus that reference this work. Sorted by Pith novelty score. Full citation record

  1. Faster Linear Algebra Algorithms with Structured Random Matrices

    cs.DS 2025-08 accept novelty 8.0 of 10

    Randomized sketching needs only the new OSI property, not the full subspace embedding, and multiple structured matrices satisfy it with near-optimal cost.

Reference graph

Works this paper leans on

55 extracted references · 53 canonical work pages · cited by 1 Pith paper

  1. [1]

    Numerical linear algebra on emerging architectures: The PLAS MA and MAGMA projects

    Emmanuel Agullo, Jim Demmel, Jack Dongarra, Bilel Hadri, Jakub Kurzak, Julien Langou, Hatem Ltaief, Piotr Luszczek, and Stanimir e To- mov. Numerical linear algebra on emerging architectures: The PLAS MA and MAGMA projects. In Journal of Physics: Conference Series , volume 180, pages 012–037. IOP Publishing, 2009

    work page 2009

  2. [2]

    AMD Instinct MI250X accelerator

    AMD Corporation. AMD Instinct MI250X accelerator. https://www.amd.com/en/products/server-accelerators /instinct-mi250x,

    work page

  3. [3]

    Ed Anderson, Z. Bai, C. Bischof, Susan L. Blackford, James W. D em- mel, Jack J. Dongarra, J. Du Croz, A. Greenbaum, Sven Hammarling , A. McKenney, and Danny C. Sorensen. LAPACK User’s Guide . Society for Industrial and Applied Mathematics, Philadelphia, Third edition, 1 999

    work page

  4. [4]

    The scalable matrix extension (SME), for Armv 9- A

    ARM Corporation. The scalable matrix extension (SME), for Armv 9- A. https://developer.arm.com/documentation/ddi0616/latest, 2022. [Online; accessed 30-May-2023]

    work page 2022

  5. [5]

    PTTS: power-aware tensor cores using two-s ided sparsity

    Ehsan Atoofian. PTTS: power-aware tensor cores using two-s ided sparsity. J. Parallel Distributed Comput. , 173:70–82, 2023

    work page 2023

  6. [6]

    The GraphBLAS C API specification, version 2.0.0

    Benjamin Brock, Aydın Bulu¸ c, Timothy Mattson, Scott McMillan, a nd Jos´ e Moreira. The GraphBLAS C API specification, version 2.0.0. 20 21

    work page

  7. [7]

    Mattson, Scott McMillan , and Jos´ e E

    Benjamin Brock, Aydin Bulu¸ c, Timothy G. Mattson, Scott McMillan , and Jos´ e E. Moreira. A roadmap for the graphblas c++ api. In 2020 IEEE International Parallel and Distributed Processing Sympos ium Workshops (IPDPSW), pages 219–222, 2020

    work page 2020

  8. [8]

    GraphBLAS C++ specification

    Benjamin Brock, Scott McMillan, Aydın Bulu¸ c, Timothy Mattson, and Jos´ e Moreira. GraphBLAS C++ specification. https://github.com/GraphBLAS/graphblas-api-cpp , 2023

    work page 2023

Show all 55 references
  1. [9]

    The Combinatorial BLAS: Design, im - plementation, and applications

    Aydın Bulu¸ c and John R Gilbert. The Combinatorial BLAS: Design, im - plementation, and applications. The International Journal of High Perfor- mance Computing Applications , 25(4):496–509, 2011. 39

    2011

  2. [10]

    Cerebras

    Cerebras Corporation. Cerebras. https://www.cerebras.net/, 2022. [On- line; accessed 30-May-2023]

    2022

  3. [11]

    Algorithm 1000: SuiteSparse: GraphBLAS: Gra ph al- gorithms in the language of sparse linear algebra

    Timothy A Davis. Algorithm 1000: SuiteSparse: GraphBLAS: Gra ph al- gorithms in the language of sparse linear algebra. ACM Transactions on Mathematical Software (TOMS) , 45(4):1–25, 2019

    2019

  4. [12]

    Algorithm 1037: SuiteSparse: GraphBLAS: Par allel graph algorithms in the language of sparse linear algebra

    Timothy A Davis. Algorithm 1037: SuiteSparse: GraphBLAS: Par allel graph algorithms in the language of sparse linear algebra. ACM Transac- tions on Mathematical Software , 49(3):1–30, 2023

    2023

  5. [13]

    J. Demmel. Underflow and the reliability of numerical software. SIAM J. Sci. Stat. Comput. , 5(4):887–919, Dec 1984

    1984

  6. [14]

    J. Demmel. On error analysis in arithmetic with varying relative pre cision. In IEEE 8th Symp. on Computer Arithmetic (ARITH) , pages 148–152, 1987

    1987

  7. [15]

    Proposed consistent exception handling for the blas an d lapack, 2022

    James Demmel, Jack Dongarra, Mark Gates, Greg Henry, Julien Langou, Xiaoye Li, Piotr Luszczek, Weslley Pereira, Jason Riedy, and Cindy Ru bio- Gonz´ alez. Proposed consistent exception handling for the blas an d lapack, 2022

    2022

  8. [16]

    Dinechin, L

    F. Dinechin, L. Forget, J.-M. Muller, and Y. Uguen. Posits: the g ood, the bad and the ugly. In CoNGA (Conf. on Next Generation Arithmetic) , Mar

  9. [17]

    Dodson, Roger G

    David S. Dodson, Roger G. Grimes, and John G. Lewis. Sparse ex tensions to the FORTRAN basic linear algebra subprograms. ACM Trans. Math. Softw., 17(2):253–263, jun 1991

    1991

  10. [18]

    Dodson and John G

    David S. Dodson and John G. Lewis. Proposed sparse extension s to the basic linear algebra subprograms. SIGNUM Newsl. , 20(1):22–25, jan 1985

    1985

  11. [19]

    P2300r7: std::execution

    Michal Dominiak, Georgy Evtushenko, Lewis Baker, Lucian Radu Teodorescu, Lee Howes, Kirk Shoop, Michael Garland, Eric Niebler, and Bryce Adelstein Lelbach. P2300r7: std::execution. https://www.open-std.org/jtc1/sc22/wg21/docs/papers /2023/p2300r7.html, April 2023

    2023

  12. [20]

    Dongarra, J

    Jack J. Dongarra, J. Du Croz, Iain S. Duff, and Sven Hammarling . Al- gorithm 679: A set of Level 3 Basic Linear Algebra Subprograms. ACM Transactions on Mathematical Software , 16:1–17, March 1990

    1990

  13. [21]

    Dongarra, J

    Jack J. Dongarra, J. Du Croz, Iain S. Duff, and Sven Hammarling . A set of Level 3 Basic Linear Algebra Subprograms. ACM Transactions on Mathematical Software, 16:18–28, March 1990. 40

    1990

  14. [22]

    Dongarra, J

    Jack J. Dongarra, J. Du Croz, Sven Hammarling, and R. Hanson . Al- gorithm 656: An extended set of FORTRAN Basic Linear Algebra Sub- programs. ACM Transactions on Mathematical Software , 14:18–32, March 1988

    1988

  15. [23]

    Dongarra, J

    Jack J. Dongarra, J. Du Croz, Sven Hammarling, and R. Hanson . An ex- tended set of FORTRAN Basic Linear Algebra Subprograms. ACM Trans- actions on Mathematical Software , 14:1–17, March 1988

    1988

  16. [24]

    Dongarra, Cleve B

    Jack J. Dongarra, Cleve B. Moler, J. R. Bunch, and G. W. Stewa rt. LIN- PACK Users’ Guide . Society for Industrial and Applied Mathematics, Philadelphia, PA, 1979

    1979

  17. [25]

    Duff, Michael A

    Iain S. Duff, Michael A. Heroux, and Roldan Pozo. An overview of the sparse basic linear algebra subprograms: The new standard from t he BLAS Technical Forum. ACM Trans. Math. Softw. , 28(2):239–267, jun 2002

    2002

  18. [26]

    Duff, Michele Marrone, Giuseppe Radicati, and Carlo Vittoli

    Iain S. Duff, Michele Marrone, Giuseppe Radicati, and Carlo Vittoli. Level 3 basic linear algebra subprograms for sparse matrices: A user-lev el inter- face. ACM Trans. Math. Softw. , 23(3):379–401, sep 1997

    1997

  19. [27]

    Object-oriented tech niques for sparse matrix computations in Fortran 2003

    Salvatore Filippone and Alfredo Buttari. Object-oriented tech niques for sparse matrix computations in Fortran 2003. ACM Trans. Math. Softw. , 38(4), aug 2012

    2003

  20. [28]

    PSBLAS: A library for pa rallel linear algebra computation on sparse matrices

    Salvatore Filippone and Michele Colajanni. PSBLAS: A library for pa rallel linear algebra computation on sparse matrices. ACM Trans. Math. Softw. , 26(4):527–550, dec 2000

    2000

  21. [29]

    SLATE working note 2: C++ API for BLAS and LAPACK

    Mark Gates, Piotr Luszczek, Jakub Kurzak, Jack Dongarra, Konstantin Arturov, Cris Cecka, and Chip Freitag. SLATE working note 2: C++ API for BLAS and LAPACK. Technical Report ICL-UT-17-03, Inno vative Computing Laboratory, University of Tennessee, June 2017. rev ision 06- 2017

    2017

  22. [30]

    Eigen v3

    Ga¨ el Guennebaud, Beno ˆ ıt Jacob, et al. Eigen v3. http://eigen.tuxfamily.org, 2010

    2010

  23. [31]

    Gustafson and I

    J. Gustafson and I. Yonemoto. Beating floating point at its own game: Posit arithmetic. Supercomputing Frontiers and Innovations, 4:71–86, 2017. https://posithub.org/docs/posit standard-2.pdf

    2017

  24. [32]

    Mixed-precision iterative refinement using tensor cores on GPUs to accelerate solution of linear systems

    Azzam Haidar, Harun Bayraktar, Stanimire Tomov, Jack Donga rra, and Nicholas J Higham. Mixed-precision iterative refinement using tensor cores on GPUs to accelerate solution of linear systems. Proceedings of the Royal Society A , 476(2243):20200110, 2020

    2020

  25. [33]

    Mixed precision algorithms in nume r- ical linear algebra

    Nicholas J Higham and Theo Mary. Mixed precision algorithms in nume r- ical linear algebra. Acta Numerica, 31:347–414, 2022. 41

    2022

  26. [34]

    P1673R13: A free function linear algebra interface based on the BL AS

    Mark Hoemmen, Daisy Hollman, Christian Trott, Daniel Sunderlan d, Nevin Liber, Alicia Klinvex, Li-Ta Lo, Lebrun-Grandie Damien, Graham Lopez, Peter Caday, Sarah Knepper, Piotr Luszczek, and Timoth y Costa. P1673R13: A free function linear algebra interface based on the BL AS. ...

    2023

  27. [35]

    P1673: A free function linear algebra int erface based on the BLAS

    Mark Hoemmen, Daisy Hollman, Christian Trott, Daniel Sunderlan d, Nevin Liber, Li-Ta Lo, Damien Lebrun-Grandie, Graham Lopez, Pete r Ca- day, Sarah Knepper, et al. P1673: A free function linear algebra int erface based on the BLAS. Technical report, Open Standards, 2023

    2023

  28. [36]

    IEEE standard f or floating- point arithmetic

    IEEE Microprocessor Standards Committee. IEEE standard f or floating- point arithmetic. IEEE Std 754-2019 (Revision of IEEE 754-2008) , pages 1–84, 2019

    2019

  29. [37]

    Graph algorithms in the language of linear algebra

    Jeremy Kepner and John Gilbert. Graph algorithms in the language of linear algebra. SIAM, 2011

    2011

  30. [38]

    Koenig, D

    J. Koenig, D. Biancolin, J. Bachrach, and K. Asanovic. A hardwa re ac- celerator for computing an exact dot product. In IEEE 24th Symp. on Computer Arithmetic (ARITH) , pages 114–121, 2017

    2017

  31. [39]

    NVIDIA Ampere architecture in-depth, 2023

    Ronny Krashinsky, Olivier Giroux, Stephen Jones, Nick Stam, an d Srid- har Ramaswamy. NVIDIA Ampere architecture in-depth, 2023. [On line; accessed 30-May-2023]

    2023

  32. [40]

    Evaluation criteria for sparse m atrix storage formats

    Daniel Langr and Pavel Tvrdik. Evaluation criteria for sparse m atrix storage formats. IEEE Transactions on parallel and distributed systems , 27(2):428–440, 2015

    2015

  33. [41]

    C. L. Lawson, R. J. Hanson, D. Kincaid, and F. T. Krogh. Basic L in- ear Algebra Subprograms for FORTRAN usage. ACM Transactions on Mathematical Software, 5:308–323, 1979

    1979

  34. [42]

    P3300r0: C++ asynchronous parallel algorithms

    Bryce Adelstein Lelbach. P3300r0: C++ asynchronous parallel algorithms. https://www.open-std.org/jtc1/sc22/wg21/docs/papers /2024/p3300r0.html, February 2024

    2024

  35. [43]

    FP8 formats for deep learning

    Paulius Micikevicius, Dusan Stosic, Neil Burgess, Marius Cornea, Pradeep Dubey, Richard Grisenthwaite, Sangwon Ha, Alexander Heinecke, P atrick Judd, John Kamalu, et al. FP8 formats for deep learning. arXiv preprint arXiv:2209.05433, 2022

    2022 arXiv

  36. [44]

    Jouppi, and David A

    Thomas Norrie, Nishant Patil, Doe Hyun Yoon, George Kurian, Sh eng Li, James Laudon, Cliff Young, Norman P. Jouppi, and David A. Patterso n. The design process for Google’s training chips: TPUv2 and TPUv3. IEEE Micro, 41(2):56–63, 2021. 42

    2021

  37. [45]

    Microscaling data formats for deep le arning

    Bita Darvish Rouhani, Ritchie Zhao, Ankit More, Mathew Hall, Alirez a Khodamoradi, Summer Deng, Dhruv Choudhary, Marius Cornea, Er ic Dellinger, Kristof Denolf, et al. Microscaling data formats for deep le arning. arXiv preprint arXiv:2310.10537 , 2023

    arXiv

  38. [46]

    The Matrix Template Librar y: A generic programming approach to high performance numerical line ar algebra

    Jeremy G Siek and Andrew Lumsdaine. The Matrix Template Librar y: A generic programming approach to high performance numerical line ar algebra. In International Symposium on Computing in Object-Oriented Parallel Environments , pages 59–70. Springer, 1998

    1998

  39. [47]

    IBM’s POWER10 processor

    William J Starke, Brian W Thompto, Jeff A Stuecheli, and Jos´ e E Mor eira. IBM’s POWER10 processor. IEEE Micro, 41(2):7–14, 2021

    2021

  40. [48]

    Boost uBLAS: Basic Linear Algebra Library

    Joerg Walter, Mathias Koch, et al. Boost uBLAS: Basic Linear Algebra Library

  41. [49]

    BFloat16: The secret to high pe rformance on cloud TPUs

    Shibo Wang and Pankaj Kanwar. BFloat16: The secret to high pe rformance on cloud TPUs. Google Cloud Blog , 4, 2019

    2019

  42. [50]

    python- graphblas/python-graphblas: 2024.2.0, February 2024

    Erik Welch, Jim Kitchen, Sultan Orazbayev, ParticularMiner, Sta n Seib- ert, William Zijie Zhang, Adam Lugowski, and Paul Nguyen. python- graphblas/python-graphblas: 2024.2.0, February 2024

    2024

  43. [51]

    J. H. Wilkinson. Rounding Errors in Algebraic Processes . Prentice Hall, 1963

    1963

  44. [52]

    GraphBLAST: A high - performance linear algebra-based graph framework on the GPU

    Carl Yang, Aydın Bulu¸ c, and John D Owens. GraphBLAST: A high - performance linear algebra-based graph framework on the GPU. ACM Transactions on Mathematical Software (TOMS) , 48(1):1–51, 2022

    2022

  45. [53]

    A C++ GraphBLA S: specification, implementation, parallelisation, and evaluation

    AN Yzelman, D Di Nardo, JM Nash, and WJ Suijlen. A C++ GraphBLA S: specification, implementation, parallelisation, and evaluation. Preprint, 2020. 43

    2020

  46. [2019]

    doi:10.1145/3316279.3316285

  47. [2021]

    [Online; accessed 30-May-2023]

    2023

Pith tools

Reviewed August 12, 2026 · model on record in the stance chip above.