В ноябре 2024 года я написал пост «Действительно ли Python такой медленный?», в котором протестировал множество версий Python и отметил стабильный прогресс производительности языка.
Сегодня девятое октября 2025 года, прошла всего пара дней после официального релиза Python 3.14. Давайте снова запустим бенчмарки, чтобы проверить, насколько быстра новая версия Python!
Примечание: если вам неинтересны таблицы и графики и вы хотите просто прочитать мои выводы, сразу переходите к концу статьи.
Вкратце о том, как бенчмарки могут вводить в заблуждение
Да, хоть я и собираюсь рассказать о своих результатах бенчмаркинга, мне кажется, что снова стоит вас предупредить, что подобные обобщённые бенчмарки не особо полезны. Выполнять их любопытно, именно поэтому я этим и занимаюсь, но, выполнив пару поверхностных маленьких скриптов, практически невозможно создать точный профиль производительность столь сложной системы, как интерпретатор Python.
Я спроектировал свои тесты таким образом, чтобы они выполняли только чистый код на Python, избегая использования любых зависимостей, и в частности функций, написанных на C. Нативный код (если не считать сам интерпретатор Python) с меньшей вероятностью будет становиться быстрее между релизами Python, поэтому я не вижу смысла включать его в этот бенчмарк. Однако в реальных приложениях часто применяется комбинация чистого Python и нативного кода, будь то C, C++ или Rust, поэтому хоть мои тестовые скрипты и хорошо справляются с оценкой производительности чистого кода на Python, их нельзя считать репрезентативными для обычно используемых нами приложений.
Если вкратце, то изучите мой бенчмарк, но считайте его лишь одним примером данных, а не окончательным вердиктом о производительности Python!
Матрица тестирования
Вот матрица тестирования, с которой я работал; она состоит из пяти измерений:
-
6 версий Python, плюс недавние версии Pypy, Node.js и Rust:
-
3 интерпретатора Python
Стандартный
Just-In-Time (JIT): только для CPython 3.13+
Free-threading (FT): только для CPython 3.13+
-
2 тестовых скрипта
fibo.py: вычисляет числа Фибоначчи, активно используя при этом рекурсию
bubble.py: сортирует список случайно сгенерированных чисел при помощи алгоритма сортировки пузырьком с большим количеством итераций, но без рекурсии
-
2 потоковых режима
Однопоточный
4 потока, выполняющих независимые вычисления
-
2 компьютера
Ноутбук Framework с Ubuntu Linux 24.04 (CPU Intel Core i5)
Ноутбук Mac с macOS Sequoia (CPU M2)
Кто-то может решить, что странно было добавлять в бенчмарк Node.js и Rust. Возможно, это так, но тем не менее, я портировал два тестовых приложения Python на JavaScript и Rust, чтобы иметь какие-то значения вне экосистемы Python, от которых можно было бы отталкиваться.
Тестовые скрипты
Ниже показана основная логика fibo.py:
def fibo(n):
if n <= 1:
return n
else:
return fibo(n-1) + fibo(n-2)
Проведя эксперименты, я выяснил, что для вычисления сорокового числа Фибоначчи при помощи этой функции на моих ноутбуках требуется несколько секунд, поэтому я использовал его для всех показанных ниже результатов тестов.
Вот функция сортировки из bubble.py:
def bubble(arr):
n = len(arr)
for i in range(n):
for j in range(0, n-i-1):
if arr[j] > arr[j+1]:
arr[j], arr[j+1] = arr[j+1], arr[j]
return arr
Для этого скрипта я тоже подобрал размер массива так, чтобы программа выполнялась несколько секунд. Я остановился на списке из 10000 случайно генерируемых чисел.
Не стоит считать, что это замечательные примеры, потому что это не так. Есть более эффективные способы кодирования этих функций, на случай, если бы мы стремились выполнять их как можно быстрее. Но цель здесь не в создании быстрых функций, а в сравнении того, как выполняют код разные интерпретаторы Python. Я выбрал эти функции в основном потому, что одна рекурсивна, а другая нет, чтобы в тестовом наборе у меня было два разных стиля кодинга.
Фреймворк, созданный мной для выполнения этого бенчмарка, запускает каждую функцию три раза и сообщает среднее время этих трёх прогонов. Полные тестовые скрипты с скриптами бенчмарка выложены в репозиторий GitHub.
Бенчмарк 1: однопоточный Фибоначчи
Давайте посмотрим на первый тест. В нём я измерял время в секундах, необходимое для выполнения fibo(40)
. Как говорилось выше, для каждого примера данных я запускал код три раза и усреднял результаты.
Вот значения в табличном виде:
fibo 1 thread |
Linux |
macOS |
относительно 3.14 |
---|---|---|---|
3.9 |
15.21 |
13.81 |
0.45x |
3.10 |
16.24 |
14.97 |
0.42x |
3.11 |
9.11 |
9.23 |
0.71x |
3.12 |
8.01 |
8.54 |
0.78x |
3.13 |
8.26 |
8.24 |
0.79x |
3.14 |
6.59 |
6.39 |
-- |
Pypy 3.11 |
1.39 |
1.24 |
4.93x |
Node 24 |
1.38 |
1.28 |
4.88x |
Rust 1.90 |
0.08 |
0.10 |
69.82x |
В самом правом столбце показано соотношение скорости относительно 3.14, то есть если число меньше 1, то соответствующий тест был медленнее, чем 3.14, а число выше означает, что он был быстрее. Для вычисления соотношений я использовал средние значения между результатами в Linux и macOS.
Иногда полезно посмотреть на данные и в графическом виде, поэтому вот график со всеми приведёнными выше значениями:

Что можно понять из этих результатов? Видно, что 3.14 стал заметно быстрее по сравнению с 3.13. Он работал примерно на 27% быстрее; иными словами, 3.13 работал примерно на 79% от скорости 3.14. Также эти результаты демонстрируют, что версия 3.11 стала той переломной точкой, в которой версии Python превратились из «очень медленных» в «не такие уж медленные».
Не связанная с Python 3.14 деталь: Pypy продолжает меня удивлять. В этом тесте он был чуть быстрее Node.js и почти в пять раз быстрее, чем 3.14. Впечатляет, но он всё равно очень далеко от Rust, который и должен быть намного быстрее остальных.
Варианты Just-In-Time и Free-Threading
Начиная с Python 3.13, интерпретатор CPython имеет три разновидности: стандартную, free-threading (FT) и just-in-time (JIT). Интерпретатор free-threading отключает global interpreter lock (GIL), и это изменение в перспективе позволит добиться большого роста скорости в многопоточных приложениях. Интерпретатор JIT включает в себя компиляцию «на лету» в нативный код, что должно, теоретически, помочь ускорить многократно выполняемый код благодаря его единоразовой компиляции в нативный код.
В показанных выше результатах для 3.13 и 3.14 использовался стандартный интерпретатор, но мне хотелось посмотреть, как справляются с моим тестом конкретно два других варианта интерпретатора. В таблице и графике ниже показаны сравнения того же теста, запущенного на трёх интерпретаторах 3.13 и 3.14:
fibo 1 thread |
Linux |
macOS |
относительно 3.14 |
---|---|---|---|
3.13 |
8.26 |
8.24 |
0.79x |
3.13 JIT |
8.26 |
8.28 |
0.78x |
3.13 FT |
12.40 |
12.40 |
0.52x |
3.14 |
6.59 |
6.39 |
-- |
3.14 JIT |
6.59 |
6.37 |
1.00x |
3.14 FT |
7.05 |
7.27 |
0.91x |

Результаты немного разочаровывают. По крайней мере, в этом тесте интерпретатор JIT не обеспечил никаких существенных улучшений производительности, поэтому мне даже трижды пришлось проверить, действительно ли я использовал корректно собранный интерпретатор, где эта фича включена. Я не особо разбираюсь во внутреннем устройстве нового компилятора JIT, но возможно, он не может справляться с этой сильно рекурсивной функцией.
Что касается free-threading, то в прошлом году я уже выяснил, что интерпретатор медленно выполнял однопоточный код. В 3.14 этот интерпретатор, похоже, по-прежнему медленнее стандартного интерпретатора, но разница гораздо меньше: free-threading работает на 91% от скорости стандартного интерпретатора.
Бенчмарк 2: однопоточная сортировка пузырьком
Ниже показаны результаты для бенчмарка сортировки пузырьком массива из 10000 случайных чисел:
bubble 1 thread |
Linux |
macOS |
относительно 3.14 |
---|---|---|---|
3.9 |
3.77 |
3.29 |
0.60x |
3.10 |
4.01 |
3.38 |
0.57x |
3.11 |
2.48 |
2.15 |
0.91x |
3.12 |
2.69 |
2.46 |
0.82x |
3.13 |
2.82 |
2.61 |
0.78x |
3.14 |
2.18 |
2.05 |
-- |
Pypy 3.11 |
0.10 |
0.14 |
18.14x |
Node 24 |
0.43 |
0.21 |
6.64x |
Rust 1.90 |
0.04 |
0.07 |
36.15x |

Этот тест демонстрирует более серьёзное расхождение между моими ноутбуками с Linux и macOS, но соотношения между версиями на каждой машине более-менее одинаковы. Из разницы просто можно сделать вывод, что Python на Mac может выполнять этот тест чуть быстрее.
Как и в тесте Фибоначчи, интерпретатор 3.14 — самый быстрый из всех CPython, но разница зде��ь меньше, чем в предыдущем бенчмарке: Python 3.11 работает на 91% от скорости 3.14. Кроме того, этот тест выполняется медленнее в 3.12 и 3.13, чем в 3.11 — интересная особенность, которую я наблюдал и в прошлогоднем бенчмарке.
Pypy на этот раз был в 18 быстрее, чем 3.14, и даже в три раза быстрее, чем Node. Мне нужно внимательнее изучить Pypy, потому что выглядит он замечательно.
Варианты Just-In-Time и Free-Threading
Давайте посмотрим, насколько хорошо справляются с тестом сортировки пузырьком специализированные интерпретаторы 3.13 и 3.14. Вот таблица и график с результатами:
bubble 1 thread |
Linux |
macOS |
относительно 3.14 |
---|---|---|---|
3.13 |
2.82 |
2.61 |
0.78x |
3.13 JIT |
2.59 |
2.44 |
0.84x |
3.13 FT |
4.13 |
3.75 |
0.54x |
3.14 |
2.18 |
2.05 |
-- |
3.14 JIT |
2.03 |
2.32 |
0.97x |
3.14 FT |
2.66 |
2.28 |
0.86x |

Здесь интерпретатор JIT оказался чуть быстрее, но только в Linux-версии Python. На Mac он был чуть быстрее в версии 3.13, но медленнее в 3.14. Различия в скорости тоже очень малы, поэтому в целом мне кажется, что интерпретатору JIT ещё нужно время, чтобы повзрослеть. Похоже, написанный мной код не может воспользоваться преимуществами компиляции JIT.
Интерпретатор free-threading тоже работал медленнее, но снова разница была гораздо меньше в 3.14, чем в 3.13, поэтому результаты двух бенчмарков согласуются. На данный момент, похоже, нет смысла переходить на интерпретатор free-threading в случае обычных нагрузок, но он окажется интересным вариантом, когда GIL становится помехой, что актуально только для многопоточных нагрузок с большими потребностями в ресурсах CPU.
Бенчмарк 3: многопоточный Фибоначчи
В этом году я решил добавить многопоточные версии двух тестовых программ; в первую очередь это стало хорошей возможностью продемонстрировать сильные стороны интерпретатора free-threading.
Для многопоточного теста Fibonacci я запускал четыре потока, выполняющих одинаковые вычисления сорокового числа Фибоначчи. Четыре потока работали независимо друг от друга, а у двух моих ноутбуков больше четырёх ядер, поэтому они должны отлично распараллелить этот тест. Замерялось время от запуска первого потока до завершения всех четырёх.
Вот результаты fibo.py, запущенного на четырёх потоках со стандартными интерпретаторами:
fibo 4 threads |
Linux |
macOS |
относительно 3.14 |
---|---|---|---|
3.9 |
67.87 |
57.51 |
0.46x |
3.10 |
72.42 |
61.57 |
0.43x |
3.11 |
45.83 |
36.98 |
0.70x |
3.12 |
36.22 |
34.13 |
0.82x |
3.13 |
37.20 |
33.53 |
0.81x |
3.14 |
32.60 |
24.96 |
-- |
Pypy 3.11 |
7.49 |
6.84 |
4.02x |

Стоит отметить, что в данном случае я не выполнял версии тестов для Node и Rust, так как это очень специфичный тест, применимый только к GIL Python.
Разумеется, эти результаты не говорят нам о многом. Снова видно, что Mac, похоже, чуть быстрее машины с Linux, но во всём остальном скорость более-менее масштабируется линейно. Например, однопоточный тест Фибоначчи выполнялся 7 секунд, а четырёхпоточный — 25 секунд на Mac и 32 секунды в Linux, то есть примерно в четыре раза медленнее. Это ожидаемо, потому что GIL не позволяет распараллеливать код на Python.
Давайте взглянем на подробные результаты для интерпретаторов 3.13 и 3.14:
fibo 4 threads |
Linux |
macOS |
относительно 3.14 |
---|---|---|---|
3.13 |
37.20 |
33.53 |
0.81x |
3.13 JIT |
37.48 |
33.36 |
0.81x |
3.13 FT |
21.14 |
15.47 |
1.57x |
3.14 |
32.60 |
24.96 |
-- |
3.14 JIT |
32.58 |
24.90 |
1.00x |
3.14 FT |
10.80 |
7.81 |
3.09x |

Довольно неплохо!
Так как мы не ожидали в этом тесте ничего особенного от интерпретатора JIT, то можем игнорировать эти результаты. Однако интерпретатор free-threading показывает нам, что отключение GIL может помочь с выполнением нескольких потоков, активно задействующих CPU.
В Python 3.13 интерпретатор free-threading работал примерно в 2,2 раза быстрее, чем стандартный. В 3.14 его производительность почти в 3,1 раза больше. Замечательный результат!
Бенчмарк 4: многопоточная сортировка пузырьком
Для завершения нашего бенчмаркинга покажем результаты теста сортировки пузырьком, запущенного на четырёх потоках. В этом тесте каждый поток сортировал 10000 случайных чисел. Четыре потока получали копии одинакового случайно сгенерированного массива.
Для начала взглянем на стандартные интерпретаторы:
bubble 4 threads |
Linux |
macOS |
относительно 3.14 |
---|---|---|---|
3.9 |
16.14 |
12.58 |
0.66x |
3.10 |
16.12 |
12.95 |
0.65x |
3.11 |
11.43 |
7.89 |
0.97x |
3.12 |
11.39 |
9.01 |
0.92x |
3.13 |
11.54 |
9.78 |
0.88x |
3.14 |
10.55 |
8.27 |
-- |
Pypy 3.11 |
0.54 |
0.59 |
16.65x |

Эти результаты тоже неудивительны. Однопоточная версия этого теста выполнялась на 3.14 примерно 2 секунды, а здесь мы получили 10 секунд в Linux и 8 секунд на Mac. Интересно, что на машине с Linux этот тест занял чуть больше, чем четырёхкратное время однопоточного теста.
Вот результаты с новыми интерпретаторами в 3.13 и 3.14:
bubble 4 threads |
Linux |
macOS |
относительно 3.14 |
---|---|---|---|
3.13 |
11.54 |
9.78 |
0.88x |
3.13 JIT |
10.90 |
9.19 |
0.94x |
3.13 FT |
9.83 |
5.05 |
1.17x |
3.14 |
10.55 |
8.27 |
-- |
3.14 JIT |
10.03 |
9.26 |
0.98x |
3.14 FT |
6.23 |
3.02 |
2.03x |

И здесь мы снова видим хороший сценарий применения интерпретатора free-threading. В этом тесте free-threading на Mac проявил себя лучше, чем в Linux, но в среднем 3.14 FT выполнялся примерно в два раза быстрее, чем стандартный 3.14. Если ваше многопоточное приложение активно нагружает CPU, то, возможно, стоит перейти на интерпретатор free-threading.
Странные результаты интерпретатора JIT, который оказался в однопоточном тесте сортировки пузырьком интерпретатора 3.14 на Mac медленнее, повторились и здесь; предположу, что это не случайность, но, на мой взгляд, различия всё равно несущественны. Просто будем ждать дальнейшего развития интерпретатора JIT в последующих релизах.
Выводы
Надеюсь, результаты моего бенчмарка показались вам интересными. Из этих результатов я сделал следующие выводы:
Похоже, CPython 3.14 — самый быстрый из всех CPython.
Если вы пока не можете проапгрейдиться до 3.14, то подумайте об использовании релиза с 3.11 и выше, потому что они существенно быстрее 3.10 и более старых версий.
Интерпретатор 3.14 JIT, похоже, не обеспечивает никакого существенного прироста скорости, по крайней мере, в моих тестовых скриптах.
Интерпретатор 3.14 free-threading быстрее, чем стандартный интерпретатор в сильно нагружающих CPU многопоточных приложениях, поэтому стоит его попробовать, если у вас подобное приложение. Не рекомендую использовать этот интерпретатор для других нагрузок, потому что он по-прежнему медленнее для кода, не замедляемого непосредственно GIL.
Pypy безумно быстр!
А вы проводили бенчмаркинг Python 3.14? Напишите в комментариях, если у вас получились другие результаты.
Комментарии (4)
evgenyk
09.10.2025 13:22Мне кажется, тесты однозначно показывают, что как волка не корми, медведь все равно сильнее.
Питон не про скорость выплнения математики.
Johan_Palych
09.10.2025 13:22Framework laptop running Ubuntu Linux 24.04 (Intel Core i5 CPU)
Просто интересно,где Miguel Grinberg брал Python 3.14 под Ubuntu 24.04?
Есть 2 варианта:
Собрать самому из сырцов Python-3.14.0.tar.xz
Поставить из ppa “deadsnakes” team
Anfisapi
09.10.2025 13:22говорят, что теперь там ещё появились официальные бинарные сборки для платформы Android
Dhwtj
Надо бы добавить, что PyPy работает с RPython (Restricted Python) — подмножеством языка Python, предназначенном для реализации интерпретаторов и других систем, которые могут быть переведены в эффективный низкоуровневый код.
Некоторые особенности RPython:
Статическая типизация. В отличие от Python, RPython требует, чтобы переменные сохраняли постоянные типы на протяжении всего выполнения.
Ограничения. Например, нет функций eval(), exec() и других динамических функций Python.
Ограничения в отражении. Ограничено использование getattr(), setattr() и других.
Отсутствие выражений генераторов. Нельзя использовать выражения генераторов или yield.
Структура модулей. Импорты должны быть на верхнем уровне.
RPython служит основой проекта PyPy, обеспечивая высокопроизводительную реализацию Python за счёт автоматизированной генерации кода
Соответственно, он сильно ограничен по библиотекам. Если нужен перформанс/статичность — зовите C++/Rust/C# (gRPC/FFI) или держите Python-микросервис
Соответственно, PyPy нишевая штука и преимущество python по библиотекам превращается в тыкву