Лабораторная работа 3. GIL: почему потоки не ускоряют CPU-код

Время на работу: 2 пары. Зависимости: лабы 1–2.

Цель работы

Экспериментально исследовать GIL (Global Interpreter Lock) и научиться обходить его тремя способами: процессы, освобождающие GIL C-функции (hashlib), мультипоточность вне GIL (превью sys._is_gil_enabled).

Теория

Что такое GIL

GIL — мьютекс в CPython, разрешающий исполнять байт-код Python только одному потоку процесса в каждый момент. Один интерпретатор — один «держатель» GIL.

Зачем он нужен: упрощает реализацию CPython (счётчики ссылок, внутренние структуры не защищены отдельными замками) и делает однопоточный код быстрым. Потоки в CPython — настоящие потоки ОС, но байт-код Python они исполняют по очереди.

Как поток получает процессор: держатель GIL обязан отпускать его периодически (по умолчанию каждые ~5 мс, sys.getswitchinterval()), и при блокирующих вызовах (sleep, чтение сети/диска).

Следствия

Тип задачи	Потоки	Почему
I/O-bound	ускоряют почти идеально	GIL отпускается на время ожидания
CPU-bound (чистый Python)	НЕ ускоряют	GIL: байт-код исполняется по очереди
CPU-bound (C-код внутри)	МОГУТ ускорять	C-функция может отпустить GIL

Третий пункт — самый интересный: библиотеки на C (hashlib, zlib, numpy во многих операциях) во время длинных вычислений отпускают GIL, и потоки работают по-настоящему параллельно. Тонкость: GIL отпускается на время одного вызова C-функции. Если блоки маленькие (4 КБ), вызовы слишком короткие и GIL тут же забирается обратно — ускорения не будет. Блоки ≥ 256 КБ (в работе — 1 МБ) дают честный параллелизм. В лабе это демонстрирует hashlib.

Свободнный threading (Python 3.13+, превью)

Начиная с CPython 3.13 существует экспериментальная сборка без GIL (free-threaded). В обычном CPython можно проверить, включён ли GIL: sys._is_gil_enabled(). В работе — короткое ознакомление, не основное.

Проверка GIL в эксперименте

Метод: фиксированная CPU-работа W. Замеряем T(1), затем ту же работу на p потоках. Ускорение S = T(1)/T(p):

S ≈ 1 → GIL не отпускался (чистый Python);
S ≈ p → GIL отпускался (C-код, sleep).

Задание

CPU-задача — из вашего варианта (common.tasks), ядро kernel работает на чистом Python. Заполните solution.py:

measure_cpu_threads(task_name, params, p_list) — для каждого p: последовательный запуск (p=1, база) и запуск CPU-задачи на p потоках (ThreadPoolExecutor, каждый поток — свой кусок). Вернуть {p: время}. Убедиться, что checksum совпадает с последовательным.
measure_gil_release(p_list, block_size, blocks_per_part) — то же, но работа — SHA-256 над готовыми блоками байтов (освобождает GIL). Фиксированный общий объём W = blocks_per_part * max(p_list) блоков по block_size байт (os.urandom), делится между p потоками. Вернуть {p: время}, проверять checksum.
gil_status() — вернуть (python_version, gil_enabled) через sys._is_gil_enabled() (если атрибута нет — GIL включён).
main() — таблицы ускорений для обоих случаев + график S(p).

Ожидаемые результаты

Чистый Python: S(4) ≈ 0.9–1.1 (замедление из-за переключений GIL).
SHA-256 на блоках 1 МБ: S(4) ≈ 2–4 (реальный параллелизм).
SHA-256 на блоках 4 КБ: S(4) ≈ 0.8 — GIL не успевает отпускаться. Попробуйте оба размера блоков и объясните разницу — это ядро работы.
Разница между «чистый Python» и «hashlib 1 МБ» — и есть GIL.

Важно про честность замеров

объём работы при любом p одинаковый (проверка checksum);
time_call(..., repeats=3), берём лучшее;
следите, чтобы данные hashing-задачи были крупными блоками (в банке задач так и сделано).

Контрольные вопросы

Что такое GIL и зачем он в CPython?
Почему time.sleep в 100 потоках не «съедает» процессор, а 100 считающих потоков работают как один?
Почему hashlib.sha256 ускоряется потоками, а sum по списку — нет?
Что изменится в Python 3.13+ free-threaded сборках? Найдите статус PEP 703.
Как проверить в вашем эксперименте, что работа распределена честно?

Что сдаётся

solution.py + отчёт: таблица S(p) для чистого Python и для hashlib, график с обеими кривыми и «идеальной» прямой, вывод: когда потоки полезны. Ответы на контрольные вопросы.

Критерии оценки

Пункт	Баллы
Корректный замер чистого Python (S ≈ 1)	2
Корректный замер hashlib (S(p) > 1.5 при p=4)	2
`gil_status` и версия Python в отчёте	1
График с тремя кривыми	2
Анализ и ответы на вопросы	3

Типичные ошибки

Слишком мелкие блоки для hashlib (4 КБ): S ≈ 0.8, а не 3+. GIL отпускается на время одного вызова — вызовы должны быть долгими (блоки ≥ 256 КБ).
Разный объём работы при разных p — обязательно проверяйте checksum.
Замер на ноутбуке без питания — турбо-частоты скачут, S(p) «плавает».

7.5 KiB Raw Permalink Blame History Unescape Escape