On 08/17/2017 12:05 AM, Dan Horák wrote:
On Wed, 16 Aug 2017 22:57:28 +0200
Kevin Kofler <kevin.kofler@xxxxxxxxx> wrote:
Dave Love wrote:
Kevin Kofler writes:
If you are talking about the missing RPM AutoProvides:
Provides: libblas.so.3()(64bit)
does wonders.
I mean you need to get the soname right and ensure that you have
everything implemented in the replacement library.
Only the soname of the Provides matters. The actual library file can
be a symlink to the monolithic libopenblas.so.0, the dynamic linker
(ld.so) will load it just fine. The soname is only read at link time,
and there, it is fine (and in fact desired) that newly linked
applications get libopenblas.so.0 recorded as the soname, not
libblas.so.3.
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.
It's not available for them all as far as I know -- there's an rpm
macro which says which ones. I'm happy if that's wrong now.
"things" = "packages" here. Surely OpenBLAS should work for all the
BLAS- using packages on x86, especially if we symlink libblas.so to
it. If not, it is a bug either in OpenBLAS or in the package.
OpenBLAS is not available for some exotic architectures, but the
solution there is to build ATLAS (or some other implementation) for
those architectures (and those architectures only) and set up the
symlinks there too.
in F-27+ we should have OpenBLAS available for all active Fedora
architectures
Dan
_______________________________________________
OpenBLAS (https://github.com/xianyi/OpenBLAS) and BLIS
(https://github.com/flame/blis) are nice, but for performance, may need
to rethink packaging entirely. Ability to use GPUs may require better
coordination with upstream developers - clBLAS looks promising for this,
but seemed not to have gained much traction. This would be particularly
useful for single precision applications such as image and audio
processing. RocBLAS (https://github.com/ROCmSoftwarePlatform/rocBLAS) is
an open alternative, but mostly for AMD. For commonly used libraries,
might it be worth getting performance information in Koji or Copr? It
may also be good to allow intelligent performance based choice of BLAS
library based on architecture, what may be the best library on a 2 core
mobile platform, 32 core workstation, ARM cloud server, Power cloud
server etc. may be quite different.
Having a correct and slow reference BLAS is also useful. Though
expectation of average user to choose correct BLAS implementation may be
too much - packager may have a better idea of a reasonable default.
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
