Kevin, Simon discussed why they opted to avoid this back in June '19 when Jon Clayden brought up a similar success.
https://stat.ethz.ch/pipermail/r-sig-mac/2019-June/012998.html The sentiment was using the system compiler is in manner is unsupported and works only on some systems. I'm not sure with the OS bump whether there still is disparity across 10.13/14/15. That said, I do agree with Tim that it would be nice to have OpenMP enabled-by default. But, I'm also equally okay with it being disabled to simplify workflow and encourage more parallelization through snow/future as getting into parallelized compiled code with R has far more dragons afoot. Best, JJB On 4/2/20, 12:05 PM, "R-SIG-Mac on behalf of Kevin Ushey" <r-sig-mac-boun...@r-project.org on behalf of kevinus...@gmail.com> wrote: Hi, For what it's worth, it looks like it is still possible to use OpenMP on macOS with the system toolchain. Using the example file here: https://computing.llnl.gov/tutorials/openMP/samples/C/omp_hello.c I can compile + link + run this on macOS 10.15.4 and with: $ /usr/bin/clang -Xpreprocessor -fopenmp -I/usr/local/opt/libomp/include -L/usr/local/opt/libomp/lib -lomp omp_hello.c As for whether this is 'safe', or whether R could conceivably bundle and use its own copy of libomp is a separate question I cannot answer. But at least this is a mechanism for enterprising users to enable OpenMP in packages built from source if they so desire. Best, Kevin On Thu, Apr 2, 2020 at 6:01 AM BATES Timothy <tim.ba...@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). > > 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. > > 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. > > 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 <rip...@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@r-project.org > https://stat.ethz.ch/mailman/listinfo/r-sig-mac _______________________________________________ R-SIG-Mac mailing list R-SIG-Mac@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac _______________________________________________ R-SIG-Mac mailing list R-SIG-Mac@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
