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 <[email protected]<mailto:[email protected]>> wrote: Simon Urbanek <[email protected]<mailto:[email protected]>> writes: On Nov 21, 2014, at 3:47 AM, Rainer M Krug <[email protected]<mailto:[email protected]>> wrote: Simon Urbanek <[email protected]<mailto:[email protected]>> writes: On Nov 20, 2014, at 11:17 AM, Braun, Michael <[email protected]<mailto:[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. 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 [email protected]<mailto:[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 -- Rainer M. Krug email: Rainer<at>krugs<dot>de PGP: 0x0F52F982 -------------------------------------------- Michael Braun, Ph.D. Associate Professor of Marketing Cox School of Business Southern Methodist University [email protected]<mailto:[email protected]> [[alternative HTML version deleted]] _______________________________________________ R-SIG-Mac mailing list [email protected] https://stat.ethz.ch/mailman/listinfo/r-sig-mac
