On 2025-09-11 20:07:11, Michał Górny wrote: > Hi, everyone. > > TL;DR: I'm proposing removing eselect-blas/lapack and the virtuals, > and using sci-libs/flexiblas instead.
I wish this (not your proposal necessarily, but all of it) were simpler in the common case where OpenBLAS works well enough that the user would never think about switching, much less switching at runtime. I'm a little skeptical of the FlexiBLAS benchmarks. The only ones I've seen are in lawn284.pdf, where they measure in seconds(!) on a very fast CPU the extra time taken by FlexiBLAS... on top of an already slow computation. The wrapper could be 1000% slower than a direct library call, but you'd never know because they multiply two big matrices afterwards and then tell you how long it took to do the fast thing and the slow thing together. All I personally want is to be able to dump OpenBLAS in $libdir, the same way you're planning to do with FlexiBLAS. I can do this now with eselect-ldso, but I don't care about runtime switching and would be fine if that went away or was replaced with FlexiBLAS. Instead of putting FlexiBLAS in $libdir, I guess we could make the $libdir implementation configurable via USE and have FlexiBLAS be one of the options. Default to OpenBLAS on most arches, unless you need the reference implementation as a dependency? But then we would have to make sure that every implementation knows how to install itself to two places, etc. It would be even more work than doing it 1x for FlexiBLAS, and I'm not volunteering, so this is just thinking out loud.
