Экспериментальный JIT Python будет удалён

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

JIT добавил в CPython Brandt Bucher в начале 2024 года. Обычно такой крупный компонент должен был бы попасть в релиз только после одобрения советом standards-track PEP. Bucher выступил с презентацией (видео на YouTube, слайды) о JIT на встрече ключевых разработчиков Python и объявил о намерении объединить функциональность—но не написал и не подал PEP для её одобрения. Члена совета Thomas Wouters, также выступавшего в роли менеджера релиза Python 3.13, побудили это сделать.

Bucher и Savannah Ostrowski разработали PEP 744 («JIT Compilation»), который оказался информационным PEP—то есть просто предоставлял информацию сообществу Python и не представлял формального согласия продолжать работу над функцией. LWN освещала обсуждение PEP 744 в апреле 2024 года, позже описала доклад Bucher о JIT на PyCon US 2024 и последующий доклад на PyCon US 2025.

Предложение PEP

Работа над JIT продолжалась на основе PEP 744 до июня, когда совет выдвинул официальный запрос разработчикам JIT создать standards-track PEP. Можно было бы задаться вопросом, как это сделал Antoine Pitrou, почему совет решил пора говорить и просить новый PEP. По словам Wouters, не было единого события, спустившего триггер, но совет обсуждал тему уже какое-то время и указал, что хочет убедиться, что JIT не помешает другим проектам. Идёт работа над тем, чтобы JIT хорошо уживался с инструментами профилирования, отладки и мониторинга. Есть также внешние JIT-ы (вроде CinderX), похожие на JIT компоненты (вроде Numba и PyTorch compile), и обсуждение о tier 3 JIT. Совет дождался завершения бета-релиза Python 3.15 чтобы дать понять, что мы хорошо относимся к статусу quo для 3.15.

Совет запросил PEP, который обосновал бы JIT как поддерживаемую, экспериментальную часть CPython: его гарантии, обязательства по поддержке и влияние на переработчиков. Совет установил дедлайн в шесть месяцев на подачу и одобрение PEP; если это не произойдёт, совет потребует удалить код JIT из основной ветки CPython.

Bucher, Ostrowski и Ken Jin разработали PEP 836 и опубликовали его на форуме Python 3 июля для обсуждения сообществом. Он вызвал немало дискуссий—часть положительных, часть критических. Одна из ключевых тем в комментариях, вроде этого от Wouters и этого от Mark Shannon, заключалась в том, что черновик должен был бы быть двумя отдельными PEP. Shannon, например, считал, что PEP должен охватывать только цели принятия работы JIT и должен исключить детали реализации. Было также много запросов на дополнительную информацию.

Bucher немного возразил на предложение раскрыть в два PEP, а Ostrowski защищала структуру PEP как она есть. Рассказ о целях, как в PEP, без возможности поделиться планом и всем, что мы обдумали, делал бы меня неудобно. Для меня цели без плана—это не совсем цели.

Когда мы в последний раз смотрели на эту тему в сентябре, обсуждение PEP замедлилось без обязательства разрабатывать новые PEP или формального заявления от совета. Последнее слово совета в то время, в виде резюме его встречи 6 августа, было то, что он встретился с авторами PEP и обсуждал состояние PEP и отвечает ли он на вопросы, которые СС задал в запросе на PEP.

Экспериментирование в основной ветке

21 сентября Wouters опубликовал заявление совета руководителей (без Ostrowski, которая в данный момент является членом совета, но не участвовала, так как соавтор PEP), которое резюмировало его позицию. Заявление говорило, что PEP ответил на все вопросы, которые были выделены в запросе совета, хотя возможно некоторые менее убедительно, чем другие.

Совет хотел пояснить, что не ищет критерии, которым JIT должен соответствовать, чтобы быть поддерживаемой функцией, или считаться ли её таковой. Напротив, совет оценивал, должен ли JIT продолжать оставаться экспериментом в основной ветке CPython.

Часть проблемы с разрешением экспериментирования в основной ветке—отсутствие единого проекта и неопределённость, которую испытывают разработчики ядра, мейнтейнеры пакетов и пользователи, по мере того как экспериментирование меняет поведение и API-поверхность.

Совет сказал, что PEP был недостаточно конкретен в отношении планов поддержки, критериев производительности и слишком расплывчат или слишком оптимистичен в ряде других областей. Заявление включило список из десяти пунктов вещей, которые совет хотел бы увидеть либо расписанными в PEP, либо по крайней мере обсуждёнными и отклонёнными. Список совета выражал беспокойства, начиная от воздействия на память до безопасности. Например, по теме паритета платформ совет хотел убедиться, что JIT предназначен для лёгкого внедрения на новых платформах. Требовалась гарантия, что проектирование JIT не будет привязано к конкретной платформе и не потребует специфических для платформы знаний для поддержки.

Другой областью, на которую обратил внимание совет, было воздействие на пользователей. Сказано, что PEP был чрезмерно оптимистичен насчёт видимых пользователю различий с включённым JIT. Было много случаев, когда пользователи зависят от идиосинкразии в дизайне интерпретатора, как мы видели в других реализациях Python или даже между основными версиями Python, и требовалось уточнение, как эти различия будут обработаны. Будут ли они рассматриваться как баги, как будут обработаны ситуации, если различие в поведении неизбежно, и так далее.

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

PEP 836 определил вехой совместимости первого релиза-кандидата Python 3.17—который ожидается примерно в августе 2028—в ходе которого будут запущены тестовые наборы топовых пакетов PyPI, чтобы увидеть, сломал ли JIT их. Совет хотел это сроки значительно передвинуть. Мы думаем, что это намного, намного слишком поздно, и проверка совместимости должна быть постоянным и непрерывным процессом, начиная как можно скорее.

Совет также беспокоился о том, что решения в проектировании JIT принимаются без критической оценки большей группой разработчиков, в итоге ответственных за разработку, поддержку и поддержку [CPython]. В итоге, сказано, PEP 836 в основном отвечает на вопросы, которые мы задали, отсутствуют какие-либо недостающие части, но требуется более полное обсуждение этих вопросов, чтобы оценить поддержку сообществом и консенсус, прежде чем нас попросят вынести суждение по этому PEP.

Jin ответил несколько дней спустя, благодаря совет за подробную обратную связь и сказал, что группа будет работать над его рекомендациями.

Отозвано

После обсуждения, кажется, авторы PEP решили не продолжать добиваться одобрения совета. 19 октября Ostrowski (также менеджер релиза Python 3.16 и 3.17) объявила, что PEP отозван:

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

Barry Scott спросил, означает ли это, что работа над JIT остановлена. Brett Cannon ответил, что работа будет остановлена в основном репозитории, но будет зависеть от сообщества, продолжится ли работа где-то ещё. Dunc Graham предложил, что могла быть время для альтернативного PEP, представленного до дедлайна совета. Cannon сказал, что это маловероятно, так как все люди, активно ведущие JIT, либо были авторами того PEP, либо контрибьюторами в него.

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