On Sat, Aug 12, 2017 at 12:40:18PM +0200, Kevin Kofler wrote: > 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. Sounds all good. Are source-level changes needed to dependent packages and if so are they simple to make? Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://libguestfs.org _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
