Minimizzare tempi di compilazione/ricompilazione

[joe]

Ultimamente mi sono trovato a costruirmi alcuni pacchetti partendo dai sorgenti e sfruttando degli slackbuild.
Purtroppo non ho un pc recente e ho dovuto fare i conti con i ritmi di un vecchio Mobile-P4-3.2GHz.

L'altro giorno per esempio mi sono cimentato nella compilazione di MPlayer e visto che alla prima non è riuscita, ho dovuto tentare più volte la compilazione modificando opportunamente lo slackbuild. Inutile dire che i tempi sono stati veramente inaccettabili.

Mi chiedevo se vi fosse qualche accorgimento o "trucco" per migliorare le prestazioni in fase di compilazione.

Tanto per dare un'idea, ricordo parecchio tempo fa una lettura relativa a gentoo in cui si parlava di una specie di cache in grado di interventre in qualche modo durante la seconda e successive ricompilazioni di un certo software. Se ricordo bene, ma è passato parecchio tempo...

Avete qualche considerazione da fare in merito agli eventuali accorgimenti che possono migliorare i tempi di compilazione del software anche su CPU vecchie?
Quali altri parametri sono incisivi a livello hardware? (ram.. velocità hd ? e in che misura rispetto alla capacita di calcolo della cpu? trascurabili oppure no?).

[sardylan]

Se riparti da zero con la compilazione non penso che puoi velocizzare...
L'unica cosa che si può fare è fare delle prove con i cflags... Alcuni compilano più in fretta di altri.
Ma occhio a quello che fai... Velocizzare la compilazione per poi avere un binario più pesante secondo me non ha senso...
Conviene che ottimizzi invece la compilazione per quella macchina, costi il tempo che costi, e poi alla fine hai un programma più stabile, e meno oneroso di risorse (sarà anche di poco, ma è sempre meglio)...
Tanto non stai li a frugare mentre compila... Lo lasci lavorare e via...

[414N]

Mi chiedevo se vi fosse qualche accorgimento o "trucco" per migliorare le prestazioni in fase di compilazione.

Il problema delle ricompilazioni "a tentativi" è che, se le fai tramite SlackBuild, solitamente questi va a cancellare ad ogni lancio la directory di lavoro dove erano stati estratti i sorgenti la volta precedente, insieme a tutti i file oggetto compilati fino a quel momento. È per questo che con mplayer hai ricominciato da capo ogni volta.
Per poter fermare la compilazione, fare qualche modifica (flag per il configure, variabili d'ambiente ecc.) e poi ripartire più o meno da dove si era fermato il lavoro è necessario tenere i file oggetto; tuttavia, questo potrebbe non bastare se si vanno a cambiare opzioni basilari della compilazione (ad esempio i CFLAGS).
A volte mi è successo di essere alle prese con la creazione/modifica di uno SlackBuild con una compilazione piuttosto "impegnativa" e di vedermi interrotto il processo di creazione del pacchetto tramite SlackBuild per un qualche errore subito dopo la compilazione e prima della effettiva creazione del pacchetto. In quei casi, per non perdere il compilato, ho commentato tutte le righe "distruttive" nello SlackBuild (cancellazione directory temporanea, estrazione sorgenti, cambio permessi, configure ecc...), corretto quel che c'era da correggere e rilanciato lo script, ripetendo questa procedura finché non arrivavo al pacchetto come lo volevo. Ovviamente, una volta appurato che, nel complesso, lo SlackBuild funziona, ho poi decommentato quanto avevo commentato in precedenza.
Un'altra accortezza che può essere utile è di non usare flag di ottimizzazione del compilato (per esempio -O2) in fase di prove:

Without any optimization option, the compiler's goal is to reduce the cost of
compilation and to make debugging produce the expected results. Statements are
independent: if you stop the program with a breakpoint between statements, you can
then assign a new value to any variable or change the program counter to any other
statement in the function and get exactly the results you would expect from the
source code.

Turning on optimization flags makes the compiler attempt to improve the performance
and/or code size at the expense of compilation time and possibly the ability to
debug the program.

[...]
-O0 Reduce compilation time and make debugging produce the expected results. This
is the default.
[...]

Come puoi leggere nel man di gcc, il compilatore tende a ridurre al minimo il tempo di compilazione già di suo. Questo ovviamente lo paghi con eseguibili più ingombranti e dotati di simboli per il debugging, ma perfetti per capire se si arriva in fondo alla compilazione come si vuole o no.
Per usare quest'accortezza agevolmente con gli SlackBuild, potresti sostituire il flag O2 per la tua ARCH con O0, in modo da forzare il comportamento di default di gcc.
Se hai a disposizione altri pc collegati in rete, puoi anche pensare di usare programmi per la compilazione parallela, come icecream o distcc, per distribuire i job di compilazione su più macchine.

[joe]

Più o meno ho capito.
Quindi la storia di ccache non è inerente all'esempio di mplayer...

Dal canto mio penso che forse un piccolo incremento di prestazioni sia ottenibile spegnendo il server grafico X e lanciando la compilazione in tty1 per esempio. Io l'ho fatto compilando all'interno di una sessione "screen" mandata in background e appunto spegnendo X e altri software che potessero occupare inutilmente cpu..
Francamente non so quanto incida, a me la compilazione di mplayer impiega veramente troppo... non ho cronometrato ma sicuramente più di un'ora.

E il kernel... io sto usando quello di default non riconfigurato/ricompilato quindi, si potrebbe assistere ad un incisivo miglioramento compilando su un sistema ch eusa un kernel maggiormente ottimizzato?

[414N]

Più o meno ho capito.
Quindi la storia di ccache non è inerente all'esempio di mplayer...

Non ho mai usato ccache e non so come funzioni di preciso, ma se tiene una cache di tutte le compilazioni che effettui sulla tua macchina può aiutare non poco. Bisogna poi vedere quanto diventa grande la cache e se funziona effettivamente così...

Dal canto mio penso che forse un piccolo incremento di prestazioni sia ottenibile spegnendo il server grafico X e lanciando la compilazione in tty1 per esempio. Io l'ho fatto compilando all'interno di una sessione "screen" mandata in background e appunto spegnendo X e altri software che potessero occupare inutilmente cpu..
Francamente non so quanto incida, a me la compilazione di mplayer impiega veramente troppo... non ho cronometrato ma sicuramente più di un'ora.

Credo che X incida piuttosto poco, anche se meno processi hai in esecuzione, più tempo il processore può essere dedicato alla compilazione.

E il kernel... io sto usando quello di default non riconfigurato/ricompilato quindi, si potrebbe assistere ad un incisivo miglioramento compilando su un sistema ch eusa un kernel maggiormente ottimizzato?

Non credo. A livello kernel, quello che gioca a favore del tempo di compilazione può essere la scelta di uno scheduler piuttosto di un altro, ma hai già a disposizione il meccanismo della "niceness" per alterare la priorità di un processo senza dover ricompilare nulla.
Qualche incremento potresti forse ottenerlo ricompilando tutta la compiler suite (gcc, glibc ecc.) con ottimizzazioni spinte e specifiche per il tuo processore. Ma se impieghi tanto con mplayer, con questi programmi impiegherai ancora di più...

[erio]

aspetti il 2.6.38 e la patch di Galbraith,poi dai i make a -j32,e puoi fare anche altro,almeno con il port del 2.6.36 era cosi.

[414N]

aspetti il 2.6.38 e la patch di Galbraith,poi dai i make a -j32,e puoi fare anche altro,almeno con il port del 2.6.36 era cosi.

Il processore resta sempre 1 anche aggiornando il kernel. Quella patch serve solo a migliorare la latenza percepita da un utente desktop in caso di tanti job in esecuzione. Non rende più veloce la compilazione creando un numero spropositato di job paralleli.

[albatrosla]

Quando compili programmi i cui sorgenti richiedono un certo spazio, ti trovi nella situazione in cui il disco ed i tempi di accesso al fs fanno da collo di bottiglia. Perciò tutte le operazioni che la macchina esegue sul disco rallentano potenzialmente la compilazione (non nel senso stretto del termine: il mero tempo di compilazione è lo stesso, ma se dai un bel time in testa al make ti rendi conto che "real time" > "user time + sys time") e possono farlo di tanto (compilando il kernel, mplayer, firefox e cose del genere è una cosa che si nota). Un trucco per "risolvere" il problema, che torna utile se la directory dei sorgenti è "a perdere" o se si pensa di doverci riprovare un po' di volte, è quello di copiare i sorgenti e compilare tutto in tmpfs o comunque su un ramdisk. I tempi di accesso alla ram sono molto inferiori di quelli di accesso al disco, e non c'è il problema di operazioni concorrenti che vengano eseguite sul device. Potendo disporre di quantitativi di ram sufficienti, è una via da prendere seriamente in considerazione.

[targzeta]

...Un trucco per "risolvere" il problema, che torna utile se la directory dei sorgenti è "a perdere" o se si pensa di doverci riprovare un po' di volte, è quello di copiare i sorgenti e compilare tutto in tmpfs o comunque su un ramdisk. I tempi di accesso alla ram sono molto inferiori di quelli di accesso al disco, e non c'è il problema di operazioni concorrenti che vengano eseguite sul device. Potendo disporre di quantitativi di ram sufficienti, è una via da prendere seriamente in considerazione.

Ma lo sai che non ci avevo mai pensato? Anche se dal risultato che ti posto non sembra esserci molta differenza (ma un esempio non è significativo) ho deciso di mettere la directory /tmp in tmpfs, anche perché:

• Generalmente ogni settimana compilo molti programmi di cui seguo il ramo current.
• Ho 2GB di memoria di cui me ne resta più o meno sempre 1 libero.

Ecco il risultato di un esempio:

Codice: Seleziona tutto

Compilazione di 'dia' con /tmp in tmpfs:
real    4m39.050s
user    4m40.930s
sys     0m36.770s

Compilazione di 'dia' con /tmp  su HD:
real    4m45.916s
user    4m39.930s
sys     0m38.680s

La seconda prova l'ho fatta dopo aver riavviato il PC, non volevo che il kernel potesse sfruttare la cache. Anzi ne approfitto per chiedere a qualcuno se conosce un modo per svuotare (o invalidare) la cache.

Se avrò problemi di swap vedrò di segnalarvelo, anche perché non ho nessun filesystem per lo swap e se finisce la RAM sono guai !!!
Emanuele

[414N]

Ho appena fatto un po' di prova anch'io compilando wine su tmpfs e su disco sul mio monoprocessore di fiducia.
tmpfs:

Codice: Seleziona tutto

1933.48user 199.33system 45:06.56elapsed 78%CPU (0avgtext+0avgdata 986432maxresident)k
87176inputs+121648outputs (297major+72912414minor)pagefaults 0swaps

disco rigido:

Codice: Seleziona tutto

1834.78user 165.98system 41:17.21elapsed 80%CPU (0avgtext+0avgdata 985584maxresident)k
1088inputs+2930848outputs (16major+66907912minor)pagefaults 0swaps

Ci ha messo addirittura di meno da disco rigido, quindi non credo che il fatto di avere i sorgenti in RAM aiuti più di tanto...

[targzeta]

Ma la compilazione su HD è avvenuta dopo un riavvio? Perché se no il risultato potrebbe essere falsato. Comunque mi sono venuti dei dubbi, ho provato a compilare 5 programmi e mi è sembrato anche a me che ci mettesse più del solito. In teoria però il ragionamento non è sbagliato e l'accesso al disco è davvero molto più lungo di quello in RAM. Non vorrei ci sfuggisse qualche altro dettaglio. Ad esempio a me è sembrato che il processore si riscaldasse più del solito. Magari in questo modo la RAM si scalda troppo o che ne so. Butto delle ipotesi perché effetticamente non mi spiego questi risultati, teoricamente dovrebbe metterci molto di meno se tutto il processo avviene in RAM-

Emanuele

[414N]

Ma la compilazione su HD è avvenuta dopo un riavvio? Perché se no il risultato potrebbe essere falsato.

No, non ho riavviato perché ho utilizzato percorsi diversi per tmpfs (/mnt/tmp) e hdd (/tmp), percui non penso che il kernel potesse usare i file già in RAM per fare caching. Anche perché ho smontato il ramdisk prima della seconda compilazione.

Comunque mi sono venuti dei dubbi, ho provato a compilare 5 programmi e mi è sembrato anche a me che ci mettesse più del solito. In teoria però il ragionamento non è sbagliato e l'accesso al disco è davvero molto più lungo di quello in RAM. Non vorrei ci sfuggisse qualche altro dettaglio. Ad esempio a me è sembrato che il processore si riscaldasse più del solito. Magari in questo modo la RAM si scalda troppo o che ne so. Butto delle ipotesi perché effetticamente non mi spiego questi risultati, teoricamente dovrebbe metterci molto di meno se tutto il processo avviene in RAM-

Ho trovato questo post in un thread su LQ nel quale viene spiegato quando e perché tmpfs aiuta le performance di I/O. Tra l'altro viene anche spiegato come rendere duraturo quanto presente in RAM senza perdite notevoli di prestazioni (tramite un raid1 con una partizione su disco).
Infine, non abbiamo tenuto conto di un fattore: il VFS, che fa caching in RAM sia che si lavori in tmpfs che su disco.

[albatrosla]

Parecchi anni fa usavo questo escamotage per compilare il kernel perché la macchina rallentava vistosamente negli accessi al disco anche da altre applicazioni. Non ricordo dei benchmark, ciò che è certo è che in generale non avevo intoppi legati all'uso del disco durante la compilazione.

[targzeta]

Ho fatto un po' di ricerche anche io. Effettivamente non sembra esserci differenza tra la compilazione in RAM e quella su HD, il motivo penso sia quello descritto da 414N e dal link che ci ha fornito.

Vi posto comunque qualche link da leggere, forse c'è anche la risposta a ciò che chiedeva joe nel suo primo post (i documenti sono tutti linkati uno all'altro):
http://www.dslreports.com/forum/r181205 ... ng-in-RAM-
http://en.gentoo-wiki.com/wiki/Speeding ... with_tmpfs
http://forums.gentoo.org/viewtopic-p-6233551.html
http://en.gentoo-wiki.com/wiki/Ccache

Comunque, per ora provo a tenere il /tmp in RAM, se troverò problemi ve lo farò sapere. Il problema più grave è che io faccio praticamente tutto in /tmp e quindi rischio di riempirla senza accorgemene, a quel punto voglio vedere che succede, semplice "no space left on device" o altro? Fino ad ora non ho mai consumato interamente i miei 2GB, neanche compilando le wxGTK con -j3.

Emanuele

[414N]

Comunque, per ora provo a tenere il /tmp in RAM, se troverò problemi ve lo farò sapere. Il problema più grave è che io faccio praticamente tutto in /tmp e quindi rischio di riempirla senza accorgemene, a quel punto voglio vedere che succede, semplice "no space left on device" o altro? Fino ad ora non ho mai consumato interamente i miei 2GB, neanche compilando le wxGTK con -j3.

Beh, se non fornisci opzioni specifiche in merito al momento del mount, la partizione tmpfs viene creata di default grande quanto metà della RAM (che equivarrebbe a -o size=50%). Se hai paura di sbordare ed impallare il sistema, puoi sempre crearti un file di swap di qualche GB ed attivarlo con swapon.