[Thread Ufficiale] Aspettando ZEN

[Ren]

edit

[Ren]

Originariamente inviato da tuttodigitale

FPu singola che non fa chissà quanto da collo di bottiglia.
più che altro sono 8 vs 16 thread

Appunto, sono 8(+SMT) core contro 4+CMT.

Per il resto si vedrà...

[cdimauro]

Originariamente inviato da bjt2

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...

Prima ho sbagliato a scrivere: anziché FPU x87 dovevo mettere FPU x86.

Comunque istruzioni dell'FPU che, su Skylake, hanno un throughput di 1 o anche 2 ce ne sono molte. In particolare quelle più comuni (incluse quelle "fused"/FMA) hanno un throughput di 2, com'è ovvio che sia visto che ci sono due porte dedicate.

Quindi, almeno su Skylake, è possibile eseguire 2 istruzioni SIMD di tipo FMA a 256 bit per ciclo di clock. Oltre ovviamente ad un paio di istruzioni intere/scalari, che fanno molto comodo visto che, per l'appunto, non è possibile eseguire soltanto istruzioni dell'FPU in un normale codice.

Zen dovrebbe poter eseguire fino a 4 istruzioni SIMD a 128 bit, oppure 2 istruzioni SIMD a 256 bit per ciclo di clock (o 2/128 bit + 1/246 bit, sulla carta). E niente istruzioni intere in questo caso, visto che il decoder riesce a decodificare al massimo 4 istruzioni per ciclo di clock.

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...

Ma ancora non raggiungeresti quanto possibile con un'FPU x86 con AVX, che riesce a eseguire 8 + 8 (8 per istruzione) operazioni FMAC a 32 bit per ciclo di clock.

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...

Già, ma dipende molto anche dalla struttura dell'ISA.

Devo dire che sono rimasto estremamente impressionato da quella dell'Hitachi/STM SH4: è l'unico design RISC (che finora m'è capitato di studiare) che ha un'eccezionale densità di codice, pur avendo opcode a dimensione fissa da 16 bit (ma l'ISA è a 32 bit, con 16 registri).

E per design RISC intendo che gli opcode siano rigorosamente a lunghezza fissa, non fake-RISC come il Thumb di ARM o l'AVR32, che in realtà hanno istruzioni da 16 o 32 bit liberamente mischiabili.

Per il resto i CISC (inclusi questi due ultimi che ho citato) dominano nella classifica della densità di codice.

Originariamente inviato da Ren

Appunto, sono 8(+SMT) core contro 4+CMT.

Anche per questo è un confronto che lascia il tempo che trova: uno Zen da 8 core che ha il doppio di prestazioni di un PD da 4 core non ha assolutamente nulla di eccezionale...

[george_p]

Originariamente inviato da cdimauro

Anche per questo è un confronto che lascia il tempo che trova: uno Zen da 8 core che ha il doppio di prestazioni di un PD da 4 core non ha assolutamente nulla di eccezionale...

Si ma occhio che PD ha 8 cores integer, sono le fpu ad essere 4, ossia 1 fpu per due integer.
Amd quando ha introdotto BD intendeva come core quello integer e non l'fpu.
Quindi il confronto lo farebbe con l'FX 8150 o 8350. Mi auguro con il secondo almeno, se no...

[cdimauro]

AMD poteva intendere quello che voleva, ma non erano core veri e propri.

[george_p]

Originariamente inviato da cdimauro

AMD poteva intendere quello che voleva, ma non erano core veri e propri.

Mah, molti dicono che i core veri e propri siano quelli integer, nati quando ancora non esisteva l'fpu come esiste oggi (da svariati anni realmente).
Comunque, sta di fatto che la stessa amd (con il cambio di dirigenza naturalmente) sia tornata indietro sui suoi passi e integrando l'smt al posto del cmt... c'è arrivata con un bel decennio di ritardo ma alla fine ci è arrivata.
E alla fine questo conta.

[Theodorakis]

Originariamente inviato da cdimauro

AMD poteva intendere quello che voleva, ma non erano core veri e propri.

Mah ... http://www.bitsandchips.it/informati...vero-dual-core

[digieffe]

IMHO, core è quello che può cambiare il flusso di esecuzione di un codice, quindi una LU (Logical Unit) che poi la troviamo sempre accorpata con l'unità arimetica.
tutto il resto che se ne possa dire sono coprocessori vari.

Resterebbe la condivione del decoder (non più cosi a partire da XV?) delle caches ecc. ma la possibilità di eseguire nello stesso ciclo di clock due salti condizionati ed avere distinte e non condivise pipeline per fare ciò (2 alu+2 aglu)x2, esclude che si tratti dello stesso core.
inoltre al contrario di SMT il CMT è "più" deterministico nell'esecuzione.

in altre parole i 2 core risc sono ben distinti ed indipendenti ma condividono qualche accessorio

IMHO causa persa...


Edit:
ho appena letto il motivo della causa: "cannot perform eight instructions simultaneously and independently as claimed"

ridicolo...

[cdimauro]

Mi sono già espresso sull'argomento tempo fa. In particolare qui e nei commenti seguenti.

@digieffe: non conta la possibilità di eseguire due salti nello stesso clock, e nemmeno che ci siano ALU e AGU separate. Altrimenti, da questo punto di vista, anche un thread hardware di Intel lo si potrebbe contare come core.

Riguardo alla causa, bisogna vedere cos'abbia dichiarato AMD. L'unica cosa ridicola è quella di fare un'affermazione che, poi, non corrisponda al vero...

[bjt2]

Originariamente inviato da cdimauro

Prima ho sbagliato a scrivere: anziché FPU x87 dovevo mettere FPU x86.

Comunque istruzioni dell'FPU che, su Skylake, hanno un throughput di 1 o anche 2 ce ne sono molte. In particolare quelle più comuni (incluse quelle "fused"/FMA) hanno un throughput di 2, com'è ovvio che sia visto che ci sono due porte dedicate.

Quindi, almeno su Skylake, è possibile eseguire 2 istruzioni SIMD di tipo FMA a 256 bit per ciclo di clock. Oltre ovviamente ad un paio di istruzioni intere/scalari, che fanno molto comodo visto che, per l'appunto, non è possibile eseguire soltanto istruzioni dell'FPU in un normale codice.

Zen dovrebbe poter eseguire fino a 4 istruzioni SIMD a 128 bit, oppure 2 istruzioni SIMD a 256 bit per ciclo di clock (o 2/128 bit + 1/246 bit, sulla carta). E niente istruzioni intere in questo caso, visto che il decoder riesce a decodificare al massimo 4 istruzioni per ciclo di clock.

Ma ancora non raggiungeresti quanto possibile con un'FPU x86 con AVX, che riesce a eseguire 8 + 8 (8 per istruzione) operazioni FMAC a 32 bit per ciclo di clock.

Già, ma dipende molto anche dalla struttura dell'ISA.

Devo dire che sono rimasto estremamente impressionato da quella dell'Hitachi/STM SH4: è l'unico design RISC (che finora m'è capitato di studiare) che ha un'eccezionale densità di codice, pur avendo opcode a dimensione fissa da 16 bit (ma l'ISA è a 32 bit, con 16 registri).

E per design RISC intendo che gli opcode siano rigorosamente a lunghezza fissa, non fake-RISC come il Thumb di ARM o l'AVR32, che in realtà hanno istruzioni da 16 o 32 bit liberamente mischiabili.

Per il resto i CISC (inclusi questi due ultimi che ho citato) dominano nella classifica della densità di codice.

Anche per questo è un confronto che lascia il tempo che trova: uno Zen da 8 core che ha il doppio di prestazioni di un PD da 4 core non ha assolutamente nulla di eccezionale...

La FPU di Zen non dovrebbe essere potente quanto quella di Skylake. E' su questo che stavo facendo i calcoli. Come dici tu dovrebbe avere 4 pipeline in grado di fare 4 operazioni a 128 bit (ad esempio 4 a 32 bit), accoppiabili per farne 2 da 256, con MOP double. Fino a XV 2 erano per l'FP (compreso FMAC) e due facevano l'SSE/AVX/MMX su interi e le altre operazioni, come conversione, accesso a memoria, e non ho notizie sulle x87.

Ci sono rumors che la FPU di Zen sia più potente di quella di BD, ma dalle stime ad occhio dell'area occupata da Zen, non sembra più grande di un modulo XV, quindi non mi aspetto che la FPU sia molto più potente...
Comunque i rumors danno 2 pipeline in grado di fare FMAC o FADD o FMUL e 2 pipeline in grado di fare solo FADD, ma anche il resto delle istruzioni (memoria conversione ecc)... Ancora nessuna notizia sulle x87...

La mia stima ottenuta moltiplicando per 8 il consumo di una FMAC a 32 bit costruita come hanno fatto quei tizi, corrisponde al caso IDEALE di 2 pipeline simmetriche, in grado di fare 2x4x32 FMAC per ciclo, continuamente alimentate dalla L1, che dovrebbe avere 2 porte in lettura a 128 bit e una in scrittura, giusto giusto per uno stream. Quindi la mia stima era per eccesso, poichè la cache può supportare solo una FMAC, ma visto che l'IPC medio di un codice FP è circa 2 (se non mi sbaglio per spec FP è stato calcolato un IPC di 2.4, compreso le istruzioni intere di controllo e di flusso, che è tantissimo, visto che per spec INT si è poco sopra 1), si può supporre che in media sia occupata un'altra pipeline, con dati intermedi, da registro, simulando un calcolo mediamente complesso.

E' chiaro che la FPU di Zen dovrebbe poter fare almeno altre 2 FADD per ciclo, ma la cache non dovrebbe riuscire a sostenere questo carico allo steady state. Neanche si trattasse di due thread, perchè la cache dati dovrebbe essere una sola.

L'unico codice che riuscirebbe a sforare questo limite è un codice che fa parecchie operazioni per ogni dato in memoria e quindi può usare dei registri di appoggio per i dati intermedi. Ad esempio il powerhog che mi viene in mente è un calcolo che fa una FMAC e poi combina questo risultato altre 3 volte con dati fissi oppure di cicli precedenti, conservati in registri. Potrebbe essere un qualche filtro convolutivo molto ottimizzato. A regime si potrebbero avere anche 4 istruzioni per ciclo, se i risultati nei registri sono forwardati in tempo.

Ma la maggior parte dei calcoli utili, non usano solo fmac, fmul o addizioni, ma anche funzioni più complesse come fdiv, sqrt ecc, che non hanno un throughput di 1 per ciclo per pipeline e che quindi riducono l'IPC... In casi reali non si supera il 2.

[george_p]

Originariamente inviato da cdimauro

Mi sono già espresso sull'argomento tempo fa. In particolare qui e nei commenti seguenti.

@digieffe: non conta la possibilità di eseguire due salti nello stesso clock, e nemmeno che ci siano ALU e AGU separate. Altrimenti, da questo punto di vista, anche un thread hardware di Intel lo si potrebbe contare come core.

Riguardo alla causa, bisogna vedere cos'abbia dichiarato AMD. L'unica cosa ridicola è quella di fare un'affermazione che, poi, non corrisponda al vero...

Non posso entrare troppo nel tecnico per mia ignoranza, anche se mi piace leggere a riguardo.
Difatti ho scritto che per molti il concetto di core è prettamente l'unità integer, io i miei dubbi un pò li ho sempre, anche perché, ripeto, amd stessa è tornata indietro con core a un integer+un fpu scartando praticamente tutto il concetto di cluster, fpu condivisa, cmt ecc., aggiungendo invece anche l'smt, che per "presunzione", come voler distinguersi dalla concorrenza forse, non hanno voluto implementare sin dall'inizio.

[george_p]

Originariamente inviato da Veradun

Carino il tentativo di bitsandchips di storicizzare la cosa a come fosse un "core" all'inizio, ma davvero inutile, visto che era un processore, non un core.

Il processore prima era costituito da un "core" in cuiera presente la sola unità integer senza la fpu, inizialmente esterna, poi introdotta in seguito come integrazione del "core" nel suo insieme.

[george_p]

Originariamente inviato da Veradun

Il fatto è che è tutto molto opinabile, non c'è una definizione univoca di "core". Ad oggi i nostri computer sono tutti dei multiprocessore asimmetrici, con "cores" molto diversi fra di loro. Un "CUDA Core" o uno "Stream Processor" hanno una conformazione del tutto diversa da un core x86, per dirne una. Allora non sono core? Quando ti mettono una GPU sul mercato con 4096 core ti stanno truffando perché queste unità sono raggruppate poi a formare cluster di elaborazione più grandi? Non direi proprio, è una definizione che chi produce i chip si autoproduce e non ci vedo niente di trascendentale.

Ribadisco, se la mia mente malata interpreta "hyper" come più di "il doppio" sono titolato a dire che chiamare l'SMT "HyperThreading" è una truffa? Non direi proprio.

Questa class action fa ridere :>

Mah, indubbiamente, solo non penso che la definizione di core nelle schede video sia la stessa di core nei processori x86.
Core è un termine e come tutti i termini viene applicato per intendere un insieme o parti di insiemi fondamentali, niente più.

Sulla class action nulla da dire, pare inutile anche a me.

[digieffe]

Originariamente inviato da cdimauro

Mi sono già espresso sull'argomento tempo fa. In particolare qui e nei commenti seguenti.

la differenza è che tu consideri il decoder parte del core, io considero core solo il singolo risc.

@digieffe: non conta la possibilità di eseguire due salti nello stesso clock, e nemmeno che ci siano ALU e AGU separate. Altrimenti, da questo punto di vista, anche un thread hardware di Intel lo si potrebbe contare come core.

i thread hardware di intel condividono le pipeline (dell'unico risc) in modo probabilistico. In un unico ciclo di clock se uno stadio della pipeline è occupato da un th hw non può essere disponibile per l'altro th cosa che non accade per il CMT.

Riguardo alla causa, bisogna vedere cos'abbia dichiarato AMD. L'unica cosa ridicola è quella di fare un'affermazione che, poi, non corrisponda al vero...

quale sarebbe l'affermazione che non corrisponderebbe al vero?


Ps: personalmente preferisco SMT.


Edit:
a partire da un successore di BD hanno messo due decoder, da quel momento li consideri due core?

[george_p]

Originariamente inviato da Veradun

Purtroppo ero già nato e già usavo i computer quando è successo

Quel che dicevo è che non c'è bisogno di quella narrazione storica per deridere abbondantemente una class action basata sul nulla come questa :>

Le prime CPU x86 non avevano una FPU, che aveva un socket dedicato sulla scheda madre in cui installarla sotto forma di coprocessore x87. Questa distinzione è continuata fino al 386, di cui esisteva una versione senza FPU (SX) e una con (DX). Ma quel che dico è che si trattava di un processore, non di un core, il concetto di core era ancora ben lontano, quindi non si trattava di un core senza fpu, perché nessuno parlava di core.

Ma, ti dirò, a me quella narrazione storica ha dato informazioni che mi mancavano, non penso ne mi sembra sia fatta per deridere una class action che è fondata sul nulla già di suo, magari per spiegarne un pò l'evoluzione di un processore che oggi come oggi è divenuto un insieme di "processori".

Mi sembra che attorno al concetto core esistano molti punti di vista anche tra ingegneri, vedi amd con BD.

Un core sarà pure principalmente unità integer ma personalmente non inserire la fpu, come è stato fatto in BD è grosso errore, soprattutto perché la fpu non è più elemento esterno come un tempo.

[tuttodigitale]

Originariamente inviato da cdimauro

Mi sono già espresso sull'argomento tempo fa.

ne avevano discusso tempo fa.

Originariamente inviato da george_p

Ma, ti dirò, a me quella narrazione storica

ma quale narrazione storica...
la FPU era opzionale fino a pochi anni fa, per le architetture di ARM...

Come non detto....in piena epoca multi-core la FPU è opzionale, per l'a5..
http://www.arm.com/files/pdf/AT2_-_P...rtex-A5_v1.pdf vedi pagina 19

[Free Gordon]

Può essere che in AMD quando crearono BD, pensarano principalmente alla sua integrazione con Fusion e quindi "risparmiarono" potenza in virgola mobile, sperando di delegarla alla futura GPU integrata..?

Io ho sempre pensato così..

Peccato che le APU/HSA non abbian ancora preso piede adesso...nel 2017 tra un pò..

[george_p]

Originariamente inviato da tuttodigitale

ne avevano discusso tempo fa.



ma quale narrazione storica...
la FPU era opzionale fino a pochi anni fa, per le architetture di ARM...

Come non detto....in piena epoca multi-core la FPU è opzionale, per l'a5..
http://www.arm.com/files/pdf/AT2_-_P...rtex-A5_v1.pdf vedi pagina 19

Boh a me risulta che lo fosse venti anni fa non pochi anni fa. Ma non insisto su argomenti di cui sono poco esperto.

[tuttodigitale]

Originariamente inviato da george_p

Boh a me risulta che lo fosse venti anni fa non pochi anni fa. Ma non insisto su argomenti di cui sono poco esperto.

l'a5 non è vecchissimo, essendo costuito sui 40nm, e poteva avere fino a 4 core.

a pagina 19,è chiaro che la NEON e la FPU erano opzioni...

[george_p]

Originariamente inviato da tuttodigitale

l'a5 non è vecchissimo, essendo costuito sui 40nm, e poteva avere fino a 4 core.

a pagina 19,è chiaro che la NEON e la FPU erano opzioni...

Si però tutto quello che vuoi per quanto siano potenti oggi non considero arm cpu a livello delle storiche intel, amd e ibm.
Poi ripeto, ognuno ha i suoi punti di vista su cosa sia un core, e visto che funziona così per ingegneri che lavorano nel settore, chi sono io per dire cosa è o cosa non è un determinato concetto?