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

Такой вот костыль в питоне, о котором стоит знать :) Типа GIL - вынужденный хак, который повышает производительность однопоточного кода, но создаёт проблемы в многопоточном. Так как большинство скриптов реально однопоточные (или хотя бы IO-bound), то быстрая работа однопоточного кода считается более приоритетной.

Есть реализации интерпретатора питона без GIL, типа Jython или IronPython.

Как раз думал о tornado и twisted. Но они оба мимо меня прошли, только слышал их как "не продакш решения" тех лет.

Не говорю, что asyncio поможет. Хотя можно посмотреть на ProcessPoolExecutor, например

Тут даже вопрос, что именно коллега делал. Потому что параллельный скрапинг соц-сети не должно быть CPU-bound, но как раз IO-bound. Но раз фикс помог, что он где-то в CPU и GIL утыкался

Хороший опыт, спасибо

Всё верно, multiprocessing.Process был, поправил пост. Модуль subprocess нужен, если требуется внешние тулзы дёргать, в том числе скрипты на питоне. А для распараллеливания уровня функций в разных процессах нужен multiprocessing

Если нужно общее адресное пространство, то threading не избежать. Для multiprocessing приходится организовывать передачу данных каким-либо образом, потому что общей памяти нет.

Хм, кажется это был multiprocessing.Process, верное замечания. Попутал, т.к. недавно subprocess на sh переделывал в pet-проекте

Так есть много способов организовать связь между процессами. Это классические каналы, сокеты, брокер сообщений - тьма их. Да, накладные расходы могут быть выше, но надо смотреть на бутылочное горлышко конкретного случая.

Например, в https://t.me/devfm/101 рассматривалась статья, где для разных брокеров сообщений измерялись сетевые задержки. В случае kafka по сети сетевая задержка может быть порядка 20 мс и пропускной способностью в сотни mb/s. Вот тут сравнивают варианты передачи данных по пропускной способности https://www.baeldung.com/linux/ipc-performance-comparison , порядок токе сотни mb/s.

Понятно, что быстрее общей памяти не сделать. Но многопоточность ограничена одним сервером, а многопроцессность может горизонтально масштабироваться дальше. Так что мы имеем относительно узкий спектр задач, где один поток не справляется (мешает GIL), но сотня процессов не нужна (чтобы не вылезать за один сервер), при этом потоки настолько интенсивно друг с другом взаимодействуют, что варианты IPC недостаточны, и нужна общая память. Выглядит как редкий случай)

Ну, я даже задачу его точно не знаю, и не знаю что он внутри делал. Возможно, он через scrapy и делал. Но это не снимает вопроса GIL. По крайней мере, на stackoverflow пишут

The recommended way for working with scrapy is to NOT use multiprocessing inside the running spiders. The better alternative would be to invoke several scrapy jobs with the respective separated inputs.

А это приводит опять к вопросу многопоточности или многопроцессности

Тогда asyncio только-только зарождался и были только экспериментальные веб-фреймворки. Теперь то живём)

В соцсети. В то время было популярно скрапить разные площадки