RI
Не будет в паралель CPU молотить больше работы чем вмешается в Default пул
Size: a a a
2020 May 12
AN
Ну threadpool starvation не решается добавлением потоков. Ну часть проблемы решается конечно, но в целом пропускная способность упадет
Если есть два разных тред пула, то они не будут интерферировать. Все будет тормрозить равномерно.
BP
Не будет в паралель CPU молотить больше работы чем вмешается в Default пул
+
VP
Какой смысл плодить потоки? Если Default уже забит computation work, то новые потоки не разгрузят его, а наоборот
Если какая-то работа выполняется несколько секунд, зачем ждать её завершения тем, кому её результат не нужен? А ждать будут все.
Такое лучше в фон уносить, и дать вытесняющей многозадачности сделать своё дело.
Такое лучше в фон уносить, и дать вытесняющей многозадачности сделать своё дело.
AN
Не будет в паралель CPU молотить больше работы чем вмешается в Default пул
так никто не говорит, что оно будет быстрее. Просто если вы весь Default забьете своим блоком, то остальное вообще встанет, а не просто будет медленно работать
AN
Если какая-то работа выполняется несколько секунд, зачем ждать её завершения тем, кому её результат не нужен? А ждать будут все.
Такое лучше в фон уносить, и дать вытесняющей многозадачности сделать своё дело.
Такое лучше в фон уносить, и дать вытесняющей многозадачности сделать своё дело.
+
VP
Ну threadpool starvation не решается добавлением потоков. Ну часть проблемы решается конечно, но в целом пропускная способность упадет
Я же сразу написал, что проблема в latency
BP
так никто не говорит, что оно будет быстрее. Просто если вы весь Default забьете своим блоком, то остальное вообще встанет, а не просто будет медленно работать
Ну так это уже тестировать, мерять. Шипилева на вас нет
RI
так никто не говорит, что оно будет быстрее. Просто если вы весь Default забьете своим блоком, то остальное вообще встанет, а не просто будет медленно работать
Проблема в том, что есть шанс в таком случае замедлить все, сильнее чем последовательнее выполнить
AN
Ну так это уже тестировать, мерять. Шипилева на вас нет
Я просто постоянно с этой штукой сталкиваюсь. Если есть много тяжелых вычислений, они блокают Default и все кроме UI зависает.
VP
Почему мимо ?
Потому что он расширяется не по тем правилам, которые нужны для вычислительных задач
AN
Проблема в том, что есть шанс в таком случае замедлить все, сильнее чем последовательнее выполнить
Безусловно. Но если тяжелые вычисления сильно тяжелые, оно того стоит.
AN
Потому что он расширяется не по тем правилам, которые нужны для вычислительных задач
это я согласен, хотя в принципе вполне можно использовать.
AN
собсственно спор про кооперативную многозадачность vs вытесняющую многозадачность.
BP
Потому что он расширяется не по тем правилам, которые нужны для вычислительных задач
Ну если у вас реально высокие нагрузки то да он не подходит
RI
Тут скорее можно придумать что-то с приоритизацией задач, если в этих "тяжелых вычислениях" местами yieldы расставить
RI
И если появилась более приоритетная вычислительная задача, которая при этом еще и к latency чувствительная, то ее диспатчить, заменяя менее приоритетную задачу
VP
это я согласен, хотя в принципе вполне можно использовать.
Ну если например исходные данные делятся на много-много частей, и каждую обрабатывает своя корутина, которая запускается сразу, то IO даст плохой результат.
Мы же хотим, чтобы диспатчер сам решал, как параллелить?
Мы же хотим, чтобы диспатчер сам решал, как параллелить?
AN
Ну если например исходные данные делятся на много-много частей, и каждую обрабатывает своя корутина, которая запускается сразу, то IO даст плохой результат.
Мы же хотим, чтобы диспатчер сам решал, как параллелить?
Мы же хотим, чтобы диспатчер сам решал, как параллелить?
Ну тут уже очень много деталей. Я бы сказал, что свой пул - это всегда безопасный вариант.