Linking Intel's Math Kernel Library (MKL) to R on Windows

Question

Using an alternative BLAS for R has several advantages, see e.g. https://cran.r-project.org/web/packages/gcbd/vignettes/gcbd.pdf.

Microsoft R Open https://mran.revolutionanalytics.com/documents/rro/installation/#sysreq is using Intel's MKL instead of the default Reference BLAS to speed up calculations.

My question is:

What would be the exact steps to link Intel's MKL library **manually to R**'s most recent version on Windows (https://cran.r-project.org/bin/windows/base/)?

---

UPDATE 20-07-2016: Here is very detailed description on how to build a OpenBLAS-based Rblas.dll for 64-bit R for Windows for R ≥ 3.3.0: http://www.avrahamadler.com/r-tips/build-openblas-for-windows-r64/

Zitella

I believe you have to compile R (old, sorry), which can get complicated; apparently the compiled releases are pretty carefully optimized. There are sometimes exceptions, though; on OS X you can switch it to the built-in Accelerate BLAS without recompiling. I believe RcppArmadillo has further BLAS/LAPACK capabilities, too; maybe if you're lucky Dirk will stop by and give you better advice than I can. – Exon

Yep, I've found many blog posts on how to do this for Linux, some on how to do this for Mac, but with regards to Windows everybody seems to avoid the "manual way" opting for the obvious solution, i.e. Revolution R / Microsoft R Open. – Zitella

From what I've read (maybe incorrect), that's because it's a pain to compile well without near R-Core level expertise. Really, unless you handle huge matrices regularly, MKL may not really make much of a difference for you, though, so the point may be moot. – Exon

This would then also apply to any other BLAS like OpenBLAS, right? – Zitella

Yup, AFAIK. I think the OS X Accelerate framework thing is a one-off; anything else takes compilation. – Exon

Worth a look if you haven't: the CRAN R Installation and admin guide – Exon

This dosnt really answer the question, but instead of using core team R you can switch to revolution open R which uses the MKL blas. All packages are still usable as always, and the integration with Rstudio is just as easy. You simply download, install and then you are ready to go – Lure

Thanks. Revolution R Open is now called Microsoft R Open (as described in my question). – Zitella

Yea this one is a big headache because what you're asking for actually is a huge deal and if we could do it then we should just brand the final product and start competing with Microsoft ;) I think this is a great question though and I only wish we could make a community bounty that's like 500 pts so maybe it will get answered. @Exon That doc page says "There are also versions of MKL for OS X and Windows, but at the time these were tried they did not work with the standard compilers used for R on those platforms." BTW this question deserves more upvotes. – Jaquelynjaquenetta

I want to correct one of the premises in your question. The Microsoft team are releasing MRO for every release of R, including all minor releases. Right now, there is some delay in getting the releases out, but we are working on ways of reducing this delay. I view the hurdles as more commercial than technical. To redistribute the MKL, you need a contract with Intel that allows you to do this. – Featherweight

Thanks for the clarification. I updated the question. – Zitella

@Zitella Did the instructions work for you? – Bedazzle

Answer 1

Easier solution than having to recompile R against the Intel MKL libraries on Windows is just to

1. Install Microsoft R Open from https://mran.microsoft.com/download, which comes with the outdated R version 3.5.3 but also with the Intel MKL multithreaded BLAS libraries
2. Install the latest version of R from https://cran.r-project.org/bin/windows/base/, i.e. currently R 3.6.2
3. copy files libiomp5md.dll, Rblas.dll and Rlapack.dll from C:\Program Files\Microsoft\R Open\R-3.5.3\bin\x64 to C:\Program Files\R\R-3.6.2\bin\x64 (you can back up your existing default non-hyperthreaded Rblas.dll and Rlapack.dll files first if you like)
4. copy Microsoft R Open libraries/packages MicrosoftR, RevoIOQ, RevoMods, RevoUtils, RevoUtilsMath and doParallel from C:\Program Files\Microsoft\R Open\R-3.5.5\library to your default package directory, e.g. C:\Documents\R\win-library\3.6
5. copy files Rprofile.site and Renviron.site from directory C:\Program Files\Microsoft\R Open\R-3.5.5\etc to C:\Progral Files\R\R-3.6.2\etc
6. replace line 24 in file Rprofile.site options(repos=r) with options(repos="https://cran.rstudio.com") (or your favourite CRAN repository - you can also use "https://cran.revolutionanalytics.com", the MRO repository that has the latest daily builds of all packages) to make sure that it will install the latest CRAN packages as opposed to the outdated mran.microsoft.com mirror that has outdated package versions, frozen at the 15th of April 2019. Also comment out lines 153, 154 and 155 with a #

Then restart RStudio to check that it works, with small SVD benchmark on my Intel Core i7-4700HQ 2.4GHz 4 core/8 thread laptop:

getMKLthreads()
4

# Singular Value Decomposition
m <- 10000
n <- 2000
A <- matrix (runif (m*n),m,n)
system.time (S <- svd (A,nu=0,nv=0))
   user  system elapsed 
  15.20    0.64    4.17

That same benchmark without Intel MKL installed ran at

   user  system elapsed 
  35.11    0.10   35.21 

so we get a >8 fold speed increase here!

Screenshot of Microsoft R Open 6.2 with Intel MKL up and running:

Alternatively, if you don't like copying files from MRO to your latest R installation, you can also copy the files from the free Intel MKL installation to your R installation to get multithreaded operation (as outlined in the other answer below):

1. Install Intel MKL from https://software.intel.com/en-us/mkl/choose-download (free)

Copy all the contents from inside these folders

C:\Program Files (x86)\IntelSWTools\compilers_and_libraries\windows\redist\intel64\mkl
C:\Program Files (x86)\IntelSWTools\compilers_and_libraries\windows\redist\intel64\compiler

to

C:\Program Files\R\R-3.6.1\bin\x64

2. Inside the destination folder, create 2 copies of mkl_rt.dll and rename one of them Rblas.dll and the other Rlapack.dll replacing the originals and also keeping mkl_rt.dll.
3. This will not provide you with the function setMKLthreads() and getMKLthreads() functions though to set the nr of intel MKL threads, as these come with the MRO package RevoUtilsMath. But for most people the default nr of threads set equal to the nr of physical cores will be OK though...

Not sure what's up with Microsoft, and why they are no longer updatig MRO... And why they also dropped Mac OS X support...

I hope that, given that Intel MKL is free now, the R core people will sooner or later provide a precompiled R version that is compiled to use the Intel MKL libs, or possibly detect at run time if Intel MKL is installed, and if it is, use it. I think this is important, especially since the easy availability of a good multithreaded BLAS also determines how one would develop packages - e.g. if a good multithreaded BLAS would be available for all OSes one would veer towards using RcppArmadillo, which falls back on whatever BLAS one has installed (but on Windows would give drastically worse timings if Intel MKL is not installed), and if not RcppEigen would be the best option, as that has its own multithreaded matrix algebra, irrespective of the BLAS against which R is compiled......

On Ubuntu btw it's very easy to make R use Intel MKL, without having to recompile R, as outlined here: https://github.com/eddelbuettel/mkl4deb

PS Slight problem is that running setMKLthreads(4) will crash RStudio (that was already a problem in the official MRO 3.5.3 though) but it does work OK in the R console...

Ogrady

Just noticed that this link is to a dropbox account. Seems sketchy. @Tom, can you link to something on Intel's website? – Cupriferous

Problem is that they only provide it packaged together with the whole of Microsoft Open R. But I found that all that was needed to make Intel MKL work were these files, which is why I put those separately on dropbox... Haven't been able to track down a good download location unfortunately... – Ogrady

"move the files from there..." yeah, don't do that. I don't know what will happen if you start mixing up binaries from different releases of R, but I'm betting something will go wrong. MRO is R anyway; everything you want to do with the regular version, you should be able to do with MRO – Salesroom

Yes but Microsoft Open R is always a little behind in terms of R releases, and the question was how to get multithreaded operation in the latest version of R (which is never the one that is shipped with Microsoft Open R). Myself I just use MRO, indeed... But this little trick works, believe me and it's so much easier than having to recompile R against some custom optimized BLAS... – Ogrady

Moving the MKL libs from MRO to normal R is a breach of the license: mran.microsoft.com/assets/text/mkl-eula.txt – Degas

It's really high time btw that MRO should publish a version with R 3.6.1. Not sure why it's taking them so long... – Ogrady

@HongOoi Just updated the info on how to get R 3.6.2 use Intel MKL and confirmed once more that it works just by copying across a couple of files! – Ogrady

@hansi Just updated the info on how to get R 3.6.2 use Intel MKL and confirmed once more that it works just by copying across a couple of files! – Ogrady

@kennyb Just updated the info on how to get R 3.6.2 use Intel MKL and confirmed once more that it works just by copying across a couple of files! – Ogrady

Does this still work with CRAN R 4.0.3, and MRO not having been updated still? – Tooth

Follow the procedures above for R 4.1.2. Unsuccessfully. Can anyone claim update this procedure to the most current version of R? the most current version of Microsoft R is 4.0.2. – Paz

I followed the first procedure (i.e. copy from MRO). It seems to work with R version 4.1.1. I.e. RStudio starts w/o errors, simple benchmark (mainly chol) indicates speedup of factor 4. One small issue: one has to fix a few assignments in Rprofile.site following this SO answer – Presentment

Update: Now I did run into trouble. It is not possible to execute any Numpy linear algebra code using reticulate in RStudio. The session crashes immediately. – Presentment

Did you try in the R console, ie not in RStudio? Does it crash there too? I recall that executing setMKLthreads(4) also crashes RStudio, but not the R console (that was also a problem already in the official MRO release). – Ogrady

Answer 2

I was able to link R 3.6.0 with custom dlls you create using the builder. Basically you have to export the same symbols Rblas.dll and Rlapack.dll do. Start the Compiler 19.0 Update 4 for Intel 64 Visual Studio 2017 environment command prompt:

Get the symbols:

dumpbin /exports Rblas.dll > Rblas_list
dumpbin /exports Rlapack.dll > Rlapack_list_R

Edit both files deleting the "header" and "footer" and have all the lines with the symbol names (ex.: 248 F7 00138CE0 dgeevx_) be like dgeevx_ (only with the names). Copy the builder directory to somewhere in your pc and inside it run:

# blas links fine
nmake libintel64 export=..path..\Rblas_list name=Rblas 
# save lapack errors in another list
nmake libintel64 export=..path..\Rlapack_list_R name=Rlapack 1> undefined_symbols_list

Edit undefined_symbols_list keep only the names in each line and create a new list with the difference

findstr /v /g:undefined_symbols_list Rlapack_list_R > Rlapack_list
nmake libintel64 export=..path..\Rlapack_list name=Rlapack

With dumpbin /dependents Rlapack.dll, you can see that they depend on libiomp5md.dll, which you can find inside the redist folder in mkl installation.

---

Method 2

This method uses more disk space, but it's simpler. Copy all the contents from inside these folders

C:\Program Files (x86)\IntelSWTools\compilers_and_libraries\windows\redist\intel64\mkl
C:\Program Files (x86)\IntelSWTools\compilers_and_libraries\windows\redist\intel64\compiler

to

C:\Program Files\R\R-3.6.1\bin\x64

Inside the destination folder, create 2 copies of mkl_rt.dll and rename one of them Rblas.dll and the other Rlapack.dll replacing the originals and also keeping mkl_rt.dll.

Levantine

Would you be willing to turn this into a blog with slightly more details step by step? – Degas

maybe, I don't have a blog. Which part would you like more details? – Levantine

This is a great advance. I would like, if possible, a more verbose version of your description. Particularly method 2. Do you download the MKL from software.intel.com/en-us/mkl/choose-download/windows, install, and copy mkl_rt.dll twice, rename the first copy to Rblas.dll, and the second copy of mkl_rt.dll Rlapack.dll ? Therefore not requiring VS 2017? – Edina

@Edina Yes, download it from Intel. Method 2 is simple copy and paste of redist folder, so if you're able to install it without VS then you're good to go. Note that, having all these dlls in the same folder is equivalent of having them on a folder in PATH (assuming only that folder contains these dlls). However, same folder is safer. – Levantine

Both Rblas.dll and Rlapack.dll will be the same mkl_rt.dll file? – Lampoon

I have tried your method 2 but R doesn't detect MKL – Lampoon

@Lampoon Yes, they'll be same copy of mkl_rt.dll as R expects Rblas.dll and Rlapack.dll. How can you tell it doesn't detect MKL? Does it crash? Error message? – Levantine

If I start R open (with MKL already integrated) it shows the message "Using the Intel MKL for parallel mathematical computing (using 4 cores)". But when I use a regular R version, 3.6.2, and copy mklRblas.dll and Rlapack.dll as you explained... it doesn't show any message. And later executing setMKLthreads(4) gives the error this function doesn't exist. – Lampoon

@Lampoon Ok, the startup message and setMKLthreads(4) are from MRAN distribution. Before running any function (before R loads blas/lapack) turn on the MKL verbose mode with Sys.setenv(MKL_VERBOSE=1) and run a simple lm(dist~speed,cars), you should see some MKL function calls. Compare time with this benchmark script https://mac.r-project.org/benchmarks/R-benchmark-25.R. – Levantine

OK, it seems to work, thanks. Do all regular R's packages automatically use these dll files? Or I need to explicitly recompile them linking the MKL libraries? – Lampoon

@Lampoon I've noticed that, in method 2, if a package's dll is linked to Rblas or Rlapack, it'll actually be linked to mkl_rt.dll because simple renaming doesn't change the dll metadata. You can check this with dumpbin; e.g. with package quantreg: dumpbin /imports Documents\R\win-library\3.6\quantreg\libs\x64\quantreg.dll – Levantine

@Lampoon also leave mkl_rt.dll there – Levantine

Hello @GuilhermeHigashi. I'm trying this a couple of years later and can only install Intel's new oneAPI. The files are now in: C:\Program Files (x86)\Intel\oneAPI\mkl\2022.0.3\redist\intel64 and as far as I can see it's now mkt_rt.2.dll. I follow the process as above and R loads fine but crashes as soon as any linear algebra is called with no error message (just the standard WIndows "this program has crashed" type thing). Any ideas? – Tenet

Nevermind - the compiler files are now C:\Program Files (x86)\Intel\oneAPI\compiler\2022.0.3\windows\redist\intel64_win\compiler I forgot these seeing as they're in a different part of the folders now! – Tenet

Answer 3

just tried for R 3.5.1 installation. I installed Microsoft R Open alongside with the CRAN R and copy libiomp5md.dll and overwrite Rblas.dll, Rlapack.dll from MRO MKL counterparts to link to CRAN R on Windows (similar to another answer above but need to copy the file libiomp5md.dll as well). This worked out fine and the CRAN R runs as fast as MRO according to the version.compare package on Github (https://github.com/andrie/version.compare)

Keyte

Added some more detailed instructions above and confirmed that this works! Thx! – Ogrady

Answer 4

I followed the recommendations of @guilherme-higashi above (see method 2).

I'm using windows 11, R 4.3.2 and downloaded the oneAPI mkl tools from Intel. I copied the entire contents of

C:\Program Files (x86)\Intel\oneAPI\mkl\2024.0\bin

and

C:\Program Files (x86)\Intel\oneAPI\compiler\2024.0\bin

into the location of the R x64 subfolder, so for me

C:\Program Files\R\R-4.3.2\bin\x64

Then I made three copies of mkl_rt.2.dll and renamed two of them to Rblas.dll and Rlapack.dll. Opening R now and running sessionInfo() gives the following results:

R version 4.3.2 (2023-10-31 ucrt)
Platform: x86_64-w64-mingw32/x64 (64-bit)
Running under: Windows 11 x64 (build 22631)

Matrix products: default

which is slightly confusing but I can certainly tell you that R is using the oneAPI mkl and not R's original blas and lapack. Using this R benchmarking script I got 2.77333 seconds compared to 14.97 seconds using default Rblas and Rlapack under R 4.3.1 on the same machine.

Gauldin

Answer 5

The solution presented by Tom Weenseleers worked for me with the latest R version. Thank you.

I wanted to add something to this discussion, as its related, and I was unsure how to add this to the greater community. Please forgive my descriptions, I am an amateur.

This workaround seems to break at least two other R packages, igraph, and clusterProfiler. Clusterprofiler depends on igraph, so the root cause was igraph. Likely other igraph dependent packages as well.

I am posting this because I found a simple workaround, and after extensive searching I never found this addressed explicitly on any forum, and this may help someone else.

for reference, clusterProfiler_4.4.4 and igraph_1.3.4 R version 4.2.1, Platform: x86_64-w64-mingw32/x64 (64-bit) Windows 10 x64 (build 22000)

calling library(igraph) after implementing the above workaround yielded the following error in a popup:

rsession-utf8.exe Entry Point Not Found The procedure entry point quadmath_snprintf could not be located in the dynamic link library C:Program Files\R\R->4.2.1\library\graph\libs\x64\igraph.dll.

Pressing OK yields an error message in R

Error: package or namespace load failed for ‘igraph’ in inDL(x, >as.logical(local), as.logical(now), ...): unable to load shared object 'C:/Program Files/R/R->4.2.1/library/igraph/libs/x64/igraph.dll': LoadLibrary failure: The specified procedure could not be found.

The workaround - When implementing the workaround to use MKL in R, keep the original Rlapack.dll and Rlablas.dll (i simply renamed these i.e Rblas_orig.dll) To use igraph or dependent packages, swap the .dll filenames, such that the two original R blas file has the original name, and the MKL file is renamed (i.e. Rblas_mkl.dll). Restart R, and igraph/clusterprofiler loads fine.

Unfortunately, this will disable the MKL until you revert the .dll filenames again and restart R, but as long as you don't need to use both igraph and MKL at the same time it works, although frustrating.

If anyone finds a better solution please let me know.

Sanalda

Answer 6

The latest dev version of igraph seems to have solved this. To install the latest version:

devtools::install_github("igraph/rigraph")

This seems to be a bug in R-core which is re-exporting a symbols from libquadmath in Rlapack.dll. The fix seems to be to linked to libquadmath before Rlapack.

This worked with the latest oneMKL and R 4.3.0, using the corrections mentioned in some of the comments above (by @Mooks).

Nodus