From pe|j@@z @end|ng |rom y@hoo@co@uk  Fri Jun 14 13:43:49 2019
From: pe|j@@z @end|ng |rom y@hoo@co@uk (lejeczek)
Date: Fri, 14 Jun 2019 12:43:49 +0100
Subject: [Rd] compiler flags for performance
In-Reply-To: <23810.26695.725131.693656@rob.eddelbuettel.com>
References: <3cd16957-b4f0-6d32-25ed-c3b1ffa4f241@yahoo.co.uk>
 <23810.26695.725131.693656@rob.eddelbuettel.com>
Message-ID: <b312e475-575f-5173-d7c8-2b404690b1ce@yahoo.co.uk>

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.






[Rd] compiler flags for performance
lejeczek