On Nov 21, 2014, at 3:47 AM, Rainer M Krug <[email protected]> wrote: > > Simon Urbanek <[email protected]> writes: > >> On Nov 20, 2014, at 11:17 AM, Braun, Michael <[email protected]> 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. 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. 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 >>> [email protected] >>> >>> _______________________________________________ >>> R-SIG-Mac mailing list >>> [email protected] >>> 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 _______________________________________________ R-SIG-Mac mailing list [email protected] https://stat.ethz.ch/mailman/listinfo/r-sig-mac
