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차원 게임에서 충돌검사루틴이라면.. 이것은 장난아니겠죠.
사실.. 이것은 아주 단순한 예였고, 솔직히, 이것으로 속도 차이를 느낄 수 없겠지만..
이러한 현상은 아주 큰 틀에서도 역시 벌어진다는 것입니다. 즉 설계때 이러한 고려가 필요할 때가 발생한다는 것이죠.
예를 들어서 어떤 일을 할때 속도의 개선을 위해서 캐싱(caching) 루틴을 추가한다면 캐슁 오버헤드와 캐싱에 의한 속도증가를 검사해야합니다. 예를 들어서 캐싱 오버헤드가 1ms였고, 캐싱이 동작할 경우 벌어들이는 이득이 2ms였다고 해보죠.
캐싱에 저장된 곳을 액세스할 확률이 80%였다면, \(1ms - 2ms \cdot 0.8 = -0.6ms \) 로 매번 0.6ms 정도의 이득이 발생합니다.
그에 비해서 확률이 30%였다면, \( 1ms - 2ms \cdot 0.3 = 0.4ms\)로 매번 0.4ms 정도의 손해가 발생합니다.
캐슁 확률이 높다면 캐싱 오버헤드를 감안하더래도 캐싱 루틴을 짜 넣어 주는 것이 좋겠죠.
이 역시 확률에 의한 결정이 필요한 부분입니다.
프로그램을 짜다 보면.. 이런 확률에 대해서도 생각할 필요가 있으리라 생각됩니다.
'Programming > Game' 카테고리의 다른 글
Z Buffer vs. W Buffer (0) | 2011.09.22 |
---|---|
Culling vs. Clipping (0) | 2011.09.21 |
알파 오브젝트 정렬 (0) | 2011.09.19 |
이벤트 핸들링에서의 case 문장 (0) | 2011.09.16 |
댓글