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

ATTENZIONE: risposta basata sulla propria esperienza - YMMV

Se il codice è davvero dispendioso dal punto di vista computazionale, sì, sicuramente . Ho visto un miglioramento di oltre 20 volte x con il precedente compilatore Intel C ++ (ora Intel Studio se ricordo correttamente) rispetto al compilatore Microsoft Visual C ++ standard. È 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, è stato più semplice del refactoring del codebase 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. Lo stesso compilatore contiene una miriade di modi per ottimizzare il codice, incluso il targeting di una specifica CPU in termini di, ad esempio, funzionalità SSE . Fa veramente vergognare -O2 / -O3 . E questo era prima usando il profiler.

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

Qualcosa sulle prestazioni delle macchine AMD: non è buono come le CPU Intel, ma è ancora modo migliore del compilatore MS C ++ (di nuovo, dalla mia esperienza). Il motivo è che puoi anche indirizzare una CPU generica con il supporto SSE2 (per esempio). Quindi le CPU AMD con SSE2 non saranno discriminate molto. Il compilatore Intel su CPU Intel ruba davvero lo spettacolo, però. Comunque non sono tutti arcobaleni doppi e unicorni splendenti. Ci sono state pesanti accuse sui binari che non funzionano affatto su CPU non Genuine Intel e (questa è ammessa) prestazioni inferiori indotte artificialmente su CPU di altri fornitori . Si noti inoltre che si tratta di informazioni di almeno 3 anni fa e la sua validità è sconosciuta, ma le nuove descrizioni dei prodotti offrono ai binari una carta bianca da eseguire con la stessa lentezza che Intel considera adatta alle CPU non Intel.

Non so cosa sia Intel e perché facciano strumenti di calcolo numerico così buoni, ma diamo un'occhiata anche a questo: link . 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 Math Kernel Library .

Mi rendo conto che sembra molto simile a un annuncio per il toolkit Intel Compiler, ma nella mia esperienza ha fatto davvero bene il lavoro, e anche la semplice logica impone che i ragazzi che fanno le CPU debbano sapere come programmare meglio per loro. IMO, il compilatore Intel C ++ stringe ogni possibile aumento di prestazioni possibile.

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

link

link

link

Si noti che non ritengo che sia il compilatore più veloce, ma sicuramente gode di un'ottima reputazione per l'efficienza. Nota che gli autori dei binari "ufficiali" di LAPACK per Windows usano il compilatore Intel Fortran per costruirli: link e dovrebbero sapere una cosa o due sull'efficienza.

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

Il primo è che emette di solito messaggi di errore molto migliori. Potresti voler consultare un confronto di messaggi di errore tra Clang e gcc. Intel C ++ (insieme alla maggior parte degli altri basati sul front-end EDG) ha rilasciato strumenti diagnostici simili a quelli di Clang per anni.

In secondo luogo, il front end EDG è altrettanto noto per una conformità linguistica eccezionalmente buona come il generatore di codice Intel è per la produzione di codice veloce. Quasi ogni misura ragionevole, il front-end EDG fornisce una migliore conformità con C ++ 98, 03, o (nelle versioni correnti) C ++ 0x di qualsiasi altro compilatore disponibile.

Come ho detto, entrambi questi vantaggi si sono ridotti a vari livelli nel tempo. Le versioni recenti di gcc hanno una conformità linguistica abbastanza decente. Clang ha messaggi di errore sostanzialmente migliori e sta compiendo buoni progressi verso l'implementazione dell'intero linguaggio C ++. Tuttavia, quando si arriva fino a questo punto, Intel C ++ è ancora migliore di entrambi in entrambi i casi, ed è un singolo pacchetto che fa la maggior parte delle cose giuste invece di aver bisogno di un compilatore per una buona diagnostica e un altro per una migliore conformità e generazione di codice. / p>     

Abbiamo provato questo al lavoro un po 'di tempo fa. La maggior parte del nostro codebase è in Delphi, ma abbiamo alcune funzionalità altamente intensive che qualcuno pensava sarebbe stata una buona idea fare in un 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 e abbiamo eseguito alcuni test di velocità, ei risultati lo hanno sorpreso così tanto che ha pensato che doveva fare qualcosa di sbagliato.

La DLL deve calcolare alcuni problemi molto complessi con i componenti della combinatoria e della topologia, che sono tecnicamente nella classe di difficoltà NP-hard se li abbiamo fatti "bene", ma usiamo varie euristiche per evitare le prestazioni NP. Anche così, c'è un sacco di numeri in corso. E per i test che abbiamo eseguito, la differenza tra il compilatore VS e il compilatore Intel era o all'interno di epsilon, o il compilatore Intel era notevolmente più lento, generalmente da qualche parte nell'intorno del 20%. E rimase così, indipendentemente dalle modifiche apportate alle impostazioni di compilazione, per cercare di ottenere che il compilatore Intel producesse codice più veloce. Quindi abbiamo finito per non passare ad esso.

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

In un'applicazione incorporata su cui ho lavorato una volta, una versione di prova di un compilatore Intel ha dimostrato che ci avrebbe risparmiato la necessità di eseguire il nuovo hardware con prestazioni più elevate. Il costo del nuovo hardware era di circa $ 10 / unità, le vendite previste di 1 milione di unità, l'aggiunta di costi di sviluppo e ritardi del progetto. L'opzione 2 era un profilo / micro ottimizzare una base di codice già sufficientemente ben definita / ottimizzata - risultati sconosciuti, tempo sconosciuto.

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

Tuttavia - questo è stato un caso limite molto fortunato e raro - l'output di codice del 10% più veloce del compilatore Intel ci ha spinto verso il lato corretto delle prestazioni. Se fossimo già dalla parte giusta, o fossero superiori del 10%, non avrebbe fatto la differenza. Se avessimo avuto gli ingegneri probabilmente avremmo potuto ottimizzare il codice e aver salvato la rotazione dell'hardware e non aver avuto bisogno del compilatore Intel, ma il rischio era elevato e il compilatore Intel ha funzionato meno del tempo di progettazione.

A conti fatti direi che è una forma di micro-ottimizzazione - non farlo finché non sai di averne bisogno, e poi, solo dopo averlo profilato e trovato la vera causa dei problemi. È una scelta particolarmente buona del tuo profilo indica che sei lento "ovunque" e non hai colli di bottiglia identificati.

Ho riscontrato solo tre vantaggi:

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

2. È un ottimo compilatore aggiuntivo per emettere avvisi e problemi di cattura che gli altri compilatori mancano. GCC prende alcune cose che ICC non ha, e viceversa. Visual Studio prende alcune cose che ICC non ha, e viceversa.

3. Fa un lavoro molto migliore dei cicli di parallelizzazione automatica (distribuendoli su più thread automaticamente) rispetto a qualsiasi altro compilatore. Non molto codice ne trae beneficio, ma quando hai un codice che lo fa, può fare una bella differenza.

Usiamo il compilatore intel per ogni progetto critico di performance del nostro codebase. La cosa grandiosa è che rende il codice di ottimizzazione davvero mantenibile. Invece di aggiungere manualmente le chiamate __mm ovunque e di dire al compilatore di precaricare i dati, che saranno tutti sub ottimali nella prossima versione di nuovo, basta riorganizzare il codice e ottenere una velocità folle.

Spesso, il codice ottimizzato è più facile da seguire rispetto alla mano ottimizzata, è più veloce della mano ottimizzata, e quando un nuovo set di istruzioni è rilasciato, il compilatore userà quella serie di istruzioni. È fantastico.

Lo stesso vale anche per il compilatore di bracci (da braccio, non da Intel), se il tuo rilascio a braccio fa un ottimo lavoro nel vettorizzare 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 costruzione non supporta l'ottimizzazione guidata del profilo, il guadagno è dell'ordine del 10%. Un tale miglioramento vale la pena e tempi di compilazione più lunghi?

È stato detto che Intel ha rilasciato Intel C ++ Compiler v13.0 per il 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 gli strumenti di sviluppo nell'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 la versione 4.6 della toolchain open source Gnu Compiler Collection (GCC) per impostazione predefinita. Ma i compilatori di Intel includono molte ottimizzazioni proprietarie per i propri chip e possono spesso generare codice eseguibile che offre prestazioni migliori rispetto a quelle prodotte da compilatori di terze parti come GCC.