Le 23/12/2012 13:23, Volker Braun a écrit :
The handling of BLAS/LAPACK libraries suck, Sage basically hardcodes
ATLAS or OSX accelerate into the build process. Matrix operations are
one place where using ISA extensions and careful choice of blocking to
match processor cache really matters, but we have no mechanism to use a
good implementation in binary builds.
My proposal is to make the BLAS library configurable at runtime with
defaults chosen by an automatic benchmark run. This is similar to what
GMP/MPIR does but at a higher level. Instead of writing our own "FAT"
BLAS, we use a wrapper library that resolves (using dlopen/dlsym) the
BLAS library at runtime to the reference/netlib BLAS, ATLAS, OpenBlas,
Intel MKL, or any other implementation. The backend can be selected with
the LINEAR_ALGEBRA_CONFIG environment variable.
Why is a wrapper needed? The same code should build as well with one
implementation as with another... or even run with a different
implementation from build-time to run-time to another run-time, in fact.
For example, in debian, there is a /usr/lib/libblas.so... which is a
symlink to the real blas (I'm simplifying a little here -- there is an
'alternatives' mechanism which is more involved). Then all binary
packages which need a blas just depend on this pseudo-blas. You can just
change the carpet under their feet like you want and whenever you want,
without even a recompilation needed.
Snark on #sagemath
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
Visit this group at http://groups.google.com/group/sage-devel?hl=en.
