ИИтог

Python: JIT-компилятор CPython, вероятно, удалят после отзыва PEP 836

инструментыРедакция ИИтогHacker News🔥74Рейтинг ИИтог74Влияние60Новизна40Релевантность90Неожиданность65Участники55Достоверность90

Экспериментальный JIT-компилятор (just-in-time, компиляция «на лету»), добавленный в CPython в 2024 году в релизе 3.13, судя по всему, уходит. В июне руководящий совет Python (steering council) объявил, что приостанавливает работу над JIT в основной ветке CPython, пока не будет принято предложение по развитию Python (PEP), которое снимет опасения по поддержке и совместимости, задаст чёткие метрики успеха и сроки завершения. Чтобы выполнить эту просьбу, авторы JIT подготовили PEP 836 («JIT Go Brrr: The Path to a Supported JIT Compiler for CPython»), но после нескольких месяцев обсуждения отозвали его. По словам автора материала в LWN, разработка некогда многообещающего проекта сейчас, похоже, остановлена.

История началась в начале 2024 года, когда Брандт Бучер (Brandt Bucher) добавил JIT в CPython. Обычно такая крупная функция попадает в код только после одобрения советом PEP стандартного пути (standards-track), но Бучер лишь выступил с докладом на спринте core-разработчиков и объявил о намерении влить код. Его подтолкнул к написанию PEP член совета Томас Вустерс (Thomas Wouters), который тогда был ещё и релиз-менеджером Python 3.13. Бучер и Саванна Островски (Savannah Ostrowski) подготовили PEP 744 («JIT Compilation»), но он информационный: он лишь сообщает сообществу сведения и не фиксирует формального согласия продолжать работу над функцией.

В июне совет формально попросил написать PEP стандартного пути. Вустерс объяснил, что единого повода не было: совет давно обсуждал тему и хотел убедиться, что JIT не мешает другим проектам, работе над совместимостью с инструментированием, отладкой и профилированием, внешним JIT (например, CinderX), смежным проектам вроде Numba и torch compile в PyTorch, а также обсуждению JIT третьего уровня (tier 3). Совет подождал бета-релиза Python 3.15, чтобы дать понять, что статус-кво для 3.15 его устраивает. От PEP требовалось обосновать JIT как поддерживаемую, неэкспериментальную часть CPython: гарантии, обязательства по сопровождению, влияние на тех, кто пересобирает и распространяет Python. Срок на подачу и принятие PEP, шесть месяцев; иначе совет потребует удалить код JIT из основной ветки.

Бучер, Островски и Кен Цзинь (Ken Jin) написали PEP 836 и 3 июля опубликовали его на форуме Python. Реакция была разной, от одобрения до критики. Главная тема комментариев, в том числе у Вустерса и Марка Шеннона (Mark Shannon): текст стоило разделить на два PEP. Шеннон считал, что PEP должен описывать только цели принятия JIT, без деталей реализации. Просили и дополнительных сведений. Бучер возражал против разделения, а Островски защищала структуру: по её словам, «цели без планов за ними, это вообще не цели», и описывать цели, не показав плана, ей было бы неуютно.

К сентябрю обсуждение затихло, формального заявления совета не было: после заседания 6 августа совет лишь сообщил, что встретился с авторами и обсуждает, отвечает ли PEP на его вопросы. 21 сентября Вустерс опубликовал заявление совета (без Островски, которая входит в совет, но не участвовала как соавтор PEP). Совет признал, что PEP отвечает на все выделенные в запросе вопросы, «хотя, возможно, одни менее убедительно, чем другие». Он уточнил, что оценивает не критерии статуса поддерживаемой функции, а вопрос, стоит ли JIT оставаться экспериментом в основной ветке. Проблема такого эксперимента, отсутствие единого дизайна и неопределённость для core-разработчиков, сопровождающих пакеты и пользователей, когда эксперимент меняет поведение и API.

По мнению совета, PEP недостаточно конкретен в планах поддержки и критериях производительности, а в ряде областей слишком расплывчат или чересчур оптимистичен. Заявление содержало список из десяти пунктов, которые совет хотел видеть либо проработанными в PEP, либо хотя бы обсуждёнными и отвергнутыми: от влияния на память до безопасности. По паритету платформ совет хотел гарантий, что дизайн JIT легко переносится на новые платформы и не требует специфичных для платформы знаний для сопровождения. Описание различий в поведении при включённом JIT названо «чрезмерно оптимистичным»: пользователи зависят от особенностей интерпретатора, и нужно пояснить, считаются ли расхождения ошибками и что делать, если их не избежать. Безопасность названа «недостаточно проработанной областью»: совет предложил обсудить её с группой реагирования на проблемы безопасности Python и сделать проверку безопасности частью критериев поддерживаемого статуса. PEP 836 привязывал проверку совместимости (прогон тестов самых популярных пакетов PyPI) к первому релиз-кандидату Python 3.17, ожидаемому примерно в августе 2028 года. Совет счёл это «слишком, слишком поздно»: такая проверка должна идти непрерывно и начаться как можно раньше. Совет также беспокоило, что решения по дизайну JIT принимались без критического разбора более широкой группой разработчиков. Итог: PEP «в основном отвечает на вопросы», но совет хотел больше обсуждения, чтобы оценить поддержку сообщества до вынесения решения. Кен Цзинь через несколько дней поблагодарил за отзыв и пообещал поработать над замечаниями.

19 октября Островски (она же релиз-менеджер Python 3.16 и 3.17) объявила об отзыве PEP: совет «справедливо задаёт высокую планку», а у авторов нет личных ресурсов, чтобы довести текущую версию до конца. Авторы по-прежнему верят в техническое направление PEP, включая поддержку free-threaded-сборок и фронтенд на уровне методов, и сохраняют оптимизм насчёт потенциала JIT в CPython. Референсная реализация будет доступна и привязана по ссылке к отозванному PEP.

На вопрос Барри Скотта, остановлена ли работа, Бретт Кэннон ответил: в основном репозитории, да, а продолжится ли она в другом месте, решать сообществу. Данк Грэм предположил, что альтернативный PEP ещё можно успеть подать до дедлайна, но Кэннон счёл это маловероятным: все, кто активно вёл работу над JIT, были либо авторами, либо участниками этого PEP. По оценке автора LWN, JIT довольно скоро удалят из основной ветки CPython, чтобы возможные проблемы от удаления были выявлены в начале цикла разработки Python 3.16. Неясно, собираются ли прежние разработчики вообще продолжать работу или проект подхватят другие, если найдётся интерес сообщества. Автор написал им с просьбой прокомментировать, но на момент публикации ответа не получил.

Ключевые факты

  • Авторы PEP 836 (Бучер, Островски, Цзинь) отозвали его 19 октября; в июне совет Python приостановил работу над JIT в основной ветке до принятия такого PEP и дал шесть месяцев, иначе код JIT нужно удалить.
  • Совет в заявлении от 21 сентября признал, что PEP отвечает на заданные вопросы, но потребовал проработать десять пунктов: поддержка, производительность, влияние на пользователей, память, безопасность, паритет платформ.
  • Проверку совместимости PEP 836 планировал на первый релиз-кандидат Python 3.17 (ожидается около августа 2028 года); совет назвал это «слишком, слишком поздно».
  • Бретт Кэннон: работа в основном репозитории будет остановлена, продолжение вне него, на усмотрение сообщества; альтернативный PEP маловероятен.
  • По оценке LWN, JIT довольно скоро удалят из основной ветки CPython; точной даты нет, намерения авторов продолжать работу неясны.

Почему это важно

JIT-компилятор был самой заметной попыткой ускорить стандартный интерпретатор CPython изнутри: он вошёл в Python 3.13 в 2024 году. Теперь проект фактически останавливается в основной ветке, не из-за технической неудачи, а потому что у авторов не хватило ресурсов выполнить требования управления проектом. Эпизод показывает, что для крупной экспериментальной функции в CPython недостаточно рабочего кода: нужны PEP, обязательства по сопровождению, проверка совместимости и безопасности.

Кому это важно

Разработчикам CPython и сопровождающим пакетов, которые следят за изменениями поведения и API при экспериментах в основной ветке. Тем, кто пересобирает и распространяет Python (в PEP это названо «redistributors»). Авторам смежных проектов, внешних JIT вроде CinderX, Numba, torch compile в PyTorch. Пользователям Python, которые надеялись на встроенный JIT в будущих версиях.

Как это применить

Источник не даёт практических инструкций и цифр по производительности JIT. Из сказанного: референсная реализация будет опубликована и привязана ссылкой к отозванному PEP, так что заинтересованные смогут изучить её и развивать вне основной ветки. Кто полагается на JIT в сборках из основной ветки, должен учитывать, что код, вероятно, скоро будет удалён, точные сроки не названы.

Можно ли доверять

Материал LWN подробный, со ссылками на цитаты из публичного обсуждения и заявления совета. Однако вывод об удалении JIT «довольно скоро», оценка автора LWN, а не объявленное решение. Автор написал авторам PEP с просьбой уточнить планы, но на момент публикации ответа не получил. Оригинал, материал только для подписчиков LWN.

Риски и подводные камни

Точные срок и версия удаления JIT не названы; формального решения совета после отзыва PEP источник не приводит. Неясно, продолжат ли прежние разработчики работу вне основной ветки и найдётся ли кто-то, кто подхватит проект. Годы дат обсуждения (3 июля, 6 августа, 21 сентября, 19 октября) в тексте не указаны.

«Руководящий совет справедливо задаёт высокую планку для предложения такого масштаба, и мы не чувствуем, что у нас достаточно личных ресурсов, чтобы довести текущую версию до конца.»

— Саванна Островски, объявление об отзыве PEP 836, 19 октября