doc/UsingBlasLapackBackends.dox

/*
 Copyright (c) 2011, Intel Corporation. All rights reserved.
 Copyright (C) 2011-2016 Gael Guennebaud <gael.guennebaud@inria.fr>

 Redistribution and use in source and binary forms, with or without modification,
 are permitted provided that the following conditions are met:

 * Redistributions of source code must retain the above copyright notice, this
   list of conditions and the following disclaimer.
 * Redistributions in binary form must reproduce the above copyright notice,
   this list of conditions and the following disclaimer in the documentation
   and/or other materials provided with the distribution.
 * Neither the name of Intel Corporation nor the names of its contributors may
   be used to endorse or promote products derived from this software without
   specific prior written permission.

 THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND
 ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
 WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
 DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR
 ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
 (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
 LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON
 ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
 (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
 SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

 ********************************************************************************
 *   Content : Documentation on the use of BLAS/LAPACK libraries through Eigen
 ********************************************************************************
*/

namespace Eigen {

/** \page TopicUsingBlasLapack Using BLAS/LAPACK from %Eigen


Since %Eigen version 3.3 and later, any F77 compatible BLAS or LAPACK libraries can be used as backends for dense matrix products and dense matrix decompositions.
For instance, one can use <a href="https://www.intel.com/content/www/us/en/developer/tools/oneapi/onemkl.html">Intel® oneMKL</a>, Apple's Accelerate framework on macOS, <a href="http://www.openblas.net/">OpenBLAS</a>, <a href="http://www.netlib.org/lapack">Netlib LAPACK</a>, etc.

Do not miss this \link TopicUsingIntelMKL page \endlink for further discussions on the specific use of Intel® MKL (also includes VML, PARDISO, etc.)

In order to use an external BLAS and/or LAPACK library, you must link your own application to the respective libraries and their dependencies.
For LAPACK, you must also link to the standard <a href="http://www.netlib.org/lapack/lapacke.html">Lapacke</a> library, which is used as a convenient thin layer between %Eigen's C++ code and LAPACK F77 interface. Then you must activate their usage by defining one or multiple of the following macros (\b before including any %Eigen's header):

\note For Mac users, in order to use the lapack version shipped with the Accelerate framework, you also need the lapacke library.
Using <a href="https://www.macports.org/">MacPorts</a>, this is as easy as:
\code
sudo port install lapack
\endcode
and then use the following link flags: \c -framework \c Accelerate \c /opt/local/lib/lapack/liblapacke.dylib

<table class="manual">
<tr><td>\c EIGEN_USE_BLAS </td><td>Enables the use of external BLAS level 2 and 3 routines (compatible with any F77 BLAS interface)</td></tr>
<tr class="alt"><td>\c EIGEN_USE_LAPACKE </td><td>Enables the use of external Lapack routines via the <a href="http://www.netlib.org/lapack/lapacke.html">Lapacke</a> C interface to Lapack (compatible with any F77 LAPACK interface)</td></tr>
<tr><td>\c EIGEN_USE_LAPACKE_STRICT </td><td>Same as \c EIGEN_USE_LAPACKE but algorithms of lower numerical robustness are disabled. \n This currently concerns only JacobiSVD which otherwise would be replaced by \c gesvd that is less robust than Jacobi rotations.</td></tr>
<tr class="alt"><td>\c EIGEN_64BIT_BLAS </td><td>Selects the 64-bit integer ("ILP64") BLAS interface instead of the default 32-bit ("LP64") one. See \ref TopicUsingBlasLapack_ILP64 below.</td></tr>
<tr><td>\c EIGEN_BLAS_SYMBOL_SUFFIX </td><td>Suffix of the external BLAS symbol names, for ILP64 libraries that decorate them; e.g. \c _64 selects \c dgemm_64_ instead of \c dgemm_. See \ref TopicUsingBlasLapack_ILP64 below.</td></tr>
</table>

When doing so, a number of %Eigen's algorithms are silently substituted with calls to BLAS or LAPACK routines.
These substitutions apply only for \b Dynamic \b or \b large enough objects with one of the following four standard scalar types: \c float, \c double, \c complex<float>, and \c complex<double>.
Operations on other scalar types or mixing reals and complexes will continue to use the built-in algorithms.

The breadth of %Eigen functionality that can be substituted is listed in the table below.
<table class="manual">
<tr><th>Functional domain</th><th>Code example</th><th>BLAS/LAPACK routines</th></tr>
<tr><td>Matrix-matrix operations \n \c EIGEN_USE_BLAS </td><td>\code
m1*m2.transpose();
m1.selfadjointView<Lower>()*m2;
m1*m2.triangularView<Upper>();
m1.selfadjointView<Lower>().rankUpdate(m2,1.0);
\endcode</td><td>\code
?gemm
?symm/?hemm
?trmm
dsyrk/ssyrk
\endcode</td></tr>
<tr class="alt"><td>Matrix-vector operations \n \c EIGEN_USE_BLAS </td><td>\code
m1.adjoint()*b;
m1.selfadjointView<Lower>()*b;
m1.triangularView<Upper>()*b;
\endcode</td><td>\code
?gemv
?symv/?hemv
?trmv
\endcode</td></tr>
<tr><td>LU decomposition \n \c EIGEN_USE_LAPACKE \n \c EIGEN_USE_LAPACKE_STRICT </td><td>\code
v1 = m1.lu().solve(v2);
\endcode</td><td>\code
?getrf
\endcode</td></tr>
<tr class="alt"><td>Cholesky decomposition \n \c EIGEN_USE_LAPACKE \n \c EIGEN_USE_LAPACKE_STRICT </td><td>\code
v1 = m2.selfadjointView<Upper>().llt().solve(v2);
\endcode</td><td>\code
?potrf
\endcode</td></tr>
<tr><td>QR decomposition \n \c EIGEN_USE_LAPACKE \n \c EIGEN_USE_LAPACKE_STRICT </td><td>\code
m1.householderQr();
m1.colPivHouseholderQr();
\endcode</td><td>\code
?geqrf
?geqp3
\endcode</td></tr>
<tr class="alt"><td>Singular value decomposition \n \c EIGEN_USE_LAPACKE </td><td>\code
JacobiSVD<MatrixXd, ComputeThinV> svd;
svd.compute(m1);
\endcode</td><td>\code
?gesvd
\endcode</td></tr>
<tr class="alt"><td>Singular value decomposition \n \c EIGEN_USE_LAPACKE \n \c EIGEN_USE_LAPACKE_STRICT </td><td>\code
BDCSVD<MatrixXd> svd;
svd.compute(m1);
\endcode</td><td>\code
?gesdd
\endcode</td></tr>
<tr><td>Eigen-value decompositions \n \c EIGEN_USE_LAPACKE \n \c EIGEN_USE_LAPACKE_STRICT </td><td>\code
EigenSolver<MatrixXd> es(m1);
ComplexEigenSolver<MatrixXcd> ces(m1);
SelfAdjointEigenSolver<MatrixXd> saes(m1+m1.transpose());
GeneralizedSelfAdjointEigenSolver<MatrixXd>
    gsaes(m1+m1.transpose(),m2+m2.transpose());
\endcode</td><td>\code
?gees
?gees
?syev/?heev
?syev/?heev,
?potrf
\endcode</td></tr>
<tr class="alt"><td>Schur decomposition \n \c EIGEN_USE_LAPACKE \n \c EIGEN_USE_LAPACKE_STRICT </td><td>\code
RealSchur<MatrixXd> schurR(m1);
ComplexSchur<MatrixXcd> schurC(m1);
\endcode</td><td>\code
?gees
\endcode</td></tr>
</table>
In the examples, m1 and m2 are dense matrices and v1 and v2 are dense vectors.

\section TopicUsingBlasLapack_ILP64 The 64-bit integer (ILP64) interface

By default %Eigen calls the 32-bit integer ("LP64") BLAS interface, which limits matrix dimensions and strides to
2<sup>31</sup>-1. Define \c EIGEN_64BIT_BLAS to call the 64-bit integer ("ILP64") interface instead. ILP64 libraries
come in two flavours, and they differ in how the symbols are named rather than only in the integer width:

<table class="manual">
<tr><th>Flavour</th><th>Symbol</th><th>Example</th><th>%Eigen configuration</th></tr>
<tr><td>Separate ILP64 library, undecorated names</td><td>\c dgemm_ </td>
    <td>oneMKL \c *_ilp64, OpenBLAS \c INTERFACE64=1 </td><td>\c EIGEN_64BIT_BLAS </td></tr>
<tr class="alt"><td>Decorated names, may coexist with LP64 in one library</td><td>\c dgemm_64_ </td>
    <td>Netlib LAPACK \c BUILD_INDEX64_EXT_API, oneMKL >= 2025, OpenBLAS \c SYMBOLSUFFIX=64_ </td>
    <td>\c EIGEN_64BIT_BLAS and \c EIGEN_BLAS_SYMBOL_SUFFIX=_64 </td></tr>
</table>

With Intel® MKL, \c EIGEN_64BIT_BLAS must agree with \c MKL_ILP64; %Eigen checks this at compile time.

\warning \c EIGEN_64BIT_BLAS is ABI-affecting: it changes the integer type %Eigen passes to BLAS, so it must be
defined consistently for every translation unit linked into your program. Prefer setting it on the compile line
(for example through a CMake target) rather than \c \#define -ing it in individual sources.

\warning %Eigen cannot detect a mismatch between \c EIGEN_64BIT_BLAS and the library you actually link, except for
Intel® MKL. Fortran BLAS passes every dimension by pointer, so a width mismatch is invisible to both the compiler
and the linker. Getting it wrong corrupts arguments at run time: calling an ILP64 library without
\c EIGEN_64BIT_BLAS fails immediately with nonsense dimensions, while the reverse tends to appear to work on
little-endian machines until a dimension exceeds 2<sup>31</sup>. Since no build-time check is possible, verify the
combination by running a product against the library you actually ship. %Eigen's test suite does this from CMake;
see \c eigen_check_external_blas_integer_size in \c test/CMakeLists.txt for a probe you can adapt.

*/

}