[R-SIG-Mac] Compiler options for R binary

[Rainer M Krug]

Simon Urbanek <simon.urbanek at r-project.org> writes:

> On Nov 20, 2014, at 11:17 AM, Braun, Michael <braunm at mail.smu.edu> wrote:
>
>> I run R on a recent Mac Pro (Ivy Bridge architecture), and before
>> that, on a 2010-version (Nehalem architecture).  For the last few
>> years I have been installing R by compiling from source.  The reason
>> is that I noticed in the etc/Makeconf file that the precompiled
>> binary is compiled with the -mtune=core2 option.  I had thought that
>> since my system uses a processor with a more recent architecture and
>> instruction set, that I would be leaving performance on the table by
>> using the binary.
>> 
>> My self-compiled R has worked well for me, for the most part. But
>> sometimes little things pop-up, like difficulty using R Studio, an
>> occasional permissions problem related to the Intel BLAS, etc.  And
>> there is a time investment in installing R this way.  So even though
>> I want to exploit as much of the computing power on my desktop that
>> I can, now I am questioning whether self-compiling R is worth the
>> effort.
>> 
>> My questions are these:
>> 
>> 1.  Am I correct that the R binary for Mac is tuned to Core2 architecture?  
>> 2.  In theory, should tuning the compiler for Sandy Bridge (SSE4.2, AVX instructions, etc) generate a faster R?
>
> In theory, yes, but often the inverse is true (in particular for AVX).
>
>
>> 3.  Has anyone tested the theory in Item 2?
>> 4.  Is the reason for setting -mtune=core2 to support older
>> machines?  If so, are enough people still using pre-Nehalem 64-bit
>> Macs to justify this?
>
> Only partially. In fact, the flags are there explicitly to increase
> the tuning level - the default is even lower. Last time I checked
> there were no significant benefits in compiling with more aggressive
> flags anyway. (If you want to go there, Jan De Leeuw used to publish
> most aggressive flags possible). You cannot relax the math ops
> compatibility which is the only piece that typically yields gain,
> because you start getting wrong math op results. You have to be very
> careful with benchmarking, because from experience optimizations often
> yield speed ups in some areas, but also introduce slowdown in other
> areas - it's not always a gain (one example on the extreme end is AVX:
> when enabled some ops can even take twice as long, believe it or
> not...) and even the gains are typically in single digi
>  t percent range.
>
>
>> 5.  What would trigger a decision to start tuning the R binary for a more advanced processor?
>> 6.  What are some other implications of either self-compiling or
>> using the precompiled binary that I might need to consider?
>> 
>
> When you compile from sources, you're entirely on your own and you
> have to take care of all dependencies (libraries) and compilation
> yourself. Most Mac users don't want to go there since they typically
> prefer to spend their time elsewhere ;).

I have to mention homebrew [1]here - by tuning the recipe used to install R,
one could (I guess) tune compiler options and recompile without any
fuss. The R installation with homebrew worked for me out-of-the-box and
the re-compilation and installation is one command.

The recipes are simple ruby scripts and can easily be changed.

OK - I come from a Linux background, but I like the homebrew approach
and it works flawless for me.

Cheers,

Rainer

>
> BTW: if you really care about speed, the real gains are with using
> parallel BLAS, Intel OpenMP runtime and enabling built-in threading
> support in R.
>
> Cheers,
> Simon
>
>
>> tl;dr:  My Mac Pro has a Ivy Bridge processor.  Is it worthwhile to compile R myself, instead of using the binary?
>> 
>> Thanks,
>> 
>> Michael
>> 
>> 
>> --------------------------
>> Michael Braun
>> Associate Professor of Marketing
>> Cox School of Business
>> Southern Methodist University
>> Dallas, TX 75275
>> braunm at smu.edu
>> 
>> _______________________________________________
>> R-SIG-Mac mailing list
>> R-SIG-Mac at r-project.org
>> https://stat.ethz.ch/mailman/listinfo/r-sig-mac
>> 


Footnotes: 
[1]  http://brew.sh

-- 
Rainer M. Krug
email: Rainer<at>krugs<dot>de
PGP: 0x0F52F982
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 494 bytes
Desc: not available
URL: <https://stat.ethz.ch/pipermail/r-sig-mac/attachments/20141121/429bced0/attachment-0001.bin>