我正在使用Java 8的流，無(wú)法理解我得到的性能結(jié)果。我有2個(gè)核心CPU（Intel i73520M），Windows 8 x64和64位Java 8 Update5。我正在對(duì)String的流/并行流進(jìn)行簡(jiǎn)單映射，發(fā)現(xiàn)并行版本要慢一些。Function<Stream<String>, Long> timeOperation = (Stream<String> stream) -> { long time1 = System.nanoTime(); final List<String> list = stream .map(String::toLowerCase) .collect(Collectors.toList()); long time2 = System.nanoTime(); return time2 - time1;};Consumer<Stream<String>> printTime = stream -> System.out.println(timeOperation.apply(stream) / 1000000f);String[] array = new String[1000000];Arrays.fill(array, "AbabagalamagA");printTime.accept(Arrays.stream(array)); // prints around 600printTime.accept(Arrays.stream(array).parallel()); // prints around 900考慮到我有2個(gè)CPU內(nèi)核，并行版本是否應(yīng)該更快？有人可以提示我為什么并行版本比較慢嗎？
3 回答
FFIVE
TA貢獻(xiàn)1797條經(jīng)驗(yàn) 獲得超6個(gè)贊
確實(shí)有幾個(gè)并行發(fā)生的問(wèn)題。
首先是并行解決問(wèn)題始終比順序執(zhí)行涉及更多的實(shí)際工作。開(kāi)銷涉及將工作劃分為多個(gè)線程，以及合并或合并結(jié)果。諸如將短字符串轉(zhuǎn)換為小寫(xiě)字母之類的問(wèn)題足夠小，以至于它們有被并行拆分開(kāi)銷淹沒(méi)的危險(xiǎn)。
第二個(gè)問(wèn)題是，對(duì)Java程序進(jìn)行基準(zhǔn)測(cè)試非常微妙，并且很容易得出令人困惑的結(jié)果。兩個(gè)常見(jiàn)問(wèn)題是JIT編譯和無(wú)效代碼消除。簡(jiǎn)短的基準(zhǔn)測(cè)試通常在JIT編譯之前或期間完成，因此它們無(wú)法衡量峰值吞吐量，實(shí)際上它們可能是在衡量JIT本身。當(dāng)編譯發(fā)生時(shí)是不確定的，因此它也可能導(dǎo)致結(jié)果變化很大。
對(duì)于小型綜合基準(zhǔn)，工作負(fù)載通常會(huì)計(jì)算被丟棄的結(jié)果。JIT編譯器非常擅長(zhǎng)檢測(cè)到這一點(diǎn)，并消除了不會(huì)產(chǎn)生可在任何地方使用的結(jié)果的代碼。在這種情況下可能不會(huì)發(fā)生這種情況，但是如果您修改其他綜合工作負(fù)載，則肯定會(huì)發(fā)生。當(dāng)然，如果JIT消除了基準(zhǔn)測(cè)試工作量，它將使基準(zhǔn)測(cè)試無(wú)用。
我強(qiáng)烈建議您使用完善的基準(zhǔn)測(cè)試框架（例如JMH），而不是手動(dòng)編寫(xiě)一個(gè)自己的框架。JMH具有幫助避免常見(jiàn)基準(zhǔn)測(cè)試陷阱（包括這些陷阱）的功能，并且很容易設(shè)置和運(yùn)行。這是您轉(zhuǎn)換為使用JMH的基準(zhǔn)：
package com.stackoverflow.questions;
import java.util.Arrays;
import java.util.List;
import java.util.stream.Collectors;
import java.util.concurrent.TimeUnit;
import org.openjdk.jmh.annotations.*;
public class SO23170832 {
@State(Scope.Benchmark)
public static class BenchmarkState {
static String[] array;
static {
array = new String[1000000];
Arrays.fill(array, "AbabagalamagA");
}
}
@GenerateMicroBenchmark
@OutputTimeUnit(TimeUnit.SECONDS)
public List<String> sequential(BenchmarkState state) {
return
Arrays.stream(state.array)
.map(x -> x.toLowerCase())
.collect(Collectors.toList());
}
@GenerateMicroBenchmark
@OutputTimeUnit(TimeUnit.SECONDS)
public List<String> parallel(BenchmarkState state) {
return
Arrays.stream(state.array)
.parallel()
.map(x -> x.toLowerCase())
.collect(Collectors.toList());
}
}
我使用命令運(yùn)行此命令：
java -jar dist/microbenchmarks.jar ".*SO23170832.*" -wi 5 -i 5 -f 1
（這些選項(xiàng)指示5個(gè)熱身迭代，5個(gè)基準(zhǔn)迭代和1個(gè)分叉的JVM。）在運(yùn)行期間，JMH會(huì)發(fā)出很多詳細(xì)消息，而我已經(jīng)忽略了這些消息?？偨Y(jié)結(jié)果如下。
Benchmark Mode Samples Mean Mean error Units
c.s.q.SO23170832.parallel thrpt 5 4.600 5.995 ops/s
c.s.q.SO23170832.sequential thrpt 5 1.500 1.727 ops/s
請(qǐng)注意，結(jié)果以每秒操作數(shù)為單位，因此看起來(lái)并行運(yùn)行比順序運(yùn)行快約三倍。但是我的機(jī)器只有兩個(gè)核心。嗯 而且每次運(yùn)行的平均錯(cuò)誤實(shí)際上大于平均運(yùn)行時(shí)間！WAT？這里有些魚(yú)腥味。
這給我們帶來(lái)了第三個(gè)問(wèn)題。仔細(xì)觀察工作負(fù)載，我們可以看到它為每個(gè)輸入分配了一個(gè)新的String對(duì)象，并且還將結(jié)果收集到一個(gè)列表中，該列表涉及大量的重新分配和復(fù)制。我猜想這將導(dǎo)致大量垃圾回收。通過(guò)在啟用了GC消息的情況下重新運(yùn)行基準(zhǔn)測(cè)試，我們可以看到以下內(nèi)容：
java -verbose:gc -jar dist/microbenchmarks.jar ".*SO23170832.*" -wi 5 -i 5 -f 1
結(jié)果如下：
[GC (Allocation Failure) 512K->432K(130560K), 0.0024130 secs]
[GC (Allocation Failure) 944K->520K(131072K), 0.0015740 secs]
[GC (Allocation Failure) 1544K->777K(131072K), 0.0032490 secs]
[GC (Allocation Failure) 1801K->1027K(132096K), 0.0023940 secs]
# Run progress: 0.00% complete, ETA 00:00:20
# VM invoker: /Users/src/jdk/jdk8-b132.jdk/Contents/Home/jre/bin/java
# VM options: -verbose:gc
# Fork: 1 of 1
[GC (Allocation Failure) 512K->424K(130560K), 0.0015460 secs]
[GC (Allocation Failure) 933K->552K(131072K), 0.0014050 secs]
[GC (Allocation Failure) 1576K->850K(131072K), 0.0023050 secs]
[GC (Allocation Failure) 3075K->1561K(132096K), 0.0045140 secs]
[GC (Allocation Failure) 1874K->1059K(132096K), 0.0062330 secs]
# Warmup: 5 iterations, 1 s each
# Measurement: 5 iterations, 1 s each
# Threads: 1 thread, will synchronize iterations
# Benchmark mode: Throughput, ops/time
# Benchmark: com.stackoverflow.questions.SO23170832.parallel
# Warmup Iteration 1: [GC (Allocation Failure) 7014K->5445K(132096K), 0.0184680 secs]
[GC (Allocation Failure) 7493K->6346K(135168K), 0.0068380 secs]
[GC (Allocation Failure) 10442K->8663K(135168K), 0.0155600 secs]
[GC (Allocation Failure) 12759K->11051K(139776K), 0.0148190 secs]
[GC (Allocation Failure) 18219K->15067K(140800K), 0.0241780 secs]
[GC (Allocation Failure) 22167K->19214K(145920K), 0.0208510 secs]
[GC (Allocation Failure) 29454K->25065K(147456K), 0.0333080 secs]
[GC (Allocation Failure) 35305K->30729K(153600K), 0.0376610 secs]
[GC (Allocation Failure) 46089K->39406K(154624K), 0.0406060 secs]
[GC (Allocation Failure) 54766K->48299K(164352K), 0.0550140 secs]
[GC (Allocation Failure) 71851K->62725K(165376K), 0.0612780 secs]
[GC (Allocation Failure) 86277K->74864K(184320K), 0.0649210 secs]
[GC (Allocation Failure) 111216K->94203K(185856K), 0.0875710 secs]
[GC (Allocation Failure) 130555K->114932K(199680K), 0.1030540 secs]
[GC (Allocation Failure) 162548K->141952K(203264K), 0.1315720 secs]
[Full GC (Ergonomics) 141952K->59696K(159232K), 0.5150890 secs]
[GC (Allocation Failure) 105613K->85547K(184832K), 0.0738530 secs]
1.183 ops/s
注意：以開(kāi)頭的行#是正常的JMH輸出線。其余所有都是GC消息。這只是五個(gè)預(yù)熱迭代中的第一個(gè)，它先于五個(gè)基準(zhǔn)迭代。在其余的迭代過(guò)程中，GC消息以相同的方式繼續(xù)傳遞。我認(rèn)為可以肯定地說(shuō)，測(cè)得的性能主要由GC開(kāi)銷決定，不應(yīng)相信報(bào)告的結(jié)果。
目前尚不清楚該怎么做。這純粹是綜合性的工作量。顯然，與分配和復(fù)制相比，完成實(shí)際工作只需要很少的CPU時(shí)間。很難說(shuō)您真正想在這里衡量什么。一種方法是提出在某種意義上更“真實(shí)”的不同工作負(fù)載。另一種方法是更改堆和GC參數(shù)，以避免在基準(zhǔn)測(cè)試運(yùn)行期間出現(xiàn)GC。
添加回答
舉報(bào)
0/150
提交
取消