[Slackbuilds-users] lapack, blas, etc.

Serban Udrea serban.udrea at skmail.ikp.physik.tu-darmstadt.de
Thu Dec 4 16:58:28 UTC 2008

João Felipe Santos wrote:
> On Wed, Nov 19, 2008 at 4:04 PM, Serban Udrea
> Hello Serban,
> you should check this URL [1] if you want to create a LAPACK/Blas
> SlackBuild.


And thank you for the hint. I'll take a look.

Until now I did compile lapack 3.1.1(*) and it looks like all tests 
succeeded except the timing one. I'm not sure how important this is. I'm 
actually puzzled why such a test is performed.
Here is the output, maybe you can give me a hint about its 
interpretation and/or importance:

Time for 1,000,000 SAXPY ops  =   0.00     seconds
  *** Error:  Time for operations was zero
  Including SECOND, time        =  0.400E-02 seconds
  Average time for SECOND       =  0.800E-03 milliseconds
  Time for 1,000,000 DAXPY ops  =  0.400E-02 seconds
  DAXPY performance rate        =   250.     mflops
  Including DSECND, time        =  0.400E-02 seconds
  Average time for DSECND       =   0.00     milliseconds
  Equivalent floating point ops =   0.00     ops

This one works, but was written by the Slacky.eu
> community, and their style of writing SlackBuilds is different from
> the SBo style. I want to create a SlackBuild for ATLAS, and want to
> make it compatible with a previous LAPACK/Blas installation (so I
> don't need to recompile LAPACK when compiling ATLAS). If you need some
> help for doing this, let me know.

If I understand you well, you already have lapack/blas installed but 
would like to have the ATLAS implementation of blas for the performance 
gain, and you don't want to recompile lapack against ATLAS? In this case 
you may have problems, which may arise from differences in compiler 
flags, as stated in section 3.1.1 of ATLAS's compilation instructions.

I have to say, that I don't realy understand section 3.1.1 in the 
installation instructions for ATLAS. It is written there about 
installing first lapack and then ATLAS. But lapack depends on blas, if 
I'm not mistaken, and needs an already installed/compiled blas 
implementation. On the other hand ATLAS is a blas implementation. Thus I 
don't realy get it(**), and this is why I stick for the time beeing with 
the netlib implementation as delivered with the lapack source tree.

Best regards,


(*) I didn't go for 3.2 because I use to be somehow conservative and 
expect there may be some bugs to be squeezed out of 3.2. There seem to 
be also some API changes too. I also compiled blas from the lapack tree, 
did not try ATLAS.

(**) Might it be that ATLAS just automaticaly substitutes the blas 
libraries created during lapack compilation?

More information about the SlackBuilds-users mailing list