分块输入与非分块输入的pmap并行级别不一致

Question

pmap代码为需要执行的map操作集创建了futures（map #(future %) coll），然后以显而易见旨在在任何给定时间只实现#CPUs+2个未完成futures的方式作用于该序列。对于非分块输入序列，它正是这样工作的，但当pmap接收到一个分块序列时，futures序列也会变成分块的。这导致当#CPUs+2窗口和块大小窗口交互时，会实现任意数量的futures。

pmap的文档字符串并没有承诺特定的并行级别，但我认为分块输入与非分块输入的不一致并行级别构成了一个bug。

Answer 1

由stu发表的评论

下一步深入查看pmap的人应该也可能需要考虑fork/join。

Answer 2

由jim.blomo发表的评论

fork/join是Java 7的功能。提出的补丁是否需要能够回退到Java 5的功能？

Answer 3

由jafingerhut发表的评论

关于Clojure/core团队的意见可能更具权威性，但我相信，随着最近基于jsr166代码的reduce增强，Clojure 1.5版本很可能需要Java 6或更高版本，不再支持Java 5。

Answer 4

由jim.blomo发表的评论

当工作受到CPU约束时，不要启动超过CPU核心的线程。目前（1.4版）pmap使用无界的线程池，所以分块序列将创建比预期更多的线程。最轻微的改变是使用固定大小的线程池（例如ForkJoinPool）。pmap与core.reducers的区别在于它是惰性的。这意味着线程池的submit模式是一次一个，而不是递归的fork/join模式。权衡包括

即使是对分块序列也要强制预览
- 不改变threadPool
- 违反分块，可能是出于某种原因

转移到固定大小线程池
- 减少分块序列上CPU密集型函数的竞争
- 增加I/O密集型函数的总实现时间

使用ForkJoinPool代替newFixedThreadPool进行固定线程池
- 自动和动态并行化
- 复杂的设置（选择Java 6与7的实现，与core.reducers共享池）

我认为使用传统的固定大小线程池是正确的选择。大多数时候，所有的pmap结果都会实现，因此我认为没有必要严格限制预览大小。这也是map决策的原因。由于我们没有使用ForkJoin的主要优势（递归工作队列），我认为在clojure.core中设置它是不值得的。

我将使用Agent/pooledExecutor作为固定大小的线程。

如果我有遗漏或误解，请告知。

Answer 5

由jim.blomo发表的评论

2012-05-28的pmap-chunking-862.diff使用固定大小线程池对pmap函数。

Answer 6

由jafingerhut发表的评论

2012年5月28日的patch pmap-chunking-862.diff自从2014年1月11日Clojure主分支上的最新提交后不再干净地应用。我认为唯一的问题是添加的测试已经改变了上下文行，如果有人想更新补丁，应该是一个快速的修复。

Answer 7

由jim.blomo发表的评论

感谢您的更新，Andy。这个月我会试着解决它。

Answer 8

参考：[https://clojure.atlassian.net/browse/CLJ-862](https://clojure.atlassian.net/browse/CLJ-862) （由 llasram 报告）