Numba: компилятор для numpy-кода

1. Одна строка — ускорение в 59 раз

Возьмём честную вычислительную задачу: метод Монте-Карло для π. Бросаем n случайных точек в единичный квадрат и считаем, какая доля попала в четверть круга; доля, умноженная на 4, стремится к π. Чистый цикл, ничего кроме арифметики:

import numpy as np
from numba import njit

def monte_carlo_pi(n):
    inside = 0
    x = 1234567.0
    for i in range(n):
        # простенький генератор случайных чисел прямо в цикле,
        # чтобы сравнение python/numba было работой один в один
        x = (1103515245 * x + 12345) % 2147483648
        px = x / 2147483648
        x = (1103515245 * x + 12345) % 2147483648
        py = x / 2147483648
        if px * px + py * py <= 1.0:
            inside += 1
    return 4.0 * inside / n

fast_pi = njit(monte_carlo_pi)      # та же функция + компилятор; обычно пишут @njit

Запускаем обе версии на двух миллионах точек (замеры этого конспекта — реальные, с обычного настольного процессора):

Никакой параллельности здесь ещё нет — одно ядро, один поток. Всё ускорение — из отказа от интерпретатора: вместо «прочитать байткод, определить тип x, найти метод сложения, упаковать результат в объект» на каждой строчке — голые машинные инструкции над числами в регистрах, как в C.

2. Что происходит при первом вызове

Numba — компилятор just-in-time: он работает не заранее, а в момент вызова, когда уже известны настоящие типы аргументов. Конвейер такой:

Ключевой этап — вывод типов: по типам аргументов первого вызова Numba прослеживает каждый оператор функции и приписывает каждой переменной конкретный машинный тип. Скомпилированный результат кэшируется на пару «функция + сигнатура типов»: вызов fast_pi с int64 использует готовый код, а вызов с float64 запустит новую компиляцию. Флаг @njit(cache=True) сохраняет результат на диск — и следующий запуск программы обойдётся без повторной компиляции.

Приставка «n» в njit означает режим nopython: компилируется всё или ничего. Если в функции встретилось что-то, что Numba не умеет превратить в машинный код, вы получите не тихое замедление, а честную ошибку компиляции:

@njit
def bad(d):
    return d["a"]

bad({"a": 1})
# TypingError: Failed in nopython mode pipeline (step: nopython frontend)
# ...обычный словарь Python компилятору не по зубам

Это осознанный дизайн: старший декоратор @jit умел «object mode» — прозрачно откатываться к интерпретатору на непонятных местах, — и программы годами работали медленно, не сообщая об этом. TypingError неприятен ровно один раз, зато после него вы точно знаете: раз скомпилировалось — значит, быстро.

3. Граница волшебства: что ускоряется, а что нет

Numba создана для числового кода и не претендует на весь Python. Практическая карта:

Отсюда рабочий приём: не заворачивайте в @njit программу целиком — выносите горячее вычислительное ядро в отдельную функцию с числами и массивами на входе-выходе, и компилируйте её. Загрузка данных, pandas-обвязка и графики остаются обычным Python, которому и так хорошо.

4. Тренажёр: ускорит или нет

Контрольные вопросы

• Почему первый вызов @njit-функции медленнее чистого Python и что с этим делать?
  В первый вызов входит вся компиляция: вывод типов, генерация LLVM-кода, машинный код. Это разовая плата; дальше работает готовый код. Для замеров — прогревочный вызов вне секундомера; для продакшена — @njit(cache=True), сохраняющий скомпилированное на диск между запусками программы.
• Что означает режим nopython и чем он лучше тихого отката в интерпретатор?
  Компилируется всё или ничего: встретив нетипизируемую конструкцию, Numba бросает TypingError вместо того, чтобы молча выполнить кусок через интерпретатор. Ошибка при разработке лучше незаметной медленности в проде: раз скомпилировалось — значит, действительно быстро.
• Откуда берётся ускорение в 59 раз, если параллельности ещё нет?
  Из отказа от интерпретатора: в чистом Python каждая итерация — это чтение байткода, динамическое определение типов, поиск методов и упаковка чисел в объекты. Скомпилированный код выполняет голые машинные инструкции над числами в регистрах — как программа на C, на том же одном ядре.
• Почему @njit почти не ускорит функцию из пары вызовов np.dot на больших матрицах?
  np.dot и так выполняется скомпилированной библиотекой BLAS; интерпретатору принадлежат микросекунды на диспетчеризацию вызова. Numba ускоряет пользовательские циклы, где интерпретатор работает на каждой итерации, — а не внутренности чужих библиотек.
• Как Numba решает, для каких типов компилировать, и что случится при вызове с другими типами?
  Типы выводятся из фактических аргументов первого вызова; результат кэшируется на сигнатуру. Вызов с другой комбинацией типов запускает отдельную компиляцию — у одной функции может быть несколько машинных версий под разные сигнатуры.

Источники

1. A ~5 minute guide to Numba // Numba Documentation : [сайт]. — URL: https://numba.readthedocs.io/en/latest/user/5minguide.html (дата обращения: 09.07.2026).
2. Compiling Python code with @jit // Numba Documentation : [сайт]. — URL: https://numba.readthedocs.io/en/latest/user/jit.html (дата обращения: 09.07.2026).
3. Supported NumPy features // Numba Documentation : [сайт]. — URL: https://numba.readthedocs.io/en/latest/reference/numpysupported.html (дата обращения: 09.07.2026).