Scala 为什么使用并行集合不能更快？

我只是想测试一下并行集合，我使用了以下代码行（在REPL中）：

反对：

(1 to 100000).filter(BigInt(_).isProbablePrime(100))

但并行版本并不快。事实上，它甚至感觉有点慢（但我还没有真正测量）

有人对此有解释吗

编辑1：是的，我有一个多核处理器

---

编辑2：好的，我自己“解决”了这个问题。

isProbablePrime

的实现似乎是问题所在，而不是并行集合。我用另一个函数替换了

isProbablePrime

，以测试素数，现在我得到了预期的加速比。

对于顺序和并行范围，

过滤器将分别生成向量数据结构-a
向量
或a
ParVector

这是从范围集合生成的并行向量的一个已知问题-用于并行向量的转换器方法（如
过滤器
）不会并行构造向量

已经开发了一种解决方案，可以有效地并行构建向量，但尚未实现。我建议您提交一个文件，以便在下一个版本中对其进行修复。
并行性只有在让您获得更多硬件启动的情况下才会更快，而且它确实有开销。scala的设置是为了利用额外的内核吗？我不知道我必须设置任何东西。你有关于这个的更多信息吗？这里不需要配置；Scala查找可用的内核数量，并将代理工作到适当大小的Fork-Join池中。我认为这不是问题所在。例如，如果我做了一些事情，比如<代码>（1到10000）。PAR。过滤器（x= > {线程。睡眠（1）；真}）< /> >并行版本比顺序版本快得多。因此，并行执行似乎是可行的，但看起来isProbablePrime不能同时在多个线程中运行（无论出于何种原因）。这是真的——的确如此。但是，在这种情况下，处理每个元素所花费的时间远远大于构建
ParVector所需的时间（当前是按顺序完成的），因此您不会注意到创建向量所花费的时间。但是，
isProbablePrime
也应该并行执行，并行运行它的好处应该被最后的顺序构造所掩盖。我假设
isProbablePrime
有相当大的同步代码部分，因为我注意到的另一件事是，顺序版本最大化了一个内核，但并行版本相当平均地分配负载。我想我应该停止使用
isProbablePrime
来测试并行的东西：）是的，我刚刚实现了我自己的isPrime函数，在那里，并行版本要快得多。因此在我的例子中，
isProbablePrime
肯定是个问题，而不是scala本身的并行集合。我猜想，
isProbablePrime
的两个版本都做了大量的工作。你的问题仍然是合理的，我会说——如果你有一些计算上相当便宜的谓词，你最终会“感觉”到
ParVector
构造在性能方面的成本。
(1 to 100000).filter(BigInt(_).isProbablePrime(100))