R detection of Blas version

Question

Is there a way of detecting the version of BLAS that R is using from inside R? I am using Ubuntu, and I have a couple of BLAS versions installed - I just don't know which one is "active" from R's point of view!

I am aware of http://r.789695.n4.nabble.com/is-Rs-own-BLAS-td911515.html where Brian Ripley said in June 2006 that it was not possible - but have things changed?

Kettering

Did you check whether there's something in this line in package [gcbd][1]? That is where I'd have a look to start with. [1]: cran.r-project.org/web/packages/gcbd/index.html – Superstratum

Answer 1

I think you cannot. R will be built against the BLAS interface, and R itself does not which package supplies the actual library.

You can only look at ldd output. On my server, this points to Atlas

edd@max:~$ ldd /usr/lib/R/bin/exec/R
    linux-vdso.so.1 =>  (0x00007fffc8ddb000)
    libR.so => /usr/lib/libR.so (0x00007f8be940c000)
    libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f8be91ef000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f8be8e4d000)
    libblas.so.3gf => /usr/lib/atlas-base/atlas/libblas.so.3gf (0x00007f8be88e4000)
    libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f8be8660000)
    libreadline.so.6 => /lib/libreadline.so.6 (0x00007f8be841d000)
    libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 (0x00007f8be81e1000)
    liblzma.so.2 => /usr/lib/liblzma.so.2 (0x00007f8be7fbf000)
    libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f8be7da6000)
    librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f8be7b9e000)
    libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f8be799a000)
    libgomp.so.1 => /usr/lib/x86_64-linux-gnu/libgomp.so.1 (0x00007f8be778b000)
    /lib64/ld-linux-x86-64.so.2 (0x00007f8be99a5000)
    libgfortran.so.3 => /usr/lib/x86_64-linux-gnu/libgfortran.so.3 (0x00007f8be7475000)
    libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f8be725f000)
    libtinfo.so.5 => /lib/libtinfo.so.5 (0x00007f8be7037000)
    libquadmath.so.0 => /usr/lib/x86_64-linux-gnu/libquadmath.so.0 (0x00007f8be6e01000)
edd@max:~$ 

which makes sense as this BLAS-providing package gets the highest priority per the Debian packaging.

Edit, some nine years later: R, which always grows in capabilities, now reports this (even pretty-printed) in sessionInfo(). On my machine (R 4.1.1, Ubuntu 21.04) it says just that too:

> sessionInfo()
R version 4.1.1 (2021-08-10)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Ubuntu 21.04

Matrix products: default
BLAS:   /usr/lib/x86_64-linux-gnu/openblas-pthread/libblas.so.3
LAPACK: /usr/lib/x86_64-linux-gnu/openblas-pthread/libopenblasp-r0.3.13.so

[...]

You can also access those two paths directly:

> si <- sessionInfo()
> si$BLAS
[1] "/usr/lib/x86_64-linux-gnu/openblas-pthread/libblas.so.3"
> si$LAPACK
[1] "/usr/lib/x86_64-linux-gnu/openblas-pthread/libopenblasp-r0.3.13.so"
> 

Gamekeeper

For mac users, I think this should work otool -L /Library/Frameworks/R.framework/R – Langsdon

And on debian or ubuntu, I think you can do: update-alternatives --config libblas.so.3. Using ldd as Dirk writes, I see my R points to /usr/lib/libblas.so.3 which is a link to /etc/alternatives/libblas.so.3 – Bickford

Yes, if you know a little about your system then update-alternatives is good. I built the older gcbd package / testing framework / vignette around that trick. I am not sure I recommend it as an (R-user) facing command. – Gamekeeper

Perhaps we should modify this answer so to say that the BLAS version is now reported in sessionInfo() ? The other part of the answer could be kept for older versions of R. – Whorish

That's a good suggestion (and now DONE) and something I also noticed more-or-less in passing last year. Do you happen to remember when that change was made? R 4.0.0 maybe? – Gamekeeper

Answer 2

In R, type:

sessionInfo()

which should give you among other things the BLAS used as well.

For example, on my machine I get:

Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Ubuntu 18.04.3 LTS

Matrix products: default
BLAS:   /usr/lib/x86_64-linux-gnu/openblas/libblas.so.3
LAPACK: /usr/lib/x86_64-linux-gnu/libopenblasp-r0.2.20.so

locale:
 [1] LC_CTYPE=en_US.UTF-8       LC_NUMERIC=C               LC_TIME=en_US.UTF-8        LC_COLLATE=en_US.UTF-8     LC_MONETARY=en_US.UTF-8   
 [6] LC_MESSAGES=en_US.UTF-8    LC_PAPER=en_US.UTF-8       LC_NAME=C                  LC_ADDRESS=C               LC_TELEPHONE=C            
[11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C       

attached base packages:
[1] stats     graphics  grDevices utils     datasets  methods   base     

loaded via a namespace (and not attached):
[1] compiler_3.6.1    Matrix_1.2-17     tools_3.6.1       Rcpp_1.0.2        grid_3.6.1        data.table_1.12.2 packrat_0.5.0     lattice_0.20-38  
[9] stm_1.3.3        

Coeducation

This seems so much easier, was this not a thing when Dirk wrote his answer? – Adversative

Yes, this wasn't around until 2018. The commit history suggests they started working on in it 2017. – Coeducation

Answer 3

This solution works if its enough for you to know at which path the BLAS library can be found. For example, I use this solution to decide whether to load the package libraries for the "normal" R version or the OpenBLAS version.

Of course, you can not know where other people store their libraries, so for use in a package or shared code it is not suitable. But for own maintenance it can be used:

extSoftVersion()["BLAS"]
## [1] "/the/path/to/your/libblas.so"

Deputy

Answer 4

Partial answer for linux if lsof is installed.

# on a system using openblas:
> grep('blas', system2('lsof', c('-p', Sys.getpid()), stdout=TRUE), value = TRUE)
[1] "R       282 docker  mem    REG   0,52 29998440     233 /usr/lib/libopenblasp-r0.2.12.so"


# on a system using R internal Blas:
> grep('blas', system2('lsof', c('-p', Sys.getpid()), stdout=TRUE), value = TRUE)
[1] "R       157 docker  mem    REG   0,44   180936     3105 /usr/local/lib/R/lib/libRblas.so"

Issiah