Minimizzare tempi di compilazione/ricompilazione

Postate qui per tutte le discussioni legate a Linux in generale.

Moderatore: Staff

Regole del forum
1) Citare sempre la versione di Slackware usata, la versione del Kernel e magari anche la versione della libreria coinvolta. Questi dati aiutano le persone che possono rispondere.
2) Per evitare confusione prego inserire in questo forum solo topic che riguardano appunto Gnu/Linux in genere, se l'argomento è specifico alla Slackware usate uno dei forum Slackware o Slackware64.
3) Leggere attentamente le risposte ricevute
4) Scrivere i messaggi con il colore di default, evitare altri colori.
5) Scrivere in Italiano o in Inglese, se possibile grammaticalmente corretto, evitate stili di scrittura poco chiari, quindi nessuna abbreviazione tipo telegramma o scrittura stile SMS o CHAT.
6) Appena registrati è consigliato presentarsi nel forum dedicato.

La non osservanza delle regole porta a provvedimenti di vari tipo da parte dello staff, in particolare la non osservanza della regola 5 porta alla cancellazione del post e alla segnalazione dell'utente. In caso di recidività l'utente rischia il ban temporaneo.
Avatar utente
joe
Iper Master
Iper Master
Messaggi: 3261
Iscritto il: ven 27 apr 2007, 11:21
Slackware: 14.2
Kernel: 4.4.38
Desktop: KDE-4.14.21

Minimizzare tempi di compilazione/ricompilazione

Messaggio da 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?).

Avatar utente
sardylan
Linux 3.x
Linux 3.x
Messaggi: 993
Iscritto il: mar 24 apr 2007, 9:21
Nome Cognome: Luca Cireddu
Slackware: current 64bits
Kernel: 3.16
Desktop: KDE 4.14
Distribuzione: Debian - CLFS
Località: Cagliari
Contatta:

Re: Minimizzare tempi di compilazione/ricompilazione

Messaggio da 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...

Avatar utente
414N
Iper Master
Iper Master
Messaggi: 2902
Iscritto il: mer 13 feb 2008, 16:19
Slackware: 14.2
Kernel: 4.4.19
Desktop: KDE4
Località: Bulagna
Contatta:

Re: Minimizzare tempi di compilazione/ricompilazione

Messaggio da 414N »

joe ha scritto: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:
man gcc ha scritto: 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.

Avatar utente
joe
Iper Master
Iper Master
Messaggi: 3261
Iscritto il: ven 27 apr 2007, 11:21
Slackware: 14.2
Kernel: 4.4.38
Desktop: KDE-4.14.21

Re: Minimizzare tempi di compilazione/ricompilazione

Messaggio da 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?

Avatar utente
414N
Iper Master
Iper Master
Messaggi: 2902
Iscritto il: mer 13 feb 2008, 16:19
Slackware: 14.2
Kernel: 4.4.19
Desktop: KDE4
Località: Bulagna
Contatta:

Re: Minimizzare tempi di compilazione/ricompilazione

Messaggio da 414N »

joe ha scritto: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ì...
joe ha scritto: 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.
joe ha scritto: 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
Linux 4.x
Linux 4.x
Messaggi: 1212
Iscritto il: ven 9 ott 2009, 19:25
Slackware: 13.37
Kernel: 3.0.7
Desktop: kde

Re: Minimizzare tempi di compilazione/ricompilazione

Messaggio da 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.

Avatar utente
414N
Iper Master
Iper Master
Messaggi: 2902
Iscritto il: mer 13 feb 2008, 16:19
Slackware: 14.2
Kernel: 4.4.19
Desktop: KDE4
Località: Bulagna
Contatta:

Re: Minimizzare tempi di compilazione/ricompilazione

Messaggio da 414N »

erio ha scritto: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.
:-k
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
Packager
Packager
Messaggi: 1339
Iscritto il: sab 27 mar 2004, 0:00
Slackware: current
Desktop: fluxbox.git
Località: Collegno, but made in Friûl
Contatta:

Re: Minimizzare tempi di compilazione/ricompilazione

Messaggio da 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.

Avatar utente
targzeta
Iper Master
Iper Master
Messaggi: 6563
Iscritto il: gio 3 nov 2005, 14:05
Nome Cognome: Emanuele Tomasi
Slackware: 64-current
Kernel: latest stable
Desktop: IceWM
Località: Carpignano Sal. (LE) <-> Pisa

Re: Minimizzare tempi di compilazione/ricompilazione

Messaggio da targzeta »

albatrosla ha scritto:...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
Linux Registered User #454438
Se pensi di essere troppo piccolo per fare la differenza, prova a dormire con una zanzara -- Dalai Lama
20/04/2013 - Io volevo Rodotà 

Avatar utente
414N
Iper Master
Iper Master
Messaggi: 2902
Iscritto il: mer 13 feb 2008, 16:19
Slackware: 14.2
Kernel: 4.4.19
Desktop: KDE4
Località: Bulagna
Contatta:

Re: Minimizzare tempi di compilazione/ricompilazione

Messaggio da 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...

Avatar utente
targzeta
Iper Master
Iper Master
Messaggi: 6563
Iscritto il: gio 3 nov 2005, 14:05
Nome Cognome: Emanuele Tomasi
Slackware: 64-current
Kernel: latest stable
Desktop: IceWM
Località: Carpignano Sal. (LE) <-> Pisa

Re: Minimizzare tempi di compilazione/ricompilazione

Messaggio da 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
Linux Registered User #454438
Se pensi di essere troppo piccolo per fare la differenza, prova a dormire con una zanzara -- Dalai Lama
20/04/2013 - Io volevo Rodotà 

Avatar utente
414N
Iper Master
Iper Master
Messaggi: 2902
Iscritto il: mer 13 feb 2008, 16:19
Slackware: 14.2
Kernel: 4.4.19
Desktop: KDE4
Località: Bulagna
Contatta:

Re: Minimizzare tempi di compilazione/ricompilazione

Messaggio da 414N »

spina ha scritto: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.
spina ha scritto: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
Packager
Packager
Messaggi: 1339
Iscritto il: sab 27 mar 2004, 0:00
Slackware: current
Desktop: fluxbox.git
Località: Collegno, but made in Friûl
Contatta:

Re: Minimizzare tempi di compilazione/ricompilazione

Messaggio da 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.

Avatar utente
targzeta
Iper Master
Iper Master
Messaggi: 6563
Iscritto il: gio 3 nov 2005, 14:05
Nome Cognome: Emanuele Tomasi
Slackware: 64-current
Kernel: latest stable
Desktop: IceWM
Località: Carpignano Sal. (LE) <-> Pisa

Re: Minimizzare tempi di compilazione/ricompilazione

Messaggio da 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
Linux Registered User #454438
Se pensi di essere troppo piccolo per fare la differenza, prova a dormire con una zanzara -- Dalai Lama
20/04/2013 - Io volevo Rodotà 

Avatar utente
414N
Iper Master
Iper Master
Messaggi: 2902
Iscritto il: mer 13 feb 2008, 16:19
Slackware: 14.2
Kernel: 4.4.19
Desktop: KDE4
Località: Bulagna
Contatta:

Re: Minimizzare tempi di compilazione/ricompilazione

Messaggio da 414N »

spina ha scritto: 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.

Rispondi