[tuttodigitale]

QUESTO È ZEN: Architettura (non ufficiale)




CPU COMPLEX

Il CPU Complex è costituito da quattro core interconnessi ad una cache L3. All’interno del modulo ogni core può accedere alle 4 fette di cache l3, 8 MB e 8-vie, con la stessa latenza media. la porzione di L3 più vicina al core avrà una latenza inferiore a causa del metodo low-order address interleave.
zen octa-core sarà costituito da 2 CCX.


Basta una rapida lettura per rendersi conto che ZEN è un core molto più grande, complesso e potente dei core excavator all’interno di un modulo CMT. Se questo era prevedibile per la parte integer, per il quantitativo doppio di ALU e thread gestiti dal singolo core, meno ovvio è per la sezione floating point. In ZEN non solo a parità di core viene raddoppiato il quantitativo di unità FP, ma viene potenziato in modo abbastanza massivo, la quantità di istruzioni gestiti dallo scheduler FP, che passano dai 60 visti in Steamroller/excavator a 96.

Originariamente inviato da bjt2

Questa è la slide più succosa e pregna di informazioni! Punto per punto:
- Two threads per core: lo sapevamo già... Ma ora è confermato: SMT2
- Branch misprediction improved: questo può essere dovuto a pipeline più corte (e quindi avremo un clock relativamente più basso) oppure al checkpointing... Speriamo la seconda...
- 2 BTB per entry: questo deve essere un brevetto di AMD. Mi sembra una cosa stranissima, comunque tu is megl che uan...
- Large op cache: vabeh, ma quanto?
- Wider uop dispatch 6 vs 4. Questo da solo può aumentare del 50% le prestazioni
- larger instruction scheduler: vabeh, questo aiuta con 2 thread per ordinare meglio le istruzioni
- Larger retire: 8 vs 4. QUESTO E' IMPORTANTISSIMO! Questo da solo può raddoppiare le prestazioni sui due thread. Con questo, l'SMT può veramente guadagnare come il CMT in casi fortunati e sicuramente più del 25-30% in media
- Quad issue FPU: questo ci conferma la PUTEEEEENZA della FPU. (era 3 in BD, mi pare)
- Larger retire queue: anche qui aiuta nell'SMT
- Larger load e store queue: migliore riordinamento delle istruzioni e aiuta nell'SMT
- Writeback l1 cache: è meglio di quella di BD
- faster L3 e L3: vabeh
- Faster load to FPU: 7 vs 9. Questo può essere dovuto al fatto che non è più CMT e quindi non si devono più sincronizzare e arbitrare i due core int
- better l1 e l2 prefetch: vabeh.
- Close to l1 & l2 bw: sulla L1 non vedo come si raddoppi, perchè il bus è lo stesso (forse bus a 256 bit? ma non mi pare). Sulla L2 può darsi che il bus sia raddoppiato, magari era 16+16bytes in BD. Ma close to 2x può voler dire che il clock non è superiore...
- L3 BW 5x: anche qui 4x bus e +25% frequenza
- Aggressive clock gating: ok
- Stack engine: probabilmente non si usano le AGU per lo stack, quindi anche miglioramenti delle prestazioni
- Move elimination: non si usano le ALU per i MOVE
- Power focus: si sono sbattuti sul risparmio energetico fin dal principio
- Low power methodologies: ok

DECODER
Dalla slide sopra, sembra che i decoder in ZEN differiscano in maniera sostanziale da quelli viste nelle precedenti architetture AMD. Un core steamroller/excavator ha 4 decoder, ognuno dei quali è in grado di eseguire una fastpatch. Basandoci sulle (poche informazioni) offerte dalla slide sembrerebbe che i 4 decoder, una prima assoluta per AMD nell'epoca post k7, forniscano in uscita le microop. La gestione delle uop da parte dello scheduler potenzialmente è in grado di fornire un maggior parallelismo a livello istruzione.
La scelta (non confermata) permette da una parte di contenere più istruzioni nella cache l0, a causa del ridotto numero di bit richiesto per la rapprentazione delle micro-op rispetto alle macro-op, e dall'altra aumenterebbe la probabilità di richiedere con maggior frequenza la stessa micro-op.




vi rimando ad alcuni commenti di bjt2, alcuni sono riferiti a BD

Originariamente inviato da bjt2

Primo vantaggio di AMD: le unità RISC interne sono più complesse ed hanno più porte e ci sono molte più istruzioni di INTEL che sono traducibili in una sola microop. Ad esempio per INTEL basta che si usino 4 operandi ed è richiesto il microcodice (ecco perchè hanno FMA3 e non FMA4).

Secondo vantaggio AMD: prima di usare il microcodice, AMD può generare anche 2 microop (le cosiddette fastpath double) con i decoder semplici. Invece INTEL appena serve una istruzione più complessa deve usare la microcode ROM.

Terzo vantaggio AMD: INTEL può decodificare in burst di 4-1-1-1. Fuori da questo schema le cose si rallentano molto.

Originariamente inviato da bjt2

Il decoding può essere fatto in vari modi e AMD ha una tecnica innovativa (e penso brevettata, visto che INTEL non la usava) di memorizzare il predecoding in bit aggiuntivi della L1 istruzioni, come limiti di istruzione e informazioni di branch predicition, velocizzando il decoding e la previsione per le istruzioni già in cache e accorciando le pipeline. Per il resto le operazioni da fare in serie sono abbastanza definite... Resta solo da definire dove spezzare per formare gli stadi..

Originariamente inviato da bjt2

4 decoder, non è specificato i limiti. Ne sapremo di più domani.
Stack engine con una sorta di cache L0: la rilettura di dati scritti da poco è processata subito (sul MEMFILE).
4 uop alla FP e 6 alla unità intera. Domani sapremo se sono 6+4 per ciclo o ci sono delle limitazioni
Inline istruction length decoder è interessante: nelle vecchie CPU, AMD le calcolava e le inseriva nella L1 al posto dei bit di ECC/parità e se non erano calcolati (perchè erano istruzioni appena caricate), si perdeva qualche ciclo per calcolarli...
Con questa soluzione, non solo non si perde tempo ulteriore a calcolarli, ma si può anche usare i bit ECC per quello per cui sono stati progettati: l'ECC!

UOP CACHE, BUFFER UOP E CHECKPOINT
La presenza di una cache L0 posta ad un livello gerarchico superiore alla L1 è stata anticipata dal Cern. Tuttavia dalle patch le cache sarebbero 2: uop cache e buffer uop. Ad oggi non sono noti i dettagli sul loro funzionamento, tuttavia sappiamo quale è la loro funzione, essendo la cache uop presente nelle architetture Intel da Sandy Bridge.
Il nome uop è dovuto al fatto che in questa porzione di memoria vengono memorizzate le uop, le micro-operazioni elementari che le unità del back-end sono in grado di eseguire. Le istruzioni decodificate vengono memorizzate in questa piccola cache, e rese disponibile anche per l’esecuzione di istruzioni successive permettendo di saltare la fase di decodifica, che in una moderna architettura può richiedere anche più di 5 cicli.
I vantaggi sono duali: saltare la fase di decodifica permette di ridurre la potenza dissipata. Un vantaggio, per così dire minore ma comunque importante, è throughput massimo più alto.
Nel caso specifico di ZEN, sappiamo che può emettere 6 uop (come skylake), sfruttando i 4 decoder e la cache uop. Quest’ultima, infine, è in grado di supportare 2048 micro-ops (contro i 1536 di skylake) e una associatività ad 8 vie (come il rivale).

Sul checkpoint, la cui presenza è stata ancora una volta confermata dalla patch, oltre al nome si sa veramente poco, se non il fatto che dalle slide del HOT CHIPS pubblicate da AMD, questa è una tecnologia pensata per aumentare le prestazioni, nulla a che vedere con il checkpoint delle architetture Power, una tecnologia atta a correggere eventuali anomalie in sistemi data-center.

Originariamente inviato da cdimauro

Riguarda al checkpoint, un meccanismo che ha lo stesso nome si ritrova nei database transazionali, dove transazioni lunghe possono essere suddivise in checkpoint, nelle quali vengono eseguite dei commit "parziali" (non ancora definitivi) delle operazioni fino ad allora eseguite. L'idea è quella di evitare di accumulare troppe operazioni in sospeso nella transazione in corso, la cui chiusura porterebbe via troppo tempo alla fine. Coi checkpoint alcune operazioni vengono "quasi completate", liberando risorse (ed eventuali lock, in particolare), ma che possono essere annullate più velocemente in caso di rollback (se la transazione fallisce).

Una cosa del genere si potrebbe applicare anche a una CPU, sebbene non abbia idea di come, ma il principio di funzionamento fra database e CPU, a livello astratto, è esattamente lo stesso.

Quanto detto da cdimauro, sembra essere confermato dal fatto che AMD nel 2009 ha proposto una estensione dell’ISA x86, che prevedeva il supporto alla memoria transazionale in HW.
http://developer.amd.com/community/b...specification/





CACHE L1 & L2 & L3


Radicali i cambiamenti. È stata cambiata la gestione della cache: la tecnica exclusive che ha caratterizzato per 3 lustri le architetture della casa di Sunnyvale, fa spazio a quella inclusive, che prevede la copia di tutti i dati contenuti nelle cache di livello gerarchico superiore in quelle inferiori, più lontane dal core.
Tuttavia va segnalata una importante differenza rispetto a quanto visto nelle architetture Intel a partire da Nehalem: in ZEN la cache L3 è di tipo victim, una cache che contiene i blocchi che sono stati cancellati dalla L2. In ZEN, il quantitativo di informazioni gestibile dal sistema di caching nel suo complesso, che si interpone tra i core e la lenta ram di sistema, è determinata non solo dalle dimensioni dell’ultimo livello di cache LLC (Last Level Cache), ma anche dalla L2.


i quantitativi di cache L1d, L1i, L2 , sono pari rispettivamente 32KB, 64KB e 512 KB per core. La cache L1d è una 8-way 2R1W, con 4 cicli di latenza.
Si registra, un raddoppio di banda di 2x, per le cache l1 ed l2, mentre per la L3 addirittura di un 5x…questo dato starebbe a significare un aumento consistente della velocità di clock per Northbridge, che potrebbe passare dai 2200 MHz attuali a 2800MHz.

Per la cache L3 si prevede un quantitativo di 16MB complessivi.

Originariamente inviato da bjt2

GERARCHIA DI CACHE:

la cache esclusiva utilizzata da AMD fino ad ora aveva l'unico vantaggio che le capacità si sommavano. Poteva andare bene quando le cache erano piccole. Ma ora con cache enormi gli svantaggi che andrò ad elencare, ampiamente superano il vantaggio di avere una cache effettiva maggiore.

1) Maggiore latenza: con la cache inclusiva bisogna cercare solo nella LLC (in genere la L3). So dove sono i dati e non devo ravanare anche nelle L1 e L2 di tutti gli altri core. Utile sopratutto nei server dove gli altri core sono lontani.
2) Maggiore consumo: con la esclusiva se un core va in risparmio energetico devo tenere accesa la L1 e la L2 per rispondere alle richieste degli altri core. Se voglio spegnere le L1 e le L2 le devo prima svuotare, scrivendo i dati modificati, con conseguente consumo di energia. Con una cache inclusiva spengo tutto e basta.
3) minori spostamenti: con una cache esclusiva, i dati condivisi vengono continuamente spostati tra i core. Con una cache inclusiva ognuno ha le sue copie che tiene aggiornate alle modifiche degli altri core spiando la LLC senza necessariamente dover segnalare agli altri core nulla.

Quindi il passaggio a questa gerarchia di cache farà fare un balzo alle prestazioni.

BACK-END
MOLTO AMPIO, con ben 10 porte di esecuzione contro le 8 del predecessore. Il cambiamento più vistoso è il raddoppio delle ALU che passano da 2 a 4.

Come è possibile vedere dallo schema, solo 2 unità su 4, eseguono operazioni complesse come DIV e MUL, questo ha permesso di aumentare la complessità della singola MUL, come dimostra la latenza ridotta di 3 cicli rispetto a BD, in netto contrasto di quanto visto per l’esecuzione di un altro tipo di istruzione (ZEN è un’architettura dalle pipeline decisamente lunghe)

Originariamente inviato da bjt2

Sono andato a leggere la patch. Tutte le latenze dei load FP aumentati.

Com'è possibile abbassare il FO4, causando l'aumento di alcune latenze, ma abbassare le latenze delle moltiplicazioni? La soluzione è aumentare il numeri di bit calcolati più di quanto si sia diminuito il FO4 per più che compensare... Hanno fatto un grande lavoro sui moltiplicatori. Probabilmente sugli addizionatori c'era già ampio margine per abbassare il FO4 senza dover spezzare l'addizione... E sulle moltiplicazioni hanno usato addizionatori a più porte per diminuire gli stadi, e quindi il FO4 e allo stesso tempo aumentare i bit calcolati per ciclo. Questo richiede circuiti più complessi e quindi più area...

Come hanno fatto? Supponiamo che con un disegno ad alto FO4, si riesca a calcolare 12 bit per ciclo della moltiplicazione, con il circuito non ciclico più semplice del mondo, ossia 12 addizionatori a 2 porte in cascata. Il FO4 sarà 12 volte quello di un addizionatore a 2 porte.
Se uso addizionatori a 3 porte, posso fare 24 bit per ciclo con 12 stadi o 16 bit per ciclo con 8 stadi (una porta per il risultato precedente più 2 per 2 bit alla volta, più il carry). Quindi il FO4 è 8 volte quello di un addizionatore a 3 porte che non è molto superiore a quello di uno a 2 porte.
Quindi con un po' di hardware in più (l'addizionatore a 3 porte è comunque più complicato di quello a 2) ho ridotto il FO4 e aumentato il numero di bit calcolati per ciclo...
Ma perchè fermarsi a 3 porte?

Ecco come è possibile diminuire il FO4 e aumentare contemporaneamente la potenza del moltiplicatore, a scapito di un aumento di area e numero di transistors consumati.

FPU
È sicuramente uno degli elementi più interessanti. Questa unità è formata da 4 pipeline da 128 bit, di cui 2 FMUL e 2 FADD. Le FMA sono eseguite con l’uso congiunto di una pipeline FADD e una FMUL.


La latenza è di 3 cicli per l’accesso alla cache (quindi 7 cicli totali, se consideriamo i 4 cicli propri della l1)

Originariamente inviato da bjt2

Il moltiplicatore è fatto per il massimo risparmio energetico. Fa 32 bit alla volta (ricordate il mio esempio di 8 e 12 bit?) e quindi per 64 e 80 bit è più lento.
Rispetto a BD, la FMA è fatta con una FMUL+FADD con la lettura ritardata a dopo la moltiplicazione dell'addendo. Questo cosa comporta? Meno porte sui registri FPU, quindi potenzialmente più veloci. Consumo più distribuito nel tempo. Questo è importantissimo. Perchè? Le FMA implementate in BD sono affamatissime di corrente e causano un alto voltage droop. In Carrizo e Bristol Ridge questo è stato risolto con l'AVFS. Ecco perchè con il 28nm bulk ciofeca si raggiungono comunque 4.3GHz. Senza l'AVFS BD e steamroller sono limitati in base clock. E' stato fatto un esperimento su Orochi solo abbassando il throughput delle istruzioni FMUL e si è riusciti a salire di frequenza base di oltre 400MHz!
Poi sono discussi altri brevetti per ridurre le latenze delle istruzioni FPU, travasando i risultati intermedi.
Insomma in sintesi la nuova FPU dovrebbe essere molto meno ingorda di corrente e quindi consentire clock più alti, anche se un po' più lenta. Ma con il nuovo brevetto, se implementato, si dovrebbe controbilanciare questa lentezza...

Originariamente inviato da bjt2

C'è una cosa non visibile nei diagrammi a blocchi della FPU (leggendo anand)...
La coda delle microop è doppia: una per le istruzioni schedulabili e una per quelle non schedulabili. La prima credo di aver capito che contiene le istruzioni prontamente eseguibili perchè i dati sono già pronti, mentre la seconda contiene istruzioni che aspettano dati dalla memoria e immagino anche dalla unità intera (penso alle istruzioni di move/conversione da int a FP)
Il vantaggio è che non si spreca spazio e potenza nella coda a più alta velocità e si divide il lavoro perchè la coda secondaria può fare, con calma e poca potenza, il lavoro in parallelo alla coda primaria...

SMT secondo AMD
In Zen abbiamo la prima implementazione della logica SMT2 in una cpu della casa di Sunnyvale. Questa prevede la capacità di un core di gestire 2 thread, condividendo alcune risorse all’interno del core.
Di vitale importanza è la gestione delle stesse. Dare lo stesso tempo di esecuzione per eseguire entrambi i thread, non è sempre la politica corretta, soprattutto quando si ha un thread dominante o che crea un sacco di stalli o in cui la latenza è di vitale importanza.
In alcune metodologie un thread principale, può essere etichettato o determinato, e questo è ciò che avviene in ZEN, anche se per alcune strutture del core si deve comunque ricorrere ad un modello base.


In Zen viene eseguita un analisi interna sul flusso dati per determinare quale thread ha la priorità. Ciò significa che alcuni thread richiederanno più risorse, o che ad una predizione errata debba cessare una eventuale priorità a fine di evitare lunghi stalli.
Gli elementi in blu (branch prediction, INT/FP Rename) operano su questa metodologia.

Un thread può anche essere etichettato con priorità più alta. Questo è importante per le operazioni sensibili alla latenza. Translation Lookside Buffer (TLB) lavora in questo modo, dando la priorità alla ricerca degli ultimi indirizzi virtuali mappati.
La load queue opera in maniera analoga, come tipicamente carichi di lavoro a bassa latenza richiedono dati il prima possibile.

Alcune parti del core sono staticamente partizionati, dando ad ogni thread la stessa quantità di risorse. Questo viene implementato soprattutto per tutto ciò che è in genere elaborato in order, come qualsiasi cosa che esce dalla micro-op, store e retire queue.



Il livello di condivisione dei 2 thread all’interno di un core ZEN, non ha eguali nel panorama x86.
A partire dal front-end, si registra la capacità, assente nelle CPU skylake, di decodificare nello stesso ciclo di clock istruzioni di 2 thread distinti. I 4 decoder possono decodificare da 0-4 istruzioni per singolo thread a seconda della distribuzione del carico tra i 2 thread. In skylake, così come in Bulldozer/Piledriver, viene utilizzato il temporal multi-threading, che prevede la decodifica dei 2 thread in cicli di clock distinti. Questo dovrebbe permettere all’architettura ZEN di sfruttare per intero il potere di decodifica.
E’ giusto segnalare che la small page iTLB è anch'essa partizionata staticamente nelle architetture Intel.
Addirittura le risorse per il RENAME, la large page iTLB e il Load buffer sono DEDICATE nelle CPU della casa di Santa Clara.

Originariamente inviato da bjt2

Quì è interessante. INTEL ci è arrivata con varie iterazioni a questo punto: le prime iterazioni dell'HTT avevano quasi tutto partizionato. Qui invece AMD ha quasi tutto condiviso dinamicamente. E in modalità ST è tutto a disposizione di quel thread.
Cosa è partizionato staticamente?
1)La microop queue: se la coda è abbastanza grande ha senso, perchè farla partizionata dinamicamente avrebbe rallentato il clock massimo.
2)La retire queue: stessa cosa di sopra. Tenere il critical path semplice aiuta ad avere clock alto
3)La store queue: questa non è critica perchè una volta messi in coda gli store si può proseguire e comunque la coda è più grande di BD

Da notare i blocchi in blu, che non mi pare sia presente in INTEL, dove è possibile dare priorità ai thread. Non so se sotto il controllo del SO o se è automatico, ma è interessante!

Niente di interessante qui se non una cache L0 piccola e veloce, probabilmente per avere la massima velocità. Hash percetron mi sembra un termine di inteligenza artificiale, quindi presumo che il branch predictor sia molto inteligente...

NUOVE ISTRUZIONI
Insieme alla nuova ISA standard, ci sono alcune nuove istruzioni personalizzate che sono compatibili solo con la nuova architettura di AMD.



Alcuni dei nuovi comandi sono collegati con quelli che Intel utilizza già, come RDSEED per la generazione di numeri casuali, o SHA1 / SHA256 per la crittografia. Le due nuove istruzioni sono CLZERO e PTE coalescing.
Il primo, CLZERO, si propone di cancellare una linea di cache ed è più finalizzato al mercato data center e HPC. Questo permette ad un thread di cancellare una riga di cache (in un ciclo) in preparazione di una zero data structure. Esso consente anche un livello di ripetibilità quando la linea di cache viene riempita con dati previsti.
PTE (Page Table Entry) coalescing è la capacità di cassociarele piccole 4K page tables nelle più grandi 32K , ed è una implementazione trasparente del software. Questo è utile per ridurre il numero di voci nella TLB e nelle code.



CONFRONTO CARATTERISTICHE E LATENZE




post di BJT2

Previsioni prestazioni

mini guida