GCC 와 타 컴파일러의 비교

제가 똑같은 C++코드로 약 만라인짜리 코드를 VC++과 C++코드의 컴파일 속도를 비교해보자면 약 3배의 시간차가 났습니다.

제가 똑같은 C++코드로 약 만라인짜리 코드를 VC++과 C++코드의 컴파일 속도를 비교해보자면 약 3배의 시간차가 났습니다.

그리고 플랫폼의 차이라고 치자면 같은 Linux에서 인텔의 컴파일러도 GCC보다 훨씬 빠르고 객관적으로 30% 가까운 성능향상을 수치계산에서는 보인다고 나와있습니다.
이렇듯 제가 특별히 시간차가 나는 코드를 비교한게 아니라 구글에서 검색해보셔도 그럴겁니다.

x86 플랫폼에서는 인텔 컴파일러가 제일 빠릅니다만...

문제는 인텔 전용이라는 겁니다. 앞서도 많은 분들이 지적하셨듯이 인텔 전용 컴파일러는 다른 플랫폼에서의 유연성이 매우 떨어집니다. 다만 인텔 윈도 플랫폼만을 놓고 보면, 컴파일 속도는 물론 바이너리의 실행속도까지 상당한 차이를 보입니다. 인텔이 과거 소켓 펜티엄3 와 소켓 애슬론과 성능 경쟁 벌일때 단순히 인텔 컴파일러로 컴파일 한 것만으로도 펜티엄3 성능이 높아졌을 정도니까요.

gcc 는 효율성 면에서는 별로 좋은 선택이 아닙니다. gcc 이외에도 X 라든가 리눅스 커널도 역시 효율 좋은 선택은 아니죠. 컴파일 리눅스인 젠투조차도 전용 코드로 컴파일해도 성능향상 폭은 미미한 수준입니다. 확실히 개발자 입장에서는 gcc 를 이용해서 프로그램 개발하기가 쉽지는 않습니다만, 크로스 플랫폼을 염두에 둔다면 선택의 여지는 전무합니다. gcc 를 써야하겠죠. 결국 어떤 것을 선택할 것인가의 문제로 귀결됩니다. 성능이냐 유연성이냐 ㅡ,.ㅡ

GCC가 유용한 분야는 사실 크로스 컴파일러로써 쓰일때 뿐이고

이게 만약 실제 회사에서 개발스케쥴로 보자면 모든 개발시간이 3배가 아니라 3의 제곱으로 시간이 더 들어가니 개발비용은 정말 엄청난 차이인것입니다.

개인이 취미로는 상관없지만 회사에서 이래도 GCC를 사용해야 될까요? 엄청난 낭비일것입니다.

GCC가 최고라 생각하시는분이 여기 많으실줄 압니다.

하지만, 사실은 완전히 다릅니다.

GCC가 유용한 분야는 사실 크로스 컴파일러로써 쓰일때 뿐이고

대부분 윈도우 플랫폼 컴파일러와 상용 유닉스 컴파일러보다 컴파일 속도 자체도 엄청 느리고..

Linux빼고는 그다지 효율적인 바이너리를 생성해내지도 못합니다.

제가 똑같은 C++코드로 약 만라인짜리 코드를 VC++과 C++코드의 컴파일 속도를 비교해보자면 약 3배의 시간차가 났습니다.

그리고 플랫폼의 차이라고 치자면 같은 Linux에서 인텔의 컴파일러도 GCC보다 훨씬 빠르고 객관적으로 30% 가까운 성능향상을 수치계산에서는 보인다고 나와있습니다.

이렇듯 제가 특별히 시간차가 나는 코드를 비교한게 아니라 구글에서 검색해보셔도 그럴겁니다.

이게 만약 실제 회사에서 개발스케쥴로 보자면 모든 개발시간이 3배가 아니라 3의 제곱으로 시간이 더 들어가니 개발비용은 정말 엄청난 차이인것입니다.

개인이 취미로는 상관없지만 회사에서 이래도 GCC를 사용해야 될까요? 엄청난 낭비일것입니다.

kernuts wrote:

preisner wrote:

Quote:

GCC가 유용한 분야는 사실 크로스 컴파일러로써 쓰일때 뿐이고

크로스,멀티 플렛폼 개발을 해보셨다면 이게 얼마나 중요한지 아실겁니다.
자바가 탄생한 이유 중 하나가 젠장할 멀티 플렛폼 때문이라는거 잘 아시죠?

유비쿼터스 시대로 갈 수록 더욱더 중요해지겠지요...

유비쿼터스가 gcc와 어떠한 연관성이 있나 궁금해지는군요..
^^;;;;

kenny007one wrote:

이게 만약 실제 회사에서 개발스케쥴로 보자면 모든 개발시간이 3배가 아니라 3의 제곱으로 시간이 더 들어가니 개발비용은 정말 엄청난 차이인것입니다.

개인이 취미로는 상관없지만 회사에서 이래도 GCC를 사용해야 될까요? 엄청난 낭비일것입니다.

대체 개발 시간에서 컴파일 시간이 얼마나 차지하길래 =_=;;
그리고 3의 제곱의 시간이 들어간다는 의미는 컴파일 시간이 느린데다가 실행 시간도 느리기 때문에 그러시는 건가요? =_=;;
말씀하신 컴파일 속도 3배 느림 및 실행속도 30%차이를 인정한다고 하더라도
gcc를 사용할 때의 업무시간에 대한 식 이라면

업무시간 = gcc와 무관한 업무시간(이건 동일하겠죠?)+컴파일타임*3+실행시간*1.3 

입니다만?
대체 어떤 방식으로 산출하면 3의 제곱의 시간이 드는지 모르겠군요.
그나저나 제대로 된 비교자료나 언급해주십시오. 근거 없는 비방은 아무런 신빙성도 갖지 못합니다.

irondog wrote:

bestyt wrote:

프로젝트에 컴파일시간이 차지하는비중이 작다는 의견엔 조금 다른 의견입니다.

컴파일시간이 6시간이나 걸리게 되면 개발자가 개발에 쓰이는 시간중 무시못할 시간이 될것입니다.

제가 폰을 개발하는 일에 종사해서 그런지 이쪽은 풀로 컴파일할라치면 6시간이나 걸리네요. 6시간걸리는 컴파일시간은 출근해서 하루에 2번 돌릴수(많으면 3번)밖엔 없을것이고, 퇴근시 걸어놓고 아침에 확인했는데 컴파일에러보면 스팀오릅니다..

저희회사에서도 이런 불필요한 컴파일시간을 어떻게하면 줄여볼까 연구중(?)이고 갖가지 꽁수(?)들이 난무하고 있는실정입니다.

어느 제조사의 소스코드를 가지고 계신지는 모르겠으나, 제 경험(컬ㅤㅋㅝㅁ msm6100)으로는 map파일만 안만들어도 배로 빨라지고, 헤더파일 채크해서 소스 디펜던시 만드는 perl스크립트에서 전체 디렉토리가 아닌 소스 디렉토리만 검사하도록 해도 엄청난 개선 효과를 보실 수 있습니다.

폰업계를 비하하고 싶은 생각은 전혀 없습니다만, 진짜 비효율적이던데요. 소스코드 관리서부터...

제말을 오해하셨나보네요.

물론 .c파일 몇개고치던지 dependency낮은것들은 금방됩니다.
linking도 전체 컴파일시간에 비하면 금방되구요.

제가 얘기해드리고 싶은건
깊은 dependency를 가지는 경우를 컴파일할때가 종종있으며,
이런경우를 닥쳤을때 .c파일 하나 컴파일할때 걸리는 속도차이가 쌓이고 쌓이면 많은 시간차이를 나타낼것이라는 겁니다.

개발자라면 조금이라도 빨리 컴파일해주는 넘을 선택할꺼고,
그 컴파일속도도 컴파일러를 선택하는데 무시못하는 시간이라는 거죠.

물론 map파일 없으면 빨라집니다. 그러나 디버깅엔 필수파일이기 때문에 map과 elf파일은 필수입니다.

vc pch는 제가 싫어하는 기능 중 하나인데

헤더파일 인클루드해도 못 찾는 경우가 왕왕 발생하더군요 -_-

어느 제조사의 소스코드를 가지고 계신지는 모르겠으나, 제 경험(컬ㅤㅋㅝㅁ msm6100)으로는 map파일만 안만들어도 배로 빨라지고, 헤더파일 채크해서 소스 디펜던시 만드는 perl스크립트에서 전체 디렉토리가 아닌 소스 디렉토리만 검사하도록 해도 엄청난 개선 효과를 보실 수 있습니다.

htna wrote:

kernuts wrote:

preisner wrote:

Quote:

GCC가 유용한 분야는 사실 크로스 컴파일러로써 쓰일때 뿐이고

크로스,멀티 플렛폼 개발을 해보셨다면 이게 얼마나 중요한지 아실겁니다.
자바가 탄생한 이유 중 하나가 젠장할 멀티 플렛폼 때문이라는거 잘 아시죠?

유비쿼터스 시대로 갈 수록 더욱더 중요해지겠지요...

유비쿼터스가 gcc와 어떠한 연관성이 있나 궁금해지는군요..
^^;;;;

여러 임베디드 타겟을 사용할 수 있다는 뜻입니다.

jwhan wrote:

유비쿼터스는 유비가 1/4를 먹는다는 뜻이라는데...

유비가 1/4밖에 못먹었나요???
꽤 먹은줄알았는데...
역사를 다시 써야할듯...

GCC가 최고라 생각하시는분이 여기 많으실줄 압니다.

하지만, 사실은 완전히 다릅니다.

bestyt wrote:

프로젝트에 컴파일시간이 차지하는비중이 작다는 의견엔 조금 다른 의견입니다.

컴파일시간이 6시간이나 걸리게 되면 개발자가 개발에 쓰이는 시간중 무시못할 시간이 될것입니다.

제가 폰을 개발하는 일에 종사해서 그런지 이쪽은 풀로 컴파일할라치면 6시간이나 걸리네요. 6시간걸리는 컴파일시간은 출근해서 하루에 2번 돌릴수(많으면 3번)밖엔 없을것이고, 퇴근시 걸어놓고 아침에 확인했는데 컴파일에러보면 스팀오릅니다..

저희회사에서도 이런 불필요한 컴파일시간을 어떻게하면 줄여볼까 연구중(?)이고 갖가지 꽁수(?)들이 난무하고 있는실정입니다.

.c파일 하나당 컴파일걸리는시간이 조금 차이난다고 치더라도 티끌모아 태산이라고, 전체적으론 최소 한시간정도 차이난다고 들었고, 개발자 입장에선 한시간이라도 빠른걸 쓰게 마련이겠죠^^;

상용프로젝트에서 느끼는 컴파일러의 선택은 실행시간 못지않게 컴파일시간도 절대적이란 생각입니다.

폰? phone 인가요? 아니면 PON(passive optical network)인가요? 선뜻 이해가 안가는데, 두 가지 모두 어떤 물건을 컴파일 하길래 6시간이나 걸리는지.. -_-;; 이거 완전 신세계네요 -_);;

지나가는새 wrote:

bestyt wrote:

프로젝트에 컴파일시간이 차지하는비중이 작다는 의견엔 조금 다른 의견입니다.

컴파일시간이 6시간이나 걸리게 되면 개발자가 개발에 쓰이는 시간중 무시못할 시간이 될것입니다.

제가 폰을 개발하는 일에 종사해서 그런지 이쪽은 풀로 컴파일할라치면 6시간이나 걸리네요. 6시간걸리는 컴파일시간은 출근해서 하루에 2번 돌릴수(많으면 3번)밖엔 없을것이고, 퇴근시 걸어놓고 아침에 확인했는데 컴파일에러보면 스팀오릅니다..

저희회사에서도 이런 불필요한 컴파일시간을 어떻게하면 줄여볼까 연구중(?)이고 갖가지 꽁수(?)들이 난무하고 있는실정입니다.

.c파일 하나당 컴파일걸리는시간이 조금 차이난다고 치더라도 티끌모아 태산이라고, 전체적으론 최소 한시간정도 차이난다고 들었고, 개발자 입장에선 한시간이라도 빠른걸 쓰게 마련이겠죠^^;

상용프로젝트에서 느끼는 컴파일러의 선택은 실행시간 못지않게 컴파일시간도 절대적이란 생각입니다.

폰? phone 인가요? 아니면 PON(passive optical network)인가요? 선뜻 이해가 안가는데, 두 가지 모두 어떤 물건을 컴파일 하길래 6시간이나 걸리는지.. -_-;; 이거 완전 신세계네요 -_);;

phone쪽으로 알고 있습니다.
후배가 phone쪽에서 일하는데,
한번 컴파일 하면 기본은 2시간 걸린다고 하더군요.
아마 phone쪽이 맞을 겁니다.
자세한 건 저도 모릅니다. -_-;;;

GCC가 최고라 생각하시는분이 여기 많을거라고 생각하는 걸로 압니다.

하지만, 사실은 완전히 다릅니다.

GCC가 최고라 생각하시는분이 여기 많을거라고 생각하는 걸로 압니다.

하지만, 사실은 완전히 다릅니다.

mmim wrote:

theone3 wrote:

지나가는새 wrote:

bestyt wrote:

프로젝트에 컴파일시간이 차지하는비중이 작다는 의견엔 조금 다른 의견입니다.

컴파일시간이 6시간이나 걸리게 되면 개발자가 개발에 쓰이는 시간중 무시못할 시간이 될것입니다.

제가 폰을 개발하는 일에 종사해서 그런지 이쪽은 풀로 컴파일할라치면 6시간이나 걸리네요. 6시간걸리는 컴파일시간은 출근해서 하루에 2번 돌릴수(많으면 3번)밖엔 없을것이고, 퇴근시 걸어놓고 아침에 확인했는데 컴파일에러보면 스팀오릅니다..

저희회사에서도 이런 불필요한 컴파일시간을 어떻게하면 줄여볼까 연구중(?)이고 갖가지 꽁수(?)들이 난무하고 있는실정입니다.

.c파일 하나당 컴파일걸리는시간이 조금 차이난다고 치더라도 티끌모아 태산이라고, 전체적으론 최소 한시간정도 차이난다고 들었고, 개발자 입장에선 한시간이라도 빠른걸 쓰게 마련이겠죠^^;

상용프로젝트에서 느끼는 컴파일러의 선택은 실행시간 못지않게 컴파일시간도 절대적이란 생각입니다.

폰? phone 인가요? 아니면 PON(passive optical network)인가요? 선뜻 이해가 안가는데, 두 가지 모두 어떤 물건을 컴파일 하길래 6시간이나 걸리는지.. -_-;; 이거 완전 신세계네요 -_);;

phone쪽으로 알고 있습니다.
후배가 phone쪽에서 일하는데,
한번 컴파일 하면 기본은 2시간 걸린다고 하더군요.
아마 phone쪽이 맞을 겁니다.
자세한 건 저도 모릅니다. -_-;;;

CDMA 전화기를 개발 하고 있습니다.
컴파일 시간은 PC 사양에 따라 다르긴 하겠지만 제 경우에는 현재 개발 하고 있는 모델의 경우 풀 컴파일 시 한시간 반 정도 걸립니다.
MSM6500 기반이고 컴파일러는 ADS 1.2 (Build 848), PC사양은 펜티엄4 3.0Ghz, RAM 1G 입니다.
PC 사양이나 소스에 따라 차이는 있겠지만 퀄컴기반 CDMA폰이라면 풀 컴파일 시간이 한시간에서 두시간 사이가 아닐까 싶습니다.
6시간이 걸린다는 글은 좀 놀랍군요. 제가 MSM5100, 6025, 6100, 6500 폰들을 보았지만 풀컴파일시 세시간이 넘어가는 경우는 본 적이 없습니다.
6시간 걸린다는 분은 CDMA폰은 아닐거 같군요.

GSM도 길어야 2시간입니다.
덩치가 작은 녀석들은 1시간이면 충분하구요.
솔루션을 뭘 쓰느냐에 따라 다르겠지만요;;

닌텐도는 그럴지 몰라도, 대부분의 CPU 까지 제작하는 일본 대기업 전자회사들은 자체 컴파일러를 갖고 있습니다.

소니, 도시바, NEC, 등등..

모두 자사 CPU의 최적화된 gcc는 비교도 안되는 성능의 컴파일러들이죠.

...
또다른 극단적인 예를 들자면, 자동차 엔진을 제어하는 모듈이 오동작해서 급발진 사고가 났다고 칩시다.
대부분의 경우 자동차 회사가 대충 쉬쉬하며 돈으로 떼우거나, 결함이 없다고 대외적으로 발표합니다.
기계적인 결함일 수도, 탑제된 제어 소프트웨어의 문제일 수도 있겠지요. 조사 결과 제어 소프트웨어가 문제를 일으켰을 경우에는 소프트웨어 제작사에게 1차적인 책임이 있겠지요. 그런데 그 제작사가 프로그램을 분석해본 결과 자신들이 사용한 컴파일러가 자체오류를 가지고 있어서 제대로된 바이너리를 생성하지못했다면 그 제작사는 당연히 컴파일러 제작회사에 책임을 물을 것입니다.

상용 제품을 제작하는 입장에서 보면 책임의 소재를 명확히 하기 위해서라도 상용 제품들을 쓰는 것을 선호할 수 밖에 없습니다.
"어떠한 종류의 보증도 제공하지 않습니다."와 같은 의미가 "모든 것이 니 책임이다" 쯤 되겠죠. 8)

M.W.Park wrote:

...
또다른 극단적인 예를 들자면, 자동차 엔진을 제어하는 모듈이 오동작해서 급발진 사고가 났다고 칩시다.
대부분의 경우 자동차 회사가 대충 쉬쉬하며 돈으로 떼우거나, 결함이 없다고 대외적으로 발표합니다.
기계적인 결함일 수도, 탑제된 제어 소프트웨어의 문제일 수도 있겠지요. 조사 결과 제어 소프트웨어가 문제를 일으켰을 경우에는 소프트웨어 제작사에게 1차적인 책임이 있겠지요. 그런데 그 제작사가 프로그램을 분석해본 결과 자신들이 사용한 컴파일러가 자체오류를 가지고 있어서 제대로된 바이너리를 생성하지못했다면 그 제작사는 당연히 컴파일러 제작회사에 책임을 물을 것입니다.

상용 제품을 제작하는 입장에서 보면 책임의 소재를 명확히 하기 위해서라도 상용 제품들을 쓰는 것을 선호할 수 밖에 없습니다.
"어떠한 종류의 보증도 제공하지 않습니다."와 같은 의미가 "모든 것이 니 책임이다" 쯤 되겠죠. 8)

돈 주고 산 컴파일러의 라이선스를 잘 읽어 보세요. no warranty이긴 마찬가지입니다. 컴파일러를 이용한 사람이 "이거 내 책임 아니다"라고 면피할 핑계거리는 되겠지만, 실제로는 제조사에서 아무것도 책임지지 않습니다.

저는 오히려 문제점들을 숨기는 기업들의 습성때문에 돈주고 산 개발툴에 더 어려움을 많이 겪었습니다. 문제가 영영 해결되지 않았을 때 아무 정보도 없어 답답하기만 하고, 기껏 귀중한 시간을 소비해서 컴파일러 개발팀까지 연락이 닿을 때쯤 되니까 이미 알려진 버그다 업그레이드해라 이런 말 들으면 정말 힘빠집니다.

sigsegv wrote:

모바일 게임 제작업체에서 일하고 계시는 지인의 말씀으로는

닌텐도에서 배포하는 NDS SDK툴킷이 GCC라더군요.

그런가요? 닌텐도 게임보이의 경우는 아마추어 + 해커들이 사용하는 툴이 GCC였거든요. 그래서 정식 툴은 다를 것으로 생각했었습니다.

NDS에는 바뀐 것인가요? 아니면 원래 내가 잘못생각하고 있었던 건가요?

Embedded s/w 개발자입니다.

예전에 임베디드 쪽에서 유명한 강사분이 강의한 것을 들은적이 있는데, 해당 chip vendor에서 제공하는 컴파일러를 사용하는 것도 최적화 방법중에 하나라고 합니다. (다른걸로는 나눗셈/나머지 연산 사용 줄이고... 기타 등등...)

그냥 취미 생활정도라면 gcc면 충분하지만, 제품을 만드는 경우라면 컴파일러를 구입해서 사용하는 것이 좋다고 들었습니다. 바이너리 사이즈, 실행 속도 모두 이득을 본다고 하더군요.

그리고, ps2는 gcc컴파일러 쓴걸로 알았는데 아닌가보군요. @.@

(추가 : 바이너리 사이즈는 아닌가? -_-a)

cwryu wrote:

M.W.Park wrote:

...
또다른 극단적인 예를 들자면, 자동차 엔진을 제어하는 모듈이 오동작해서 급발진 사고가 났다고 칩시다.
대부분의 경우 자동차 회사가 대충 쉬쉬하며 돈으로 떼우거나, 결함이 없다고 대외적으로 발표합니다.
기계적인 결함일 수도, 탑제된 제어 소프트웨어의 문제일 수도 있겠지요. 조사 결과 제어 소프트웨어가 문제를 일으켰을 경우에는 소프트웨어 제작사에게 1차적인 책임이 있겠지요. 그런데 그 제작사가 프로그램을 분석해본 결과 자신들이 사용한 컴파일러가 자체오류를 가지고 있어서 제대로된 바이너리를 생성하지못했다면 그 제작사는 당연히 컴파일러 제작회사에 책임을 물을 것입니다.

상용 제품을 제작하는 입장에서 보면 책임의 소재를 명확히 하기 위해서라도 상용 제품들을 쓰는 것을 선호할 수 밖에 없습니다.
"어떠한 종류의 보증도 제공하지 않습니다."와 같은 의미가 "모든 것이 니 책임이다" 쯤 되겠죠. 8)

돈 주고 산 컴파일러의 라이선스를 잘 읽어 보세요. no warranty이긴 마찬가지입니다. 컴파일러를 이용한 사람이 "이거 내 책임 아니다"라고 면피할 핑계거리는 되겠지만, 실제로는 제조사에서 아무것도 책임지지 않습니다.

아 제글의 의도를 약간 오해하셨나 봅니다.
상용제품이 모든 책임을 진다고 사용계약서에 명시를 한다는 뜻은 아닙니다.
사소한 것은 그냥 넘어간다 쳐도, 생명에 관계된 것처럼 중대한 사안은 충분히 소송감이 된다는 뜻입니다.

아이테니엄의 경우에는 컴파일러가 힘을 못 쓰는게 아니라 현실적으로 컴파일러 밖에 못 쓰는 것이 아닌가요? 이쪽은 어셈블러를 만들기가 매우 힘이 든 플랫폼으로 알고 있습니다.

cwryu wrote:

사용계약서에 모든 책임을 진다고 명시하지 않고, 오히려 반대로 절대 책임을 지지 않는다고 명시해 놓습니다. 소프트웨어 세계에 품질보증이나 제조물 책임같은 건 없습니다.

그 효과가 어디까지인가는 논란의 여지가 있겠지만 책임이 없다는 라이선스에 "동의" 버튼을 눌러 설치를 했으니 컴파일러 제조사도 충분한 면피꺼리가 되죠.

컴파일러가 컴파일 도중 일부 소스를 날려 버리거나,
혹은 하드디스크 파티션을 날려버리거나,
전에 유명한 M$의 VS처럼 자기 마음대로 소스를 고쳐버리거나
한다면, 고소의 가능성은 있겠죠...
(마지막은 없나?)

하지만, 컴파일러 자체의 버그로 인해
생성물이 오동작하는 것에 대해서는 책임을 물기 어려울 것 같습니다.

지리즈 wrote:

컴파일러가 컴파일 도중 일부 소스를 날려 버리거나,
혹은 하드디스크 파티션을 날려버리거나,
전에 유명한 M$의 VS처럼 자기 마음대로 소스를 고쳐버리거나
한다면, 고소의 가능성은 있겠죠...
(마지막은 없나?)

고소 가능성 절대 없습니다.

미국에서는 전자렌지에 고양이 돌려서 죽인거 가지고도 재조사 고발합니다.
그런데 ms 고발한 적이 없다는건. 고발해보았자,라이센스 때문에 승소할 가능성이 없다는 말입니다.

VS를 이용해서 C++을 하고있지만 소스를 자기 멋대로 고치는 경우는 못봤습니다.