I wanted to report an issue with R 4.5.2 for arm64, which is caused by the
change in the default BLAS from R�s standard BLAS library to using Apple
Accelerate vecLib BLAS library by default. In 4.5.1 and earlier, R for macOS
ships with the standard R BLAS. To change to vecLib, users had to deliberately
invoke this using a terminal command to change a symlink:
https://cran.r-project.org/bin/macosx/RMacOSX-FAQ.html#Which-BLAS-is-used-and-how-can-it-be-changed_003f
However, R 4.5.2 for arm64 now defaults to vecLib. For intel macOS, 4.5.2 stays
with the standard R BLAS. VecLib BLAS has a problem with parallelisation using
mclapply() which now gives a warning and returns NULL if mc.cores >= 2 and
vecLib is invoked e.g. by the use of crossprod(). Here�s a short reprex:
system("readlink /Library/Frameworks/R.framework/Resources/lib/libRblas.dylib")
# R 4.5.2 arm64: libRblas.vecLib.dylib
# R 4.5.1 arm64: libRblas.0.dylib
N <- 200
M <- 4000
X <- matrix(rnorm(N*M),N)
library(parallel)
# ok
res <- mclapply(1:4, function(i) {crossprod(X + i)}, mc.cores = 1)
# ok in R 4.5.1
# not ok in R 4.5.2 arm64 (but works if M is smaller)
res <- mclapply(1:4, function(i) {crossprod(X + i)}, mc.cores = 2)
# gives warning and `res` contains NULL
The same error occurs on Intel & arm Macs with any version of R if the BLAS is
switched to VecLib by symlink.
My question is whether R for arm64 should go back to standard R BLAS by
default. Otherwise, users may find that functions which invoke the BLAS e.g.
lm() may crash unexpectedly and return NULL when parallelised using mclapply (a
fairly common situation in lots of packages).
Thanks,
Myles Lewis
[[alternative HTML version deleted]]
_______________________________________________
R-SIG-Mac mailing list
[email protected]
https://stat.ethz.ch/mailman/listinfo/r-sig-mac
