Попробовал. map, если использую 2-4-6-8 процессов, то превзойти скорость обработки одним процессом я так и не смог (используя операцию hash(x)). Заменил операцию на x**2 и при 8 процессах получилось на 40% быстрее чем одним процессом. apply и get на самом деле по умолчанию асинхронные? Я правильно вас понял?
мне стоило сделать на этом акцент в самом видео - в моих примерах, если мы используя один процесс обработали 100 числе за 1 секунду, а потом включили пул и мэпом прошли тоже за 1 секунду в 4 потока, то это не значит, что производительность плохая, это значит, что мы за 1 секунду обработали в 4 раза больше данных, везде ведь range(n) передаётся apply и map под капотом асинхронные, при их вызове мы получаем apply_aync().get() и map_async().get() под капотом (рад, что вы досмотрели)))
@@pythonclinic "apply и map под капотом асинхронные, при их вызове мы получаем apply_aync().get() и map_async().get()" вот это прям совсем было неожиданно. Мир не будет прежним )))
@@pythonclinic Не совсем понял. Когда мы задействуем 4 процесса и используем pool.map(some_func, range(100)) обрабатывается в 4 раза больше данных, то есть 400?
Почему imap запрашивает из iterable объекта, первые 180 значений в начале программы. Хотя в моем пуле 20 процессов, а в таргет функции я написал sleep(очень много секунд). Я ожидал следующего поведения, запросится 20 значений из iterable, все процессы отработают, начнут запрашивать next(iterable) и.т.д Короче я не понимаю что за кучу значений imap достает заранее, это какой то запас на будущее? Чтоб процессы не проставили ни секунды когда будут готовы получить следующие входные аргументы?
всё верно, можно сказать, что это запас на будущее, но вообще вы увидели именно работу очереди задач внутри процесса, в которую как раз и добавились эти значения вместе с целевыми функциями (хоть они и спят в начале)
в теории может быть такое, отожрать памяти пул в случае чего действительно сможет знатно (но не до переполнения конечно), но это в том числе цена за параллельность
@@pythonclinic из альтернатив остаётся только применение apply_asinc, с хардкодом контроля количества создаваемых задач для процессов? Мне нужно реализовать обработку очень большого файла, результат обработки нужно писать в другой файл.
Привет на 21:28 подразумевается ведь параллельное выполнение?
в этом примере да, можно назвать параллельным
Попробовал. map, если использую 2-4-6-8 процессов, то превзойти скорость обработки одним процессом я так и не смог (используя операцию hash(x)). Заменил операцию на x**2 и при 8 процессах получилось на 40% быстрее чем одним процессом.
apply и get на самом деле по умолчанию асинхронные? Я правильно вас понял?
мне стоило сделать на этом акцент в самом видео - в моих примерах, если мы используя один процесс обработали 100 числе за 1 секунду, а потом включили пул и мэпом прошли тоже за 1 секунду в 4 потока, то это не значит, что производительность плохая, это значит, что мы за 1 секунду обработали в 4 раза больше данных, везде ведь range(n) передаётся
apply и map под капотом асинхронные, при их вызове мы получаем apply_aync().get() и map_async().get() под капотом (рад, что вы досмотрели)))
@@pythonclinic "apply и map под капотом асинхронные, при их вызове мы получаем apply_aync().get() и map_async().get()" вот это прям совсем было неожиданно. Мир не будет прежним )))
@@pythonclinic Не совсем понял. Когда мы задействуем 4 процесса и используем pool.map(some_func, range(100)) обрабатывается в 4 раза больше данных, то есть 400?
Почему imap запрашивает из iterable объекта, первые 180 значений в начале программы. Хотя в моем пуле 20 процессов, а в таргет функции я написал sleep(очень много секунд).
Я ожидал следующего поведения, запросится 20 значений из iterable, все процессы отработают, начнут запрашивать next(iterable) и.т.д
Короче я не понимаю что за кучу значений imap достает заранее, это какой то запас на будущее? Чтоб процессы не проставили ни секунды когда будут готовы получить следующие входные аргументы?
всё верно, можно сказать, что это запас на будущее, но вообще вы увидели именно работу очереди задач внутри процесса, в которую как раз и добавились эти значения вместе с целевыми функциями (хоть они и спят в начале)
@@pythonclinic А что если генератор будет йаилдить очень большие объекты? Не переполнится ли память от того, что пул пытается запастись на будущее
в теории может быть такое, отожрать памяти пул в случае чего действительно сможет знатно (но не до переполнения конечно), но это в том числе цена за параллельность
@@pythonclinic из альтернатив остаётся только применение apply_asinc, с хардкодом контроля количества создаваемых задач для процессов?
Мне нужно реализовать обработку очень большого файла, результат обработки нужно писать в другой файл.
я бы посоветовал посмотреть в сторону потоков на самом деле
Насколько я понимаю, использовать асинхронность в нынешний век быстрых процессоров, по большей части нужно лишь в операциях IO.
помимо IO асинхронность применяется при запросах по http например, или при работе с пользовательским интерфейсом
По каким то причинам у меня даже при n=2 всегда разные pid процесса, как будто балансировка не работает. python3.10
так наоборот же сработала) нагрузка распределилась сразу же, первый проц не успел обработать, и подключился второй
@@pythonclinic проц вроде бы не слабый, удивительно, что не успевает обработать 2 запроса, там где у вас 10 обрабатывает
возможно специфика архитектуры конкретной модели процессора, трудно сказать