lapack 3.0

James R. Phillips
Wed Jun 29 14:48:00 GMT 2005

--- Max Bowsher wrote:

> What sort of factors affect the optimization? Does the optimized library 
> actually perform _worse_ than the non-optimized one if its binaries are 
> copied to another computer?

The optimized libraries depend on the floating point acceleration architecture.
 Atlas supports SSE2 (pentium 3), SSE3 (pentium 4), 3dnow (amd athlon ?), and a
few  more.  Between these, there is no lowest common denominator, as 3dnow will
not execute on a non-amd processor, and SSE2 will not execute on some amds,
etc.  So due to the variety of floating point acceleration architectures, it
just isn't possible to provide one that is lowest common denominator, except
the non-optimized reference implementation.

> > installed by hand in the /usr/local/bin subdirectory.  This insures two
> > things: 1) they will be loaded at run time instead of the nonoptimized 
> > dlls
> Point 1) is valid only for executables not installed in /usr/bin themselves. 
> Is it likely that we would ever want to accept packages which use 
> lapack/atlas into the Cygwin distribution? If so, the above is not a 
> wonderful solution.
Umm, of course it is likely.  This is the intent.  My test configuration is of
octave-2.1.71, installed from source in /usr/local/bin.  In an official package
it would be installed in /usr/bin, so this would be a problem.  It just hasn't
come up in my testing.  I'll have to look into the issue.  Suggestions
involving minimal effort gratefully accepted.

More information about the Cygwin-apps mailing list