Python GIL убивает многопоточность или можно обойтись

[eelvis]

Пишу сервис на Python 3.11, который параллельно обрабатывает входящие JSON-запросы и делает CPU-тяжёлые вычисления — нормализация данных, агрегация по большим массивам. Запустил ThreadPoolExecutor с 8 воркерами, мониторю через htop — все ядра простаивают, реально работает одно. Читал про GIL, но так и не понял: это вообще решаемо без переписывания на другой язык?

[cohenst1]

GIL блокирует именно CPU-bound задачи в потоках — это фундаментальное ограничение CPython. Для твоего кейса нужен ProcessPoolExecutor вместо ThreadPoolExecutor: каждый процесс получает свой интерпретатор и свой GIL. Примерно так: from concurrent.futures import ProcessPoolExecutor; with ProcessPoolExecutor(max_workers=8) as ex: results = list(ex.map(process_item, data)). Накладные расходы на сериализацию через pickle есть, но для тяжёлых вычислений это окупается.

[rburr]

Ещё вариант — NumPy и SciPy. Большинство их операций реализованы на C и освобождают GIL на время выполнения. Если твоя агрегация ложится на векторные операции numpy, можешь получить реальный параллелизм даже в потоках, без смены архитектуры. Проверь, можно ли переписать узкое место под np.sum / np.mean / np.vectorize.

[solidity2024]

Python 3.13 наконец-то добавил экспериментальный режим без GIL (--disable-gil / free-threaded build). Но это пока не продакшн, у меня на синтетических тестах были странные краши при интенсивном shared state. Следи за PEP 703, там всё расписано. Для серьёзного проекта сейчас я бы не рисковал.

[gdgdgd]

Смотри ещё в сторону multiprocessing.shared_memory если нужно шарить большие массивы между процессами без лишней сериализации — появилось в 3.8. Для агрегации по numpy-массивам это реально спасает: создаёшь SharedMemory, оборачиваешь в np.ndarray в каждом процессе и работаешь напрямую. Выигрыш по памяти и времени старта ощутимый.

[mstrbates]

Честно говоря, если задача реально CPU-bound и масштабирование критично — рассмотри Rust-расширение через PyO3. Звучит страшно, но на практике написать одну функцию на Rust и подключить её как .so за день вполне реально. У нас так сделано для парсинга — 40x ускорение по сравнению с чистым Python.

[Mcstorm]

Ещё момент: убедись, что задача действительно CPU-bound, а не I/O-bound. Если процессы ждут базу или сеть — asyncio даст больше, чем любые потоки и процессы. Профилируй сначала через py-spy или cProfile, потом уже выбирай инструмент.

[bun8]

ProcessPoolExecutor — правильное направление, но есть нюанс: если JSON-запросы идут с внешнего источника, сериализация данных через pickle на каждый запрос может съесть весь выигрыш от параллелизма, особенно при больших объёмах. Стоит замерить конкретно overhead pickle до и после — иногда оказывается, что узкое место переехало, а не исчезло.

[pleki]

@rburr, про NumPy — хорошая мысль, но np.vectorize это обёртка над Python-циклом, GIL она не освобождает. Реальный параллелизм в потоках дают только нативные операции типа np.sum, np.dot, np.einsum — те, что уходят в BLAS/LAPACK. Так что перед переписыванием стоит проверить конкретную операцию: если она сводится к этим примитивам — работает, если это кастомная логика с циклами — нет.