maintick이 매 1ms마다 1씩증가합니다.
이를 이용하여 매 초를 체크하고싶은데
1000을 나누어 나누어 떨어질 때를 1초로 체크하고싶습니다.
'%'나 '/'를 사용하자니 비용이 클꺼같아서
1000의 hex값인 0x3E8를 비트연산하여 체크하려는데 더 좋은방법이나 이 방식에 문제점이 있을까요?
u16 check1Sec(void) { return !(main_tick&0x3E8); }
$ printf "%x\n" 1000 3e8 $ printf "%x\n" 2000 7d0
결정적으로
$ printf "%03x\n" 1 001
고치고 있습니다 ㅎㅎ 제 생각이 짧았네요 ;;
그냥 머리아파서
u16 check1Sec(void) { return !(main_tick%1000); }
1000 = 125 * 8이니까.. 끝에 3비트가 0인지 체크만 해도 좀 빨라지지 않을까요..? 끝 3비트가 0이 아니면 1000의 배수가 아닌게 확실하니까요..
만약 이런 식이라면....
if ( t & 0x7 ) return false; ------------------ (1) return (t % 1000) == 0; ------- (2)
7/8의 확률로 1번에서 걸러지고.. 1/8의 확률로 2번을 거칠겁니다.(유니폼 확률로 인자가 주어진다고 할때.. 아니라면 입력 확률에 맞도록 알고리즘을 짜야죠..) (1)의 비용이 1, (2)의 비용이 n이라고 하면 총 비용의 평균은 7/8 + (n+1)/8이네요..
원래 방식(그냥 1000으로 나눠보는 방식)과 비교하면..
원래방식 > 비트 비교 방식 n > 7/8 + (n+1)/8 n > 8/7
1000 나누기 연산보다 비트 연산이 12.5%이상 빠르기만 하면 위 방식이 더 낫다고 할 수 있겠네요.. 맥주한잔하고 쓰는 내용이라 맞는지는 모르겠습니다.
오오, 흥미롭네요. ^^
www.gilgil.net
8/7=1.14...
=>1000모드연산시간이 &연산시간보다 8/7배이상 오래 걸리면 두번째 방법이 더 빠름. ==>&연산시간이 1000모드연산시간보다 1/(8/7)*100=12.5(%)빠르면 두번째 방법이 더 빠름.
감사합니다
정확히 1초일 필요가 없다면 1024틱마다 재는 수도 있습니다.
근데 /나 %연산이 아까워서 저렇게까지 할 필요가 있을까요?
http://www.gilgil.net/31635
결론 : 대충 알아서 코딩을 해도 C++ 컴파일러가 알아서 최적화를 해 준다.
와 감사합니다!!! 정말 많은 도움이 되었습니다. 컴파일러가 생각보다 많이! 똑똑하네요 ㅎㅎ
저도 가끔 어셈코드를 보는지라 컴파일러가 결과만 맞다면 무슨짓이든 한다..라는걸 알고 있었습니다만, 이정도인지는 몰랐네요.. 좋은 정보 감사합니다.
텍스트 포맷에 대한 자세한 정보
<code>
<blockcode>
<apache>
<applescript>
<autoconf>
<awk>
<bash>
<c>
<cpp>
<css>
<diff>
<drupal5>
<drupal6>
<gdb>
<html>
<html5>
<java>
<javascript>
<ldif>
<lua>
<make>
<mysql>
<perl>
<perl6>
<php>
<pgsql>
<proftpd>
<python>
<reg>
<spec>
<ruby>
<foo>
[foo]
$ printf "%x\n" 10003e8$
결정적으로
고치고 있습니다 ㅎㅎ 제 생각이 짧았네요 ;;
고치고 있습니다 ㅎㅎ 제 생각이 짧았네요 ;;
그냥 머리아파서 u16 check1Sec(void)
그냥 머리아파서
u16 check1Sec(void) { return !(main_tick%1000); }해버렸어요 ㅎㅎ
1000 = 125 * 8이니까.. 끝에 3비트가
1000 = 125 * 8이니까.. 끝에 3비트가 0인지 체크만 해도 좀 빨라지지 않을까요..?
끝 3비트가 0이 아니면 1000의 배수가 아닌게 확실하니까요..
만약 이런 식이라면....
if ( t & 0x7 ) return false; ------------------ (1)
return (t % 1000) == 0; ------- (2)
7/8의 확률로 1번에서 걸러지고.. 1/8의 확률로 2번을 거칠겁니다.(유니폼 확률로 인자가 주어진다고 할때.. 아니라면 입력 확률에 맞도록 알고리즘을 짜야죠..)
(1)의 비용이 1, (2)의 비용이 n이라고 하면 총 비용의 평균은 7/8 + (n+1)/8이네요..
원래 방식(그냥 1000으로 나눠보는 방식)과 비교하면..
원래방식 > 비트 비교 방식
n > 7/8 + (n+1)/8
n > 8/7
1000 나누기 연산보다 비트 연산이 12.5%이상 빠르기만 하면 위 방식이 더 낫다고 할 수 있겠네요..
맥주한잔하고 쓰는 내용이라 맞는지는 모르겠습니다.
gilgil.net
오오, 흥미롭네요. ^^
www.gilgil.net
보충.
8/7=1.14...
좀더...
=>1000모드연산시간이 &연산시간보다 8/7배이상 오래 걸리면 두번째 방법이 더 빠름.
==>&연산시간이 1000모드연산시간보다 1/(8/7)*100=12.5(%)빠르면 두번째 방법이 더 빠름.
감사합니다
감사합니다
정확히 1초일 필요가 없다면 1024틱마다 재는 수도
정확히 1초일 필요가 없다면
1024틱마다 재는 수도 있습니다.
근데 /나 %연산이 아까워서 저렇게까지 할 필요가 있을까요?
다양한 modulo 연산자에 대해서 테스트를 해 보았습니다.
http://www.gilgil.net/31635
결론 : 대충 알아서 코딩을 해도 C++ 컴파일러가 알아서 최적화를 해 준다.
www.gilgil.net
와 감사합니다!!! 정말 많은 도움이
와 감사합니다!!! 정말 많은 도움이 되었습니다.
컴파일러가 생각보다 많이! 똑똑하네요 ㅎㅎ
저도 가끔 어셈코드를 보는지라 컴파일러가 결과만
저도 가끔 어셈코드를 보는지라 컴파일러가 결과만 맞다면 무슨짓이든 한다..라는걸 알고 있었습니다만, 이정도인지는 몰랐네요..
좋은 정보 감사합니다.
댓글 달기