On 2025-09-15 10:43:51, Matthias Maier wrote: > Dear all, > > Looking at the publication for FlexiBLAS I'd say the runtime overhead is > negligible.
It is, if you are multiplying huge matrices with each API call... > 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. To avoid getting into an argument over hypotheticals, I wrote a small C program that I assume is the worst case for FlexiBLAS: doing 100,000,000 scalar (1x1 matrix) multiplications with repeated calls to cblas_dgemm(). These numbers obviously fluxuate, but they are representative: * netlib: 8.51s * openblas: 13.75s * flexiblas (netlib): 24.71s * flexiblas (openblas): 27.45s > 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] n=3 is just an example, but I think you will find dimension three to be quite popular among the people who live there. For every researcher working directly with BLAS, there are a thousand users of software like Mathematica, MATLAB, Magma, Maple, Octave, SageMath, SciPy, etc. Typically these will hand off your computation regardless of size. Likewise for graphics and signal processing applications. On a distro where BLAS gets pulled in as a dependency, I think this generic use case has to be considered the main one. > 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. No argument here. I'm not going to die if the Sage test suite gets 1% slower, I would just rather be clear about the overhead.
