Changing the BLAS from openblas on a F32 box
Of course, even a simpler trick is to launch R as follows: LD_PRELOAD=/lib64/atlas/libsatlas.so.3 R and then the symbols in libsatlas take precedence over libopenblas. Or a mix between both alternatives, i.e., setting LD_PRELOAD=/path/to/some/link R and then change that link to point to openblas, atlas... Whatever suits you best. I?aki
On Wed, 27 May 2020 at 11:00, I?aki Ucar <iucar at fedoraproject.org> wrote:
Hi Gavin, On Wed, 27 May 2020 at 01:15, Gavin Simpson <ucfagls at gmail.com> wrote:
Dear list, What is the recommended incantation on Fedora 32 to swap out the openblas BLAS that the packaged (rpm) version of R-core installs for ATLAS?
I'm afraid there is no official mechanism in place to do that yet.
There was a proposal [1], but it was never pushed forward due to some
issues and lack of time. There's a simple hack you can do though.
Since recently, R in Fedora no longer uses openblas-Rblas and links
against system openblas, as you can see here:
$ ldd /usr/lib64/R/bin/exec/R | grep blas
libopenblas.so.0 => /lib64/libopenblas.so.0 (0x00007f8fff849000)
So one simple trick to override that is something along these lines:
$ mkdir ~/blas
$ ln -s /lib64/atlas/libsatlas.so.3 ~/blas/libopenblas.so.0
$ LD_LIBRARY_PATH=~/blas ldd /usr/lib64/R/bin/exec/R | grep blas
libopenblas.so.0 => /home/****/blas/libopenblas.so.0
(0x00007f78b3ea2000)
As you can see, now R points to the link in my home, which in turn
points to system's atlas. Now you can define an alias in your .bashrc
to always prepend that override to R and Rscript. If you remove the
link in your home, it will default to system's openblas. If you point
it to another BLAS implementation, it will pick it up.
Hope it helps.
[1] https://fedoraproject.org/w/index.php?title=PackagingDrafts:BLAS_LAPACK
If anyone is interested, the issue Simon Wood reports with openblas and *mgcv* is: Issues: ** openblas 0.3.x x<7 is not thread safe if itself compiled for single thread use and then called from multiple threads (unlike the reference BLAS, say). 0.2.20 appears to be OK. For 0.3.x x>6 make USE_THREAD=0 USE_LOCKING=1 to make openblas ensures thread safety (currently unclear if USE_LOCKING will be default from 0.3.7).
Does this mean that single-threaded openblas should be built with USE_LOCKING=1 by default? Is there any upstream recommendation about this? -- I?aki ?car
I?aki ?car