Hacker News Digest

Добро пожаловать на 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/параллельных подходов, но признают их практические ограничения.