[Thread Ufficiale] Aspettando ZEN

[Ren]

Originariamente inviato da tuttodigitale

Ho fatto i calcoli, sono 19mmq per il dual core Cyclone con cache l2, praticamente identico ad un modulo XV con 1MB l2 (entrambi su 28nm e HDL)
un dual core typhoon con cache l2, è grande 12,9mmq, che moltiplicatore per il maggior fattore di integrazione (2,1x) dei 20nm fa 27mmq..

a maggior ragione twister è una cpu dalla complessità enorme, paragonabile a sandy bridge....

Rifai i calcoli che i numeri di partenza sono sbagliati.

A7 CPU 28nm - 17mm2
A8 CPU 20nm - 12.2mm2
A9 CPU 16FF+(meno di mezzo nodo di scaling) - 13.5mm2 (con il triplo di L2)

Il fattore di integrazione che hai usato è riferito allo scaling della SRAM, la logica scala meno...

[tuttodigitale]

li ho ricavati con un programma di fotoritocco, non credo di aver sbagliato così tanto .

Se non scalano bene neppure le CPU da smartphone, che hanno obiettivi di frequenza assi più modesti, non avrebbe granchè senso la corsa alla miniaturizzazione...detto questo i core skylake sono piccolissimi: siamo passati dai 17,5mmq a 6,85mmq da SB a skylake (core+l2) per un fattore di integrazione pari a 2,5x (in realtà superiore considerando che skylake ha 2 pipeline e 1 decoder e tante altre cose in più)

[bjt2]

Originariamente inviato da Ren

Mi riferivo alla questione pipeline da 16 a 9 stadi con aumento di clock del 40%. Com'è possibile ?

cmq le pipeline fp sono indipendenti come in zen.

Twister(A9) può fare 3 mul(128bit).

Per misurare la profondità di una pipeline uno non può che far altro che misurare la latenza di branch mispredicition. Infatti se leggete bene non dice che la pipeline è a 9 stadi, ma che la branch misprediction è scesa a 9 cicli. Quando si predice erratamente un salto, la cosa più semplice e bug free è svuotare la pipeline e ricominciare daccapo. In tal modo l'istruzione che segue il salto sarà completata quando avrà passato tutta la pipeline. Ma se quando arriva un salto inizi a fare il prefetch anche dell'altro ramo e, visto che hai 6 decoder, magari inizi anche a usare metà decoder per decodificarle, puoi ridurre la latenza di mispredict. Visto che non c'è il SMT si potrebbe fare così, come se fossero due thread separati...

AMD ha anche un brevetto per il checkpointing che serve per ridurre tale latenza, ma non credo che faccia la stessa cosa, altrimenti il brevetto non sarebbe stato approvato

Originariamente inviato da plainsong

Che abbiano effettivamente ridotto la branch misprediction penalty da 16 a 9 cicli di clock può implicare che abbiano accorciato la pipeline, ma questo non significa che l'abbiano portata a 9 stadi.

vedi sopra

Originariamente inviato da tuttodigitale

x bjt2
sicuro che non ti confondi (mi confondo anch'io non ti preoccupare) wide-issue con il wide instruction execution? (ovvero la cpu in questione sarebbe un 6-wide issue e 9-wide dispatch)

Chissà magari anche le ALU di ZEN saranno sulla falsa riga di twister.

Il problema è che IBM usa issue per il dispatch e INTEL usa un'altra convenzione... Non so ARM o Apple che convenzione usano... Per AMD issue significa mandare in esecuzione e dispatch mettere in coda dai decoder... Ma poichè i decoder sono 6 immagino che issue si riferisca ai decoder... Ricordo che il set di istruzioni ARM è più "RISC" di quello INTEL, quindi avere più decoder non implica che il software giri più veloce...

Originariamente inviato da Ren

Da quello che si legge, sono 6 istruzione realmente in esecuzione OutOfOrder.

ps. cmq anandtech ha davvero troppi dettagli(non dichiarati da apple) per cannare la storia del misspredict...

Se il diagramma è esatto, le istruzioni in esecuzione possono essere fino a 9...

Originariamente inviato da tuttodigitale

7 cicli sono comunque enormi, considerano che la fase di decodifica, in una CPU ARM, è marginale rispetto ad una CPU x86..

vedi sopra

Originariamente inviato da Ren

Lo so bene, infatti è davvero un balzo miracoloso...

vedi sopra

Originariamente inviato da tuttodigitale

Qui nasce una domanda per bjt2:
Le misure di anandtech sono attendibili?
Dice di aver analizzato la penalità media, non avendo informazioni sul numero degli stadi. Ma questa è condizionata enormemente dalle missprediction eventuali nella l1 e l2 (in bulldozer significa perdere altri 20 cicli aggiuntivi). A me pare pure poco 16 medi per typhon.
Voglio spiegazioni. Palla a te BJT2.

Beh, penso che facciano andare a regime le caches e poi facciano parecchi cicli... Quindi si, credo siano affidabili...

[digieffe]

Originariamente inviato da bjt2

Per misurare la profondità di una pipeline uno non può che far altro che misurare la latenza di branch mispredicition. Infatti se leggete bene non dice che la pipeline è a 9 stadi, ma che la branch misprediction è scesa a 9 cicli. Quando si predice erratamente un salto, la cosa più semplice e bug free è svuotare la pipeline e ricominciare daccapo. In tal modo l'istruzione che segue il salto sarà completata quando avrà passato tutta la pipeline. Ma se quando arriva un salto inizi a fare il prefetch anche dell'altro ramo e, visto che hai 6 decoder, magari inizi anche a usare metà decoder per decodificarle, puoi ridurre la latenza di mispredict. Visto che non c'è il SMT si potrebbe fare così, come se fossero due thread separati...

AMD ha anche un brevetto per il checkpointing che serve per ridurre tale latenza, ma non credo che faccia la stessa cosa, altrimenti il brevetto non sarebbe stato approvato

mi chiedo perché, nel caso sia in esecuzione un solo thread, le cpu HT non eseguano* sempre entrambi i rami del branch, scartando i risultati di quello errato... forse potrebbe essere annullato il branch missprediction?

riesci in due parole a spiegare cos'è e come funziona il checkpoint?


EDIT: *ovviamente meglio se dedicando tutte le risorse necessarie al ramo indicato dal branch-predictor come probabile e le rimanenti all'altro ramo.

[Ren]

Originariamente inviato da tuttodigitale

li ho ricavati con un programma di fotoritocco, non credo di aver sbagliato così tanto .

Se non scalano bene neppure le CPU da smartphone, che hanno obiettivi di frequenza assi più modesti, non avrebbe granchè senso la corsa alla miniaturizzazione...detto questo i core skylake sono piccolissimi: siamo passati dai 17,5mmq a 6,85mmq da SB a skylake (core+l2) per un fattore di integrazione pari a 2,5x (in realtà superiore considerando che skylake ha 2 pipeline e 1 decoder e tante altre cose in più)

Purtroppo x te sono sbagliati, ho controllato sia con le mie che sul web...
Controlla le immagini che qualcosa non va.

Apple con i 20nm(core simile) ha ridotto di circa 0.7.

ps. Skylake è 8.2mm2 (sb 18.4)

[Ren]

Originariamente inviato da bjt2

Per misurare la profondità di una pipeline uno non può che far altro che misurare la latenza di branch mispredicition. Infatti se leggete bene non dice che la pipeline è a 9 stadi, ma che la branch misprediction è scesa a 9 cicli. Quando si predice erratamente un salto, la cosa più semplice e bug free è svuotare la pipeline e ricominciare daccapo. In tal modo l'istruzione che segue il salto sarà completata quando avrà passato tutta la pipeline. Ma se quando arriva un salto inizi a fare il prefetch anche dell'altro ramo e, visto che hai 6 decoder, magari inizi anche a usare metà decoder per decodificarle, puoi ridurre la latenza di mispredict. Visto che non c'è il SMT si potrebbe fare così, come se fossero due thread separati...

AMD ha anche un brevetto per il checkpointing che serve per ridurre tale latenza, ma non credo che faccia la stessa cosa, altrimenti il brevetto non sarebbe stato approvato

Realisticamente non "ti sembrano" troppi 7 stadi di vantaggio per un tale sistema ?

[bjt2]

Originariamente inviato da digieffe

mi chiedo perché, nel caso sia in esecuzione un solo thread, le cpu HT non eseguano* sempre entrambi i rami del branch, scartando i risultati di quello errato... forse potrebbe essere annullato il branch missprediction?

riesci in due parole a spiegare cos'è e come funziona il checkpoint?


EDIT: *ovviamente meglio se dedicando tutte le risorse necessarie al ramo indicato dal branch-predictor come probabile e le rimanenti all'altro ramo.

Non è semplice gestirlo e ci si deve mettere a progettarlo e comunque consuma area e si spreca energia: se la predizione è corretta nel 95% dei casi, nel 95% dei casi hai sprecato energia. Infatti non sono sicuro che l'A9 faccia così... Ci sarà probabilmente modo di accorciare la pipeline, magari svuotandola appena si sa che la predizione è sbagliata...

Il check pointing non l'ho approfondito... DOvrei leggere il brevetto, ma spesso sono inutilmente complicati... Se qualche anima pia mi linka un PDF di qualche paper... Oppure quando ho tempo me lo cerco da solo...

[bjt2]

Originariamente inviato da Ren

Realisticamente non "ti sembrano" troppi 7 stadi di vantaggio per un tale sistema ?

Beh, se eseguono entrambi i rami del salto e poi scartano il resto, 7 cicli di risparmio possono essere anche pochi... Non sono sicuro che usino questa tecnica perchè non è efficiente dal punto di vista energetico... E su un cellulare... Conta...

Il checkpointing AMD sono curioso di vedere come funziona.

[bjt2]

Originariamente inviato da gridracedriver

io però avevo capito e credo che il fo4 sia legato anche al silicio, perché le caratteristiche del silicio influenzano tensioni e frequenze e quindi anche il fo4 in fase di progettazione.

vero che il silicio cambia e quindi l'architettura zen potrebbe subire un aumento di fo4 rispetto a BD senza che questo comprometta i consumi a parità di clock, ma un fo4 superiore a 20 lo trovo eccessivo per una architettura a 360° che deve rullare ed essere allo stesso tempo parca nei consumi

Il FO4 dovrebbe essere una misura normalizzata e quindi indipendente dal processo. Solo se un processo impone dei vincoli realizzativi, ad esempio il circuito con il migliore FO4 non si può fare perchè le tracce sono più lunghe per vincoli geometrici del processo, allora può influire... Ma in teoria no.

[tuttodigitale]

BJT2
Certo se funziona in questo modo, sarebbe davvero un mostro. La complessità per molti aspetti fondamentali sarebbe paragonabile a quella di una CPU con SMT...
Tuttavia, caricare un dato inutile nel 90% dei casi, è un costo non trascurabile. Sei sicuro al 100%?

Originariamente inviato da Ren

...

con SB sono andato a memoria.
di skylake ho preso, le dimensioni dei core M, che dovrebbe essere semplicemente un core skylake con HDL, quindi piuttosto rappresentativo della differente complessità tra le architetture Intel ed Apple.
Aldilà dei numeri che contano fino ad un certo punto, volevo semplicemente affermare che le cpu risc di apple dall'A7 sono dei mostriciattoli, molto più grandi di jaguar.

[bjt2]

Originariamente inviato da tuttodigitale

BJT2
Certo se funziona in questo modo, sarebbe davvero un mostro. La complessità per molti aspetti fondamentali sarebbe paragonabile a quella di una CPU con SMT...
Tuttavia, caricare un dato inutile nel 90% dei casi, è un costo non trascurabile. Sei sicuro al 100%?

Sicuro di cosa? Un modo per non avere la branch misprediction è quella, ma è costosa energeticamente e comunque richiede area di chip... Di più nin zo'!

[tuttodigitale]

Originariamente inviato da bjt2

Il FO4 dovrebbe essere una misura normalizzata e quindi indipendente dal processo. Solo se un processo impone dei vincoli realizzativi, ad esempio il circuito con il migliore FO4 non si può fare perchè le tracce sono più lunghe per vincoli geometrici del processo, allora può influire... Ma in teoria no.

credo che volesse dire che la scelta di un determinato FO4 piuttosto che un altro sia legato alle caratteristiche (presunte) del silicio su cui lavorerà.
In pratica ritornando a BD, AMD avrebbe progettato questa architettura con in mente i 45-22 SOI, mentre ZEN per i finfet 14-10nm

Originariamente inviato da bjt2

Sicuro di cosa?

Originariamente inviato da gridracedriver

vero che il silicio cambia e quindi l'architettura zen potrebbe subire un aumento di fo4 rispetto a BD senza che questo comprometta i consumi a parità di clock, ma un fo4 superiore a 20 lo trovo eccessivo per una architettura a 360° che deve rullare ed essere allo stesso tempo parca nei consumi

in teoria un FO4 basso non è adatto alle CPU a bassi consumi. Tuttavia, il FO4 di bulldozer, per quanto basso, non è assolutamente esagerato. Il vecchio kaveri era efficiente nel mobile quasi quanto SB, questo la dice lunga su come scalava (e scala) male in frequenza il 28nm bulk di GF rispetto ai 32nm di Intel (e non ditemi che è colpa dell'architetture che vi lincio )

Il gap dell'efficienza energetica a basse frequenze, è stato drasticamente mitigato dalle nuove tecnologie sul risparmio energetico che funzionano meglio con numerosi stadi.

il FO4 influenza l'ipc, per questo spero che il +40% nel ST sia ottenuto con stadi poco complessi che permettono di lavorare a frequenze o vcore nettamente più favorevoli
E' un compromesso. Spero che scelgano il migliore: FO4 10 - ipc +100%

[tuttodigitale]

Originariamente inviato da gridracedriver

quindi comunque ti auguri pipe piuttosto medio-lunghe come quelle di BD, e da come detto fin ora sembra così.

se come sembra, AMD avrà ancora una volta deficit nell'ipc nel ST, me lo auguro.
L'ipotesi che mi sono fatto è questa.
Se AMD si limita a 95W, significa che almeno 3,5GHz di base, li abbia...è un no-sense fermarsi quando le prestazioni aumentano ancora significativamente, con 30-45W di margine...a meno di non avere una superiorità tecnologica tale da permettersi questo ed altro...(a64 docet), ovviamente dovremmo rivedere a rialzo le stime...
Per quello che ne sappiamo (davvero MOLTO poco), ZEN potrebbe raggiungere i 5 GHz in turbo mode...
Al momento la patch riferisce latenze lato FPU identiche a quelle di Bulldozer. Potrebbe non essere veritiera, ma se fosse confermata vuol dire che ZEN è un demonio di velocità, esattamente come il suo predecessore
Con tutto il bene del SOI, il bulk a 28nm si è dimostrato della stessa pasta del più prestante (sulla carta) 32nm, ad alte frequenze: il a10-7890k, gira a 4,1/4,3GHz.
Siceramente, mi aspetto ulteriori aumenti di clock (turbo) passando ai finfet, qualora mantenesse un FO4 simile a BD.

[tuttodigitale]

Originariamente inviato da gridracedriver

tu si che sai come convincere le persone

cosa dovrei dire di bjt2:
attualmente penso che l'ipc salga del 40% nel ST e del 100% nel MT (sono ritornato alle mie vecchie convinzioni, scaling del SMT migliore per AMD). In pratica, tra un core ZEN e uno skylake, le differenze nel multithread sarebbero irrisorie.

Dirò di più, per i più pessimisti. IBM ha aumentato l'ipc nel ST del 40-50% dal power7/+ al power8..e non mi pare che abbia subito penalità a livello di clock (ha una frequenza massima di 5GHz vs 4,42 del predecessore)...
certo partiva da un livello infimo di ipc, ma non avevano keller . D'altra parte non si può non notare quanto sia ampio il core ZEN..

un octa core nel MT paragonabile ad uno skylake, con una frequenza 3,5 GHz base in 95W, è un mostro efficientissimo, altro che aspettative basse. .

Quelle delle frequenze alte, 3,5GHz+ per l'octa core, è una inevitabile conseguenza delle commercializzazione di un opteron da 32 core. Se partono bassi (3GHz) con un octa core...

[AceGranger]

Originariamente inviato da tuttodigitale

cosa dovrei dire di bjt2:
attualmente penso che l'ipc salga del 40% nel ST e del 100% nel MT (sono ritornato alle mie vecchie convinzioni, scaling del SMT migliore per AMD). In pratica, tra un core ZEN e uno skylake, le differenze nel multithread sarebbero irrisorie.

se è cosi non esistera la versione 32 core perchè riuscirebbero tranquillamente a competere con Intel in tutta la fascia Xeon e a quanto annunciato non sara cosi.

[digieffe]

@tuttodigitale

se intel produce/rra sul suo 14nm un 10core@3ghz 140W ed un [email protected] 140w, non capisco come amd possa produrre un throughput analogo al secondo in [email protected]

non è più verosimile che a 95w si fermi a 3.0ghz? (con throughput inferiore all'intel x8)

[davo30]

Originariamente inviato da digieffe

@tuttodigitale

se intel produce/rra sul suo 14nm un 10core@3ghz 140W ed un [email protected] 140w, non capisco come amd possa produrre un throughput analogo al secondo in [email protected]

non è più verosimile che a 95w si fermi a 3.0ghz? (con throughput inferiore all'intel x8)

Intel con il 6600k sta a 3.5/3.9 in 91w. Con silicio prodotto da lei specificatamente per i suoi proci. È estremamente inverosimile che GF riesca a fornire un silicio che permetta ad AMD di far rientrare un x8 nei 95w a più di 3ghz.

Inviato dal mio XT1092 utilizzando Tapatalk

[tuttodigitale]

Originariamente inviato da digieffe

non è più verosimile che a 95w si fermi a 3.0ghz? (con throughput inferiore all'intel x8)

fermarsi a soli 3 GHz con ben 30-45W di margine, vuol dire o farsi male (non sarebbe la prima volta per AMD ) o avere una superiorità tecnologica schiacciante o ancora che non salga in frequenza, ma la patch ad oggi indicherebbe un FO4 in linea con BD...
Più probabile che l'ipc sia bassino, e sicuramente lo sarà nel ST. Mi aspetto un bel boost con il SMT, proprio perchè ipotizzo che ci sia una scarsa efficienza nell'usare le 10 porte.

Se i 2,7GHz saranno la frequenza base di Carrizo/BristolRIdge in 15W, AMD già con i 28nm, raggiungerebbe senza grossi sforzi le più efficienti soluzioni Xeon a 22nm....
Le prestazioni altissime nel MT, sono proprio il minimo che possiamo attenderci...tanto varrebbe fare un die shrink di quello che sarebbe il più prestante excavator.....

Originariamente inviato da AceGranger

se è cosi non esistera la versione 32 core perchè riuscirebbero tranquillamente a competere con Intel in tutta la fascia Xeon e a quanto annunciato non sara cosi.

i miglioramenti a 3GHz dei 14nm sono sostanziosi (sei stato tu ad affermarlo, tempo fa), credi che Intel con i 14nm non sia in grado di migliorare di una virgola gli XEON, che sono già 10-core@3GHz?

il meglio dei 14nm Intel, deve ancora venire.

Originariamente inviato da digieffe

@tuttodigitale

se intel produce/rra sul suo 14nm un 10core@3ghz 140W ed un [email protected] 140w, non capisco come amd possa produrre un throughput analogo al secondo in [email protected]

10 core@3GHz, mi pare che li faccia già sui 22nm, vedi xeon....possibile che non riusciranno a migliorare?
Per curiosità più tardi vedrò un pò di test sui prodotti da 35-45W di Intel, per vedere quanto rullano rispetto alla generazione precedente . MAgari hanno migliorato anche oltre i 3GHz...

[davo30]

Originariamente inviato da tuttodigitale

fermarsi a soli 3 GHz con ben 30-45W di margine, vuol dire o farsi male (non sarebbe la prima volta per AMD ) o avere una superiorità tecnologica schiacciante o ancora che non salga in frequenza, ma la patch ad oggi indicherebbe un FO4 in linea con BD...
Più probabile che l'ipc sia bassino, e sicuramente lo sarà nel ST. Mi aspetto un bel boost con il SMT, proprio perchè ipotizzo che ci sia una scarsa efficienza nell'usare le 10 porte.

Se i 2,7GHz saranno la frequenza base di Carrizo/BristolRIdge in 15W, AMD già con i 28nm, raggiungerebbe senza grossi sforzi le più efficienti soluzioni Xeon a 22nm....
Le prestazioni altissime nel MT, sono proprio il minimo che possiamo attenderci...tanto varrebbe fare un die shrink di quello che sarebbe il più prestante excavator.....


prendiamo i modelli di punta, please:
l'i7 6700k, sta a 4/4,2GHz in 95W e non è da escludere ulteriori aumenti di clock...
l'i7 6700 sta a 3,4/4GHz in 65W.
quelli mobili (quad core/8thread) 2,9/3,8GHz in 35W:
a titolo di paragonare la vecchia generazione era 2,8/4 GHz in 47W...in teoria ci sarebbe il margine per un 12-14 core a 3GHz e quindi un 8 core a 3GHz@95W. Quest'ultimo per me sarà il rivale di ZEN (PS Intel in qualsiasi momento potrebbe fare un downgrade di una cpu xeon, come fece a suo tempo con lo XEON Gallatin)


i miglioramenti a 3GHz dei 14nm sono sostanziosi (sei stato tu ad affermarlo, tempo fa), credi che Intel con i 14nm non sia in grado di migliorare di una virgola gli XEON, che sono già 10-core@3GHz?

il meglio dei 14nm Intel, deve ancora venire.

Penso che i 95w siano più un limite psicologico e di marketing che AMD si sia imposta per non trovarsi più nella situazione "ma gli FX consumano troppo", visto che per molti tdp=consumo

Inviato dal mio XT1092 utilizzando Tapatalk

[tuttodigitale]

Originariamente inviato da davo30

Penso che i 95w siano più un limite psicologico e di marketing che AMD si sia imposta per non trovarsi più nella situazione "ma gli FX consumano troppo", visto che per molti tdp=consumo

Inviato dal mio XT1092 utilizzando Tapatalk

PS ho sbagliato è quello adattivo. A livello nominale non c'è stato nessun miglioramento.