Dave Love wrote:
You'll find Dominik was correct if you try it.
If you are talking about the missing RPM AutoProvides:
Provides: libblas.so.3()(64bit)
does wonders.
Various things have been changed to use openblas on x86 after some of
us
agitated.
The problem is, "various things" is not enough, we need a plan to ensure ALL
things use it.
As far as I remember, there's good reason (apart from the
previous
(FPC?) vote against it), like the atlas blas and lapack have to go
together.
If the ld.so.conf.d override were implemented correctly, it would just work.
The issue with the old state was that there was only an override for
liblapack installed and not for libblas, which is of course very broken.
But the new approach I am proposing installs only one version of both BLAS
and LAPACK (the OpenBLAS one), so there cannot possibly be mismatched
versions (except if you have third-party binaries bundling BLAS and linking
to the system LAPACK or the other way round, but those are then very broken
and will also fail on other distributions for the same reason).
It will exceed it on any relevant platform that openblas doesn't
support,
Is there even such a platform, the keyword being "relevant"? :-)
OpenBLAS supports all these:
https://github.com/xianyi/OpenBLAS/blob/develop/GotoBLAS_01Readme.txt#L21
https://github.com/xianyi/OpenBLAS#additional-support-cpu
If you want anything else, sure, you can ExcludeArch OpenBLAS on them, build
ATLAS as an ExclusiveArch package for them, and set up the symlinks
accordingly. That should not be an obstacle to shipping an optimal
implementation on our primary architectures. (Quite the opposite, it means
that no other package would need %ifarch hacks, all the logic would stay
confined to the OpenBLAS and ATLAS packages as it should be.)
but where OB doesn't do DYNAMIC_ARCH you still have the problem
of needing
micro-architecture-specific packages (which seems to be against policy,
although atlas does it).
ld.so.conf.d is the only way to build those, if you want to support them. I
wonder whether non-x86 architectures are even worth investing the effort.
> It is the job of the distribution to ensure that software uses
the most
> efficient BLAS/LAPACK implementation available. Other distributions ship
> symlinks ensuring that. The current packaging in Fedora is horrible.
I presume that means the most efficient free implementation.
Sure, I mean the most efficient implementation available in Fedora, for
which freeness is of course a prerequisite.
On avx512, that's BLIS (+libxsmm), but MKL is still substantially
faster.
Well, another technical criterion is that we can really only pick the
default implementation per architecture (e.g., x86_64), not per
subarchitecture (e.g., AVX-512), and I think OpenBLAS is still the best
option for x86_64 overall (also because it supports runtime subarchitecture
detection and BLIS does not).
For AVX-512, I think what we really want is to get AVX-512 optimizations
into OpenBLAS. It can match MKL performance when it is using the same
instruction set, see e.g. the graph for Sandy Bridge (AVX):
https://github.com/xianyi/OpenBLAS/wiki/faq#sandybridge_perf
Of course, if your CPU supports AVX-512 and your BLAS is only using AVX2 (as
OpenBLAS currently does), it will not be optimal, no surprise there.
Kevin Kofler