Как параллельные коллекции Scala 2.9 работают за кулисами?
Scala 2.9 представила параллельные коллекции. Они действительно отличный инструмент для определенных задач. Тем не менее, как они работают внутри, и могу ли я влиять на поведение / конфигурацию?
Какой метод они используют, чтобы выяснить оптимальное количество потоков? Если я не удовлетворен результатом, есть ли какие-либо параметры конфигурации для настройки?
Меня не только интересует, сколько потоков на самом деле создано, меня также интересует, как фактическая работа распределяется между ними. Как собираются результаты и сколько магии происходит за кулисами. Проверяет ли Scala, является ли коллекция достаточно большой, чтобы получить выгоду от параллельной обработки?
1 ответ
Вкратце, есть два ортогональных аспекта того, как ваши операции распараллеливаются:
- Степень, в которой ваша коллекция разбивается на куски (т.е. размер кусков) для распараллеливаемой операции (такой как
mapили жеfilter) - Количество потоков, используемых для базового пула fork-join (в котором выполняются параллельные задачи)
Для #2 это управляется самим пулом, который обнаруживает "идеальный" уровень параллелизма во время выполнения (см. java.lang.Runtime.getRuntime.availableProcessors)
Для #1 это отдельная проблема, и API параллельных коллекций Scala делает это через концепцию кражи работы (адаптивное планирование). То есть, когда определенная часть работы выполнена, работник попытается украсть работу из других рабочих очередей. Если ни один не доступен, это указывает на то, что все процессоры очень заняты, и, следовательно, большая часть работы должна быть взята.
Александар Прокопец, который внедрил библиотеку, выступил с докладом на ScalaDays этого года, который скоро будет онлайн. Он также выступил с большой речью на ScalaDays2010, где он подробно описывает, как операции разделяются и объединяются (есть ряд проблем, которые не сразу очевидны, и есть некоторые прекрасные кусочки сообразительности!).
Более полный ответ доступен в PDF, описывающем API параллельных коллекций.