Dale Steele
2010-Jun-07 23:02 UTC
[R-sig-Debian] Compiling R-2.11.1 patched on Ubuntu 10.04 with Optimized GotoBLAS2 libraries
I've attempted to use the optimized GotoBLAS2 library with a freshly compiled R-2.11.1 patched on 64-bit Ubuntu 10.4. (See details below). When I run this version of R, the timings are not different than the original install, and only one core is used in test computations. Can someone point out my error? Thanks. --Dale Details ... I'm running the 64-bit version of Ubuntu 10.04 on my 2 core laptop. I first installed needed tools as follows: sudo apt-get build-dep r-base sudo apt-get install gobjc sun-java6-jdk sun-java6-jre Subsequently, I successfully installed R 2.11.1 patched from subversion using defaults: ./configure Next, I built the optimized Optimized GotoBLAS2 libraries version 1.13 and placed the file 'libgoto2_penrynp-r1.13.so' in /usr/lib Finally, I renamed the original 'libRblas.so' file that was installed in /usr/local/lib64 and created a soft link to the libgoto2 file. cd /usr/local/lib64/R/lib sudo ln -s /usr/lib/libgoto2_penrynp-r1.13.so libRblas.so
Paul Johnson
2010-Jun-27 19:47 UTC
[R-sig-Debian] Compiling R-2.11.1 patched on Ubuntu 10.04 with Optimized GotoBLAS2 libraries
On Mon, Jun 7, 2010 at 6:02 PM, Dale Steele <dale.w.steele at gmail.com> wrote:> I've attempted to use the optimized GotoBLAS2 library with a freshly > compiled R-2.11.1 patched on 64-bit Ubuntu 10.4. ?(See details below). > ?When I run this version of R, the timings are not different than the > original install, and only one core is used in test computations. > > Can someone point out my error? Thanks. ?--DaleThis is a tricky one. I've been digging into it for months. I think I understand it now. I'm typing this in a hurry because my battery is running down, so I'm not putting in exact version numbers, but I believe the main idea is correct. Perhaps Dirk will clarify. There seems to be some difference of opinion about how selection of BLAS should best be done. If you are reading the Radmin manual, it does say you should move the existing libRblas.so and then link up the new BLAS so file. But i bet you did not have a libRblas.so file that could be moved out of the way, as described in the Radmin manual. In this list, I have asked your question, several times, in various forms. I thought libRblas.so was "missing" accidentally. But Dirk Eddelbuetttel, who does the packaging, explained it was not a mistake, but rather a packaging strategy. Most users just want a BLAS that works, don't want to fiddle around. As a result, the debian packages you installed (if you used the default repositories, anyway) do not include libRblas.so, so linking to that has no effect. As you observed. Dirk sets up the deb packages to use a different BLAS. Actually, if you run the R that comes from Ubuntu proper, there is a copy of the Intel kernel math library shared BLAS, which is supposed to be awesome. (look for a package called "revolution-mkl"). You can grab that MKL library from the Ubuntu install and still use it, even if you recompile R. I've reread the license and I believe you are even allowed to recompile it for other Linux, although you must not try to deconstruct it. It may be as good or better than ATLAS or GOTOBLAS2. I don't know. On the other hand, if you use R packages built elsewhere, such as on CRAN, they default to use the ATLAS BLAS, as far as I can tell. So there's the rub. To replace ATLAS BLAS or MKL, what do you do? On my systems, I've experimented with various strategies to deal with this. On some systems, I've downloaded the R src code that Dirk uses to build the Debian packages (apt-get source r). I've re-configured and rebuilt R so I do get libRblas.so and then I can follow the Admin manual and use the symbolic link to replace it. Make the changes in the rules file from the debian packaging. You see below my configure statement. I comment out the $atlas and $lapack statements and I enable the BLAS-shlib. If you build that way, you do get libRblas.so and you can follow along with the Radmin manual to link against a different BLAS.so file. ./configure --prefix=/usr \ --with-cairo \ --with-jpeglib \ --with-pango \ --with-png \ --with-readline \ --with-tcltk \ --with-system-bzlib \ --with-system-pcre \ --with-system-zlib \ --mandir=/usr/share/man \ --infodir=/usr/share/info \ --datadir=/usr/share/R/share \ --includedir=/usr/share/R/include \ # $(atlas) \ # $(lapack) \ --enable-BLAS-shlib \ --without-gnome \ --enable-R-profiling \ --enable-R-shlib \ --enable-memory-profiling \ --without-recommended-packages \ --build $(buildarch) In the R admin manual, they say there is some speed benefit to be gained by not building R as a shared library, and so on high performance systems I have turned off the shlib option. (--disable-R-shlib) On the other hand, this is not necessary. What you need to do is run ldd on the R executable and see what libraries it is actually pointing at. One of them will be atlas BLAS, probably. So if you go in your libraries and move the atlas blas, and put that GOTOBLAS2 in its place, then R will use that BLAS. Here's what I see now on this particular computer. Look below for the libblas.so.3gf line. That means I'm right now linked up to the ATLAS version. But I could change that to point at GOTOBLAS2. $ ldd /usr/lib/R/bin/exec/R linux-vdso.so.1 => (0x00007fff56bff000) libR.so => /usr/lib/libR.so (0x00007fd70e049000) libc.so.6 => /lib/libc.so.6 (0x00007fd70dcc7000) libblas.so.3gf => /usr/lib/atlas/libblas.so.3gf (0x00007fd70d32b000) libgfortran.so.3 => /usr/lib/libgfortran.so.3 (0x00007fd70d03e000) libm.so.6 => /lib/libm.so.6 (0x00007fd70cdbb000) libreadline.so.6 => /lib/libreadline.so.6 (0x00007fd70cb79000) libpcre.so.3 => /lib/libpcre.so.3 (0x00007fd70c94b000) libbz2.so.1.0 => /lib/libbz2.so.1.0 (0x00007fd70c73a000) libz.so.1 => /lib/libz.so.1 (0x00007fd70c522000) libdl.so.2 => /lib/libdl.so.2 (0x00007fd70c31e000) /lib64/ld-linux-x86-64.so.2 (0x00007fd70e5ea000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00007fd70c107000) libncurses.so.5 => /lib/libncurses.so.5 (0x00007fd70bec3000) I made some comparisons and GOTOBLAS2 works fine, and it is faster in some cases, possibly because it does use multiple cores on matrix multiplication problems, whereas we don't see the Atlas use more than one (some discussion of that in this list too). Because of that, I have installed GOTOBLAS2 on our 8 or 16 core systems. The bad part of this strategy is that you have to do this at the /usr/lib level and affect all users & programs by changing the BLAS. On the other hand, if you install libRblas.so, then you can move that out of the way and use the other BLAS only with R, and leave other programs & users alone. I hope this is a complete explanation, possibly a FAQ answer! PJ> > Details ... > I'm running the 64-bit version of Ubuntu 10.04 on my 2 core ?laptop. I > first installed > needed tools as follows: > > sudo apt-get build-dep r-base > sudo apt-get install gobjc sun-java6-jdk sun-java6-jre> Subsequently, I successfully installed R 2.11.1 patched from subversion using > defaults: > ./configure > > Next, I built the optimized Optimized GotoBLAS2 libraries version 1.13 > and placed the file 'libgoto2_penrynp-r1.13.so' in /usr/lib > > Finally, I renamed the original 'libRblas.so' file that was installed > in /usr/local/lib64 > and created a soft link to the libgoto2 file. > > cd /usr/local/lib64/R/lib > sudo ln -s /usr/lib/libgoto2_penrynp-r1.13.so libRblas.so > > _______________________________________________ > R-SIG-Debian mailing list > R-SIG-Debian at r-project.org > https://stat.ethz.ch/mailman/listinfo/r-sig-debian >-- Paul E. Johnson Professor, Political Science 1541 Lilac Lane, Room 504 University of Kansas