在for循环中求和数组中所有元素的性能(吞吐量)在较新的JVM上比在Java1.8.0 JDK的JVM上要慢。我执行了JHM基准测试(如下图)。在每次测试之前,源代码由提供的javac.exe编译,由java.exe运行,这两个二进制文件都由选定的JDK提供。测试在视窗10上执行,并由powershell脚本启动,没有在后台运行任何程序(没有其他jvms)。计算机配备了32GB的内存,因此没有使用硬盘上的虚拟内存。
我的测试源代码:
@Param({"10000000", "100000000"})
public static int ELEMENTS;
public static void main(String[] args) throws RunnerException, IOException {
File outputFile = new File(args[0]);
int javaMajorVersion = Integer.parseInt(System.getProperty("java.version").split("\\.")[0]);
ChainedOptionsBuilder builder = new OptionsBuilder()
.include(IteratingBenchmark.class.getSimpleName())
.mode(Mode.Throughput)
.forks(2)
.measurementTime(TimeValue.seconds(10))
.measurementIterations(50)
.warmupTime(TimeValue.seconds(2))
.warmupIterations(10)
.resultFormat(ResultFormatType.SCSV)
.result(outputFile.getAbsolutePath());
if (javaMajorVersion > 8) {
builder = builder.jvmArgs("-Xms20g", "-Xmx20g", "--enable-preview");
} else {
builder = builder.jvmArgs("-Xms20g", "-Xmx20g");
}
new Runner(builder.build()).run();
}
@Benchmark
public static void cStyleForLoop(Blackhole bh, MockData data) {
long sum = 0;
for (int i = 0; i < data.randomInts.length; i++) {
sum += data.randomInts[i];
}
bh.consume(sum);
}
@State(Scope.Thread)
public static class MockData {
private int[] randomInts = new int[ELEMENTS];
@Setup(Level.Iteration)
public void setup() {
Random r = new Random();
this.randomInts = Stream.iterate(r.nextInt(), i -> i + r.nextInt(1022) + 1).mapToInt(Integer::intValue).limit(ELEMENTS).toArray();
}
}
原始数据:
JDK 1.8.0_241:
"Benchmark";"Mode";"Threads";"Samples";"Score";"Score Error (99,9%)";"Unit";"Param: ELEMENTS"
"benchmark.IteratingBenchmark.cStyleForLoop";"thrpt";1;100;331,446104;5,563589;"ops/s";10000000
"benchmark.IteratingBenchmark.cStyleForLoop";"thrpt";1;100;33,757268;0,431403;"ops/s";100000000
JDK 11.0.2:
"Benchmark";"Mode";"Threads";"Samples";"Score";"Score Error (99,9%)";"Unit";"Param: ELEMENTS"
"benchmark.IteratingBenchmark.cStyleForLoop";"thrpt";1;100;322,728461;4,823611;"ops/s";10000000
"benchmark.IteratingBenchmark.cStyleForLoop";"thrpt";1;100;31,075948;0,062830;"ops/s";100000000
JDK 12.0.1:
"Benchmark";"Mode";"Threads";"Samples";"Score";"Score Error (99,9%)";"Unit";"Param: ELEMENTS"
"benchmark.IteratingBenchmark.cStyleForLoop";"thrpt";1;100;322,914782;4,450969;"ops/s";10000000
"benchmark.IteratingBenchmark.cStyleForLoop";"thrpt";1;100;31,095232;0,075051;"ops/s";100000000
JDK 13.0.1:
"Benchmark";"Mode";"Threads";"Samples";"Score";"Score Error (99,9%)";"Unit";"Param: ELEMENTS"
"benchmark.IteratingBenchmark.cStyleForLoop";"thrpt";1;100;325,103055;4,933257;"ops/s";10000000
"benchmark.IteratingBenchmark.cStyleForLoop";"thrpt";1;100;31,228403;0,067954;"ops/s";100000000
JDK 14.0.1:
"Benchmark";"Mode";"Threads";"Samples";"Score";"Score Error (99,9%)";"Unit";"Param: ELEMENTS"
"benchmark.IteratingBenchmark.cStyleForLoop";"thrpt";1;100;300,861148;0,443404;"ops/s";10000000
"benchmark.IteratingBenchmark.cStyleForLoop";"thrpt";1;100;29,863602;0,035781;"ops/s";100000000
OpenJDK 14.0.2:
"Benchmark";"Mode";"Threads";"Samples";"Score";"Score Error (99,9%)";"Unit";"Param: ELEMENTS"
"benchmark.IteratingBenchmark.cStyleForLoop";"thrpt";1;100;300,781930;0,481579;"ops/s";10000000
"benchmark.IteratingBenchmark.cStyleForLoop";"thrpt";1;100;29,873509;0,033055;"ops/s";100000000
OpenJDK 15:
"Benchmark";"Mode";"Threads";"Samples";"Score";"Score Error (99,9%)";"Unit";"Param: ELEMENTS"
"benchmark.IteratingBenchmark.cStyleForLoop";"thrpt";1;100;343,530895;0,445551;"ops/s";10000000
"benchmark.IteratingBenchmark.cStyleForLoop";"thrpt";1;100;34,287083;0,035028;"ops/s";100000000
有没有什么有效的解释,为什么Java新版本比1.8慢(OpenJDK 15除外)?< br>
更新1:
我对不同的Xmx/Xms值运行相同的测试(对于每个测试Xmx==Xms),结果如下:
更新2:
“级别迭代”
更改为“级别试用”
。原始数据:
JDK 1.8.0_241:
"Benchmark";"Mode";"Threads";"Samples";"Score";"Score Error (99,9%)";"Unit";"Param: ELEMENTS"
"benchmark.IteratingBenchmark.cStyleForLoop";"thrpt";1;15;33,760346;0,089646;"ops/s";100000000
JDK 11.0.2:
"Benchmark";"Mode";"Threads";"Samples";"Score";"Score Error (99,9%)";"Unit";"Param: ELEMENTS"
"benchmark.IteratingBenchmark.cStyleForLoop";"thrpt";1;15;31,075120;0,086171;"ops/s";100000000
JDK 12.0.1:
"Benchmark";"Mode";"Threads";"Samples";"Score";"Score Error (99,9%)";"Unit";"Param: ELEMENTS"
"benchmark.IteratingBenchmark.cStyleForLoop";"thrpt";1;15;31,173939;0,044176;"ops/s";100000000
JDK 13.0.1:
"Benchmark";"Mode";"Threads";"Samples";"Score";"Score Error (99,9%)";"Unit";"Param: ELEMENTS"
"benchmark.IteratingBenchmark.cStyleForLoop";"thrpt";1;15;31,219283;0,062329;"ops/s";100000000
JDK 14.0.1:
"Benchmark";"Mode";"Threads";"Samples";"Score";"Score Error (99,9%)";"Unit";"Param: ELEMENTS"
"benchmark.IteratingBenchmark.cStyleForLoop";"thrpt";1;15;29,808609;0,072664;"ops/s";100000000
OpenJDK 14.0.2:
"Benchmark";"Mode";"Threads";"Samples";"Score";"Score Error (99,9%)";"Unit";"Param: ELEMENTS"
"benchmark.IteratingBenchmark.cStyleForLoop";"thrpt";1;15;29,845817;0,074315;"ops/s";100000000
OpenJDK 15:
"Benchmark";"Mode";"Threads";"Samples";"Score";"Score Error (99,9%)";"Unit";"Param: ELEMENTS"
"benchmark.IteratingBenchmark.cStyleForLoop";"thrpt";1;15;34,310620;0,087412;"ops/s";100000000
不幸的是,在我的Windows机器上,结果仍然显示性能下降(不包括JDK15)。
即使从GitHub逐字复制基准测试并使用相同的参数运行,我仍然无法复制结果。在我的环境中,JDK14的性能与JDK8一样快(甚至快一点)。因此,在这个答案中,我将根据编译代码的反汇编分析两个版本之间的差异。
首先,让我们看看来自同一供应商的最新OpenJDK构建
在这里,我比较了64位Windows的Liberica JDK 8u265 1和Liberica DDK 14.0.2 13。
JMH得分如下:
Benchmark (ELEMENTS) Mode Cnt Score Error Units
IteratingBenchmark.cStyleForLoop 10000000 thrpt 30 263,137 ± 0,484 ops/s # JDK 8
IteratingBenchmark.cStyleForLoop 10000000 thrpt 30 264,406 ± 0,788 ops/s # JDK 14
现在,让我们使用内置的-prof xperfasm
profiler运行JMH,以查看基准测试中最热门部分的反汇编。预计,约99.5%的CPU时间用于C2编译的cStyleForLoop
方法。
JDK 8上最热的地区
....[Hottest Region 1]..............................................................................
C2, level 4, codes.dbg.IteratingBenchmark::cStyleForLoop, version 574 (71 bytes)
0x0000028c5607fc5f: add r10d,0fffffff9h
0x0000028c5607fc63: lea rax,[r12+rcx*8]
0x0000028c5607fc67: mov ebx,80000000h
0x0000028c5607fc6c: cmp r9d,r10d
0x0000028c5607fc6f: cmovl r10d,ebx
0x0000028c5607fc73: mov r9d,1h
0x0000028c5607fc79: cmp r10d,1h
╭ 0x0000028c5607fc7d: jle 28c5607fccch
│ 0x0000028c5607fc7f: nop ;*lload_2
│ ; - codes.dbg.IteratingBenchmark::cStyleForLoop@15 (line 25)
0,07% │↗ 0x0000028c5607fc80: movsxd rbx,dword ptr [rax+r9*4+10h]
0,06% ││ 0x0000028c5607fc85: add rbx,r8
8,93% ││ 0x0000028c5607fc88: movsxd rcx,r9d
0,41% ││ 0x0000028c5607fc8b: movsxd r8,dword ptr [rax+rcx*4+2ch]
25,02% ││ 0x0000028c5607fc90: movsxd rdi,dword ptr [rax+rcx*4+14h]
0,10% ││ 0x0000028c5607fc95: movsxd rsi,dword ptr [rax+rcx*4+18h]
8,56% ││ 0x0000028c5607fc9a: movsxd rbp,dword ptr [rax+rcx*4+28h]
0,58% ││ 0x0000028c5607fc9f: movsxd r13,dword ptr [rax+rcx*4+1ch]
0,41% ││ 0x0000028c5607fca4: movsxd r14,dword ptr [rax+rcx*4+20h]
0,20% ││ 0x0000028c5607fca9: movsxd rcx,dword ptr [rax+rcx*4+24h]
8,85% ││ 0x0000028c5607fcae: add rdi,rbx
0,38% ││ 0x0000028c5607fcb1: add rsi,rdi
0,15% ││ 0x0000028c5607fcb4: add r13,rsi
8,57% ││ 0x0000028c5607fcb7: add r14,r13
13,76% ││ 0x0000028c5607fcba: add rcx,r14
5,51% ││ 0x0000028c5607fcbd: add rbp,rcx
8,50% ││ 0x0000028c5607fcc0: add r8,rbp ;*ladd
││ ; - codes.dbg.IteratingBenchmark::cStyleForLoop@24 (line 25)
8,95% ││ 0x0000028c5607fcc3: add r9d,8h ;*iinc
││ ; - codes.dbg.IteratingBenchmark::cStyleForLoop@26 (line 24)
0,40% ││ 0x0000028c5607fcc7: cmp r9d,r10d
│╰ 0x0000028c5607fcca: jl 28c5607fc80h ;*if_icmpge
│ ; - codes.dbg.IteratingBenchmark::cStyleForLoop@12 (line 24)
↘ 0x0000028c5607fccc: cmp r9d,edx
0x0000028c5607fccf: jnl 28c5607fce4h
0x0000028c5607fcd1: nop ;*lload_2
; - codes.dbg.IteratingBenchmark::cStyleForLoop@15 (line 25)
0x0000028c5607fcd4: movsxd r10,dword ptr [rax+r9*4+10h]
0x0000028c5607fcd9: add r8,r10 ;*ladd
; - codes.dbg.IteratingBenchmark::cStyleForLoop@24 (line 25)
....................................................................................................
JDK 14上最热的地区
....[Hottest Region 1]..............................................................................
c2, level 4, codes.dbg.IteratingBenchmark::cStyleForLoop, version 622 (147 bytes)
; - codes.dbg.IteratingBenchmark::cStyleForLoop@23 (line 25)
0x000001e844438f72: mov r11d,r10d
0x000001e844438f75: add r11d,0fffffff9h
0x000001e844438f79: lea rax,[r12+r9*8]
0x000001e844438f7d: mov ebx,1h
0x000001e844438f82: cmp r11d,1h
0x000001e844438f86: jle 1e8444390c0h ;*goto {reexecute=0 rethrow=0 return_oop=0}
; - codes.dbg.IteratingBenchmark::cStyleForLoop@29 (line 24)
╭ 0x000001e844438f8c: jmp 1e844438ffah
│ 0x000001e844438f8e: nop
0,04% │↗ 0x000001e844438f90: mov rsi,r8 ;*lload_2 {reexecute=0 rethrow=0 return_oop=0}
││ ; - codes.dbg.IteratingBenchmark::cStyleForLoop@15 (line 25)
0,04% ││ ↗ 0x000001e844438f93: movsxd rdx,dword ptr [rax+rbx*4+10h]
8,41% ││ │ 0x000001e844438f98: movsxd rbp,dword ptr [rax+rbx*4+14h]
1,23% ││ │ 0x000001e844438f9d: movsxd r13,dword ptr [rax+rbx*4+18h]
0,03% ││ │ 0x000001e844438fa2: movsxd r8,dword ptr [rax+rbx*4+2ch]
23,87% ││ │ 0x000001e844438fa7: movsxd r11,dword ptr [rax+rbx*4+28h]
8,22% ││ │ 0x000001e844438fac: movsxd r9,dword ptr [rax+rbx*4+24h]
1,25% ││ │ 0x000001e844438fb1: movsxd rcx,dword ptr [rax+rbx*4+20h]
0,14% ││ │ 0x000001e844438fb6: movsxd r14,dword ptr [rax+rbx*4+1ch]
0,28% ││ │ 0x000001e844438fbb: add rdx,rsi
7,82% ││ │ 0x000001e844438fbe: add rbp,rdx
1,14% ││ │ 0x000001e844438fc1: add r13,rbp
0,17% ││ │ 0x000001e844438fc4: add r14,r13
14,57% ││ │ 0x000001e844438fc7: add rcx,r14
11,05% ││ │ 0x000001e844438fca: add r9,rcx
5,26% ││ │ 0x000001e844438fcd: add r11,r9
6,32% ││ │ 0x000001e844438fd0: add r8,r11 ;*ladd {reexecute=0 rethrow=0 return_oop=0}
││ │ ; - codes.dbg.IteratingBenchmark::cStyleForLoop@24 (line 25)
8,45% ││ │ 0x000001e844438fd3: add ebx,8h ;*iinc {reexecute=0 rethrow=0 return_oop=0}
││ │ ; - codes.dbg.IteratingBenchmark::cStyleForLoop@26 (line 24)
1,15% ││ │ 0x000001e844438fd6: cmp ebx,edi
│╰ │ 0x000001e844438fd8: jl 1e844438f90h ;*if_icmpge {reexecute=0 rethrow=0 return_oop=0}
│ │ ; - codes.dbg.IteratingBenchmark::cStyleForLoop@12 (line 24)
│ │ 0x000001e844438fda: mov r11,qword ptr [r15+110h] ; ImmutableOopMap {rax=Oop xmm0=Oop xmm1=Oop }
│ │ ;*goto {reexecute=1 rethrow=0 return_oop=0}
│ │ ; - (reexecute) codes.dbg.IteratingBenchmark::cStyleForLoop@29 (line 24)
0,00% │ │ 0x000001e844438fe1: test dword ptr [r11],eax ;*goto {reexecute=0 rethrow=0 return_oop=0}
│ │ ; - codes.dbg.IteratingBenchmark::cStyleForLoop@29 (line 24)
│ │ ; {poll}
0,02% │ │ 0x000001e844438fe4: cmp ebx,dword ptr [rsp]
│ ╭│ 0x000001e844438fe7: jnl 1e844439028h
0,00% │ ││ 0x000001e844438fe9: mov rsi,r8
│ ││ 0x000001e844438fec: vmovq r8,xmm0
│ ││ 0x000001e844438ff1: vmovq rdx,xmm1
0,01% │ ││ 0x000001e844438ff6: mov r11d,dword ptr [rsp]
↘ ││ 0x000001e844438ffa: mov ecx,r10d
││ 0x000001e844438ffd: sub ecx,ebx
││ 0x000001e844438fff: add ecx,0fffffff9h
0,00% ││ 0x000001e844439002: mov r9d,1f40h
││ 0x000001e844439008: cmp r9d,ecx
││ 0x000001e84443900b: mov edi,1f40h
││ 0x000001e844439010: cmovnle edi,ecx
0,02% ││ 0x000001e844439013: add edi,ebx
││ 0x000001e844439015: vmovq xmm0,r8
││ 0x000001e84443901a: vmovq xmm1,rdx
││ 0x000001e84443901f: mov dword ptr [rsp],r11d
0,01% │╰ 0x000001e844439023: jmp 1e844438f93h
↘ 0x000001e844439028: vmovq rdx,xmm1
0x000001e84443902d: cmp ebx,r10d
0x000001e844439030: jnl 1e844439043h
0x000001e844439032: nop ;*lload_2 {reexecute=0 rethrow=0 return_oop=0}
; - codes.dbg.IteratingBenchmark::cStyleForLoop@15 (line 25)
0x000001e844439034: movsxd r11,dword ptr [rax+rbx*4+10h]
0x000001e844439039: add r8,r11 ;*ladd {reexecute=0 rethrow=0 return_oop=0}
; - codes.dbg.IteratingBenchmark::cStyleForLoop@24 (line 25)
0x000001e84443903c: inc ebx ;*iinc {reexecute=0 rethrow=0 return_oop=0}
; - codes.dbg.IteratingBenchmark::cStyleForLoop@26 (line 24)
....................................................................................................
如我们所见,循环体在两个JDK上的编译类似:
关键区别在于,在JDK 14上,循环迭代被分成两个嵌套块。这是一个结果,循环条带开采优化出现在JDK 10。这种优化的思想是将计数循环分成没有安全点轮询的热内部部分和具有安全点轮询指令的外部部分。
C2 JIT将循环转换成类似于
for (int i = 0; i < array.length; i += 8000) {
for (int j = 0; j < 8000; j += 8) {
int ix = i + j;
int v0 = array[ix];
int v1 = array[ix + 1];
...
int v7 = array[ix + 7];
sum += v0 + v1 + ... + v7;
}
safepoint_poll();
}
请注意,JDK 8版本在计数循环中根本没有安全点轮询。一方面,这可以使循环运行得更快。但另一方面,这实际上对低延迟应用是不利的,因为暂停时间可能会随着整个循环的持续时间而增加。
JDK 14 在循环内插入安全点轮询。这可能是你观察到的减速的原因,但我并不真正相信这一点,因为由于循环条带挖掘优化,安全点轮询在8000次迭代中只执行一次。
要验证这一点,您可以使用< code >-XX:-UseCountedLoopSafepoints JVM选项禁用安全点轮询。在这种情况下,JDK 14编译版将看起来几乎与JDK 8一模一样。基准分数也是如此。
以下是为 linkerd 提供商业支持和其他企业产品的公司列表: Buoyant 是 linkerd 的原创者,并提供支持,培训和企业产品。 了解更多 »
作用 用于查询企业账户额度、开票额度等信息。 依赖 暂无依赖 注意 所有接口调用时需要严格遵守请求方式(GET/POST) 使用接口前需要仔细阅读每个接口的注意事项 接口报错时先阅读通用错误解决方案和当前接口文档下的接口错误解决方案
方法一、录入成员并通过短信/邮件邀请加入企业 1、发起企业认证 1)进入企业管理平台-设置-企业信息-发起认证,平台管理员会在1-2个工作日左右审批 2)仅认证通过的企业可以通过短信/邮件邀请成员 2、录入成员 1)单个添加:进入企业管理平台-通讯录,选择某个部门,点击右上角“添加成员” 2)批量导入: 进入企业管理平台-通讯录,
企业微信联合微信支付,提供企业支付能力。满足企业红包,向员工付款,向员工收款三种支付场景。 开通方法 登录管理后台,在【企业应用】中找到【企业支付】应用。企业支付的相关配置需要在微信支付商户平台完成,请先确保企业已申请了微信支付商户号 1 / 没有微信支付商户号 点击【立即申请】前往微信支付商户平台申请商户号,申请通过后即可在微信支付商户平台中开启企业微信专区,进行企业支付的相关设置。 2 / 已
企业邮箱是以企业自己的域名为后缀名的工作专用邮箱,通过配置企业邮箱,可以让员工方便地在企业微信收发和管理邮件,在企业微信统一处理工作上的事务。 配置步骤 设置入口:【管理后台】>【企业应用】>【企业邮箱】查看 1 / 企业没有企业邮箱 若企业没有企业邮箱,也没有企业域名,可在管理后台申请企业的专属域名。只需简单的配置,就可以拥有企业专属的企业邮箱。配置步骤如下: 01/04进入企业邮箱,点击【立即
支持为企业自定义系统名称、logo及版权信息。 企业信息页面用于自定义 云联壹云 系统的系统名称、Logo、版权信息等。 操作步骤 在云管平台单击左上角导航菜单,在弹出的左侧菜单栏中单击 “系统配置/系统/企业信息” 菜单项,进入企业信息页面。 配置以下信息: 产品名称(中文/英文):云管平台的系统名称。 系统内Logo:平台登录成功后,显示在右上角Logo,要求宽76*高52大小的png格式的图