수십 배면 양반이고 시스템에 따라 수백 배 느릴 수도 있습니다. 옛날에 회사 다닐 때 속도를 시스템 별로 조사한 적이 있었는데 지금은 다 까먹었지만 -.- 시스템 중에 아예 정수 나눗셈을 하드웨어에서 지원하지 않는 경우도 있더군요. 이런 데서 % 쓰면 우리가 국민학교에서 배우는 나눗셈 알고리듬을 기계어로 짜서 돌린다는 얘기죠.
그런데 이걸 제대로 테스트해 보려면, 원래 코드처럼 % 8 해버리면 웬만한 컴파일러는 다 비트 연산으로 최적화를 해버리니까 임의의 숫자를 받아서 %를 돌려주는 함수를 만들고 다른 데서 불러보면서 테스트해 보시면 됩니다. 차이가 확연할 겁니다.
똑같을 때 %보다 &이
똑같을 때 %보다 &이 빠르지 않나요?
그런데..
구조적으로 % 연산이 어떤 과정을 거치는지 잘은 모르겠지만
단순히 생각해 보면
한번 뺀 다음에 다시 & 연산을 하니까
한번 % 연산한것 보다는 아주 조금이라도 느리지 않나요 ?
단순히 속도적인 면 이외에 다른 뭔가는 없는가 ? 해서 여쭤봅니다.
고민이 많아 고민인 애늙은이 입니다.
속도입니다. 뺄셈과 &
속도입니다. 뺄셈과 & 를 감수할만큼 % 가 느립니다. 클럭수 합산을 해보면 아마 맞을 겁니다.
경우에따라 컴파일러가 똑똑하면 이런 최적화를 내부적으로 수행할 수도 있습니다만, 속도문제가 중요한 루프 안에서는 좋지 않은 컴파일러까지 대비해서 속도 위주로 가는 게 일반적이죠...
Orion Project : http://orionids.org
Computer arithmetic 책을
Computer arithmetic 책을 보시면 알겠지만,
*일반적인 구현에서* %는 +,-,& 등 에 비해 수십배 느립니다.
수십 배면 양반이고
수십 배면 양반이고 시스템에 따라 수백 배 느릴 수도 있습니다. 옛날에 회사 다닐 때 속도를 시스템 별로 조사한 적이 있었는데 지금은 다 까먹었지만 -.- 시스템 중에 아예 정수 나눗셈을 하드웨어에서 지원하지 않는 경우도 있더군요. 이런 데서 % 쓰면 우리가 국민학교에서 배우는 나눗셈 알고리듬을 기계어로 짜서 돌린다는 얘기죠.
그런데 이걸 제대로 테스트해 보려면, 원래 코드처럼 % 8 해버리면 웬만한 컴파일러는 다 비트 연산으로 최적화를 해버리니까 임의의 숫자를 받아서 %를 돌려주는 함수를 만들고 다른 데서 불러보면서 테스트해 보시면 됩니다. 차이가 확연할 겁니다.
아.. 그렇군요..
오늘도 하나 배워가네요.
답변달아주신 분들 고맙습니다. ^^
고민이 많아 고민인 애늙은이 입니다.
signed 의 &7 와 %8 은
signed 의 &7 와 %8 은 틀립니다.
마찬가지로 *2 와 <<1 도 틀리고, /2 와 >>1 도 틀립니다.
OTL
2의 승수로의 나누기
2의 승수로의 나누기 관련해서는
A / 2^n ==> A >> n ( 오른쪽으로 n번 shift)
A % 2^n ==> A & (2^n-1), (여기서 2^n-1은 2진수로 1이 n개인 수가 되겠지요~)
로 하는 것이 빠른 듯 합니다~
그런데
여기도 위와 마찬가지로 변수가 아니라 (변수-1) 아닌가요?
댓글 달기