OpenBLAS as default BLAS implementation
Use OpenBLAS as the default BLAS library implementation.
Most application use ATLAS because it's faster than reference BLAS. However, it doesn't support runtime CPU detection, so it must be built for a particular CPU. OpenBLAS is a competing BLAS implementation based on GotoBLAS2 that is and supports runtime CPU detection and all current Fedora primary arches.
Benefit to Fedora
Using a single default BLAS implementation will avoid bugs stemming from having two different BLAS libraries loaded at runtime that causes computation errors.
OpenBLAS detects CPU capabilities at runtime and selects the fastest computation kernel for the running hardware.
A lot of benchmarks around the net suggest openblas is faster than ATLAS in most workloads: https://github.com/tmolteno/necpp/issues/18 http://blog.nguyenvq.com/blog/2014/11/10/optimized-r-and-python-standard-blas-vs-atlas-vs-openblas-vs-mkl/ https://freddie.witherden.org/pages/blas-gemm-bench/ http://nghiaho.com/?p=1726
- Proposal owners:
Modify the affected packages to BuildRequire: openblas-devel instead of atlas-devel or blas-devel and rebuild. Fix any failures.
- Other developers:
- Release engineering:
No help should be necessary. No mass rebuild necessary.
- List of deliverables: all
- Policies and guidelines: N/A
- Trademark approval: N/A
How To Test
atlas (34): ceres-solver CheMPS2 cxsc DSDP freefem++ ga gromacs iml jblas libcint libghemical linbox Macaulay2 mpqc ncl python-nipy ocaml-gsl octave octave-odepkg opengrm-ngram psfex psi4 python-cvxopt python-scikit-learn qcint qm-vamp-plugins sagemath scamp sextractor shogun suitesparse SuperLU SuperLU43 wannier90
blas (2): octave-control octave-optim
- Contingency mechanism: (What to do? Who will do it?) If switching to OpenBLAS breaks a particular package, changes to the package will be reverted and package rebuilt.
- Contingency deadline: beta freeze
- Blocks release? No
- Blocks product? No