R with GotoBLAS on Windows 10

In my experience, the default libRblas gives horrible performance across all of the platforms that I regularly use (Windows, Mac OS & Linux). The R package that I’m currently developing uses RcppEigen, which is not dependent on an efficient BLAS or LAPACK library. However, many other R packages do have this dependency. Therefore, I would recommend following the instructions in the R Installation and Administration guide to switch over to a more efficient implementation. Avraham Adler, Tony Fischetti and Zachary Mayer have written similar blog posts on this topic. I use the Accelerate Umbrella Framework (vecLib) on OS X and Intel MKL with icc on Linux. The following instructions describe how (and why) to install GotoBLAS for R on Microsoft Windows.

As described in pp. 191-192 of “Seamless R and C++ Integration with Rcpp” (DOI: 10.1007/978-1-4614-6868-4), the lmBenchmark script can be used as a rough performance measurement for dense matrix algebra on any system. You need to install the packages RcppEigen and rbenchmark, then run:

Rscript -e "source(system.file(\"examples\", \"lmBenchmark.R\", package = \"RcppEigen\"))"

The output should look something like this (with default Rblas.dll):

lm benchmark for n = 1650 and p = 875: nrep = 20
   user system  elapsed 
2021.83  21.27  2043.75 

   test relative elapsed user.self sys.self
3  LDLt    1.000    4.70      4.54     0.17
7  QR      1.374    6.46      6.25     0.20
8  LLt     1.436    6.75      6.44     0.32
1  lm.fit  3.853   18.11     18.03     0.03
6  SymmEig 5.700   26.79     26.57     0.22
2  PivQR   9.783   45.98     26.75    19.20
9  arma   19.155   90.03     89.72     0.29
4  GESDD  19.313   90.77     90.53     0.22
5  SVD   184.362  866.50    865.94     0.39
10 GSL   188.672  886.76    886.19     0.21

R version 3.2.3 (2015-12-10)
Platform: x86_64-w64-mingw32/x64 (64-bit)
Running under: Windows >= 8 x64 (build 9200)

These timings are for a 1650 × 875 matrix, rather than the default of 100,000 × 40. The results are highly dependent on the matrix dimensions, so you should use a size that is representative of the data that you are working with. The benchmark was run on a 2GHz Intel Core i7-4750HQ with Windows 10. You can compare these results to Table 12.2 on pg. 191 of Eddelbuettel (2013).

I installed OpenBLAS from SourceForge (the usual caveats for downloading binaries from SourceForge notwithstanding). Unfortunately, the usual method of replacing libRblas with libopenblas (or a softlink) is a one-way trip to DLL hell on Windows. If you start getting an error message that libgcc_s_seh-1.dll is missing, switch back to the original Rblas.dll (you did make a backup copy, right?). There are drop-in replacements using SurviveGotoBLAS 3.14 for some CPU architectures available here, but unfortunately not for the 4th generation Haswell with SSE 4.2 and AVX 2.0 instructions.

These are the results for the SurviveGotoBLAS binary (Nehalem architecture):

lm benchmark for n = 1650 and p = 875: nrep = 20
 user system elapsed 
2012.86 115.13 2072.31 

   test relative elapsed user.self sys.self
3  LDLt    1.000    4.71      4.45     0.25
7  QR      1.465    6.90      6.59     0.30
8  LLt     1.643    7.74      7.47     0.27
4  GESDD   4.662   21.96     38.75     5.33
6  SymmEig 6.270   29.53     29.24     0.28
9  arma    6.696   31.54     61.69    11.65
2  PivQR   9.688   45.63     26.45    19.10
1  lm.fit 25.607  120.61     36.31    77.37
5  SVD   190.735  898.36    897.09     0.43
10 GSL   191.970  904.18    903.67     0.13

RcppArmadillo (“arma”) improved from 90s elapsed time to 31.5, almost a 3× speedup. Likewise, GESDD improved from 90.8s to 22. However, lm.fit is slower at 120.6s elapsed. The 77s spent in sys.self is likely due to threading issues. Clearly, this is far from the desired outcome in switching BLAS implementations. There is a workaround for this issue, which is to install the R package RhpcBLASctl. This offers a function blas_set_num_threads(..) that you can use to force BLAS to be single-threaded.

Results for single-threaded SurviveGotoBLAS were as follows:

lm benchmark for n = 1650 and p = 875: nrep = 20
 user system elapsed 
1894.76 23.33 1919.85

   test relative elapsed user.self sys.self
3  LDLt    1.000    4.67      4.46     0.21
7  QR      1.355    6.33      6.08     0.25
8  LLt     1.422    6.64      6.43     0.22
1  lm.fit  1.623    7.58      7.50     0.08
6  SymmEig 5.728   26.75     26.39     0.33
9  arma    6.503   30.37     29.89     0.40
4  GESDD   7.017   32.77     32.45     0.32
2  PivQR  10.107   47.20     26.33    20.86
5  SVD   186.285  869.95    868.83     0.45
10 GSL   189.852  886.61    885.47     0.19

As described by Avraham Adler, the alternative is to install MSYS2 & MINGW64, then compile both OpenBLAS & R from source. Once again, Windows is the redheaded stepchild of platforms for running R.

Note that the Gnu scientific library (GSL) is also available for Windows. If you want to run lmBenchmark for RcppGSL, then you will also need to install it. However, GSL uses its own libgslcblas.dll, so it won’t benefit from installing OpenBLAS as described above. I don’t know why gsl_multifit_linear(..) is so slow, in comparison to all of the other implementations. I’ve observed similar RcppGSL performance when I ran lmBenchmark on Linux and OS X.