Hacker News Digest

• Python-оптимизация часто сводится к выносу «горячих» участков в C/NumPy, а не к микро-оптимизации кода.
• Сам факт, что в CPython «всё является объектом» влечёт за собой неизбежные накладные расходы, которые нельзя убрать без отказа от части философии языка.
• JIT (PyPy) и отсутствие GIL в будущем могут решить 90 % проблем производительности, но это не касается CPython.
• Сообщество в целом согласно с тем, что вместо попыток «оптимизировать» Python-стильный код, стоит либо полностью переписать узкие места на C/Rust, либо вовсе перейти на Julia/Go.

SPy — это интерпретатор и компилятор для статически типизированного варианта Python с фокусом на производительность. Важно понимать, что SPy не является компилятором для полного Python — по дизайну он не поддерживает все динамические возможности языка. Код SPy будет находиться в файлах с расширением *.spy для четкого отличия от обычного Python. Хотя проект находится в разработке и пока не готов для серьезного использования, уже существует пример трассировки лучей, работающий в 200 раз быстрее CPython. SPy стремится к тесной интеграции с экосистемой Python, позволяя импортировать Python-библиотеки и наоборот.

Существующие подходы к ускорению Python делятся на две категории: реализация "полного Python" с JIT-компиляторами (PyPy, GraalPy, Pyston) и создание "подмножества Python" (Cython, Numba). SPy позиционируется как мысленный эксперимент, направленный на определение того, сколько динамичности можно удалить из Python, сохранив его "питоничность". Автор подчеркивает, что большинство "компиляторов для Python" не поддерживают полный язык, даже если заявляют обратное, и предпочитает быть более открытым о ограничениях SPy.

• Обсуждение вращается вокруг того, что статически-типизированный подмножество Python (SPy) может быть полезным, но вызывает вопросы о совместимости, экосистеме и цели проекта.
• Участники обсуждают, что неясно, как SPy будет взаимодействовать с существующими библиотеками Python, и что это значит для пользователей.
• Также обсуждается, что статическая типизация может не подходить для всех задач, и что динамическая природа Python может быть важной для некоторых задач.
• Некоторые участники высказывают, что вместо того, чтобы создавать новый язык, было бы лучше улучшить существующие инструменты, такие как Cython или Numba.

Python 3.14 вышел 8 октября 2025 года. Автор сравнил его с 3.9-3.13, а также с PyPy 3.11, Node.js 24 и Rust 1.90. Для тестов использовались два скрипта: рекурсивный расчет 40-го числа Фибоначчи и пузырьковая сортировка 10 000 элементов. Все тесты запускались на ноутбуке с Intel Core i5 под Ubuntu и ноутбуке Apple M2 под macOS.

Результаты: CPython 3.14 оказался на 10-15% быстрее 3.13 и примерно вдвое быстрее 3.9. JIT в 3.14 работает стабильно, а в 3.13 еще может выдавать сбои. Free-threading в 3.14 показал себя как надежный способ распараллеливать задачи, но прирост не столь драматичен, как ожидалось. PyPy 3.11 оказался в 2-3 раза быстрее CPython 3.14, но требует в 2-3 раза больше памяти. Node.js и Rust оказались в 2-3 раза быстрее, но это сравнение не совсем корректно, так как они не тестировали рекурсию.

• Пользователи обсуждают производительность Python 3.14, сравнивая его с PyPy и другими языками, и обсуждают, почему сообщество продолжает тратить усилия на ускорение CPython вместо перехода на PyPy.
• Несколько комментаторов отмечают, что 3.14 всё ещё значительно уступает PyPy и даже Node.js в ряде тестов, хотя и демонстрирует прогресс.
• Обсуждается, почему Python не может быть переименован в π-thon, несмотря на то, что это было бы логично, и почему не используется возможность перехода на PyPy, несмотря на то, что он быстрее.
• Участники также обсуждают, что, несмотря на то, что Python всё ещё остаётся медленным, он остаётся незаменимым для прототипирования и имеет огромную экосистему библиотек, что делает его незаменимым для многих задач.
• Наконец, обсуждается, что, несмотря на то, что Python медленный, он всё ещё может быть использован для большинства задач, и что важнее всего - он всё ещё может быть использован для большинства задач.

Добро пожаловать на LWN.net

Этот материал для подписчиков стал доступен благодаря читателю LWN. Тысячи подписчиков зависят от LWN как от источника новостей о Linux и свободном ПО. Если статья вам понравилась, пожалуйста, рассмотрите возможность оформления подписки. Спасибо за визит!

Антонио Куни, давний инженер по производительности Python и разработчик PyPy, на EuroPython 2025 в Праге представил доклад «Мифы и сказки про производительность Python». По его мнению, привычная «мудрость» о скорости Python часто вводит в заблуждение. На примерах он показал реальные узкие места и пришел к выводу: в конечном счете предел оптимизаций упирается в управление памятью. Он начал ранний проект SPy, который, возможно, приведет к сверхбыстрому Python.

Он попросил зал поднять руки, кто считает «Python медленным или недостаточно быстрым» — рук было много (в отличие от PyCon Italy). Годы работы с производительностью и общение с разработчиками породили набор мифов, которые он хочет развеять.

Мифы

Миф: «Python не медленный». Да, часто «достаточно быстрый», особенно как «склеечный» язык в эпоху «важен только GPU». Но это верно лишь для части задач. Есть множество программ, где скорость Python критична — отсюда постоянные усилия по оптимизации интерпретатора и перенос горячих участков в Cython, Numba и т.п.

В слайдах он показал множества: «программы, где Python достаточно быстр» — подмножество «всех Python-программ», а снаружи — «все возможные программы». В идеале Python должен подходить для всех; пока что задачи, требующие максимума от процессора, не могут быть на Python. Он хочет расширять «внутренние круги».

Королларий «это всего лишь клей»: «просто перепишите горячее в C/C++» (сегодня — в Rust). Прием рабочий, но быстро упирается в стену: принцип Парето подсказывает оптимизировать 20% кода, где 80% времени, но затем срабатывает закон Амдаля — ускорив горячую часть, вы упираетесь в остальной код, который начинает доминировать во времени выполнения.

Еще миф: «Python медленный, потому что интерпретируемый». Интерпретация — лишь малая часть. Даже выражение p.x * 2 в C/C++/Rust — это загрузка, умножение, сохранение. В Python же нужно определить тип p, вызвать getattribute(), распаковать p.x и 2, выполнить операцию с учетом перегрузок и протоколов, упаковать результат, выделить память и т.д. Это диктуют семантика и динамичность языка, не способ исполнения.

Статические типы

С распространением тайпингов слышно: «теперь компиляторы могут пропускать лишнее и считать напрямую». Пример:

def add(x: int, y: int) -> int:
    return x + y

print(add(2, 3))

Но аннотации не применяются во время выполнения, и можно вызвать:

print(add('hello ', 'world'))  # type: ignore

Чекер доволен, но семантика сложения уже другая. Аннотации бесполезны для оптимизации и скорости, если их не гарантирует рантайм. Более того, в Python легально перегружать операции, меняя поведение в рантайме, что разрушает предпосылки для агрессивных оптимизаций.

• Обсуждение сосредоточено на мифах о скорости Python: динамичность языка, непредсказуемость типов и плохая кэш-локальность мешают компиляторам и JIT достигать производительности системных языков без компромиссов по совместимости и простоте.
• Многие отмечают, что JIT и спекулятивное выполнение помогают на «хэппи-пате», но становятся хрупкими: небольшие изменения кода могут срывать оптимизации и резко просаживать скорость.
• Популярные пути ускорения — PyPy, Numba, Pythran, mypyc, а также перенос «горячих» участков в C/C++/Rust или использование DSL/субсетов (SPy); однако граница вызовов и динамика Python часто «съедают» выгоды.
• Отмечают альтернативы и эволюцию: Mojo как супермножество Python с статикой и компиляцией, возможное сосуществование компиляторов рядом с CPython вместо «Python 4».
• Критики указывают, что популярность Python не доказывает его производительность; многие реальные «тормоза» — это не CPU, а I/O и сеть, где помогают async и масштабирование.
• Скептики считают, что «быстрым» Python не станет без отказа от ключевых динамических свойств (примерно как в JS — оптимизации на общий случай, но с ограничениями); часть участников предлагает оставлять Python для скриптинга и клеевого кода.
• Вопросы многопоточности, старта интерпретатора и GIL остаются проблемными; параллельно обсуждают идеи «final»-квалификаторов, иммутабельности и GPU/параллельных подходов, но признают их практические ограничения.