[R-sig-Debian] Compiling R-2.11.1 patched on Ubuntu 10.04 with Optimized GotoBLAS2 libraries

Paul Johnson pauljohn32 at gmail.com
Sun Jun 27 21:47:28 CEST 2010


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.  --Dale


This 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



More information about the R-SIG-Debian mailing list