정말 C가 C++보다 빠릅니까?

ikpil의 이미지

... 전 헛소리라고 생각 합니다.(좀 강하게 표현했을 뿐; 악의적인 의미는 없어용;;;)

가장 많은 비용을 지불한다는것을 손꼽자면
1. 클래스 설계에 따른 잦은 함수 호출에 드는 비용
2. 가상 함수의 사용에 드는 비용

이라고 생각 하는데요...

... 이 가상 함수 호출과 잦은 함수 호출에 드는 비용은 .. 정말 미약합니다.
아니.. 거의 비용을 물지 않는다고 봐도 될 정도입니다.

C가 C++보다 빠르다면, 어느부분에서 더 빠를 까요?
이게 아니라면, 왜 C가 C++보다 빠르다는 이야기가 나왔을까요?

끝까지 읽어 주셔서 감사합니다.

dhunter의 이미지

http://minjang.egloos.com/1934885
--
from bzImage
It's blue paper

from bzImage
It's blue paper

truecolor의 이미지

네, 정말 C는 C++보다 빠릅니다.
http://minjang.egloos.com/1973793

wish의 이미지

혹시나 해서,
위의 글은 C가 C++보다 빠르다고 주장하는 글이 절대 아닙니다. 원문 글의 "가상 함수 호출 비용이 매우 싸다"는 주장을 반박한 글이라고 봐야 합니다. 블로그 주인장님께서 제목을 좀 섹시하게 뽑으신듯 하네요 :)

DarKMinD의 이미지

콘솔 출력으로 뭐가 빠르다고 하기는 좀 무리가 있지 않을까 싶네요.
가상 테이블, 생성자, 소멸자 등등 C++이 좀 더 사이클을 많이 먹긴 하지만 콘솔 출력에서의 예처럼 극적인 차이가 나지 않을것 같습니다.
또한 어차피 수많은 wrapper등등의 내부에서 함수를 더 부르는 라이브러리가 수없이 많은데 그것 때문에 프로그램 동작을 좌우하지 않으니까요.
(MFC나 닷넷등, 많은 라이브러리 또는 언어를 보통은 문제 없이 잘 쓰니까요.)

에.... 그렇지 않나요? =_=;;
암튼 결론은 'C++에서 객체를 이용한 프로그래밍을 한다면 C언어의 라이브러리 보다 속도에서 손해가 있다. 하지만 일상에선 문제 되지 않는다.' 입니다.

ironiris의 이미지

속도가 아쉬우면 컴퓨터 업글로 해결하는게 가장 속편하죠. :)

sangwoo의 이미지

속도 때문에 C++대신에 C를 선택하는 경우는 없지 않을까요? :-)
어쩌면 옛날에 C++ 컴파일러가 지금 수준까지 도달하지 못했을 때에 나왔던 이야기가 계속 내려오는 걸수도 있겠구요.
처음 C가 나왔을때, 포트란에 비해서 느려서 어떻게 쓰냐는 말이 있었던 걸 생각하면.. :)

----
Let's shut up and code.

----
Let's shut up and code.

feanor의 이미지

C는 여전히 포트란보다 느립니다. C 언어를 만든 데니스 리치가 쓴 The Development of the C Language(http://cm.bell-labs.com/who/dmr/chist.html)에 따르면:

On the other hand, C's treatment of arrays in general (not just strings) has unfortunate implications both for optimization and for future extensions. The prevalence of pointers in C programs, whether those declared explicitly or arising from arrays, means that optimizers must be cautious, and must use careful dataflow techniques to achieve good results. Sophisticated compilers can understand what most pointers can possibly change, but some important usages remain difficult to analyze. For example, functions with pointer arguments derived from arrays are hard to compile into efficient code on vector machines, because it is seldom possible to determine that one argument pointer does not overlap data also referred to by another argument, or accessible externally.

C에서 배열=포인터이므로 최적화하려면 dataflow 분석이 필요하고, 어떤 경우에는 최적화된 코드를 생성하기 어려움을 지적하고 있습니다. 이 지적은 여전히 참입니다.

winner의 이미지

C99이 많이 활용되지는 않는 것 같지만 restrict와 const를 통해 이 문제는 해결되지 않았나요?
여전히 문제가 남아있습니까?

lifthrasiir의 이미지

지금껏 restrict라는 키워드를 표준 C 라이브러리 빼고 본 적이 없는 걸 생각하면 그다지 좋은 해결책은 아니었던 것 같습니다. 애초에 프로그래머에게 얘네들은 서로 다른 영역을 가리킨다라고 써 줘라라고 강제하는 것도 힘들고요.

sangwoo의 이미지

포트란보다 느린 경우가 많이 있지만 (주로 function call overhead에 의한..), 쓸 수 없을 정도는 아니라는 것을 말하고 싶었습니다.
C++도 머 C보다 느린 경우가 없지 않지만, 많이 느리진 않죠. Template 잘 쓰면 훨씬 빠른 경우도 많구요.
----
Let's shut up and code.

----
Let's shut up and code.

anfl의 이미지

system software중 일부는 속도 때문에 C를 더욱 선호합니다.


neogeo의 이미지

C++ 은 거의 대부분 바이너의 사이즈가 커집니다.

안타깝게도 이점은 embedded 영역에선 크리티컬합니다.

물론 vtable 참조 하고 메모리 넓게 넘어다니는것도 embedded 영역에선 무시 못하구요.

( cache miss 가 얼마나 무서운지 메모리가 느릴 수록 느낄 겁니다.. )

PC 에선 크게 성능차이를 느끼지 못 합니다. 그러나 수많은 embedder 머신에선 여전히 C가 강세입니다.

C++ 의 boost를 제대로 지원하는 크로스 컴파일러나 있나 모르겠군요 -ㅅ-

Neogeo - Future is Now.

Neogeo - Future is Now.

그노카스의 이미지

요즘, 왠만한 크로스 컴팔러는 boost를 컴팔합니다.
저도, 제가 개발하는 머신에.. 처음 boost 라이브러리를 설치하기 위해 삽질을 심하게 했었지만,
성공하고 나니, 많이 편해지더군요.^^;;

버뜨... neogeo님 말씀에 동의합니다. ㅎㅎ 혹시, 임베디드 개발하시면서(크로스 컴팔 환경에서),
boost가 가능할지 고민하시는 분들을 위해, 사실관계만.. 밝히는 겁니다. ^^;

blkstorm의 이미지

high-end cpu일수록 그 성능의 차이가 적을거라고 봅니다.

분명히 차이는 있겠지만 고성능일 수록 그 차이는 줄어들고 무의미해질 것같다는게 제 생각입니다.

최익필님이 말씀하신 '비용'이라는 것이 cpu입장에서 보았을 때,

'다음 실행해야할 인스트럭션은 어디에 위치해 있는가'를 계산하기 위한 비용이고,

객체 지향을 지원하는 컴파일러로 생성된 실행 파일들은 이러한 계산을 더 자주 요구할 것 같습니다.

x86에서 본다면, call/ret/jmp/jcc가 있겠지요. (Intel manual 표기에 따른 것입니다)

jmp는 branch target buffer를 잘 활용하면 비용을 확 줄일 수 있고,

absolute address direct call도 jmp와 마찬가지로 비용을 줄일 수 있습니다.

전반적인 Instruction fetch의 비용은 Instruction cache의 구성에 따라서도 줄어들 수도 있습니다..

그리고, pipelining도 영향을 미치겠지요. (갑자기 용어들이 생각이 안나는군요)

고성능 cpu일수록 이런 쪽에 최적화가 많이 되어있으니깐 차이가 적을 것이라고 봅니다.

그냥 cpu에서 돌아가는 모습만 보았을 때 이렇다는 말씀이고, 잘 짜여진 객체지향 프로그램이라면

미미한 성능 저하에 비해서 개발 프로세스에서 얻을 수 있는 장점이 매우 크겠지요.

(Design Patterns 다시 읽어도 감동입니다. ㅠ.ㅠ)

noblepylon의 이미지

확실히 cin, cout은 scanf, printf보다 느리더군요.

언젠가는 1000줄 정도의 데이터를 입출력하는 프로그램을 만든 적이 있는데
cout으로는 4초 걸리던 것이 printf쓰니까 1초도 안 걸리더군요.

그래서 속도가 매우 중요시되는 정보올림피아드를 준비할 때는 (무조건 1초안에 쑤셔넣어야지요...)
거의 대부분이 printf를 사용합니다.

ps. 1초안에 쑤셔넣으려고 애를 쓰다보니까 C++의 탈을 쓴 C가 양성되더군요.
C++는 STL쓸때만 가끔씩. list나 퀵소트 구현하기가 꽤 귀찮으니까.
---
"The truth will make you free."(John 8:32)
"I am the way, and the truth, and the life: no one comes to the Father but through Me."(John 14:6)

---
“내게 능력주시는 자 안에서 내가 모든 것을 할 수 있느니라.”(빌립보서 4:13)

Necromancer의 이미지

c++이 c에 비해 느리게 되는이유라면

가상함수는 내부적으로 함수포인터를 쓰는데, 이런건 긴 파이프라인을 가지는 cpu에는 엄청난 타격이 있습니다.
연산자 오버로딩은 불필요한 객체 복사를 유발하는 경우가 많습니다.
그 외에 RTTI같은 거 쓰는것도 데미지가 상당합니다. 실행시점에 변수형을 결정해야 하는 부담이 있습니다.

Written By the Black Knight of Destruction

Written By the Black Knight of Destruction

M.W.Park의 이미지

개인적으로는 이런 글 보면 좀 답답할 때가 많습니다.

포르셰랑 허머 중 누가 빠를까요?
포장도로에선 당연히 포르셰가 빠릅니다만,
만약 비포장 자갈길이라면? 사막이라면?
포르셰는 몇미터 못가서 앞으로 나가지도 못할 상황에 직면할 수도 있습니다.

문제 도메인에 따라 언어나 도구는 신중히 선택되어야 할것입니다.
즉, 다시말해 누가 빠르더라라고 했다고해서 생각없이 고민없이 선택했다가는 낭패를 볼 수 있다는 말입니다.

또한 단순히 runtime의 수행성능으로만 따지는 것도 문제가 많습니다.
제품개발 기간도 요즘은 중요한 요소로 작용하고 있습니다.

ps. 근데 C랑 C++은 유전자가 거의 같지 않나요? 비교가 별 의미가 없을 것같은데...

-----
오늘 의 취미는 끝없는, 끝없는 인내다. 1973 法頂

-----
오늘 의 취미는 끝없는, 끝없는 인내다. 1973 法頂

소타의 이미지

1란성 쌍둥이는 유전자가 같지만 팔자는 틀리다능 ㅋㅋㅋ

gamdora의 이미지

재미있는 비유네요. :)

hongminhee의 이미지

Scarecrow의 이미지

gamdora의 이미지

그럼 템플릿 메타 프로그래밍을 적극적으로 활용하는 C++은 C보다 빠르나요?

왠지 별 뜻 없는 질문을 한 느낌이 들긴 하지만 궁금합니다.

hongminhee의 이미지

빠르다고 장담할 수 없죠; 하지만 템플릿 메타프로그래밍을 이용하면 컴파일 타임에 할 수 있는 것들이 굉장히 많아집니다. 추상화를 유지하면서요.

tiffang의 이미지

처음 알았는데 참 재밌네요..
실제로 코딩시 적용할려면 연습이 많이 필요하겠어요..

hongminhee의 이미지

특정 언어가 빠르다 느리다 하는 것이 과연 의미가 있나 하는 생각을 해봅니다. 결국 언어의 문제라기 보다는 언어의 구현 문제니까요.

pinebud의 이미지

C++을 사용하는 이유는 속도의 문제보다는 구현의 편의성이나 구현 속도 때문이라고 생각합니다.
생산성이라고나 할까요?
C로 win32를 이용하는 것과 C++로 MFC를 이용하는 경우가 대표적인 C와 C++의 비교라고 생각합니다.
물론 win32구현이 동작은 빠르겠지만 저같은 헐렁한 개발자는 별로 win32를 쓰고 싶지는 않을 듯 합니다.

A rose is a rose is a rose..

netskate의 이미지


처음엔 단순히 rumtime 시의 속도 얘기 아니었나요?
나중에는 개발 속도, 편의성 등등 의 얘기가 나오는데요.

단적으로 말해, 저는 거의 모든 C++ 프로그램을 C 로 짜면 runtime 시의 속도는 향상된다고 생각합니다.
마찬가지로 C 프로그램을 Assembly 로 짜면 역시 속도는 향상됩니다.
있는 그대로의 사실 아닐까요?
===================================================
Make it Simple, Easy, Compact !!!!

===================================================
Make it Simple, Easy, Compact !!!!