2.5. Environment variables¶
Numba allows its behaviour to be changed by using environment variables. Unless otherwise mentioned, those variables have integer values and default to zero.
2.5.1. Errors and warnings display¶
-
NUMBA_WARNINGS
¶ If set to non-zero, printout of Numba warnings is enabled, otherwise the warnings are suppressed. The warnings can give insight into the compilation process.
2.5.2. Debugging¶
These variables influence what is printed out during compilation of JIT functions.
-
NUMBA_DEBUG
¶ If set to non-zero, print out all possible debugging information during function compilation. Finer-grained control can be obtained using other variables below.
-
NUMBA_DEBUG_FRONTEND
¶ If set to non-zero, print out debugging information during operation of the compiler frontend, up to and including generation of the Numba Intermediate Representation.
-
NUMBA_DEBUG_TYPEINFER
¶ If set to non-zero, print out debugging information about type inference.
-
NUMBA_DEBUG_CACHE
¶ If set to non-zero, print out information about operation of the JIT compilation cache.
-
NUMBA_TRACE
¶ If set to non-zero, trace certain function calls (function entry and exit events, including arguments and return values).
-
NUMBA_DUMP_CFG
¶ If set to non-zero, print out information about the Control Flow Graph of compiled functions.
-
NUMBA_DUMP_IR
¶ If set to non-zero, print out the Numba Intermediate Representation of compiled functions.
-
NUMBA_DUMP_ANNOTATION
¶ If set to non-zero, print out types annotations for compiled functions.
-
NUMBA_DUMP_LLVM
¶ Dump the unoptimized LLVM assembler source of compiled functions. Unoptimized code is usually very verbose; therefore,
NUMBA_DUMP_OPTIMIZED
is recommended instead.
-
NUMBA_DUMP_FUNC_OPT
¶ Dump the LLVM assembler source after the LLVM “function optimization” pass, but before the “module optimization” pass. This is useful mostly when developing Numba itself, otherwise use
NUMBA_DUMP_OPTIMIZED
.
-
NUMBA_DUMP_OPTIMIZED
¶ Dump the LLVM assembler source of compiled functions after all optimization passes. The output includes the raw function as well as its CPython-compatible wrapper (whose name begins with
wrapper.
). Note that the function is often inlined inside the wrapper, as well.
-
NUMBA_DUMP_ASSEMBLY
¶ Dump the native assembler code of compiled functions.
See also
2.5.3. Compilation options¶
-
NUMBA_OPT
¶ The optimization level; this option is passed straight to LLVM.
Default value: 3
-
NUMBA_LOOP_VECTORIZE
¶ If set to non-zero, enable LLVM loop vectorization.
Default value: 1 (except on 32-bit Windows)
-
NUMBA_ENABLE_AVX
¶ If set to non-zero, enable AVX optimizations in LLVM. This is disabled by default on Sandy Bridge and Ivy Bridge architectures as it can sometimes result in slower code on those platforms.
-
NUMBA_COMPATIBILITY_MODE
¶ If set to non-zero, compilation of JIT functions will never entirely fail, but instead generate a fallback that simply interprets the function. This is only to be used if you are migrating a large codebase from an old Numba version (before 0.12), and want to avoid breaking everything at once. Otherwise, please don’t use this.
2.5.4. GPU support¶
-
NUMBA_DISABLE_CUDA
¶ If set to non-zero, disable CUDA support.
-
NUMBA_FORCE_CUDA_CC
¶ If set, force the CUDA compute capability to the given version (a string of the type
major.minor
), regardless of attached devices.
-
NUMBA_ENABLE_CUDASIM
¶ If set, don’t compile and execute code for the GPU, but use the CUDA Simulator instead. For debugging purposes.
2.5.5. Threading Control¶
-
NUMBA_NUM_THREADS
¶ If set, the number of threads in the thread pool for the parallel CPU target will take this value. Must be greater than zero. This value is independent of
OMP_NUM_THREADS
andMKL_NUM_THREADS
.Default value: The number of CPU cores on the system as determined at run time, this can be accessed via
numba.config.NUMBA_DEFAULT_NUM_THREADS
.