님의 고견에 이견없습니다.
더불어 어줍잖은 지식으로 하드웨어와 컴파일러 그리고, 다른 프로그래머의 상상속에서 그려지는
다양한 알고리즘 들에 관해서.. 그것도 최적화에 관해서 논한다는 것은
스스로가 너무나도 부족하다고 생각이 듭니다. 하지만, 제가 거짓말을 했다는 건 좀... 그렇군요.
^^ 그냥.. 재미삼아 해보았던 잠시 짬을 내서 해봤던 경험들이  그랬었다는 것일뿐
반드시 그렇다는 건 아닙니다. 항상 그렇습니다만, 제가 생각이 틀릴수도 있죠.

어떻게 하는 결과물을 빨리 만들면 된다에서 오랜만에 초심으로 돌아간 잠시였습니다.
좋은 글 잘 읽었습니다.

PS : 개인적으로 속도를 요구하는 모듈, 알고리즘은 상용컴포넌트를 사용합니다. ^^
        하다 못해 조그만 것이라도 제손으로 만들어 보고는 싶지만... 그럴수 없는건
        비싸야 300만원도 않되는 상용컴포넌트에 손이가는 것은 어쩔수 없는 현실이겠지요.

열씸! 님이 쓰신 글 :
: 거짓말 장이가 되시겠군요 ㅋㅋ.
: 전역변수 형태로 static 하게 가서, stack을 확보하는 시간을 줄인다는 취지는
: 분명 잘못된 것이 아니지만,
: 원거리 주소의 변수를 사용하는 것은 근거리 주소의 변수를 사용하는 것에 비해 느립니다.
: 루핑을 심하게 하는 경우라면 지역변수가 더 빠르죠.
: 즉, 큰 덩어리를 수시로 할당해야 하는 경우가 아니라면 전역변수를 남용하는게
: 메모리 사용량을 늘리고, 컴파일 타임(처리할 전역 심볼이 늘어나므로)과 실행시간에 부하를 주게 됩니다.
: 물론 함수 단위의 모듈성도 떨어지게 되죠.
: (이말을 스택의 주소가 스태틱영역의 주소보다 코드부에 더 가깝다는 말로 곡해하시면 곤란합니다.
: 적어도 스택 포인터 레지스터(SP) 메카니즘은 항상 스택에 생성된 녀석들과 가까운 위치에 있단겁니다)
:
: 반복문의 확장은, 많은 개발자들에게 상당히 유효한 최적화 방법으로 알려져 있습니다.
: 그러나, 이 경우에도 반복문을 무조건 확장하는게 아니라, 매 회 확장시 마다 점프 처리가 필요한 경우라면
: 코드 량만 늘어나고, 참조해야 할 주소폭이 확장되어 바이너리만 커지는 경우가 발생할 수도 있지요.
: 또한 컴파일러의 최적화 루틴을 타지 못하게 될 수도 있습니다.
:
: (정수형)곱셈 나눗셈도, 펜티엄 이상에선 대체적으로 1사이클에 수행됩니다.
: 즉, 예전 도스시절처럼 x * 640 을 절약하기 위해 (x << 9) + (x << 7) 을 사용하는 (512x + 128x = 640x죠)
: 식의 최적화 역시 해가 됩니다.
: 물론, 특정 모바일 프로세서등에선 아직 효과가 있고, CPU내부의 부하를 줄임으로 열 발생이나
: 배터리 소모를 최적화 한다는 취지라면 것도 나쁘지 않습니다.
: 실수형 최적화를 위해 정수형으로 바꾸고 부동소수점 트릭을 사용한다. 식의 최적화면 Good 이긴합니다.
: 것도 부호연산이나 지수부와 가수부 데이타를 뜯어내는 정도에 한정되지만요.
:
: 어줍잖게 어셈블리를 남용한다. 이것도 문제가 됩니다.
: 즉, memcpy와 같은 반복 루틴을 최적화 해 보겠다고
: asm{
: mov edi, tgt     // 혹은 lds
: mov esi, src   // 마찬가지
: mov ecx, count
: rep stosb // 혹은 stosw, stosd...
: }
: 한 것이, for문 한줄을 사용해 최적화 컴파일한 결과보다 느릴 수 있습니다.
:   
: 최적화를 논하기 위해선 공부를 많이 하셔야할 듯 합니다.
: 아는 지식이 실제 근거 있는 지식이라 하더라도, 적용되는 경우가 아닌 때엔 독이 될 수 있지요.
:
: 다소 문제제기만 한 것 같군요.
: 요약하자면 이렇습니다.
: 1. 모르면 컴파일러를 믿으세요.
: 2. 단순 공식같은 최적화 Paradigm은 적용되지 않는 최적화가 많습니다. 최적화가 필요하다면,
:    Debug 타임, Release 타임을 구분해 테스트 하며 반드시 RDTSC 명령으로 실제 수행 클럭을
:    세어보시기 바랍니다.
: 3. 더 큰것 부터 최적화 하세요.