Numba is an open-source, NumPy-aware optimizing Just-In-Time (JIT) compiler for Python. It translates a subset of Python and NumPy code into fast machine code using the LLVM compiler library, enabling numerical algorithms to approach the speeds of C or Fortran without requiring a separate compilation step. Numba is currently at version 0.64.0 and maintains a regular release cadence, often coinciding with Python and NumPy releases.
pip install numbaVerified import paths — ran on the pinned version, not inferred.
This quickstart demonstrates the core usage of Numba's `@njit` decorator to compile a Python function for numerical computation. The function `sum_array` iterates over a NumPy array, and when decorated with `@njit`, Numba compiles it to highly optimized machine code at runtime, significantly speeding up its execution compared to pure Python.
Either recompile the function after modifying the global variable or, preferably, refactor your code to pass the variable as an argument to the jitted function.
Ensure that all operations and data types within a `@njit` (nopython mode) function are supported by Numba and that types are consistent. Explicitly casting types (e.g., using `np.int64(0)` instead of `0`) can sometimes help with type propagation.
Configure Spyder to exclude `numba` from its User Module Reloader (UMR). Go to `Preferences -> Console -> Advanced Settings`, click 'Set UMR excluded modules', and add `numba`. Restart the IPython console after applying the setting.
Avoid using the `target` kwarg. Numba's decorators like `jit` and `njit` infer the target (CPU by default) or specific GPU decorators like `cuda.jit` should be used for explicit targets.
Numba aims to replace this with a better implementation. Users relying on reflection for these types might need to adapt their code if they observe unexpected behavior or warnings in future versions. Pinning Numba dependency is recommended if relying on this behavior.
Update to Numba 0.64.0 or later to ensure compatibility with NumPy 2.x. Review Numba's documentation and NumPy 2.0 migration guides for potential code adjustments, especially concerning type interactions.
Code relying on the experimental RVSDG frontend will no longer function. Users should remove any explicit enabling of this frontend from their Numba configurations.
Ensure that the necessary build tools are installed in your environment. For Debian-based systems, use `apt-get install build-essential cmake`. For Alpine Linux, use `apk add build-base cmake`. For other operating systems, consult their documentation for installing development tools and CMake.
Ensure Numba is installed in your active environment using `pip install numba` or `conda install numba`. Verify the Python executable by checking `which python` and `which pip` (or `where python` and `where pip` on Windows) to ensure they belong to the same environment. If using Jupyter/IPython, restart the kernel after installation.
Inspect the types of variables within the jitted function using `my_jitted_func.inspect_types()`. Ensure all operations and data types are supported by Numba (consult Numba documentation for supported features). Often, this means avoiding dynamic Python features like heterogeneous lists or unsupported object methods. Consider explicitly casting types where Numba's inference struggles, or refactoring code to use NumPy arrays and operations. If this occurs in an IDE like Spyder, try adding `numba` to the UMR excluded modules in preferences and restarting the console.
To achieve performance benefits, compilation must succeed in `nopython` mode. Explicitly use `@numba.njit` (which is shorthand for `@numba.jit(nopython=True)`) to force `nopython` mode. This will raise an error instead of silently falling back, giving specific details about what Numba cannot compile. Refactor the problematic parts of the code to use Numba-supported types and operations. Use `my_jitted_func.inspect_types()` to see which variables are typed as `pyobject`, indicating areas that prevented `nopython` compilation.
Identify the line of code and the specific operation/function call mentioned in the full traceback. Examine the types of the arguments being passed to that operation. Ensure that the types are primitive (e.g., `int`, `float`), NumPy arrays, or other Numba-supported types, and that the operation is valid for those types within Numba. Avoid passing Python objects, lists, or dictionaries unless specifically supported by Numba for that operation. Consider explicitly defining function signatures or local variable types if inference is failing.