make 의 - j 명령 (Linux 프로그램 컴 파일 가속)

다음으로 이동:https://www.freemindworld.com/blog/2010/100105_make_complie_process_faster.shtml
프로젝트 가 점점 커지 면서 프로젝트 전 체 를 다시 컴 파일 해 야 할 때마다 시간 을 낭비 하 는 일이 다.리 서 치 를 통 해 속 도 를 높이 는 데 도움 이 되 는 방법 을 찾 아 정리 했다.
1. tmpfs
윈도 에서 램 디 스 크 를 사용 해 한 항목 의 컴 파일 시간 을 4.5 시간 에서 5 분 으로 줄 였 다 는 말 이 있다. 아마도 이 숫자 는 좀 과장 되 었 을 것 이다. 그러나 대충 생각해 보면 파일 을 메모리 에 넣 고 컴 파일 하 는 것 이 디스크 보다 훨씬 빠 를 것 이다. 특히 컴 파일 러 가 임시 파일 을 많이 만들어 야 한다 면.
이 방법 은 실현 원가 가 가장 낮 습 니 다. Linux 에서 tmpfs 를 직접 mount 하면 됩 니 다.그리고 컴 파일 된 프로젝트 에 대해 아무런 요구 도 없고 컴 파일 환경 을 바 꿀 필요 도 없다.mount -t tmpfs tmpfs ~/build -o size=1G
2.6.32.2 의 Linux Kernel 로 컴 파일 속 도 를 테스트 합 니 다.
물리 디스크 사용: 40 분 16 초
tmpfs: 39 분 56 초 로
으.. 변 한 게 없어 요.컴 파일 이 느 린 것 같 습 니 다.그러나 실제 프로젝트 의 경우 컴 파일 과정 에서 포장 등 IO 밀집 작업 이 있 을 수 있 기 때문에 가능 하 다 면 tmpfs 를 사용 하 는 것 은 유익 하고 해 롭 지 않다.물론 큰 프로젝트 에 있어 서, 당신 은 충분 한 메모리 가 있어 야만 이 tmpfs 의 비용 을 부담 할 수 있 습 니 다.
make -j
IO 가 병목 이 아 닌 이상 CPU 는 컴 파일 속도 에 영향 을 주 는 중요 한 요소 가 되 어야 한다.
make - j 로 하나의 인 자 를 가지 고 프로젝트 를 병렬 컴 파일 할 수 있 습 니 다. 예 를 들 어 쌍 핵 기계 에 서 는 make - j4 를 사용 하여 make 로 최대 4 개의 컴 파일 명령 을 동시에 실행 할 수 있 도록 합 니 다. 그러면 CPU 자원 을 더욱 효과적으로 이용 할 수 있 습 니 다.
아니면 Kernel 로 테스트 할 까요?
Make: 40 분 16 초 로.
make 로. - j4: 23 분 16 초.
make 로. - j8: 22 분 59 초.
이 를 통 해 알 수 있 듯 이 다 핵 CPU 에서 적당 한 병행 컴 파일 을 하면 컴 파일 속 도 를 뚜렷하게 높 일 수 있다.그러나 병행 하 는 임 무 는 너무 많 으 면 안 되 며, 일반적으로 CPU 의 핵심 수량의 두 배가 적당 하 다.
그러나 이 방안 은 cost 가 전혀 없 는 것 이 아 닙 니 다. 만약 에 프로젝트 의 Makefile 이 규범 에 맞지 않 고 의존 관 계 를 정확하게 설정 하지 않 으 면 병렬 컴 파일 의 결 과 는 컴 파일 이 정상적으로 진행 되 지 못 하 는 것 입 니 다.의존 관계 설정 이 너무 보수 적 이면 자체 컴 파일 의 병행 도가 떨 어 지고 최고의 효 과 를 거두 지 못 할 수도 있다.
ccache
ccache 는 컴 파일 된 중간 결 과 를 캐 시 하여 다시 컴 파일 할 때 시간 을 절약 할 수 있 도록 합 니 다.이것 은 커 널 을 하 는 데 있어 서 정말 좋 은 일이 다. 커 널 의 코드 를 수정 한 다음 에 다시 컴 파일 해 야 하기 때문에 이 두 번 의 컴 파일 은 대부분 변화 가 없 을 것 이다.평소 개발 사업 에 도 마찬가지다.왜 make 가 지원 하 는 증분 으로 직접 컴 파일 하지 않 습 니까?아니면 현실 에서 Makefile 의 불 규범 때문에 이런 '똑똑 한' 방안 이 정상적으로 작 동 하지 못 할 수도 있 습 니 다. 매번 make clean 에서 make 를 해 야 합 니 다.
ccache 를 설치 한 후 / usr / local / bin 에서 gcc, g +, c + +, cc 의 symbolic link 를 만 들 고 / usr / bin / ccache 에 체인 을 연결 할 수 있 습 니 다.어쨌든 시스템 이 gcc 등 명령 을 호출 할 때 ccache 로 호출 되 는 지 확인 하면 됩 니 다.
계속 테스트:
ccache 로 첫 번 째 컴 파일 (make - j4): 23 분 38 초
ccache 의 두 번 째 컴 파일 (make - j4): 8 분 48 초
ccache 의 세 번 째 컴 파일 (약간의 설정 수정, make - j4): 23 분 48 초
설정 수정 (CPU 형식 을 바 꿨 습 니 다.) 이 ccache 에 미 치 는 영향 이 매우 큰 것 같 습 니 다. 기본 헤더 파일 이 바 뀌 면 모든 캐 시 데이터 가 무효 가 되 므 로 다시 시작 해 야 합 니 다.그러나 c 파일 의 코드 만 수정 하면 ccache 의 효 과 는 상당히 뚜렷 합 니 다.또한 ccache 를 사용 하여 프로젝트 에 특별한 의존 이 없고 배치 비용 이 낮 아서 일상적인 업무 에서 실 용적 입 니 다.
ccache - s 로 cache 의 사용 과 명중 상황 을 볼 수 있 습 니 다:

cache directory                   /home/lifanxi/.ccache
cache hit                           7165
cache miss                         14283
called for link                       71
not a C/C++ file                     120
no input file                       3045
files in cache                     28566
cache size                          81.7 Mbytes
max cache size                     976.6 Mbytes

이 를 통 해 알 수 있 듯 이 두 번 째 번역 때 cache 만 명중 되 었 고 cache miss 는 첫 번 째 와 세 번 째 컴 파일 로 가 져 왔 다.두 번 의 cache 가 81.7M 의 디스크 를 차지 하 였 으 나, 여전히 충분히 받 아들 일 수 있다.
distcc
한 대의 기계 의 능력 에 한계 가 있어 서 여러 대의 컴퓨터 와 연합 하여 함께 컴 파일 할 수 있다.이것 은 회사 의 일상적인 개발 에서 도 가능 하 다. 왜냐하면 모든 개발 자 들 이 자신의 개발 컴 파일 환경 을 가지 고 있 기 때문이다. 그들의 컴 파일 러 버 전 은 일반적으로 일치 하고 회사 의 네트워크 도 비교적 좋 은 성능 을 가지 기 때문이다.이때 가 바로 distcc 가 크게 솜 씨 를 발휘 할 때 이다.
distcc 를 사용 하 는 것 은 상상 처럼 모든 컴퓨터 가 완전히 일치 하 는 환경 을 요구 하 는 것 이 아니 라 소스 코드 만 make - j 로 병렬 컴 파일 할 수 있 고 분포 식 컴 파일 에 참여 하 는 컴퓨터 시스템 에서 똑 같은 컴 파일 러 를 가지 도록 요구 합 니 다.사전 처 리 된 원본 파일 을 여러 대의 컴퓨터 에 나 누 어 주 는 원리 이기 때문에 사전 처리, 컴 파일 된 대상 파일 의 링크 와 컴 파일 을 제외 한 다른 작업 은 컴 파일 을 시작 하 는 메 인 제어 컴퓨터 에서 이 루어 지기 때문에 컴 파일 을 시작 하 는 그 기계 에 완전한 컴 파일 환경 을 갖 추 라 고 요구 하면 된다.
distcc 설치 후 서 비 스 를 시작 할 수 있 습 니 다:/usr/bin/distccd --daemon --allow 10.64.0.0/16
기본 3632 포트 는 같은 네트워크 의 distcc 연결 을 허용 합 니 다.
그리고 DISTCC 를 설치 해 주세요.HOSTS 환경 변수, 컴 파일 에 참여 할 수 있 는 기기 목록 을 설정 합 니 다.일반적으로 localhost 도 컴 파일 에 참여 하지만 컴 파일 에 참여 할 수 있 는 기계 가 많다 면 localhost 를 이 목록 에서 제거 할 수 있 습 니 다. 그러면 이 기 계 는 완전히 예비 처리, 배포 와 링크 만 하고 컴 파일 은 모두 다른 기계 에서 이 루어 집 니 다.기계 가 많 을 때 localhost 의 처리 부담 이 매우 크기 때문에 더 이상 '아르바이트' 컴 파일 을 하지 않 습 니 다.export DISTCC_HOSTS="localhost 10.64.25.1 10.64.25.2 10.64.25.3"
그리고 ccache 와 유사 하 게 g +, gcc 등 자주 사용 하 는 명령 을 / usr / bin / distcc 에 연결 하면 됩 니 다.
make 를 할 때 도 - j 인 자 를 사용 해 야 합 니 다. 일반적으로 인 자 는 컴 파일 된 컴퓨터 CPU 커 널 총수 의 두 배 를 병행 하 는 작업 수로 사용 할 수 있 습 니 다.
똑 같이 테스트 해 보 세 요:
컴퓨터 한 대, make - j4: 23 분 16 초
쌍 핵 컴퓨터 두 대, make - j4: 16 분 40 초
쌍 핵 컴퓨터 두 대, make - j8: 15 분 49 초
처음에는 쌍 핵 한 대 를 사용 할 때의 23 분 에 비해 훨씬 빨 랐 다.더 많은 컴퓨터 가 가입 하면 더 좋 은 효 과 를 얻 을 수 있다.
컴 파일 과정 에서 distccmon - text 로 컴 파일 작업 의 할당 상황 을 볼 수 있 습 니 다.distcc 도 ccache 와 동시에 사용 할 수 있 습 니 다. 환경 변 수 를 설정 하면 할 수 있 습 니 다. 매우 편리 합 니 다.
요약:
tmpfs: IO 병목 을 해결 하고 본 컴퓨터 의 메모리 자원 을 충분히 이용 합 니 다 make - j: 본 컴퓨터 를 충분히 이용 하여 자원 을 계산 합 니 다 distcc: 여러 대의 컴퓨터 자원 이용 ccache: 같은 코드 를 중복 컴 파일 하 는 시간 감소 이런 도구 들 의 장점 은 모두 배치 의 원가 가 상대 적 으로 낮 고 이런 도 구 를 종합 적 으로 이용 하면 상당 한 시간 을 가볍게 절약 할 수 있다 는 것 이다.위 에서 소개 한 것 은 모두 이 도구 들 의 가장 기본 적 인 용법 이 고 더 많은 용법 은 각자 의 man page 를 참고 할 수 있다.