Quanto dovrei preoccuparmi del compilatore Intel C ++ che emette codice non ottimale per AMD?

Question

Siamo sempre stati un negozio Intel. Tutti gli sviluppatori utilizzano macchine Intel, la piattaforma consigliata per gli utenti finali è Intel e se gli utenti finali vogliono eseguire AMD è la loro vedetta. Forse il reparto test aveva una macchina AMD da qualche parte per verificare che non avessimo spedito nulla di completamente rotto, ma questo era tutto.

Fino a pochi anni fa abbiamo usato il compilatore MSVC e poiché non offre davvero molte opzioni di ottimizzazione del processore oltre il livello SSE, nessuno si preoccupava troppo se il codice potesse favorire un fornitore x86 rispetto a un altro. Tuttavia, più recentemente abbiamo usato molto il compilatore Intel. La nostra roba ottiene sicuramente alcuni significativi vantaggi in termini di prestazioni (sul nostro hardware Intel) e le sue capacità di vettorializzazione significano meno necessità di passare ad asm / intrinsics. Tuttavia, le persone stanno iniziando a preoccuparsi del fatto che il compilatore Intel non stia effettivamente facendo un buon lavoro per l'hardware AMD. Certamente se si entra nelle librerie Intel CRT o IPP si vedono molte query cpuid per apparentemente impostare tabelle di salto per funzioni ottimizzate. Tuttavia, sembra improbabile che Intel faccia molto fatica a fare qualcosa di buono per i chip AMD.

Chiunque abbia esperienza in questo settore può commentare se si tratta di un grosso problema o meno nella pratica? (Dobbiamo ancora eseguire test di prestazioni su AMD noi stessi).

Aggiornamento 2010-01-04 : Beh, la necessità di supportare AMD non è mai diventata abbastanza concreta per me da fare alcun test da solo. Ci sono alcune letture interessanti sul problema qui , qui e qui però

Aggiornamento 2010-08-09 : sembra che l'insediamento Intel-FTC abbia qualcosa da dire su questo problema - vedi " Compilers and Dirty Tricks " sezione di questo articolo .

Answer 1

Compra un box AMD ed eseguilo su quello. Sembra l'unica cosa responsabile da fare, piuttosto che fidarsi degli estranei su Internet;)

A parte questo, credo che parte della causa di AMD contro Intel si basi sull'affermazione che il compilatore Intel produce specificamente codice che funziona in modo inefficiente sui processori AMD. Non so se sia vero o no, ma AMD sembra crederlo.

Ma anche se non lo fanno intenzionalmente, non c'è dubbio che il compilatore Intel ottimizzi specificamente per i processori Intel e nient'altro.

Detto questo, dubito che farebbe un'enorme differenza. Le CPU AMD trarrebbero comunque vantaggio da tutta l'auto-vettorizzazione e da altre funzioni intelligenti del compilatore.

Answer 2

Quello che abbiamo visto è che ovunque il compilatore Intel debba fare una scelta di runtime in merito al set di istruzioni disponibile, se non riconosce una CPU Intel, va nel suo "standard" codice (che, come prevedibile, potrebbe non essere ottimale).

Nota che anche se ho usato la parola "compilatore" sopra, ciò accade principalmente nelle loro librerie (intrinseche) fornite e intrinseche che controllano il set di istruzioni e chiamano il codice migliore.

Answer 3

Sto sicuramente affermando l'ovvio, se le prestazioni sono cruciali per la tua applicazione, allora faresti meglio a fare dei test su tutte le combinazioni di hardware / compilatore. Non ci sono garanzie Come estranei, possiamo solo darti le nostre ipotesi / pregiudizi. Il tuo software potrebbe avere caratteristiche uniche che sono diverse da quelle che abbiamo visto.

La mia esperienza:

Lavoravo in Intel e sviluppavo un'applicazione interna (C ++) in cui le prestazioni erano fondamentali. Abbiamo provato a usare il compilatore C ++ di Intel, e sempre sotto gcc eseguito - anche dopo aver eseguito le esecuzioni del profilo, ricompilando usando le informazioni profilate (che icc presumibilmente usa per ottimizzare) e rieseguendo sullo stesso set di dati esatto (questo è stato nel 2005-2007, ora le cose potrebbero essere diverse). Quindi, in base alla mia esperienza, potresti voler provare gcc (oltre a icc e MSVC), è possibile che tu ottenga migliori prestazioni in questo modo e faccia da parte della domanda. Non dovrebbe essere troppo difficile cambiare compilatore (se il processo di compilazione è ragionevole).

Ora lavoro in una società diversa, e la gente IT fa test hardware approfonditi, e per un po 'l'hardware Intel e AMD è stato relativamente comparabile, ma l'ultima generazione di hardware Intel ha superato significativamente l'AMD. Di conseguenza, credo che abbiano acquistato quantità significative di CPU Intel e raccomandano lo stesso per i nostri clienti che eseguono il nostro software.

Ma torniamo alla domanda se il compilatore Intel abbia come target specifico l'hardware AMD per funzionare lentamente. Dubito che Intel si preoccupi di questo. È possibile che alcune ottimizzazioni che utilizzano la conoscenza dei componenti interni dell'architettura o dei chipset della CPU Intel possano funzionare più lentamente sull'hardware AMD, ma dubito che abbiano come target specifico l'hardware AMD.

Answer 4

Scusa se hai premuto il mio pulsante generale.

Questo è in tema di ottimizzazione di basso livello, quindi è importante solo per il codice in cui 1) il contatore del programma impiega molto tempo e 2) che il compilatore vede effettivamente. Ad esempio, se il PC trascorre la maggior parte del tempo nelle routine di libreria che non si compilano, non dovrebbe importare molto.

Se condizioni 1 & amp; 2 sono soddisfatti, ecco la mia esperienza su come va l'ottimizzazione:

Vengono eseguite diverse iterazioni di campionamento e fissaggio. In ognuno di questi, viene identificato un problema e molto spesso non riguarda la posizione del contatore del programma. Piuttosto è che ci sono chiamate di funzione a medio livello dello stack di chiamate che, poiché le prestazioni sono di primaria importanza, potrebbero essere sostituite. Per trovarli rapidamente, lo faccio .

Tieni presente che se è presente un'istruzione di chiamata di funzione che è in pila per una frazione significativa del tempo di esecuzione, sia in alcune chiamate lunghe, sia in molte brevi, quella chiamata è responsabile di quella frazione di tempo , quindi rimuoverlo o eseguirlo meno spesso può far risparmiare molto tempo. E quel risparmio supera di gran lunga qualsiasi ottimizzazione di basso livello.

Ora il programma può essere molte volte più veloce di quanto non fosse inizialmente. Non ho mai visto un programma di buone dimensioni, non importa quanto accuratamente scritto, che non potesse beneficiare di questo processo. Se il processo non è stato eseguito, non si deve presumere che l'ottimizzazione di basso livello sia l'unico modo per accelerare il programma.

Dopo che questo processo è stato fatto al punto in cui semplicemente non può più essere fatto e se gli esempi mostrano che il PC è nel codice che il compilatore vede, allora l'ottimizzazione di basso livello può fare la differenza.

Answer 5

Al momento dell'avvio di questo thread, Microsoft C ++ passava automaticamente alla generazione del codice, che in alcuni casi era buona per AMD e cattiva per Intel. I loro compilatori più recenti passano automaticamente all'opzione di fusione che è buona per entrambi, in particolare dopo che entrambi i marchi di CPU hanno risolto i loro peculiari bug di prestazione. Quando ho lavorato per la prima volta in Intel, i loro compilatori hanno riservato alcune ottimizzazioni per le impostazioni dell'architettura specifiche di Intel. Immagino che potrebbe essere stato un argomento di alcune deposizioni FTC, anche se non è emerso nelle mie 10 ore di testimonianza, e la pratica era già in via di uscita a causa della convergenza dei requisiti di ottimizzazione tra i modelli di CPU aggiornati e il necessità di un uso più produttivo dei tempi di sviluppo del compilatore. Se hai utilizzato uno di quei compilatori obsoleti su una CPU Intel aggiornata, potresti riscontrare alcune delle stesse carenze di prestazioni.

Answer 6

È inutile preoccuparsi se non si può agire. Le azioni possibili sono: non acquistare AMD o utilizzare un compilatore diverso. Quindi le cose ovvie da fare sono:

(1) Acquista una scatola AMD e misura la velocità del codice compilato con il compilatore Intel. È abbastanza veloce? Se sì, hai finito, puoi acquistare AMD, non ti preoccupare.

(2) Se no: compila il codice con un altro compilatore ed eseguilo nella casella AMD. È abbastanza veloce? Se no, hai finito, non puoi acquistare AMD, non ti preoccupare.

(3) Se sì: esegui lo stesso codice su un box Intel. È abbastanza veloce? Se sì, hai finito, puoi acquistare AMD ma devi cambiare compilatore, non preoccuparti.

(4) In caso negativo: le possibilità sono: non acquistare AMD, buttare fuori tutti i computer Intel o compilare con due diversi compilatori. Sceglierne uno.

Answer 7

Ho sperimentato direttamente un paralizzante intenzionale della tecnologia quando un fornitore ha tentato di impedire a un prodotto Lotus di raggiungere il mercato prima della sua offerta. Era disponibile una tecnologia funzionante, ma a Lotus era proibito usarla. Ah bene ...

Qualche anno fa c'erano blog che mostravano agli utenti che l'applicazione di patch a un singolo byte nel compilatore Intel lo faceva emettere "ottimale" codice che non è stato paralizzato quando utilizzato su AMD. Non ho cercato quelle voci di blog da anni.

Sono propenso a credere che tale comportamento competitivo continui. Non ho altre prove da offrire.