На прошлой неделе разработчики CPython выпустили CPython 3.14.0b1. А на этой неделе в Питтсбурге, штат Пенсильвания, начинается конференция PyCon 2025. Оба эти события знаменуют собой важную веху в делах, связанных с разработкой, выпуском и доведением до стабильного состояния релизов free-threaded Python (Python с поддержкой свободной многопоточности — с отключённым механизмом GIL).

Перед вами рассказ о первом годе развития этого проекта, и о той роли, которую мы, сотрудники Quansight, в нём сыграли. А именно, речь идёт о том, что мы обеспечили возможность экспериментального использования сборок Python с поддержкой свободной многопоточности. Применялись они в реальных продакшн-системах, поддерживая процессы, которые основаны на сложных наборах зависимостей.
Введение: зачем мы работаем над «внедрением в массы» free-threaded Python?
Применение Python со свободной многопоточностью открывает дорогу к использованию полной вычислительной мощи современных компьютеров, где обычным делом стала поддержка многоядерных CPU и GPU. При применении Python-сборок с включённым механизмом GIL полноценная реализация алгоритмов, задействующих все доступные вычислительных ресурсы, требует «танцев с бубнами» и тщательной настройки систем. Python-модуль threading
нередко не используется для решения подобных задач из-за того, что GIL не даёт эффективно масштабировать параллельные вычисления. Вместо этого многие прибегают к модулю multiprocessing
, но создание новых процессов — это дорогое удовольствие. Кроме того, обмен данными между процессами часто требует создания копий данных, а для этого нужны немалые ресурсы. В новых условиях многопоточные программы не нуждаются в подобном, так как потоки могут, без дополнительных усилий, совместно пользоваться одними и теми же данными.
Учитывая вышесказанное — пакет, в дистрибутиве которого присутствует скомпилированный код, не будет, в неизменном виде, поддерживать free-threaded Python. Любой пакет, в состав которого входит нативный код (это относится ко многим Python-пакетам), необходимо проверить. Проверить нужно возможность сборки пакета, а так же то, что он не страдает от проблем, связанных с потокобезопасностью, возникновение которых невозможно в сборках, где включён механизм GIL.
Отключение GIL требует глубоких структурных изменений интерпретатора CPython. И, аналогично, полная поддержка Python-сборок со свободной многопоточностью в существующих пакетах требует решения структурных проблем, которые до настоящего времени, не считались особенно серьёзными. Нечто вроде использования глобального состояния при реализации C-расширений, что раньше делалось ради удобства, или из соображений производительности, теперь не относится к безопасным решениям. Дело в том, что теперь механизм GIL не способен предотвратить одновременный доступ разных Python-процессов к глобальному состоянию. Это может привести к неопределённому поведению программ из-за возникновения гонки данных. Такие же проблемы с потокобезопасностью могут возникнуть и в ходе работы с модулем threading
, даже при включённом механизме GIL. Но этот механизм, чаще всего, предотвращал появление подобного. Применение free-threaded Python превращает решение таких проблем в гораздо более насущную и срочную задачу.
Главные достижения
Вместе с командой, которая занимается разработкой среды выполнения Python в Meta, мы внесли значительный вклад в то, чтобы обеспечить поддержку free-threaded Python в немалом количестве пакетов и проектов. В их число входят следующие:
Инструменты для упаковки проектов и для управления ими, такие как
meson
,meson-python
,setup-python
(из GitHub Actions),packaging
,pip
иsetuptools
.Генераторы привязок, вроде
Cython
,pybind11
,f2py
иPyO3
.Базовые пакеты экосистемы PyData наподобие
NumPy
,SciPy
,PyArrow
,Matplotlib
,pandas
,scikit-learn
иscikit-image
.Самые популярные, по количеству загрузок, зависимости с PyPI. Среди них —
Pillow
,PyYAML
,yarl
,multidict
иfrozenlist
.
Мы, кроме того, сейчас наблюдаем за популярными проектами, которые пока не поддерживают free-threaded Python. В их число входят CFFI
, cryptography
, PyNaCl
, aiohttp
, SQLAlchemy
и grpcio
. То же касается и популярных библиотек для организации машинного обучения — таких как safetensors
и tokenizers
.
Официальные участники разработки CPython из нашей команды внесли в проект несколько важных улучшений, которые будут включены в CPython 3.14.
Python-модуль
warnings
теперь, по умолчанию, потокобезопасен при работе на free-threaded Python-сборках. В сборках, где включён механизм GIL, этот модуль можно сделать потокобезопасным, прибегнув к конфигурационному параметру, или воспользовавшись флагом командной строки при запуске Python.Были исправлены значительные проблемы
asyncio
, связанные с потокобезопасностью. Наши тесты производительности указывают на значительное улучшение масштабирования параллельного выполнения кода с использованиемasyncio
и пула потоков.Проведена полная переработка механизмов потокобезопасности в модуле
ctypes
.Была значительно улучшена производительность сборщика мусора, работающего в среде с поддержкой свободной многопоточности.
Члены нашей команды помогли в реализации схемы отложенного подсчёта ссылок с использованием интерпретатора, поддерживающего свободную многопоточность в Python 3.14.
Были реализованы несколько специализаций для адаптивного специализированного интерпретатора и проведены оптимизации, которые довели однопоточную производительность CPython 3.14 без GIL до уровня, близкого к производительности сборки, в которой механизм GIL включён.
В проект было внесено множество исправлений небольших ошибок, а так же — множество улучшений, касающихся потокобезопасности.
Мы, кроме того, обобщив наш опыт, подготовили всеобъемлющее руководство по поддержке free-threaded Python в существующих приложениях и пакетах. Надеемся, написанная нами документация станет ценным ресурсом для авторов «длинного хвоста» Python-пакетов, которые в ближайшие годы решено будет обновить под поддержку свободной многопоточности.
Подробности об этом можно почитать здесь, в публикации команды из Meta.
В каком состоянии находится экосистема free-threaded Python?
В прошлом году, в это же время, когда вышел Python 3.13.0b1, гораздо больше Python-пакетов было, так или иначе, полностью неработоспособно на Python-сборке, поддерживающей свободную многопоточность. Попытка установки, с помощью команды pip install, чего-то, не являющегося наипростейшим пакетом без зависимостей, или пакетом, обладающим исключительно Python-зависимостями, почти наверняка завершалась сообщениями об ошибках сборки. Большинство этих неприятностей не были связаны с какими-то фундаментальными проблемами. Они возникали из-за неподдерживаемых опций, применяемых по умолчанию, или из-за того, что разработчики пакетов писали их, ожидая определённого поведения системы в каких-то мелочах, а сборка, поддерживающая свободную многопоточность, эти ожидания не оправдывала.
Вместе с программистами, которые занимаются поддержкой пакетов, а так же — вместе с теми, кто вносит вклад в их разработку, мы исправили многие из этих проблем. Сегодня ситуация выглядит куда лучше, чем год назад. Готовясь к выпуску Cython 3.1.0, где имеется официальная поддержка free-threaded Python, мы, кроме того, помогли исправить одну из самых важных причин проблем со сборкой проектов.
Сейчас мы работаем над пакетами, в состав которых входит скомпилированный код, но авторы которых пока не опубликовали wheel-файлы, поддерживающие свободную многопоточность в Python. Вы можете следить за нашими успехами, заглянув в эту таблицу, обновляемую вручную, или воспользоваться автоматически обновляемым трекером Хуго ван Кеменаде.
Важнейшие задачи
По состоянию на сегодняшний день free-threaded Python готов к тому, чтобы с ним можно было бы поэкспериментировать. Нам нужно больше отчётов о проблемах с производительностью и об ошибках, отчётов от тех, кто использует новшества в реальных проектах. Эти новшества способны дать значительный рост производительности, в особенности — в тех задачах, которые используют пакет multiprocessing
, и, выполняя которые, приходится подвергать систему дополнительной нагрузке, характерной для этого подхода. Но, при этом, многие Python-пакеты всё ещё нуждаются в серьёзной проверке, которая способна выявить проблемы с потокобезопасностью. Во многих Python-библиотеках используются изменяемые структуры данных, которые не будут правильно работать, если одновременно модифицировать их из нескольких потоков. Кроме того, такие библиотеки либо совсем не обладают документацией, касающейся их потокобезопасности и производительности в многопоточной среде, либо имеют документацию весьма скромного объёма.
Как и при любом изменении таких масштабов, которое воздействует на целую экосистему пакетов некоего языка программирования, мы сталкиваемся со случаями, когда у авторов популярных Python-пакетов просто нет ресурсов, необходимых для обеспечения поддержки свободной многопоточности. Это особенно актуально для крупных устаревших пакетов, код которых хорошо понимают лишь немногие — а порой вообще никто. Нам, сообществу Python-разработчиков, нужно понять эти проблемы, присутствующие в наших деревьях зависимостей проектов, и работать в направлении обеспечения стабильной поддержки важнейших пакетов.
Как нам помочь?
Взгляните на руководство для тех, кто хочет внести вклад в проект, которое мы добавили в основную документацию по free-threaded Python. Мы наблюдаем за проблемами, касающимися всей экосистемы Python, и работаем над текстом руководства по свободной многопоточности в Python в GitHub-репозитории free-threaded-compatibility, входящем в состав репозиториев Quansight Labs.
О, а приходите к нам работать? 🤗 💰
Мы в wunderfund.io занимаемся высокочастотной алготорговлей с 2014 года. Высокочастотная торговля — это непрерывное соревнование лучших программистов и математиков всего мира. Присоединившись к нам, вы станете частью этой увлекательной схватки.
Мы предлагаем интересные и сложные задачи по анализу данных и low latency разработке для увлеченных исследователей и программистов. Гибкий график и никакой бюрократии, решения быстро принимаются и воплощаются в жизнь.
Сейчас мы ищем плюсовиков, питонистов, дата-инженеров и мл-рисерчеров.