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 _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
