Kann man ./configure beschleunigen?

Um ein Softwarepaket auf einer Workstation mit vielen CPU - Kerne (etwa 12) zu kompilieren, nimmt die Konfigurationsphase oft viel länger als die eigentlichen Übersetzungsstufe , weil ./configuredie Tests tut eins nach dem anderen, während make -jLäufe gccsowie andere Befehle parallel.

Ich halte es für eine enorme Verschwendung von Ressourcen, wenn die verbleibenden 11 Kerne die meiste Zeit im Leerlauf sitzen und darauf warten, dass die langsame ./configureAusführung abgeschlossen ist. Warum müssen die Tests nacheinander durchgeführt werden? Hängt jeder Test voneinander ab? Ich kann mich irren, aber es sieht so aus, als wären die meisten von ihnen unabhängig.

Was noch wichtiger ist: Gibt es Möglichkeiten zur Beschleunigung ./configure?

Bearbeiten: Um die Situation zu veranschaulichen, ist hier ein Beispiel mit 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

Ergebnisse:

# 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

Mit coreutils-8,9 , ./configuredauert 6 - mal länger als make. Obwohl ./configureweniger CPU-Zeit benötigt wird (siehe "user" & "sys" -Zeiten), dauert es viel länger ("real"), da es nicht parallelisiert ist. Ich habe den Test einige Male wiederholt (wobei die relevanten Dateien wahrscheinlich im Speichercache verbleiben) und die Zeiten liegen innerhalb von 10%.

Ich erinnere mich an Diskussionen auf der Autoconf-Mailingliste zu diesem Thema vor ungefähr 10 Jahren, als die meisten Leute tatsächlich nur einen CPU-Kern hatten. Aber es wurde nichts getan, und ich vermute, es wird nichts getan. Es wäre sehr schwierig, alle Abhängigkeiten für die Parallelverarbeitung configurein einer portablen und robusten Weise einzurichten .

Abhängig von Ihrem speziellen Szenario gibt es ohnehin einige Möglichkeiten, die Konfigurationsläufe zu beschleunigen. Beispielsweise:

• Verwenden Sie eine schnellere Shell. Verwenden Sie beispielsweise dashanstelle von bashas /bin/sh. (Hinweis: Unter Debian dashist es so gepatcht, dass configurees nicht verwendet wird, da es viele configureSkripte kaputt macht .)
• Wenn Sie Builds aus der Ferne ausführen (z. B. über ssh), kann die Konsolenausgabe sehr langsam sein. Erwägen Sie einen Anruf configure -q.
• Wenn Sie dasselbe Projekt wiederholt erstellen, sollten Sie die Verwendung einer Cachedatei in Betracht ziehen. Rufen Sie an configure -C. Weitere Informationen finden Sie in der Autoconf-Dokumentation.
• Wenn Sie viele verschiedene Projekte erstellen, sollten Sie eine Site-Datei ( config.site) verwenden. Siehe auch hier die Dokumentation.
• Erstellen Sie mehrere Projekte gleichzeitig.

Sie haben Ramdrive geschickt eingesetzt, damit sich der Sourcebaum darin befindet, aber überlegen Sie es sich zweimal - was macht configure? Es erledigt seine Aufgabe, indem es nicht nur Ihren Sourcebaum , sondern häufig auch das System auf Verfügbarkeit von Bibliotheken, Compilern usw. überprüft . In diesem Fall liegt das Zugriffsproblem manchmal im Festplattenzugriff Beispiel ein SSD-basiertes Root-Dateisystem.

Wenn Sie den ondemand-CPU-Governor verwenden, versuchen Sie es mit dem Performance-Governor. Dies hilft auf dem i7 und a8-3850 um 40-50%. Macht beim q9300 keinen großen Unterschied.

Auf einer Quad-Core-CPU könnten Sie dies tun

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

(Die Option -r sollte es schaffen, damit Sie cpufreq-set nicht für jeden Kern ausführen müssen, aber auf meinen Computern funktioniert es nicht.)

Die Cache-Option hilft jedoch noch mehr.

Es gibt viele Arten von ./configureSkripten. Es gibt beliebte Tools ( darunter auch autconf ), mit denen ein Entwickler ein ./configureSkript erstellen kann. Es gibt jedoch keine Regel, die besagt, dass jeder Entwickler diese Tools verwenden muss, und selbst unter diesen Tools kann es große Unterschiede in der Art und Weise geben, in der diese Skripts erstellt werden aufgebaut sind.

Mir sind keine gängigen ./configureSkripte bekannt, die parallel ausgeführt werden können. Bei den meisten Skripten, die mit gängigen Tools erstellt wurden, werden zumindest einige oder alle Ergebnisse zwischengespeichert. Wenn Sie sie also erneut ausführen ( make cleanjedenfalls ohne eine erste), wird sie beim zweiten Mal viel schneller ausgeführt.

Das heißt nicht, dass dies nicht möglich war ... aber ich vermute, dass die Leute, die daran arbeiten autoconf, wenig Motivation dazu haben, da die Konfigurationsphase für die meisten Pakete im Vergleich zur tatsächlichen Kompilierung und Verknüpfung sehr schnell ist Phasen.

Die Festplatte ist in diesem Fall der Engpass. Um den Build zu beschleunigen, bauen Sie auf einem System mit schnellen Laufwerken auf (lesen Sie: niedrige Zugriffszeit). Es gibt viel Aufhebens um SSD-Discs, aber es gab einige Kritik daran, dass sie die Kompilierungszeit nicht positiv beeinflussen. Das heißt, das Bauen auf SSD war nicht so viel schneller als auf einem anständigen SATA-Laufwerk. Ich kann mich nicht erinnern, wo ich das gelesen habe, da der Artikel ein paar Jahre alt ist.

Sowieso ... Untar zu rammen und von dort aus zu bauen.

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

Ihre Frage könnte heute noch relevanter sein, da wir Dutzende von Core-CPUs mit (ziemlich) geringer Single-Core-Leistung haben. Automatisierte Builds für Continuous Integration (CI) verschwenden bei jedem Commit viel CPU-Zeit und Energie. Gleiches gilt für das Hüpfen zwischen Zweigen.

Lesen Sie meine Tipps zur Beschleunigung des Vorgangs unter https://gitlab.com/gnuwget/wget2/wikis/Developer-hints:-Increaseing-speed-of-GNU-toolchain .

"Warum müssen die Tests nacheinander durchgeführt werden? ..." Tatsächlich gibt es einige Dinge, die parallel ausgeführt werden könnten, während andere nacheinander ausgeführt werden müssen. Einige Dinge hängen von der Build-Umgebung ab - und das Konfigurationsskript selbst ist systemunabhängig. Es enthält nicht einmal Bashismen und funktioniert daher mit einer reinen POSIX-Shell.

Wenn Sie tragbare Software schreiben möchten, gibt es kein anderes Build-System wie Autotools. Wenn Ihnen die (breite) Portabilität nichts ausmacht, sollten Sie auf Autotools verzichten - es gibt eine Fülle schneller und ausreichend guter Build-Tools.