Кто реально гонял Python 3.13t free-threaded? У меня одиночный поток просел на 40%

[k8s2000]

Собрал 3.13t (free-threaded), погонял свой парсер на одном ядре — стало почти в полтора раза медленнее чем обычный 3.13. Это норма или я что-то накосячил со сборкой?

[Austkin]

Норма. Atomic refcount + per-object locking на каждой операции даёт оверхед даже когда поток один. На релизе обещали ~40% регрессии в single-thread, ты прям в учебник попал. В 3.14t починили специализирующий интерпретатор, там просадка уже 5-10%.

[navspy]

У меня обратная картина: numpy-тяжёлый пайплайн на 8 потоках дал х2.8 против single. GIL реально мешал. Но да, чисто питоновый код на одном ядре платит налог. Жди 3.14t или ставь оба билда.

[jpearce]

Спасибо, реально помогло! Полдня бился, а оказалось всё просто.

[kernel_veteran]

Попробовал — работает, но пришлось ещё права на папку поправить.

[seniorsamurai]

40% просадка на одном ядре — это ожидаемо и задокументировано самим CPython-тимом. Free-threaded сборка отключает ряд оптимизаций которые были завязаны на GIL как на гарантию: например, некоторые path в object allocation и reference counting теперь атомарные операции вместо простых инкрементов. По бенчмаркам pyperformance CPython-команда называет цифру ~10-15% для типичного single-thread кода, но на реальных парсерах с большим количеством создания/удаления объектов просадка может быть и 30-40% — это нормально для 3.13t.

[sammy99]

Реальный выигрыш от 3.13t начинается только если у тебя CPU-bound работа которую можно честно распараллелить через threading.Thread или concurrent.futures.ThreadPoolExecutor — без GIL потоки теперь действительно параллельны на нескольких ядрах. Если твой парсер IO-bound (сеть, диск), то и на обычном 3.13 asyncio решает лучше. Для CPU-bound парсинга попробуй взять 4 потока на 3.13t и замерить суммарную пропускную способность — вот там должен быть плюс.

[navspy]

Ещё важный момент: библиотеки которые используют C-расширения (lxml, numpy, etc.) могут вести себя непредсказуемо на free-threaded сборке если их C-код сам не потокобезопасен. Для парсера это актуально. Проверяй через python3.13t -c 'import sys; print(sys._is_gil_enabled())' что GIL действительно выключен — иногда расширения при загрузке его принудительно включают обратно и ты гоняешь просевший код без профита.