Почему CPU-bound задачи неэффективно распараллеливать потоками в Python?

Определение

CPU-bound задача — это задача, где узкое место — процессорные вычисления (парсинг, криптография, обработка изображений, численные расчёты).

Причина: GIL в CPython

Определение:
GIL (Global Interpreter Lock) — механизм, который защищает внутренние структуры интерпретатора CPython и обеспечивает, что байткод Python в одном процессе выполняется только одним потоком одновременно.

Что это означает на практике:

1. Вы создаёте несколько потоков

2. Они по очереди получают доступ к интерпретатору

3. Реально вычисления выполняются «по одному»

В итоге:

• прироста скорости нет или он минимальный

• появляется overhead на переключение потоков

Почему для I/O-bound всё иначе

Когда поток ждёт:

• сетевой ответ

• диск

• таймаут

он часто освобождает управление, и другой поток может выполняться. Поэтому потоки дают выигрыш там, где много ожидания.

Мини-демонстрация идеи

CPU-bound код в потоках:

from threading import Thread

def work():
    s = 0
    for i in range(10_000_000):
        s += i

threads = [Thread(target=work) for _ in range(4)]
for t in threads: t.start()
for t in threads: t.join()

Обычно это не даст ускорения пропорционально количеству потоков.

Что делать вместо потоков

Смысловой выбор зависит от задачи:

1. Multiprocessing / ProcessPoolExecutor

   • каждый процесс со своим GIL

   • реальное использование нескольких ядер

2. Нативные библиотеки

   • NumPy / OpenCV могут отпускать GIL и считать в C

3. Перенос вычислений

   • отдельный сервис, очередь задач, воркеры

(про альтернативы подробно будет в следующем вопросе по списку)

Краткий вывод

Потоки в CPython почти не ускоряют CPU-bound из-за GIL: параллелизм получается «логическим», но не вычислительным. Для вычислений чаще используют процессы или нативные библиотеки.