if 문장 안에 쓴 조건문의 표현 방식에 따라서 속도차이가 발생한다는
것입니다.
요즘 진보된 프로세서에서는 이것마저도.. 아주 훌륭하게 잘 처리되고
있지만.. (실제.. 조건문을 두세단계정도는 미리 계산하는 것이 요즘
프로세서던가?? 테스트해보질 않아서.. 하하.. 나중에 기회가 되면 한번
속도 테스트해보아야지.. :)
예를 들어서 조건문 A의 확률이 80%, 조건문 B의 확률이 20%였다면..
다음의 두 프로그램은 같은 기능을 하지만 속도에서는 약간 차이가
발생한다.
if(A || B)
return;
if(B || A)
return;
이경우.. 첫번째 조건문은 80%확률로 A 조건을 검사하고, 20% 확률로
A 조건과 B 조건을 검사합니다.
두번째 조건문은 20% 확률로 B 조건을 검사하고 80% 확률로 A 조건과
B 조건을 검사합니다.
예를 들어서 이 조건문이 100번 불렸다면, 첫번째는 총 120번의 조건문
검사를 하고 두번째는 총 180번의 조건문 검사를 하게 되겠죠.
초당 수십만번 불리는 함수라면, 이 단순한 차이가 속도의 차이가 될 수
있습니다. 예를 들어서 3차원 게임에서 충돌검사루틴이라면.. 이것은
장난아니겠죠.
사실.. 이것은 아주 단순한 예였고, 솔직히, 이것으로 속도 차이를
느낄 수 없겠지만..
이러한 현상은 아주 큰 틀에서도 역시 벌어진다는 것입니다. 즉 설계때
이러한 고려가 필요할 때가 발생한다는 것이죠.
예를 들어서 어떤 일을 할때 속도의 개선을 위해서 캐슁 루틴을 추가한다면
캐슁 오버헤드와 캐슁에 의한 속도증가를 검사해야합니다. 예를 들어서
캐슁 오버헤드가 1ms였고, 캐슁이 동작할 경우 벌어들이는 이득이 2ms였다면..
이경우.. 캐슁에 의한 이득이 발생할 확률에 따라서 캐슁을 할 것인지
말것인지를 결정해주어야한다. 확률이 80%였다면..
1ms - 2ms * 0.8 = -0.6ms
즉 매번 0.6ms 정도의 이득이 발생한다.
그에 비해서 확률이 30%였다면.
1ms - 2ms * 0.3 = 0.4ms
즉 매번 0.4ms 정도의 손해가 발생한다.
캐슁 확률이 높다면 캐슁 오버헤드를 감안하더래도 캐슁 루틴을 짜 넣어
주는 것이 좋겠죠.
이 역시 확률에 의한 결정이 필요한 부분입니다.
프로그램을 짜다 보면.. 이런 확률에 대해서도 생각할 필요가 있으리라
생각됩니다.
출처 :
http://cafe.naver.com/dxgameprogramming.cafe?iframe_url=/ArticleRead.nhn%3Farticleid=980
알고리즘의설계_업로드용.ppt
www.cs.indiana.edu.zip