Skip to content

(Current) Ubuntu : r-base-dev seems incompatible with atlas-base-dev.

2 messages · Dirk Eddelbuettel, Emmanuel Charpentier

#
Emmanuel,
On 30 August 2008 at 00:04, Emmanuel Charpentier wrote:
| Dear list,
| 
| Setup : Ubuntu Hardy + updates + backports + security + R repository on
| a 3.2 GHz PIV dual-core processor.
| 
| Bitten (again...) by the "I'll optimize my setup" bug, I tried to test
| atlas. Following Dirk's advice on a not-so-recent post to R-help, I
| tried "apt-get install -s atlas3-doc atlas3-base-dev" (I tend to
| recompile some packages, so I need r-base-dev and I *think* I need
| atlas3-base-dev to allow the recompiled packages to use it, but I might
| be completely wrong...). Ahem ... :
| 
| [ Snip... ]
| 
| Les paquets suivants seront ENLEV?S :
|   libblas-dev liblapack-dev r-base-dev
| 
| [ Snip again ... ]
| 
| (for non-francophones : "The following packages will be REMOVED : ...").
| 
| However, atlas3-base *is* currently installed, and I never had problems
| recompiling packages.

Quick guess: you have the old atlas-* packages instead of the new libatlas-*
packages. Try 

	$ sudo apt-get install libatlas3gf-base libatlas-base-dev

| So, my (first) question is : what would be the benefits of installing
| atlas3-base-dev ? Isn't that necessary for recompiling packages ?

[Make that libatlas-base-dev]  So that you can compile against Atlas and get
the 'automatically tuned linear algebra system' for better performance on
linear algebra.

| Second question : what would be the benefits/drawbacks of "apt-get
| install atlas3-sse2 lapack3" ? A brief test seems to hint to limited
| benefits...

[Make that libatlas3gf-sse2]  Faster performance for binary code tuned to
your process.  Atlas actually provides lapack, and replace it in use.

| Last but not least : Atlas does not seem to exist on other architectures
| (I'm interested in amd64, of course...), at least in Debian and Ubuntu.
| Are there similar projects for amd64 I'm not aware of ?

Are you sure?  This has built on many architectures for many years, and the
reason it took so long to get to libatlas [ie the new build with the new
Fortran compuler] was as far as I know the darn portability.

All this works on my Debian (which gets R from my Debian packages) and Ubuntu
(which gets R from CRAN) machines.

Hope this helps, Dirk
#
Dear Dirk,

Le vendredi 29 ao?t 2008 ? 17:37 -0500, Dirk Eddelbuettel a ?crit :
Right on ! It happened that I had already libatlas3gf-base on my PIV
system. libatlas-base-dev  installed without a hitch.

My asinine insistence on atlas* was probably due to the fact that this
system has been installed quite a bit ago (dapper ? or even before
that ? ) and has been upgraded since. It has ben, however, reinforced by
a README.Atlas file which hasn't been updated since 2001 and points to
atlas2-*.

Maybe an upgrade of this file would be in order ?

Anyway, installing libatlas3gf-sse2 didn't produce any difference in the
"small" test hinted at in the README file.

[ Snip ...  ]
We are both right : no atlas* executable package in Ubuntu or Debian
amd64 (there is, however, an altas2-base-dev (IIRC)...). But there is
indeed a libatlas3gf-base and a -dev packages in Ubuntu amd64.

That's what happens when you use "dpkg -l atlas*" instead of searching
"atlas" in the synaptic GUI... I might have got the right hint by
searching "*atlas*" instead...

Installing it gave me more or less 3x acceleration of your matrix
inversion test. Mmmm...
It sure did ! Thank you, Dirk !

					Emmanuel Charpentier