Further macOS OpenMP tweaks #497
Conversation
There was a problem hiding this comment.
Pull Request Overview
This PR improves OpenMP support on macOS by removing the previous blanket special-casing and introducing a more flexible configuration approach that respects compiler capabilities while still allowing opt-out.
Key changes:
- Introduced macOS-specific OpenMP detection that enables OpenMP by default when the compiler supports it (
_OPENMPis defined), with an opt-out mechanism via a new configuration macro - Removed the blanket exclusion of OpenMP flags for macOS in the inline plugin function
- Conditionally restricted
ARMA_CRIPPLED_LAPACKdefinition to only legacy Armadillo versions on Windows
Reviewed Changes
Copilot reviewed 4 out of 4 changed files in this pull request and generated 3 comments.
| File | Description |
|---|---|
| inst/include/RcppArmadillo/config/RcppArmadilloConfigGenerated.h.in | Adds macOS-specific OpenMP logic with conditional enabling based on compiler support and new opt-out macro; updates copyright years |
| inst/include/RcppArmadillo/config/RcppArmadilloConfig.h | Restricts ARMA_CRIPPLED_LAPACK to legacy Armadillo versions only; updates copyright years |
| R/inline.R | Removes macOS special case for OpenMP flags, now consistently uses $(SHLIB_OPENMP_CFLAGS) across all platforms; updates copyright year |
| ChangeLog | Documents the R/inline.R change |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
inst/include/RcppArmadillo/config/RcppArmadilloConfigGenerated.h.in
Outdated
Show resolved
Hide resolved
inst/include/RcppArmadillo/config/RcppArmadilloConfigGenerated.h.in
Outdated
Show resolved
Hide resolved
coatless
left a comment
coatless
left a comment
There was a problem hiding this comment.
In short, this is solid; however, we need to tweak Rcpp::plugins(openmp).
Specifics:
- We now get the appropriate number of cores if the local computer configuration has OpenMP.
- under the apple compiler setting we're still setting the
#define ARMA_DONT_USE_OPENMP 1.
- under the apple compiler setting we're still setting the
- Users must explicitly set in their
~/.R/Makevarsthe required OpenMP flags to opt-in:
CPPFLAGS += -Xclang -fopenmp
LDFLAGS += -lomp- If we switch over to trying to compile with OpenMP enabled via
// [[Rcpp::plugins(openmp)]]we're still getting a compile error on a locally configured mac due to only-fopenmpbeing set instead of-Xclang -fopenmp.
Failed compilation using `Rcpp::plugins(openmp)`
#include <RcppArmadillo.h>
// [[Rcpp::depends(RcppArmadillo)]]
// [[Rcpp::plugins(openmp)]]
// [[Rcpp::export]]
arma::ivec openmp_limits() {
arma::ivec limit_data(3);
#ifdef _OPENMP
limit_data[0] = omp_get_num_procs();
limit_data[1] = omp_get_max_threads();
limit_data[2] = omp_get_thread_limit();
#endif
return limit_data;
}
// [[Rcpp::export]]
bool openmp_enabled() {
bool enabled = false;
#ifdef _OPENMP
enabled = true;
#endif
return enabled;
}
// [[Rcpp::export]]
arma::ivec timesTwo(arma::ivec x) {
#pragma omp parallel for
for (size_t i = 0; i < x.size(); ++i) {
x[i] *= 2;
}
return x ;
}
/*** R
openmp_enabled()
openmp_limits()
timesTwo(42)
*/using C++ compiler: ‘Apple clang version 17.0.0 (clang-1700.4.4.1)’
using SDK: ‘MacOSX26.1.sdk’
clang++ -arch arm64 -std=gnu++17 -I"/Library/Frameworks/R.framework/Resources/include" -DNDEBUG -I../inst/include -I"/Library/Frameworks/R.framework/Versions/4.5-arm64/Resources/library/Rcpp/include" -I"/Library/Frameworks/R.framework/Versions/4.5-arm64/Resources/library/RcppArmadillo/include" -I"/Users/ronin/Documents/GitHub/rcppcore/RcppArmadillo" -I/opt/R/arm64/include -I/opt/R/arm64/include -fopenmp -fPIC -falign-functions=64 -Wall -g -O2 -c test.cpp -o test.o
clang++: error: unsupported option '-fopenmp'
make: *** [test.o] Error 1
Error in Rcpp::sourceCpp("test.cpp") :
Error 1 occurred building shared library.Standalone compilation via `sourceCpp()` with explicit `~/.R/Makevars` set
Set in ~/.R/Makevars:
CPPFLAGS += -Xclang -fopenmp
LDFLAGS += -lompSame script without plugins(openmp).
#include <RcppArmadillo.h>
// [[Rcpp::depends(RcppArmadillo)]]
// [[Rcpp::export]]
arma::ivec openmp_limits() {
arma::ivec limit_data(3);
#ifdef _OPENMP
limit_data[0] = omp_get_num_procs();
limit_data[1] = omp_get_max_threads();
limit_data[2] = omp_get_thread_limit();
#endif
return limit_data;
}
// [[Rcpp::export]]
bool openmp_enabled() {
bool enabled = false;
#ifdef _OPENMP
enabled = true;
#endif
return enabled;
}
// [[Rcpp::export]]
arma::ivec timesTwo(arma::ivec x) {
#pragma omp parallel for
for (size_t i = 0; i < x.size(); ++i) {
x[i] *= 2;
}
return x ;
}
/*** R
openmp_enabled()
openmp_limits()
timesTwo(42)
*/Compilation trail
/Library/Frameworks/R.framework/Resources/bin/R CMD SHLIB --preclean -o 'sourceCpp_2.so' 'test.cpp'
using C++ compiler: ‘Apple clang version 17.0.0 (clang-1700.4.4.1)’
using SDK: ‘MacOSX26.1.sdk’
clang++ -arch arm64 -std=gnu++17 -I"/Library/Frameworks/R.framework/Resources/include" -DNDEBUG -I../inst/include -I"/Library/Frameworks/R.framework/Versions/4.5-arm64/Resources/library/Rcpp/include" -I"/Library/Frameworks/R.framework/Versions/4.5-arm64/Resources/library/RcppArmadillo/include" -I"/Users/ronin/Documents/GitHub/rcppcore/RcppArmadillo" -I/opt/R/arm64/include -I/opt/R/arm64/include -Xclang -fopenmp -fPIC -falign-functions=64 -Wall -g -O2 -c test.cpp -o test.o
clang++ -arch arm64 -std=gnu++17 -dynamiclib -Wl,-headerpad_max_install_names -undefined dynamic_lookup -L/Library/Frameworks/R.framework/Resources/lib -L/opt/R/arm64/lib -L/opt/R/arm64/lib -lomp -o sourceCpp_2.so test.o -L/Library/Frameworks/R.framework/Resources/lib -lRlapack -L/Library/Frameworks/R.framework/Resources/lib -lRblas -L/opt/gfortran/lib/gcc/aarch64-apple-darwin20.0/14.2.0 -L/opt/gfortran/lib -lemutls_w -lheapt_w -lgfortran -lquadmath -F/Library/Frameworks/R.framework/.. -framework R
Output
> openmp_enabled()
[1] TRUE
> openmp_limits()
[,1]
[1,] 12
[2,] 12
[3,] 2147483647
> timesTwo(42)
[,1]
[1,] 84| inlineCxxPlugin <- function(...) { | ||
| ismacos <- Sys.info()[["sysname"]] == "Darwin" | ||
| openmpflag <- if (ismacos) "" else "$(SHLIB_OPENMP_CFLAGS)" | ||
| openmpflag <- "$(SHLIB_OPENMP_CFLAGS)" |
There was a problem hiding this comment.
Shouldn't this be SHLIB_OPENMP_CXXFLAGS instead?
| openmpflag <- "$(SHLIB_OPENMP_CFLAGS)" | |
| openmpflag <- "$(SHLIB_OPENMP_CXXFLAGS)" |
There was a problem hiding this comment.
It does not matter in practice. There are three, they are always identical (?) and CRAN only complains if you use different ones between compiler and linker. I have long used the C variant for simplicity (though also probably not always).
edd@paul:~$ grep SHLIB_OPENMP_ /etc/R/Makeconf
SHLIB_OPENMP_CFLAGS = -fopenmp
SHLIB_OPENMP_CXXFLAGS = -fopenmp
SHLIB_OPENMP_FFLAGS = -fopenmp
edd@paul:~$ | #if !defined(ARMA_USE_OPENMP) | ||
| #if defined(__APPLE__) && defined(_OPENMP) | ||
| // User has OpenMP available, but check if they want it disabled | ||
| #ifndef RCPPARMA_MACOS_DISABLE_OPENMP |
There was a problem hiding this comment.
Is the standard prefix RCPPARMA? Or should we go RCPPARMADILLO ?
There was a problem hiding this comment.
Good catch. Both better and more consistent. Will switch to long form.
(I think I followed your suggestion letter by letter though 😜 )
There was a problem hiding this comment.
@eddelbuettel I know. I couldn't remember what was settled on for the prefix though post legacy/current defines.
|
I think given how messy the macOS situation is in general when it comes to OpenMP I am ok with requiring the file Or do you think we can do substantially better? By altering the openmp plugin in Rcpp? Even if so (and we can look at that for Rcpp) it seems like this PR is ready and improves over the previous one? Big thank you for all the very detailed and helpful feedback. |
|
@eddelbuettel yes to a large extent. The other option is setting session options via There shouldn't be anymore hold up on this PR. I'll shoot over a change PR for Rcpp
I'm not going to add a check on the plugin itself for whether OpenMP is correctly setup. The goal of making the plugins PR is to have some level of "unity" across standalone C++ scripts so there isn't a "gotcha" if Edit: PR now available at: |
|
Hey @coatless I am going to hang this here for context... I had noticed that RcppArmadillo started to fail at r-universe for arm64 and (finally) pinged @jeroen who, apparently without having to look at it, asked me about OpenMP. So I guess still more compilcations. Copying what I had sent to @jeroen: Bad at r-universeGood at macbuilder (when I wrap it up and submit it) |
|
@eddelbuettel @jeroen I think this might be a result of forking happening since tinytest has the tests running in parallel to speed up execution: Maybe we add |
|
Are you sure? I know tinytest quite well, may even have been the one in the suggesting an explicit parallel mode to Mark and am fairly certain he is not in parallel by default. The entry point via tests/tinytest.R is commonly tinytest::test_package() and ncpu=NULL it will not parallelise: Glancing at the code seems to confirm that NULL for |
|
@eddelbuettel my gut is saying something is being forked somewhere causing the OpenMP process to be a child and that's what is causing the segfault on macOS ARM64. From the 
I'm not at all familiar with r-universe infrastructure; but, that's my guess as @jeroen likely would have seen this issue appear elsewhere. I'll look later tonight. This change can be pulled back if needed. |
|
I am all for a working hypothesis, and I (or you) can easily branch off RcppArmadillo and tickle a build with the number of threads forced to 1. I just don't think that tinytest is the smoking gun as I use it many other places too... |
|
The other, even simpler, test would of course be GHA. I install mac and fortran via wget -q ${CRAN}/bin/macosx/big-sur-${ARCH}/base/R-${RVER}-${ARCH}.pkg -O /tmp/R-latest.pkg
sudo installer -pkg "/tmp/R-latest.pkg" -target /
wget -q https://mac.r-project.org/tools/gfortran-14.2-universal.pkg -O /tmp/gfortran.pkg
sudo installer -pkg "/tmp/gfortran.pkg" -target /which gets me default R and Fortran. What does one then do for OpenMP or is this enough as it is included these days? |
|
@eddelbuettel this should work: - name: Install R for macOS
if: runner.os == 'macOS'
run: |
CRAN="https://cran.r-project.org"
RVER="4.5.2"
ARCH="arm64"
wget -q ${CRAN}/bin/macosx/big-sur-${ARCH}/base/R-${RVER}-${ARCH}.pkg -O /tmp/R-latest.pkg
sudo installer -pkg "/tmp/R-latest.pkg" -target /
- name: Install gfortran for macOS
if: runner.os == 'macOS'
run: |
wget -q https://mac.r-project.org/tools/gfortran-14.2-universal.pkg -O /tmp/gfortran.pkg
sudo installer -pkg "/tmp/gfortran.pkg" -target /
- name: Install OpenMP for macOS
if: runner.os == 'macOS'
run: |
curl -fsSL https://raw.githubusercontent.com/coatless-shell/openmp/main/install-openmp.sh | bash -s -- --yes
- name: Configure R Makevars for OpenMP
if: runner.os == 'macOS'
run: |
mkdir -p ~/.R
cat <<EOF > ~/.R/Makevars
CPPFLAGS += -Xclang -fopenmp
LDFLAGS += -lomp
EOFThis is shaky on the gfortran part if the R version changes drastically. (R 4.3. would fail as it uses an earlier version, et cetera). |
|
Adding this to my CI file now. One thing I realized is that I do have macOS in the matrix, so I given how GH flipped to arm64 for it I also test it ... meaning maybe @jeroen is the outlier? From last week's check log in [this macOS log file](https://github.com/RcppCore/RcppArmadillo/actions/runs/19465791346/job/55700383925) (under 'Configure') with the So if @jeroen is right, adding OpenMP to the mix should break things under the current setup implying it may need work. |
|
Yes building with OpenMP on MacOS requires some extra setup on the server, see https://mac.r-project.org/openmp/ Although from the log file of the failing build, I don't think your configure is picking up on it? https://github.com/r-universe/rcppcore/actions/runs/19474394547/job/55752797364 |
|
We seem to be converging because @coatless (see above) suggested to pull in a script he offers (which seems to follow that page) and also to set the ~/.R/Makevars accordingly. So I now do this (after bungling the matrix condition twice even though I used it correctly below in the same file to turn on coverage, sigh...) - name: OpenMP for macOS
if: ${{ matrix.os == 'macos-latest' }}
run: |
curl -fsSL https://raw.githubusercontent.com/coatless-shell/openmp/main/install-openmp.sh | bash -s -- --yes
mkdir -p ~/.R
cat <<EOF > ~/.R/Makevars
CPPFLAGS += -Xclang -fopenmp
LDFLAGS += -lomp
EOF
cat ~/.R/Makevarsand this now gets us green: 
(Coverage under Linux takes longer, and compiler is slower, sadly) So if I turn r-universe support on for this branch, it will break again as you do not have this server support so we need to make our configure test more potent to detect that? Is that your reading? |
|
No beans, @coatless: 
Frustrating. It has been a few weeks dancing with macOS on this with zero to show. PS Mind you that is still us / me in the package as we have the important so question now is why we see |
|
Yes there was a case missng for the newly add ~/.R/Makevars I am now five more attempts in and have nothing to show. @coatless I am coming close to throwing all this out. You made me add variables CPPFLAGS and LIBS in ~/.R/Makevars but that is not what your test snippets test for so it all falls apart and ... remains so brittle. Not great. |
|
I may have fixed it. The key was to grep from We want |
|
So I have it sorted in the 'worked at GH with OpenMP on linux and macos' sense (an improvement) yet it still conks under r-universe. @jeroen can we inject log printing from our end just how I could add to the GHA yaml to show me configure results and other variables? |
|
r-universe just logs the verbatim output from |
|
Very good. I always get lost between |
|
But it is still no solution. We now at your end get because, I presume, the required OpenMP add-in is not installed. In that case it should just do what it always did, and what always worked. But now it falls over in linear algebra test that used to pass for years at your end too. So I am lost. |
|
I'm quite sure it is installed because The linear algebra error may be something else then? Nothing has changed on our end, only that R-4.5.1 was updated to R-4.5.2. |
|
Do not focus on that one line, there is more context: @coatless is expert here, I am just trying to accommodate. Following his script we have 
and that is used in the above (when OpenMP is around). |
|
Also, what is a bit weird is that the CI of course passed all this time at GitHub so in some subtle way your r-universe setup may be different from what I do on 'macos-latest' (following the default steps from my r-ci script which bring in what Simon provides as the R and Fortran download). And now augmented by what James has provided for OpenMP. |
|
I like your data.table example though. It clearly compiles with -fopenmp and uses the -lomp linker choice: Maybe we should try that. Part of this may be on me; I had hoped/expected we could just rely on R's own Edit: Turns out data.table does rely on Edit 2 And uses |
|
After some digging, I found that the MacOS build for R-base has changed to another BLAS implementation in 4.5.2. # R 4.5.0
> extSoftVersion()['BLAS']
BLAS
"/Library/Frameworks/R.framework/Versions/4.5-arm64/Resources/lib/libRblas.0.dylib"# R 4.5.2
> extSoftVersion()['BLAS']
BLAS
"/System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libBLAS.dylib"Maybe this change is related to the test suddenly failing. Can you update https://eddelbuettel.github.io/r-ci/run.sh to use R-4.5.2 such that we can rule out this difference between your CI and r-universe? |
|
Nice work. That is a manual toggle I can flip later today. I had in the meantime tossed my configure out and switch to the data.table one. That has not yet bubbled up at r-universe in the branch I opted into but should 'shortly'. We'll see what that says. |
|
I think it did already? https://github.com/r-universe/eddelbuettel/actions/runs/19515826635/job/55867499052 |
|
When I just looked it still said '5 hours ago' for the update. Maybe the cache tricked me. Looks like it did and this failed too. Boo. One more test of not manually download the OpenMP bits to do (to be closer to data.table). |
|
It did pick up on openmp, and that seems to work on all other macos flavors. I think the BLAS crash is another issue . |
|
Oh, no, wait, that is what I get at r-universe already so I don't need to simulate it at my CI. You are correct. So ... still a mess. But at least I have a smoking gun from you with the 4.5.0 / 4.5.2 issue. |
|
Slightly longer story (from this blog post) is that RcppArmadillo was actually running the containerised r-ci and that one was already at RVER=4.5.1. Anyway, I switched that to 4.5.2 as we can now, and tickled a new build. And you were once again spot on. It also breaks, and in the same spot as r-universe. "Interesting." At least one less mystery there. |
|
And as it always goes there is no justice or fairness in this world. The required diff was to skip the one test file because R simply does not like complex variables. modified inst/tinytest/test_Rlapack.R
@@ -20,6 +20,8 @@
library(RcppArmadillo)
+if (Sys.info()['sysname'] == "Darwin") exit_file("Skip on macOS")
+
if (isFALSE(tryCatch({svd(matrix(complex(1, 1, 1),1,1)); TRUE}, error=function(e) FALSE)))
exit_file("Skipping for lack of Fortran complex functions in this R build")Can you eyeball why the test we already had there would no longer work? Looking at it it seems like an older/poorer way to get on the bad side of |
|
And with that the r-universe issue is solved too (in the branch, mainline below still busted). 
So it never was OpenMP. Sigh. |
|
For the folks following at home:
I suppose one question that arises given Armadillo interacts with the BLAS is: Does the augmented BLAS (vecLib + additional routines) override how Armadillo is expecting to handle complex number matrix ops being performed similar to the hidden argument mess back in the day? AppendixRelevant R 4.5.0 release note section: 
CI Build Branch: master...feature/macos_openmp |
|
I also have the feeling we need to reach out to Simon / demonstrate that something is possibly borked here. We may need to create an R + C only little demo. |
As discussed with @coatless in #493 -- marking it draft for now.
Edit: Draft status now removed.