[Thread Ufficiale] Aspettando ZEN

[capitan_crasy]

Originariamente inviato da Ren

Gianni è morto, la sua testa era esposta in magazzino con la scritta "Era troppo ottimista ed era uno stronzo"!

[paolo.oliva2]

Comunque non c'è da essere pessimisti.
AMD ha riportato ufficialmente che Zen va il doppio di un 8350.
Basta fare 2 conti, l'incremento IPC è dichiarato, quindi per trovare la frequenza basta calcolare.
A spannella Zen guadagna il 70% di IPC su PD, a cui va aggiunto il 30% di SMT, totale 221. Se Zen avesse la stessa frequenza di 4GHz, farebbe più del doppio, cioè un +10. Se perde quel 10% (e se L'IPC è quello dichiarato) è ovvio che avrà una frequenza di poco inferiore ai 4GHz di PD, ma il di poco vuole dire sopra i 3,7GHz.

Quelli che sparano addirittura frequenze sotto i 3GHz lo fanno solo per bandiera (perché AMD non può avere frequenze superiori ad Intel, come se fino ad ora non le ha avute), ma non lo dico per pro AMD, ma mi sembra lampante che guadagnare +70% di IPC ma nel contempo perdere 33% di clock, vorrebbe dire che nel complesso uno Zen X8 sarebbe più potente di un 8350 manco del +50%, al che, a culo l'SMT e restiamo in BD col suo bel CMT e XV X16 che risulterebbe +50% di quel Zen.

[cdimauro]

Originariamente inviato da paolo.oliva2

http://m.hexus.net/tech/news/cpu/931...0-performance/

Qui ci sarebbe una sfide dove AMD riporta che Zen X8 andrebbe tanto quanto 2 8350.
È vecchia, ma la riporto perché è ufficiale (io pensavo rumors) e vorrei esporre una riflessione.

AMD riporta che Zen avrebbe >+40% di IPC su XV e sommando l'incremento di XV su PD, diciamo che saremmo a +70% su PD, e con +30% di SMT arriveremmo a +210%.

Ora, Zen allo stesso clock di PD deve dare quanto 2,1 * 8350 e non 2, diverso nel caso di Zen <4GHz, tipo 3,8GHz.

Però devo capire perché un 5960x andrebbe quanto 2 8350. È vero? Perché non può essere una media... Se un Zen X8 come riferito da AMD andrebbe tanto quanto due 8350, e il 5960X uguagliasse Zen, vorrebbe dire che la differenza di IPC sarebbe uguale allo differenza di clock tra 3,8GHz (Zen) e 3GHz (5960X) il che non torna, assurdo ~-27%.

Se un Zen ? Cioè... In base a cosa? Se la differenza di IPC tra Zen e 5960x sarebbe minima, come si sp

Ora, se AMD riporta Zen X8 = 2 * 8350, qualche cosa non torna, o Zen ha un incremento IPC inferiore se hanno fatto il confronto a parità di frequenza per valutare il core Zen Vs modulo PD, oppure Zen avrebbe una frequenza < ai 4GHz di un 8350.

Quel test su Zen 8 core vs 8350 riguarda esclusivamente Cinebench R15 in multithreading (c'è scritto pure "Compute", ma che vuol dire? In genere è CPU), e dunque i risultati non puoi generalizzarli.

E' ben noto che Cinebench sfrutti bene il multithreading, ma non è così con tutti i programmi, anche multithreaded. Tutt'altro.

Originariamente inviato da tuttodigitale

ma soprattutto , non torna con le tempistiche....ZEN non è pronto per il mercato in volume..

Infatti le voci parlano di un lancio per fine anno, ma in realtà i volumi arriveranno nel 2017.

oggi, in realtà non sappiamo quanto i 30 fps siano dovuti alla CPU e quanto alla oggettiva scarsa potenza delle GPU...
ad esempio killzone gira 900p@60 fps e [email protected]te gpu
diversi titoli di xbox che girano a 1080p a 30fps girano a 60 su ps4, come Tomb-Raider....

Vero, ma in genere si tagliano i dettagli se non ci si arriva. Inclusa quanta roba la CPU debba elaborare.

Ma questo lo sanno di preciso gli sviluppatori, ovviamente.

la frequenza, sempre stando alle indiscrezioni, passerà dai 1,6 a 2,1GHz, un incremento non certo da poco.

Sarebbe di meno per Scorpio, perché l'XBoxOne parte da 1,75Ghz.

E infine al momento vengono utilizzati solo 6 core Jaguar su 8...gli altri 2 sono riservati. Magari, grazie al maggior clock, e a True Audio, sarà possibile usare il settimo core.

E' plausibile, ma magari mettono pure un altro cluster (4 core) Jaguar. Occupano poco spazio, e passando ai 14nm occupano ancora meno.

Poi si sta perdendo di vista il fatto che i software essendo fatti su una specifica CPU, possono estrarre un livello di prestazioni superiori, senza contare il fatto che, almeno PS4, e maggior ragione nelle future console, non c'è bisogno della copia dei dati....
all'improvviso ci stiamo dimenticando che le console sono scatolette chiuse..

Questo varrebbe anche nel caso (IMO irreale) in cui Zen fosse adottato per le prossime console, ma in ogni caso il framerate delle console attuali viene generato nelle condizioni che hai descritto, e purtroppo non è un granché al momento.

dai 1,84TFLOPs ai 5/6TFLops già molto meno e la Ps4 ha una versione a più basso clock di jaguar (1,6 vs 1,75GHz)

Esatto. Ma è pure quella che avrà una GPU molto meno potente in futuro.

Originariamente inviato da paolo.oliva2

@cdimauro
Il 14nm per quanto riguarda l'incremento di potenza a core, poco o nulla (ma questo bisogna vedere il PP), ma per quanto riguarda la potenza a die, 65W con un X22 a 1,7GHz e/o 135W a 2,2GHz sono un miglioramento enorme.
Secondo me bisogna vedere il futuro...

Non ci sono informazioni per poter parlare di numeri, a parte quelle su IPC e processo produttivo. Riguardo alle prestazioni, vedi sopra.

Cioè, se mettiamo l'ancora al software, e si rimane sui 4 core, la differenza da oggi è che ci ritroveremo un PC in un telefonino ma con le prestazioni di oggi. Se invece il software si evolve, e si percorre la strada di parallelizzare quello che si può parallelizzare (ma che oggi lo si fa in minima parte), allora la miniaturizzazione del silicio ha un senso al di fuori dell'ecologismo e del max dei core per server.

Mi spiace, ma il software è proprio una brutta bestia, e non è affatto facile parallelizzarlo. Tutt'altro, visto che ci sono tanti algoritmi che non lo sono per niente. Qualora ciò fosse possibile, potrebbe anche non essere affatto conveniente considerato il rapporto fra sforzo e miglioramento prestazionale.

P.S.
Io non mi intendo di software, ma per me il processore cerca di emulare il cervello umano. Il più grande elaboratore esistente arriva al 10% della potenza di un cervello di un topo, che a sua volta è il 10% di quello umano. Il mio pensiero è che per singole funzioni il processore è già ben più potente del cervello umano (vedi calcoli, tempi di risposta esempio sensori) ma perde enormemente nella sinergia dell'insieme.
Fantasticando, per realizzare un sistema stile cervello umano sicuramente avremmo problemi con il numero di unità di calcolo, con la mole di dati da rendere stile memoria, e quant'altro, ma credo che la vera distanza è che siamo anni luce distanti da un software con un motore AI in grado di gestire il tutto, ben di più di quanto non lo siamo a livello di procio e nanometri silicio.

Lasciamo stare il cervello umano, che funziona in maniera molto diversa.

[paolo.oliva2]

Qui si riporta che il 5960X va il doppio di un 8350 solamente sulla base del risultato di cinebench 15. Però guardando altri bench di confronto, ci sono cose dove il 5960X va anche di più ma altre dove va anche di meno, ed è ovvio perché PD è un BD ma con una architettura di 6 anni fa e non aggiornata con i set di istruzioni ed alcune cose non può risolverle nativamente. È impensabile che Zen non sia più che aggiornato per risolvere nativamente quello che oggi il software richiede, ed inoltre avendo una potenza ST ben superiore a PD (e le medie di performances hanno per un 50% l'ST), un Zen che va il doppio di un 8350 in MT di certo in ST non può andare come un 8350 ma ben di più.

A me non interessa se un Zen X8+8 andrà quanto un 6900k o un 6950k o un 6850k, ma siccome la produzione di QUESTO Zen ha come base X8 e si parla di riciclo fallati al max X6, è mia (personalissima) opinione che AMD non commercializzerà Zen X8 prezzandolo sulla fascia 2011 Intel, ma ricercherà volumi che può ottenere unicamente prezzandolo come alternativa alla fascia alta 1155 e bassa 2011, e questo è indipendente dalla potenza ottenuta ma più un rapporto sul costo (un po' sulla riga rx480).

Sulla base di questo mio pensiero, AMD potrebbe pure ricercare più potenza con un modello top Zen X12 (anche perché se Intel propone al max un X22 a 65W Vs un Zen X32 a 45W, e Intel nel desktop riesce a commercializzare un X10, AMD sullo stesso metro potrebbe commercializzare un Zen X16) ovviamente più costoso, ma il centro di ogni aspettativa è di quanto incrementerà la potenza Zen, a che prezzo e quanto si occherà. Un Zen che va il doppio di un 8350 valutato con lo stesso metro di un 5960x, per me non è parziale, tutt'altro.

[stefanonweb]

Scusate, ma se parlate di Zen forse ad Ottobre a 14 nm... Bristol Ridge a 28 nm quando uscirebbe e con che scopo? Siamo sicuri che i 28 nm ci saranno, oppure si potrebbe passare subito ai 14 nm? Ed allora BR che senso avrebbe... poi con delle tempistiche moto ravvicinate a Zen... Grazie.

[george_p]

Originariamente inviato da stefanonweb

Scusate, ma se parlate di Zen forse ad Ottobre a 14 nm... Bristol Ridge a 28 nm quando uscirebbe e con che scopo? Siamo sicuri che i 28 nm ci saranno, oppure si potrebbe passare subito ai 14 nm? Ed allora BR che senso avrebbe... poi con delle tempistiche moto ravvicinate a Zen... Grazie.

MA BR è un Apu mentre Zen inizialmente no, solo core X86 pura.
BR dovrebbe venire sostituito da Zen Apu nel 2017.
Cmq personalmente BR mi sembra quasi quasi più un paper launch cisto che doveva già essere uscito da tempo nel 2016.
E penso che lo vedremo in poche quantità, tra l'altro non mi spiego nemmeno perché amd abbia commercializzato godavari (7870K) che si pone sullo stesso piano o quasi di BR.
Di quest'ultimo ho visto solo slide di comparazioni e niente più.
Probabilmente se esce davvero sarà a settembre e l'apu zen sarà almeno un anno dopo.
Mi speculazione personale ovvio

[bjt2]

Dresdenboy ha postato un link a questo FPU generator:

https://sites.google.com/a/stanford.edu/fpgen/tapeout

Guardate anche le altre pagine.
In pratica il meglio che hanno fatto sul 28nm FDSOI in termini di velocità è una FPU a 3.4GHz@1V che consuma circa (32mW*GFlops*3.4*2GFlops) 218mW per una FMAC FP32, quindi una FPU in grado di fare 8x32=256 bit FMAC a 3.4GHz, consumerebbe 1744mW.

Hanno fatto anche altre versioni a clock più basso (900-1350 MHz), più efficienti per consumo o per area ed hanno fatto il tapeout di un chip di test nel 2013

Transistors LVT (si vede dal BIAS di 1.2V).

Se AMD ha usato queste FPU... Non oso pensare...

[tuttodigitale]

Originariamente inviato da george_p

Cmq personalmente BR mi sembra quasi quasi più un paper launch cisto che doveva già essere uscito da tempo nel 2016.

non penso proprio che sia un paper launch alla fine il die di BR è diverso da quello visto in Carrizo, e probabilmente Carrizo come doveva essere nel 2015



sono quasi sicuro, che l'apu che uscirà nel 2017 sia basata su ZEN+.

[george_p]

Originariamente inviato da tuttodigitale

non penso proprio che sia un paper launch alla fine il die di BR è diverso da quello visto in Carrizo, e probabilmente Carrizo come doveva essere nel 2015


sono quasi sicuro, che l'apu che uscirà nel 2017 sia basata su ZEN+.

Ma questo deve essere il minimo se Zen+ è in programma per il 2017 (fine?), se no cosa metti una parte X86 "vecchia"?

D'altra parte anche Zen prima versione non dovrebbe essere male per un apu quadcore con Smt, di sicuro il balzo in avanti dopo anni e anni di apu lo fa a prescindere.

[Free Gordon]

Originariamente inviato da cdimauro

Molto interessante, grazie.
Purtroppo per un confronto fra VLIW e SIMD/GCN1.0 servirebbero i manuali di entrambi, perché ovviamente ci saranno delle notevoli differenze (come ci sono già fra GCN 1.1 e 1.2, come puoi vedere a pag. 15).
Al momento la cosa che mi ha sorpreso è vedere un design CISC per l'architettura, che è a lunghezza variabile.

Cosa ti sorprende? non ho capito cosa vuoi dire.

[paolo.oliva2]

Secondo me BR va inquadrato solamente nel fatto che era stato progettato ben prima dell'ES di Zen (e quindi AMD non poteva sapere i tempi di Zen + 14nm) e avendo fatto (e speso) gran parte del lavoro... Poi il fatto di stare zitti su Zen APU io non lo vedo come una notevole distanza di tempo, ma più un fatto commerciale; se AMD dicesse Zen APU a febbraio 2017, chi si comprerebbe BR?
Per me Zen+ non sarà altro che Zen + igp + HBM/HBM2 e l'incremento prestazionale altro non sarebbe che la maggior velocità delle HBM che per mezzo di Huma farebbero sia da L3 che da Ram per l'IGP e magari qualche ottimizzazione architetturale magari condita da funzioni HSA implementate nell'hardware del procio che non necessitano di compilazioni apposite.
Una volta be succedeva quando il coprocessore matematico era un chip a parte? Il software era sempre quello ma era l'hardware che a seconda da della presenza del coprocessore smistava le operazioni. Se AMD sbandiera Carrizo compatibile nativamente a HSA 1.0, dovrà offrire qualche cosa in più rispetto a non averla.

Ritornando a Zen, Zen APU... Polaris oramai è ultimata, Zen X86 idem, AMD dalla sua ha una competenza in APU al top, il 14nm oramai lo conosce, non ci vedo tempi extra-large per un Zen APU, perché non vedo un progetto da zero ma più un progetto addirittura in contemporanea a Zen X86, però rallentato nell'evoluzione per attendere il completamento di Polaris, quindi per me un +6 mesi da Zen X86 sarebbero già più che sufficienti.

[Ren]

Originariamente inviato da cdimauro

Quel test su Zen 8 core vs 8350 riguarda esclusivamente Cinebench R15 in multithreading (c'è scritto pure "Compute", ma che vuol dire? In genere è CPU), e dunque i risultati non puoi generalizzarli.

E' ben noto che Cinebench sfrutti bene il multithreading, ma non è così con tutti i programmi, anche multithreaded. Tutt'altro.

Aggiungo che BD ha FPU condivise, non ci vedo nulla di straordinario in quel risultato al cinebench...

[Free Gordon]

Originariamente inviato da Ren

Aggiungo che BD ha FPU condivise, non ci vedo nulla di straordinario in quel risultato al cinebench...

Finalmente con Zen siamo ritornati a Deneb/Thuban??

Quelli alla fine erano buoni proci. Certo, non superavano Intel ma gli stavano perlomeno dietro..

[Ren]

Originariamente inviato da Free Gordon

Finalmente con Zen siamo ritornati a Deneb/Thuban??

Quelli alla fine erano buoni proci. Certo, non superavano Intel ma gli stavano perlomeno dietro..

Erano bei tempi...

[paolo.oliva2]

Originariamente inviato da Free Gordon

Finalmente con Zen siamo ritornati a Deneb/Thuban??

Quelli alla fine erano buoni proci. Certo, non superavano Intel ma gli stavano perlomeno dietro..

Non dimentichiamoci del silicio... Il modulo di BD doveva controbattere il core + HT di Intel. È ovvio che se il 32nm permetteva a BD 4 moduli in 1,2 milioni di transistor 125W ed Intel sul 22nm ci metteva 2,5 milioni di transistor in 140W con 8 core + HT, è ovvio che poi Intel possa ottenere una potenza doppia a die. Se oggi il 14nm permetterebbe 8 moduli/16 core XV, tu vedi una differenza in MT con un 6900k? Io non ne vedo... Quindi se stiamo parlando sempre di BD, mi sembra ovvio che se cambiando silicio in MT si pareggerebbero le prestazioni con Intel, a cosa attribuire se non al silicio? Poi l'ST avrà i suoi problemi, ovviamente, ma se ipotizzassimo un Zen sul 32nm che avresti? Un X8 o un X4? Certamente più ST di BD ma altrettanto certamente non un maggiore MT/potenza die.

[tuttodigitale]

Originariamente inviato da Ren

Aggiungo che BD ha FPU condivise, non ci vedo nulla di straordinario in quel risultato al cinebench...

FPu singola che non fa chissà quanto da collo di bottiglia.
più che altro sono 8 vs 16 thread
praticamente fare il doppio di un fx8350/2700k significherebbe spannometricamente essere nelle prossimità di un octa core Haswell da 3GHz. Per un 95W sarebbe un buon/ottimo risultato

Originariamente inviato da Free Gordon

Finalmente con Zen siamo ritornati a Deneb/Thuban??

Quelli alla fine erano buoni proci. Certo, non superavano Intel ma gli stavano perlomeno dietro..

in teoria a parità di thread, la FPu configurata come in ZEN, è più debole, per la mancata presenza di 2 AGU (le prestazioni nei calcoli floating point, dipendono anche dalla parte intera)...
mi aspetto che le prestazioni scalino peggio anche nei test fp-intensive. Scaling peggiore -> prestazioni ST superiori.


Alla fine denigrare il CMT è come denigrare il SMT....visto che le tecniche messe in atto sono estremamente simili....il CMT alla fine che cosa è, se non un implementazione parziale del SMT?

Quindi è assolutamente falso che si ritorna a thuban...la FPU è condivisa da 2 thread anche in ZEN....in aggiunta a questo a differenza di thuban/bulldozer non ci saranno alu/agu dedicate....ZEN si allontana ancora di più da thuban, e in un certo senso prosegue il cammino intrapreso con bulldozer.

E questo appunto si rifletterà sullo scaling, sensibilmente diverso (peggiore) da una soluzione con core ST come k10

Originariamente inviato da paolo.oliva2

Ritornando a Zen, Zen APU... Polaris oramai è ultimata, Zen X86 idem, AMD dalla sua ha una competenza in APU al top, il 14nm oramai lo conosce, non ci vedo tempi extra-large per un Zen APU, perché non vedo un progetto da zero ma più un progetto addirittura in contemporanea a Zen X86, però rallentato nell'evoluzione per attendere il completamento di Polaris, quindi per me un +6 mesi da Zen X86 sarebbero già più che sufficienti.

credo che in tutto questo lasso di tempo AMD abbia sviluppato anche ZEN+....è probabile che iniziano a mettere sul silicio direttamente l'architettura ZEN+ per le APU...
Vedo illogico, fare un nuovo prodotto, con un'architettura "vecchia"...come è stato per piledriver, si darà precedenza alle apu, imho. Introdotte a Maggio 2012, 5 mesi prima del fx8350.

http://www.anandtech.com/show/5831/a...00m-a-new-hope

[paolo.oliva2]

Originariamente inviato da tuttodigitale

credo che in tutto questo lasso di tempo AMD abbia sviluppato anche ZEN+....è probabile che iniziano a mettere sul silicio direttamente l'architettura ZEN+ per le APU...
Vedo illogico, fare un nuovo prodotto, con un'architettura "vecchia"...come è stato per piledriver, si darà precedenza alle apu, imho. Introdotte a Maggio 2012, 5 mesi prima del fx8350.

http://www.anandtech.com/show/5831/a...00m-a-new-hope

Io penso che Zen+ sia la naturale evoluzione da X86 a APU, con la differenza che secondo me avrà sorprese rispetto agli APU precedenti.

Rispetto al link che hai postato, c'è una tabella che non capisco.
Verso la fine riporta le differenze tra Phenom II, BD e I7.
Sigle core peak decode rate. Io non conosco che mazza voglia dire, però messo così sembra quasi come capacità di elaborazione rispetto ai core.
Non comprendo... Perché BD regge tranquillamente 4TH a modulo, ovvero 2TH a core, mentre il Phenom II cala prestazionalmente con > di 1 TH a core, come l'i7 regge tranquillamente 2TH a core ma crolla con 3TH.
Li praticamente dice che un Thuban arriva a 18 istruzioni, un X6 I7 a 24 ed un FX X8 a 16? Ma se un 8350 regge un carico almeno 3 volte superiore ad un Thuban senza mostrare rallentamenti...

[cdimauro]

Originariamente inviato da bjt2

Dresdenboy ha postato un link a questo FPU generator:

https://sites.google.com/a/stanford.edu/fpgen/tapeout

Guardate anche le altre pagine.
In pratica il meglio che hanno fatto sul 28nm FDSOI in termini di velocità è una FPU a 3.4GHz@1V che consuma circa (32mW*GFlops*3.4*2GFlops) 218mW per una FMAC FP32, quindi una FPU in grado di fare 8x32=256 bit FMAC a 3.4GHz, consumerebbe 1744mW.

Hanno fatto anche altre versioni a clock più basso (900-1350 MHz), più efficienti per consumo o per area ed hanno fatto il tapeout di un chip di test nel 2013

Transistors LVT (si vede dal BIAS di 1.2V).

Se AMD ha usato queste FPU... Non oso pensare...

Come già detto prima per l'unità NEON, non prenderei in considerazione questi test su FPU così semplici (questa, poi, è enormemente più semplice persino di NEON). Un'FPU x87 è decisamente più complicata (anche perché fa molto di più), e dunque il suo power budget sarà ben diverso.

Originariamente inviato da Free Gordon

Cosa ti sorprende? non ho capito cosa vuoi dire.

In genere questi core sono molto semplici, per cui si usa un design RISC, e dunque con istruzioni aventi lunghezza fissa. Hanno lo svantaggio, però, di avere una più bassa densità di codice (e questo influisce su tutta la gerarchia della memoria).

Un design CISC è a lunghezza variabile, per cui richiede un decoder più complicato, ma per contro ha il vantaggio di avere una densità di codice maggiore, e dunque fa meno pressione sulla memoria.

Un approccio di questo genere per gli shader processor mi fa pensare che uno dei problemi del design VLIW fosse dovuto alla scarsa densità di codice (che nei VLIW è ancora più accentuata rispetto ai normali RISC), che con GCN hanno eliminato.

P.S. Da quando sono nati i RISC, i CISC sono stati considerati lo zimbello delle architetture degli elaboratori, ma negli ultimi 5 lustri si sono presi delle belle rivincite sia sul piano prestazionale sia su quello del design, perché tanti blasonati RISC hanno dovuto realizzare delle versioni dell'ISA "compatte" sfruttando opcode a lunghezza variabile (in genere 16 e 32 bit), e dunque introducendo sostanzialmente un design CISC.

Originariamente inviato da tuttodigitale

FPu singola che non fa chissà quanto da collo di bottiglia.
più che altro sono 8 vs 16 thread
praticamente fare il doppio di un fx8350/2700k significherebbe spannometricamente essere nelle prossimità di un octa core Haswell da 3GHz. Per un 95W sarebbe un buon/ottimo risultato

Sostanzialmente d'accordo, ma vedremo anche a che frequenze arriverà Zen, e se realmente rispetterà questi 95W.

in teoria a parità di thread, la FPu configurata come in ZEN, è più debole, per la mancata presenza di 2 AGU (le prestazioni nei calcoli floating point, dipendono anche dalla parte intera)...

Esattamente, ma dipende anche dal tipo di codice eseguito: ci può essere più o meno carico sull'unità scalare/intera (incluse le AGU) a seconda del modo in cui si accede alla memoria.

Ecco perché ritengo sia inutile continuare a prendere come riferimento l'FPU NEON degli ARM, o un'FPU molto più semplice come quella di un design dedicato: non danno e non posso dare alcuna misura di come si comporterà a livello di consumi l'FPU integrata in Zen.

mi aspetto che le prestazioni scalino peggio anche nei test fp-intensive. Scaling peggiore -> prestazioni ST superiori.

Come mai prevedi uno scaling peggiore?

Alla fine denigrare il CMT è come denigrare il SMT....visto che le tecniche messe in atto sono estremamente simili....il CMT alla fine che cosa è, se non un implementazione parziale del SMT?

Quindi è assolutamente falso che si ritorna a thuban...la FPU è condivisa da 2 thread anche in ZEN....in aggiunta a questo a differenza di thuban/bulldozer non ci saranno alu/agu dedicate....ZEN si allontana ancora di più da thuban, e in un certo senso prosegue il cammino intrapreso con bulldozer.

Diciamo che assomiglia molto a un design Intel.

[bjt2]

Originariamente inviato da cdimauro

Come già detto prima per l'unità NEON, non prenderei in considerazione questi test su FPU così semplici (questa, poi, è enormemente più semplice persino di NEON). Un'FPU x87 è decisamente più complicata (anche perché fa molto di più), e dunque il suo power budget sarà ben diverso.

E' più semplice perchè fa una singola FMAC anzichè 4/8, ma è più calda di una x87 perchè questa non ha la FMAC. Inoltre molte istruzioni x87 sono microcodificate e spalmano il loro payload di consumo su molti cicli... Ad esempio sincos è oltre 200 cicli e blocca l'unità per tutto il tempo, quindi funziona un solo stadio di pipeline in ogni ciclo... Invece con istruzioni il cui throughput è 1 per ciclo, tutti gli stadi di pipeline stanno lavorando su qualcosa e quindi consumano di più...
Quella FMAC ha un throughput di 1 per ciclo di una addizione e una moltiplicazione, che termicamente è il massimo possibile stress...
Su x87 (ma anche SSE/AVX) sono poche le istruzioni che hanno un throughput di 1 per ciclo, quindi spesso c'è solo una piccola porzione di FPU che sta facendo qualcosa...
Moltiplicando per 8 hai il consumo massimo di una FPU a regime che sforna una SIMD a 256 bit di FMAC 32 bit per ciclo, cosa non raggiungibile per limiti di banda RAM a meno di codici che non fanno nulla di utile, facendo calcoli su dati in registro giusto per scaldare il chip...

Originariamente inviato da cdimauro

In genere questi core sono molto semplici, per cui si usa un design RISC, e dunque con istruzioni aventi lunghezza fissa. Hanno lo svantaggio, però, di avere una più bassa densità di codice (e questo influisce su tutta la gerarchia della memoria).

Un design CISC è a lunghezza variabile, per cui richiede un decoder più complicato, ma per contro ha il vantaggio di avere una densità di codice maggiore, e dunque fa meno pressione sulla memoria.

Un approccio di questo genere per gli shader processor mi fa pensare che uno dei problemi del design VLIW fosse dovuto alla scarsa densità di codice (che nei VLIW è ancora più accentuata rispetto ai normali RISC), che con GCN hanno eliminato.

P.S. Da quando sono nati i RISC, i CISC sono stati considerati lo zimbello delle architetture degli elaboratori, ma negli ultimi 5 lustri si sono presi delle belle rivincite sia sul piano prestazionale sia su quello del design, perché tanti blasonati RISC hanno dovuto realizzare delle versioni dell'ISA "compatte" sfruttando opcode a lunghezza variabile (in genere 16 e 32 bit), e dunque introducendo sostanzialmente un design CISC.

Ricordo ancora la domanda di esame di Calcolatori I: una istruzione frequente è bene codificarla con pochi o molti bit?

Il RISC vs CISC è un po' come la compressione della memoria sulle GPU (se lossless): si risparmia banda e spazio RAM a scapito di un po' di area chip e complessità... E' un gioco che spesso vale la candela...

[stefanonweb]

Per caso si sa a che voltaggio saranno le memorie DDR4 per BR e ZEN? Grazie. 1,2 volt? E che frequenze potrebbero andare bene?