Kevin Kofler <kevin.kofler@xxxxxxxxx> writes: > Dominik 'Rathann' Mierzejewski wrote: >> It also needs some patching, because each library has a different >> SONAME. > > Symlinking > libblas.so.3 → libopenblas.so.0 > liblapack.so.3 → libopenblas.so.0 > is enough to get things linked against BLAS and/or LAPACK to pick up > OpenBLAS instead. A similar symlinking should work for the -devel package. > If the symlinks confuse ldconfig or cause some other issues, linker scripts > can be used instead. You'll find Dominik was correct if you try it. >> I think atlas used to provide a drop-in replacement, but it was abandoned > > Ouch! Indeed, the current ATLAS packages provide only libsatlas and > libtatlas, no libblas or liblapack. This is a regression and should never > have been packaged that way. Now all the packages end up with the > unoptimized reference BLAS. Various things have been changed to use openblas on x86 after some of us agitated. > (In fact, I think I already noticed that when it > happened and complained loudly about it, but was ignored, as it seems. > Sigh!) 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. > That said, ATLAS should really go away, unless they add support for runtime > CPU detection and the result matches or exceeds OpenBLAS performance. It will exceed it on any relevant platform that openblas doesn't support, 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). > In its > current state (which has been the state since its inception), ATLAS is > really unsuitable for distribution packaging. They just do not care about > binary packages, at all. I don't know whether that's true, but Fedora could at least improve the situation by providing more than the -sse2 and -sse3 packages. >> on the premise that scientific codes are compiled specificlly for their >> target clusters anyway > > … which is of course not true for distribution packages! I might note that, typically, people who insist on specific compilation haven't made relevant measurements -- I know that's not true generally -- e.g. the myths about MKL et al. Where reasonable, the computational kernels that are sensitive to SIMD should be abstracted into libraries like openblas, libxsmm, fftw, elpa, etc. >> and Intel's math library (MKL) doesn't provide a drop-in replacement. > > … which is entirely irrelevant. > > 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. On avx512, that's BLIS (+libxsmm), but MKL is still substantially faster. _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
