./configure 속도를 높일 수 있습니까?

많은 CPU 코어가있는 워크 스테이션에서 소프트웨어 패키지를 컴파일하려면 (예 : 12) 구성 단계는 실제 컴파일 단계보다 훨씬 오래 걸립니다 ./configure. 테스트는 하나씩 수행 하고 다른 명령은 병렬로 make -j실행 하기 때문 gcc입니다.

나머지 11 개의 코어가 느리게 ./configure완료 되기를 기다리는 대부분의 시간 동안 유휴 상태로 유지하는 것은 엄청난 자원 낭비라고 생각합니다 . 테스트를 순차적으로 수행해야하는 이유는 무엇입니까? 각 테스트는 서로 의존합니까? 나는 착각 할 수 있지만 대부분 독립 한 것처럼 보입니다.

더 중요한 것은 속도를 높일 수있는 방법이 ./configure있습니까?

편집 : 상황을 설명하기 위해 GNU Coreutils 의 예가 있습니다.

cd /dev/shm
rm -rf coreutils-8.9
tar -xzf coreutils-8.9.tar.gz
cd coreutils-8.9
time ./configure
time make -j24

결과 :

# For `time ./configure`
real    4m39.662s
user    0m26.670s
sys     4m30.495s
# For `time make -j24`
real    0m42.085s
user    2m35.113s
sys     6m15.050s

로 로 coreutils-8.9 , ./configure6 시간 이상 소요됩니다 make. ./configureCPU 시간을 적게 사용 하지만 ( "사용자"및 "sys"시간보기) 병렬화되지 않기 때문에 훨씬 더 오래 걸립니다 ( "실제"). 테스트를 몇 번 반복하고 (관련 파일이 메모리 캐시에있을 수 있음) 시간은 10 % 이내입니다.

대부분의 사람들이 실제로 하나의 CPU 코어 만 가지고 있었던 약 10 년 전부터이 문제에 대한 Autoconf 메일 링리스트에 대한 토론을 기억합니다. 그러나 아무것도 한 적이 없으며, 아무 일도 일어나지 않을 것 같습니다. 에서 병렬 처리에 대한 모든 종속성을 설정하고 configure이식 가능하고 강력한 방식으로 수행하는 것은 매우 어렵습니다 .

특정 시나리오에 따라 어쨌든 구성 실행 속도를 높이는 몇 가지 방법이있을 수 있습니다. 예를 들면 다음과 같습니다.

• 더 빠른 껍질을 사용하십시오. 예를 들어 as dash대신 사용 을 고려하십시오 . (참고 : 데비안에서는 패치를 사용하므로 많은 스크립트 가 깨지기 때문에 사용하지 않습니다 .)bash/bin/shdashconfigureconfigure
• 예를 들어 ssh를 통해 원격으로 빌드를 실행하면 콘솔 출력이 상당히 느릴 수 있습니다. 전화를 고려하십시오 configure -q.
• 동일한 프로젝트를 반복해서 빌드하는 경우 캐시 파일 사용을 고려하십시오. 전화하십시오 configure -C. 자세한 내용은 Autoconf 설명서를 참조하십시오.
• 많은 다른 프로젝트를 빌드하는 경우 사이트 파일 ( config.site) 사용을 고려하십시오 . 다시, 설명서를 참조하십시오.
• 여러 프로젝트를 병렬로 빌드하십시오.

소스 트리에 상주하기 위해 ramdrive를 사용하는 것이 현명했지만, 두 번 생각하십시오. configure는 무엇을합니까? 소스 트리 뿐만 아니라 라이브러리, 컴파일러 등의 가용성에 대한 시스템 을 검사하여 작업을 수행합니다 .이 경우 액세스 문제가 디스크 액세스에 가끔 있습니다. 예를 들어 SSD 기반 루트 파일 시스템.

온 디맨드 CPU 거버너를 사용하는 경우 성능을 높여보십시오. 이것은 i7과 a8-3850에 40-50 % 도움이됩니다. q9300에는 큰 차이가 없습니다.

쿼드 코어 CPU에서는

for cpu in `seq 0 3`; do sudo cpufreq-set -g performance -c $cpu; done

(-r 옵션을 사용하면 각 코어에 대해 cpufreq-set을 수행하지 않아도되지만 내 컴퓨터에서는 작동하지 않습니다.)

캐시 옵션은 더 많은 도움이됩니다.

많은 유형의 ./configure스크립트가 있습니다. 스크립트 작성시 개발자를 지원하기 위해 널리 사용되는 도구 ( utconf 중 하나임)가 ./configure있지만 모든 개발자가이 도구를 사용해야한다는 규칙은 없습니다. 건설됩니다.

./configure병렬로 실행할 수 있는 인기있는 스크립트를 알지 못합니다 . 널리 사용되는 도구로 작성된 대부분의 스크립트는 최소한 일부 또는 모든 결과를 캐시하므로 make clean처음 다시 실행하지 않고 다시 실행하면 두 번째로 훨씬 빠르게 실행됩니다.

그것은 할 수 없다고 말할 수는 없지만 ... autoconf예를 들어 작업하는 사람들에게는 동기 부여가 거의 없다고 생각 합니다. 대부분의 패키지의 경우 구성 단계가 실제 컴파일 및 링크에 비해 매우 빠르기 때문입니다. 단계.

이 경우 하드 드라이브가 병목 현상입니다. 빌드 속도를 높이려면 빠른 드라이브 (읽기 : 낮은 액세스 시간)가있는 시스템을 빌드하십시오. SSD 디스크에 대한 많은 소란이 있지만, 긍정적 인 방식으로 컴파일 시간에 영향을 미치지 않는 비판이있었습니다. 즉, SSD를 구축하는 것이 괜찮은 sata 드라이브보다 훨씬 빠르지는 않습니다. 기사가 몇 살이 기 때문에이 글을 읽은 곳을 기억할 수 없습니다.

어쨌든 .. 램을 타서 거기에서 짓다.

mkdir /tmp/tmp 
mount -t tmpfs -o size=400M tmpfs /tmp/tmp 
cd /tmp/tmp
tar xjf somesourcetarball-1.1.33.tar.bz2

단일 코어 성능이 매우 낮은 수십 개의 CPU가 있으므로 오늘날 귀하의 질문은 더 관련성이 있습니다. CI (Continuous Integration)를위한 자동화 된 빌드는 모든 커밋마다 많은 CPU 시간 / 에너지를 낭비합니다. 가지 사이를 호핑하는 것과 같습니다.

따라서 https://gitlab.com/gnuwget/wget2/wikis/Developer-hints:-Increasing-speed-of-GNU-toolchain 에서 속도를 높이는 방법에 대한 힌트를 검토 하십시오 .

"테스트를 순차적으로 수행해야하는 이유는 무엇입니까? ..."실제로 병렬로 수행 할 수있는 몇 가지가 있지만 다른 것들은 순차적이어야합니다. 빌드 환경에 따라 몇 가지 사항이 있으며 구성 스크립트 자체는 시스템과 무관합니다. bashism도 포함하지 않으므로 순수한 POSIX 셸과 함께 작동합니다.

휴대용 소프트웨어를 작성하려면 autotools와 같은 다른 빌드 시스템이 없습니다. 그러나 (넓은) 이식성에 신경 쓰지 않는다면 autotools를 피하십시오-빠르고 좋은 빌드 도구가 많이 있습니다.