파스칼이 C언어보다 성능이 좋다는분이 있어서요.....

저 프로그램이 BMT문제라면 님은 떨어집니다. 세상을 너무 아름답게 보시는 듯하군요.

상사가 아니라면 무시하면 그만입니다. 그런거 설득할려고 해봐야, 저같은 사람만 만날 뿐입니다.

테스트

아래의 결과는 델파이7 의 트라이얼 버전을 받아 IDE 에서 컴파일 한것을 콘솔에서 테스트 한 결과 입니다.

(델파이 컴파일러가 어떤 것인지 몰라서. dcc32.exe 가 없더군요, 제가 못찾은건지 아님 다른 이름으로 되어 있는지 몰라도)

D:\download\test>p

Time : 611

Sum : 1647668640

D:\download\test>p

Time : 601

Sum : 1647668640

D:\download\test>p

Time : 601

Sum : 1647668640

D:\download\test>p

Time : 601

Sum : 1647668640

다음은 VC++ 6 의 컴파일러를 가지고 컴파일 했습니다.

D:\download\test>cl /GX /O2 c.cpp

Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 12.00.8804 for 80x86

Copyright (C) Microsoft Corp 1984-1998. All rights reserved.

c.cpp

Microsoft (R) Incremental Linker Version 6.00.8447

Copyright (C) Microsoft Corp 1992-1998. All rights reserved.

/out:c.exe

c.obj

D:\download\test>c

time 721 , 1647668640

D:\download\test>c

time 711 , 1647668640

D:\download\test>c

time 711 , 1647668640

D:\download\test>c

time 721 , 1647668640

헌주님의 결과와 같이 C++ 쪽이 느리더군요...

저의 개인적인 입장은 어짜피 코드 간단한것이니 성능은 비슷하다는 것인데 오히려 차이가 이렇게 난다는것이 놀랍더군요...

그래서 VC++7.1 로 컴파일러를 바꾸어 봤습니다.

그러나 약간의 속도 차이는 있었지만 별로 효과는 보지 못했습니다.

심지어는 /G7 (펜티엄 4 최적화 옵션) 옵션으로 해봤지만 640 ~ 650 까지는 성능을 내봤으나 그래도 델파이에는 미치치 못했습니다.

그래서 C++이 느리구나 라고 생각을 할무렵 혹시나 해서 bcc5.5 (borland free compiler) 으로 실행을 해보았습니다.

D:\download\test>bcc32 -O2 c.cpp

Borland C++ 5.5.1 for Win32 Copyright (c) 1993, 2000 Borland

c.cpp:

Warning W8004 c.cpp 8: 'i' is assigned a value that is never used in function ma

in()

Turbo Incremental Link 5.00 Copyright (c) 1997, 2000 Borland

D:\download\test>c

time 611 , 1647668640

D:\download\test>c

time 601 , 1647668640

D:\download\test>c

time 601 , 1647668640

D:\download\test>c

time 611 , 1647668640

아 근데 델파이와 비슷한 결과를 보여주었습니다.

그래서 이번엔 반대로 왜 볼랜드 C++ 컴파일러와 MS C++ 컴파일러가 틀릴까 생각을 하던중 혹시나 해서

MS VC 6.0 컴파일러 쪽에 O2(속도 최적화) 옵션이 아닌 O1(크기 최적화) 를 사용 해보았습니다.

D:\download\test>cl /GX /O1 c.cpp

Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 12.00.8804 for 80x86

Copyright (C) Microsoft Corp 1984-1998. All rights reserved.

c.cpp

Microsoft (R) Incremental Linker Version 6.00.8447

Copyright (C) Microsoft Corp 1992-1998. All rights reserved.

/out:c.exe

c.obj

D:\download\test>c

time 611 , 1647668640

D:\download\test>c

time 601 , 1647668640

D:\download\test>c

time 601 , 1647668640

D:\download\test>c

time 601 , 1647668640

그러니 이제야 델파이와 bcc32 5.5 같은 결과를 내었습니다.

개인적으로 생각하기엔 아마 작은 코드이다 보니 속도로 최적화보다는 크기로 최적화를해 코드의 적중률을 높여서 그런게 아닌가 생각이 듭니다.

델파이는 이작업을 자동으로 해줄 뿐이고 C++은 옵션을 조정 했다는 거 차이입니다.

결론

저렇게 작은 코드로 그리고 하나의 테스트로 컴파일러 혹은 언어의 성능을 측정 하는것은 무리라고 봅니다.

오히려 차이가 나는 것이 이상하겠지요...

델파이도 훌륭한 컴파일러이고 C++ 못지 않는 성능을 낸다는것은 의심할 필요가 없다고 봅니다.

다만 C++쪽이 파스칼 보다는 상대적으로 로우레벨의 접근이 용이하기 때문에 최적화가 유리할수 있다고 생각을 하면 될것 같습니다.

어떠한 언어도 위의 코드를 Win32 네이티브 최적화 코드로 생성해 놓은 것이 있다면 거의다 비슷할 거라고 생각이 듭니다.

느낌점

이 내용을 가지고 많이 논쟁이 있는데 우선 남을 비방해 가면서 까지 할 논쟁은 아니라고 봅니다.

오히려 상대의 말을 존중하고 객관적인 자료로 서로 설득하는것이 맞는것 같습니다.

저도 이 BMT을 하면서 배운것이 많았습니다.

특히 그냥 Release모드로 해놓으면 모든것이 다 잘되는 것이라 생각을 무심결에 한것 같습니다.

많은 그루들의 책을 보아도 최적화에 대해서는 함부로 하지 말라는 말을 합니다.

많은 테스트와 프로파일의 결과를 가지고 적용해야한다는 것을 몸으로 배우는 기회 인것 같습니다.

--

cdecl

쩝.. 주말에 할 일도 많은데

답답해서 자료 좀 만들어봤습니다.

거의 1시간 넘게 걸렸네요.

델파이 시험판 다운 받아서 테스트 프로그램 만들어서 VC 디버거에서 잡아서 디스어셈블을 했습니다.

아무튼.. 관련 자료는 모두 첨부 했으니 의심가는 분은 정확성을 검토해보십시오.

-------------- 파스칼 프로그램 및 컴파일 결과 ---------------------

미드미 님이 올려주신 소스입니다.

program StrTest;

{$APPTYPE CONSOLE}

uses SysUtils, Windows;

var

start: Cardinal;

i, j, sum: Integer;

begin

MessageBox(0, 'Test Begin !!', 'Test', 0); // VC 디버거에서 잡기 위해 삽입한 코드

Start := GetTickCount();

Start := GetTickCount();

//00408295 call 00404A64

//0040829A mov esi,eax

for j := 1 to 100 do

//0040829C mov edx,64h

begin

Sum := 0;

//004082A1 xor ebx,ebx

for i := 1 to 5000000 do

//004082A3 mov eax,1

begin

Inc(Sum,i);

//004082A8 add ebx,eax

//004082AA inc eax

end;

//004082AB cmp eax,4C4B41h

//004082B0 jne 004082A8

end;

//004082B2 dec edx

//004082B3 jne 004082A1

Writeln('Time : ' + IntToStr(GetTickCount() - Start));

//004082B5 call 00404A64

//004082BA sub eax,esi

Writeln('Sum : ' + IntToStr(Sum));

end.

-------------- 씨 프로그램 및 컴파일 결과 ----------------------

cl /O1 test.c /Fa /o test_c.exe

#define WIN32_LEAN_AND_MEAN

#include <windows.h>

#include <stdio.h>

int main()

{

DWORD startTime, i, j;

DWORD sum = 0;

char tmpStr[100];

startTime = GetTickCount();

/*

mov esi, DWORD PTR __imp__GetTickCount@0

push edi

call esi

push 100 ; 00000064H

mov ebx, eax

pop ecx

*/

for (j = 0; j<100; j++)

{

sum = 0;

for(i = 1; i<=5000000; i++)

/*

$L20083:

xor eax, eax

xor edi, edi

inc eax

*/

{

sum += i;

}

/*

$L20086:

add edi, eax

inc eax

cmp eax, 5000000 ; 004c4b40H

jbe SHORT $L20086

*/

}

/*

dec ecx

jne SHORT $L20083

*/

itoa(GetTickCount() - startTime, tmpStr, 10);

/*

push 10 ; 0000000aH

lea eax, DWORD PTR _tmpStr$[ebp]

push eax

call esi

sub eax, ebx

push eax

call _itoa

*/

printf("Time : %s", tmpStr);

printf("Sum : %d\n", sum);

return 0;

}

------------------- 어셈블리 소스 비교 ------------------

파스칼 씨

외부 루프 시작

xor ebx,ebx xor eax, eax

mov eax,1 xor edi, edi

inc eax

내부 루프 시작

add ebx,eax add edi, eax

inc eax inc eax

cmp eax,4C4B41h cmp eax, 5000000

내부 루프 끝

jne 004082A8 jbe SHORT $L20086

dec edx dec ecx

jne 004082A1 jne SHORT $L20083

외부 루프 끝

보시다 시피 거의 차이가 없습니다.

내부 루프는 동일하고

외부 루프는 조금 다른데 클럭 수를 비교해봐야 알겠지만 별 차이 없을 겁니다.

(차이 나봐야 inc 100개 실행되는 클럭수 차이 -_-)

-------------------------- 결론 -----------------------------

벤치마크 테스트도 참 어려운 일입니다.

정수 500만개 더하기, 알파벳 500만번 덧붙이기 같은 무식한 프로그램으로는 제대로 된 벤치마크가 안나오죠.

잘하는 짓은 아니지만... 어쨋든 저는 최소한 기술적 깊이나 난이도 면에서는 델파이를 무시해도 된다고 봅니다.

델파이 거의 처음 써봤는데 프로젝트 옵션 화면이 마치 VB의 화면을 보는 것 같아 질겁했습니다.

으..

괜히 쓸데 없는 로우레벨 퍼포먼스 같은 걸로 말도 안되는 광고 하지 마시고

각자 자기 장점을 살리는 게 좋다고 봅니다.

끝으로 VC 없는 분들을 위해 VC 옵션 화면 보여드립니다.

C/C++ COMPILER OPTIONS

-OPTIMIZATION-

/O1 minimize space /Op[-] improve floating-pt consistency

/O2 maximize speed /Os favor code space

/Oa assume no aliasing /Ot favor code speed

/Ob<n> inline expansion (default n=0) /Ow assume cross-function aliasing

/Od disable optimizations (default) /Ox maximum opts. (/Ogityb2 /Gs)

/Og enable global optimization /Oy[-] enable frame pointer omission

/Oi enable intrinsic functions

-CODE GENERATION-

/G3 optimize for 80386 /Gh enable _penter function call

/G4 optimize for 80486 /GH enable _pexit function call

/G5 optimize for Pentium /GR[-] enable C++ RTTI

/G6 optimize for PPro, P-II, P-III /GX[-] enable C++ EH (same as /EHsc)

/G7 optimize for Pentium 4 or Athlon /EHs enable C++ EH (no SEH exceptions)

/GB optimize for blended model (default) /EHa enable C++ EH (w/ SEH exceptions)

/Gd __cdecl calling convention /EHc extern "C" defaults to nothrow

/Gr __fastcall calling convention /GT generate fiber-safe TLS accesses

/Gz __stdcall calling convention /Gm[-] enable minimal rebuild

/GA optimize for Windows Application /GL[-] enable link-time code generation

/Gf enable string pooling /QIfdiv[-] enable Pentium FDIV fix

/GF enable read-only string pooling /QI0f[-] enable Pentium 0x0f fix

/Gy separate functions for linker /QIfist[-] use FIST instead of ftol()

/GZ Enable stack checks (/RTCs) /RTC1 Enable fast checks (/RTCsu)

/Ge force stack checking for all funcs /RTCc Convert to smaller type checks

/Gs[num] control stack checking calls /RTCs Stack Frame runtime checking

/GS enable security checks /RTCu Uninitialized local usage checks

/clr[:noAssembly] compile for the common language runtime

noAssembly - do not produce an assembly

/arch:<SSE|SSE2> minimum CPU architecture requirements, one of:

SSE - enable use of instructions available with SSE enabled CPUs

SSE2 - enable use of instructions available with SSE2 enabled CPUs

-OUTPUT FILES-

/Fa[file] name assembly listing file /Fo<file> name object file

/FA[sc] configure assembly listing /Fp<file> name precompiled header file

/Fd[file] name .PDB file /Fr[file] name source browser file

/Fe<file> name executable file /FR[file] name extended .SBR file

/Fm[file] name map file

-PREPROCESSOR-

/AI<dir> add to assembly search path /Fx merge injected code to file

/FU<file> forced using assembly/module /FI<file> name forced include file

/C don't strip comments /U<name> remove predefined macro

/D<name>{=|#}<text> define macro /u remove all predefined macros

/E preprocess to stdout /I<dir> add to include search path

/EP preprocess to stdout, no #line /X ignore "standard places"

/P preprocess to file

-LANGUAGE-

/Zi enable debugging information /Ze enable extensions (default)

/ZI enable Edit and Continue debug info /Zl omit default library name in .OBJ

/Z7 enable old-style debug info /Zg generate function prototypes

/Zd line number debugging info only /Zs syntax check only

/Zp[n] pack structs on n-byte boundary /vd{0|1} disable/enable vtordisp

/Za disable extensions (implies /Op) /vm<x> type of pointers to members

/Zc:arg1[,arg2] C++ language conformance, where arguments can be:

forScope - enforce Standard C++ for scoping rules

wchar_t - wchar_t is the native type, not a typedef

-MISCELLANEOUS-

@<file> options response file /wo<n> issue warning n once

/?, /help print this help message /w<l><n> set warning level 1-4 for n

/c compile only, no link /W<n> set warning level (default n=1)

/H<num> max external name length /Wall enable all warnings

/J default char type is unsigned /Wp64 enable 64 bit porting warnings

/nologo suppress copyright message /WX treat warnings as errors

/showIncludes show include file names /WL enable one line diagnostics

/Tc<source file> compile file as .c /Yc[file] create .PCH file

/Tp<source file> compile file as .cpp /Yd put debug info in every .OBJ

/TC compile all files as .c /Yl[sym] inject .PCH ref for debug lib

/TP compile all files as .cpp /Yu[file] use .PCH file

/V<string> set version string /YX[file] automatic .PCH

/w disable all warnings /Y- disable all PCH options

/wd<n> disable warning n /Zm<n> max memory alloc (% of default)

/we<n> treat warning n as an error

-LINKING-

/MD link with MSVCRT.LIB /MDd link with MSVCRTD.LIB debug lib

/ML link with LIBC.LIB /MLd link with LIBCD.LIB debug lib

/MT link with LIBCMT.LIB /MTd link with LIBCMTD.LIB debug lib

/LD Create .DLL /F<num> set stack size

/LDd Create .DLL debug library /link [linker options and libraries]

http://www.devpia.com/Forum/BoardView.aspx?no=35174&Tpage=1093&forumname=vc_free

델파이(오브젝트파스칼)가 싫은 C/C++ 추종자(패자).

승자는 자기보다 우월한 사람을 보면 존경심을 갖고 그로부터 배울 점을 찾지만
패자는 자기보다 우월한 사람을 만나면 질투심을 갖고 어디 구멍난 곳이 없는지 찾는다. - 하비스

제 사견으로는 mastercho님께서 논점 제기를 잘못하셨다고 생각합니다.
처음에는 파스칼 개발자가 파스칼이 C보다 2배 빠르다고 주장하고 있는데 이것을 꺾어달라는 식으로 논점을 제기하셨고, 논쟁의 대상은 "저 몇줄의 코드로 언어의 모든걸 평가하다니요?" 였습니다.

이 성능의 차이가 컴파일러의 차이라는 게 드러나고 나서가 문제인데요.. 결국 이것은 언어의 문제가 아니라 컴파일러의 특성 차이라는 것입니다.
처음 파스칼이 2배가 빠르다고 주장했던 파스칼 개발자도 사실은 이 부분은 몰랐을 수도 있습니다. 그렇다고 파스칼이 성능이 떨어지는 언어라거나 델파이가 우둔한 컴파일러는 절대 아니라는 것입니다.

Quote:

글세요 , 억지 논리 아니신가요? 우월하지 않은데도 우월한척한거겠죠

그리고 파스칼이 싫다기보다 , 말이 안되는걸로 우기는게 싫었을뿐입니다

파스칼이 얼마든지 다른 부분에서도 C보다 좋을수 있습니다

그것을 부인한적은 없습니다

하지만 for문같이 몇줄 되지도 않은 코드에서 2배이상 파스칼이 빠르다고 우기는 모습에 짜증이 났을뿐이죠

오히려 C가 싫은 파스칼 추종자의 열등감이 부른 사건이라 불러야 정상이겠죠

절대 바람직한 토론 태도가 아닙니다. mastercho님의 포스팅 중간중간에 충분히 감정을 이입시킬수 있을만한 문장들이 있습니다. 다 끄집어내서 토 달 필요는 없을 것 같구요.
C나 파스칼이 충분히 좋은 언어고 각자 좋은 컴파일러를 가지고 있다면 어느 누구 한쪽이 흠집낼 필요는 없다고 생각합니다.
파스칼 개발자의 있지도 않은 열등의식을 부각시켜 C개발자들의 상대적 우월감을 이곳에서 이용할 필요는 없다고 생각합니다.

토론은 앞사람의 입을 막는 것이 아닙니다. 델파이라도 한번 깔아보시고 소외되었네, 열등감이 어떠네 라고 판단 하시기 바랍니다. 그 다음에 파스칼 개발자들에게 확실한 근거(그 짜증나는 사람의 코드처럼요)를 가지고 응답해야 할 것입니다. 제가 볼때는 mastercho님이야 말로 파스칼을 싫어하는 C/C++추종자로만 보입니다..

ps. 프로그램의 성능은 20%의 코드가 좌우한다. 라는 말 들어보셨는지.. 이곳에서 마저도 20:80의 법칙이 작용합니다. 몇 줄의 코드를 무시하시면 안되져 :D

KLDP 까지 오셔서, 이 쓰레드를 만드신 이유를 잘 모르겠습니다.

누가 맞든 틀리든 간에,여기까지 그 논쟁을 끌어오신게 가히
보기 좋질 않습니다. 그렇게 흥분해야 될 문제인지도 잘 모르겠습니다만
그 상황에서 발끈하셔서 , 데브피아 논쟁을 KLDP 까지 끌어와서 논쟁하는게
과연 보기 좋았는지 생각해보셨으면 좋겠습니다.

꽤 오랜 시간동안 mastercho 님을 보아왔습니다만, 자기 논리가
단번에 먹여들어가지 않으면 흥분하고, 공격적이 되는게 그리 좋은 태도가 아닌것으로 생각합니다.

이번 주제가 맞든 틀리든 간에, 자기 수양은 조금 하시는게 어떨까 싶습니다.

다 읽어봤습니다. C++ 이 빠른지 델파이가 빠른지 처음에 글을 올렸던 분이 C++ 유저인지 델파이인지 관심없습니다.

제가 읽기로는 어느분이 델파이와 C++ 로 테스트 해봤는데, 의외로 델파이가 빨랐다. 그래서 이번에 델파이로 하기로 결정했다... 정도의 글이 아니었습니까?
그런데 못믿겠다. 증명하라...를 지속적으로 요구한 것은 mastercho 님이었고,
그분이 더빠른 코드를 보여달라고 요구했을때, mastercho 님은 스스로 증명해볼생각은 않고, 그글을 KLDP 로 퍼오면 “즉빵”이라며 이곳까지 퍼오신것 아닌가요?
급기야 내 컴퓨터로 와서 내 앞에서 확인해주기전엔 못믿겠으니 와서 증명하라... 고 하는 글을 읽고 웃음이 나오더군요.

제가 보기엔 별 문제없는 글을 대단히 확대해석하신 것 같습니다.
먼저 MyCluster님이 옳은 말 해주셨잖습니까? 더 빠른 코드를 보여주면 된다고..
저도 그렇게 생각합니다. 그게 귀찮아서 싫거나 그럴만한 처지가 못되면 그냥 지나치는게 대부분의 사람들의 선택이지요.

델파이 컴파이러좀 올려주실수 있는지요

제가 한번
for문으로 + 연산을 하는 델파이보다 빠른 결과를 내는 테스트 코드를 만들어 보도록 해보겠습니다 --;
참 그리고 간단한 파스칼 문법도요