Re: [R-SIG-Mac] Apple Clang does support OpenMP (if libomp is available)
On 06/06/2019 16:39, Simon Urbanek wrote: Jon, some time ago Apple's clang has silently dropped -fopenmp so we were able to at least keep it in the flags even if it wasn't actually using it. Still, it was only dropping it, it wasn't actually generating any parallel code, so there was real point in using it. That's when we decided to use non-Apple clang since it has proper support for parallel code generation. What you're pointing out is that more recent clang builds from Apple now do include the OMP generation pieces (in particular the pre-processor), they just don't ship any OpenMP-related headers or libraries. The problem is that it's hard to rely on something that is unsupported and works only on some systems. We could ship libomp (we already do - no need to get it from homebrew), but, for example, the omp.h headers from clang7 don't work with Apple's clang (you do need explicit -I.. and -lomp in addition to -Wp,-fopenmp because it's not only the pre-processor that needs to know about it). Also note that "-Wp,-fopenmp" is a hack - just because Apple has not patched the pre-processor and only the front-end/linker to refuse it, it doesn't mean that it actually works properly. There is no guarantee that they made changes to the code-generation which break something in OpenMP since it's not not even included in any of their tests. Hence I'd say it's a quick hack if you don't want to to install clang7 that may or may not work depending on your code, but not something I'd trust in a release. There is another issue: libomp is not explicitly versioned, but there are differences between LLVM-project releases (and there are other sources, and even projects which symlink other implementations to libomp). So putting -lomp in LIBS is unsafe, and part of the job of a -fopenmp flag when a compiler is used to link is to arrange to link to the correct libomp (also at runtime). clang has not always done a good job in finding the right libomp, and it has a couple of times recently adding OpenMP features which need support in libomp. So whereas this may 'work OK' for one user's limited testing, it may not work for all R packages (and in my experience it has been just a handful which failed). Cheers, Simon On Jun 6, 2019, at 6:42 AM, Jon Clayden wrote: Dear all, Lack of OpenMP support in Apple’s build of Clang is cited as one reason for not using it in CRAN builds, but this is only partly true: after installing libomp from Homebrew, I have been adding “-Wp,-fopenmp” to CXXFLAGS and CFLAGS (and “-lomp” to LIBS) to my builds for a while, and everything seems to work OK. I’m not sure how far back this support goes (and I haven’t tried the Xcode 11 tools yet), but is there any known reason not to take this approach, and if not, would it make sense for R’s configure script to try “-Wp,-fopenmp” when testing for OpenMP support? All the best, Jon -- Brian D. Ripley, rip...@stats.ox.ac.uk Emeritus Professor of Applied Statistics, University of Oxford ___ R-SIG-Mac mailing list R-SIG-Mac@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] Apple Clang does support OpenMP (if libomp is available)
Jon, some time ago Apple's clang has silently dropped -fopenmp so we were able to at least keep it in the flags even if it wasn't actually using it. Still, it was only dropping it, it wasn't actually generating any parallel code, so there was real point in using it. That's when we decided to use non-Apple clang since it has proper support for parallel code generation. What you're pointing out is that more recent clang builds from Apple now do include the OMP generation pieces (in particular the pre-processor), they just don't ship any OpenMP-related headers or libraries. The problem is that it's hard to rely on something that is unsupported and works only on some systems. We could ship libomp (we already do - no need to get it from homebrew), but, for example, the omp.h headers from clang7 don't work with Apple's clang (you do need explicit -I.. and -lomp in addition to -Wp,-fopenmp because it's not only the pre-processor that needs to know about it). Also note that "-Wp,-fopenmp" is a hack - just because Apple has not patched the pre-processor and only the front-end/linker to refuse it, it doesn't mean that it actually works properly. There is no guarantee that they made changes to the code-generation which break something in OpenMP since it's not not even included in any of their tests. Hence I'd say it's a quick hack if you don't want to to install clang7 that may or may not work depending on your code, but not something I'd trust in a release. Cheers, Simon > On Jun 6, 2019, at 6:42 AM, Jon Clayden wrote: > > Dear all, > > Lack of OpenMP support in Apple’s build of Clang is cited as one > reason for not using it in CRAN builds, but this is only partly true: > after installing libomp from Homebrew, I have been adding > “-Wp,-fopenmp” to CXXFLAGS and CFLAGS (and “-lomp” to LIBS) to my > builds for a while, and everything seems to work OK. > > I’m not sure how far back this support goes (and I haven’t tried the > Xcode 11 tools yet), but is there any known reason not to take this > approach, and if not, would it make sense for R’s configure script to > try “-Wp,-fopenmp” when testing for OpenMP support? > > All the best, > Jon > > ___ > 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
Re: [R-SIG-Mac] Apple Clang does support OpenMP (if libomp is available)
Hi James, > > Lack of OpenMP support in Apple’s build of Clang is cited as one reason for > > not using it in CRAN builds > > From R 3.4.x forward, OpenMP has been enabled in CRAN builds as the toolchain > is using a custom compiler. I’m aware of that, but this makes building packages from source more complicated for users in my opinion, since they also have to install the custom compiler toolchains. But whatever one’s views on that, I’m suggesting that one reason given for not using Apple Clang may not be entirely correct. > > but this is only partly true: after installing libomp ***from Homebrew***, > > I have been adding > > Unfortunately, both Xcode and Xcode CLI do not ship clang with support for > OpenMP. By installing `libomp` from homebrew, the system is getting a > clang-compliant OpenMP compiler from the llvm formula. To check, please see: Not at all. The libomp formula is standalone, with no dependency on the llvm formula. See https://github.com/Homebrew/homebrew-core/blob/master/Formula/libomp.rb. I can assure you that I don’t have the llvm formula installed. > which clang /usr/bin/clang All the best, Jon ___ R-SIG-Mac mailing list R-SIG-Mac@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
Re: [R-SIG-Mac] Apple Clang does support OpenMP (if libomp is available)
Greetings and Salutations Jon, > Lack of OpenMP support in Apple’s build of Clang is cited as one reason for > not using it in CRAN builds From R 3.4.x forward, OpenMP has been enabled in CRAN builds as the toolchain is using a custom compiler. You can see this with regard to the work done to enable OpenMP with RcppArmadillo with a configure script to detect the compiler: https://github.com/RcppCore/RcppArmadillo/pull/170 https://github.com/RcppCore/RcppArmadillo/pull/219 > but this is only partly true: after installing libomp ***from Homebrew***, I > have been adding Unfortunately, both Xcode and Xcode CLI do not ship clang with support for OpenMP. By installing `libomp` from homebrew, the system is getting a clang-compliant OpenMP compiler from the llvm formula. To check, please see: which clang I wish it were the case though... Sincerely, JJB On 6/6/19, 5:43 AM, "R-SIG-Mac on behalf of Jon Clayden" wrote: Dear all, Lack of OpenMP support in Apple’s build of Clang is cited as one reason for not using it in CRAN builds, but this is only partly true: after installing libomp from Homebrew, I have been adding “-Wp,-fopenmp” to CXXFLAGS and CFLAGS (and “-lomp” to LIBS) to my builds for a while, and everything seems to work OK. I’m not sure how far back this support goes (and I haven’t tried the Xcode 11 tools yet), but is there any known reason not to take this approach, and if not, would it make sense for R’s configure script to try “-Wp,-fopenmp” when testing for OpenMP support? All the best, Jon ___ 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] Apple Clang does support OpenMP (if libomp is available)
Dear all, Lack of OpenMP support in Apple’s build of Clang is cited as one reason for not using it in CRAN builds, but this is only partly true: after installing libomp from Homebrew, I have been adding “-Wp,-fopenmp” to CXXFLAGS and CFLAGS (and “-lomp” to LIBS) to my builds for a while, and everything seems to work OK. I’m not sure how far back this support goes (and I haven’t tried the Xcode 11 tools yet), but is there any known reason not to take this approach, and if not, would it make sense for R’s configure script to try “-Wp,-fopenmp” when testing for OpenMP support? All the best, Jon ___ R-SIG-Mac mailing list R-SIG-Mac@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
