Re: [R-SIG-Mac] Link-Time Optimization (LTO)
On 15/07/2020 09:50, Jeroen Ooms wrote: On Tue, Jul 14, 2020 at 4:22 PM Prof Brian Ripley wrote: This is a rather technical post about how libraries of compiled code can be further optimized. LTO generally produces smaller[*] and faster code (typically by a few percent) at the expense of increased installation time and is being used for large projects such as browsers and soon for some Linux distributions. I have committed a series of enhancements to LTO support in R-devel and will shortly port the more important of these to R-patched. Would it be worthwhile looking into this for Windows? We did enable support for LTO in the rtools40 toolchains*, but those are gcc-8.3.0 and some of the benefits require gcc-9. * https://github.com/r-windows/rtools-packages/blob/master/mingw-w64-gcc/PKGBUILD#L166 Way off topic for R-sig-mac, but it is under discussion for Windows once all the planned LTO changes are in. A minor point which is relevant here: the recommended gfortran distribution for macOS (which is from GCC 8.2) contains gcc and g++. So Mac users could try that to get C/Fortran consistency checks. However, only much later versions are compatible with Catalina's SDK (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90835), and from trying on High Sierra it looks like Apple's linker does not understand GCC's LTO format. -- 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] Link-Time Optimization (LTO)
On Tue, Jul 14, 2020 at 4:22 PM Prof Brian Ripley wrote: > > This is a rather technical post about how libraries of compiled code can > be further optimized. LTO generally produces smaller[*] and faster code > (typically by a few percent) at the expense of increased installation > time and is being used for large projects such as browsers and soon for > some Linux distributions. > > I have committed a series of enhancements to LTO support in R-devel and > will shortly port the more important of these to R-patched. Would it be worthwhile looking into this for Windows? We did enable support for LTO in the rtools40 toolchains*, but those are gcc-8.3.0 and some of the benefits require gcc-9. * https://github.com/r-windows/rtools-packages/blob/master/mingw-w64-gcc/PKGBUILD#L166 ___ R-SIG-Mac mailing list R-SIG-Mac@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
[R-SIG-Mac] Link-Time Optimization (LTO)
This is a rather technical post about how libraries of compiled code can be further optimized. LTO generally produces smaller[*] and faster code (typically by a few percent) at the expense of increased installation time and is being used for large projects such as browsers and soon for some Linux distributions. I have committed a series of enhancements to LTO support in R-devel and will shortly port the more important of these to R-patched. This includes pretty comprehensive LTO support for clang, mainly to make LTO usable on macOS. (LLVM/clang has diverged considerably from GCC in how LTO is implemented - in particular with 'Thin LTO'.) Full details (including example settings for macOS) are in the R-admin manual. I would not use LTO on macOS routinely (I do on Linux), but for some applications the performance gains[+] maybe valuable enough. By the time R 4.1.0 is released it may be worth using it for the distributed R and binary packages LTO can be used to find inconsistencies between C/C++ compilation units as reported in the CRAN LTO 'Additional issues'. Unfortunately it cannot help with the more common C/Fortran inconsistencies as the intermediate representation used by gfortran is different and ignored by the macOS linker. An LLVM-based Fortran compiler (variously called flang and f18) has been promised for years but is being re-implemented and is far from usable. [*] although probably due to inlining, sometimes larger as it is for libR.dylib. [+] some R test scripts show negligible change in performance, several a gain of 5% and a couple a gain of 10-15%. Installation times depend rather a lot on how much one can make use of multithreading: on my dual-core MBP total R build elapsed time increased from 7:13 to 8:04 (m:s). -- 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
