From andy_liaw at merck.com  Mon Jul 24 17:14:34 2006
From: andy_liaw at merck.com (Liaw, Andy)
Date: Mon, 24 Jul 2006 11:14:34 -0400
Subject: [Rd] compiling R | multi-Opteron | BLAS source
Message-ID: <39B6DDB9048D0F4DAD42CB26AAFF0AFA029B17D4@usctmx1106.merck.com>

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



[Rd] compiling R | multi-Opteron | BLAS source
Liaw, Andy