[java] Java에서 올바른 마이크로 벤치 마크를 작성하는 방법

Java에서 올바른 마이크로 벤치 마크를 작성하고 실행하는 방법은 무엇입니까?

생각할 다양한 것들을 보여주는 코드 샘플과 주석을 찾고 있습니다.

예 : 벤치 마크가 시간 / 반복 또는 반복 / 시간을 측정해야하는 이유는 무엇입니까?

관련 : 스톱워치 벤치마킹이 허용됩니까?



답변

Java HotSpot 제작자의 마이크로 벤치 마크 작성에 대한 팁 :

규칙 0 : JVM 및 마이크로 벤치마킹에 대한 평판이 좋은 논문을 읽으십시오. 좋은 것은 Brian Goetz, 2005 입니다. 마이크로 벤치 마크에서 너무 많이 기대하지 마십시오. 제한된 범위의 JVM 성능 특성 만 측정합니다.

규칙 1 : 타이밍 단계 전에 모든 초기화 및 컴파일을 트리거 할 수있을만큼 테스트 커널을 완전히 실행하는 워밍업 단계를 항상 포함하십시오. 예열 단계에서는 반복 횟수가 적습니다. 일반적으로 수만 개의 내부 루프 반복이 있습니다.

규칙 2 : 항상 실행 -XX:+PrintCompilation, -verbose:gc당신은 컴파일러와 JVM의 다른 부분은 타이밍 단계에서 예상치 못한 일을하지 않는 것을 확인할 수 있도록, 등.

규칙 2.1 : 타이밍 및 워밍업 단계의 시작과 끝에 메시지를 인쇄하여 타이밍 단계 중에 규칙 2의 출력이 없는지 확인할 수 있습니다.

규칙 3 :-client 및 의 차이점 -server과 OSR 및 정기적 인 편집에 유의하십시오. 이 -XX:+PrintCompilation플래그는 초기 값이 아닌 진입 점을 표시하기 위해 at 기호로 OSR 컴파일을보고합니다 (예 🙂 Trouble$1::run @ 2 (41 bytes). 최상의 성능을 갖춘 경우 서버를 클라이언트로, OSR을 정기적으로 선호하십시오.

규칙 4 : 초기화 효과에 유의하십시오. 인쇄는 클래스를로드하고 초기화하기 때문에 타이밍 단계에서 처음으로 인쇄하지 마십시오. 클래스 로딩을 구체적으로 테스트하지 않는 한 (그리고이 경우 테스트 클래스 만로드) 워밍업 단계 (또는 최종보고 단계) 외부에 새 클래스를로드하지 마십시오. 규칙 2는 이러한 영향에 대한 첫 번째 방어선입니다.

규칙 5 : 최적화 해제 및 재 컴파일 효과에 유의하십시오. 경로가 전혀 사용되지 않을 것이라는 이전의 낙관적 인 가정에 따라 컴파일러가 코드를 정크 및 재 컴파일 할 수 있으므로 타이밍 단계에서 처음으로 코드 경로를 사용하지 마십시오. 규칙 2는 이러한 영향에 대한 첫 번째 방어선입니다.

규칙 6 : 적절한 도구를 사용하여 컴파일러의 마음을 읽고, 생성하는 코드에 놀라게 될 것입니다. 무언가를 더 빠르거나 느리게 만드는 것에 대한 이론을 만들기 전에 코드를 직접 검사하십시오.

규칙 7 : 측정시 노이즈를 줄입니다. 조용한 컴퓨터에서 벤치 마크를 실행하고 여러 번 실행하여 특이 치를 버립니다. -Xbatch컴파일러를 응용 프로그램과 직렬화하는 데 사용 하고 컴파일러가 -XX:CICompilerCount=1병렬로 실행되지 않도록 설정 하는 것을 고려 하십시오. GC 오버 헤드를 줄이고 최대한 Xmx(충분히) 동일하게 설정 Xms하고 가능한 UseEpsilonGC경우 사용하도록 최선을 다하십시오 .

규칙 8 : 벤치 마크에 라이브러리를 사용하는 것이 더 효율적일 수 있으며이 목적을 위해 이미 디버깅 되었기 때문입니다. 같은 JMH , 캘리퍼스 또는 빌과 자바에 대한 바울의 우수한 UCSD 벤치 마크 .


답변

이 질문에 대한 답변이 표시되었지만 마이크로 벤치 마크 작성에 도움이되는 두 개의 라이브러리를 언급하고 싶습니다.

Google의 캘리퍼스

튜토리얼 시작하기

  1. http://codingjunkie.net/micro-benchmarking-with-caliper/
  2. http://vertexlabs.co.uk/blog/caliper

OpenJDK의 JMH

튜토리얼 시작하기

  1. JVM에서 벤치마킹 함정 방지
  2. http://nitschinger.at/Using-JMH-for-Java-Microbenchmarking
  3. http://java-performance.info/jmh/

답변

Java 벤치 마크의 중요한 사항은 다음과 같습니다.

  • 코드 를 타이밍하기 전에 코드를 여러 번 실행하여 JIT를 먼저 예열 하십시오.
  • 결과를 초 또는 (더 나은) 수십 초로 측정 할 수있을 정도로 오래 실행하십시오
  • System.gc()반복 사이에 호출 할 수는 없지만 테스트간에 실행하는 것이 좋습니다. 따라서 각 테스트에서 “깨끗한”메모리 공간을 확보 할 수 있습니다. (예, gc()보증보다 힌트가 더 많지만 실제로 내 경험에서 가비지 수집 가능성큽니다 .)
  • 반복 및 시간을 표시하고 “최상의”알고리즘이 1.0의 점수를 얻고 다른 알고리즘이 상대적으로 점수가 매겨 질 수 있도록 시간 / 반복 점수를 표시하고 싶습니다. 즉 , 반복 횟수와 시간을 모두 바꾸면서도 모든 알고리즘을 오랫동안 실행할 수 있지만 여전히 비슷한 결과를 얻을 수 있습니다.

.NET에서 벤치마킹 프레임 워크 디자인에 대해 블로그하는 중입니다. 나는 당신에게 몇 가지 아이디어를 줄 수 있는 가지 초기 게시물을 가지고 있습니다. 물론 모든 것이 적절하지는 않지만 일부는 적합 할 수도 있습니다.


답변

jmh 는 OpenJDK에 최근 추가 된 것으로 Oracle의 일부 성능 엔지니어가 작성했습니다. 확실히 볼만한 가치가 있습니다.

jmh는 Java 및 JVM을 대상으로하는 다른 언어로 작성된 나노 / 마이크로 / 매크로 벤치 마크를 작성, 실행 및 분석하기위한 Java 하네스입니다.

샘플 테스트 주석에 묻힌 매우 흥미로운 정보 조각 .

또한보십시오:


답변

벤치 마크가 시간 / 반복 또는 반복 / 시간을 측정해야하는 이유는 무엇입니까?

이에 따라 무엇을 당신이 시험에 노력하고 있습니다.

대기 시간 에 관심이있는 경우 시간 / 반복을 사용 하고 처리량에 관심이있는 경우 반복 / 시간을 사용하십시오.


답변

두 알고리즘을 비교하려는 경우 순서에 따라 두 개 이상의 벤치 마크를 수행하십시오. 즉 :

for(i=1..n)
  alg1();
for(i=1..n)
  alg2();
for(i=1..n)
  alg2();
for(i=1..n)
  alg1();

다른 패스에서 동일한 알고리즘의 런타임에서 눈에 띄는 차이 (때로는 5-10 %)를 발견했습니다.

또한 각 루프의 런타임이 최소 10 초 정도가되도록 n 이 매우 큰지 확인하십시오 . 반복 횟수가 많을수록 벤치 마크 시간이 더 중요하고 데이터의 안정성이 높아집니다.


답변

어떻게 든 벤치마킹 된 코드로 계산 된 결과를 사용해야합니다. 그렇지 않으면 코드를 최적화 할 수 있습니다.