if (x != 0) ==> if (x)
if (x == 0) ==> if (!x)
if (x != -1) ==> if (~x)
if (x != y) ==> if (x ^ y)
이 정도는 기본으로 알고 적극 활용하자. 저걸 안다면 for문도 이렇게 최적화시킬 수 있다.
for (i = 1; i < 5; ++i)
이 경우처럼 시작 값이 끝 값 이하라는 보장이 있다면 이렇게 바꿀 수 있다.
for (i = 1; i ^ 5; ++i)
왜 후자가 더 빠르냐고? i < 5는 빼기 연산을 수행해서 비교하지만 i ^ 5는 비트 연산인 xor 연산으로 비교하기 때문에 속도가 더 빠르다.
오 팁 ㄳ
잉? for 문 최적화는 룰이 단순하지 않아
저건 최적화 기능 약한 컴파일러에서나 통함
잘려구 누웠다가 모기소리 듣구 깼더 ㅠㅠ
ㄷㄷㄷ 근데 코세 성님 말씀은 컴파일러가 제 이상으로 최적화해주기도 한다는 말씀이신 건가요?
^가뭐임? - DCW
비트연산? - DCW
ㅅㅅㅅ 도 stos 알잖아
rep 도 알고
상수 for 루프는 최적화 디게 잘돼
흐린바다 // 배타적 논리합 (XOR). 비트 연산의 하나인데 a ^ b를 하면 b의 자리 중에 0인 자리는 a가 그대로, 1인 자리는 a가 값이 반전되는 연산임. 성질 중에 a ^ a = 0 이 있으므로 그걸 이용한 것.
함튼 그럼 이거 몰라도되는정보임? 저렇게써버릇해야함? - DCW
!=를 비트연산 ^로 쓰고있는거구나 - DCW
흐린바다 // ㅇㅇ. != 랑 ^ 를 비교하면 ^ 가 더 빨라. != 는 빼기 연산을 수행하거든.
컴파일러가 띨빡하면 xor의 결과를 0이랑 또 cmp 하기도 하고 말이지
코세 // 근데 그 i 값을 루프 내부에서 쓰거나 하면 그렇게 심하세 최적화는 못할 거 같은데요.
잘되는것들 보면 stos movs lods 도 써
ecx 를 이용한 rep 로 말야
그래서 cmp 일지 test 일지에 따라서도 성능이 갈리구
황당한 분기문이 삽입 되는 경우도 많음
for 문은 얌전히 쓰는게 최적화가 젤 잘되는편
if (x ^ y) 같은 건 xor 하고 바로 jnz 오겠죠. xor 명령어 자체가 ZF 건드리니까요.
아 실수. jnz가 아니라 jz.
우리 생각은 그런데 ㅋㅋ 해봐 다 다름
CodeSafer X86 C Compiler하나 빡세게 최적화되는 거 만들어서 팔면 대박날 듯 ㅋㅋ
fabs 부르면 자동으로 MSB만 0 해주고요 ㅋㅋㅋㅋㅋㅋㅋ
요즘 cpu들이 기능블럭별로 병렬화가 되니깐 특정 블럭을 쓰고 있으면 다른 블럭을 이용하도록 최적화됑
그래서 hazard 에서도 통째로 버블인 경우는 많지 않은듯
부동소수점 트릭은 아직 좀 통하는듯
당연하게도 emms 비용이 크니깐
( 수백클럭 폭파됨 )
근데 성님 부동소수점 값끼리 비교할 때도 그럼 *(int*)&a < *(int*)&b 이렇게 하면 성능 향상되겠네요?
부동소수점 구조 보면 재미있는 게 대소 비교 정도는 그냥 부호 있는 정수 데이터처럼 취급해서 비교해도 될거 같더라소요.
응 물론이지 근데 2의 보수법이 아니라 음수끼리면 병신됨
아 맞다. 부동 소수점은 정수 표현으로 치면 '부호와 절대치'에 가까우니 음수끼리면 2의 보수 표현으로 보정히 줄 필요가 있겠네요.
응 msb 끼리 and 한걸로 뒤집어주면 됨
((*(int32_t*)&a & 0x7fffffff) < (*(int32_t*)&b & 0x7fffffff)) ^ ((*(uint32_t *)&a >> 31) & (*(uint32_t *)&b >> 31)) 이렇게 하면 되겠군요.
모바일이라 한참 코드 적고 있는데 이미 선수 치심 잼
더 간단히 될걸~
1/3 을 줄여봐 ㅋㅋ
속도가 빨라지느거엔 신경 안써도 됨. 어차피 프로그램 에서 느려지는 부분은 저런부분이 아님. 나도 초기시절엔 저런 자잘한 속도에 꽤 예민했는데 개뿔 다 쓰잘데기 없는 짓이었음. 그리고 요즘 컴파일러면 다 알아서 최적화 할듯. if 문 저렇게 쓰는것도 가독성 면에서 별로 추천하지 않음