Bug#732064: lapack depends on specific blas implementation

[Andrey Gursky]

2013/12/19, Sébastien Villemot <sebastien at debian.org>:
> Le mardi 17 décembre 2013 à 16:47 +0100, Andrey Gursky a écrit :
>
>> Sebastien, thanks for pointing this out. I've also got caught in the
>> same trap. But this would mean a trade-off, since openblas's version
>> of lapack is just striped away for now. Should I open a new bug for
>> openblas or could it be, that optimizations of openblas's lapack are
>> not significant enough?
>
> My understanding is that OpenBLAS does not provide a specialized version
> of LAPACK. It just gives the possibility of bundling LAPACK within the
> libopenblas.a, which is uninteresting for us. But I have not
> investigated this too much, so if OpenBLAS provides a customized LAPACK
> as ATLAS does, then please open a wishlist bug against openblas.

I just was confused by the thread [1], where an opinion(?) was expressed:
"Now, because the both ATLAS and OpenBLAS versions of LAPACK have some
functions overridden with more efficient versions..."

Now comparing OpenBLAS.git and lapack-3.5.0 yields:
...
Only in OpenBLAS.git/lapack: getf2
Only in OpenBLAS.git/lapack: getrf
Only in OpenBLAS.git/lapack: getri
Only in OpenBLAS.git/lapack: getrs
...
Only in OpenBLAS.git/lapack: laswp
Only in OpenBLAS.git/lapack: lauu2
Only in OpenBLAS.git/lapack: lauum
...
Only in OpenBLAS.git/lapack: potf2
Only in OpenBLAS.git/lapack: potrf
Only in OpenBLAS.git/lapack: trti2
Only in OpenBLAS.git/lapack: trtri

>> I'm wondering, whether lapack interface could be remaining general
>> modified in a way, atlas and openblas could use it without changing.
>> Or the things are more complicated?
>
> When you use the general LAPACK in Debian, you still benefit from ATLAS
> and OpenBLAS optimizations everytime LAPACK calls a BLAS function. Does
> this answer your question?

Yes, I was surprised, that besides a BLAS optimization an optimization
of LAPACK is also needed. Considering at least a statement from ATLAS
FAQ [2]:
"The provided LAPACK routines utilize a recursive algorithm that
should yield reliably better results than the more common
staticly-blocked algorithms."
and it seems the ATLAS LAPACK is not a patched general netlib LAPACK at all.

Anyway, I believe, this bug report belongs to be merged with the one
you've mentioned (#576972).

[1] https://fedorahosted.org/fpc/ticket/352
[2] http://math-atlas.sourceforge.net/faq.html#optcomp