R devel - Jul 2006 - compiling R | multi-Opteron | BLAS source

Greetings -

A quick perusal of some of the posts to this maillist suggest the level 
of the questions is probably beyond someone working at my level, but at 
the risk of looking foolish publicly (something I find I get 
increasingly comfortable with as I get older), here goes:

My research group recently purchased a multi-Opteron system (bunch of 
880 chips), running 64-bit RHEL 4 (which we have site licensed at our 
university, so it cost us nothing - good price) with SMP support built 
into the kernel (perhaps obviously, for a multi-pro system). Several of 
our user use [R], which I've only used on a few occasions. However, it 
is part of my task to get [R] installed for folks using this system.

While the simple, basic compile sequence (./configure, make, make check, 
make install) went smoothly, its pretty clear from our benchmarks that 
the [R] code isn't running as 'rocket-fast' as it should for a
system
like this. So, I dig a bit deeper. Most of the jobs we want to run could 
benefit from BLAS support (lots of array manipulations and other bits of 
linear algebra), and a few other compilation optimizations - and here is 
where I seek advice.

1) Looks like there are 3-4 flavours: LAPACK, ATLAS, ACML 
(AMD-chips...), and Goto. In reading what I can find, it seems that 
there are reasons not to use ACML (single-thread) despite the AMD chips, 
reasons to avoid ATLAS (some hassles compiling on RHEL 4 boxes), reasons 
to avoid LAPACK (ibid), but apparently no problems with Goto BLAS.

Is that a reasonable summary? At the risk of starting a larger 
discussion, I'm simply looking to get BLAS support, yielding the fastest 
[R] code with the minimum of hassles (while tweaking lines of configure 
fies,  weird linker sequences and all that used to appeal when I was a 
student, I don't have time at this stage). So, any quick recommendation 
for *which* BLAS library? My quick assessment suggests goto BLAS, but 
I'm hoping for some confirmation.

3) compilation of BLAS - I can compile for 32-bit, or 64-bit. 
Presumably, given we've invested in 64-bit chips, and a 64-bit OS, we'd 
like to consider a 64-bit compilation. Which, also presumably, means 
we'd need 64-bit compilation for [R]. While I've read the short blurb on
CRAN concerning 64-bi vs 32-bit compilations (data size vs speed), I'd 
be happy to have both on our machine. But, I'm not sure how one 
specifies 64-bits in the [R] compilation - what flags to I need to set 
during ./configure, or what config file do I need to edit?

Thanks very much in advance - and, again, apologies for the 'low-level' 
of these questions, but one needs to start somewhere.

From: Evan Cooch
> 
> Greetings -
> 
> A quick perusal of some of the posts to this maillist suggest 
> the level of the questions is probably beyond someone working 
> at my level, but at the risk of looking foolish publicly 
> (something I find I get increasingly comfortable with as I 
> get older), here goes:
> 
> My research group recently purchased a multi-Opteron system 
> (bunch of 880 chips), running 64-bit RHEL 4 (which we have 
> site licensed at our university, so it cost us nothing - good 
> price) with SMP support built into the kernel (perhaps 
> obviously, for a multi-pro system). Several of our user use 
> [R], which I've only used on a few occasions. However, it is 
> part of my task to get [R] installed for folks using this system.
> 
> While the simple, basic compile sequence (./configure, make, 
> make check, make install) went smoothly, its pretty clear 
> from our benchmarks that the [R] code isn't running as 
> 'rocket-fast' as it should for a system like this. So, I dig 
> a bit deeper. Most of the jobs we want to run could benefit 
> from BLAS support (lots of array manipulations and other bits 
> of linear algebra), and a few other compilation optimizations 
> - and here is where I seek advice.
> 
> 1) Looks like there are 3-4 flavours: LAPACK, ATLAS, ACML 
> (AMD-chips...), and Goto. In reading what I can find, it 
> seems that there are reasons not to use ACML (single-thread) 
> despite the AMD chips, reasons to avoid ATLAS (some hassles 
> compiling on RHEL 4 boxes), reasons to avoid LAPACK (ibid), 
> but apparently no problems with Goto BLAS.
> 
> Is that a reasonable summary? At the risk of starting a 
> larger discussion, I'm simply looking to get BLAS support, 
> yielding the fastest [R] code with the minimum of hassles 
> (while tweaking lines of configure fies,  weird linker 
> sequences and all that used to appeal when I was a student, I 
> don't have time at this stage). So, any quick recommendation 
> for *which* BLAS library? My quick assessment suggests goto 
> BLAS, but I'm hoping for some confirmation.
I think the early version of ACML lagged behind others, but recent
 versions are competitive.  I've run into precision problem (failing
 make check all) with some Goto BLAS before.  Also, Goto BLAS has 
switched to a more restrictive license (probably not a problem for 
you though).
 
> 3) compilation of BLAS - I can compile for 32-bit, or 64-bit. 
> Presumably, given we've invested in 64-bit chips, and a 
> 64-bit OS, we'd like to consider a 64-bit compilation. Which, 
> also presumably, means we'd need 64-bit compilation for [R]. 
> While I've read the short blurb on CRAN concerning 64-bi vs 
> 32-bit compilations (data size vs speed), I'd be happy to 
> have both on our machine. But, I'm not sure how one specifies 
> 64-bits in the [R] compilation - what flags to I need to set 
> during ./configure, or what config file do I need to edit?
That's up to the compiler(s) you use (unstated).  For GCC, I believe
-m64/-m32 is the flag.  For 64-bit GCC -m64 is the default.

Andy
 
> Thanks very much in advance - and, again, apologies for the 
> 'low-level' 
> of these questions, but one needs to start somewhere.
> 
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
> 
>