I compilatori Intel sono davvero migliori di quelli Microsoft? [chiuso]

Anni fa, sono stato sorpreso quando ho scoperto che Intel vende compilatori compatibili con Visual Studio. L'ho provato in particolare per C / C ++ e per fantastici strumenti diagnostici. Ma il codice non era semplicemente così intenso dal punto di vista computazionale da notare la differenza. L'unica impressione è stata: Intel l'ha fatto davvero per me proprio ora, wow, strumenti straordinari con risoluzione di nanosecondi, incredibile. Ma il processo è terminato e il team non ha mai preso in seria considerazione un acquisto.

In base alla tua esperienza, se il costo della licenza non ha importanza, quale fornitore è il vincitore?

Non è una domanda ampia o vaga o tentare di innescare una guerra santa. Questo tipo di domanda riguarda due strumenti molto visibili. A nessuno piace quando gli strumenti hanno misteri o sorprese. E le scelte tra il meglio e il migliore sono sempre il dolore. Capisco anche che l'erba è sempre argomento più verde . Voglio ascoltare tutte le storie "what ifs".

Cosa succederebbe se Intel lo ottimizzasse localmente per il chip stepping del mese e non tutti i target hardware funzionassero così come compilati da Microsoft? Cosa succede se l'hardware AMD è l'obiettivo e tutto rallenterà senza motivo? O d'altra parte, cosa succede se l'hardware di Intel ha così tante opportunità impercettibili, che gli autori di compilatori Microsoft sono troppo lenti da adottare e non implementano mai nel compilatore? Che cosa succede se entrambi sono esattamente uguali, in realtà un unico codice base racchiuso in due scatole diverse e concesso in licenza a entrambi i fornitori da un negozio di terze parti?

E così via. Ma qualcuno conosce alcune risposte.

ATTENZIONE: risposta basata sulla propria esperienza - YMMV

Se il codice è davvero costoso dal punto di vista computazionale, sì, sicuramente . Ho visto un miglioramento di oltre 20 volte con l'ex compilatore Intel C ++ (ora Intel Studio se ricordo bene) rispetto al compilatore standard Microsoft Visual C ++. È vero che il codice era ben lungi dall'essere perfetto e che potrebbe aver giocato un ruolo (in realtà è per questo che ci siamo preoccupati di usare il compilatore Intel, era più semplice che refactoring della base di codice gigante), anche la CPU utilizzata per eseguire il codice era un Intel Core 2 Quad, che è la CPU perfetta per una cosa del genere, ma i risultati sono stati scioccanti. Il compilatore stesso contiene una miriade di modi per ottimizzare il codice, incluso il targeting di una CPU specifica in termini, ad esempio, di funzionalità SSE . Fa vergognare -O2/ -O3scappare davvero . E quello eraprima di usare il profiler.

Si noti che, tuttavia, l'attivazione di ottimizzazioni davvero aggressive renderà la compilazione un po 'di tempo, due ore per un progetto di grandi dimensioni non è affatto impossibile. Inoltre, con alti livelli di ottimizzazione, c'è una maggiore possibilità che si manifesti un errore nel codice (questo può essere osservato anche con gcc -O3). Per un progetto che conosci bene, questo potrebbe essere un vantaggio, dal momento che troverai e correggerai eventuali bug che non hai catturato prima, ma quando compili un pasticcio peloso, basta incrociare le dita e pregare gli dei x86.

Qualcosa sulle prestazioni delle macchine AMD: non è buono come le CPU Intel, ma è comunque molto meglio del compilatore MS C ++ (di nuovo, per mia esperienza). Il motivo è che puoi anche scegliere come target una CPU generica con supporto SSE2 (ad esempio). Quindi le CPU AMD con SSE2 non saranno discriminate molto. Il compilatore Intel sulla CPU Intel ruba davvero lo spettacolo, però. Tuttavia, non sono tutti arcobaleni doppi e unicorni luccicanti. Ci sono state alcune accuse pesanti nei confronti dei binari che non funzionano affatto su CPU non GenuineIntel e (questo è ammesso) hanno indotto artificialmente prestazioni inferiori sulle CPU da altri fornitori. Si noti inoltre che si tratta di informazioni di almeno 3 anni fa e che la loro validità al momento non è nota, MA le descrizioni dei nuovi prodotti danno ai binari una carta bianca per funzionare più lentamente di quanto Intel ritenga opportuno utilizzare CPU non Intel.

Non so di cosa si tratti su Intel e perché creino strumenti di calcolo numerico così buoni, ma dai un'occhiata anche a questo: http://julialang.org/ . C'è un confronto e se guardi l'ultima riga, MATLAB brilla sconfiggendo sia il codice C che Julia , ciò che mi colpisce è che gli autori pensano che il motivo sia la Intel Kernel Library di Intel .

Mi rendo conto che suona molto come un annuncio pubblicitario per Intel Compiler Toolkit, ma nella mia esperienza ha fatto davvero bene il lavoro, e anche la semplice logica impone che i ragazzi che producono CPU dovrebbero sapere meglio come programmare per loro. IMO, il compilatore Intel C ++ comprime ogni possibile miglioramento delle prestazioni.

Intel Compiler ha la reputazione di produrre codice numerico molto efficiente:

https://stackoverflow.com/questions/1733627/anyone-here-has-benchmarked-intel-c-compiler-and-gcc

http://www.open-mag.com/754088105111.htm

http://www.freewebs.com/godaves/javabench_revisited/

Nota che non sostengo che sia il compilatore più veloce in circolazione, ma gode sicuramente di un'ottima reputazione per efficienza. Si noti che gli autori dei binari LAPACK "ufficiali" per Windows usano il compilatore Intel Fortran per costruirli: http://icl.cs.utk.edu/lapack-for-windows/ e dovrebbero sapere qualcosa o due sull'efficienza.

Intel C ++ ha un paio di vantaggi rispetto a gcc oltre al generatore di codice. Entrambi derivano (in gran parte) dal fatto che si basa sul front-end EDG . Nel bene e nel male, entrambi si stanno erodendo (lentamente), quindi i vantaggi non sono così grandi come una volta.

Il primo è che di regola emette messaggi di errore molto migliori. Potresti voler dare un confronto tra i messaggi di errore tra Clang e gcc. Intel C ++ (insieme alla maggior parte degli altri basati sul front-end EDG) da anni fornisce una diagnostica simile a quella di Clang.

In secondo luogo, il front-end EDG è famoso per la sua eccezionale conformità linguistica, come il generatore di codice Intel è per la produzione di codice veloce. Con quasi tutte le misure ragionevoli, il front-end EDG offre una migliore conformità con C ++ 98, 03 o (nelle versioni correnti) C ++ 0x rispetto a qualsiasi altro compilatore disponibile.

Come ho detto, entrambi questi vantaggi si sono erosi in varia misura nel tempo. Le versioni recenti di gcc hanno una conformità linguistica abbastanza decente. Clang ha messaggi di errore sostanzialmente migliori e sta facendo buoni progressi anche nell'implementazione dell'intero linguaggio C ++. Tuttavia, Intel C ++ è ancora meglio di uno dei due aspetti, ed è un singolo pacchetto che fa la maggior parte delle cose invece di aver bisogno di un compilatore per una buona diagnostica e un altro per una migliore conformità e generazione di codice.

Ci abbiamo provato al lavoro qualche tempo fa. La maggior parte della nostra base di codice è in Delphi, ma abbiamo alcune funzionalità ad alta intensità di calcolo che qualcuno pensava che sarebbe stata una buona idea fare in una DLL C ++ quando. E uno dei miei colleghi aveva sentito grandi cose sul compilatore Intel, quindi ha deciso di provarlo. Abbiamo ricostruito la DLL nel compilatore Intel ed eseguito alcuni test di velocità, e i risultati lo hanno sorpreso così tanto che ha pensato che dovesse fare qualcosa di sbagliato.

La DLL deve calcolare alcuni problemi molto difficili con componenti combinatori e di topologia, che sono tecnicamente nella classe di difficoltà NP se li facessimo "giusti", ma usiamo varie euristiche per evitare le prestazioni NP. Anche così, ci sono molti scricchiolii in corso. E per i test che abbiamo eseguito, la differenza tra il compilatore VS e il compilatore Intel era all'interno di epsilon o il compilatore Intel era notevolmente più lento, generalmente da qualche parte nelle vicinanze del 20%. Ed è rimasto così, indipendentemente dalle modifiche apportate alle impostazioni di compilazione per cercare di ottenere il codice più veloce dal compilatore Intel. Quindi abbiamo finito per non passare ad esso.

Questo è solo un esempio del mondo reale, ovviamente. Il tuo chilometraggio può variare.

In un'applicazione embedded su cui ho lavorato una volta, una versione di prova di un compilatore Intel ha dimostrato che ci risparmierebbe di dover girare nuovo hardware con prestazioni più elevate. Il costo del nuovo hardware era di circa $ 10 / unità, vendite previste di 1 milione di unità, Aggiungi costi di sviluppo e ritardi nel progetto. L'opzione 2 era un profilo / micro ottimizza una base di codice già ragionevolmente ben profilata / ottimizzata - risultati sconosciuti, tempo sconosciuto.

Cosa pensi che abbia detto il capo quando abbiamo chiesto i fondi per acquistare il compilatore .......

Tuttavia, questo è stato un caso molto fortunato e più raro: l'output del codice del 10% più veloce dal compilatore Intel ci ha riportato sul lato corretto delle prestazioni. Se fossimo già dalla parte giusta, o avessimo superato il 10%, non avrebbe fatto differenza. Se avessimo avuto gli ingegneri probabilmente avremmo potuto ottimizzare il codice e salvare lo spin hardware e non aver bisogno del compilatore Intel, ma il rischio era elevato e il compilatore Intel si è comportato in modo più economico del tempo di progettazione.

A conti fatti, direi che è una forma di micro ottimizzazione - non farlo fino a quando non sai che è necessario, e quindi, solo dopo aver profilato e trovato la vera causa dei problemi. È una scelta particolarmente buona del tuo profilo che mostra che sei lento "ovunque" e non hai il collo di bottiglia identificato.

Ho riscontrato solo tre vantaggi:

1. Ha il supporto per le funzionalità delle nuove CPU Intel molto prima di altri compilatori.

2. È un ottimo compilatore aggiuntivo per emettere avvisi e rilevare problemi che mancano ad altri compilatori. GCC rileva alcune cose che ICC non fa e viceversa. Visual Studio cattura alcune cose che ICC non fa e viceversa.

3. Fa un lavoro molto migliore dei cicli di auto-parallelizzazione (distribuendoli automaticamente su più thread) rispetto a qualsiasi altro compilatore. Non molto vantaggio del codice da questo, ma quando si dispone di codice che lo fa, può fare la differenza.

Usiamo il compilatore Intel per ogni progetto critico per le prestazioni della nostra base di codice. La cosa grandiosa è che rende l'ottimizzazione del codice davvero mantenibile. Invece di aggiungere manualmente __mm chiamate dappertutto e dire al compilatore di precaricare i dati, che saranno di nuovo subottimali nella prossima versione, devi semplicemente riorganizzare il tuo codice e ottenere una folle accelerazione.

Spesso, il codice ottimizzato è più facile da seguire rispetto all'ottimizzazione manuale, è più veloce dell'ottimizzazione manuale e quando viene rilasciato un nuovo set di istruzioni, il compilatore utilizzerà tale set di istruzioni. È fantastico.

Lo stesso vale anche per il compilatore arm (da arm, non da Intel), se rilasci su arm, fa un ottimo lavoro nel vettorializzare per te.

Controlla questa pagina di riferimento. In breve, Intel vince.

Ma il margine potrebbe non essere così grande: se compili a 32 bit e il tuo sistema di build non supporta l'ottimizzazione guidata del profilo, il guadagno è dell'ordine del 10%. Un tale miglioramento vale la pena e i tempi di compilazione più lunghi?

È stato detto che Intel ha rilasciato il compilatore Intel C ++ v13.0 per sistema operativo Android, il suo primo tentativo di fornire un compilatore C / C ++ ottimizzato progettato specificamente per la piattaforma mobile di Google.

Gli sviluppatori possono utilizzare il compilatore su sistemi basati su Linux * per creare app per dispositivi Android basati su processori Intel, incluso il processore Intel® Atom ™. Il compilatore Intel è compatibile con GNU C ++ e strumenti di sviluppo in Android Native Development Kit (NDK). Non è possibile utilizzare il compilatore su qualsiasi macchina di sviluppo. Né Windows né OS X sono supportati; gli strumenti sono certificati solo per l'uso con Ubuntu 10.04 o 11.04

La versione corrente di Android NDK utilizza per impostazione predefinita la versione 4.6 della toolchain GCC (Open Source Collection) Gnu Compiler. Ma i compilatori Intel includono molte ottimizzazioni proprietarie per i propri chip e spesso possono generare codice eseguibile che funziona meglio di quello prodotto da compilatori di terze parti come GCC.