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 ------------------------------------------------------------------------ -------------------------
BLAS/Lapack for OS X
7 messages · Brian Ripley, Paul Gilbert, Jan de Leeuw
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
ripley@stats.ox.ac.uk wrote:
...
I have hacked the code to use sunperf and on real problems the gain is negligible.
... I also found this to be the case in some recent testing I did in Linux (Mandrake 9.0) with an AMD Athlon 2100+. Converting from my non BLAS version of R 1.6.1 to optimized ATLAS saved about 10 minutes on a 4.5 hour test suite. This was using a .a rather than a .so version of the library, but according to a comment by Doug Bates, the .a library is probably faster (but I presume uses more memory). The tests do many things I would not expect to benefit from ATLAS, but about a quarter of the time is spent on programs that do make fairly heavy use of La.svd and La.eigen. So, on some problems you might save some time, but overall I think, as Brian says, the gain is negligible. Paul Gilbert
NB: I referred to sunperf, not ATLAS. Sunperf is a BLAS/LAPACK replacement, not just a version of BLAS. There are problems where using an optimized BLAS helps, but my comment was about an optimized LAPACK on top of an optimized BLAS.
On Fri, 29 Nov 2002, Paul Gilbert wrote:
ripley@stats.ox.ac.uk wrote: ...
I have hacked the code to use sunperf and on real problems the gain is negligible.
... I also found this to be the case in some recent testing I did in Linux (Mandrake 9.0) with an AMD Athlon 2100+. Converting from my non BLAS version of R 1.6.1 to optimized ATLAS saved about 10 minutes on a 4.5 hour test suite. This was using a .a rather than a .so version of the library, but according to a comment by Doug Bates, the .a library is probably faster (but I presume uses more memory). The tests do many things I would not expect to benefit from ATLAS, but about a quarter of the time is spent on programs that do make fairly heavy use of La.svd and La.eigen. So, on some problems you might save some time, but overall I think, as Brian says, the gain is negligible. Paul Gilbert
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
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 ------------------------------------------------------------------------ -------------------------
On Fri, 29 Nov 2002, Jan de Leeuw wrote:
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.
I don't think that follows. It just seems to indicate problems in what you did. That's not surprising, as your lapack will not have the modified routines in double.f (did you read the README?). You should have used your tools to find the missing symbols.
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.
Not at all. Dynamic linking works on Linux and Solaris, for example. Who knows about non-Unix OS's like MacOS, though? Take a look at the current R-devel, which does allow an external LAPACK library to be used, and even allows it to be the same as the BLAS library. This works with SunPerf, which is a combined BLAS/LAPACK, except that it is not quite complete and I had to use a re-named copy of dlange.f in the sources. [BTW, when I say `works' it all builds but fails to complete the mva-Ex.R test on 64-bit Solaris, something I have yet to track down.] I would expect that on your `OS' specifying --with-blas will automatically notice that you have LAPACK in the BLAS library and omit double.lo and cmplx.lo. There should thne be no duplicate symbols, but you will have to check with ldd+nm (or whatever) to see that symbols are being resolved. There's a fair chance something will be missing. Brian
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 ------------------------------------------------------------------------ -------------------------
______________________________________________ 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
Since this may lead to some misunderstandings, I will elaborate a bit. Darwin is BSD 4.4 on top of the Mach 3.0 OSF kernel (not the old microkernel). Some IPC and threading components are taken from the Mach part, otherwise all of FreeBSD 4.4 is there. Much is added: VSF, Journalling, CUPS, gcc and friends. A version of Darwin for x86 machines is available from CVS. All of it is open source. Brian is right that Darwin is not Unix, neither are FreeBSD, NetBSD, OpenBSD, and the various Linuxes. Unix is a trademark owned by the Open Group, and none of the above mentioned OS's are registered. See http://www.osopinion.com/perl/printer/9451/ for more details, and http://developer.apple.com/darwin/history.html for some history and propaganda. Of course Mac OS X is certainly not Unix, because it adds Quartz, OpenGL, Aqua, Cocoa, Carbon, Classic on top of the Darwin Mach/BSD layer. But currently, for the Darwin/X11 version, none of those top layers are used, and we just add Xfree86 to get the GUI (and all of gnome if we want the extension module). On Saturday, November 30, 2002, at 07:04 AM, ripley@stats.ox.ac.uk wrote:
Not at all. Dynamic linking works on Linux and Solaris, for example. Who knows about non-Unix OS's like MacOS, though?
=== 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 ------------------------------------------------------------------------ -------------------------