Why do I have openblas installed on my mac (intel) then? Recent openblas require clang though. Haven't managed to compile it with gcc. Overall I like openblas, I even put it on a BlueGene/P.
Francois On 24/12/2012, at 5:57, "William Stein" <[email protected]<mailto:[email protected]>> wrote: On Sun, Dec 23, 2012 at 4:23 AM, Volker Braun <[email protected]<mailto:[email protected]>> wrote: 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. I was at a conference a week ago with a bunch of applied mathematicians who are extremely experienced in high performance *numerical* computing (at least compared to me). One strongly suggested we simply dump ATLAS for OpenBLAS (https://github.com/xianyi/OpenBLAS). OpenBLAS does not support OS X, but that might be OK, since I don't think we build ATLAS on OS X anyways. I'm not for or against the above proposal (yet). But I'm putting it out there. The argument was that OpenBLAS has significant and broad developer momentum around it, whereas ATLAS is almost all Clint Whaley's project, and OpenBLAS is much easier to build. I've not verified any of these claims. (Both projects are I think BSD licensed.) William The backend can be selected with the LINEAR_ALGEBRA_CONFIG environment variable. Ultimately, there will be a Python program to build different BLAS/LAPACK libraries and install them either in /usr/lib/linear_algebra/NAME/ (or /usr/lib64 or any compile-time prefix) or $(HOME)/.local/lib/linear_algebra/NAME/ where NAME is a combination of implementation and compile options used. The LINEAR_ALGEBRA_CONFIG environment variable will then be set to NAME. As a demo, I wrote the wrapper library linalg_cblas.so, see https://github.com/vbraun/linear_algebra_config/blob/master/library_src/cblas.c which wraps two CBLAS functions. For now, LINEAR_ALGEBRA_CONFIG is used as name (possibly with full path info) of the cblas library, though this will be changed. The example program https://github.com/vbraun/linear_algebra_config/blob/master/test/startup.c is just a call to these two CBLAS functions and is linked with -llinalg_cblas -ldl. Then the CBLAS library can be selected at runtime (here switched between Sage GSL CBLAS, the Fedora GSL CBLAS, and ATLAS): [vbraun@volker-desktop linear_algebra]$ LINEAR_ALGEBRA_CONFIG=~/Sage/sage/local/lib/libgslcblas.so ./test/startup Address of cblas_zdotc_sub: d817a0b0 Address of cblas_dgemm: d815ffb0 destructor [vbraun@volker-desktop linear_algebra]$ LINEAR_ALGEBRA_CONFIG=libgslcblas.so.0 ./test/startup Address of cblas_zdotc_sub: c30260f0 Address of cblas_dgemm: c300c000 destructor [vbraun@volker-desktop linear_algebra]$ LINEAR_ALGEBRA_CONFIG=libcblas.so ./test/startup Address of cblas_zdotc_sub: c58159e0 Address of cblas_dgemm: c580c420 destructor The computational cost is of course an extra stack frame whenever you call a BLAS/LAPACK function. But then thats already faster than any operation that you can do in Python. In the Sage build process we would then build the wrapper library and the reference blas by default. The wrapper will try to pick up system BLAS/LAPACK implementations if they are available. Installing ATLAS or OpenBlas would then be optional. Right now we compile ATLAS in parallel together with anything else, which makes little sense if you want to get accurate timings. Also the ATLAS library interface changed in ATLAS-3.10 so we'll have to modify everything sooner or later. Finally, ATLAS-3.10 doesn't work on Itanium any more and there is not much interest in making it work there, so if we ever want to get AVX support, say, on modern Intel chips we need to fall back to a dumb implementation on Itanium (or face the fact that Itanium is dead). -- 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]<mailto:[email protected]>. To unsubscribe from this group, send email to [email protected]<mailto:sage-devel%[email protected]>. Visit this group at http://groups.google.com/group/sage-devel?hl=en. -- William Stein Professor of Mathematics University of Washington http://wstein.org -- 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]<mailto:[email protected]>. To unsubscribe from this group, send email to [email protected]<mailto:[email protected]>. Visit this group at http://groups.google.com/group/sage-devel?hl=en. This email may be confidential and subject to legal privilege, it may not reflect the views of the University of Canterbury, and it is not guaranteed to be virus free. If you are not an intended recipient, please notify the sender immediately and erase all copies of the message and any attachments. Please refer to http://www.canterbury.ac.nz/emaildisclaimer for more information. -- 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.
