Закон дырявых абстракций и GIL в python⁠⁠

Давным давно Джоел Спольски рассказал о "законе дырявых абстракций" (оригинал от 2002 года). В современном мире, чтобы починить проблему, часто надо уметь работать на уровень ниже текущего уровня абстракции. Проблема может быть с compose, docker, конкретной библиотекой, python, операционной системой, сетью, железом... Чем больше абстракций вы знаете, тем больше вероятность, что вы сможете решить проблему следующего уровня.

Нельзя в один момент освоить десяток нужных инструментов и абстракций. Нужно плавно расширять используемый инструментарий. Освоили git? Ни строчки кода далее без него. Научились тестам? В каждом проекте их нужно писать с самого начала. Теперь Docker в копилке? Применяем, если это уместно. Чем больше опыта в разных технологиях, тем вы сильнее как специалист.

Расскажу о своём опыте. В статье как расширить технический кругозор я делился, что для ориентирования в технологиях я постоянно читал хабр (2010-2015 года, самый расцвет технического контента там). Пришёл ко мне коллега со следующим вопросом. Я, говорит, выгружаю строю граф друзей в социальной сети, для этого массово скриптом на python выгружаю оттуда списки всех друзей и складываю в mongodb. Запускаю выборку на N человек на 1 потоке — скрипт работает 60 секунд. Запускаю на 10 потоках — скрипт работает 70 секунд. Мне надо N увеличить и запуститься на сутки, но какого чёрта увеличение числа процессоров замедляет выполнение?  Где проблему искать?

Это питон тормозит?

В монге проблемы?

С компом что-то не так?

Социальная сеть меня банит?

Сеть тормозит?

Где вообще искать беду?

А я просто знал ответ. Прочитал накануне статью про GIL в python. На вики она выглядит так. Если кратко, то из-за потоковой небезопасности кода на Си, который внутри всех стандартных библиотек питона, интерпретатор физически работает на одном ядре, а многопоточность реализована с блокировками. Это не важно для IO-bound задач (когда код ждёт внешних данных), но критична для CPU-bound задач (когда реально надо все ядра использовать).

Для починки всего-то и надо, что заменить модуль многопоточности threading.Thread на многопроцессность multiprocessing.Process. Теперь работают 10 независимых процессов, которые делают своё черное дело. У них нет связи (общего адресного пространства), которое есть у потоков. Но в этой задаче связь и не нужна была, процессу выдавался пул адресов для анализа.

И теперь 60 секунд на 1 ядре превратилось в 10 секунд на 10 ядрах. Да, не в 10 раз ускорилось, но это вполне годное ускорение. А ещё можно посмотреть, как делают рядом и воспользоваться топовым инструментом.

В телеграм-канале разбираем разные нюансы из жизни разработчика на Python и не только — python, bash, linux, тесты, командную разработку.