음... 최적화 옵션이 없다면 디버깅을 위한 정보 추가로 인한 코드의 크기 증가 뿐일거라고 *예상* 되네요. ... ^^ ... 코드의 크기가 커지면 하드디스크를 조금 더 많이 차지하고, 읽어들일때 I/O가 좀 더 많을꺼고... 인스트럭션 캐시의 히트가 감소할 것 같고, 페이지 몇개쯤 더 차지할지도 모르고 ... 그정도의 성능 저하가 있지 않을까요?
-On 같은 옵션이랑 -g 를 같이 쓰는건 아직까지는 저에게는 별 의미가 없었으므로 패스 ... =)
앗, 그런데 -On 옵션이 들어가는 경우 미친듯이 빨라지는 경우가 가끔 있습니다. . . 얼마전에 경험해봤군요. ( 뭐, 미친듯한 스파게티 코드이긴 했습니다만... ;; )
Add. 생각해보니 디버깅 정보는 인스트럭션 자체에는 전혀 영향이 없겠네요. 사용하는 메모리나 인스트럭션 캐시 등등은 똑같을것 같네요. =) 용량이 커지는 것 뿐??
예전에 재귀호출 함수가 많은 경우에는 이상하게 O2를 주면 프로그램이 뻑나는 증상이 발생하더군요. 뭐 시간이 없어서 그냥 자세히는 보지 않았지만, 최적화는 꼭 크리티컬한 경우가 아니면 저의 경우에는 하지 않습니다. 애초에 프로그램을 쓸모없는 부분을 제거해서 짜는게 더 좋은것 같습니다.
========================================
* The truth will set you free.
속도 차이는 잘 모르겠고 -g 옵션 준 게 실행 파일 크기가 커지는 걸로
속도 차이는 잘 모르겠고 -g 옵션 준 게 실행 파일 크기가 커지는 걸로 알고 있습니다.
세벌 https://sebuls.blogspot.kr/
음... 최적화 옵션이 없다면 디버깅을 위한 정보 추가로 인한 코드의 크
음... 최적화 옵션이 없다면 디버깅을 위한 정보 추가로 인한 코드의 크기 증가 뿐일거라고 *예상* 되네요. ... ^^ ... 코드의 크기가 커지면 하드디스크를 조금 더 많이 차지하고, 읽어들일때 I/O가 좀 더 많을꺼고... 인스트럭션 캐시의 히트가 감소할 것 같고, 페이지 몇개쯤 더 차지할지도 모르고 ... 그정도의 성능 저하가 있지 않을까요?
-On 같은 옵션이랑 -g 를 같이 쓰는건 아직까지는 저에게는 별 의미가 없었으므로 패스 ... =)
앗, 그런데 -On 옵션이 들어가는 경우 미친듯이 빨라지는 경우가 가끔 있습니다. . . 얼마전에 경험해봤군요. ( 뭐, 미친듯한 스파게티 코드이긴 했습니다만... ;; )
Add. 생각해보니 디버깅 정보는 인스트럭션 자체에는 전혀 영향이 없겠네요. 사용하는 메모리나 인스트럭션 캐시 등등은 똑같을것 같네요. =) 용량이 커지는 것 뿐??
--
http://www.deisys.net
Re: -g 옵션을 주고 컴파일 했을 경우 성능..
strip 쓰시면 디버깅 심볼 제거가 가능합니다. man 1 strip 해 보세요 :-)
----
Let's shut up and code.
-g 옵션을 넣어도 그다지 속도차이는 안날것 같습니다. 테스트는 안해봐서
-g 옵션을 넣어도 그다지 속도차이는 안날것 같습니다. 테스트는 안해봐서...
대개, release 할때는 -O2, -O3 정도로 컴파일을 하되, -g 도 같이 넣습니다. 그리고,
binary가 생성되면, copy 한뒤
"strip" 명령을 사용 하여 symbol들을 말끔히 제거해줍니다.
그렇게 되면, -g 를 넣어 컴파일한 것도, -g 를 넣지 않은 상태로 만들 수 있습니다.
그렇게 심볼이 있는 것과 없는 것을 보관하여 나중에 core가 발생하면, 디버깅에 사용하면 됩니다.
---
http://coolengineer.com
[quote="deisys"]앗, 그런데 -On 옵션이 들어가는 경우 미
얼마전에 -O3랑 -O2 중에 O2가 만들어내는 코드가 더 빠르다는
글을 어서 봐서-_- 테스트한다고..
a += pi;
이런걸 한 1000줄정도 복사해넣고.. 컴파일했던 적이 있는데요 흠..
최적화를 하면서.. 이런걸 여러번 하는게 아니라 그냥 계산해서 넣어버리는거 같더라구요-_-;;; 아 뭔가 대략 신기했어요..
c소스로 1000줄이 넘는게 어셈블리로 바꿔버리니
오히려 확 짧아져버리는 기현상이 발생하더군요 :)
막 생각없이 스파게티로 짜버리면 오히려 빨라지는 현상이 더 심할수도
있을거 같단 생각이 들었습니다..
흠.. 근데 테스트결과 신기하게도 오히려 O2가 조금씩 더 빠르더군요
time으로 수십번씩 해서 통계내보니.. ;;;
오랫동안 꿈을 그리는 사람은 그 꿈을 닮아간다...
http://mytears.org ~(~_~)~
나 한줄기 바람처럼..
-O3는 절대 쓰지마세요~!절대! 절대! 절대! 절대!....
-O3는 절대 쓰지마세요~!
절대! 절대! 절대! 절대!
....(절규한다)
지역 최적화를 하기 때문에 무슨 일이 생길지 모릅니다.
특히 일반적인 프로그래밍이 아니라 임베디드 환경에서 사용한 적이 있었는데 멀쩡한 코드가 안돌아가서 무지 고생한 기억이 있답니다.
(결국 컴파일 옵션을 -O3로 했기 때문이라는 것을 알기 위해 반나절을 날려 말았죠.)
My Passion for the Vision!
예 O2가 정답인 것 같습니다.제 경험으로는 O3의 경우는
예 O2가 정답인 것 같습니다.
제 경험으로는
O3의 경우는 미미하게 빨라지긴 하는데요.
약 1~2%정도..
큰 차이를 보이지는 않았습니다.
간혹가다가는 02도 문제를 일으킬때가 있더군요.
예전에 재귀호출 함수가 많은 경우에는 이상하게 O2를 주면 프로그램이 뻑나는 증상이 발생하더군요. 뭐 시간이 없어서 그냥 자세히는 보지 않았지만, 최적화는 꼭 크리티컬한 경우가 아니면 저의 경우에는 하지 않습니다. 애초에 프로그램을 쓸모없는 부분을 제거해서 짜는게 더 좋은것 같습니다.
========================================
* The truth will set you free.
이 부분은 아마 다른곳에 문제가 있어서 그런 걸 겁니다.-02 사용때
이 부분은 아마 다른곳에 문제가 있어서 그런 걸 겁니다.
-02 사용때는 우연히 초기화된 변수가 있었거나..
안전하게도 빈 공간이 있었거나 했을 겁니다.
screen + vim + ctags 좋아요~
[quote="Viz"]-O3는 절대 쓰지마세요~!절대! 절대!
일반적인 환경에서 03 까지는 괜찮을껍니다.
그 이상이 되면 코드가 바이너리 화 되었을때
원래 의도했던것과 같은걸 보장하지 못한다고 하더군요.
O3 이 괜찮은건 제가 시스템의 모든 프로그램을 O3 으로 최적화해서
컴파일 해서 쓰고 있기 때문입니다
하지만 Viz님처럼 임베디드 환경이라면 특별할 수 있겠군요.
- advanced -
-O3 옵션을 주었을 때 치명적인 문제가 발생했던 부분은 외부 인터럽트에
-O3 옵션을 주었을 때 치명적인 문제가 발생했던 부분은 외부 인터럽트에 관련되었던 부분이였습니다.
-O3 옵션부터 이루어지는 지역 최적화로 인해 인터럽트 서비스 루틴에서 벌어지는 일하고 어찌 코드가 꼬여 버려서 그랬다고 그때는 생각했습니다.
그런데... 지금 곰곰히 생각해보면 extern으로 인터럽트하고 관련된 flag로 쓰이는 변수를 선언할때 volatile을 안 붙였을지도 모른다는 생각이 뇌리를 스치네요. :oops:
ps. 저의 실수가 아니라면 컴파일러 버그 중의 하나라고 볼 수 있는 것이니까요. :)
My Passion for the Vision!
댓글 달기