[Thread Ufficiale] Aspettando ZEN

[digieffe]

Originariamente inviato da gridracedriver

SB sarebbe sandy bridge?

Carrizo è XV ovvero 845, mentre Bristol Ridge sarà sia su mobile che su desktop ed è un Carrizo con steroidi

in ST l'IPC grosso modo è così:

PD 100 ----- +5~7%
SR 105~107 +12~15%
XV 120 ----- +40%
Zn 168

SB = refuso : BD

quindi BristolR è il successore di carizzo prima della apu zen?

[digieffe]

Originariamente inviato da gridracedriver

Fixed

anche a 3ghz rullerebbe abbastanza, ma non stai considerando che L'ES di bulldozer FX-8150 nel giugno 2011 con step B0/B1 girava a 2.8ghz def e 3.2ghz turbo poi portato a 3.6/4ghz come step B2g ad ottobre 2011

ci sono tutte le carte per girare a frequenza def 4ghz e turbo 4.4ghz

e non consideri che salire di frequenza con un fo4 basso è molto più facile e meno dispendioso in termini di watt rispetto ad un fo4 medio come appunto fo4 15~17 vs 22~24

ps. alta frequenza non vuol dire basso IPC per forza

sono d'accordo con il fatto che ci sono tutte le carte per girare a frequenza def 4ghz e turbo 4.4ghz, ma non a 95w... probabilmente 140w

[george_p]

Bisogna poi capire cosa significhi allora "e sfrutta alcune nuove tweak" dove tweak dovrebbe essere "miglioria".
Sono sempre dell'idea che far uscire un excavator per desktop con le stesse prestazioni del carrizo mobile... bah, scelta da polli.

Staremo a vedere quando esce.

[tuttodigitale]

Originariamente inviato da bjt2

Non ricordo dove l'ho letto, comunque mi sembra plausibile l'IPC ST, perchè non si può confrontare mele (SMT) con pere (CMT) e se intentevano throughput, scrivevano throughput e non IPC...

questa dove salta fuori
throughput e ipc sono concetti diversi seppur collegati tra loro. Da quanto IPC è diventato sinonimo di ILP?
uno studio del 2005 dell'University of Rhode Island, è intitolato ILP is Dead, Long Live IPC! , sotto intendendo che è possibile migliorare l'ipc sacrificando le prestazioni nel ST.:

Non voglio che qualcuno ci rimanga male...le latenze sono molto alte, AMD non ha mai parlato di ILP, ma si è fermata ad un generico IPC. E poi che senso ha fare confronti disabilitando il SMT, è pur sempre una caratteristica importante del core ZEN.

Originariamente inviato da davo30

E poi arriva Cioccofoundry con i 14nm che reggono al massimo 3ghz e siamo punto è a capo.

Inviato dal mio XT1092 utilizzando Tapatalk

se reggono massimo 3 GHzcon un fo4 17, sulla carta sono solo 2,1GHz per un FO4 24....
se il silicio è pessimo lo sarà anche per l'architettura ad alto IPC

Originariamente inviato da davo30

Si ma da 3 a 5ghz è come passare da una panda a un Ferrari..... Mi pare improbabile che abbiano scelto di rifare un'architettura basata sulle alte frequenze. Per me sarebbe una scelta totalmente folle, più che altro vista la fonderia partner che si ritrova

invito a riflettero di quanto sia andato bene k10 sui 32nm , con ben 6 mesi di sviluppo non programmato.
il silicio non guarda in faccia a nessuno. Se fa schifo, fa schifo, c'è poco da fare.

[tuttodigitale]

Originariamente inviato da digieffe

sono d'accordo con il fatto che ci sono tutte le carte per girare a frequenza def 4ghz e turbo 4.4ghz, ma non a 95w... probabilmente 140w

manca un elemento fondamentale la complessità di ZEN.
Come ha detto bjt2, al momento non c'è motivo per pensare ad un decadimento delle prestazioni per transistor rispetto a XV..
un +40% di ipc potrebbe tradursi in appena +40% (pure meno) rispetto ad XV.
Questo significherebbe che un core Skylake sarebbe comunque più grande del 50% circa...un octa core potrebbe essere più piccolo a di un 6 core..
considerando che il FO4, a 4 GHz potrebbe voler dire 1-1,1V....probabilmente saremmo abbondantemente sotto al TDP...

[Free Gordon]

Originariamente inviato da bjt2

Guardando le latenze delle istruzioni direi di NO: Jaguar ci mette 43 cicli per fare una divisione intera a 128/64 bit. Ed è una architettura low cost e low power. Zen ci mette circa il doppio e un po' di più di BD. Perchè l'architettura di punta dovrebbe metterci di più di una a basso consumo? L'unica spiegazione è che il FO4 di Zen è al massimo pari a quello di BD...

Quindi non ho capito na fava

Se ha lo stesso FO4 di BD, non dovrebbe avere una pipe con molti stadi e vocazione per le alte frequenze? Quindi, in teoria, un IPC molto più basso di un Haswell/Broadwell?

[tuttodigitale]

Originariamente inviato da paolo.oliva2

@Bjt2

A prescindere da quale frequenza def potrà arrivare Zen X8, credo che comunque il 14nm FinFet abbia una impennata di TDP oltre una certa frequenza.

questa frequenza è 4,1GHz HDL
4,7GHz HPL
su uno sconosciuto core ARM (visto che è Samsung credo sia l'a72). C'è da stare tranquilli

Stasera cerco quel bel grafico (giuro).. c'è anche l'andamento del consumo (per adesso ti accenno che mi è sembrato straordinariamente buono) a variare della frequenze, con le varie combinazioni di transistor e librerie

[Free Gordon]

Originariamente inviato da bjt2

http://forums.anandtech.com/showpost...&postcount=187
Ancora sulle AVX: Carrizo è più lenta su AVX di Skylake, mentre Jaguar, nonostante il clock più basso, rivaleggia con Skylake e lo batte anche in un test. Il team di jaguar è confluito in quello di Zen e si aspetta che Zen sia una sorta di doppio Jaguar che esegue 2 thread in SMT, ottimizzato per le alte frequenze (leggi: con un FO4 minore di Jaguar)...
EDIT: Jaguar straccia Skylake nella latenza, anche assoluta, tenendo conto del clock, ma ovviamente skylake lo straccia nel throughput perchè ha 2 unità a 256bit contro le una a 128b di jaguar... Ma se accoppi la latenza di jaguar, con le 4 pipeline FP128...

Quindi sarebbero partiti dall'architettura jaguar...
Sinceramente ci speravo, dall'alto della mia ignoranza, a occhio mi è sempre parsa la cosa più sensata..

[Free Gordon]

Originariamente inviato da gridracedriver

le hanno fuse
hanno preso il meglio di XV, il meglio di Jaguar e aggiunto il talento di Keller

Speriamo sia un minestrone piccante e afrodisiaco!

Forza AMD!!!!

[bjt2]

Originariamente inviato da tuttodigitale

questa dove salta fuori
throughput e ipc sono concetti diversi seppur collegati tra loro. Da quanto IPC è diventato sinonimo di ILP?
uno studio del 2005 dell'University of Rhode Island, è intitolato ILP is Dead, Long Live IPC! , sotto intendendo che è possibile migliorare l'ipc sacrificando le prestazioni nel ST.:

Questa non l'ho capita. IPC sta per istruzioni per clock. Migliorare l'IPC sacrificando le prestazioni nell'ST può solo significare che per avere un IPC più alto, si è dovuti sacrificare il clock massimo... Per IPC in ST intendo dire proprio quello che ho detto: istruzioni per clock con un core Zen caricato con un solo thread... Indipendentemente dal fatto che per salire in IPC hanno dovuto sacrificare il clock massimo oppure no (come noi speriamo). Cos'altro può significare?

Originariamente inviato da Free Gordon

Quindi non ho capito na fava

Se ha lo stesso FO4 di BD, non dovrebbe avere una pipe con molti stadi e vocazione per le alte frequenze? Quindi, in teoria, un IPC molto più basso di un Haswell/Broadwell?

Si può fare una architettura a basso FO4 e alto IPC...

Originariamente inviato da Free Gordon

Quindi sarebbero partiti dall'architettura jaguar...
Sinceramente ci speravo, dall'alto della mia ignoranza, a occhio mi è sempre parsa la cosa più sensata..

Guardando le prestazioni AVX si, ma il divisore intero è più lento di quello di Jaguar...

[Mister D]

Originariamente inviato da tuttodigitale

Voglio solo ricordare che è solo la nostra interpretazione, magari viziata dagli ottimi risultati dell'architettura Intel, ci ha portato a credere fin da subito ad un aumento di tale entità nel ST.. Ma chi l'ha detto? AMD? Certo che no!

+40% di ipc core to core, da che mondo è mondo, significa che un core esegue complessivamente +40% di istruzioni per ciclo di clock. E, guarda caso, il SMT è una tecnica utile ad aumentare l'ipc attraverso il parallelismo a livello di thread (TLP).
Siamo noi, che abbiamo interpretato questo fatto come Single Threaded IPC, quello ottenuto mediante il parallelismo a livello di istruzione (ILP).

occhio. che 4GHz +40% di ipc complessivo, siamo già a livello di un esacore, e in 95W non è male. A 5GHz, cosa tutt'altro che remota (viste le latenze sembrerebbe raggiungibile in piena efficienza addirittura con le HDL ) , siamo a livelli superiori dell'octa-core (prestazioni core to core più alte )

Ho qualche perplessità sull'ipc, ma le prestazioni, con un clock di SOLI 4GHz, saranno estremamente positive, soprattutto considerando i 95W, in tutti i casi, anche quello di ipc basso...

Tuttodigitale e lo dici come me??
Sono sempre stato un sostenitore dell'architettura BD e un fortemente critico sulla prima implementazione causa sia sfiga atavica sui pp soi sia su alcune scelte sbagliate dettate chissà da quali ragionamenti (poco tempo per arrivare in tempo sul mercato quando si era già in ritardo, aspettative altissime sul silicio, ingegneri che avevano alzato il gomito, boh) ergo a me fa piacere vedere che hanno mantenuto lo stesso FO4 a patto che la cpu vada indipendentemente dal silicio e questo vuol dire che sebbene la tua teoria possa essere valida c'è un ma. Ok il SMT aiuta il parallelismo ma se loro intendono quello non puoi scrivere, per me, +40% IPC rispetto core XV.
Se era quello avrebbero messo +40 rispetto modulo XV (perché il CMT è un altro metodo di aumento del parallelismo, a livello di thread e non di istruzione). Io rimango dell'idea che visto quanto amd abbia preso m*** in faccia sulle prestazioni in ST dei propri core, penso invece che quel +40% sia da intendersi esattamente sul core singolo e in ST. E poi aggiungi il SMT come aumento in MT a contrasto di una vera seconda unità integer di un mudulo.
In definitiva credo che sia più valido il calcolo mio modo1 che il modo2 (+40% modulo XV SMT compreso) e se ti ricordi il calcolo modo1 veniva minore del modo2.
La tua obbiezione è che si potrebbe pensare: ma come cavolo si fa ad aumentare in ST del 40% le prestazioni di un core di solo IPC senza considerare il SMT e senza aumentare il FO4? Risposta: Keller

[tuttodigitale]

Originariamente inviato da bjt2

Questa non l'ho capita. IPC sta per istruzioni per clock. Migliorare l'IPC sacrificando le prestazioni nell'ST può solo significare che per avere un IPC più alto, si è dovuti sacrificare il clock massimo... Per IPC in ST intendo dire proprio quello che ho detto: istruzioni per clock con un core Zen caricato con un solo thread... Indipendentemente dal fatto che per salire in IPC hanno dovuto sacrificare il clock massimo oppure no (come noi speriamo). Cos'altro può significare?

IPC significa semplicemente istruzioni per clock: un supercomputer elabora certamente più istruzioni per ciclo di clock grazie alle migliaia di unità di calcolo presenti...
un aumento dell'ipc si può ottenere anche aumentando semplicemente le unità di calcolo, mediante il parallelismo a livello di thread

Originariamente inviato da gridracedriver

mi focalizzerei su questo punto

è stato apertamente detto che è una architettura orientata a 360°, per tanto fatta anche per viaggiare a medio-basse frequenze senza sacrificare troppo le prestazioni a vantaggio del TDP (mobile?).

il fo4 17, è secondo il famoso studio IBM, adatto anche al mobile.Ed XV ha confermato ampiamente questo fatto..

PS quella famosa (a furia di ripeterlo) ignota architettura Arm, gira a 3,3 GHz (3 GHz con buona efficienza) con transistor RVT, quelli usati dai SoC da pochi watt, seppur appesantiti dalle HDL. Penso di avere detto tutto ,

[bjt2]

Originariamente inviato da tuttodigitale

IPC significa semplicemente istruzioni per clock: un supercomputer elabora certamente più istruzioni per ciclo di clock grazie alle migliaia di unità di calcolo presenti...
un aumento dell'ipc si può ottenere anche aumentando semplicemente le unità di calcolo, mediante il parallelismo a livello di thread

Infatti Zen ha più porte di INTEL e anche di BD e potenzialmente potrebbe avere un IPC in ST anche più alto dei vari INTEL... Ma ovviamente poi ci sono le dipendenze tra le varie istruzioni e l'esecuzione speculativa e out of order ecc...

Attenzione: io mi riferisco all'IPC di una singola unità (CPU core) e con un solo thread... L'IPC che tu citi di un supercomputer è appunto il numero di istruzioni TOTALI (medio, massimo, a seconda di cosa si vuole dire) che un sistema può processare per clock, se caricato con un numero adeguato di thread, ad esempio PEAK FLOPS per una GPU, oppure nell'era delle battaglie RISC vs CISC si confrontavano le MIPS medie o su un dato carico di riferimento, ma qui era già più difficile perchè la I sta per istruzioni, mentre in FLOPS la O sta per operazioni ed è più definita: ad esempio una FMAC è una istruzione ma due operazioni... Per risolvere sono stati inventati i benchmark come lo SPEC (int, fp, totale), in modo da definire una prestazione più o meno assoluta... Insomma un casino...

[Mister D]

Originariamente inviato da tuttodigitale

questa dove salta fuori
throughput e ipc sono concetti diversi seppur collegati tra loro. Da quanto IPC è diventato sinonimo di ILP?
uno studio del 2005 dell'University of Rhode Island, è intitolato ILP is Dead, Long Live IPC! , sotto intendendo che è possibile migliorare l'ipc sacrificando le prestazioni nel ST.:

Non voglio che qualcuno ci rimanga male...le latenze sono molto alte, AMD non ha mai parlato di ILP, ma si è fermata ad un generico IPC. E poi che senso ha fare confronti disabilitando il SMT, è pur sempre una caratteristica importante del core ZEN.

cut...

Quello studio appunto (e intuisco dal titolo molto espressivo) sembrerebbe dire che se aumentare ancora la complessità di un core a livello di pipeline (ergo >FO4 o aumento n.ro pipeline -> modi di incremento dell'ILP) è poco fattibile per aumento die size (perché si aumentano i transistor con quei 2 metodi di incremento dell'ILP) che a suo volta fa diminuire la resa produttiva e le frequenze gestibili da quell'architettura, si può aumentare l'IPC in altro modo. Ora io non me la sono letto l'articolo (e se riesci a trovarlo e postarlo, gliela do volentieri una letta) suppongo che quando dice IPC non intenda anche troughput ma proprio l'aumento delle istruzioni processate in un ciclo di clock. Probabilmente suggerisce che è arrivato il momento di ripensare le istruzioni, le varie operazioni su queste e su tutti gli altri possibili colli di bottiglia che stanno intorno al core, soprattutto se il core è già complesso. E questo lo ricollego allo studio di IBM, ricordato ancora da bjt2 e che anche tu conosci, in cui il FO4 17 è idealmente il miglior compromesso per massimizzare IPC*freq/consumo. IPC*freq che ricordo essere le IPS istruzioni per secondo.
Detto questo se il livello di parallelismo delle istruzioni può essere aumentato attraverso aumento del numero delle pipe o della complessità delle stesse, il SMT non ha questo scopo. Il SMT aumenta il thruoghput (la tradurrei come capacità di elaborazione) attraverso lo sfruttamento dei tempi morti delle stesse pipe simulando all'OS la presenza di uno o più core. E infatti in un SMT a 2 vie ogni core processa simultaneamente 2 thread e l'OS pensa che ci siano 2 core. Ma quando processa 2 thread? Quando questi 2 benedetti thread non sono in relazione di dipendenza e quando le pipeline sono in attesa per uno dei due. Quando la pipe è in attesa? Dipende dal software. Se il software ha codice che può essere parallelizzato questo viene gestito in tanti piccoli thread e non essendo in relazioni di dipendenza vengono messi in pasto ai core che però rimangono singoli e solo per il raddoppio dei registri possono processare 2 thread, ma se il software è composto da codice seriale il SMT potrà far poco o nulla. E poi si aggiunge l'ottimizzazione del codice di un software. Se un codice, anche seriale, è scritto per ottimizzare i tempi di elaborazione farà stallare poco le pipe (ergo pochi tempi morti) ergo ancora entrerà poco in gioco il SMT. Viceversa un software scritto ad cacchium sai quanti tempi morti può introdurre? Ergo il SMT ti aiuta, altrimenti puoi avere la tua potentissima architettura a IPC stellare (chi ha detto intel?) e poi girarsi i pollici
Dove voglio arrivare? Semplicemente che sarebbe stato poco furbo per amd fare una previsione sul loro SMT perché nonostante in fase di progettazione e sviluppo prototipico abbiano degli strumenti di simulazione, come fai a sapere quando realmente uscirà la tua cpu come sarà scritto il software??? E' da pazzi pensare di tirare fuori un numero medio da sbattere sul tavolo degli azionisti (e poi sui nostri monitor). Pensaci ma è più facile che con tutto quello che hanno progettato su carta abbiano fatto simulazioni su quante istruzioni il singolo core possa processare in un ciclo di clock. Ma non avete notato che se per llano si erano sbilanciati sulla frequenza sulle slide qua su zen hanno scritto solo cose sicure:
- architettura fortemente rivista con "disegno completamente nuovo del core" basata su IPC alto (e qua si sono sbilanciati su un numero);
- adozione del SMT per aumentare il thruoghput;
- Alta banda passante e sistema di cache a bassa latenza (ma quanto bassa? e con riferimento a che frequenza?????);
- cpu ad alta efficienza grazie ai Finfet.

Questo si legge dalle slide oltre quella famosa del +40%. Non hanno specificato nulla su cui non potevano dare numeri (e meno male dico io, perché forse con l'altra dirigenza avremmo avuto slide piene zeppe di numeri su previsioni fatte dall'Ing. Cane cit. "Mille") e cioè quando basse le latenze perché dipende dal silicio, quanto efficiente perché dipende dal silicio e quanta frequenza perché dipende dal silicio.
L'unico numero è sull'IPC che è difficile da considerare in MT perché quello sarebbe ancora il thruoghput. Anzi hanno proprio evidenziato "Zen core" "Excavatore core". Non so mica, ma cosa dovevano scrivere? Quel +40% per me si riferisce all'ipc in st e non vedo altra strada.

PS: ho fatto il mio mappazzone ah ah

[Ren]

Originariamente inviato da tuttodigitale

questa frequenza è 4,1GHz HDL
4,7GHz HPL
su uno sconosciuto core ARM (visto che è Samsung credo sia l'a72). C'è da stare tranquilli

Stasera cerco quel bel grafico (giuro).. c'è anche l'andamento del consumo (per adesso ti accenno che mi è sembrato straordinariamente buono) a variare della frequenze, con le varie combinazioni di transistor e librerie

Dai che siamo curiosi...

Cerca anche le condizioni del test, magari è stato fatto su Marte, dove i TDP sono bassi ad alta frequenza...

[paolo.oliva2]

Originariamente inviato da Free Gordon

Quindi sarebbero partiti dall'architettura jaguar...
Sinceramente ci speravo, dall'alto della mia ignoranza, a occhio mi è sempre parsa la cosa più sensata..

Veramente quando era uscito Jaguar che non aveva il CMT, io avevo detto che se il problema fosse il CMT, perchè non sviluppare Jaguar? Mi hanno mangiato la faccia icendo che era un procio per gioco.....

[Ren]

Originariamente inviato da bjt2

Una cosa che non sapevo: 4 cicli di latenza ipotizzati per la L1... Una tale alta latenza vuol dire o che AMD fa schifo nel fare caches, oppure che Zen è una CPU ad alto clock... Scegliete pure...

Anche intel usa 4 cicli di latenza, forse dettati dalla complessità del BP.

[bjt2]

Originariamente inviato da Ren

Anche intel usa 4 cicli di latenza, forse dettati dalla complessità del BP.

Magari ha molte vie...

[paolo.oliva2]

Originariamente inviato da Mister D

Quello studio appunto (e intuisco dal titolo molto espressivo) sembrerebbe dire che se aumentare ancora la complessità di un core a livello di pipeline (ergo >FO4 o aumento n.ro pipeline -> modi di incremento dell'ILP) è poco fattibile per aumento die size (perché si aumentano i transistor con quei 2 metodi di incremento dell'ILP) che a suo volta fa diminuire la resa produttiva e le frequenze gestibili da quell'architettura, si può aumentare l'IPC in altro modo. Ora io non me la sono letto l'articolo (e se riesci a trovarlo e postarlo, gliela do volentieri una letta) suppongo che quando dice IPC non intenda anche troughput ma proprio l'aumento delle istruzioni processate in un ciclo di clock. Probabilmente suggerisce che è arrivato il momento di ripensare le istruzioni, le varie operazioni su queste e su tutti gli altri possibili colli di bottiglia che stanno intorno al core, soprattutto se il core è già complesso. E questo lo ricollego allo studio di IBM, ricordato ancora da bjt2 e che anche tu conosci, in cui il FO4 17 è idealmente il miglior compromesso per massimizzare IPC*freq/consumo. IPC*freq che ricordo essere le IPS istruzioni per secondo.
Detto questo se il livello di parallelismo delle istruzioni può essere aumentato attraverso aumento del numero delle pipe o della complessità delle stesse, il SMT non ha questo scopo. Il SMT aumenta il thruoghput (la tradurrei come capacità di elaborazione) attraverso lo sfruttamento dei tempi morti delle stesse pipe simulando all'OS la presenza di uno o più core. E infatti in un SMT a 2 vie ogni core processa simultaneamente 2 thread e l'OS pensa che ci siano 2 core. Ma quando processa 2 thread? Quando questi 2 benedetti thread non sono in relazione di dipendenza e quando le pipeline sono in attesa per uno dei due. Quando la pipe è in attesa? Dipende dal software. Se il software ha codice che può essere parallelizzato questo viene gestito in tanti piccoli thread e non essendo in relazioni di dipendenza vengono messi in pasto ai core che però rimangono singoli e solo per il raddoppio dei registri possono processare 2 thread, ma se il software è composto da codice seriale il SMT potrà far poco o nulla. E poi si aggiunge l'ottimizzazione del codice di un software. Se un codice, anche seriale, è scritto per ottimizzare i tempi di elaborazione farà stallare poco le pipe (ergo pochi tempi morti) ergo ancora entrerà poco in gioco il SMT. Viceversa un software scritto ad cacchium sai quanti tempi morti può introdurre? Ergo il SMT ti aiuta, altrimenti puoi avere la tua potentissima architettura a IPC stellare (chi ha detto intel?) e poi girarsi i pollici
Dove voglio arrivare? Semplicemente che sarebbe stato poco furbo per amd fare una previsione sul loro SMT perché nonostante in fase di progettazione e sviluppo prototipico abbiano degli strumenti di simulazione, come fai a sapere quando realmente uscirà la tua cpu come sarà scritto il software??? E' da pazzi pensare di tirare fuori un numero medio da sbattere sul tavolo degli azionisti (e poi sui nostri monitor). Pensaci ma è più facile che con tutto quello che hanno progettato su carta abbiano fatto simulazioni su quante istruzioni il singolo core possa processare in un ciclo di clock. Ma non avete notato che se per llano si erano sbilanciati sulla frequenza sulle slide qua su zen hanno scritto solo cose sicure:
- architettura fortemente rivista con "disegno completamente nuovo del core" basata su IPC alto (e qua si sono sbilanciati su un numero);
- adozione del SMT per aumentare il thruoghput;
- Alta banda passante e sistema di cache a bassa latenza (ma quanto bassa? e con riferimento a che frequenza?????);
- cpu ad alta efficienza grazie ai Finfet.

Questo si legge dalle slide oltre quella famosa del +40%. Non hanno specificato nulla su cui non potevano dare numeri (e meno male dico io, perché forse con l'altra dirigenza avremmo avuto slide piene zeppe di numeri su previsioni fatte dall'Ing. Cane cit. "Mille") e cioè quando basse le latenze perché dipende dal silicio, quanto efficiente perché dipende dal silicio e quanta frequenza perché dipende dal silicio.
L'unico numero è sull'IPC che è difficile da considerare in MT perché quello sarebbe ancora il thruoghput. Anzi hanno proprio evidenziato "Zen core" "Excavatore core". Non so mica, ma cosa dovevano scrivere? Quel +40% per me si riferisce all'ipc in st e non vedo altra strada.

PS: ho fatto il mio mappazzone ah ah

Onestamente trovo tutto a rigor di logica, anche perchè

- architettura fortemente rivista con "disegno completamente nuovo del core" basata su IPC alto (e qua si sono sbilanciati su un numero);

Direi che la riga sopra esclude quella sotto,

- adozione del SMT per aumentare il thruoghput;

Inoltre non avrebbe senso confrontare un core XV con un core Zen con SMT... al limite sarebbe stato logico il confronto tra il modulo XV (2 TH) ed il core Zen con SMT (2TH).

Poi vorrei aggiungere... io di tutti i cicli delle operazioni e qualsivoglia, mi perdo... però credo che il Capitano abbia dato la spiegazione più semplice... cioè BD con CMT e pipe lunghe e relativo FO4 non è che non andava bene, ma BD era troppo "snello" e AMD non ci aveva speso una tozza per potenziare Cache e predizione... e poi c'è stato il crack del silicio che non ha permesso nè di raggiungere le frequenze prefissate e nè di aumentare il numero di core.
XV va meglio semplicemente perchè l'adozione delle HDL + 28nm ha ridotto il TDP e raggiunto delle frequenze accettabili,, unito all'aumento di IPC. Ma perchè Steamroller/XV non sono usciti sul 32nm SOI? Semplicemente perchè aumentando l'IPC (e quindi il TDP a core), o avrebbero dovuto abbassare la frequenza finale o ridurre il numero di core per rimanere nei 125W TDP. La minchiata che si dice che AMD non ha voluto investire su BD, è una bufala, visto che anche il prox Carrizo è pur sempre BD.

Riassumendo, io posso dire (da non tecnico procio) che l'IPC di BD dipende da tutto, ma quanto influisce la cache L0? Quanto le latenze delle cache? Quanto la FP condivisa e quant'altro? Bisogna inquadrare l'insieme... se Intel fa l'architettura X e poi passa alla Y ma la Y ha le stesse cache (latenza, dimensioni, ecc) e le stesse componenti I/O,, è chiaro che l'aumento IPC è risicato, mica può fare i miracoli.
Ma non è il caso di Zen... XV è un BD, XV2 è un BD con gli estrogeni, Zen fa il mistone prendendo il meglio di XV con il contorno di quello che Intel ha nelle cache, nella condivisione, nelle latenze, e bla bla bla, è ovvio che l'aumento di IPC è senz'altro superiore a quello del 5% medio di Intel.

[Ren]

Originariamente inviato da bjt2

Magari ha molte vie...

Le evoluzioni del P6 hanno spesso alternato le vie da 4 a 8, ma se non ricordo male i 4cicli sono stati implementati nel Pentium M.