CPython, GIL и когда 'быстрее как в C' вообще имеет смысл

core объяснить, почему popытка вручную оптимизировать структуру данных в стиле C не даст ожидаемого ускорения в типичном Python-коде, и определить, когда проблема реально требует другого решения (C-расширение, многопроцессность, другой алгоритм)

В C у вас есть прямой мысленный контракт: меньше выделений памяти, компактные структуры, ручное управление кэш-локальностью — и вы получаете предсказуемое ускорение. Это работает, потому что вы контролируете layout памяти, а компилятор транслирует это почти без потерь в машинный код. В Python этот контракт не работает — и не потому, что «Python медленный», а потому что модель исполнения принципиально другая.

CPython — эталонная реализация Python, написанная преимущественно на C, но это не единственная реализация (есть, например, PyPy, Jython); спецификация языка определяет семантику независимо от конкретного интерпретатора [18]. Семантика языка не гарантирует ту машинную модель, которую вы себе представляете из C: любой int, любой объект — это полноценная структура в куче, а не значение в типизированной ячейке; даже итерация по списку — это не обход контигуального массива примитивов, а обход последовательности ссылок на объекты. Попытка «уплотнить структуру» вручную (например, упаковать данные в кортеж вместо словаря, надеясь на C-подобный выигрыш от компактности) даёт эффект существенно меньший, чем в C, потому что накладные расходы интерпретации байткода и динамической диспетчеризации доминируют над экономией на layout.

Второй источник ложных ожиданий — GIL (Global Interpreter Lock). В стандартной сборке CPython только один поток исполняет байткод Python в любой момент времени, даже на многоядерной машине. Следствие: заводить threading.Thread для CPU-bound задачи (числовые вычисления, разбор данных в чистом Python) не даёт параллельного ускорения — потоки будут по очереди захватывать GIL, конкурируя за один ресурс. Для I/O-bound задач (сеть, диск) GIL освобождается на время ожидания системного вызова, поэтому threading/asyncio там работают эффективно — ключевое различие, которое C-программист по инерции игнорирует, ожидая, что «многопоточность = параллелизм» всегда, как это ближе к истине в C с pthreads.

sequenceDiagram
    participant T1 as Поток 1
    participant GIL
    participant T2 as Поток 2
    T1->>GIL: захватывает
    Note over T1: выполняет байткод
    T1->>GIL: отпускает (переключение)
    GIL->>T2: захватывает
    Note over T2: выполняет байткод
    T2->>GIL: отпускает

GIL допускает выполнение байткода Python только одним потоком в момент времени

Из этого следует практическая модель производительности: прежде чем оптимизировать «в стиле C», нужно определить характер проблемы и выбрать инструмент, соответствующий именно ей, а не пытаться вручную экономить байты внутри интерпретируемого кода.

flowchart TD
    Slow["Код работает медленно"] --> Q1{"CPU-bound или I/O-bound?"}
    Q1 -->|I/O-bound| IO["threading / asyncio:<br/>GIL освобождается на I/O"]
    Q1 -->|CPU-bound| Q2{"Можно сменить алгоритм<br/>или структуру данных?"}
    Q2 -->|Да| Algo["Сначала алгоритм/структуры,<br/>а не ручная 'C-оптимизация' layout"]
    Q2 -->|Нет| Q3{"Нужен параллелизм<br/>на нескольких ядрах?"}
    Q3 -->|Да| MP["multiprocessing /<br/>отдельные процессы"]
    Q3 -->|Нет| Ext["C-расширение / Cython /<br/>вызов уже быстрой C-библиотеки (напр. numpy)"]

Дерево решений при выборе способа ускорения Python-кода

Разобранный пример

C-программист видит горячий цикл, который обрабатывает миллион чисел через list, и вручную переписывает его на tuple, избегая промежуточных списков, рассчитывая на выигрыш «как от компактного массива в C». Замер timeit показывает лишь незначительную разницу — потому что доминирующая стоимость это интерпретация байткода на каждой итерации for, а не выбор list против tuple.

Правильный ход рассуждения: это CPU-bound числовая задача → сначала ищем алгоритмический выигрыш (можно ли векторизовать через numpy, где сам цикл выполняется в C-коде библиотеки, а не в интерпретаторе Python) → если да, замена for-цикла на numpy-операцию даёт выигрыш, которого ручная микро-оптимизация layout в чистом Python не даст.

import numpy as np

def slow_sum_squares(data):
    total = 0
    for x in data:
        total += x * x
    return total

def fast_sum_squares(data):
    arr = np.asarray(data)
    return int(np.sum(arr * arr))

Разница не в «более компактной структуре в Python», а в том, что цикл вообще перестал исполняться байткодом CPython.

Попробуй сейчас

Возьмите список из миллиона случайных целых чисел. Напишите два варианта подсчёта суммы квадратов: обычный for-цикл и вариант через sum(x*x for x in data) (генераторное выражение). Замерьте оба через python -m timeit или модуль time. Затем попробуйте третий вариант с threading (двумя потоками, каждый обрабатывает половину списка) и сравните время с однопоточным.

Ожидаемый результат: многопоточный вариант не станет быстрее однопоточного (а может оказаться медленнее из-за накладных расходов на переключение) — это и есть наблюдаемое следствие GIL для CPU-bound задачи.

Получилось, если…

Вы поняли модель, если можете для конкретной задачи за 10 секунд сказать: «это I/O-bound → threading/asyncio сработает» или «это CPU-bound → threading не поможет, нужен либо алгоритм/numpy, либо multiprocessing, либо C-расширение» — без запуска профилировщика, только по характеру задачи.

Вывод

GIL ограничивает параллелизм потоков для CPU-bound кода; для I/O-bound потоки/asyncio работают штатно. Ручная «C-оптимизация» структур данных в обычном Python-коде редко даёт заметное ускорение, потому что расходы интерпретатора доминируют — реальный выигрыш ищут в алгоритме, векторизованных библиотеках, multiprocessing или C-расширении, а не в layout памяти.

Check yourself