[Thread Ufficiale] Aspettando ZEN

[bjt2]

Originariamente inviato da Free Gordon

Perchè dici "incidentalmente"?

Perchè lo scopo era avere il minor consumo possibile e incidentalmente l'algoritmo utilizzato funzionava anche meglio di quelli usati fin'ora che consumavano anche di più...

[vegitto4]

salve a tutti, cosa ne pensate?

http://forums.anandtech.com/showthread.php?t=2465958

[Ren]

Originariamente inviato da bjt2

L'IPC di jaguar non poteva aumentare tanto perchè ha meno unità di BD e più semplici... Ha incidentalmente un buon IPC per l'ottimo predittore dei salti. Infatti l'hanno inserito in excavator ed ha fatto il salto di qualità... L'evoluzione di jaguar si può a tutti gli effetti considerare Carrizo.... E ora sta arrivando sul desktop... Per essere competitivo, jaguar avrebbe dovuto avere un clock troppo alto.

Il branch locator di bobcat è stato integrato già in piledriver.

Con Steamroller hanno aumentato cache/decoder e raddoppiato uno dei BTB (10K).

[Ren]

Originariamente inviato da Free Gordon

E poi un'altra cosa che non ho mai capito è questa..

Avendo Jaguar in cantiere dal 2012...(presente tra l'altro in tutte e due le console dal 2013...) perchè in AMD non hanno evoluto quell'architettura per portarla attorno ai 3-3.5ghz, dato che dal principio si era capito che fosse certamente più efficiente di BD in ambito desktop?

A quest'ora l'eventuale "Zen" sarebbe già fuori...magari non avrebbe le prestazioni di uno skylake ma perlomeno AMD non si troverebbe in questa situazione di mercato catastrofica.. mi gioco il proverbiale nichelino..

Perchè praticamente dovevano rifare e raddoppiare quasi tutto.

La pipeline sebbene abbia più stadi di quella del K8-10 ha un FO4 da schifo. Per la serie, che ci frega se qualche stadio fa da tappo, tanto lavorerà a bassa frequenza.
Il progetto è nato con budget e tempi ridotti, ma con concetti migliori di bulldozer .

Zen ha molte cose in comune con jaguar, come gli scheduler dedicati, la loop cache ecc...

ps. speriamo tirino fuori un mostro di pipeline stile k8, pochi stadi alto clock.

[bjt2]

Originariamente inviato da Ren

Il branch locator di bobcat è stato integrato già in piledriver.

Con Steamroller hanno aumentato cache/decoder e raddoppiato uno dei BTB (10K).

Non ero sicuro che lo avessero integrato in PD e quindi ho detto XV... Tanto meglio!

[davo30]

Originariamente inviato da vegitto4

salve a tutti, cosa ne pensate?

http://forums.anandtech.com/showthread.php?t=2465958

Io penso che sia ora delle CPU/APU AM4. Tutto il resto è aria fritta

Inviato dal mio XT1092 utilizzando Tapatalk

[tuttodigitale]

Originariamente inviato da Ren

La pipeline sebbene abbia più stadi di quella del K8-10 ha un FO4 da schifo. Per la serie, che ci frega se qualche stadio fa da tappo, tanto lavorerà a bassa frequenza.

Uno stadio fuori posto compromette i consumi dell'intero core. E' più probabile che le prestazioni a livello di clock siano state massacrate dalle HDL.

FAtto salva l'eccezione di excavator, che è figlia di un'architettura progettata per sforare sulla carta allegramente i 5GHz, tutte le CPU ad alto TDP sono costruite utilizzando librerie ad alte prestazioni. Sembra esserci un nesso causale.

Originariamente inviato da Ren

ps. speriamo tirino fuori un mostro di pipeline stile k8, pochi stadi alto clock.

la uop-cache, è vantaggiosa proprio con stadi corti...
poi neppure le CPU da alte prestazioni da smartphone hanno pochi stadi (la CPU ARM by keller ne ha 16), perchè dovrebbe
averli ZEN
PS abbiamo visto che fine ha fatto l'alto clock di k10...

[Free Gordon]

Originariamente inviato da bjt2

Perchè lo scopo era avere il minor consumo possibile e incidentalmente l'algoritmo utilizzato funzionava anche meglio di quelli usati fin'ora che consumavano anche di più...

Capito. Grazie

Originariamente inviato da Ren

Il progetto è nato con budget e tempi ridotti, ma con concetti migliori di bulldozer

E' proprio l'impressione che ho avuto io..

Zen ha molte cose in comune con jaguar, come gli scheduler dedicati, la loop cache ecc...
ps. speriamo tirino fuori un mostro di pipeline stile k8, pochi stadi alto clock.

[Free Gordon]

Originariamente inviato da tuttodigitale

edit2
in definitiva adottare soluzioni jaguar nelle console aveva due vanntaggi:
1) prestazioni per watt superiori rispetto ai core steamroller
2) prestazioni per mmq, molto superiori
Mentre il primo punto, per un TDP di 15W, le soluzioni excavator sono in netto vantaggio (ma le console sarebbero dovute uscire quest'anno), sul secondo, nonostante la cura dimagrante delle HDL (-30%), le dimensioni di un modulo, privo di l2, è di 14,8mmq contro gli appena 6,2mmq (3,1 a core) di Jaguar.. Nello stesso spazio di 2 core PD/SR (19mmq) ce ne vanno 6 di Jaguar.

Quindi confermi abbastanza quello che dicevo, no? 6 core Jaguar vs 2 SR alla stessa frequenza, sarebbe un bagno di sangue in MT per l'architettura CMT.. no?

Mi pare che Jaguar complessivamente sia un progetto migliore di BD e soci, anche se ha tutte le problematiche dei progetti low budget e manca di features che sarebbe cmq costato molto implementare, probabilmente..

[Ren]

Originariamente inviato da tuttodigitale

Uno stadio fuori posto compromette i consumi dell'intero core. E' più probabile che le prestazioni a livello di clock siano state massacrate dalle HDL.

Non è mai così semplice.

Hanno inciso almeno tre fattori (in ordine sparso):

Layout molto automatizzato, per rientrare dei costi. (pochissime parti full custom)
Pipeline con qualche stadio lento
HDL

[Ren]

Originariamente inviato da tuttodigitale

poi neppure le CPU da alte prestazioni da smartphone hanno pochi stadi (la CPU ARM by keller ne ha 16), perchè dovrebbe
averli ZEN
PS abbiamo visto che fine ha fatto l'alto clock di k10...

Una pipeline da 12 stadi di certo non è proponibile ad oggi, ma 16 sembra un numero giusto se ben progettata.

Se non ricordo male Oracle con una pipe 16stadi tocca quasi i 4ghz su bulk TSMC.

CPU ARM di keller ?

ps.Nel K10+ è stata toccata la pipeline FP riducendo la latenza,inoltre non credo abbiano speso molto per il layout di una cpu di transizione.
Hanno di sicuro combinato qualche porcheria, perchè tanto erano convinti di piazzarlo a basso clock nei laptop. Cioè per fare di peggio con un nodo di vantaggio ci vuole davvero buona volontà .
IBM non ha di certo abbassato il clock del p7+ con i 32nm .

[paolo.oliva2]

Originariamente inviato da riuzasan

Na, la complessità globale alla fine è di poco superiore e il vantaggio commerciale verso i produttori esponenzialmente più alto rispetto alla vecchia idea dei due Socket (del resto Intel docet).

Il pronlema però sta nel fatto che anche se con lo stesso socket, si avrebbe un APU Carrizo che quanto TDP al max ha? Realizzato sul 28nm Bulk... e idem un Zen che minimo avrebbe 95W TDP (ma presumo che AMD possa optare per un aumento di MT aumentando i core sfruttando il TDP massimo desktop 125W/140W), sicuramente con frequenze def superiori rispetto al 28nm Bulk, perchè il 14nm e Zen (almeno al momento) non nasce con prerogative mobili ma massima potenza.
Ora... a parte il bios, come unisci le 2 cose nella parte alimentazione mobo? Per farti un esempio... il socket 2011 Intel supporta 140W, il socket inferiore 95W a scendere. Un Zen X8 + SMT a livello di TH è tale ed uguale ad un 5960X... quindi sarebbe come se il socket AM4 accorperebbe il socket 1155 e socket 2011. Cosa risulterebbe se uno acquistasse la mobo più ciofeca 1155 e ci montasse un 5960X?

Piuttosto se le caratteristiche globali sono quelle sviscerate fino ad ora, Zen sarà un passo in avanti netto (con tutti gli scongiuri del caso), ma rimarrà un prodotto paragonabile alla ATTUALE generazione Intel Broadwell, già vecchia a fine 2016/inizi 2017.

Se conti che Kaveri ha implementazioni HSA/Huma che è già vecchia rispetto a Carrizo e prox Zen APU, ed Intel non le ha... il concetto di vecchio è individuale... poi non mi sembra un granchè di vantaggioso parlare di architettura vecchia/nuova se non correlato al costo rispetto ai vantaggi.
Ad esempio... io avevo un mobile Intel a 22nm 1,9/2,4GHz, ed il presente Broadwell aumenta l'IPC (del 5%?) ed il clock di un 25%, ma a confronto aumenta pure il prezzo di un +50%.
Se Zen X8 venisse venduto a 300€ (e di certo per dimensioni die potrebbe pure costare meno), non vedo che senso abbia la parola vecchio quando magari per acquistare la nuova architettura Intel ci devi aggiungere un +30% di money per poi avere un X2... vecchio/nuovo e prezzo/prestazioni sono 2 cose distinte.

Comunque (sempre incrociando le dita) sarebbero un'alternativa valida soprattutto se lato gestione SATA, Network, USb supereranno tutti quei piccoli bug/problemi della generazione attuale AMD

Qui ci sono 1000 diatribe, e si è discusso più volte, senza trovare comunque un punto di incontro.
Gestione disco, la velocità del chip-set AM3 potrai trovare differenze con dei raid SD, ma fino al singolo SD nessuna differenza, idem network, USB, quando la mobo ha l'USB 3.0, che poi sia nativa nel chip-set o che che richieda un Chip a parte, non vedo la differenza, se non quella di dover caricare in fase di installazione 1 driver in più. PCI integrato o meno, differenze prestazionali nulle...
Non è che io abbia in antipatia un cambio chip-set (AM3-->AM4), ma io lo vedo più d'obbligo per il passaggio DDR3-->DDR4/BD-->Zen/X86-->APU che per il North-Bridge in sè.

[el-mejo]

Originariamente inviato da paolo.oliva2

Qui ci sono 1000 diatribe, e si è discusso più volte, senza trovare comunque un punto di incontro.
Gestione disco, la velocità del chip-set AM3 potrai trovare differenze con dei raid SD, ma fino al singolo SD nessuna differenza, idem network, USB, quando la mobo ha l'USB 3.0, che poi sia nativa nel chip-set o che che richieda un Chip a parte, non vedo la differenza, se non quella di dover caricare in fase di installazione 1 driver in più. PCI integrato o meno, differenze prestazionali nulle...
Non è che io abbia in antipatia un cambio chip-set (AM3-->AM4), ma io lo vedo più d'obbligo per il passaggio DDR3-->DDR4/BD-->Zen/X86-->APU che per il North-Bridge in sè.

Bhe riguardo ai ssd questi si fermano a 70000 iops in lettura e 55000 in scrittura, quando dovrebbero arrivare a 100000 in entrambi i valori su interfaccia sata 3. Chiaramente se l'ssd è all'altezza.
Inoltre in molti si sono lamentati dei driver Amd: personalmente ho riscontrato problemi con il driver Amd per Win 10, che per qualche oscura ragione fa freezare Crystaldiskmark sui 4k QD. Fortunatamente Win 10 ha un driver ahci generico all'altezza, senza quell'osceno overhead cpu che aveva su windows 7. E sempra non esistano ancora quelli Raid ufficiali.

Riguardo network cambia niente, mentre potrebbe migliorare il supporto all'usb 3: attualmente si usa un chip integrato interfacciato su pcie 2.0 1x, con quindi 500mb/s di banda: con un singola periferica usb3 si è già saturato il bus...

Ovviamente parlando di sb950.

[tuttodigitale]

Originariamente inviato da Free Gordon

Quindi confermi abbastanza quello che dicevo, no?

Io non confermo niente!
Il discorso è molto più articolato.
Kaveri non è una ciofeca, come usualmente si vuol dipengere. Offre, nel range 2-3,4GHz all'incirca il 90-95%. delle prestazioni per watt nel MT di una soluzione Sandy Bridge.
I problemi erano 2:
1) si scontravano con soluzioni basate sui formidabili finfet.
2) le prestazioni nel ST.

Tra le "ciofeche" kaveri, c'era anche una APU da 2,1GHz SR @2,4 GHz PD, con 3,3GHz di tubo core, da soli 19W di TDP che ben si posiziona contro le CPU da 17W di Intel, che avevano 1,8GHz di base (2,9 Turbo), tra le più efficienti CPU Intel su un processo produttivo planare.

confrontando i valori nominali, abbiamo:
CPU-------ST-----MT----TDP
FX-7500---70----108----113
Efficienza---------------95--
uno scarto di appena 5 punti..

Come vedi sulla carta kaveri era assai efficiente, se consideriamo il processo produttivo planare.

Jaguar intorno ai 2 GHz, necessita di 15W di TDP, e quindi perde assai della sua efficienza energetica (gira a 1,4 GHz con un terzo di TDP...). Segno che le HDL stanno rallentando la corsa ai GHz. La frequenza turbo è di soli 2,4 GHz: questo implica uno svantaggio del 50% rispetto a Kaveri nel ST..


Sulle dimensioni, un modulo BD/SR è sostanzialmente equivalente ad un dual core SB, a livello di dimensioni. Un modulo Excavator è ancora più piccolo...
Avevo pure confrontato le dimensioni della APPLE a7 (purtroppo non ricordo le misure), creatura di keller, ed ero giunto alla conclusione, che era pazzesco come una architettura per desktop fosse più piccola di quella montata in uno smartphone...

La Slide di AMD, se non mente, riporta un consumo di soli 2,5W, per il modulo a 1,7GHz....Questo ci dice che in realtà XV sarebbe un'architettura perfetta per tablet già oggi sui 28nm, mentre Intel ha dovuto aspettare i 14nm finfet per la sua architettura core.

Originariamente inviato da Free Gordon

6 core Jaguar vs 2 SR alla stessa frequenza, sarebbe un bagno di sangue in MT per l'architettura CMT.. no?

Ritornando a Jaguar, fa ancora più impressionante il fatto che invece di 2 core SB, ne rientrerebbero 12. Ho il sospetto che si scontrerebbe positivamente con le architetture di fascia media-bassa ARM. Quello che volevo sottolineare che non è un core della famiglia bulldozer ad essere grande (anzi è esattamente l'opposto) ma Jaguar ad essere piccolissimo, tanto che AMD potrebbe integrarlo nelle GPU, anche se non ne ha proprio bisogno.
Sarebbe un bagno di sangue a patto di far lavorare Jaguar con una frequenza inferiore ai 1,5 GHz e codice altamente parallelizzabile. Non a caso per le soluzioni XEON PHI, Intel usa dei piccolissimi ma efficientissimi core.

E questa è la caratteristica su quale hanno puntato i produttori di console (78mmq tra core e L2 in più, se avessero puntato ad un'octa core PD/SR, 50mmq se optavano per una soluzione a 6 core) , e probabilmente non erano disposti ad accollarsi i soldi per portare i core steamroller/piledriver sui 28nm, di TSMC.

PS Nel 2013, anno di debutto delle console, non era neppure uscito Kaveri...

[bjt2]

Da Twitter...

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

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

[tuttodigitale]

Originariamente inviato da Ren

ps.Nel K10+ è stata toccata la pipeline FP riducendo la latenza,inoltre non credo abbiano speso molto per il layout di una cpu di transizione.
Hanno di sicuro combinato qualche porcheria, perchè tanto erano convinti di piazzarlo a basso clock nei laptop. Cioè per fare di peggio con un nodo di vantaggio ci vuole davvero buona volontà .

Ma ti devo ricorreggere...
uno stadio fuori posto compromette la CPU anche alle basse frequenze. C?è una stretta relazione tra voltaggio di alimentazione e l'aumento del gate delay causato da uno stadio non ottimizzato.
Secondo dati forniti da TSMC. Si può passare da 1V a 0,8V di alimentazione riducendo il ritardo dello stadio più lento del 25%. Passare da 0,8 a 1V significa consumare il 56% in più.
Per questo quello che dici non ha assolutamente senso.
Se una CPU è buona/ottima a basse frequenze non può avere uno stadio fatto a . Il muro ad alte frequenze deve in quel caso essere rappresentato da altro.

Caso opposto, per llano, dove le prestazioni per watt sono compromesse su tutta la linea. I maggiori indiziati sono il silicio e/o una scarsa cura dei progettisti (ma llano ha subito un ritardo di 6 mesi....)

Originariamente inviato da Ren

Se non ricordo male Oracle con una pipe 16stadi tocca quasi i 4ghz su bulk TSMC.

Non tocca quasi, ma li supera: 4,1GHz.
Non possiamo confrontare il numero di stadi di una CPU ARM, e rapportarli ad una X86. La complessità della fase di decodifica è ben diversa e richiede certamente un certo numero di stadi aggiuntivi.

Originariamente inviato da Ren

IBM non ha di certo abbassato il clock del p7+ con i 32nm .

OMG, stai parlando dello stesso power 7+, che doveva superare i 6 GHz?
http://www.bitsandchips.it/recension...o-cpu-da-6-ghz

Di certo non ti stai riferendo al power 7+ (REALE) che secondo la stessa IBM, avrebbe migliorato le prestazioni per watt (attenzione non l'ipc) del 15%, ed essendo valori usciti dall'ufficio marketing è più probabile che sia più vicino al 10..

Non è un caso se Intel abbia rubato quote di mercato ad IBM.

[tuttodigitale]

Originariamente inviato da bjt2

Da Twitter...


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

AZZ mi smentisci così, subito

[bjt2]

Originariamente inviato da tuttodigitale

AZZ mi smentisci così, subito

Cosa avrei smentito?
Si sapeva che BD era un design per l'alto clock, molto difficile da raggiungere vedi Netburst. Questo ci dice che le unità di Zen sono più "chiattone" da poter fare in meno cicli le operazioni... Confermano che Zen ha meno stadi di BD. Però visto che siamo a 14nm contro 28nm non è detto che non si riesca a raggiungere gli stessi clock...

[Ren]

Originariamente inviato da tuttodigitale

OMG, stai parlando dello stesso power 7+, che doveva superare i 6 GHz?
http://www.bitsandchips.it/recension...o-cpu-da-6-ghz

Di certo non ti stai riferendo al power 7+ (REALE) che secondo la stessa IBM, avrebbe migliorato le prestazioni per watt (attenzione non l'ipc) del 15%, ed essendo valori usciti dall'ufficio marketing è più probabile che sia più vicino al 10..

Ma che news hai preso ,sembra il libro dei sogni di intel prescott...


http://image.slidesharecdn.com/20130...?cb=1365183251

Il clock è aumentato del 20%, più gli acceleratori, la cache quasi tripla e SIMD+.

[Ren]

Originariamente inviato da tuttodigitale

Non tocca quasi, ma li supera: 4,1GHz.
Non possiamo confrontare il numero di stadi di una CPU ARM, e rapportarli ad una X86. La complessità della fase di decodifica è ben diversa e richiede certamente un certo numero di stadi aggiuntivi.

Lo so bene, ma era un esempio per dirti che esistono pipeline cancrena come quella del Power5/IBM G5.

Originariamente inviato da bjt2

Cosa avrei smentito?
Si sapeva che BD era un design per l'alto clock, molto difficile da raggiungere vedi Netburst. Questo ci dice che le unità di Zen sono più "chiattone" da poter fare in meno cicli le operazioni... Confermano che Zen ha meno stadi di BD. Però visto che siamo a 14nm contro 28nm non è detto che non si riesca a raggiungere gli stessi clock...

Tuttodigitale è un aficionado delle pipe lunghe...