Thanks Kevin, interesting approach.
However, when testing it against a few packages I get symbol pointer issues (e.g. for data.table and xgboost).
Using llvm everything works.
Could llvm be the best middle way? Easy installation via brew and still clang compliant.
Currently my Makevars look as follows
CFLAGS=-isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX10.13.sdk
[?]
CC = ccache /usr/local/opt/llvm/bin/clang
[?]
Where llvm was installed via `brew install llvm`.
SDK 10.13 because of {igraph} and {Rcpp} issues with SDK 10.14 and SDK 10.15
On 2. Apr 2020, 23:01 +0200, Simon Urbanek <simon.urbanek at r-project.org>, wrote:
Tim,
On 3/04/2020, at 2:01 AM, BATES Timothy <tim.bates at ed.ac.uk> wrote: Moving to a compiler that drops support for OpenMP seems a sad choice, especially now we?ve all climbed the learning curve of the non-Apple compiler (the real barrier was lack of a pkg installer and that?s done now).
It has caused a lot of issues, it trips people on a daily basis which is just not worth it. Also with Apple's increasingly strict rules about what can be distributed we don't want to be in the business in maintaining a separate toolchain. There have been numerous issues with C++ exceptions so the fall out was much bigger than originally expected and it would only get worse.
Losing OpenMP for the CRAN version of OpenMx/umx (our SEM packages) would be a big loss for users (for whom the CRAN version now supports OpenMP giving them a 2-12x speed up). In general, R on Mac is made more viable by having OpenMP Re Brian?s points, I?d say that the distribution problem is crucial: Packages not on CRAN have dramatically diminished accessibility/useage.
The idea is that if a package deems this critical, it can enable this for the users. As it is now, packages can still supply iomp and use it. That said, I would open for discussion the ability to distribute iomp with the R binary, but it would not be supported by R directly, i.e., it would be on the package author to make sure that the way the package operates is compatible with that binary. Let me know what you think.
Second, a great range of compute-intensive problems are amenable to division amongst cores, including nearly all models that take more than a nominal amount of time to run: So simulations, CIs, bootstrapping, nearly everything in genetics all speeds up.
Yes, but OpenMP is rarely used for those tasks. In R OpenMP can be only used for very small subset of such tasks - which is why alternative approaches are much more common. Cheers, Simon
I?d say especially on desktop/laptop. The big advantage of multi blade systems requires snowfall-type solutions, but desktops profit automatically from their multi-core structure and don;?t have multiple processors (except graphics, which no-one seems to be exploiting on CRAN-style R), so OpenMP is their one trick. I?d hope not to lose it. Best, t
On 2 Apr 2020, at 05:18, Prof Brian Ripley <ripley at stats.ox.ac.uk> wrote: On 01/04/2020 22:02, Simon Urbanek wrote:
JJB, 1. correct, there was too much trouble in this. But please feel free to start a new thread about this here if you have strong opinions.
Also note that it is possible (and not hard) to install packages from source with an OpenMP-supporting compiler, and how to do so is in the R-admin manual. The problems come in distributing them. The benefits of OpenMP are often overestimated, especially on desktop/laptop level hardware. But it is available for the small (tiny?) proportion of users who need it.
The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.
_______________________________________________ R-SIG-Mac mailing list R-SIG-Mac at r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
_______________________________________________ R-SIG-Mac mailing list R-SIG-Mac at r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac