Myles, thanks, I'll have a look if I can reproduce it. The default for most builds is the reference BLAS and I heave not heard issues with the vecLib/Accelerate BLAS before, either, so it's quite rare (you are the first one to report an issue), but I'll look into it. In general, forking processes is always fraught with peril, that's why we warn about it and you shouldn't do it unless you are absolutely sure it's safe - and it certainly makes no sense (and is not safe) if you use any other kind of parallelization as that defeats the purpose. (FWIW on arm64 it's more complicated than that, because the speed gains are not by parallelization, but by the use of the AMX co-processor which is independent of the CPU).
Cheers, Simon > On 16/01/2026, at 00:27, Myles Lewis <[email protected]> wrote: > > Hi Simon, > > I’ve tested this on MacBook Pro 14-inch 2023 M3 max, running Sequoia 15.7.3. > I’ve also tested this on iMac 27-inch 2019 intel 8-core i9 running Sonoma > 14.8.3. Both have 64 GB RAM. > > It’s linked to Veclib. When using R 4.5.2 on the Intel Mac, it works fine > because R’s standard BLAS is the default. But on either machine if I change > the BLAS symlink to vecLib then the error occurs. That’s true even with old > versions of R version 4.x.x. If I change the symlink back to the default R > BLAS, the error goes away. It occurs in both R via normal Mac GUI as well as > in Rstudio. > > Here’s my sessionInfo on the ARM machine: > > > sessionInfo() > R version 4.5.2 (2025-10-31) > Platform: aarch64-apple-darwin20 > Running under: macOS Sequoia 15.7.3 > > Matrix products: default > BLAS: > /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libBLAS.dylib > > LAPACK: > /Library/Frameworks/R.framework/Versions/4.5-arm64/Resources/lib/libRlapack.dylib; > LAPACK version 3.12.1 > > locale: > [1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8 > > time zone: Europe/London > tzcode source: internal > > attached base packages: > [1] stats graphics grDevices utils datasets methods base > > loaded via a namespace (and not attached): > [1] compiler_4.5.2 > > It’s dependent on the size of the matrix. With smaller M (e.g. M=400), the > error goes away. I’m assuming that crossprod() does not invoke multiple > threads with small M. > > Thanks, > Myles > > From: Simon Urbanek <[email protected]> > Date: Wednesday, 14 January 2026 at 22:41 > To: Myles Lewis <[email protected]> > Cc: [email protected] <[email protected]> > Subject: Re: [R-SIG-Mac] Parallel errors with default BLAS (vecLib) in R > 4.5.2 for arm64 > > [You don't often get email from [email protected]. Learn why this > is important at https://aka.ms/LearnAboutSenderIdentification ] > > Myles, > > can you please, provide more details such as exact versions of your macOS and > well as details on the hardware you are using? I cannot reproduce the problem > - it works perfectly fine for me on M3 running macOS 26.0.1 so it would be > good to know what the conditions for failure are. > > Thanks, > Simon > > > > On 15 Jan 2026, at 06:05, Myles Lewis via R-SIG-Mac > > <[email protected]> wrote: > > > > 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 > _______________________________________________ R-SIG-Mac mailing list [email protected] https://stat.ethz.ch/mailman/listinfo/r-sig-mac
