On Nov 22, 2014, at 1:27 PM, Braun, Michael <[email protected]> wrote:
> 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. > Thanks, I'll look into it, it should be there at least for the SL build. > 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? > Unfortunately not, because GOMP has both performance and stability issues on OS X, so the CRAN binaries are explicitly build with disabled OpenMP support to work around that. However, as I said, we hope to have iomp binaries soon (perhaps even as soon as next week). > 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. > I would have to dig out the benchmarks, but if I recall correctly there was a set of BLAS kernels that doubled the runtime with AVX enabled. There were other instances, too, but I can't recall the details. In a spare minute I can try to replicate the experiment. Cheers, Simon > > 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 _______________________________________________ R-SIG-Mac mailing list [email protected] https://stat.ethz.ch/mailman/listinfo/r-sig-mac
