Richard W.M. Jones wrote:
> I have no particular affinity for Atlas.  But if we're going to
> replace it, is OpenBLAS a complete drop-in replacement for Atlas that
> requires no or at least very minimal changes?  In what ways is it better
> or worse?

Proper support for runtime CPU feature detection on x86 architectures 
(x86_64 and i686). ATLAS expects to be tuned to every single machine, and 
distro packages can only be built to the lowest common denominator. 
(Anything else can only be in atlas-* subpackages that have to be manually 
installed.) OpenBLAS can also do that, but it also has a mode (used in 
packaging) where it will check for the available vector instruction sets 
(MMX, SSE*, AVX*) and pick the highest one available on the machine that is 
implemented for the called function. E.g., it can use SSE3 and newer on 
x86_64 when available, without breaking the SSE2-only x86_64 baseline. 
(Please note that this is only supported on x86 at this time. For ARM, it is 
like ATLAS, you can only compile for the baseline.) This can make a big 
difference in distro packages.

There might also be other performance benefits. OpenBLAS is derived from 
GotoBLAS (which was put under a BSD license when Prof. Goto left TACC in 
2010, so that the community can continue development, which is exactly what 
OpenBLAS is doing). GotoBLAS has, since its proprietary times, had a 
reputation of being a really fast implementation.

        Kevin Kofler
devel mailing list --
To unsubscribe send an email to

Reply via email to