Kann man ./configure beschleunigen?

29

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%.

netvope
quelle
4
Es ist lächerlich und schade, dass es KEINE guten Build-Tools gibt. Alle diejenigen, die existieren, sind nur aufgrund der Trägheit da. Das Erstellen von Binärdateien ist so eine fummelige, unvorhersehbare Sache.
Matt Joiner
Die Tests werden nacheinander ausgeführt, da es ein Albtraum wäre, herauszufinden, wie Parallelität auf dem jeweiligen System durchgeführt werden kann, auf dem sie ausgeführt werden.
Simon Richter

Antworten:

13

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.
Peter Eisentraut
quelle
2
Könnten Sie bitte etwas näher erläutern, warum makeparallelisiert werden kann configureoder autoconfnicht?
Netvope
Anscheinend habe ich einige Leistungsprobleme mit der Shell. Das sh -c "echo $i" > /dev/null1000-fache Ausführen dauert auf diesem System ungefähr 10 Sekunden, auf meinen anderen Systemen jedoch nur 1-2 Sekunden.
Netvope
1
GNU make verwendet ziemlich komplizierten C-Code zum Starten und Verwalten mehrerer Prozesse. Konfigurationsskripte werden in einer portablen Bourne-Shell geschrieben. Es wäre möglich, aber wahrscheinlich sehr schwierig.
Peter Eisentraut
4
Das Aussortieren der Abhängigkeiten zwischen den configureTests ist eigentlich eine Operation mit geringer Komplexität (topologische Sortierung) und wurde in den frühen Tagen des Rechnens gelöst. Das eigentliche Problem ist, dass sich niemand die Mühe gemacht hat, den Code zu autoconf hinzuzufügen, und dass viele Programmierer die generierten Dateien manuell ändern. Das gesamte System sollte überarbeitet werden, damit die Konfiguration nicht mehr über ein Shell-Skript, sondern über eine residente Binärdatei zum Lesen von Metadatendateien erfolgt.
billc.cn
1
Bitte fügen Sie einen Verweis auf die erwähnte Diskussion in der Mailingliste hinzu (einen Link zum Archiv).
Karl Richter
3

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.

bubu
quelle
1
Leider scheinen SSDs nicht viel zu helfen. Ich habe ./configurewiederholt versucht zu laufen, aber nachfolgende Läufe dauern fast so lange wie der erste Lauf. Da im System viel freier Speicher vorhanden ist, werden auf dem System die Compiler und Bibliotheken aus dem Speichercache ausgeführt, ohne auf die Festplatte zuzugreifen.
Netvope
1
Wenn Sie versucht haben, ./configure wiederholt auszuführen (und wenn es von autoconf erstellt wurde), sollten alle Ergebnisse zwischengespeichert sein und sehr gut funktionieren. Sie können das Konfigurationsskript posten, damit wir es uns ansehen können, wenn Sie weitere Hilfe benötigen. Ich bin mir ziemlich sicher, dass es hier eine Fülle von Guru gibt
Bubu
Ich habe es tatsächlich zwischen den Läufen aufgeräumt ( ./configureläuft immer in einem frisch extrahierten Source-Tree). Ich werde im Originalbeitrag weitere Details hinzufügen (hier ist der Platz begrenzt).
Netvope
Ich habe gerade getestet, ohne den Ordner zu bereinigen (dh ./configureunmittelbar nacheinander auszuführen ./configure), und die beiden Durchläufe dauern ungefähr die gleiche Zeit. Bedeutet das, dass Caching auf meinem System wahrscheinlich nicht funktioniert?
Netvope
Ich werde Coreutils holen und versuchen, zu konfigurieren, wenn ich Zeit habe. Bleib dran.
Bubu
3

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.

Dan Kegel
quelle
3

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.

Fadenscheinig
quelle
2
Es gibt jedoch einen guten Grund, diese Tools zu verwenden: Sie sind ausgereift und behalten viele der winzigen Details im Auge. Ich denke, Linux wäre in der Embedded-Welt nicht so gut positioniert, wenn Sie das configure- Skript nicht einfach auf Ihren Cross-Compiler verweisen könnten und es zu 90% sofort funktionieren würde.
Simon Richter
2

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
Ярослав Рахматуллин
quelle
1
Danke, aber ich habe bereits auf / dev / shm kompiliert, was ein tmpfs ist :-)
netvope 18.06.11
0

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.

Tim Ruehsen rockdaboot
quelle