Question

我为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）

问题出在哪里？谢谢！

Answer 1

教导这个令人惊讶的结果的是你不应该依赖微基准。

在我的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])

其中从输入数组中获取值，因此无法优化总和，然后您可以获得更符合您期望的加速结果：

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的加速，如原始示例中那样。

帕特里克

Ateji加速示例返回意外结果

1 个答案: