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
signature.asc
Description: This is a digitally signed message part