View Full Version : [Thread Ufficiale] Aspettando ZEN
Aspettavo un thread su Zen per ripalesarmi... :sofico:
Ero in crisi di astinenza da notizie...
Il thread più completo su Zen che ho trovato fin'ora è questo: http://semiaccurate.com/forums/showthread.php?t=8654&page=206
Ma sono 206 pagine... :sofico:
george_p
24-02-2016, 09:39
Aspettavo un thread su Zen per ripalesarmi... :sofico:
Ero in crisi di astinenza da notizie...
Il thread più completo su Zen che ho trovato fin'ora è questo: http://semiaccurate.com/forums/showthread.php?t=8654&page=206
Ma sono 206 pagine... :sofico:
Riguardo le cache e nuovi brevetti amd:
http://www.bitsandchips.it/9-hardware/4395-con-le-future-architetture-x86-e-k12-amd-ha-deciso-di-migliorare-la-cache
:cool:
Riguardo le cache e nuovi brevetti amd:
http://www.bitsandchips.it/9-hardware/4395-con-le-future-architetture-x86-e-k12-amd-ha-deciso-di-migliorare-la-cache
:cool:
Sono tutte migliorie che sono indipendenti dall'inclusività della cache, ma sono molto interessanti se poi saranno implementate in Zen...
george_p
24-02-2016, 10:02
Sono tutte migliorie che sono indipendenti dall'inclusività della cache, ma sono molto interessanti se poi saranno implementate in Zen...
Ma se non erro amd ha deciso di optare anche lei alla fine per la cache inclusiva, no?
I più queste migliorie saranno valore aggiunto.
Free Gordon
24-02-2016, 10:15
W bjt2!! :yeah: :yeah: :yeah:
Mister D
24-02-2016, 10:21
Visto solo ora il thread...
Iscritto...
cut...
Ben tornato bjt2!!!!:yeah: :yeah: :yeah:
Non vedevo l'ora di rileggere uno dei tuo post molto tecnici. Se posso chiedere, scrivi ancora articoli su extremehardware? Se no, potresti pensare di farlo solo per Zen:D ?
PS: con la tua previsione di un aumento medio del 50% del smt amd dovrei rivedere i miei calcoli xD
Mister D
24-02-2016, 10:36
Confronto tra PD, XV e ZEN core a parità di frequenza (no turbo). -REV1 per osservazioni bjt2-
Valori di riferimento cb r15 Fx8350 ST 100 (4,2 GHz turbo) e MT 640 (4 GHz)
ST a 4 GHz di PD: 95
MT modulo PD: 95+95*0,80 = 171
Aumento percentuale da PD a XV: *1,29
Aumento percentuale dichiarato da amd tra xv e core zen: *1,4
Fattore correttivo scaling non lineare in cb r15: 640/(171*4)= 0,935->*0,94
Aumento percentuale medio del SMT: *1,5
Caso 1
Il più verosimile perché applico l'aumento dichirato da amd alle prestazioni in cb r15 di un core XV e poi ricavo il valore MT applicando l'aumento percentuale del SMT del 50% al core XV.
Prima di tutto ricavo da 95*1,29=123 il valore di un core XV, poi il modulo XV 171*1,29=221 e infine core zen 1th 123*1,4=172 e il core zen 2th 172*1,50=258.
Gli altri valori verranno ricavati moltiplicando per il numero di core (moduli per PD e XV) e per il fattore correttivo.
------ST (1th)---MT (2th)---MT (8th)---MT (16th)
PD------95---------171--------640--------1280*
XV------123--------221--------830*------1660*
Zen-----172--------258--------970-------1940
Ora un ipotetico Zen 8c/16 th a 3,2 GHz Turbo_max_1core 4 GHz avrebbe in ST 172 e MT 2th 258 ma in MT 16th avrebbe 1940*3,2/4= 1552 punti. Questo valore mi pare verosimile con un buon lavora di amd senza miracoli.
Caso 2
Il più aggressivo perché applico l'aumento dichirato da amd alle prestazioni in cb r15 di un modulo XV senza applicare il SMT che è così già incluso (1,4=1,15 IPC * 1,2 SMT medio) e poi ricavo inversamente il valore ST andando a dividere la parte di SMT.
Prima di tutto ricavo da 95*1,29=123 il valore di un core xv, poi il modulo xv 171*1,29=221 e infine core zen 2th 221*1,4=309 e il core zen 1th 309/1,20=258. Gli altri valori verranno ricavati moltiplicando per il numero di core (moduli per PD e XV) e per il fattore correttivo.
------ST (1th)---MT (2th)---MT (8th)---MT (16th)
PD------95---------171---------640--------1280*
XV-----123--------221---------830*-------1660*
Zen----258--------309--------1162--------2324
Ora un ipotetico Zen 8c/16 th a 3,2 GHz Turbo_max_1core 4 GHz avrebbe in ST 258 e MT 2th 309 ma in MT 16th avrebbe 2324*3,2/4= 1859 punti. Questo valore mi pare meno probabile perché amd (Keller) avrebbe dovuto fare un vero miracolo (ci possiamo sperare ma attenzione a rimaner delusi).
Nota: i valori con gli asterischi corrispondono a cpu mai nate (PD con 8 moduli e XV con 4/8 moduli)
@tuttodigitale: se vuoi rifare i grafici puoi utilizzare questi valori aggiornati;)
EDIT: Lo so è un metodo un po' rozzo ma almeno sembrano delle tabelle LOL
Ma se non erro amd ha deciso di optare anche lei alla fine per la cache inclusiva, no?
I più queste migliorie saranno valore aggiunto.
Si! :D :cool:
Ben tornato bjt2!!!!:yeah: :yeah: :yeah:
Non vedevo l'ora di rileggere uno dei tuo post molto tecnici. Se posso chiedere, scrivi ancora articoli su extremehardware? Se no, potresti pensare di farlo solo per Zen:D ?
PS: con la tua previsione di un aumento medio del 50% del smt amd dovrei rivedere i miei calcoli xD
Con mio grande rammarico non ho il tempo di scrivere per loro e mi dispiace tantissimo, non credo di poterlo fare neanche per Zen... :D
Il lavoro mi prende molto... Ho anche imparato a programmare le GPU... :sofico:
george_p
24-02-2016, 11:10
Si! :D :cool:
Con mio grande rammarico non ho il tempo di scrivere per loro e mi dispiace tantissimo, non credo di poterlo fare neanche per Zen... :D
Il lavoro mi prende molto... Ho anche imparato a programmare le GPU... :sofico:
A noi basta che posti qua, sei il nostro dresdenboy italiano :D
Comunque anche il caso ideale per cui il +40% di IPC si riferisca a 1 thread vs 1 thread, in ST non credo si raggiunga INTEL, ma forse in MT si, visto che l'efficienza dell'MT dovrebbe essere superiore...
Ma poi, visto il numero di porte di esecuzione, chi vi dice che l'SMT di ZEN sarà solo a 2 vie? :sofico: Non è scritto da nessuna parte che è a 2 vie... :sofico:
Il Power 8 è un SMT a 8 vie su 16 pipelines... Con 10 pipelines si potrebbe anche pensare a 4 thread... :sofico:
La mia è una provocazione, magari l'SMT4 se lo terranno per Zen+ o non lo vedremo mai, ma teoricamente è possibile...
Tuttodigitale lo escludeva sia per via delle porte comunque limitate che del decoders 4-wide (come haswell), anche se il tipo del Cern nell'ultima conferenza ha indicato che Zen sarà 6-wide decoders (come skylake) :fagiano:
Il Power 8, per un SMT 8 è dato a ten issue e eight dispatch on 16 pipes. Dimezza tutto e per 4 thread, per avere la stessa efficienza di un POWER 8 (che è un MOSTRO, ricordiamolo), devi avere 5 issue (se non mi sbaglio sarebbe quello prodotto dai decoders), 4 dispatch e 8 pipes. Zen avrà 4 (o 6, se quello che dice il tipo del CERN è vero :sofico: ) issue, 4 dispatch e 10 pipes... Credo che si possa fare... Ma la mia era una provocazione... Un SMT4 può essere utile nell'HPC, ma nel desktop, visto che i core saranno già 8, penso di no... Anche se io li vorrei 4 thread per core... :D
Mister D
24-02-2016, 11:43
1.29* tra PD e XV come salta fuori?
esempio in CB 11.5 XV senza L3 con L2 da 512kb (2x1 MB a modulo, l'Athlon 845) fa +12% in ST e +21% in MT, in CB 15 XV fa sempre +11% in ST ma -20% in MT :stordita:
ok non considerate superpippo, ma li il guadagno ST è nell'ordine del +40~60% circa:
"Superpi 32M is much smoother than everything from AMD. At 3.8 GHz single channel in 13m 6s. Wow, for this you need FX Vishera with dualchannel and some light tweaks at 5300 MHz or Kaveri at 4900 MHz!"
5.3/3.8= +40% di IPC in SuperPI con 32M rispetto a Piledriver_Vishera in single channel
in dual channel invece
"in 32M run 27s quicker than before! And result? Wow...As 5 GHz hard tweaked Kaveri or as 6 GHz FX Vishera Lol, its my personal record at AMD AIR :-D"
6/3.8=+58% di IPC in SuperPI con 1M dual channel
ma nel secondo caso non dovresti fare 309/1.5=206 per il ST?
cioè ho capito che calcoli il +40% sull'intero modulo, ma se consideriamo il +50% di SMT di bjt2 l'ST diventa quindi 206 e non 258
giusto?
Ciao,
il 1,29 deriva da un calcolo di tuttodigitale e l'ho preso per buono. Alla fine circa il +29% tra pd e xv non è poi così lontano visto che c'è di mezzo pure steamroller. Cmq quei valori del 845 non mi convincono poi così tanto anche se già si vede che carizzo è un passo avanti.
Nel secondo caso ci avevo pensato di fare come dici te ma non è coerente con l'interpretazione che ho dato io (molto estrema). Se dico che l'aumento del 40% si riferisce ad un modulo XV vs un core+smt zen viene da se che 1,40 non può essere dato da =x*1,50 perché verrebbe che l'IPC (la x) è pure sceso. In questo caso si ipotizza semplicemente che quel 40% è dato da un +15% e +20%. Da quello ricavo inversamente il valore di 1core/1th zen.
Ho modificato solo il prima caso che effettivamente, con l'osservazione di bjt2, si avvicina all'interpretazione più estrema del secondo caso;)
Mister D
24-02-2016, 11:45
Si! :D :cool:
Con mio grande rammarico non ho il tempo di scrivere per loro e mi dispiace tantissimo, non credo di poterlo fare neanche per Zen... :D
Il lavoro mi prende molto... Ho anche imparato a programmare le GPU... :sofico:
"Grande Giove!!" Cit.:sofico:
Dai, ci accontenteremo delle tue riflessioni/spiegazioni/illuminazioni in questo trhead:ave: :yeah:
Mister D
24-02-2016, 11:47
Il Power 8, per un SMT 8 è dato a ten issue e eight dispatch on 16 pipes. Dimezza tutto e per 4 thread, per avere la stessa efficienza di un POWER 8 (che è un MOSTRO, ricordiamolo), devi avere 5 issue (se non mi sbaglio sarebbe quello prodotto dai decoders), 4 dispatch e 8 pipes. Zen avrà 4 (o 6, se quello che dice il tipo del CERN è vero :sofico: ) issue, 4 dispatch e 10 pipes... Credo che si possa fare... Ma la mia era una provocazione... Un SMT4 può essere utile nell'HPC, ma nel desktop, visto che i core saranno già 8, penso di no... Anche se io li vorrei 4 thread per core... :D
Concordo con te che si potrebbe fare fin da subito (se fosse 6 vie) ma penso che si siano tenuti questa possibilità per Zen+. Da keller c'è da aspettarselo. Invece potrebbe essere che già su k12 (architettura arm by amd) siano già a SMT4 o anche 8;)
Grizlod®
24-02-2016, 12:24
Con mio grande rammarico non ho il tempo di scrivere per loro e mi dispiace tantissimo, non credo di poterlo fare neanche per Zen... :D
Il lavoro mi prende molto... Ho anche imparato a programmare le GPU... :sofico:Bentornato!
Immagino che gli esami per cui avevi lasciato il forum siano andati bene (notando pure la firma) :)
"Grande Giove!!" Cit.:sofico:
Dai, ci accontenteremo delle tue riflessioni/spiegazioni/illuminazioni in questo trhead:ave: :yeah:
Mi sono appassionato anche alle architetture delle GPU... :sofico: Abbiamo scritto vari paper dove analizziamo varie soluzioni implementative per sfruttare al massimo la GPU... Ho anche analizzato l'assembly... :sofico: Ma il nostro algoritmo è abbastanza semplice e siamo limitati dalla banda della cache L1...
Bentornato!
Immagino che gli esami per cui avevi lasciato il forum siano andati bene (notando pure la firma) :)
:)
Free Gordon
24-02-2016, 12:46
Mi sono appassionato anche alle architetture delle GPU... :sofico: Abbiamo scritto vari paper dove analizziamo varie soluzioni implementative per sfruttare al massimo la GPU... Ho anche analizzato l'assembly... :sofico: Ma il nostro algoritmo è abbastanza semplice e siamo limitati dalla banda della cache L1...:)
AMD o Nvidia?
AMD o Nvidia?
CUDA, purtroppo... Il framework è facilissimo da usare... Invece con OpenCL ti dovevi preoccupare tu di caricare il codice, compilarlo ecc... Invece ncc è un pre-processore che fa tutto lui e poi chiama il compilatore... Abbiamo una macchina con 2 GTX 690 e ho scritto una dll multithread e multi GPU da usare con Matlab...
Free Gordon
24-02-2016, 13:22
E' ora che AMD di svegli ad immettere sul mercato un framework tipo CUDA per sfruttare appieno le capacità delle APU presenti e future...e delle gpu di prossima gen che presumo saranno in grado di accedere alla memoria di sistema autonomamente..
tuttodigitale
24-02-2016, 13:24
Iscritto...
:yeah: :sbavvv:
Ho dato una lettura veloce e espongo di seguito le mie considerazioni... Scusatemi se sono già state fatte e me le sono perse...
Scuse accettate :D
Clock vs clock ZEN può fare 4ALU+2AGU+4FPU, mentre INTEL 4 tra ALU e FPU+2AGU, per limiti di porte.
In Haswell/skylake ci sono 4 alu+ 3 AGU, una delle quali è specializzata nello store. Questo potrebbe essere un vantaggio per Intel.
Terzo vantaggio AMD: INTEL può decodificare in burst di 4-1-1-1. Fuori da questo schema le cose si rallentano molto. Invece AMD può decodificare con 1-1-1-1, 2-2, 2-1-1, 1-1-2, 4.
Con skylake, Intel ha modificato il front-end, che ora è in grado di sparare fino a 6micro/ops, I decoder sono: 1 di tipo Complex e 4 Simple.
Devo riempirti di domande. Uomo avvisato :D
E' ora che AMD di svegli ad immettere sul mercato un framework tipo CUDA per sfruttare appieno le capacità delle APU presenti e future...e delle gpu di prossima gen che presumo saranno in grado di accedere alla memoria di sistema autonomamente..
Ma a basso livello CUDA è fatto esattamente come OpenCL... Solo che NVidia ha creato un programmino magico, ncc, Nvidia C Compiler che traduce ed espande delle direttive C e il codice shader direttamente dal C...
:yeah: :sbavvv:
Scuse accettate :D
In Haswell/skylake ci sono 4 alu+ 3 AGU, una delle quali è specializzata nello store. Questo potrebbe essere un vantaggio per Intel.
Con skylake, Intel ha modificato il front-end, che ora è in grado di sparare fino a 6micro/ops, I decoder sono: 1 di tipo Complex e 4 Simple.
Devo riempirti di domande. Uomo avvisato :D
Quindi non è più 4-1-1-1 ma 4-1-1-1-1 + una bonus data dalla uop fusion (CMP+Jxx)...
tuttodigitale
24-02-2016, 13:33
Quindi non è più 4-1-1-1 ma 4-1-1-1-1 + una bonus data dalla uop fusion (CMP+Jxx)...
Esattamente
Concordo con te che si potrebbe fare fin da subito (se fosse 6 vie) ma penso che si siano tenuti questa possibilità per Zen+. Da keller c'è da aspettarselo. Invece potrebbe essere che già su k12 (architettura arm by amd) siano già a SMT4 o anche 8;)
Ma anche con 4 vie eh! Penso che i decoder AMD accoppiati al codice x86 siano più espressivi del PowerPC... Ricordiamoci poi che c'è una cache L0 da 4KB... Non è detto che tutti e 4 i thread necessitino dei decoder a ogni ciclo... Anche se fosse, fai un roudrobin o se sei un pazzo li fai dual o quad pumped... In ogni caso con la cache L0 si spera che in ogni momento in media 1, max 2 thread richiedano i decoders...
marchigiano
24-02-2016, 13:48
bentornato bjt2 :)
ma i power-qualcosa non sono stati sempre meno efficienti degli xeon? ricordo una discussione simile ai tempi di bulldozer... che deja vu :eek: :eek:
tuttodigitale
24-02-2016, 14:12
Ciao,
il 1,29 deriva da un calcolo di tuttodigitale e l'ho preso per buono.
in un post successivo (non ditemi quale) avevo detto anche che avevo sbagliato (e di conseguenza corretti i grafici). A proposito in questi giorni grazie a "marchigiano" abbiamo valori piuttosto attendibili sulle prestazioni MT e ST di SR soprattutto nei confronti di PD, e per estensione permette di ridurre i margini di errore (vi ricordo che le prestazioni sono riferite a CB11.5). Il grafico nel MT è stato corretto un paio di giorni fa, Quello ST è leggermente ottimistico (2-3% la differenza).
Non mi prendo nessuna responsabilità dei tuoi valori :D
vi rimando ai grafici (http://www.hwupgrade.it/forum/showpost.php?p=43213591&postcount=101)
ma la L0 come mai non viene mai indicata? è già presente in skylake giusto?
onestamente è la prima volta che ne senso parlare :stordita:
Anche io ho scoperto pochi giorni fa che c'è una cache L0... E li nomina il 6 wide (probabilmente 4ALU+2AGU)... Ora me lo leggo meglio perchè avevo solo letto il riassunto su semiaccurate...
http://vrworld.com/2016/02/12/cern-confirms-amd-zen-high-end-specifications/
Un estratto:
ZEN High End ‘Exascale’ CPU, 1-4 Socket (1P-4P) – Specs As Per CERN
Multi-Chip Module (2×16-core)
32 ZEN x86 Core, 6-wide
128 KB L0 Cache (4KB per core)
2 MB L1 D-Cache (64KB per core)
2 MB L1 I-Cache (64 KB per core)
16 MB L2 Cache (512 KB per core)
64 MB L3 Cache (8MB cluster per quad unit)
576-bit Memory Controller (two times 4×72-bit, 64-bit + 8-bit ECC)
204.8 GB/s via DDR4-3200 (ECC Off, 102.4 GB/s per die)
170.6 GB/s via DDR4-2666 (ECC On, 85.3 GB/s per die)
ZEN High End Exascale APU, 1-2 Socket (1P-2P) – Rumored Specs From Fast Forward
16 ZEN x86 Core, 6-wide
64 KB L0 Cache (4KB per core)
1 MB L1 D-Cache (64KB per core)
1 MB L1 I-Cache (64 KB per core)
8 MB L2 Cache (512 KB per core)
No L3 Cache
288-bit CPU Memory Controller (4×72-bit, 64-bit + 8-bit ECC)
102.4 GB/s via DDR4-3200 (ECC Off)
85.3 GB/s via DDR4-2666 (ECC On)
102.4 GB/s between CPU and GPU via GMI
~2000-core Polaris GPU
2048-bit GPU Memory Controller
8 GB HBM2 SGRAM Memory (2 chips at 4GB)
512 GB/s GPU Bandwidth
george_p
24-02-2016, 14:22
Cosa intendente per 6 wide?
Cosa intendente per 6 wide?
Io credo che siano le 4 alu + le 2 agu... Ma non ne sono sicuro... Il processore dell'iPhone 6s è 6 wide issue ed ha 4 alu, 2 agu e 3 fpu.
Se 6 wide è 6 wide issue allora ha 6 decoder o un qualche accrocchio che consente di sparare fino a 6 MOP per ciclo... (ad esempio 3 double fast path decoder che possono sparare 6 mop o 3 mop per ciclo)... Se è 6 wide dispatch si riferisce alle 4alu+2agu... E' ambiguo...
tuttodigitale
24-02-2016, 14:30
Cosa intendente per 6 wide?
io, ma mi pare di capire anche BJT2, ho inteso che indichi il numero delle unità integer (4ALU+2AGU) e non ai decoder. Poi tutto può essere.
Mi confondo sempre tra issue e dispatch... Dispatch è quando escono dal decoder per andare in coda e issue e quando escono dalla coda per andare in esecuzione...
La confusione nasce dal fatto che per INTEL (e AMD) è così, ma per IBM è il contrario... :rolleyes:
george_p
24-02-2016, 14:47
Vi confondete voi, figurarsi io... non lo farò mai più :stordita:
Mister D
24-02-2016, 14:48
in un post successivo (non ditemi quale) avevo detto anche che avevo sbagliato (e di conseguenza corretti i grafici). A proposito in questi giorni grazie a "marchigiano" abbiamo valori piuttosto attendibili sulle prestazioni MT e ST di SR soprattutto nei confronti di PD, e per estensione permette di ridurre i margini di errore (vi ricordo che le prestazioni sono riferite a CB11.5). Il grafico nel MT è stato corretto un paio di giorni fa, Quello ST è leggermente ottimistico (2-3% la differenza).
Non mi prendo nessuna responsabilità dei tuoi valori :D
vi rimando ai grafici (http://www.hwupgrade.it/forum/showpost.php?p=43213591&postcount=101)
Ok perfetto:D
Quindi tra un core PD e uno XV alla fine avendo la preview del 845 cosa viene fuori? un 20%. Così aggiorno anche i miei calcoli e poi se vuoi utilizzarli nei grafici ben venga.;)
EDIT: ho visto il grafico ed il 15% (69/60). Vado a modificare il mio post.
tuttodigitale
24-02-2016, 14:49
ma la L0 come mai non viene mai indicata? è già presente in skylake giusto?
onestamente è la prima volta che ne senso parlare :stordita:
la L0, è la cache uop, e Intel ce l'ha dai tempi di Sandy Bridge ed è quella che permette di saltare tutta la fase di decodifica.
tuttodigitale
24-02-2016, 14:52
Ok perfetto:D
Quindi tra un core PD e uno XV alla fine avendo la preview del 845 cosa viene fuori? un 20%. Così aggiorno anche i miei calcoli e poi se vuoi utilizzarli nei grafici ben venga.;)
I valori oscillano tra i 20% e il 23% nel MT(prendendo come riferimento i test di di marchigiano, che ha un a10-6800k a 4,4GHz FISSI, salta fuori un +23,5%, nei grafici ho approssimato a 23.)
Nel ST circa il 13%.
Mister D
24-02-2016, 15:04
-REV1 per osservazioni bjt2- ->#1
-REV2 per dati da marchigiano e preview 845- ->#2
Confronto tra PD, XV e ZEN core a parità di frequenza (no turbo).
Valori di riferimento cb r15 Fx8350 ST 100 (4,2 GHz turbo) e MT 640 (4 GHz)
ST a 4 GHz di PD: 95
MT modulo PD: 95+95*0,80 = 171
Aumento percentuale da PD a XV: *1,15 #2
Aumento percentuale dichiarato da amd tra xv e core zen: *1,4
Fattore correttivo scaling non lineare in cb r15: 640/(171*4)= 0,935->*0,94
Aumento percentuale medio del SMT: *1,5 #1
Caso 1 #1#2
Il più verosimile perché applico l'aumento dichirato da amd alle prestazioni in cb r15 di un core XV e poi ricavo il valore MT applicando l'aumento percentuale del SMT del 50% al core XV.
Prima di tutto ricavo da 95*1,15=109 il valore di un core XV, poi il modulo XV 171*1,15=197 e infine core zen 1th 109*1,4=153 e il core zen 2th 153*1,50=230.
Gli altri valori verranno ricavati moltiplicando per il numero di core (moduli per PD e XV) e per il fattore correttivo.
------ST (1th)---MT (2th)---MT (8th)---MT (16th)
PD------95---------171--------640--------1280*
XV------109--------197--------741*------1481*
Zen-----153--------230--------865-------1730
Ora un ipotetico Zen 8c/16 th a 3,2 GHz Turbo_max_1core 4 GHz avrebbe in ST 153 e MT 2th 230 ma in MT 16th avrebbe 1730*3,2/4= 1384 punti. Questo valore mi pare verosimile con un buon lavora di amd senza miracoli.
Caso 2 #2
Il più aggressivo perché applico l'aumento dichirato da amd alle prestazioni in cb r15 di un modulo XV senza applicare il SMT che è così già incluso (1,4=1,15 IPC * 1,2 SMT medio) e poi ricavo inversamente il valore ST andando a dividere la parte di SMT.
Prima di tutto ricavo da 95*1,15=109 il valore di un core xv, poi il modulo xv 171*1,15=197 e infine core zen 2th 197*1,4=276 e il core zen 1th 276/1,20=230. Gli altri valori verranno ricavati moltiplicando per il numero di core (moduli per PD e XV) e per il fattore correttivo.
------ST (1th)---MT (2th)---MT (8th)---MT (16th)
PD------95---------171--------640--------1280*
XV------109--------197--------741*------1481*
Zen-----230--------276-------1038-------2076
Ora un ipotetico Zen 8c/16 th a 3,2 GHz Turbo_max_1core 4 GHz avrebbe in ST 230 e MT 2th 276 ma in MT 16th avrebbe 2076*3,2/4= 1661 punti. Questo valore mi pare meno probabile perché amd (Keller) avrebbe dovuto fare un vero miracolo (ci possiamo sperare ma attenzione a rimaner delusi).
Nota: i valori con gli asterischi corrispondono a cpu mai nate (PD con 8 moduli e XV con 4/8 moduli)
@tuttodigitale: se vuoi rifare i grafici puoi utilizzare questi valori aggiornati;)
EDIT: Lo so è un metodo un po' rozzo ma almeno sembrano delle tabelle LOL
Mister D
24-02-2016, 15:17
I valori oscillano tra i 20% e il 23% nel MT(prendendo come riferimento i test di di marchigiano, che ha un a10-6800k a 4,4GHz FISSI, salta fuori un +23,5%, nei grafici ho approssimato a 23.)
Nel ST circa il 13%.
Le ho visti dopo, solo che ora ti toccherà cambiare il caso 2 (mio caso 1) e caso 3 (mio caso 2) perché ho aggiornato usando la stima di bjt2 del smt e per i valori più precisi di incremento st tra PD e XV:sofico: Lo so mi vorrai un sacco di male:D
paolo.oliva2
24-02-2016, 15:23
Ciao Bjt2 :sofico:.
Ho letto i tuoi post (tecnici), ma compreso meglio le considerazioni, ovvio per le mie limitazioni.
Anche io sono della posizione che Zen non arriverà alla forza bruta di Intel, anche nella situazione favorevole di clock silicio.
Inoltre... mi sembra più che ovvio. Se Zen arrivasse alla potenza/core di Intel, non avrebbe senso arrivare fino ad un X32 (non ho capito se nativo) ma anche un X16 nativo. Se Zen X8 andasse tanto quanto un 5960X (ipotizzando 3,5GHz il clock def), si ridurrebbe la grandezza del die con tutto vantaggio del numero di die a wafer con ovvi guadagni superiori. La mossa di aumentare il numero di core mi sembra più una soluzione per ottenere più potenza MT.
Stesso discorso per l'SMT maggiore di 2TH a core. Fare un X32 e avere 4TH a core significherebbe 128TH... poi, credo, dovrebbe essere dimensionato a livello di cache differentemente. Cioè... anche se le cache sarebbero inclusive e più veloci, comunque dovrebbero avere pur sempre una certa quantità per ogni TH. Cioè, se Zem con SMT 2TH a core avesse X quantità di cache, con un SMT >2TH dovrebbe averne di più di cache.
Ciao Bjt2 :sofico:.
Ho letto i tuoi post (tecnici), ma compreso meglio le considerazioni, ovvio per le mie limitazioni.
Anche io sono della posizione che Zen non arriverà alla forza bruta di Intel, anche nella situazione favorevole di clock silicio.
Inoltre... mi sembra più che ovvio. Se Zen arrivasse alla potenza/core di Intel, non avrebbe senso arrivare fino ad un X32 (non ho capito se nativo) ma anche un X16 nativo. Se Zen X8 andasse tanto quanto un 5960X (ipotizzando 3,5GHz il clock def), si ridurrebbe la grandezza del die con tutto vantaggio del numero di die a wafer con ovvi guadagni superiori. La mossa di aumentare il numero di core mi sembra più una soluzione per ottenere più potenza MT.
Stesso discorso per l'SMT maggiore di 2TH a core. Fare un X32 e avere 4TH a core significherebbe 128TH... poi, credo, dovrebbe essere dimensionato a livello di cache differentemente. Cioè... anche se le cache sarebbero inclusive e più veloci, comunque dovrebbero avere pur sempre una certa quantità per ogni TH. Cioè, se Zem con SMT 2TH a core avesse X quantità di cache, con un SMT >2TH dovrebbe averne di più di cache.
Bulldozer aveva 16KB di cache L1 dati... Zen ne avrà 64... E alcuni dati sono in comune (pensa al sistema operativo)...
Mister D
24-02-2016, 16:08
non c'entra o forse si con Zen, ma dai risultati viene fuori che un XV 16c a 3.2ghz farebbe 1185p al cinebench r15 (1481p*3.2/4 ghz) :eek: ovvero il -13% di un 5960x che fa 1337p a 3ghz...
ok magari in AMD hanno pensato che non c'era tempo e risorse per farlo, ma 4, 6 e 8 moduli XV avrebbero fatto fare ad amd un bel balzo avanti almeno sul MT e sempre a 28nm...
ecco perché dico che c'entra con Zen: se già XV sarebbe competitivo a 28nm+HDL in MT thread to thread vs 22nm, non vedo perchè Zen a 14nm debba esserlo da meno vs 14nm Intel quando l'intento principale è quello di aumentare l'IPC del 40% ;)
Appunto. Non l'hanno fatto perché non era economicamente remunerativo, nuove maschere, nuovo debug, nuova linea a 28 per gli fx a cui andava aggiunta una l3. Però se si pensa dove sarebbero arrivati con XV e lo si aggiunge alle dichiarazioni di amd (+40%) mi pare ovvio che Zen sia di altra pasta rispetto al primo buldozer. Sempre che poi siano vere le dichiarazioni del +40% e che i 14 nm non facciano schifo a frequenze tanto da mangiarsi il vantaggio di ipc.;)
Bulldozer aveva 16KB di cache L1 dati... Zen ne avrà 64... E alcuni dati sono in comune (pensa al sistema operativo)...
dresdenboy aveva indicato 32kb(8w) come l1d...:confused:
ps. il tizio del cern parla solo della slide, da dove escono quei numeri ?
Io credo che siano le 4 alu + le 2 agu... Ma non ne sono sicuro... Il processore dell'iPhone 6s è 6 wide issue ed ha 4 alu, 2 agu e 3 fpu.
Se 6 wide è 6 wide issue allora ha 6 decoder o un qualche accrocchio che consente di sparare fino a 6 MOP per ciclo... (ad esempio 3 double fast path decoder che possono sparare 6 mop o 3 mop per ciclo)... Se è 6 wide dispatch si riferisce alle 4alu+2agu... E' ambiguo...
Amd non ha mai abbandonato i decoderx86 MacroOP, ma per sua stessa ammissione(bobcat) meno del 10% del codice si trasforma in 2op.
Forse l'ambiguità nasce dalla versione ARM che adotta decoder diversi...
Radeon80
24-02-2016, 17:15
Bentornato Bjt2.
Rileggere di nuovo i tuoi post sulle caratteristiche architetturali dei vari core x86 AMD e Intel mi fa un grande piacere :)
capitan_crasy
24-02-2016, 17:31
Visto solo ora il thread...
Iscritto...
CUT
Ciao bjt2...
Mi sei mancato...:cry:
Volevo fare un GIF tutta nuova per il tuo ritorno ma purtroppo il mio vecchio corel photo paint è diventato incompatibile con WIN 8 da un giorno all'altro...
Comunque noi non ci siamo dimenticati di te e se ogni tanto ti fai vedere su questo thread (anche se hai poco tempo) ne saremo felici...
Questo post qua sotto è/era dedicato a te.:)
Clicca qui... (http://www.hwupgrade.it/forum/showpost.php?p=42429619&postcount=14562)
dresdenboy aveva indicato 32kb(8w) come l1d...:confused:
ps. il tizio del cern parla solo della slide, da dove escono quei numeri ?
Beh, nel link che ho riportato sopra è specificato 4+64+64+512 di cache L0, L1D, L1I, L2 per core... Immagino loro abbiano le specifiche direttamente da AMD...
Amd non ha mai abbandonato i decoderx86 MacroOP, ma per sua stessa ammissione(bobcat) meno del 10% del codice si trasforma in 2op.
Forse l'ambiguità nasce dalla versione ARM che adotta decoder diversi...
In effetti ho scritto anche io sopra che le unità RISC dei core AMD sono veramente potenti e questo è uno dei vantaggi rispetto ad INTEL. Sicuramente le AVX a 256 bit e le FMA avranno almeno 2 MOP. Ma per la maggior parte delle altre una sola MOP basta visto che una MOP può fare lettura (con AGU), esecuzione e scrittura e avere fino a 4 operandi. E nonostante le fastpath double siano relativamente rare, AMD le ha sempre supportate senza rallentamenti a partire dai K7... Invece INTEL... 4-1-1-1(-1)(+uop fusion) e guai a sgarrare... Oltre a unità RISC molto più loffie...
Bentornato Bjt2.
Rileggere di nuovo i tuoi post sulle caratteristiche architetturali dei vari core x86 AMD e Intel mi fa un grande piacere :)
Grazie... :)
Ciao bjt2...
Mi sei mancato...:cry:
Volevo fare un GIF tutta nuova per il tuo ritorno ma purtroppo il mio vecchio corel photo paint è diventato incompatibile con WIN 8 da un giorno all'altro...
Comunque noi non ci siamo dimenticati di te e se ogni tanto ti fai vedere su questo thread (anche se hai poco tempo) ne saremo felici...
Questo post qua sotto è/era dedicato a te.:)
Clicca qui... (http://www.hwupgrade.it/forum/showpost.php?p=42429619&postcount=14562)
Grazie... :) Bellissime immagini... Sono onorato!
Ho messo questo thread nei preferiti, come quello di semiaccurate...
Avevo sempre (ed ho ancora) l'iscrizione agli altri thread e ogni tanto gli davo una occhiata ma oltre alla depressione per le scarse prestazioni, mi mancava il tempo... Ora da casa ho risolto con internet (tethering su cellulare... ADSL manco a parlarne) e quindi posso essere un po' più presente...
E poi Zen mi intriga e come quando uscì Bulldozer, sono fiducioso...
La cache inclusiva, la cache L0, il nuovo branch predictor, i vari brevetti sulla cache, l'SMT e un motore RISC a 10 vie mi fanno sperare per il meglio... Se poi il processo FinFET dovesse essere anche buono, come sembra...:sofico:
tuttodigitale
24-02-2016, 17:49
ma è mai saltato fuori dalle review? e bulldozer e derivati non ce l'hanno... anche qua Zen ne trarrà beneficio
su hwupgrade, no se puoi interessarti...
Visto che si parla di L0, approfondisco il funzionamento della cache uop di Intel (tieni a mente che le mie competenze sono lontanissime da quelle di bjt2).
Parto dai vantaggi, già espressi dal nostro B. keller :cool:
La cache uop permette di ridurre il consumo di energia, e permette di ridurre la penalità da miss-prediction (i due fatti sono collegati tra loro). Il percorso della pipeline diventa lungo solo 14 stadi in caso di hit nella cache uop. E a dispetto delle piccolissime dimensioni (1,5KB per SB), la cache ha il dato che serve per 80% del tempo.
Partiamo dal front-end, ma questa volta parliamo di skylake (ZEN deve fargli il :sofico: ) in effetti dalle review sembra un oggetto oscuro, quasi per caso si scopre che è stato modificato nel front-end e tanto:
i decoder sono 4-1-1-1-1. Chiariamo subito il significato di questi numeri. Vuol dire che ci sono 5 decoder: 1 in grado di decodificare istruzioni complesse che emettono fino a 4 uops, 4 decodificano le istruzioni più semplici.
Qualcuno potrebbe pensare che il potere di decodificata data dai soli decoder sia pari a 4+1+1+1+1, per un totale di 8 uops/cycle. Sbagliato. In skylake i decoder possono emettere al massimo "solo" 5 uops/cycle.
Un altro punto, ma che non è di vantaggio (quelle di AMD sono già macro op), è quello di fondere due uops insieme. (ma su questo ci torneremo su se vi interessa ovviamente)
Allora è una bugia che un 6-wide. NO. C'entrerà qualcosa la cache uop? :read:
In parole povere (anche perchè molto di più non so :) ), una volta che le istruzioni vengono decodificate, le microops (massimo 5) vengono inviate alla cache L0 (non a caso prende il nome di cache UOP) e al back-end per l'allocazione, rename e esecuzione OoO
La successiva istruzione di fetch il più delle volte va a colpire la L0 (nel senso che si trova la).
La cache UOP è in grado di emettere 6uops/cycle (contro i 4 di haswell), ampliando di fatto la dimensione del front-end, ed è di fatto un 6-wide issue.
Ora credo (e spero), che il post interessantissimo di BJT, sia un poco più chiaro per quel che riguarda il confronto dei decoder di Piledriver (ZEN?) e Haswell.
Perchè non si può mettere mi piace ai post?:cry: :cry: :cry:
Sono troppo drogato di FB...
tuttodigitale
24-02-2016, 18:33
Posto lo schema (ci ho messo una vita per trovarlo :D ).
http://pc.watch.impress.co.jp/img/pcw/docs/724/408/06.png
Mister D
24-02-2016, 19:37
Posto lo schema (ci ho messo una vita per trovarlo :D ).
http://pc.watch.impress.co.jp/img/pcw/docs/724/408/06.png
Che poi non è per avercela con intel, ma tutto questo ben di dio e poi, vedi anadtech, l'aumento dell'ipc tra haswell e skylake è un misero 6%. Estica@@i:D
tuttodigitale
24-02-2016, 19:42
Che poi non è per avercela con intel, ma tutto questo ben di dio e poi, vedi anadtech, l'aumento dell'ipc tra haswell e skylake è un misero 6%. Estica@@i:D
Se ci pensi, è la stessa identica storia di conroe, che aveva un super front-end e poi abbiamo visto a cosa serviva. Intel ha partorito il mostro: NEHALEM.
Il front-end di Skylake è "pronto" per il SMT4, probabilmente stanno solo aspettando un die shrink per aumentare un poco le risorse del back-end..
aggiungo una cosa, Intel ha effettuato una modifica all'IDQ (Allocation Queue nella figura) gestisce i 2 thread i maniera unificata: da una soluzione 2x28uops in haswell si è passato ad una soluzione 1x64 uops in Skylake. Un passo nella direzione SMT4 (ovviamente sono mie speculazione e valgono zero, ma tantè).
Tuttodigitale lo escludeva sia per via delle porte comunque limitate che del decoders 4-wide (come haswell), anche se il tipo del Cern nell'ultima conferenza ha indicato che Zen sarà 6-wide decoders (come skylake) :fagiano:
Quando ho saputo che ZEN avrebbe avuto 10 porte di esecuzione io insieme a Paolo.Oliva abbiamo pensato subito al SMT4, o al limite ad una sorta di ibrido CMT+SMT. ...
10 porte sono tante, se Intel con SB ne aveva solo 6, quindi ce ne sarebbero in abbondanza. Sarebbe stato (ed è) un peccato limitarsi ad un semplice smt2.
Sulla decodifica, i dubbi c'erano e rimangono. Fermo restando la maggior flessibilità dei decoder AMD, e la maggior potenza espressiva delle macro-ops, mi sembrano insufficienti per alimentare 4 thread.
Mister D
24-02-2016, 19:58
Se ci pensi, è la stessa identica storia di conroe, che aveva un super front-end e poi abbiamo visto a cosa serviva. Intel ha partorito il mostro: NEHALEM.
Il front-end di Skylake è pronto per il SMT4, probabilmente stanno solo aspettando un die shrink per aumentare un poco le risorse del back-end..
cut..
Sì hai ragione però hanno già annunciato solo kabylake sempre a 14 nm invece che cannolake a 10 nm cannolake non dovrebbe portare rivoluzioni sull'architettura visto che è un tick anche se ormai è cambiata in un
tick-tock-tock+.
In pratica userebbero questo ben di dio solo dal successore di cannolake? Vedremo, chissà che non mettano già in kabylake il smt4 perché forse temono Zen? Chissà ..... (sto creando hype per nulla ah ah che diabolico che sono :sofico: )
tuttodigitale
24-02-2016, 20:16
Anche per Nehalem, hanno aspettato il tick di Conroe sui 45nm (ha debuttato con i 65nm). La storia potrebbe ripetersi.
Sui rumors di Intel non so niente. :D
Free Gordon
25-02-2016, 00:49
Ma a basso livello CUDA è fatto esattamente come OpenCL... Solo che NVidia ha creato un programmino magico, ncc, Nvidia C Compiler che traduce ed espande delle direttive C e il codice shader direttamente dal C...
Figata! :eek:
Figata! :eek:
E ti dirò di più... I kernel che gireranno su GPU li scrivi in normalissimo C, così:
__global__ void questoeunkernel(...)
{
...
}
All'interno di un kernel puoi usare funzioni speciali, come __syncthreads() per sincronizzare tutti i kernel, __shared__ per dichiarare variabili da allocare nel pool condiviso e poi ci sono le variabili per sapere in quale blocco e thread ti trovi...
Per lanciare un kernel la chiamata di funzione è stata leggermente modificata:
questoeunkernel <<<numeroblocchi,numerothreadperblocchi>>> (...);
Questa sintassi poi viene tradotta a basso livello nella compilazione del codice GPU, nel caricamento sulla GPU e nell'esecuzione...
Per le funzioni di servizio, come di inizializzazione, sincronizzazione spostamento dati da e per la GPU ci sono normali procedure di libreria.
ncc traduce quello che gli compete e poi per il normale codice C chiama un compilatore C supportato. Su linux è supportato gcc e su windows il compilatore microsoft e quello INTEL. Quello ms si può anche installare senza visualstudio... Si scarica un file da 120MB che contiene i due compilatori a 32 e 64 bit... Io ho usato quello a 64 bit per fare una dll a 64 bit perchè uso Matlab a 64 bit...
Tramite parametri da riga di comando è possibile far creare l'assembly dei kernel dentro i file.
Questo è un estratto...
.entry _Z14gpu_nlm_filterPfS_S_fffiiiiiiiiiifiii (
.param .u64 __cudaparm__Z14gpu_nlm_filterPfS_S_fffiiiiiiiiiifiii_d_img,
.param .u64 __cudaparm__Z14gpu_nlm_filterPfS_S_fffiiiiiiiiiifiii_d_means,
.param .u64 __cudaparm__Z14gpu_nlm_filterPfS_S_fffiiiiiiiiiifiii_d_output,
.param .f32 __cudaparm__Z14gpu_nlm_filterPfS_S_fffiiiiiiiiiifiii_Ni,
.param .f32 __cudaparm__Z14gpu_nlm_filterPfS_S_fffiiiiiiiiiifiii_beta,
.param .f32 __cudaparm__Z14gpu_nlm_filterPfS_S_fffiiiiiiiiiifiii_std_dev,
.param .s32 __cudaparm__Z14gpu_nlm_filterPfS_S_fffiiiiiiiiiifiii_rice,
.param .s32 __cudaparm__Z14gpu_nlm_filterPfS_S_fffiiiiiiiiiifiii_d_x,
.param .s32 __cudaparm__Z14gpu_nlm_filterPfS_S_fffiiiiiiiiiifiii_d_y,
.param .s32 __cudaparm__Z14gpu_nlm_filterPfS_S_fffiiiiiiiiiifiii_d_z,
.param .s32 __cudaparm__Z14gpu_nlm_filterPfS_S_fffiiiiiiiiiifiii_M_x,
.param .s32 __cudaparm__Z14gpu_nlm_filterPfS_S_fffiiiiiiiiiifiii_M_y,
.param .s32 __cudaparm__Z14gpu_nlm_filterPfS_S_fffiiiiiiiiiifiii_M_z,
.param .s32 __cudaparm__Z14gpu_nlm_filterPfS_S_fffiiiiiiiiiifiii_s0,
.param .s32 __cudaparm__Z14gpu_nlm_filterPfS_S_fffiiiiiiiiiifiii_s1,
.param .s32 __cudaparm__Z14gpu_nlm_filterPfS_S_fffiiiiiiiiiifiii_s2,
.param .f32 __cudaparm__Z14gpu_nlm_filterPfS_S_fffiiiiiiiiiifiii_mean_tresh,
.param .s32 __cudaparm__Z14gpu_nlm_filterPfS_S_fffiiiiiiiiiifiii_K0,
.param .s32 __cudaparm__Z14gpu_nlm_filterPfS_S_fffiiiiiiiiiifiii_KN,
.param .s32 __cudaparm__Z14gpu_nlm_filterPfS_S_fffiiiiiiiiiifiii_K)
{
.reg .u16 %rh<6>;
.reg .u32 %r<97>;
.reg .u64 %rd<16>;
.reg .f32 %f<48>;
.reg .f64 %fd<13>;
.reg .pred %p<24>;
.loc 15 350 0
$LDWbegin__Z14gpu_nlm_filterPfS_S_fffiiiiiiiiiifiii:
ld.param.s32 %r1, [__cudaparm__Z14gpu_nlm_filterPfS_S_fffiiiiiiiiiifiii_M_x];
ld.param.s32 %r2, [__cudaparm__Z14gpu_nlm_filterPfS_S_fffiiiiiiiiiifiii_d_x];
add.s32 %r3, %r1, %r2;
mov.u16 %rh1, %ctaid.x;
mov.u16 %rh2, %ntid.x;
mul.wide.u16 %r4, %rh1, %rh2;
cvt.u32.u16 %r5, %tid.x;
add.u32 %r6, %r5, %r4;
setp.gt.s32 %p1, %r3, %r6;
@%p1 bra $Lt_0_22274;
ld.param.s32 %r7, [__cudaparm__Z14gpu_nlm_filterPfS_S_fffiiiiiiiiiifiii_s0];
sub.s32 %r8, %r7, %r3;
setp.ge.s32 %p2, %r6, %r8;
@%p2 bra $Lt_0_22274;
ld.param.s32 %r9, [__cudaparm__Z14gpu_nlm_filterPfS_S_fffiiiiiiiiiifiii_M_y];
ld.param.s32 %r10, [__cudaparm__Z14gpu_nlm_filterPfS_S_fffiiiiiiiiiifiii_d_y];
add.s32 %r11, %r9, %r10;
mov.u16 %rh3, %ctaid.y;
mov.u16 %rh4, %ntid.y;
mul.wide.u16 %r12, %rh3, %rh4;
cvt.u32.u16 %r13, %tid.y;
add.u32 %r14, %r13, %r12;
setp.gt.s32 %p3, %r11, %r14;
@%p3 bra $Lt_0_22274;
ld.param.s32 %r15, [__cudaparm__Z14gpu_nlm_filterPfS_S_fffiiiiiiiiiifiii_s1];
sub.s32 %r16, %r15, %r11;
setp.ge.s32 %p4, %r14, %r16;
@%p4 bra $Lt_0_22274;
...
tuttodigitale
25-02-2016, 07:10
Ulteriori approfondimenti, nel limite delle mie conoscenze, sulla decodifica.
Prima di iniziaiare il nostro viaggio, lngo ma certamente non approfondito, bisogna distinguere tra RISC e CISC
RISC vs CISC: 2 scuole di pensiero
RISC è l'acronimo di Reduced Instruction Set Computer
CRISC è l'acronimo di Complex Instruction Set Computer, che semplicemente sta a significare che una CPU Risc (vedi ARM) ha un set i isruzione ridotto (chi l'avrebbe detto :D ) rispetto ad una CISC (vedi x86).
La prima notevole differenza, è il fatto che il campo operativo di una istruzione RISC ha le dimensioni prestabilite, anche a costo di generare codice meno compatto di un corrispettivo CISC.
Il risultato di questa soluzione tecnica, è che sono richiesti un numero ridotti di formati per rappresentare le istruzioni. Molto più facili da ricordare e imparare.
Di norma, quello che è semplice per noi lo è anche per il corrispettivo elettronico (fonte di questa sciocchezza? IO :cool: ). Non dovendo più stabilire le dimensioni delle lunghezze delle istruzioni x86, che variano da 1 a 15byte (!) e relativi campi delle istruzioni x86, hanno un compito meno gravoso che si traduce in risparmi di transistor e corrente.
Per paragone, le istruzioni ARM possono avere una lunghezza di 16 o 32 bit (2-4 byte). In origine erano solo a 32bit.
Ovviamente questa semplicità si paga, in quello che in gergo viene chiamata espressività delle singole istruzioni.
Le CPU RISC prima di poter elaborare i dati (pensiamo ad un'istruzione di somma, ADD) questi devono trovarsi nei registri.
Questo vincolo è rilassato, dalla maggior potenza dell'isa CISC, le cui istruzioni possono accedere ai dati contenuti nei registri e alle memorie in modo indifferente. Questo non vuol dire che i CISC possono operare tranquillamente sulla RAM di sistema, in ballo ci sono le prestazioni e l'efficienza.
MICRO-OPS: quando il CISC si crede un RISC
Abbiamo discusso tanto di decoder, ma ora visceriamo il prodotto delle loro "elaborazioni".
A fine di aumentare le prestazioni e l'efficienza delle CPU RISC, queste hanno iniziato a lavorare internamente come CPU RISC.
In altre parole le complesse istruzioni x86 sono state decomposte in istruzioni di tipo RISC.
Ci sono ragioni tecniche, indirizzate a massimizzate il ILP, ovvero la maggior facilità di riempire le numerose unità esecutive delle cpu superscalari analizzando molte istruzioni semplici che poche ma complesse (detto terra terra :) ).
Qui esiste una sostanziale differenza tra Intel e AMD, che spiegherò nel seguito (questo post servirebbe a questo :Prrr: )
Parto per semplicità con le CPU INTEL (:confused: ).
Dai decoder delle CPU INTEL, escono micro-ops (uops). Come detto nei post precedenti, ci sono decoder semplici e complessi, ovvero capaci di decodificare istruzioni x86 semplici (che forniscono una sola uops) e quelli che decodificano istruzioni x86 complesse (fino a 4uop).
2 micro-ops, possono essere sostituite (fuse) da una singola micro-ops. Questa tecnica prende il nome di MICRO-OPS FUSION (chi l'avrebbe detto?:ciapet: ).
Le 2 uops sono trattate come una, e si ha un effettivo aumento della larghezza della cpu.
MACRO-OPS: il ritorno alle CPU CISC
Le CPu x86 si sono evolute basandosi su nuclei RISC ad alte prestazioni, pur mantenendo l'ISA di tipo CISC, e quindi la compatibilità software.
Tuttavia, si scopre che alcune istruzioni x86 non dovrebbero essere suddivise in piccole uops, perchè il loro numero rischia di aumentare eccessivamente.
Con conroe sono "ritornate" le istruzioni x86.
Le istruzioni che sono nel formato di tipo load-op-store o load-op-execution sono trattate come uniche uop.
In altre parole se si dispone di un istruzione che consente di caricare i dati, operare sui dati e memorizza il risultato, viene trattata come un'unica uops invece di 3.
MACRO-OPS FUSION: quando il CISC non basta.
Vi starete chiedendo a questo punto :ciapet: "se determinate istruzione x86 producono una sola uops, probabilmente ci sarà la possibilità di contenere due istruzioni x86 in una sola uops?" Certo che si :cool:
I decoder di Conroe (e ovviamente di tutte le altre CPU successive di Intel fino ad Haswell) sono in grado di leggere fino a 5 istruzioni x86 per ciclo di clock per mezzo (indovinate un pò?) delle MACRO-OPS FUSION.
In media, per ogni 10 istruzioni x86, 2 vengono fuse insieme(ad esempio si fonde l'istruzione di confronto con il salto)
Quando 2 istruzioni sono fuse insieme, l'istruzione che si forma viaggia lungo la pipeline, portando ai vantaggi quali maggior larghezza di banda di decodifica, meno spazio occupato dalla IDQ (allocation Queue) e minor overhead.
Da solo il macro-ops fusion, dovrebbe essere l'artefice di circa il 10% di ipc delle architetture Intel.
MACRO-OPS AMD: le differenze
Finalmente parliamo di AMD :D
In bulldozer (ZEN?) i decoder sono 4 e hanno tasso di decodifica di 4 macro-ops.
Attenzione, Intel e AMD, usano lo stesso nome per identificare 2 cose diverse. E' facile cadere in erroee confondersi.
Per Intel se avete letto i paragrafi precedenti(?), si intendono le istruzioni x86.
Per AMD le MACRO-OPS, sono istruzioni RISC like, che sono il risultato della codifica di una istruzione x86. Rispetto alle uops, hanno una potenza espressiva maggiore.
Le macro-ops vengono splittate in micro-ops prima che vengono date in pasto alle unità esecutive.
ANche in AMD, esistono le Macro-ops FUSION, introdotte con BD. Ma a differenza di quelle Intel, la fusione viene fatta dopo la decodifica e in questo caso non si ha un aumento del numero di istruzioni decodificabili.
Ma come detto da BJT2, il tasso maggiore è parte penalizzato dal fatto di essere vincolato alla forma 4-1-1-1-1.
MACRO OPS e MICRO OPS nel mondo reale
Tutti bei discorsi (spero). Ma alla fine quanto sono determinanti le differenze tra micro e macro-ops (per quello dobbiamo rompere le scatole a bjt2 :cool: )
in parte ci viene in aiuto Intel
http://techreport.com/r.x/centrino-atom/instruction-type-mix.gif
dice, che ben il 96% di tutte le istruzioni sono singole uops.
Il vantaggio delle macro-ops è più teorico che pratico o sbaglio.
Free Gordon
25-02-2016, 08:29
E ti dirò di più... I kernel che gireranno su GPU li scrivi in normalissimo C, così:
__global__ void questoeunkernel(...)
{
...
}
All'interno di un kernel puoi usare funzioni speciali, come __syncthreads() per sincronizzare tutti i kernel, __shared__ per dichiarare variabili da allocare nel pool condiviso e poi ci sono le variabili per sapere in quale blocco e thread ti trovi...
Per lanciare un kernel la chiamata di funzione è stata leggermente modificata:
questoeunkernel <<<numeroblocchi,numerothreadperblocchi>>> (...);
Questa sintassi poi viene tradotta a basso livello nella compilazione del codice GPU, nel caricamento sulla GPU e nell'esecuzione...
Questo è davvero un grosso vantaggio per Nvidia...
AMD deve lavorare molto su un compiler simile perché sennò le sue architetture...seppur magari buonissime a svolgere un certo tipo di lavori non verrà in realtà mai preso in considerazione... :rolleyes:
Free Gordon
25-02-2016, 08:30
Ulteriori approfondimenti, nel limite delle mie conoscenze, sulla decodifica.
Grazie mille per l'esauriente spiegazione. :cool:
Mister D
25-02-2016, 08:44
Questo è davvero un grosso vantaggio per Nvidia...
AMD deve lavorare molto su un compiler simile perché sennò le sue architetture...seppur magari buonissime a svolgere un certo tipo di lavori non verrà in realtà mai preso in considerazione... :rolleyes:
Infatti per semplificare amd ha introdotto un traduttore da cuda verso hsa, così puoi prendere lavoro già fatto più facilmente con cuda e trasformarlo in hsa. Chiaro detto così è semplice, poi bisogna vedere come funziona la traduzione e la qualità della stessa. Potrebbe provare bjt2 e dirci come va;)
Ulteriori approfondimenti, nel limite delle mie conoscenze, sulla decodifica.
...CUT...
Un solo appunto. INTEL usa il microcodice per qualsiasi istruzione che non sia di una sola uop. Esistono istruzioni con anche 200 e oltre uops... Quel 4 che si legge è il numero massimo di uop per ciclo che possono essere emesse dal decoder. INTEL può decodificare fino a 4(5) uop per ciclo. 4 se sono tutte semplici oppure 4 per una istruzione microcodificata, fino all'esaurimento delle uop. Per AMD anche succede una cosa simile: se c'è una istruzione microcodificata il decoder si mette a lavorare solo su quella. Ma per AMD quelle microcodificate sono MOLTO di meno, perchè solo quelle con 3 o più MOPS lo sono. Considerando che le MOPS sono più potenti delle uops, c'è un doppio vantaggio...
Questo è anche uno dei motivi per cui INTEL è costretta ad avere unita molto grosse: se vuole implementare AVX 256 deve per forza avere unità a 256 bit. Perchè se ha unità a 128 bit, le istruzioni devono essere di ALMENO 2 uops e quindi microcodificate, bloccando la simultanea decodifica di altre istruzioni.
E' probabile che AMD abbia trattato il caso speciale di istruzioni a 2 uops proprio per poter implementare le estensioni con unità di larghezza dimezzata...
Mister D
25-02-2016, 08:53
Ulteriori approfondimenti, nel limite delle mie conoscenze, sulla decodifica.
Prima di iniziaiare il nostro viaggio, lngo ma certamente non approfondito, bisogna distinguere tra RISC e CISC
RISC vs CISC: 2 scuole di pensiero
RISC è l'acronimo di Reduced Instruction Set Computer
CRISC è l'acronimo di Complex Instruction Set Computer, che semplicemente sta a significare che una CPU Risc (vedi ARM) ha un set i isruzione ridotto (chi l'avrebbe detto :D ) rispetto ad una CISC (vedi x86).
La prima notevole differenza, è il fatto che il campo operativo di una istruzione RISC ha le dimensioni prestabilite, anche a costo di generare codice meno compatto di un corrispettivo CISC.
Il risultato di questa soluzione tecnica, è che sono richiesti un numero ridotti di formati per rappresentare le istruzioni. Molto più facili da ricordare e imparare.
Di norma, quello che è semplice per noi lo è anche per il corrispettivo elettronico (fonte di questa sciocchezza? IO :cool: ). Non dovendo più stabilire le dimensioni delle lunghezze delle istruzioni x86, che variano da 1 a 15byte (!) e relativi campi delle istruzioni x86, hanno un compito meno gravoso che si traduce in risparmi di transistor e corrente.
Per paragone, le istruzioni ARM possono avere una lunghezza di 16 o 32 bit (2-4 byte). In origine erano solo a 32bit.
Ovviamente questa semplicità si paga, in quello che in gergo viene chiamata espressività delle singole istruzioni.
Le CPU RISC prima di poter elaborare i dati (pensiamo ad un'istruzione di somma, ADD) questi devono trovarsi nei registri.
Questo vincolo è rilassato, dalla maggior potenza dell'isa CISC, le cui istruzioni possono accedere ai dati contenuti nei registri e alle memorie in modo indifferente. Questo non vuol dire che i CISC possono operare tranquillamente sulla RAM di sistema, in ballo ci sono le prestazioni e l'efficienza.
MICRO-OPS: quando il CISC si crede un RISC
Abbiamo discusso tanto di decoder, ma ora visceriamo il prodotto delle loro "elaborazioni".
A fine di aumentare le prestazioni e l'efficienza delle CPU RISC, queste hanno iniziato a lavorare internamente come CPU RISC.
In altre parole le complesse istruzioni x86 sono state decomposte in istruzioni di tipo RISC.
Ci sono ragioni tecniche, indirizzate a massimizzate il ILP, ovvero la maggior facilità di riempire le numerose unità esecutive delle cpu superscalari analizzando molte istruzioni semplici che poche ma complesse (detto terra terra :) ).
Qui esiste una sostanziale differenza tra Intel e AMD, che spiegherò nel seguito (questo post servirebbe a questo :Prrr: )
Parto per semplicità con le CPU INTEL (:confused: ).
Dai decoder delle CPU INTEL, escono micro-ops (uops). Come detto nei post precedenti, ci sono decoder semplici e complessi, ovvero capaci di decodificare istruzioni x86 semplici (che forniscono una sola uops) e quelli che decodificano istruzioni x86 complesse (fino a 4uop).
2 micro-ops, possono essere sostituite (fuse) da una singola micro-ops. Questa tecnica prende il nome di MICRO-OPS FUSION (chi l'avrebbe detto?:ciapet: ).
Le 2 uops sono trattate come una, e si ha un effettivo aumento della larghezza della cpu.
MACRO-OPS: il ritorno alle CPU CISC
Le CPu x86 si sono evolute basandosi su nuclei RISC ad alte prestazioni, pur mantenendo l'ISA di tipo CISC, e quindi la compatibilità software.
Tuttavia, si scopre che alcune istruzioni x86 non dovrebbero essere suddivise in piccole uops, perchè il loro numero rischia di aumentare eccessivamente.
Con conroe sono "ritornate" le istruzioni x86.
Le istruzioni che sono nel formato di tipo load-op-store o load-op-execution sono trattate come uniche uop.
In altre parole se si dispone di un istruzione che consente di caricare i dati, operare sui dati e memorizza il risultato, viene trattata come un'unica uops invece di 3.
MACRO-OPS FUSION: quando il CISC non basta.
Vi starete chiedendo a questo punto :ciapet: "se determinate istruzione x86 producono una sola uops, probabilmente ci sarà la possibilità di contenere due istruzioni x86 in una sola uops?" Certo che si :cool:
I decoder di Conroe (e ovviamente di tutte le altre CPU successive di Intel fino ad Haswell) sono in grado di leggere fino a 5 istruzioni x86 per ciclo di clock per mezzo (indovinate un pò?) delle MACRO-OPS FUSION.
In media, per ogni 10 istruzioni x86, 2 vengono fuse insieme(ad esempio si fonde l'istruzione di confronto con il salto)
Quando 2 istruzioni sono fuse insieme, l'istruzione che si forma viaggia lungo la pipeline, portando ai vantaggi quali maggior larghezza di banda di decodifica, meno spazio occupato dalla IDQ (allocation Queue) e minor overhead.
Da solo il macro-ops fusion, dovrebbe essere l'artefice di circa il 10% di ipc delle architetture Intel.
MACRO-OPS AMD: le differenze
Finalmente parliamo di AMD :D
In bulldozer (ZEN?) i decoder sono 4 e hanno tasso di decodifica di 4 macro-ops.
Attenzione, Intel e AMD, usano lo stesso nome per identificare 2 cose diverse. E' facile cadere in erroee confondersi.
Per Intel se avete letto i paragrafi precedenti(?), si intendono le istruzioni x86.
Per AMD le MACRO-OPS, sono istruzioni RISC like, che sono il risultato della codifica di una istruzione x86. Rispetto alle uops, hanno una potenza espressiva maggiore.
Le macro-ops vengono splittate in micro-ops prima che vengono date in pasto alle unità esecutive.
ANche in AMD, esistono le Macro-ops FUSION, introdotte con BD. Ma a differenza di quelle Intel, la fusione viene fatta dopo la decodifica e in questo caso non si ha un aumento del numero di istruzioni decodificabili.
Ma come detto da BJT2, il tasso maggiore è parte penalizzato dal fatto di essere vincolato alla forma 4-1-1-1-1.
MACRO OPS e MICRO OPS nel mondo reale
Tutti bei discorsi (spero). Ma alla fine quanto sono determinanti le differenze tra micro e macro-ops (per quello dobbiamo rompere le scatole a bjt2 :cool: )
in parte ci viene in aiuto Intel
http://techreport.com/r.x/centrino-atom/instruction-type-mix.gif
dice, che ben il 96% di tutte le istruzioni sono singole uops.
Il vantaggio delle macro-ops è più teorico che pratico o sbaglio.
Ottimo veramente. A suo tempo avevo letto qualcosa in inglese ed è stato difficile capire, così è un buon sunto facile da comprendere.
L'unica cosa aggiungerei che il set CISC è stata fatto perché impatta meno sull'uso della ram che all'epoca era un risorsa rara, mica come ora che ne hai a tonnellate.
Vedi arm che adesso può spingere di più con il suo RISC o anche IBM. Intanto di ram ce né quanta ne vuoi.;)
http://cs.stanford.edu/people/eroberts/courses/soco/projects/risc/risccisc/
Estratti
CISC
....
One of the primary advantages of this system is that the compiler has to do very little work to translate a high-level language statement into assembly. Because the length of the code is relatively short, very little RAM is required to store instructions. The emphasis is put on building complex instructions directly into the hardware.
RISC
....
At first, this may seem like a much less efficient way of completing the operation. Because there are more lines of code, more RAM is needed to store the assembly level instructions. The compiler must also perform more work to convert a high-level language statement into code of this form.
The Overall RISC Advantage
Today, the Intel x86 is arguable the only chip which retains CISC architecture. This is primarily due to advancements in other areas of computer technology. The price of RAM has decreased dramatically. In 1977, 1MB of DRAM cost about $5,000. By 1994, the same amount of memory cost only $6 (when adjusted for inflation). Compiler technology has also become more sophisticated, so that the RISC use of RAM and emphasis on software has become ideal.
Infatti per semplificare amd ha introdotto un traduttore da cuda verso hsa, così puoi prendere lavoro già fatto più facilmente con cuda e trasformarlo in hsa. Chiaro detto così è semplice, poi bisogna vedere come funziona la traduzione e la qualità della stessa. Potrebbe provare bjt2 e dirci come va;)
Probabilmente visto che a basso livello funziona uguale, invece di implementare un traduttore come ncc, con altra sintassi, hanno pensato di sfruttare il grosso parco di applicazioni CUDA e invogliare a passare ad AMD senza toccare il codice o quasi...
Stessa cosa che ha fatto microsoft con windows 10 mobile: esistono dei "traduttori" per ricompilare applicazioni Android e iOS su windows 10 mobile con poche o nessuna modifiche...
Ottimo veramente. A suo tempo avevo letto qualcosa in inglese ed è stato difficile capire, così è un buon sunto facile da comprendere.
L'unica cosa aggiungerei che il set CISC è stata fatto perché impatta meno sull'uso della ram che all'epoca era un risorsa rara, mica come ora che ne hai a tonnellate.
Vedi arm che adesso può spingere di più con il suo RISC o anche IBM. Intanto di ram ce né quanta ne vuoi.;)
http://cs.stanford.edu/people/eroberts/courses/soco/projects/risc/risccisc/
Estratti
CISC
....
One of the primary advantages of this system is that the compiler has to do very little work to translate a high-level language statement into assembly. Because the length of the code is relatively short, very little RAM is required to store instructions. The emphasis is put on building complex instructions directly into the hardware.
RISC
....
At first, this may seem like a much less efficient way of completing the operation. Because there are more lines of code, more RAM is needed to store the assembly level instructions. The compiler must also perform more work to convert a high-level language statement into code of this form.
The Overall RISC Advantage
Today, the Intel x86 is arguable the only chip which retains CISC architecture. This is primarily due to advancements in other areas of computer technology. The price of RAM has decreased dramatically. In 1977, 1MB of DRAM cost about $5,000. By 1994, the same amount of memory cost only $6 (when adjusted for inflation). Compiler technology has also become more sophisticated, so that the RISC use of RAM and emphasis on software has become ideal.
Il problema del codice RISC è che non solo la RAM ma anche la cache e la banda RAM è preziosa: se per fare un dato lavoro occupo il doppio di spazio, poi devo avere una cache L1I e una banda doppia tra processore e memoria... E' vero che la RAM ora non costa un cavolo, ma la cache e la velocità della RAM si paga... E' anche per questo che il codice x86 è sopravvissuto, oltre che per la compatibilità...
Mister D
25-02-2016, 09:05
Il problema del codice RISC è che non solo la RAM ma anche la cache e la banda RAM è preziosa: se per fare un dato lavoro occupo il doppio di spazio, poi devo avere una cache L1I e una banda doppia tra processore e memoria... E' vero che la RAM ora non costa un cavolo, ma la cache e la velocità della RAM si paga... E' anche per questo che il codice x86 è sopravvissuto, oltre che per la compatibilità...
Verissimo, infatti se vedi il Power 8 ha cache e soprattutto banda passante tra cpu e memoria elevata, di più degli xeon. (va beh lo dico a te che piace un sacco il power8 :D )
Mister D
25-02-2016, 09:09
Probabilmente visto che a basso livello funziona uguale, invece di implementare un traduttore come ncc, con altra sintassi, hanno pensato di sfruttare il grosso parco di applicazioni CUDA e invogliare a passare ad AMD senza toccare il codice o quasi...
Stessa cosa che ha fatto microsoft con windows 10 mobile: esistono dei "traduttori" per ricompilare applicazioni Android e iOS su windows 10 mobile con poche o nessuna modifiche...
Esattamente.
OT:
Cmq su bitandchips c'è un utente (alessio) che se ho ben capito è un programmatore gpu e che scrive un sacco di cose interessanti. Se non sei già iscritto potresti farlo e approfondire il tema, visto che poi hai anche iniziato a programmare le gpu.
Se non ti iscrivi lo posso capire. Io non l'ho fatto perché già passo abbastanza tempo di qua, se mi iscrivo di là è finita:D
Free Gordon
25-02-2016, 09:14
Infatti per semplificare amd ha introdotto un traduttore da cuda verso hsa, così puoi prendere lavoro già fatto più facilmente con cuda e trasformarlo in hsa. Chiaro detto così è semplice, poi bisogna vedere come funziona la traduzione e la qualità della stessa. Potrebbe provare bjt2 e dirci come va;)
Avevo letto questa cosa...ma c'è qualcuno che l'ha usato? Si hanno info fresche a riguardo?
Mister D
25-02-2016, 09:24
Avevo letto questa cosa...ma c'è qualcuno che l'ha usato? Si hanno info fresche a riguardo?
:D siamo in due allora con voglia di scoprire com'è andata a finire. Avevo letto sia qua che sugli altri portali le news e mi ero letto le slide di amd (sì le leggo ancora:D ) però poi non ho fatto ricerche per vedere se qualcuno ha fatto dei test;)
EDIT:
OT: ho trovato solo questo:
http://gpuopen.com/hip-to-be-squared-an-introductory-hip-tutorial/
http://gpuopen.com/platform-aware-coding-inside-hip/
Se a qualcuno può essere utile (bjt2 è tutto tuo, se hai tempo e voglia di provare)
tuttodigitale
25-02-2016, 10:07
Un solo appunto.
:banned:
Esistono istruzioni con anche 200 e oltre uops...
:eek:
Un solo appunto. INTEL usa il microcodice per qualsiasi istruzione che non sia di una sola uop.
ma per istruzione microcodificata di Intel , non si intendono quelle con uop>4?
Mentre AMD sarebbe limitata ad 1-1-1-1, 2-2, 2-1-1 MOPS (>2)
Ma per AMD quelle microcodificate sono MOLTO di meno, perchè solo quelle con 3 o più MOPS lo sono. Considerando che le MOPS sono più potenti delle uops, c'è un doppio vantaggio...
Ti faccio una domanda:
secondo la slide di Intel il 96% delle istruzioni sono delle uops, quel 4%, non sarebbe un numero tanto esiguo se si pensa al numero di uops equivalenti delle istruzioni microcodificate. Ad esempio la media di uop per singola istruzione microcodificata (sparo un numero a caso) è di 10, abbiamo che ben il 42% delle uops derivano da istruzioni di questo tipo.
Ho capito?
Quindi la domanda è quanto sono complesse mediamente le istruzioni microcodificate?
Esattamente.
OT:
Cmq su bitandchips c'è un utente (alessio) che se ho ben capito è un programmatore gpu e che scrive un sacco di cose interessanti. Se non sei già iscritto potresti farlo e approfondire il tema, visto che poi hai anche iniziato a programmare le gpu.
Se non ti iscrivi lo posso capire. Io non l'ho fatto perché già passo abbastanza tempo di qua, se mi iscrivo di là è finita:D
Anche io seguo di la, e mi pare piacevolmente preparato (detto dall'alto della mia ignoranza :doh: )
george_p
25-02-2016, 12:16
Esattamente.
OT:
Cmq su bitandchips c'è un utente (alessio) che se ho ben capito è un programmatore gpu e che scrive un sacco di cose interessanti. Se non sei già iscritto potresti farlo e approfondire il tema, visto che poi hai anche iniziato a programmare le gpu.
Se non ti iscrivi lo posso capire. Io non l'ho fatto perché già passo abbastanza tempo di qua, se mi iscrivo di là è finita:D
Anche io seguo di la, e mi pare piacevolmente preparato (detto dall'alto della mia ignoranza :doh: )
Esatto e ci sta un bel thread su Zen (http://www.bitsandchips.it/forum/viewtopic.php?f=4&t=9903) anche li :read:
Quindi BJT2 sei invitato a prenderne parte :yeah: :yeah: :yeah:
Ulteriori approfondimenti, nel limite delle mie conoscenze, sulla decodifica.
MACRO OPS e MICRO OPS nel mondo reale
Tutti bei discorsi (spero). Ma alla fine quanto sono determinanti le differenze tra micro e macro-ops (per quello dobbiamo rompere le scatole a bjt2 :cool: )
in parte ci viene in aiuto Intel
http://techreport.com/r.x/centrino-atom/instruction-type-mix.gif
dice, che ben il 96% di tutte le istruzioni sono singole uops.
Il vantaggio delle macro-ops è più teorico che pratico o sbaglio.
Aggiungo che sempre secondo slide intel, i decoder Macro occupano il 20-25% di area in più.
Secondo me il compilatore intel evita il microcodice come la pesta:p , per questo non ci sono impatti sulle performance.
cmq i decoder odierni decodificano molte più istruzioni senza l'ausilio del microcodice...
Verissimo, infatti se vedi il Power 8 ha cache e soprattutto banda passante tra cpu e memoria elevata, di più degli xeon. (va beh lo dico a te che piace un sacco il power8 :D )
Power8 usa un approccio forza bruta via SMT8 e TDP(250w), altrimenti IPC(Single thread) in se non è un granché.
Intel con i suoi 18core(165w) offre qualcosa in meno, ma come costi e TDP stiamo su un altro pianeta.
http://images.anandtech.com/graphs/graph9567/61428.png
In Decompressione la banda passante fa la differenza insieme al SMT4-8.
http://images.anandtech.com/graphs/graph9567/61428dec.png
ps. scusate OT.
:D siamo in due allora con voglia di scoprire com'è andata a finire. Avevo letto sia qua che sugli altri portali le news e mi ero letto le slide di amd (sì le leggo ancora:D ) però poi non ho fatto ricerche per vedere se qualcuno ha fatto dei test;)
EDIT:
OT: ho trovato solo questo:
http://gpuopen.com/hip-to-be-squared-an-introductory-hip-tutorial/
http://gpuopen.com/platform-aware-coding-inside-hip/
Se a qualcuno può essere utile (bjt2 è tutto tuo, se hai tempo e voglia di provare)
Non ho gpu amd e istallare opencl su gpu nvidia è, prevedibilmente, un casino... :D
:banned:
:eek:
ma per istruzione microcodificata di Intel , non si intendono quelle con uop>4?
Mentre AMD sarebbe limitata ad 1-1-1-1, 2-2, 2-1-1 MOPS (>2)
Ti faccio una domanda:
secondo la slide di Intel il 96% delle istruzioni sono delle uops, quel 4%, non sarebbe un numero tanto esiguo se si pensa al numero di uops equivalenti delle istruzioni microcodificate. Ad esempio la media di uop per singola istruzione microcodificata (sparo un numero a caso) è di 10, abbiamo che ben il 42% delle uops derivano da istruzioni di questo tipo.
Ho capito?
Quindi la domanda è quanto sono complesse mediamente le istruzioni microcodificate?
La maggior parte delle istruzioni mostro, sono per codice legacy o x87, che il compilatore intel ovviamente si guarda bene di usare: tutte le librerie ottimizzate hanno codice SSE dove eventualmente queste istruzioni sono simulate a la RISC. Istruzioni x87 con 200 uop sono ad esempio seno, coseno tangente e, proprio per risparmiare, se ti serve seno e coseno di uno stesso angolo, esiste sincos che calcola tutti e due in un tempo inferiore alle due istruzioni separate... Ma sono istruzioni legacy e non sono vettoriali. Applicano algoritmi standard che possono essere replicati con normali loop e codice SSE che magari ci sta benissimo nella cache L0, a costo di qualche byte in più di occupazione di memoria... Altre istruzioni mostro sono istruzioni per la gestione di task e processi, ad esempio il context switch che sono ovviamente lunghe perchè devono salvare tutti i registri interni in memoria e recuperare i nuovi ecc...
A quanto ho capito poichè i decoder simple possono gestire una soloa uop e il decoder complex è uno solo, se c'è una istruzione con 2 o più uop, questa occupa tutto il ciclo, bloccando la decodifica delle altre...
Il 96% delle istruzioni sono a una uop proprio perchè è il compilatore e le librerie ottimizzate che fanno così, sostituendo quando possibile con istruzioni più semplici. Infatti è probabile che persino i sistemi operativi facciano il task switch "a mano" e non con l'istruzione apposita...
In ogni caso 96% probabilmente è il conteggio dinamico e non statico: se tu hai un programma con il 50% di istruzioni a 1 mop, ma nei grossi loop sono tutte a 1 mop, è probabile che il conteggio dinamico ti dia 96% di istruzioni a 1 mop...
AMD non so se ha implementato tutte le combinazioni possibili, ma mi pare di si. In tal caso le operazioni possibili in 1 ciclo sarebbero:
1-1-1-1
2-2
1-2-1
2-1-1
1-1-2
3
4
Solo istruzioni con 3 o più uop monopolizzano i decoder e richiedono la microcode ROM.
Le istruzioni microcodificate sono relativamente poche e si cerca di non usarle quando possibile e certamente non nei loop: per velocizzare i loop si cerca di fare il loop unrolling, figuriamoci se non si farebbe la sostituzione delle istruzioni microcodificate con le sequenze equivalenti...
paolo.oliva2
25-02-2016, 15:28
@Tuttodigitale
Io posso avere fantasia, ma le mie basi nel funzionamento interno del procio (a parte sbelinarmi nell'OC) non sono granchè, quindi quando magari faccio qualche sparata (che può essere fuori dai coppi il più delle volte e a volte una buona intuizione) mi fermo lì, poi ci vuole il personale competente (come te, Bjt2) che valuta la cosa con le basi necessarie. :sofico:
Un TH come questo che stai realizzando, io non sarei mai arrivato a farlo.
Poi magari mi rifaccio quando ci sarà da occare Zen :mc:
tuttodigitale
25-02-2016, 16:14
@REN
avevo calcolato l'ipc di power8 e power7 nel ST nel vecchio thread, secondo i dati forniti da IBM. L'ipc nel ST era bassino, ma la cosa interessante era l'aumento da una generazione all'altra. Cerco il mio post e se lo trovo lo posto.
@ BJT2
molto interessante (come sempre) il tuo intervento.
Piccola correzione sui decoder di Bulldozer e Piledriver.
AMD ha implementato le seguente combinazioni:
Bulldozer
1-1-1-1
2-1-1
Piledriver
1-1-1-1
2-1-1
2-2
@Paolo.Oliva
Senza fantasia il thread muore.
E poi è pieno il forum del mie c@zz@te.:cry: :sofico:
EDIT
ho trovato uno dei due post!
Il power8 ha subito un vertiginoso aumento a livello di ipc anche nel ST rispetto a Power7: intorno al 50%.
Se ci atteniamo a spec int/ fp l'ipc di un core P8 sembrerebbe molto molto alto.
p8 12 core (96 th) 3,1GHz circa uguale a Xeon 18 core (36 th) 2,3GHz
considerando le prestazioni di un cora aumentano secondo le slide di IBM del 120% nel MT.
A parità di clock un singolo core Power 8 mostrerebbe un livello di ipc superiore del 12% nell'integer e +24% nel FP (ma necessita di 8 thread vs 2 thread)
IPC ST Power8
FP 124/2,2 =56,4
INT 112/2,2=50,9
IPC ST Haswell
100/1,3=77
differenza ipc ST: +36 - 51% a favore di Intel
EDIT2
solo adesso vedo i grafici...
@REN
avevo calcolato l'ipc di power8 e power7 nel ST nel vecchio thread, secondo i dati forniti da IBM. L'ipc nel ST era bassino, ma la cosa interessante era l'aumento da una generazione all'altra. Cerco il mio post e se lo trovo lo posto.
@ BJT2
molto interessante (come sempre) il tuo intervento.
Piccola correzione sui decoder di Bulldozer e Piledriver.
AMD ha implementato le seguente combinazioni:
Bulldozer
1-1-1-1
2-1-1
Piledriver
1-1-1-1
2-1-1
2-2
Ah ecco, mi pareva strano avessero implementato tutte le combinazioni... :D
Esatto e ci sta un bel thread su Zen (http://www.bitsandchips.it/forum/viewtopic.php?f=4&t=9903) anche li :read:
Quindi BJT2 sei invitato a prenderne parte :yeah: :yeah: :yeah:
E' un po' moscio... Non c'è neanche la notizia dei 32 core lato server...
Bella però la faccina sdentata :asd:
george_p
26-02-2016, 11:17
E' un po' moscio... Non c'è neanche la notizia dei 32 core lato server...
Bella però la faccina sdentata :asd:
Diciamo che si cazzeggia di meno e le notizie su zen ultimamente, quelle più "verosimili", ultimamente sono proprio scarse. Comunque trovi tutto sotto forma di articoli e moltissime news uscite (di prima mano) su B&C sono risultate vere.
:)
Diciamo che si cazzeggia di meno e le notizie su zen ultimamente, quelle più "verosimili", ultimamente sono proprio scarse. Comunque trovi tutto sotto forma di articoli e moltissime news uscite (di prima mano) su B&C sono risultate vere.
:)
Quindi quelle slides del CERN con Zen a 32 core potrebbero essere false?
E' un po' moscio... Non c'è neanche la notizia dei 32 core lato server...
Bella però la faccina sdentata :asd:
Fidati che se metti qualche post dei tuoi, il thread prende vita.
Radeon80
26-02-2016, 11:35
Sono iscritto anche io al forum di bitsandchips e ti posso garantire che tutte le news riportate dal sito si sono rivelate veritiere.
Fidati che se metti qualche post dei tuoi, il thread prende vita.
Troppo sbattimento... :asd:
Non penso che possa fare copia incolla da qui anche se è farina del mio sacco... Sarebbe una inutile duplicazione e forse non è consentito dalle regole del forum...:banned:
Sono iscritto anche io al forum di bitsandchips e ti posso garantire che tutte le news riportate dal sito si sono rivelate veritiere.
Non lo metto in dubbio... :)
Proprio perchè quel sito non ha nominato la faccenda dei 32 core ho chiesto...
george_p
26-02-2016, 12:31
Quindi quelle slides del CERN con Zen a 32 core potrebbero essere false?
Questo non lo so e non mi pare che ne abbiano parlato come false, però qui si parla di questo e non so se sia lo stesso (pare di si?!):
http://www.bitsandchips.it/9-hardware/6577-amd-zeppelin-con-architettura-zen-all-interno-della-potente-apu-da-hpc
Troppo sbattimento... :asd:
Non penso che possa fare copia incolla da qui anche se è farina del mio sacco... Sarebbe una inutile duplicazione e forse non è consentito dalle regole del forum...:banned:
Ok i copia e incolla ma una volta che interagisci con altri utenti il copia e incolla non esiste più.
tuttodigitale
26-02-2016, 14:19
Ok i copia e incolla ma una volta che interagisci con altri utenti il copia e incolla non esiste più.
E proprio per quello che diventa uno sbattimento. BJT2 anzichè fare un unico post che risponde a domande simili, ne deve scriverne il doppio. (pensa che rottura di scatole rispondere a 2 tuttodigitale :ciapet: )
BJT2 è il fior all'occhiello del nostro thread, che vengano qui :cool:
PS non me ne volere, fa abbastanza schifo come thread (forse perchè non ci sono :Prrr: ), ma è pieno di inesattezze a partire dal primo post:
1) Haswell avrebbe 14 stages...
2) Dresdenboy avrebbe detto che ZEN avrà pipeline da 10 stadi....
3) Non c'è stata nessuna discussione sul fatto che si passi da una soluzione con due flussi FMA con una che ha solo uno stream, questo a partire da quanto ha reso disponibile da dresdenboy.....
4) dove è finito il rumors del nuovo bus di AMD, la cui necessità per le soluzioni Opteron, visto che AMD non fa più parte del consorzio HT, si era espresso il Capitano (un'altro fiore all'occhiello :cool: ) prima di qualsiasi notizia?
5) Dei 32 core nessuna traccia, del 6wide (?) idem, della L0 (perla di bjt) niente.
C@zzezziamo, limite delle nostre limitate competenze. Ma c'è di tutto e (molto) di più Ma Bjt2 metterà freno (se ci riuscirà?) alle nostre fantasie, con dati oggettivi.
PS mi sembra più un tentativo di valorizzare un ottimo sito come bitsandchips, che non quello di rendere più interessante il dialogo. Sbaglio?
PPS OMG stiamo litigando per tenerci BJT2. Sembriamo due ragazzine :eek:
Faccio una domanda: ma è sicuro che il 32 core sarà la classica soluzione MCM con due die collegati tra di loro? Su altri lidi si parla che sarà una configurazione MCM, e questo implicherebbe (quando mai!) die a 16 core nativi. Lo ha detto il tizio del CERN, o è una estensione fantozziana?
Si vociferava da tempo che il 32 core avrebbe avuto una configurazione basata su 8 core, addirittura anche l'APU HPC, sarebbe costituita da un puzzle formata da 2 core ZEN x8 e 2xGPU polaris, collegati attraverso il nuovo bus a bassa latenza (tutte le news sono qui http://www.hwupgrade.it/forum/showpost.php?p=43205840&postcount=3).
george_p
26-02-2016, 15:10
Non vedo nessun motivo di litigio ne di contesa, e ognuno è libero di postare ovunque o solo dove gli pare.
Per quanto riguarda le inesattezze non posso certo risponderti visto che non conosco in modo approfondito le architetture nè ne ho il tempo per studiarle, potresti farle notare direttamente ai diretti interessati.
Per quanto ho letto Dresdenboy riporta quello che scrive da documenti ufficiali, come fa lo stesso BJT2.
Altri modi esternamente ad amd (o intel) penso non ci siano prima di documentazioni ufficiali e debutto architetture.
Faccio una domanda: ma è sicuro che il 32 core sarà la classica soluzione MCM con due die collegati tra di loro? Su altri lidi si parla che sarà una configurazione MCM, e questo implicherebbe (quando mai!) die a 16 core nativi. Lo ha detto il tizio del CERN, o è una estensione fantozziana?
Si vociferava da tempo che il 32 core avrebbe avuto una configurazione basata su 8 core, addirittura anche l'APU HPC, sarebbe costituita da un puzzle formata da 2 core ZEN x8 e 2xGPU polaris, collegati attraverso il nuovo bus a bassa latenza (tutte le news sono qui http://www.hwupgrade.it/forum/showpost.php?p=43205840&postcount=3).
Probabilmente qualcuno fa un po' di confusione. Da quel thread di semiaccurate, tra tanti litigi, si evince che probabilmente saranno 4 die da 8 core e un totale di 8 canali ram. Ogni die porta 2 canali ram. Possibile anche soluzioni dual die e 4 canali, forse su un altro socket intermedio, e al posto di due moduli CPU, possibilità di moduli gpu con memoria hbm e 4 canali dram, quindi forse per il socket da 4 canali e max 16 core...
IMHO 16 core in un die monolitico mi pare troppo. Se l'MCM lo fanno con l'interposer (e non vedo perchè porsi problemi di costo visto che sono per il settore enterprise e comunque almeno per la apu con hbm l'interposer è obbligatorio), il collegamento tra i die può essere molto veloce e magari a molti bit...
george_p
26-02-2016, 15:36
Si avranno dettagli e informazioni in più su zen tra un pò? Che ne dite?
Serve altra legna da ardere :D
tuttodigitale
26-02-2016, 16:09
@bjt2
OMG, devo fare un salto su quel forum, ci sono dei tizi che la pensano come me. :eek:
IMHO 16 core in un die monolitico mi pare troppo.
Eccone un'altro :eek: :sofico:
@tuttodigitale o altri come bjt2 o il capitano, invece della dicitura "Core Complex" che ci dite? :stordita:
hai sbagliato l'ordine! Io sono un ignorantello. Da quello che ho capito il Core Complex altri non è che un modulo costituito da 4core ZEN + LLC.
@bjt2
OMG, devo fare un salto su quel forum, ci sono dei tizi che la pensano come me. :eek:
Eccone un'altro :eek: :sofico:
Devi pregare che sia così... :D Altrimenti vuol dire che c'è poca cache L3 e/o i core sono piccolini e quindi semplici... :D
hai sbagliato l'ordine! Io sono un ignorantello. Da quello che ho capito il Core Complex altri non è che un modulo costituito da 4core ZEN + LLC.
Esatto...
tuttodigitale
26-02-2016, 16:28
ma LLC non significa semplicemente Last Level Cache? è un modo generico per non scrivere L3 perché in alcuni casi esiste la L4 ad esempio?
SI, mi riferivo alla L3.
La L4, se esiste unirebbe i diversi moduli (sempre imho). Quindi NO.
sei tu sei ignorante in queste cose noi altri cosa siamo? :asd:
E che ne so? :ciapet:
Esatto...
spuntini sospensivi...:stordita:
spuntini sospensivi...:stordita:
Non ci leggere niente... Sono affetto da puntinite... :ciapet: Come un vecchio utente del forum (nel senso che diceva di avere oltre 60 anni) che forse tu non conosci... :D
Due cose.
La prima è una considerazione sulla cache L0. Dalle slide del tizio del CERN, sembrerebbe che Zen abbia una cache L0 di 4KB. Quella dei processori INTEL è 1,5KB. Quindi anche se Zen fosse SMT4, ci sarebbe comunque più cache per thread dei processori INTEL. Se poi è un SMT2 classico, hai voglia! :ciapet:
Seconda cosa: un tweet di dresdenboy rimanda a un post su un forum, che riporto qui. Buone notizie.
https://arch.b4k.co/g/thread/52492812/
Functional untethered 8-core znver1 Summit Ridge A0 engineering samples with an estimated 95W TDP have now taped out on Samsung's 14nm FinFET and are undergoing validation.
It's not yet clear how well they will clock (but Samsung's 14nm FinFET process is slightly better than Intel's - Intel haven't pulled ahead with 10nm yet as that EUV process is very late, hence their Kaby Lake). IPC efficiency is very roughly equal with Broadwell, very slightly behind Skylake, but it's push and shove.
They are currently targeting October 2016 (ish) for release. AM4 motherboards compatible with Summit Ridge have chipsets already shipping and should be coming out around about March 2016 (ish).
Subject to change. They may dual-source on GF14A.
Tapeout di uno Zen 8 core step A0 95W (unthethered non so cosa significhi) su processo Samsung 14nm finfet, che sembra migliore di quello INTEL. IPC simile a broadwell un po' sotto a skylake (ma siamo allo step A0, ricordiamolo). Chipset comaptibili per MB AM4 in arrivo a marzo. Tenteranno di uscire con Zen a ottobre. Validazione in corso... Dita incrociate...
Buone notizie direi...
Radeon80
27-02-2016, 10:16
Da quello che si sa Zen dovrebbe uscire su desktop in versione 4,6 e 8 core.
Sicuramente la versione 6 core userà lo stesso "pezzo si silicio" dell'8 core,mentre mi chiedo se la versione 4 core sarà basato sullo stesso silicio oppure ne faranno una versione nativa.
tuttodigitale
27-02-2016, 11:59
Sono molto dubbioso su quanto dicono.
untethered, dovrebbe significare sciolto, libero, slegato. Quindi bo:cry: .
mi chiedo se la versione 4 core sarà basato sullo stesso silicio oppure ne faranno una versione nativa.
La seconda. Per la prima aspetteranno l'apu.
IMHO.
Grizlod®
27-02-2016, 12:47
Sono molto dubbioso su quanto dicono.
untethered, dovrebbe significare sciolto, libero, slegato. Quindi bo:cry: .
Credo sia da intendere come una sorta di sample-prototipo, cioè svincolato dall'esemplare che andrebbe in produzione di serie.
Ad ogni modo, non dimentichiamoci che lo scorso Novembre, GloFo uscì con una Press Release ufficiale:
http://globalfoundries.com/newsroom/press-releases/2015/11/05/globalfoundries-achieves-14nm-finfet-technology-success-for-next-generation-amd-products
Ciò non significa che produrrà Zen, ma lo ritengo cmq significativo.
tuttodigitale
27-02-2016, 14:05
all'epoca mi ricordo, che non si diede importanza a quanto scritto, ovvero che AMD avrebbe prodotto alcune GPU Polaris su 14nm.:)
In teoria, a regime, le differenze tra Samsung e GF, dovrebbero essere nulle, e questo si ripercuoterebbe positivamente anche sui costi delle maschere. Passare da GF a Samsung, e viceversa, non dovrebbe rappresentare un ostacolo a livello tecnico.
paolo.oliva2
27-02-2016, 17:16
Secondo me, il problema di GF/Samsung (sul silicio che dovrebbe essere per Zen) non hanno particolari problemi, sempre se non sono pinocchio. AMD ha riportato prima di Natale che il silicio avrebbe già raggiunto le aspettative (comunque quali aspettative?) e che Zen non presentava bug particolari.
Ora... quello che ipotizzo è che la resa sia deludente, unendo 2 info: a suo tempo si parlava sempre di Zen minimo X4 e praticamente multipli di X4 (fermiamoci a X8). Per quanto ne ho capito io, Zen avrà anche stravolto il core BD, ma non ci vedo un I/O (seppur potenziato e qualsivoglia) che stravolga le linee base di BD/modulo, nel senso che non ce la vedo proprio AMD (per la riduzione dei costi) che faccia come Intel che a seconda del numero dei core crea un die a sè ottimizzato nel TDP a seconda della frequenza, della quantità di cache e qualsivoglia.
Se gli APU sono X4 XV, la base minima di Zen può essere solamente X4, anche perchè se un Zen X8 è 95W con L3 e frequenze da desktop, non ha alcun senso un Zen X2, anche perchè se Zen ottiene +40% su XV, con -50% di core sarebbe un arretramento di potenza.
Ora, partendo da X4, Zen può saltare a X8, non a X6, ma se ci fossero problemi di resa, questo spiegherebbe Zen X6 (un po' come i Phenom II X3).
Inoltre, da novembre 2015 (quando uscì il 1° prototipo Zen) + 6 mesi fa maggio 2016, e se le voci di Zen per settembre/ottobre 2016 fossero vere, 3 mesi di ritardo sarebbero giustificati come affinamento, ma non certo per un PP ulteriore (ci vorrebbero 6 mesi).
Comunque io rifletterei su un punto. AMD, con i tanti problemi di TDP/silicio, ha fatto dei passi da gigante per riuscire a diminuire i consumi acquisendo notevole esperienza con librerie ad alta densità, isole di tensione e quant'altro. Questo lo ha fatto su Carrizo, ma Zen le ha implementate (ovviamente) e comunque l'architettura è stata portata avanti con la compatibilità di quelle features.
Se, come si parla, Il 14nm di Zem sarebbe all'altezza del 14nm Intel, non possiamo non considerare che l'utilizzo di quelle features ha permesso al 28nm Bulk di GF di portare comunque un Carrizo mobile molto competitivo come consumo/prestazioni con l'ultima architettura Intel + 14nm.
Ora, se Zen 14nm, implementando quelle features, non mi sorprenderebbe che un Zen X8 potrebbe competere con un 5960X ma con 45W TDP in meno.
Lungi da me discorsi di bandiera, ma se si parla che l'IPC di Zen possa realmente essere di poco inferiore a quello Intel, una cosa sono i 4GHz per un 6700K, tutt'altra un 5960X a 3GHz o 3,5GHz forse su un 14nm...
Grizlod®
27-02-2016, 17:20
all'epoca mi ricordo, che non si diede importanza a quanto scritto, ovvero che AMD avrebbe prodotto alcune GPU Polaris su 14nm.:)
In teoria, a regime, le differenze tra Samsung e GF, dovrebbero essere nulle, e questo si ripercuoterebbe positivamente anche sui costi delle maschere. Passare da GF a Samsung, e viceversa, non dovrebbe rappresentare un ostacolo a livello tecnico.
Infatti a riguardo in Gennaio uscì un'altra; avevo salvato il link (che pero ora non linka a nulla):
http://thefoundryfiles.com/2016/01/07/globalfoundries-to-build-new-14nm-gpus-for-amd/
tuttavia sulla Home Page si legge di: AMD products, high performance, compute and graphics Technologies:
http://globalfoundries.com/home
george_p
27-02-2016, 18:42
Due cose.
La prima è una considerazione sulla cache L0. Dalle slide del tizio del CERN, sembrerebbe che Zen abbia una cache L0 di 4KB. Quella dei processori INTEL è 1,5KB. Quindi anche se Zen fosse SMT4, ci sarebbe comunque più cache per thread dei processori INTEL. Se poi è un SMT2 classico, hai voglia! :ciapet:
Seconda cosa: un tweet di dresdenboy rimanda a un post su un forum, che riporto qui. Buone notizie.
Tapeout di uno Zen 8 core step A0 95W (unthethered non so cosa significhi) su processo Samsung 14nm finfet, che sembra migliore di quello INTEL. IPC simile a broadwell un po' sotto a skylake (ma siamo allo step A0, ricordiamolo). Chipset comaptibili per MB AM4 in arrivo a marzo. Tenteranno di uscire con Zen a ottobre. Validazione in corso... Dita incrociate...
Buone notizie direi...
Non capisco che forum sia, è affidabile la fonte?
Free Gordon
28-02-2016, 00:36
Buone notizie direi...
Più che buone direi... fantastiche!!! :read:
Se davvero uscisse a Ottobre (e questo particolare mi preoccupa assai perchè non credo ce la facciano... :( ) con un procio del genere, AMD tornerebbe in gioco ben 10 anni dopo l'A64! :sofico: Commozione everywhere! :cry: :cry: :cry:
tuttodigitale
28-02-2016, 09:26
Tutti danno per scontato che non si possono raggiungere e magari superare, e di parecchio, i 4GHz di base a 95W per l'octa core. C'è anche questa eventualità :cool:
Non capisco che forum sia, è affidabile la fonte?
Dresdenboy è abbastanza affidabile ed ha tweetato con un punto interrogativo... Attendiamo conferme... :D
Più che buone direi... fantastiche!!! :read:
Se davvero uscisse a Ottobre (e questo particolare mi preoccupa assai perchè non credo ce la facciano... :( ) con un procio del genere, AMD tornerebbe in gioco ben 10 anni dopo l'A64! :sofico: Commozione everywhere! :cry: :cry: :cry:
Tieni conto che una parola di quel post l'ho sottovalutata: "functional". Ossia il chip è funzionante. Quindi devono solo vedere bachi e problemi e se correggerli con microcodice o altro step. Direi che sono ad un OTTIMO punto. Classifico come problema anche un eventuale basso clock...
george_p
28-02-2016, 12:00
Dresdenboy è abbastanza affidabile ed ha tweetato con un punto interrogativo... Attendiamo conferme... :D
Dresdenboy è affidabile e lo si conosce da anni, mi domandavo infatti del forum perché non vedevo nessun nickname visualizzato ma forse è dovuto al fatto del non essere iscritto.
capitan_crasy
28-02-2016, 13:16
Tieni conto che una parola di quel post l'ho sottovalutata: "functional". Ossia il chip è funzionante. Quindi devono solo vedere bachi e problemi e se correggerli con microcodice o altro step. Direi che sono ad un OTTIMO punto. Classifico come problema anche un eventuale basso clock...
Più che altro questa è la prima volta che riceviamo rumors di una certa rilevanza sui primissimi stepping.
A memoria AMD non è mai riuscita a mandare in produzione il primo step; l'unica eccezione fu il core Thuban (D0) ma li i 45nm avevano già molta esperienza con Deneb...
george_p
28-02-2016, 13:22
Più che altro questa è la prima volta che riceviamo rumors di una certa rilevanza sui primissimi stepping.
A memoria AMD non è mai riuscita a mandare in produzione il primo step; l'unica eccezione fu il core Thuban (D0) ma li i 45nm avevano già molta esperienza con Deneb...
Quindi è una buona notizia anche da questo punto di vista. Processo produttivo e lavoro di affinamento anche da parte di amd probabilmente ai massimi livelli.
Free Gordon
28-02-2016, 15:41
In TEORIA..un chip del genere ci mette 1 annetto dal primo tapeout all'uscita sugli scaffali..
Se davvero è avvenuto ora, la vedo dura per Ottobre... Sennò significa che l'hanno fatto a Novembre 2015, con quell'annuncio criptico postato sul sito di GloFo..e così ci starebbe anche un lancio ad Ottobre
Che per una volta glofo ha fatto un buon lavoro con il pp. Beh sarebbe un gradita e insperata sorpresa
Inviato dal mio XT1092 utilizzando Tapatalk
tuttodigitale
28-02-2016, 16:47
Ufficialmente AMD ha fatto il tape-out di 2 prodotti a Luglio 2015 su FinFET.
A Settembre GF ha confermato che ci sono stati dei tape out.
A Ottobre Dresdenboy afferma che il tape-out è avvenuto sia per ZEN sia per k12.
A novembre esce quel documento criptico di GF.
Neppure una settimana dopo ci sono già rumors, che vogliono ZEN privo di importanti colli di bottiglia.
A Gennaio viene confermato da Raja Koduri che Polaris sarà anche sui 14nm Finfet, e il post di quel tizio che dice l'ipc è quello di broadwell.
se devo proprio dare un range (devo?:sofico: ), il tape-out di ZEN è avvenuto tra luglio-ottobre 2015.
capitan_crasy
28-02-2016, 17:45
Ufficialmente AMD ha fatto il tape-out di 2 prodotti a Luglio 2015 su FinFET.
A Settembre GF ha confermato che ci sono stati dei tape out.
A Ottobre Dresdenboy afferma che il tape-out è avvenuto sia per ZEN sia per k12.
A novembre esce quel documento criptico di GF.
Neppure una settimana dopo ci sono già rumors, che vogliono ZEN privo di importanti colli di bottiglia.
A Gennaio viene confermato da Raja Koduri che Polaris sarà anche sui 14nm Finfet, e il post di quel tizio che dice l'ipc è quello di broadwell.
Se devo proprio dare un range (devo?:sofico: ), il tape-out di ZEN è avvenuto tra luglio-ottobre 2015.
Al di la delle tempistiche se conti che i rumors sul A0 core Agena (K10 65nm, apparsi dopo l'uscita del 45nm) era nato MORTO, qui ce da stare più allegri...:asd:
Free Gordon
28-02-2016, 18:05
Incrociare le dita please..... :sperem: :sperem: :sperem: :sperem: :sperem: :sperem: :sperem:
Se il tapeout è di ottobre 2015, ci sta che Ottobre 2016 abbiamo il nostro Zen by Keller 8core sugli scaffali (e nei case di tutti a questo punto! :D )
Se l'IPC è quello di Broadwell, clocckano Zen a 100-200mhz in più e hanno un concorrente per Skylake..
Certo...bisognerà vedere a che prezzo lo piazzeranno..
Curioso di vedere cosa decide Lisa in questo ambito....Pari prezzo Intel? Rilancio AMD??:sofico:
george_p
28-02-2016, 19:01
http://www.bitsandchips.it/enterprise-business/9-hardware/6186-tape-out-di-zen-e-k12-a-14nm-e-16nm-come-da-noi-anticipato
Lo avevano già segnalato sul loro canale twitter a luglio 2015, quindi possiamo dire con un certo margine di sicurezza che il tape out è precedente a ottobre 2015.
http://www.bitsandchips.it/cache/500x230-equal_images_2015_10_19_zentapeout.png
digieffe
29-02-2016, 00:09
bentornato bjt2...
fraussantin
29-02-2016, 00:14
Incrociare le dita please..... :sperem: :sperem: :sperem: :sperem: :sperem: :sperem: :sperem:
Se il tapeout è di ottobre 2015, ci sta che Ottobre 2016 abbiamo il nostro Zen by Keller 8core sugli scaffali (e nei case di tutti a questo punto! :D )
Se l'IPC è quello di Broadwell, clocckano Zen a 100-200mhz in più e hanno un concorrente per Skylake..
Certo...bisognerà vedere a che prezzo lo piazzeranno..
Curioso di vedere cosa decide Lisa in questo ambito....Pari prezzo Intel? Rilancio AMD??:sofico:
Se son furbi tirano il prezzo al minimo del procio e alzano un po il chipset che è basso ( tanto intel spara alto sugli z)
Solo versioni occabili , e la gente inizia a comprarli. Poi quando e se hanno una mobo amd ci restano .
Se sparano alto quanto gli intel di pari prestazioni fanno la fine delle fury.
paolo.oliva2
29-02-2016, 00:51
Se son furbi tirano il prezzo al minimo del procio e alzano un po il chipset che è basso ( tanto intel spara alto sugli z)
Solo versioni occabili , e la gente inizia a comprarli. Poi quando e se hanno una mobo amd ci restano .
Se sparano alto quanto gli intel di pari prestazioni fanno la fine delle fury.
Perfettamente d'accordo, in più c'è da aggiungere un punto fondamentale:
Intel ha le FAB, AMD no, quindi mentre Intel può fare il prezzo che vuole perchè il suo metro è una quantità sicura di vendita (e quindi FAB a regime) ed un costo produzione che è tutto sul wafer silicio. AMD, con GF, può strappare un prezzo basso a die UNICAMENTE se punta sulla quantità, ed è ovvio che la quantità è più marcata o meno a seconda dell'appetibilità prezzo/prestazioni.
Mi sembra ovvio che prezzare Zen = Intel, vorrebbe dire meno quantità = prezzo a die + alto da pagare a GF. Viceversa, un prezzo più aggressivo per Zen significa un prezzo più basso a die da pagare a GF.
Insomma, cerchiamo di voler capire che AMD a tutti gli effetti guadagnerebbe di più prezzando meno Zen che fare la politica di Intel.
Comunque secondo me stiamo ipotizziamo prezzi di Zen su un listino che di per è sfalsato per ovvia mancanza di concorrenza... ed Intel fa quel che vuole.
AMD non ha alcun interesse a piazzare un prezzo su Zen alto perchè vorrebbe dire unicamente soldi in più per GF (non per AMD), mentre al contrario potrebbe sfruttare proprio il momento buono (ammesso e concesso che 14nm GF + architettura Zen siano dignitosi con TDP da favola) per piazzare quanti più sistemi AM4 possibili (compatibili si sa già con Zen+), perchè al 99% chi compra una mobo AMD con chip-set AMD, ci schiaffa una ATI di VGA.
Non dimentichiamoci della crisi, e che AM4 vuole le DDR4, quindi una mobo AM4, + DDR4 + Zen, devono costare una cifra alla portata di molti, non di pochi, altrimenti AMD col cacchio che recupera fette di mercato.
Free Gordon
29-02-2016, 01:43
Secondo me un OCTAcore Zen 3.5ghz, se le prestazioni sono quelle dichiarate, possono metterlo tranquillamente a 250$. Li vale e il pubblico AMD (che non è poi così risicato come sembra), lo comprerà.
Se poi Apple monterà le APU Zen sui Mac... :) AMD è di nuovo in sella! :sofico:
Secondo me un OCTAcore Zen 3.5ghz, se le prestazioni sono quelle dichiarate, possono metterlo tranquillamente a 250$. Li vale e il pubblico AMD (che non è poi così risicato come sembra), lo comprerà.
Se poi Apple monterà le APU Zen sui Mac... :) AMD è di nuovo in sella! :sofico:
Sugli ultraportatili già Apple monta le "APU" (in realtà SoC) Intel, accontentandosi delle prestazioni, che in versione Pro con memoria eDRAM esterna superano anche quelle delle APU AMD...
Se AMD vuole il mercato degli ultraportatili, anche Apple, deve produrre APU con memoria HBM(2), magari non come cache LLC ma come memoria di sistema: con 4 chip HBM2 si può arrivare a 32GB di RAM...
Free Gordon
29-02-2016, 14:18
Sugli ultraportatili già Apple monta le "APU" (in realtà SoC) Intel, accontentandosi delle prestazioni, che in versione Pro con memoria eDRAM esterna superano anche quelle delle APU AMD...
Se AMD vuole il mercato degli ultraportatili, anche Apple, deve produrre APU con memoria HBM(2), magari non come cache LLC ma come memoria di sistema: con 4 chip HBM2 si può arrivare a 32GB di RAM...
Il fatto che AMD non usi l'eDRAM alla fine sarà un vantaggio competitivo...perché le HBM avranno prezzi sempre più bassi e capienze sempre più ampie.
ATI già nel 2005 implementò l'eDRAM in Xenos per sgravare la banda di Xbox360...(la GPU poteva solo leggerla, però), quindi credo non avrebbero problemi a creare anche loro una APU con eDRAM annessa ma non l'hanno fatto per i costi, penso..
Il fatto che AMD non usi l'eDRAM alla fine sarà un vantaggio competitivo...perché le HBM avranno prezzi sempre più bassi e capienze sempre più ampie.
ATI già nel 2005 implementò l'eDRAM in Xenos per sgravare la banda di Xbox360...(la GPU poteva solo leggerla, però), quindi credo non avrebbero problemi a creare anche loro una APU con eDRAM annessa ma non l'hanno fatto per i costi, penso..
128MB vs 4-32GB ad un costo comparabile, con una banda anche superiore... Naaaahhh... Non c'è storia...
Free Gordon
29-02-2016, 16:40
Ma infatti! ;)
Radeon80
29-02-2016, 21:54
http://dresdenboy.blogspot.it/2016/02/new-amd-zen-core-details-emerged.html?spref=tw
Nuove info su Zen.
http://dresdenboy.blogspot.it/2016/02/new-amd-zen-core-details-emerged.html?spref=tw
Nuove info su Zen.
L'avevo lette ieri sera durante la pausa della partita... :asd: Volevo scrivere qualcosa, ma la partita ha avuto la meglio... :asd:
Dunque:
1) Conferma che la cache L0 è per le uops.
2) Checkpointing, ossia recupero più veloce in caso di predizione salto errata
3) Ricompaiono gli FMAC (per qualche ragione si era speculato che lo FMAC era fatto con addizione e moltiplicazione unite tra loro e quindi occupavano due pipeline) e si specifica meglio la FPU: più potente di quello che si pensava
4) I thread dovrebbero essere 2, ma la buona notizia è che se la cache L0 è veramente 4KB, c'è più del doppio di cache rispetto ad INTEL... Considerando anche che le MOPS AMD sono più espressive e ce ne vogliono di meno rispetto a INTEL...
5) Dall'analisi dei dati Dresdenboy dice che praticamente un core Zen è due front end con un solo back end. Credo voglia intendere che le risorse per i due thread siano di più rispetto ad INTEL e che quindi ci si deve attendere un alto guadagno dal secondo thread...
6) Compare il GMI link, utile per la comunicazione tra die (compreso probabilmente una eventuale GPU su die separato in una APU server)
7) Ci sono delle righe "reserved": Dresdenboy suppone che siano funzionalità gustose, tenute nascoste perchè la mailing list è pubblica. Dice così perchè sono in mezzo e non in coda e quindi non sono vere funzionalità riservate per il futuro, ma semplici funzionalità implementate, ma tenute nascoste... Per ora...
8) Non ho capito cosa sia il FUSE subsystem, ma il nome è gustoso... :D
9) Stack cache: cache separata per i dati stack: più per questioni di risparmio energetico che per le maggiori prestazioni
10) Modulo di gestione della paginazione a 4 vie: probabilmente 1 dati e 1 istruzioni per ognuno dei thread, ma il patent menzionato parla anche di riordinamento delle operazioni di memoria. Probabilmente questo le rende più efficienti...
11) La FPU è 128 bit. Ciò si deduce dal fatto che le istruzioni AVX 256 bit sono double (2 MOPS) e le altre single.
12) La FPU può fare per ogni ciclo 2FADD+2FMUL o 2FADD+2FMAC. Se sono stati inteligenti le 2FMAC possono fare anche FADD e quindi si hanno fino a 4 addizioni a 128 bit per ciclo o 2 a 256 per ciclo. Non male.
13) Si consiglia di disabilitare il prefetcher software: o quello hardware è molto buono, oppure c'è interferenza ed è meglio disabilitare quello software
14) Cache L1 con latenza 4 e 2 letture e una scrittura (a 128 bit?) per ciclo
15) In futuro riparlerà più in dettaglio della FPU...
Ottime notizie! :D
Free Gordon
01-03-2016, 10:07
Il DATA frabric a 25GB/s per singolo link non è un pò poco?
Sarebbero 50GB su una config normale a doppio link, non mi pare moltissimo considerando la velocità delle ddr4 in config quad channel..o ho detto una cazzata?
Il DATA frabric a 25GB/s per singolo link non è un pò poco?
Sarebbero 50GB su una config normale a doppio link, non mi pare moltissimo considerando la velocità delle ddr4 in config quad channel..o ho detto una cazzata?
Non sappiamo quanti link ci sono in una CPU. Avevo letto che la banda era 100GB/s, quindi 4x, nel documento del tizio del CERN...
tuttodigitale
01-03-2016, 12:28
BJT2 non c'è gusto, hai detto tutto tu
posto in prima prima pagina.
Ricompaiono gli FMAC (per qualche ragione si era speculato che lo FMAC era fatto con addizione e moltiplicazione unite tra loro e quindi occupavano due pipeline) e si specifica meglio la FPU: più potente di quello che si pensava
Non solo. Si era ipotizzato anche che non erano due coppie di pipeline, ma lo FMAC si potesse ottenere solo combinando la FP3 con la FP1 o con la FP0. Devo rivedere al rialzo le mie stime dell'ipc (in realtà già con la l0 avevo cambiato idea).
12) La FPU può fare per ogni ciclo 2FADD+2FMUL o 2FADD+2FMAC. Se sono stati inteligenti le 2FMAC possono fare anche FADD e quindi si hanno fino a 4 addizioni a 128 bit per ciclo o 2 a 256 per ciclo. Non male.
Credo che l'equivoco sia nata proprio perchè le FP0 e FP1 non erano in grado di eseguire le FADD singole...
https://2.bp.blogspot.com/-eb5-vfWEsuE/VtSXfu9-gII/AAAAAAAABgE/-m1Ibsa4T_w/s1600/Zen-Architektur%2BCore%2BV0.3.2.png
Considerando la cache L0 enorme rispetto ad INTEL, il checkpointing, le porte (ben 10), il potenziale per superare di gran lunga INTEL c'è...
Questa è solo la prima iterazione e si posiziona tra Broadwell e Skylake...
Zen+ dal grafico postato da AMD sembrava che non fosse un piccolo miglioramento (anche se graficamente poteva non essere in scala), ma penso che in Zen+ si può fare anche più del +5-6% che ha fatto Intel con Skylake...
Sempre che con lo step ufficiale non si incrementi ulteriormente l'IPC rispetto allo step A0 e non si superi INTEL già adesso...
Vedremo... :D
Credo che l'equivoco sia nata proprio perchè le FP0 e FP1 non erano in grado di eseguire le FADD singole...
Mi sembra una assurdità... Basta mettere il moltiplicando a 1 e si trasforma in una addizione...
tuttodigitale
01-03-2016, 13:37
Mi sembra una assurdità... Basta mettere il moltiplicando a 1 e si trasforma in una addizione...
Nella vecchia Patch non compariva nessun riferimento delle FADD per fp0 e fp1.
Ma il moltiplicatore ad uno, immagino attuato con un registro speciale, dovrebbe essere posto prima dello scheduler, ovvero con la FADD, sostituita da una FMA con il riferimento al registro in questione (chiedo :D ). In tal caso si rischia di fare un pasticcio, ovvero far diventare tutte le istruzioni FADD delle FMA...
Nella vecchia Patch non compariva nessun riferimento delle FADD per fp0 e fp1.
Ma il moltiplicatore ad uno, immagino attuato con un registro speciale, dovrebbe essere posto prima dello scheduler, ovvero con la FADD, sostituita da una FMA con il riferimento al registro in questione (chiedo :D ). In tal caso si rischia di fare un pasticcio, ovvero far diventare tutte le istruzioni FADD delle FMA...
Gli sviluppatori sono liberi di implementarla in vari modi: possono creare una MOP dove il moltiplicando è cablato a 1 stesso dentro la FMAC, ma poi si spreca un codice e si rende la FMAC più complicata, oppure, se ad esempio esistono registri speciali con le costanti, come 0, 1, ecc, è il decoder che può mettere come moltiplicando uno di questi registri e usare la MOP della FMAC... Ci sono varie opzioni...
digieffe
01-03-2016, 16:52
Considerando la cache L0 enorme rispetto ad INTEL, il checkpointing, le porte (ben 10), il potenziale per superare di gran lunga INTEL c'è...
Questa è solo la prima iterazione e si posiziona tra Broadwell e Skylake...
Zen+ dal grafico postato da AMD sembrava che non fosse un piccolo miglioramento (anche se graficamente poteva non essere in scala), ma penso che in Zen+ si può fare anche più del +5-6% che ha fatto Intel con Skylake...
Sempre che con lo step ufficiale non si incrementi ulteriormente l'IPC rispetto allo step A0 e non si superi INTEL già adesso...
Vedremo... :D
In pratica con le info disponibili attualmente l'ipc di Zen sarebbe il 90-95% di skylake
Ed in ogni caso non meno del 90, o no?
fraussantin
01-03-2016, 17:02
Domanda nabba l'ipc( istruzioni per clock) di preciso in cosa consiste nei megahertz?
In pratica con le info disponibili attualmente l'ipc di Zen sarebbe il 90-95% di skylake
Ed in ogni caso non meno del 90, o no?
Probabile
Domanda nabba l'ipc( istruzioni per clock) di preciso in cosa consiste nei megahertz?
IPC e frequenza sono misure complementari. Le prestazioni sono date da IPC*frequenza. E' vero che una architettura ad IPC alto tenderà ad avere una frequenza minore a parità di processo e consumo, e viceversa, ma non sono collegati causalmente.
fraussantin
01-03-2016, 17:43
Probabile
IPC e frequenza sono misure complementari. Le prestazioni sono date da IPC*frequenza. E' vero che una architettura ad IPC alto tenderà ad avere una frequenza minore a parità di processo e consumo, e viceversa, ma non sono collegati causalmente.
E per capire esattamente che valore si intende per ipc .per dire l'ipc del 6700 quale è?
Ho googlato ma non ho trovato niente di preciso.
Piedone1113
01-03-2016, 17:46
E per capire esattamente che valore si intende per ipc .per dire l'ipc del 6700 quale è?
Ho googlato ma non ho trovato niente di preciso.
Perchè l'ipc è misurato su un certo numero di software non standardizzato, prendilo come un valore generico della bontà di un'architettura, un'indicazione e non una misura precisa.
fraussantin
01-03-2016, 17:50
Perchè l'ipc è misurato su un certo numero di software non standardizzato, prendilo come un valore generico della bontà di un'architettura, un'indicazione e non una misura precisa.
Ok capito ...
tuttodigitale
01-03-2016, 18:17
Gli sviluppatori sono liberi di implementarla in vari modi: possono creare una MOP dove il moltiplicando è cablato a 1 stesso dentro la FMAC, ma poi si spreca un codice e si rende la FMAC più complicata, oppure, se ad esempio esistono registri speciali con le costanti, come 0, 1, ecc, è il decoder che può mettere come moltiplicando uno di questi registri e usare la MOP della FMAC... Ci sono varie opzioni...Facevo appunto riferimento alla seconda opzione, e non mi pare questa gran genialata.:D . 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.:stordita:
tuttodigitale
01-03-2016, 18:26
In pratica con le info disponibili attualmente l'ipc di Zen sarebbe il 90-95% di skylake
Ed in ogni caso non meno del 90, o no?
OGGI (domani si vedrà) penso che avremo:
IPC ST = SB
IPC MT= 95% Skylake
penso che lo scaling del SMT di AMD sia superiore.
Free Gordon
01-03-2016, 18:49
Ora tutto sta nel vedere se riescono ad uscire a ottobre 2016...
I 10nm di Intel per quando sono previsti?
fraussantin
01-03-2016, 18:51
Ora tutto sta nel vedere se riescono ad uscire a ottobre 2016...
I 10nm di Intel per quando sono previsti?
Se non escono entro 1 anno rischiano che intel abbia già fatto una serie nuova e sia già obsoleti .
Debbono sbrigarsi.
Grizlod®
01-03-2016, 20:45
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.
Facevo appunto riferimento alla seconda opzione, e non mi pare questa gran genialata.:D . 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.:stordita:
4 FMAC improbabile, perchè il moltiplicatore costa molta area, ma non si sa mai... :D 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
02-03-2016, 11:48
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... :Prrr:
4 FMAC improbabile, perchè il moltiplicatore costa molta area, ma non si sa mai... :D
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....:D
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....:O
OMG. Ho detto tutto e il contrario di tutto. Ho senz'altro ragione:cool:
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....:O
OMG. Ho detto tutto e il contrario di tutto. Ho senz'altro ragione:cool:
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...
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
02-03-2016, 16:25
Facciamo i conti:
se non ti dispiace ti dò una mano. Probabilmente ti riferisci a PD.
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...
. 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
02-03-2016, 17:00
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?
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... :doh:
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! :eek: Sarà forse per il nuovo branch predicition di Jaguar? O la L1I da 96KB?
12 decoder per core?
Sta triplicando le risorse per avere la stessa area di XV a 28nm.
Hai ragione sui decoder... :doh:
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! :eek: 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
02-03-2016, 18:47
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 :muro:
Dai ti aiuto(copione:p). Hanno anche aumentato il branch target L1 del 50% (768e 3way)
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
03-03-2016, 00:46
Puma è identico a livello di architettura?
A parte le migliorie legate al processo produttivo, minor leakage ecc..
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
03-03-2016, 09:48
12 decoder per core?
come ha detto 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.
Cosa credi che siano le MOP? Sono solo delle istruzioni come le x86, ma a lunghezza fissa e con campi predeterminati e formattati...
:nonsifa: 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".:rolleyes:
:cincin:
:nonsifa: 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".:rolleyes:
:cincin:
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
03-03-2016, 12:35
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. :cool:
:mano:
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. :cool:
:mano:
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... :cool:
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/multifacet/papers/tr1813_stack_cache.pdf
tuttodigitale
03-03-2016, 14:13
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 :ciapet:
il link, è molto interessante.
stefanonweb
03-03-2016, 17:13
Scusate la domanda banale, ma il socket FM2+ che fine dovrebbe fare? Grazie.
tuttodigitale
03-03-2016, 17:54
ma il socket FM2+ che fine dovrebbe fare?
Soccombere.:D
In questo momento in commercio c'è un solo prodotto basato sui core excavator. Una delle tante ipotesi è che si possa avere prodotti AM4, di questo tipo, compatibili con FM2+.
le soluzioni ZEN sono tagliate fuori dal discorso compatibilità, perchè il MC non sarebbe in grado di lavorare con le ddr3.
paolo.oliva2
03-03-2016, 18:13
Domanda banale...
Io ancora non ho capito una cosa... il socket AM4 AMD lo ha dato per compatibile sia con gli APU che con Zen.
Visto che gli APU e Zen avranno il PCI integrato e simili, l'unica differenza è che un APU avrebbe la VGA integrata e Zen, per quanto si sa, non sarebbe APU.
Quello che mi viene da riflettere, è che un APU con l'opzione di disabilitare l'IGP, risulterebbe un normale procio. Però AMD ha di fatto integrato negli APU l'IGP con HSA e Huma e di fatto praticamente l'IGP non è disattivabile perchè altrimenti non funzionerebbe il procio. Ora... un socket che supporti gli APU con tali caratteristiche, come può un X86 (Zen) essere compatibile? HSA/Huma come fanno a funzionare su un socket che poi lo stesso socket prevederebbe un procio con caratteristiche diversissime? Va bene che può essere risolto tutto da bios, tramite riconoscimento modello procio e quindi attivazione o meno di parti di bios, ma così facendo, non sarebbe un lavoro disumano? Si raddoppierebbero le release di aggiornamento e comunque la complessità del tutto... e questo a che pro? Non riesco a trovarne la logica...
Non voglio alzare sabbia su un nulla... ma se Zen uscirebbe ad ottobre 2016 e nella pessimistica ai primi del 2017, qualsiasi sia l'opinione personale, comunque AMD comunque DEVE avere il progetto carta/silicio di come sarà Zen, o X86 o APU, le cose che possono variare, sono in base al PP finale del 14nm, tipo quale frequenza avrà, quale TDP, quanti core nel max TDP, ecc...
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 :ciapet:
il link, è molto interessante.
Mi pare che le istruzioni fondibili sono solo cmp e successiva jmp condizionale... Ma deve essere immediata e non indiretta... Quindi nessuno calcolo+accesso in memoria... Anche perchè solo le unità di load store hanno accesso alla memoria (l1 dati)... Se ci sono altri casi allora sono rimasto indietro... :stordita:
Domanda banale...
Io ancora non ho capito una cosa... il socket AM4 AMD lo ha dato per compatibile sia con gli APU che con Zen.
Visto che gli APU e Zen avranno il PCI integrato e simili, l'unica differenza è che un APU avrebbe la VGA integrata e Zen, per quanto si sa, non sarebbe APU.
Quello che mi viene da riflettere, è che un APU con l'opzione di disabilitare l'IGP, risulterebbe un normale procio. Però AMD ha di fatto integrato negli APU l'IGP con HSA e Huma e di fatto praticamente l'IGP non è disattivabile perchè altrimenti non funzionerebbe il procio. Ora... un socket che supporti gli APU con tali caratteristiche, come può un X86 (Zen) essere compatibile? HSA/Huma come fanno a funzionare su un socket che poi lo stesso socket prevederebbe un procio con caratteristiche diversissime? Va bene che può essere risolto tutto da bios, tramite riconoscimento modello procio e quindi attivazione o meno di parti di bios, ma così facendo, non sarebbe un lavoro disumano? Si raddoppierebbero le release di aggiornamento e comunque la complessità del tutto... e questo a che pro? Non riesco a trovarne la logica...
Non voglio alzare sabbia su un nulla... ma se Zen uscirebbe ad ottobre 2016 e nella pessimistica ai primi del 2017, qualsiasi sia l'opinione personale, comunque AMD comunque DEVE avere il progetto carta/silicio di come sarà Zen, o X86 o APU, le cose che possono variare, sono in base al PP finale del 14nm, tipo quale frequenza avrà, quale TDP, quanti core nel max TDP, ecc...
Che io sappia esistono anche APU low end senza IGP... Ovviamente serve per forza una scheda video... :stordita:
Puma è identico a livello di architettura?
A parte le migliorie legate al processo produttivo, minor leakage ecc..
Stessa architettura, ma hanno ridotto i consumi di parecchio(25w VS 15w) passando ad un layout con più parti full custom su silicio GF28HP.
La prima versione di jaguar aveva solo due parti custom per velocizzare il time-to-market e la portabilità verso altre fab.
ps. dimenticavo il nuovo turbo con sensore di temperatura.
tuttodigitale
03-03-2016, 20:22
Mi pare che le istruzioni fondibili sono solo cmp e successiva jmp condizionale...
ti sbagli.
tutte le istruzioni del tipo load-op possono essere fuse nelle CPU INTEL.
In più, le macro ops di AMD permettono di eseguire dei load-op-store, allo stesso indirizzo.
Stessa architettura, ma hanno ridotto i consumi di parecchio(25w VS 15w) passando ad un layout con più parti full custom su silicio GF28HP.
il TDP è ridotto di parecchio, il consumo molto meno, ma era già estremamente competitivo. A dispetto del TDP il consumo delle APU Kabini era assai ridotto:
http://www.tomshw.it/files/2013/05/immagini_contenuti/46087/power-gaming-avg_t.png
L'IB in questione è una soluzione da 17W, l'apu jaguar 15W. Anandtech aveva registrato consumi per l'intera piattaforma addirittura inferiori ai 20, con CPU a pieno carico l'intero sistema consumava appena 12W...
http://www.anandtech.com/show/6981/the-kabini-deal-can-amd-improve-the-quality-of-mainstream-pcs-with-its-latest-apu/2
meaning SoC power consumption is far lower, likely sub-10W
ti sbagli.
tutte le istruzioni del tipo load-op possono essere fuse nelle CPU INTEL.
In più, le macro ops di AMD permettono di eseguire dei load-op-store, allo stesso indirizzo.
Ah ok... Allora non sono più uop ma sono delle macroop... Immagino che le uop load op faranno 2 passaggi, uno nella AGU+LSU e uno nell'unità di esecuzione... Come le MOP AMD... Quindi hanno copiato da AMD... Perchè nei diagrammi delle CPU INTEL le AGU, le LSU e le unità di esecuzione normali, sono separate e su porte separate... Quindi giocoforza una load - op deve passare prima per la LSU+AGU in un registro e poi per l'unità di esecuzione... Proprio come fa AMD: c'è un calderone per le MOP e le uop componenti, nell'ordine giusto, vengono eseguite nelle varie unità e solo alla fine la MOP può essere ritirata...
Le load op store sono istruzioni CISC, hai ragione. Non ci avevo pensato. E mi viene in mente che le MOP AMD sono del tipo op, load-op, load-op-store o op-store, quindi a rigore, tranne la prima, sono tutte CISC... Chiedo venia... Immagino che tutto questo ben di dio sia stato brevettato e che lo abbia fatto AMD, visto che le MOP ci sono dal K7... Com'è che INTEL usa un meccanismo simile, anzi quasi uguale?
il TDP è ridotto di parecchio, il consumo molto meno, ma era già estremamente competitivo. A dispetto del TDP il consumo delle APU Kabini era assai ridotto:
http://www.tomshw.it/files/2013/05/immagini_contenuti/46087/power-gaming-avg_t.png
L'IB in questione è una soluzione da 17W, l'apu jaguar 15W. Anandtech aveva registrato consumi per l'intera piattaforma addirittura inferiori ai 20, con CPU a pieno carico l'intero sistema consumava appena 12W...
http://www.anandtech.com/show/6981/the-kabini-deal-can-amd-improve-the-quality-of-mainstream-pcs-with-its-latest-apu/2
Se cerci il beema da 15w vedrai che il clock è salito a 1.8ghz (jaguar 1.5), in più in turbo mode si ha una frequenza di 2.4ghz. Un bel miglioramento se pensi che è frutto del layout migliorato.
tuttodigitale
03-03-2016, 22:03
@bjt2, anche i migliori sbagliano :O. Sui brevetti boh, non saprei. Come ti dicevo Intel non le chiama macro-ops, anche se sono effettivamente più lunghe delle uop ordinarie...mi pare di ricordare che siano state introdotto addirittura con il pentium M.
Se cerci il beema da 15w vedrai che il clock è salito a 1.8ghz (jaguar 1.5), in più in turbo mode si ha una frequenza di 2.4ghz. Un bel miglioramento se pensi che è frutto del layout migliorato.
Nessuno lo nega. Ma capisci anche che se uno legge 25W->15W, 2->2,4GHz non pensa ad un miracolo di AMD, ma che kabini abbia una scarsa efficienza, cosa assolutamente errata.
http://www.anandtech.com/show/7974/amd-beema-mullins-architecture-a10-micro-6700t-performance-preview/2
Purtroppo con l'introduzione del turbo il marketing ci sguazza...
tuttodigitale
03-03-2016, 22:42
Purtroppo con l'introduzione del turbo il marketing ci sguazza...
Adesso, non fare l'errore contrario di sminuirli. Il passo in avanti è consistente..
http://images.anandtech.com/graphs/graph7974/63084.png
La differenza di efficienza NOMINALE è di 3x, anche ammettendo che il 63% è dovuto alla maggiore temperatura abbiamo un solido 1,8x (credo che non si sbagli ad ipotizzare un tdp reale per l'a4-5000 di 8W)
Peccato non ne esistano varianti desktop per farne un analisi completa senza turbo...:(
ps. i bench in giro sono pochi o mi sbaglio ?
Free Gordon
04-03-2016, 00:19
Stessa architettura, ma hanno ridotto i consumi di parecchio(25w VS 15w) passando ad un layout con più parti full custom su silicio GF28HP.
La prima versione di jaguar aveva solo due parti custom per velocizzare il time-to-market e la portabilità verso altre fab.
ps. dimenticavo il nuovo turbo con sensore di temperatura.
Ma quindi perchè non fare delle APU desktop per sistemi vesa10x10 da piazzare negli HTPC low cost? :muro: Ho notato che con le vecchie APU (e450 e simili), Netflix ad esempio si vede a scatti... o setti la qualità in low, oppure scatta..
Con apu del genere si potrebbe avere dei bei sistemini HTPC entro i 200 euro. Credo che molti opterebbero per AMD, potendo spendere un 50-70 in meno rispetto ad Intel.. :stordita:
Free Gordon
04-03-2016, 00:30
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.. :fagiano:
unnilennium
04-03-2016, 06:14
L'efficienza r una cosa, la potenza e un'altra... Come potenza jaguar non e che sia nulla di che, gia all'uscita, su desktop poi... Il ritardo nello sviluppo di tecnologia del processo produttivo e stato il maggior problema di amd, e lo stanno ancora subendo, meno male che almeno le console vanno bene, qualche soldo in tasca entra
Inviato dal mio PLK-L01 utilizzando Tapatalk
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.. :fagiano:
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.
riuzasan
04-03-2016, 10:14
Domanda banale...
Io ancora non ho capito una cosa... il socket AM4 AMD lo ha dato per compatibile sia con gli APU che con Zen.
Visto che gli APU e Zen avranno il PCI integrato e simili, l'unica differenza è che un APU avrebbe la VGA integrata e Zen, per quanto si sa, non sarebbe APU.
Quello che mi viene da riflettere, è che un APU con l'opzione di disabilitare l'IGP, risulterebbe un normale procio. Però AMD ha di fatto integrato negli APU l'IGP con HSA e Huma e di fatto praticamente l'IGP non è disattivabile perchè altrimenti non funzionerebbe il procio. Ora... un socket che supporti gli APU con tali caratteristiche, come può un X86 (Zen) essere compatibile? HSA/Huma come fanno a funzionare su un socket che poi lo stesso socket prevederebbe un procio con caratteristiche diversissime? Va bene che può essere risolto tutto da bios, tramite riconoscimento modello procio e quindi attivazione o meno di parti di bios, ma così facendo, non sarebbe un lavoro disumano? Si raddoppierebbero le release di aggiornamento e comunque la complessità del tutto... e questo a che pro? Non riesco a trovarne la logica...
Non voglio alzare sabbia su un nulla... ma se Zen uscirebbe ad ottobre 2016 e nella pessimistica ai primi del 2017, qualsiasi sia l'opinione personale, comunque AMD comunque DEVE avere il progetto carta/silicio di come sarà Zen, o X86 o APU, le cose che possono variare, sono in base al PP finale del 14nm, tipo quale frequenza avrà, quale TDP, quanti core nel max TDP, ecc...
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).
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.
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
Free Gordon
04-03-2016, 11:39
L'efficienza r una cosa, la potenza e un'altra...
Dicevo efficienza in ambito desktop inteso proprio come IPC ;)
Jaguar rispetto alla sua frequenza di funzionamento era decisamente veloce. Ecco anche perchè l'hanno inserito nelle console. :)
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.
Perchè dici "incidentalmente"? :D
Seguendo i primi leak sulle console, avevo letto delle difficoltà di far salire di frequenze gli 8 core Jaguar all'interno dell'APU oltre gli 1.6ghz prestabiliti..
Al di là dell'inserimento all'interno di un'APU (con tutti i maggiori problemi di calore e leakage intrinsechi ecc ecc), c'è qualche ragione per cui non avrebbero potuto produrre un'architettura Jaguar 2° con clock molto più alti?
Considerando la resa a 1.5ghz...un Jaguar/Puma al doppio del clock (ma consumi molto più alti degli attuali 25W ovviamente..) che valori potrebbe restituire? :D
tuttodigitale
04-03-2016, 11:39
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.
basti pensare che le HDL, che sono state il principale artefice del salto qualitativo di bulldozer, sono state impiegate anche da kabini.
L'ipc di SR nel MT, penalizzato dal CMT, era già superiore a quello di Jaguar. Sul buon ipc di Kabini (siamo sotto a PD nel ST, è meglio essere chiari) la pipeline molto più corta (indicativamente 15 vs 22 stadi) gioca un ruolo fondamentale.
tuttodigitale
04-03-2016, 11:44
Dicevo efficienza in ambito desktop inteso proprio come IPC ;)
Jaguar per rispetto alla sua frequenza di funzionamento era decisamente veloce. Ecco anche perchè l'hanno inserito nelle console. :)
ma quello dell'ipc superiore di jaguar/puma, è una leggenda...
http://www.extremetech.com/wp-content/uploads/2014/01/Kabini-Kaveri.png
queste sono le prestazioni MT,
EDIT
ho tolto i riferimenti al MT, poichè in quei test ci potrebbero essere anche riferimenti a prestazioni ST, anche se visto l'ampio gap tra SR e PD lo escluderei.
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...
Perchè dici "incidentalmente"? :D
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
04-03-2016, 14:42
salve a tutti, cosa ne pensate?
http://forums.anandtech.com/showthread.php?t=2465958
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).
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.. :fagiano:
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 :sofico: .
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.
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!
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
04-03-2016, 18:53
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.
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:D
PS abbiamo visto che fine ha fatto l'alto clock di k10...
Free Gordon
04-03-2016, 19:06
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 :)
Il progetto è nato con budget e tempi ridotti, ma con concetti migliori di bulldozer :sofico:
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.
:sperem: :sperem: :sperem:
Free Gordon
04-03-2016, 19:10
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..
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
poi neppure le CPU da alte prestazioni da smartphone hanno pochi stadi (la CPU ARM by keller ne ha 16), perchè dovrebbe
averli ZEN:D
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 ? :confused:
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à:p .
IBM non ha di certo abbassato il clock del p7+ con i 32nm :sofico: .
paolo.oliva2
04-03-2016, 21:43
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.
:confused:
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è.
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
05-03-2016, 15:22
Quindi confermi abbastanza quello che dicevo, no?
Io non confermo niente!:D
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. :read:
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...
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
05-03-2016, 16:52
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à:p .
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 :ciapet: . 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....)
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.
IBM non ha di certo abbassato il clock del p7+ con i 32nm :sofico: .
OMG, stai parlando dello stesso power 7+, che doveva superare i 6 GHz?
http://www.bitsandchips.it/recensioni/50-enterprise-business/1425-ibm-presentera-power-7-allhot-chips-di-agosto-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
05-03-2016, 16:58
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 :cool:
AZZ mi smentisci così, subito :cool:
Cosa avrei smentito? :stordita: :D
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...
OMG, stai parlando dello stesso power 7+, che doveva superare i 6 GHz?
http://www.bitsandchips.it/recensioni/50-enterprise-business/1425-ibm-presentera-power-7-allhot-chips-di-agosto-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 :sofico:,sembra il libro dei sogni di intel prescott...
http://image.slidesharecdn.com/20130208annuncipower7plussitocta-130405173336-phpapp01/95/2013-02-08-annunci-power-7-plus-sito-cta-7-638.jpg?cb=1365183251
Il clock è aumentato del 20%, più gli acceleratori, la cache quasi tripla e SIMD+.
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.
Cosa avrei smentito? :stordita: :D
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... :angel: :ops:
tuttodigitale
05-03-2016, 17:53
Ma che news hai preso :sofico:,sembra il libro dei sogni di intel prescott...
http://image.slidesharecdn.com/20130208annuncipower7plussitocta-130405173336-phpapp01/95/2013-02-08-annunci-power-7-plus-sito-cta-7-638.jpg?cb=1365183251
Il clock con tutti i core attivi è aumenato del 20%, più gli acceleratori, la cache quasi tripla e SIMD+.
Sono valori (volutamente) indicativi. Il power7 i 3 GHz non sa neppure cosa siano: il modello a frequenza più bassa ha 3,3GHz di frequenza base
Il modello 7, più potente ha una frequenza di 3,7-4,25 , quello 7+ 3,72-4,42GHz (si quel + vicino a GHz indica un formidabile +0,4%) raggiunti spegnendo la metà dei core
Di certo ci saranno dei carichi di lavoro dove le cache faranno enormi differenze.
Visto che oggettivamente l'aumento di frequenza è miserabile...vediamo cosa offre lato IPC
dati IBM (HPC Performance Report)
Power 7+ 3,6GHz 8 core 102,4
Power 7 3,7GHz 8 core 101,6
per un pauroso aumento di IPC del 3,6%...
Se l'ufficio marketing parla di un'aumento del 15% (purtroppo non riesco a trovare il link) lato efficienza perchè attendersi di più?
Tuttodigitale è un aficionado delle pipe lunghe... :angel: :ops:
Adesso lo sa anche bjt2. Doveva essere un segreto:p
Accorciarle è un conto, corte è un 'altro.:read: Se saranno lunghe 18 stadi, keller mi farà contento :D .
Questo ci dice che le unità di Zen sono più "chiattone" da poter fare in meno cicli le operazioni...
Non deve essere né "chiatta" nè uno "Stuzzicadente", ma deve essere una "bella gn:sofico: ...unità"
scusa se chiedo, riusciresti a spiegarti meglio? :D
hanno accorciato la pipe nel caso delle moltiplicazioni intere da un minimo di 3 ad un massimo di 4 contro i 4 e 6 di BD? cioè la pipe è più corta da 1 a 2 stadi in meno?
perché alcuni stadi hanno un FO4 superiore ad altri? :fagiano:
Le unità più complesse come le moltiplicazioni sono pipelined, ossia vengono eseguite in più passi, perchè se fossero fatte con meno passi gli stadi della pipeline avrebbero un FO4 più elevato. Diminuire la latenza delle moltiplicazioni significa che servono meno stadi di pipeline per farla, ossia ogni stadio può fare una operazione più complicata, quindi è più complesso, ossia ha un maggiore FO4, da cui clock più basso.
Se il moltiplicatore ha un FO4 più alto vuol dire che anche gli altri stadi hanno un FO4 più alto altrimenti farebbe da tappo, quindi hanno aumentato il FO4 di tutti gli stadi. Questo vuol dire che tutti gli stadi sono più complessi e quindi ci vogliono meno stadi per fare tutto... Quindi questo ci dice che Zen ha meno stadi. E' vero che il clock massimo diminuisce, ma diminuisce anche il numero di cicli necessari per fare alcune operazioni... E sopratutto la latenza per le branch misprediction, anche se con il checkpointing dovrebbe essere ancora minore...
tuttodigitale
05-03-2016, 20:50
Spiegazione semplice e chiara.
Vedo che hai trovato il tempo di postare..... :read:
A dopo
EDIT
partita finita :)
Vedo che la divisione ha sempre un costo di 19 cicli. Ho la sensazione, che la riduzione del costo, sia ottenuto mediante manipolazione funzionali. Ovvero piuttosto che una sola ALU completa, si sia optato ad un frazionamento del compito su più ALU, In sostanza l'ALU non ha stadi grossi, ma fa meno cose. Il risultato sarebbe si una riduzione degli stadi complessivi, ma senza compromettere il FO4.
bjt2 sei a conoscenza delle funzioni delle diverse ALU?
Ho fatto confronti, alla buona, e mi pare che non ci siano sostanziali differenze(ad una prima occhiata mi sono apparsi identici), tra il costo di manipolazione dei dati nei registri della CPU tra ZEN e Bulldozer e ciò vale anche per l'esecuzione delle istruzioni FADD, FDIV e FMUL. Questi dati possono anche non essere corretti, ovviamente.
paolo.oliva2
05-03-2016, 22:46
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.
Precisando, io non è che dico che non esistano differenze, però dico che ci deve essere una coerenza per quanto riguarda i giudizi.
Se si guarda il lato prestazionale massimo, nessuno può dire che Intel non sia più prestazionale, ma la cosa non equivale a dire con la stessa spesa. Quello che voglio dire, è che indubbiamente un 6700K va di più di un 8370, però con i 200€ in più di procio, a parità di spesa magari si avrebbe il sistema 6700K con un SATA 3 normale ed un sistema con l'8370 con un SD, dove il chip-set SB950 comunque offrirebbe prestazioni superiori.
Poi volevo aggiungere, se da una parte si considera che un 2 core soddisfa il 90% delle pretese della massa, non mi sembra sullo stesso metro considerare che la maggior parte degli utilizzatori abbia più di una periferica USB 3.0 (io non ne ho manco 1), come sistemi SD o CF da favola o qualsivoglia.
Non è solamente AMD ad avere problemi con Windows 10. Ho un i7 5500U (Lenovo) con chip-set Intel Broadwell-U rev 09 e SB Intel Broadwell-U PCH L-P rev 03, aggiornato da windows 8.1 a Windows 10, ho problemi sia con la rete (mi riporta che mancano dei pacchetti ed invece ci sono tutti) e la cosa rognosa, inspiegabile, è che ho 3 penne USB, e se faccio operazioni lettura/scrittura su una penna, disattivandola a fine operazioni, dopo un certo tempo (1h come 5h) il sistema si resetta :confused:. Ci ho messo 1 mese per capire... all'inizio pensavo al caldo (solo torrent attivo e CPU a 65° addirittura in turbo fisso a 3GHz), ma scaricando con torrent e avendo la rete che non mi va, l'unico modo per passare i dati è con le penne. Caso vuole che per 1 settimana non ho trasferito i dati con le penne e nessun riavvio... poi le ho usate e dopo i problemi, anche se disattivate e sembra tutto ok, passa del tempo e mi ritrovo il sistema che è ripartito.
Spiegazione semplice e chiara.
Vedo che hai trovato il tempo di postare..... :read:
A dopo
EDIT
partita finita :)
Vedo che la divisione ha sempre un costo di 19 cicli. Ho la sensazione, che la riduzione del costo, sia ottenuto mediante manipolazione funzionali. Ovvero piuttosto che una sola ALU completa, si sia optato ad un frazionamento del compito su più ALU, In sostanza l'ALU non ha stadi grossi, ma fa meno cose. Il risultato sarebbe si una riduzione degli stadi complessivi, ma senza compromettere il FO4.
bjt2 sei a conoscenza delle funzioni delle diverse ALU?
Ho fatto confronti, alla buona, e mi pare che non ci siano sostanziali differenze(ad una prima occhiata mi sono apparsi identici), tra il costo di manipolazione dei dati nei registri della CPU tra ZEN e Bulldozer e ciò vale anche per l'esecuzione delle istruzioni FADD, FDIV e FMUL. Questi dati possono anche non essere corretti, ovviamente.
Per quanto riguarda la divisione, l'algoritmo più semplice è iterativo e con iterazioni fisse dove è calcolato 1 bit alla volta. L'algoritmo è lo stesso che si impara alle elementari dove però si ricava una cifra alla volta, ovviamente in binario si ricava 1 bit alla volta... Una prima ottimizzazione è non fare iterazioni fisse ma uscire prima se ci sono meno bit da calcolare. Un'altra ottimizzazione è calcolare più di un bit per ciclo. Se la latenza è 19 cicli, allora probabilmente l'unità di Zen è da 2 bit/ciclo (immagino che valga per le divisioni a 32 bit). Mi pare che INTEL sia arrivato anche a 4 bit per ciclo...
Sulle latenze delle FADD non c'è molto da fare... L'addizione è semplicissima e un ciclo basta, non c'è molto da migliorare, ma il problema con i numeri floating point è che ci sono varie operazioni da fare prima e dopo per cui una operazione FP impiega almeno 3 o 4 cicli...
Penso che anche per il moltiplicatore si sia aggiunto altro hardware e si è ridotto i cicli, calcolando più bit per stadio... Se non mi sbaglio la moltiplicazione è più semplice: addizioni e shift che non occupano spazi, perchè sono un semplice spostamento di bit,... Resta solo da vedere quanti bit calcoli in un ciclo di clock... Per passare da 6 a 4 hanno aumentato almeno di una volta e mezzo i bit calcolati, e quindi almeno di una volta e mezzo gli addizionatori in cascata e quindi il FO4... Anzi possiamo calcolare il numero di addizioni per ciclo: se 4 cicli è la 64 bit allora sono almeno 16 bit per ciclo, ecc... Anche qui l'algoritmo è lo stesso che si studia alle elementari, ovviamente con cifre binarie...
tuttodigitale
06-03-2016, 08:21
@bjt2
Per una volta e mezzo, intendi + 50% o +150%?
Mister D
06-03-2016, 11:49
grazie :)
ma FO4 di BD non era già alto nonostante avesse pipeline lunghe e propensione ad alti clock e quindi stadi meno complessi?
quindi che senso avrebbe diminuire la pipe se però come effetto hai che ti aumenta ulteriormente FO4? non sarebbe controproducente?
FO4 è un numero che indica fisicamente che cosa? 10 o 20, per esempio, ma cosa cosa, nanosecondi? tuttodigitale mi aveva spiegato che è il tempo quindi ritardo che impiega il segnale ad attraversare lo stadio, se non ricordo male
Ciao,
no il FO4 (ritardo normalizzato di una pipeline) è inversamente proporzionale alla lunghezza delle stessa pipeline.
Per es il Pentium IV aveva FO4 di 13 e un sacco di stadi (pipeline molto lunga) perché il progetto aspirava a frequenze elevatissime e impossibili.
BD ha FO4 di 19 mentre i vecchi phenom II sopra i 22 se la memoria non mi inganna.
Quindi:
FO4 elevato -> pipe corte -> frequenza massima poco elevata
FO4 basso -> pipe lunghe -> frequenza massima elevata.
Chiaro che poi c'entrano le latenze che sono collegate e ancora di più il silicio. Trovo giusto che abbiano pensato di alzare un po' il FO4 perché passare dal soi al bulk perdi in leakage e quindi in frequenza massima. Se poi si pensa che ultimamente tutti i pp sono più orientati al mobile o cmq ai bassi consumi e che il finfet da appunto una mano in questo piuttosto che in frequenze alte, per me sarebbe ottimo Zen con un FO4 intermedio, a metà tra BD e i vecchi phenomII, in modo da ottimizzare l'efficienza su frequenze più basse di quelle che avrebbero dovuto avere BD e le varie evoluzioni (ho scritto volutamente averebbero dovuto avere e non quelle che hanno avuto).;)
@bjt2
Per una volta e mezzo, intendi + 50% o +150%?
+50%
Se per calcolare 32 bit di prodotto adotto stadi che calcolano 8 bit, ci vorranno 4 cicli, se ne adotto stadi da 12 bit (+50%) ce ne vorranno circa il 50% in meno, in questo caso 3. Più un ciclo extra per un po' di margine.
Poichè abbiamo 6 e 4 cicli per BD e 4 e 3 cicli per Zen, possiamo ipotizzare che si è passati da 13 a 22 bit per ciclo, in questo caso il 70% in più. Se non ci volesse il ciclo "morto" (non sono così esperto di pipeline, quindi non lo so per certo... :D) allora saremmo a 11 vs 16, circa il 50% in più...
grazie :)
ma FO4 di BD non era già alto nonostante avesse pipeline lunghe e propensione ad alti clock e quindi stadi meno complessi?
quindi che senso avrebbe diminuire la pipe se però come effetto hai che ti aumenta ulteriormente FO4? non sarebbe controproducente?
FO4 è un numero che indica fisicamente che cosa? 10 o 20, per esempio, ma cosa cosa, nanosecondi? tuttodigitale mi aveva spiegato che è il tempo quindi ritardo che impiega il segnale ad attraversare lo stadio, se non ricordo male
In realtà il FO4 indica la complessità di uno stadio di pipeline. FO4 significa Fan Out 4, ossia il ritardo, normalizzato ad un numero di stadi con fan out 4, ossia ad esempio una porta AND, l'uscita di un addizionatore, ecc, caricato con 4 porte NOT. Quindi FO4 12 significa che lo stadio di pipeline ha un ritardo pari a una cascata di 12 porte logiche che ognuna a loro volta alimentano 4 altre porte logiche.
Quindi è un indice di complessità del circuito... Ad esempio un moltiplicatore ha FO4 proporzionale al numero di bit per ciclo che calcola. Se in uno stadio di pipeline voglio avere un moltiplicatore che calcola x bit per ciclo, avrò un ritardo dato dal FO4 del moltiplicatore, più quello della circuiteria che fa il loop e shift per calcolare in 32/x e 64/x passi il prodotto a 32 o 64 bit...
Si devono progettare gli stadi in modo da avere lo stesso FO4 massimo, perchè è quello che limiterà il clock. Se ci sono stadi con FO4 diversi, quelli con un FO4 più basso sono stati implementati con un FO4 inutilmente basso (e quindi magari ad esempio un moltiplicatore più lento) perchè da limitatore al clock farà un altro stadio con FO4 più alto.
Il fatto che il moltiplicatore ha diminuito la latenza, significa che hanno potuto aumentare x e quindi il FO4 perchè hanno aumentato il FO4 di tutti gli altri stadi e quindi anche gli altri stadi sono diventati più complessi.
Il fallimento dei design ad alto clock, oltre al limite del processo, è anche colpa di questo sistema: se io devo fare un design ad alto clock, devo ridurre il FO4, quindi ad esempio un moltiplicatore lo farò di x/2 bit anzichè x bit e ci metterò il doppio del tempo. Ma il FO4 non si dimezza perchè ho ancora più o meno la stessa circuiteria che mi deve fare il loop e shift... Mettici che dimezzando il FO4 non raddoppio il clock per i limiti e non linearità del processo ed ecco che non conviene fare processori con clock alto... Finchè le addizioni le riesci a fare in un solo ciclo, ti puoi spingere a scendere il FO4, ma oltre non conviene... Non conviene neanche fare il FO4 troppo alto, perchè magari riesci a fare le moltiplicazioni in 1-2 cicli, ma le addizioni meno di un ciclo non ci puoi mettere e per fare le MUL in 1-2 cicli dimezzi il clock... Ma le ADD sono molto più frequenti delle MUL, quindi si cerca un compromesso... Pochi cicli per MUL e DIV ma non troppo oltre con il FO4... Questo ovviamente trascurando il costo: fare pipeline corte costa anche meno transistors e quindi meno area... Analogamente per fare MUL da 1-2 cicli, oltre a non avere un clock alto, avrai anche alta area, alto leakage e alto costo... Quindi è tutto un compromesso a seconda di quello che vuoi fare...
digieffe
06-03-2016, 12:32
Visto il basso TDP (95w) di Zen X8 (è probabile che il clock di base si fermi a 3.0ghz) e tenendo conto che l'ipc di zen dovrebbe essere (pessimisticamente) il 90% di broadwell ne conseguirebbe che avrebbe le stesse prestazioni dell' Intel Core i7-6850K http://wccftech.com/intel-broadwell-e-specifications-leaked-core-i7-6950x-flagship-processor-10-cores-20-threads-core-i7-6900k-core-i7-6850k-core-i7-6800k-detailed/.
dato che l' Intel Core i7-6850K sarà prezzato a ~550$ e Intel Core i7-6800K a ~390$ mi sembra improbabile che sarà prezzato a meno di quest'ultimo (~400$) ...
tuttodigitale
06-03-2016, 14:02
@ bjt2
gli stadi che eseguono una MUL sarebbero scarsamente ottimizzati, visto che si passerebbe, valori indicativi, da un FO4 16 (2 bit/ciclo)- FO4 24 (3bit ciclo)-FO4 32 (4bit/ciclo).
A livello software, lo saprai meglio di me, ci sono algoritmi molto più avanzati, rispetto a quello elementare, e non c'è nessuna ragione per pensare che la soluzione sia utilizzare l'algoritmo X implementato in HW, ripetuto 1-2-3-4 volte in base alla lunghezza dello stadio.
Secondo me, rifanno completamente il moltiplicatore...
Sulle DIV, appunto, se utilizzano stadi molto più lunghi (50%), perchè la divisione intera richiederebbe 19 colpi di clock esattamente quanto bulldozer?
Sulle istruzioni floating point (FDIV, FADD e FMUL) idem. Anzi la FMUL che condivide parte degli algoritmi della MUL semplice, dovrebbe subire una riduzione di cicli. Eppure non è così.
Io sono convinto che il FO4 dipenda non solo da quanti bit macini per ciclo e dall'algoritmo usato, ma anche dalle funzioni della singola ALU.
Nel senso ho una pipeline che esegue sia moltiplicazione che divisioni. E' chiaro che lo stadio di questa pipeline sarà enormente più complesso di una che esegue un solo tipo di operazioni. Tenendo a mente che per attivare una funzionalità o l'altra è necessario fare ricorso ad una rete combinatoria, che introduce latenza, da quel poco che so di elettronica, direi che la partizione delle funzionalità su diverse pipeline, è un primo fattore che può ridurre il numero di stadi senza compromettere il FO4. Tanto più che in questo caso si parla di una riduzione della latenza solo per l'istruzione MUL.
Questo significherebbe anche che le 2 unità FMAC sono in grado di eseguire le FADD, vista l'identica latenza tra le unità bulldozer e ZEN.
@ bjt2
gli stadi che eseguono una MUL sarebbero scarsamente ottimizzati, visto che si passerebbe, valori indicativi, da un FO4 16 (2 bit/ciclo)- FO4 24 (3bit ciclo)-FO4 32 (4bit/ciclo).
Ho parlato di implementazione triviale della MUL, ovviamente è possibile, con l'adeguato hardware e consumo di area, fare in parallelo gli n bit e non in cascata e poi sommarli in parallelo, avendo così un ritardo di solo 2 stadi, con il secondo un ritardo maggiore perchè è un adder di n addendi, che può essere fatto in cascata 2 a 2, 3 a 3, ecc... Le soluzioni sono molteplici e mi pento di non aver fatto il piano di studi personalizzato all'università per includere l'esame "architettura dei sistemi integrati" dove si studiano a fondo tutte queste cose...
si intendevo dire che l'FO4 di BD è troppo alto rispetto alla lunghezza delle sue pipe ed il suo clock infatti doveva essere più elevato di quello che poi è stato
19 non mi sembra poi chissà che risultato
grazie ancora, cercherò di capire al meglio quanto hai scritto :asd:
in sostanza un FO4 elevato non è per forza negativo se ad ogni ciclo mi permette di elaborare molti più bit rispetto ad uno basso
è tutto un trovare un giusto compromesso, ma dopo tutti questi anni ancora non sono arrivati a trovare l'equilibrio adatto? ok che dipende dal silicio, ma bene o male si è capito da anni che la corsa ai ghz è finita.
domanda 1: come mai parlate sempre di tutto ma mai delle SUB? :stordita:
domanda 2: per stadi di una pipeline potete fare esempi pratici? cioè una pipe da 10 o 20 stadi che differenze può avere negli stadi stessi? ci sono stadi "fissi" e/o "variabili" e/o "secondari"? creano stadi nuovi? uno stadio in se in cosa consiste?... ecc?
scusate la nabbaggine :fagiano:
1) Sub e add cambia solo il segno di uno degli operandi, quindi è semplicissimo
2) E' molto complicato da spiegare in un post... :asd: Operazioni complicate possono essere divise in stadi e poi si può fare uno stadio più corto... Per le operazioni aritmetiche è più facile perchè sono operazioni ripetitive quindi è facile fare un solo passo e poi fare dei cicli (come le MUL) come implementazione base o replicare tutto come implementazione più veloce, ma per operazioni complicate come la decodifica delle istruzioni x86 ogni passo è diverso, quindi semplicemente per diminuire il FO4 e aumentare il clock, si spezza ad esempio a metà uno stadio e vi si mettono dei registri che tengono i risultati intermedi, comandati dal clock... Questo permette di aumentare il clock...
sul SUB ci ho pensato appena l'ho scritto :D
sei stato chiarissimo, forse la mia domanda meno :fagiano:
ma ad esempio (porto questo esempio perché è il primo che mi è saltato in mente e che si trova facile):
http://www.realworldtech.com/wp-content/uploads/2014/03/Fig1.gif
l'unica differenza che vede "il mio occhio" è che in Jaguar (28nm) rispetto a Bocat (40nm) lo stadio "iDec" è stato aggiunto.
quindi quello che volevo dire è che ci sono degli "stadi" considerati "standard" "default" da cui partire per creare la pipe?
alcuni "conosciuti" ma di cui si può fare a meno?
alcuni che devono ancora essere "inventati" :sofico: ?
:help:
comunque non temere queste pagine finiscono dritte tra i miei preferiti :read:
Semplicemente il lavoro di decodifica che era diviso in 3 stadi, è stato riunito e ri-spezzato in 4 stadi... I nomi sono solo indicativi... :D
Probabilmente il limitatore del clock era lo stadio di decodifica e quindi hanno cercato di diminuire il FO4...
quindi non c'è nulla di cui "inventarsi" a livello di pipe/stadi?
Il decoding può essere fatto in vari modi e AMD ha una tecnica innovativa (e penso brevettata, visto che INTEL non la usava) di memorizzare il predecoding in bit aggiuntivi della L1 istruzioni, come limiti di istruzione e informazioni di branch predicition, velocizzando il decoding e la previsione per le istruzioni già in cache e accorciando le pipeline. Per il resto le operazioni da fare in serie sono abbastanza definite... Resta solo da definire dove spezzare per formare gli stadi...
tuttodigitale
08-03-2016, 12:33
quindi non c'è nulla di cui "inventarsi" a livello di pipe/stadi?
Le pipeline aggiuntive possono servire anche per mantenere il FO4 inalterato. La fase di decodifica non viene certamente fatta allo stesso modo. Anzi in jaguar neppure il set di istruzioni è il medesimo.
Un ultimo particolare, in Jaguar non c'è una vera e propria fase di pre-decodifica, tipica dei grandi core AMD e Intel, nella quale vengono predeterminate le dimensioni dell'istruzione e salvate nella cache. Cioè le innovazioni di Jaguar sono da intendersi come quelle atte a risparmiare energia. Può capitare che queste vengono trasportate sui modelli di punta (vedi algoritmo di branch prediction e HDL di Jaguar in Excavator o il clamoroso caso Pentium M->cpu high end), ma non è certamente la prassi.
c'è la possibilità che in Zen siano riusciti ad accorciare la pipe lasciando inalterato FO4?
ciò vorrebbe dire avere quasi certamente le stesse frequenze di funzionamento di excavator considerando anche il fatto che si passa ad un processo più avanzato (essendo che FO4 è legato anche al livello/qualità del processo)?
Tutto è possibile, perché questi aspetti della pipeline non sono quasi mai pubblici. Ovviamente disegnare una pipeline ad alta frequenza con "meno stadi" non è semplice, inoltre presuppone un layout su silicio impeccabile.
Il vecchio K10(45nm) con soli 12stadi dava una pista al nehalem che ne aveva 17...
Apple ad esempio è passata da 16stadi a 9 (misspredict) aumentando di molto il clock (+40-50% ipad) anche se aiutata dal finfet. Tanto per cambiare hanno ridotto anche la dimensione del core (senza cache), che rimane più grande degli A57-72, ma lontano da skylake (x86 non aiuta).
Ancora oggi non mi spiego del tutto come hanno compiuto un miracolo simile...
ps. gridrace hai PM
paolo.oliva2
08-03-2016, 21:21
Vorrei un chiarimento, se possibile.
Per chi segue BD da Zambesi, si ricorderà che all'inizio Excavator era stato annunciato come un raddoppio di parti logiche di Steamroller. A posteriori, sembra facile intuire che l'Exavator di cui si parlava fosse in realtà Zen e che invece l'Excavator reale (probabilmente per i limiti di disponibilità silicio 28nm Bulk) fosse in realtà un perfezionamento di Steamroller con il passaggio Kaveri-Carrizo.
Io cerco un attimo di capirci, anche se a priori CMT e SMT sono praticamente opposti. Però... se parliamo di pipeline, mi sembra di capire che Zen sia più simile a BD di quanto lo sia Intel/SMT. Anche commercialmente, AMD mi sembra propensa a commercializzare Zen con un numero di core/TH superiore a Intel (Zen dovrebbe essere minimo X4/8TH, l'offerta Intel minima è X2/4TH).
Quello che faccio fatica a collegare, è che se da una parte AMD diciamo potrebbe raggiungere il 90% dell'IPC di Intel (copio quanto postato da altri Digieffe), non comprendo perchè AMD commercializzerebbe un die la cui offerta base avrebbe un numero di core doppio dell'equivalente Intel. :confused:
Sintetizzando, se Intel commercializza un X2+2 vs AMD X4, una volta che AMD aumenta l'IPC e inserisce l'SMT, commercialmente non sarebbe più valido offrire gli stessi numeri di core per contenere il prezzo e piazzarlo sul mercato al prezzo più competitivo possibile?
@Digieffe
Posso anche concordare con te sul discorso che Zen X8 abbia un prezzo a cavallo tra il 6850K e 6800 (anche se fare una correlazione di numero core senza sapere l'effettiva potenza ed ancor più la grandezza die è azzardato), però bisogna vedere l'offerta Zen per intero.
Ammesso che Zen venga offerto anche come X4/X6, AMD potrebbe avere un prezzo molto aggressivo perchè potrebbe sfruttare il fatto che un utente Intel dal 6700K agli i7 >X4 cambia il socket e di qui l'obbligo di cambiare mobo. Poi non è detto che Zen X8 non sia APU (con ovvie implicazioni HSA/Huma).
digieffe
08-03-2016, 21:50
Vorrei un chiarimento, se possibile.
Per chi segue BD da Zambesi, si ricorderà che all'inizio Excavator era stato annunciato come un raddoppio di parti logiche di Steamroller. A posteriori, sembra facile intuire che l'Exavator di cui si parlava fosse in realtà Zen e che invece l'Excavator reale (probabilmente per i limiti di disponibilità silicio 28nm Bulk) fosse in realtà un perfezionamento di Steamroller con il passaggio Kaveri-Carrizo.
Io cerco un attimo di capirci, anche se a priori CMT e SMT sono praticamente opposti. Però... se parliamo di pipeline, mi sembra di capire che Zen sia più simile a BD di quanto lo sia Intel/SMT. Anche commercialmente, AMD mi sembra propensa a commercializzare Zen con un numero di core/TH superiore a Intel (Zen dovrebbe essere minimo X4/8TH, l'offerta Intel minima è X2/4TH).
Quello che faccio fatica a collegare, è che se da una parte AMD diciamo potrebbe raggiungere il 90% dell'IPC di Intel (copio quanto postato da altri Digieffe), non comprendo perchè AMD commercializzerebbe un die la cui offerta base avrebbe un numero di core doppio dell'equivalente Intel. :confused:
Sintetizzando, se Intel commercializza un X2+2 vs AMD X4, una volta che AMD aumenta l'IPC e inserisce l'SMT, commercialmente non sarebbe più valido offrire gli stessi numeri di core per contenere il prezzo e piazzarlo sul mercato al prezzo più competitivo possibile?
@Digieffe
Posso anche concordare con te sul discorso che Zen X8 abbia un prezzo a cavallo tra il 6850K e 6800 (anche se fare una correlazione di numero core senza sapere l'effettiva potenza ed ancor più la grandezza die è azzardato), però bisogna vedere l'offerta Zen per intero.
Ammesso che Zen venga offerto anche come X4/X6, AMD potrebbe avere un prezzo molto aggressivo perchè potrebbe sfruttare il fatto che un utente Intel dal 6700K agli i7 >X4 cambia il socket e di qui l'obbligo di cambiare mobo. Poi non è detto che Zen X8 non sia APU (con ovvie implicazioni HSA/Huma).
ipotizzo che, tra frequenza ed ipc, Zen X8 non andrà meno dell X6 di punta intel, di conseguenza Zen X6 andrà oltre il 4+4 intel, resta da capire Zen X4 come si posizionerà.
tenedo conto che Amd deve recuperare mercato, ipotizzo a parità di prestazioni prezzi inferiori, ma non tanto da andare sotto il modello con meno core.
quindi se il modello di pari prestazioni (6850k) Intel lo vende a 500+ $ Amd vendererà Zen x8 a meno, ma non meno del 6700k in quanto ci sarà Zen x6 (già più potente di quest'ultimo) da vendere a prezzo leggermente inferiore.
tuttodigitale
08-03-2016, 22:23
c'è la possibilità che in Zen siano riusciti ad accorciare la pipe lasciando inalterato FO4?
ciò vorrebbe dire avere quasi certamente le stesse frequenze di funzionamento di excavator considerando anche il fatto che si passa ad un processo più avanzato (essendo che FO4 è legato anche al livello/qualità del processo)?
Il fo4 di un architettura non dipende dal silicio. Non a caso ti avevo detto che è una misura della latenza di uno stadio NORMALIZZATA.
Nella migliore delle ipotesi, sul silicio, anche un eventuale aumento di fo4 non impedirà un incremento di clock..
Le pipeline della patch, lato integer si sono accorciate di 1-2 stadi. Questo è un dato di fatto. Sul fo4 è difficile sbilanciarsi: se le latenze (le patch su zen dicono questo ad oggi) sulla FPU rimangono alte, identiche a quelle di BD, possiamo esser certi che il fo4 è invariato.
Per il momento, direi che hanno mantenuto il fo4 basso (alto clock) e accorciato le pipeline per mezzo di modifiche funzionali alle ALU (mia speculazione, ovviamente).
tuttodigitale
08-03-2016, 22:42
[QUOTE=Ren
A9 ha 16 stadi non 9.
Su k10 e le sue pipe corte con fo4 Bassini, c'è da considerare che quando noi diciamo che un modulo BD è circa uguale ad un un core SB, omettiamo di dire che sono grandi quasi come 2core k10...Il fo4 relativamente piccolo è dovuto anche a questo....Inutile dire che probabilmente una CPU come Nehalem portata a soli 12 stadi avrebbe frequenze ridicole anche sul rinomato finfet di Intel
A9 ha 16 stadi non 9.
No, con Twister hanno ridotto la Branch Mispredict Penalty. Adesso sono 9 stadi contro i 16 del cyclone+ (A8)
Probabilmente hanno implementato qualche sistema simile alla loop-cache di intel, ma il salto da 16 a 9 è troppo ampio per esser solo quello.
Eccoli il link di anandtech:
http://www.anandtech.com/show/9686/the-apple-iphone-6s-and-iphone-6s-plus-review/4
Su k10 e le sue pipe corte con fo4 Bassini, c'è da considerare che quando noi diciamo che un modulo BD è circa uguale ad un un core SB, omettiamo di dire che sono grandi quasi come 2core k10...Il fo4 relativamente piccolo è dovuto anche a questo....Inutile dire che probabilmente una CPU come Nehalem portata a soli 12 stadi avrebbe frequenze ridicole anche sul rinomato finfet di Intel
Vuoi forse dirmi che un processore spiccatamente Super-scalare (Out of order) non può raggiungere con lo stesso F04 le frequenze di uno meno Wide ?
Ovviamente la domanda presuppone Consumi diversi, dato che quello più wide assorbirà per forza più watt.
tuttodigitale
09-03-2016, 10:01
Vuoi forse dirmi che un processore spiccatamente Super-scalare (Out of order) non può raggiungere con lo stesso F04 le frequenze di uno meno Wide ?
Ovviamente la domanda presuppone Consumi diversi, dato che quello più wide assorbirà per forza più watt.
l'equivoco è pensare che il FO4 e il numero di stadi siano non solo dipendenti ma anche inversamente proporzionali, come se l'implementazione non fosse determinante, cosa assolutamente falsa.
Con BD; AMD avrebbe ridotto solo del 23% il FO4 (+30% di clock a pari vcore) da k10, e al coltempo aumentato il numero degli stadi del 83%...
BD e Nehalem, se presi così e venissero semplicemente accorpati alla meno peggio gli stadi farebbero pena lato frequenza (BD avrebbe un FO4 30+ con 11 stadi), idem l'A8.
Un'architettura wide, presuppone anche una logica sequenziale piuttosto complessa in grado di sfruttare a dovere le unità disponibili nel ST.
Un'ampliamento dell'architettura pressuppone:
a) aumento FO4,
b) aumento degli stadi (vedi NEHALEM e co),
C) riduci la complessità circuitale a scapito del ILP e ti affidi al SMT (vedi IBM)
D) hai keller :cool:
Sul A9, mi pare strano, questo sarebbe un processore COMPLETAMENTE nuovo altro che rivisitazione (cit.) . E a questo si aggiunge un bel boost lato frequenza (+30 e rotti, ma addirittura +72% se consideriamo l'ipad...),
D'altra parte ci andrei con i piedi di piombo. Anandtech parla di 9 stadi secchi, e mi pare che sia l'unico a dirlo (se hai altre fonti posta :D ).
Anche sull'aumento di ipc, ho delle perplessità. Siamo a conoscenza di quanto sia difficile conoscere la reale frequenza di funzionamento nei notebook, ma abbiamo il vantaggio di conoscere l'ipc di una architettura, quindi anche se con difficoltà riusciamo a risalire (una equazione e una incognita). Anandtech né l'uno né l'altro. Ha fatto una stima a ca..o.
Io leggo di scaling nel MT COMPLETAMENTE differenti tra ipad e iphone con SoC con la stessa architettura....Tipo scaling del 80% vs 20%....in pratica il confronto è fatto, magari con i software multithread prendendo quella che in realtà è la cosidetta frequenza turbo...
l'equivoco è pensare che il FO4 e il numero di stadi siano non solo dipendenti ma anche inversamente proporzionali, come se l'implementazione non fosse determinante, cosa assolutamente falsa.
Con BD; AMD avrebbe ridotto solo del 23% il FO4 (+30% di clock a pari vcore) da k10, e al coltempo aumentato il numero degli stadi del 83%...
BD e Nehalem, se presi così e venissero semplicemente accorpati alla meno peggio gli stadi farebbero pena lato frequenza (BD avrebbe un FO4 30+ con 11 stadi), idem l'A8.
Un'architettura wide, presuppone anche una logica sequenziale piuttosto complessa in grado di sfruttare a dovere le unità disponibili nel ST.
Un'ampliamento dell'architettura pressuppone:
a) aumento FO4,
b) aumento degli stadi (vedi NEHALEM e co),
C) riduci la complessità circuitale a scapito del ILP e ti affidi al SMT (vedi IBM)
D) hai keller :cool:
Sul A9, mi pare strano, questo sarebbe un processore COMPLETAMENTE nuovo altro che rivisitazione (cit.) . E a questo si aggiunge un bel boost lato frequenza (+30 e rotti, ma addirittura +72% se consideriamo l'ipad...),
D'altra parte ci andrei con i piedi di piombo. Anandtech parla di 9 stadi secchi, e mi pare che sia l'unico a dirlo (se hai altre fonti posta :D ).
Anche sull'aumento di ipc, ho delle perplessità. Siamo a conoscenza di quanto sia difficile conoscere la reale frequenza di funzionamento nei notebook, ma abbiamo il vantaggio di conoscere l'ipc di una architettura, quindi anche se con difficoltà riusciamo a risalire (una equazione e una incognita). Anandtech né l'uno né l'altro. Ha fatto una stima a ca..o.
Io leggo di scaling nel MT COMPLETAMENTE differenti tra ipad e iphone con SoC con la stessa architettura....Tipo scaling del 80% vs 20%....in pratica il confronto è fatto, magari con i software multithread prendendo quella che in realtà è la cosidetta frequenza turbo...
A9X non ha la cache L3 ed ha il doppio della banda RAM (64 vs 128 bit), inoltre la GPU è più potente. Lo scaling MT dipende se il processo è limitato o no dalla RAM...
tuttodigitale
09-03-2016, 14:17
A9X non ha la cache L3 ed ha il doppio della banda RAM (64 vs 128 bit), inoltre la GPU è più potente. Lo scaling MT dipende se il processo è limitato o no dalla RAM...
nello specifico mi riferivo ad ipad air 1 vs iphone 5s, entrambi dovrebbero avere lo stesso soc, o sbaglio?
Sul A9, mi pare strano, questo sarebbe un processore COMPLETAMENTE nuovo altro che rivisitazione (cit.) . E a questo si aggiunge un bel boost lato frequenza (+30 e rotti, ma addirittura +72% se consideriamo l'ipad...),
D'altra parte ci andrei con i piedi di piombo. Anandtech parla di 9 stadi secchi, e mi pare che sia l'unico a dirlo (se hai altre fonti posta :D ).
Anche sull'aumento di ipc, ho delle perplessità. Siamo a conoscenza di quanto sia difficile conoscere la reale frequenza di funzionamento nei notebook, ma abbiamo il vantaggio di conoscere l'ipc di una architettura, quindi anche se con difficoltà riusciamo a risalire (una equazione e una incognita). Anandtech né l'uno né l'altro. Ha fatto una stima a ca..o.
Io leggo di scaling nel MT COMPLETAMENTE differenti tra ipad e iphone con SoC con la stessa architettura....Tipo scaling del 80% vs 20%....in pratica il confronto è fatto, magari con i software multithread prendendo quella che in realtà è la cosidetta frequenza turbo...
Se non ricordo male è anandtech che ha tirato fuori la stima degli stadi dal A7 (16 stadi), così come decoder,issue ecc..
Sinceramente sembrano competenti(Kanter non è disponibile mi spiace :p ), ed hanno spessissimo informazioni privilegiate.
Come hai visto dai bench hanno misurato anche IPC clock-to-clock. (30-40% forse più:eek: )
Che io sappia Apple usa solo il thermal throttle per gli iphone(esistono anche bench sulla solo frequenza). Su Ipad (premium) è molto difficile che riducano considerevolmente il clock per questioni di temperatura (poi dipende dal modello).
BJT2 che ne pensi di questa storia del Apple A9 (twister) ?
stefanonweb
09-03-2016, 15:32
Scusate, ma non ho seguito e non sono informato...
Mi domando:
1-Quando uscirebbero le prime mobo AM4 e le prime CPU...
2-Ci sarà qualche cosa di compatibile per le "vecchie" mobo FM2+ tramite aggiornamento bios? Visto che la mia Gigabyte riporta un nuovo Bios con il supporto a Carrizzo? Intendo se faranno altre APU compatibili con FM2+ comprendenti pure la parte grafica... cioè NON come l'Athlon X4 845 (che mi pare abbia core Excavator) ???
Possibile che non si sappia nulla...???
Grazie.
capitan_crasy
09-03-2016, 15:56
Scusate, ma non ho seguito e non sono informato...
Mi domando:
1-Quando uscirebbero le prime mobo AM4 e le prime CPU...
Non ce ancora una data precisa; le CPU arriveranno entro la fine di quest'anno...
2-Ci sarà qualche cosa di compatibile per le "vecchie" mobo FM2+ tramite aggiornamento bios?
Se AMD proporrà delle soluzioni con architettura Excavator su socket FM2+ direi di si...
Visto che la mia Gigabyte riporta un nuovo Bios con il supporto a Carrizzo? Intendo se faranno altre APU compatibili con FM2+ comprendenti pure la parte grafica... cioè NON come l'Athlon X4 845 (che mi pare abbia core Excavator) ???
A parte le soluzioni Athlon 845/835 (in cui è riferito la compatibilità della tua scheda a Carrizo) non si conosce se e quando AMD presenterà altre soluzioni Carrizo sul socket FM2+...
Possibile che non si sappia nulla...???
Quello che sappiamo di sicuro:
Zen è previsto entro la fine del 2016 e sarà basato sul socket AM4.
Le APU AM4 saranno basate sull'architettura Excavator a 28nm e dovrebbero arrivare prima di Zen.
Tutto il resto sono solo rumors...
BJT2 che ne pensi di questa storia del Apple A9 (twister) ?
E' un bel processore... E' 6 wide, nel senso che può eseguire 4 alu + 2 mem e poi 3 operazioni fp32 o NEON (SIMD), contro Zen che dovrebbe farne 4, ma ha un IPC fenomenale per chissà quanti accorgimenti a livello di pipeline. Poichè è dato 6 wide issue, deduco che le FP siano in alternativa alle ALU, come INTEL, altrimenti avrebbero detto 9-wide (Zen dovrebbe essere 10-wide), INTEL ha anche clock più che doppi, quindi il paragone non è possibile... Zen potrebbe e dovrebbe avere IPC superiori e per quanto riguarda il clock non c'è storia...
Questo fatto della L3 victim cache porterà svantaggi come per AMD pre-Zen, ma daltronde con una L2 da 3 MB non c'era altro da fare...
Ho già scritto i vantaggi di una cache inclusiva... Ma forse poichè i core sono solo due e non 8, il consumo non dovrebbe essere poi così eccessivo...
E' un bel processore... E' 6 wide, nel senso che può eseguire 4 alu + 2 mem e poi 3 operazioni fp32 o NEON (SIMD), contro Zen che dovrebbe farne 4, ma ha un IPC fenomenale per chissà quanti accorgimenti a livello di pipeline. Poichè è dato 6 wide issue, deduco che le FP siano in alternativa alle ALU, come INTEL, altrimenti avrebbero detto 9-wide (Zen dovrebbe essere 10-wide), INTEL ha anche clock più che doppi, quindi il paragone non è possibile... Zen potrebbe e dovrebbe avere IPC superiori e per quanto riguarda il clock non c'è storia...
Mi riferivo alla questione pipeline da 16 a 9 stadi con aumento di clock del 40%:eek:. Com'è possibile ?
cmq le pipeline fp sono indipendenti come in zen.
Twister(A9) può fare 3 mul(128bit).
http://images.anandtech.com/doci/7910/Cyclone.png
plainsong
09-03-2016, 22:27
Mi riferivo alla questione pipeline da 16 a 9 stadi con aumento di clock del 40%:eek:. Com'è possibile ?
Che abbiano effettivamente ridotto la branch misprediction penalty da 16 a 9 cicli di clock può implicare che abbiano accorciato la pipeline, ma questo non significa che l'abbiano portata a 9 stadi.
paolo.oliva2
09-03-2016, 22:43
ipotizzo che, tra frequenza ed ipc, Zen X8 non andrà meno dell X6 di punta intel, di conseguenza Zen X6 andrà oltre il 4+4 intel, resta da capire Zen X4 come si posizionerà.
tenedo conto che Amd deve recuperare mercato, ipotizzo a parità di prestazioni prezzi inferiori, ma non tanto da andare sotto il modello con meno core.
quindi se il modello di pari prestazioni (6850k) Intel lo vende a 500+ $ Amd vendererà Zen x8 a meno, ma non meno del 6700k in quanto ci sarà Zen x6 (già più potente di quest'ultimo) da vendere a prezzo leggermente inferiore.
Facendo un calcolo a spannella, +40% di IPC di Zen su XV, corrisponderebbero a oltre +60% su Piledriver, quindi 160, a cui aggiungendo l'SMT considerandolo un +30%, si supererebbero 200, quindi a parità di clock 6 core Zen andrebbero poco più di 12 core Piledriver, ed un X8 Zen poco più di un X16 Piledriver.
Anche se ci fossero sorprese (negative) sul clock per Zen, Un X8 Zen a 2GHz andrebbe già più di 8370 :sofico: e a 3GHz un +50%.
Questo però è su quanto è trapelato e/o dichiarato da AMD.
Però, quello che non mi è chiaro, è che se consideriamo che AMD aveva riportato che le aspettative di clock di Zen si erano già raggiunte con la prima stesura, e si parlava di ALMENO 3GHz di clock def (considerando che AMD quando ha parlato di Zen lo ha sempre riportato X8/95W), direi che addirittura ci sarebbe margine TDP sia per un tiraggio di clock (95W vs 125W/140W) e/o un aumento dei core.
Ora... o consideriamo Zen un Opteron (quindi TDP/prestazioni da procio server), vorrebbe dire che se con Piledriver, su un procio desktop di X8 125W AMD ha commercializzato un Opteron raddoppiando i core penalizzando di un 30% la frequenza def (4GHz -30% =2,8GHz), mi sembra plausibile che partendo da 95W (non 125W), Zen con tutta probabilità avrebbe lo stesso raddoppio dei core ma con una diminuzione del clock def in percentuale inferiore... quindi un Zen Opteron X16 è possibile abbia lo stesso clock di un Piledriver X16, cioè circa 2,8GHz, e quindi raddoppio della potenza MT.
Personalmente io vedo Zen X8 nativo... probabile X4 APU (mobile), ma non ci vedo un die X6 nativo (commercializzando i fallati però probabile).
Non ci vedo logica diversa... con BD, Phenom II (X4/X6) AMD ha sempre optato per una catena con la variante Opteron sempre con la possibilità di 2 die nativi.
Realizzare Zen X4/X6 e X8, già vorrebbe dire 3 varianti sulla stessa catena, e se valutassimo la voce di Zen X32 come possibilità di 2 Zen X16 nativi, risulterebbero 4 varianti. Sballerebbero i tempi di quantitativi di commercializzazione, aumenterebbero i costi e si allungherebbero i tempi di affinamento....
Ora come ora, considerando che Carrizo mobile è un X4 e compatibile con il socket AM4, è vero che il salto a Zen X8 sarebbe troppo... ed un Zen X4/X6 troverebbe spazio... ma è anche vero (mia personalissima idea) che l'architettura Zen in accoppiata a tutte le features maturate con Carrizo e trasportate sul 14nm, sulla base di un Zen X8/95W, avrebbe poco senso commercializzare Zen X4 a 45W e Zen X6 a 65W, ma sarebbe più competitivo commercializzare con lo stesso TDP di un 6700K un Zen X8, vuoi sia verso gli X4 Intel che verso i 140W del socket 2011, anche perchè ad un i7 X10/140W, ci sarebbe spazio TDP per un Zen X12 dai 95W di un X8.
Comunque rimango dell'opinione, con il mio naso, che non vedo (o credo) in un aumento di forza bruta/core di Zen stile Intel, ma rimango MOLTO ottimista, invece, in un corposo aumento della potenza MT.
tuttodigitale
09-03-2016, 23:07
x bjt2
sicuro che non ti confondi (mi confondo anch'io non ti preoccupare) wide-issue con il wide instruction execution? (ovvero la cpu in questione sarebbe un 6-wide issue e 9-wide dispatch)
Chissà magari anche le ALU di ZEN saranno sulla falsa riga di twister.
Che abbiano effettivamente ridotto la branch misprediction penalty da 16 a 9 cicli di clock può implicare che abbiano accorciato la pipeline, ma questo non significa che l'abbiano portata a 9 stadi.
Ma va ;) , nel post precedente l'ho detto io stesso che è probabile l'adozione di un sistema di loop-cache stile sandybridge o altri trick simili...
x bjt2
sicuro che non ti confondi (mi confondo anch'io non ti preoccupare) wide-issue con il wide instruction execution?
Da quello che si legge, sono 6 istruzione realmente in esecuzione OutOfOrder.
ps. cmq anandtech ha davvero troppi dettagli(non dichiarati da apple) per cannare la storia del misspredict...
tuttodigitale
09-03-2016, 23:44
Ma va ;) , nel post precedente l'ho detto io stesso che è probabile l'adozione di un sistema di loop-cache stile sandybridge o altri trick simili...
7 cicli sono comunque enormi, considerano che la fase di decodifica, in una CPU ARM, è marginale rispetto ad una CPU x86..
7 cicli sono comunque enormi, considerano che la fase di decodifica, in una CPU ARM, è marginale rispetto ad una CPU x86..
Lo so bene, infatti è davvero un balzo miracoloso...:confused:
digieffe
10-03-2016, 00:27
...
intendevo zen x6 e x4 come chip x8 fallati...
tuttodigitale
10-03-2016, 00:32
Qui nasce una domanda per bjt2:
Le misure di anandtech sono attendibili?
Dice di aver analizzato la penalità media, non avendo informazioni sul numero degli stadi. Ma questa è condizionata enormemente dalle missprediction eventuali nella l1 e l2 (in bulldozer significa perdere altri 20 cicli aggiuntivi). A me pare pure poco 16 medi per typhon.
Voglio spiegazioni. Palla a te BJT2.
Per me non hanno ridotto le pipeline, se non in misura marginale , rulla a 2,4GHz nel ipad.
Ho fatto i calcoli, sono 19mmq per il dual core Cyclone con cache l2, praticamente identico ad un modulo XV con 1MB l2 (entrambi su 28nm e HDL)
un dual core typhoon con cache l2, è grande 12,9mmq, che moltiplicato per il maggior fattore di integrazione (2,1x) dei 20nm fa 27mmq..
a maggior ragione twister è una cpu dalla complessità enorme, paragonabile a sandy bridge....
Ho fatto i calcoli, sono 19mmq per il dual core Cyclone con cache l2, praticamente identico ad un modulo XV con 1MB l2 (entrambi su 28nm e HDL)
un dual core typhoon con cache l2, è grande 12,9mmq, che moltiplicatore per il maggior fattore di integrazione (2,1x) dei 20nm fa 27mmq..
a maggior ragione twister è una cpu dalla complessità enorme, paragonabile a sandy bridge....
Rifai i calcoli che i numeri di partenza sono sbagliati.
A7 CPU 28nm - 17mm2
A8 CPU 20nm - 12.2mm2
A9 CPU 16FF+(meno di mezzo nodo di scaling) - 13.5mm2 (con il triplo di L2)
Il fattore di integrazione che hai usato è riferito allo scaling della SRAM, la logica scala meno...
tuttodigitale
10-03-2016, 06:54
li ho ricavati con un programma di fotoritocco, non credo di aver sbagliato così tanto :D.
Se non scalano bene neppure le CPU da smartphone, che hanno obiettivi di frequenza assi più modesti, non avrebbe granchè senso la corsa alla miniaturizzazione...detto questo i core skylake sono piccolissimi: siamo passati dai 17,5mmq a 6,85mmq da SB a skylake (core+l2) per un fattore di integrazione pari a 2,5x (in realtà superiore considerando che skylake ha 2 pipeline e 1 decoder e tante altre cose in più)
Mi riferivo alla questione pipeline da 16 a 9 stadi con aumento di clock del 40%:eek:. Com'è possibile ?
cmq le pipeline fp sono indipendenti come in zen.
Twister(A9) può fare 3 mul(128bit).
http://images.anandtech.com/doci/7910/Cyclone.png
Per misurare la profondità di una pipeline uno non può che far altro che misurare la latenza di branch mispredicition. Infatti se leggete bene non dice che la pipeline è a 9 stadi, ma che la branch misprediction è scesa a 9 cicli. Quando si predice erratamente un salto, la cosa più semplice e bug free è svuotare la pipeline e ricominciare daccapo. In tal modo l'istruzione che segue il salto sarà completata quando avrà passato tutta la pipeline. Ma se quando arriva un salto inizi a fare il prefetch anche dell'altro ramo e, visto che hai 6 decoder, magari inizi anche a usare metà decoder per decodificarle, puoi ridurre la latenza di mispredict. Visto che non c'è il SMT si potrebbe fare così, come se fossero due thread separati...
AMD ha anche un brevetto per il checkpointing che serve per ridurre tale latenza, ma non credo che faccia la stessa cosa, altrimenti il brevetto non sarebbe stato approvato
Che abbiano effettivamente ridotto la branch misprediction penalty da 16 a 9 cicli di clock può implicare che abbiano accorciato la pipeline, ma questo non significa che l'abbiano portata a 9 stadi.
vedi sopra
x bjt2
sicuro che non ti confondi (mi confondo anch'io non ti preoccupare) wide-issue con il wide instruction execution? (ovvero la cpu in questione sarebbe un 6-wide issue e 9-wide dispatch)
Chissà magari anche le ALU di ZEN saranno sulla falsa riga di twister.
Il problema è che IBM usa issue per il dispatch e INTEL usa un'altra convenzione... Non so ARM o Apple che convenzione usano... :D Per AMD issue significa mandare in esecuzione e dispatch mettere in coda dai decoder... Ma poichè i decoder sono 6 immagino che issue si riferisca ai decoder... Ricordo che il set di istruzioni ARM è più "RISC" di quello INTEL, quindi avere più decoder non implica che il software giri più veloce...
Da quello che si legge, sono 6 istruzione realmente in esecuzione OutOfOrder.
ps. cmq anandtech ha davvero troppi dettagli(non dichiarati da apple) per cannare la storia del misspredict...
Se il diagramma è esatto, le istruzioni in esecuzione possono essere fino a 9...
7 cicli sono comunque enormi, considerano che la fase di decodifica, in una CPU ARM, è marginale rispetto ad una CPU x86..
vedi sopra
Lo so bene, infatti è davvero un balzo miracoloso...:confused:
vedi sopra
Qui nasce una domanda per bjt2:
Le misure di anandtech sono attendibili?
Dice di aver analizzato la penalità media, non avendo informazioni sul numero degli stadi. Ma questa è condizionata enormemente dalle missprediction eventuali nella l1 e l2 (in bulldozer significa perdere altri 20 cicli aggiuntivi). A me pare pure poco 16 medi per typhon.
Voglio spiegazioni. Palla a te BJT2.
Beh, penso che facciano andare a regime le caches e poi facciano parecchi cicli... Quindi si, credo siano affidabili...
digieffe
10-03-2016, 10:14
Per misurare la profondità di una pipeline uno non può che far altro che misurare la latenza di branch mispredicition. Infatti se leggete bene non dice che la pipeline è a 9 stadi, ma che la branch misprediction è scesa a 9 cicli. Quando si predice erratamente un salto, la cosa più semplice e bug free è svuotare la pipeline e ricominciare daccapo. In tal modo l'istruzione che segue il salto sarà completata quando avrà passato tutta la pipeline. Ma se quando arriva un salto inizi a fare il prefetch anche dell'altro ramo e, visto che hai 6 decoder, magari inizi anche a usare metà decoder per decodificarle, puoi ridurre la latenza di mispredict. Visto che non c'è il SMT si potrebbe fare così, come se fossero due thread separati...
AMD ha anche un brevetto per il checkpointing che serve per ridurre tale latenza, ma non credo che faccia la stessa cosa, altrimenti il brevetto non sarebbe stato approvato
mi chiedo perché, nel caso sia in esecuzione un solo thread, le cpu HT non eseguano* sempre entrambi i rami del branch, scartando i risultati di quello errato... forse potrebbe essere annullato il branch missprediction?
riesci in due parole a spiegare cos'è e come funziona il checkpoint?
EDIT: *ovviamente meglio se dedicando tutte le risorse necessarie al ramo indicato dal branch-predictor come probabile e le rimanenti all'altro ramo.
li ho ricavati con un programma di fotoritocco, non credo di aver sbagliato così tanto :D.
Se non scalano bene neppure le CPU da smartphone, che hanno obiettivi di frequenza assi più modesti, non avrebbe granchè senso la corsa alla miniaturizzazione...detto questo i core skylake sono piccolissimi: siamo passati dai 17,5mmq a 6,85mmq da SB a skylake (core+l2) per un fattore di integrazione pari a 2,5x (in realtà superiore considerando che skylake ha 2 pipeline e 1 decoder e tante altre cose in più)
Purtroppo x te sono sbagliati, ho controllato sia con le mie che sul web... :angel:
Controlla le immagini che qualcosa non va.
Apple con i 20nm(core simile) ha ridotto di circa 0.7.
ps. Skylake è 8.2mm2 ;) (sb 18.4)
Per misurare la profondità di una pipeline uno non può che far altro che misurare la latenza di branch mispredicition. Infatti se leggete bene non dice che la pipeline è a 9 stadi, ma che la branch misprediction è scesa a 9 cicli. Quando si predice erratamente un salto, la cosa più semplice e bug free è svuotare la pipeline e ricominciare daccapo. In tal modo l'istruzione che segue il salto sarà completata quando avrà passato tutta la pipeline. Ma se quando arriva un salto inizi a fare il prefetch anche dell'altro ramo e, visto che hai 6 decoder, magari inizi anche a usare metà decoder per decodificarle, puoi ridurre la latenza di mispredict. Visto che non c'è il SMT si potrebbe fare così, come se fossero due thread separati...
AMD ha anche un brevetto per il checkpointing che serve per ridurre tale latenza, ma non credo che faccia la stessa cosa, altrimenti il brevetto non sarebbe stato approvato
Realisticamente non "ti sembrano" troppi 7 stadi di vantaggio per un tale sistema ?
mi chiedo perché, nel caso sia in esecuzione un solo thread, le cpu HT non eseguano* sempre entrambi i rami del branch, scartando i risultati di quello errato... forse potrebbe essere annullato il branch missprediction?
riesci in due parole a spiegare cos'è e come funziona il checkpoint?
EDIT: *ovviamente meglio se dedicando tutte le risorse necessarie al ramo indicato dal branch-predictor come probabile e le rimanenti all'altro ramo.
Non è semplice gestirlo e ci si deve mettere a progettarlo e comunque consuma area e si spreca energia: se la predizione è corretta nel 95% dei casi, nel 95% dei casi hai sprecato energia. Infatti non sono sicuro che l'A9 faccia così... Ci sarà probabilmente modo di accorciare la pipeline, magari svuotandola appena si sa che la predizione è sbagliata...
Il check pointing non l'ho approfondito... DOvrei leggere il brevetto, ma spesso sono inutilmente complicati... Se qualche anima pia mi linka un PDF di qualche paper... :stordita: Oppure quando ho tempo me lo cerco da solo...
Realisticamente non "ti sembrano" troppi 7 stadi di vantaggio per un tale sistema ?
Beh, se eseguono entrambi i rami del salto e poi scartano il resto, 7 cicli di risparmio possono essere anche pochi... Non sono sicuro che usino questa tecnica perchè non è efficiente dal punto di vista energetico... E su un cellulare... Conta...
Il checkpointing AMD sono curioso di vedere come funziona.
io però avevo capito e credo che il fo4 sia legato anche al silicio, perché le caratteristiche del silicio influenzano tensioni e frequenze e quindi anche il fo4 in fase di progettazione.
vero che il silicio cambia e quindi l'architettura zen potrebbe subire un aumento di fo4 rispetto a BD senza che questo comprometta i consumi a parità di clock, ma un fo4 superiore a 20 lo trovo eccessivo per una architettura a 360° che deve rullare ed essere allo stesso tempo parca nei consumi
Il FO4 dovrebbe essere una misura normalizzata e quindi indipendente dal processo. Solo se un processo impone dei vincoli realizzativi, ad esempio il circuito con il migliore FO4 non si può fare perchè le tracce sono più lunghe per vincoli geometrici del processo, allora può influire... Ma in teoria no.
tuttodigitale
10-03-2016, 14:03
BJT2
Certo se funziona in questo modo, sarebbe davvero un mostro. La complessità per molti aspetti fondamentali sarebbe paragonabile a quella di una CPU con SMT...
Tuttavia, caricare un dato inutile nel 90% dei casi, è un costo non trascurabile. Sei sicuro al 100%?
...
con SB sono andato a memoria.
di skylake ho preso, le dimensioni dei core M, che dovrebbe essere semplicemente un core skylake con HDL, quindi piuttosto rappresentativo della differente complessità tra le architetture Intel ed Apple.
Aldilà dei numeri che contano fino ad un certo punto, volevo semplicemente affermare che le cpu risc di apple dall'A7 sono dei mostriciattoli, molto più grandi di jaguar.
vBulletin® v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.