hi guys, I'd like to ask, and I believe this place here should be best as who can know better, if building R with different compilers and opt flags is something worth investing time into? Or maybe this a subject that somebody has already investigated. If yes what then are the conclusion? Reason I ask is such that, on Centos 7.6 with different compilers from stock repo but also from so called software collections, do not render(with flags for performance) an R binaries which would perform any better, according to R-benchmark-25 at least, then "vanilla" packages shipped from distro. And that makes me curious - is it because R is such a case which is prone to any compiler performance optimizations? Maybe there is more structured and organized way to conduct such different-compilers-optimizations benchmarks/test? What do devel can say and advise with regards to compile-for-performance subject? many thanks, L.?
On 13 June 2019 at 16:05, lejeczek via R-devel wrote: | I'd like to ask, and I believe this place here should be best as who can | know better, if building R with different compilers and opt flags is | something worth investing time into? | | Or maybe this a subject that somebody has already investigated. If yes | what then are the conclusion? | | Reason I ask is such that, on Centos 7.6 with different compilers from | stock repo but also from so called software collections, do not | render(with flags for performance) an R binaries which would perform any | better, according to R-benchmark-25 at least, then "vanilla" packages | shipped from distro. | | And that makes me curious - is it because R is such a case which is | prone to any compiler performance optimizations? | | Maybe there is more structured and organized way to conduct such | different-compilers-optimizations benchmarks/test? | | What do devel can say and advise with regards to compile-for-performance | subject? Of course you do that, and add those switches to ~/.R/Makeconf. The resulting binaries may become non-portable. E.g. "at work" we use -march=native quite a bit but it means can't share libraries from a beefier dev box with skinnier deployment boxen as they don't have the same chipset even thought the are both x86_64 and use the same Linux distro. As for which switches help in which way on different compiler: that is probably best seen as a black box. Time and profile locally, I no longer try to generalize. The newer 'link-time-optimizations' can help too, they certainly make builds longer ... Dirk -- http://dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org
On 13/06/2019 16:14, Dirk Eddelbuettel wrote:> On 13 June 2019 at 16:05, lejeczek via R-devel wrote: > | I'd like to ask, and I believe this place here should be best as who can > | know better, if building R with different compilers and opt flags is > | something worth investing time into? > | > | Or maybe this a subject that somebody has already investigated. If yes > | what then are the conclusion? > | > | Reason I ask is such that, on Centos 7.6 with different compilers from > | stock repo but also from so called software collections, do not > | render(with flags for performance) an R binaries which would perform any > | better, according to R-benchmark-25 at least, then "vanilla" packages > | shipped from distro. > | > | And that makes me curious - is it because R is such a case which is > | prone to any compiler performance optimizations? > | > | Maybe there is more structured and organized way to conduct such > | different-compilers-optimizations benchmarks/test? > | > | What do devel can say and advise with regards to compile-for-performance > | subject? > > Of course you do that, and add those switches to ~/.R/Makeconf. The > resulting binaries may become non-portable. > > E.g. "at work" we use -march=native quite a bit but it means can't share > libraries from a beefier dev box with skinnier deployment boxen as they don't > have the same chipset even thought the are both x86_64 and use the same Linux > distro. > > As for which switches help in which way on different compiler: that is > probably best seen as a black box. Time and profile locally, I no longer try > to generalize. The newer 'link-time-optimizations' can help too, they > certainly make builds longer ... > > Dirk >I've tried the "usual" tweaks and what puzzles me is the fact, that -march=native and -lto(s) + Os/3 do not help much, make almost invisible improvements (again, judging by results from R-benchmark-25) with gcc >7 as compared to distro's package which is built with -O2 -mtune=generic and no ltos. Would there be other(better) way to test core R? What king of R perf increases do you guys see with compiler's opt flags, if any? regards, L.