Java에서 2 * (i * i)가 2 * i * i보다 빠른 이유는 무엇입니까?
다음 Java 프로그램을 실행하는 데 평균 0.50초에서 0.55초가 소요됩니다.
public static void main(String[] args) {
long startTime = System.nanoTime();
int n = 0;
for (int i = 0; i < 1000000000; i++) {
n += 2 * (i * i);
}
System.out.println((double) (System.nanoTime() - startTime) / 1000000000 + " s");
System.out.println("n = " + n);
}
★★★을 2 * (i * i)2 * i * i.60~0.이다 왜왜?
나는 각 버전의 프로그램을 15번씩 번갈아 실행했다.결과는 다음과 같습니다.
2*(i*i) | 2*i*i
----------+----------
0.5183738 | 0.6246434
0.5298337 | 0.6049722
0.5308647 | 0.6603363
0.5133458 | 0.6243328
0.5003011 | 0.6541802
0.5366181 | 0.6312638
0.515149 | 0.6241105
0.5237389 | 0.627815
0.5249942 | 0.6114252
0.5641624 | 0.6781033
0.538412 | 0.6393969
0.5466744 | 0.6608845
0.531159 | 0.6201077
0.5048032 | 0.6511559
0.5232789 | 0.6544526
동작2 * i * i 2 * (i * i), 이이 발생할 은, 「동일」보다 1/2^15 * 100% = 0.00305%.
바이트 코드 순서에는 약간의 차이가 있습니다.
2 * (i * i):
iconst_2
iload0
iload0
imul
imul
iadd
»2 * i * i:
iconst_2
iload0
imul
iload0
imul
iadd
언뜻 보기에는 차이가 없습니다.한 개의 슬롯을 적게 사용하기 때문에 두 번째 버전이 더 적합합니다.
그래서 우리는 낮은 수준(JIT)1을 더 깊이 파고들 필요가 있다.
JIT는 작은 루프를 매우 적극적으로 전개하는 경향이 있습니다.실제로 우리는 16x 롤링을 관찰합니다.2 * (i * i) 예:
030 B2: # B2 B3 <- B1 B2 Loop: B2-B2 inner main of N18 Freq: 1e+006
030 addl R11, RBP # int
033 movl RBP, R13 # spill
036 addl RBP, #14 # int
039 imull RBP, RBP # int
03c movl R9, R13 # spill
03f addl R9, #13 # int
043 imull R9, R9 # int
047 sall RBP, #1
049 sall R9, #1
04c movl R8, R13 # spill
04f addl R8, #15 # int
053 movl R10, R8 # spill
056 movdl XMM1, R8 # spill
05b imull R10, R8 # int
05f movl R8, R13 # spill
062 addl R8, #12 # int
066 imull R8, R8 # int
06a sall R10, #1
06d movl [rsp + #32], R10 # spill
072 sall R8, #1
075 movl RBX, R13 # spill
078 addl RBX, #11 # int
07b imull RBX, RBX # int
07e movl RCX, R13 # spill
081 addl RCX, #10 # int
084 imull RCX, RCX # int
087 sall RBX, #1
089 sall RCX, #1
08b movl RDX, R13 # spill
08e addl RDX, #8 # int
091 imull RDX, RDX # int
094 movl RDI, R13 # spill
097 addl RDI, #7 # int
09a imull RDI, RDI # int
09d sall RDX, #1
09f sall RDI, #1
0a1 movl RAX, R13 # spill
0a4 addl RAX, #6 # int
0a7 imull RAX, RAX # int
0aa movl RSI, R13 # spill
0ad addl RSI, #4 # int
0b0 imull RSI, RSI # int
0b3 sall RAX, #1
0b5 sall RSI, #1
0b7 movl R10, R13 # spill
0ba addl R10, #2 # int
0be imull R10, R10 # int
0c2 movl R14, R13 # spill
0c5 incl R14 # int
0c8 imull R14, R14 # int
0cc sall R10, #1
0cf sall R14, #1
0d2 addl R14, R11 # int
0d5 addl R14, R10 # int
0d8 movl R10, R13 # spill
0db addl R10, #3 # int
0df imull R10, R10 # int
0e3 movl R11, R13 # spill
0e6 addl R11, #5 # int
0ea imull R11, R11 # int
0ee sall R10, #1
0f1 addl R10, R14 # int
0f4 addl R10, RSI # int
0f7 sall R11, #1
0fa addl R11, R10 # int
0fd addl R11, RAX # int
100 addl R11, RDI # int
103 addl R11, RDX # int
106 movl R10, R13 # spill
109 addl R10, #9 # int
10d imull R10, R10 # int
111 sall R10, #1
114 addl R10, R11 # int
117 addl R10, RCX # int
11a addl R10, RBX # int
11d addl R10, R8 # int
120 addl R9, R10 # int
123 addl RBP, R9 # int
126 addl RBP, [RSP + #32 (32-bit)] # int
12a addl R13, #16 # int
12e movl R11, R13 # spill
131 imull R11, R13 # int
135 sall R11, #1
138 cmpl R13, #999999985
13f jl B2 # loop end P=1.000000 C=6554623.000000
스택에 「스필」되어 있는 레지스터가 1개 있는 것을 알 수 있습니다.
,에 대해서2 * i * i★★★★
05a B3: # B2 B4 <- B1 B2 Loop: B3-B2 inner main of N18 Freq: 1e+006
05a addl RBX, R11 # int
05d movl [rsp + #32], RBX # spill
061 movl R11, R8 # spill
064 addl R11, #15 # int
068 movl [rsp + #36], R11 # spill
06d movl R11, R8 # spill
070 addl R11, #14 # int
074 movl R10, R9 # spill
077 addl R10, #16 # int
07b movdl XMM2, R10 # spill
080 movl RCX, R9 # spill
083 addl RCX, #14 # int
086 movdl XMM1, RCX # spill
08a movl R10, R9 # spill
08d addl R10, #12 # int
091 movdl XMM4, R10 # spill
096 movl RCX, R9 # spill
099 addl RCX, #10 # int
09c movdl XMM6, RCX # spill
0a0 movl RBX, R9 # spill
0a3 addl RBX, #8 # int
0a6 movl RCX, R9 # spill
0a9 addl RCX, #6 # int
0ac movl RDX, R9 # spill
0af addl RDX, #4 # int
0b2 addl R9, #2 # int
0b6 movl R10, R14 # spill
0b9 addl R10, #22 # int
0bd movdl XMM3, R10 # spill
0c2 movl RDI, R14 # spill
0c5 addl RDI, #20 # int
0c8 movl RAX, R14 # spill
0cb addl RAX, #32 # int
0ce movl RSI, R14 # spill
0d1 addl RSI, #18 # int
0d4 movl R13, R14 # spill
0d7 addl R13, #24 # int
0db movl R10, R14 # spill
0de addl R10, #26 # int
0e2 movl [rsp + #40], R10 # spill
0e7 movl RBP, R14 # spill
0ea addl RBP, #28 # int
0ed imull RBP, R11 # int
0f1 addl R14, #30 # int
0f5 imull R14, [RSP + #36 (32-bit)] # int
0fb movl R10, R8 # spill
0fe addl R10, #11 # int
102 movdl R11, XMM3 # spill
107 imull R11, R10 # int
10b movl [rsp + #44], R11 # spill
110 movl R10, R8 # spill
113 addl R10, #10 # int
117 imull RDI, R10 # int
11b movl R11, R8 # spill
11e addl R11, #8 # int
122 movdl R10, XMM2 # spill
127 imull R10, R11 # int
12b movl [rsp + #48], R10 # spill
130 movl R10, R8 # spill
133 addl R10, #7 # int
137 movdl R11, XMM1 # spill
13c imull R11, R10 # int
140 movl [rsp + #52], R11 # spill
145 movl R11, R8 # spill
148 addl R11, #6 # int
14c movdl R10, XMM4 # spill
151 imull R10, R11 # int
155 movl [rsp + #56], R10 # spill
15a movl R10, R8 # spill
15d addl R10, #5 # int
161 movdl R11, XMM6 # spill
166 imull R11, R10 # int
16a movl [rsp + #60], R11 # spill
16f movl R11, R8 # spill
172 addl R11, #4 # int
176 imull RBX, R11 # int
17a movl R11, R8 # spill
17d addl R11, #3 # int
181 imull RCX, R11 # int
185 movl R10, R8 # spill
188 addl R10, #2 # int
18c imull RDX, R10 # int
190 movl R11, R8 # spill
193 incl R11 # int
196 imull R9, R11 # int
19a addl R9, [RSP + #32 (32-bit)] # int
19f addl R9, RDX # int
1a2 addl R9, RCX # int
1a5 addl R9, RBX # int
1a8 addl R9, [RSP + #60 (32-bit)] # int
1ad addl R9, [RSP + #56 (32-bit)] # int
1b2 addl R9, [RSP + #52 (32-bit)] # int
1b7 addl R9, [RSP + #48 (32-bit)] # int
1bc movl R10, R8 # spill
1bf addl R10, #9 # int
1c3 imull R10, RSI # int
1c7 addl R10, R9 # int
1ca addl R10, RDI # int
1cd addl R10, [RSP + #44 (32-bit)] # int
1d2 movl R11, R8 # spill
1d5 addl R11, #12 # int
1d9 imull R13, R11 # int
1dd addl R13, R10 # int
1e0 movl R10, R8 # spill
1e3 addl R10, #13 # int
1e7 imull R10, [RSP + #40 (32-bit)] # int
1ed addl R10, R13 # int
1f0 addl RBP, R10 # int
1f3 addl R14, RBP # int
1f6 movl R10, R8 # spill
1f9 addl R10, #16 # int
1fd cmpl R10, #999999985
204 jl B2 # loop end P=1.000000 C=7419903.000000
와 '더 .[RSP + ...]보존할 필요가 있는 중간 결과가 더 많기 때문입니다.
따라서 이 질문에 대한 답은 간단합니다.2 * (i * i)2 * i * i왜냐하면 JIT는 첫 번째 사례에 대해 더 최적의 어셈블리 코드를 생성하기 때문입니다.
그러나 물론 첫 번째 버전도 두 번째 버전도 좋지 않습니다. x86-64 CPU는 적어도 SSE2를 지원하므로 루프는 벡터화의 이점을 얻을 수 있습니다.
따라서 이는 옵티마이저가 안고 있는 문제입니다.대부분의 경우처럼 너무 공격적으로 전개되어 스스로 발등을 찍게 됩니다.다양한 다른 기회를 놓치는 경우가 많습니다.
실제로 최신 x86-64 CPU는 명령어를 micro-ops(ops)로 더 세분화하여 레지스터 이름 변경, op 캐시 및 루프 버퍼 등의 기능을 사용하면 루프 최적화는 단순한 언롤링보다 훨씬 더 정교하게 처리하여 최적의 성능을 얻을 수 있습니다.Agner Fog의 최적화 가이드에 따르면:
평균 명령 길이가 4바이트를 초과하면 op 캐시에 의한 퍼포먼스가 크게 향상될 수 있습니다.op 캐시 사용을 최적화하는 방법은 다음과 같습니다.
- critical loop이 op 캐시에 들어갈 수 있을 정도로 작은지 확인합니다.
- 가장 중요한 루프 엔트리와 함수 엔트리를 32로 정렬합니다.
- 불필요한 루프 언롤링을 피하십시오.
- 로드 은 피하십시오.
. . . . . . . .
이러한 로드 타임에 대해서는 - 아무리 빠른 L1D 히트라도 4사이클, 추가 레지스터 및 op이 소요되기 때문에 메모리에 대한 몇 번의 액세스라도 엄격한 루프에서는 퍼포먼스가 저하됩니다.
그러나 벡터화 기회로 돌아가서, 얼마나 빠른지 확인하기 위해 GCC를 사용하여 유사한 C 애플리케이션을 컴파일할 수 있습니다(AVX2, SSE2도 이와 유사합니다).2
vmovdqa ymm0, YMMWORD PTR .LC0[rip]
vmovdqa ymm3, YMMWORD PTR .LC1[rip]
xor eax, eax
vpxor xmm2, xmm2, xmm2
.L2:
vpmulld ymm1, ymm0, ymm0
inc eax
vpaddd ymm0, ymm0, ymm3
vpslld ymm1, ymm1, 1
vpaddd ymm2, ymm2, ymm1
cmp eax, 125000000 ; 8 calculations per iteration
jne .L2
vmovdqa xmm0, xmm2
vextracti128 xmm2, ymm2, 1
vpaddd xmm2, xmm0, xmm2
vpsrldq xmm0, xmm2, 8
vpaddd xmm0, xmm2, xmm0
vpsrldq xmm1, xmm0, 4
vpaddd xmm0, xmm0, xmm1
vmovd eax, xmm0
vzeroupper
실행 시간 포함:
- SSE: 0.24초, 즉2배의 속도.
- AVX: 0.15초, 즉3배의 속도.
- AVX2: 0.08초, 즉5배의 속도.
1 JIT에서 생성된 어셈블리 출력을 가져오려면 디버깅 JVM을 가져와-XX:+PrintOptoAssembly
2 은 C로 되어 있습니다.-fwrapv플래그: GCC가 서명된 정수 오버플로를 2개의 보완 랩어라운드로 처리할 수 있도록 합니다.
(편집자 주: 이 답변은 다른 답변에서 알 수 있듯이 ASM을 본 증거와 모순됩니다.이것은 몇 가지 실험으로 뒷받침된 추측이었지만, 사실이 아닌 것으로 밝혀졌다.
이 「」인 2 * (i * i)은 JVM에 의한 수 2하지만 보다 코드가 됩니다: 그, 、 등 from 、 등 from 、 등 from : from:: 。
int n = 0;
for (int i = 0; i < 1000000000; i++) {
n += i * i;
}
n *= 2;
, 이 지지 but but일 (2 * i) * i이 JVM의 앞에 없기 않습니다.n +=★★★★★★ 。
다음은 제가 이렇게 생각하는 몇 가지 이유입니다.
- " " " "
if (n == 0) n = 1에서는 두 버전이 할 수 없기 입니다. - 버전은 의 곱셈을으로) 2의 곱셈과 합니다.
2 * (i * i)표시
다음 테스트 코드를 사용하여 다음과 같은 결론을 도출했습니다.
public static void main(String[] args) {
long fastVersion = 0;
long slowVersion = 0;
long optimizedVersion = 0;
long modifiedFastVersion = 0;
long modifiedSlowVersion = 0;
for (int i = 0; i < 10; i++) {
fastVersion += fastVersion();
slowVersion += slowVersion();
optimizedVersion += optimizedVersion();
modifiedFastVersion += modifiedFastVersion();
modifiedSlowVersion += modifiedSlowVersion();
}
System.out.println("Fast version: " + (double) fastVersion / 1000000000 + " s");
System.out.println("Slow version: " + (double) slowVersion / 1000000000 + " s");
System.out.println("Optimized version: " + (double) optimizedVersion / 1000000000 + " s");
System.out.println("Modified fast version: " + (double) modifiedFastVersion / 1000000000 + " s");
System.out.println("Modified slow version: " + (double) modifiedSlowVersion / 1000000000 + " s");
}
private static long fastVersion() {
long startTime = System.nanoTime();
int n = 0;
for (int i = 0; i < 1000000000; i++) {
n += 2 * (i * i);
}
return System.nanoTime() - startTime;
}
private static long slowVersion() {
long startTime = System.nanoTime();
int n = 0;
for (int i = 0; i < 1000000000; i++) {
n += 2 * i * i;
}
return System.nanoTime() - startTime;
}
private static long optimizedVersion() {
long startTime = System.nanoTime();
int n = 0;
for (int i = 0; i < 1000000000; i++) {
n += i * i;
}
n *= 2;
return System.nanoTime() - startTime;
}
private static long modifiedFastVersion() {
long startTime = System.nanoTime();
int n = 0;
for (int i = 0; i < 1000000000; i++) {
if (n == 0) n = 1;
n += 2 * (i * i);
}
return System.nanoTime() - startTime;
}
private static long modifiedSlowVersion() {
long startTime = System.nanoTime();
int n = 0;
for (int i = 0; i < 1000000000; i++) {
if (n == 0) n = 1;
n += 2 * i * i;
}
return System.nanoTime() - startTime;
}
결과는 다음과 같습니다.
Fast version: 5.7274411 s
Slow version: 7.6190804 s
Optimized version: 5.1348007 s
Modified fast version: 7.1492705 s
Modified slow version: 7.2952668 s
바이트 코드: https://cs.nyu.edu/courses/fall00/V22.0201-001/jvm2.html 바이트 코드 뷰어: https://github.com/Konloch/bytecode-viewer
JDK(Windows 10 64비트, 1.8.0_65-b17)에서는 다음 내용을 재현하고 설명할 수 있습니다.
public static void main(String[] args) {
int repeat = 10;
long A = 0;
long B = 0;
for (int i = 0; i < repeat; i++) {
A += test();
B += testB();
}
System.out.println(A / repeat + " ms");
System.out.println(B / repeat + " ms");
}
private static long test() {
int n = 0;
for (int i = 0; i < 1000; i++) {
n += multi(i);
}
long startTime = System.currentTimeMillis();
for (int i = 0; i < 1000000000; i++) {
n += multi(i);
}
long ms = (System.currentTimeMillis() - startTime);
System.out.println(ms + " ms A " + n);
return ms;
}
private static long testB() {
int n = 0;
for (int i = 0; i < 1000; i++) {
n += multiB(i);
}
long startTime = System.currentTimeMillis();
for (int i = 0; i < 1000000000; i++) {
n += multiB(i);
}
long ms = (System.currentTimeMillis() - startTime);
System.out.println(ms + " ms B " + n);
return ms;
}
private static int multiB(int i) {
return 2 * (i * i);
}
private static int multi(int i) {
return 2 * i * i;
}
출력:
...
405 ms A 785527736
327 ms B 785527736
404 ms A 785527736
329 ms B 785527736
404 ms A 785527736
328 ms B 785527736
404 ms A 785527736
328 ms B 785527736
410 ms
333 ms
그럼 왜? 바이트 코드는 다음과 같습니다.
private static multiB(int arg0) { // 2 * (i * i)
<localVar:index=0, name=i , desc=I, sig=null, start=L1, end=L2>
L1 {
iconst_2
iload0
iload0
imul
imul
ireturn
}
L2 {
}
}
private static multi(int arg0) { // 2 * i * i
<localVar:index=0, name=i , desc=I, sig=null, start=L1, end=L2>
L1 {
iconst_2
iload0
imul
iload0
imul
ireturn
}
L2 {
}
}
츠키다( 「 」 )2 * (i * i)
- 푸시 컨스턴스택
- 스택에 로컬 푸시
- 스택에 로컬 푸시
- 겹겹이 쌓다
- 겹겹이 쌓다
(「」)2 * i * i
- 푸시 컨스턴스택
- 스택에 로컬 푸시
- 겹겹이 쌓다
- 스택에 로컬 푸시
- 겹겹이 쌓다
스택에 모든 것을 로드하고 나서, 다시 다운하는 것은, 스택에의 배치와 동작의 전환보다 빠릅니다.
Kasperd는 인정된 답변의 코멘트에서 다음과 같이 물었다.
Java와 C의 예에서는 전혀 다른 레지스터 이름을 사용합니다.두 예 모두 AMD64 ISA를 사용하고 있습니까?
xor edx, edx
xor eax, eax
.L2:
mov ecx, edx
imul ecx, edx
add edx, 1
lea eax, [rax+rcx*2]
cmp edx, 1000000000
jne .L2
코멘트로 대답할 만한 평판은 없지만, 같은 ISA입니다.GCC 버전은 32비트 정수 로직을 사용하고 JVM 컴파일 버전은 내부적으로 64비트 정수 로직을 사용합니다.
R8에서 R15는 새로운 X86_64 레지스터입니다.EAX to EDX는 RAX to RDX 범용 레지스터의 하부 부분입니다.답변에서 중요한 부분은 GCC 버전이 언롤되지 않는다는 것입니다.실제 머신 코드 루프마다 루프를 1라운드만 실행합니다.JVM 버전은 1개의 물리 루프에 16라운드의 루프가 있지만(rustx의 답변에 근거해, 어셈블리의 재해석은 실시하지 않았습니다.루프 본체가 실제로 16배 길기 때문에 사용되는 레지스터가 많아지는 이유 중 하나입니다.
질문의 환경과 직접 관련된 것은 아니지만 궁금해서 동일한 테스트를 에 수행했습니다.NET Core 2.1, x64, 릴리즈 모드
여기 흥미로운 결과가 있다.힘의 어두운 면에서도 유사한 포메나가 일어나고 있음을 확인시켜 준다.코드:
static void Main(string[] args)
{
Stopwatch watch = new Stopwatch();
Console.WriteLine("2 * (i * i)");
for (int a = 0; a < 10; a++)
{
int n = 0;
watch.Restart();
for (int i = 0; i < 1000000000; i++)
{
n += 2 * (i * i);
}
watch.Stop();
Console.WriteLine($"result:{n}, {watch.ElapsedMilliseconds} ms");
}
Console.WriteLine();
Console.WriteLine("2 * i * i");
for (int a = 0; a < 10; a++)
{
int n = 0;
watch.Restart();
for (int i = 0; i < 1000000000; i++)
{
n += 2 * i * i;
}
watch.Stop();
Console.WriteLine($"result:{n}, {watch.ElapsedMilliseconds}ms");
}
}
결과:
2 * (i * i )
- 결과: 119860736, 438밀리초
- 결과: 119860736, 433밀리초
- 결과: 119860736, 437밀리초
- 결과: 119860736, 435밀리초
- 결과: 119860736, 436밀리초
- 결과: 119860736, 435밀리초
- 결과: 119860736, 435밀리초
- 결과: 119860736, 439 밀리초
- 결과: 119860736, 436밀리초
- 결과: 119860736, 437밀리초
2 * i * i
- 결과: 119860736, 417 밀리초
- 결과: 119860736, 417 밀리초
- 결과: 119860736, 417 밀리초
- 결과: 119860736, 418밀리초
- 결과: 119860736, 418밀리초
- 결과: 119860736, 417 밀리초
- 결과: 119860736, 418밀리초
- 결과: 119860736, 416밀리초
- 결과: 119860736, 417 밀리초
- 결과: 119860736, 418밀리초
비슷한 결과를 얻었습니다.
2 * (i * i): 0.458765943 s, n=119860736
2 * i * i: 0.580255126 s, n=119860736
두 루프가 같은 프로그램에 있거나 각각 다른 실행으로 실행되는 별도의 .java 파일/.class에 있는 경우에도 동일한 결과를 얻을 수 있습니다.
마지막으로 여기 있습니다.javap -c -v <.java>각 디컴파일:
3: ldc #3 // String 2 * (i * i):
5: invokevirtual #4 // Method java/io/PrintStream.print:(Ljava/lang/String;)V
8: invokestatic #5 // Method java/lang/System.nanoTime:()J
8: invokestatic #5 // Method java/lang/System.nanoTime:()J
11: lstore_1
12: iconst_0
13: istore_3
14: iconst_0
15: istore 4
17: iload 4
19: ldc #6 // int 1000000000
21: if_icmpge 40
24: iload_3
25: iconst_2
26: iload 4
28: iload 4
30: imul
31: imul
32: iadd
33: istore_3
34: iinc 4, 1
37: goto 17
대.
3: ldc #3 // String 2 * i * i:
5: invokevirtual #4 // Method java/io/PrintStream.print:(Ljava/lang/String;)V
8: invokestatic #5 // Method java/lang/System.nanoTime:()J
11: lstore_1
12: iconst_0
13: istore_3
14: iconst_0
15: istore 4
17: iload 4
19: ldc #6 // int 1000000000
21: if_icmpge 40
24: iload_3
25: iconst_2
26: iload 4
28: imul
29: iload 4
31: imul
32: iadd
33: istore_3
34: iinc 4, 1
37: goto 17
참고 -
java -version
java version "1.8.0_121"
Java(TM) SE Runtime Environment (build 1.8.0_121-b13)
Java HotSpot(TM) 64-Bit Server VM (build 25.121-b13, mixed mode)
Java 11을 사용한 흥미로운 관찰 및 다음 VM 옵션을 사용하여 루프 롤링을 해제합니다.
-XX:LoopUnrollLimit=0
를 사용한 루프2 * (i * i)expression을 통해 보다 콤팩트한 네이티브1 코드가 생성됩니다.
L0001: add eax,r11d
inc r8d
mov r11d,r8d
imul r11d,r8d
shl r11d,1h
cmp r8d,r10d
jl L0001
와 비교하여2 * i * i버전:
L0001: add eax,r11d
mov r11d,r8d
shl r11d,1h
add r11d,2h
inc r8d
imul r11d,r8d
cmp r8d,r10d
jl L0001
Java 버전:
java version "11" 2018-09-25
Java(TM) SE Runtime Environment 18.9 (build 11+28)
Java HotSpot(TM) 64-Bit Server VM 18.9 (build 11+28, mixed mode)
벤치마크 결과:
Benchmark (size) Mode Cnt Score Error Units
LoopTest.fast 1000000000 avgt 5 694,868 ± 36,470 ms/op
LoopTest.slow 1000000000 avgt 5 769,840 ± 135,006 ms/op
벤치마크 소스 코드:
@BenchmarkMode(Mode.AverageTime)
@OutputTimeUnit(TimeUnit.MILLISECONDS)
@Warmup(iterations = 5, time = 5, timeUnit = TimeUnit.SECONDS)
@Measurement(iterations = 5, time = 5, timeUnit = TimeUnit.SECONDS)
@State(Scope.Thread)
@Fork(1)
public class LoopTest {
@Param("1000000000") private int size;
public static void main(String[] args) throws RunnerException {
Options opt = new OptionsBuilder()
.include(LoopTest.class.getSimpleName())
.jvmArgs("-XX:LoopUnrollLimit=0")
.build();
new Runner(opt).run();
}
@Benchmark
public int slow() {
int n = 0;
for (int i = 0; i < size; i++)
n += 2 * i * i;
return n;
}
@Benchmark
public int fast() {
int n = 0;
for (int i = 0; i < size; i++)
n += 2 * (i * i);
return n;
}
}
1 - 사용하는 VM 옵션:-XX:+UnlockDiagnosticVMOptions -XX:+PrintAssembly -XX:LoopUnrollLimit=0
기본 archetype을 사용하여 JMH를 시도했습니다.Runemoro의 설명을 바탕으로 최적화된 버전도 추가했습니다.
@State(Scope.Benchmark)
@Warmup(iterations = 2)
@Fork(1)
@Measurement(iterations = 10)
@OutputTimeUnit(TimeUnit.NANOSECONDS)
//@BenchmarkMode({ Mode.All })
@BenchmarkMode(Mode.AverageTime)
public class MyBenchmark {
@Param({ "100", "1000", "1000000000" })
private int size;
@Benchmark
public int two_square_i() {
int n = 0;
for (int i = 0; i < size; i++) {
n += 2 * (i * i);
}
return n;
}
@Benchmark
public int square_i_two() {
int n = 0;
for (int i = 0; i < size; i++) {
n += i * i;
}
return 2*n;
}
@Benchmark
public int two_i_() {
int n = 0;
for (int i = 0; i < size; i++) {
n += 2 * i * i;
}
return n;
}
}
결과는 다음과 같습니다.
Benchmark (size) Mode Samples Score Score error Units
o.s.MyBenchmark.square_i_two 100 avgt 10 58,062 1,410 ns/op
o.s.MyBenchmark.square_i_two 1000 avgt 10 547,393 12,851 ns/op
o.s.MyBenchmark.square_i_two 1000000000 avgt 10 540343681,267 16795210,324 ns/op
o.s.MyBenchmark.two_i_ 100 avgt 10 87,491 2,004 ns/op
o.s.MyBenchmark.two_i_ 1000 avgt 10 1015,388 30,313 ns/op
o.s.MyBenchmark.two_i_ 1000000000 avgt 10 967100076,600 24929570,556 ns/op
o.s.MyBenchmark.two_square_i 100 avgt 10 70,715 2,107 ns/op
o.s.MyBenchmark.two_square_i 1000 avgt 10 686,977 24,613 ns/op
o.s.MyBenchmark.two_square_i 1000000000 avgt 10 652736811,450 27015580,488 ns/op
PC(Core i7 860 - 스마트폰으로 읽는 것 이외에는 아무것도 하지 않습니다):
n += i*i그리고나서n*2첫 번째입니다2 * (i * i)두 번째입니다.
JVM은 Runemoro의 답변에 따라 인간과 같은 방식으로 최적화되지 않은 것이 분명합니다.
이제 바이트 코드를 읽습니다.javap -c -v ./target/classes/org/sample/MyBenchmark.class
- 2*(i*i)(왼쪽)와 2*i*i(오른쪽)의 차이:https://www.diffchecker.com/cvSFppWI
- 2*(i*i)와 최적화된 버전의 차이: https://www.diffchecker.com/I1XFu5dP
바이트 코드 전문가는 아니지만iload_2우리 앞에imul: 여기서 차이가 날 수 있습니다.JVM이 읽기를 최적화한다고 가정할 수 있습니다.i2회(i이미 존재하며 다시 로드할 필요가 없습니다.)2*i*i할 수 없어요.
부록에 가까워요.IBM의 최신 Java 8 JVM을 사용하여 실험을 재평가했습니다.
java version "1.8.0_191"
Java(TM) 2 Runtime Environment, Standard Edition (IBM build 1.8.0_191-b12 26_Oct_2018_18_45 Mac OS X x64(SR5 FP25))
Java HotSpot(TM) 64-Bit Server VM (build 25.191-b12, mixed mode)
그리고 이것은 매우 유사한 결과를 보여줍니다.
0.374653912 s
n = 119860736
0.447778698 s
n = 119860736
(2 * i * i 를 사용한 두 번째 결과).
흥미롭게도 Oracle Java를 사용하여 동일한 머신에서 실행할 경우:
Java version "1.8.0_181"
Java(TM) SE Runtime Environment (build 1.8.0_181-b13)
Java HotSpot(TM) 64-Bit Server VM (build 25.181-b13, mixed mode)
결과는 평균 조금 느립니다.
0.414331815 s
n = 119860736
0.491430656 s
n = 119860736
간단히 말하면, 여기에서는, JIT의 실장내의 미묘한 차이 때문에, HotSpot의 마이너 버전 번호도 중요합니다.
를 추가하는 두 가지 방법은 약간 다른 바이트 코드를 생성합니다.
17: iconst_2
18: iload 4
20: iload 4
22: imul
23: imul
24: iadd
위해서2 * (i * i)vs:
17: iconst_2
18: iload 4
20: imul
21: iload 4
23: imul
24: iadd
위해서2 * i * i.
JMH 벤치마크를 다음과 같이 사용하는 경우:
@Warmup(iterations = 5, batchSize = 1)
@Measurement(iterations = 5, batchSize = 1)
@Fork(1)
@BenchmarkMode(Mode.AverageTime)
@OutputTimeUnit(TimeUnit.MILLISECONDS)
@State(Scope.Benchmark)
public class MyBenchmark {
@Benchmark
public int noBrackets() {
int n = 0;
for (int i = 0; i < 1000000000; i++) {
n += 2 * i * i;
}
return n;
}
@Benchmark
public int brackets() {
int n = 0;
for (int i = 0; i < 1000000000; i++) {
n += 2 * (i * i);
}
return n;
}
}
차이는 명확합니다.
# JMH version: 1.21
# VM version: JDK 11, Java HotSpot(TM) 64-Bit Server VM, 11+28
# VM options: <none>
Benchmark (n) Mode Cnt Score Error Units
MyBenchmark.brackets 1000000000 avgt 5 380.889 ± 58.011 ms/op
MyBenchmark.noBrackets 1000000000 avgt 5 512.464 ± 11.098 ms/op
관찰한 내용은 정확하며 단순히 벤치마크 스타일의 이상이 아닙니다(예: 워밍업하지 않음, Java에서 올바른 마이크로 벤치마크를 작성하는 방법 참조).
Graal과 함께 다시 실행:
# JMH version: 1.21
# VM version: JDK 11, Java HotSpot(TM) 64-Bit Server VM, 11+28
# VM options: -XX:+UnlockExperimentalVMOptions -XX:+EnableJVMCI -XX:+UseJVMCICompiler
Benchmark (n) Mode Cnt Score Error Units
MyBenchmark.brackets 1000000000 avgt 5 335.100 ± 23.085 ms/op
MyBenchmark.noBrackets 1000000000 avgt 5 331.163 ± 50.670 ms/op
Graal은 전반적으로 성능이 우수하고 보다 현대적인 컴파일러이기 때문에 결과가 훨씬 비슷하다는 것을 알 수 있습니다.
따라서 이는 JIT 컴파일러가 특정 코드를 얼마나 잘 최적화할 수 있느냐에 달려 있을 뿐 논리적 이유가 반드시 있는 것은 아닙니다.
언급URL : https://stackoverflow.com/questions/53452713/why-is-2-i-i-faster-than-2-i-i-in-java
'programing' 카테고리의 다른 글
| 비밀번호로 String보다 char[]가 선호되는 이유는 무엇입니까? (0) | 2022.08.24 |
|---|---|
| 어레이 이름이 포인터입니까? (0) | 2022.08.24 |
| vue2-dataerange-picker 드롭다운에서 연도 선택 (0) | 2022.08.21 |
| Kotlin과 Java의 String은 무엇입니까? (0) | 2022.08.21 |
| Vue 슬롯이 드물고 예측할 수 없는 경우(잠재적인 vue 버그)에서 작동하지 않습니다. (0) | 2022.08.21 |