ivo welch
2013-Jun-23 23:14 UTC
[R-sig-Debian] stock ubuntu raring binary R 3.0.1 and accelerated blas libraries?
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). libatlas use is not determined at compile time. 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? (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.) regards, /iaw ---- Ivo Welch (ivo.welch@gmail.com) ---- [[alternative HTML version deleted]]
Dirk Eddelbuettel
2013-Jun-24 00:22 UTC
[R-sig-Debian] stock ubuntu raring binary R 3.0.1 and accelerated blas libraries?
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