From Fedora Project Wiki

< PackagingDrafts

Revision as of 05:38, 13 January 2016 by Orion (talk | contribs) (Created page with "{{Draft}} = Introduction = Besides being implementations, BLAS and LAPACK are also API standards for basic linear algebra operations (such as vector and matrix multiplication...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

This page is a draft only
It is still under construction and content may change. Do not rely on the information on this page.


Besides being implementations, BLAS and LAPACK are also API standards for basic linear algebra operations (such as vector and matrix multiplication).

Many implementations of these API exist. The reference implementation of BLAS and LAPACK from netlib is very stable but is not as fast as optimized ones such as ATLAS and OpenBLAS.

Implementations of BLAS:

  • blas - Reference implementation from netlib
  • atlas - Automatically Tuned Linear Algebra Software
  • openblas - OpenBLAS, an optimized BLAS based on GotoBLAS2

Implementations of LAPACK:

  • lapack - Reference implementation from netlib
  • ATLAS and OpenBLAS both provide an optimized subset of LAPACK

Due to implementation differences, it is important that all components of a particular software stack link to the same BLAS/LAPACK implementation. Also, users may want to choose a particular implementation that works best for them at run time. This guideline gives a structure that can enforce the first while allowing the second.

BLAS/LAPACK implementations

Implementations of a BLAS and/or LAPACK library will provide relative symbolic links in %{_libdir}/IMPLEMENTATION-NAME/ of and/or as appropriate pointing to the actual implementation library. Each implementation may have multiple IMPLEMENTATION-NAMEs, e.g. for serial and parallel versions.

For example, atlas would do:

ln -s ../ %{buildroot}%{_libdir}/atlas-serial/
ln -s ../ %{buildroot}%{_libdir}/atlas-serial/
ln -s ../ %{buildroot}%{_libdir}/atlas-threaded/
ln -s ../ %{buildroot}%{_libdir}/atlas-threaded/

For each IMPLEMENTATION-NAME, the implementation package will provide an environment module, e.g.:

#%Module 1.0
# ATLAS module for loading serial atlas library
conflict                blas
prepend-path            LD_LIBRARY_PATH /usr/lib64/atlas-serial

as %{_datadir}/modulefiles/blas/atlas-serial. The implementation must then require an environment module implementation:

Requires: environment(modules)

Because many (all except the reference?) BLAS/LAPACK implementations are combined BLAS/LAPACK libraries, we do not support separate specification of BLAS and LAPACK, only combinations that are explicitly known to work.

BLAS/LAPACK dependent packages

Generic Usage

If the BLAS/LAPACK consumer does not require special compile time configuration for different BLAS/LAPACK implementations, it should simply build against the reference implementation:

BuildRequires: blas-devel
BuildRequires: lapack-devel

so that they end up linking to and, thus allowing the implementation to be switched at run time.

Compile time configuration

If the consumer requires special configuration for different implementations, it should provide versions compiled with each implementation.

End-User Documentation

End users will load the implementation they desire with:

module load blas/IMPLEMENTATION-NAME

TODO - choose a distribution default?