2 개의 작은 구조의 Performace 차이점

Question

다음 두 가지 사이에 성능 차이가 있는지 궁금합니다.

if(i>=0){ 
    //some code here 
} 

//and 

if(i>-1){ 
    //some code here 
} 

다음 두 가지는 무엇입니까?

if(i>=0){ 
    //some code here 
} 

//and 

if(i>0 || i==0){ 
    //some code here 
} 

은 >=는 내부적으로 > || ==로 변환 될 수 있습니까?

P. 성능 차이는 거의 없으며 무시할 수 있지만 성능 차이가 있는지 알고 싶습니까?

Answer 1

저는 첫 번째 방법이 더 좋다고 생각합니다.

두번째 3 개 비교 필요

1.
1. if (i > 0)
2. if (i == 0)
3. 부울 OR과 그러나

2, 실제 결과는 여전히 컴파일러 경우 의존 (같은 일을하기 때문에) 2 개의 코드를 동일하게 최적화 할 수 있습니다.

아마도 더 나은 아이디어 일 수 있습니다.

Answer 2

objdump을 사용하여 해당 어셈블리 코드를 확인하거나 런타임에 실제로 얼마나 많은 명령이 폐기되었는지 검사 할 수 있습니다. 그러나 파이프 라인을 사용하면 필요한 실제주기가 명확하지 않을 수 있습니다.

Answer 3

답변은 플랫폼에 따라 다릅니다. 즉, Java 설치시 하드웨어 플랫폼, ISA 및 JIT 컴파일러에 따라 다릅니다.

그리고 이것은 특정 하드웨어/ISA/JIT 컴파일러 플랫폼에 대한 마이크로 최적화 시간을 낭비하고 싶지 않기 때문에 대답을 알기가 매우 어렵습니다.

하지만 알아야 할 사항이 있다면 벤치 마크해야합니다 ... Java 벤치 마크에서 유효한 결과를 얻으려면 필요한 모든 작업을 수행해야합니다.

---

FWIW - 현대 JIT 컴파일러는 두 경우 모두 서브 케이스에 대해 동일한 원시 코드를 생성한다고 생각합니다. 즉, 사용하는 성능에 아무런 차이가 없어야합니다. 그러나 i>0 || i==0은 무의미한 난독 화이며 이러한 이유 때문에 피해야합니다.

Answer 4

현대 JVM에서 나는 이런 유형의 사고가 단지 무의미하다고 생각합니다. JVM은 코드를 컴파일하고 멈추지 않습니다. 은 런타임시 코드에 대해을 학습하고 그에 따라 동작을 수정합니다. 이제는 컴파일러 전문가가 아니지만 JVM이 매우 똑똑해서 실제로 if 문을 실행시에 최적화 할 수 있으므로 항상 i 값이 true 또는 false로 평가되는 것을 볼 수 있습니다.

코드를 이와 같이 미세한 방법으로 "최적화"하고 싶을 때마다, 속이기 때문에 JVM만큼 똑똑하지 않다는 것을 잊어 버려라. 실제로 코드가 실행될 때 코드가 실행되는 것을 확인하고 이에 따라 코드의 동작을 변경합니다.

VM이 얼마나 인상적인지에 대한 힌트를주는 Steve Yegge의 강연에서이 우수한 성적을 확인하십시오. 그리고 이것은 몇 년 전이었습니다! 추가 된 더 나은 예

이

http://steve-yegge.blogspot.com/2008/05/dynamic-languages-strike-back.html

지금은 불가능 방법 마이크로 벤치 마크에 대해 이야기 조쉬 블로흐 이야기에서 슬라이드입니다. 소스 코드 줄을보고 런타임에서 JVM이 수행 할 작업을 알 수 없습니다. 내가 좋아하는 슬라이드는 &&과 같은 단락 회로 연산자가 항상 더 빨랐지만 현대 하드웨어에서는 항상 더 이상 사실이 아닙니다. 직관적 인 방법과 완전히 반대되므로이 길로 내려 가기를 그만 두어야합니다. 당신은 정말 상관 경우 특정 플랫폼에 대한 벤치 마크를해야합니다 있도록

http://wiki.jvmlangsummit.com/images/1/1d/PerformanceAnxiety2010.pdf

Answer 5

그것은, 구현에 의존합니다.

처음 두

• 가 합리적으로 현대 하드웨어/JVM 조합에 아마 동일합니다
  는 말했다 가졌어요. 모든 비교는 최신 하드웨어에서 동일하게 수행되는 경향이 있습니다.
• 두 번째 두 번째 옵션의 첫 번째 옵션은 입니다. 똑똑한 컴파일러가 동등성을 발견하고 동일한 단일 네이티브 연산을 생성하는 동안, 현재의 JIT 컴파일러 중 일부는 이것을 발견하지 못할 것이라고 생각합니다. 그러나 읽기와 유지가 훨씬 명확하기 때문에 첫 번째 옵션을 사용해야합니다.