问题描述
user=> (.. Runtime getRuntime availableProcessors)
2
并评估此示例：我得到
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秒内执行。为什么不同？
I wonder why I have to pass 33 to wait 33 sec. for result. pmap create 2 (available processors) + 2 threads, yes? I suppose that when pass (range 5) it will be executed in 6 sec. Why it is different?
推荐答案
实际上 pmap 不遵守处理器+ 2 。这是常规映射和未来宏工作方式的结果：
Actually pmap does not obey the "processors + 2" limit. That's a result of the ways in which the regular map and the future macro work:
-
未来使用没有大小限制的缓存线程池;
futureuses a cached thread pool which has no size limit;
map 产生一个分块序列，即一次强制32个元素，即使只有一个
map produces a chunked sequence, that is, one which is always forced 32 elements at a time, even if only a handful at the beginning of a chunk are actually consumed by the caller.
最终的结果是期货 pmap 是以32块为单位并行启动的。
The ultimate result is that futures in pmap are launched in parallel in blocks of 32.
请注意，这不违反 pmap 的docstring。另一方面，代码可能会导致一个人相信它的意图是处理器+2限制被尊重 - 如果 map 天真地写。事实上， pmap 可能早于分块seq的移动，虽然我不确定，一段时间。
Note that this is not in violation of the contract specified in pmap's docstring. The code, on the other hand, might lead one to believe that it was intended that the "processors + 2" limit be respected -- as it would if map was written naively. In fact, pmap might well predate the move to chunked seqs, although I'm not really sure, it's been a while.
这篇关于pmap和线程计数的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！