앞서 array의 0번째 item을 sentinel로 사용한 sequential scan이라는 글에서 배열의 0번째 요소에 검색 대상을 미리 저장해둠으로써 sequential scan의 성능을 향상 시키는 방법에 대해서 말씀드렸습니다. 이에 대해 trax님이 100만개를 관리할 때의 효율이 중요할까?라는 글을 남기셔서 한말씀 적고자 합니다.

Douglas E. Comer라는 퍼듀 대학의 교수는 How To Criticize Computer Scientists or Avoiding Ineffective Deprecation And Making Insults More Pointed 라는 글을 통해 다음과 같은 2가지로 컴퓨터 과학자를 분류하였습니다.

Researchers who follow the mathematical paradigm are called theorists, and include anyone working in an area that has the terms “analysis”, “evaluation”, “algorithms”, or “theory” in the title.

Researchers who follow the engineering paradigm are called experimentalists, and include most people working in areas that have the terms “experimental”, “systems”, “compiler”, “network”, or “database” in the title.

이론과 실재는 컴퓨터를 다루는 중요한 두가지 분류 기준인 것은 사실입니다. 하지만 모든 experimentalist가 문제를 동일하게 해결하지는 않음을 말하고 싶습니다. 예를들어 제 웹 사이트의 초기 페이지의 로딩 속도가 느리다고 가정할 때, 서로다른 소프트웨어 엔지니어는 서로 다른 답안을 내놓습니다. 그리고 보통은 자기가 선호하는 기법을 먼저 적용하고자 할 것입니다. 예를들면, “서버를 한 대 더 사서 클러스터로 묶어”, “초기 페이지를 정적 페이지로 바꿔”, “톰캣 던져버리고 아파치로 해”, “루비 던져버리고 C로 짜서 cgi로 돌려” 등등이요. 물론 사실 튜닝이란 튜닝 목표설정, 현재 상태 분석 등의 단계로 이루어짐이 합당하지만 심지어 그 목표가 무엇인가에 대해서도 의견일치를 보기 힘들 수 있습니다. 웹사이트의 첫페이지는 0.5초안에 뜨면 됩니까 아니면 0.2초입니까 아니면 2초입니까? 이런 문제에는 명확한 답을 내리기 힘듭니다.

앞서 소개했던 sequential scan이 중요한 improvement인가 아닌가의 문제도 역시 다양한 관점에서 바라볼 수 있습니다.

분명히 Knuth 는 20%의 성능 향상을 이야기했고 저는 10% 정도의 성능향상을 보았습니다. 물론 Knuth의 실험결과가 정확하지 않을 수 있으며 제 실험 결과 역시 정확하지 않을 수 있습니다. 하지만 20%와 10%의 차이는 무척 커보입니다. 또 -O3 에 의해 10% 정도가 아닌 더 큰 차이가 난다는 것을 보여드렸습니다. 물론 -O3까지 쓸 경우 원치 않는 결과를 볼 수 있으므로 실제로 저는 사용하지 않지만, 극적인 대비를 보이고자 한 목적이었습니다.

물론 이미 더 나은 검색 기법(트리, 해싱 등)을 제가 이미 알고 있기 때문일 수도 있으나 그런 이유로 그다지 대단한 성능 향상은 없다고 결론 내렸습니다. 특히나 for (i = N – 1; i >= 0 && array[i] != TARGET; –i) 정도의 매우 반복적일 것이 뻔한 코드의 튜닝은 컴파일러의 책임으로 넘기고 명료한 코드를 택하고 싶습니다. 물론 매우 작은 효율성에도 중요한 가치를 두는 커널 제작자는 이와같은 튜닝에도 큰 가치를 두며, 그다지 불명료 하지 않다고 생각할 수 있습니다.

요컨데, 관점의 차이겠죠. 이런 서로 다른 관점을 갖게되는 근본적인 차이도 흥미로운 이야기거리이긴 하겠지만, 제 능력은 못미치는 듯. 하지만 저 역시 Knuth 가 보인 개선안은 재미있고 훌륭하다고 생각하는 것은 사실입니다. sequential scan 코드를 수천번은 짰을텐데 한번도 저런 아이디어를 못내봤으니까요.