x64 Java에서 int보다 긴 이유는 무엇입니까?

Question 1

Surface Pro 2 태블릿에서 Java 7 업데이트 45 x64 (32 비트 Java가 설치되지 않음)와 함께 Windows 8.1 x64를 실행하고 있습니다.

아래 코드는 i 유형이 길면 1688ms, i가 정수이면 109ms가 걸립니다. 64 비트 JVM이있는 64 비트 플랫폼에서 long (64 비트 유형)이 int보다 훨씬 느린 이유는 무엇입니까?

내 유일한 추측은 CPU가 32 비트 정수보다 64 비트 정수를 추가하는 데 더 오래 걸리지 만 그럴 것 같지 않다는 것입니다. Haswell이 잔물결 운반 가산기를 사용하지 않는 것 같습니다.

Eclipse Kepler SR1, btw에서 이것을 실행하고 있습니다.

public class Main {

    private static long i = Integer.MAX_VALUE;

    public static void main(String[] args) {    
        System.out.println("Starting the loop");
        long startTime = System.currentTimeMillis();
        while(!decrementAndCheck()){
        }
        long endTime = System.currentTimeMillis();
        System.out.println("Finished the loop in " + (endTime - startTime) + "ms");
    }

    private static boolean decrementAndCheck() {
        return --i < 0;
    }

}

편집 : 다음은 동일한 시스템 인 VS 2013 (아래)에서 컴파일 한 동등한 C ++ 코드의 결과입니다. ~~long : 72265ms int : 74656ms~~ 그 결과는 디버그 32 비트 모드였습니다.

64 비트 릴리스 모드 : ~~긴 : 875ms~~ long long : 906ms int : 1047ms

이것은 내가 관찰 한 결과가 CPU 제한이 아닌 JVM 최적화 이상임을 시사합니다.

#include "stdafx.h"
#include "iostream"
#include "windows.h"
#include "limits.h"

long long i = INT_MAX;

using namespace std;


boolean decrementAndCheck() {
return --i < 0;
}


int _tmain(int argc, _TCHAR* argv[])
{


cout << "Starting the loop" << endl;

unsigned long startTime = GetTickCount64();
while (!decrementAndCheck()){
}
unsigned long endTime = GetTickCount64();

cout << "Finished the loop in " << (endTime - startTime) << "ms" << endl;



}

편집 : Java 8 RTM에서 다시 시도했지만 큰 변화는 없습니다.

Question 2

내 JVM은 longs 를 사용할 때 내부 루프에 대해 매우 간단한 작업을 수행합니다 .

0x00007fdd859dbb80: test   %eax,0x5f7847a(%rip)  /* fun JVM hack */
0x00007fdd859dbb86: dec    %r11                  /* i-- */
0x00007fdd859dbb89: mov    %r11,0x258(%r10)      /* store i to memory */
0x00007fdd859dbb90: test   %r11,%r11             /* unnecessary test */
0x00007fdd859dbb93: jge    0x00007fdd859dbb80    /* go back to the loop top */

ints 를 사용하면 속임수를 쓰게됩니다 . 먼저 내가 이해한다고 주장하지 않지만 풀린 루프에 대한 설정처럼 보이는 약간의 나사가 있습니다.

0x00007f3dc290b5a1: mov    %r11d,%r9d
0x00007f3dc290b5a4: dec    %r9d
0x00007f3dc290b5a7: mov    %r9d,0x258(%r10)
0x00007f3dc290b5ae: test   %r9d,%r9d
0x00007f3dc290b5b1: jl     0x00007f3dc290b662
0x00007f3dc290b5b7: add    $0xfffffffffffffffe,%r11d
0x00007f3dc290b5bb: mov    %r9d,%ecx
0x00007f3dc290b5be: dec    %ecx              
0x00007f3dc290b5c0: mov    %ecx,0x258(%r10)   
0x00007f3dc290b5c7: cmp    %r11d,%ecx
0x00007f3dc290b5ca: jle    0x00007f3dc290b5d1
0x00007f3dc290b5cc: mov    %ecx,%r9d
0x00007f3dc290b5cf: jmp    0x00007f3dc290b5bb
0x00007f3dc290b5d1: and    $0xfffffffffffffffe,%r9d
0x00007f3dc290b5d5: mov    %r9d,%r8d
0x00007f3dc290b5d8: neg    %r8d
0x00007f3dc290b5db: sar    $0x1f,%r8d
0x00007f3dc290b5df: shr    $0x1f,%r8d
0x00007f3dc290b5e3: sub    %r9d,%r8d
0x00007f3dc290b5e6: sar    %r8d
0x00007f3dc290b5e9: neg    %r8d
0x00007f3dc290b5ec: and    $0xfffffffffffffffe,%r8d
0x00007f3dc290b5f0: shl    %r8d
0x00007f3dc290b5f3: mov    %r8d,%r11d
0x00007f3dc290b5f6: neg    %r11d
0x00007f3dc290b5f9: sar    $0x1f,%r11d
0x00007f3dc290b5fd: shr    $0x1e,%r11d
0x00007f3dc290b601: sub    %r8d,%r11d
0x00007f3dc290b604: sar    $0x2,%r11d
0x00007f3dc290b608: neg    %r11d
0x00007f3dc290b60b: and    $0xfffffffffffffffe,%r11d
0x00007f3dc290b60f: shl    $0x2,%r11d
0x00007f3dc290b613: mov    %r11d,%r9d
0x00007f3dc290b616: neg    %r9d
0x00007f3dc290b619: sar    $0x1f,%r9d
0x00007f3dc290b61d: shr    $0x1d,%r9d
0x00007f3dc290b621: sub    %r11d,%r9d
0x00007f3dc290b624: sar    $0x3,%r9d
0x00007f3dc290b628: neg    %r9d
0x00007f3dc290b62b: and    $0xfffffffffffffffe,%r9d
0x00007f3dc290b62f: shl    $0x3,%r9d
0x00007f3dc290b633: mov    %ecx,%r11d
0x00007f3dc290b636: sub    %r9d,%r11d
0x00007f3dc290b639: cmp    %r11d,%ecx
0x00007f3dc290b63c: jle    0x00007f3dc290b64f
0x00007f3dc290b63e: xchg   %ax,%ax /* OK, fine; I know what a nop looks like */

그런 다음 펼쳐진 루프 자체 :

0x00007f3dc290b640: add    $0xfffffffffffffff0,%ecx
0x00007f3dc290b643: mov    %ecx,0x258(%r10)
0x00007f3dc290b64a: cmp    %r11d,%ecx
0x00007f3dc290b64d: jg     0x00007f3dc290b640

그런 다음 펼쳐진 루프에 대한 분해 코드, 자체 테스트 및 직선 루프 :

0x00007f3dc290b64f: cmp    $0xffffffffffffffff,%ecx
0x00007f3dc290b652: jle    0x00007f3dc290b662
0x00007f3dc290b654: dec    %ecx
0x00007f3dc290b656: mov    %ecx,0x258(%r10)
0x00007f3dc290b65d: cmp    $0xffffffffffffffff,%ecx
0x00007f3dc290b660: jg     0x00007f3dc290b654

따라서 JIT가 int루프를 16 번 풀었지만 long루프를 전혀 풀지 않았기 때문에 int의 경우 16 배 더 빠릅니다 .

완전성을 위해 실제로 시도한 코드는 다음과 같습니다.

public class foo136 {
  private static int i = Integer.MAX_VALUE;
  public static void main(String[] args) {
    System.out.println("Starting the loop");
    for (int foo = 0; foo < 100; foo++)
      doit();
  }

  static void doit() {
    i = Integer.MAX_VALUE;
    long startTime = System.currentTimeMillis();
    while(!decrementAndCheck()){
    }
    long endTime = System.currentTimeMillis();
    System.out.println("Finished the loop in " + (endTime - startTime) + "ms");
  }

  private static boolean decrementAndCheck() {
    return --i < 0;
  }
}

어셈블리 덤프는 옵션을 사용하여 생성되었습니다 -XX:+UnlockDiagnosticVMOptions -XX:+PrintAssembly. 이 작업을 수행하려면 JVM 설치를 엉망으로 만들어야합니다. 임의의 공유 라이브러리를 정확한 위치에 배치해야합니다. 그렇지 않으면 실패합니다.

Question 3

JVM 스택은 단어 로 정의되며 , 그 크기는 구현 세부 사항이지만 최소 32 비트 너비 여야합니다. JVM 구현 자는 64 비트 단어를 사용할 수 있지만 바이트 코드는 이에 의존 할 수 없으므로 long또는 double값을 사용하는 작업 은 특별히주의하여 처리해야합니다. 특히 JVM 정수 분기 명령 은 정확히 유형에 정의되어 int있습니다.

코드의 경우 분해가 도움이됩니다. 다음 int은 Oracle JDK 7에 의해 컴파일 된 버전 의 바이트 코드입니다 .

private static boolean decrementAndCheck();
  Code:
     0: getstatic     #14  // Field i:I
     3: iconst_1      
     4: isub          
     5: dup           
     6: putstatic     #14  // Field i:I
     9: ifge          16
    12: iconst_1      
    13: goto          17
    16: iconst_0      
    17: ireturn

JVM은 정적 값 i(0) 을로드하고 1 (3-4)을 빼고 스택 (5)에 값을 복제 한 다음 변수 (6)로 다시 푸시합니다. 그런 다음 0과 비교 분기를 수행하고 반환합니다.

가있는 버전 long은 좀 더 복잡합니다.

private static boolean decrementAndCheck();
  Code:
     0: getstatic     #14  // Field i:J
     3: lconst_1      
     4: lsub          
     5: dup2          
     6: putstatic     #14  // Field i:J
     9: lconst_0      
    10: lcmp          
    11: ifge          18
    14: iconst_1      
    15: goto          19
    18: iconst_0      
    19: ireturn

첫째, JVM이 스택 (5)에 새 값을 복제 할 때 두 개의 스택 단어를 복제해야합니다. 귀하의 경우 JVM은 편리하다면 64 비트 단어를 자유롭게 사용할 수 있기 때문에 복제하는 것보다 더 비싸지 않을 수 있습니다. 그러나 여기서 분기 논리가 더 길다는 것을 알 수 있습니다. JVM에는 a long를 0과 비교하는 명령이 없으므로 상수 0L를 스택 (9) 으로 푸시 하고 일반 long비교 (10)를 수행 한 다음 해당 계산 값을 분기 해야 합니다.

다음은 그럴듯한 두 가지 시나리오입니다.

JVM은 정확히 바이트 코드 경로를 따릅니다. 이 경우 long버전 에서 더 많은 작업을 수행하고 몇 가지 추가 값을 푸시하고 팝 하며 이는 실제 하드웨어 지원 CPU 스택이 아닌 가상 관리 스택 에 있습니다. 이 경우 워밍업 후에도 상당한 성능 차이를 볼 수 있습니다.
JVM은이 코드를 최적화 할 수 있음을 인식합니다. 이 경우 실제로 불필요한 푸시 / 비교 로직 중 일부를 최적화하는 데 추가 시간이 걸립니다. 이 경우 예열 후 성능 차이가 거의 나타나지 않습니다.

난 당신이 추천 정확한 마이크로 벤치 쓰기 의 JIT 킥을 가지고, 또한에서 동일한 비교를 수행 할 JVM을 강제로 0이 아닌 최종 조건이 노력의 효과를 제거하기 int가 함께한다는 것을를 long.

Question 4

Java Virtual Machine에서 데이터의 기본 단위는 단어입니다. 올바른 단어 크기를 선택하는 것은 JVM 구현에 달려 있습니다. JVM 구현은 32 비트의 최소 단어 크기를 선택해야합니다. 효율성을 얻기 위해 더 높은 단어 크기를 선택할 수 있습니다. 64 비트 JVM이 64 비트 워드 만 선택해야한다는 제한도 없습니다.

기본 아키텍처는 단어 크기도 동일해야한다고 규정하지 않습니다. JVM은 단어 단위로 데이터를 읽고 / 씁니다. 이것이 int 보다 오래 걸리는 이유 입니다.

여기 에서 동일한 주제에 대해 더 많이 찾을 수 있습니다.

Question 5

방금 caliper를 사용하여 벤치 마크를 작성했습니다 .

결과를 사용하기위한 ~ 12 배 속도 향상 : 원래의 코드와 상당히 일치 int이상 long. tmyklebu 또는 매우 유사한 것으로보고 된 루프 언 롤링 이 진행되고있는 것 같습니다.

timeIntDecrements         195,266,845.000
timeLongDecrements      2,321,447,978.000

이것은 내 코드입니다. caliper기존 베타 릴리스에 대해 코딩하는 방법을 알 수 없었기 때문에 새로 빌드 된의 스냅 샷을 사용합니다 .

package test;

import com.google.caliper.Benchmark;
import com.google.caliper.Param;

public final class App {

    @Param({""+1}) int number;

    private static class IntTest {
        public static int v;
        public static void reset() {
            v = Integer.MAX_VALUE;
        }
        public static boolean decrementAndCheck() {
            return --v < 0;
        }
    }

    private static class LongTest {
        public static long v;
        public static void reset() {
            v = Integer.MAX_VALUE;
        }
        public static boolean decrementAndCheck() {
            return --v < 0;
        }
    }

    @Benchmark
    int timeLongDecrements(int reps) {
        int k=0;
        for (int i=0; i<reps; i++) {
            LongTest.reset();
            while (!LongTest.decrementAndCheck()) { k++; }
        }
        return (int)LongTest.v | k;
    }    

    @Benchmark
    int timeIntDecrements(int reps) {
        int k=0;
        for (int i=0; i<reps; i++) {
            IntTest.reset();
            while (!IntTest.decrementAndCheck()) { k++; }
        }
        return IntTest.v | k;
    }
}

Question 6

기록을 위해이 버전은 조잡한 "예열"을 수행합니다.

public class LongSpeed {

    private static long i = Integer.MAX_VALUE;
    private static int j = Integer.MAX_VALUE;

    public static void main(String[] args) {

        for (int x = 0; x < 10; x++) {
            runLong();
            runWord();
        }
    }

    private static void runLong() {
        System.out.println("Starting the long loop");
        i = Integer.MAX_VALUE;
        long startTime = System.currentTimeMillis();
        while(!decrementAndCheckI()){

        }
        long endTime = System.currentTimeMillis();

        System.out.println("Finished the long loop in " + (endTime - startTime) + "ms");
    }

    private static void runWord() {
        System.out.println("Starting the word loop");
        j = Integer.MAX_VALUE;
        long startTime = System.currentTimeMillis();
        while(!decrementAndCheckJ()){

        }
        long endTime = System.currentTimeMillis();

        System.out.println("Finished the word loop in " + (endTime - startTime) + "ms");
    }

    private static boolean decrementAndCheckI() {
        return --i < 0;
    }

    private static boolean decrementAndCheckJ() {
        return --j < 0;
    }

}

전체 시간은 약 30 % 개선되지만 둘 사이의 비율은 거의 동일하게 유지됩니다.

Question 7

기록을 위해 :

내가 사용한다면

boolean decrementAndCheckLong() {
    lo = lo - 1l;
    return lo < -1l;
}

( "l--"을 "l = l-1l"로 변경) 긴 성능이 ~ 50 % 향상됩니다.

Question 8

테스트 할 64 비트 머신은 없지만 다소 큰 차이는 작업에서 약간 더 긴 바이트 코드 이상이 있음을 나타냅니다.

32 비트 1.7.0_45에서 long / int (4400 vs 4800ms)에 대한 매우 가까운 시간이 보입니다.

이것은 추측 일 뿐이지 만 메모리 정렬 불량 페널티의 효과 라고 강력히 의심합니다. 의심을 확인 / 거부하려면 public static int dummy = 0을 추가해보십시오. i 선언 전에 . 그러면 메모리 레이아웃에서 i를 4 바이트까지 밀어 내고 더 나은 성능을 위해 올바르게 정렬 할 수 있습니다. 문제를 일으키지 않는 것으로 확인되었습니다.

편집하다: ~~그 이유는 VM이 JNI를 방해 할 수 있으므로 최적의 정렬을 위해 패딩을 추가하여 여유 시간에 필드 를 재정렬하지 않을 수 있기 때문입니다.~~ (경우가 아님).