Qualcuno fa benchmark hardware sul codice di compilazione? [chiuso]


21

Ho visto un sacco di siti che confrontano il nuovo hardware sulle prestazioni di gioco, comprimono alcuni file, codificano un film o altro. C'è qualcuno che prova l'impatto di nuovo hardware (come SSD, nuove CPU, velocità RAM o altro) sulla velocità di compilazione e collegamento, sia Linux che Windows?

Sarebbe davvero bello scoprire cosa contava di più per la velocità di compilazione ed essere in grado di concentrarsi su questo, invece di estrapolare da altri benchmark.


Penso che questo appartenga a SuperUser.
Mahmoud Hossam,

2
@Mahmoud Hossam: una sorta di argomento misto, la compilazione è un'attività intensamente programmatrice, mentre i benchmark hardware sono sicuramente un territorio diverso.
Orbling

@Orbling bene, non sta chiedendo se dovrebbe compilare X o Y, sta chiedendo se le persone usano la compilazione in generale per fare benchmark.
Mahmoud Hossam,


1
C'è un benchmark della CPU basato sui tempi di compilazione del kernel Linux qui: openbenchmarking.org/showdown/pts/build-linux-kernel
sjakobi

Risposte:


4

L'ho fatto per un po '- guarda qui e qui .

All'epoca, stavo lavorando su hacking GTK + e X11 per una distribuzione di telefoni cellulari Linux e ogni volta che toccavo qualcosa di così basso livello, si avviava la ricostruzione di tutti i tipi di cose. Uno dei miei colleghi non ha mai realizzato build complete perché, sul computer, la società ha fornito le opzioni di compilazione standard, ci sono volute cinque ore.

Avevo tutti i tipi di hardware pazzo seduto a casa, quindi ho eseguito benchmark su alcune macchine mentre ho codificato su altri, e puoi vedere i risultati sui link.

Per quello che stavamo facendo su Ubuntu, una volta ho esaurito l'utilizzo della CPU - cosa che puoi fare facilmente con l'argomento -j da fare - il collo di bottiglia sembrava essere il disco.

Ma poi la compagnia ha avuto grandi licenziamenti, quindi ero fuori dalla porta e non ho finito di esplorare tutto. Ho avuto molti dati e interpretazioni che non ho pubblicato su quel blog.


Peccato costruirlo con due post dettagliati e li fermiamo. Hai ancora tutti quei dati? In ogni caso, sarebbe molto interessante vedere alcuni post / risposte sul blog con alcune conclusioni di ciò che hai trovato.
Hugo,

@Hugo: No, temo di no - i dati grezzi sono spariti da tempo. Ma fondamentalmente quello che mi è venuto in mente è che per i sistemi (1-8 core della CPU) e il codice sorgente (il kernel Linux) che stavo testando, i tempi di compilazione più veloci sono stati quando l'opzione -j era a 1,5 volte il numero di core, con -j = 2 è il migliore per un core. Al di sotto di ciò, i sistemi erano collegati alla CPU e, al di là di ciò, erano associati all'I / O. È una domanda interessante - forse dovrei riprenderlo un giorno.
Bob Murphy,

0

Il primo sulla mia lista dei desideri è un disco a stato solido. Non avrà un impatto enorme sui tempi di compilazione, ma l'apertura delle applicazioni diventa drasticamente più veloce (IDE, PhotoShop, ETC). http://joelonsoftware.com/items/2009/03/27.html

Il fattore principale per il tempo di compilazione sarà la CPU. Sei abbastanza sicuro usando questo per il benchmark http://www.cpubenchmark.net/ .


1
Quindi di nuovo molto dipende dalla tua catena di build. Se la tua catena di build utilizza un solo thread per la compilazione su una CPU multi-CPU, multi-core o persino multi-thread, stai sprecando un'opportunità per ottenere enormi guadagni. Un semplice benchmark CPU non lo dimostrerà, e un benchmark di compilazione sarebbe buono solo per una data toolchain.
asoundmove,

2
In realtà, ho scoperto per esperimento che una volta eseguita la compilazione parallela, è il tuo collo di bottiglia che è il collo di bottiglia. Entro limiti ragionevoli, stai meglio con una CPU più lenta e un disco più veloce di viceversa.
Bob Murphy,

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.