PackagingDrafts/BLAS LAPACK

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

Introduction

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 must build versions of their libraries with the libblas.so.3 and liblapack.so3 sonames containing the appropriate symbols and ship them in %{_libdir}/IMPLEMENTATION-NAME/. Each implementation may have multiple IMPLEMENTATION-NAMEs, e.g. for serial and parallel versions.

For example, atlas would have:

%files
...
%{_libdir}/%{name}-serial/libblas.so.3
%{_libdir}/%{name}-serial/liblapack.so.3
%{_libdir}/%{name}-threaded/libblas.so.3
%{_libdir}/%{name}-threaded/liblapack.so.3

If ILP64 (64-bit integer) implementations are available, they should be provided as well. For openblas:

%files
...
%{_libdir}/%[name}-serial/libblas64.so.3
%{_libdir}/%{name}-serial/liblapack64.so.3
%{_libdir}/%{name}-serial/libblas64_.so.3
%{_libdir}/%{name}-serial/liblapack64_.so.3

System level BLAS/LAPACK selection

To allow system level selection of the desired BLAS/LAPACK implementation, alternatives are used, selecting which path is desired for /etc/ld.so.conf.d/blas-%{arch}.conf.

Requires(post): %{_sbindir}/update-alternatives
Requires(postun): %{_sbindir}/update-alternatives

%install
...
mkdir -p %{buildroot}%{_sysconfdir}/ld.so.conf.d
touch %{buildroot}%{_sysconfdir}/ld.so.conf.d/blas-%{_arch}.conf
echo %{_libdir}/%{name}-serial > %{buildroot}%{_sysconfdir}/ld.so.conf.d/blas-%{_arch}.conf-%{name}-serial

%post
%{_sbindir}/update-alternatives --install %{_sysconfdir}/ld.so.conf.d/blas-%{_arch}.conf \
  blas %{_sysconfdir}/ld.so.conf.d/blas-%{_arch}.conf-%{name}-serial 60
/sbin/ldconfig

%postun
if [ $1 -eq 0 ] ; then
  %{_sbindir}/update-alternatives --remove blas %{_sysconfdir}/ld.so.conf.d/blas-%{_arch}.conf-%{name}-serial
fi
/sbin/ldconfig

Current established priorities are 30 for atlas and 60 for openblas.

Also, we provide libblas/liblapack:

%if %{_lib} == "lib64"
Provides: libblas.so.3()(64bit)
Provides: liblapack.so.3()(64bit)
%else
Provides: libblas.so.3
Provides: liblapack.so.3
%endif

User level BLAS/LAPACK selection

Environment modules are used to provide user level selection of the desired BLAS/LAPACK implementation. 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.

Consistent LAPACK versions

Most optimized BLAS implementations also offer a subset of optimized LAPACK functions. They must then fill out the rest of the LAPACK API from the reference netlib LAPACK, either via static LAPACK library or a bundled version. The reference LAPACK interface is slowly changing so it is important that the LAPACK API version be consistent across all LAPCK implementations on a specific release. This is most easily handled by linking to the static LAPACK reference library.

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 libblas.so.3 and liblapack.so.3, 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?