(Add system level selection via alternatives.) |
(→BLAS/LAPACK implementations: note that this doesn't work) |
||

Line 21: | Line 21: | ||

= BLAS/LAPACK implementations = | = BLAS/LAPACK implementations = | ||

+ | |||

+ | {{admon/important|This doesn't work. We need to build versions of the libraries with the blas/lapack sonames and symbols.}} | ||

+ | |||

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

## Revision as of 17:10, 10 August 2016

## Contents

# 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 will provide relative symbolic links in %{_libdir}/IMPLEMENTATION-NAME/ of libblas.so.3 and/or liblapack.so.3 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:

%install ... ln -s ../libsatlas.so.3 %{buildroot}%{_libdir}/%{name}-serial/libblas.so.3 ln -s ../libsatlas.so.3 %{buildroot}%{_libdir}/%{name}-serial/liblapack.so.3 ln -s ../libtatlas.so.3 %{buildroot}%{_libdir}/%{name}-threaded/libblas.so.3 ln -s ../libtatlas.so.3 %{buildroot}%{_libdir}/%{name}-threaded/liblapack.so.3

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

%install ... ln -s ../libopenblas64.so.0 %{buildroot}%{_libdir}/%[name}-serial/libblas64.so.3 ln -s ../libopenblas64.so.0 %{buildroot}%{_libdir}/%{name}-serial/liblapack64.so.3 ln -s ../libopenblas64_.so.0 %{buildroot}%{_libdir}/%{name}-serial/libblas64_.so.3 ln -s ../libopenblas64_.so.0 %{buildroot}%{_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?