옛날 옛적 C 포인터를 처음배울 때, 배열과 포인터의 유사성에 대해서 배웠다. 그리고 배열로 표현된 코드도 결국 다 포인터로 바뀐다는 것으로 배웠다. 맞다. 2차원 배열을 쓰더라도 실제 생성된 x86 코드를 보면 i*width+j와 같이 인덱스를 계산해서 포인터 연산으로 바뀐다. 그런데 여기서 이상한 믿음이 생겨나기 시작한다. 바로 포인터로 코딩하는 것이 배열보다 더 낫다라는 잘못된 믿음이다.

과거 (20년 전 쯤) 컴파일러가 그렇게 뛰어나지 못했을 때는 이런 배열보다 포인터를 더 선호하는 코딩 습관이 좋았을지는 모른다. 그러나 이제는 전혀 그렇지 않다.

특히 DSP를 타겟으로 하는 임베디드 시스템에서는 이런 코딩 습관이 더 심했다고 한다. 그래서 루프안에서 배열을 그대로 쓰기보다는 포인터로 풀어헤쳐서 짜여진 코드가 많다고 한다.

그러나, 이러한 코딩 습관으로 만들어진 코드들은 최신 컴파일러가 컴파일하기 매우 힘들다. 포인터를 많이 쓰면 쓸 수록 C/C++ 컴파일러는 최적화하기 더욱 힘들어진다.

어설픈 최적화는 안 하는 것보다 더 못하다. 괜히 코드를 더 복잡하게 만들어 유지 보수에도 어려울 뿐만 아니라 컴파일러 입장에서도 명확하게 그 의도를 파악하지 못해 최적화 기회를 많이 놓칠 수 있다.

이쯤에서 Knuth 선생님의 말씀 하나를 인용한다.

We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil." (Knuth, Donald. Structured Programming with go to Statements, ACM Journal Computing Surveys, Vol 6, No. 4, Dec. 1974. p.268.)

우리는 조그마한 효율성에 대해 고민할 필요가 없다. 대략 97%의 경우, 어설픈 최적화는 모든 악의 근원이라 말하고 싶다.

30년 전에 하신 이 말씀은 여전히 유효하다.

그래서 어떤 이들은 포인로 짜여진 코드를 배열형태로 다시 복원을 하여 고차원의 최적화를 시도하기도 한다. 또, 많은 사람들이 /4 대신에 >>2와 같은 코딩을 많이 한다. 당연히 정수 나눗셈보다 (경우에따라 수십사이클이 걸림) 비트 연산 (대부분의 경우 한 사이클)이 훨씬 빠르다. 그러나 걱정할 필요가 없다. 컴파일러가 이 정도는 알아서 최적화를 다 해준다. 루프 안에 반복적으로 계산이 되지만 그 값이 바뀌지 않는, loop invariants도 다 알아서 밖으로 빼준다.

쉬운 문제는 아니다. 이 말을 오해해서도 안된다. 하고 싶은 말은 정확하지 않은 최적화에 대한 소문만 듣고 하지 말라는 것이다. 언제나 의심이 되면 직접 컴파일러가 만들어주는 어셈블리를 보면서 확인을 해야할 것이다. 여기서 다시 한번 프로그래머는 쪼잔해질 필요가 있다는 나의 주장을 재차 역설한다.