Due Core, una FPU
L'unità in virgola mobile condivisa è separata dalle pipeline integer. Quindi quando le operazioni arrivano all'interfaccia dispatch alla fine dello stadio di decodifica, dirette alle unità integer, le operazioni in virgola mobile presenti nel flusso d'informazioni vengono deviate allo scheduler (programma le operazioni) in virgola mobile. Qui entrano in competizione per le risorse e il bandwith indipendente del thread a cui appartengono.
Come potete vedere nel diagramma sotto, la logica a virgola mobile di AMD è differente dal lato integer. Il suo scopo è di sola esecuzione; riporta le informazioni di completamento e le eccezioni nuovamente al core integer originario, che è responsabile per il ritiro dell'istruzione.
L'unità in virgola mobile ha due pipeline MMX e un paio di unità fused multiply-accumulate (FMAC) a 128 bit. Queste pipeline FMAC possono gestire istruzioni a quattro operandi, che danno un risultato non destabilizzante. Intel, da parte sua, pensa di incorporare il formato a tre operandi nella propria microarchitettura Haswell (quella che seguirà Ivy Bridge), mentre AMD afferma che aggiungerà le FMA3 nel successore di Bulldozer, chiamato Piledriver, atteso nel 2012.
Clicca per ingrandire
Ogni volta che vediamo produttori prendere decisioni divergenti come questa, ci chiediamo quale impatto avranno sugli sviluppatori. Quindi abbiamo chiesto ad Adrian Silasi di SiSoftware che cosa dobbiamo aspettarci che accada e lui ci ha detto che la maggioranza degli sviluppatori non vuole implementare codici tripli (uno per AVX, uno per AVX più FMA3, e uno per AVX più FMA4). E quando considerate che poche applicazioni sfruttando oggi l'AVX e nessuna usa l'FMA, AMD dovrebbe essere in una posizione migliore per supportare i tre path quando Piledriver diventerà realtà .
La domanda più pressante oggi è come sarà il supporto AVX in Bulldozer rispetto a quello Intel? Sandy Bridge vi dà due operazioni AVX a 256 bit per clock, mentre Bulldozer ne una sola.
Prima di questo articolo abbiamo parlato con Noel Borthwick, CTO di Cakewalk Inc., su come la sua azienda abbia lavorato ottimizzando Sonar X1 per AVX. Secondo un documento di cui Noel è co-autore, il supporto all'istruzione AVX aiuta a ridurre il carico software applicato quando si effettuano audio bit depth conversation mentre si effettua lo streaming di buffer audio attraverso un grafico di riproduzione, rendering e mixing - per chi è a digiuno di audio digitale, si tratta di operazioni molto impegnative. Le conversioni comuni includono integer a 24 bit fino a 32 bit in virgola mobile, la conversione in doppia precisione a 64-bit, e una in virgola a 32-bit verso una a doppia precisione a 64-bit.
Al tal fine Noel ci ha inviato il codice di un'applicazione di prova, che mette a confronto due routine Cakewalk ottimizzate per AVX con una non ottimizzata. AMD e Intel hanno accesso alla stessa metrica, quindi i risultati non dovrebbero sorprendere nessuna delle due aziende.
| Architettura | Operazione | Risultato (cicli di CPU gudagnati/persi) |
|---|---|---|
| AMD Bulldozer | Copy Int24toFloat64 | Guadagno del 69% |
| AMD Bulldozer | Copy Float32toFloat64 | Perdita del 77% |
| Intel Sandy Bridge | Copy Int24toFloat64 | Guadagno del 61% |
| Intel Sandy Bridge | Copy Float32toFloat64 | Guadagno del 14% |
Nell'operazione Copy Int24toFloat64, il Core i7-2600K di Intel ha un guadagno del 61%, mentre l'FX-8150 di AMD realizza un guadagno del 69%. Che cosa costituisce questo guadagno? Stiamo parlando del numero di cicli della CPU che AVX aiuta a ridurre, portando a un incremento nel bandwidth potenziale del processore. Formulata in modo diverso, Sandy Bridge riduce il numero di cicli di 1.61 volte, mentre Bulldozer di 1.69 volte.
D'altra parte, nell'operazione Copy Float32toFloat64, il Core i7-2600K realizza un guadagno del 14% mentre l'FX-8150 soffre di una perdita del 77%. Sembra che la vettorizzazione intriseca di Cakewalk (o, con meno probabilità , Microsoft) non siano ottimizzate per l'architettura AMD. In ogni caso, potrebbero essere necessari una patch o il service pack di Visual Studio.
Se osservate i risultati di Sandra 2011 vedrete che il supporto AVX aiuta le prestazioni con interi e in virgola mobile dell'FX-8150 di AMD. Sandy Bridge ottiene un miglioramento in virgola mobile molto più alto con questo benchmark sintetico.
Appena prima di concludere i test, AMD ci ha mandato due versioni di x264, la libreria dietro ad applicazioni front-end come HandBrake. Queste versioni integrano supporto per AVX e XOP, l'ultima delle quali è esclusiva all'architettura AMD.
Abbiamo modificato l'x264 HD Benchmark 4.0 di Tech ARP per usare ognuno di questi nuovi code path, più CPU-Z 1.58 per le informazioni di sistema e dato in pasto all'FX-8150 le due librerie, mentre al Core i5 2500K solo la build ottimizzata per AVX.
I risultati tra i code patch AVX e XOP di AMD sono alquanto simili. Intel riesce a completare il primo passaggio più rapidamente, ma AMD offre migliori prestazioni nel secondo passaggio.
Ricordate che il numero di test ottimizzati per AVX è ridotto. Servirà ancora molto sviluppo prima che si possa trarre una chiara conclusione sul supporto AVX da parte delle due differenti architetture.
L2 condivisa
Abbiamo già parlato del TLB L2 condiviso, responsabile per le richieste di manutenzione istruzioni (front-end) e dal lato dati (core integer). C'è anche una cache L2 unificata condivisa tra i due core. Questo magazzino è di 2 MB per modulo, per un totale di 8 MB di cache L2 su un processore FX 8000 composto da quattro moduli.
Clicca per ingrandire
AMD afferma che il data prefetcher nel modulo Bulldozer è anch'esso il prodotto di un significativo investimento, ammortizzato condividendolo tra entrambi i core.