Lyn님이 재미있는 글을 올리셨는데요. 3가지 문제점을 지적하고자 합니다.

첫째. 시간 체크하는 부분 안에 IO 관련 함수가 있다.

IO 관련 함수(printf)를 쓰면 Context Switching이 일어나며, 제어권이 커널로 넘어가면 언제 다시 넘어올지는 하느님도 모릅니다. 사실 제어권을 넘겨주는 커널도 잘 모릅니다 -_-;;;;
재수 좋으면 바로 넘어오지만, 재수 없으면 수백ms 이후에 넘어오기도 합니다.
절대 쓰면 안 되죠. 제대로 속도 측정이 되질 않습니다.

둘째. 시간 체크를 한 타이머의 해상도를 믿을 수 없다.

사용된 timer는 안 써봤고 어떻게 작동되는지도 모릅니다. STL이니 소스를 보면 어떻게 동작하는지야 알겠지만, boost도 없고 귀찮아서 -_-;;;
하지만 윈도우 계열에서 제대로된 타이머는 timeGetTime()이 거의 유일합니다. 이것도 24시간 이상 돌리면 1-2초씩 오차가 생기긴 하지만 -_-;;;
퍼포먼스 카운터 등이 있긴 하지만, 이것도 CPU 클럭을 지멋대로 변화시키는 전원절약기술이나 멀티 코어 CPU의 한계 때문에 속도만 무진장 느리고 엉뚱한 값이 나올 때도 많죠.
타이머 문제는 게임 프로그래머들의 영원한 숙제입니다. 컴퓨터엔 정확한 타이머가 없어요 -_-;;;

셋째. 일반적이지 않은 것으로 일반화를 시켰다.

boost STL 하나의 결과만 가지고 속도를 논한다는거 자체가 문제가 있습니다.
그 STL이 VC++에 최적화 되어 있을지도 모르고, BCB와 충돌하는 무언가 다른 문제점이 있을지도 모르죠.

기본적인 함수 호출 능력, 루프 최적화 능력, 메모리 할당 능력 같은 프로그래밍의 기본적 요소들이 BCB가 더 빠른데 boost가 더 느린 이유가 무엇일까요?

제가 2002년에 테스트를 해보고 그 동안 안 본 사이에 VC++이 비약적인 발전을 한 것일까요?????

특히 atoi 부분의 속도가 더 느리다니 뭔가 잘못된 느낌이 들더군요. 위에 2가지 문제점이 있긴 하지만, 노파심과 궁금함에 일 농땡이 치고 테스트를 한번 해봤습니다. 사장님이 이거 알면 혼나겠네요 ㅋㅋ

"테스트 사양"

CPU: AMD 페넘 9500
RAM: 4기가
O.S: 윈도우 엑스피
빌더: Turbo C++ Explorer (=BDS 2006 버젼)
삐졀씨: Visual C++ 2008 ServicePack1 (현재 최신 버젼)

코드

#include 
#include 
#include 
#include 

const char *number = "1024768";

int StrToIntAtoi()
{
    int num;
    for( int i=0 ; i<100000000 ; i++ )
    {
      num = atoi(number);
    }
    return num;
}
int main()
{
  int ret;
  DWORD startTime, endTime, interval;

    timeBeginPeriod(1);
    startTime = timeGetTime();
    ret = StrToIntAtoi();
    endTime = timeGetTime();
    timeEndPeriod(1);

    interval = endTime - startTime;

    printf( "atoi ret: %d, interval: %u ms ", ret, interval );

    system("pause");
    return 0;
}

두 컴파일러 모두 New Project 이후 exe 실행을 위하여 static link 옵션을 제외한 옵션은 기본값 그대로 사용하였으며 Release 모드로 컴파일 하였습니다.

결과는... 빌더의 압승입니다.
2배 정도 빠르고요.
이 소스 코드만 놓고 보면, 별거 없죠. 루프의 최적화 능력, atoi 함수 호출하면서 스택 생성과 백업 능력 등이 빌더가 월등하다는 사실을 알 수 있죠.
메모리 할당 능력은 제가 2002년에 테스트한 자료가 팁게시판에 올려져 있습니다. 결과만 말씀드리면 VC++이 4배 가량 느렸지요.

컴파일된 실행 파일과 소스 파일을 제 ftp에 등록해 놓았으니, 한번씩 실행해보시고요.
혹시 제 AMD 페넘CPU가 BCB에 최적화된 CPU라서 속도가 잘 나왔을지도 모르니까요 ㅡㅡ+

ftp://azena.info/attachment/vc_bc_speed/

반드시 CMD 또는 COMMAND.COM 실행 후에 CPU가 0%일 때 테스트 하시기 바랍니다. 그래야 정확한 테스트가 되고요. 원래는 10번 정도 해서 평균값을 내야 하는데, 해보시면 아시겠지만, 스코어가 2배 차이가 나므로 대충 보셔도 빠르다는 것을 느낄 수 있습니다.

제 페넘CPU에서는 bct가 6초대, vct가 13초대로 나왔으니까요.
그래서 제가 내린 결론은 Lyn님의 테스트가 잘못 되었다 입니다.

마지막으로 푸념 좀 하자면,

저도 2000년 초에는 Lyn님처럼 이런저런 재미있는 테스트 많이 하고 그랬는데요.
나이가 쳐먹으니까 먹고 살기 바빠서 이것저것은 커녕 일하기도 바빠서 미치겠더군요 ㅎㅎ

결혼할 나이가 되니 연애도 해야겠고, 직함이 높아지니 일은 더 많아지고...
여기저기서 돈 들어갈 곳은 더 많이 생기고 그래서, 안타깝네요. 머리도 노쇠해져서 건망증도 생기고 그랬습니다. ㅎㅎㅎ
삽질도 하고 이런저런 테스트 하고 하는 것이 실력 향상에 지름길이라고 봅니다.
하지만 일부의 결과를 너무 일반화해서 폄하하는 것은 잘못된 것이라고 생각하니까요.
다음부터는 조금 더 여러가지 테스트를 해주시기 바래요.
제 테스트가 잘못된 것일수도 있으니 지적도 바랍니다.

그럼. 이만 퇴근해야겠군요.... ㅡㅡ+



Lyn 님이 쓰신 글 :
: 델파이 코드랑 합쳐지면서 느리고 자체의 최적화된 코드 제네레이션 능력이 VC++ 보다 빠르다구요?
: 순수 C 로 된 라이브러리 써보시면 과연 그런 말이 나오실까 싶습니다만..
:
: 얼마전에 직접 테스트 했던겁니다 라이브러리는 zlib 순수 c 라이브러리죠. 델파이 코드는 그림자도 없습니다.
: 각각 테스트 했던 컴파일러는 IC++ 11.1, BC++ 2007, VC++2008 입니다.
:
: Random 으로 생성한 데이터를 1M 씩 50번 반복해서 테스트 하엿습니다
: 물론 랜덤 seed 는 항상 같은 값이었구요. 모든 최적화 옵션은 프로젝트 생성 디폴트이며, 릴리즈 모드로 빌드하엿습니다.
:
: BC++2007의 소모시간을 100이라고 봤을때
: IC++ 11.1의 소모시간은 47.5
: VC++의 소모시간은 49.7
:
: 2배 이상의 퍼포먼스 차이를 보여줍니다. 특별한 경우일까봐 결과 하나 더 공개하겠습니다.
: http://cbuilder.borlandforum.com/impboard/impboard.dll?action=read&db=bcb_tutorial&no=196
: 윗글은 제가한 boost 라이브러리의 lexical_cast 의 속도 테스트 결과가 스크린샷으로 첨부 되어 있습니다.
:
: 각각
: 0.048
: 0.224
: 2.329 초가 걸렷는데요 이거 빌더에서 측정한겁니다.
:
: VC++에서 했을때 결과는 올리지는 않았지만 저는 테스트 결과를 가지고있습니다
: 각각
: 0.000 -- 측정불가. 아무래도 루프횟수가 너무 적엇던듯
: 0.076
: 0.997 초가 걸렷습니다.
:
: 이건... 속도가 중요한곳에 간다면 용납이 안되는 수준입니다.
: 단순히 컴파일러 바꾼 것 만으로도 성능향상이 엄청납니다.
:
: 그리고 빌드시간... 하드디스크 속도에 거의 영향받지 않습니다. SSD 붙여도 속도 차이 안납니다.
: 또하나 BC++은 아직 병렬컴파일 지원하지 않습니다. 싱글코어든 쿼드코어든 1024 코어든 속도 똑같습니다.
:
: 그리고 8G CPU라.. CPU는 발열과 효율문제로 4G 이상 CPU는 CPU 재질이 바뀌지 않으면 더이상의 클럭 업은 어렵다고 하는 상황입니다. 몇년안에 8코어가 나온다고 생각하는건 무리라고 생각되네요. 5년전이나 지금이나 최고 클럭은 3G 에서 왔다갔다 하죠
:
: 물론 어플리케이션 특성에 따라 CPU의 속도가 중요하지 않을 수도 있습니다만 모든 어플리케이션이 그런 것은 아니죠 ㅡ.ㅡ  성능 좋은 컴파일러는 어떤경우던 나쁠 이유가 없습니다.
:
: 아제나 님이 쓰신 글 :
: : 볼랜드가 델파이를 처음부터 C++ 플랫폼으로 잡았다면 지금처럼 뒷방 황후로 전락하진 않았을 겁니다.
: : 얼마전에 자게에서도 논의가 되었던 내용이고요.
: : C++컴파일러 특성상 컴파일 속도는 지랄 맞게 느리고요. 어쩔 수 없습니다. ㅎㅎㅎㅎ
: :
: : 컴파일 속도야 시대가 좋아진 만큼 하드웨어를 좋은거 쓰면 해결됩니다 SSD 4개 정도를 레이드로 장착하고
: : 쿼드 코아 시퓨에 돌리면 천만 라인도 순식간에 컴파일되니까요.
: :
: : 문제는 C++빌더가 델파이의 태생적 한계를 가지고 있다는 점이 몇가지 있어서 안타깝지요.
: : __fastcall 이라던가.. 지금 딱히 생각은 안 나지만 여러가지가 있습니다.
: :
: : 컴파일된 바이너리의 속도 차이는 그리 크지 않습니다. 대부분 델파이 코드를 오브젝트 과정에서
: : 합치면서 뭔가 맛이 가서 느려지는 것일 뿐이죠 ㅡㅡ;
: : C++빌더에 탑재된 C++컴파일러 자체의 최적화된 코드 제네레이션 능력은 VC++보다도 빠른 편입니다.
: :
: : 그리고 지금은 제가 처음 프로그래밍 하던 시절에서 20여년 가까이 흘렀기 때문에 ㅡㅡ;
: : 당시에 8Mhz CPU 가지고 연산자의 CPU 클럭수 계산하면서 최적화 하던 삽질의 시대는 끝났지요.
: : 몇 년 안에 8Ghz CPU가 나올텐데요.
: :
: : 이런 상황에선 CPU 속도는 완전 무시해도 되고, 대부분의 바틀렉은 IO에서 걸리게 됩니다.
: : 얼마나 IO 처리를 스무스하게 하느냐가 고급 프로그래머와 저급 프로그래머를 결정 짓는 요소가 되겠습니다.
: : 그것보다도 더 중요한 것은 얼마나 exception 처리를 잘 하느냐 하는 것이죠.
: : 심심하면 뻑나는 프로그램이 어찌 프로그램이라 할 수 있겠습니까 ㅎㅎㅎ
: :
: :
: : 한울 님이 쓰신 글 :
: : : C++B으로 작성하는 것보다는 델파이로 작성하는 것이 빠를텐데..
: : :
: : : C++B를 사용하는 이유는 무엇인가요? 즉, 왜 C++B가 나오게 된 것인가요?