pmap и количество потоков

Question

user=> (.. Runtime getRuntime availableProcessors)
2

И оценивая этот пример: http://clojuredocs.org/clojure_core/clojure.core/pmap#example_684 Я получаю

user=> (time (doall (map long-running-job (range 4)))) 
"Elapsed time: 12000.621 msecs"
(10 11 12 13)
user=> (time (doall (pmap long-running-job (range 5))))
"Elapsed time: 3000.454 msecs"
(10 11 12 13 14)
user=> (time (doall (pmap long-running-job (range 32))))
"Elapsed time: 3014.969 msecs"
(10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 3839 40 41)
user=> (time (doall (pmap long-running-job (range 33))))
"Elapsed time: 6001.526 msecs"
(10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42)

Интересно, почему я должен пройти 33, чтобы ждать 33 сек. за результат. pmap create 2 (доступно для процессоров) + 2 потока, да? Полагаю, что когда пройдет (диапазон 5), он будет выполнен через 6 секунд. Почему это отличается?

Answer 1

На самом деле pmap не подчиняется пределу «Процессоры + 2».Это результат того, как обычный макрос map и future работают:

1. future использует пул кэшированных потоков без ограничения размера;

2. map создает последовательность фрагментов, то есть последовательность, в которой всегда используется 32 элемента за раз, даже если вызывающая сторона фактически потребляет только несколько элементов в начале фрагмента.

Конечным результатом является то, что фьючерсы в pmap запускаются параллельно в блоках по 32.

Обратите внимание, что это не является нарушением контракта, указанного в pmap Документация.Код, с другой стороны, может привести к тому, что он полагает, что предполагается, что предел «процессоров + 2» будет соблюдаться - как если бы map было написано наивно.На самом деле, pmap вполне может предшествовать переходу на фрагментированные последовательности, хотя я не совсем уверен, это было давно.