[Thread Ufficiale] Aspettando ZEN

[Piedone1113]

Originariamente inviato da bjt2

Abbassare il FO4 vuol dire abbassare il FO4 di tutta la CPU, quindi anche la cache L2: si aumenta la latenza e stop.

Il problema di BD e la cache L2 è appunto che è la L2 il fattore limitante di BD...

La L2 è il fattore limitante di Bd sia per le latenze alte, sia per il clock basso (rapportato ai voltaggi che servirebbero per far funzionare in 125w la cpu a 4,8 ghz)
L'MC di intel è limitante solo oltre certe frequenze, se non sbaglio andando su di clock con il molti non si modifica le frequenze dell'mc, cambia il sincronismo tra mc e cache, e nonostante tutto oltre una certa freq della cpu il Mc non riconosce più qualche banco su qualche canale.

Non è poi automatico dire rilassare i timing e aumento il clock, lo potresti fare sulle ram, sui memory controller, ma non sugli stadi della pipeline, altrimenti non servirebbe a nulla alzare le frequenze, o sbaglio?

[bjt2]

Originariamente inviato da Piedone1113

La L2 è il fattore limitante di Bd sia per le latenze alte, sia per il clock basso (rapportato ai voltaggi che servirebbero per far funzionare in 125w la cpu a 4,8 ghz)
L'MC di intel è limitante solo oltre certe frequenze, se non sbaglio andando su di clock con il molti non si modifica le frequenze dell'mc, cambia il sincronismo tra mc e cache, e nonostante tutto oltre una certa freq della cpu il Mc non riconosce più qualche banco su qualche canale.

Non è poi automatico dire rilassare i timing e aumento il clock, lo potresti fare sulle ram, sui memory controller, ma non sugli stadi della pipeline, altrimenti non servirebbe a nulla alzare le frequenze, o sbaglio?

Sono i pricnipi del pipelining... Per abbassare il FO4 devo fare più stadi... Mentre la latenza aumenta, il throughput aumenta... Se prima avevo ad esempio 5 stadi e 1 GHz, potevo fare 1G istruzioni al secondo con latenza 5... Se passo a 10 stadi e 2GHz, avrò 2G istruzioni al secondo con latenza 10... Ovviamente se ci sono istruzioni dipendenti salta tutto, ma se sono poche, ho comunque un aumento delle prestazioni...

[digieffe]

Originariamente inviato da xk180j

http://fudzilla.com/news/processors/...n-is-snowy-owl

sarei curioso di sapere quanto perda in frequenza risprtto all'8 core dovrebbero essere entrambi a 95w

al raddoppio dell'intera cpu avrà una frequenza NON inferiore al 71% (quindi una perdita del 29%)
es 8 core 3.4ghz = 16 core 2.4ghz


Edit: anche più del 71% nel caso la cpu richieda un aumento della tensione non lineare e/o ci sia una esplosione del leackage negli alle frequenze più alte.

[digieffe]

Originariamente inviato da paolo.oliva2

Zen APU X4
http://www.christiantoday.com/articl...2017/90516.htm

asp! solo 704 sp... non dico 1024 ma 896 a frequenza più bassa ne potevano mettere

[george_p]

Si, come no, magari è anche vero!
Che ci sarà Zen apu ok ma che questi sappiano già le specifiche ho molti dubbi... quanti click al suo sito con queste esclusive verità

[Piedone1113]

Originariamente inviato da bjt2

Sono i pricnipi del pipelining... Per abbassare il FO4 devo fare più stadi... Mentre la latenza aumenta, il throughput aumenta... Se prima avevo ad esempio 5 stadi e 1 GHz, potevo fare 1G istruzioni al secondo con latenza 5... Se passo a 10 stadi e 2GHz, avrò 2G istruzioni al secondo con latenza 10... Ovviamente se ci sono istruzioni dipendenti salta tutto, ma se sono poche, ho comunque un aumento delle prestazioni...

Questo è palese, ma attenzione, aumentare numero di stadi non deve significare aumentare la latenza della cache, perchè se hai bisogno di svuotare la pipeline devi aspettare il numero di cicli per la sua profondità (non sempre vero, anzi tutt'altro), ma se aumenti anche la latenza cache il totale dell'operazione non è più direttamente proporzionale al solo numero delle pipe, ma bisogna attendere ancora (sperando che i dati siano almeno in l2 perchè altrimenti addio).

Se poi il miglior compromesso sia con FO4 17 (?) o maggiore è relativo al silicio che stai utilizzando.
Mettiamola così:
Per funzionare a 5ghz def il silicio Intel ha bisogno di una densità del 30% minore rispetto a quanto avviene per frequenza a 4ghz.
Ammesso che l'ipc sia identico nel passaggio da 4 a 5 ghz (cosa non vera) avremo un + 25% throughput con un costo del +30% di superfice.
Senza contare che probabilmente avrebbe anche bisogno di un processo di drogaggio e metallizzazione del silicio differente e più costoso.

Considera anche che il passaggio da 4.2 a 4.4 ghz per le cpu intel vede un consumo esponenziale del chip anche a parità di vcore e credo che questo sia dovuto più al silicio che all'architettura.

[bjt2]

Originariamente inviato da Piedone1113

Questo è palese, ma attenzione, aumentare numero di stadi non deve significare aumentare la latenza della cache, perchè se hai bisogno di svuotare la pipeline devi aspettare il numero di cicli per la sua profondità (non sempre vero, anzi tutt'altro), ma se aumenti anche la latenza cache il totale dell'operazione non è più direttamente proporzionale al solo numero delle pipe, ma bisogna attendere ancora (sperando che i dati siano almeno in l2 perchè altrimenti addio).

Se poi il miglior compromesso sia con FO4 17 (?) o maggiore è relativo al silicio che stai utilizzando.
Mettiamola così:
Per funzionare a 5ghz def il silicio Intel ha bisogno di una densità del 30% minore rispetto a quanto avviene per frequenza a 4ghz.
Ammesso che l'ipc sia identico nel passaggio da 4 a 5 ghz (cosa non vera) avremo un + 25% throughput con un costo del +30% di superfice.
Senza contare che probabilmente avrebbe anche bisogno di un processo di drogaggio e metallizzazione del silicio differente e più costoso.

Considera anche che il passaggio da 4.2 a 4.4 ghz per le cpu intel vede un consumo esponenziale del chip anche a parità di vcore e credo che questo sia dovuto più al silicio che all'architettura.

L'esplosione dei consumi è dovuta al vcore. Se fai una architettura a FO4 più basso, per avere 5GHz bastano meno volts e quindi anche meno leakage... Ecco perchè AMD arriva a una frequenza più alta del 14nm INTEL anche sul 28nm... Mica è perchè il processo 28nm è migliore del 14nm INTEL...

[xk180j]

Originariamente inviato da digieffe

al raddoppio dell'intera cpu avrà una frequenza NON inferiore al 71% (quindi una perdita del 29%)
es 8 core 3.4ghz = 16 core 2.4ghz


Edit: anche più del 71% nel caso la cpu richieda un aumento della tensione non lineare e/o ci sia una esplosione del leackage negli alle frequenze più alte.

grazie

[paolo.oliva2]

Originariamente inviato da bjt2

L'esplosione dei consumi è dovuta al vcore. Se fai una architettura a FO4 più basso, per avere 5GHz bastano meno volts e quindi anche meno leakage... Ecco perchè AMD arriva a una frequenza più alta del 14nm INTEL anche sul 28nm... Mica è perchè il processo 28nm è migliore del 14nm INTEL...

Comunque il Vcore del 28nm GF è a dir poco spaventoso per raggiungere i 4GHz (Tuttodigitale aveva postato i CPU-Z), erano tutti >1,4V con punte di 1,55V, praticamente a livello dell'FX 9590.

Io non ho idea di come GF/AMD faccia per contenere l'esplosione del leakage sul 28nm, ma se ciò fosse dovuto in gran parte a tutte le features implementate (ed in minima parte al silicio in sè), il 14nm finfet dovrebbe letteralmente volare.

P.S.
Samsung ha la prossima generazione di processo a 14 nm in esecuzione (LPH, Advanced, LPC), GLOBALFOUNDRIES sta lavorando su HP (High Performance SOI) e LPP + (High Performance / Super Low Power). (Tradotto dal tedesco... https://www.google.it/url?sa=t&rct=j...27178174,d.d2s)

[cdimauro]

Originariamente inviato da bjt2

Loro si sono sempre bullati del fatto che il SOI, a parità di miniaturizzazione, avesse un leakage 10-20 volte di meno di un processo bulk, a parità di Vcore e temperatura... Quindi pensavano di non incappare nel problema del P4...

Anche Intel pensava di arrivare a 10Ghz entro il 2010, e non mi pare fossero gli ultimi arrivati.

Il problema è che già quando è stato raggiunto il Ghz, si sono cominciati a manifestare problemi a salire in frequenza come in passato. Era, insomma, il primo segnale che la cuccagna fosse finita.

Poi c'è stato il P4.

E a questo punto mi chiedo come si poteva bellamente pensare che non potesse succedere altro.

E' ovvio che la fisica metta dei paletti: tanto alla miniaturizzazione, quanto alla frequenza, vcore, e quant'altro.

E poi hanno usato un FO4 di 17, ottimale secondo i paper IBM, e non 13 come il P4...

Come ho già detto altre volte questo non è il mio campo, ma mi sfugge qualcosa. Non s'è detto diverse volte di abbassare il FO4 per salire in frequenza? Perché un FO4 di 17, che è superiore al 13, avrebbe dovuto essere "ottimale" rispetto a quest'ultimo?

Semplicemente hanno semplificato troppo il core: se mettevano 4 ALU e passavano ad una cache inclusiva e magari una L2 separata per core, viste le enormi dimensioni, penso che un 20% in più di IPC non glielo toglieva nessuno... Su semiaccurate c'è un tizio che afferma che è la L2 il collo di bottiglia sia per le prestazioni pure che per salire in frequenza: poi una L2 che serve 2 core deve avere un numero di porte sufficiente, vista la L1 microscopica (16 e poi 32kb)...

Non è solo la cache L2 il problema di BD. IMO il problema più grosso è dovuto alla suddivisione del core in 2 macroALU intere. Come abbiamo già discusso, è meglio una coda unica che 2 specializzate.

Originariamente inviato da Piedone1113

Questo è quello che la gente non vuole capire, ridurre il pp serve a marginalizzare meglio, bassi voltaggi, minori consumi, maggiori frequenze sono effetti collaterali.

*

Originariamente inviato da bjt2

Non sono d'accordo... E' l'architettura core che non è fatta per girare a 5ghz sul bulk intel... Abbassa il FO4 a 17 e vedi come rulla a oltre 5ghz anche sul bulk intel...

Ma non è che puoi abbassarlo arbitrariamente. Serviranno dei cambiamenti notevoli alla microarchitettura.

Il P4, ancora una volta, è un esempio di ciò: il design è completamente diverso da quello del P3, proprio per essere orientato a scalare in frequenza. E da lì l'uso della trace cache per disaccoppiare il backend dal frontend (e dunque dal complesso decoder x86 in primis), 20 stadi per la pipeline (poi addirittura portati a 31, se non ricordo male), e cache L1 dati microscopica, ma molto veloce.

I risultati li conosciamo tutti, mi pare.

Originariamente inviato da bjt2

Sono i pricnipi del pipelining... Per abbassare il FO4 devo fare più stadi... Mentre la latenza aumenta, il throughput aumenta... Se prima avevo ad esempio 5 stadi e 1 GHz, potevo fare 1G istruzioni al secondo con latenza 5... Se passo a 10 stadi e 2GHz, avrò 2G istruzioni al secondo con latenza 10...
Ovviamente se ci sono istruzioni dipendenti salta tutto, ma se sono poche, ho comunque un aumento delle prestazioni...

Il problema è nel codice "general purpose", dove ovviamente ci sono, eccome, le dipendenze. Questo costringe il backend a tenersi in pancia parecchie istruzioni che aspettano di completare l'esecuzione, richiedendo quindi instruction window più grandi e retire logic più complesse. La maggiore latenza non fa che complicare tutto ciò, ovviamente.

Il codice che fa uso di FPU è molto più lineare, ed è anche per questo che è stato tirato fuori il paradigma SIMD. Ci sono anche qui le dipendenze, ma si "sbrogliano" più velocemente.

Originariamente inviato da bjt2

L'esplosione dei consumi è dovuta al vcore. Se fai una architettura a FO4 più basso, per avere 5GHz bastano meno volts e quindi anche meno leakage... Ecco perchè AMD arriva a una frequenza più alta del 14nm INTEL anche sul 28nm... Mica è perchè il processo 28nm è migliore del 14nm INTEL...

Scusa l'ignoranza, ma aumentare le frequenze non vuol dire anche essere più soggetti a interferenze nei segnali?

E abbassando il vcore non si amplificano i problemi d'integrità dei segnali?

Se sì, non è che si possa arbitrariamente pensare di aumentare le frequenze, addirittura diminuendo anche i voltaggi...

[paolo.oliva2]

Secondo me non c'è assolutamente similitudine tra PIV (inteso nei 10GHz) e BD, in primis perchè il PIV è a sè perchè si era nell'era del single core, mentre BD è inglobato con il CMT il quale guadagna un botto rispetto all'SMT.
Inoltre il PIV per essere competitivo doveva arrivare a 10GHz e Intel arrivò a 3,3GHz (con enormi problemi di dissipazione in quanto già il dissi stock non era sufficiente), cioè manco il 33% dell'aspettativa, BD doveva arrivare sui 4,7GHz def, siamo a 4GHz, è mancato il 20% del clock, mica il 67%...

Inoltre, secondo me, BD non è ben rappresentato come archtettura nella fascia FX semplicemente perchè come FX è ancora PD e non XV, e l'aumento del 15% di IPC di certo non sarebbe sufficiente in ST, ma in MT comporterebbe un buon incremento.
Se PD = 100, +15% XV = 115 vs Intel quanto? 170?
Ma in MT 115 + 80% = 207, vs Intel 170 + 30% = 221.

Da notare che i valori sopra riportati sono per parità di clock, ma già oggi, sul 28nm, BD riesce ad ottenere +100MHz come frequenza massima (4,2GHz) rispetto al 6700K (4,2GHz), ma in un discorso >X4, saremmo ad oltre +20% (4,3GHz AMD vs 3,5GHz Intel) e percentuali ben più importanti >X6.

Il divario del PIV vs AMD era talmente ampio che Intel fu costretta a cambiare in toto TUTTO, dall'A alla Z, AMD con BD in primis è ancora in produzione come APU con XV, in secondo luogo il discorso del clock mi sembra tutt'altro che abbandonato, visto che (SEMBRA) l'FO4 di Zen sembra essere il medesimo di BD, inoltre Zen, anche se adottando l'SMT sembra sposare Intel, guardando un die avrebbe più similitudini con BD di quanto le possa avere con Intel. Anche se io non ne capisco molto del dentro dei proci, Zen a me sembra un BD con l'SMT come evoluzione del CMT, del PIV di allora cosa ritroviamo?

In sintesi, non è che voglio difendere BD, CMT e quant'altro, ma trovo dispregiativo per BD l'associazione al PIV perchè di per sè il PIV è stata una ciofeca in quanto progetto e in quanto aspettative... a tutt'oggi BD, come architettura e come potenzialità, sarebbe bastato solamente aver avuto la disponibilità di un silicio che permettesse l'evoluzione da PD a XV e nel contempo l'aumento di moduli (>4m, almeno 6m se non 8) per avere un incremento da +50% di MT anche al doppio... Poi è ovvio che l'ST sarebbe stata sempre a favore di Intel, ma guardiamo a 360°, potenza ST = IPC * frequenza, i 4,2GHz di un 6700K non li ritroviamo in un 6850K, max 3,5GHz, è un IPC inferiore di XV ma con un +25% di frequenza, limano e non di poco la differenza di IPC.

[bjt2]

Originariamente inviato da cdimauro

Come ho già detto altre volte questo non è il mio campo, ma mi sfugge qualcosa. Non s'è detto diverse volte di abbassare il FO4 per salire in frequenza? Perché un FO4 di 17, che è superiore al 13, avrebbe dovuto essere "ottimale" rispetto a quest'ultimo?

E' tutto un compromesso. All'abbassare del FO4 abbassi i ritardi di gate, ma i ritardi RC delle linee di trasmissione rimangono invariati (a meno di fare cavi più "spessi", minore R, ma comunque ci vogliono transistors più potenti per caricare e scaricare più velocemente le capacità parassite e di linea), poichè allo scendere del FO4 ovviamente aumenti il numero di stadi pipeline necessari, e dunque anche la lunghezza totale e la quantità dei "cavi" di collegamento, oltre al numero di registri di disaccoppiamento, ognuno dei quali aggiunge almeno 2.5 FO4, si è calcolato (o forse addirittura simulato) che sotto il FO4 di 7 si va a perdere e che 17 è il miglior compromesso prestazioni/watt e forse anche costo... Non ho letto i papers, ma solo un sunto... E poi credo che fossimo sul 65 o 45 SOI, perchè quei paper servirono a dimostrare che il POWER 6 era si veloce, ma non efficiente dal punto di vista energetico...

Originariamente inviato da cdimauro

Scusa l'ignoranza, ma aumentare le frequenze non vuol dire anche essere più soggetti a interferenze nei segnali?

E abbassando il vcore non si amplificano i problemi d'integrità dei segnali?

Se sì, non è che si possa arbitrariamente pensare di aumentare le frequenze, addirittura diminuendo anche i voltaggi...

Se i ritardi di linea più quelli di gate sono abbassati in proporzione all'aumento della frequenza e il vcore è lo stesso, allora il margine di rumore è lo stesso... Il problema è che abbassando il FO4 diminuisci solo il ritardo di gate e non quello di linea... Quindi dimezzando il FO4 non si può raddoppiare la frequenza... Questo influisce anche sul compromesso e sul limite di cui parlavo prima.

Il Vcore più basso che intendevo è questo: ipotizziamo che tu riesca a trovare un Vcore (magari sotto azoto) a cui Skylake è stabile a 5GHz. Se abbassi il FO4 (e in base alle tensioni di soglia è possibile calcolare di quanto devi abbassarlo), puoi usare un Vcore più basso per i 5GHz e magari ti ritrovi con consumi umani. Ovviamente l'architettura va cambiata. Il processo può essere relativamente più facile se riesci a spezzare tutti gli stadi delle pipeline a metà, dimezzando o quasi il FO4 (in realtà ci sono i 2.5 FO4 dei registri usati per spezzare lo stadio), oppure può essere un casino, come hanno fatto con il P4, in cui hanno anche cambiato e semplificato le ALU e i decoder...

[bjt2]

http://forums.anandtech.com/showpost...postcount=2219

Non so quanto sia affidabile sto tizio, ma dice che gli ES A0 che ci sono in giro hanno base clock 2.8GHz, all core turbo 3Ghz e max turbo 3.2GHz, con frequenza idle 550MHz. Che ci saranno varianti 4 core 65W e 8 core 95W (poi le varianti server a 16, 24 e 32 core) e che almeno inizialmente non ci sarannmo le versioni a 6 core, ma solo core complexes interi, come avevo pensato. Inoltre gli ES x4 hanno la stessa frequenza degli ES x8 e in idle consumano 2.5W i 4 core e 5W gli 8 core... Non male per degli ES A0, se fosse vero...

[capitan_crasy]

Originariamente inviato da bjt2

http://forums.anandtech.com/showpost...postcount=2219

Non so quanto sia affidabile sto tizio, ma dice che gli ES A0 che ci sono in giro hanno base clock 2.8GHz, all core turbo 3Ghz e max turbo 3.2GHz, con frequenza idle 550MHz. Che ci saranno varianti 4 core 65W e 8 core 95W (poi le varianti server a 16, 24 e 32 core) e che almeno inizialmente non ci sarannmo le versioni a 6 core, ma solo core complexes interi, come avevo pensato. Inoltre gli ES x4 hanno la stessa frequenza degli ES x8 e in idle consumano 2.5W i 4 core e 5W gli 8 core... Non male per degli ES A0, se fosse vero...

E' affidabile quanto qualsiasi sconosciuto al suo primo post dove dice cose abbastanza note sulle versioni ES A0...

[paolo.oliva2]

Originariamente inviato da bjt2

http://forums.anandtech.com/showpost...postcount=2219

Non so quanto sia affidabile sto tizio, ma dice che gli ES A0 che ci sono in giro hanno base clock 2.8GHz, all core turbo 3Ghz e max turbo 3.2GHz, con frequenza idle 550MHz. Che ci saranno varianti 4 core 65W e 8 core 95W (poi le varianti server a 16, 24 e 32 core) e che almeno inizialmente non ci sarannmo le versioni a 6 core, ma solo core complexes interi, come avevo pensato. Inoltre gli ES x4 hanno la stessa frequenza degli ES x8 e in idle consumano 2.5W i 4 core e 5W gli 8 core... Non male per degli ES A0, se fosse vero...

La notizia, se vera, sarebbe buona, perchè vorrebbe dire che gli Zen fallati (X6) non possono reggere un volume commerciale idoneo.

Domanda... . la lettura dei dati da e verso la RAM di sistema, da dove parte? Lo chiedo perchè... se parte dai core è un problema, ma se partisse dalla L3 (tipo il dato c'è o non c'è), allora in teoria non ci sarebbe manco bisogno di un ulteriore MC (a parte la banda/n° core), perchè essendo la L3 unificata, partirebbe la lettura/scrittura sulla DDR.

Io ho sempre l'idea che se ci fosse la possibilità (che il socket AM4 supporti 2 MC e/o qualche compromesso per supportare Zen >X8), la genialata di un Zen esempio X12 starebbe nel fatto di poter riciclare tutti i Zen fallati almeno come X4 "sano" e poterli monetizzare quanto un X8 sano nel caso di un Zen X12, a tutto vantaggio del prezzo, perchè il modello top X8 deve comunque integrare le "perdite" dei modelli con frequenza inferiore e/o con n° core inferiore. Un X12 a tutti gli effetti potrebbe costare il doppio di un X8, praticamente prezzando un die Zen fallato tanto quanto un die sano.

In ogni caso, a me sembra che AMD abbia "creato" il socket AM4 per durare certamente più di 1 anno. A mio avviso se il socket AM4 supportasse 1 solo MC, rappresenterebbe già un limite per Zen >X8 e per Zen APU > X4 (se con logica stile BD APU). A parte discorso di bandiera su chi l'ha più lungo... che non è quello che faccio, mi sembra da dementi, visto che il socket AM4 è anteriore alla conoscienza della frequenza massima di 14nm + Zen, e visto che AMD ha sbandierato Zen X8 95W TDP, perchè perdere in toto la possibilità di raggiungere potenze MT di rilievo anche optando per Zen >X8?

[george_p]

Originariamente inviato da capitan_crasy

E' affidabile quanto qualsiasi sconosciuto al suo primo post dove dice cose abbastanza note sulle versioni ES A0...

Quotone

[xk180j]

Originariamente inviato da paolo.oliva2

La notizia, se vera, sarebbe buona, perchè vorrebbe dire che gli Zen fallati (X6) non possono reggere un volume commerciale idoneo.

Domanda... . la lettura dei dati da e verso la RAM di sistema, da dove parte? Lo chiedo perchè... se parte dai core è un problema, ma se partisse dalla L3 (tipo il dato c'è o non c'è), allora in teoria non ci sarebbe manco bisogno di un ulteriore MC (a parte la banda/n° core), perchè essendo la L3 unificata, partirebbe la lettura/scrittura sulla DDR.

Io ho sempre l'idea che se ci fosse la possibilità (che il socket AM4 supporti 2 MC e/o qualche compromesso per supportare Zen >X8), la genialata di un Zen esempio X12 starebbe nel fatto di poter riciclare tutti i Zen fallati almeno come X4 "sano" e poterli monetizzare quanto un X8 sano nel caso di un Zen X12, a tutto vantaggio del prezzo, perchè il modello top X8 deve comunque integrare le "perdite" dei modelli con frequenza inferiore e/o con n° core inferiore. Un X12 a tutti gli effetti potrebbe costare il doppio di un X8, praticamente prezzando un die Zen fallato tanto quanto un die sano.

In ogni caso, a me sembra che AMD abbia "creato" il socket AM4 per durare certamente più di 1 anno. A mio avviso se il socket AM4 supportasse 1 solo MC, rappresenterebbe già un limite per Zen >X8 e per Zen APU > X4 (se con logica stile BD APU). A parte discorso di bandiera su chi l'ha più lungo... che non è quello che faccio, mi sembra da dementi, visto che il socket AM4 è anteriore alla conoscienza della frequenza massima di 14nm + Zen, e visto che AMD ha sbandierato Zen X8 95W TDP, perchè perdere in toto la possibilità di raggiungere potenze MT di rilievo anche optando per Zen >X8?

la trovo un'ipotesi probabile ma penso che la giocheranno fra un anno dall'uscita dell x8

[sgrinfia]

Ciao, ho letto che Zen sarà posticipato nella sua uscita, c'è qualcosa di vero?.

[george_p]

Originariamente inviato da sgrinfia

Ciao, ho letto che Zen sarà posticipato nella sua uscita, c'è qualcosa di vero?.

Se lo leggi su siti affidabili (e oggi si contano sulle dita di una mano) può essere vero e non è detto lo sia, se lo leggi su un canale ufficiale amd è vero.
Se lo leggi altrove sul web poniti sempre il dubbio dell'affidabilità della notizia, qualunque essa sia.

[cdimauro]

Originariamente inviato da paolo.oliva2

Secondo me non c'è assolutamente similitudine tra PIV (inteso nei 10GHz)

I 10GHz erano il piano a lungo termine di Intel, che prevedeva di raggiungerli nel 2010, ovviamente con l'architettura NetBurst del P4.

e BD, in primis perchè il PIV è a sè perchè si era nell'era del single core, mentre BD è inglobato con il CMT il quale guadagna un botto rispetto all'SMT.

Invece proprio il P4 ha introdotto l'SMT (in ambito consumer), con l'Hyperthreading. Dunque il confronto, anche da questo punto di vista, ci sta tutto.

Inoltre il PIV per essere competitivo doveva arrivare a 10GHz e Intel arrivò a 3,3GHz (con enormi problemi di dissipazione in quanto già il dissi stock non era sufficiente), cioè manco il 33% dell'aspettativa, BD doveva arrivare sui 4,7GHz def, siamo a 4GHz, è mancato il 20% del clock, mica il 67%...

Come già detto, il P4 doveva arrivarci nel 2010, mentre è stato ucciso molto prima, anche per altre ragioni.

Il divario del PIV vs AMD era talmente ampio che Intel fu costretta a cambiare in toto TUTTO, dall'A alla Z,

Il divario c'è stato con le prime versioni del P4, anche per certe scelte scellerate, come quella di legarsi mani e piedi con Ranbus e le sue memorie, mentre AMD e concorrenza poterono sfruttare le DDR, che consentivano buona banda di memoria unita a ottime latenze.

Caduto quest'accordo di esclusiva e aumentate nel frattempo le frequenze (il P4 non era certo nato per girare a 1,5Ghz), le cose sono cambiate.

Questo lo puoi controllare tu stesso se vai a vedere i benchmark dell'epoca seguendo l'evoluzione delle varie versioni del P4, e ovviamente degli Athlon di AMD.

AMD con BD in primis è ancora in produzione come APU con XV, in secondo luogo il discorso del clock mi sembra tutt'altro che abbandonato, visto che (SEMBRA) l'FO4 di Zen sembra essere il medesimo di BD, inoltre Zen, anche se adottando l'SMT sembra sposare Intel, guardando un die avrebbe più similitudini con BD di quanto le possa avere con Intel. Anche se io non ne capisco molto del dentro dei proci, Zen a me sembra un BD con l'SMT come evoluzione del CMT, del PIV di allora cosa ritroviamo?

Hyperthreading, bus (all'epoca il Pentium-M adottò il nuovo bus del P4, ovviamente, che è poi stato la basa delle successive evoluzioni), e cache L0 sono le prime cose che mi vengono in mente, a livello microarchitetturale.

In sintesi, non è che voglio difendere BD, CMT e quant'altro, ma trovo dispregiativo per BD l'associazione al PIV perchè di per sè il PIV è stata una ciofeca in quanto progetto e in quanto aspettative...

Mi spiace, ma il confronto ci sta tutto: entrambe erano architetture pensate per bassi IPC, ma puntando sulle alte frequenze.

Ed entrambe sono state un buco nell'acqua, con annesso cambio di (micro)architettura.

P.S: Ho tagliato i discorsi sui FO4 e numeri vari perché non c'è nulla di concreto.

Originariamente inviato da bjt2

E' tutto un compromesso. All'abbassare del FO4 abbassi i ritardi di gate, ma i ritardi RC delle linee di trasmissione rimangono invariati (a meno di fare cavi più "spessi", minore R, ma comunque ci vogliono transistors più potenti per caricare e scaricare più velocemente le capacità parassite e di linea), poichè allo scendere del FO4 ovviamente aumenti il numero di stadi pipeline necessari, e dunque anche la lunghezza totale e la quantità dei "cavi" di collegamento, oltre al numero di registri di disaccoppiamento, ognuno dei quali aggiunge almeno 2.5 FO4, si è calcolato (o forse addirittura simulato) che sotto il FO4 di 7 si va a perdere e che 17 è il miglior compromesso prestazioni/watt e forse anche costo... Non ho letto i papers, ma solo un sunto... E poi credo che fossimo sul 65 o 45 SOI, perchè quei paper servirono a dimostrare che il POWER 6 era si veloce, ma non efficiente dal punto di vista energetico...

Ma allora perché non si tiene fisso a 17 questo benedetto FO4, e le microarchitetture si modellano su questo punto di fisso?

Devono esserci altre motivazioni che portano ad avere un uso così diverso del FO4.

Se i ritardi di linea più quelli di gate sono abbassati in proporzione all'aumento della frequenza e il vcore è lo stesso, allora il margine di rumore è lo stesso... Il problema è che abbassando il FO4 diminuisci solo il ritardo di gate e non quello di linea... Quindi dimezzando il FO4 non si può raddoppiare la frequenza... Questo influisce anche sul compromesso e sul limite di cui parlavo prima.

OK, e questo spiega perché non si scala linearmente in frequenza col FO4.

Il Vcore più basso che intendevo è questo: ipotizziamo che tu riesca a trovare un Vcore (magari sotto azoto) a cui Skylake è stabile a 5GHz. Se abbassi il FO4 (e in base alle tensioni di soglia è possibile calcolare di quanto devi abbassarlo), puoi usare un Vcore più basso per i 5GHz e magari ti ritrovi con consumi umani. Ovviamente l'architettura va cambiata. Il processo può essere relativamente più facile se riesci a spezzare tutti gli stadi delle pipeline a metà, dimezzando o quasi il FO4 (in realtà ci sono i 2.5 FO4 dei registri usati per spezzare lo stadio), oppure può essere un casino, come hanno fatto con il P4, in cui hanno anche cambiato e semplificato le ALU e i decoder...

Beh, i suoi frutti li ha dati: il P4 ha raggiunto frequenze estremamente alte rispetto agli altri processori dell'epoca, e in ambito number crunching (FP) aveva ottime prestazioni.

Il problema è che tutto ciò non era abbastanza per arrivare ai 10GHz, ma soprattutto i consumi sono esplosi già molto prima, "grazie" al leakage.