정렬 알고리즘에 대한 테스트를 설계 할 때 JVM 워밍업을 방지하기 위해이 방법을 사용할 수 있습니까? 고맙습니다!jvm warmup 피하기
double count = 0;
double start, end;
for(int r = 0; r < warmup; r++) {
// do test
}
for(int t = 0; t < runs; t++){
start = System.nanoTime();
// do test
end = System.nanoTime();
count += start - end;
}
double avg = count/avg
JVM을 예열은 일반적으로 JVM은 핫스팟 및 JIT 코드의 다음 섹션을 찾을하는 데 걸리는 시간을 의미합니다. 실제 테스트를 실행하면 몇 백 (실제로는 수천이라고 생각합니다) 시간에 당신은 꽤 잘 가야합니다.
그러나 이렇게해도 보증을받을 수는 없습니다. 중요한 파트가 JITed되기 전에 얼마나 많은 작업을해야하는지 파악하기 위해 특정 JVM을 시험해야합니다.
this little case study에서 1700 호출 후에 JIT 컴파일이 시작되었습니다.
흠. 루프가 실제로 정렬 테스트를 실행한다면?! –
아, 죄송합니다. 나는 당신이 실제로 초기 루프에서 테스트를 실행했다는 것을 몰랐다. 예, 더 잘 작동합니다. 내 대답을 업데이트 할게. – aioobe
예. 워밍업 루프는 실제 테스트를 실행하기 때문에 모든 클래스 등이로드되고 JIT 컴파일이 실행 된 상태 여야합니다.
정렬 알고리즘에 대한 테스트를 설계 할 때 JVM 워밍업을 방지하기 위해이 방법을 사용할 수 있습니까?
일부 보행자 먼저. 을 사용하지 마십시오. JVM 예열을 피하십시오. 그것은 일어날 필요가있다. 당신이하려고하는 것은 JVM 워밍업이 에서 여러분의 벤치 마크 결과 인을 왜곡시키지 않도록하는 것입니다.
귀하의 질문에 대한 답변을 얻으려면 대략적인 방법이 있지만 초기 루프에서 테스트를 수행해야하는 횟수를 예측하는 것은 매우 어렵습니다. 테스트 코드, JVM 버전 및 JVM 튜닝 매개 변수에 의존 할 가능성이 높습니다.
일반적으로 원시 타이밍을 인쇄하고 "눈으로"비정상적인 타이밍 값이 나타나는 것으로 보이는 초기 "예열"반복을 필터링 한 다음 평균을 계산합니다. 그것은 clunky이지만, 그것은 내가 워밍업과 다른 가능한 원인을 설명했다는 확신을 준다.
이 매우 큰 지역이지만, 여기에 몇 가지 팁입니다 :
1) 반복 루프를 포함하여 전체 테스트 (확인)를 반복해서 호출되는 서브 루틴입니다. 그래서 당신의 테스트는 "부모"메소드에 for() 루프를 가지고있다. 그것을 "하위"로 밀어 넣고 반복적으로 호출하십시오. 이를 통해 다양한 JIT 기술이 기내 코드 교체 (dynamic loop transfer 등)없이 실제로 완전히 최적화 할 수 있습니다.
2) 긴 워밍업 후 오랜 시간 동안 테스트가 실행되는지 확인하십시오. 가능하다면 30 초는 실제 측정 기간 동안 동일하게 긴 워밍업 후 최소값입니다. 예를 들어, SPECjbb 등은 여러 반복에 대해 반복 당 몇 분 동안 실행됩니다.
여전히 5,000 요소 정렬을 벤치마킹하려고합니까, 아니면 이전 질문에서 주어진 조언을 따르기로 결정 했습니까? 그리고 그 조언을 따르기로 결심했다면, 대답 중 하나를 받아 들여야합니다. – Anon
고마워요, 고맙습니다. – Ang