[Slackbuilds-users] lapack, blas, etc.
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  if you want to create a LAPACK/Blas
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.
(*) 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