Compiler options for R binary

Thank you for all of the helpful replies.  I think I?ll go back to using the CRAN binary, and still link to an external BLAS.

I do have some follow-up questions:

1.  Section 10.5 of the R for Mac FAQ suggests that there is a libRblas.veclib.dylib in the Resources/lib directory.  I do not see that after installing the binary for R 3.1.2.  I can still link to the Apple vecLib (/System/Library/Accelerate ?./libBLAS.dylib --  it?s a very long path), but there appears to be an inconsistency between the CRAN build and the FAQ.

2.  Simon mentioned Intel OpenMP runtime, and enabling R threading support.  Is this something that can be done at the user level (like pointing to a different BLAS), or is it something that needs to be built in to the binary?

3.  Just out of curiosity, what are the operations that slow down with AVX?  Someday, when I have some free time, I may want to check that out, mainly as a learning experience.

On Nov 22, 2014, at 9:57 AM, Rainer M Krug <Rainer at krugs.de<mailto:Rainer at krugs.de>> wrote:

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

On Nov 21, 2014, at 3:47 AM, Rainer M Krug <Rainer at krugs.de<mailto:Rainer at krugs.de>> wrote:

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

On Nov 20, 2014, at 11:17 AM, Braun, Michael <braunm at mail.smu.edu<mailto: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.


As others have said - if you don't mind the crashes, then it's ok.

Well - I am using R via ESS and nearly never the GUI, so I can't say
anything from that side, but I never had crashes of R after switching to
homebrew - but I might be lucky.

I actually like homebrew, it's good for small tools when you're in the
pinch, but it doesn't tend to work well for complex things like R (or
package that has many options). Also like I said, you'll have to take
care of packages and dependencies yourself - not impossible, but
certainly extra work.



However, if you don't mind to get your hands dirty, then I would
recommend Homebrew over the alternatives.

As I said - I am coming from the Linux side of things (but always used
the binaries there...) so I don't mind compiling and prefer the better
control / understanding homebrew gives me. And my hands never got as
dirty as trying to compile under Linux :-)

Cheers,

Rainer



Cheers,
Simon




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<mailto:braunm at smu.edu>