Automatically Tuned Linear Algebra Software

Automatically Tuned Linear Algebra Software (ATLAS) is a software library for linear algebra. It provides a mature open source implementation of BLAS APIs for C and Fortran77.
ATLAS is often recommended as a way to automatically generate an optimized BLAS library. While its performance often trails that of specialized libraries written for one specific hardware platform, it is often the first or even only optimized BLAS implementation available on new systems and is a large improvement over the generic BLAS available at Netlib. For this reason, ATLAS is sometimes used as a performance baseline for comparison with other products.
ATLAS runs on most Unix-like operating systems and on Microsoft Windows (using Cygwin). It is released under a BSD-style license without advertising clause, and many well-known mathematics applications including MATLAB, Mathematica, Scilab, SageMath, and some builds of GNU Octave may use it.
Functionality.
ATLAS provides a full implementation of the BLAS APIs as well as some additional functions from LAPACK, a higher-level library built on top of BLAS. In BLAS, functionality is divided into three groups called levels 1, 2 and 3.
Optimization approach.
The optimization approach is called Automated Empirical Optimization of Software (AEOS), which identifies four fundamental approaches to computer assisted optimization of which ATLAS employs three:
Level 3 BLAS.
Most of the Level 3 BLAS is derived from GEMM, so that is the primary focus of the optimization.
The intuition that the formula_17 operations will dominate over the formula_18 data accesses only works for roughly square matrices.
The real measure should be some kind of surface area to volume.
The difference becomes important for very non-square matrices.
Can it afford to copy?
Copying the inputs allows the data to be arranged in a way that provides optimal access for the kernel functions, 
but this comes at the cost of allocating temporary space, and an extra read and write of the inputs.
So the first question GEMM faces is, can it afford to copy the inputs?
If so, 
If not,
The actual decision is made through a simple heuristic which checks for "skinny cases".
Cache edge.
For 2nd Level Cache blocking a single cache edge parameter is used.
The high level choose an order to traverse the blocks: "ijk, jik, ikj, jki, kij, kji". 
These need not be the same order as the product is done within a block.
Typically chosen orders are "ijk" or "jik".
For "jik" the ideal situation would be to copy "A" and the "NB" wide panel of "B". 
For "ijk" swap the role of "A" and "B".
Choosing the bigger of "M" or "N" for the outer loop reduces the footprint of the copy.
But for large "K" ATLAS does not even allocate such a large amount of memory.
Instead it defines a parameter, "Kp", to give best use of the L2 cache. 
Panels are limited to "Kp" in length.
It first tries to allocate (in the "jik" case) formula_19.
If that fails it tries formula_20.
"Kp" is a function of cache edge and "NB".
LAPACK.
When integrating the ATLAS BLAS with LAPACK an important consideration is the choice of blocking factor for LAPACK. If the ATLAS blocking factor is small enough the blocking factor of LAPACK could be set to match that of ATLAS.
To take advantage of recursive factorization, ATLAS provides replacement routines for some LAPACK routines. These simply overwrite the corresponding LAPACK routines from Netlib.
Need for installation.
Installing ATLAS on a particular platform is a challenging process which is typically done by a system vendor or a local expert and made available to a wider audience.
For many systems, architectural default parameters are available; these are essentially saved searches plus the results of hand tuning. 
If the arch defaults work they will likely get 10-15% better performance than the install search. On such systems the installation process is greatly simplified.