[HN Gopher] Efficient sparse computations using linear algebra a...
       ___________________________________________________________________
        
       Efficient sparse computations using linear algebra aware compilers
       (2025)
        
       Author : matt_d
       Score  : 61 points
       Date   : 2026-03-12 23:55 UTC (4 days ago)
        
 (HTM) web link (www.osti.gov)
 (TXT) w3m dump (www.osti.gov)
        
       | owlbite wrote:
       | It will be interesting to see if this solves any issues that
       | aren't already addressed by the likes of matlab / SciPy / Julia.
       | Reading the paper it sounds a lot like "SciPy but with MLIR"?
        
         | geremiiah wrote:
         | It's more like OpenXLA or the PyTorch compiler, that codegens
         | Kokkos C++ kernels from MLIR defined input programs, which for
         | example can be outputted from PyTorch. Kokkos is common in
         | scientific computing workloads, so outputting readable kernels
         | is a feature in itself. Beyond that there's a lot of
         | engineering that can go into such a compiler to specifically
         | optimize sparse workloads.
         | 
         | What I am missing is a comparison with JAX/OpenXLA and PyTorch
         | with torch.compile().
         | 
         | Also instead of rebuilding a whole compiler framework they
         | could have contributed to Torch Inductor or OpenXLA, unless
         | they had some design decisions that were incompatible. But it's
         | quite common for academic projects to try to reinvent the
         | wheel. It's also not necessarily a bad thing. It's a
         | pedagogical exercise.
        
           | convolvatron wrote:
           | I think the exactly opposite, if someone was able to build a
           | framework that doesn't overly constrain the problem, and
           | doesn't require weeks of screwing around with the build,
           | integration of half baked components and insane amounts of
           | boilerplate, that would be a fantastic contribution in and of
           | itself even it didn't advance the state of tensor compilation
           | in any other way.
        
       | trevyn wrote:
       | Isn't this where Mojo is going?
        
         | uoaei wrote:
         | Speaking of, where is Mojo?
        
       | snovv_crash wrote:
       | Curious how this would deal with things like Kahan Summation,
       | which corrects floating point errors that theoretically wouldn't
       | exist if you had infinite precision representations.
        
       | strujillo wrote:
       | Sparse workloads are a really good fit for scientific discovery
       | pipelines, especially when you're searching over candidate
       | equation spaces.
       | 
       | In practice, even relatively small systems can surface meaningful
       | structure. I've been using sparse regression (SINDy-style) on raw
       | solar wind data and was able to recover things like the Sun's
       | rotation period (~25.1 days estimate) and non-trivial scaling
       | laws.
       | 
       | What becomes limiting pretty quickly is compute efficiency when
       | you scale candidate spaces, so compiler-level optimizations like
       | this feel directly relevant to making these approaches practical
       | at larger scales.
        
       ___________________________________________________________________
       (page generated 2026-03-17 23:01 UTC)