Bug#732064: lapack depends on specific blas implementation

[Sébastien Villemot]

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'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?

-- 
 .''`.    Sébastien Villemot
: :' :    Debian Developer
`. `'     http://www.dynare.org/sebastien
  `-      GPG Key: 4096R/381A7594

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://lists.alioth.debian.org/pipermail/debian-science-maintainers/attachments/20131219/c6aaefb0/attachment.sig>