Numba: A High Performance Python Compiler

It’s clear that successfully compiling Python code at runtime requires not onlyhigh-quality Python-specific optimizations for the code being run, but alsoquick generation of efficient machine code for the optimized program. The Pythoncore development team has the necessary skills and experience for the former (amiddle-end tightly coupled to the interpreter), and copy-and-patch compilationprovides an attractive solution for the latter. Firstly, it combines the flexibility of an interpreted language with the performance of a compiled language. It allows the interpreter to make intelligent optimizations based on runtime information, leading to faster execution. Additionally, JIT compilation enables dynamic code generation and adaptive optimizations, resulting in improved performance for specific code paths. JIT compilers typically continuously analyze the code as it is executed, identifying parts of the code that are executed frequently (hot spots).

Well, remember that CPython is already written in C and that was already compiled to machine-code by the C compiler. In most cases, this JIT will be executing almost the same machine-code instructions as it was before. The copy-and-patch compiler for Python works by extending some new (and honestly not widely known about) APIs to Python 3.13’s API.

When to use Numba, and when Not to:

When you combine this with parallelism and GPU acceleration, you can handle even the most demanding computational tasks efficiently. Building the JIT adds between 3 and 60 seconds to the build process, dependingon platform. It is only rebuilt whenever the generated files become out-of-date,so only those who are actively developing the main interpreter loop will berebuilding it with any frequency. Clang is specifically needed because it’s the only C compiler with support forguaranteed tail calls (musttail), which are required by CPython’scontinuation-passing-style approachto JIT compilation. Without it, the tail-recursive calls between templates couldresult in unbounded C stack growth (and eventual overflow). While it is probably possible to maintain the JIT outside of CPython, itsimplementation is tied tightly enough to the rest of the interpreter thatkeeping it up-to-date would probably be more difficult than actually developingthe JIT itself.

As a JIT, it is the least interesting type and not canonically JIT compiled in the compilers sense! Most JITs however (Pypy, Java, JS Engines), are not at all about compiling code just-in-time, but compiling optimal code at an optimal time. In many cases where code is compiled, it doesn’t occur until after the source code has been executed numerous times, and the JIT will stay in an interpreter as the overhead to compilation is too high to be valuable.

What people tend to mean when they say a JIT compiler, is a compiler that emits machine code. This is in contrast to an AOT (Ahead of Time) compiler, like the GNU C compiler, GCC or the Rust compiler rustc which generates the machine code once and distributes as a binary executable. JIT, or “Just in Time” is a compilation design that implies that compilation happens on demand when the code is run the first time.

In Python 3.13, this method is part of the experimental JIT implementation, offering a balance of speed and adaptability, albeit with some additional memory and build-time requirements. It’s fine if you’re measuring the performance of generating the mandelbrot set, but becomes painful if you’re serving a web application and the first N requests are painfully slow. It means that Javascript is relatively less performant as a command line tool than it is for a webserver. If Pypy decides it needs to compile many things all at once after JITs compiling some functions, then you might have a slow-down in the middle. It also makes benchmark results more ambiguous, as you have to check if the jitted languages were given time to warmup, but you’d also want to know if it took an unseemly amount of time to warmup.

Numba also supports options pyjion like parallelization and fast-math behavior in some decorators. If you’re working with C/C++ functions or Cython, Numba has you covered with interoperability options for ctypes, cffi, and Cython-exported functions. As we can see here, the execution time of the compiled Numba JIT is a tiny fraction of the compilation. It is almost 50% faster than the native Python code, even though the code is extremely simple with little room optimization.

• By simply adding “@jit” before the “fibonacci” function definition, we enable the Numba compiler to optimize and compile the code.
• The main reason is that the dynamic-ness of the languages they tend to implement means that they need many extra instructions to decide what to do next and how to route data.
• While the “@jit” decorator can significantly enhance the performance of your Python code, it’s essential to consider its demerits and limitations.
• Your source code remains pure Python while Numba handles the compilation at runtime.
• Cython allows you to annotate variables and function signatures with type information, enabling static typing and more efficient memory access.

Goal: Apply Just-in-Time Compilation for Performance Optimization

So while you can argue about compiler benefits, you have to take into account that there are different features in different languages. JIT is commonly used in modern web browsers to optimize the performance of JavaScript code. Additionally, Python’s test framework now includes better support for testing platform-specific features and configurations, which ensures that Python remains stable across a wider range of environments, including less common platforms. While Python 3.13 does not introduce many new modules, it delivers significant enhancements to existing ones, improving functionality, usability, and performance. Key features of dbm.sqlite3 include efficient storage and retrieval of key-value pairs, making it ideal for simple databases, caching mechanisms, or configuration systems.

So how does this JIT work?¶

Anybody can submit a solution in his/her preferred language and then the tests compare the runtime of each solution. Solutions can be peer reviewed, are often further improved by others, and results are checked against the spec. In the long run this is the most fair benchmarking system to compare different languages. There are also some alternative implementations of CPython (not to be confused with JIT compilers) called Jython and IronPython which do not have the GIL. Finally, Python 3.13 introduces refined tools for mocking, stubbing, and patching during tests. This makes it easier for developers to isolate specific components, test edge cases, and simulate various runtime conditions without depending on external resources.

The language implementation only sets an upper bound for how fast you can make a sequence of operations. Generally, you can improve the program’s performance much better simply by avoiding unnecessary work, i.e. by optimizing the program. This is true regardless of whether you run the program through an interpreter, a JIT compiler, or an ahead-of-time compiler. If you want something to be fast, don’t go out of your way to get at a faster language implementation.

The first is compiling Java source to bytecode, which is an Intermediate Representation (IR). The compiler/interpreter is sometimes referred to as the “implementation” of a language, and one language can have many implementations. You may have heard things like “Python is interpreted”, but that really means the reference(standard/default) implementation of Python is an interpreter. Python is a language specification and CPython is the interpreter and implementation of Python.

These changes enable pluggable optimizers to be discoverable at runtime in CPython and control how code is executed. I assume that it will be the default in future versions once the major bugs have been squashed. For our interpreter, everytime you want to run the function, func it has to loop through each instruction and compare the bytecode name (called the opcode) with each if-statement. That overhead seems redundant if you run the function 10,000 times and the bytecodes never change (because they are immutable).