Come faccio a far andare Windows veloce come Linux per la compilazione di C ++?

So che questa non è una questione di programmazione, ma è rilevante.

Lavoro a un progetto multipiattaforma abbastanza grande . Su Windows utilizzo VC ++ 2008. Su Linux utilizzo gcc. Ci sono circa 40k file nel progetto. Windows è 10x a 40x più lento di Linux durante la compilazione e il collegamento dello stesso progetto. Come posso ripararlo?

Una singola modifica incrementale costruisce 20 secondi su Linux e> 3 minuti su Windows. Perché? Posso anche installare il linker "gold" su Linux e ridurre il tempo a 7 secondi.

Allo stesso modo git è 10x a 40x più veloce su Linux rispetto a Windows.

Nel caso git è possibile che git non stia usando Windows in modo ottimale ma VC ++? Penseresti che Microsoft vorrebbe rendere i propri sviluppatori il più produttivi possibile e una compilazione più veloce farebbe molto per questo. Forse stanno cercando di incoraggiare gli sviluppatori in C #?

Come semplice test, trova una cartella con molte sottocartelle e fai una semplice

dir /s > c:\list.txt

Su Windows. Fallo due volte e cronometra la seconda esecuzione in modo che venga eseguita dalla cache. Copia i file su Linux ed esegui le equivalenti 2 corse e cronometra la seconda.

ls -R > /tmp/list.txt

Ho 2 workstation con le stesse specifiche esatte. HP Z600s con 12 gig di ram, 8 core a 3.0 ghz. In una cartella con ~ 400k file Windows impiega 40 secondi, Linux impiega <1 secondo.

Esiste un'impostazione di registro che posso configurare per velocizzare Windows? Cosa dà?

Alcuni collegamenti leggermente rilevanti, pertinenti ai tempi di compilazione, non necessariamente I / O.

• Apparentemente c'è un problema in Windows 10 (non in Windows 7) che la chiusura di un processo comporta un blocco globale . Durante la compilazione con più core e quindi più processi, questo problema ha esito positivo.

• L' /analyseopzione può influire negativamente su perf perché carica un browser web . (Non pertinente qui ma buono a sapersi)

A meno che non arrivi un hacker di sistemi Windows hardcore, non otterrai più di commenti partigiani (cosa che non farò) e speculazioni (che è quello che sto per provare).

1. File system: dovresti provare le stesse operazioni (incluso il dir) sullo stesso filesystem. Mi sono imbattuto in questo che confronta alcuni filesystem per vari parametri.

2. Caching. Una volta ho provato a eseguire una compilation su Linux su un disco RAM e ho scoperto che era più lento rispetto all'esecuzione su disco grazie al modo in cui il kernel si occupa della memorizzazione nella cache. Questo è un solido punto di forza per Linux e potrebbe essere il motivo per cui le prestazioni sono così diverse.

3. Specifiche di dipendenza errate su Windows. Forse le specifiche di dipendenza del cromo per Windows non sono corrette come per Linux. Ciò potrebbe comportare compilazioni non necessarie quando si apportano piccole modifiche. Potresti essere in grado di convalidarlo utilizzando la stessa toolchain del compilatore su Windows.

Alcune idee:

1. Disabilita i nomi 8.3. Questo può essere un grande fattore su unità con un numero elevato di file e un numero relativamente piccolo di cartelle:fsutil behavior set disable8dot3 1
2. Usa più cartelle. Nella mia esperienza, NTFS inizia a rallentare con più di circa 1000 file per cartella.
3. Abilita build parallele con MSBuild; basta aggiungere l'opzione "/ m" e avvierà automaticamente una copia di MSBuild per core della CPU.
4. Metti i tuoi file su un SSD - aiuta enormemente per l'I / O casuale.
5. Se la dimensione media del file è molto maggiore di 4KB, prendere in considerazione la ricostruzione del filesystem con una dimensione del cluster più grande che corrisponde approssimativamente alla dimensione media del file.
6. Assicurarsi che i file siano stati deframmentati. I file frammentati causano molte ricerche su disco, il che può costare un fattore di oltre 40 nella velocità effettiva. Utilizzare l'utilità "contig" di sysinternals o la deframmentazione di Windows integrata.
7. Se la dimensione media del file è piccola e la partizione in cui ti trovi è relativamente piena, è possibile che tu sia in esecuzione con una MFT frammentata, il che è negativo per le prestazioni. Inoltre, i file di dimensioni inferiori a 1 KB vengono archiviati direttamente nella MFT. L'utilità "contig" di cui sopra può essere d'aiuto, oppure potrebbe essere necessario aumentare la dimensione MFT. Il seguente comando lo raddoppierà, al 25% del volume: fsutil behavior set mftzone 2Cambia l'ultimo numero in 3 o 4 per aumentare la dimensione di ulteriori incrementi del 12,5%. Dopo aver eseguito il comando, riavviare e quindi creare il filesystem.
8. Disabilita l'ora dell'ultimo accesso: fsutil behavior set disablelastaccess 1
9. Disabilita il servizio di indicizzazione
10. Disabilita il tuo software antivirus e antispyware o almeno imposta le cartelle pertinenti da ignorare.
11. Inserisci i tuoi file su un'unità fisica diversa dal sistema operativo e dal file di paging. L'uso di un'unità fisica separata consente a Windows di utilizzare gli I / O paralleli su entrambe le unità.
12. Dai un'occhiata alle tue bandiere del compilatore. Il compilatore di Windows C ++ ha molte opzioni; assicurati di utilizzare solo quelli di cui hai veramente bisogno.
13. Prova ad aumentare la quantità di memoria utilizzata dal sistema operativo per i buffer del pool di paging (assicurati di disporre prima di RAM sufficiente): fsutil behavior set memoryusage 2
14. Controllare il registro degli errori di Windows per assicurarsi che non si verifichino errori occasionali del disco.
15. Dai un'occhiata ai contatori delle prestazioni relativi al disco fisico per vedere quanto sono occupati i tuoi dischi. Lunghe lunghezze di coda o tempi lunghi per trasferimento sono segni negativi.
16. Il primo 30% delle partizioni del disco è molto più veloce rispetto al resto del disco in termini di tempo di trasferimento non elaborato. Le partizioni più strette aiutano anche a ridurre al minimo i tempi di ricerca.
17. Stai usando RAID? In tal caso, potrebbe essere necessario ottimizzare la scelta del tipo di RAID (RAID-5 è dannoso per operazioni pesanti come la compilazione)
18. Disabilita tutti i servizi che non ti servono
19. Deframmenta le cartelle: copia tutti i file su un'altra unità (solo i file), elimina i file originali, copia tutte le cartelle su un'altra unità (solo le cartelle vuote), quindi elimina le cartelle originali, deframmenta l'unità originale, copia prima la struttura delle cartelle , quindi copia i file. Quando Windows crea cartelle di grandi dimensioni un file alla volta, le cartelle finiscono per essere frammentate e lente. ("contig" dovrebbe aiutare anche qui)
20. Se si è collegati agli I / O e si hanno dei cicli della CPU di riserva, provare ad attivare la compressione del disco. Può fornire alcune accelerazioni significative per file altamente comprimibili (come il codice sorgente), con un certo costo in CPU.

NTFS salva ogni volta il tempo di accesso ai file. Puoi provare a disabilitarlo: "comportamento fsutil set disablelastaccess 1" (riavvio)

Il problema con Visual c ++ è, per quanto posso dire, che non è una priorità per il team del compilatore ottimizzare questo scenario. La loro soluzione è che usi la loro funzione di intestazione precompilata. Questo è ciò che hanno fatto progetti specifici di Windows. Non è portatile, ma funziona.

Inoltre, su Windows in genere hai scanner di virus, nonché strumenti di ripristino e ricerca del sistema che possono rovinare completamente i tuoi tempi di costruzione se controllano la tua cartella buid per te. Windows 7 resouce monitor può aiutarti a individuarlo. Ho una risposta qui con alcuni ulteriori suggerimenti per ottimizzare i tempi di costruzione di vc ++ se sei veramente interessato.

Personalmente ho scoperto che eseguire una macchina virtuale Windows su Linux è riuscito a rimuovere gran parte della lentezza dell'IO in Windows, probabilmente perché la VM Linux stava facendo un sacco di cache che Windows stesso non lo era.

In questo modo sono stato in grado di accelerare i tempi di compilazione di un grande progetto C ++ (250Kloc) su cui stavo lavorando da qualcosa come 15 minuti a circa 6 minuti.

La difficoltà nel farlo è dovuta al fatto che il C ++ tende a diffondersi e il processo di compilazione su molti piccoli file individuali. Questo è qualcosa in cui Linux è bravo e Windows no. Se vuoi creare un compilatore C ++ davvero veloce per Windows, prova a conservare tutto nella RAM e tocca il filesystem il meno possibile.

Questo è anche il modo in cui creerai una catena di compilazione C ++ Linux più veloce, ma è meno importante in Linux perché il file system sta già facendo molto di quel tuning per te.

Il motivo è dovuto alla cultura Unix: storicamente le prestazioni del file system sono state una priorità molto più alta nel mondo Unix che in Windows. Per non dire che non è stata una priorità in Windows, solo che in Unix è stata una priorità più alta.

1. Accesso al codice sorgente.

   Non puoi cambiare ciò che non puoi controllare. La mancanza di accesso al codice sorgente di Windows NTFS significa che la maggior parte degli sforzi per migliorare le prestazioni sono stati apportati miglioramenti hardware. In altre parole, se le prestazioni sono lente, si aggira il problema migliorando l'hardware: il bus, il supporto di archiviazione e così via. Puoi fare così tanto se devi aggirare il problema, non risolverlo.

   L'accesso al codice sorgente Unix (anche prima dell'open source) era più diffuso. Pertanto, se si desidera migliorare le prestazioni, è necessario prima affrontarle nel software (più economico e più semplice) e poi nell'hardware.

   Di conseguenza, ci sono molte persone al mondo che hanno ottenuto il loro dottorato di ricerca studiando il file system Unix e trovando nuovi modi per migliorare le prestazioni.

2. Unix tende a molti piccoli file; Windows tende verso pochi (o un singolo) file di grandi dimensioni.

   Le applicazioni Unix tendono a gestire molti piccoli file. Pensa a un ambiente di sviluppo software: molti piccoli file sorgente, ognuno con il proprio scopo. La fase finale (collegamento) crea un file di grandi dimensioni, ma questa è una piccola percentuale.

   Di conseguenza, Unix ha richieste di sistema altamente ottimizzate per l'apertura e la chiusura di file, la scansione di directory e così via. La storia dei documenti di ricerca Unix abbraccia decenni di ottimizzazioni del file system che riflettono molto sul miglioramento dell'accesso alle directory (ricerche e scansioni di directory complete), sull'apertura iniziale dei file e così via.

   Le applicazioni Windows tendono ad aprire un file di grandi dimensioni, tenerlo aperto per lungo tempo, chiuderlo al termine. Pensa a MS-Word. msword.exe (o qualsiasi altra cosa) apre il file una volta e lo aggiunge per ore, aggiorna i blocchi interni e così via. Il valore di ottimizzazione dell'apertura del file sarebbe una perdita di tempo.

   La storia del benchmarking e dell'ottimizzazione di Windows è stata su quanto velocemente si possono leggere o scrivere file lunghi. Questo è ciò che viene ottimizzato.

   Purtroppo lo sviluppo del software ha fatto tendenza verso la prima situazione. Diamine, il miglior sistema di elaborazione testi per Unix (TeX / LaTeX) ti incoraggia a mettere ogni capitolo in un file diverso e #includerli tutti insieme.

3. Unix è focalizzato sulle alte prestazioni; Windows è focalizzato sull'esperienza utente

   Unix è stato avviato nella sala server: nessuna interfaccia utente. L'unica cosa che gli utenti vedono è la velocità. Pertanto, la velocità è una priorità.

   Windows è stato avviato sul desktop: agli utenti interessa solo ciò che vedono e visualizzano l'interfaccia utente. Pertanto, viene spesa più energia per migliorare l'interfaccia utente che per le prestazioni.

4. L'ecosistema di Windows dipende dall'obsolescenza pianificata. Perché ottimizzare il software quando il nuovo hardware è a solo un anno o due di distanza?

   Non credo nelle teorie della cospirazione, ma se lo facessi, vorrei sottolineare che nella cultura di Windows ci sono meno incentivi per migliorare le prestazioni. I modelli di business di Windows dipendono dalle persone che acquistano nuove macchine come un orologio. (Ecco perché il prezzo delle azioni di migliaia di aziende è interessato se MS spedisce un sistema operativo in ritardo o se Intel non rileva una data di rilascio del chip.). Ciò significa che esiste un incentivo per risolvere i problemi di prestazioni dicendo alle persone di acquistare nuovo hardware; non migliorando il vero problema: i sistemi operativi lenti. Unix proviene dal mondo accademico, dove il budget è limitato e puoi ottenere il tuo dottorato di ricerca inventando un nuovo modo per rendere i file system più veloci; raramente qualcuno in università ottiene punti per risolvere un problema emettendo un ordine di acquisto.

   Inoltre, poiché Unix è open source (anche quando non lo era, tutti avevano accesso alla fonte) qualsiasi studente di dottorato annoiato può leggere il codice e diventare famoso rendendolo migliore. Ciò non accade in Windows (MS ha un programma che offre agli accademici l'accesso al codice sorgente di Windows, raramente viene sfruttato). Guarda questa selezione di documenti sulle prestazioni relativi a Unix: http://www.eecs.harvard.edu/margo/papers/ o consulta la storia dei documenti di Osterhaus, Henry Spencer o altri. Diamine, uno dei dibattiti più grandi (e più divertenti da guardare) nella storia di Unix è stato il ritorno tra Osterhaus e Selzer http://www.eecs.harvard.edu/margo/papers/usenix95-lfs/supplement/rebuttal. html Non vedi questo genere di cose accadere nel mondo Windows. Potresti vedere i fornitori uno alla volta, ma ultimamente sembra essere molto più raro poiché l'innovazione sembra essere a livello corporeo standard.

Ecco come lo vedo.

Aggiornamento: se guardi alle nuove catene di compilatori che escono da Microsoft, sarai molto ottimista perché gran parte di ciò che stanno facendo rende più semplice mantenere l'intera toolchain nella RAM e ripetere meno lavoro. Roba davvero impressionante.

Collegamento incrementale

Se la soluzione VC 2008 è impostata come più progetti con output .lib, è necessario impostare "Usa input dipendenza libreria"; questo rende il collegamento del linker direttamente contro i file .obj anziché .lib. (E in realtà lo rende in modo incrementale link.)

Prestazioni di attraversamento di directory

È un po 'ingiusto confrontare la ricerca per indicizzazione della directory sulla macchina originale con la ricerca per indicizzazione di una directory appena creata con gli stessi file su un'altra macchina. Se si desidera un test equivalente, è consigliabile creare un'altra copia della directory sul computer di origine. (Potrebbe essere ancora lento, ma ciò potrebbe essere dovuto a un numero qualsiasi di cose: frammentazione del disco, nomi di file brevi, servizi in background, ecc.) Anche se penso che i problemi perf dir /sabbiano più a che fare con la scrittura dell'output che con la misurazione del file effettivo prestazione trasversale. Anche dir /s /b > nulè lento sulla mia macchina con una directory enorme.

Sono abbastanza sicuro che sia legato al filesystem. Lavoro a un progetto multipiattaforma per Linux e Windows in cui tutto il codice è comune tranne per i casi in cui il codice dipendente dalla piattaforma è assolutamente necessario. Usiamo Mercurial, non git, quindi la "Linuxness" di git non si applica. L'estrazione delle modifiche dal repository centrale richiede un'eternità su Windows rispetto a Linux, ma devo dire che le nostre macchine Windows 7 funzionano molto meglio di quelle di Windows XP. Compilare il codice dopo è ancora peggio su VS 2008. Non è solo hg; CMake funziona molto più lentamente anche su Windows ed entrambi questi strumenti utilizzano il file system più di ogni altra cosa.

Il problema è talmente grave che la maggior parte dei nostri sviluppatori che lavorano in ambiente Windows non si preoccupano più di creare build incrementali, ma scoprono che invece fare una build unitaria è più veloce.

Per inciso, se si desidera ridurre drasticamente la velocità di compilazione in Windows, suggerirei la build di unità di cui sopra. È difficile implementarlo correttamente nel sistema di compilazione (l'ho fatto per il nostro team in CMake), ma una volta fatto accelera automagicamente le cose per i nostri server di integrazione continua. A seconda del numero di binari che il tuo sistema di generazione sta distribuendo, puoi ottenere da 1 a 2 ordini di miglioramento della grandezza. Il tuo chilometraggio può variare. Nel nostro caso penso che abbia accelerato la tripla build di Windows e quella di Windows di circa un fattore 10, ma abbiamo molte librerie ed eseguibili condivisi (che diminuiscono i vantaggi di una build unitaria).

Come costruisci il tuo grande progetto multipiattaforma? Se si utilizzano makefile comuni per Linux e Windows, è possibile degradare facilmente le prestazioni di Windows di un fattore 10 se i makefile non sono progettati per essere veloci su Windows.

Ho appena corretto alcuni makefile di un progetto multipiattaforma usando makefile comuni (GNU) per Linux e Windows. Make sta iniziando un sh.exeprocesso per ogni riga di una ricetta che causa la differenza di prestazioni tra Windows e Linux!

Secondo la GNU fare la documentazione

.ONESHELL:

dovrebbe risolvere il problema, ma questa funzione non è (attualmente) supportata per Windows. Quindi riscrivere le ricette su singole righe logiche (ad es. Aggiungendo; \ o \ alla fine delle righe dell'editor correnti) ha funzionato molto bene!

IMHO questo è tutto sulle prestazioni di I / O del disco. L'ordine di grandezza suggerisce che molte delle operazioni vanno su disco sotto Windows mentre sono gestite in memoria sotto Linux, ovvero Linux sta migliorando la memorizzazione nella cache. L'opzione migliore in Windows sarà quella di spostare i tuoi file su un disco veloce, un server o un filesystem. Prendi in considerazione l'acquisto di un'unità a stato solido o lo spostamento dei file su un ramdisk o un server NFS veloce.

Ho eseguito i test di attraversamento della directory e i risultati sono molto vicini ai tempi di compilazione riportati, suggerendo che ciò non ha nulla a che fare con i tempi di elaborazione della CPU o con gli algoritmi del compilatore / linker.

Tempi misurati come suggerito sopra attraversando l'albero delle directory di cromo:

• Windows Home Premium 7 (8 GB di RAM) su NTFS: 32 secondi
• Ubuntu 11.04 Linux (2 GB di RAM) su NTFS: 10 secondi
• Ubuntu 11.04 Linux (2 GB di RAM) su ext4: 0,6 secondi

Per i test ho estratto le fonti di cromo (entrambe in win / linux)

git clone http://github.com/chromium/chromium.git 
cd chromium
git checkout remotes/origin/trunk 

Per misurare il tempo che ho corso

ls -lR > ../list.txt ; time ls -lR > ../list.txt # bash
dir -Recurse > ../list.txt ; (measure-command { dir -Recurse > ../list.txt }).TotalSeconds  #Powershell

Ho disattivato i timestamp di accesso, il mio scanner antivirus e aumentato le impostazioni del gestore della cache in Windows (> 2 GB di RAM), il tutto senza alcun miglioramento evidente. Il fatto è che Linux ha funzionato 50 volte meglio di Windows con un quarto della RAM.

Per chiunque voglia sostenere che i numeri sono sbagliati, per qualsiasi motivo, provalo e pubblica i tuoi risultati.

Prova a usare jom invece di nmake

Scarica qui: https://github.com/qt-labs/jom

Il fatto è che nmake utilizza solo uno dei tuoi core, jom è un clone di nmake che utilizza processori multicore.

GNU lo rende pronto all'uso grazie all'opzione -j, che potrebbe essere una ragione della sua velocità rispetto a Microsoft nmake.

jom funziona eseguendo in parallelo diversi comandi make su processori / core diversi. Prova te stesso e senti la differenza!

Voglio aggiungere solo un'osservazione usando Gnu make e altri strumenti dagli strumenti MinGW su Windows: sembrano risolvere i nomi host anche quando gli strumenti non possono nemmeno comunicare via IP. Immagino che questo sia causato da una routine di inizializzazione del runtime di MinGW. L'esecuzione di un proxy DNS locale mi ha aiutato a migliorare la velocità di compilazione con questi strumenti.

Prima ho avuto un grosso mal di testa perché la velocità di costruzione è diminuita di un fattore di circa 10 quando ho aperto una connessione VPN in parallelo. In questo caso tutte queste ricerche DNS sono passate attraverso la VPN.

Questa osservazione potrebbe applicarsi anche ad altri strumenti di compilazione, non solo basati su MinGW e potrebbe essere cambiata nell'ultima versione di MinGW nel frattempo.

Recentemente ho potuto archiviare un altro modo per accelerare la compilazione di circa il 10% su Windows usando Gnu make sostituendo mingw bash.exe con la versione di win-bash

(Win-bash non è molto a suo agio per quanto riguarda l'editing interattivo.)