Pull to refresh

Comments 7

Это всё-таки не универсальный ответ.


На CPU-bound задачах лучше утилизировать все ядра, причём, желательно минимизировать количество переключений контекста. Для этого обычно лучше всего подходит количество ядер = количество потоков.


А для IO-bound задач надо смотреть, что это за IO, какой планировщик используется в системе, и прочее… Вот тут только бенчмарк, заранее что-то сказать нельзя.


UPD: увидел, что это описано в последнем абзаце, согласен.

Ну, на самом-то деле все обычно еще интереснее. Это у вас один пул на приложение, а если их будет несколько (а их будет — потому что некоторые фреймворки их будут создавать, не спрашивая у вас)? Ну плюс все остальное, что уже изложили...

В этом и прелесть commonPool в java — все добропорядочные фреймворки для CPU-bound задач должны использовать именно его, а не создавать дополнительные пулы. Это позволяет снизить количество принудительных переключений контекста.

Я боюсь что это в общем случае невозможно. Во-первых, насколько я помню, common pool появился в 8-ке, а просто ForkJoin — раньше. Так что вполне может существовать кучка фреймворков, написанных иначе.


А во-вторых, все равно бывают требования, которые противоречат общему пулу. Причем тривиальные — наличие одновременно пакетных и интерактивных задач, например. Или даже просто интерактивных — для них обычно наплевать, что процессор недогружен до 100%, главное чтобы время реакции было хорошим.

А на 2-ядерной машине стандартные параллельные методы вообще имеют смысл?
Конечно имеют. Чтобы убедиться можно добавить в этот бенчмарк копипасту parallelSort из JDK но только строго ту её часть, где merge sort и прогнать эту копипасту на пуле из одного потока, сравнить с пулом из двух.
Я наверно плохо спросил.
Если commonPool имеет размер N-1, то как поведут себя базовые функции на 2-ядернике?
Sign up to leave a comment.