Prof Brian Ripley wrote: > On Fri, 10 Feb 2006, Amit Aronovitch wrote: > > You set the reply address to Martin Maechler! That's antisocial. > Sincere apologies. I certainly didn't intend to! (I probably misclicked while trying to put him on Cc: )
Please ignore that header. >> Hi, >> >> Sorry for sending such a late reply, and for being abit OT. >> >> I've been trying to compile 64 bit ATLAS for numpy >> (http://numeric.scipy.org/ ), and so far this thread is the most >> useful one I could google up - thanks!. >> I encountered similiar problems, and so far could not get a .a >> linkable to numpy (comparing to your post - it seems I might have >> forgotten to add the -fPIC for the F77FLAGS or MMFLAGS). > > > Yes, that _is_ in the R-admin manual. I guess you have not read that > - it describes how to install R. You can get it in the R tarball from > > ftp://ftp.stat.math.ethz.ch/Software/R/R-devel.tar.bz2 > > >> Also, I'm having trouble with the ATLAS lapack. To get a usable lib, >> one has to merge it with a full lapack implementation (as described >> in the ATLAS errata). However, I'm using RHEL4, and their installed >> liblapack.a seems to have been compiled without -fPIC, so the merged >> library is unlinkable to numpy's .so. Is there a way to use Redhat's >> installed liblapack.so? > > > No, nor should you want to. If RHEL4 is like FC3/4 watch out, as RH > have managed to get BLAS routines in liblapack and not liblas, and use > incorrect patches to LAPACK 3.0. (Again, see the latest R-admin manual.) Thanks for the tip - guess that means I'll have to compile my own lapack... > >> Few questions about your compiler flags: >> >> 1) Is there a reason to compile with -O rather than -O3? >> (did you try and encounter some problem, or found no major performance >> difference) > > > ATLAS chose that. Since the real work is done by hand-tuned assembler > code it should not matter. > >> 2) I see you use -mfpmath=387 - does this work better than sse2 (which >> seems to be >> the default)? How about the "sse,387" option - should I try that? > > > Depends on your ATLAS version. Again, ATLAS chose those. > > As it happens, I have been trying to build ATLAS on my new dual > Opteron box this morning. The latest devel version (3.7.11) does not > build, as at some point it says it expects the GNU x86-32 assembler. > If it did it would use SSE3 and so be faster. > > Both 3.6.0 and 3.7.11 fail because my machine is too fast, and I had > to increase the number of replications (1000) in make/Make.{mv,r1}tune > and in tune/blas/level1/*.c. Even then I do not entirely trust the > results (and the two versions report different L1 caches sizes ...). > > I got pretty exasperated with this (it needed about ten builds to get > one that succeeded). Both ACML and the Goto BLAS work well out of the > box on Opterons, but do have licence issues. (Again, see the R-admin > manual for details.) > I'll certainly have to read the R-admin manual. Once I manage to get a working lib I'll try posting some of that info to ATLAS lists (should prbly be included in atlas errata or something). thanks alot, Amit A. ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
