[Thread Ufficiale] Aspettando ZEN

[Grizlod®]

Originariamente inviato da Free Gordon

Ora tutto sta nel vedere se riescono ad uscire a ottobre 2016...

I 10nm di Intel per quando sono previsti?

Io sono realisticamente fiducioso, se hanno detto 2016, sarà quest'anno.

Se poi non ricordo male, c'erano rumors dove prevedevano prima l'uscita per desktop e successivamente (2017) per server.

[bjt2]

Originariamente inviato da tuttodigitale

Facevo appunto riferimento alla seconda opzione, e non mi pare questa gran genialata. . Meglio rendere capaci di eseguire le FADD, gli costa meno silicio (IMHO).
D'altra parte abbiamo avuto informazioni mancanti, lacunose e aberranti. Vuoi vedere che sono quattro FMAC, come ce li immaginavamo fin dall'inizio.

4 FMAC improbabile, perchè il moltiplicatore costa molta area, ma non si sa mai... Perchè poi si semplifica il decoder e lo scheduler se le unità sono tutte quante uguali, vedi le GPU...

Quello che dici tu è la prima opzione che ho menzionato... Cosa credi che siano le MOP? Sono solo delle istruzioni come le x86, ma a lunghezza fissa e con campi predeterminati e formattati... Se per esempio la FMAC è codificata con il codice x, la FADD potrebbe essere codificata con il codice y e l'unità FMAC saprà che con il codice y deve ignorare il moltiplicando che sta su un bus predeterminato ed usare la costante predefinita 1.0f (1 in floating point) a 32 bit o 64 bit a seconda se la FADD è a 32 o 64 bit (e avranno 2 codici diversi ovviamente)...

[tuttodigitale]

Originariamente inviato da bjt2

Quello che dici tu è la prima opzione che ho menzionato...

NO, mi riferivo alla seconda opzione che utilizza un registro speciale, che rende del tutto inconsapevole l'unità FMAC. Nella prima opzione dovresti comunque mettere mano alla FMAC, per riconoscere una nuova istruzione.

Credo che l'opzione sia o rendere compatibile FADD la FMAC, o non renderla capace affatto. I rumors tendono per questa seconda ipotesi, ma erano gli stessi che dicevano che non esistevano unità FMAC e che la P3 era indispensabile per l'esecuzione di questo tipo di istruzioni..Questa era l'ipotesi più accreditata fino ad un paio di giorni fa....ed era la ragione principale per cui ho rivisto assai al ribasso l'aumento di ipc...

NNon dimentichiamo che non utilizzare la FMAC per le semplici FADD permette anche un maggior risparmio energetico. Quindi boh...

Originariamente inviato da bjt2

4 FMAC improbabile, perchè il moltiplicatore costa molta area, ma non si sa mai...

Siamo passati da una 1MUL+2ADD (devo controllare, ma sono sicuro al 90% che era così) ad una 2FMAC+2ADD, di questo passo davvero ci sono 4 FMAC: non si sa mai....

PS è vero che le FMUL costano tanto in termini di transistor, ma le pipeline sono ampie solo 128bit, e Intel ne ha 2 ma da 256 bit. Tutto può essere....

OMG. Ho detto tutto e il contrario di tutto. Ho senz'altro ragione

[bjt2]

Originariamente inviato da tuttodigitale

PS è vero che le FMUL costano tanto in termini di transistor, ma le pipeline sono ampie solo 128bit, e Intel ne ha 2 ma da 256 bit. Tutto può essere....

OMG. Ho detto tutto e il contrario di tutto. Ho senz'altro ragione

Effettivamente non ci avevo pensato... A 28nm magari il core veniva troppo grande... Ma a 14nm, visto che i core saranno sempre 8 (anche se erano 4 moduli, ma vabeh) e la densità è praticamente quasi doppia...

Facciamo i conti: 28nm -> 8 core, 4 moduli (escludiamo GPU o L3 a seconda dei modelli). Ogni modulo sono 4 ALU, 4 AGU, 2 FMAC 128b, 2 MMX 128b, 4 decoder, 96KB+32KB cache L1, 2MB cache L2, quindi:

4 Moduli Excavator, escludendo L3 o GPU hanno:
16 ALU, 16 AGU, 8 FMAC, 8 MMX, 16 decoder, circa 8MB tra L1 e L2.

Tutto questo a 28nm.

8 core ZEN richiedono:
8x4=32 ALU
8x2=16 AGU
8x2=16 FMAC
8x2=16 FADD
8x4=32 decoder
8x64+64=1MB di cache L1
8x512=4MB di cache L2

Tutto questo a 14nm. Supponendo una densità doppia del 14nm, questo può richiedere meno area di excavator perchè è come se avessimo la stessa area di 4 core Zen implementati però a 28nm. Avremmo stesse ALU, decoder, FMAC e FADD/MMX, la metà delle AGU e un quarto della cache L2! Avremmo anche spazio per core più complessi! E infatti c'è la cache L0, checkpointing, supporto SMT e chissà cos'altro... Probabilmente c'è lo spazio per fare nella stessa area delle FPU più potenti...

Se vediamo INTEL a 14nm per il desktop ha 4 core+GPU dove i core hanno FMAC a 256 bit... Quindi c'è spazio per fare 4 FMAC.

Resto del parere che in un modo o nell'altro le 2 FMAC sono sicuramente usate anche per le FADD... Avevo letto da qualche parte che le prestazioni di picco erano attestate a 4 FADD, tanto che era sorto il dubbio che a regime non si riusciva a tenerle tutte occupate perchè la lettura da memoria può fare solo 2 parole da 128 bit per ciclo...

[Ren]

Originariamente inviato da Free Gordon

Ora tutto sta nel vedere se riescono ad uscire a ottobre 2016...

I 10nm di Intel per quando sono previsti?

La prima ad uscire con i 10nm sarà Samsung.

I 14nm di intel sono quasi mezzo nodo avanti, usano airgap(nelle interconnessioni) ed hanno tre gate contro i due dei concorrenti.

E' probabile che intel integri tecnologie previste per i 7nm (III-V, QWFET), nei suoi 10nm.

[tuttodigitale]

Originariamente inviato da bjt2

Facciamo i conti:

se non ti dispiace ti dò una mano. Probabilmente ti riferisci a PD.

Originariamente inviato da bjt2

4 Moduli Excavator, escludendo L3 o GPU hanno:
16 ALU, 16 AGU, 8 FMAC, 4 MMX, 32 decoder, circa 4MB tra L1 e L2.

FIXED
ogni modulo excavator/steamroller ha 8 decoder, 4 per ogni core e 1 unità MMX. In excavator hanno dimezzato la cache l2.

Da notare che nello spazio di 2 moduli steamroller con l2 da 2 MB ce ne vanno quasi 3 di excavator con l2 da 1MB, sempre su 28nm.

Con l'uso dellle HDL, la dimensione del modulo excavator, privo della l2, è di soli 14mmq, che passando ai finfet sarebbero circa 7mmq e altri 3 per la cache l2 da 1MB. Se la memoria non mi tradisce, un modulo+l2 bulldozer era grande poco più di 30mmq...Potrebbero in teoria triplicare TUTTE le risorse e avere dimensioni accettabili...

Originariamente inviato da bjt2

. Supponendo una densità doppia del 14nm, questo può richiedere meno area di excavator perchè è come se avessimo la stessa area di 4 core Zen implementati però a 28nm.

Come detto, a più riprese i 14nm e i 16nm, sono solo nomi commerciali. La prima è stata Intel, per dare risalto alle migliorie offerte dal tri-gate, commercializzando un PP da 26nm come un 22nm.
A dispetto del nome, ad oggi siamo a conoscenza del fatto che i 14nm lpe (non so cosa cambi dal lpp a livello di integrazione) permette un aumento di densità dei transistor (transistor/mmq) "solo" del 2,1x rispetto ai 28nm TSMC, a dispetto dei 4 teorici.
Tuttavia è stato ridotto il consumo in misura maggiore, e questo dovrebbe aiutare le CPU che usano le HDL e/o che hanno una bella propensione a viaggiare ad alta frequenza..

Rispetto ai 32nm, siamo a 2,5x.

abbiamo quindi:
SUPER CORE by tuttodigitale
cpu 8 core

caratteristiche del singolo core
12 decoder
6 ALU
6AGU,
3 FMAC
1,5MB

è strasotto, in tutto le parti, ergo, AMD per pareggiare le dimensioni di un modulo di BD, deve infarcire di elementi la CPU. Credo di non rischiare niente se dico che il core ZEN sarà più piccolo di un modulo SR e PD.

[digieffe]

Originariamente inviato da tuttodigitale

se non ti dispiace ti dò una mano. Probabilmente ti riferisci a PD.

FIXED
ogni modulo excavator/steamroller ha 8 decoder, 4 per ogni core e 1 unità MMX. In excavator hanno dimezzato la cache l2.

Da notare che nello spazio di 2 moduli steamroller con l2 da 2 MB ce ne vanno quasi 3 di excavator con l2 da 1MB, sempre su 28nm.

Con l'uso dellle HDL, la dimensione del modulo excavator, privo della l2, è di soli 14mmq, che passando ai finfet sarebbero circa 7mmq e altri 3 per la cache l2 da 1MB. Se la memoria non mi tradisce, un modulo+l2 bulldozer era grande poco più di 30mmq...Potrebbero in teoria triplicare TUTTE le risorse e avere dimensioni accettabili...


Come detto, a più riprese i 14nm e i 16nm, sono solo nomi commerciali. La prima è stata Intel, per dare risalto alle migliorie offerte dal tri-gate, commercializzando un PP da 26nm come un 22nm.
A dispetto del nome, ad oggi siamo a conoscenza del fatto che i 14nm lpe (non so cosa cambi dal lpp a livello di integrazione) permette un aumento di densità dei transistor (transistor/mmq) "solo" del 2,1x rispetto ai 28nm TSMC, a dispetto dei 4 teorici.
Tuttavia è stato ridotto il consumo in misura maggiore, e questo dovrebbe aiutare le CPU che usano le HDL e/o che hanno una bella propensione a viaggiare ad alta frequenza..

Rispetto ai 32nm, siamo a 2,5x.

abbiamo quindi:
SUPER CORE by tuttodigitale
cpu 8 core

caratteristiche del singolo core
12 decoder
6 ALU
6AGU,
3 FMAC
1,5MB

è strasotto, in tutto le parti, ergo, AMD per pareggiare le dimensioni di un modulo di BD, deve infarcire di elementi la CPU. Credo di non rischiare niente se dico che il core ZEN sarà più piccolo di un modulo SR e PD.

12 decoder per core?

[bjt2]

Originariamente inviato da tuttodigitale

se non ti dispiace ti dò una mano. Probabilmente ti riferisci a PD.

FIXED
ogni modulo excavator/steamroller ha 8 decoder, 4 per ogni core e 1 unità MMX. In excavator hanno dimezzato la cache l2.

Da notare che nello spazio di 2 moduli steamroller con l2 da 2 MB ce ne vanno quasi 3 di excavator con l2 da 1MB, sempre su 28nm.

Con l'uso dellle HDL, la dimensione del modulo excavator, privo della l2, è di soli 14mmq, che passando ai finfet sarebbero circa 7mmq e altri 3 per la cache l2 da 1MB. Se la memoria non mi tradisce, un modulo+l2 bulldozer era grande poco più di 30mmq...Potrebbero in teoria triplicare TUTTE le risorse e avere dimensioni accettabili...


Come detto, a più riprese i 14nm e i 16nm, sono solo nomi commerciali. La prima è stata Intel, per dare risalto alle migliorie offerte dal tri-gate, commercializzando un PP da 26nm come un 22nm.
A dispetto del nome, ad oggi siamo a conoscenza del fatto che i 14nm lpe (non so cosa cambi dal lpp a livello di integrazione) permette un aumento di densità dei transistor (transistor/mmq) "solo" del 2,1x rispetto ai 28nm TSMC, a dispetto dei 4 teorici.
Tuttavia è stato ridotto il consumo in misura maggiore, e questo dovrebbe aiutare le CPU che usano le HDL e/o che hanno una bella propensione a viaggiare ad alta frequenza..

Rispetto ai 32nm, siamo a 2,5x.

abbiamo quindi:
SUPER CORE by tuttodigitale
cpu 8 core

caratteristiche del singolo core
12 decoder
6 ALU
6AGU,
3 FMAC
1,5MB

è strasotto, in tutto le parti, ergo, AMD per pareggiare le dimensioni di un modulo di BD, deve infarcire di elementi la CPU. Credo di non rischiare niente se dico che il core ZEN sarà più piccolo di un modulo SR e PD.

Hai ragione sui decoder...
Anche sul 14nm sapevo che lo scaling non era 4x... Stavo facendo conti a spanne... Per la L2 non ricordavo che l'avessero dimezzata in XV... E nonostante questo dalle prove preliminari sembra abbia un IPC bello alto! Sarà forse per il nuovo branch predicition di Jaguar? O la L1I da 96KB?

Originariamente inviato da digieffe

12 decoder per core?

Sta triplicando le risorse per avere la stessa area di XV a 28nm.

[Ren]

Originariamente inviato da bjt2

Hai ragione sui decoder...
Anche sul 14nm sapevo che lo scaling non era 4x... Stavo facendo conti a spanne... Per la L2 non ricordavo che l'avessero dimezzata in XV... E nonostante questo dalle prove preliminari sembra abbia un IPC bello alto! Sarà forse per il nuovo branch predicition di Jaguar? O la L1I da 96KB

Su excavator hanno modificato anche la L1D, adesso è da 32KB.
Credo che anche la latenza della L2 sia un tantino diversa.

[tuttodigitale]

Originariamente inviato da bjt2

O la L1I da 96KB?

La L1I da 96KB, ce l'ha anche steamroller. E' la L1D, che ha raddoppiato di dimensioni passando da 16 a 32KB.
La cache l2 ha mantenuto la stessa associatività dei predecessori e pare che abbia subito una drastica riduzione delle latenze.

EDIT
ho scritto le stesse cose. Quanto sono letto a scrivere con il telefono

[Ren]

Dai ti aiuto(copione). Hanno anche aumentato il branch target L1 del 50% (768e 3way)

[bjt2]

Ma da prove con i primi XV desktop sembra che in cinebench si sia guadagnato anche 10% di IPC... Penso che la branch predicition di jaguar per caso sia stata fenomenale... Daltronde il team era probabilmente diverso come ai tempi di Merom/Conroe e Precotto in Intel... Poi sappiamo chi è stato fanculizzato e chi no...

[Free Gordon]

Puma è identico a livello di architettura?

A parte le migliorie legate al processo produttivo, minor leakage ecc..

[bjt2]

Originariamente inviato da Free Gordon

Puma è identico a livello di architettura?

A parte le migliorie legate al processo produttivo, minor leakage ecc..

Mi pare di no. Sicuramente Bobcat era con unità a 64 bit e quindi non supportava le AVX a 256 bit, mentre Jaguar ha unità a 128 bit. Puma mi sfugge al momento...

[tuttodigitale]

Originariamente inviato da digieffe

12 decoder per core?

come ha detto bjt2

Originariamente inviato da bjt2

Sta triplicando le risorse per avere la stessa area di XV a 28nm.

Mi rendo conto che è un poco oscuro il mio post. Cerco di renderlo più chiaro.
Abbiamo calcolato il gap, a livello di dimensioni tra un modulo+L2 excavator sui 14nm e un modulo+L2 piledriver.

Per fare ciò abbiamo preso le misure di excavator su 28nm, valori indicativi:

Excavator@28nm: 14,8mmq (2core) +6mmq (cache l2 da 1MB)
e abbiamo diviso per 2,1, che è il guadagno in termini di densità areale dei 14nm sui 28nm (di fatto sono dei 20nm...)

otteniamo questo:
Excavator@die shrink a 14nm: 7mmq (2core)+ 3mmq (cache l2 da 1MB)

per confronto abbiamo preso PD
Piledriver@32nm:19,2mmq+12mmq (cache l2 da 2MB)

Tra i due c'è una differenza di 3x, ovvero un ipotetico modulo XV sui 14nm occuperebbe un'area 3 volte inferiore a quella di PD sui 32nm.
A questo punto, abbiamo ipotizzato, che finchè si rimane nelle dimensioni del vecchio PD, le dimensioni di un core sono per così dire accettabili.
Viene da sè, che se i core rimangono 8, ZEN con annessa L2, può avere una complessità circuitale 3 volte superiore al singolo core.

Per questa ragione ho moltiplicato le risorse del singolo core per 3. Il fatto che sia usciti numeri fuori dal mondo, ci dice che in realtà un core ZEN sarà decisamente più piccolo di un core PD.
Addirittura, anche la l3, dovrebbe subire una minima riduzione delle dimensioni, nonostante si passi da 8 a 16MB..

Le caratteristiche attuali grossolanamente portano a questi risultati:
1core XV------- -vs------- 1 core ZEN
4decoder-----------------4decoder (uguale)
1 INT-vs------------------2x1 scheduler INT (+100%)
2ALU---------------------4ALU (+100%, ma dubito assai che sia tutte in grado di eseguire le MUL/ADD, è più vero simile un +40%)
2AGU---------------------2AGU (uguale)

FPU (valori di XV da dividere per 2)
2x1 scheduler FP--vs------2x1 scheduler (indentico, ma sono 1 per core, +100%)
2 FMAC-----------vs-------2FMAC (uguale. +100%)
1MMX-------------vs-------2FADD (facciamo +500%, ma ricordiamo che sono unità relativamente piccole)

cache L2 per core
512KB------------vs--------512KB (indentico, ma credo che si passi al 8T SRAM, quindi +33%)

di gran lunga inferiore al 3x calcolato su. Credo che un core ZEN abbia più o meno la stessa complessità di un modulo XV.

Originariamente inviato da bjt2

Cosa credi che siano le MOP? Sono solo delle istruzioni come le x86, ma a lunghezza fissa e con campi predeterminati e formattati...

ho fatto un intero post sulle uop e MOP, e mi pare che abbia anche scritto che le uop di Intel, e quindi a maggior ragione le MOP di AMD, sono in grado di eseguire codice CISC pur presentando una formattazione "razionale".

[bjt2]

Originariamente inviato da tuttodigitale

ho fatto un intero post sulle uop e MOP, e mi pare che abbia anche scritto che le uop di Intel, e quindi a maggior ragione le MOP di AMD, sono in grado di eseguire codice CISC pur presentando una formattazione "razionale".

A rigore le istruzioni CISC possono fare operazioni complesse come seno, coseno, operazioni read/modify/write complesse, lock, istruzioni di sistema. Le MOP AMD, e a maggior ragione le uop INTEL no.
Le uop INTEL seguono la filosofia RISC. Anche le uop AMD, ma AMD raggruppa le uop in MOP. Quindi le MOP AMD sono una sorta di CISC perchè uniscono più uop RISC, ma non arrivano alla complessità necessaria per fare tutte le operazioni con una sola MOP: il set x86 è sterminato e pieno di istruzioni complesse e astruse. Per definire un set di istruzioni CISC, molti sostengono che debba essere microcodificato e le MOP non lo sono. Semplicemente sono un raggruppamento fisso di più uop e quindi sono paragonabili a una singola uop molto estesa. E sono anche decodificate: una istruzione può avere un codice numerico come opcode, che non significa nulla. Invece una uop, e quindi le MOP, hanno il "codice" che descrive l'operazione che non è un codice, ma una sequenza di bit, di cui pochi a 1 e moltissimi a zero, dove ogni bit accende o spegne particolari unità e bus di una pipeline. Ad esempio: se ipotizzo che FADD è codificato con x, FMUL con y e FMAC con z, una ipotetica MOP avrà dei bit a 1 per attivare i bus di ingresso e uscita, dei bit a 1 per l'ADD e/o MUL (per la FMAC), ecc...

[tuttodigitale]

Tra le complex micro-ops di intel e le MOP di AMD, non esistono sulla carta, sostanziali differenze, se nonchè l'architettura Intel non è in grado di sfornarne più di una per ciclo.

Non sono tenuto a conoscere la definizione di questi "molti" sul CISC, mi basta che gli ingegneri di Intel concordano che le micro-ops Fusion di fatto abilitano la CPU all'esecuzione di codice CISC.
Anche perchè diverse architetture, anche all'interno della stessa famiglia, hanno le uops di diversa potenza, e pertanto istruzioni simili, possono essere o non essere microcodificate...

Non so per quale ragione, lei abbia esteso l'esecuzione di alcune semplici istruzioni CISC, da parte delle uops che hanno una dimensione di 236 bit, all'intero set di istruzioni x86 ....

Non devi dimostrarmi che sei competente, ho già avuto modo di constatarlo anni fa.

[bjt2]

Originariamente inviato da tuttodigitale

Tra le complex micro-ops di intel e le MOP di AMD, non esistono sulla carta, sostanziali differenze, se nonchè l'architettura Intel non è in grado di sfornarne più di una per ciclo.

Non sono tenuto a conoscere la definizione di questi "molti" sul CISC, mi basta che gli ingegneri di Intel concordano che le micro-ops Fusion di fatto abilitano la CPU all'esecuzione di codice CISC.
Anche perchè diverse architetture, anche all'interno della stessa famiglia, hanno le uops di diversa potenza, e pertanto istruzioni simili, possono essere o non essere microcodificate...

Non so per quale ragione, TU hai esteso l'esecuzione di alcune istruzioni CISC, da parte delle uops che hanno una dimensione di 236 bit, all'intero set di istruzioni x86 che è si limitato a 15byte, ma con una formattazione dei diversi campi irregolare, finalizzata alla riduzione delle dimensioni (Spesso nelle micro-op ci sono interi campi inutilizzati, o con il numero di bit eccessivi).

Non devi dimostrarmi che sei competente, ho già avuto modo di constatarlo anni fa.

Vabeh, molte istruzioni CISC sono semplici e si traducono in 1 MOP o addirittura in una uop, ma la definizione più accettata per distinguere RISC da CISC è che le RISC sono istruzioni che agiscono SOLO su registri e le uniche istruzioni abilitate ad accedere alla memoria sono le load e store e le uop INTEL e le MOP AMD da questo punto di vista sono istruzioni RISC, perchè SOLO le uop/MOP che accedono alle LSU possono accedere alla memoria: le altre uop/MOP hanno 0/1/2/3 registri in ingresso e 1/2 in uscita... Resta il fatto che le MOP sono più potenti delle uop...

BTW ho letto il PDF della stack cache... Se usano la strategia di cache separata per lo stack, oltre al risparmio energetico, e quindi potenziale turbo maggiore, si ha anche una cache effettiva di dimensione superiore, perchè tutta la cache dati è usata per i soli dati e non è "mangiata" dallo stack che è nella cache a parte... MOOOLTO interessante...

http://research.cs.wisc.edu/multifac...tack_cache.pdf

[tuttodigitale]

Originariamente inviato da bjt2

ma la definizione più accettata per distinguere RISC da CISC è che le RISC sono istruzioni che agiscono SOLO su registri

che poi è la definizione che insegnano a scuola per distinguere le 2 grandi famiglie. Ma le micro-ops di Intel sono in grado di eseguire operazioni memory to register, inevitabile conseguenza quando si fondono due micro-ops.
Non volgio dire che io abbia ragione, ma si ho ragione

il link, è molto interessante.

[stefanonweb]

Scusate la domanda banale, ma il socket FM2+ che fine dovrebbe fare? Grazie.