[HEADSUP] Atlas changed libraries

[Kevin Kofler]

Susi Lehtola wrote:
> Multicore CPUs are nowadays the norm, and packages should really use
> libraries that support this approach. Thus your argument is obsolete.
> The parallel libraries are not interchangeable.

I'd rather have an optimized serial implementation than being stuck with the 
unoptimized serial reference implementation.

There are many packages in Fedora that need some linear algebra and thus 
link BLAS or LAPACK. Not all of them are designed by people trying to 
squeeze every last millisecond out of their code. Most of them just expect 
to use -llapack and get a sensible implementation!

For all I care, you can ship the parallel build as libtatlas.so (if it 
really does cause compatibility issues), just don't expect other packages to 
actually use it then.

> Currently your argument is rather theoretical.

My argument is very practical. We have many packages that BR lapack-devel 
and expect to end up with a fast ATLAS implementation if the user installs 
it (the one most appropriate for his/her CPU). The change which started this 
thread breaks this.

> If you really feel strongly about this, then prepare a packaging guideline
> along the lines of the MPI guidelines, where there is a analogous
> situation with regard to multiple implementations of the MPI standard.

The existing ATLAS setup (before the change) just worked!

Sam Halliday wrote the following comment in the OpenBLAS thread:
| @susilehtola with separate dynamic libraries for BLAS/LAPACK, users can
| still code against a specific implementation if they want to: those vendor
| specific libs are still there. However, what you're doing is cutting off
| decades of binary compatibility and simply removing yourself from being an
| option for existing binaries... who may have no specific memory or thread
| model requirements.
|
| I still don't see why different threading models can cause such a problem.
| So long as the array pointers are pointers into the heap (and not into
| some other memory model, like in GPUs), there should be no stability
| problems, and threading models are simply a machine/user decision. If that
| runs suboptimally, then boo hoo for the sysadmin. If memory location is
| really a big issue, then standard BLAS / LAPACK are probably not the best
| options anyway.
|
| In any case, I have no personal plans to use OpenBLAS. But please know
| that by doing this you are essentially forcing a lot of end-users away
| from your library, simply because you're now positioning yourself as a
| vendor-specific implementation of BLAS/LAPACK. I recommend that you change
| all the symbol names to reflect this (which is farcical, I know... but
| there really is no point in implementing BLAS/LAPACK if users can't switch
| to you at runtime).
and I have to say I agree with him. The change to ATLAS packaging discussed 
in this thread is NOT acceptable and should be reverted immediately, and 
OpenBLAS should also be packaged as libblas.so.3 and liblapack.so.3. Having 
libraries which would be binary-compatible, but use different library names, 
is very broken.

        Kevin Kofler