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
