GCC 와 타 컴파일러의 비교

kenny007one의 이미지

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

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

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

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

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

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

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

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

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

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

댓글

warpdory의 이미지

gcc 는 수많은 컴파일러중 하나입니다.

최고인 분야도 있고 아닌 분야도 있는 거죠.

회사에서도 gcc 많이 씁니다. 컴파일러 바꿔서 문제 일으키느니 하드웨어 30% 성능 좋은 거 사는 곳도 많거든요.

gcc 에 들어 있는 포트란보다는 후지쯔 포트란이 20 배쯤 빠르긴 하더군요. 근데, 둘이 서로 다른 결과를 보여줘서 ... 좀 삽질을 했었습니다.


---------
귓가에 햇살을 받으며 석양까지 행복한 여행을...
웃으며 떠나갔던 것처럼 미소를 띠고 돌아와 마침내 평안하기를...
- 엘프의 인사, 드래곤 라자, 이영도

즐겁게 놀아보자.

eminency의 이미지

gcc가 상용 컴파일러, 특히 플랫폼 네이티브(?) 컴파일러보다 느린 것은 대부분 아실 거라고 생각됩니다.

일단 gcc는 오픈 소스 및 개인 개발자에게는 큰 의미가 있다고 생각되구요. 물론 말씀하신 요지는 기업에서의 관점으로 얘기하신 것 같습니다만...

말씀하신 관점에서는 gcc가 성능이 떨어진다고 저도 생각합니다.
gcc의 장점은 역시 무료라는 것과 수많은 플랫폼을 지원한다는 것이 아닐까요...?

노루가 사냥꾼의 손에서 벗어나는 것 같이, 새가 그물치는 자의 손에서 벗어나는 것 같이 스스로 구원하라 -잠언 6:5

deisys의 이미지

MS윈도가 최고의 OS가 아니지만 많은 사람이 사용하는 것과 비슷하지요. ;-)

프로그램의 효율성은 한 Factor일 뿐입니다.

정태영의 이미지

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

vc 는 precompiled header 등을 사용하기 때문에 거기서 얻어지는 속도 이득도 분명 있었을겁니다... ccache 등을 이용했을 땐 어떤지도 혹시 비교해봐주실 수 있으신지요 ;)

그리고 같은 gcc 끼리도 3.3, 3.4, 4.0 의 컴파일 속도도 틀리고... 만들어진 결과물의 크기... 효율 등도 약간씩 차이가 납니다... 3.4 에서 4.0 으로 넘어갈 때 lex,yacc 를 사용하지 않고 직접 파싱하도록 수정되면서 많은 속도 향상이 있었던 걸로 압니다만... 뭐 얼마나 좋아졌는지는 관심이 없어서 잘 모르겠군요 -_-;;

컴파일러 비용을 지불할 생각이 있고... 컴파일 속도등이 중요하다면 상용컴파일러를 사면 되는거고... 그게 그렇게 큰 문제가 아니라면 gcc 를 쓰면 되는게 아닐까 싶네요...

p.s) 그나저나 x86 을 벗어나면 쓸만한 컴파일러는 거의 없을텐데요? sparc이야 sun 에서 만든게 있다지만...

오랫동안 꿈을 그리는 사람은 그 꿈을 닮아간다...

http://mytears.org ~(~_~)~
나 한줄기 바람처럼..

권순선의 이미지

portability와 속도가 서로 tradeoff관계에 있기 때문입니다. gcc의 장점은 지원하는 아키텍처가 다양하다는 것입니다. 그러나 속도는 느립니다. 반면 arm cc는 속도가 빠릅니다만 arm에서만 쓸 수 있습니다.

속도 면에서만 보자면 gcc보다 더 좋은 컴파일러가 많이 있지만 portability 측면에서 gcc를 앞서는 컴파일러는 많이 없을 것입니다. 용도와 상황에 맞게 골라 쓰는 거지요... portability도 높고 속도도 잘 나오고 무료로 사용할 수 있는 컴파일러가 있다면 모두들 그것을 쓰겠지요. :-)

어떤 것이 좋다/나쁘다의 관점에서 접근할 수 있는 것은 아니라고 생각하고요, gcc가 portability를 위해서 어떻게 속도를 희생하였는지, 혹은 구체적으로 어떤 부분 때문에 이 둘이 tradeoff관계에 있는지를 이야기해 보는 것이 좀더 생산적이리라고 봅니다.

yundream4의 이미지

gcc가 다른 사용 컴파일러에 비해서 최고의 성능과 효율을 보여주지 않을 거라는 것은 굳이 수치를 보여주지 않아도, 대게 알고 있는 사실아닌가요 ?

그래도 사용하는건 그 컴파일하는데 걸린다는 시간이 프로젝트에 영향을 줄만큼 크게 문제되지도 않고, 그럭저럭 문제 없이 돌아가는 데다가 특히 *nix 계열에서 작동해야 하는 프로그램의 작성시, 코드의 일관성과 개발환경의 일관성을 유지하게끔 도와주기 (아시겠지만 컴파일러 달라지면 코드에서 개발환경까지 알게모르게 손봐야 될 부분들이 많죠) 때문이죠.

그리고 30%만큼 빠르다는 것은 어떤 환경에서의 테스트 결과 인가요 ? 그런식이라면 대부분이 gcc로 개발되는 커널과 애플리케이션으로 구성된 리눅스 환경은 다른 상용 Unix에 비해서 30%정도 느리거나 불안정하거나 해야 할건데, 실제로 그렇게 느끼는 분이 있나요.

그런 테스트는 그러려니 하고 넘어가는게 일반적이죠. 테스트를 했더니 Mysql이 postgresql에 비해서 50% 빠르더라라는게 특정한 상황을 제외하고는 별 의미가 없듯이 말입니다.

뭐.. 윈도우에서 개발할거라면.. 취미삼아 하는 개발이 아닌한은 VC++을 사용하거나, VC++환경에 익숙한 윈도우 개발자에게 맡기지 gcc를 이용하진 않겠죠.

그리고 기업형 제품을 만드는데 있어서 성능(얼마나 빠른가)는 (윗분 말씀처럼)수많은 선택사항 가운데 하나의 요소일 뿐이구요.

dg의 이미지

수치계산쪽이라면 포트란 말하는거 같은데
상용 포트란 컴파일러가 수치계산쪽으로 매우 최적화 되었지만
gcc의 포트란은 그렇지 않기 때문에 그분야에서는 사용 안하는걸로 알고 있습니다.
c, c++에서는 gcc도 성능이 크게 떨어지지 않을텐데요..

prio의 이미지

kenny007one wrote:

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

논문을 쓰자는 건 아니지만..
성능 비교를 하자면 컴파일러 옵티마이즈 옵션 정도는 적어주셔야.. 수긍하기가 더 쉬울텐데요..
어떤 프로그램을 돌리셨는지 모르겠지만. 제가 아는 상식으로는 수치계산에서 gcc가 VC++보다 세배 느릴리가 없거든요. windows gui라면 모를까. -_-;

kenny007one wrote:

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

벤치마킹이야 원래 트릭 아니겠습니까. :D
'객관적'인 벤치마크가 있을리가요 -_-;;
이건 어떨까요?
http://www.coyotegulch.com/reviews/linux_compilers/index.html

@ gcc가 성능이 그렇게 떨어진다면 제가 논문 때매 고민도 안해요. ㅠ.ㅠ

CY71의 이미지

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

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

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

preisner의 이미지

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

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

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


동감 입니다.
gcc 가 최고의 컴파일러라고 알려진것은 생성된 바이너리의 성능 때문이 아니고,
이만큼 다양한 플렛폼과 언어를 지원하는 컴파일러는 존재 하지 않기 때문입니다.
더군다나.. 무료..
Quote:
GCC가 유용한 분야는 사실 크로스 컴파일러로써 쓰일때 뿐이고

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

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

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

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

The knowledge belongs to the World like Shakespear's and Asprin.

cronex의 이미지

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

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


대체 개발 시간에서 컴파일 시간이 얼마나 차지하길래 =_=;;
그리고 3의 제곱의 시간이 들어간다는 의미는 컴파일 시간이 느린데다가 실행 시간도 느리기 때문에 그러시는 건가요? =_=;;
말씀하신 컴파일 속도 3배 느림 및 실행속도 30%차이를 인정한다고 하더라도
gcc를 사용할 때의 업무시간에 대한 식 이라면
업무시간 = gcc와 무관한 업무시간(이건 동일하겠죠?)+컴파일타임*3+실행시간*1.3 
입니다만?
대체 어떤 방식으로 산출하면 3의 제곱의 시간이 드는지 모르겠군요.
그나저나 제대로 된 비교자료나 언급해주십시오. 근거 없는 비방은 아무런 신빙성도 갖지 못합니다.

------------------------------------------------------------
이 멍청이~! 나한테 이길 수 있다고 생각했었냐~?
광란의 귀공자 데코스 와이즈멜 님이라구~!

tristansong의 이미지

낚였다는 저 밑바닥에서 올라오는 이 분노는 도대체 뭐란 말인가:wink:

zelon의 이미지

음... 저는 나름대로 gcc 가 성능도 꽤 좋다고 믿고(!) 있었는데 그렇지는 않았나보군요. 저한테는 무척이나 의미있는 포스팅입니다.

portability 가 꽤 중요하다는 걸 새삼느꼈습니다.

근데 gcc 에서도 3.4 부터 Precompiled Header 를 지원해줘서 상당히 빠르게 컴파일되더군요.

http://www.wimy.com/wiki/wiki.php/%B8%AE%B4%AA%BD%BA#s-12

살짝 광고를 ^^;;

-----------------------------------------------------------------------
GPL 오픈소스 윈도우용 이미지 뷰어 ZViewer - http://zviewer.wimy.com
블로그 : http://blog.wimy.com

corba의 이미지

이런 광고라면 언제나 환영입니다. :)

tinywolf의 이미지

무언가 흥분된 언쟁을 하고 나신 후에 쓰신듯합니다..

솔직히 전 뭐가 조금더.. 뭐가 조금더.. 따지기에는 체감으로 와닿는건 거의 없게 느껴지는 입장이라..
그냥 그때 그때 있는 거 씁니다..
오히려 크로스 컴파일이나 이런 다른 요인 때문에 선택의 폭이 줄어들긴 하지만..
시간이나 효율은 별로 안 따지게 되더군요..
(워낙 하드웨어들이 좋아지다 보니..)

ㅡ_ㅡ;

체스맨의 이미지

회사 개발 스케쥴에서 컴파일러의 속도 차이는 비중이 작을 뿐더러,
그간 관찰한 바 컴파일 시간이 많이 걸리는 요인은 컴파일러가
느려서가 아니라, 프로그램 아키텍쳐와 소스 구성이 잘 못 되어있기
때문인 경우가 대부분입니다.

Orion Project : http://orionids.org

hanbyeol의 이미지

시스템의 목적, 용도, 개발환경, 개발기간, 성능, 예산, 인적 리소스 등등등 다양한 변수에 따라 이러저러한 이유로 필요한 걸 선택하는 거라고 봅니다.

성능? 효율성? 성능만 따진다면 어셈블러로 코딩해야겠죠. 특히 성능, 메모리, 전력소모 등등등이 관건인 임베디드 환경에서 DSP 에 최적화시키기 위해 코어는 어셈블러를 쓰고 ... 그럭저럭 돌아가는 코드에서 튜닝하는데 수개월에서 1년이 넘게 걸릴 수도 있겠죠.

덩치 큰 박스 경우에 특히 개발 기간 등이 중요할 때는 그냥 박스 사이즈 키우면 되는거고 ...

기술/엔지니어링 이슈와 비즈니스/돈의 이슈의 관점은 다를 수 있으니까요 ....

foo의 이미지

gcc 4.0.x에서 이루어진 많은 개선에 대해서는 별로 언급이 없는 것 같습니다.

포트란 부분은 g77에서 gfortran으로 완전히 이전된 상태이고, 계속적으로 개발되고 있습니다. (g77하위 호환성은 대신이 없어지고,
이미 많은 포트란 프로그램들이 gfortran으로 컴파일 되고 있고..)

벌써 gcc 4.1 브랜치가 가동중입니다.

이미 portability뿐만 아니라 성능 향상을 위한 여러 기술이 구현되고 있습니다. 이만큼 많은 기술이 구현된 컴파일러는 어떤 상용 컴파일러에서도 찾아보기 힘든 것입니다.

많은 기술들이 적용되다보니 gcc 상위버전으로 갈수록 느려지는 경향이 있었고, 이를 보완하기 위해 노력중인 것 같습니다.

gcc는 사실 그다지 느리지 않으며 평균적인 성능을 내고 있으며,
frontend와 backend가 잘 분리되어있기 때문에
g++이 느린 것과 gcc가 느린 것은 그다지 큰 상관관계가 없습니다.
(g++ 프론트 엔드 혹은 플랫폼별 백앤드가 느리거나, libstdc++라이브러리의 성능과 관계있습니다)

또, 플랫폼별로 gcc백앤드의 성능이 다를 수도 있습니다.
(코드를 generating하는 방식이 다를 수 있으므로..)

컴파일러에 관심있는 국내 어셈블러와 C 해커분들도 충분히 도전해볼만한 프로젝트가 아닌가 합니다.
(저는 백앤드부분 조금 보다가 시간상의 이유로 접었...)

foo의 이미지

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

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

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

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

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

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

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

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

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

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

돈 넘치는 회사라면 좀 더 좋은 하드웨어 사달라고 조르세요 :twisted: 그래도 돈 넘치면 VC++ 합법적을 구매해서 쓰고,
오픈소스에 관심 있으시고, gcc의 느린 속도에 불만 있으시면
gcc소스 한번 읽어보심이..

gcc를 써서 개발 스케줄이 얼마나 느려졌는지는 잘 모르겠지만, 총 개발 시간에서 컴파일 시간이 차지하는 비중은 아마 1/10도 안될겁니다.

일례로, glibc같은 것을 컴파일하는데 엄청난 시간이 걸리지만, 그중에서 몇 서브루틴을 고치며 개발을 할 경우 재컴파일 하는 시간은 이것에 1/10도 안걸립니다. (이런게 바로 빌드 툴을 쓰는 방식과 다른 make+기타 스크립트의 강점이죠)

bestyt의 이미지

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

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

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

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

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

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

Tony의 이미지

gcc의 컴파일 타임 볼랜드 계열 제외하곤 다른 컴파일러와 큰 차이난경우 못봤는데요.
gcc의 컴파일된 코드의 수행시간 옵티마이즈 문제인데 인텔이라면 icc가 절대적으로 빠르긴 하지만 앞서 이야기 된 대로 일반 프로그램에선 그다지 크리티컬하진 않던데요. RISC계열 CPU에선 좀 차이가 벌어지긴 하더군요...

hyperhidrosis의 이미지

vc 의 pch 의 기능은 막강합니다.
만일 간단한 cpp 파일을 하나 바꿨는데 컴파일 타임이 2-3분 이상 걸리면
개발에 상당한 지장을 줍니다.

중요치 않은 .h 파일을 하나 수정했는데 수많은 cpp 파일을
컴파일 해야 한다면, cpp와h 파일의 구성을 잘못한 겁니다.

uriel의 이미지

gcc4 쪽에서 intel 쪽의 참여로 icc의 상당 부분이 gcc에 포함되었다고 들었습니다. 성능은 조금 더 지나면 많이 개선되겠죠.

sweetpa의 이미지

프로그램을 안해본지 10년이 넘은것 같네요.
그 옛날에 터미널에서 프로그램하며 개발할 때 컴파일 시간을 절약하려고 별의별 수단을 다 쓰던 생각이 납니다.

특수한 경우 전체를 컴파일 하는 경우가 아니라면 소스를 여러 개로 조각 내서 컴파일 속도를 빠르게 하려고 하는 것이 일반적일겁니다.

아무튼 컴파일 속도도 문제가 되기는 하겠지만 더 큰 문제는 컴파일 결과에 대한 품질이 아닐까요?
수치 계산이라면 계산의 정확성은 말할 것도 없고 생성된 프로그램의 실행 속도가 더 문제가 될겁니다. 요즘은 하드웨어가 빨리 발달해버리니까 책임을 하드웨어에 떠 넘겨버리고 대충 하지는 않는지 궁금합니다.

정말 빠른 코드가 필요한 경우에는 알고리즘과 변수의 적절한 선택, 인라인 어셈블러 사용 등이 필요할겁니다. 물론 이런 경우에는 해당 벤더의 컴파일러가 최고일겁니다마는...

GCC로 컴파일된 linux kernel의 성능은 "완전히" 엉망이겠네요?

notnull의 이미지

GCC 가 비교적 타 상용컴파일러보다 빠르지 않다는건 유닉스계열에서 C 로 프로그램 해 보신 분들이가면 거의 기본적인 상식선 아닌가요..

아파치 웹서버가 IIS 보다 느리다는 것도 대부분 알고 그 속도차이만큼보다 대신할 무언가가 있기때문에 느린걸 쓰는것이지요..

속도만 놓고보면야.... 누가 윈도xp 쓰겠습니까..윈도95,98 쓰지요..날라다닐텐데..

정태영의 이미지

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

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

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

개발을 하시는 분들이라면 소스를 조금씩 고치면서 계속해서 컴파일하실텐데요... 그런 경우라면 ccache 를 통해 엄청난 속도 향상을 느낄 수 있을겁니다...

http://ccache.samba.org/

p.s) 근데 매번 make clean;make 처럼 처음부터 빌드하는건 아니니까 처음에나 6시간이지 매번 6시간은 아닐 듯 한데요?

오랫동안 꿈을 그리는 사람은 그 꿈을 닮아간다...

http://mytears.org ~(~_~)~
나 한줄기 바람처럼..

drinkme의 이미지

폰쪽 코드는 헤더파일에서 상당한 코딩이 이루어진답니다.
그리고, 아주 많은 헤더와 c파일이 그 헤더를 참조하는 형식으로요....
일단 뭐 하나 고치면, 다 컴파일하게되는 경우가 허다합니다.

htna의 이미지

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

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

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

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

WOW Wow!!!
Computer Science is no more about computers than astronomy is about telescopes.
-- E. W. Dijkstra

sangwoo의 이미지

htna wrote:
kernuts wrote:
preisner wrote:
Quote:
GCC가 유용한 분야는 사실 크로스 컴파일러로써 쓰일때 뿐이고

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

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

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

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

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

kernuts의 이미지

htna wrote:
kernuts wrote:
preisner wrote:
Quote:
GCC가 유용한 분야는 사실 크로스 컴파일러로써 쓰일때 뿐이고

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

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

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

저도 궁금하군요....(글쓴이)

The knowledge belongs to the World like Shakespear's and Asprin.

웃는 남자의 이미지

질문있습니다.

위에 언급된 ccache를 사용하면 반복적인 컴파일작업시에 많은 시간을 줄일 수 있습니다.
ccache 가 gcc 와는 잘 연동되는데 윈도우에서도 ccache 를 사용할 수 있는 방법이 있는지요?
아니면 Windows 에서 VC 컴파일할 때 ccache 와 같은 역할을 해주는 프로그램은 어떤게 있는가요?

----------------------------------------
Nothing left after Nirvana.

irondog의 이미지

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

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

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

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


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

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

navidad의 이미지

로우레벨 폰 펌웨어 개발은 아니지만, 그 위레벨에서 동작하는 폰용 App(SKT용 WITOP/WIPI)를 개발해본 경험으로도 ARM 컴파일/링킹시 map 파일을 생성하지 않는경우 기존 1시간 가까이 걸리던 작업이 3-4분 작업으로 줄었던 기억이 있습니다.

컴파일시간이 납득하기 어려울정도로 오래 걸린다면.. 빌드옵션을 확인해보세요.

=================================
나비아빠

bestyt의 이미지

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

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

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

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


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

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

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

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

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

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

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

쌀밥의 이미지

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

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


대체 개발 시간에서 컴파일 시간이 얼마나 차지하길래 =_=;;
그리고 3의 제곱의 시간이 들어간다는 의미는 컴파일 시간이 느린데다가 실행 시간도 느리기 때문에 그러시는 건가요? =_=;;
말씀하신 컴파일 속도 3배 느림 및 실행속도 30%차이를 인정한다고 하더라도
gcc를 사용할 때의 업무시간에 대한 식 이라면
업무시간 = gcc와 무관한 업무시간(이건 동일하겠죠?)+컴파일타임*3+실행시간*1.3 
입니다만?
대체 어떤 방식으로 산출하면 3의 제곱의 시간이 드는지 모르겠군요.
그나저나 제대로 된 비교자료나 언급해주십시오. 근거 없는 비방은 아무런 신빙성도 갖지 못합니다.

TDD 개발 방식을 사용한다면
코딩 한줄 할때마다 컴파일을 하고 실행 시켜봐야 하기 때문에 개발 시간의 상당 부분을 컴파일 타임이 잡아 먹게 됩니다.

*PS : ccache 와 같은 것을 VC++ 에서도 사용할 수 있도록 해주는게 있는지 저도 궁금합니다. 특히 저는 링크 타임을 줄이는 방법을 찾고 싶은데요...

일하는 사람들의 희망 민주노동당 : http://www.kdlp.org
반공 교육의 성과로, 민주주의의 반대가 공산주의(또는 사회주의)라고 생각하는 사람이 많다.

creativeidler의 이미지

플랫폼 독립적이라서 성능 면에서 포기해야하는 어떤 기술적인 문제가 있는 것 같진 않습니다. 어차피 instruction으로 변환되는 건 똑같으니까요. 트레이드오프가 있다면 Human Resource 트레이드오프겠죠. GCC도 많은 사람들이 퍼포먼스 튜닝에 참여한다면 충분히 ICC 못지 않게 빨라질 수 있을 겁니다.

notexist의 이미지

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

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

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

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


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

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

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

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

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

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

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


디버깅할때 그거 없으면 못 살아요... :oops:
그리고 여러가지 면에서 비효율적인 점도 있기는 하지만...
단말기 소스 컴파일시간이 결코 적지는 않죠...

There is more than one way to do it...

kihongss의 이미지

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

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

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

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

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

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

6시간이라.. 정말 하루 2번 풀컴파일하는것도 빠듯하겠네요.
2시간여 풀컴파일한다고 투덜되던 제 모습이 생각나네요~
요즘 회사 생활하면서 제일 바라는게 있다면
컴파일 전용 머신, 사양 빵빵하게 해서 한대 줬으면
좋겠군요.

moonhyunjin의 이미지

only gcc can compiles Linux kernel. :D

리눅스까 99% -> 리눅스 해볼려다가 몰라서 포기한 윈도우 유저들.

<- 이거면 안 되는 게 없어~
정품 소프트웨어 사용 캠패인

Necromancer의 이미지

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

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

Written By the Black Knight of Destruction

hyperhidrosis의 이미지

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

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

가끔 dependency 를 제대로 못처리하는 경우가 있지만..
단점보다는 장점이 많다고 생각합니다.
컴파일 속도를 절반이상줄여주니까요..
가끔 문제생기면 rebuild-all 해주면 되고요.

pynoos의 이미지

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

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


대체 개발 시간에서 컴파일 시간이 얼마나 차지하길래 =_=;;
그리고 3의 제곱의 시간이 들어간다는 의미는 컴파일 시간이 느린데다가 실행 시간도 느리기 때문에 그러시는 건가요? =_=;;
말씀하신 컴파일 속도 3배 느림 및 실행속도 30%차이를 인정한다고 하더라도
gcc를 사용할 때의 업무시간에 대한 식 이라면
업무시간 = gcc와 무관한 업무시간(이건 동일하겠죠?)+컴파일타임*3+실행시간*1.3 
입니다만?
대체 어떤 방식으로 산출하면 3의 제곱의 시간이 드는지 모르겠군요.
그나저나 제대로 된 비교자료나 언급해주십시오. 근거 없는 비방은 아무런 신빙성도 갖지 못합니다.

TDD 개발 방식을 사용한다면
코딩 한줄 할때마다 컴파일을 하고 실행 시켜봐야 하기 때문에 개발 시간의 상당 부분을 컴파일 타임이 잡아 먹게 됩니다.

*PS : ccache 와 같은 것을 VC++ 에서도 사용할 수 있도록 해주는게 있는지 저도 궁금합니다. 특히 저는 링크 타임을 줄이는 방법을 찾고 싶은데요...

이기회에 cl.exe 를 대체할만한 ccache.exe를 만들어 보심이... :)

lovewar의 이미지

irondog wrote:

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

아래와 같이 하면 될까요?

컴파일 시간은 순차적으로 대기하는 시간이 상당한 것으로 판단하여 make파일들 관계를 분석하여 관련성을 최소화시킨 다음,
하위부터 상위로 올라가는 makefile에서 n개의 프로세스를 실행하게끔 변경하면 n개의 프로세스만큼 시간을 줄이지는 못하지만,
상당한 시간을 줄 걸로 예측은 하지만, 막상 해보지 않아서 모르겠습니다.

아래는 그와 관련된 내용을 도식화 한것 입니다.

동급일 경우 연관성이 없게끔 make 파일을 만든다는 가정하여,
 
              makefile                               (3) 
               /          \
  submakefiles        .....n     - n개의 프로세스에서 실행  (2)
           |
        submakefiles  ....n       -  n개의 프로세스에서 실행 (1)
 
괄호안의 숫자는 완료순서입니다.
hey의 이미지

autotools 등을 이용해 연관성을 잘 짜시고 make -jN 하시면 됩니다.


----------------------------
May the F/OSS be with you..


jongwooh의 이미지

sangwoo wrote:
htna wrote:
kernuts wrote:
preisner wrote:
Quote:
GCC가 유용한 분야는 사실 크로스 컴파일러로써 쓰일때 뿐이고

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

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

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

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

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

you must know the power of dark side.

htna의 이미지

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

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

WOW Wow!!!
Computer Science is no more about computers than astronomy is about telescopes.
-- E. W. Dijkstra

lifthrasiir의 이미지

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

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

다른 말로 하면 현대 역사는 유비가 1/4밖에 못 먹는 상황으로 진행되고 있다는 뜻입니다.

- 토끼군

litdream의 이미지

인텔 컴파일러가 인텔 아키텍쳐 위에서 속도가 가장 빠르다는 글을 읽고,
예전에 읽었던 재미있는 ./ 기사를 하나 올립니다.
MS 와 인텔이 행보를 같이 하는건 알겠지만, 이렇게까지 ~~

http://yro.slashdot.org/article.pl?sid=05/07/12/1320202&tid=142&tid=118&tid=123

요약하자면, Intel 에서 제작한 컴파일러가 AMD 아키텍쳐를 발견하면 의도적으로
덜 효율적인 code path 를 실행한다는 얘기인데요, 사실여부까지는 확인안하고
그냥 재미로만 읽었습니다.

삽질의 대마왕...

fibonacci의 이미지

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

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

사실을 단정하여 대단히 선정적인 글을 쓰시는군요. 본인이 그렇게 느낄 뿐이겠죠.

No Pain, No Gain.

지나가는새의 이미지

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

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

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

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

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

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

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

Fever Pitch!

theone3의 이미지

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

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

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

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

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

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

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

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

당신은 사랑받기 위해 태어난 사람.

죠커의 이미지

많은 분들이 언급 안하시는데 GCC는 템플릿 하나만 조사한다면 느린 컴파일러입니다.

특히 아래의 경우에는 동종 컴파일러에 비해서 매우 느린데 아래의 big O 복잡도를 보이고 있기 때문입니다.

비용이 들지 않는 특수화의 경우에 O(N^3)
재귀적인 인스턴스화의 경우에 O(N^2)
메타함수 이름의 구조 복잡도 O(N)

물론 일반적으로는 폭발할 듯이 상승하지 않습니다만 컴파일 시간이 느리다고 개발자가 알기에는 충분합니다.

specerx의 이미지

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폰은 아닐거 같군요.

Tony의 이미지

map file 만들고 하면서 메모리가 1G이하일경우에 아마 그정도 시간 걸릴껍니다.

soul의 이미지

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

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

null

monpetit의 이미지

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

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


뭐죠? 독백인가요?
dipole의 이미지

일반적이지 않은 상황에서 다른 결과를 나타낸다고 해서 일반화 시켜 버리는 것은 동의 할수가 없네요.

어떤분이 말씀하셨듯이 임베디드와 같은 크로스 환경을 제외한다면 GCC 의 효율성은 떨어진다라고 하면 임베디드에서 사용하고 있는 사람에게는 최고의 컴파일러가 됩니다.
컴파일 시간이 얼마 걸리지 않는 사람에게는 컴파일 시간이 그리 중요한 요소가 되지 않습니다. 이 글타래를 올리신 분처럼 컴파일 시간이 몇시간씩 되는 일에
컴파일러를 사용하시는 분이 몇프로나 될까요? 소수의 예를 들어 일반화시켜 버리는 것이 아닐까요?

GCC 가 최고라고 이야기 하고 싶지 않습니다.
여러가지 요소들을 고려했을때 우수한 컴파일러중의 하나라고 생각합니다.

너는 누구냐?

soul의 이미지

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

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


뭐죠? 독백인가요?

유치한 패러디입니다.

null

unipro의 이미지

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

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

이해할 수 있는 설명을 부탁합니다. 직접 설명하기에 자료가 방대하다면 참조할 수 있는 문서라도 좀 부탁드립니다.

내 블로그: http://unipro.tistory.com

Prentice의 이미지

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

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


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

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

이해할 수 있는 설명을 부탁합니다. 직접 설명하기에 자료가 방대하다면 참조할 수 있는 문서라도 좀 부탁드립니다.


GCC가 형편없다고 떡밥을 던진 사람에게, 떡밥을 물 사람은 여기 얼마 없다는 반박을 하신 것 같습니다.
wkpark의 이미지

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

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


검은해님의 해석을 보고 이해했습니다 :P 오늘의 유머에 한표~

온갖 참된 삶은 만남이다 --Martin Buber

maddie의 이미지

애플도 gcc를 씁니다.
BSD도 gcc를 씁니다.
심지어는 일부 윈도 프로그램도 gcc를 이용하는 것으로 알고 있습니다.

움. 왜 리눅스만 쓸데 있는 바이너리가 나온다고 생각하는 건지..
그렇다면 맥오에스는 엄청 느리고 맨날 에러나야겠군요.

힘없는자의 슬픔

serialx의 이미지

정작 그물 푼 본인께서는 보지도 않는 글에 뭣하러 답글을 다십니까? :wink:

Dont feed the troll!

uleech의 이미지

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시간이면 충분하구요.
솔루션을 뭘 쓰느냐에 따라 다르겠지만요;;
paranoea의 이미지

uleech wrote:
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시간이면 충분하구요.
솔루션을 뭘 쓰느냐에 따라 다르겠지만요;;

tcc 에 ccache 적용해보신분 없나요?
cache 얻어서 copy 하는데도 기존 컴파일시간과 동일하더군요.

arm compiler 가 워낙 좋은건가요? :cry:

unipro의 이미지

검은해 wrote:
kenny007one wrote:
GCC가 최고라 생각하시는분이 여기 많으실줄 압니다.

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


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

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

이해할 수 있는 설명을 부탁합니다. 직접 설명하기에 자료가 방대하다면 참조할 수 있는 문서라도 좀 부탁드립니다.


GCC가 형편없다고 떡밥을 던진 사람에게, 떡밥을 물 사람은 여기 얼마 없다는 반박을 하신 것 같습니다.

선입관이란 것이 무섭군요. 읽기전에 이미 문장의 의미를 이미 짐작해놓고 읽으니 문장의 참뜻을 몰랐습니다. 무척 재밌는 내용이었습니다. :lol:

내 블로그: http://unipro.tistory.com

segfault의 이미지

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

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

kenny007one의 이미지

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

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

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

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

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

blkstorm의 이미지

Embedded s/w 개발자입니다.

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

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

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

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

ironiris의 이미지

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

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

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

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

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

왜 gcc는 인텔칩에서 돌아가는 인텔컴파일러와 비교당해야하고 플스에서 돌아가는 소니컴파일러와 비교당해야 하는거지요?
플랫폼이 다른 인텔컴파일러와 소니컴파일러는 아예 비교조차 할수도 없잖아요??
비교당할수 있는 gcc가 더 좋은 것 아닌가요??
이 글을 쓰신 분은 빌게이츠보다도 돈이 없고 장동건보다도 못생겼고 송유근보다도 멍청하니 이 세상 존재의 가치가 없습니까??
jongwooh의 이미지

kenny007one wrote:

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

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

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

자체적으로 제작한 컴파일러를 가지고 있는 회사는 몇개 없습니다. 프로세서 칩을 만들면서 그 칩용 컴파일러를 만든 회사는 sun, mips (현재 sgi), 인텔, ibm, HP, arm, ti 정도뿐이라고 보시면 됩니다.

프로세서 메이커가 아니면서 컴파일러를 제공하는 있는 업체는 마이크로소프트와 메트로웍스, 메타웨어(예전에 High-C컴파일러라는걸 들어보신 적이 있으신 분이 있을겁니다), 볼랜드 외에는 거의 없습니다. 8비트 8051계열 컴파일러를 제공하는 Keil정도가 좀 특화된 회사랄까... (그리고 마이크로소프트 컴파일러는 옛날 래티스C를 산 경우입니다)

모토롤라의 경우에는 프로세서 사업부문을 freescale이라는 회사로 분사하고 그 회사의 powerpc 칩들은 ibm에서 라이센스한 컴파일러와 gcc 툴체인을 제공합니다. 8비트인 6800 계열 컴파일러는 메트로웍스 코드워리어를 OEM 제공합니다.

한마디 첨언하자면 80년대까지만 해도 어셈블리 프로그래밍을 많이 했기 때문에 사람이 직접 어셈블리 언어를 쉽게 만들기 위해 CISC 칩을 먼저 만들고 고급 언어 컴파일러를 그 칩에 맞추어 만들었는데, 90년대부터 RISC개념이 퍼지면서부터 컴파일러가 생산하는 컴파일 결과에 맞추어 칩을 만듭니다. (sparc, mips, alpha, powerpc등등이 모두 그 개념으로 만든 프로세서들입니다. 인텔 IA64-아이태니엄은 좀 다른 개념-VLIW으로 접근해서 컴파일러가 힘을 못 씀)

소니나 도시바는 자체적으로 CPU를 만들지 않습니다. 그건 자체적으로 컴파일러를 만들 생각이 없어서 cpu를 만들지 않는 것입니다. 플스2,3만 해도 MIPS와 PowerPC 프로세서를 라이센스해서 외부 팹에서 생산하거나 또는 프로세서 메이커(IBM에)에 주문생산하고 칩에 맞는 컴파일러를 mips,ibm에서 제공받아서 제품을 만듭니다.

일본회사중에 프로세서 메이커이면서 컴파일러를 제공하는 회사는 NEC로부터 분사한 르네사스가 독자설계한 SH아키텍처에 기반한 H8계열 칩과 SH C 컴파일러를 제공하고 있는게 제가 알고 있는 유일한 컴파일러입니다만, H8 프로세서를 쓰는 회사가 너무 적어서 gcc에 비해 별로 최적화되어 있지는 않고 주로 내세우는 장점은 편리한 크로스 컴파일 개발 IDE라는 점으로 팔고 있습니다.

일본 회사들이 어떤 자체 CPU와 컴파일러제품을 제공하는지를 제시하지도 못하면서 그런 혼자만의 상상세계에서 만들어낸 구라를 치지는 말으시길 바랍니다.

you must know the power of dark side.

M.W.Park의 이미지

blkstorm wrote:
Embedded s/w 개발자입니다.

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

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

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

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


컴파일러 뿐만 아니라 개발에 필요한 다른 모든 제품들도 돈주고 사는 것이 성능 향상에 대부분은 도움이 되겠지만, 문제 생겼을 때 책임을 물을 곳이 생긴다는 것이 더 큰 의미를 가진다고 생각합니다.
컴파일 결과물이 오동작을 했을 때 명백히 컴파일러 잘못인 것이 확실하다고 해도 gcc로 만든 경우라면 직접고치든지, 피해가는 꽁수를 쓰던지, 버그픽스를 기다리던지 하는 방법밖에 없습니다.
돈주고 샀을 때는 전화해서 당장에 고쳐내라고 호통을 칠 수 있습니다.

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

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

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

cwryu의 이미지

M.W.Park wrote:

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

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

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

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

죠커의 이미지

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

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

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

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

죠커의 이미지

cwryu wrote:
M.W.Park wrote:

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

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

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

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

상용 제품도 책임지지 않나 보군요.

여담이지만 제가 가장 어렸을 때 충격을 받았던 것은 DJGPP의 한 버전을 접했을 때 였습니다. 하드디스크가 날라가고 메인보드에서 연기가 나더라도 책임지지 않는다는 구문을 국민학생 시절에 보고 몇일 밤을 잠을 잘 못잤던 기억이 나네요 (...)

죠커의 이미지

jongwooh wrote:
한마디 첨언하자면 80년대까지만 해도 어셈블리 프로그래밍을 많이 했기 때문에 사람이 직접 어셈블리 언어를 쉽게 만들기 위해 CISC 칩을 먼저 만들고 고급 언어 컴파일러를 그 칩에 맞추어 만들었는데, 90년대부터 RISC개념이 퍼지면서부터 컴파일러가 생산하는 컴파일 결과에 맞추어 칩을 만듭니다. (sparc, mips, alpha, powerpc등등이 모두 그 개념으로 만든 프로세서들입니다. 인텔 IA64-아이태니엄은 좀 다른 개념-VLIW으로 접근해서 컴파일러가 힘을 못 씀)

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

segfault의 이미지

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

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

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

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

아마추어용 툴체인인 devkitadv, 닌텐도에서 배포하는 SDK가 둘다 GCC 기반이고, 둘 간의 성능 차이는 그리 심하지는 않다고 들었습니다.

다만, devkitadv에는 API가 없는게 치명적입니다. 메모리 번지수가 define되어 있는 헤더파일 하나만 참조해서 코딩해야 합니다.
(아마 이것때문에 아마츄어 GBA 게임중에 괜찮은 퀄리티가 나오지 않는 걸지도 모르겠네요.)

저도 GBA 개발 툴킷으로 간단한 GBA 어플리케이션을 짜본 적이 있어서 압니다.

M.W.Park의 이미지

cwryu wrote:
M.W.Park wrote:

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

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

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

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

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

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

ljh6341의 이미지

blkstorm wrote:
Embedded s/w 개발자입니다.

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

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

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

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

테클은 절대 아니고 그냥 아는 바가 있어서 소견을 몇자 적습니다.

chip vendor가 제공하는 툴은 몇가지 최적화된 옵션들과 유틸리티 들이 존해합니다. 하지만, 다른 컴파일러에 비해서 더 최적화 된다는 보장은 없습니다.

그리고 ps2의 정식 sdk에 있는 컴파일러는 gcc가 아니고, 상용 컴파일러를 따로 사용하고 있습니다.

본론으로 돌아가서..

컴파일러의 치명적인 버그로 인해 일어난 것이 명백한 사고라면, 고소가 가능하지 않을까요. 단, 상대가 M$라면 제고해야 될지두요. ^^;;
또, 정부를 상대로 "캐나다로 회사 이전해 버린다"고 협박하면 .. -_-;

whitelazy의 이미지

ljh6341 wrote:
blkstorm wrote:
Embedded s/w 개발자입니다.

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

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

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

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

테클은 절대 아니고 그냥 아는 바가 있어서 소견을 몇자 적습니다.

chip vendor가 제공하는 툴은 몇가지 최적화된 옵션들과 유틸리티 들이 존해합니다. 하지만, 다른 컴파일러에 비해서 더 최적화 된다는 보장은 없습니다.

그리고 ps2의 정식 sdk에 있는 컴파일러는 gcc가 아니고, 상용 컴파일러를 따로 사용하고 있습니다.

본론으로 돌아가서..

컴파일러의 치명적인 버그로 인해 일어난 것이 명백한 사고라면, 고소가 가능하지 않을까요. 단, 상대가 M$라면 제고해야 될지두요. ^^;;
또, 정부를 상대로 "캐나다로 회사 이전해 버린다"고 협박하면 .. -_-;


각 컴파일러 라이센스 따라 다르지만 그런경우 책임 안지오 하는 경우도 있을수 있습니다
몇몇 API라이센스 보니까 원자로나 병원등에서 쓰지마시오 일생기면 우린 책임 못짐.. 이란 요지의 라이센스가 있는 경우도 있습니다
이건 컴파일러 라이센스에서 본건 아니지만요 ;;;

또 위에 보다보면 전용 컴파일러가 좋다는 글도 있지만...
GCC 아무리 전용 컴파일러보다 느리다 해도 좋은 컴파일러입니다
전용 혹은 상용 컴파일러들중에 X86이나 파워피시 같은 시피유말고 개발 타임이나 생명 주기(?) 가 짧은(시피유가 빨리나오고 빨리 단종되는 경우말입니다 소프트웨어 말고) MCU 경우에는 개발사에서 제공해 주는 컴파일러도 버그 많고 성능 안좋은 경우도 많습니다... 워낙 계속 새로운 칩이 개발되니 거기에 맞는것도 계속 추가하느라 그런지 ...
이런경우 왜안되는지 난감해 하다가 다른거로 우회하지요..
성능 비교는 안해봤지만 모 MCU 개발에 참가했다는 루머가 있는 모사의 컴파일러가 있어 단지 참가 했으니좋지 않겠느냐는 이유로 그 시피유 용으로 동아리방에서 GCC를 대체해 잠식당한적이 있습니다(물론 당시에는 나름대로 gcc보다 사용하기 편했다는것도 이유겠지요) 이거 쓸때는 옵션 하나 변경 혹은 한줄 추가시에도 프로그램이 돌았다 말았다 하는 경우가 많았습니다(물론 저만 - _-;;; 나중가니 너만 왜그러냐던 친구 한명도 동일한 증상 생기길래 열심히 갈궈줬지요 ㅋㅋㅋ)
또한 어차피 안쓸꺼라 생각했는지 진짜 엉망인 코드 집어넣으면 아예 수행도 안되구요 뭐 다중 루프같은경우 ... 2중 for문 이상쓰면 안돕니다... 물론 일주일 밤세고 어차피 성능에 문제가 없어서 써본거긴 하지만 다시짰습니다 ㅠㅠ (정말 자고싶어서....) 나중에 들으니 이중 for문 이상은 아예 지원안하나보더군요 ;;;
버전따라서 라이브러리가 지원하는 범위도 차이나구요 가격별로 표준 라이브러리로 쓸수있는 표준함수 범위가 정해져있더군요...
그코드 전부 GCC로 이식후에 그런 당혹스러운 경우 생기는 적이 없었습니다... 물론 제가 프로그램 실력이 일천하여 생기는 경우겠지만 너무 심하더군요
TI사의 DSP도 한번 해봤는데 나름대로 버그 많았습니다
DSP쓰긴했는데 속도가 남아돌아 귀찮아서 표준 라이브러리 가져다 쓰다가 버그가..................
문제가 한 반쯤은 표준라이브러리에서 걸리는군요 ;;; 이건 컴파일러랑은 별개지만... 보통다 통합환경으로 지원하니 -_-;; 같이 뭍혀서 투덜대고 있었군요 ㅎㅎ;;

cwryu의 이미지

M.W.Park wrote:
cwryu wrote:
M.W.Park wrote:

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

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

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

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

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

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

지리즈의 이미지

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

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

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

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

There is no spoon. Neo from the Matrix 1999.

jongwooh의 이미지

CN wrote:

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

아, 제말은 "전통적인" 컴파일러가 힘을 못 쓴다는 말이었습니다. VLIW의 경우 한 워드에 인스트럭션과 레지스터 지정이 여러개가 들어가는데 gcc의 RTL구조는 특히 그런 문제를 해결하기에 아주 취약합니다.

you must know the power of dark side.

죠커의 이미지

jongwooh wrote:
CN wrote:

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

아, 제말은 "전통적인" 컴파일러가 힘을 못 쓴다는 말이었습니다. VLIW의 경우 한 워드에 인스트럭션과 레지스터 지정이 여러개가 들어가는데 gcc의 RTL구조는 특히 그런 문제를 해결하기에 아주 취약합니다.

아 RTL이 아이테니엄에 취약한가요? 처음 들었습니다. 그런 문제점도 있군요.

hys545의 이미지

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

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

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

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


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

즐린

ayh1800의 이미지

꽤 격해지시네요.

임베디드 쪽 분들은 아무래도 한정된 자원을 활용하셔야 되는 만큼 컴파일러의 최적화 부분등에 대해서 아쉬움이 많으신 듯 합니다.

저같은 응용프로그래머의 경우에는 사실상 큰 차이를 못 느끼는데 말이죠.

컴파일 속도 빠른 건 아무래도 개발하는 입장에서는 편한 부분이 있는 것 같습니다.
Borland 툴을 주로 이용해서 windows 개발을 많이 합니다만, C++ Builder를 사용할 때보다 delphi를 사용할 때 말할 수 없는 쾌감을 느낄 때가 많습니다. C++ Builder에서 근 몇 분 가까이 걸릴 컴파일 작업이 Delphi에서는 불과 수초에 쫑나는 기분입니다. 파스칼 언어의 장점이겠죠.

UI부분 같은 부분 수정할 때는 때때로 실행해봐야지만 어떤 식으로 동작하는지 정확히 볼 수 있는 경우가 많기 때문에, 아무래도 컴파일이 빠르다는 건 장점일 수 있겠습니다. 고치고 실행해보고 고치고 실행해보고를 빠르게 반복할 수 있는 게 편할 때가 많죠.

gcc가 pre-compiled header를 지원하는 모양이네요. 개인적으로는 pre-compiled header를 쓸 때와 안 쓸 때 굉장히 큰 차이를 느꼈었는데 말입니다.

최근 추세에서는 아무래도 하드웨어의 성능이 워낙 좋아지다 보니 적절한 수준의 성능 저하는 적당히 무시하는 분위기 같습니다만, (자바나 .Net같은 걸 보면 솔직히.. ^^) 이 쪽은 Unix 쪽 개발하시는 분들이나 임베디드 쪽 분들이 많으셔서 그런지 절대 그렇지 않은 부분이네요.

이것저것 많은 입장 차이를 배우고 갑니다.

지리즈의 이미지

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

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

마지막 M$의 소스 자동고침은 전에 어떤 분이 엄창나게 짜증을 내셨다는
말에서 그냥 농담삼아 적어본 글입니다. ^^

그런데, 컴파일러가 소스를 날려 보리는 것이나,
혹은 하드드스크나 다른 건드려서는 안돼는 파일을
삭제하는 오류가 분명히 있다면,
상용제품은 분명히 고소할 수 있습니다.

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

M$와 법정 싸움하는 것만큼 아둔것이 없죠..
물론 수십억대의 대부라면 몰라도요...

그것은 M$의 EULA가 완벽해서가 아니라,
법정싸움에서 승소할 만큼 돈이나 혹은 그러할 만한 가치가 없기 때문입니다.

승소해도 보상금이 소송에 드는 비용을 상쇄해야 하고,
피해도 보상받을 수준이 되야 하는데,이런 경우는 거의 없거든요...

돈이 충분히 아주 많이 남아돌고, M$를 흠찝을 내고 싶다면,
충분히 고소할 수도 승소할 수도 있습니다..

물론 먼저 M$의 제품이 하자가 있어야 겠지만요...

There is no spoon. Neo from the Matrix 1999.

나는오리의 이미지

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

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

마지막 M$의 소스 자동고침은 전에 어떤 분이 엄창나게 짜증을 내셨다는
말에서 그냥 농담삼아 적어본 글입니다. ^^

그런데, 컴파일러가 소스를 날려 보리는 것이나,
혹은 하드드스크나 다른 건드려서는 안돼는 파일을
삭제하는 오류가 분명히 있다면,
상용제품은 분명히 고소할 수 있습니다.

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

욕심많은오리 wrote:
VS를 이용해서 C++을 하고있지만 소스를 자기 멋대로 고치는 경우는 못봤습니다.

http://bbs.kldp.org/viewtopic.php?t=59067

이런 글도 있더군요... 물론, C++예기는 아닙니다만...

There is no spoon. Neo from the Matrix 1999.

페이지

댓글 달기

Filtered HTML

  • 텍스트에 BBCode 태그를 사용할 수 있습니다. URL은 자동으로 링크 됩니다.
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param><hr>
  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.

BBCode

  • 텍스트에 BBCode 태그를 사용할 수 있습니다. URL은 자동으로 링크 됩니다.
  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param>
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.

Textile

  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • You can use Textile markup to format text.
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param><hr>

Markdown

  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • Quick Tips:
    • Two or more spaces at a line's end = Line break
    • Double returns = Paragraph
    • *Single asterisks* or _single underscores_ = Emphasis
    • **Double** or __double__ = Strong
    • This is [a link](http://the.link.example.com "The optional title text")
    For complete details on the Markdown syntax, see the Markdown documentation and Markdown Extra documentation for tables, footnotes, and more.
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param><hr>

Plain text

  • HTML 태그를 사용할 수 없습니다.
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.
  • 줄과 단락은 자동으로 분리됩니다.
댓글 첨부 파일
이 댓글에 이미지나 파일을 업로드 합니다.
파일 크기는 8 MB보다 작아야 합니다.
허용할 파일 형식: txt pdf doc xls gif jpg jpeg mp3 png rar zip.
CAPTCHA
이것은 자동으로 스팸을 올리는 것을 막기 위해서 제공됩니다.