프로그래머의 강박증

음, 10%는 맞고 90%는 틀린 것 같습니다.

for(int i = 0; i != 100; ++i)
...

만약 이 루프 안에서 i가 99 -> 101로 설정되었다면 i < 100으로 비교했을 때에는 정상적으로 루프가 종료되는데, i != 100으로 비교하면 루프를 탈출하기 어려워지죠. 그리고 요새의 컴파일러와 CPU를 너무 얕잡아볼 필요도 없습니다.

아, C++에서 iterator를 쓴다면 이야기가 조금 달라지긴 하지만, C++11의 foreach를 쓴다면 iterator를 굳이 for()에다가 끼워넣을 필요도 없습니다. 할렐루야!

for 루프 인덱스가 많은 경우에 배열 인덱스로도 사용되기 때문에 배열이 0부터 시작하는 C 언어에서는 for (i=0;...) 이 사용되는 경우가 많겠죠.

1. 컴공 학부생의 수준 낮은 생각임을 미리 밝힙니다.
제 생각이 옳다고 주장하려는 것보다, 제가 아직 많이 모른다는 점을 느끼고 싶어서 덧글 남겨봅니다.

!=로 비교 연산을 하는 것은, less than 연산보다 훨씬 빠릅니다. CPU가 Pipelined Architecture라면요.

아주 기본적인 CPU에서는 branch 연산은 EX stage에서 ALU가 계산한 후, MEM 단계에서 PC를 업데이트합니다.
하지만 Pipelined CPU Architecture에서 branch 연산은, ID 단계에 비교 모듈(xor)을 넣는 것으로 ID 단계에서 바로 branch가 일어나도록 할 수 있습니다.
하지만 less than 연산은 반드시 ALU가 계산하여 결과를 내놓아야 하기 때문에, ID 단계에서 branch를 할 수 있는 데에 비해 2개의 stall이 생기는 것과 같죠.

컴파일러가 똑똑해서 루프 내에서 i에 대해 less than 연산을 not equal로 바꾼다면 latency는 같아집니다.

덧. x86과 같은 CPU는 옛날에는 CISC 계열의 CPU였지만, 요새는 Instruction만 CISC고 실제 구현은 RISC로 바뀌었다고 알고 있습니다.
(수업 시간에 교수님한테 그렇게 들었던 기억이 나는데, 근거를 찾아오라시면 시간이 걸릴 것 같습니다. 잘못 들었을 수도 있구요.)

Pipelined CPU의 사진 첨부합니다. 빨간색 줄은 equal로 연산했을 때, 주황색은 ALU가 연산하고 MEM에서 PC로 넘길 때를 표현해보았습니다.

내공이 부족합니다. 많은 가르침 부탁합니다.

출처: 학교 수업 with "Computer Organization and Design - the Hardware/Software Interface 5th"

이거는 속도가 어떨까요?

for(;;)
{
if(i++ == 100)
break;
}

제가 생각할때는 좋은 프로그램 = 제대로 동작하면서, 가장 유지보수하기 좋은(읽기 좋은) 프로그램이라는 측면에서

전자는 의미가 불충분한 코드고 후자는 의미가 완벽한 코드가 되겠죠.

물론 리얼타임 OS 라던지, 퍼포먼스가 안정성보다 훨씬 중요한 SW에서는 비트연산이라던지 가능한 최적화를 해주는게 좋을테지만...

그럼 어셈블리를 사용하는게 더 좋지 않을까요? 그렇게 퍼포먼스 디펜던트하다면...