Review Re-Request: ATLAS, a fast implementation of BLAS and LAPACK
qspencer at ieee.org
Tue Sep 13 21:34:31 UTC 2005
Dominik 'Rathann' Mierzejewski wrote:
>On Tuesday, 13 September 2005 at 20:17, Quentin Spencer wrote:
>>Dominik 'Rathann' Mierzejewski wrote:
>>>On Monday, 12 September 2005 at 20:42, Quentin Spencer wrote:
>>>>This has been waiting for review for a while, but I just revised the
>>>>package, so I thought I'd send a new notice. The request for review is
>>>>Bugzilla number 166871. The spec and SRPM can be found at
>>>>Note that this one can take a long time to compile, especially on i386,
>>>>because it makes subpackages for sse, sse2, and 3dnow. It also has a
>>>>custom compilation option that can build libraries that enable the
>>>>compile-time optimizations to create libraries for a specific hardware
>>>>configuration--see the spec file and documentation.
>>>I think the 3DNow-optimized binary could be %ifarch'd athlon
>>>and SSE could be default for pentium3, SSE2 for pentium4.
>>>I don't think there's any point in providing an i386 package.
>>> at least for FC4. For FC3 there's a problem with lack of pentium3
>>>and pentium4 arches in RPM.
>>The point in providing an i386 package is that we don't know what
>>hardware people are running FC4 on, and it is unacceptable for the
>>package to simply not work on pre-SSE processors (I still have a Pentium
>>233 which I run Fedora on).
>I agree, but I thought the point of atlas was to provide libs only
>for those CPUs with SSE/3DNow. If that's not the case, then what's
>their advantage over BLAS?
They are still faster than BLAS. Some rough figures from my experience
(depending on the size of the matrix computation) are that base i386
atlas is about 3x faster than BLAS, and SSE2 atlas is about 10x faster.
>>Furthermore, the base i386 architecture is
>>the only one on which shared libraries can currently be compiled with
>>GCC4 (The maintainer is aware of the problem, but a fix might not be).
>>So compiling the package on i386 creates the following packages:
>instead? The last three would be, as I proposed earlier, %ifarch'd in the
>spec, so this would need to be built with
>--target i386 to get the first two
>--target pentium3, pentium4 and athlon to get the rest
>I think it's cleaner that way and doesn't require the user to know
>whether or not his CPU supports SSE2 instructions. It also prevents
>him from installing the wrong package accidentally.
This would all be nice if we had yum repositories that were specific to
pentium3, athlon, etc. However, right now we have three repository and
build system architectures: i386, x86_64, and PPC, so the spec file has
to build everything from those base architectures, and the user has to
know a bit about his system. The libs are designed to go into separate
subdirectories of /usr/lib, so they can theoretically all be installed
at the same time. When the shared libs are fixed, I plan to borrow some
tricks from the Debian packages in the install scripts that determine
what is supported and modify a file in /etc/ld.so.conf.d/ accordingly.
More information about the fedora-extras-list