Skip to content
Prev 4518 / 15075 Next

BLAS/LAPACK/Accelerate on Leopard with R 2.6.2

On Thu, 27 Mar 2008, Alexy Khrabrov wrote:

            
Whatever you compile it against!  It looks like you didn't consult the 
R-admin manual before posting, so please do study it now.

I believe that the binary versions distributed from CRAN are compiled 
against vecLib:

blacklark% otool -L libRblas.dylib
libRblas.dylib:

/Library/Frameworks/R.framework/Versions/2.6/Resources/lib/libRblas.dylib 
(compatibility version 0.0.0, current version 0.0.0)
         /System/Library/Frameworks/vecLib.framework/Versions/A/vecLib 
(compatibility version 1.0.0, current version 192.15.0)
         /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current 
version 1.0.0)
         /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current 
version 88.3.9)

since the recommended configure sequence is

./configure --with-blas='-framework vecLib' --with-lapack \
   --with-aqua --enable-R-framework

(see the R-admin manual).

Note that we prefer to have correct answers rather than fast ones, and the 
reference BLAS given by the default options is often more accurate and 
more reliable (and so is the LAPACK distributed -- is is 3.1 so has 
bugfixes against 3.0, but not the several incorrect bugfixes that some 
Linux distributions have). So personally I only recommend using an 
optimized BLAS when you need the performance (and few R sessions use 
enough matrix algebra to do so).

I've checked that --with-blas='-framework Accelerate' also works, but I 
see no real performance difference (and small differences can be hard to 
detect).  (I tested i386, but x86_64 seems also to work.)
Hmm, actually it tells you Accelerate uses vecLib for BLAS/LAPACK.
That's always wrong: lapack should never be part of the BLAS.
Ultimately, we don't know.  Different compilers can have different 
argument-passing conventions on the same platform, so we would have to 
look at every call (in vecLib, which is not AFAIK Open Source) on each 
MacOS X architecture to *know*.

This is not idle speculation: gcc3 and gcc4 ('Gnu Compiler Collection') 
have used different calling conventions on x86_64 on Linux and Solaris, so 
it is likely that not all Fortran compilers on x86_64 on MacOS are 
compatible.  (And AFAIR that is why there are vecLibg95c.c and 
vecLibg95f.f in the R sources, and why there are configure tests in R for 
this.)
Ask IBM.