1

我安装了适用于 Win64 的 Eclipse 3.7 版 JavaEE，然后按照手册 1.2 版中的 Ateji 安装说明进行操作。

我通过运行 I = J = 100000 的加速示例得到的结果：

PERFORMANCE COMPARISON BETWEEN SEQUENTIAL AND PARALLEL COMPREHENSIONS

sequential sum:
    `+ for (int i : I, int j : J) (i*j);
parallel sum:
    `+ for || (int i : I, int j : J) (i*j);
data size : I = 100000; J = 100000

Wait for the result...
sequential sum: mean time = 202 ms; standard deviation = 1 ms; ( 8473 8460 203 202 202 204 203 202 205 202 203 202 203 204 203 202 204 202 203 203 )
parallel sum: mean time = 2017 ms; standard deviation = 961.311 ms; ( 1787 1800 1790 1847 1457 1442 1698 1457 1455 1439 1467 4083 3239 1461 1458 1469 1470 1469 3077 4311 )

Speed up = 0.10014873574615767
Available processors = 8

我的处理器活动监视器显示 4 个内核确实用于并行任务。hello world 示例有效（“hello”和“world”以随机顺序打印）。我检查了 Ateji 手册的故障排除部分，一切都是正确的（我使用了 JDK 和 JRE 1.7）

问题可能来自哪里？谢谢！

4

1 回答 1

3

告诉我们这个令人惊讶的结果是你不应该依赖微基准。

在我的 4 核笔记本电脑上，我使用 Java6 VM（1.6.0_22-b04 HotSpot(TM) 64 位服务器）获得了预期的加速：

sequential sum: mean time = 383 ms; standard deviation = 83,319 ms;
parallel sum: mean time = 114 ms; standard deviation = 22,271 ms;
Speed up = 3.3596491228070176

在同一台机器上，我使用 Java7 VM（1.7.0_03-b05 HotSpot(TM) 64 位服务器）得到了您提到的令人惊讶的结果：

sequential sum: mean time = 7 ms; standard deviation = 0 ms;
parallel sum: mean time = 69 ms; standard deviation = 10,863 ms; 
Speed up = 0.10144927536231885

请注意两个 VM 版本之间的连续时间是如何除以 50 的！这绝对是一个强大的优化开始的迹象。

一个聪明的 VM 可以不做任何计算（时间 = 0ms），因为它可以静态地将总和的结果表示为一个简单的代数表达式。代码的并行版本中一定有一些东西会排除相同的优化，因此您会看到令人惊讶的结果。

确实，如果您将求和表达式更改为更现实的

    `+ for (int i : I, int j : J) (x[i]*y[j])

其中 summands 取自输入数组，因此无法优化总和，那么您将获得更符合您期望的加速结果：

JRE6

sequential sum: mean time = 436 ms;
parallel sum: mean time = 156 ms; standard deviation = 35,086 ms;
Speed up = 2.7948717948717947

JRE7

sequential sum: mean time = 163 ms; standard deviation = 4 ms;
parallel sum: mean time = 78 ms; standard deviation = 15,362 ms;
Speed up = 2.08974358974359

较低的加速数字是由于对数组 x 和 y 的并发访问。为每个核心使用阵列的本地副本可能会提供接近 4 的加速，如在原始示例中。

帕特里克

于 2012-12-02T15:07:48.117 回答