R with LAPACK from OpenBLAS

[DBScan]

I would like to compile R with OpenBLAS and its integrated LAPACK implementation. However, when I configure R, it always complains that it cant' find dgemm_ and dpstr_f:

checking for dgemm_ in -lopenblas -I/opt/OpenBLAS-0.3.23/include -L/opt/OpenBLAS-0.3.23/lib... yes
checking whether double complex BLAS can be used... yes
checking whether the BLAS is complete... yes
checking for dgemm_ in -llapack... no
checking for dpstrf_ in -llapack... no
checking if LAPACK version >= 3.10.0... no
configure: using internal LAPACK sources

I can find these two functions in libopenblas.a by typing nm /opt/OpenBLAS-0.3.23/lib/libopenblas.a | grep "dpstrf_", the output is the following:

0000000000000000 T dpstrf_
                 U LAPACKE_dpstrf_work
lapacke_dpstrf_work.o:
                 U dpstrf_
0000000000000000 T LAPACKE_dpstrf_work

[michaelmayer]

Which version of R are you attempting to build and what is your exact configure command you are using ?

On my small test system with CentOS 7 and R 4.3.1 I can get (openblas-devel preinstalled from the EPEL repo)

./configure --with-blas="-L/usr/lib/x86_64-linux-gnu/ -lopenblas" --with-lapack

which leads to

...
checking for dgemm_ in -L/usr/lib/x86_64-linux-gnu/ -lopenblas... yes
checking whether double complex BLAS can be used... yes
checking whether the BLAS is complete... yes
checking for dpstrf_... yes
...

[DBScan]

I've successfully managed to compile R version 4.3.1 with the following command:

./configure \
  --prefix=${INSTALL_DIR} \
  --with-x=no \
  --with-tcltk \
  --with-recommended-packages=no \
  --enable-BLAS-shlib \
  --enable-R-shlib \
  --with-blas="-lopenblas -I/opt/OpenBLAS-0.3.23/include -L/opt/OpenBLAS-0.3.23/lib -fopenmp"

It seems like the issue with LAPACK is only displayed during the configuration step, my sessionInfo() now correctly lists the following:

Matrix products: default
BLAS/LAPACK: /opt/OpenBLAS-0.3.23/lib/libopenblas_zenp-r0.3.23.so;  LAPACK version 3.11.0

I am using Rocky Linux 9.2 and compiled OpenBLAS with the following options:

make BINARY=64 TARGET=ZEN USE_OPENMP=1
make install BINARY=64 TARGET=ZEN USE_OPENMP=1 PREFIX=/opt/OpenBLAS-0.3.23

[michaelmayer]

I agree with that - R figures out what to do to best link against OpenBLAS - I ran a few tests comparing various compilation methods but the two approaches in this ticket (despite the different configure messages lead to the same compute performance.

[DBScan]

Thanks for checking! Have you by any chance used BLIS (for BLAS) and libflame (for LAPACK)?

[michaelmayer]

I am aware of BLIS and libflame but have not extensively tested it myself so far.

While some of the performance results from BLIS/libflame shown on the various gh pages look rather impressive, I also need to state that having a performant BLAS/LAPACK implementation is helpful but will only help with speeding up codes if the majority of time is spent in BLAS/LAPACK routines and the data size is sufficiently large.

Benchmarks like https://mac.r-project.org/benchmarks/R-benchmark-25.R show speed-ups of 10x and more when used with OpenBLAS and Intel MKL but in real-world code the speed-up on average I have seen is more in the 20-30 % range (if at all). Also, OpenBLAS is packaged in most if not all Linux distributions today and hence makes it more easy to integrate it with R. A possible alternative with regards to ease of integration would be to look into flexiblas

In my very own tests of comparing Intel MKL, OpenBLAS and vanilla LAPACK/BLAS the mentioned R benchmark execution time was 5.2 s / 6.6 s / 38.4 s, respectively.

While in the past I have been a strong proponent of Intel MKL and have pushed the limits of the Intel toolkit (Intel Compilers + MKL) to the limits, I have come to the conclusion that GNU Compilers + OpenBLAS for most workloads is close enough to Intel MKL performance so that the extra overhead and potential troubles with reproducibility (MKL_CBWR) and stability is just not worth it. With R being an open source product it also does not feel right to combine it with a yet free but closed source product such as Intel MKL.

But don't get me wrong - if you and your colleagues have codes that call R functions that make efficient use of BLAS/LAPACK (i.e.push enough data into those BLAS/LAPACK functions) and also spend the majority of time during code execution in BLAS/LAPACK, you really should continue to optimise for BLAS/LAPACK performance.

While I am far from trying to quench your desire for optimising performance of R via BLAS/LAPACK - having the R developers write efficient code still goes a long way compared to tuning the R installation.

[DBScan]

Many thanks for the detailed explanation!

[tmc]

If it's useful to see, I tested this a couple years ago. Here's a summary of the results comparing three different OS with default vs optimized BLAS: Assessing R performance with optimized BLAS across three operating systems | T. Crow