VA
Оно конечно будет работать, но всё равно выглядит грязно
thread_pool = ThreadPoolExecutor()
await loop.run_in_executor(
thread_pool,
partial(processor, param)
)
Size: a a a
2020 November 12
F🍭
F🍭
выглядит нормально
VA
Я не про то, что ты можешь три строки написать. А про то, что у тебя в асинхронном коде вдруг появляется контролируемый поток.
F🍭
если задача тяжёлая, то это нормально
F🍭
в этом нет ничего плохого
VA
если задача тяжёлая, то это нормально
Да, ведь потоки пайтона так классно приспособлены для CPU-Bound операций)
F🍭
в таком случаи ты выбрал не тот язык
F🍭
для своей задачи
VA
в таком случаи ты выбрал не тот язык
В таком случае ты не видишь дальше своего носа.
А представь, что мы из асинхронного кода породим не поток, а процесс)
Тогда шедулер Операционной системы сам поселит его на ядро и сбалансирует по нагрузке)
А в асинхронке у тебя будет только io корутина, которая будет смотреть на pipe процесса) Ни блокировок, ни потоков, и максимально доступные ресурсы для процесса (ведь это отдельный процесс)
А представь, что мы из асинхронного кода породим не поток, а процесс)
Тогда шедулер Операционной системы сам поселит его на ядро и сбалансирует по нагрузке)
А в асинхронке у тебя будет только io корутина, которая будет смотреть на pipe процесса) Ни блокировок, ни потоков, и максимально доступные ресурсы для процесса (ведь это отдельный процесс)
VA
никаких исполнений по 5мс от GIL
F🍭
справедливо
VA
Все задачи на пайтоне решаются прекрасно и я выбрал тот язык. Надо просто нормально планировать и писать нормально, а не "на потоках, потмоу что это просто в три строки"
F🍭
я просто не выполнял настолько тяжёлые единовременные задачи, чтобы доходить до мультипроцессоринга
🤔T
я просто не выполнял настолько тяжёлые единовременные задачи, чтобы доходить до мультипроцессоринга
Процессоринга лол
ЕП
В таком случае ты не видишь дальше своего носа.
А представь, что мы из асинхронного кода породим не поток, а процесс)
Тогда шедулер Операционной системы сам поселит его на ядро и сбалансирует по нагрузке)
А в асинхронке у тебя будет только io корутина, которая будет смотреть на pipe процесса) Ни блокировок, ни потоков, и максимально доступные ресурсы для процесса (ведь это отдельный процесс)
А представь, что мы из асинхронного кода породим не поток, а процесс)
Тогда шедулер Операционной системы сам поселит его на ядро и сбалансирует по нагрузке)
А в асинхронке у тебя будет только io корутина, которая будет смотреть на pipe процесса) Ни блокировок, ни потоков, и максимально доступные ресурсы для процесса (ведь это отдельный процесс)
В мемориз, спасибо
VA
я просто не выполнял настолько тяжёлые единовременные задачи, чтобы доходить до мультипроцессоринга
4 задачи по "производству гифок" на потоках выполняются примерно на 40% дольше, чем они же на процессах. Замерял на Raspi 4 с 4 ядрами.
Значения были от 20% до 55% (там инфлюкс фонил ещё)
Но считаю примерно 40%
Значения были от 20% до 55% (там инфлюкс фонил ещё)
Но считаю примерно 40%
ЕП
4 задачи по "производству гифок" на потоках выполняются примерно на 40% дольше, чем они же на процессах. Замерял на Raspi 4 с 4 ядрами.
Значения были от 20% до 55% (там инфлюкс фонил ещё)
Но считаю примерно 40%
Значения были от 20% до 55% (там инфлюкс фонил ещё)
Но считаю примерно 40%
Используется стандартный multiprocessing или какая-то обёртка вокруг него? Именно для вынесения на процессы
VA
Всё же придётся показывать) Момент
VA
Используется стандартный multiprocessing или какая-то обёртка вокруг него? Именно для вынесения на процессы
Я наговнокодил такую функцию. Её задача - запустить CMD процесс с переданными аргументами и следить за stdout и stderr