For a general introduction to the BLAS routines, please refer to the extensive documentation of their reference implementation hosted at netlib:
https://www.netlib.org/blas. On that site you will likewise find documentation for the reference implementation of the higher-level library LAPACK - the Linear Algebra Package that comes included with OpenBLAS. If you are looking for a general primer or refresher on Linear Algebra, the set of six
20-minute lecture videos by Prof. Gilbert Strang on either MIT OpenCourseWare here or YouTube here may be helpful.
Binary Packages
We provide official binary packages for the following platform:
Obtain the source code from https://github.com/OpenMathLib/OpenBLAS/. Note that the default branch
is develop (a master branch is still present, but far out of date).
Build-time parameters can be chosen in Makefile.rule, see there for a short description of each option.
Most options can also be given directly on the command line as parameters to your make or cmake invocation.
Dependencies
Building OpenBLAS requires the following to be installed:
GNU Make or CMake
A C compiler, e.g. GCC or Clang
A Fortran compiler (optional, for LAPACK)
In general, using a recent version of the compiler is strongly recommended.
If a Fortran compiler is not available, it is possible to compile an older version of the included LAPACK
that has been machine-translated to C.
Normal compile
Simply invoking make (or gmake on BSD) will detect the CPU automatically.
To set a specific target CPU, use make TARGET=xxx, e.g. make TARGET=NEHALEM.
The full target list is in the file TargetList.txt, other build optionss are documented in Makefile.rule and
can either be set there (typically by removing the comment character from the respective line), or used on the
make command line.
Note that when you run make install after building, you need to repeat all command line options you provided to make
in the build step, as some settings like the supported maximum number of threads are automatically derived from the
build host by default, which might not be what you want.
For building with cmake, the usual conventions apply, i.e. create a build directory either underneath the toplevel
OpenBLAS source directory or separate from it, and invoke cmake there with the path to the source tree and any
build options you plan to set.
Set CC and FC to point to the cross toolchains, and if you use make, also set HOSTCC to your host C compiler.
The target must be specified explicitly when cross compiling.
Examples:
On a Linux system, cross-compiling to an older MIPS64 router board:
make BINARY=64 CC=mipsisa64r6el-linux-gnuabi64-gcc FC=mipsisa64r6el-linux-gnuabi64-gfortran HOSTCC=gcc TARGET=P6600
You can find instructions for other cases both in the “Supported Systems” section below and in
the Building from source docs.
The .yml scripts included with the sources (which contain the
build scripts for the “continuous integration” (CI) build tests automatically run on every proposed change to the sources) may also provide additional hints.
When compiling for a more modern CPU target of the same architecture, e.g. TARGET=SKYLAKEX on a HASWELL host, option CROSS=1 can be used to suppress the automatic invocation of the tests at the end of the build.
Debug version
A debug version can be built using make DEBUG=1.
Compile with MASS support on Power CPU (optional)
The IBM MASS library consists of a set of mathematical functions for C, C++, and Fortran applications that are tuned for optimum performance on POWER architectures.
OpenBLAS with MASS requires a 64-bit, little-endian OS on POWER.
The library can be installed as shown:
After installing the MASS library, compile OpenBLAS with USE_MASS=1.
For example, to compile on Power8 with MASS support: make USE_MASS=1 TARGET=POWER8.
Install to a specific directory (optional)
Use PREFIX= when invoking make, for example
make install PREFIX=your_installation_directory
(along with all options you added on the make command line in the preceding build step)
The default installation directory is /opt/OpenBLAS.
Supported CPUs and Operating Systems
Please read GotoBLAS_01Readme.txt for older CPU models already supported by the 2010 GotoBLAS.
Additional supported CPUs
x86/x86-64
Intel Xeon 56xx (Westmere): Used GotoBLAS2 Nehalem codes.
Intel Sandy Bridge: Optimized Level-3 and Level-2 BLAS with AVX on x86-64.
Intel Haswell: Optimized Level-3 and Level-2 BLAS with AVX2 and FMA on x86-64.
Intel Skylake-X: Optimized Level-3 and Level-2 BLAS with AVX512 and FMA on x86-64.
Intel Cooper Lake: as Skylake-X with improved BFLOAT16 support.
AMD Bobcat: Used GotoBLAS2 Barcelona codes.
AMD Bulldozer: x86-64 ?GEMM FMA4 kernels. (Thanks to Werner Saar)
AMD PILEDRIVER: Uses Bulldozer codes with some optimizations.
AMD STEAMROLLER: Uses Bulldozer codes with some optimizations.
AMD ZEN: Uses Haswell codes with some optimizations for Zen 2/3 (use SkylakeX for Zen4)
MIPS32
MIPS 1004K: uses P5600 codes
MIPS 24K: uses P5600 codes
MIPS64
ICT Loongson 3A: Optimized Level-3 BLAS and the part of Level-1,2.
ICT Loongson 3B: Experimental
ARM
ARMv6: Optimized BLAS for vfpv2 and vfpv3-d16 (e.g. BCM2835, Cortex M0+)
ARMv7: Optimized BLAS for vfpv3-d32 (e.g. Cortex A8, A9 and A15)
ARM64
ARMv8: Basic ARMV8 with small caches, optimized Level-3 and Level-2 BLAS
Cortex-A53: same as ARMV8 (different cpu specifications)
Cortex-A55: same as ARMV8 (different cpu specifications)
Cortex A57: Optimized Level-3 and Level-2 functions
Cortex A72: same as A57 ( different cpu specifications)
Cortex A73: same as A57 (different cpu specifications)
Cortex A76: same as A57 (different cpu specifications)
Falkor: same as A57 (different cpu specifications)
ThunderX: Optimized some Level-1 functions
ThunderX2T99: Optimized Level-3 BLAS and parts of Levels 1 and 2
POWER8: Optimized BLAS, only for PPC64LE (Little Endian), only with USE_OPENMP=1
POWER9: Optimized Level-3 BLAS (real) and some Level-1,2. PPC64LE with OpenMP only.
POWER10: Optimized Level-3 BLAS including SBGEMM and some Level-1,2.
AIX: Dynamic architecture with OpenXL and OpenMP.
make CC=ibm-clang_r FC=xlf_r TARGET=POWER7 BINARY=64 USE_OPENMP=1 INTERFACE64=1 DYNAMIC_ARCH=1 USE_THREAD=1
IBM zEnterprise System
Z13: Optimized Level-3 BLAS and Level-1,2
Z14: Optimized Level-3 BLAS and (single precision) Level-1,2
RISC-V
C910V: Optimized Level-3 BLAS (real) and Level-1,2 by RISC-V Vector extension 0.7.1.
make HOSTCC=gcc TARGET=C910V CC=riscv64-unknown-linux-gnu-gcc FC=riscv64-unknown-linux-gnu-gfortran
(also known to work on C906 as long as you use only single-precision functions - its instruction set support appears to be incomplete in double precision)
x280: Level-3 BLAS and Level-1,2 are optimized by RISC-V Vector extension 1.0.
make HOSTCC=gcc TARGET=x280 NUM_THREADS=8 CC=riscv64-unknown-linux-gnu-clang FC=riscv64-unknown-linux-gnu-gfortran
ZVL???B: Level-3 BLAS and Level-1,2 including vectorised kernels targeting generic RISCV cores with vector support with registers of at least the corresponding width; ZVL128B and ZVL256B are available.
e.g.:
LA64_GENERIC: Optimized Level-3, Level-2 and Level-1 BLAS with scalar instruction
make HOSTCC=gcc TARGET=LA64_GENERIC CC=loongarch64-unknown-linux-gnu-gcc FC=loongarch64-unknown-linux-gnu-gfortran USE_SIMPLE_THREADED_LEVEL3=1
The old-style TARGET=LOONGSONGENERIC is still supported
LA264: Optimized Level-3, Level-2 and Level-1 BLAS with LSX instruction
make HOSTCC=gcc TARGET=LA264 CC=loongarch64-unknown-linux-gnu-gcc FC=loongarch64-unknown-linux-gnu-gfortran USE_SIMPLE_THREADED_LEVEL3=1
The old-style TARGET=LOONGSON2K1000 is still supported
LA464: Optimized Level-3, Level-2 and Level-1 BLAS with LASX instruction
make HOSTCC=gcc TARGET=LA464 CC=loongarch64-unknown-linux-gnu-gcc FC=loongarch64-unknown-linux-gnu-gfortran USE_SIMPLE_THREADED_LEVEL3=1
The old-style TARGET=LOONGSON3R5 is still supported
Support for multiple targets in a single library
OpenBLAS can be built for multiple targets with runtime detection of the target cpu by specifiying DYNAMIC_ARCH=1 in Makefile.rule, on the gmake command line or as -DDYNAMIC_ARCH=TRUE in cmake.
For x86_64, the list of targets this activates contains Prescott, Core2, Nehalem, Barcelona, Sandybridge, Bulldozer, Piledriver, Steamroller, Excavator, Haswell, Zen, SkylakeX, Cooper Lake, Sapphire Rapids. For cpu generations not included in this list, the corresponding older model is used. If you also specify DYNAMIC_OLDER=1, specific support for Penryn, Dunnington, Opteron, Opteron/SSE3, Bobcat, Atom and Nano is added. Finally there is an option DYNAMIC_LIST that allows to specify an individual list of targets to include instead of the default.
DYNAMIC_ARCH is also supported on x86, where it translates to Katmai, Coppermine, Northwood, Prescott, Banias,
Core2, Penryn, Dunnington, Nehalem, Athlon, Opteron, Opteron_SSE3, Barcelona, Bobcat, Atom and Nano.
On ARMV8, it enables support for CortexA53, CortexA57, CortexA72, CortexA73, Falkor, ThunderX, ThunderX2T99, TSV110 as well as generic ARMV8 cpus. If compiler support for SVE is available at build time, support for NeoverseN2, NeoverseV1 as well as generic ArmV8SVE targets is also enabled.
For POWER, the list encompasses POWER6, POWER8 and POWER9. POWER10 is additionally available if a sufficiently recent compiler is used for the build.
on ZARCH it comprises Z13 and Z14 as well as generic zarch support.
On riscv64, DYNAMIC_ARCH enables support for riscv64_zvl128b and riscv64_zvl256b in addition to generic riscv64 support. A compiler that supports RVV 1.0 is required to build OpenBLAS for riscv64 when DYNAMIC_ARCH is enabled.
On LoongArch64, it comprises LA264 and LA464 as well as generic LoongArch64 support.
The TARGET option can - and usually should - be used in conjunction with DYNAMIC_ARCH=1 to specify which cpu model should be assumed for all the common code in the library, usually you will want to set this to the oldest model you expect to encounter.
Failure to specify this may lead to advanced instructions being used by the compiler, just because the build host happens to support them. This is most likely to happen when aggressive optimization options are in effect, and the resulting library may then crash with an
illegal instruction error on weaker hardware, before it even reaches the BLAS routines specifically included for that cpu.
Please note that it is not possible to combine support for different architectures, so no combined 32 and 64 bit or x86_64 and arm64 in the same library.
The priorities are OPENBLAS_NUM_THREADS > GOTO_NUM_THREADS > OMP_NUM_THREADS.
If you compile this library with USE_OPENMP=1, you should set the OMP_NUM_THREADS
environment variable; OpenBLAS ignores OPENBLAS_NUM_THREADS and GOTO_NUM_THREADS when
compiled with USE_OPENMP=1.
Setting the number of threads at runtime
We provide the following functions to control the number of threads at runtime:
Note that these are only used once at library initialization, and are not available for
fine-tuning thread numbers in individual BLAS calls.
If you compile this library with USE_OPENMP=1, you should use the above functions too.
Please use GCC version 4.6 and above to compile Sandy Bridge AVX kernels on Linux/MinGW/BSD.
Please use Clang version 3.1 and above to compile the library on Sandy Bridge microarchitecture.
Clang 3.0 will generate the wrong AVX binary code.
Please use GCC version 6 or LLVM version 6 and above to compile Skylake/CooperLake AVX512 kernels
Please use LLVM version 18 and above (version 19 and above on Windows) if you plan to use
its new flang compiler for Fortran
Please use GCC version 11 and above to compile OpenBLAS on the POWER architecture
The number of CPUs/cores should be less than or equal to 256. On Linux x86_64 (amd64),
there is experimental support for up to 1024 CPUs/cores and 128 numa nodes if you build
the library with BIGNUMA=1.
OpenBLAS does not set processor affinity by default.
On Linux, you can enable processor affinity by commenting out the line NO_AFFINITY=1 in
Makefile.rule. However, note that this may cause
a conflict with R parallel.
On Loongson 3A, make test may fail with a pthread_create error (EAGAIN).
However, it will be okay when you run the same test case on the shell.
Contributing
Check for open issues or open a fresh issue
to start a discussion around a feature idea or a bug.
Fork the OpenBLAS repository to start making your changes.
Write a test which shows that the bug was fixed or that the feature works as expected.
Send a pull request. Make sure to add yourself to CONTRIBUTORS.md.
OpenBLAS
Cirrus CI:
OSUOSL POWERCI
OSUOSL IBMZ-CI
Introduction
OpenBLAS is an optimized BLAS (Basic Linear Algebra Subprograms) library based on GotoBLAS2 1.13 BSD version.
For more information about OpenBLAS, please see:
For a general introduction to the BLAS routines, please refer to the extensive documentation of their reference implementation hosted at netlib: https://www.netlib.org/blas. On that site you will likewise find documentation for the reference implementation of the higher-level library LAPACK - the Linear Algebra Package that comes included with OpenBLAS. If you are looking for a general primer or refresher on Linear Algebra, the set of six 20-minute lecture videos by Prof. Gilbert Strang on either MIT OpenCourseWare here or YouTube here may be helpful.
Binary Packages
We provide official binary packages for the following platform:
You can download them from file hosting on sourceforge.net or from the Releases section of the GitHub project page.
OpenBLAS is also packaged for many package managers - see the installation section of the docs for details.
Installation from Source
Obtain the source code from https://github.com/OpenMathLib/OpenBLAS/. Note that the default branch is
develop
(amaster
branch is still present, but far out of date).Build-time parameters can be chosen in
Makefile.rule
, see there for a short description of each option. Most options can also be given directly on the command line as parameters to yourmake
orcmake
invocation.Dependencies
Building OpenBLAS requires the following to be installed:
In general, using a recent version of the compiler is strongly recommended. If a Fortran compiler is not available, it is possible to compile an older version of the included LAPACK that has been machine-translated to C.
Normal compile
Simply invoking
make
(orgmake
on BSD) will detect the CPU automatically. To set a specific target CPU, usemake TARGET=xxx
, e.g.make TARGET=NEHALEM
. The full target list is in the fileTargetList.txt
, other build optionss are documented in Makefile.rule and can either be set there (typically by removing the comment character from the respective line), or used on themake
command line. Note that when you runmake install
after building, you need to repeat all command line options you provided tomake
in the build step, as some settings like the supported maximum number of threads are automatically derived from the build host by default, which might not be what you want. For building withcmake
, the usual conventions apply, i.e. create a build directory either underneath the toplevel OpenBLAS source directory or separate from it, and invokecmake
there with the path to the source tree and any build options you plan to set.For more details, see the Building from source section in the docs.
Cross compile
Set
CC
andFC
to point to the cross toolchains, and if you usemake
, also setHOSTCC
to your host C compiler. The target must be specified explicitly when cross compiling.Examples:
You can find instructions for other cases both in the “Supported Systems” section below and in the Building from source docs. The
.yml
scripts included with the sources (which contain the build scripts for the “continuous integration” (CI) build tests automatically run on every proposed change to the sources) may also provide additional hints.When compiling for a more modern CPU target of the same architecture, e.g.
TARGET=SKYLAKEX
on aHASWELL
host, optionCROSS=1
can be used to suppress the automatic invocation of the tests at the end of the build.Debug version
A debug version can be built using
make DEBUG=1
.Compile with MASS support on Power CPU (optional)
The IBM MASS library consists of a set of mathematical functions for C, C++, and Fortran applications that are tuned for optimum performance on POWER architectures. OpenBLAS with MASS requires a 64-bit, little-endian OS on POWER. The library can be installed as shown:
On Ubuntu:
On RHEL/CentOS:
After installing the MASS library, compile OpenBLAS with
USE_MASS=1
. For example, to compile on Power8 with MASS support:make USE_MASS=1 TARGET=POWER8
.Install to a specific directory (optional)
Use
PREFIX=
when invokingmake
, for example(along with all options you added on the
make
command line in the preceding build step) The default installation directory is/opt/OpenBLAS
.Supported CPUs and Operating Systems
Please read
GotoBLAS_01Readme.txt
for older CPU models already supported by the 2010 GotoBLAS.Additional supported CPUs
x86/x86-64
MIPS32
MIPS64
ARM
ARM64
PPC/PPC64
POWER8: Optimized BLAS, only for PPC64LE (Little Endian), only with
USE_OPENMP=1
POWER9: Optimized Level-3 BLAS (real) and some Level-1,2. PPC64LE with OpenMP only.
POWER10: Optimized Level-3 BLAS including SBGEMM and some Level-1,2.
AIX: Dynamic architecture with OpenXL and OpenMP.
IBM zEnterprise System
RISC-V
C910V: Optimized Level-3 BLAS (real) and Level-1,2 by RISC-V Vector extension 0.7.1.
(also known to work on C906 as long as you use only single-precision functions - its instruction set support appears to be incomplete in double precision)
x280: Level-3 BLAS and Level-1,2 are optimized by RISC-V Vector extension 1.0.
ZVL???B: Level-3 BLAS and Level-1,2 including vectorised kernels targeting generic RISCV cores with vector support with registers of at least the corresponding width; ZVL128B and ZVL256B are available. e.g.:
LOONGARCH64
LA64_GENERIC: Optimized Level-3, Level-2 and Level-1 BLAS with scalar instruction
The old-style TARGET=LOONGSONGENERIC is still supported
LA264: Optimized Level-3, Level-2 and Level-1 BLAS with LSX instruction
The old-style TARGET=LOONGSON2K1000 is still supported
LA464: Optimized Level-3, Level-2 and Level-1 BLAS with LASX instruction
The old-style TARGET=LOONGSON3R5 is still supported
Support for multiple targets in a single library
OpenBLAS can be built for multiple targets with runtime detection of the target cpu by specifiying
DYNAMIC_ARCH=1
in Makefile.rule, on the gmake command line or as-DDYNAMIC_ARCH=TRUE
in cmake.For x86_64, the list of targets this activates contains Prescott, Core2, Nehalem, Barcelona, Sandybridge, Bulldozer, Piledriver, Steamroller, Excavator, Haswell, Zen, SkylakeX, Cooper Lake, Sapphire Rapids. For cpu generations not included in this list, the corresponding older model is used. If you also specify
DYNAMIC_OLDER=1
, specific support for Penryn, Dunnington, Opteron, Opteron/SSE3, Bobcat, Atom and Nano is added. Finally there is an optionDYNAMIC_LIST
that allows to specify an individual list of targets to include instead of the default.DYNAMIC_ARCH
is also supported on x86, where it translates to Katmai, Coppermine, Northwood, Prescott, Banias, Core2, Penryn, Dunnington, Nehalem, Athlon, Opteron, Opteron_SSE3, Barcelona, Bobcat, Atom and Nano.On ARMV8, it enables support for CortexA53, CortexA57, CortexA72, CortexA73, Falkor, ThunderX, ThunderX2T99, TSV110 as well as generic ARMV8 cpus. If compiler support for SVE is available at build time, support for NeoverseN2, NeoverseV1 as well as generic ArmV8SVE targets is also enabled.
For POWER, the list encompasses POWER6, POWER8 and POWER9. POWER10 is additionally available if a sufficiently recent compiler is used for the build.
on ZARCH it comprises Z13 and Z14 as well as generic zarch support.
On riscv64, DYNAMIC_ARCH enables support for riscv64_zvl128b and riscv64_zvl256b in addition to generic riscv64 support. A compiler that supports RVV 1.0 is required to build OpenBLAS for riscv64 when DYNAMIC_ARCH is enabled.
On LoongArch64, it comprises LA264 and LA464 as well as generic LoongArch64 support.
The
TARGET
option can - and usually should - be used in conjunction withDYNAMIC_ARCH=1
to specify which cpu model should be assumed for all the common code in the library, usually you will want to set this to the oldest model you expect to encounter. Failure to specify this may lead to advanced instructions being used by the compiler, just because the build host happens to support them. This is most likely to happen when aggressive optimization options are in effect, and the resulting library may then crash with an illegal instruction error on weaker hardware, before it even reaches the BLAS routines specifically included for that cpu.Please note that it is not possible to combine support for different architectures, so no combined 32 and 64 bit or x86_64 and arm64 in the same library.
Supported OS
Usage
Statically link with
libopenblas.a
or dynamically link with-lopenblas
if OpenBLAS was compiled as a shared library.Setting the number of threads using environment variables
Environment variables are used to specify a maximum number of threads. For example,
The priorities are
OPENBLAS_NUM_THREADS
>GOTO_NUM_THREADS
>OMP_NUM_THREADS
.If you compile this library with
USE_OPENMP=1
, you should set theOMP_NUM_THREADS
environment variable; OpenBLAS ignoresOPENBLAS_NUM_THREADS
andGOTO_NUM_THREADS
when compiled withUSE_OPENMP=1
.Setting the number of threads at runtime
We provide the following functions to control the number of threads at runtime:
Note that these are only used once at library initialization, and are not available for fine-tuning thread numbers in individual BLAS calls. If you compile this library with
USE_OPENMP=1
, you should use the above functions too.Reporting bugs
Please submit an issue in https://github.com/OpenMathLib/OpenBLAS/issues.
Contact
Change log
Please see Changelog.txt.
Troubleshooting
x86_64
(amd64
), there is experimental support for up to 1024 CPUs/cores and 128 numa nodes if you build the library withBIGNUMA=1
.NO_AFFINITY=1
in Makefile.rule. However, note that this may cause a conflict with R parallel.make test
may fail with apthread_create
error (EAGAIN
). However, it will be okay when you run the same test case on the shell.Contributing
CONTRIBUTORS.md
.Donation
Please see the donations section in the docs.