<分区>
尽管通过重复进行“预热”，并且算法增加了一些复杂性，parallelSetAll() 在这里似乎始终较慢。我并不是真的想在这里进行微观基准测试，只是对正在发生的事情有一个粗略的感觉。
import java.util.*;
import java.time.*;
public class SlowParallelSetAll {
static final int SIZE = 20_000_000;
static long timeIt(Runnable test) {
Instant start = Instant.now();
test.run();
long millis = Duration.between(start, Instant.now()).toMillis();
System.out.println(millis);
return millis;
}
public static void main(String[] args) {
int reps = 10;
long[] la = new long[SIZE];
for(int i = 0; i < reps; i++)
timeIt(() -> Arrays.setAll(la, n -> n * n * 11 + n * 7));
System.out.println("###");
for(int i = 0; i < reps; i++)
timeIt(() -> Arrays.parallelSetAll(la, n -> n * n * 11 + n * 7));
}
}
/* Output:
38
37
35
34
35
34
35
34
34
35
###
52
42
43
44
46
46
44
44
43
43
*/
(lambda 表达式)算法应该是独立的，因为它只依赖于索引值 n，因此看起来应该很容易并行化。
四处移动调用、交替使用两种方法等确实会产生不同的结果，但似乎这里除了微基准测试噪音之外还有更多的东西。一方面，我期待正常版本和并行版本之间有更大的时间差异。此外，似乎人们可能会偶然发现并行版本似乎是正确选择但普通版本实际上更合适的情况。基本上，我正在寻找对此的一些见解 --- 包括是否有一些简单的方法可以证明我所看到的纯粹是一种微基准测试现象。
为了它的值(value)，这里它被重写为使用 System.nanoTime() 并且只是交替测试。这些结果似乎是合理的，尽管整个微基准测试问题令人生畏:
import java.util.*;
import java.time.*;
import java.util.concurrent.*;
public class SlowParallelSetAll {
static final int SIZE = 20_000_000;
static long timeIt(Runnable test) {
long start = System.nanoTime();
test.run();
long delta = System.nanoTime() - start;
long millis = TimeUnit.NANOSECONDS.toMillis(delta);
System.out.println(millis);
return millis;
}
public static void main(String[] args) {
int reps = 10;
long[] la = new long[SIZE];
for(int i = 0; i < reps; i++) {
timeIt(() -> Arrays.parallelSetAll(la, n -> n * n * 11 + n * 7));
timeIt(() -> Arrays.setAll(la, n -> n * n * 11 + n * 7));
}
}
}
/* Output:
41
74
41
73
41
67
40
67
40
67
41
67
41
67
40
67
40
67
40
67
*/