Python 3.14 без GIL — реально быстрее или маркетинг?

[boblee]

Обновился до Python 3.14, включил free-threaded сборку (python3.14t). Запустил свой старый скрипт с поиском простых чисел в нескольких потоках — ускорение реально ощутимое, раньше 3.7 секунды, теперь 0.35. Но на одиночном потоке заметил небольшой регресс, вроде 7-8%. Кто уже щупал в продакшене? Есть ли смысл переходить на free-threaded или проблема с расширениями всё ещё не решена? У меня проект использует numpy и несколько C-extension модулей.

[Farkle]

Проблема с расширениями — это основной стопор прямо сейчас. numpy в free-threaded режиме официально поддерживается начиная с 2.1, но далеко не все популярные пакеты пересобраны. Если хоть одно расширение не поддерживает, CPython тихо включает GIL обратно и ты даже не замечаешь. Проверяй через sys._is_gil_enabled() — вот где люди теряют время, думают что запустили без GIL, а там всё то же самое.

[Austkin]

Тестировал на своём ML-пайплайне с обработкой текстов — дал 3.2x на батчевой предобработке данных (независимые задачи на 8 ядрах). Но памяти жрёт примерно на 20% больше, это важно если у вас ограниченные VPS-ки или аренда облака в рублях считается. На нашем деплое в Hetzner с 16GB RAM это ок, но на мелких инстансах надо смотреть.

[oldschoolpanic]

Честно говоря, для большинства типичных задач на бэкенде всё это не важно. Если у вас I/O-bound веб-сервис на FastAPI — вы и так нормально живёте с asyncio. Free-threading нужно тем, у кого CPU-bound параллелизм и при этом нельзя вынести в multiprocessing из-за накладных расходов на IPC. Это довольно узкий кейс.

[depechie]

Я наоборот жду когда экосистема устаканится. Запускать в продакшене экспериментальное поведение интерпретатора — это риск. PEP 779 говорит что 3.14 уже 'официально поддерживается', но 'официально' и 'стабильно в вашем конкретном проекте' — разные вещи. Подожду год, пока основные либы подтянутся.

[cohenst1]

@Farkle, Вот конкретный рецепт для проверки у себя: ставишь python3.14t через pyenv (pyenv install 3.14t-dev), создаёшь venv, и перед запуском любого кода делаешь import sys; assert not sys._is_gil_enabled(). Если ассерт падает — значит какой-то импорт заставил GIL включиться. Можно ещё PYTHON_GIL=0 выставить как переменную окружения и смотреть предупреждения при импорте. У меня таким образом нашёл что старый модуль для работы с БД молча всё портил.

[rawgoblin]

Для data engineering задач в нашей конторе (Минск, аутсорс на европейских заказчиков) уже начали мигрировать. Ускорение на ETL-пайплайнах реальное. Но главная засада — это не GIL, а то что все ваши коллеги должны понять что теперь race condition возможен там, где его раньше не было. Обучение команды стоит дороже самого перехода.

[arsa4soles]

@oldschoolpanic, плюсую жирно. сидишь на fastapi с asyncio и постгресом, узкое место это бд и сеть, гил там вообще не при делах. вся шумиха про free-threading а реальный профит у узкой прослойки cpu-bound задач где multiprocessing неудобен из-за ipc. для веба это маркетинг чистой воды.

[Macrano]

@boblee, 7-8% регресс на одном потоке это не баг, это плата за снятие гила, счетчики ссылок теперь атомарные. в ранних сборках 3.13 было под 30-40% просадки, так что 8 это уже неплохо ужали. но для однопоточных скриптов ты просто теряешь, нет смысла включать t-сборку там.

[jwil1440]

@rawgoblin, вот про race condition это самое важное во всем треде, остальные про numpy да про память, а ты про людей. народ думает снял гил и полетели, а на деле list.append из двух потоков теперь стрельнет так что неделю дебажить. ревью придется гонять параноидально, и да обучение команды дороже самого апгрейда выходит.