[R-sig-Debian] stock ubuntu raring binary R 3.0.1 and accelerated blas libraries?

[Dirk Eddelbuettel]

On 23 June 2013 at 16:14, ivo welch wrote:
| dear debian-R group:
| 
| I am using the stock ubuntu binary R 3.0.1 for ubuntu raring but on
| cinnamon mint olivia 15.
| 
| I read dirk's gcbd paper from a couple of years ago.  it suggests that
| stock blas is pretty bad compared to the four main alternatives.   of
| course, dirk also maintains the binaries for debian/ubuntu R, so he
| probably knows the answer off hand.
| 
| I installed libatlas3-base (3.8.4-9ubuntu1)  from the software
| repositories.  ldd tells me that this is not enough ( ldd
| /usr/lib/R/bin/exec/R | grep -i atlas).  

If 'mint' follows what we do on Debian and Ubuntu then you would not see it
there directly. On my Ubuntu 13.04 box:

edd at max:~$ ldd /usr/lib/R/bin/exec/R 
        linux-vdso.so.1 =>  (0x00007fffa4fff000)
        libR.so => /usr/lib/libR.so (0x00007f109c698000)
        libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f109c47b000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f109c0b2000)
        libblas.so.3 => /usr/lib/libblas.so.3 (0x00007f109a6e1000)
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f109a3dc000)
        libreadline.so.6 => /lib/x86_64-linux-gnu/libreadline.so.6 (0x00007f109a199000)
        libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 (0x00007f1099f5a000)
        liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x00007f1099d38000)
        libbz2.so.1.0 => /lib/x86_64-linux-gnu/libbz2.so.1.0 (0x00007f1099b27000)
        libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f1099910000)
        librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f1099708000)
        libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f1099503000)
        libgomp.so.1 => /usr/lib/x86_64-linux-gnu/libgomp.so.1 (0x00007f10992f4000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f109cbd0000)
        libtinfo.so.5 => /lib/x86_64-linux-gnu/libtinfo.so.5 (0x00007f10990cb000)
edd at max:~$ ls -l /usr/lib/libblas.so.3 /etc/alternatives/libblas.so.3
lrwxrwxrwx 1 root root 39 Dec  9  2012 /etc/alternatives/libblas.so.3 -> /usr/lib/openblas-base/libopenblas.so.0
lrwxrwxrwx 1 root root 30 Dec  9  2012 /usr/lib/libblas.so.3 -> /etc/alternatives/libblas.so.3
edd at max:~$ 

You have to follow the link.  The more relevant file to ldd is this one:
edd at max:~$ ldd /usr/lib/R/modules/lapack.so 
        linux-vdso.so.1 =>  (0x00007fff3adff000)
        libR.so => /usr/lib/libR.so (0x00007f087d98d000)
        liblapack.so.3 => /usr/lib/liblapack.so.3 (0x00007f087cc94000)
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f087c98e000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f087c5c6000)
        libblas.so.3 => /usr/lib/libblas.so.3 (0x00007f087abf5000)
        libreadline.so.6 => /lib/x86_64-linux-gnu/libreadline.so.6 (0x00007f087a9b2000)
        libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 (0x00007f087a773000)
        liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x00007f087a551000)
        libbz2.so.1.0 => /lib/x86_64-linux-gnu/libbz2.so.1.0 (0x00007f087a340000)
        libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f087a129000)
        librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f0879f21000)
        libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f0879d1c000)
        libgomp.so.1 => /usr/lib/x86_64-linux-gnu/libgomp.so.1 (0x00007f0879b0d000)
        libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f08798f0000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f087e0cf000)
        libgfortran.so.3 => /usr/lib/x86_64-linux-gnu/libgfortran.so.3 (0x00007f08795db000)
        libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f08793c5000)
        libtinfo.so.5 => /lib/x86_64-linux-gnu/libtinfo.so.5 (0x00007f087919d000)
        libquadmath.so.0 => /usr/lib/x86_64-linux-gnu/libquadmath.so.0 (0x00007f0878f67000)
edd at max:~$ ls -l /usr/lib/liblapack.so.3 /etc/alternatives/liblapack.so.3
lrwxrwxrwx 1 root root 30 Dec  9  2012 /etc/alternatives/liblapack.so.3 -> /usr/lib/lapack/liblapack.so.3
lrwxrwxrwx 1 root root 32 Dec  9  2012 /usr/lib/liblapack.so.3 -> /etc/alternatives/liblapack.so.3
edd at max:~$ 

As you can see, I (currently) use OpenBLAS which is multithreaded, rather
than Atlas.

| libatlas use is not determined at
| compile time.  

Absolutely not as my gbcd paper explains. Or tries to explain, seemingly not
successfully enough (hey, it is a draft).

| I also redownloaded the 'r-base' binary to check whether it
| is determined at download time.  this did not make R use atlas, either.
| 
| so, I wanted to confirm what I think it is: one needs to source compile R
| to take advantage of the atlas (or any other accelerated) blas library.
| correct?

Absolutely not as my gbcd paper explain.

It is a run-time decision following a standard binary interface allowing the
very 'plug and play' comparison that is the whole point behind the gcbd paper.
 
| (would it make sense to bundle the R binary distribution with atlas?  disk
| space is no longer an issue nowadays, and this would probably make life
| better for many users.)

Not for this reason.  Wrong assumptions lead you to the wrong conclusion.

Dirk
 
| regards,
| 
| /iaw
| ----
| Ivo Welch (ivo.welch at gmail.com)
| ----
| 
| 	[[alternative HTML version deleted]]
| 
| _______________________________________________
| R-SIG-Debian mailing list
| R-SIG-Debian at r-project.org
| https://stat.ethz.ch/mailman/listinfo/r-sig-debian

-- 
Dirk Eddelbuettel | edd at debian.org | http://dirk.eddelbuettel.com