Java Ateji加速示例返回意外结果

我安装了Eclipse3.7版本的JavaEE for Win64，然后按照手册版本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核笔记本电脑上，我使用Java6虚拟机（1.6.0_22-b04 HotSpot（TM）64位服务器）获得了预期的加速：

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

请注意，两个VM版本之间的顺序时间是如何除以50的！！！这无疑是一个强有力的优化开始的迹象

聪明的虚拟机甚至可以不进行任何计算（时间=0ms），因为可以将求和的结果静态地表示为一个简单的代数表达式。在代码的并行版本中，一定有某种东西阻止了相同的优化，因此您会看到令人惊讶的结果

实际上，如果将求和表达式更改为更真实的

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

如果summand是从输入数组中获取的，因此无法对其进行优化，那么您将获得更符合预期的加速结果：

JRE6

JRE7

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

帕特里克

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

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

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

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