ATLAS RPM

ATLAS is a BLAS implementation that is tweaked at compile time for a particular CPU. By doing so it can achieve speeds that even vendors cannot match.

This page is about RPMs that I have made for the ATLAS libraries. It was necessary to write this page because making RPMs of ATLAS is tricky. Read on for more information. But first, for the impatient:

All my RPMs are signed with my public key.² Older releases can be found here.

Why are there only source RPMs?

The very nature of ATLAS is to be tweaked to death for a particular CPU. The concept of RPM architecture is not sufficient for the distribution of precompiled RPMs. For example, I may compile ATLAS on my "Intel(R) Pentium(R) 4 Mobile CPU 1.60GHz" and label the RPM as compiled for the i686 architecture, but that would be too general. Since my laptop has SSE1 and SSE2 instructions, the precompiled library would be incompatible with other i686 CPUs that don't have these instructions.

This is only one example. The size of the L1 and L2 (and possibly L3) caches fluctuate a lot from one CPU to the other. The ordering of the instructions changes too among CPUs of the same architecture. The bottom line is that precompiled ATLAS RPMs cannot be distributed at large. Not because the license doesn't allow it. It's simply not technically feasible if you want maximum performance.

What about the Debian precompiled package?

The Debian package, made by the very clever Camm Maguire, is distributed precompiled in various flavours. However, it cannot bypass the DEB architecture limitation. There is one package for each architecture, even if CPUs vary a lot inside the same architecture. This means that the package must be compiled using the common denominator, usually the slowest and smallest CPU that can be found for a particular architecture. For example, the i386 package is compiled using a Pentium II 350MHz. This means that the precompiled package does not take advantage of all the possibilities of more advanced CPUs. But the package works on the system, and from a package management standpoint everything is fine.

Another problem that arises when you try to maintain binary packages is the question of how to reproduce the exact same libraries on different systems. This is important because, for a given architecture, you don't want the build to be affected by the kind of CPU it is compiled on. The strategy that Debian packagers use is very clever. Using the reference CPU, they generate some kind of log of all the decisions that the ATLAS build process takes. This log is added to the package as a gigantic patch. When building the package, the log is simply replayed. This guarantees the integrity of the package when compiled on different CPUs. However, a log has to be generated for all architectures, which creates a very big patch. (The Debian package comes with a patch that is bigger than the original tarball!) These logs have to be regenerated for each architecture every time the original tarball is updated, and system for which no log exists cannot recompile the package.

But the whole point of using ATLAS is to get maximum performance out of your CPU. If this is not important to you, then you might as well be running the reference implementations, for which RPMs come standard in most distros. On the other hand, if it is important to you, then you simply can't be using generic RPMs.

So what am I supposed to do with your source RPM?

Building a source RPM (SRPM) is much easier than building a generic package from source. Most of the work has been done for you. First of all, you should create a .rpmmacros file in your home directory. It should contain the following:

%packager               Foo Bar <foo@bar.com>
%_topdir                /home/foobar/rpmbuild

Replace the definition of %packager with your own name and email address. If you want to sign your RPM with GPG, you may add the following:

%_signature             gpg
%_gpg_name              foo@bar.com

Finally, if you have a multiprocessor system you should add the following line:

%_smp_mflags            -j2

You should tweak the above according to the number of processors on your system.

Now that you have a basic .rpmmacros file, the next step is creating the necessary directory hierarchy. The following commands should do it:

cd
mkdir rpmbuild
cd rpmbuild
mkdir BUILD RPMS SOURCES SPECS SRPMS tmp
cd

These directories are used by the rpmbuild command when compiling your RPM from source.

The final step is actually compiling the SRPM. Simply issue the rpmbuild --rebuild command on the SRPM file you have downloaded. Then the ATLAS configuration script will as you some questions. I answer all of them by using the default and pressing enter, but you may wish to fine-tune some little things. Consult the ATLAS documentation for more information on the configuration script.

When compilation is done, your binary RPM is placed in ~/rpmbuild/RPMS/$arch, where $arch varies depending on your CPU. You can sign your RPM using the following command:

rpm --addsign ~/rpmbuild/$arch/atlas*

You can distribute this RPM on CPUs of the exact same model, but you should always recompile it for different CPUs

I just lied to you

In fact, there are precompiled RPMs available on this page. I just wanted to scare you a little to really make you understand the implications of using precompiled binaries of ATLAS RPMs. The major problem you will encounter when using a RPM compiled for different hardware is that the speed is not as good as it could be. You've been warned.

Here are precompiled RPMs, listed along with the type of CPU on which they were compiled. If your exact target CPU is not listed, try to pick one which is closest. Even better: compile your own RPM. This is easy! Just follow the instructions above. Then send me your compiled RPM and I'll include it here!

Why are there no shared libraries?

I know, static libraries are almost worthless for package management. However, the ATLAS developers have not provided a way to build shared libraries. Maximum performance is obtained using static libraries and so the decision of ATLAS developers is justified. We'll have to put pressure on ATLAS developers to make shared libraries.

Notes

1. Although the RPM style is Fedora, it should work on any other distro. Please tell me if you find any incompatibility.
2. To verify the authenticity of my RPMs using my public key, first import it into your RPM keyring:
   rpm --import http://nomis80.org/nomis80.gpg
   Then verify files using this command:
   rpm -K atlas-xxx.rpm