도저히 이해할 수 없는 Visual C++ 6.0의 성능

디카 메모리가 부족하다고 풍경을 마음에 담을 순 없다! (업그레이드)에 올린 프로그램을 만들면서 느낀 병맛스러움.

어느 필터나 그러하듯이 필터의 생명은 정확함과 더불어 성능이다.
포토샵의 필터가 좋긴 한데, 리샘플링 하나에 이틀 반이 걸리면 누가 쓰겠는가.

리샘플링이 아무리 기본적인 기능이라도 막상 실제로 쓰려면 최적화해야 되는 구석이 한둘이 아니다.

예컨데, R-G-B-R-G-B... 순으로 저장된 데이터를 R 따로, G 따로, B 따로 뽑아서 리샘플링 한 뒤 합칠 것인가 아니면 원본 데이터를 놓고 이리저리 뛰어다니며 리샘플링 할 것인가 하는 문제들.
(전자의 경우 코드가 명확해지긴 하지만 불필요한 memcpy가 세상을 지배한다)

또, 루프를 도는 과정에서 포인터를 계속 이동시켜야 하는데, 이동시킬 때 포인터는 더하기만으로 이동할 것인가 아니면 곱하기를 가미할 것인가하는 문제도 있다.
(보통 전자와 같이 하면 가독성이 떨어지지만, 후자와 같이 하면 가독성은 높으나 성능은 떨어짐,
아무리 CPU가 좋아져도 곱하기보다 더하기가 빠른 건 컴퓨터나 인간이나 마찬가지임)

어쨌든 (진리는 아닐지라도) 거의 불문율처럼 인정받은 사실은, 성능이 올라가려면 코드의 가독성을 포기해줘야 된다는 거.
따라서 처음엔 읽을만한 코드를 쓰고 나중엔 읽기 어렵더라도 곱하기와 같은 나쁜 연산을 최대한 배제하는 것이 정석.

아래와 같은 순서로 진행했다.

1. old: R-G-B... 순서의 이미지를 R, G, B 따로 추출 후 resampling한 뒤 다시 하나로 합침
2. new: R-G-B... 메모리 내에서 요리조리 왔다갔다하며 값을 읽어 resampling
3. new(opt): 2번과 같으나 루프 내에 있는 곱하기를 몽땅 더하기로 대치

어디 태클 걸만한 구석도 없는 걍 일반론이다.
그런데, 결과가 디게 웃긴다. Visual Studio .Net 2003은 당연히 1>>2>3 의 속도로 시간이 소요된다.
그런데, Visual C++ 6.0은 1>>3>2의 순서. 이건 컴파일러 만드는 놈이 미치지 않고서야 달성하기 힘든 경지다.
어떻게 더하기가 곱하기보다 느리냐! (아니, 곱하기가 더하기보다 빠르다고 행복해해야되는 거냐?)

게다가 VS2003에서 가장 느린 알고리즘으로 돌려도 VS6의 최고기록과 유사한 성적이 나온다.
이거 뭐 나랑 우사인 볼트 달리기도 아니고... (볼트 씨 미안)

문제는 libjpeg을 VS2003에서 컴파일하는 방법을 못 찾았다는 거...
방법만 찾으면 VS6은 버릴란다. 이거 뭐 ㅂㅅ도 아니고, 이게 이 정도의 병맛 컴파일러였나?