Newsgroup: it.comp.hardware.cpu
Titolo: Confronto tra compilatori Intel, Microsoft e GCC con FX, PII ed i7

Su Hardware.fr un'articolo sui compilatori Intel,
Microsoft e GCC , con confonto prestazionale
con le CPU AMD FX-8150, Phenom II X4 975
ed Intel Core i7-2600K.
http://www.hardware.fr/articles/847-1/impact-compilateurs-architectures-cpu-x86-x64.html
 
 
Riassumo solo due tabelle, i test con C-Ray ed h264
presi dalla suite SPEC ma se qualcuno trova dei risultati
eclatanti che stravolgono i risultati, e' invitato a segnalarli.
 
Premetto che l'intento non e' quello di aprire l'ennesimo
flame Intel-vs-AMD (tanto non se ne esce piu') ma di
stabilire quale  combinazione CPU/compilatore/flag
offre i risultati migliori: come punto di partenza ho
indicato il flag del compilatore comune a tutte le CPU
(confronto diretto) ed in caso di sensibili variazioni anche
il flag specifico con prestazioni migliori (confronto tra
ottimizzazioni e non).
 
Iniziamo con il rendering , C-Ray (Multithread, Floating)
tempi in secondi:
 
GCC : C-RAY (flag "barcelona" comune a tutte le CPU)
40 sec - Intel Core i7-2600K 3,4GHz (4 core/8 thread)
45 sec *** AMD FX-8150 (flag "bdver1" -10%)
49 sec - AMD FX-8150 3,6Ghz (4 moduli/8 thread)
77 sec - AMD Phenom II X4 975 3,6GHz (4 core/4 thread)
 
Intel : C-RAY (flag "SSE2" , "SSE3")
12 sec - i7-2600K
14 sec - FX-8150
19 sec - X4 975
 
Microsoft : C-RAY (flag "SSE2")
13 sec - i7-2600K
16 sec - FX-8150
21 sec - X4 975
 
Con il rendering Il compilatore GCC e' 3-4 volte piu' lento
degli altri due .
 
Passiamo alla codifica video con h264ref
(Multithread,  Interi) tempi in secondi:
 
GCC : h264ref (opzioni base per tutte le CPU)
546 sec - Intel Core i7-2600K 3,4GHz (4 core/8 thread)
872 sec - AMD FX-8150 3,6Ghz (4 moduli/8 thread)
879 sec - AMD Phenom II X4 975 3,6GHz (4 core/4 thread)
 
GCC : h264ref (flag specifici per le singole CPU)
533 sec *** Intel Core i7-2600K (flag "corei7avx" -3%)
847 sec *** AMD Phenom II X4 975 (flag "barcelona" -4%)
879 sec *** AMD FX-8150 (flag "bdver1" +1%)
 
Note: pochissime differenze con le ottimizzazioni
 
Intel : h264ref (opzioni base per tutte le CPU)
585 sec - i7-2600K
610 sec - X4 975
790 sec - FX-8150
 
Intel : h264ref (flag specifici per le singole CPU)
570 sec - i7-2600K (flag "AVX.D" -3%)
608 sec - X4 975 (flag "SSE2" )
787 sec - FX-8150  (flag "AVX.D")
 
Note : anche qui pochissime differenze con le ottimizzazioni
 
Microsoft : h264ref (opzioni base per tutte le CPU)
514 sec - i7-2600K
832 sec - X4 975
832 sec - FX-8150
 
In questo test con gli interi l'architettura Bulldozer paga
dazio anche nei confronti del K10 . Analizziando i
migliori risultati ottenibili con ogni CPU si nota
che paradossalmente il compilatore Intel favorisce
l'X4 , solo il 6% di differenza rispetto al 2600K (migliore) ,
divario che sale al 40% con i compilatori Microsoft
e GCC (!).
 
La piattaforma software e' Windows 7 SP1 con tutte le patch
e gli hotfix per AMD FX . Il comportamento su Linux lo
avevamo gia' affrontato mesi fa, si possono trovare su
Google Gruppi o direttamente sul sito Phoronix .
 
 
Interessanti le conclusioni (traduzione "grossolana" con Google) :
http://tinyurl.com/6sg9xsb
 
 
"Ma possiamo dare la colpa agli sviluppatori che passano? Questo è davvero
il cuore del problema. Se offriamo uno sviluppatore la possibilità di
utilizzare un compilatore "equo" contro un altro che porterà le prestazioni
del 35% in più per gli utenti di AMD, prestazioni e 54% in più per gli
utenti di processori Intel, dobbiamo la colpa di scegliere un compilatore
che accelererà in entrambi i casi i suoi utenti, certamente un modo
partigiano? "
 
"E per quanto riguarda l'utente di AMD in questo caso? Lui preferisce una
versione lenta e fiera, o un po 'più forte sapendo che andrà a beneficio
degli utenti più processori concorrenti? In pratica, al di fuori del mondo
dell'open source, lo farà in ogni caso non per dare consigli. Gli utenti di
applicazioni commerciali devono essere sottoposti a scelte, buone o cattive,
realizzati dagli sviluppatori. "
 
"Allo stesso modo, le metriche di performance che portiamo nei nostri
processori comparativi sono influenzati dalle scelte fatte. Se scartare in
via di sviluppo i nostri benchmark protocolli troppo di parte - o quelli
raccomandati dai produttori - quando un processore molto popolare vantaggio
rispetto ad un altro modello di applicazione, misurare queste differenze
riflettono solo la finale , la realtà vissuta dagli utenti di questo
software. "
 
"La questione dell'equità è spessa e sottile soluzioni. L'evoluzione di
compilatori che producono codice gestito, l'immagine può essere la soluzione
LLVM, come una generalizzazione. NET. Tenendo presente che chi controlla la
macchina virtuale, in ultima analisi, il controllo della chiave di
performance su ciascuna delle architetture. Spostare un problema, non
significa necessariamente la soluzione ... "
 
Ricordo il link all'articolo su Hardware.fr :
http://www.hardware.fr/articles/847-1/impact-compilateurs-architectures-cpu-x86-x64.html
 
 
Ciao
Luca
 
 
 
 

<...megacut...>
 
Molto interessante, ringrazio per la buona lettura e per il sunto che mi 
ha sollevato dall'onere di sobbarcarmi una traduzione approssimativa dal 
gallico idioma.
 
 

 degli altri due .
 
Interessante. Un fattore 4 di differenza mi fa pensare che gcc abbia
problemi con l'autovettorizzazione. Intel e Microsoft devono riuscire
ad autovettorizzare su SSE/AVX, mentre gcc no. Oppure non hanno
proprio passato la flag a gcc, riportano esplicitamente le flag SSEx
per gli altri due ma non per gcc.