[Rd] BLAS/Lapack for OS X
Jan de Leeuw
deleeuw@stat.ucla.edu
Fri Nov 29 22:21:03 2002
Thanks. I have compared flags --without-blas and
--with-blas="-framework vecLib"
and no flag (which means it chooses the static ATLAS library from fink).
All three compiles go through fine. The ATLAS version is about twice as
fast as the --without-blas version on large eigenvalue problems for
Hilbert matrices (the larger, the more gain). The vecLib version does
not
work, because it says
Error in eigen(hilbert(500)) : lapack routines cannot be loaded
The only indication during compilation of something wrong is that the
lapack routines are defined twice (once in double.c and cmplx.c and
once in the vecLib framework), and that generates warnings.
I also tried
-- do not include double.lo and cmplx.lo in linking lapack.so
-- change the order in the link of -framework vecLib and double.lo and
cmplx.lo,
-- do not include -framework vecLib in the link
but I still get the same error, which seems to indicate the error is in
the BLAS part.
Does the lapack loading depend on the fact that the BLAS routines are
statically
linked (and come from static libraries) ? Of course the vecLib BLAS (and
LAPACK) are in a dynamic library.
On Friday, November 29, 2002, at 12:03 AM, ripley@stats.ox.ac.uk wrote:
> We do not use optimized LAPACKs because too many of them contain
> errors (one of which is in the current LAPACK sources and for which we
> use a modified souce with a modified name). That's stated in
> the distribution somewhere.
>
> There's nothing to allow you to build with an optimized LAPACK. The
> current code does work with some blases that contain lapack routines,
> e.g.
> sunperf. I have hacked the code to use sunperf and on real problems
> the
> gain is negligible.
>
> If `which do not work in combination with the BLAS from vecLib' is
> true,
> then your library is not providing a proper BLAS interface, but I
> would be
> interested to know what `does not work' means (it is the dreaded
> phrase of
> technical support staff).
>
> I have plans to have BLAS support in a shared library (as on Windows).
> There are some potential problems (e.g. ATLAS is built without PIC
> flags)
> and I do intend to get back to this for 1.7.x. The main potential
> problem
> will be the non-standard behaviour of MacOS X, I believe.
>
> On Thu, 28 Nov 2002, Jan de Leeuw wrote:
>
>> OS X 10.2 and higher comes standard with highly optimized versions
>> of BLAS and Lapack in /Systems/Library/Frameworks/vecLib.framework.
>> It seems that even for double precision they do much better. See
>>
>> http://sthmac.magnet.fsu.edu/benchmarks/
>>
>> I am not sure how these numbers would look on G3 Macs, but
>> obviously for double precision there is not much reliance on Altivec.
>>
>> So I tried to configure R-devel with --with-blas="-framework vecLib",
>> which seems to work well since --with-blas is used literally as a
>> linker flag
>>
>> But later the build gets into trouble because of the
>> Lapack sources in the R distribution, which define the same
>> (non-optimized) functions as the (optimized) functions in vecLib.
>> Thus double definitions, different sources, the linker uses the
>> R-versions
>> which come first and which do not work in combination with the BLAS
>> from vecLib.
>>
>> In this case we may also need a flag --with-lapack="-framework
>> vecLib",
>> which implies it should not use the Lapack files in R to build
>> lapack.so. Since Mac OS X 10.2 and higher always comes with
>> both Lapack and BLAS this could be the default in configure for
>> those systems.
>> ===
>> Jan de Leeuw; Professor and Chair, UCLA Department of Statistics;
>> Editor: Journal of Multivariate Analysis, Journal of Statistical
>> Software
>> US mail: 9432 Boelter Hall, Box 951554, Los Angeles, CA 90095-1554
>> phone (310)-825-9550; fax (310)-206-5658; email:
>> deleeuw@stat.ucla.edu
>> homepage: http://gifi.stat.ucla.edu
>>
>> ----------------------------------------------------------------------
>> --
>> -------------------------
>> No matter where you go, there you are. --- Buckaroo Banzai
>> http://gifi.stat.ucla.edu/sounds/nomatter.au
>>
>> ----------------------------------------------------------------------
>> --
>> -------------------------
>>
>> ______________________________________________
>> R-devel@stat.math.ethz.ch mailing list
>> http://www.stat.math.ethz.ch/mailman/listinfo/r-devel
>>
>
> --
> Brian D. Ripley, ripley@stats.ox.ac.uk
> Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
> University of Oxford, Tel: +44 1865 272861 (self)
> 1 South Parks Road, +44 1865 272860 (secr)
> Oxford OX1 3TG, UK Fax: +44 1865 272595
>
>
===
Jan de Leeuw; Professor and Chair, UCLA Department of Statistics;
Editor: Journal of Multivariate Analysis, Journal of Statistical
Software
US mail: 9432 Boelter Hall, Box 951554, Los Angeles, CA 90095-1554
phone (310)-825-9550; fax (310)-206-5658; email: deleeuw@stat.ucla.edu
homepage: http://gifi.stat.ucla.edu
------------------------------------------------------------------------
-------------------------
No matter where you go, there you are. --- Buckaroo Banzai
http://gifi.stat.ucla.edu/sounds/nomatter.au
------------------------------------------------------------------------
-------------------------