Как Scala 2.9 параллельные коллекции работают за кулисами?

Scala 2.9 введены параллельные коллекции. Это действительно отличный инструмент для определенных задач. Однако, как они работают внутри, и могу ли я влиять на поведение/конфигурацию?

Какой метод они используют для определения оптимального количества потоков? Если меня не устраивает результат, есть ли какие-либо параметры конфигурации для настройки?

Мне не только интересно, сколько потоков действительно создано, меня также интересует способ распределения фактической работы между ними. Как собираются результаты и сколько магии происходит за кулисами. Проверяет ли Scala, если коллекция достаточно велика, чтобы воспользоваться параллельной обработкой?

Ответ 1

Вкратце, есть два ортогональных аспекта распараллеливания ваших операций:

Степень, в которой ваша коллекция делится на куски (например, размер кусков) для параллелизуемой операции (например, map или filter)
Количество потоков, используемых для базового пула fork-join (на котором выполняются параллельные задачи)

Для # 2 это управляется самим пулом, который обнаруживает "идеальный" уровень parallelism во время выполнения (см. java.lang.Runtime.getRuntime.availableProcessors)

Для # 1 это отдельная проблема, а API параллельных коллекций scala выполняет это через концепцию кражи работы (адаптивное планирование). То есть, когда выполняется определенная работа, рабочий попытается украсть работу из других рабочих очередей. Если ни один из них недоступен, это свидетельствует о том, что все процессоры очень заняты, и, следовательно, необходимо выполнить большую часть работы.

Aleksandar Prokopec, который внедрил библиотеку, рассказал в этом году ScalaDays, который скоро будет в сети. Он также дал отличный разговор на ScalaDays2010, где он подробно описывает, как операции разделяются и повторно соединяются ( есть ряд проблем, которые не сразу очевидны и некоторые прекрасные кусочки умности там тоже!).

Более полный ответ доступен в PDF, описывающий API параллельных коллекций.