[tuttodigitale]

Originariamente inviato da bjt2

Visto solo ora il thread...
IPC architettura INTEL vs AMD ZEN, sia in ST, che MT.

Partiamo dal ST.

INTEL ha dei core infarciti di unità molto potenti, che quando utilizzate a pieno regime, scaldano e richiedono un downclock, ma hanno il collo di bottiglia delle porte, che sono limitate. E meno male, altrimenti fonderebbe...

Clock vs clock ZEN può fare 4ALU+2AGU+4FPU, mentre INTEL 4 tra ALU e FPU+2AGU, per limiti di porte.

Nel ST ciò non penalizza parecchio perchè comunque il parallelismo estraibile da un singolo thread non va oltre una IPC di 2-3 di massimo, ecco perchè INTEL ha 4 porte condivise. Se consideriamo codice AVX a 256 bit, su ZEN è splittato a 128 bit e quindi ha senso per AMD avere più porte, per non perdere troppo contro INTEL, visto che l'"IPC reale" diventerebbe 4-5.

Ma INTEL ha 2 vantaggi ENORMI e uno piccolo: cache "L0" delle microistruzioni e gerarchia cache INCLUSIVA, più veloce e parca di consumi (spiego dopo) e quello piccolo è il miglior branch prediction.

La cache L0 di INTEL è stata fatta per compensare le mancanze rispetto alla struttura AMD.

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. Invece AMD può decodificare con 1-1-1-1, 2-2, 2-1-1, 1-1-2, 4.

Quarto vantaggio AMD: AMD fa il prefetch del codice a 32 bytes per ciclo di clock. INTEL fino a poco tempo fa era fermo a 16. Non sono sicuro, ma forse con broadwell o skylake questo problema è stato risolto.

Da qui la necessità prima del loop buffer (per piccoli loop) e poi addirittura di una cache L0 per le uop tradotte.

Ebbene, dalle informazioni leaked sembrerebbe che ZEN abbia una cache L0 da 4KB. Che probabilmente manterrà le uop tradotte e consentirà di spegnere spesso le voraci unità di fetch e decodifica, portando a risparmio energetico e aumento di prestazioni.

MULTI THREADING
Con HT INTEL guadagna da 0% a circa 60%, con una media del 30% per colpa delle scarse porte. Qualunque codice FP intensive ha ANCHE istruzioni intere e memoria. Non si può estrapolare questa media a ZEN perchè ha molte più porte. Il guadagno SMT potrà andare da 0 (in casi patologici che credo neanche esistono) a 100% (codice a basso IPC con molti calcoli e poco accesso alla RAM) e la media si attesterà molto sopra del 30%. Più verso il 50-60% IMHO.



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.

Branch prediction:
INTEL è sempre stata avanti ad AMD se non altro per il budget maggiore che gli consente di fare molta ricerca.
AMD incidentalmente, con lo scopo di una migliore efficienza, ha prodotto un nuovo tipo di branch predictor in jaguar o puma (non ricordo quale), che mi pare sia stato usato in excavator (da cui il balzo di IPC) e comunque non vi è motivo di ritenere che non sarà usato in ZEN.

Quindi sono molto fiducioso che ZEN avrà un buon IPC e una migliore efficienza energetica grazie alla cache L0, la cache inclusiva e il nuovo branch prediction.

Originariamente inviato da bjt2

Anche io ho scoperto pochi giorni fa che c'è una cache L0... E li nomina il 6 wide (probabilmente 4ALU+2AGU)... Ora me lo leggo meglio perchè avevo solo letto il riassunto su semiaccurate...

http://vrworld.com/2016/02/12/cern-c...pecifications/

Un estratto:

ZEN High End ‘Exascale’ CPU, 1-4 Socket (1P-4P) – Specs As Per CERN

Multi-Chip Module (2×16-core)
32 ZEN x86 Core, 6-wide
128 KB L0 Cache (4KB per core)
2 MB L1 D-Cache (64KB per core)
2 MB L1 I-Cache (64 KB per core)
16 MB L2 Cache (512 KB per core)
64 MB L3 Cache (8MB cluster per quad unit)
576-bit Memory Controller (two times 4×72-bit, 64-bit + 8-bit ECC)
204.8 GB/s via DDR4-3200 (ECC Off, 102.4 GB/s per die)
170.6 GB/s via DDR4-2666 (ECC On, 85.3 GB/s per die)
ZEN High End Exascale APU, 1-2 Socket (1P-2P) – Rumored Specs From Fast Forward

16 ZEN x86 Core, 6-wide
64 KB L0 Cache (4KB per core)
1 MB L1 D-Cache (64KB per core)
1 MB L1 I-Cache (64 KB per core)
8 MB L2 Cache (512 KB per core)
No L3 Cache
288-bit CPU Memory Controller (4×72-bit, 64-bit + 8-bit ECC)
102.4 GB/s via DDR4-3200 (ECC Off)
85.3 GB/s via DDR4-2666 (ECC On)
102.4 GB/s between CPU and GPU via GMI
~2000-core Polaris GPU
2048-bit GPU Memory Controller
8 GB HBM2 SGRAM Memory (2 chips at 4GB)
512 GB/s GPU Bandwidth

Originariamente inviato da bjt2

Due cose.

La prima è una considerazione sulla cache L0. Dalle slide del tizio del CERN, sembrerebbe che Zen abbia una cache L0 di 4KB. Quella dei processori INTEL è 1,5KB. Quindi anche se Zen fosse SMT4, ci sarebbe comunque più cache per thread dei processori INTEL. Se poi è un SMT2 classico, hai voglia!


Seconda cosa: un tweet di dresdenboy rimanda a un post su un forum, che riporto qui. Buone notizie.

Tapeout di uno Zen 8 core step A0 95W (unthethered non so cosa significhi) su processo Samsung 14nm finfet, che sembra migliore di quello INTEL. IPC simile a broadwell un po' sotto a skylake (ma siamo allo step A0, ricordiamolo). Chipset comaptibili per MB AM4 in arrivo a marzo. Tenteranno di uscire con Zen a ottobre.

Originariamente inviato da bjt2

http://dresdenboy.blogspot.it/2016/0....html?spref=tw
Dunque:
1) Conferma che la cache L0 è per le uops.
2) Checkpointing, ossia recupero più veloce in caso di predizione salto errata
3) Ricompaiono gli FMAC (per qualche ragione si era speculato che lo FMAC era fatto con addizione e moltiplicazione unite tra loro e quindi occupavano due pipeline) e si specifica meglio la FPU: più potente di quello che si pensava
4) I thread dovrebbero essere 2, ma la buona notizia è che se la cache L0 è veramente 4KB, c'è più del doppio di cache rispetto ad INTEL... Considerando anche che le MOPS AMD sono più espressive e ce ne vogliono di meno rispetto a INTEL...
5) Dall'analisi dei dati Dresdenboy dice che praticamente un core Zen è due front end con un solo back end. Credo voglia intendere che le risorse per i due thread siano di più rispetto ad INTEL e che quindi ci si deve attendere un alto guadagno dal secondo thread...
6) Compare il GMI link, utile per la comunicazione tra die (compreso probabilmente una eventuale GPU su die separato in una APU server)
7) Ci sono delle righe "reserved": Dresdenboy suppone che siano funzionalità gustose, tenute nascoste perchè la mailing list è pubblica. Dice così perchè sono in mezzo e non in coda e quindi non sono vere funzionalità riservate per il futuro, ma semplici funzionalità implementate, ma tenute nascoste... Per ora...
8) Non ho capito cosa sia il FUSE subsystem, ma il nome è gustoso...
9) Stack cache: cache separata per i dati stack: più per questioni di risparmio energetico che per le maggiori prestazioni
10) Modulo di gestione della paginazione a 4 vie: probabilmente 1 dati e 1 istruzioni per ognuno dei thread, ma il patent menzionato parla anche di riordinamento delle operazioni di memoria. Probabilmente questo le rende più efficienti...
11) La FPU è 128 bit. Ciò si deduce dal fatto che le istruzioni AVX 256 bit sono double (2 MOPS) e le altre single.
12) La FPU può fare per ogni ciclo 2FADD+2FMUL o 2FADD+2FMAC. Se sono stati inteligenti le 2FMAC possono fare anche FADD e quindi si hanno fino a 4 addizioni a 128 bit per ciclo o 2 a 256 per ciclo. Non male.
13) Si consiglia di disabilitare il prefetcher software: o quello hardware è molto buono, oppure c'è interferenza ed è meglio disabilitare quello software
14) Cache L1 con latenza 4 e 2 letture e una scrittura (a 128 bit?) per ciclo
15) In futuro riparlerà più in dettaglio della FPU...

Originariamente inviato da bjt2

Considerando la cache L0 enorme rispetto ad INTEL, il checkpointing, le porte (ben 10), il potenziale per superare di gran lunga INTEL c'è...

Latenze di ZEN

Originariamente inviato da bjt2

Da Twitter...
Quote:
Matthias Waldhauer ‏@Dresdenboy
New GCC Patch [X86_64] : Fix multiplication cost for -march=znver1. - Patchwork - this means faster int muls http://j.mp/1TgWWx2 #AMDZen

Le moltiplicazioni intere passano da 4 a 6 cicli di BD (da cui avevano copiato le linee) a 3 e 4 cicli...

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

Questo il nuovo post di dresdenboy su twitter:

Quote:
New #AMDZen patch: minor latency changes for znver1.md http://j.mp/1PefXsc L/S in FX cluster and not too low clocks? 4GHz 8C DT?

Sono andato a leggere la patch. Tutte le latenze dei load FP aumentati. Quello che lui ipotizza, e che è ragionevole, è che il FO4 sia stato abbassato rispetto a XV, e quindi clock più alto, lui ipotizza 8 core a 4GHz DT (dual thread, suppongo)...



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.

Ipotesi SOCKET AM4

Originariamente inviato da bjt2

1) I pin sono più sottili, quindi per la stessa corrente servono più pin.
2) TDP max aumentato, quindi servono più pin per l'alimentazione.
3) Vcore abbassato notevolmente, quindi per dissipare lo stesso TDP serve più corrente (ma quindi maggiore frequenza massima)
4) Linea/linee di alimentazione aggiuntiva/e con tensione separate e indipendenti da quelle già presenti, ad esempio per eventuale memoria HBM on chip, oppure per alimentazione di south bridge integrato (nel caso di SoC)
5) Linee pciexpress, DP, usb, sata, ecc. aggiuntive
6) Pin per le funzionalità aggiuntive del SB, come gigabit ethernet, wifi, magari addirittura audio...

Processo Produttivo

Originariamente inviato da bjt2

Ok, 3 cose buone e una cattiva:
Buone:
1) Guadagno (transconduttanza differenziale) maggiore: non ne ero sicuro.
2) Bassa off state current: minore leakage
3) Bassa resistenza parassita: migliore come spiegato sopra (rumore minore e velocità superiore)
Cattive:
4) However, the overlap capacitance is increased.
Io intendevo le capacità parassite, ma questa potrebbe essere comunque deleteria, ma può essere bilanciato dal basso leakage.

In sostanza:
1) guadagno maggiore significa minore tensione necessaria a parità di frequenza
2) minore leakage: minore potenza dissipata
3) minore resistenza parassita => minore rumore => minore margine richiesto ai segnali => maggiore frequenza possibile a parità di altre condizioni (ad esempio Vcore)
4) Questa capacità non so che effetti abbia, ma nel peggiore dei casi serve più corrente (e quindi tensione) a parità di frequenza, probabilmente più che bilanciato dai precedenti 3 punti


Resta solo da vedere il Vt...

La 1 e la 2 se sono veramente LARGE come dicono sono un BEL vantaggio! Il primo alle alte frequenze e il secondo per le basse potenze (mobile)...

Originariamente inviato da bjt2

http://forums.anandtech.com/showpost...&postcount=935

Non so da dove prende le informazioni sto tizio, ma dice faville sul processo 14nm FF...
1) 14FF INTEL richiede 950mV a 2.8GHz. 14FF GF è più efficiente nel range basso e richiede 800mV per una CPU a 2.4GHz non ottimizzata per le alte frequenze (forse hanno testato il 14nmFF con una CPU ARM?): nel range dei 2.4GHz il processo GF è più efficiente del 20% del processo INTEL.
2) il 14FF LVT ha comunque 6 volte meno leakage del processo 28nm HP e 3.5 volte meno al 28nm SPP. Il 14nmFF sLVT ha più leakage del 14nm LVT, ma comunque meno del 28nm HP, quindi deduco che sia probabile che Zen sia fatto con i transistors sLVT
3) I numeri che ha dato GF (quali?) sul progresso rispetto ai 28nm sono relativi ai transistors LVT... Quindi gli sLVT fanno ancora meglio (ho letto da qualche altra parte +10% di frequenza a parità di Vcore tra LVT e sLVT, nulla sulla potenza)

Originariamente inviato da bjt2

http://forums.anandtech.com/showpost...&postcount=940

Alle rimostranze di un utente, che non crede che i dati di 28nm vs 14nm siano su una CPU completa, risponde che sono 2 core ARM A57, che hanno una pipeline più corta, e quindi un FO4 più elevato, di Zen e da dei numeri:

Processo, Frequenza MAX...., Potenza dinamica, Leakage, Totale
28 SLP..., 0.97GHz@0.90V..., 158mW@1.1V....., 70mW..., 228mW
28 HPP..., 1.17GHz@0.765V., 210mW@0.935V.., 119mW., 329mW
14 LPP...., 2.41GHz@0.72V.., 310mW@0.88V...., 18.6mW, 328.6mW

Da notare il leakage bassissimo, la frequenza doppia a parità di potenza, ma a noi interessa il rapporto potenza dinamica/frequenza: migliora del 40% (129mW/GHz contro 179mW/GHz)...

Due core ARM a 2.4GHz consumano 330mW (!!!)... Hai voglia a fare i K12...
Anche ammesso che il FO4 sia lo stesso di Zen e che i due core ARM siano mezzo core Zen, avremmo 0.66W@2.4GHz per core... Ossia un 32 core consumerebbe meno di 25W... Quindi in 140W credo che il 32 core possa arrivare almeno a 3GHz... E l'8 core tranquillamente a 4GHz...

Le tensioni sono diverse, perchè quella più bassa è la tensione minima necessaria per far funzionare le CPU a quelle frequenze, mentre quella più alta che si usa per calcolare la potenza è quella con il margine... Quindi c'è anche margine di overclock o undevolt!

Originariamente inviato da bjt2

http://research.cs.wisc.edu/multifac...tack_cache.pdf

Per chi se la sente, due possibili implementazioni di una stack cache.
In sintesi:
La prima, restringendo l'allocazione dei dati stack a solo una parte della cache, per ridurre il consumo.
La seconda, con una stack cache separata, che consente di non usare i TLB, perchè ci si accede direttamente con gli indirizzi virtuali e usare una diversa politica di gestione delle scritture, che possono aumentare eventualmente le prestazioni, ma sopratutto per ridurre i consumi...

Originariamente inviato da bjt2

https://twitter.com/momomo_us/status/727849367806222336

L'ES del Broadwell 10 core (core e processo già parzialmente collaudati) è 2.2GHz...
L'ES di Zen 8 core (nuovo processo e nuova architettura) è 3 GHz...

Non aggiungo altro...