Dear all, Looking at the publication for FlexiBLAS I'd say the runtime overhead is negligible.
Just another pointer: glibc is already doing dynamic dispatch for transcendental functions (sin, exp, pow, etc.) to specialized implementations. This is a noticeable pointer walk but still small compared to the actual runtime of, say, pow(). So if flexiblas has implemented their dynamic dispatch in a similar fashion then it's going to be reasonably fast. I doubt that n=3 is the target application for BLAS/LAPACK routines. Setting up everything and then calling into the routines (without flexiblas) will already cost you much more than the 10 instructions that are executed in the end. [1] In that sense the benchmarks presented are quite representable, I would say. Maybe n=100 would have been a nice pointer to have. But all that said, our current support for blas/lapack in gentoo isn't particularly great and I think that flexiblas has the potential to improve that situation significantly. Best, Matthias [1] And from my experience, *every* project that cares about efficient algorithms for n=3 handrolls these 10 instructions anyway... On Mon, Sep 15, 2025, at 10:05 CDT, Michael Orlitzky <[email protected]> wrote: > On 2025-09-15 16:05:53, Michał Górny wrote: >> >> Can you suggest a good (and easy to use) benchmark for BLAS/LAPACK? > > No, I'm honestly not that knowledgable about it. Despite nominally > working in linear algebra, I mainly use the computer to solve systems > of low dimension that arise in other algorithms. There are no doubt a > few thousand such uses in R, Octave, SageMath, etc. > > My only real concern is that the FlexiBLAS benchmarks appear targeted > at people who use linear algebra to do large-scale linear algebra. > Their smallest n=500 is larger than the matrices I usually work > with. But if the numbers look the same for n=3, then there's nothing > to worry about. You could steal the FlexiBLAS benchmarks and tone down > "n" to test this? > > (You can always turn many small systems into one big system to cut > down on the number of API calls, but the size of the system grows > quadratically so this isn't a real strategy.)
