| 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
| 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
| 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
have the same chipset even thought the are both x86_64 and use the same
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
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.
[0] https://github.com/gabx/R-project/tree/master/R-mkl