zero(int*):
mov DWORD PTR [rdi], 0
ret
zero2(int*):
mov DWORD PTR [rdi], 0
ret
2. 이렇게 딱 한 줄 가지고 "뭐가 더 빠른가요?"라고 묻는 건 거의 의미가 없습니다. 요즘 컴파일러는 함수 전체를 통째로 보고 어느 순간에 어느 변수가 필요한지를 다 계산하면서 최적화를 합니다. 그렇게 최적화가 된 함수를 요즘 CPU는 또 명령을 하나씩 수행하는 게 아니라 한번에 100여 개의(!!) 명령을 동시에 들여다보면서 필요한 데이터가 준비가 되는 명령부터 먼저 계산합니다:
> The out-of-order engine can handle 192 uops in flight compared to 168 in Intel microarchitecture code
name Sandy Bridge.
3. 그러니까 "ALU를 사용하면 더 느리다" 이런 개념은 8086 쓰던 90년대 초반에나 통하던 얘기고, 지금은 "그 명령을 수행하는 데 필요한 데이터가 제때 준비되어 있는가"가 훨씬 더 중요한 요소입니다.
4. 각설하고, 무슨 얘기를 하든 실제 프로그램을 돌려서 어디서 시간이 오래 걸리는지 재지 않고 "이러이러하니까 이러할 거야"라고 추측하는 건 별로 의미가 없습니다. 심지어 마이크로벤치마크를 만들어서 돌려 본다고 해도, 캐시가 어떤 식으로 쓰이느냐 등등 수많은 변수가 있기 때문에, 그게 실제 프로그램과 같은 상황이라는 보장이 안됩니다.
?
질문을 좀 더 엄밀히 하면, C 레벨이 아니라 어셈블리 레벨에서 봐야 합니다.
왜냐면 동일한 expression 도 최적화나 기타 옵션에 따라 다르게 컴파일되고
당연히 컴파일러에 따라서도 다르기 때문에 명확한 답이 없습니다.
범용 레지스터를 0으로 만드는 연산은 x86 기준으로만 보면 참 많은 연산이 가능하지만
대표적인 것 두 가지만 보면 아래의 것들입니다.(편의상 eax 에 이미 로드했다고 가정)
mov eax, 0
xor eax, eax
이 둘의 차이에 대해서는 이미 흥미로운 글들이 많으므로 아래 링크들을 참조하시면 됩니다.
http://stackoverflow.com/questions/1135679/does-using-xor-reg-reg-give-advantage-over-mov-reg-0
http://stackoverflow.com/questions/7695309/zero-assignment-versus-xor-is-the-second-really-faster
http://board.flatassembler.net/topic.php?t=4485
http://blogs.candoerz.com/question/134855/which-is-best-way-to-set-a-register-to-zero-in-x86-assembly-xor-mov-or-and.aspx
(가장 밑의 링크만 참조하셔도 무방할 것 같습니다.)
?
왜인지 링크에 줄바꿈이 안되있네요.
http://stackoverflow.com/questions/33666617/which-is-best-way-to-set-a-register-to-zero-in-x86-assembly-xor-mov-or-and
한줄 띄어 주시면 됩니다.
한줄 띄어 주시면 됩니다.
?
감사합니다.
입력할 때는 한줄 띄웠는데 이상하네요.
1. 요즘 컴파일러는 똑똑해서 "a&=0" 정도는
1. 요즘 컴파일러는 똑똑해서 "a&=0" 정도는 결과값이 0이 된다는 것을 알고 최적화를 해줍니다.
http://goo.gl/iC02Dq
입력:
void zero(int *p) { *p = 0; } void zero2(int *p) { *p &= 0; }결과:
zero(int*): mov DWORD PTR [rdi], 0 ret zero2(int*): mov DWORD PTR [rdi], 0 ret2. 이렇게 딱 한 줄 가지고 "뭐가 더 빠른가요?"라고 묻는 건 거의 의미가 없습니다. 요즘 컴파일러는 함수 전체를 통째로 보고 어느 순간에 어느 변수가 필요한지를 다 계산하면서 최적화를 합니다. 그렇게 최적화가 된 함수를 요즘 CPU는 또 명령을 하나씩 수행하는 게 아니라 한번에 100여 개의(!!) 명령을 동시에 들여다보면서 필요한 데이터가 준비가 되는 명령부터 먼저 계산합니다:
http://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-optimization-manual.pdf :
> The out-of-order engine can handle 192 uops in flight compared to 168 in Intel microarchitecture code
name Sandy Bridge.
3. 그러니까 "ALU를 사용하면 더 느리다" 이런 개념은 8086 쓰던 90년대 초반에나 통하던 얘기고, 지금은 "그 명령을 수행하는 데 필요한 데이터가 제때 준비되어 있는가"가 훨씬 더 중요한 요소입니다.
4. 각설하고, 무슨 얘기를 하든 실제 프로그램을 돌려서 어디서 시간이 오래 걸리는지 재지 않고 "이러이러하니까 이러할 거야"라고 추측하는 건 별로 의미가 없습니다. 심지어 마이크로벤치마크를 만들어서 돌려 본다고 해도, 캐시가 어떤 식으로 쓰이느냐 등등 수많은 변수가 있기 때문에, 그게 실제 프로그램과 같은 상황이라는 보장이 안됩니다.
댓글 달기