【发布时间】:2011-06-07 19:26:14
【问题描述】:
我有一个创建迷宫的小程序。它使用了很多集合(默认变体,它是不可变的,或者至少用作不可变的)。
程序会计算 30 个尺寸不断增加的迷宫。对 (1 到 30) 使用 for 理解
自从有了最新版本的并行集合框架,我想给它一个新版本,希望能获得一些性能提升。
这失败了,当我调查了一下时,我发现了以下内容:
在不调用任何远程并行程序的情况下运行时,我的机器的 4 个内核中的每一个内核仍然显示出大约 30% 的处理器负载。
当我将范围 1 到 30 替换为 (1 到 30).par CPU 负载在所有内核上上升到大约 80%(这是我的预期)。迷宫完成的顺序或多或少是随机的(这是我所预料的)。所有迷宫的总时间保持不变。
将一些内部使用的集合替换为它们的并行计数器部件似乎确实有效果。
我现在有两个问题:
为什么我的 4 个核心都在旋转,虽然没有任何东西并行运行。
程序仍然需要相同时间的可能原因是什么,无论是否并行运行。没有明显的其他瓶颈,但 CPU 周期(没有 IO,没有网络,通过 -Xmx 设置的大量内存)
对此有何想法?
【问题讨论】:
-
你应该做一个不超过一页的例子并编译。否则只是过多的猜测。唯一可能在您不做任何事情的情况下同时运行的是垃圾收集器。您的程序是否创建了很多在创建后很快就会被垃圾收集的对象?这在函数式编程风格中很常见......
-
是的,我想确实会创建很多对象,所以 GC 可能是一个不错的选择。我将激活一些日志记录,看看结果如何。
-
我确实看起来我没有获得任何性能提升,因为我正在等待 GC
标签: scala collections parallel-processing