Bug#598638: lapack: update-alternatives breaks application linking

[Sylvestre Ledru]

Hello Francesco,

Le samedi 14 janvier 2012 à 19:16 +0100, Francesco Poli a écrit :
> On Fri, 13 Jan 2012 21:54:39 +0100 Sylvestre Ledru wrote:
> 
> > Le mardi 03 janvier 2012 à 00:13 +0100, Francesco Poli a écrit :
> [...]
> > > Hello and happy new year!
> > > 
> > > Any update on this bug?
> > Unfortunately, I don't have any ETA on this.
> 
> OK, let's hope it may be fixed soon...
Yep, but I am not optimism...
> > 
> > > Is there a workaround?
> > > I mean: is there something that I can do manually in order to make the
> > > whole thing work correctly?
> > Of course!
> > 
> > When you run atlas, make sure that both blas and lapack ATLAS
> > implementation are used in the configure (both runtime & -dev packages)
> 
> I am not sure I understand what you mean...
> 
> The default configuration has the alternatives set so that both blas and
> lapack ATLAS implementations are used.
> This setup *works for me*: I can compile, link, and run applications
> using lapack, with no issues at all (see the original bug report).
> 
> What I initially tried to do (again, see the original bug report) was
> exactly the opposite of what you seem to suggest: I wanted to change
> the alternatives so that both blas and lapack *reference*
> implementations are used.
> The reason is that I wanted to see how much *worse* those reference
> implementations would perform with respect to the ATLAS implementations.
> I tried to follow the instructions explained in
> http://sylvestre.ledru.info/blog/sylvestre/2010/04/06/update_of_the_linear_algebra_libraries_i
> but the result was that I could no longer compile and link the simple
> test program I was using as a minimal benchmark...
> I see that the same instructions are included
> in /usr/share/doc/libatlas3gf-base/README.Debian.gz
> Well, they do *not* seem to work for me.
> 
> Could you please clarify what you suggest, and explicitly spell out the
> commands I should issue to switch to the reference implementations, and
> the commands to switch back to the ATLAS implementations?
> I would like to minimize the risk of breaking my production system!
Well, if you are looking for performance, continue to use your "pure atlas configuration" (and you could even drop
blas from your system)
 

> 
> BTW, according to my original plan, I wanted to also test
> libatlas-core2sse3-dev, but the optimized packages have been dropped,
> as stated in the README.Debian file.
> Well, the explanation for this decision is not really clear to me: why
> is it suggesting that *each* interested user rebuilds *each* new
> version of the package on his/her own box, when buildds could do this
> job *once* for all the users (for each version)?
>
>
> This is Debian, after all, not Gentoo!
> I acknowledge that Debian packages are usually not optimized for
> specific CPUs, and generally only one port per architecture is present
> in the archive. But ATLAS is a bit special in this respect: it is "born
> to be optimized" (yeah, it sounds like a parody of a famous song!). 
> 
> Could you please explain?
Sure. I am writing this email offline. I cannot point you to my original
email explaining this decision. However, here are some of the reasons:
* atlas is only perfectly optimized when it is built on the target host.
Since every build system in Debian being different, you will get an
atlas optimized for a random system (for example, if you are using
amd64, you would get the version optimized for my laptop).
This applies even with the package libatlas-core2sse3-dev because I
probably have a CPU cache size different from your.
* atlas is optimized for a specific number of threads. This is also
computed at buildtime. For example, if you have 8 cores and the build
machine has only 2, it is likely that your 8 core won't ever be used at
the same time. I could had set a hardcoded number of threads in the
package but it would have been missleading to users and in some cases,
degrading performances
* some build hosts in the debian archs are old and don't have some CPU
extensions (SSE 4 for example). Since I cannot say "
I want atlas to build only on X, Y & Z", we had some random build
failures depending on the host.
* on the overall, it was missleading to users. in the linear algebra
world, users expect to have the best performances at possible. 
With atlas, it is never the case if prebuilt packages are used. The only
right way is to rebuild atlas on your system.
See:
"Building Optimized Atlas Packages on your ARCH"
in /usr/share/doc/libatlas3gf-base/README.Debian.gz

I hope you understand our choose.

Sylvestre