[Thread Ufficiale] Aspettando ZEN

[bjt2]

https://translate.google.com/transla...-text=&act=url

Maggiori dettagli sul branch prediciton di Zen. Anche qui sembra essere confermato la possibilità di predirre 2 salti per ciclo anche per lo stesso thread...

[Crysis90]

Originariamente inviato da Ale55andr0

http://wccftech.com/intel-developing...re-generation/

L'effetto Zen comincia a dare i sui frutti.

Originariamente inviato da digieffe

Come fa ad essere OLD, se il link è stato postato adesso per la prima volta e si riferisce ad un articolo di una fonte esterna che lo ha pubblicato appena qualche ora fa?!?!??

[cdimauro]

Originariamente inviato da Ren

Dai test sulle sram il 32nm IBM/GF è più denso.

0.17um2 (intel) vs 0.15um2 (gf)

Intel ha un metal pitch peggiore oltre che qualche layer in meno...

Questo vale solo per le SRAM, che sono i circuiti più semplici.

Il grafico di AnandTech mostra uno scenario diverso. Infatti anche le versioni di SandyBridge con le GPU mostrano una densità diversa, segno che il tutto dipenda dal tipo di circuiti implementato.

Originariamente inviato da tuttodigitale

premesso che il numero di transistor lascia davvero il tempo che trova...

Il numero di transistor è fondamentale per stabile cosa fa il chip.

le dimensioni di un core SB è sovrapponibile a quello di un intero modulo BD.

Com'è possibile, visto che il die di BD è del 46% più grande? Hai delle immagini di confronto?

Vedi Jaguar, piccolissimo anche rispetto ad XV (dual core Jaguar 6,2mmq vs 14mmq modulo XV) eppure è il secondo a consumare di meno a 2,5GHz. Il fatto che l'ipc superiore a Jaguar, sia ottenuto allungando a dismisura le pipeline, ha permesso di ridurre il consumo, anche con l'ingente quantità di transistor, che comunque è assai minore di quella di un dual core SB....

Agner riporta questo per Jaguar:

"The article cited below indicates a misprediction penalty of 13 clock cycles. In my tests, however, the misprediction penalty ranged from 8 to 19 clock cycles depending on the subsequent instructions. There was no consistent difference between integer and floating point code in this respect."

Riporto nuovamente i dati per BD & compagnia (non c'è XV):

"The misprediction penalty is specified as minimum 20 clock cycles for conditional and indirect branches and 15 clock cycles for unconditional jumps and returns. My measurements indicated up to 19 clock cycles for conditional branches and 22 clock cycles for returns."

Facendo un confronto, nel caso migliore abbiamo 15 - 8 = 7 stadi, e in quello peggiore 22 - 19 = 3 stadi.

Certamente le pipeline sono più lunghe, ma non mi sembra che si possa affermare "a dismisura".

al contrario di bjt2, io non sono affatto convinto che il FO4 di ZEN sia rimasto invariato, se fosse il caso dovremmo attenderci turbo core ben superiore a quello visto con bulldozer, e soprattutto non si capirebbe il motivo per cui limitarsi a 95W con una frequenza base di poco superiore ai 3GHz....a meno di non avere problemi grossi con il silicio.

Zen e BD sono micro-architetture abbastanza diverse, per cui è plausibile che il FO4 sia cambiato.

ritornando alla tua domanda, la risposta è semplice: perchè ai transistor è richiesta una velocità di commutazione inferiore...
Esiste una relazione di proporzionalità inversa tra FO4 e frequenza a parità di Vcore.

i transistor in più per spezzare le pipeline, è sempre compreso in quel +10% di un modulo BD rispetto ad un solo core SB.

Premesso che un +10% di transistor soltanto per spezzare la pipeline mi sembra un'esagerazione, BD si porta dietro un +21% di transistor: dove sono finiti gli altri?

fermo restando che sei stato tu stesso ad affermare che è impossibile che in AMD non sapessero l'ipc di bulldozer a pochi mesi dal lancio,

Assolutamente. Ma anche molto prima, a meno di bug in parti che influenzino le prestazioni.

Una volta che hai il tuo chip funzionante, puoi farci girare del codice, fare dei test, e avere dei dati.

Lo Skylake A0 che ho avuto a disposizione aveva parecchi bug e alcune parti non funzionanti, ma potevo comunque far girare Windows, le applicazioni, e... i miei test. E stiamo parlando di un A0 Intel: il PRIMISSIMO tape-out!

Non ho fatto test prestazionali, e non ero al corrente se ci fossero dei bug che limitassero le prestazioni, ma avrei potuto documentarmi o chiedere, e far girare dei benchmark, se avessi voluto. Cosa che non ho fatto, perché mi pagavano per fare il mio lavoro.

e nonostante ciò hanno pubblicizzato un livello di prestazioni praticamente irraggiungibile.

Ed è forse la prima volta che capita? E' Intel o AMD a essere famosa per le sue slide? Come c'è arrivata a questa nomea?

E quindi se queste sono state ampiamente disattese, il motivo non può essere che ad una componente non sicura al 100% come il silicio (se non bastasse hanno sbagliato le previsioni di vcore e frequenza di k10 e anche le previsioni di vcore e frequenza della cache l3....tre indizi fanno una prova )

L'ho già detto anche in passato che hanno fatto lo stesso errore di Intel col Pentium 4: un'architettura a basso IPC e frequenze elevate, nella speranza di ottenere queste ultime grazie ai futuri processi produttivi.

Evidentemente coi 32nm si aspettavano di più. Ma è stata una questione di fede. Disattesa. E non per questo si può imputare la causa al processo produttivo di per sé.

IBM, inoltre, ha saputo fare di meglio, ma aveva anche altri target sia prestazionali sia di consumi. Difatti i suoi chip hanno raggiunto frequenze elevate, ma con 220W di consumi.

Inoltre con la serie Z, sono aumentate enormemente le prestazioni sia sul ST sia sul MT, perché ha saputo sfruttare al meglio il maggior numero di transistor a disposizione. E in questo caso il silicio non c'entra: se decidi di utilizzare i transistor in un modo o in un altro, è una questione puramente progettale.
Vedi, in proposito, la differenza col POWER7+, per cui IBM ha preferito sfruttare i nuovi transistor per aumentare soltanto la cache L3, lasciando tutto il resto invariato.

Questo a dimostrazione che i transistor sono, invece, molto importanti.

Originariamente inviato da tuttodigitale

queste misure lasciano davvero il tempo che trovano.
anche i 14nm hanno migliorato e di brutto il livello di integrazione rispetto a quanto permesso dai 28nm, all'atto pratico le gpu hanno visto guadagnare "solo" il 60% di transistor a mmq.

Forse perché i 14nm non sono reali?

Originariamente inviato da paolo.oliva2

Cosa c'è cdi incomprensibile in ciò che scrivo? L'ho scritto 1, 2, 3, 4, 5, 6 volte... il mercato AMD l'ha perso BD/32nm vs SB/32nm o l'ha perso BD/32nm vs Haswell/22nm e Broadwell/14nm?

Il punto è che già a 32nm s'è potuto vedere che la micro-architettura di AMD fosse intrinsecamente meno efficiente di quella Intel (e persino dei precedenti Phenom II in ST).

Poi è chiaro che, essendo rimasta al palo dei successivi 28nm, non abbia potuto sfruttare un silicio migliore.

Ma ciò non toglie che invece di ritoccare BD, che era oggettivamente scarsa (vedi i benchmark che ho postato prima), avrebbe potuto puntare a una micro-architettura diversa e più simile alle precedenti, che erano più efficienti.

Invece ha preferito far evolvere BD in tutte le salse, e soltanto con Zen ha dato un taglio netto col passato.

Originariamente inviato da paolo.oliva2

Non voglio sparare stronzate, ma AMD aveva più soldi all'epoca BD di quanti ne poteva avere per Zen, eppure ha fatto un tot di brevetti e per come ha operato Keller, non mi da manco di striscio un modo di lavoro con budget limitato... boh. Si parla di 250 milioni di $ lo sviluppo di Zen... e comunque c'è pure Polaris, Vega, APU... dove cacchio li ha trovati tutti sti soldi? L'ultima commissione di spicco, quella da 300 milioni di $, è servita per pagare GF per avere autonomia di produzione su silici alternativi, io tutti sti soldi in entrata non li vedo...

Perché quei soldi sono sparsi durante tutti e 4/5 anni di sviluppo: non è che AMD li ha scuciti tutti in un colpo...

Originariamente inviato da Ren

No no, ti confondi con i tuoi compagni di merende che giustificavano i risultati mediocri di AMD con il 32nm rispetto ad IBM. Dopo tutte le prove portate da cdimauro con la serie Z (ibm) ancora lo menate con sto 32nm del pianto...

Infatti. Ed è interessante notare che IBM ha usato i benefici dei 32nm in maniera completamente diversa con POWER+ e zNext. Con quest'ultimo che, da mega CISC, si presta molto bene a un confronto con BD.

Originariamente inviato da bjt2

Discussione tra Dresdenboy, Instlat86 e quelli di Canard PC, molto interessante...

https://twitter.com/Dresdenboy/statu...53513031352326

Vari punti:

1) I test AIDA sono troppo belli per essere veri, per questo non li hanno ancora pubblicati. Throughput anche il doppio di Skylake su alcune istruzioni. Instlat86 risponde che skylake/kabylake hanno qualche problema sulla porta 5 e per alcune istruzioni anche bristol ridge ha througput doppio (esempio: VEXTRACTI128)

E' normale: sono micro-architetture diverse, per cui ci sono punti di forza / debolezza da ambo le parti.

2) Il sample che hanno quelli di Canard PC ha problemi con SMT e uopcache, e su semi dicono anche che la MB ha problemi e non ha il firmware per ES più nuovi. D'altronde è un ES A0. Quindi io prenderei con le pinze i risultati più bassi rispetto a New Horizon di Canard PC...

Ma non sono stati fatti gli stessi test, però. Le medie sono relative a bouquet di applicazioni, per "tipologia".

Inoltre non è dato sapere se questi bug affliggono le prestazioni, e in questo caso in che modo.

Altro tweet:

https://twitter.com/InstLatX64/statu...39775944785921


Latenza delle cache... Finalmente decenti...

Sì, nettamente meglio rispetto al passato e in linea fra Haswell e Skylake.

Originariamente inviato da bjt2

https://translate.google.com/transla...-text=&act=url

Maggiori dettagli sul branch prediciton di Zen. Anche qui sembra essere confermato la possibilità di predirre 2 salti per ciclo anche per lo stesso thread...

Lo schema di Zen, all'inizio, conferma il retire di massimo 8 uop.

[tuttodigitale]

Originariamente inviato da Ren

No no, ti confondi con i tuoi compagni di merende che giustificavano i risultati mediocri di AMD con il 32nm rispetto ad IBM. Dopo tutte le prove portate da cdimauro con la serie Z (ibm) ancora lo menate con sto 32nm del pianto...

L'unica prova fornita dalla serie Z, che il SOI dà i suoi frutti con architetture pensatemen e MAGGIORMENTE orientate al clock.

Il power7+ non è stato cosi fortunato: il 10% scarso sul p7 mi pare troppo poco per un die shrink

[cdimauro]

Ho già riportato i dati in passato, per ben due volte: rispetto a POWER7, il POWER7+ ha aumentato il clock, soprattutto col turbo, e consumando di meno.

zNext, in ogni caso, ha portato ENORMI miglioramenti prestazionali a prescindere dal clock (che peraltro è aumentato di poco): perché ha saputo sfruttare MOLTO MEGLIO i tanti transistor in più.

[bjt2]

Originariamente inviato da cdimauro

Inoltre non è dato sapere se questi bug affliggono le prestazioni, e in questo caso in che modo.

Difficile che bug sull'SMT e sulla cache uop non dia problemi prestazionali... Almeno uno dei 2... Poi anche MB in fase beta, dove non funzionano SSD e GPU NVidia... Anche qui difficile che non impatti le prestazioni almeno uno di questi fattori...

Originariamente inviato da cdimauro

Lo schema di Zen, all'inizio, conferma il retire di massimo 8 uop.

Penso a questo punto che il tizio abbia sbagliato la frase... Magari non è la sua lingua nativa (anche se io l'avrei saputo dire senza ambiguità, ma forse era voluta?)

Comunque lo schema del sito giapponese mi da un altro vantaggio per la microcode rom in quella posizione: può sparare 6 uops ciclo, anzichè 4...

[tuttodigitale]

Originariamente inviato da cdimauro

Questo vale solo per le SRAM, che sono i circuiti più semplici.

Il grafico di AnandTech mostra uno scenario diverso. Infatti anche le versioni di SandyBridge con le GPU mostrano una densità diversa, segno che il tutto dipenda dal tipo di circuiti implementato.

su questo siamo d'accordo.

Originariamente inviato da cdimauro

Il numero di transistor è fondamentale per stabile cosa fa il chip.

è fondamentale se il FO4 è comparabile....
se 2 cpu ad una frequenza X lavorano a 1V e l'altra a 1,4V, ti pare che sia così decisivo la grandezza del core?

i core Jaguar, che hanno 15 stadi (dato ufficiale), murano in OC con i 28nm HDL a 2,8GHz@1,475V....
valori molto diversi da quelli di XV.

Originariamente inviato da cdimauro

Certamente le pipeline sono più lunghe, ma non mi sembra che si possa affermare "a dismisura".

le pipe sono in effetti solo leggermente più lunghe, mai detto il contrario

Originariamente inviato da cdimauro

Premesso che un +10% di transistor soltanto per spezzare la pipeline mi sembra un'esagerazione, BD si porta dietro un +21% di transistor: dove sono finiti gli altri?

premesso che non ho fatto i conti sui transistor, ma di primo acchito direi che i 16MB vs 9 MB di cache tra l2 ed l3 siano i maggiori responsabili dell'aumento delle dimensioni del die (sono circa 350 milioni di transistor)..
e acnhe il die è occupata da molti collegamenti HT, necessari anche per la configurazione dual die, oltre ad essere progettati per essere installati in piattaforme 4P.

Originariamente inviato da cdimauro

Com'è possibile, visto che il die di BD è del 46% più grande? Hai delle immagini di confronto?

Nessuna immagine di confronto, mi spiace

Originariamente inviato da cdimauro

Assolutamente. Ma anche molto prima, a meno di bug in parti che influenzino le prestazioni.

OK.

Originariamente inviato da cdimauro

L'ho già detto anche in passato che hanno fatto lo stesso errore di Intel col Pentium 4: un'architettura a basso IPC e frequenze elevate, nella speranza di ottenere queste ultime grazie ai futuri processi produttivi.

5,5GHz non sono una frequenza proibitiva per il SOI, architettura permettendo. e anche abbassando la frequenza non è che si recuperi tanta efficienza....l
poi se proprio vogliamo dirla tutta, c'è uno studio IBM in cui si consiglia un FO4 molto ridotto..

Originariamente inviato da cdimauro

Vedi, in proposito, la differenza col POWER7+, per cui IBM ha preferito sfruttare i nuovi transistor per aumentare soltanto la cache L3, lasciando tutto il resto invariato.

per tale ragione mi sarei aspettato clock maggiore (4,25 vs 4,42 è praticamente la stessa cosa) considerando che di solito i maggiori benefici con lo shrink si hanno proprio con gli elementi a bassa complessità.

Originariamente inviato da cdimauro

Il punto è che già a 32nm s'è potuto vedere che la micro-architettura di AMD fosse intrinsecamente meno efficiente di quella Intel (e persino dei precedenti Phenom II in ST).

l'obiettivo neppure tanto nascosto di AMD era di aumentare le prestazioni nel ST rispetto a k10, e ci sono riusciti.

Originariamente inviato da cdimauro

Ma ciò non toglie che invece di ritoccare BD, che era oggettivamente scarsa (vedi i benchmark che ho postato prima), avrebbe potuto puntare a una micro-architettura diversa e più simile alle precedenti, che erano più efficienti.

ti sei già dimenticato che k10 è stato il primo progetto shrinkato sui 32nm... e a 3 GHz aveva un vcore di 1,4V....

[paolo.oliva2]

Io non mi intendo di software, ma si continua a dire che nei giochi conti IPC*Frequena (visto come potenza massima a core) e che un numero di core >4 sia perfettamente inutile perchè il software non sarebbe in grado di sfruttare.

Ma allora perchè le console game sono l'esatto contrario? IPC*frequenza bassi e 8 core? Perchè AMD ha vinto tutte le commesse? Stando al discorso sopra, un i3 3GHz dovrebbe dare di più e non credo che AMD abbia venduto un Jaguar X8 perchè minor prezzo di un i3 magari perfino senza iGPU.

Le console possono avere uno sviluppo software proprietario, nel senso studiato appositamente per gli 8 core? Ma allora... se ci fosse un'invasione di software game progettato per 8 core e non 8TH, come risulterebbe il mercato?

[Gioz]

Originariamente inviato da paolo.oliva2

Io non mi intendo di software, ma si continua a dire che nei giochi conti IPC*Frequena (visto come potenza massima a core) e che un numero di core >4 sia perfettamente inutile perchè il software non sarebbe in grado di sfruttare.

Ma allora perchè le console game sono l'esatto contrario? IPC*frequenza bassi e 8 core? Perchè AMD ha vinto tutte le commesse? Stando al discorso sopra, un i3 3GHz dovrebbe dare di più e non credo che AMD abbia venduto un Jaguar X8 perchè minor prezzo di un i3 magari perfino senza iGPU.

Le console possono avere uno sviluppo software proprietario, nel senso studiato appositamente per gli 8 core? Ma allora... se ci fosse un'invasione di software game progettato per 8 core e non 8TH, come risulterebbe il mercato?

sviluppare su console è diverso.
tu hai un Hw chiuso con degli sdk e la possibilità di monitorare effettivamente quanto saturi delle risorse a disposizione.
su pc devi gestire la cosa in maniera impersonale per renderlo fruibile a vari livelli con architetture e capacità di calcolo diverse.
spesso su pc fanno porting fatti male proprio perché per girare su tutto le risorse vengono gestite in maniera poco ottimizzata.

[bjt2]

Originariamente inviato da paolo.oliva2

Io non mi intendo di software, ma si continua a dire che nei giochi conti IPC*Frequena (visto come potenza massima a core) e che un numero di core >4 sia perfettamente inutile perchè il software non sarebbe in grado di sfruttare.

Ma allora perchè le console game sono l'esatto contrario? IPC*frequenza bassi e 8 core? Perchè AMD ha vinto tutte le commesse? Stando al discorso sopra, un i3 3GHz dovrebbe dare di più e non credo che AMD abbia venduto un Jaguar X8 perchè minor prezzo di un i3 magari perfino senza iGPU.

Le console possono avere uno sviluppo software proprietario, nel senso studiato appositamente per gli 8 core? Ma allora... se ci fosse un'invasione di software game progettato per 8 core e non 8TH, come risulterebbe il mercato?

Le console moderne hanno molti processi in background e un vero sistema operativo. Servono core per far girare tutta quella roba senza rallentare il gioco. Inoltre ci sono altre cose che richiedono cores: la telecamera 3D di Xbox ad esempio...

[Gioz]

Originariamente inviato da paolo.oliva2

Perchè AMD ha vinto tutte le commesse?

mi sono accorto di aver saltato questo punto.
la ragione può riguardare esclusivamente il prezzo e le potenzialità del connubio cpu/gpu offerta.
la ps3 ad esempio, o la prima xbox, avevano gpu nvidia ma abbinate ad altri processori(il cell ed un celeron 700 - mi pare - per fare un esempio). ora andando in direzione simil pc con architettura di tipo x86 (probabilmente per facilità di programmazione, e nel caso di M$ in particolare per la derivazione dell'o.s. e delle librerie da quelle dell'o.s. pc) non esiste un'alternativa paragonabile ad amd perché:
-intel lato gpu è comunque ad un livello prestazionale inferiore ed è l'aspetto più rilevante nei giochi, che non può essere compensato da cpu più performante (per intenderci una gtx 1080 su un fx 4300 ti offre di più di una gtx 750 su un i7 6700K);
-rimane il pressoché certo abbattimento dei costi prendendo una fornitura unica di apu da amd anziché ad esempio una gpu da nvidia o ati ed una cpu da terzi (ad esempio la xbox 360 vedeva abbinato un ppc ed una gpu ati - che sarà probabilmente costata meno di una nvidia).

[Gioz]

Originariamente inviato da Veradun

- il design termico del prodotto è (molto) semplificato se c'è un solo hot spot invece di due e di nuovo costa molto meno.

vero, non l'avevo preso in considerazione, e al contempo può agevolare la gestione interna/ingombri.

[Crysis90]

Originariamente inviato da gridracedriver

su B&C la notizia è uscita settimana scorsa
http://www.bitsandchips.it/forum/vie...hp?f=3&t=11549

Azz.

[digieffe]

Originariamente inviato da Crysis90

Azz.

non solo... l'avevo pure riportata... non siete attenti

[tuttodigitale]

Originariamente inviato da bjt2

Le console moderne hanno molti processi in background e un vero sistema operativo. Servono core per far girare tutta quella roba senza rallentare il gioco. Inoltre ci sono altre cose che richiedono cores: la telecamera 3D di Xbox ad esempio...

non è solo quello. Anche le librerie fanno certamente la parte da leone, e quelle dx11 sono fortemente legate alle prestazioni del singolo thread.

[tuttodigitale]

Originariamente inviato da paolo.oliva2

Io non mi intendo di software, ma si continua a dire che nei giochi conti IPC*Frequena (visto come potenza massima a core) e che un numero di core >4 sia perfettamente inutile perchè il software non sarebbe in grado di sfruttare.

Ma allora perchè le console game sono l'esatto contrario? IPC*frequenza bassi e 8 core? Perchè AMD ha vinto tutte le commesse? Stando al discorso sopra, un i3 3GHz dovrebbe dare di più e non credo che AMD abbia venduto un Jaguar X8 perchè minor prezzo di un i3 magari perfino senza iGPU.

Le console possono avere uno sviluppo software proprietario, nel senso studiato appositamente per gli 8 core? Ma allora... se ci fosse un'invasione di software game progettato per 8 core e non 8TH, come risulterebbe il mercato?

jaguar come dicevo nei miei ultimi post, è un'architettura impressionante se consideriamo le sue minuscole dimensioni......tra 8 core+4MB di l2 occupa appena 45mmq...un i3, se stringiamo la valuzione ai core e alle cache ha grossomodo le stesse dimensioni sui 32nm bulk, e sui finfet non so quanto sia giusto paragonare i costi in base alle dimensioni.
Senza considerare il fatto che un prodotto monolitico permette di riutilizzare transistor, come il MC di PS4....

dall'altra è inutile girarci attorno, se non sarebbero in grado di sfruttare i core non avrebbero valutato una soluzione del genere, dotata di prestazioni molto basse nel ST, ma avrebbero semplicemente continuato ad utilizzare soluzione gpu e cpu distinte.

[bjt2]

Originariamente inviato da tuttodigitale

non è solo quello. Anche le librerie fanno certamente la parte da leone, e quelle dx11 sono fortemente legate alle prestazioni del singolo thread.

Beh certo... Le DX 12 hanno le loro richieste...

[Ryddyck]

Non so se già postato ma quella preview non finiva lì, c'era anche altro in merito a ryzen http://imgur.com/a/qo9pH

[stefanonweb]

Chiedo agli esperti: Una Apu Zen 4c/8t a che cpu sky/kaby lake potrebbe essere paragonata come prestazioni lato x86 secondo i calcoli fino a qui stimati? E teoricamente quando potrebbero verosimilmente essere commercializzate? Grazie.

[bjt2]

Originariamente inviato da Ryddyck

Non so se già postato ma quella preview non finiva lì, c'era anche altro in merito a ryzen http://imgur.com/a/qo9pH

Varie cose:

IBQ: coda dei bytes dalla L1I. 20x16Bytes. Nelle vecchie CPU era 2 o 4 (non ricordo, comunque poco) x16B. 10 per thread in modalità SMT.
Interessante.

uop cache: 2k istruzioni. Per INTEL se non sbaglio è 1.5K e in Zen comunque non ci vanno le istruzioni microcodificate perchè c'è solo il puntatore. Inoltre in genere le MOP AMD sono più dense delle uop INTEL, ossia in media un programma è tradotto in meno uops in AMD.
Interessantissimo se vero.

uop cache throughput: 8uops ciclo. Questo non è specificato nelle slide di hot chips (ho verificato: 6uop ciclo è il dispatch, come detto anche dai francesi, ma l'output dalla uop cache non era specificato), inoltre mancano microcode rom e stack memfile dal diagramma. Confronta con INTEL che ha 1.5K entry e 6 uop ciclo.
Interessantissimo se vero.