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

[timur_nova63]

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

[lera_cache57]

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

[egor_real]

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

[elena7809]

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

[konstantin5861]

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

[netvue4299]

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

[vlad_rust]

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