From Fedora Project Wiki
m (typo)
m (Added feedback and more details)
Line 51: Line 51:


== Feedback ==
== Feedback ==
<!-- Summarize the feedback from the community and address why you chose not to accept proposed alternatives. This section is optional for all change proposals but is strongly suggested. Incorporating feedback here as it is raised gives FESCo a clearer view of your proposal and leaves a good record for the future. If you get no feedback, that is useful to note in this section as well. For innovative or possibly controversial ideas, consider collecting feedback before you file the change proposal. -->


TBD
Some minor comments are directly addressed as modifications to this change proposal. Major comments are discussed below.
 
=== License ===
 
It is noted that FlexiBLAS is licensed as GPLv3 only, which could be incompatible with some packages. Particularly, a quick assessment of the licenses of BLAS/LAPACK-dependent packages reveals that there are some incompatibilities such as BSD with advertising, CeCILL-B, CeCILL-C, CPL and GPLv2 only.
 
However, this is a particular case, because FlexiBLAS replicates the BLAS/LAPACK API on the one hand (which originally is BSD), and exposes another API for management, profiling... This change proposes to link packages to the BLAS/LAPACK API, so FlexiBLAS acts as a wrapper, but it is in no way needed by those packages to function. Besides, the authors of FlexiBLAS are actively sponsoring this change and want to allow and support this use case.
 
Therefore, we asked legal (still waiting for a response) whether FlexiBLAS could be considered an exception as a "system library", as defined in Section 1 of the GPLv3. If not, the authors are willing to add an exception to the license terms (e.g., like the [[Licensing/GPL_Classpath_Exception| Classpath Exception]]) to allow this usage.
 
=== System-wide default ===
 
There seems to be no discussion that OpenBLAS is the best choice nowadays among the backends available in Fedora. However, which specific flavor to choose is a harder question.
 
The OpenBLAS package maintainer thinks that there should be no system-wide default BLAS/LAPACK backend, because "each maintainer needs to be able to pick the correct flavor". Otherwise, "if you use the wrong one, you may seriously handicap
performance". But if there needs to be one, "in my opinion it should be the OpenMP version [of OpenBLAS], since it plays well together with both sequential and OpenMP parallel programs".
 
In the change owner's opinion, there is no best choice for many programs, because many different workloads are possible (e.g., in R, octave... there may be parallelization involved, or not at all...). But even if there really is a best option for a certain program, the maintainer may just not know (as it is clear from other messages in the mailing list thread). Sometimes, upstream recomends a flavor just because they use it for testing, but it may not be the best option (see, e.g., jblas, which recommends ATLAS).
 
Therefore, again in the change owner's opinion, Fedora benefits from having a system-wide default. But if a particular package really needs a particular flavor and there are arguments to avoid users from switching it, then an exception could be granted for that package. Having a sane system-wide default is not incompatible with specific needs by particular maintainers.


== Benefit to Fedora ==
== Benefit to Fedora ==
Line 60: Line 78:
* '''Provides a centralized way of managing the system-wide default''', just by changing a global variable in the FlexiBLAS SPEC.
* '''Provides a centralized way of managing the system-wide default''', just by changing a global variable in the FlexiBLAS SPEC.
* '''Provides sysadmins with tools to manage the system-wide configuration'''. FlexiBLAS ships system-wide configuration files to, e.g., change the default or point to new backends. A CLI tool is also provided to easily manage such configurations.
* '''Provides sysadmins with tools to manage the system-wide configuration'''. FlexiBLAS ships system-wide configuration files to, e.g., change the default or point to new backends. A CLI tool is also provided to easily manage such configurations.
* '''Provides users with tools to switch the backend'''. This can be managed by the same CLI tool too in user mode, and it generates per-user configuration files.
* '''Provides users with tools to switch the backend'''. This can be managed by the same CLI tool too in user mode, and it generates per-user configuration files. Also, the $FLEXIBLAS environment variable overrides the default and thus enables more granularity.  
* '''Provides developers with an API to hook into the BLAS/LAPACK API calls'''. E.g., FlexiBLAS comes with a plugin that enables basic profiling support.
* '''Provides developers with an API to hook into the BLAS/LAPACK API calls'''. E.g., FlexiBLAS comes with a plugin that enables basic profiling support.


Line 80: Line 98:
BLAS/LAPACK-dependent packages should work normally, without any (new) issue. To test the switching capabilities, testers may want to run a BLAS/LAPACK benchmark. There are many out there for different software, but we will describe the workflow for R as an example:
BLAS/LAPACK-dependent packages should work normally, without any (new) issue. To test the switching capabilities, testers may want to run a BLAS/LAPACK benchmark. There are many out there for different software, but we will describe the workflow for R as an example:


* Install R, which requires BLAS/LAPACK for operations with matrices.
# Install R, which requires BLAS/LAPACK for operations with matrices.
* Run any benchmark involving calculations with matrices (e.g., R-benchmark-25.R provided by an R-core member [https://mac.r-project.org/benchmarks here]).
# Run any benchmark involving calculations with matrices (e.g., R-benchmark-25.R provided by an R-core member [https://mac.r-project.org/benchmarks here]).
* Switch to the reference implementation:
# Switch to the reference implementation (with the flexiblas tool or by setting the $FLEXIBLAS environment variable; see the docs).
flexiblas -u default netlib
# Run the benchmark again. Timings should be much worse.
* Run the benchmark again. Timings should be much worse.


== User Experience ==
== User Experience ==
Users will have a new CLI tool, called flexiblas, which will allow them to properly switch the BLAS/LAPACK backend without administrative privileges and any compatibility issues.
Users will have a new CLI tool, called flexiblas (or flexiblas64, for programs using the 64-bit interface), which will allow them to properly switch the BLAS/LAPACK backend without administrative privileges and any compatibility issues. Alternatively, the $FLEXIBLAS environment variable (or $FLEXIBLAS64, for programs using the 64-bit interface) overrides both the system-wide and users defaults, allowing switching the backend for a particular application without changing the defaults.


== Dependencies ==
== Dependencies ==

Revision as of 13:54, 3 July 2020

FlexiBLAS as BLAS/LAPACK manager

Summary

BLAS/LAPACK packages will be compiled against the FlexiBLAS wrapper library, which will set OpenBLAS as system-wide default backend, and at the same time will provide a proper switching mechanism that currently Fedora lacks.

Owner

Current status

  • Targeted release: Fedora 33
  • Last updated: 2020-07-03
  • FESCo issue: <will be assigned by the Wrangler>
  • Tracker bug: <will be assigned by the Wrangler>
  • Release notes tracker: <will be assigned by the Wrangler>

Detailed Description

BLAS and LAPACK are API standards for basic linear algebra operations (such as vector and matrix multiplication). Fedora packages the reference implementation from Netlib as well as several optimized backends, such as ATLAS, BLIS and OpenBLAS. Historically, there have been two unresolved issues regarding this API:

  1. Fedora lacks a system-wide default. Due to implementation differences, it is important that all components of a particular software stack link to the same BLAS/LAPACK implementation. Although there have been efforts to standardize OpenBLAS as a system-wide default, they are incomplete.
  2. Fedora lacks a proper switching mechanism. Different implementations work differently depending on the workload, but also depending on whether the consumer of this API implements some kind of parallelization, for instance. Therefore, users may want to choose a particular implementation that works best for them at run time. Mechanisms such as update-alternatives and modules have been discussed in the past, but were considered improper (the former) or faced technical issues (the latter).

This change proposal aims to solve both issues at the same time with minimal changes and minimal impact by using FlexiBLAS.

FlexiBLAS is a framework that wraps the BLAS/LAPACK API with interfaces for both 32- and 64-bit integers. It provides runtime exchangeable backends without recompilation, with a transparent fallback mechanism to Netlib's reference implementation if a certain symbol is not present in the selected backend. It also supports flexible per-system/user/host configuration files and basic profiling.

Therefore, this change proposal requires:

  1. Recompilation of all BLAS/LAPACK-dependent packages linking against FlexiBLAS instead of the current implementation they are using (just changing a BuildRequires line should be sufficient in most cases, unless a SPEC has something hardcoded somewhere else).
  2. Changing the packaging guidelines to reflect this new requirement for BLAS/LAPACK consumers (there is a draft already).

In this way, all the BLAS/LAPACK-dependent packages will automatically use the system-wide default backend, set and centralized in the FlexiBLAS SPEC, and will benefit from the straightforward switching mechanism that FlexiBLAS provides.

Feedback

Some minor comments are directly addressed as modifications to this change proposal. Major comments are discussed below.

License

It is noted that FlexiBLAS is licensed as GPLv3 only, which could be incompatible with some packages. Particularly, a quick assessment of the licenses of BLAS/LAPACK-dependent packages reveals that there are some incompatibilities such as BSD with advertising, CeCILL-B, CeCILL-C, CPL and GPLv2 only.

However, this is a particular case, because FlexiBLAS replicates the BLAS/LAPACK API on the one hand (which originally is BSD), and exposes another API for management, profiling... This change proposes to link packages to the BLAS/LAPACK API, so FlexiBLAS acts as a wrapper, but it is in no way needed by those packages to function. Besides, the authors of FlexiBLAS are actively sponsoring this change and want to allow and support this use case.

Therefore, we asked legal (still waiting for a response) whether FlexiBLAS could be considered an exception as a "system library", as defined in Section 1 of the GPLv3. If not, the authors are willing to add an exception to the license terms (e.g., like the Classpath Exception) to allow this usage.

System-wide default

There seems to be no discussion that OpenBLAS is the best choice nowadays among the backends available in Fedora. However, which specific flavor to choose is a harder question.

The OpenBLAS package maintainer thinks that there should be no system-wide default BLAS/LAPACK backend, because "each maintainer needs to be able to pick the correct flavor". Otherwise, "if you use the wrong one, you may seriously handicap performance". But if there needs to be one, "in my opinion it should be the OpenMP version [of OpenBLAS], since it plays well together with both sequential and OpenMP parallel programs".

In the change owner's opinion, there is no best choice for many programs, because many different workloads are possible (e.g., in R, octave... there may be parallelization involved, or not at all...). But even if there really is a best option for a certain program, the maintainer may just not know (as it is clear from other messages in the mailing list thread). Sometimes, upstream recomends a flavor just because they use it for testing, but it may not be the best option (see, e.g., jblas, which recommends ATLAS).

Therefore, again in the change owner's opinion, Fedora benefits from having a system-wide default. But if a particular package really needs a particular flavor and there are arguments to avoid users from switching it, then an exception could be granted for that package. Having a sane system-wide default is not incompatible with specific needs by particular maintainers.

Benefit to Fedora

  • Packaging of BLAS/LAPACK-dependent packages will be easier and safer. FlexiBLAS is 100% compatible with the reference API. It uses optimized symbols that are present in the selected backend and transparently falls back to Netlib for the missing ones, so compatibility is always guaranteed.
  • Provides a centralized way of managing the system-wide default, just by changing a global variable in the FlexiBLAS SPEC.
  • Provides sysadmins with tools to manage the system-wide configuration. FlexiBLAS ships system-wide configuration files to, e.g., change the default or point to new backends. A CLI tool is also provided to easily manage such configurations.
  • Provides users with tools to switch the backend. This can be managed by the same CLI tool too in user mode, and it generates per-user configuration files. Also, the $FLEXIBLAS environment variable overrides the default and thus enables more granularity.
  • Provides developers with an API to hook into the BLAS/LAPACK API calls. E.g., FlexiBLAS comes with a plugin that enables basic profiling support.

Scope

  • Proposal owners: Modify the SPECs of the BLAS/LAPACK-dependent packages to build against FlexiBLAS instead of the current backend they are using.
  • Other developers: Maintainers of the affected packages need to merge the changes and rebuild. Alternatively, a provenpackager could help with this process (it's 30-40 packages).
  • Release engineering: N/A (not needed for this Change)
  • Policies and guidelines: #995 Package guidelines should be updated to require BLAS/LAPACK-dependent packages to link against FlexiBLAS.
  • Trademark approval: N/A (not needed for this Change)

Upgrade/compatibility impact

There is no upgrade/compatibility impact.

How To Test

BLAS/LAPACK-dependent packages should work normally, without any (new) issue. To test the switching capabilities, testers may want to run a BLAS/LAPACK benchmark. There are many out there for different software, but we will describe the workflow for R as an example:

  1. Install R, which requires BLAS/LAPACK for operations with matrices.
  2. Run any benchmark involving calculations with matrices (e.g., R-benchmark-25.R provided by an R-core member here).
  3. Switch to the reference implementation (with the flexiblas tool or by setting the $FLEXIBLAS environment variable; see the docs).
  4. Run the benchmark again. Timings should be much worse.

User Experience

Users will have a new CLI tool, called flexiblas (or flexiblas64, for programs using the 64-bit interface), which will allow them to properly switch the BLAS/LAPACK backend without administrative privileges and any compatibility issues. Alternatively, the $FLEXIBLAS environment variable (or $FLEXIBLAS64, for programs using the 64-bit interface) overrides both the system-wide and users defaults, allowing switching the backend for a particular application without changing the defaults.

Dependencies

Packages depedent on the BLAS/LAPACK API will depend on FlexiBLAS after this change. Maintainers of those packages are required to collaborate to change their BuildRequires or, alternatively, this can be done with the help of a provenpackager.

Contingency Plan

  • Contingency mechanism: Revert BLAS/LAPACK-dependent packages to their prior BuildRequires and rebuild them.
  • Contingency deadline: Beta freeze.
  • Blocks release? No.
  • Blocks product? No.

Documentation

See the README of the upstream project and their homepage for further information about FlexiBLAS.

Release Notes

TBD