Review Re-Request: ATLAS, a fast implementation of BLAS and LAPACK

[Quentin Spencer]

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 
>>>>http://webpages.charter.net/qspencer/rpm/
>>>>
>>>>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[1], SSE2 for pentium4[1].
>>>I don't think there's any point in providing an i386 package.
>>>
>>>[1] 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:
>>atlas
>>atlas-devel
>>atlas-sse-devel
>>atlas-sse2-devel
>>atlas-3dnow-devel
>>    
>>
>
>How about
>atlas.i386
>atlas-devel.i386
>atlas-devel.pentium3
>atlas-devel.pentium4
>atlas-devel.athlon
>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
>and with
>--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.

-Quentin