Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Riduzione tempi di compilazione software da sorgenti
16 views
Skip to first unread message
kk
Dec 28, 2021, 4:35:57 PM12/28/21
to
Utilizzo Linux e ho parte del parco software pacchettizzato
a partire da sorgenti. A livello hardware, in generale quali
componenti / caratteristiche influenzano maggiormente i tempi
di compilazione?
La CPU?
- la frequenza
- il numero di core
- il tipo di cpu
La Ram?
Dubito faccia la differenza ma... il collegamento del disco
quindi SSD sata piuttosto che NVMe ?
Chi è l'indagato numero uno?
Domanda esotica, coinvolgere i core della scheda video per
lo scopo è pensabile?
So che si può implementare nel software eventualmente scritto ad hoc
la possibilità di sfruttare la GPU per calcoli vari, ma a livello di
runtime del software stesso. Non so se si possa sfruttare quella roba
per compilare software... tipicamente con gcc e simili. Non credo ma
la butto lì lo stesso, se qualcuno ne sa nulla...
Grazie in anticipo!
marimbarza
Dec 28, 2021, 6:44:09 PM12/28/21
to
On Tue, 28 Dec 2021 22:35:53 +0100
kk <k...@k.invalid> wrote:
> Utilizzo Linux e ho parte del parco software pacchettizzato
> a partire da sorgenti. A livello hardware, in generale quali
> componenti / caratteristiche influenzano maggiormente i tempi
> di compilazione?
>
> La CPU?
> - la frequenza
> - il numero di core
> - il tipo di cpu
>
> La Ram?
>
> Dubito faccia la differenza ma... il collegamento del disco
> quindi SSD sata piuttosto che NVMe ?
>
>
> Chi è l'indagato numero uno?
Prendo come riferimento la compilazione di cose molto massicce tipo il kernel di Linux, che mi capita di compilare spesso.
kk <k...@k.invalid> wrote:
> Utilizzo Linux e ho parte del parco software pacchettizzato
> a partire da sorgenti. A livello hardware, in generale quali
> componenti / caratteristiche influenzano maggiormente i tempi
> di compilazione?
>
> La CPU?
> - la frequenza
> - il numero di core
> - il tipo di cpu
>
> La Ram?
>
> Dubito faccia la differenza ma... il collegamento del disco
> quindi SSD sata piuttosto che NVMe ?
>
>
> Chi è l'indagato numero uno?
Compilare sorgenti beneficia in modo netto della presenza di più core.
La ram ti serve perché, nel momento in cui lanci una compilazione in parallelo su più core, ogni istanza del compilatore occuperà la sua parte di ram.
A spanne direi che compilare su 8 core hai bisogno *come minimo* di 2 gigabyte di ram, dove per minimo si intende la quantità più modesta per non farti mandare una istanza in out of memory.
Avere un ssd bello veloce anche aiuta molto poiché minimizza i tempi di accesso ai sorgenti, se nvme meglio, ma il collo di bottiglia già lo elimini passando dal meccanico allo stato solido.
> Domanda esotica, coinvolgere i core della scheda video per
> lo scopo è pensabile?
> So che si può implementare nel software eventualmente scritto ad hoc
> la possibilità di sfruttare la GPU per calcoli vari, ma a livello di
> runtime del software stesso. Non so se si possa sfruttare quella roba
> per compilare software... tipicamente con gcc e simili. Non credo ma
> la butto lì lo stesso, se qualcuno ne sa nulla...
>
> Grazie in anticipo!
Rispetto alle CPU general purpose, le GPU hanno molte unità esecutive con una complessità di gran lunga inferiore, mentre le CPU hanno poche unità esecutive ma allo stesso tempo molto complesse.
Lorenz
Dec 28, 2021, 7:33:18 PM12/28/21
to
Il 28/12/2021, kk ha detto :
e frequenza operativa in primis. Poi viene la RAM ma
di norma 16GB bastano per la maggiorparte dei casi.
la necessita' di eseguire processi relativamente semplici
ma altamente parallelizzabili, oppure in ambito dell'elaborazione
matriciale come ad esempio nel machine learning.
> Utilizzo Linux e ho parte del parco software pacchettizzato
> a partire da sorgenti. A livello hardware, in generale quali
> componenti / caratteristiche influenzano maggiormente i tempi
> di compilazione?
>
> La CPU?
> - la frequenza
> - il numero di core
> - il tipo di cpu
>
> La Ram?
>
> Dubito faccia la differenza ma... il collegamento del disco
> quindi SSD sata piuttosto che NVMe ?
>
>
> Chi è l'indagato numero uno?
In generale la cpu la fa da padrone, n. di core
> a partire da sorgenti. A livello hardware, in generale quali
> componenti / caratteristiche influenzano maggiormente i tempi
> di compilazione?
>
> La CPU?
> - la frequenza
> - il numero di core
> - il tipo di cpu
>
> La Ram?
>
> Dubito faccia la differenza ma... il collegamento del disco
> quindi SSD sata piuttosto che NVMe ?
>
>
> Chi è l'indagato numero uno?
e frequenza operativa in primis. Poi viene la RAM ma
di norma 16GB bastano per la maggiorparte dei casi.
>
>
> Domanda esotica, coinvolgere i core della scheda video per
> lo scopo è pensabile?
> So che si può implementare nel software eventualmente scritto ad hoc
> la possibilità di sfruttare la GPU per calcoli vari, ma a livello di
> runtime del software stesso. Non so se si possa sfruttare quella roba
> per compilare software... tipicamente con gcc e simili. Non credo ma
> la butto lì lo stesso, se qualcuno ne sa nulla...
>
Le GPU si usano soprattutto per calcoli dove si ha
>
> Domanda esotica, coinvolgere i core della scheda video per
> lo scopo è pensabile?
> So che si può implementare nel software eventualmente scritto ad hoc
> la possibilità di sfruttare la GPU per calcoli vari, ma a livello di
> runtime del software stesso. Non so se si possa sfruttare quella roba
> per compilare software... tipicamente con gcc e simili. Non credo ma
> la butto lì lo stesso, se qualcuno ne sa nulla...
>
la necessita' di eseguire processi relativamente semplici
ma altamente parallelizzabili, oppure in ambito dell'elaborazione
matriciale come ad esempio nel machine learning.
nop
Dec 29, 2021, 6:38:54 AM12/29/21
to
On 29/12/2021 10:34, asdf wrote:
> Aggiungo un link che potrebbe interessarti.
>
> https://distcc.github.io/
>
Forse era un esperimento interessante nel 2006.
6 minuti e 45 secondi per compilare il kernel di linux con un vetusto
Pentium 4 a 1,7ghz.
Ha senso mettere in piedi una infrastruttura del genere? quanto si potrà
mai risparmiare.
> On Tue, 28 Dec 2021 22:35:53 +0100, kk wrote:
>
>> Chi è l'indagato numero uno?
>
>
> Tutto valido quello che ti hanno consigliato su CPU, RAM e storage.
>
>> Chi è l'indagato numero uno?
>
>
> Aggiungo un link che potrebbe interessarti.
>
> https://distcc.github.io/
>
Forse era un esperimento interessante nel 2006.
6 minuti e 45 secondi per compilare il kernel di linux con un vetusto
Pentium 4 a 1,7ghz.
Ha senso mettere in piedi una infrastruttura del genere? quanto si potrà
mai risparmiare.
Bender Piegatore Rodriguez
Dec 29, 2021, 8:13:43 AM12/29/21
to
"asdf" <as...@nospam.com> ha scritto nel messaggio
news:sqhlr8$27q$1...@gioia.aioe.org...
> E perchè non dovrebbe andar bene anche oggi?
In effetti 30 secondi sono meno di 32.
Ne vale la pena!
marimbarza
Dec 29, 2021, 12:25:45 PM12/29/21
to
forse era solo kernel + moduli.
Ti posso assicurare che che fare cross-compiling di un kernel general
purpose sull'i7 2700k che uso non ci mette meno di tre quarti d'ora..
RobertoA
Dec 29, 2021, 1:10:34 PM12/29/21
to
Ma hai provato, molto semplicemente, col 'monitor risorse' di Windows a
verificare cosa viene realmente usato?
Se disco, se cpu, se ram, ...?
Il Gcc ha diverse possibilita' di ottimizzazione, hai verificato su
qualche ng/forum di 'utenti gcc' se salta fuori qualcosa di buono?
Comunque anche senza ottimizzazioni mi pare davvero lenta la
compilazione cosi' com'e' ora
https://stackoverflow.com/questions/47564415/which-of-gccs-o3-optimization-flags-enable-hardware-accelerated-instructions
marimbarza
Dec 29, 2021, 3:41:59 PM12/29/21
to
La mia attività è principalmente cross-compilazione per architetture ARM
(armbian) con linux virtualizzato sotto linux.
Sicuramente se gli forzo -O3 ci mette ancora di più, da quel che mi
ricordo il kernel ha per default -O2
kk
Dec 29, 2021, 6:25:05 PM12/29/21
to
-O2 o -O3 servono per ottimizzare le performance del software
prodotto, non per velocizzare l'operazione di compilazione o
linking. Se si attivano quelle ottimizzazioni è giusto aspettarsi
tempi di compilazione maggiori.
Al volo da una googolata è spiegato più in dettaglio qui sotto:
https://gcc.gnu.org/onlinedocs/gcc-4.1.0/gcc/Optimize-Options.html
------
Without any optimization option, the compiler's goal is to *reduce the*
*cost of compilation* and to make debugging produce the expected results.
[...]
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
------
Per quel che riguarda distcc, servono più macchine su cui distribuire
il carico di lavoro, non è il mio caso, mi sembra più indicato per chi
debba distribuire i binari di un parco software da installare ad esempio
su un sistema ufficiale "vanilla", che gli altri utenti possano avere:
esempio se io dovessi gestire un repository di software non ufficiale,
extra preparato per essere installato e funzionare sulla versione
stabile di Debian, o quel che è.
In quel caso avendo esempio 10 macchine su cui ho altrettante
installazioni "full" del software ufficiale Debian, posso farle lavorare
insieme e sarò sicuro che la compilazione e soprattutto il linking verrà
fatto "contro" librerie ufficiali che anche gli utenti finali avranno
sui loro sistemi se hanno un'installazione vanilla.
Se i sistemi messi in network che lavorano via distcc contengono
librerie diverse, non saprei cosa salterebbe fuori. I binari finari
girerebbero forse, ma forse no perché magari si aspettano di trovare
una certa libreria che invece non c'è.
Va be' non era questo lo spirito della mia domanda comunque, distcc
non è ciò che fa al caso mio, a meno di non costruire enne macchine
per lo scopo.
C'era anche un'altro progetto che memorizzava pezzi delle compilazioni
e li richiamava in caso di compilazioni successive, ccache:
https://ccache.dev
Però non l'ho mai provato.
Non so se funzionerebbe per effettuare compilazione di software
necessaria in caso di upgrade vari. Del tipo, aggiorno una libreria
e devo compilare i software che dipendono da quella libreria in modo
che si colleghino ad essa.
Tornando all'hardware...
Quindi principalmente volendo migliorare la situazione tempi di
compilazione, principalmente si deve avere una CPU più prestante
accompagnata da Ram in abbondanza che più ne abbiamo e meglio è
come da sempre, il tutto condito con SSD che ormai per ospitare
il sistema operativo è in ogni caso un must.
Faccio una domanda sul processore allora:
meglio puntare sulla frequenza o sul numero di core per lo scopo in
oggetto?
nop
Dec 30, 2021, 3:17:00 AM12/30/21
to
On 29/12/2021 18:25, marimbarza wrote:
>
> Forse era una ricompilazione con parte dei sorgenti già compilati, o
> forse era solo kernel + moduli.
> Ti posso assicurare che che fare cross-compiling di un kernel general
> purpose sull'i7 2700k che uso non ci mette meno di tre quarti d'ora..
>
così per curiosità ogni quanto ricompili il kernel di linux? e
>
> Forse era una ricompilazione con parte dei sorgenti già compilati, o
> forse era solo kernel + moduli.
> Ti posso assicurare che che fare cross-compiling di un kernel general
> purpose sull'i7 2700k che uso non ci mette meno di tre quarti d'ora..
>
sopratutto perchè?
Grazie
PS il pentium 4 era vetusto ma anche il i7-2700k non scherza eh.
Bender Piegatore Rodriguez
Dec 30, 2021, 5:20:11 AM12/30/21
to
"marimbarza" <a@b.c> ha scritto nel messaggio
news:sqi5mm$cik$1...@gioia.aioe.org...
> Ti posso assicurare che che fare cross-compiling di un kernel general
> purpose sull'i7 2700k che uso non ci mette meno di tre quarti d'ora..
marimbarza
Dec 30, 2021, 10:34:19 AM12/30/21
to
On Wed, 29 Dec 2021 23:47:56 +0100
kk <k...@k.invalid> wrote:
>
> Rispondo qui un po' a tutti, per quello che ne sapevo io i flag
> -O2 o -O3 servono per ottimizzare le performance del software
> prodotto, non per velocizzare l'operazione di compilazione o
> linking. Se si attivano quelle ottimizzazioni è giusto aspettarsi
> tempi di compilazione maggiori.
Si è esatto, chiaramente -O3 aggiunge più ottimizzazioni e quindi peggiora i tempi di compilazione rispetto a -O2, e così via fino a -O0 che compila il codice così com'è.
kk <k...@k.invalid> wrote:
>
> Rispondo qui un po' a tutti, per quello che ne sapevo io i flag
> -O2 o -O3 servono per ottimizzare le performance del software
> prodotto, non per velocizzare l'operazione di compilazione o
> linking. Se si attivano quelle ottimizzazioni è giusto aspettarsi
> tempi di compilazione maggiori.
> C'era anche un'altro progetto che memorizzava pezzi delle compilazioni
> e li richiamava in caso di compilazioni successive, ccache:
> https://ccache.dev
>
> Però non l'ho mai provato.
> Non so se funzionerebbe per effettuare compilazione di software
> necessaria in caso di upgrade vari. Del tipo, aggiorno una libreria
> e devo compilare i software che dipendono da quella libreria in modo
> che si colleghino ad essa.
Make usato dal kernel ha già delle tecniche per evitare di ricompilare file che non hanno subito modifiche, ma ccache va' più in dettaglio e scorre il codice per cercare di capire se i sorgenti e gli include sono cambiati; in presenza di ccache i tempi si accorciano notevolmente nelle successive ricompilazioni, ma i tempi della prima ricompilazione si allungano perché deve analizzare i file al volo e generare la cache.
Alla fine si usa in luogo di cc normale, di cui praticamente diventa un wrapper.
> Tornando all'hardware...
> Quindi principalmente volendo migliorare la situazione tempi di
> compilazione, principalmente si deve avere una CPU più prestante
> accompagnata da Ram in abbondanza che più ne abbiamo e meglio è
> come da sempre, il tutto condito con SSD che ormai per ospitare
> il sistema operativo è in ogni caso un must.
Metterei più in risalto l'SSD che la RAM. Diciamo che se hai 8 gigabyte di ram se già più che a posto, ma anche con 4 non dovresti avere problemi - poi molto dipende anche dall'ambiente di compilazione che utilizzi. Se usi una distro slim come debian a riga di comando è un conto, se usi Ubuntu con ambiente grafico e tutto il resto di contorno allora devi tenerne conto.
L'accesso al disco, in caso di RAM ridotta, sarebbe comunque garantito essere immediato in presenza di SSD.
> Faccio una domanda sul processore allora:
> meglio puntare sulla frequenza o sul numero di core per lo scopo in
> oggetto?
--
marimbarza
Dec 30, 2021, 10:37:46 AM12/30/21
to
Ultimamente sto smanettando con un driver per il wireless quindi sto dedicando poco tempo al supporto tv box, però di solito ricompilo spesso, fino a diverse volte al giorno :D
0 new messages