È possibile velocizzare ./configure?

29

Per compilare un pacchetto software su una workstation con molti core della CPU (diciamo 12), la fase di configurazione spesso richiede molto più tempo della fase di compilazione effettiva perché ./configureesegue i test uno per uno, mentre make -jesegue gccin parallelo altri comandi.

Sento che è un enorme spreco di risorse avere gli 11 core rimanenti inattivi la maggior parte del tempo in attesa del ./configurecompletamento del rallentamento . Perché deve eseguire i test in sequenza? Ogni test dipende l'uno dall'altro? Posso sbagliarmi, ma sembra che la maggior parte di loro sia indipendente.

Ancora più importante, ci sono modi per accelerare ./configure?

Modifica: per illustrare la situazione, ecco un esempio con 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

risultati:

# 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

Con coreutils-8.9 , ci ./configurevuole 6 volte di più di make. Sebbene ./configureusi meno tempo della CPU (guarda i tempi "utente" e "sys"), ci vuole molto più tempo ("reale") perché non è parallelizzato. Ho ripetuto il test alcune volte (con i file pertinenti probabilmente presenti nella cache di memoria) e i tempi sono entro il 10%.

— netvope
fonte

4

È ridicolo, e un peccato, che NON ci siano buoni strumenti di costruzione. Tutti quelli che esistono sono lì per pura inerzia. Costruire binari è una cosa così complicata e imprevedibile.

— Matt Joiner,

Esegue i test in sequenza perché sarebbe un incubo scoprire come fare il parallelismo sul sistema particolare su cui si sta eseguendo.

— Simon Richter,

13

Ricordo le discussioni sulla mailing list di Autoconf su questo problema di circa 10 anni fa, quando la maggior parte delle persone aveva effettivamente un solo core CPU. Ma nulla è stato fatto e sospetto che non sarà fatto nulla. Sarebbe molto difficile impostare tutte le dipendenze per l'elaborazione parallela configuree farlo in modo portatile e robusto.

A seconda del tuo particolare scenario, potrebbero esserci comunque alcuni modi per velocizzare le esecuzioni di configurazione. Per esempio:

Usa una shell più veloce. Ad esempio, considera di utilizzare dashinvece di bashcome /bin/sh. (Nota: sotto Debian, dashè patchato in modo che configurenon lo usi, perché usarlo rompe molti configurescript.)
Se esegui build in remoto (tramite ssh, ad esempio), ho scoperto che l'output della console può essere piuttosto lento. Valuta di chiamare configure -q.
Se costruisci ripetutamente lo stesso progetto, considera l'utilizzo del file cache. Chiama configure -C. Vedere la documentazione di Autoconf per i dettagli.
Se costruisci molti progetti diversi, considera l'utilizzo di un file del sito ( config.site). Ancora una volta, consultare la documentazione.
Costruisci diversi progetti in parallelo.

— Peter Eisentraut
fonte

2

Potrebbe spiegare un po 'di più il motivo per cui makepuò essere parallelized ma configureo autoconfnon ci riesce?

— netvope,

Sembra che io abbia dei problemi di prestazioni con la shell. L'esecuzione di sh -c "echo $i" > /dev/null1000 volte richiede circa 10 secondi su questo sistema, ma solo 1-2 secondi sui miei altri sistemi.

— netvope,

1

GNU make utilizza un codice C piuttosto complicato per l'avvio e la gestione di più processi. gli script di configurazione sono scritti nella shell Bourne portatile. Sarebbe possibile, ma probabilmente molto difficile.

— Peter Eisentraut,

4

L'ordinamento delle dipendenze tra i configuretest è in realtà un'operazione a bassa complessità (ordinamento topologico) ed è stato risolto nei primi giorni dell'informatica. Il vero problema è che nessuno si è preoccupato di aggiungere il codice ad autoconf per farlo e il fatto che molti programmatori modificano manualmente i file generati. L'intero sistema dovrebbe essere rinnovato in modo tale che la configurazione non venga più eseguita da uno script di shell ma da un binario residente che legge i file di metadati.

— billc.cn,

1

Aggiungi un riferimento alla discussione menzionata sulla mailing list (un link all'archivio).

— Karl Richter,

3

Sei stato intelligente nell'usare ramdrive per far risiedere la sourcetree, ma pensaci due volte: cosa fa la configurazione? Fa il suo lavoro controllando non solo il codice sorgente , ma abbastanza spesso anche il sistema per la disponibilità di librerie, compilatori, ecc. In questo caso, il problema di accesso a volte risiede nell'accesso al disco - Avrai fatto molto più veloce se hai per esempio un file system root basato su SSD.

— bubu
fonte

1

Sfortunatamente, gli SSD non aiuteranno molto. Ho provato a correre ./configureripetutamente ma le corse successive impiegano quasi il tempo della prima corsa. Dal momento che c'è molta memoria libera nel sistema, penso che il sistema stia eseguendo compilatori e librerie dalla cache di memoria senza andare sul disco.

— netvope,

1

se hai provato a eseguire ripetutamente ./configure (e se è stato creato da autoconf) dovrebbe avere tutti i risultati memorizzati nella cache e dovrebbe andare molto bene. Puoi pubblicare lo script di configurazione per consentirci di dare un'occhiata se desideri ulteriore aiuto. Sono abbastanza sicuro che ci sia abbondanza di guru qui

— bubu,

In realtà l'ho pulito tra le esecuzioni ( ./configureè sempre in esecuzione in un albero dei sorgenti appena estratto). Aggiungerò ulteriori dettagli nel post originale (lo spazio è limitato qui).

— netvope,

Ho appena testato senza ripulire la cartella (ovvero correre ./configureimmediatamente dopo l'altro ./configure) e le due esecuzioni richiedono circa lo stesso tempo. Vuol dire che la cache non funziona probabilmente sul mio sistema?

— netvope,

Prenderò coreutils e proverò a configurare quando avrò tempo. Rimanete sintonizzati.

— bubu,

3

Se stai usando il governatore ondemand cpu, prova a usare quello delle prestazioni. Questo aiuta su i7 e a8-3850 del 40-50%. Non fa molta differenza sul q9300.

Su una CPU quad core, potresti farlo

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

(L'opzione -r dovrebbe renderlo tale da non dover fare cpufreq-set per ogni core, ma sui miei computer non funziona.)

L'opzione cache aiuta ancora di più, però.

— Dan Kegel
fonte

3

Esistono molti tipi di ./configurescript. Esistono strumenti popolari ( essendo autconf uno di questi) per aiutare uno sviluppatore a creare un./configure script, ma non esiste una regola che dice che ogni sviluppatore deve usare questi strumenti, e quindi anche tra questi strumenti, ci possono essere ampie variazioni nel modo in cui questi script sono costruiti.

Non sono a conoscenza di ./configurescript popolari che possono essere eseguiti in parallelo. La maggior parte degli script creati dagli strumenti più diffusi memorizza almeno alcuni o tutti i risultati nella cache, quindi se lo esegui di nuovo (senza fare un make cleanprimo, comunque), verrà eseguito molto più velocemente la seconda volta.

Questo non vuol dire che non si possa fare ... ma ho il sospetto che ci sia poca motivazione per le persone che lavorano autoconf, per esempio, a farlo, poiché per la maggior parte dei pacchetti, la fase di configurazione è molto rapida rispetto alla compilazione e al collegamento effettivi fasi.

— flimzy
fonte

2

C'è una buona ragione per usare questi strumenti: sono maturi e tengono traccia di molti piccoli dettagli. Penso che Linux non sarebbe in una posizione così eccezionale nel mondo embedded se non potessi semplicemente indirizzare lo script di configurazione sul tuo compilatore incrociato e farlo funzionare immediatamente 90% delle volte.

— Simon Richter,

2

Il disco rigido è il collo di bottiglia in questo caso. Per accelerare la generazione, costruisci su un sistema con unità veloci (leggi: tempo di accesso ridotto). C'è un sacco di confusione sui dischi SSD, ma ci sono state alcune critiche riguardo al fatto che non influenzano il tempo di compilazione in modo positivo. Vale a dire che costruire su SSD non è stato molto più veloce che su un discreto disco SATA. Non ricordo dove ho letto questo perché l'articolo ha un paio d'anni.

Comunque ... Untar per speronare e costruire da lì.

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

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

1

Grazie, ma stavo già compilando / dev / shm che è un tmpfs :-)

— netvope,

0

La tua domanda potrebbe essere ancora più rilevante oggi poiché abbiamo una dozzina di CPU core con (piuttosto) basse prestazioni single core. Le build automatizzate per l'integrazione continua (CI) sprecano davvero molto tempo / energia della CPU per ogni commit. Lo stesso con il salto tra i rami.

Quindi rivedi / leggi i miei suggerimenti su come accelerare la cosa su https://gitlab.com/gnuwget/wget2/wikis/Developer-hints:-Increasing-speed-of-GNU-toolchain .

"Perché è necessario eseguire i test in sequenza? ..." Ci sono in effetti alcune cose che potrebbero essere fatte in parallelo, mentre altre devono essere sequenziali. Diverse cose dipendono dall'ambiente di compilazione e lo script configure stesso è indipendente dal sistema. Non contiene nemmeno bashismi, quindi funziona con una shell POSIX pura.

Se vuoi scrivere un software portatile, non esiste nessun altro sistema di compilazione come gli autotools. Ma se non ti dispiace per la (ampia) portabilità, evita gli autotools - c'è una pletora di strumenti di costruzione veloci e abbastanza buoni.

— Tim Ruehsen rockdaboot
fonte