Kann ich ./configure beschleunigen?

6343
netvope

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 habe das Gefühl, dass es eine enorme Ressourcenverschwendung ist, wenn die verbleibenden elf Kerne die meiste Zeit im Leerlauf sitzen und warten, bis die langsame ./configurePhase abgeschlossen ist. Warum müssen die Tests nacheinander durchgeführt werden? Ist jeder Test voneinander abhängig? Ich kann mich irren, aber es sieht so aus, als ob die Mehrheit von ihnen unabhängig ist.

Was noch wichtiger ist, gibt es Möglichkeiten, um zu beschleunigen ./configure?

Edit: Um die Situation zu veranschaulichen, 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 "Benutzer" und "sys" -Zeiten), dauert es viel länger ("real"), da es nicht parallelisiert wird. Ich habe den Test einige Male wiederholt (wobei die relevanten Dateien wahrscheinlich im Cache-Speicher verbleiben) und die Zeiten innerhalb von 10% liegen.

26
Es ist lächerlich und schade, dass es KEINE guten Build-Tools gibt. Alle existierenden sind nur aufgrund der Trägheit da. Der Bau von Binärdateien ist eine so unübersichtliche und unberechenbare Sache. Matt Joiner vor 13 Jahren 3
Die Tests werden nacheinander durchgeführt, da es ein Albtraum wäre, um herauszufinden, wie Parallelität auf dem jeweiligen System ausgeführt wird, auf dem man läuft. Simon Richter vor 13 Jahren 0

6 Antworten auf die Frage

11
Peter Eisentraut

Ich erinnere mich an Diskussionen auf der Autoconf-Mailingliste zu dieser Ausgabe von vor etwa 10 Jahren, als die meisten Leute tatsächlich nur einen CPU-Kern hatten. Es wurde jedoch nichts getan, und ich habe den Verdacht, dass nichts unternommen wird. Es ist sehr schwierig, alle Abhängigkeiten für die parallele Verarbeitung in festzulegenconfigure, und dies auf tragbare und robuste Weise.

Abhängig von Ihrem speziellen Szenario gibt es möglicherweise einige Möglichkeiten, die Konfigurationsläufe zu beschleunigen. Zum Beispiel:

  • Verwenden Sie eine schnellere Shell. Betrachten Sie beispielsweise die Verwendung dashanstelle von bashals /bin/sh. (Hinweis: Unter Debian dashist ein Patch vorhanden, so dass configurees nicht verwendet wird, da bei Verwendung eine Menge configureSkripts abgebrochen werden.)
  • Wenn Sie Builds remote ausführen (z. B. über ssh), habe ich festgestellt, dass die Konsolenausgabe ziemlich langsam sein kann. Überlegen Sie, anzurufen configure -q.
  • Wenn Sie dasselbe Projekt wiederholt erstellen, sollten Sie die Cachedatei verwenden. Rufen configure -C. Einzelheiten finden Sie in der Autoconf-Dokumentation.
  • Wenn Sie viele verschiedene Projekte erstellen, sollten Sie eine Site-Datei ( config.site) verwenden. Siehe auch die Dokumentation.
  • Erstellen Sie mehrere Projekte parallel.
Könnten Sie bitte etwas näher erläutern, warum "make" parallelisiert werden kann, aber "configure" oder "autoconf" nicht? netvope vor 13 Jahren 2
Anscheinend habe ich mit der Shell einige Leistungsprobleme. Das Ausführen von "sh -c" echo $ i "> / dev / null" dauert 1000 Mal auf diesem System etwa 10 Sekunden, auf meinen anderen Systemen jedoch nur 1-2 Sekunden. netvope vor 13 Jahren 0
GNU make verwendet recht komplizierten C-Code zum Starten und Verwalten mehrerer Prozesse. Konfigurationsskripts werden in einer portablen Bourne-Shell geschrieben. Es wäre möglich, aber wahrscheinlich sehr schwierig. Peter Eisentraut vor 13 Jahren 1
Das Aussortieren der Abhängigkeiten zwischen den "configure" -Tests ist tatsächlich eine Operation mit geringer Komplexität (topologische Sortierung) und wurde in den frühen Tagen des Rechnens gelöst. Das eigentliche Problem ist, dass niemand den Code zu autoconf hinzufügen wollte, und dass viele Programmierer die erzeugten Dateien manuell ändern. Das gesamte System sollte überarbeitet werden, sodass die Konfiguration nicht mehr von einem Shell-Skript, sondern von residenten binären Metadatendateien ausgeführt wird. billc.cn vor 13 Jahren 3
Bitte fügen Sie einen Hinweis auf die erwähnte Diskussion in der Mailingliste hinzu (ein Link zum Archiv). Karl Richter vor 9 Jahren 1
3
Flimzy

Es gibt viele Arten von ./configureSkripten. Es gibt beliebte Tools ( Autconf ist eines davon), die einen Entwickler bei der Erstellung eines ./configureSkripts unterstützen. 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 verwendet werden sind gebaut.

Mir sind keine gängigen ./configureSkripts bekannt, die parallel ausgeführt werden können. Die meisten der von gängigen Tools erstellten Skripts speichern zumindest einige oder alle Ergebnisse zwischen. Wenn Sie sie also erneut ausführen (ohne ein make cleanerstes zu tun ), läuft sie beim zweiten Mal viel schneller.

Das soll nicht heißen, dass es nicht geht ... aber ich vermute, dass die Motivation der Leute, die daran arbeiten autoconf, zum Beispiel gering ist, da die Konfigurationsphase bei den meisten Paketen relativ zur eigentlichen Kompilierung und Verknüpfung sehr schnell ist Phasen.

Es gibt jedoch einen guten Grund, diese Tools zu verwenden: Sie sind ausgereift und verfolgen viele winzige Details. Ich denke, Linux wäre in der Embedded-Welt nicht so gut positioniert, wenn Sie das Skript * configure * nicht einfach auf Ihren Cross-Compiler verweisen und es 90% der Zeit ohne vorherige Ankündigung haben könnten. Simon Richter vor 13 Jahren 2
3
bubu

Sie waren klug bei der Verwendung von ramdrive für den Quellbaum, aber denken Sie zweimal darüber nach - was macht das Konfigurieren? Es erledigt seine Aufgabe, indem es nicht nur Ihren Quellcode überprüft, sondern häufig auch das System auf Verfügbarkeit von Bibliotheken, Compilern usw. In diesem Fall liegt das Zugriffsproblem manchmal im Festplattenzugriff - Sie haben es viel schneller, wenn Sie dies tun Beispiel ein SSD-basiertes Root-Dateisystem.

Leider scheinen SSDs nicht viel zu helfen. Ich habe wiederholt versucht, `. / Configure 'auszuführen, aber nachfolgende Läufe dauern fast so lange wie der erste Lauf. Da im System viel freier Speicherplatz vorhanden ist, werden die Compiler und Bibliotheken aus dem Speichercache heraus ausgeführt, ohne auf die Festplatte zu gehen. netvope vor 13 Jahren 1
Wenn Sie wiederholt versucht haben, ./configure auszuführen (und wenn dies von autoconf gemacht wird), sollten alle Ergebnisse zwischengespeichert sein und sehr gut funktionieren. Sie können das Konfigurationsskript für uns posten, damit Sie nachschauen können, ob Sie weitere Hilfe benötigen. Ich bin mir ziemlich sicher, dass es hier einen Überfluss an Guru gibt bubu vor 13 Jahren 1
Ich habe es tatsächlich zwischen den Läufen aufgeräumt (`. / Configure` läuft immer in einem frisch extrahierten Quellbaum). Ich werde im ursprünglichen Beitrag mehr Details hinzufügen (der Platz ist hier begrenzt). netvope vor 13 Jahren 0
Ich habe gerade getestet, ohne den Ordner aufzuräumen (dh,. / Configure` unmittelbar nach einem anderen `. / Configure`) und die beiden Läufe dauern ungefähr die gleiche Zeit. Bedeutet das, dass das Cachen wahrscheinlich nicht auf meinem System funktioniert? netvope vor 13 Jahren 0
Ich hole Coreutils und versuche zu konfigurieren, wenn ich Zeit habe. Bleib dran. bubu vor 13 Jahren 0
3
Dan Kegel

Wenn Sie den OnDemand-CPU-Regler verwenden, versuchen Sie es mit dem Performance-Controller. Dies hilft beim 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 so machen, dass Sie nicht cpufreq-set für jeden Core machen müssen, aber auf meinen Computern funktioniert es nicht.)

Die Cache-Option hilft jedoch noch mehr.

2
Ярослав Рахматуллин

Die Festplatte ist in diesem Fall der Engpass. Um die Erstellung zu beschleunigen, bauen Sie auf einem System mit schnellen Laufwerken auf (lesen Sie: niedrige Zugriffszeit). Es gibt viel Aufhebens über SSD-Discs, aber es gab Kritik, dass sie die Erstellungszeit nicht positiv beeinflussten. Das heißt, auf SSD zu bauen war nicht viel schneller als auf einem ordentlichen SATA-Laufwerk. Ich kann mich nicht erinnern, wo ich das gelesen habe, weil der Artikel ein paar Jahre alt ist.

Wie auch immer ... Untar von dort zu rammen und 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
Danke, aber ich habe bereits auf / dev / shm kompiliert, was ein tmpfs ist :-) netvope vor 13 Jahren 1
0
Tim Ruehsen rockdaboot

Ihre Frage könnte heute sogar relevanter sein, da wir über Dutzendkern-CPUs mit (ziemlich) niedriger Single-Core-Leistung verfügen. Automatisierte Builds für Continuous Integration (CI) verschwenden bei jedem Commit viel CPU-Zeit / Energie. Gleiches gilt für das Springen zwischen den Zweigen.

Lesen Sie also meine Hinweise zur Beschleunigung der Sache unter https://gitlab.com/gnuwget/wget2/wikis/Developer-hints:-Erwachsen- der Geschwindigkeit-von-GNU- toolchain .

"Warum müssen die Tests nacheinander durchgeführt werden? ..." Es gibt tatsächlich einige Dinge, die parallel durchgeführt werden könnten, während andere sequentiell sein müssen. Die Umgebung hängt von der Build-Umgebung ab. Das configure-Skript selbst ist vom System unabhängig. Es enthält nicht einmal Bashismen, es funktioniert also mit einer reinen POSIX-Shell.

Wenn Sie tragbare Software schreiben möchten, gibt es kein anderes Build-System wie Autotools. Wenn Sie sich jedoch nicht für die (breite) Portabilität interessieren, sollten Sie auf Autotools verzichten - es gibt eine Unmenge an schnellen und ausreichend geeigneten Build-Tools.

Verwandte Probleme