컴파일을 빠르게 하는 방법??
용량이 큰 서드 파티 프로그램을 컴파일 할 때
make; make install 이런식으로 하는데요...
이렇게 하면 화면에 그 모든 compile 과정들이 보이니까
OS에 이것을 출력하기 위한 I/O interrupt가 많이 걸릴 것 같은데요.
그렇다고 make > out.txt 형식으로 파일로 redirect를 하게
되더라도 file I/O에 대한 interrupt가 많이 걸려서
컴파일하는데 이런 과정들을 출력하는데에 대한 overhead가
많이 들 것 같습니다.
질문이 있는데...
compile 시 화면에 그냥 결과를 출력하게 하는 게 빠를까요?
아니면 file에 그 과정을 기록하게 하는게 더 빠를까요?
화면에 출력한다고 치더라도 만약 원격 터미널로 접속하여
그 결과가 자신 로컬 호스트에 출력이 된다면 네트워크에 결과값을
패킷에 전송하는 데에 있어서 또 다른 부가적인 overhead가 있을 것 같습니다.
컴파일이 중간에 실패할 수도 있으니, 그렇다고 그 과정을 안보는 것도
이상하구...
도대체 여러분들은 어떻게 컴파일 하는데 어떻게 하십니까?
PS. make > /dev/null 로 하면 null로 출력값들을 다 보내버리는데,
make > out.txt로 할 때와 마찬가지로 file을 기록하는 overhead가 들까요?
유닉스는 모든 것이 파일로 구성되어 있다는 말에 의하면 /dev/null도
하나의 파일이니 거기다 컴파일 과정의 출력 값을 쓰기 때문에
같은 overhead가 들것 같은데요...
고수님들의 가르침 부탁드립니다.
기도 합니다만...
그러구 보니 화면에 출력하는 것도 /dev/ttys에 쓰는 것이니
그럼 로컬 화면에 출력하는 거랑 일반 파일에 쓰는 거랑 똑같은 overhead가 드는 걸일까요??
컴파일과정에 걸리는 시간이 화면에 출력하는 시간보다 대부분 클 것이기 때
컴파일과정에 걸리는 시간이 화면에 출력하는 시간보다 대부분 클 것이기 때문에 화면에 과정을 출력하는 것을 없애더라도 크게 시간차가 나지 않을 것으로 보입니다.
정교하게 체크하는것도 불가능할테고.. (커널 캐시로 2번째 로딩부터는 빨
정교하게 체크하는것도 불가능할테고.. (커널 캐시로 2번째 로딩부터는 빨라집니다.)
한다 하더라도 무의미할것 같습니다.
/dev/null 참조하는 i/o는 커널에서 바로 드랍할것 같은데요.
(어차피 /dev는 커널과 연결되는 장치모음이지 디스크의 특정부분을 가르키지는 않으니까요..)
/dev/null로 보내나 특정 tty로 보내나 별 차이는 없을것 같습니다.
(tty가 9600 이하 모뎀이 아닌이상, lan환경이라면 터미널 신호도 거의 무의미하죠..)
차이가 있을법한 경우라면 disk에 기록하는 경우겠죠... 근데 디스크에 몇백바이트 기록하는건 보통 커널 캐시에 먼저 저장되므로...
어떤 경우라도 큰 차이는 없을겁니다.
gcc 컴파일 속도 올리기에 관한 몇가지 팁.
gcc에서 컴파일 할때는 preprocessing을 거친후 어셈 파일로 바뀌고 다시 오브젝트 파일로 바뀝니다.
중간에 어셈파일로 바뀔때는 $TMPDIR로 설정된 디렉토리에 임시로 어셈 파일을 쓰게 되는데 gcc의 -pipe 옵션을 쓰면 디스크 억세스없이 파이프를 거쳐서 오브젝트를 만들기 때문에 컴파일 속도가 빨라진다고 알려져 있습니다.
그리고 http://ccache.samba.org 의 컴파일러 캐시를 이용하면 속도가 비약적으로 빨라집니다.
그리고 컴파일을 디스크가 아닌 램디스크 (tmpfs 같은)에서 하면 당연히 속도가 빨라질것입니다.
단순히 화면 출력정도는 시스템 IO에 크게 영향을 못줄것 같습니다.
(저같은 경우에는 screen 안에서 빌드 돌리고 그냥 떼어(detach)버립니다 ^^ )
----
데스크탑 프로그래머를 꿈꾸는 임베디드 삽질러
make -j 2옵션으로도 전체 컴파일 시간을 약간 절약할 수 있
make -j 2
옵션으로도 전체 컴파일 시간을 약간 절약할 수 있습니다. (SMP라면 꽤 많이..)
ganadist 님의 좋은 글 감사드립니다. 또 좋은 거 배워갑니다.
ganadist 님의 좋은 글 감사드립니다. 또 좋은 거 배워갑니다. :o
cdpark 님, 그 옵션은 항상 글에서 아니면 말고 식으로 얘기를 하던데요. 그러니까, 쓰면 속도가 빨라지지만 결과는 모르겠다고 하더라구요. 지금은 괜찮은 상황인가요? 궁금합니다.
make -j n
make 에서 -j 옵션은 job 을 분산시키는 옵션입니다..
즉, -j 2 라고 하면, make 에서 수행해야 하는 작업중 두개를 동시에
수행하라는 의미가 됩니다.
동시에 수행한다는 것이 별다른건 아니고..
작업을 하는 프로세스가 두개 뜬다고 보시면 됩니다...
그러니까...make 로 컴파일을 한다면,
컴파일러 프로세스 두개가 서로 다른 소스 파일을 컴파일 한다고 보시면 됩니다.
하지만, 이 옵션 같은 경우에는...
SMP 환경이 아니라면 속도 향상의 효과를 볼수 없습니다.
Single-CPU 환경에서 두가지 작업이 동시에 이루어지는게 가능하질 않기 때문이죠.
(동시에 이루어지는'것' 처럼 보이긴 하지만, 수행 시간을 봤을때는 순차적으로
수행된것과 다름없죠)
그리고 몇몇 경우에서는...
make 가 순차적으로 수행해야 하는 작업을 같이 처리함으로 인해서..
꼬이는 경우도 있습니다 -_-;;
네, 하는 일은 알고 있는데요... 그게... 컴파일 순서가 좀 애매해지
네, 하는 일은 알고 있는데요... 그게... 컴파일 순서가 좀 애매해지는 경우가 있다고 해서 혹시나 여쭤본겁니다...
Re: make -j n
Single CPU라 하더라도 disk I/O와 계산은 동시에 수행할 수 있습니다.
A.c를 컴파일한 후에 A.o를 저장하면서 동시에 B.c를 컴파일하고 있을 수 있죠. 약간의 이득은 있습니다. gcc의 -pipe 옵션에서 얻는 이득처럼요.
사용해도 문제없는 건가요? (집요합니다...) :wink:
사용해도 문제없는 건가요? (집요합니다...) :wink:
Re:
사용해도 어지간한 경우 아니면 문제될일이 없긴 합니다......
물론, 문제가 되는 경우에는..make 가 좀 이상하게 동작한다는 느낌이 듭니다.
문제가 되는 경우의 대부분은 Makefile 내용에 문제가 있는 경우입니다.
make 가 순차적으로 수행해야 하는지, 병렬로 처리해도 되는지 판단하지
못하는 상황에서 순차적으로 수행해야 하는 작업을 나열하면 그런 문제가
생기죠..
보통, GNU Autoconf 를 사용하는 녀석은 문제 없다고 봐도 무방합니다.
SMP 머신을 개발머신으로 1년 넘게 돌리면서 -j 옵션을 많이 써 봤지만..
Autoconf 를 쓴 녀석은 문제를 일으키는 녀석이 없더군요.
어지간히 무성의한 Makefile 이 아니라면 대부분 문제 없이 돌아갔습니다.
그리고,
"효과를 볼수 없다" 라는 표현을 사용한 것은...
컴파일러의 컴파일 타임에 비해서 Disk I/O 나 다른 요인들에서 걸리는 시간이
작기 때문에 그러한 표현을 쓴 것입니다..
Big-O 를 계산할때 가장 큰 Factor 만을 계산하듯...그렇게 생각을 해서
그런 표현을 사용한 것입니다.
이득이 완전히 "0" 라는 의미는 아니였습니다.
단지 메시지가 구찮을땐make -s -s 가 silent
단지 메시지가 구찮을땐
make -s
-s 가 silent
screen + vim + ctags 좋아요~
저같은 경우엔 -j 옵션...
별 차이를 못 느끼겠더라구요.
이렇게 하면 끝나고 수행시간을 보여주는데, 거의 차이가 없던 걸로 기억합니다.
... Do It Now!!!
댓글 달기