[Thread Ufficiale] CPU serie FX: AMD Bulldozer/Piledriver - Aspettando Steamroller

[FazzoMetal]

"Nuovi" rumors riportati recentemente sul thread del forum di overclock.net dedicato a ZEN:

"If this capability to fuse and process larger instructions is carried over to Zen it would enable the two 256-bit FMAC units – 4 128-bit pipes – to fuse and process 512bit AVX instructions. Which would make the core compatible with Intel’s AVX512 instruction set extension. Which is currently only supported by Intel’s Knight’s Landing Xeon Phi microarchitecture.

The wider floating point unit also means that Zen will be able to process less complex instructions at double the rate of Steamroller A massive boost in floating point performance, an area where AMD had historically excelled in with Phenom II and prior CPUs."

Se AMD implementerà anche in ZEN la possibilità di configurare dinamicamente le pipe della FPU allora le nuove CPU sarebbero davvero competitive offrendo "paradossalmente" più di quanto Intel proponga oggi sulle sue attuali CPU.

[digieffe]

Originariamente inviato da paolo.oliva2

Ma a prescindere, io comprendo perfettamente che per eseguire un dato bisogna aspettare il risultato del precedente, quello che non capisco è dover continuare il TH su quel core e non in un altro core.
È comprensibile che in un SMT basato sul singolo core (Intel) la logica è questa, ma in un modulo AMD si potrebbero già caricare le pipeline nel core 2 aspettando un risultato elaborato sul core 1.

Ripeto, io sono ignorante in materia, ma l'SMT in Intel prepara le pipeline basato sul 2° TH il quale "aspetta" che siano disponibili le risorse quando il 1° TH ad esempio aspetta un dato e quindi stalla.

Se inquadrassimo il modulo AMD come un super core con una L2 e 4 INT e 4 FP, perché non fare in modo che l'SMT agisca su quello che è libero a modulo? Perché infognarsi invece su quello che è libero a core?

Se ciò è impossibile, OK, avrò detto una cavolata, però se fosse possibile inquadrare il modulo Zen come un X4 in 1 e l'SMT che vede le risorse libere dell'intero modulo, cacchio, alla faccia del vantaggio.

Un nesso logico a quello che dico per me c'è, semplicemente perché se AMD volesse "copiare" Intel con l'SMT, Zen non sarebbe un modulo. A che pro AMD conserva il modulo? Per il CMT? Ma il CMT ha me punto fermo la condivisione delle risorse, ed allora perché sarebbe assurdo un SMT basato sul modulo con core condivisi?

credo di aver capito cosa intendi e lo faccio con un esempio super semplificato, tralasciando architetture sofisticate come BD, HT.

considerando il primo athon dualcore, unire le risorse dei due core in un unico supercore, in grado di avere un ipc elevatissimo quando gestisce solo un thread ed un ipc cmq alto quando ne gestisce due.

poi si può anche aggiungere l'smt, e ne gestisce 4.

ne risulterebbe un'architettura a moduli + CMT.

ho intuito?

[tuttodigitale]

Originariamente inviato da digieffe

credo di aver capito cosa intendi

Io ho capito altro.
secondo la mia interpretazione:
1) Per Paolo HT dovrebbe essere gestito a livello di modulo, nel senso se devo gestire 12 thread, carico 6 su un modulo, e 6 nell'altro. Sarebbe penalizzante secondo Paolo usare un modulo al 100% (8 thread) e quell'altro solo con 4 threads.

2) Questo sarebbe dovuto alla condivisione della cache (l3 e non l2 come riportato da Paolo). Gli faccio notare che nel caso in cui il core1 aspetta un dato elaborato dal core 7, questo deve passare attraverso
la memoria RAM.

La mia personale opinione, è che il SO deve continuare a gestire la cpu come ha sempre fatto. Caricare il più possibile in maniera uniforme i core. Una soluzione alla Paolo (preferenza per il carico su un modulo) penalizza questo tipo di approccio (e in effetti è alternativo, ma vedi quante idee ha Paolo? Semplicemente mostruoso), ma ha un suo perchè.

Chi avrà ragione?

[Piedone1113]

Originariamente inviato da tuttodigitale

dovrò dare una piegazione più estesa


ho detto che quasi nessun stadio esegue operazioni aritmetico-logiche. Ed è senz'altro vero che l'esecuzione è uno degli ultimi compiti (mai scritto che forse l'ultimo).
Stai dicendo l'opposto di quello che ho scritto, per dimmi che ho torto?


Qui non si tratta di macchina perfetta o non.
Una pipeline da x-stadi quando è piena esegue in un ciclo x operazioni di complessità pari a 1/x rispetto ad uno a singolo ciclo. Le istruzioni logiche aritmetiche (di questo parlavi, quando escludevi, se non sbaglio, le istruzioni di fetch, decode ) hanno un tasso pari al numero di pipeline esecutive * clock.
Non puoi fare l'esempio (e pretendere di avere ragione) di una pipeline e dire che lo stadio Y esegue l'operazione di somma, e lo stadio successivo Y+1, esegue un operazione simile, o ancora che lo stadio Y+2 esegue un ulteriore istruzione aritmetica logica. E' lo stadio Y quello specializzato per le operazioni aritmetiche-logiche. Y+1 e Y+2 e così via fanno altre cose.

EDIT


Nella lunga pipeline del P4, è lo stadio 17, quello che esegue le operazioni aritmetico-logiche.

Va bene, nonostante avessi scritto esempio terra-terra per un esempio sbagliato, ma semplice nel capirlo per parlare dell'impossibilità di trasferire un th in corso tra una pipeline ed un'altra (quello che chiedeva Paolo).
Paolo parlava del salto del th in esecuzione (per esempio dallo stadio 10 della pipeline 1 del core 0 allo stadio 11 della pipeline 3 del core 2) ed il mio esempio era solo per spiegare (e ripeto terra terra) che un'istruzione in pipeline non può essere fatta uscire da uno stadio per entrare in uno stadio consecutivo di una pipeline diversa.
avrei scritto meglio:
Nello stadio 1 (fech) l'istruzione viene caricata dalla memerio
nel 2 viene codificata
nel 3 vengono caricati gli operandi
nel 4 viene eseguito il calcolo
nel 5 viene scritto il risultato in ram( cache).
Quindi passare dallo stadio 2 di una pipeline allo stadio 3 della pipeline di un altro core è non fattibile, ma bisogna ripetere il processo dall'inizio.
Questo volevo spiegare, perché 2+2/2 non è un'istruzione, ma due istruzioni separate (che alcune volte possono essere accorpate ed eseguite in singola passata, altre volte hanno bisogno di più passate dipendente dalla complessita totale e dalla logica della cpu che la esegue)

[paolo.oliva2]

Mi sono spiegato male, colpa mia.

Partiamo dalla L2 che comunque deve contenere le istruzioni dei TH.

In Intel abbiamo 1 L2 e a cascata tutte le vie per gestire i 2 TH su 1 core.

In AMD, abbiamo sempre 1 L2, ma siccome condivisa nel modulo per 4 core, l'SMT potrebbe funzionare non sulla disponibilità di 1 core, ma su quella del modulo.

Ora, se 1 core nella media lavorasse al 75%, il TH "parallelo" avrebbe a disposizione il 25%.
Siccome la L2 in Zen è condivisa e praticamente serve tutti e 4 i core, l'SMT credo che anziché portare al 100% 1 core potrebbe portare al 100% il modulo

Ora, supponiamo che un 4 core Intel + SMT debba risolvere 5TH. 4 TH avrebbero la priorità e elaborati al 75%, ma il 5° avrebbe a disposizione il 25% di 1 core, e risulterebbe richiedere 4 volte in più di tempo rispetto agli altri TH e di fatto 3 core che non sfrutterebbero l'SMT.

Se fosse possibile che l'SMT di AMD sfruttasse il modulo e non il singolo cote, il 5° TH potrebbe lavorate anche al 100% (senza dare la priorità ad altri core) semplicemente perché ogni stallo di qualsiasi core verrebbe sfruttato per portare avanti quel TH senza che poi un TH venga impostato a priorità differenti.

Io faccio fatica a spiegare, ma se in Intel il 2° TH lavora al 25% e sta al 75% ad aspettare il primo TH, quei cicli 3 x 25% non potrebbero essere spostati sugli altri core?

P.S.
Lungi da me interpretazioni di bandiera, io prospetto solamente cosa potrebbe avere l'SMT di AMD di diverso fa Intel. Fermo restando, anche letto gli ultimi post, che le potenze sulla carta possono essere superiori quelle di Zen, ma dalla carta al silicio, dubito sull'efficienza AMD.

[tuttodigitale]

Originariamente inviato da paolo.oliva2

Mi sono spiegato male, colpa mia.

Partiamo dalla L2 che comunque deve contenere le istruzioni dei TH.

In Intel abbiamo 1 L2 e a cascata tutte le vie per gestire i 2 TH su 1 core.

In AMD, abbiamo sempre 1 L2, ma siccome condivisa nel modulo per 4 core, l'SMT potrebbe funzionare non sulla disponibilità di 1 core, ma su quella del modulo.

Paolo la l2 da 512KB è dedicata. E' la cache l3, che sembra essere condivisa tra 4 core, e non di più. Questo fa presupporre che AMD abbia intenzione di aggiungere un ulteriore livello di cache negli opteron oltre al fatto che la cache l3 sarà probabilmente velocissima.

Piedone, ero rimasto un pochino perplesso quando hai risposto ad un commento alterandone il significato. Tutto a posto: la prossima vedrai che mi correggerai tu.

[Piedone1113]

Originariamente inviato da paolo.oliva2

Mi sono spiegato male, colpa mia.

Partiamo dalla L2 che comunque deve contenere le istruzioni dei TH.

In Intel abbiamo 1 L2 e a cascata tutte le vie per gestire i 2 TH su 1 core.

In AMD, abbiamo sempre 1 L2, ma siccome condivisa nel modulo per 4 core, l'SMT potrebbe funzionare non sulla disponibilità di 1 core, ma su quella del modulo.

Ora, se 1 core nella media lavorasse al 75%, il TH "parallelo" avrebbe a disposizione il 25%.
Siccome la L2 in Zen è condivisa e praticamente serve tutti e 4 i core, l'SMT credo che anziché portare al 100% 1 core potrebbe portare al 100% il modulo

Ora, supponiamo che un 4 core Intel + SMT debba risolvere 5TH. 4 TH avrebbero la priorità e elaborati al 75%, ma il 5° avrebbe a disposizione il 25% di 1 core, e risulterebbe richiedere 4 volte in più di tempo rispetto agli altri TH e di fatto 3 core che non sfrutterebbero l'SMT.

Se fosse possibile che l'SMT di AMD sfruttasse il modulo e non il singolo cote, il 5° TH potrebbe lavorate anche al 100% (senza dare la priorità ad altri core) semplicemente perché ogni stallo di qualsiasi core verrebbe sfruttato per portare avanti quel TH senza che poi un TH venga impostato a priorità differenti.

Io faccio fatica a spiegare, ma se in Intel il 2° TH lavora al 25% e sta al 75% ad aspettare il primo TH, quei cicli 3 x 25% non potrebbero essere spostati sugli altri core?

P.S.
Lungi da me interpretazioni di bandiera, io prospetto solamente cosa potrebbe avere l'SMT di AMD di diverso fa Intel. Fermo restando, anche letto gli ultimi post, che le potenze sulla carta possono essere superiori quelle di Zen, ma dalla carta al silicio, dubito sull'efficienza AMD.

Paolo quello che chiedi è:
Se un th utilizza 3 pipeline su 4 al secondo th rimane una sola pipeline 25%
perché nel th gestito dall'smt non viene concesso l'uso delle 4 pipe rimanenti (su 4 core 3 pipe per ogni th + 5° core virtuale dalla fusione delle pipeline rimanti, cioè una per core)?

Oppure se una pipeline stalla in attesa di un dato (significa che un blocco della pipeline è in attesa di un evento in fase di elaborazione e quindi impedisce alla pipeline di proseguire con il suo flusso) spostare il th in coda nella pipeline su un'altra pipeline di un altro core?

l'smt sfrutta i tempi morti delle pipeline (praticamente un th aspetta un dato per poter iniziare una nuova operazione), ed in questi intermezzi che il core virtuale impegna la pipeline con un altro th.
In media l'uso delle pipeline è di 2,7 per processo, ma può variare e di molto da processo e processo.
Fin'ora abbiamo assistito alla gestione dinamica a livello di core delle risorse, nel tuo caso stai chiedendo se sia possibile avere una gestione dinamica della gestione dei core a livello di modulo e cioè passare da 4+4ht a 4+1ht ma sempre sfruttando il 100% delle pipeline a seconda del carico.
Giusto?

@Tuttodigitale
Figurati, non hai mica torto, ho cercato di spiegare un concetto senza entrare nella complessita propria delle cpu (che al 100% conosci molto meglio di me) e questo mi ha portato a fare un esempio non veritiero (anche se credo più facile da capire).
Anche se sono un appassionato di cpu molte cose mi sono ostiche da capire e cerco di farmi esempi elementari (per similitudine) per cercare di comprendere meglio.

[tuttodigitale]

Originariamente inviato da paolo.oliva2

Lungi da me interpretazioni di bandiera, io prospetto solamente cosa potrebbe avere l'SMT di AMD di diverso fa Intel. Fermo restando, anche letto gli ultimi post, che le potenze sulla carta possono essere superiori quelle di Zen, ma dalla carta al silicio, dubito sull'efficienza AMD.

SMT di AMD avrebbe questo di diverso:
le unità di esecutive (10) sono indipendenti. Se ci possono essere effettivi dubbi sull'effettiva utilità nel ST (i colli di bottiglia sono altrove), con due thread è effettivamente pensabile che il SMT possa effettivamente dare di più.
Il back-end di ZEN sembrerebbe bello corposo (sarebbe comunque da valutare la reale potenza delle ALU, tanto che il SMT-4 non è improbabile, sempre secondo me.

ecco il front-end di haswell.

[epimerasi]

State facendo un casino con sta storia delle pipeline che non avete idea

Originariamente inviato da FazzoMetal

"Nuovi" rumors riportati recentemente sul thread del forum di overclock.net dedicato a ZEN:

"If this capability to fuse and process larger instructions is carried over to Zen it would enable the two 256-bit FMAC units – 4 128-bit pipes – to fuse and process 512bit AVX instructions. Which would make the core compatible with Intel’s AVX512 instruction set extension. Which is currently only supported by Intel’s Knight’s Landing Xeon Phi microarchitecture.

The wider floating point unit also means that Zen will be able to process less complex instructions at double the rate of Steamroller A massive boost in floating point performance, an area where AMD had historically excelled in with Phenom II and prior CPUs."

Se AMD implementerà anche in ZEN la possibilità di configurare dinamicamente le pipe della FPU allora le nuove CPU sarebbero davvero competitive offrendo "paradossalmente" più di quanto Intel proponga oggi sulle sue attuali CPU.

IMHO la FPU di Zen sara` poco diversa da quella di Excavator (che erano 2 pipeline FPU che potevano sommarsi) raddoppiata (diventando 4-wide)

[.338 lapua magnum]

Originariamente inviato da gridracedriver

chissà, magari davvero potrebbero aver fatto un SMT a 4 vie, in pratica un 4 core con 16 thread.
Verrebbe da pensare come una sorta di lascito dell'architettura BD, e cioè quella propensione di reggere il carico che tanto è richiesta da alcuni utenti che ne fanno uso

comunque sul nome commerciale date poco peso, Zen, Meditazione...

indirettamente ci dicono che dovremmo avere calma, molta calma, quasi ascetica

Bulldozer potete dirgli tutto, ma rispecchia in pieno il nome commerciale

in effetti

[george_p]

Originariamente inviato da gridracedriver

chissà, magari davvero potrebbero aver fatto un SMT a 4 vie, in pratica un 4 core con 16 thread.
Verrebbe da pensare come una sorta di lascito dell'architettura BD, e cioè quella propensione di reggere il carico che tanto è richiesta da alcuni utenti che ne fanno uso

comunque sul nome commerciale date poco peso, Zen, Meditazione...

Bulldozer potete dirgli tutto, ma rispecchia in pieno il nome commerciale

In realtà se il nome è lo specchio del chip allora molto ben venga

[tuttodigitale]

Originariamente inviato da epimerasi

State facendo un casino con sta storia delle pipeline che non avete idea

la conoscenza è rumorosa.

Originariamente inviato da epimerasi

IMHO la FPU di Zen sara` poco diversa da quella di Excavator (che erano 2 pipeline FPU che potevano sommarsi) raddoppiata (diventando 4-wide)

Per adesso sembra che l'unica differenza sia la dimensione dei registri.

In BD/PD ci sono 4 pipeline per la fpu contro le 3 di Steamroller (per entrambi 2 FMAC).
P0 f.p. addition, multiplication, division,
integer vector multiplication
P1 f.p. addition, multiplication, division,
shuffle, shift, pack
P2 integer vector addition, boolean, move
P3 integer vector addition, boolean, move,
store
la p2 è stata eliminata in Steamroller

[paolo.oliva2]

Se posso dire...

Se la potenza di calcolo complessiva di Zen grossomodo fosse simile a quella Intel, ed Intel riesce a sfruttarla con 2 TH, nel senso che il numero pipeline riesce a far lavorare tutte le ALU del core... Perché AMD dovrebbe produrre una potenza superiore? Cioè, o Intel non arriva al 100% ed AMD con SMT 4 si, altrimenti qualche cosa non mi torna.

Ma... Io vedo che l'esperienza di AMD con l'acquisizione di ATI è notevole ed Intel fatica il recupero seppur con pozzi di sodi e quant'altro.... Allo stesso modo, trovo incomprensibile ed impossibile che AMD possa realizzare un SMT ancor più complesso di quello Intel, con tutto il contorno di cache, predizione e simili, e dalla carta al silicio con tutti i problemi sia di "compatibilità" da progetto al silicio ed annessi e connessi bilanciamenti TDP dovuto al consumo su un silicio che a tutt'oggi ad essere ottimisti sarebbe in via di sviluppo e quindi ben lontano dal conoscere gli effettivi limiti.

BAH... Nei comunicati GF si inquadra un range di funzionamento di Zen tra i 3 e 4GHz, cioè un range di +/- 33%, una vita. Da una parte si arriverebbe a poco più di un 25% rispetto a Pile, dall'altra un 70% in più.

[tuttodigitale]

Originariamente inviato da paolo.oliva2

BAH... Nei comunicati GF si inquadra un range di funzionamento di Zen tra i 3 e 4GHz, cioè un range di +/- 33%, una vita. Da una parte si arriverebbe a poco più di un 25% rispetto a Pile, dall'altra un 70% in più.

addirittura si suppone 4 GHz su un processo low-power? Anche se forse solo in turbo-mode, resto sempre più convinto della stretta parentela tra Zen e Bulldozer.
Ma non si sa niente sul numero di stages?

[Ren]

Originariamente inviato da tuttodigitale

addirittura si suppone 4 GHz su un processo low-power? Anche se forse solo in turbo-mode, resto sempre più convinto della stretta parentela tra Zen e Bulldozer.
Ma non si sa niente sul numero di stages?

Penso intorno ai soliti 14-16 stadi.

Dresdenboy ha parlato di una riduzione generica di stadi della pipeline, ma come al solito sono solo speculazioni.

[paolo.oliva2]

Originariamente inviato da gridracedriver

trascendi il fatto che per la prima volta negli ultimi 15 anni un gruppo di ingegneri cazzutissimi abbiano avuto carta bianca
non voglio fare proclami inutili, ma sta volta mi sa proprio che il 40% di IPC in più è il minimo che si aspettano.

siamo tutti d'accordo che debba rullare almeno sui 3.5ghz a def su tutti i core (conta che un i7-4 core a 14nm è 4ghz a def in 90watt, mente i7-8 core a 22nm è 3ghz a def in 140watt) ed in OC essere stabile a 4.5ghz ad aria e senza vcore fuori dalla grazia, ma tutto sta a capire quanti benedetti core avrà sta cpu, se 4 o 8 più SMT; è probabile che la base sia da 4 core e la top a 8 core, ma quello che mi fa storcere il naso è che si parla di 8 core più SMT in 95 watt e che rulli come un 6 core più SMT Intel!... a me pare assurdo, troppo ottimistico come efficienza raggiunta

Grossomodo il 40% in più dibIPC su Excavator che a sua volta ha il 20/25% in più di IPC su Pile porterebbe ad una differenza Zen Pile oltre il 70%.
Sempre a spannella, da un 32nm ad un 14/16nm si avrebbe un -50% di TDP, quindi da un 8350 X8 si passerebbe tranquillamente ad un X16. Un Zen X8 con +70% di IPC concederebbe un X12 nei 125W, un X8 nei 95W ci starebbe. Da tenere presente che BD ha un TDP alto non per l'architettura, ma per il silicio. Considerando un 8350 a 95W, un Zen X8 a 95W ci starebbe alla stragrande.
Comunque, a me piacerebbe se possibile quantificare un Zen con e senza SMT (se disabilitabile), perché si avrebbe il metro preciso di quanto sarebbe potuto andare il CMT sul 32nm, perché il CMT è una cosa, la lunghezza pipeline un'altra e tutta la differenza (per me abnorme) era tutta nel 32nm. Anche il discorso IPC di BD pra di Zen è stato strettamente dipendente al silicio, vedi FX no Steamroller e no Excavator, ma non possiamo manco escludere che sia ST che Ex siano stati gambizzati per rientrare in determinati TDP.

[tuttodigitale]

Originariamente inviato da paolo.oliva2

Grossomodo il 40% in più dibIPC su Excavator che a sua volta ha il 20/25% in più di IPC su Pile porterebbe ad una differenza Zen Pile oltre il 70%.

Paolo se la FPu è la stessa, automaticamente un modulo SR/XV e un core ZEN HT, andrebbero uguali! Visto che un minimo di miglioramento ci deve pur essere, potremmo aspettarci un +100% secco tra un core PD e un core ZEN, per quanto riguarda i calcoli in floating point. E secondo me ci sono buone possibilità di non rimanere delusi.

ho come l'impressione che in quella slide AMD, si riferisca si alle prestazioni di un core XV vs ZEN+SMT, ma solo per quello che attiene al calcolo intero. (per amd i core sono i cluster integer).

imho, un core ZEN con HT potrebbe andare circa 80-90% di un modulo SR nei calcoli integer, e un buon 10-20% in più nel FP. Non mi sembra affatto male.

[epimerasi]

Originariamente inviato da tuttodigitale

la conoscenza è rumorosa.


Per adesso sembra che l'unica differenza sia la dimensione dei registri.

In BD/PD ci sono 4 pipeline per la fpu contro le 3 di Steamroller (per entrambi 2 FMAC).
P0 f.p. addition, multiplication, division,
integer vector multiplication
P1 f.p. addition, multiplication, division,
shuffle, shift, pack
P2 integer vector addition, boolean, move
P3 integer vector addition, boolean, move,
store
la p2 è stata eliminata in Steamroller

da quel che ho capito in zen p0 e p1 dovrebbero raddoppiare

[paolo.oliva2]

Originariamente inviato da tuttodigitale

Paolo se la FPu è la stessa, automaticamente un modulo SR/XV e un core ZEN HT, andrebbero uguali! Visto che un minimo di miglioramento ci deve pur essere, potremmo aspettarci un +100% secco tra un core PD e un core ZEN, per quanto riguarda i calcoli in floating point. E secondo me ci sono buone possibilità di non rimanere delusi.

ho come l'impressione che in quella slide AMD, si riferisca si alle prestazioni di un core XV vs ZEN+SMT, ma solo per quello che attiene al calcolo intero. (per amd i core sono i cluster integer).

imho, un core ZEN con HT potrebbe andare circa 80-90% di un modulo SR nei calcoli integer, e un buon 10-20% in più nel FP. Non mi sembra affatto male.

Onestamente io non mi faccio tanti preamboli per la testa. Personalmente il prossimo procio che farei sarebbe un 5960X.
Se poi AMD farebbe un Zen 5960X , bene, l'importante è anche i produttori di mobo facciano la loro parte.con un supremo reparto alimentazione, un BIOS cazzuto ed un Zen sbloccato in ogni singola parte.

[Grizlod®]

Comparativa tratta dal profilo twitter di dresdenboy



saranno obsolete, ma a me fa (molto) piacere rivedere le X87