stefanonweb
20-12-2016, 10:35
Scusate, non ho seguito questi ultimi giorni.... Ma cosa è cambiato dall'entusiasmo iniziale... Avevo letto che nella prova Zen pareva essere un po' overvoltato... Mi riassumete? Grazie.
View Full Version : [Thread Ufficiale] Aspettando ZEN
Pagine :
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
[43]
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
CiccoMan
20-12-2016, 10:38
ma per "pareggio" di che situazioni state parlando? rendering? cinebench? gaming?
perchè personalmente sono interessato solo all'ultimo aspetto, gli altri due manco li caco di striscio, ma purtroppo quando si parla di processori sembra sempre un'aspetto trascurato sul forum :asd:
:mano:
Gaming, Benchmarking and Overclocking :yeah:
perchè personalmente sono interessato solo all'ultimo aspetto, gli altri due manco li caco di striscio, ma purtroppo quando si parla di processori sembra sempre un'aspetto trascurato sul forum :asd:
:mano:
Gaming, Benchmarking and Overclocking :yeah:
mircocatta
20-12-2016, 11:09
Questo è il motivo per cui dicevo quel che dicevo poco sopra sui prezzi fattibili e con cosa si scontra Zen. Un 8c/16t non puoi necessariamente venderlo a di più di un 4c/4t Intel, se in ambiti desktop non va effettivamente veloce uguale.
un esa o octa rende meglio in gaming rispetto ad un quad, anche avesse un IPC leggermente inferiore (recupuerabile con le frequenze che da una certa in poi, non serve più alzarla per molti intel)
ti mostrerei bench che avvalorano quel che dico ma trovare comparative su FPS MINIMI (dove un procio con + di 4 core fa la differenza) è quasi impossibile
:mano:
Gaming, Benchmarking and Overclocking :yeah:
fuck yeah bro!
un esa o octa rende meglio in gaming rispetto ad un quad, anche avesse un IPC leggermente inferiore (recupuerabile con le frequenze che da una certa in poi, non serve più alzarla per molti intel)
ti mostrerei bench che avvalorano quel che dico ma trovare comparative su FPS MINIMI (dove un procio con + di 4 core fa la differenza) è quasi impossibile
:mano:
Gaming, Benchmarking and Overclocking :yeah:
fuck yeah bro!
Roland74Fun
20-12-2016, 11:23
ti mostrerei bench che avvalorano quel che dico ma trovare comparative su FPS MINIMI (dove un procio con + di 4 core fa la differenza) è quasi impossibile
Su game gpu ho visto che li mettono in ordine proprio in base agli fps minimi come dici tu.
http://uploads.tapatalk-cdn.com/20161220/3f223959bb8e696e1c0ccb40195d7b62.jpg
Su game gpu ho visto che li mettono in ordine proprio in base agli fps minimi come dici tu.
http://uploads.tapatalk-cdn.com/20161220/3f223959bb8e696e1c0ccb40195d7b62.jpg
capitan_crasy
20-12-2016, 11:26
Scusate, non ho seguito questi ultimi giorni.... Ma cosa è cambiato dall'entusiasmo iniziale... Avevo letto che nella prova Zen pareva essere un po' overvoltato... Mi riassumete? Grazie.
Per riassumere le CPU ZEN si chiameranno Ryzen, si prevede una frequenza nominale di 3.40Ghz, un TDP a 95W, avranno nuove tecnologie cioè il Precision Boost, il Pure Power, Extended Frequency Range o XFR, il Neural Net Prediction e lo Smart Prefetch.
Ci sono stati due bench a caso naturalmente in favore di una CPU ES ZEN e tanta pastura per i persici trota.
Quindi nulla è cambviato tranne ovviamente i super pipponi mentali marchio di fabbrica di ogni discussione su AMD...:asd:
Per riassumere le CPU ZEN si chiameranno Ryzen, si prevede una frequenza nominale di 3.40Ghz, un TDP a 95W, avranno nuove tecnologie cioè il Precision Boost, il Pure Power, Extended Frequency Range o XFR, il Neural Net Prediction e lo Smart Prefetch.
Ci sono stati due bench a caso naturalmente in favore di una CPU ES ZEN e tanta pastura per i persici trota.
Quindi nulla è cambviato tranne ovviamente i super pipponi mentali marchio di fabbrica di ogni discussione su AMD...:asd:
conan_75
20-12-2016, 11:29
Per riassumere le CPU ZEN si chiameranno Ryzen, si prevede una frequenza nominale di 3.40Ghz, un TDP a 95W, avranno nuove tecnologie cioè il Precision Boost, il Pure Power, Extended Frequency Range o XFR, il Neural Net Prediction e lo Smart Prefetch.
Ci sono stati due bench a caso naturalmente in favore di una CPU ES ZEN e tanta pastura per i persici trota.
Quindi nulla è cambviato tranne ovviamente i super pipponi mentali marchio di fabbrica di ogni discussione su AMD...:asd:
:D :D :D :D :D :D :D :D :D :D
Ci sono stati due bench a caso naturalmente in favore di una CPU ES ZEN e tanta pastura per i persici trota.
Quindi nulla è cambviato tranne ovviamente i super pipponi mentali marchio di fabbrica di ogni discussione su AMD...:asd:
:D :D :D :D :D :D :D :D :D :D
paolo.oliva2
20-12-2016, 11:44
Questo è assolutamente certo. La maggior parte di chi aspetta Zen vuole una CPU competitiva.
Quelli che hanno un 4c/4t Intel vogliono poter salire come numero di thread, che sia 4c/8t o più e sperano in prezzi molto più accessibili degli attuali di Intel. Ma questa speranza solo questo è, e dipende fortemente dalle prestazioni assolute che Zen potrà offrire con prodotti sul mercato. Siamo lontanissimi da fare una previsione credibile in merito. Tu sei convinto che i prezzi saranno iperaggressivi, ma è una tua convinzione. E se ti daranno un 8c/16t a prezzi molto bassi la motivazione più logica da aspettarsi è che non abbiano, nel breve termine, prodotti che possano competere nel punto più alto dell'offerta Intel, almeno a 360°.
Per capirsi, se il top di gamma te lo dessero a 500€ molto probabilmente questo significa che le prestazioni desktop (che sono ancora molto legate alle performance ST) sono in media quelle di un 6850K.
Le prestazioni desktop del 6850k sono superiori a quelle del 6900K. Il fratello minore perde due core, ma guadagna in frequenza, il che significa che in tutte quelle attività per cui non servono più di 6c/12t va meglio o uguale...
Da questo punto di vista AMD ha ampi margini di manovra nel prezzare le proprie cpu...
Per me sono i 2 punti assieme.
Ragiogniamo su una cosa... AMD avrebbe overvoltato un Zen X8+8 per 3,4GHz quando Zen, per essere competitivo con un 7700K, dovrebbe raggiungere >4GHz almeno come turbo X4+4?
Io non penso che lo possa fare... però invece penso che possa essere competitivo sfruttando i 4 core in più. Un X4+4 Intel è "tosto" fino a 4TH, quando si superano i 4TH, deve ricorrere all'SMT, e il TH logico è come 1 core che funziona a a meno di 1,5GHz.
Un 6850K, ad esempio, perde poca frequenza rispetto ad un i7 X4, e come i TH da elaborare (intensivi) diventerebbero 5, vale il discorso prima... cioè il 5° TH di un 7700K sarebbe come un core a 1,5GHz, mentre tutti e 5 i TH nel 6850K lavorerebbero alla frequenza def, e idem nel caso di un 6° TH.
Zen X8+8 per sbancare dovrebbe offrire frequenze def paragonabili a quelle di un 6850K, costare meno di un 6850K ed essere più potente di un 6850K.
AMD cosa sta pubblicizzando? Un MT Zen X8+8 ~=6900K, e certamente siamo più in alto di un 6850K, frequenze simili al 6850K... basta che lo prezzi meno di un 6850K, ed il marketing è finito.
La logica turbo di Zen per me è quella di riuscire a fornire le frequenze massime in base al carico, ed è l'ovvia soluzione di adattare le prestazioni e efficienza di un X8 nell'MT massimo, a quelle di maggior frequenza con meno core. Bisogna vedere quale limite nel PP avrà il 14nm GF.
Se AMD non scopre la frequenza massima di Zen, mi sembra più che ovvio che non lo riporti manco sotto tortura...
Quelli che hanno un 4c/4t Intel vogliono poter salire come numero di thread, che sia 4c/8t o più e sperano in prezzi molto più accessibili degli attuali di Intel. Ma questa speranza solo questo è, e dipende fortemente dalle prestazioni assolute che Zen potrà offrire con prodotti sul mercato. Siamo lontanissimi da fare una previsione credibile in merito. Tu sei convinto che i prezzi saranno iperaggressivi, ma è una tua convinzione. E se ti daranno un 8c/16t a prezzi molto bassi la motivazione più logica da aspettarsi è che non abbiano, nel breve termine, prodotti che possano competere nel punto più alto dell'offerta Intel, almeno a 360°.
Per capirsi, se il top di gamma te lo dessero a 500€ molto probabilmente questo significa che le prestazioni desktop (che sono ancora molto legate alle performance ST) sono in media quelle di un 6850K.
Le prestazioni desktop del 6850k sono superiori a quelle del 6900K. Il fratello minore perde due core, ma guadagna in frequenza, il che significa che in tutte quelle attività per cui non servono più di 6c/12t va meglio o uguale...
Da questo punto di vista AMD ha ampi margini di manovra nel prezzare le proprie cpu...
Per me sono i 2 punti assieme.
Ragiogniamo su una cosa... AMD avrebbe overvoltato un Zen X8+8 per 3,4GHz quando Zen, per essere competitivo con un 7700K, dovrebbe raggiungere >4GHz almeno come turbo X4+4?
Io non penso che lo possa fare... però invece penso che possa essere competitivo sfruttando i 4 core in più. Un X4+4 Intel è "tosto" fino a 4TH, quando si superano i 4TH, deve ricorrere all'SMT, e il TH logico è come 1 core che funziona a a meno di 1,5GHz.
Un 6850K, ad esempio, perde poca frequenza rispetto ad un i7 X4, e come i TH da elaborare (intensivi) diventerebbero 5, vale il discorso prima... cioè il 5° TH di un 7700K sarebbe come un core a 1,5GHz, mentre tutti e 5 i TH nel 6850K lavorerebbero alla frequenza def, e idem nel caso di un 6° TH.
Zen X8+8 per sbancare dovrebbe offrire frequenze def paragonabili a quelle di un 6850K, costare meno di un 6850K ed essere più potente di un 6850K.
AMD cosa sta pubblicizzando? Un MT Zen X8+8 ~=6900K, e certamente siamo più in alto di un 6850K, frequenze simili al 6850K... basta che lo prezzi meno di un 6850K, ed il marketing è finito.
La logica turbo di Zen per me è quella di riuscire a fornire le frequenze massime in base al carico, ed è l'ovvia soluzione di adattare le prestazioni e efficienza di un X8 nell'MT massimo, a quelle di maggior frequenza con meno core. Bisogna vedere quale limite nel PP avrà il 14nm GF.
Se AMD non scopre la frequenza massima di Zen, mi sembra più che ovvio che non lo riporti manco sotto tortura...
mircocatta
20-12-2016, 11:48
Su game gpu ho visto che li mettono in ordine proprio in base agli fps minimi come dici tu.
http://uploads.tapatalk-cdn.com/20161220/3f223959bb8e696e1c0ccb40195d7b62.jpg
ottimo, il problema è che non ci sono cpu umane a 6 core nel confronto :asd: tipo i7 980, i7 3960x ... vabè, poi in fullhd e sli di 1080 non ha molto senso
http://uploads.tapatalk-cdn.com/20161220/3f223959bb8e696e1c0ccb40195d7b62.jpg
ottimo, il problema è che non ci sono cpu umane a 6 core nel confronto :asd: tipo i7 980, i7 3960x ... vabè, poi in fullhd e sli di 1080 non ha molto senso
alexsky8
20-12-2016, 12:04
Scusate, non ho seguito questi ultimi giorni.... Ma cosa è cambiato dall'entusiasmo iniziale... Avevo letto che nella prova Zen pareva essere un po' overvoltato... Mi riassumete? Grazie.
cambiato nulla, solo le normali fluttuazioni umorali
per me AMD zen sarà (con molte probabilità) un ottimo prodotto in relazione al prezzo ed è quello ciò che conta veramente
cambiato nulla, solo le normali fluttuazioni umorali
per me AMD zen sarà (con molte probabilità) un ottimo prodotto in relazione al prezzo ed è quello ciò che conta veramente
paolo.oliva2
20-12-2016, 12:07
Concordo appieno.
A questo punto meglio su altri forum dove il livello é:
AMD=sempre cacca, Intel=bello.
Ogni altro parere non sarà contemplato/tollerato.
Così niente più questioni di lana caprina od infiniti wall-text.
Ed infatti è questo il punto.
Si discute sulle aspettative Zen, liberi di essere pessimisti o ottimisti, ma non c'è collegamento del perchè chi è pessimista sia realista e chi ottimista visionario.
Del resto, chi parte dal presupposto che AMD non può assolutamente fare come Intel, è ovvio che qui ci viene per trollare e non per discutere.
Cacchio, c'è gente che ancora posta che un Zen X8+8 avrà meno potenza di un 6700K, ed è AMPIAMENTE tollerato, se uno ipotizza Zen 4GHz turbo su 8 core, è da neuro? N.B. Che Zen possa avere almeno 3,5GHz di frequenza def come X8+8, oramai è pressochè certo... in turbo vuoi che non arrivi a 3,7/3,8GHz? 4GHz sono SOLAMENTE +200MHz, non mi sembra ci voglia un miracolo, specie se si ipotizza una selezione TOP.
A questo punto meglio su altri forum dove il livello é:
AMD=sempre cacca, Intel=bello.
Ogni altro parere non sarà contemplato/tollerato.
Così niente più questioni di lana caprina od infiniti wall-text.
Ed infatti è questo il punto.
Si discute sulle aspettative Zen, liberi di essere pessimisti o ottimisti, ma non c'è collegamento del perchè chi è pessimista sia realista e chi ottimista visionario.
Del resto, chi parte dal presupposto che AMD non può assolutamente fare come Intel, è ovvio che qui ci viene per trollare e non per discutere.
Cacchio, c'è gente che ancora posta che un Zen X8+8 avrà meno potenza di un 6700K, ed è AMPIAMENTE tollerato, se uno ipotizza Zen 4GHz turbo su 8 core, è da neuro? N.B. Che Zen possa avere almeno 3,5GHz di frequenza def come X8+8, oramai è pressochè certo... in turbo vuoi che non arrivi a 3,7/3,8GHz? 4GHz sono SOLAMENTE +200MHz, non mi sembra ci voglia un miracolo, specie se si ipotizza una selezione TOP.
Roland74Fun
20-12-2016, 12:35
ottimo, il problema è che non ci sono cpu umane a 6 core nel confronto :asd: tipo i7 980, i7 3960x ... vabè, poi in fullhd e sli di 1080 non ha molto senso
É una strategia di test fatta apposta per vedere il limite lelle cpu e come scalano con quel determinato software.
Ci sono anche le slide col contrario, cpu da 1000 euro con tutte le schede video, dalla 750ti fino allo sli di 1080. Anche lì incolonnate secondo lo stesso metodo.
É una strategia di test fatta apposta per vedere il limite lelle cpu e come scalano con quel determinato software.
Ci sono anche le slide col contrario, cpu da 1000 euro con tutte le schede video, dalla 750ti fino allo sli di 1080. Anche lì incolonnate secondo lo stesso metodo.
paolo.oliva2
20-12-2016, 13:58
E' certo che avrà frequenza def almeno 3.4, non 3.5, o avrebbero detto 3.5+
AMD non è nota per fare dei binning particolarmente spinti, e anzi spara spesso dei vcore esagerati, cosa che conferma l'impressione. Lo fa sicuramente per accorciare e rendere più economico il binning stesso, non ci sono dubbi, e sicuramente se come prevedi faranno prezzi iperaggressivi non cominceranno a ridursi pure quei margini.
Però il + comunque concede spazio ad una frequenza >3,4GHz.
Per i Vcore esagerati, un conto credo che sia fino a ieri con TDP predittivo, un conto sarà con Zen, perchè la nuova logica delle frequenze, può funzionare unicamente con TDP rilevato in tempo reale, il che porterebbe un livellamento del Vcore al minimo necessario a prescindere da quello def impostato a monte, penso.
Inoltre... secondo me AMD proporrà si proci con prezzo aggressivo, ma i rumors riportano un modello top.
Cerchiamo di intendere la differenza tra i modelli base ed il modello top. Non credo sia tanto nella frequenza massima, quanto nella frequenza def a parità di TDP su tutti e 8 i core.
Questo perchè? Perchè se AMD (realmente) volesse piazzare un X8 a competere con un X4, questo lo può fare solamente se il procio scala come X4 in frequenza in quanto AMD da un Zen X4+4 65W, 95W per un Zen X8+8 nel funzionamento X4+4, darebbero un margine enorme.
A sto punto la selezione top, dovrebbe essere unicamente quella che come X8 riuscirebbe nei 95W TDP >3,4GHz. Credo facile i 3,5GHz almeno.
AMD non è nota per fare dei binning particolarmente spinti, e anzi spara spesso dei vcore esagerati, cosa che conferma l'impressione. Lo fa sicuramente per accorciare e rendere più economico il binning stesso, non ci sono dubbi, e sicuramente se come prevedi faranno prezzi iperaggressivi non cominceranno a ridursi pure quei margini.
Però il + comunque concede spazio ad una frequenza >3,4GHz.
Per i Vcore esagerati, un conto credo che sia fino a ieri con TDP predittivo, un conto sarà con Zen, perchè la nuova logica delle frequenze, può funzionare unicamente con TDP rilevato in tempo reale, il che porterebbe un livellamento del Vcore al minimo necessario a prescindere da quello def impostato a monte, penso.
Inoltre... secondo me AMD proporrà si proci con prezzo aggressivo, ma i rumors riportano un modello top.
Cerchiamo di intendere la differenza tra i modelli base ed il modello top. Non credo sia tanto nella frequenza massima, quanto nella frequenza def a parità di TDP su tutti e 8 i core.
Questo perchè? Perchè se AMD (realmente) volesse piazzare un X8 a competere con un X4, questo lo può fare solamente se il procio scala come X4 in frequenza in quanto AMD da un Zen X4+4 65W, 95W per un Zen X8+8 nel funzionamento X4+4, darebbero un margine enorme.
A sto punto la selezione top, dovrebbe essere unicamente quella che come X8 riuscirebbe nei 95W TDP >3,4GHz. Credo facile i 3,5GHz almeno.
bjt2
20-12-2016, 14:42
https://www.reddit.com/r/Amd/comments/5jcj6c/amd_ryzen_cinebench_r15_against_core_i77700k_and/
Confermato che era un fake (dal moderatore di Baidu).
E' un E5 2660 (Xeon?).
Il tizio è un rivenditore e non può avere Ryzen.
Il post è stato cancellato.
edit:
http://www.overclock.net/t/1617227/amd-new-horizon-zen-preview-on-12-13-at-3-pm-cst/1580#post_25723175
Qui il post di un tizio che spiega chi è il postatore di fake...
Confermato che era un fake (dal moderatore di Baidu).
E' un E5 2660 (Xeon?).
Il tizio è un rivenditore e non può avere Ryzen.
Il post è stato cancellato.
edit:
http://www.overclock.net/t/1617227/amd-new-horizon-zen-preview-on-12-13-at-3-pm-cst/1580#post_25723175
Qui il post di un tizio che spiega chi è il postatore di fake...
george_p
20-12-2016, 17:25
:rotfl:
...strano wccf...
Ah beh...
...strano wccf...
Ah beh...
Ale55andr0
20-12-2016, 17:32
un esa o octa rende meglio in gaming rispetto ad un quad, anche avesse un IPC leggermente inferiore (recupuerabile con le frequenze che da una certa in poi, non serve più alzarla per molti intel)
ti mostrerei bench che avvalorano quel che dico ma trovare comparative su FPS MINIMI (dove un procio con + di 4 core fa la differenza) è quasi impossibile
Infatti già OGGI un octacore non è assolutamente una scelta insensata nel gaming, anzi:
http://techbuyersguru.com/intels-core-i5-6600k-vs-i7-6700k-vs-i7-6900k-games
Nonostante la "bassa" frequenza i giochi di oggi non paiono soffrire particolarmente appoggiandosi molto alla gpu...quando si perde, si perde poco, per il resto o si va uguale o meglio. Poi se si ama maxare i giochi dal 1440p in su i freni dalla cpu praticamente non esistono. Quindi 8 core già oggi sono un ottimo investimento anche per il gaming per chi cambia di rado l'hardware! come quello che fece chi scelse un q9550 invece di un e8500...se zen avrà un costo accessibile, l'octacore è da preferire ai quad tirati, imho. Gli esacore invece non mi sembrano ne carne ne pesce :D, e poi le console sono tutte octa...
ti mostrerei bench che avvalorano quel che dico ma trovare comparative su FPS MINIMI (dove un procio con + di 4 core fa la differenza) è quasi impossibile
Infatti già OGGI un octacore non è assolutamente una scelta insensata nel gaming, anzi:
http://techbuyersguru.com/intels-core-i5-6600k-vs-i7-6700k-vs-i7-6900k-games
Nonostante la "bassa" frequenza i giochi di oggi non paiono soffrire particolarmente appoggiandosi molto alla gpu...quando si perde, si perde poco, per il resto o si va uguale o meglio. Poi se si ama maxare i giochi dal 1440p in su i freni dalla cpu praticamente non esistono. Quindi 8 core già oggi sono un ottimo investimento anche per il gaming per chi cambia di rado l'hardware! come quello che fece chi scelse un q9550 invece di un e8500...se zen avrà un costo accessibile, l'octacore è da preferire ai quad tirati, imho. Gli esacore invece non mi sembrano ne carne ne pesce :D, e poi le console sono tutte octa...
paolo.oliva2
20-12-2016, 17:36
Il + ha lo stesso significato del tuo e del mio "almeno". Vuol dire almeno 3.4. Forse di più, forse no. Quindi la certezza è a 3.4.
Non ho capito :confused:
Guardiamo BD.
In poche parole l'8350 ha un determinato Vcore def, che non è soggettivo al procio, ma diciamo il Vcore più alto rispetto alla mandata e al tipo di selezione.
Esempio... io posso avere nella stessa mandata 1,28V per 4GHz, 1,31V, 1,26V. L'8350 a 1,35V non supera i 125W, a 1,42V non supera 125W in Turbo 4 core 4,2GHz.
A sto punto che al procio bastino 1,28V per 4Ghz o 1,35V, comunque verrà assegnato 1,35V, idem nel turbo.
Il TDP predittivo lo considero a questo modo, dove un 8320 ha dei parametri Vcore/frequenza per QUELLA selezione, l'8350 idem, l'8370 idem e il 9590 idem ancora.
Noi quando scopriamo se il procio è :ciapet: o sfigato? Quando aumentaiamo la frequenza senza toccare il Vcore o undervoltiamo senza toccare la frequenza.
Se un 6900K varia il TDP a parità di un altro 6900K, a seconda se :ciapet: o sfigato, lasciandolo a def, non credo che Intel si metta ad ogni procio a guardare per ogni core il Vcore necessario, e questo per tutti gli 8 core e nel range di frequenza del procio... credo ci sia un qualche cosa di automatico...
Idem Zen, se può fare delle micro-regolazioni di 25MHz, possibile che AMD abbia fatto tutta la procedura per 8 core? E poi come funzia il tutto? Si applica il Vcore più alto ugualmente a tutti i core? :confused:
Io credo abbia inserito una circuiteria apposità ad ogni core per far sì che il Vcore sia il minimo indispensabile al funzionamento, e quindi ogni core dovrebbe avere un Vcore a sè.
A sto punto, se il meccanismo è quello, ial boot anche se AMD settasse 1,3V il Vcore di partenza, una volta che l'automatismo partirebbe, è il core che lo cambia e di qui sarebbe di nessuna importanza il Vcore def a monte.
Non so se vuoi intendere Vcore di manica larga a valle, nel senso se il circuito automatizzato applichi un Vcore leggermente superiore... sarebbe possibile, ma non credo stile BD, perchè a quel punto a che pro progettare quel circuito?
Non ho capito :confused:
Guardiamo BD.
In poche parole l'8350 ha un determinato Vcore def, che non è soggettivo al procio, ma diciamo il Vcore più alto rispetto alla mandata e al tipo di selezione.
Esempio... io posso avere nella stessa mandata 1,28V per 4GHz, 1,31V, 1,26V. L'8350 a 1,35V non supera i 125W, a 1,42V non supera 125W in Turbo 4 core 4,2GHz.
A sto punto che al procio bastino 1,28V per 4Ghz o 1,35V, comunque verrà assegnato 1,35V, idem nel turbo.
Il TDP predittivo lo considero a questo modo, dove un 8320 ha dei parametri Vcore/frequenza per QUELLA selezione, l'8350 idem, l'8370 idem e il 9590 idem ancora.
Noi quando scopriamo se il procio è :ciapet: o sfigato? Quando aumentaiamo la frequenza senza toccare il Vcore o undervoltiamo senza toccare la frequenza.
Se un 6900K varia il TDP a parità di un altro 6900K, a seconda se :ciapet: o sfigato, lasciandolo a def, non credo che Intel si metta ad ogni procio a guardare per ogni core il Vcore necessario, e questo per tutti gli 8 core e nel range di frequenza del procio... credo ci sia un qualche cosa di automatico...
Idem Zen, se può fare delle micro-regolazioni di 25MHz, possibile che AMD abbia fatto tutta la procedura per 8 core? E poi come funzia il tutto? Si applica il Vcore più alto ugualmente a tutti i core? :confused:
Io credo abbia inserito una circuiteria apposità ad ogni core per far sì che il Vcore sia il minimo indispensabile al funzionamento, e quindi ogni core dovrebbe avere un Vcore a sè.
A sto punto, se il meccanismo è quello, ial boot anche se AMD settasse 1,3V il Vcore di partenza, una volta che l'automatismo partirebbe, è il core che lo cambia e di qui sarebbe di nessuna importanza il Vcore def a monte.
Non so se vuoi intendere Vcore di manica larga a valle, nel senso se il circuito automatizzato applichi un Vcore leggermente superiore... sarebbe possibile, ma non credo stile BD, perchè a quel punto a che pro progettare quel circuito?
capitan_crasy
20-12-2016, 17:48
https://www.reddit.com/r/Amd/comments/5jcj6c/amd_ryzen_cinebench_r15_against_core_i77700k_and/
Confermato che era un fake (dal moderatore di Baidu).
E' un E5 2660 (Xeon?).
Il tizio è un rivenditore e non può avere Ryzen.
Il post è stato cancellato.
edit:
http://www.overclock.net/t/1617227/amd-new-horizon-zen-preview-on-12-13-at-3-pm-cst/1580#post_25723175
Qui il post di un tizio che spiega chi è il postatore di fake...
Nuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuu!!!:eek: :cry: :read:
E intanto i "Micropterus salmoides" hanno abboccato proprio bene...:rotfl:
Confermato che era un fake (dal moderatore di Baidu).
E' un E5 2660 (Xeon?).
Il tizio è un rivenditore e non può avere Ryzen.
Il post è stato cancellato.
edit:
http://www.overclock.net/t/1617227/amd-new-horizon-zen-preview-on-12-13-at-3-pm-cst/1580#post_25723175
Qui il post di un tizio che spiega chi è il postatore di fake...
Nuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuu!!!:eek: :cry: :read:
E intanto i "Micropterus salmoides" hanno abboccato proprio bene...:rotfl:
suneatshours86
20-12-2016, 17:54
pensare che il mio idolo indiscusso su semiaccurate si era anche preso la briga di spiegare perchè non fosse un fake. vita dura per il mio caro juan :(
paolo.oliva2
20-12-2016, 18:09
https://www.reddit.com/r/Amd/comments/5jcj6c/amd_ryzen_cinebench_r15_against_core_i77700k_and/
Confermato che era un fake (dal moderatore di Baidu).
E' un E5 2660 (Xeon?).
Il tizio è un rivenditore e non può avere Ryzen.
Il post è stato cancellato.
edit:
http://www.overclock.net/t/1617227/amd-new-horizon-zen-preview-on-12-13-at-3-pm-cst/1580#post_25723175
Qui il post di un tizio che spiega chi è il postatore di fake...
Una curiosità. Chi cacchio è intervenuto? La CIA? Il KGB? I servizi segreti cinesi? Non capisco... mi sembra strano... uno perde la faccia pubblicamente e si scusa, il moderatore cinese del forum Baidu (che essendo Cina se ne può sbattere altamente di qualsiasi cosa o rivalsa possa fare l'occidente) cancella l'articolo, individua chi l'ha fatto e posta con cosa l'ha fatto (E5 2660), ed il tutto in 24h. :confused: Lisa Su è dei servizi segreti?
Confermato che era un fake (dal moderatore di Baidu).
E' un E5 2660 (Xeon?).
Il tizio è un rivenditore e non può avere Ryzen.
Il post è stato cancellato.
edit:
http://www.overclock.net/t/1617227/amd-new-horizon-zen-preview-on-12-13-at-3-pm-cst/1580#post_25723175
Qui il post di un tizio che spiega chi è il postatore di fake...
Una curiosità. Chi cacchio è intervenuto? La CIA? Il KGB? I servizi segreti cinesi? Non capisco... mi sembra strano... uno perde la faccia pubblicamente e si scusa, il moderatore cinese del forum Baidu (che essendo Cina se ne può sbattere altamente di qualsiasi cosa o rivalsa possa fare l'occidente) cancella l'articolo, individua chi l'ha fatto e posta con cosa l'ha fatto (E5 2660), ed il tutto in 24h. :confused: Lisa Su è dei servizi segreti?
bjt2
20-12-2016, 18:12
Ho trovato un'altra presentazione di Zen, penso che il tizio sia diverso, del primo settembre... Occhio che non ci sono i sottotitoli ed ovviamente è in inglese... Tra l'altro non so come abbia avuto questo link. Sotto youtube mi dice che "Il video non è in elenco. Fai attenzione e rifletti bene prima di condividere." :asd:
https://www.youtube.com/watch?v=Ln9WKPEHm4w#t=01h01m45s
A volte quando rivedi le cose capisci meglio... O forse sarà quello che ha detto questo tizio...
In questo punto https://youtu.be/Ln9WKPEHm4w?t=1h16m29s inizia la slide sulla unità di decoding...
Notato niente? Beh all'inizio nemmeno io...
Tra la microop queue e il dispatch si frappongono lo stack memfile e la microcode rom. Questo che vuol dire?
Partiamo dallo stack memfile. Qui nessuna sorpresa. Questa unità filtra e traduce le microop, cancellando quelle che non servono, perchè gestite all'interno e modificando quelle che dipendono dallo stack. Inoltre fa anche lo store to load forwarding, tracciando gli store e poi non spiega bene, ma comunque è chiaro che è fatto a livello di dispatch...
Passiamo alla microcode rom. Che diavolo ci fa qui? Se vediamo nella slide del decoding, dice che può decodificare 4 istruzioni, senza mai specificare se semplici, doppie ecc... Visto dove è messa la unità microcodice, io suppongo che i decoder, per le istruzioni microcodificate, forniscano semplicemente un entry point nella microcode rom, con annessi registri e immediati decodificati e poi a questo stadio le microop vengano effettivamente sparate... Anche nella uop cache c'è una sola uop che contiene solo il puntatore nella microcode rom!
Così si occupa pochissimo spazio nella uop cache e nella microop queue e i decoder non sono bloccati dalle istruzioni microcodificate, ma magari tradotte in un solo ciclo e magari fino 4 per ciclo anzichè una!
L'uovo di colombo!
https://www.youtube.com/watch?v=Ln9WKPEHm4w#t=01h01m45s
A volte quando rivedi le cose capisci meglio... O forse sarà quello che ha detto questo tizio...
In questo punto https://youtu.be/Ln9WKPEHm4w?t=1h16m29s inizia la slide sulla unità di decoding...
Notato niente? Beh all'inizio nemmeno io...
Tra la microop queue e il dispatch si frappongono lo stack memfile e la microcode rom. Questo che vuol dire?
Partiamo dallo stack memfile. Qui nessuna sorpresa. Questa unità filtra e traduce le microop, cancellando quelle che non servono, perchè gestite all'interno e modificando quelle che dipendono dallo stack. Inoltre fa anche lo store to load forwarding, tracciando gli store e poi non spiega bene, ma comunque è chiaro che è fatto a livello di dispatch...
Passiamo alla microcode rom. Che diavolo ci fa qui? Se vediamo nella slide del decoding, dice che può decodificare 4 istruzioni, senza mai specificare se semplici, doppie ecc... Visto dove è messa la unità microcodice, io suppongo che i decoder, per le istruzioni microcodificate, forniscano semplicemente un entry point nella microcode rom, con annessi registri e immediati decodificati e poi a questo stadio le microop vengano effettivamente sparate... Anche nella uop cache c'è una sola uop che contiene solo il puntatore nella microcode rom!
Così si occupa pochissimo spazio nella uop cache e nella microop queue e i decoder non sono bloccati dalle istruzioni microcodificate, ma magari tradotte in un solo ciclo e magari fino 4 per ciclo anzichè una!
L'uovo di colombo!
bjt2
20-12-2016, 18:14
Una curiosità. Chi cacchio è intervenuto? La CIA? Il KGB? I servizi segreti cinesi? Non capisco... mi sembra strano... uno perde la faccia pubblicamente e si scusa, il moderatore cinese del forum Baidu (che essendo Cina se ne può sbattere altamente di qualsiasi cosa o rivalsa possa fare l'occidente) cancella l'articolo, individua chi l'ha fatto e posta con cosa l'ha fatto (E5 2660), ed il tutto in 24h. :confused: Lisa Su è dei servizi segreti?
Il tizio sospetta che sia stato egli stesso a cancellarlo... Sarebbe una cattiva pubblicità per un sito che vende componenti e sistemi assemblati...
Il tizio sospetta che sia stato egli stesso a cancellarlo... Sarebbe una cattiva pubblicità per un sito che vende componenti e sistemi assemblati...
bjt2
20-12-2016, 18:31
https://youtu.be/Ln9WKPEHm4w?t=1h20m04s
Qui se ho capito bene dice che la coda di ritiro FP è indipendente e separata da quella INT... :mbe: Questo vuol dire che può ritirare 8+8=16 istruzioni per ciclo, contro le 8 di skylake... :eek:
Qualcuno che capisce bene l'inglese può dare un ascolto od ho le travvegole?
EDIT: poi ho capito perchè dicono 20MB di cache. La cache L3 ha i tag anche di tutti i dati nelle altre cache L2. Se un core richiede un dato che non è nella L3 ma in una L2 di un altro core, questo viene spedito core to core... Quindi è come fossero 16+4MB di cache con 4 MB più veloci e 16 più lenti...
Qui se ho capito bene dice che la coda di ritiro FP è indipendente e separata da quella INT... :mbe: Questo vuol dire che può ritirare 8+8=16 istruzioni per ciclo, contro le 8 di skylake... :eek:
Qualcuno che capisce bene l'inglese può dare un ascolto od ho le travvegole?
EDIT: poi ho capito perchè dicono 20MB di cache. La cache L3 ha i tag anche di tutti i dati nelle altre cache L2. Se un core richiede un dato che non è nella L3 ma in una L2 di un altro core, questo viene spedito core to core... Quindi è come fossero 16+4MB di cache con 4 MB più veloci e 16 più lenti...
capitan_crasy
20-12-2016, 18:33
Una curiosità. Chi cacchio è intervenuto? La CIA? Il KGB? I servizi segreti cinesi? Non capisco... mi sembra strano... uno perde la faccia pubblicamente e si scusa, il moderatore cinese del forum Baidu (che essendo Cina se ne può sbattere altamente di qualsiasi cosa o rivalsa possa fare l'occidente) cancella l'articolo, individua chi l'ha fatto e posta con cosa l'ha fatto (E5 2660), ed il tutto in 24h. :confused: Lisa Su è dei servizi segreti?
E probabile che tu non ti ricordi ma di FAKE del genere ne sono passati parecchi negli scorsi thread...:O
E probabile che tu non ti ricordi ma di FAKE del genere ne sono passati parecchi negli scorsi thread...:O
paolo.oliva2
20-12-2016, 18:38
E probabile che tu non ti ricordi ma di FAKE del genere ne sono passati parecchi negli scorsi thread...:O
Mi ricordo, ma mi ricordo che erano rimati fino alla presentazione ufficiale...
Mi ricordo, ma mi ricordo che erano rimati fino alla presentazione ufficiale...
bjt2
20-12-2016, 19:17
Mamma mia...
Alla fine di quel video c'è la sessione di domande e risposte...
Sono gasatissimo... :D
Le più interessanti:
L1D ha ECC? Si. Aggiunge latenza? No.
Bus cache L3. Domanda in 2 step perchè il tizio non è stato chiaro la prima volta. E' 32 byte per direzione? No, totale. Ma 4 transazioni per ciclo. (da notare che il tizio era di INTEL)
La microcode rom: un tizio si chiede se la microcode dove è li causa problemi con istruzioni microcodificate in un loop, perchè non va nella uop cache. Il tizio risponde che questi diagrammi non sono accurati. Nella microopcache (come avevo pensato io :D) va il puntatore allo start nella microcode rom e poi si parte da li, così non si spreca spazio... :D
uop cache size: non lo dice... :D Dice che lo diranno dopo l'uscita...
Alla fine di quel video c'è la sessione di domande e risposte...
Sono gasatissimo... :D
Le più interessanti:
L1D ha ECC? Si. Aggiunge latenza? No.
Bus cache L3. Domanda in 2 step perchè il tizio non è stato chiaro la prima volta. E' 32 byte per direzione? No, totale. Ma 4 transazioni per ciclo. (da notare che il tizio era di INTEL)
La microcode rom: un tizio si chiede se la microcode dove è li causa problemi con istruzioni microcodificate in un loop, perchè non va nella uop cache. Il tizio risponde che questi diagrammi non sono accurati. Nella microopcache (come avevo pensato io :D) va il puntatore allo start nella microcode rom e poi si parte da li, così non si spreca spazio... :D
uop cache size: non lo dice... :D Dice che lo diranno dopo l'uscita...
riuzasan
20-12-2016, 19:40
https://youtu.be/Ln9WKPEHm4w?t=1h20m04s
Qui se ho capito bene dice che la coda di ritiro FP è indipendente e separata da quella INT... :mbe: Questo vuol dire che può ritirare 8+8=16 istruzioni per ciclo, contro le 8 di skylake... :eek:
Qualcuno che capisce bene l'inglese può dare un ascolto od ho le travvegole?
EDIT: poi ho capito perchè dicono 20MB di cache. La cache L3 ha i tag anche di tutti i dati nelle altre cache L2. Se un core richiede un dato che non è nella L3 ma in una L2 di un altro core, questo viene spedito core to core... Quindi è come fossero 16+4MB di cache con 4 MB più veloci e 16 più lenti...
Thx Bjt2, me l'ero perso.
Qui se ho capito bene dice che la coda di ritiro FP è indipendente e separata da quella INT... :mbe: Questo vuol dire che può ritirare 8+8=16 istruzioni per ciclo, contro le 8 di skylake... :eek:
Qualcuno che capisce bene l'inglese può dare un ascolto od ho le travvegole?
EDIT: poi ho capito perchè dicono 20MB di cache. La cache L3 ha i tag anche di tutti i dati nelle altre cache L2. Se un core richiede un dato che non è nella L3 ma in una L2 di un altro core, questo viene spedito core to core... Quindi è come fossero 16+4MB di cache con 4 MB più veloci e 16 più lenti...
Thx Bjt2, me l'ero perso.
paolo.oliva2
20-12-2016, 19:42
Mamma mia...
Alla fine di quel video c'è la sessione di domande e risposte...
Sono gasatissimo... :D
Le più interessanti:
L1D ha ECC? Si. Aggiunge latenza? No.
Bus cache L3. Domanda in 2 step perchè il tizio non è stato chiaro la prima volta. E' 32 byte per direzione? No, totale. Ma 4 transazioni per ciclo. (da notare che il tizio era di INTEL)
La microcode rom: un tizio si chiede se la microcode dove è li causa problemi con istruzioni microcodificate in un loop, perchè non va nella uop cache. Il tizio risponde che questi diagrammi non sono accurati. Nella microopcache (come avevo pensato io :D) va il puntatore allo start nella microcode rom e poi si parte da li, così non si spreca spazio... :D
uop cache size: non lo dice... :D Dice che lo diranno dopo l'uscita...
Quindi... a parte che che ci avevi beccato in dei punti... praticamente Keller... quanto ha stravolto, cosa ha stravolto e eventualmente quale potrebbe essere il range di guadagno. E' possibile che qualche cosa di tutta sta roba ancora non sia implementata e magari ci sia qualche worck-around?
BD e Zen si dice che avevano lo stesso sviluppo iniziale, poi AMD ha optato per Zen (probabile perchè il CMT non richiedeva interventi sull'IPC essenziali come l'SMT), ma è indubbio che sviluppo BD e evoluzione Zen possono avere delle cose in comune (almeno per quanto riguarda il risparmio energetico). Comunque AMD avrà sviluppato architetturalmente almeno su carta Zen in contemporanea a BD... ma dalla carta al silicio non sarebbe una montagna di cose? Come cacchio hanno fatto a fare il tutto in 1 anno sul 14nm GF? E poi con molta sicurezza, perchè avrebbero potuto comunque realizzare XV e fare tipo un tick tock all'Intel...
Ho scritto stronzate?
Alla fine di quel video c'è la sessione di domande e risposte...
Sono gasatissimo... :D
Le più interessanti:
L1D ha ECC? Si. Aggiunge latenza? No.
Bus cache L3. Domanda in 2 step perchè il tizio non è stato chiaro la prima volta. E' 32 byte per direzione? No, totale. Ma 4 transazioni per ciclo. (da notare che il tizio era di INTEL)
La microcode rom: un tizio si chiede se la microcode dove è li causa problemi con istruzioni microcodificate in un loop, perchè non va nella uop cache. Il tizio risponde che questi diagrammi non sono accurati. Nella microopcache (come avevo pensato io :D) va il puntatore allo start nella microcode rom e poi si parte da li, così non si spreca spazio... :D
uop cache size: non lo dice... :D Dice che lo diranno dopo l'uscita...
Quindi... a parte che che ci avevi beccato in dei punti... praticamente Keller... quanto ha stravolto, cosa ha stravolto e eventualmente quale potrebbe essere il range di guadagno. E' possibile che qualche cosa di tutta sta roba ancora non sia implementata e magari ci sia qualche worck-around?
BD e Zen si dice che avevano lo stesso sviluppo iniziale, poi AMD ha optato per Zen (probabile perchè il CMT non richiedeva interventi sull'IPC essenziali come l'SMT), ma è indubbio che sviluppo BD e evoluzione Zen possono avere delle cose in comune (almeno per quanto riguarda il risparmio energetico). Comunque AMD avrà sviluppato architetturalmente almeno su carta Zen in contemporanea a BD... ma dalla carta al silicio non sarebbe una montagna di cose? Come cacchio hanno fatto a fare il tutto in 1 anno sul 14nm GF? E poi con molta sicurezza, perchè avrebbero potuto comunque realizzare XV e fare tipo un tick tock all'Intel...
Ho scritto stronzate?
techfede
20-12-2016, 19:53
https://youtu.be/Ln9WKPEHm4w?t=1h20m04s
Qui se ho capito bene dice che la coda di ritiro FP è indipendente e separata da quella INT... :mbe: Questo vuol dire che può ritirare 8+8=16 istruzioni per ciclo, contro le 8 di skylake... :eek:
Qualcuno che capisce bene l'inglese può dare un ascolto od ho le travvegole?
EDIT: poi ho capito perchè dicono 20MB di cache. La cache L3 ha i tag anche di tutti i dati nelle altre cache L2. Se un core richiede un dato che non è nella L3 ma in una L2 di un altro core, questo viene spedito core to core... Quindi è come fossero 16+4MB di cache con 4 MB più veloci e 16 più lenti...
Dice "the 8-wide retire is independent of integer and floating point".
Detta così sembra che la coda di ritiro 8-wide è indipendente da quella int e fp, ma non so se ha senso :mbe:
Probabilmente ha più senso come hai detto tu, però diciamo che non si è espresso bene nemmeno lui, se è quello che voleva dire :D
Qui se ho capito bene dice che la coda di ritiro FP è indipendente e separata da quella INT... :mbe: Questo vuol dire che può ritirare 8+8=16 istruzioni per ciclo, contro le 8 di skylake... :eek:
Qualcuno che capisce bene l'inglese può dare un ascolto od ho le travvegole?
EDIT: poi ho capito perchè dicono 20MB di cache. La cache L3 ha i tag anche di tutti i dati nelle altre cache L2. Se un core richiede un dato che non è nella L3 ma in una L2 di un altro core, questo viene spedito core to core... Quindi è come fossero 16+4MB di cache con 4 MB più veloci e 16 più lenti...
Dice "the 8-wide retire is independent of integer and floating point".
Detta così sembra che la coda di ritiro 8-wide è indipendente da quella int e fp, ma non so se ha senso :mbe:
Probabilmente ha più senso come hai detto tu, però diciamo che non si è espresso bene nemmeno lui, se è quello che voleva dire :D
bjt2
20-12-2016, 20:10
Quindi... a parte che che ci avevi beccato in dei punti... praticamente Keller... quanto ha stravolto, cosa ha stravolto e eventualmente quale potrebbe essere il range di guadagno. E' possibile che qualche cosa di tutta sta roba ancora non sia implementata e magari ci sia qualche worck-around?
BD e Zen si dice che avevano lo stesso sviluppo iniziale, poi AMD ha optato per Zen (probabile perchè il CMT non richiedeva interventi sull'IPC essenziali come l'SMT), ma è indubbio che sviluppo BD e evoluzione Zen possono avere delle cose in comune (almeno per quanto riguarda il risparmio energetico). Comunque AMD avrà sviluppato architetturalmente almeno su carta Zen in contemporanea a BD... ma dalla carta al silicio non sarebbe una montagna di cose? Come cacchio hanno fatto a fare il tutto in 1 anno sul 14nm GF? E poi con molta sicurezza, perchè avrebbero potuto comunque realizzare XV e fare tipo un tick tock all'Intel...
Ho scritto stronzate?
Questa è roba che dovrebbe essere già dentro l'architettura... Io penso che stiano nascondento ST e cinebench perchè ci sono delle sorprese...
BD e Zen si dice che avevano lo stesso sviluppo iniziale, poi AMD ha optato per Zen (probabile perchè il CMT non richiedeva interventi sull'IPC essenziali come l'SMT), ma è indubbio che sviluppo BD e evoluzione Zen possono avere delle cose in comune (almeno per quanto riguarda il risparmio energetico). Comunque AMD avrà sviluppato architetturalmente almeno su carta Zen in contemporanea a BD... ma dalla carta al silicio non sarebbe una montagna di cose? Come cacchio hanno fatto a fare il tutto in 1 anno sul 14nm GF? E poi con molta sicurezza, perchè avrebbero potuto comunque realizzare XV e fare tipo un tick tock all'Intel...
Ho scritto stronzate?
Questa è roba che dovrebbe essere già dentro l'architettura... Io penso che stiano nascondento ST e cinebench perchè ci sono delle sorprese...
bjt2
20-12-2016, 20:11
Dice "the 8-wide retire is independent of integer and floating point".
Detta così sembra che la coda di ritiro 8-wide è indipendente da quella int e fp, ma non so se ha senso :mbe:
Probabilmente ha più senso come hai detto tu, però diciamo che non si è espresso bene nemmeno lui, se è quello che voleva dire :D
Comunque ha senso, perchè in SMT è partizionata. 4 per thread mi sembrano poche...
Detta così sembra che la coda di ritiro 8-wide è indipendente da quella int e fp, ma non so se ha senso :mbe:
Probabilmente ha più senso come hai detto tu, però diciamo che non si è espresso bene nemmeno lui, se è quello che voleva dire :D
Comunque ha senso, perchè in SMT è partizionata. 4 per thread mi sembrano poche...
affiu
20-12-2016, 20:12
domanda aperta a tutti:
Fino a quello che si è discusso e visto fino ad oggi, qualcuno potrebbe, sempre approssimativamente, dirmi quando farà uno zen x8 a 4,5ghz?
In poche parole quanto farebbe con 1,1ghz IN PIU rispetto a quello visto nell'evento ryzen su tutti gli 8 core, con tanto di sistemi a risparmio attivi(nell'uso che faccio del processore mi va bene) o meno?
rispetto ai bench presentati all'evento del 13 dicembre di quest'anno, cioè blender e l'altro che non mi ricordo, quanto più veloce andrebbe?
Cioè se facessero uno zen x8/16threads , stile aggressimo come frequenze di un fx 9590, tipo 140W tdp, 4,5ghz + turbo 5ghz il tutto a 14nm!....non se ne uscissero con il giorno?...belli puliti puliti sugli scaffali a prezzo aggressivo ach'esso, anche se è un pò troppo impegnativo definirlo approssimativamente.:D
A quando deve viaggiare in frequenza un fx 8350 per pareggiarlo?...10ghz:confused: :confused:
Fino a quello che si è discusso e visto fino ad oggi, qualcuno potrebbe, sempre approssimativamente, dirmi quando farà uno zen x8 a 4,5ghz?
In poche parole quanto farebbe con 1,1ghz IN PIU rispetto a quello visto nell'evento ryzen su tutti gli 8 core, con tanto di sistemi a risparmio attivi(nell'uso che faccio del processore mi va bene) o meno?
rispetto ai bench presentati all'evento del 13 dicembre di quest'anno, cioè blender e l'altro che non mi ricordo, quanto più veloce andrebbe?
Cioè se facessero uno zen x8/16threads , stile aggressimo come frequenze di un fx 9590, tipo 140W tdp, 4,5ghz + turbo 5ghz il tutto a 14nm!....non se ne uscissero con il giorno?...belli puliti puliti sugli scaffali a prezzo aggressivo ach'esso, anche se è un pò troppo impegnativo definirlo approssimativamente.:D
A quando deve viaggiare in frequenza un fx 8350 per pareggiarlo?...10ghz:confused: :confused:
bjt2
20-12-2016, 20:14
Su anand comunque hanno fatto notare che il tizio intel alla fine, a parte che non ha manco ringraziato, ma era un po' nervoso e "tossiva" per schiarirsi la voce spesso... :D
Piedone1113
20-12-2016, 20:26
Su anand comunque hanno fatto notare che il tizio intel alla fine, a parte che non ha manco ringraziato, ma era un po' nervoso e "tossiva" per schiarirsi la voce spesso... :D
Beh, se metti un lupo in mezzo a cento arieti (o montoni alias maschio della pecora) anche lui sarebbe nervoso e si preoccuperebbe di non innervosire nessuno :O
Beh, se metti un lupo in mezzo a cento arieti (o montoni alias maschio della pecora) anche lui sarebbe nervoso e si preoccuperebbe di non innervosire nessuno :O
Gioz
20-12-2016, 20:36
Guardiamo BD.
In poche parole l'8350 ha un determinato Vcore def, che non è soggettivo al procio, ma diciamo il Vcore più alto rispetto alla mandata e al tipo di selezione.
Esempio... io posso avere nella stessa mandata 1,28V per 4GHz, 1,31V, 1,26V. L'8350 a 1,35V non supera i 125W, a 1,42V non supera 125W in Turbo 4 core 4,2GHz.
A sto punto che al procio bastino 1,28V per 4Ghz o 1,35V, comunque verrà assegnato 1,35V, idem nel turbo.
Il TDP predittivo lo considero a questo modo, dove un 8320 ha dei parametri Vcore/frequenza per QUELLA selezione, l'8350 idem, l'8370 idem e il 9590 idem ancora.
è una cosa normale in ogni ambito questa:
valuti il caso peggiore (vcore più alto "necessario" in questo caso) ed applichi quello perché sai che non ci saranno problemi;
lo stesso tdp è riferito ad una temperatura ambientale di esercizio che, ad esempio, non è 12°C proprio perché possa essere considerata una sorta di caso peggiore tollerabile.
anche se prendi un amplificatore potresti avere un funzionamento praticamente perfetto con una tensione di alimentazione inferiore rispetto alla specifica riportata nel datasheet, ma ti indicano un valore di funzionamento certo.
domanda aperta a tutti:
Fino a quello che si è discusso e visto fino ad oggi, qualcuno potrebbe, sempre approssimativamente, dirmi quando farà uno zen x8 a 4,5ghz?
In poche parole quanto farebbe con 1,1ghz IN PIU rispetto a quello visto nell'evento ryzen su tutti gli 8 core, con tanto di sistemi a risparmio attivi(nell'uso che faccio del processore mi va bene) o meno?
rispetto ai bench presentati all'evento del 13 dicembre di quest'anno, cioè blender e l'altro che non mi ricordo, quanto più veloce andrebbe?
Cioè se facessero uno zen x8/16threads , stile aggressimo come frequenze di un fx 9590, tipo 140W tdp, 4,5ghz + turbo 5ghz il tutto a 14nm!....non se ne uscissero con il giorno?...belli puliti puliti sugli scaffali a prezzo aggressivo ach'esso, anche se è un pò troppo impegnativo definirlo approssimativamente.:D
A quando deve viaggiare in frequenza un fx 8350 per pareggiarlo?...10ghz:confused: :confused:
secondo me siamo nel dominio dell'improbabile.
mi sembrano troppe ipotesi tutte insieme per poter anche solo formualre qualcosa di plausibile.
anche prendendo per certezze assolute le poche informazioni ufficiali non sarebbe possibile fare proporzioni e/o valutazioni su una scala che data una condizione X permetta di determinare quella Y.
In poche parole l'8350 ha un determinato Vcore def, che non è soggettivo al procio, ma diciamo il Vcore più alto rispetto alla mandata e al tipo di selezione.
Esempio... io posso avere nella stessa mandata 1,28V per 4GHz, 1,31V, 1,26V. L'8350 a 1,35V non supera i 125W, a 1,42V non supera 125W in Turbo 4 core 4,2GHz.
A sto punto che al procio bastino 1,28V per 4Ghz o 1,35V, comunque verrà assegnato 1,35V, idem nel turbo.
Il TDP predittivo lo considero a questo modo, dove un 8320 ha dei parametri Vcore/frequenza per QUELLA selezione, l'8350 idem, l'8370 idem e il 9590 idem ancora.
è una cosa normale in ogni ambito questa:
valuti il caso peggiore (vcore più alto "necessario" in questo caso) ed applichi quello perché sai che non ci saranno problemi;
lo stesso tdp è riferito ad una temperatura ambientale di esercizio che, ad esempio, non è 12°C proprio perché possa essere considerata una sorta di caso peggiore tollerabile.
anche se prendi un amplificatore potresti avere un funzionamento praticamente perfetto con una tensione di alimentazione inferiore rispetto alla specifica riportata nel datasheet, ma ti indicano un valore di funzionamento certo.
domanda aperta a tutti:
Fino a quello che si è discusso e visto fino ad oggi, qualcuno potrebbe, sempre approssimativamente, dirmi quando farà uno zen x8 a 4,5ghz?
In poche parole quanto farebbe con 1,1ghz IN PIU rispetto a quello visto nell'evento ryzen su tutti gli 8 core, con tanto di sistemi a risparmio attivi(nell'uso che faccio del processore mi va bene) o meno?
rispetto ai bench presentati all'evento del 13 dicembre di quest'anno, cioè blender e l'altro che non mi ricordo, quanto più veloce andrebbe?
Cioè se facessero uno zen x8/16threads , stile aggressimo come frequenze di un fx 9590, tipo 140W tdp, 4,5ghz + turbo 5ghz il tutto a 14nm!....non se ne uscissero con il giorno?...belli puliti puliti sugli scaffali a prezzo aggressivo ach'esso, anche se è un pò troppo impegnativo definirlo approssimativamente.:D
A quando deve viaggiare in frequenza un fx 8350 per pareggiarlo?...10ghz:confused: :confused:
secondo me siamo nel dominio dell'improbabile.
mi sembrano troppe ipotesi tutte insieme per poter anche solo formualre qualcosa di plausibile.
anche prendendo per certezze assolute le poche informazioni ufficiali non sarebbe possibile fare proporzioni e/o valutazioni su una scala che data una condizione X permetta di determinare quella Y.
paolo.oliva2
20-12-2016, 21:19
Boh... oggi ho qualche neurone che mi lavora in più (o in meno)... mi sono venuti dei dubbi.
Cioè... l'FO4 può ottimizzare il consumo tra il gioco IPC * Frequenza nel risultato della medesima potenza.
fin qui ho capito... ma nel risultato comunque le unità logiche arrivano comunque a consumare, nel senso che nella stessa unità di tempo o in un modo o nell'altro risolvono le stesse operazioni.
Ora... evitiamo commenti perchè faccio un esempio, Zen potrebbe arrivare allo stesso valore di istruzioni elaborate con una frequenza maggiore ma con un IPC minore rispetto al 6900K, e magari consumando un po' meno per via che l'FO4 ottimizzerebbe il cosumo.
Però le unità logiche comunque elaborano gli stessi dati, quindi comunque il consumo non può essere molto diverso... e se il silicio 14nm Intel è migliore del 15% di quello GF, come cacchio fa Zen ad ottenere potenze simili ma addirittura consumare meno?
Possono tutti sti canali avanti e indietro e parallelli in qualche modo ridurre i transistor necessari? In fin dei conti le info di Zen lo danno 170/180mmq vs un 6900K che è circa 200mmq...
Cioè... l'FO4 può ottimizzare il consumo tra il gioco IPC * Frequenza nel risultato della medesima potenza.
fin qui ho capito... ma nel risultato comunque le unità logiche arrivano comunque a consumare, nel senso che nella stessa unità di tempo o in un modo o nell'altro risolvono le stesse operazioni.
Ora... evitiamo commenti perchè faccio un esempio, Zen potrebbe arrivare allo stesso valore di istruzioni elaborate con una frequenza maggiore ma con un IPC minore rispetto al 6900K, e magari consumando un po' meno per via che l'FO4 ottimizzerebbe il cosumo.
Però le unità logiche comunque elaborano gli stessi dati, quindi comunque il consumo non può essere molto diverso... e se il silicio 14nm Intel è migliore del 15% di quello GF, come cacchio fa Zen ad ottenere potenze simili ma addirittura consumare meno?
Possono tutti sti canali avanti e indietro e parallelli in qualche modo ridurre i transistor necessari? In fin dei conti le info di Zen lo danno 170/180mmq vs un 6900K che è circa 200mmq...
Piedone1113
20-12-2016, 22:36
Boh... oggi ho qualche neurone che mi lavora in più (o in meno)... mi sono venuti dei dubbi.
Cioè... l'FO4 può ottimizzare il consumo tra il gioco IPC * Frequenza nel risultato della medesima potenza.
fin qui ho capito... ma nel risultato comunque le unità logiche arrivano comunque a consumare, nel senso che nella stessa unità di tempo o in un modo o nell'altro risolvono le stesse operazioni.
Ora... evitiamo commenti perchè faccio un esempio, Zen potrebbe arrivare allo stesso valore di istruzioni elaborate con una frequenza maggiore ma con un IPC minore rispetto al 6900K, e magari consumando un po' meno per via che l'FO4 ottimizzerebbe il cosumo.
Però le unità logiche comunque elaborano gli stessi dati, quindi comunque il consumo non può essere molto diverso... e se il silicio 14nm Intel è migliore del 15% di quello GF, come cacchio fa Zen ad ottenere potenze simili ma addirittura consumare meno?
Possono tutti sti canali avanti e indietro e parallelli in qualche modo ridurre i transistor necessari? In fin dei conti le info di Zen lo danno 170/180mmq vs un 6900K che è circa 200mmq...
L' F04 è indice della catena logica meno incline a salire di frequenza nella cpu.
Se dividi la cpu in settori logico, ipotizziamo 50, di cui 49 capaci di 5 GHz ed uno di 1 GHz o lo fai lavorare in modo asincrono, oppure sei limitato ad 1 GHz.
La complessità ideale della cpu è limitata anche dal silicio ed un f04 di 13 può essere lOptimum su un pp che non sale.
Considera che la tecnologia Core è nata sul 45nm, ed ormai è vecchia ed ha bisogno di una profonda revisione su questi pp ( anche se Cesare non è d'accordo) mentre Zen è nata per il 20nm, cucita su misura, teoricamente più efficiente.
Cioè... l'FO4 può ottimizzare il consumo tra il gioco IPC * Frequenza nel risultato della medesima potenza.
fin qui ho capito... ma nel risultato comunque le unità logiche arrivano comunque a consumare, nel senso che nella stessa unità di tempo o in un modo o nell'altro risolvono le stesse operazioni.
Ora... evitiamo commenti perchè faccio un esempio, Zen potrebbe arrivare allo stesso valore di istruzioni elaborate con una frequenza maggiore ma con un IPC minore rispetto al 6900K, e magari consumando un po' meno per via che l'FO4 ottimizzerebbe il cosumo.
Però le unità logiche comunque elaborano gli stessi dati, quindi comunque il consumo non può essere molto diverso... e se il silicio 14nm Intel è migliore del 15% di quello GF, come cacchio fa Zen ad ottenere potenze simili ma addirittura consumare meno?
Possono tutti sti canali avanti e indietro e parallelli in qualche modo ridurre i transistor necessari? In fin dei conti le info di Zen lo danno 170/180mmq vs un 6900K che è circa 200mmq...
L' F04 è indice della catena logica meno incline a salire di frequenza nella cpu.
Se dividi la cpu in settori logico, ipotizziamo 50, di cui 49 capaci di 5 GHz ed uno di 1 GHz o lo fai lavorare in modo asincrono, oppure sei limitato ad 1 GHz.
La complessità ideale della cpu è limitata anche dal silicio ed un f04 di 13 può essere lOptimum su un pp che non sale.
Considera che la tecnologia Core è nata sul 45nm, ed ormai è vecchia ed ha bisogno di una profonda revisione su questi pp ( anche se Cesare non è d'accordo) mentre Zen è nata per il 20nm, cucita su misura, teoricamente più efficiente.
george_p
20-12-2016, 23:30
Direttamente dal canale youtube di amd:
https://www.youtube.com/user/amd/videos
Delle'evento New Horizon comunque.
https://www.youtube.com/user/amd/videos
Delle'evento New Horizon comunque.
paolo.oliva2
20-12-2016, 23:43
L' F04 è indice della catena logica meno incline a salire di frequenza nella cpu.
Se dividi la cpu in settori logico, ipotizziamo 50, di cui 49 capaci di 5 GHz ed uno di 1 GHz o lo fai lavorare in modo asincrono, oppure sei limitato ad 1 GHz.
La complessità ideale della cpu è limitata anche dal silicio ed un f04 di 13 può essere lOptimum su un pp che non sale.
Considera che la tecnologia Core è nata sul 45nm, ed ormai è vecchia ed ha bisogno di una profonda revisione su questi pp ( anche se Cesare non è d'accordo) mentre Zen è nata per il 20nm, cucita su misura, teoricamente più efficiente.
Capito a grandi linee. In teoria il nuovo salto di Zen che sarebbe sul 7nm ma mi sembra 14 sarebbe ancora "compatibile".
Quindi KabyLake dovrebbe essere ancora sulla vecchia ottimizzazione, ma sarebbe probabile che con il salto al 10nm Intel cambi qualche cosa?
Se dividi la cpu in settori logico, ipotizziamo 50, di cui 49 capaci di 5 GHz ed uno di 1 GHz o lo fai lavorare in modo asincrono, oppure sei limitato ad 1 GHz.
La complessità ideale della cpu è limitata anche dal silicio ed un f04 di 13 può essere lOptimum su un pp che non sale.
Considera che la tecnologia Core è nata sul 45nm, ed ormai è vecchia ed ha bisogno di una profonda revisione su questi pp ( anche se Cesare non è d'accordo) mentre Zen è nata per il 20nm, cucita su misura, teoricamente più efficiente.
Capito a grandi linee. In teoria il nuovo salto di Zen che sarebbe sul 7nm ma mi sembra 14 sarebbe ancora "compatibile".
Quindi KabyLake dovrebbe essere ancora sulla vecchia ottimizzazione, ma sarebbe probabile che con il salto al 10nm Intel cambi qualche cosa?
capitan_crasy
20-12-2016, 23:48
http://i.imgur.com/A6Rsqg5h.jpg (http://imgur.com/A6Rsqg5)
Clicca qui... (http://www.amd.com/en-us/markets/digital-fan-kit-download?utm_source=silverpop&utm_medium=email&utm_campaign=27384670&utm_term=btn_calendar&utm_content=Global-general-product-technology-announcement-zen-post-event-en%20(1):&spMailingID=27384670&spUserID=NDEzOTUyMDc2OTUyS0&spJobID=944223550&spReportId=OTQ0MjIzNTUwS0#ryzen-themed-assets)
Clicca qui... (http://www.amd.com/en-us/markets/digital-fan-kit-download?utm_source=silverpop&utm_medium=email&utm_campaign=27384670&utm_term=btn_calendar&utm_content=Global-general-product-technology-announcement-zen-post-event-en%20(1):&spMailingID=27384670&spUserID=NDEzOTUyMDc2OTUyS0&spJobID=944223550&spReportId=OTQ0MjIzNTUwS0#ryzen-themed-assets)
Free Gordon
21-12-2016, 01:40
uop cache size: non lo dice... :D Dice che lo diranno dopo l'uscita...
E' così importante..?
E' così importante..?
Free Gordon
21-12-2016, 01:44
Clicca qui...[/URL]
Tutte le volte che la vedo, mi chiedo se abbia un senso questa immagine oppure no... (nel senso che rimandi solamente a qualcosa di "oriental-buddista" in generale... e nulla più). :D
Tutte le volte che la vedo, mi chiedo se abbia un senso questa immagine oppure no... (nel senso che rimandi solamente a qualcosa di "oriental-buddista" in generale... e nulla più). :D
bjt2
21-12-2016, 07:46
E' così importante..?
Beh, visto che le microcodificate occupano solo uno slot, può anche essere uguale a INTEL... Comunque sarà meglio... :D
Beh, visto che le microcodificate occupano solo uno slot, può anche essere uguale a INTEL... Comunque sarà meglio... :D
techfede
21-12-2016, 08:09
Comunque ha senso, perchè in SMT è partizionata. 4 per thread mi sembrano poche...
Quindi vuol dire che che in un dato momento potrebbero esserci 8fp ad usare quel 8-wide retrival oppure 8int, oppure un mix delle due?
Quindi vuol dire che che in un dato momento potrebbero esserci 8fp ad usare quel 8-wide retrival oppure 8int, oppure un mix delle due?
bjt2
21-12-2016, 09:40
Quindi vuol dire che che in un dato momento potrebbero esserci 8fp ad usare quel 8-wide retrival oppure 8int, oppure un mix delle due?
Se ho capito bene sono 8 per l'int (partizionate in 4+4 in smt mode) PIU' 8 per l'FP (sempre partizionate 4+4 in smt mode)
Se ho capito bene sono 8 per l'int (partizionate in 4+4 in smt mode) PIU' 8 per l'FP (sempre partizionate 4+4 in smt mode)
paolo.oliva2
21-12-2016, 10:52
è una cosa normale in ogni ambito questa:
valuti il caso peggiore (vcore più alto "necessario" in questo caso) ed applichi quello perché sai che non ci saranno problemi;
lo stesso tdp è riferito ad una temperatura ambientale di esercizio che, ad esempio, non è 12°C proprio perché possa essere considerata una sorta di caso peggiore tollerabile.
anche se prendi un amplificatore potresti avere un funzionamento praticamente perfetto con una tensione di alimentazione inferiore rispetto alla specifica riportata nel datasheet, ma ti indicano un valore di funzionamento certo.
Ma infatti era questo il problema del TDP predittivo di AMD rapportato al consumo effettivo, perchè di fatto applichi il Vcore peggiore a tutti i proci, di conseguenza il TDP peggiore. Praticamente è come se 125W TDP di fatto rappresentino il caso peggiore di qualsiasi 8350 nella condizione peggiore.
Il discorso del Turbo in BD, è una sorta di cammuffamento, perchè se in base al carico dei core sono messi in idle, allora aumenta la frequenza e il Vcore applicato è come quello del Vcore def su tutti i core, cioè il Vcore più alto dell'intera produzione e bla bla bla.
Zen ha dei microstep di 25MHz. A parte quello che scrivono che con i paroloni sembra un qualche cosa di soprannaturale, un controllo così microscopico ha senso unicamente se rapportato ad una sensibilità di rilevamento altrettanto microscopica, e questo mi sembra palese che sia possibile unicamente se percepita in tempo reale e non predittivo.
Ma è anche perquesto che se il Vcore/frequenza interagiscono tra loro, il Vcore applicato all'origine assume un valore nullo perchè è lo stesso circuito che poi varierà la tensione.
Io non ho competenze a riguardo... voglio fantasticare e probabilmente scriverò un tot di cazzate. Se V = R*I, e I dovrebbe essere costante nei transistor, allora V cambierà in base a R, che dovrebbe essere il silicio più o meno "pulito" con una resistenza più o meno marcata. Se si mappasse sta R nel range di funzionamento, e probabilmente a core, magari nel ciclo di test e selezione procio, salvando i dati, si potrebbe avere il quadro preciso sia di potenzialità procio, che di funzionamento il più efficiente possibile.
In questo ambito, il modello TOP potrebbe si costare di più perchè top, ma giustificare quasi il raddoppio del prezzo (300$ --> 500$) semplicemente perchè la mappatura potrebbe avere range molto più esteso.
Ad esempio, un modello base al più potrebbe essere mappato fino ad una certa frequenza def tutti i core, poi proseguire solamente nei core "migliori" e fino ad una determinata frequenza. Nel modello TOP il range potrebbe essere anche più elevato, di qui un costo superiore e giustificando, in parte il prezzaggio (dei rumors) superiore.
Se poi fosse possibile variare Vcore/frequenza senza bisogno di una mappatura, cioè a caldo... bo' non ne ho idea.
Però, credo che sta menata dei Bios dentro il procio, sia in parte questo. Ricordo che nel bios delle AM3+ c'era una sorta di mappatura del procio... e AOD, il software di OC di AMD, riportava parti disattivate o attivate in base al bios della mobo. Questo lo dico per certo perchè ricordo che in alcune occasioni, con la stessa mobo/procio, la stessa versione di AOD contemplava parti prima disattivate dopo l'aggiornamento del bios. Quindi potrebbe essere stato interpretato come bios dentro il procio semplicemente la mappatura del procio sull'alimentazione... e se sta mappatura fosse bloccata ad una certa frequenza, di fatto il procio sarebbe come bloccato. Io sono dell'idea che AMD non può permettersi di bloccare Zen, per via degli i7 X4 K, ma potrebbe bloccare il funzionamento come X8 ad una certa frequenza e lasciarlo libero come X4. In fin dei conti in questo modo si avrebbe un X8 che potrebbe competere con gli i7 X4 perchè sbloccato fino a X4, prezzandolo poco, ma nel contempo non "disturbare" le vendite di X8 più costosi, ma appunto perchè X8 a frequenze più alte, andrebbero considerati vs i7 E.
valuti il caso peggiore (vcore più alto "necessario" in questo caso) ed applichi quello perché sai che non ci saranno problemi;
lo stesso tdp è riferito ad una temperatura ambientale di esercizio che, ad esempio, non è 12°C proprio perché possa essere considerata una sorta di caso peggiore tollerabile.
anche se prendi un amplificatore potresti avere un funzionamento praticamente perfetto con una tensione di alimentazione inferiore rispetto alla specifica riportata nel datasheet, ma ti indicano un valore di funzionamento certo.
Ma infatti era questo il problema del TDP predittivo di AMD rapportato al consumo effettivo, perchè di fatto applichi il Vcore peggiore a tutti i proci, di conseguenza il TDP peggiore. Praticamente è come se 125W TDP di fatto rappresentino il caso peggiore di qualsiasi 8350 nella condizione peggiore.
Il discorso del Turbo in BD, è una sorta di cammuffamento, perchè se in base al carico dei core sono messi in idle, allora aumenta la frequenza e il Vcore applicato è come quello del Vcore def su tutti i core, cioè il Vcore più alto dell'intera produzione e bla bla bla.
Zen ha dei microstep di 25MHz. A parte quello che scrivono che con i paroloni sembra un qualche cosa di soprannaturale, un controllo così microscopico ha senso unicamente se rapportato ad una sensibilità di rilevamento altrettanto microscopica, e questo mi sembra palese che sia possibile unicamente se percepita in tempo reale e non predittivo.
Ma è anche perquesto che se il Vcore/frequenza interagiscono tra loro, il Vcore applicato all'origine assume un valore nullo perchè è lo stesso circuito che poi varierà la tensione.
Io non ho competenze a riguardo... voglio fantasticare e probabilmente scriverò un tot di cazzate. Se V = R*I, e I dovrebbe essere costante nei transistor, allora V cambierà in base a R, che dovrebbe essere il silicio più o meno "pulito" con una resistenza più o meno marcata. Se si mappasse sta R nel range di funzionamento, e probabilmente a core, magari nel ciclo di test e selezione procio, salvando i dati, si potrebbe avere il quadro preciso sia di potenzialità procio, che di funzionamento il più efficiente possibile.
In questo ambito, il modello TOP potrebbe si costare di più perchè top, ma giustificare quasi il raddoppio del prezzo (300$ --> 500$) semplicemente perchè la mappatura potrebbe avere range molto più esteso.
Ad esempio, un modello base al più potrebbe essere mappato fino ad una certa frequenza def tutti i core, poi proseguire solamente nei core "migliori" e fino ad una determinata frequenza. Nel modello TOP il range potrebbe essere anche più elevato, di qui un costo superiore e giustificando, in parte il prezzaggio (dei rumors) superiore.
Se poi fosse possibile variare Vcore/frequenza senza bisogno di una mappatura, cioè a caldo... bo' non ne ho idea.
Però, credo che sta menata dei Bios dentro il procio, sia in parte questo. Ricordo che nel bios delle AM3+ c'era una sorta di mappatura del procio... e AOD, il software di OC di AMD, riportava parti disattivate o attivate in base al bios della mobo. Questo lo dico per certo perchè ricordo che in alcune occasioni, con la stessa mobo/procio, la stessa versione di AOD contemplava parti prima disattivate dopo l'aggiornamento del bios. Quindi potrebbe essere stato interpretato come bios dentro il procio semplicemente la mappatura del procio sull'alimentazione... e se sta mappatura fosse bloccata ad una certa frequenza, di fatto il procio sarebbe come bloccato. Io sono dell'idea che AMD non può permettersi di bloccare Zen, per via degli i7 X4 K, ma potrebbe bloccare il funzionamento come X8 ad una certa frequenza e lasciarlo libero come X4. In fin dei conti in questo modo si avrebbe un X8 che potrebbe competere con gli i7 X4 perchè sbloccato fino a X4, prezzandolo poco, ma nel contempo non "disturbare" le vendite di X8 più costosi, ma appunto perchè X8 a frequenze più alte, andrebbero considerati vs i7 E.
Gioz
21-12-2016, 11:07
Ma infatti era questo il problema del TDP predittivo di AMD rapportato al consumo effettivo, perchè di fatto applichi il Vcore peggiore a tutti i proci, di conseguenza il TDP peggiore. Praticamente è come se 125W TDP di fatto rappresentino il caso peggiore di qualsiasi 8350 nella condizione peggiore.
Il discorso del Turbo in BD, è una sorta di cammuffamento, perchè se in base al carico dei core sono messi in idle, allora aumenta la frequenza e il Vcore applicato è come quello del Vcore def su tutti i core, cioè il Vcore più alto dell'intera produzione e bla bla bla.
Zen ha dei microstep di 25MHz. A parte quello che scrivono che con i paroloni sembra un qualche cosa di soprannaturale, un controllo così microscopico ha senso unicamente se rapportato ad una sensibilità di rilevamento altrettanto microscopica, e questo mi sembra palese che sia possibile unicamente se percepita in tempo reale e non predittivo.
Ma è anche perquesto che se il Vcore/frequenza interagiscono tra loro, il Vcore applicato all'origine assume un valore nullo perchè è lo stesso circuito che poi varierà la tensione.
Io non ho competenze a riguardo... voglio fantasticare e probabilmente scriverò un tot di cazzate. Se V = R*I, e I dovrebbe essere costante nei transistor, allora V cambierà in base a R, che dovrebbe essere il silicio più o meno "pulito" con una resistenza più o meno marcata. Se si mappasse sta R nel range di funzionamento, e probabilmente a core, magari nel ciclo di test e selezione procio, salvando i dati, si potrebbe avere il quadro preciso sia di potenzialità procio, che di funzionamento il più efficiente possibile.
In questo ambito, il modello TOP potrebbe si costare di più perchè top, ma giustificare quasi il raddoppio del prezzo (300$ --> 500$) semplicemente perchè la mappatura potrebbe avere range molto più esteso.
Ad esempio, un modello base al più potrebbe essere mappato fino ad una certa frequenza def tutti i core, poi proseguire solamente nei core "migliori" e fino ad una determinata frequenza. Nel modello TOP il range potrebbe essere anche più elevato, di qui un costo superiore e giustificando, in parte il prezzaggio (dei rumors) superiore.
Se poi fosse possibile variare Vcore/frequenza senza bisogno di una mappatura, cioè a caldo... bo' non ne ho idea.
Però, credo che sta menata dei Bios dentro il procio, sia in parte questo. Ricordo che nel bios delle AM3+ c'era una sorta di mappatura del procio... e AOD, il software di OC di AMD, riportava parti disattivate o attivate in base al bios della mobo. Questo lo dico per certo perchè ricordo che in alcune occasioni, con la stessa mobo/procio, la stessa versione di AOD contemplava parti prima disattivate dopo l'aggiornamento del bios. Quindi potrebbe essere stato interpretato come bios dentro il procio semplicemente la mappatura del procio sull'alimentazione... e se sta mappatura fosse bloccata ad una certa frequenza, di fatto il procio sarebbe come bloccato. Io sono dell'idea che AMD non può permettersi di bloccare Zen, per via degli i7 X4 K, ma potrebbe bloccare il funzionamento come X8 ad una certa frequenza e lasciarlo libero come X4. In fin dei conti in questo modo si avrebbe un X8 che potrebbe competere con gli i7 X4 perchè sbloccato fino a X4, prezzandolo poco, ma nel contempo non "disturbare" le vendite di X8 più costosi, ma appunto perchè X8 a frequenze più alte, andrebbero considerati vs i7 E.
stai facendo supposizioni basate su un'idea estremamente aleatoria.
inotlre stai ancora considerando i transistor come fossero delle microscopiche resistenze cui applicare una tensione e far passare una corrente.:muro:
Il discorso del Turbo in BD, è una sorta di cammuffamento, perchè se in base al carico dei core sono messi in idle, allora aumenta la frequenza e il Vcore applicato è come quello del Vcore def su tutti i core, cioè il Vcore più alto dell'intera produzione e bla bla bla.
Zen ha dei microstep di 25MHz. A parte quello che scrivono che con i paroloni sembra un qualche cosa di soprannaturale, un controllo così microscopico ha senso unicamente se rapportato ad una sensibilità di rilevamento altrettanto microscopica, e questo mi sembra palese che sia possibile unicamente se percepita in tempo reale e non predittivo.
Ma è anche perquesto che se il Vcore/frequenza interagiscono tra loro, il Vcore applicato all'origine assume un valore nullo perchè è lo stesso circuito che poi varierà la tensione.
Io non ho competenze a riguardo... voglio fantasticare e probabilmente scriverò un tot di cazzate. Se V = R*I, e I dovrebbe essere costante nei transistor, allora V cambierà in base a R, che dovrebbe essere il silicio più o meno "pulito" con una resistenza più o meno marcata. Se si mappasse sta R nel range di funzionamento, e probabilmente a core, magari nel ciclo di test e selezione procio, salvando i dati, si potrebbe avere il quadro preciso sia di potenzialità procio, che di funzionamento il più efficiente possibile.
In questo ambito, il modello TOP potrebbe si costare di più perchè top, ma giustificare quasi il raddoppio del prezzo (300$ --> 500$) semplicemente perchè la mappatura potrebbe avere range molto più esteso.
Ad esempio, un modello base al più potrebbe essere mappato fino ad una certa frequenza def tutti i core, poi proseguire solamente nei core "migliori" e fino ad una determinata frequenza. Nel modello TOP il range potrebbe essere anche più elevato, di qui un costo superiore e giustificando, in parte il prezzaggio (dei rumors) superiore.
Se poi fosse possibile variare Vcore/frequenza senza bisogno di una mappatura, cioè a caldo... bo' non ne ho idea.
Però, credo che sta menata dei Bios dentro il procio, sia in parte questo. Ricordo che nel bios delle AM3+ c'era una sorta di mappatura del procio... e AOD, il software di OC di AMD, riportava parti disattivate o attivate in base al bios della mobo. Questo lo dico per certo perchè ricordo che in alcune occasioni, con la stessa mobo/procio, la stessa versione di AOD contemplava parti prima disattivate dopo l'aggiornamento del bios. Quindi potrebbe essere stato interpretato come bios dentro il procio semplicemente la mappatura del procio sull'alimentazione... e se sta mappatura fosse bloccata ad una certa frequenza, di fatto il procio sarebbe come bloccato. Io sono dell'idea che AMD non può permettersi di bloccare Zen, per via degli i7 X4 K, ma potrebbe bloccare il funzionamento come X8 ad una certa frequenza e lasciarlo libero come X4. In fin dei conti in questo modo si avrebbe un X8 che potrebbe competere con gli i7 X4 perchè sbloccato fino a X4, prezzandolo poco, ma nel contempo non "disturbare" le vendite di X8 più costosi, ma appunto perchè X8 a frequenze più alte, andrebbero considerati vs i7 E.
stai facendo supposizioni basate su un'idea estremamente aleatoria.
inotlre stai ancora considerando i transistor come fossero delle microscopiche resistenze cui applicare una tensione e far passare una corrente.:muro:
george_p
21-12-2016, 12:08
BD e Zen si dice che avevano lo stesso sviluppo iniziale, poi AMD ha optato per Zen (probabile perchè il CMT non richiedeva interventi sull'IPC essenziali come l'SMT), ma è indubbio che sviluppo BD e evoluzione Zen possono avere delle cose in comune (almeno per quanto riguarda il risparmio energetico). Comunque AMD avrà sviluppato architetturalmente almeno su carta Zen in contemporanea a BD... ma dalla carta al silicio non sarebbe una montagna di cose? Come cacchio hanno fatto a fare il tutto in 1 anno sul 14nm GF? E poi con molta sicurezza, perchè avrebbero potuto comunque realizzare XV e fare tipo un tick tock all'Intel...
Ho scritto stronzate?
Scusa, ma ogni tanto ne leggo una nuova davvero.
Dove e chi dice che BD e Zen avevano lo stesso sviluppo iniziale?
Ho sempre letto che BD ha avuto uno sviluppo lento, ma leeento, così lento che il caro Meyer ci ha messo anni per farlo uscire e il risultato è stato a dir poco penoso.
Zen nasce per far retromarcia da un prodotto che per amd si è rivelato ancora più fallimentare di una architettura, quella phenom derivante dall'athlon, che a parte il silicio 45 non ha mai potuto competere con la concorrenza per il solo motivo di testardaggine dei dirigenti a non voler implementare il proprio SMT, tecnologia che era già allo studio dall'epoca degli athlon.
Che Zen prenda tutto quello che di buono ha realizzato AMD e dai suoi millemila brevetti è risaputo, che Zen sia stato sviluppato assieme a BD è cosa che non ho mai letto.
Poi se vogliamo parlare di nomi, ok, ma un conto è l'architettura in se e un conto è un nome che puoi dare a qualunque progetto a prescindere dal tipo e dal tempo.
Ho scritto stronzate?
Scusa, ma ogni tanto ne leggo una nuova davvero.
Dove e chi dice che BD e Zen avevano lo stesso sviluppo iniziale?
Ho sempre letto che BD ha avuto uno sviluppo lento, ma leeento, così lento che il caro Meyer ci ha messo anni per farlo uscire e il risultato è stato a dir poco penoso.
Zen nasce per far retromarcia da un prodotto che per amd si è rivelato ancora più fallimentare di una architettura, quella phenom derivante dall'athlon, che a parte il silicio 45 non ha mai potuto competere con la concorrenza per il solo motivo di testardaggine dei dirigenti a non voler implementare il proprio SMT, tecnologia che era già allo studio dall'epoca degli athlon.
Che Zen prenda tutto quello che di buono ha realizzato AMD e dai suoi millemila brevetti è risaputo, che Zen sia stato sviluppato assieme a BD è cosa che non ho mai letto.
Poi se vogliamo parlare di nomi, ok, ma un conto è l'architettura in se e un conto è un nome che puoi dare a qualunque progetto a prescindere dal tipo e dal tempo.
Wolfhang
21-12-2016, 13:53
Scusa, ma ogni tanto ne leggo una nuova davvero.
Dove e chi dice che BD e Zen avevano lo stesso sviluppo iniziale?
Ho sempre letto che BD ha avuto uno sviluppo lento, ma leeento, così lento che il caro Meyer ci ha messo anni per farlo uscire e il risultato è stato a dir poco penoso.
Zen nasce per far retromarcia da un prodotto che per amd si è rivelato ancora più fallimentare di una architettura, quella phenom derivante dall'athlon, che a parte il silicio 45 non ha mai potuto competere con la concorrenza per il solo motivo di testardaggine dei dirigenti a non voler implementare il proprio SMT, tecnologia che era già allo studio dall'epoca degli athlon.
Che Zen prenda tutto quello che di buono ha realizzato AMD e dai suoi millemila brevetti è risaputo, che Zen sia stato sviluppato assieme a BD è cosa che non ho mai letto.
Poi se vogliamo parlare di nomi, ok, ma un conto è l'architettura in se e un conto è un nome che puoi dare a qualunque progetto a prescindere dal tipo e dal tempo.
Ormai Paolo pur di difendere Bulldozer non sa più cosa inventarsi....
AMD stessa ha dichiarato che lo sviluppo di ZEN è iniziato nel 2012......una nuova architettura a pochi mesi dal rilascio di Bulldozer, richiamando in fretta e furia Jim Keller.......chissà come mai......:fiufiu:
Dove e chi dice che BD e Zen avevano lo stesso sviluppo iniziale?
Ho sempre letto che BD ha avuto uno sviluppo lento, ma leeento, così lento che il caro Meyer ci ha messo anni per farlo uscire e il risultato è stato a dir poco penoso.
Zen nasce per far retromarcia da un prodotto che per amd si è rivelato ancora più fallimentare di una architettura, quella phenom derivante dall'athlon, che a parte il silicio 45 non ha mai potuto competere con la concorrenza per il solo motivo di testardaggine dei dirigenti a non voler implementare il proprio SMT, tecnologia che era già allo studio dall'epoca degli athlon.
Che Zen prenda tutto quello che di buono ha realizzato AMD e dai suoi millemila brevetti è risaputo, che Zen sia stato sviluppato assieme a BD è cosa che non ho mai letto.
Poi se vogliamo parlare di nomi, ok, ma un conto è l'architettura in se e un conto è un nome che puoi dare a qualunque progetto a prescindere dal tipo e dal tempo.
Ormai Paolo pur di difendere Bulldozer non sa più cosa inventarsi....
AMD stessa ha dichiarato che lo sviluppo di ZEN è iniziato nel 2012......una nuova architettura a pochi mesi dal rilascio di Bulldozer, richiamando in fretta e furia Jim Keller.......chissà come mai......:fiufiu:
paolo.oliva2
21-12-2016, 13:54
Scusa, ma ogni tanto ne leggo una nuova davvero.
Dove e chi dice che BD e Zen avevano lo stesso sviluppo iniziale?
Era stato riportato nel TH che lo studio iniziale di Zen era dello stesso periodo di Buldozer.
Di mio (mia idea) posso supporre che sia stato scelto BD perchè l'implementazione dell'SMT non può esistere su una architettura povera di IPC, mentre il CMT si, ed è per questo che AMD a suo tempo potrebbe aver scelto il CMT al posto dell'SMT.
Ho sempre letto che BD ha avuto uno sviluppo lento, ma leeento, così lento che il caro Meyer ci ha messo anni per farlo uscire e il risultato è stato a dir poco penoso.
Lo sviluppo di qualsiasi cosa è proporzionale ai dindi che ci spendi, sia in termini di qualità che di rapidità di completamento.
Se paragoni le features nuove realizzate su Zen (e la mole di brevetti depositati) e quanto invece implementato su BD, non mi meravigliano affatto dei tempi superiori di BD.
Zen nasce per far retromarcia da un prodotto che per amd si è rivelato ancora più fallimentare di una architettura, quella phenom derivante dall'athlon, che a parte il silicio 45 non ha mai potuto competere con la concorrenza per il solo motivo di testardaggine dei dirigenti a non voler implementare il proprio SMT, tecnologia che era già allo studio dall'epoca degli athlon.
Lo sai che abbiamo idee diverse in merito.
Il CMT era la soluzione economica per avere un 2° TH risparmiando il 20% di transistor rispetto a 2 core, l'SMT invece aumenta del 20% (mi sembra) i transistor del core, ma la differenza è che il CMT concede l'80% in più nel secondo TH contro il 30% dell'SMT, quindi l'architettura SMT richiede un IPC core alto, l'architettura CMT no.
Che Zen prenda tutto quello che di buono ha realizzato AMD e dai suoi millemila brevetti è risaputo, che Zen sia stato sviluppato assieme a BD è cosa che non ho mai letto.
Io non ho detto questo, io ho scritto che Zen e BD hanno le stesse date di progettazione, leggendo il post qui nel TH, ma di progettazione non vuole dire che l'hanno continuato assieme, semplicemente che il progetto iniziale, presumo di carta, è rimasto a livello di carta quello di Zen e invece è finito sul silicio quello di BD.
Poi se vogliamo parlare di nomi, ok, ma un conto è l'architettura in se e un conto è un nome che puoi dare a qualunque progetto a prescindere dal tipo e dal tempo.
CMT/SMT rappresentano 2 soluzioni per aumentare le prestazioni di un procio risparmiando sul TDP.
Il CMT cosa fa? Condivide 2 core risparmiando il 20% di transistor con un -10% di potenza finale. +80% nel secondo TH equivale ad una perdita del 10% su 2 core (100 * 2 = 200), 10% = 180, a -10% rispetto a 2 core e -20% sul 2° TH.
L'SMT produce un +30% di potenza con un "costo" del 20% di transistor. E' sempre un +10%.
L'SMT è più parco del CMT se si considerano i transistor finali, ma è ovvio che a parità di IPC, il CMT non richiede investimenti sull'IPC.
Con IPC 100 alla fonte, con CMT ottieni 180, con SMT ottieni 130.
Nel momento in cui AMD realizza un core con più IPC, non sceglie l'SMT perchè il CMT è una ciofeca, lo sceglie, appunto, perchè con un IPC superiore in partenza, è più conveniente l'SMT al CMT.
Quindi BD/CMT era una soluzione a quei tempi, Zen/SMT è la soluzione odierna. BD/SMT non poteva MAI esistere allora, come oggi non potrebbe esistere ZEN/CMT, perchè richiederebbe più transistor rispetto all'SMT.
Dove e chi dice che BD e Zen avevano lo stesso sviluppo iniziale?
Era stato riportato nel TH che lo studio iniziale di Zen era dello stesso periodo di Buldozer.
Di mio (mia idea) posso supporre che sia stato scelto BD perchè l'implementazione dell'SMT non può esistere su una architettura povera di IPC, mentre il CMT si, ed è per questo che AMD a suo tempo potrebbe aver scelto il CMT al posto dell'SMT.
Ho sempre letto che BD ha avuto uno sviluppo lento, ma leeento, così lento che il caro Meyer ci ha messo anni per farlo uscire e il risultato è stato a dir poco penoso.
Lo sviluppo di qualsiasi cosa è proporzionale ai dindi che ci spendi, sia in termini di qualità che di rapidità di completamento.
Se paragoni le features nuove realizzate su Zen (e la mole di brevetti depositati) e quanto invece implementato su BD, non mi meravigliano affatto dei tempi superiori di BD.
Zen nasce per far retromarcia da un prodotto che per amd si è rivelato ancora più fallimentare di una architettura, quella phenom derivante dall'athlon, che a parte il silicio 45 non ha mai potuto competere con la concorrenza per il solo motivo di testardaggine dei dirigenti a non voler implementare il proprio SMT, tecnologia che era già allo studio dall'epoca degli athlon.
Lo sai che abbiamo idee diverse in merito.
Il CMT era la soluzione economica per avere un 2° TH risparmiando il 20% di transistor rispetto a 2 core, l'SMT invece aumenta del 20% (mi sembra) i transistor del core, ma la differenza è che il CMT concede l'80% in più nel secondo TH contro il 30% dell'SMT, quindi l'architettura SMT richiede un IPC core alto, l'architettura CMT no.
Che Zen prenda tutto quello che di buono ha realizzato AMD e dai suoi millemila brevetti è risaputo, che Zen sia stato sviluppato assieme a BD è cosa che non ho mai letto.
Io non ho detto questo, io ho scritto che Zen e BD hanno le stesse date di progettazione, leggendo il post qui nel TH, ma di progettazione non vuole dire che l'hanno continuato assieme, semplicemente che il progetto iniziale, presumo di carta, è rimasto a livello di carta quello di Zen e invece è finito sul silicio quello di BD.
Poi se vogliamo parlare di nomi, ok, ma un conto è l'architettura in se e un conto è un nome che puoi dare a qualunque progetto a prescindere dal tipo e dal tempo.
CMT/SMT rappresentano 2 soluzioni per aumentare le prestazioni di un procio risparmiando sul TDP.
Il CMT cosa fa? Condivide 2 core risparmiando il 20% di transistor con un -10% di potenza finale. +80% nel secondo TH equivale ad una perdita del 10% su 2 core (100 * 2 = 200), 10% = 180, a -10% rispetto a 2 core e -20% sul 2° TH.
L'SMT produce un +30% di potenza con un "costo" del 20% di transistor. E' sempre un +10%.
L'SMT è più parco del CMT se si considerano i transistor finali, ma è ovvio che a parità di IPC, il CMT non richiede investimenti sull'IPC.
Con IPC 100 alla fonte, con CMT ottieni 180, con SMT ottieni 130.
Nel momento in cui AMD realizza un core con più IPC, non sceglie l'SMT perchè il CMT è una ciofeca, lo sceglie, appunto, perchè con un IPC superiore in partenza, è più conveniente l'SMT al CMT.
Quindi BD/CMT era una soluzione a quei tempi, Zen/SMT è la soluzione odierna. BD/SMT non poteva MAI esistere allora, come oggi non potrebbe esistere ZEN/CMT, perchè richiederebbe più transistor rispetto all'SMT.
paolo.oliva2
21-12-2016, 13:58
stai facendo supposizioni basate su un'idea estremamente aleatoria.
Dell'esistenza del turbo a step di 25MHz, è ufficiale, ovviamente è aleatorio il funzionamento perchè si possono fare solamente supposizioni, ma aleatorio l'esistenza, quello no.
inotlre stai ancora considerando i transistor come fossero delle microscopiche resistenze cui applicare una tensione e far passare una corrente.:muro:
Avevo scritto che non ho competenze in merito... ma l'ho postato in termini di discussione/principio funzionamento.
Io preferisco almeno ipotizzare anche se non ho le basi, che avere le basi e parlare quando ci sono certezze per evitare brutte figure, anche perchè nel momento che si avrebbe la certezza, non sarebbe più una opinione ma una... spiegazione.
Dell'esistenza del turbo a step di 25MHz, è ufficiale, ovviamente è aleatorio il funzionamento perchè si possono fare solamente supposizioni, ma aleatorio l'esistenza, quello no.
inotlre stai ancora considerando i transistor come fossero delle microscopiche resistenze cui applicare una tensione e far passare una corrente.:muro:
Avevo scritto che non ho competenze in merito... ma l'ho postato in termini di discussione/principio funzionamento.
Io preferisco almeno ipotizzare anche se non ho le basi, che avere le basi e parlare quando ci sono certezze per evitare brutte figure, anche perchè nel momento che si avrebbe la certezza, non sarebbe più una opinione ma una... spiegazione.
paolo.oliva2
21-12-2016, 14:12
Ormai Paolo pur di difendere Bulldozer non sa più cosa inventarsi....
AMD stessa ha dichiarato che lo sviluppo di ZEN è iniziato nel 2012......una nuova architettura a pochi mesi dal rilascio di Bulldozer, richiamando in fretta e furia Jim Keller.......chissà come mai......:fiufiu:
Rileggiti il mio post dopo il tuo.
Io non devo difendere AMD, al limite difendo BD che è il procio che ho avuto, rileggiti pure tutti i TH riferiti a BD, perchè chi si è comprato BD, non ne ha parlato male e anche se lo ha cambiato per un Intel, non ne parla male neppure nei ricordi. Non mi sembra sia la stessa situazione in "casa" tua... :D
AMD stessa ha dichiarato che lo sviluppo di ZEN è iniziato nel 2012......una nuova architettura a pochi mesi dal rilascio di Bulldozer, richiamando in fretta e furia Jim Keller.......chissà come mai......:fiufiu:
Rileggiti il mio post dopo il tuo.
Io non devo difendere AMD, al limite difendo BD che è il procio che ho avuto, rileggiti pure tutti i TH riferiti a BD, perchè chi si è comprato BD, non ne ha parlato male e anche se lo ha cambiato per un Intel, non ne parla male neppure nei ricordi. Non mi sembra sia la stessa situazione in "casa" tua... :D
Wolfhang
21-12-2016, 14:25
Rileggiti il mio post dopo il tuo.
Io non devo difendere AMD, al limite difendo BD che è il procio che ho avuto, rileggiti pure tutti i TH riferiti a BD, perchè chi si è comprato BD, non ne ha parlato male e anche se lo ha cambiato per un Intel, non ne parla male neppure nei ricordi. Non mi sembra sia la stessa situazione in "casa" tua... :D
Non c'entra nulla con quello che tu hai affermato e cioè:
Era stato riportato nel TH che lo studio iniziale di Zen era dello stesso periodo di Buldozer.
"L'architettura Bulldozer è stata progettata completamente da zero, a differenza di quanto avvenuto con Barcelona e Shanghai che rappresentano evoluzioni dell'architettura K8.
L'annuncio fu dato prima ancora che il K10 fosse presentato ufficialmente"
IL virgolettato è tratto dalla prima pagina del TH aspettando Bulldozer, dimmi dove sarebbe stato riportato quello che tu affermi, oppure spiega come fai a fare certe affermazioni.
Io non devo difendere AMD, al limite difendo BD che è il procio che ho avuto, rileggiti pure tutti i TH riferiti a BD, perchè chi si è comprato BD, non ne ha parlato male e anche se lo ha cambiato per un Intel, non ne parla male neppure nei ricordi. Non mi sembra sia la stessa situazione in "casa" tua... :D
Non c'entra nulla con quello che tu hai affermato e cioè:
Era stato riportato nel TH che lo studio iniziale di Zen era dello stesso periodo di Buldozer.
"L'architettura Bulldozer è stata progettata completamente da zero, a differenza di quanto avvenuto con Barcelona e Shanghai che rappresentano evoluzioni dell'architettura K8.
L'annuncio fu dato prima ancora che il K10 fosse presentato ufficialmente"
IL virgolettato è tratto dalla prima pagina del TH aspettando Bulldozer, dimmi dove sarebbe stato riportato quello che tu affermi, oppure spiega come fai a fare certe affermazioni.
paolo.oliva2
21-12-2016, 14:46
Non c'entra nulla con quello che tu hai affermato e cioè:
"L'architettura Bulldozer è stata progettata completamente da zero, a differenza di quanto avvenuto con Barcelona e Shanghai che rappresentano evoluzioni dell'architettura K8.
L'annuncio fu dato prima ancora che il K10 fosse presentato ufficialmente"
IL virgolettato è tratto dalla prima pagina del TH aspettando Bulldozer, dimmi dove sarebbe stato riportato quello che tu affermi, oppure spiega come fai a fare certe affermazioni.
:confused:
Quello che hai postato è in contraddizione con quello che ho scritto?
Se poi vuoi metterla a bandiera, tipo AMD è corsa all'SMT di Intel, io non penso... visto che da quanto sembra in 2 anni AMD è riuscita a fare di più di quanto fatto dalla tua azienda in 15... magari l'allievo supera il maestro? :)
"L'architettura Bulldozer è stata progettata completamente da zero, a differenza di quanto avvenuto con Barcelona e Shanghai che rappresentano evoluzioni dell'architettura K8.
L'annuncio fu dato prima ancora che il K10 fosse presentato ufficialmente"
IL virgolettato è tratto dalla prima pagina del TH aspettando Bulldozer, dimmi dove sarebbe stato riportato quello che tu affermi, oppure spiega come fai a fare certe affermazioni.
:confused:
Quello che hai postato è in contraddizione con quello che ho scritto?
Se poi vuoi metterla a bandiera, tipo AMD è corsa all'SMT di Intel, io non penso... visto che da quanto sembra in 2 anni AMD è riuscita a fare di più di quanto fatto dalla tua azienda in 15... magari l'allievo supera il maestro? :)
Wolfhang
21-12-2016, 14:47
Rileggiti il mio post dopo il tuo.
Io non devo difendere AMD, al limite difendo BD che è il procio che ho avuto, rileggiti pure tutti i TH riferiti a BD, perchè chi si è comprato BD, non ne ha parlato male e anche se lo ha cambiato per un Intel, non ne parla male neppure nei ricordi. Non mi sembra sia la stessa situazione in "casa" tua... :D
Quindi per AMD non è importante che passino alla concorrenza, ma che ne parlino bene, scusa ma non lo sapevo, potevi anche dirlo prima eh!
Io non devo difendere AMD, al limite difendo BD che è il procio che ho avuto, rileggiti pure tutti i TH riferiti a BD, perchè chi si è comprato BD, non ne ha parlato male e anche se lo ha cambiato per un Intel, non ne parla male neppure nei ricordi. Non mi sembra sia la stessa situazione in "casa" tua... :D
Quindi per AMD non è importante che passino alla concorrenza, ma che ne parlino bene, scusa ma non lo sapevo, potevi anche dirlo prima eh!
Wolfhang
21-12-2016, 14:51
:confused:
Quello che hai postato è in contraddizione con quello che ho scritto?
Se poi vuoi metterla a bandiera, tipo AMD è corsa all'SMT di Intel, io non penso... visto che da quanto sembra in 2 anni AMD è riuscita a fare di più di quanto fatto dalla tua azienda in 15... magari l'allievo supera il maestro? :)
La mia azienda?
Per tua conoscenza ho comprato diverse azioni AMD.....guarda caso dopo l'annuncio di Zen!
Quello che hai postato è in contraddizione con quello che ho scritto?
Se poi vuoi metterla a bandiera, tipo AMD è corsa all'SMT di Intel, io non penso... visto che da quanto sembra in 2 anni AMD è riuscita a fare di più di quanto fatto dalla tua azienda in 15... magari l'allievo supera il maestro? :)
La mia azienda?
Per tua conoscenza ho comprato diverse azioni AMD.....guarda caso dopo l'annuncio di Zen!
Folgore 101
21-12-2016, 14:52
:confused:
Quello che hai postato è in contraddizione con quello che ho scritto?
Se poi vuoi metterla a bandiera, tipo AMD è corsa all'SMT di Intel, io non penso... visto che da quanto sembra in 2 anni AMD è riuscita a fare di più di quanto fatto dalla tua azienda in 15... magari l'allievo supera il maestro? :)
Dai paolo.oliva, per favore, cerca di evitare frasi che possono scatenare i soliti conflitti.
Quello che hai postato è in contraddizione con quello che ho scritto?
Se poi vuoi metterla a bandiera, tipo AMD è corsa all'SMT di Intel, io non penso... visto che da quanto sembra in 2 anni AMD è riuscita a fare di più di quanto fatto dalla tua azienda in 15... magari l'allievo supera il maestro? :)
Dai paolo.oliva, per favore, cerca di evitare frasi che possono scatenare i soliti conflitti.
Phopho
21-12-2016, 15:02
Ma è diventato Paolo VS tutti? :D
Paolo, tra tutte le cose che ho sentito l'unica della quale sono graniticamente sicuro che sia uscita dalla bocca di Lisa Su è che con Zen sono partiti da un foglio bianco facendo tesoro (ovviamente) degli errori e delle intuizioni corrette passate ma comunque partendo da zero.
Paolo, tra tutte le cose che ho sentito l'unica della quale sono graniticamente sicuro che sia uscita dalla bocca di Lisa Su è che con Zen sono partiti da un foglio bianco facendo tesoro (ovviamente) degli errori e delle intuizioni corrette passate ma comunque partendo da zero.
TheBestFix
21-12-2016, 15:14
si ma, ve lo chiedo per favore, BASTA, ormai e' dall'evento di presentazione di ryzen che leggo solo pagine e pagine di discussioni inutili e basate sul nulla con utenti che si attaccano a vicenda, e come detto da altri in precedenza la finiamo o no? Ci sono utenti (come me per esempio) che seguono il thread per capire se ci stanno novita' o interessati ad analisi puramente tecniche sui dati che gia' si sanno (come quelle fatte da BJT2 per esempio)....vi assicuro che e' diventato arduo trovarle in mezzo agli infiniti post sulle diatribe che troppo spesso finiscono in attacchi alla persona....e su dai....un tempo esistevano moderatori come il buon GIANNI, adesso che nessuno piu' interviene si finisce cosi'....
Pozhar
21-12-2016, 15:15
Ma infatti era questo il problema del TDP predittivo di AMD rapportato al consumo effettivo, perchè di fatto applichi il Vcore peggiore a tutti i proci, di conseguenza il TDP peggiore. Praticamente è come se 125W TDP di fatto rappresentino il caso peggiore di qualsiasi 8350 nella condizione peggiore.
Il discorso del Turbo in BD, è una sorta di cammuffamento, perchè se in base al carico dei core sono messi in idle, allora aumenta la frequenza e il Vcore applicato è come quello del Vcore def su tutti i core, cioè il Vcore più alto dell'intera produzione e bla bla bla.
Zen ha dei microstep di 25MHz. A parte quello che scrivono che con i paroloni sembra un qualche cosa di soprannaturale, un controllo così microscopico ha senso unicamente se rapportato ad una sensibilità di rilevamento altrettanto microscopica, e questo mi sembra palese che sia possibile unicamente se percepita in tempo reale e non predittivo.
Ma è anche perquesto che se il Vcore/frequenza interagiscono tra loro, il Vcore applicato all'origine assume un valore nullo perchè è lo stesso circuito che poi varierà la tensione.
Io non ho competenze a riguardo... voglio fantasticare e probabilmente scriverò un tot di cazzate. Se V = R*I, e I dovrebbe essere costante nei transistor, allora V cambierà in base a R, che dovrebbe essere il silicio più o meno "pulito" con una resistenza più o meno marcata. Se si mappasse sta R nel range di funzionamento, e probabilmente a core, magari nel ciclo di test e selezione procio, salvando i dati, si potrebbe avere il quadro preciso sia di potenzialità procio, che di funzionamento il più efficiente possibile.
In questo ambito, il modello TOP potrebbe si costare di più perchè top, ma giustificare quasi il raddoppio del prezzo (300$ --> 500$) semplicemente perchè la mappatura potrebbe avere range molto più esteso.
Ad esempio, un modello base al più potrebbe essere mappato fino ad una certa frequenza def tutti i core, poi proseguire solamente nei core "migliori" e fino ad una determinata frequenza. Nel modello TOP il range potrebbe essere anche più elevato, di qui un costo superiore e giustificando, in parte il prezzaggio (dei rumors) superiore.
Se poi fosse possibile variare Vcore/frequenza senza bisogno di una mappatura, cioè a caldo... bo' non ne ho idea.
Però, credo che sta menata dei Bios dentro il procio, sia in parte questo. Ricordo che nel bios delle AM3+ c'era una sorta di mappatura del procio... e AOD, il software di OC di AMD, riportava parti disattivate o attivate in base al bios della mobo. Questo lo dico per certo perchè ricordo che in alcune occasioni, con la stessa mobo/procio, la stessa versione di AOD contemplava parti prima disattivate dopo l'aggiornamento del bios. Quindi potrebbe essere stato interpretato come bios dentro il procio semplicemente la mappatura del procio sull'alimentazione... e se sta mappatura fosse bloccata ad una certa frequenza, di fatto il procio sarebbe come bloccato. Io sono dell'idea che AMD non può permettersi di bloccare Zen, per via degli i7 X4 K, ma potrebbe bloccare il funzionamento come X8 ad una certa frequenza e lasciarlo libero come X4. In fin dei conti in questo modo si avrebbe un X8 che potrebbe competere con gli i7 X4 perchè sbloccato fino a X4, prezzandolo poco, ma nel contempo non "disturbare" le vendite di X8 più costosi, ma appunto perchè X8 a frequenze più alte, andrebbero considerati vs i7 E.
https://i.makeagif.com/media/6-18-2015/Ighcn9.gif
Il discorso del Turbo in BD, è una sorta di cammuffamento, perchè se in base al carico dei core sono messi in idle, allora aumenta la frequenza e il Vcore applicato è come quello del Vcore def su tutti i core, cioè il Vcore più alto dell'intera produzione e bla bla bla.
Zen ha dei microstep di 25MHz. A parte quello che scrivono che con i paroloni sembra un qualche cosa di soprannaturale, un controllo così microscopico ha senso unicamente se rapportato ad una sensibilità di rilevamento altrettanto microscopica, e questo mi sembra palese che sia possibile unicamente se percepita in tempo reale e non predittivo.
Ma è anche perquesto che se il Vcore/frequenza interagiscono tra loro, il Vcore applicato all'origine assume un valore nullo perchè è lo stesso circuito che poi varierà la tensione.
Io non ho competenze a riguardo... voglio fantasticare e probabilmente scriverò un tot di cazzate. Se V = R*I, e I dovrebbe essere costante nei transistor, allora V cambierà in base a R, che dovrebbe essere il silicio più o meno "pulito" con una resistenza più o meno marcata. Se si mappasse sta R nel range di funzionamento, e probabilmente a core, magari nel ciclo di test e selezione procio, salvando i dati, si potrebbe avere il quadro preciso sia di potenzialità procio, che di funzionamento il più efficiente possibile.
In questo ambito, il modello TOP potrebbe si costare di più perchè top, ma giustificare quasi il raddoppio del prezzo (300$ --> 500$) semplicemente perchè la mappatura potrebbe avere range molto più esteso.
Ad esempio, un modello base al più potrebbe essere mappato fino ad una certa frequenza def tutti i core, poi proseguire solamente nei core "migliori" e fino ad una determinata frequenza. Nel modello TOP il range potrebbe essere anche più elevato, di qui un costo superiore e giustificando, in parte il prezzaggio (dei rumors) superiore.
Se poi fosse possibile variare Vcore/frequenza senza bisogno di una mappatura, cioè a caldo... bo' non ne ho idea.
Però, credo che sta menata dei Bios dentro il procio, sia in parte questo. Ricordo che nel bios delle AM3+ c'era una sorta di mappatura del procio... e AOD, il software di OC di AMD, riportava parti disattivate o attivate in base al bios della mobo. Questo lo dico per certo perchè ricordo che in alcune occasioni, con la stessa mobo/procio, la stessa versione di AOD contemplava parti prima disattivate dopo l'aggiornamento del bios. Quindi potrebbe essere stato interpretato come bios dentro il procio semplicemente la mappatura del procio sull'alimentazione... e se sta mappatura fosse bloccata ad una certa frequenza, di fatto il procio sarebbe come bloccato. Io sono dell'idea che AMD non può permettersi di bloccare Zen, per via degli i7 X4 K, ma potrebbe bloccare il funzionamento come X8 ad una certa frequenza e lasciarlo libero come X4. In fin dei conti in questo modo si avrebbe un X8 che potrebbe competere con gli i7 X4 perchè sbloccato fino a X4, prezzandolo poco, ma nel contempo non "disturbare" le vendite di X8 più costosi, ma appunto perchè X8 a frequenze più alte, andrebbero considerati vs i7 E.
https://i.makeagif.com/media/6-18-2015/Ighcn9.gif
affiu
21-12-2016, 15:33
....non ricordo di preciso ma lo sviluppo/concetto di BD è nato nel 2007, mi pare un annetto dopo l'acquisizione di Ati è la malsana idea "Fusion"...
Zen invece metà 2012, un annetto dopo l'esordio di Zambezi e la cancellazione dei 22nm SoI di GF...
Preparati che il tempo è quello e LUI sta per venire!....lasciamo perdere zen che sta per uscire e il target di potenza circa dove si andrà a posizionarsi, ma appenza uscirà APU-ZEN nel 2017 allora si vedrà di cosa sia fatto tale chip!
Poi dominio e 1 posto non basteranno e lo vedremo presto, e anche la signora BLU lo sa e si sta preparando e nulla può fare.
Poi certo ci sarà sempre chi crederà che nelle prossime console ci sarà APU-ZEN e 16k!...o no?o blu?:eek:
Zen invece metà 2012, un annetto dopo l'esordio di Zambezi e la cancellazione dei 22nm SoI di GF...
Preparati che il tempo è quello e LUI sta per venire!....lasciamo perdere zen che sta per uscire e il target di potenza circa dove si andrà a posizionarsi, ma appenza uscirà APU-ZEN nel 2017 allora si vedrà di cosa sia fatto tale chip!
Poi dominio e 1 posto non basteranno e lo vedremo presto, e anche la signora BLU lo sa e si sta preparando e nulla può fare.
Poi certo ci sarà sempre chi crederà che nelle prossime console ci sarà APU-ZEN e 16k!...o no?o blu?:eek:
paolo.oliva2
21-12-2016, 15:34
Quindi per AMD non è importante che passino alla concorrenza, ma che ne parlino bene, scusa ma non lo sapevo, potevi anche dirlo prima eh!
Mi sa che proprio non hai capito nulla, ti schiarisco le ide.
In primis io non sono AMD, quindi se il prodotto che vende AMD non soddisfa il 100% delle persone, questo è un problema AMD e non mio.
Io parlo di proci con architettura BD che ho avuto, i quali hanno soddisfatto me e chi li ha comprati in base a prezzo/prestazioni. Punto.
Chi voleva più potenza ed è passato ad Intel, qual'è il problema per me? Che Intel offra più potenza, lo sappiamo tutti, ma sappiamo anche che chiede un costo/prestazioni ben superiore e quindi anche le aspettative di chi acquista sono superiori.
-----
Se vuoi parlare di architettura, dimentichi tutto il contorno che è mancato a BD, e te lo dimostro senza mettere in causa Intel, altrimenti diventa un discorso di bandiera.
Mettiamo il confronto su BD CMT e Zen SMT.
Se Buldozer in veste XV fosse portato in toto sul 14nm, si avrebbe un XV X16, a parità di TDP rispetto a Zen e pure a frequenze superiori rispetto a quelle ottenute sul 28nm. Per facilità, lasciamo XV a 4GHz.
Come è stato postato più volte, a +40% di IPC, Zen pareggerebbe in ST con BD XV a 3,2GHz, e pareggerebbe in MT sui 3,9GHz, il tutto su un BD XV a 4GHz.
Guarda le performances di Zen a 3,4GHz, sarebbero di un buon 15% inferiori rispetto a quelle di XV X16 a 4GHz... Ti basta questo per farti capire che confrontare un 8350 ad un 6900K non è un confronto architetturale, in quanto lo si dovrebbe fare a parità di silicio?
Mi sa che proprio non hai capito nulla, ti schiarisco le ide.
In primis io non sono AMD, quindi se il prodotto che vende AMD non soddisfa il 100% delle persone, questo è un problema AMD e non mio.
Io parlo di proci con architettura BD che ho avuto, i quali hanno soddisfatto me e chi li ha comprati in base a prezzo/prestazioni. Punto.
Chi voleva più potenza ed è passato ad Intel, qual'è il problema per me? Che Intel offra più potenza, lo sappiamo tutti, ma sappiamo anche che chiede un costo/prestazioni ben superiore e quindi anche le aspettative di chi acquista sono superiori.
-----
Se vuoi parlare di architettura, dimentichi tutto il contorno che è mancato a BD, e te lo dimostro senza mettere in causa Intel, altrimenti diventa un discorso di bandiera.
Mettiamo il confronto su BD CMT e Zen SMT.
Se Buldozer in veste XV fosse portato in toto sul 14nm, si avrebbe un XV X16, a parità di TDP rispetto a Zen e pure a frequenze superiori rispetto a quelle ottenute sul 28nm. Per facilità, lasciamo XV a 4GHz.
Come è stato postato più volte, a +40% di IPC, Zen pareggerebbe in ST con BD XV a 3,2GHz, e pareggerebbe in MT sui 3,9GHz, il tutto su un BD XV a 4GHz.
Guarda le performances di Zen a 3,4GHz, sarebbero di un buon 15% inferiori rispetto a quelle di XV X16 a 4GHz... Ti basta questo per farti capire che confrontare un 8350 ad un 6900K non è un confronto architetturale, in quanto lo si dovrebbe fare a parità di silicio?
paolo.oliva2
21-12-2016, 15:35
Dai paolo.oliva, per favore, cerca di evitare frasi che possono scatenare i soliti conflitti.
Sono d'accordo con te, ma se io difendo BD, e mi mettono in causa che difendo AMD, chi inizia?
Edit
OMG
Ho riletto i post... mi sembrava...
Chiedo scusa a Wolfhang per la mia frase e grazie a Folgore 101 che mi ha ripreso.
Sono d'accordo con te, ma se io difendo BD, e mi mettono in causa che difendo AMD, chi inizia?
Edit
OMG
Ho riletto i post... mi sembrava...
Chiedo scusa a Wolfhang per la mia frase e grazie a Folgore 101 che mi ha ripreso.
paolo.oliva2
21-12-2016, 15:51
in realtà c'è anche un affermazione che parla del "prendere il meglio delle due architetture che avevano in casa" ovvero jaguar e vishera, insomma è tutto un insieme, le cose veramente diverse sono ad esempio il sistema di cache, il front-end e l'introduzione del SMT su tutto e non solo sulla fpu (cosa che aveva il CMT). Certo, si può dire che han potuto fare ciò che volevano :)
togliete l'internet a paolo oggi :D
non ricordo di preciso ma lo sviluppo/concetto di BD è nato nel 2007, mi pare un annetto dopo l'acquisizione di Ati è la malsana idea "Fusion"...
Zen invece metà 2012, un annetto dopo l'esordio di Zambezi e la cancellazione dei 22nm SoI di GF...
Quindi me lo sono sognato? Azzo... brutta cosa. :mc:
togliete l'internet a paolo oggi :D
non ricordo di preciso ma lo sviluppo/concetto di BD è nato nel 2007, mi pare un annetto dopo l'acquisizione di Ati è la malsana idea "Fusion"...
Zen invece metà 2012, un annetto dopo l'esordio di Zambezi e la cancellazione dei 22nm SoI di GF...
Quindi me lo sono sognato? Azzo... brutta cosa. :mc:
Roland74Fun
21-12-2016, 15:52
Sono d'accordo con te, ma se io difendo BD, e mi mettono in causa che difendo AMD, chi inizia?
[/B]
Difendo anche io il mio BD/PD.
Tante soddisfazzzzzioni... :D :D
Ovviamente con una mobo decente. ;)
[/B]
Difendo anche io il mio BD/PD.
Tante soddisfazzzzzioni... :D :D
Ovviamente con una mobo decente. ;)
george_p
21-12-2016, 15:55
Certo che intervenire qui diventa una scusa per attaccare a prescindere.
Comunque Paolo, Zen da ciò che si è sempre letto tra articoli di siti seri e interviste agli autori/ingegneri dell'architettura, prende il meglio di tutto quello che ha amd nei suoi cassetti.
Ovvio che prenda molte tecnologie che hanno inserito anche su XV come banco di prova e dal 2012, con l'arrivo di Keller AMD ha pure licenziato una ventina e più di nuovi brevetti, che da qualche parte in Zen doveva usare.
Comunque Paolo, Zen da ciò che si è sempre letto tra articoli di siti seri e interviste agli autori/ingegneri dell'architettura, prende il meglio di tutto quello che ha amd nei suoi cassetti.
Ovvio che prenda molte tecnologie che hanno inserito anche su XV come banco di prova e dal 2012, con l'arrivo di Keller AMD ha pure licenziato una ventina e più di nuovi brevetti, che da qualche parte in Zen doveva usare.
Piedone1113
21-12-2016, 16:05
Quindi me lo sono sognato? Azzo... brutta cosa. :mc:
Paolo vai tranquillo che AMD tutto quello che ha potuto usare di BD lo ha fatto, e ci puoi scommettere che lo si capirà meglio con ZEN+.
Se guardiamo la cpu in se gia il ccx si richiama a BD, di sicuro zen non è un'evoluzione di BD, ne tantomeno affonda le sue radici sulla struttura cmt, ma sicuramente quando esce una nuova fuoriserie anche se un nuovo modello inedito, qualcosa mutuato dalla vecchia produzione c'è sempre (e mica si reinventa la ruota ad ogni nuova uscita).
Paolo vai tranquillo che AMD tutto quello che ha potuto usare di BD lo ha fatto, e ci puoi scommettere che lo si capirà meglio con ZEN+.
Se guardiamo la cpu in se gia il ccx si richiama a BD, di sicuro zen non è un'evoluzione di BD, ne tantomeno affonda le sue radici sulla struttura cmt, ma sicuramente quando esce una nuova fuoriserie anche se un nuovo modello inedito, qualcosa mutuato dalla vecchia produzione c'è sempre (e mica si reinventa la ruota ad ogni nuova uscita).
TheBestFix
21-12-2016, 18:47
Ho capito, la spezzo io la monotonia del thread :
https://youtu.be/PgouHr2CrCI
https://youtu.be/PgouHr2CrCI
paolo.oliva2
21-12-2016, 19:06
Paolo vai tranquillo che AMD tutto quello che ha potuto usare di BD lo ha fatto, e ci puoi scommettere che lo si capirà meglio con ZEN+.
Se guardiamo la cpu in se gia il ccx si richiama a BD, di sicuro zen non è un'evoluzione di BD, ne tantomeno affonda le sue radici sulla struttura cmt, ma sicuramente quando esce una nuova fuoriserie anche se un nuovo modello inedito, qualcosa mutuato dalla vecchia produzione c'è sempre (e mica si reinventa la ruota ad ogni nuova uscita).
Si, però io avevo postato in contemporanea zen/BD perchè mi sembrava di averlo letto, e di per sè la scelta di CMT/SMT era comunque legata all'IPC... quindi avevo collegato le due cose. Sul mio ragionamento non è che cambi granchè, perchè fare un SMT con IPC di Phenom II, sarebbe come mettersi a 90°, quindi l'alternativa era o fare CMT o non fare nulla. Il Thuban mi sembra di aver letto (il mi sembra lo metto d'obbligo, ora) che non era compatibile architetturalmente con le AVX, quindi cambiare coveva cambiare... con BD hanno speso poco per aumentare l'IPC (che da quanto so aumentare l'IPC è quello che costa di più), hanno puntato tutto sull'FO4 e sul 32nm SOI, e sappiamo come è andata.
Che riciclino delle cose è normale... ma credo che anche sto giro il silicio, o meglio la mancanza di un PP decente silicio, farà la sua parte.
Però, non credo che tutto il mondo sia sfigato tranne Intel... mi sa che giudicare il PP non fortunato sia la scusa perfetta per non affermare che Intel lo ha fatto meglio, 32nm, 22nm, 14nm.
Se guardiamo la cpu in se gia il ccx si richiama a BD, di sicuro zen non è un'evoluzione di BD, ne tantomeno affonda le sue radici sulla struttura cmt, ma sicuramente quando esce una nuova fuoriserie anche se un nuovo modello inedito, qualcosa mutuato dalla vecchia produzione c'è sempre (e mica si reinventa la ruota ad ogni nuova uscita).
Si, però io avevo postato in contemporanea zen/BD perchè mi sembrava di averlo letto, e di per sè la scelta di CMT/SMT era comunque legata all'IPC... quindi avevo collegato le due cose. Sul mio ragionamento non è che cambi granchè, perchè fare un SMT con IPC di Phenom II, sarebbe come mettersi a 90°, quindi l'alternativa era o fare CMT o non fare nulla. Il Thuban mi sembra di aver letto (il mi sembra lo metto d'obbligo, ora) che non era compatibile architetturalmente con le AVX, quindi cambiare coveva cambiare... con BD hanno speso poco per aumentare l'IPC (che da quanto so aumentare l'IPC è quello che costa di più), hanno puntato tutto sull'FO4 e sul 32nm SOI, e sappiamo come è andata.
Che riciclino delle cose è normale... ma credo che anche sto giro il silicio, o meglio la mancanza di un PP decente silicio, farà la sua parte.
Però, non credo che tutto il mondo sia sfigato tranne Intel... mi sa che giudicare il PP non fortunato sia la scusa perfetta per non affermare che Intel lo ha fatto meglio, 32nm, 22nm, 14nm.
paolo.oliva2
21-12-2016, 19:10
...lo sai, io credo nella tua buona fede :flower: , e spero che non sei di nuovo in delirio da malaria :D
Appunto perchè non ho la malaria che mi preoccupo :)...
Buona fede sempre...
Appunto perchè non ho la malaria che mi preoccupo :)...
Buona fede sempre...
Gioz
21-12-2016, 20:09
Dell'esistenza del turbo a step di 25MHz, è ufficiale, ovviamente è aleatorio il funzionamento perchè si possono fare solamente supposizioni, ma aleatorio l'esistenza, quello no.
Avevo scritto che non ho competenze in merito... ma l'ho postato in termini di discussione/principio funzionamento.
Io preferisco almeno ipotizzare anche se non ho le basi, che avere le basi e parlare quando ci sono certezze per evitare brutte figure, anche perchè nel momento che si avrebbe la certezza, non sarebbe più una opinione ma una... spiegazione.
mi riferivo a tutto il discorso paolo, non intendevo dire che fosse casuale una specifica affermazione, ciò che dico è che hai mescolato concetti a caso.
quanto alla seconda parte...apprezzo il tuo impegno per analizzare cose così complesse, però se di base non si ha chiaro il funzionamento del componente elementare(e quindi suppongo anche dei vari blocchi logici) poi conseguono supposizioni che non hanno senso di esistere.
parleresti di progettare, che ne so, un motore a permanganato di potassio partendo dal presupposto che è un motore quindi basterà che girino delle cose? perché quel tuo discorso è quasi su questo livello.
Avevo scritto che non ho competenze in merito... ma l'ho postato in termini di discussione/principio funzionamento.
Io preferisco almeno ipotizzare anche se non ho le basi, che avere le basi e parlare quando ci sono certezze per evitare brutte figure, anche perchè nel momento che si avrebbe la certezza, non sarebbe più una opinione ma una... spiegazione.
mi riferivo a tutto il discorso paolo, non intendevo dire che fosse casuale una specifica affermazione, ciò che dico è che hai mescolato concetti a caso.
quanto alla seconda parte...apprezzo il tuo impegno per analizzare cose così complesse, però se di base non si ha chiaro il funzionamento del componente elementare(e quindi suppongo anche dei vari blocchi logici) poi conseguono supposizioni che non hanno senso di esistere.
parleresti di progettare, che ne so, un motore a permanganato di potassio partendo dal presupposto che è un motore quindi basterà che girino delle cose? perché quel tuo discorso è quasi su questo livello.
Piedone1113
21-12-2016, 22:41
Appunto perchè non ho la malaria che mi preoccupo :)...
Buona fede sempre...
Ps: ht Intel apporta un aumento del 5% dei transistor per singolo core a fronte di un aumento medio in mt del 18/22% delle prestazioni.
Tutto il resto è escluso.
L'uso dell'smt obbliga però ad avere core belli prestati.
Un core capace di rendere 100 su 4 software diversi porterà l'ht a rendere però in modo diverso.
Se il primo software sfrutta le caratteristiche del core al 50% delle proprie funzionalità ( magari perché usa solo 2 delle 4 alu) smt sulla stessa tipologia di software porterà un ipc del + 100% ( non vero per via delle risorse contese dai due th ed ipotizzando alu identiche e sufficiente spazio per i registri ed i puntatori).
Allo stesso modo un software che sfrutta già tutte le potenzialità del core lascerà zero risorse al secondo th ed invece che apportare vantaggio rallentano il primo th.
Un test su svariati software di diverso tempo fa portava un aumento del 2 th da un minimo del -2% (meno 2%) ad un massimo del +68%.
I software ed i core si sono evoluti e credo che si passi dal 18% di media ad un 22% ( smt a 2 vie intel).
Ma non dobbiamo credere che un +20 % di transistor portano ad un +30% di ipc, altrimenti sarebbe molto più conveniente l'approccio cmt di AMD che consente di avere core più piccoli ( stimato in circa l'85% di quello smt ) e porterebbe un aumento del +100% in mt ( considera che un core meno cicciottello avrà un ipc sul singolo th che va nel caso migliore uguale e nel caso peggiore a -20%)
Buona fede sempre...
Ps: ht Intel apporta un aumento del 5% dei transistor per singolo core a fronte di un aumento medio in mt del 18/22% delle prestazioni.
Tutto il resto è escluso.
L'uso dell'smt obbliga però ad avere core belli prestati.
Un core capace di rendere 100 su 4 software diversi porterà l'ht a rendere però in modo diverso.
Se il primo software sfrutta le caratteristiche del core al 50% delle proprie funzionalità ( magari perché usa solo 2 delle 4 alu) smt sulla stessa tipologia di software porterà un ipc del + 100% ( non vero per via delle risorse contese dai due th ed ipotizzando alu identiche e sufficiente spazio per i registri ed i puntatori).
Allo stesso modo un software che sfrutta già tutte le potenzialità del core lascerà zero risorse al secondo th ed invece che apportare vantaggio rallentano il primo th.
Un test su svariati software di diverso tempo fa portava un aumento del 2 th da un minimo del -2% (meno 2%) ad un massimo del +68%.
I software ed i core si sono evoluti e credo che si passi dal 18% di media ad un 22% ( smt a 2 vie intel).
Ma non dobbiamo credere che un +20 % di transistor portano ad un +30% di ipc, altrimenti sarebbe molto più conveniente l'approccio cmt di AMD che consente di avere core più piccoli ( stimato in circa l'85% di quello smt ) e porterebbe un aumento del +100% in mt ( considera che un core meno cicciottello avrà un ipc sul singolo th che va nel caso migliore uguale e nel caso peggiore a -20%)
cdimauro
21-12-2016, 22:43
eh se zen su 4 core raggiungesse le frequenze del 7700k e simili prestazioni e con 8 core invece le prestazione di 6900k, tutto prezzato a 300$ , secondo voi quanto ci perderebbe intel in faccia?
Assai.
E non ditemi che amd non è una onlus e non lo possa fare , visto che ipotezzando i costi della produzione è fattibile , tanto il mercato ormai è stagnato , togliendo i professionisti del rendering , a cui la potenza non basta mai per accorciare i tempi,per gli altri , la potenza per i prossimi 5/6 anni l'abbiamo. Invece se i prezzi e le prestazioni di zen saranno quelli ipotetizzati nella miglior visione , un upgrade ci starebbe visto il guadagno e il prezzo ;)
Invece te lo dico: AMD non è una ONLUS. Lo sa anche lei che una guerra sui prezzi non potrebbe sostenerla, visto che ha bisogno di incassare, e con margini ridotti incasserebbe poco. Per questo penso che proporrà sicuramente prezzi ridotti, ma non fuori mercato, in modo da guadagnare un po' di mercato e, dunque, incassare.
cesare
ignorando la parte (ora non ricordo se sottointesa) "è come se io dicessi" , ma se ne avresti tenuto conto , non lo avresti attaccato (gratuitamente?) perchè era un "esempio!"
Possiamo dire che ha sbagliato completamente esempi?
riguardo la nomenclatura degli i7 non capisci il discorso di paolo , e parti in battaglia a spada tratta :D :D
Il discorso di Paolo è semplice: per lui i7 = 4 core / 8 thread. E s'è sentito fregato quando ha preso un portatile i7, e ha visto (POI! che era con la metà di core/thread. Solo che, per l'appunto, i7 è e rimane un'etichetta per identificare una categoria di prodotto, visto che il 6900K è anch'esso un i7, ma con 8 core / 16 thread.
le tue risposte tecniche son un piacere leggerle , anzi i vostri discorsi tecnici , ma il modo di rispondere a mò di moccioso viziato , a volte me li fan saltare di pari passo , poi li rileggo nei vari quote delle risposte tecniche e leggo le cose interessanti ma già scremate dai i modi spigolosi
Buona giornata
I modi sono spigolosi solo con certi personaggi. Personalmente preferirei, e GRADIREI AMPIAMENTE, continuare a intavolare esclusivamente discussioni tecniche, ma non posso certo passare sopra offese gratuite, come essere definito idiota (da uno che, peraltro, ha mostrato un grande acume) da uno che s'inventa di sana pianta delle cose che pretende di spacciare per vere, incluso infilarmi in bocca cose che non mi sono mai sognato di scrivere (e che sistematicamente sparisce, quando gli chiedo conto e ragione. Ovviamente).
Ma la cosa più fastidiosa è vedere il comportamento (incoerente, tra l'altro) di quelli che si sono sollevati in protesta soltanto DOPO che ho risposto, mentre di fronte alle cose di cui sopra sono rimasti bellamente in silenzio, perché evidentemente a questi diversamente onesti sta benissimo così.
Se ci fosse una moderazione funzionante non avrei alcun problema a rimanere in riga: mi limiterei ai meri contenuti tecnici, e a usare il testo Segnala, attendendo l'intervento del moderatore.
Quando si rifarà vivo e metterà uno stop agli OT et similia, non avrò nessunissimo problema a ritornare nei miei ranghi.
E adesso spero che si possa continuare tranquillamente senza finire come l'altro ieri.
Secondo me il secondo spoiler ha sbagliato ad etichettarlo ed è la versione "ufficiale".
No, gli spoiler sono corretti: AVX-2 e AVX. Niente SSE.
Te ne accorgi per le istruzioni che hanno V come prefisso. Mentre le equivalenti SSE non hanno questo prefisso.
Ma potrebbe darsi che la 2.78A abbia comunque delle AVX. Bisogna vedere se ci sono istruzioni AVX dentro.
No, ha solo le SSE: basti vedere le differenze prestazionali del codice compilato per AVX. Se usi le AVX, non usi le SSE; e viceversa. Da cui le relative differenze prestazionali.
Inoltre INTEL ha le FMA3 al massimo.
Sì, e infatti ci sono solo quelle. :D
Le FMA4 le aveva AMD.
Aveva, appunto: Zen non le ha, e implementa le FMA3. Quindi è una micro-architettura (& ISA) molto simile a quella Intel.
Non sono molto aggiornato su questo, ma quindi le FMA3 sono distruttive solo sulle FMAC, che hanno 3 parametri di input e quindi non distruttive sulle operazioni "Normali"?
Per fare chiarezza, le FMAC sono state introdotte soltanto con FMA3/4, e usano 3 o 4 operandi in totale, a seconda quale delle due versioni.
Ovviamente le FMA4 sono più flessibili perché consentono di specificare 3 sorgenti diverse per i dati da usare per le (due) operazioni concatenate. Ma è una flessibilità relativa, perché comporta una complicazione a livello di implementazione della microarchitettura, visto che in genere prevede un massimo di 2 sorgenti e una destinazione. Inoltre l'FMAC è, per definizione, un'operazione di accumulazione, per cui è ovvio nonché sensato che lo stesso registro sia usato come una delle sorgenti e infine come destinazione; cioé esattamente come funzionano le FMA3.
Questo per le FMA, che sono operazioni un po' particolari, ma devo dire che ce ne sono anche altre operazioni ternarie (con 4 operandi), sebbene siano una sparuta minoranza.
Tutte le altre sono operazioni binarie (e non distruttive: hanno 3 operandi), o unarie (e non distruttive: 2 operandi).
Ovviamente le SSE non possono godere di questi vantaggi, visto che sono quasi sempre con un operando in meno, e dunque spesso distruttive. Il che obbliga in diversi casi a far uso di operazioni extra di "move" (vettoriali), con aumento della densità del codice nonché decadimento prestazionale (mitigato dalla move elimination, per chi la implementa).
Non ho capito... :stordita: Load-store forwarding?
Sì, esatto.
Vedi... da 7 anni a sta parte le solite frasi che sento sono: "AMD si, può recuperare, ma però non deve vedersela con l'architettura X, ma quando uscirà ci sarà l'architettura Y che avra +15% di IPC e bla bla bla". Non sono sempre illazioni? Che cambia? Si sparano cose sul nulla assoluto. Ti Ricordi o no quando si diceva che Zen non avrà a che fare con Broadwell ma ci sarà Skylake che avrà 10-15% di IPC in più? Siamo nell'era SkyLake... dov'è tutta sta gran potenza in più?
Qualcuno ha postato un link in cui si valutano Broadwell, Broadwell-E, e Skylake in ambito gaming (http://techbuyersguru.com/intels-core-i5-6600k-vs-i7-6700k-vs-i7-6900k-games): è lì che si vede la potenza in più di cui sopra. Ed è soltanto un esempio.
Non erano allora sempre illazioni? Che cambia se io dico se Zen avrà 4GHz di frequenza?
Siete nella stessa barca, infatti.
Lo so che le frequenze pubblicate sono quelle a default, ma è più corretto specificare nella tabella/grafico quale effettiva frequenza di funzionamento è utilizzata nel benchmark.
Perché di test realizzato in un modo si parla e così è giusto venga riportato nei grafici che sono sempre quelli di maggiore attenzione da parte di chi legge.
Concordo. D'altra parte quel sito funge più che altro da click-baiting, per cui si vede che avevano fretta di sparare la notizia... oops. fake. :stordita:
Per i Vcore esagerati, un conto credo che sia fino a ieri con TDP predittivo,
Dove l'hai letto questo "TDP predittivo"?
Il + ha lo stesso significato del tuo e del mio "almeno". Vuol dire almeno 3.4. Forse di più, forse no. Quindi la certezza è a 3.4.
*
https://www.reddit.com/r/Amd/comments/5jcj6c/amd_ryzen_cinebench_r15_against_core_i77700k_and/
Confermato che era un fake (dal moderatore di Baidu).
E' un E5 2660 (Xeon?).
Il tizio è un rivenditore e non può avere Ryzen.
Il post è stato cancellato.
edit:
http://www.overclock.net/t/1617227/amd-new-horizon-zen-preview-on-12-13-at-3-pm-cst/1580#post_25723175
Qui il post di un tizio che spiega chi è il postatore di fake...
Ottimo: così si evita di sprecare tempo per della spazzatura.
Ho trovato un'altra presentazione di Zen, penso che il tizio sia diverso, del primo settembre... Occhio che non ci sono i sottotitoli ed ovviamente è in inglese... Tra l'altro non so come abbia avuto questo link. Sotto youtube mi dice che "Il video non è in elenco. Fai attenzione e rifletti bene prima di condividere." :asd:
https://www.youtube.com/watch?v=Ln9WKPEHm4w#t=01h01m45s
A volte quando rivedi le cose capisci meglio... O forse sarà quello che ha detto questo tizio...
Le slide si capiscono meglio con questa spiegazione.
In questo punto https://youtu.be/Ln9WKPEHm4w?t=1h16m29s inizia la slide sulla unità di decoding...
Notato niente? Beh all'inizio nemmeno io...
Tra la microop queue e il dispatch si frappongono lo stack memfile e la microcode rom. Questo che vuol dire?
Partiamo dallo stack memfile. Qui nessuna sorpresa. Questa unità filtra e traduce le microop, cancellando quelle che non servono, perchè gestite all'interno e modificando quelle che dipendono dallo stack. Inoltre fa anche lo store to load forwarding, tracciando gli store e poi non spiega bene, ma comunque è chiaro che è fatto a livello di dispatch...
Le istruzioni cancellate sono quelle di "move".
Passiamo alla microcode rom. Che diavolo ci fa qui? Se vediamo nella slide del decoding, dice che può decodificare 4 istruzioni, senza mai specificare se semplici, doppie ecc... Visto dove è messa la unità microcodice, io suppongo che i decoder, per le istruzioni microcodificate, forniscano semplicemente un entry point nella microcode rom, con annessi registri e immediati decodificati e poi a questo stadio le microop vengano effettivamente sparate... Anche nella uop cache c'è una sola uop che contiene solo il puntatore nella microcode rom!
Così si occupa pochissimo spazio nella uop cache e nella microop queue e i decoder non sono bloccati dalle istruzioni microcodificate, ma magari tradotte in un solo ciclo e magari fino 4 per ciclo anzichè una!
L'uovo di colombo!
Peccato che funzioni esclusivamente con istruzioni microcodificate. :D
Nel caso di AMD, finora (non sappiamo se Zen cambierà, ma non credo, visto che è un progetto consolidato) si tratta di istruzioni che richiedono più di 2 MOP, che non sono comuni, e anzi a livello di esecuzione sono abbastanza rare.
Se ricordi, tuttodigitale aveva postato una bella immagine di Intel con delle statistiche sulla tipologia di istruzioni eseguite, e il 99% (se non ricordo male) non erano microcodificate.
Dunque il risparmio con questo nuovo meccanismo c'è sicuramente, ma nel mondo reale non incide, visto che è per lo più per roba legacy (e pochissimo utilizzata).
https://youtu.be/Ln9WKPEHm4w?t=1h20m04s
Qui se ho capito bene dice che la coda di ritiro FP è indipendente e separata da quella INT... :mbe: Questo vuol dire che può ritirare 8+8=16 istruzioni per ciclo, contro le 8 di skylake... :eek:
Qualcuno che capisce bene l'inglese può dare un ascolto od ho le travvegole?
All'inizio, quando c'era l'overview generale, ha detto che poteva ritirare 8 uop (non istruzioni). E questo era il totale (come da slide, peraltro).
Successivamente ha detto che lo potevano fare indipendentemente i due blocchi intero e FPU. Quindi parrebbe un 8+8.
Solo che mi pare un po' esagerato, visto che non sono certo scenari comuni quelli in cui si possano superare gli 8 retire.
EDIT: poi ho capito perchè dicono 20MB di cache. La cache L3 ha i tag anche di tutti i dati nelle altre cache L2. Se un core richiede un dato che non è nella L3 ma in una L2 di un altro core, questo viene spedito core to core... Quindi è come fossero 16+4MB di cache con 4 MB più veloci e 16 più lenti...
Com'è ovvio che sia. :p
Assai.
E non ditemi che amd non è una onlus e non lo possa fare , visto che ipotezzando i costi della produzione è fattibile , tanto il mercato ormai è stagnato , togliendo i professionisti del rendering , a cui la potenza non basta mai per accorciare i tempi,per gli altri , la potenza per i prossimi 5/6 anni l'abbiamo. Invece se i prezzi e le prestazioni di zen saranno quelli ipotetizzati nella miglior visione , un upgrade ci starebbe visto il guadagno e il prezzo ;)
Invece te lo dico: AMD non è una ONLUS. Lo sa anche lei che una guerra sui prezzi non potrebbe sostenerla, visto che ha bisogno di incassare, e con margini ridotti incasserebbe poco. Per questo penso che proporrà sicuramente prezzi ridotti, ma non fuori mercato, in modo da guadagnare un po' di mercato e, dunque, incassare.
cesare
ignorando la parte (ora non ricordo se sottointesa) "è come se io dicessi" , ma se ne avresti tenuto conto , non lo avresti attaccato (gratuitamente?) perchè era un "esempio!"
Possiamo dire che ha sbagliato completamente esempi?
riguardo la nomenclatura degli i7 non capisci il discorso di paolo , e parti in battaglia a spada tratta :D :D
Il discorso di Paolo è semplice: per lui i7 = 4 core / 8 thread. E s'è sentito fregato quando ha preso un portatile i7, e ha visto (POI! che era con la metà di core/thread. Solo che, per l'appunto, i7 è e rimane un'etichetta per identificare una categoria di prodotto, visto che il 6900K è anch'esso un i7, ma con 8 core / 16 thread.
le tue risposte tecniche son un piacere leggerle , anzi i vostri discorsi tecnici , ma il modo di rispondere a mò di moccioso viziato , a volte me li fan saltare di pari passo , poi li rileggo nei vari quote delle risposte tecniche e leggo le cose interessanti ma già scremate dai i modi spigolosi
Buona giornata
I modi sono spigolosi solo con certi personaggi. Personalmente preferirei, e GRADIREI AMPIAMENTE, continuare a intavolare esclusivamente discussioni tecniche, ma non posso certo passare sopra offese gratuite, come essere definito idiota (da uno che, peraltro, ha mostrato un grande acume) da uno che s'inventa di sana pianta delle cose che pretende di spacciare per vere, incluso infilarmi in bocca cose che non mi sono mai sognato di scrivere (e che sistematicamente sparisce, quando gli chiedo conto e ragione. Ovviamente).
Ma la cosa più fastidiosa è vedere il comportamento (incoerente, tra l'altro) di quelli che si sono sollevati in protesta soltanto DOPO che ho risposto, mentre di fronte alle cose di cui sopra sono rimasti bellamente in silenzio, perché evidentemente a questi diversamente onesti sta benissimo così.
Se ci fosse una moderazione funzionante non avrei alcun problema a rimanere in riga: mi limiterei ai meri contenuti tecnici, e a usare il testo Segnala, attendendo l'intervento del moderatore.
Quando si rifarà vivo e metterà uno stop agli OT et similia, non avrò nessunissimo problema a ritornare nei miei ranghi.
E adesso spero che si possa continuare tranquillamente senza finire come l'altro ieri.
Secondo me il secondo spoiler ha sbagliato ad etichettarlo ed è la versione "ufficiale".
No, gli spoiler sono corretti: AVX-2 e AVX. Niente SSE.
Te ne accorgi per le istruzioni che hanno V come prefisso. Mentre le equivalenti SSE non hanno questo prefisso.
Ma potrebbe darsi che la 2.78A abbia comunque delle AVX. Bisogna vedere se ci sono istruzioni AVX dentro.
No, ha solo le SSE: basti vedere le differenze prestazionali del codice compilato per AVX. Se usi le AVX, non usi le SSE; e viceversa. Da cui le relative differenze prestazionali.
Inoltre INTEL ha le FMA3 al massimo.
Sì, e infatti ci sono solo quelle. :D
Le FMA4 le aveva AMD.
Aveva, appunto: Zen non le ha, e implementa le FMA3. Quindi è una micro-architettura (& ISA) molto simile a quella Intel.
Non sono molto aggiornato su questo, ma quindi le FMA3 sono distruttive solo sulle FMAC, che hanno 3 parametri di input e quindi non distruttive sulle operazioni "Normali"?
Per fare chiarezza, le FMAC sono state introdotte soltanto con FMA3/4, e usano 3 o 4 operandi in totale, a seconda quale delle due versioni.
Ovviamente le FMA4 sono più flessibili perché consentono di specificare 3 sorgenti diverse per i dati da usare per le (due) operazioni concatenate. Ma è una flessibilità relativa, perché comporta una complicazione a livello di implementazione della microarchitettura, visto che in genere prevede un massimo di 2 sorgenti e una destinazione. Inoltre l'FMAC è, per definizione, un'operazione di accumulazione, per cui è ovvio nonché sensato che lo stesso registro sia usato come una delle sorgenti e infine come destinazione; cioé esattamente come funzionano le FMA3.
Questo per le FMA, che sono operazioni un po' particolari, ma devo dire che ce ne sono anche altre operazioni ternarie (con 4 operandi), sebbene siano una sparuta minoranza.
Tutte le altre sono operazioni binarie (e non distruttive: hanno 3 operandi), o unarie (e non distruttive: 2 operandi).
Ovviamente le SSE non possono godere di questi vantaggi, visto che sono quasi sempre con un operando in meno, e dunque spesso distruttive. Il che obbliga in diversi casi a far uso di operazioni extra di "move" (vettoriali), con aumento della densità del codice nonché decadimento prestazionale (mitigato dalla move elimination, per chi la implementa).
Non ho capito... :stordita: Load-store forwarding?
Sì, esatto.
Vedi... da 7 anni a sta parte le solite frasi che sento sono: "AMD si, può recuperare, ma però non deve vedersela con l'architettura X, ma quando uscirà ci sarà l'architettura Y che avra +15% di IPC e bla bla bla". Non sono sempre illazioni? Che cambia? Si sparano cose sul nulla assoluto. Ti Ricordi o no quando si diceva che Zen non avrà a che fare con Broadwell ma ci sarà Skylake che avrà 10-15% di IPC in più? Siamo nell'era SkyLake... dov'è tutta sta gran potenza in più?
Qualcuno ha postato un link in cui si valutano Broadwell, Broadwell-E, e Skylake in ambito gaming (http://techbuyersguru.com/intels-core-i5-6600k-vs-i7-6700k-vs-i7-6900k-games): è lì che si vede la potenza in più di cui sopra. Ed è soltanto un esempio.
Non erano allora sempre illazioni? Che cambia se io dico se Zen avrà 4GHz di frequenza?
Siete nella stessa barca, infatti.
Lo so che le frequenze pubblicate sono quelle a default, ma è più corretto specificare nella tabella/grafico quale effettiva frequenza di funzionamento è utilizzata nel benchmark.
Perché di test realizzato in un modo si parla e così è giusto venga riportato nei grafici che sono sempre quelli di maggiore attenzione da parte di chi legge.
Concordo. D'altra parte quel sito funge più che altro da click-baiting, per cui si vede che avevano fretta di sparare la notizia... oops. fake. :stordita:
Per i Vcore esagerati, un conto credo che sia fino a ieri con TDP predittivo,
Dove l'hai letto questo "TDP predittivo"?
Il + ha lo stesso significato del tuo e del mio "almeno". Vuol dire almeno 3.4. Forse di più, forse no. Quindi la certezza è a 3.4.
*
https://www.reddit.com/r/Amd/comments/5jcj6c/amd_ryzen_cinebench_r15_against_core_i77700k_and/
Confermato che era un fake (dal moderatore di Baidu).
E' un E5 2660 (Xeon?).
Il tizio è un rivenditore e non può avere Ryzen.
Il post è stato cancellato.
edit:
http://www.overclock.net/t/1617227/amd-new-horizon-zen-preview-on-12-13-at-3-pm-cst/1580#post_25723175
Qui il post di un tizio che spiega chi è il postatore di fake...
Ottimo: così si evita di sprecare tempo per della spazzatura.
Ho trovato un'altra presentazione di Zen, penso che il tizio sia diverso, del primo settembre... Occhio che non ci sono i sottotitoli ed ovviamente è in inglese... Tra l'altro non so come abbia avuto questo link. Sotto youtube mi dice che "Il video non è in elenco. Fai attenzione e rifletti bene prima di condividere." :asd:
https://www.youtube.com/watch?v=Ln9WKPEHm4w#t=01h01m45s
A volte quando rivedi le cose capisci meglio... O forse sarà quello che ha detto questo tizio...
Le slide si capiscono meglio con questa spiegazione.
In questo punto https://youtu.be/Ln9WKPEHm4w?t=1h16m29s inizia la slide sulla unità di decoding...
Notato niente? Beh all'inizio nemmeno io...
Tra la microop queue e il dispatch si frappongono lo stack memfile e la microcode rom. Questo che vuol dire?
Partiamo dallo stack memfile. Qui nessuna sorpresa. Questa unità filtra e traduce le microop, cancellando quelle che non servono, perchè gestite all'interno e modificando quelle che dipendono dallo stack. Inoltre fa anche lo store to load forwarding, tracciando gli store e poi non spiega bene, ma comunque è chiaro che è fatto a livello di dispatch...
Le istruzioni cancellate sono quelle di "move".
Passiamo alla microcode rom. Che diavolo ci fa qui? Se vediamo nella slide del decoding, dice che può decodificare 4 istruzioni, senza mai specificare se semplici, doppie ecc... Visto dove è messa la unità microcodice, io suppongo che i decoder, per le istruzioni microcodificate, forniscano semplicemente un entry point nella microcode rom, con annessi registri e immediati decodificati e poi a questo stadio le microop vengano effettivamente sparate... Anche nella uop cache c'è una sola uop che contiene solo il puntatore nella microcode rom!
Così si occupa pochissimo spazio nella uop cache e nella microop queue e i decoder non sono bloccati dalle istruzioni microcodificate, ma magari tradotte in un solo ciclo e magari fino 4 per ciclo anzichè una!
L'uovo di colombo!
Peccato che funzioni esclusivamente con istruzioni microcodificate. :D
Nel caso di AMD, finora (non sappiamo se Zen cambierà, ma non credo, visto che è un progetto consolidato) si tratta di istruzioni che richiedono più di 2 MOP, che non sono comuni, e anzi a livello di esecuzione sono abbastanza rare.
Se ricordi, tuttodigitale aveva postato una bella immagine di Intel con delle statistiche sulla tipologia di istruzioni eseguite, e il 99% (se non ricordo male) non erano microcodificate.
Dunque il risparmio con questo nuovo meccanismo c'è sicuramente, ma nel mondo reale non incide, visto che è per lo più per roba legacy (e pochissimo utilizzata).
https://youtu.be/Ln9WKPEHm4w?t=1h20m04s
Qui se ho capito bene dice che la coda di ritiro FP è indipendente e separata da quella INT... :mbe: Questo vuol dire che può ritirare 8+8=16 istruzioni per ciclo, contro le 8 di skylake... :eek:
Qualcuno che capisce bene l'inglese può dare un ascolto od ho le travvegole?
All'inizio, quando c'era l'overview generale, ha detto che poteva ritirare 8 uop (non istruzioni). E questo era il totale (come da slide, peraltro).
Successivamente ha detto che lo potevano fare indipendentemente i due blocchi intero e FPU. Quindi parrebbe un 8+8.
Solo che mi pare un po' esagerato, visto che non sono certo scenari comuni quelli in cui si possano superare gli 8 retire.
EDIT: poi ho capito perchè dicono 20MB di cache. La cache L3 ha i tag anche di tutti i dati nelle altre cache L2. Se un core richiede un dato che non è nella L3 ma in una L2 di un altro core, questo viene spedito core to core... Quindi è come fossero 16+4MB di cache con 4 MB più veloci e 16 più lenti...
Com'è ovvio che sia. :p
cdimauro
21-12-2016, 22:47
Quindi... a parte che che ci avevi beccato in dei punti... praticamente Keller... quanto ha stravolto, cosa ha stravolto e eventualmente quale potrebbe essere il range di guadagno. E' possibile che qualche cosa di tutta sta roba ancora non sia implementata e magari ci sia qualche worck-around?
La roba non implementata (per questioni di tempo e/o transistor budget) finirà in Zen+.
I work-around si usano per i bug.
BD e Zen si dice che avevano lo stesso sviluppo iniziale,
Non l'ha detto mai nessuno, e il loro sviluppo è temporalmente ben diverso.
Dice "the 8-wide retire is independent of integer and floating point".
Detta così sembra che la coda di ritiro 8-wide è indipendente da quella int e fp, ma non so se ha senso :mbe:
Probabilmente ha più senso come hai detto tu, però diciamo che non si è espresso bene nemmeno lui, se è quello che voleva dire :D
Già. IMO si potrebbe interpretare che la coda di ritiro pesca indipendentemente da tutte e due. Cosa che, tra l'altro, si sposerebbe perfettamente con la slide (come si può vedere, attinge senza costrizioni da ambo i macro-blocchi) e con quello che lui aveva detto all'inizio.
Comunque ha senso, perchè in SMT è partizionata. 4 per thread mi sembrano poche...
Hai detto anche tu che le MOP di AMD sono molto dense, e che spesso si mappano 1:1 con le istruzioni di provenienza.
Ricorda pure che il limite del decoder di Zen è di 4 istruzioni per ciclo di clock, ma per un solo thread alla volta.
E che la micro-op queue invia al massimo 6 uop per ciclo di clock ai due dispatcher.
Per cui una retire 8-wide mi sembra ben dimensionata alla scopo. Mentre il doppio è sicuramente molto esagerata.
Su anand comunque hanno fatto notare che il tizio intel alla fine, a parte che non ha manco ringraziato, ma era un po' nervoso e "tossiva" per schiarirsi la voce spesso... :D
Nervoso non mi è parso proprio. Un colpetto di tosse ci può anche stare.
Poi la domanda l'ha fatta (reiterata) sulla cache L3, che non mi pare offra prestazioni migliori di quella Intel. Dunque non aveva motivo d'esser nervoso. :cool:
Sarà che lavora proprio in quell'ambito, e voleva chiarire quel dettaglio.
Boh... oggi ho qualche neurone che mi lavora in più (o in meno)... mi sono venuti dei dubbi.
Cioè... l'FO4 può ottimizzare il consumo tra il gioco IPC * Frequenza nel risultato della medesima potenza.
fin qui ho capito... ma nel risultato comunque le unità logiche arrivano comunque a consumare, nel senso che nella stessa unità di tempo o in un modo o nell'altro risolvono le stesse operazioni.
Ora... evitiamo commenti perchè faccio un esempio, Zen potrebbe arrivare allo stesso valore di istruzioni elaborate con una frequenza maggiore ma con un IPC minore rispetto al 6900K, e magari consumando un po' meno per via che l'FO4 ottimizzerebbe il cosumo.
Però le unità logiche comunque elaborano gli stessi dati, quindi comunque il consumo non può essere molto diverso... e se il silicio 14nm Intel è migliore del 15% di quello GF, come cacchio fa Zen ad ottenere potenze simili ma addirittura consumare meno?
Possono tutti sti canali avanti e indietro e parallelli in qualche modo ridurre i transistor necessari? In fin dei conti le info di Zen lo danno 170/180mmq vs un 6900K che è circa 200mmq...
Si tratta di microarchitetture diverse: ci saranno scenari in cui va meglio l'una, e viceversa.
E finché non avremo altri, tanti, test diversi, non sapremo come si comporterà Zen e quale sarà di conseguenza la sua efficienza.
Considera che la tecnologia Core è nata sul 45nm, ed ormai è vecchia ed ha bisogno di una profonda revisione su questi pp ( anche se Cesare non è d'accordo) mentre Zen è nata per il 20nm, cucita su misura, teoricamente più efficiente.
Non sono d'accordo perché ciò che conta è il funzionamento della micro-architettura. E qui non c'entra la nanometria, se non per i risvolti di cui, in ogni caso, una micro-architettura trae automaticamente vantaggio (SE c'è vantaggio).
Detto in altri termini, su un processo produttivo nuovo la stessa micro-architettura consente di raggiungere prestazioni migliori, senza essere stata pensata appositamente per quel nuovo processo.
Capito a grandi linee. In teoria il nuovo salto di Zen che sarebbe sul 7nm ma mi sembra 14 sarebbe ancora "compatibile".
Quindi KabyLake dovrebbe essere ancora sulla vecchia ottimizzazione, ma sarebbe probabile che con il salto al 10nm Intel cambi qualche cosa?
Coi 10nm Intel proporrà anche una micro-architettura un po' diversa da Kaby Lake.
Scusa, ma ogni tanto ne leggo una nuova davvero.
Dove e chi dice che BD e Zen avevano lo stesso sviluppo iniziale?
Ho sempre letto che BD ha avuto uno sviluppo lento, ma leeento, così lento che il caro Meyer ci ha messo anni per farlo uscire e il risultato è stato a dir poco penoso.
Zen nasce per far retromarcia da un prodotto che per amd si è rivelato ancora più fallimentare di una architettura, quella phenom derivante dall'athlon, che a parte il silicio 45 non ha mai potuto competere con la concorrenza per il solo motivo di testardaggine dei dirigenti a non voler implementare il proprio SMT, tecnologia che era già allo studio dall'epoca degli athlon.
Che Zen prenda tutto quello che di buono ha realizzato AMD e dai suoi millemila brevetti è risaputo, che Zen sia stato sviluppato assieme a BD è cosa che non ho mai letto.
Poi se vogliamo parlare di nomi, ok, ma un conto è l'architettura in se e un conto è un nome che puoi dare a qualunque progetto a prescindere dal tipo e dal tempo.
*
bella domanda :D
mi sa che è uno dei suoi misunderstanding
*
Ormai Paolo pur di difendere Bulldozer non sa più cosa inventarsi....
AMD stessa ha dichiarato che lo sviluppo di ZEN è iniziato nel 2012......una nuova architettura a pochi mesi dal rilascio di Bulldozer, richiamando in fretta e furia Jim Keller.......chissà come mai......:fiufiu:
*
:confused:
Quello che hai postato è in contraddizione con quello che ho scritto?
Se poi vuoi metterla a bandiera, tipo AMD è corsa all'SMT di Intel, io non penso... visto che da quanto sembra in 2 anni AMD è riuscita a fare di più di quanto fatto dalla tua azienda in 15... magari l'allievo supera il maestro? :)
AMD era ENORMEMENTE in ritardo, causa Phenom prima e Bulldozer poi: è OVVIO che con Zen sia stata costretta a fare i salti mortali per cercare di essere nuovamente competitiva.
Adesso se uno a lavoro si fa una gran panzata di sonno e poi si risveglia e si sbraccia per recuperare il da fare, gli danno pure il premio produttività? Non mi pare...
La mia azienda?
Per tua conoscenza ho comprato diverse azioni AMD.....guarda caso dopo l'annuncio di Zen!
Io ho perso le mie di Intel, ormai. :cry:
Ma è diventato Paolo VS tutti? :D
Paolo, tra tutte le cose che ho sentito l'unica della quale sono graniticamente sicuro che sia uscita dalla bocca di Lisa Su è che con Zen sono partiti da un foglio bianco facendo tesoro (ovviamente) degli errori e delle intuizioni corrette passate ma comunque partendo da zero.
*
Quindi me lo sono sognato? Azzo... brutta cosa. :mc:
Mica è la prima volta...
Se non sei sicuro di una cosa, è meglio che eviti di riportarla. Oppure, meglio ancora, cerca qualche fonte a sostegno, così ti levi il dubbio.
Ed elimini alla radice i problemi.
Il Thuban mi sembra di aver letto (il mi sembra lo metto d'obbligo, ora) che non era compatibile architetturalmente con le AVX, quindi cambiare coveva cambiare...
Non c'è nulla di incompatibile a priori. Ci sono soltanto i costi per realizzare l'implementazione. Le AVX possono costare poco o molto a seconda degli obiettivi prestazionali e/o di transistor e/o di consumi, ma un'implementazione semplice (e che ricicla tantissimo dall'esistente implementazione di SSE) è possibilissimo farla.
Che riciclino delle cose è normale... ma credo che anche sto giro il silicio, o meglio la mancanza di un PP decente silicio, farà la sua parte.
Però, non credo che tutto il mondo sia sfigato tranne Intel... mi sa che giudicare il PP non fortunato sia la scusa perfetta per non affermare che Intel lo ha fatto meglio, 32nm, 22nm, 14nm.
Non mi pare che Intel se la sia goduta nel passaggio ai 22nm prima, e soprattutto i 14nm dopo. E coi 10nm è, nuovamente, in ritardo...
La roba non implementata (per questioni di tempo e/o transistor budget) finirà in Zen+.
I work-around si usano per i bug.
BD e Zen si dice che avevano lo stesso sviluppo iniziale,
Non l'ha detto mai nessuno, e il loro sviluppo è temporalmente ben diverso.
Dice "the 8-wide retire is independent of integer and floating point".
Detta così sembra che la coda di ritiro 8-wide è indipendente da quella int e fp, ma non so se ha senso :mbe:
Probabilmente ha più senso come hai detto tu, però diciamo che non si è espresso bene nemmeno lui, se è quello che voleva dire :D
Già. IMO si potrebbe interpretare che la coda di ritiro pesca indipendentemente da tutte e due. Cosa che, tra l'altro, si sposerebbe perfettamente con la slide (come si può vedere, attinge senza costrizioni da ambo i macro-blocchi) e con quello che lui aveva detto all'inizio.
Comunque ha senso, perchè in SMT è partizionata. 4 per thread mi sembrano poche...
Hai detto anche tu che le MOP di AMD sono molto dense, e che spesso si mappano 1:1 con le istruzioni di provenienza.
Ricorda pure che il limite del decoder di Zen è di 4 istruzioni per ciclo di clock, ma per un solo thread alla volta.
E che la micro-op queue invia al massimo 6 uop per ciclo di clock ai due dispatcher.
Per cui una retire 8-wide mi sembra ben dimensionata alla scopo. Mentre il doppio è sicuramente molto esagerata.
Su anand comunque hanno fatto notare che il tizio intel alla fine, a parte che non ha manco ringraziato, ma era un po' nervoso e "tossiva" per schiarirsi la voce spesso... :D
Nervoso non mi è parso proprio. Un colpetto di tosse ci può anche stare.
Poi la domanda l'ha fatta (reiterata) sulla cache L3, che non mi pare offra prestazioni migliori di quella Intel. Dunque non aveva motivo d'esser nervoso. :cool:
Sarà che lavora proprio in quell'ambito, e voleva chiarire quel dettaglio.
Boh... oggi ho qualche neurone che mi lavora in più (o in meno)... mi sono venuti dei dubbi.
Cioè... l'FO4 può ottimizzare il consumo tra il gioco IPC * Frequenza nel risultato della medesima potenza.
fin qui ho capito... ma nel risultato comunque le unità logiche arrivano comunque a consumare, nel senso che nella stessa unità di tempo o in un modo o nell'altro risolvono le stesse operazioni.
Ora... evitiamo commenti perchè faccio un esempio, Zen potrebbe arrivare allo stesso valore di istruzioni elaborate con una frequenza maggiore ma con un IPC minore rispetto al 6900K, e magari consumando un po' meno per via che l'FO4 ottimizzerebbe il cosumo.
Però le unità logiche comunque elaborano gli stessi dati, quindi comunque il consumo non può essere molto diverso... e se il silicio 14nm Intel è migliore del 15% di quello GF, come cacchio fa Zen ad ottenere potenze simili ma addirittura consumare meno?
Possono tutti sti canali avanti e indietro e parallelli in qualche modo ridurre i transistor necessari? In fin dei conti le info di Zen lo danno 170/180mmq vs un 6900K che è circa 200mmq...
Si tratta di microarchitetture diverse: ci saranno scenari in cui va meglio l'una, e viceversa.
E finché non avremo altri, tanti, test diversi, non sapremo come si comporterà Zen e quale sarà di conseguenza la sua efficienza.
Considera che la tecnologia Core è nata sul 45nm, ed ormai è vecchia ed ha bisogno di una profonda revisione su questi pp ( anche se Cesare non è d'accordo) mentre Zen è nata per il 20nm, cucita su misura, teoricamente più efficiente.
Non sono d'accordo perché ciò che conta è il funzionamento della micro-architettura. E qui non c'entra la nanometria, se non per i risvolti di cui, in ogni caso, una micro-architettura trae automaticamente vantaggio (SE c'è vantaggio).
Detto in altri termini, su un processo produttivo nuovo la stessa micro-architettura consente di raggiungere prestazioni migliori, senza essere stata pensata appositamente per quel nuovo processo.
Capito a grandi linee. In teoria il nuovo salto di Zen che sarebbe sul 7nm ma mi sembra 14 sarebbe ancora "compatibile".
Quindi KabyLake dovrebbe essere ancora sulla vecchia ottimizzazione, ma sarebbe probabile che con il salto al 10nm Intel cambi qualche cosa?
Coi 10nm Intel proporrà anche una micro-architettura un po' diversa da Kaby Lake.
Scusa, ma ogni tanto ne leggo una nuova davvero.
Dove e chi dice che BD e Zen avevano lo stesso sviluppo iniziale?
Ho sempre letto che BD ha avuto uno sviluppo lento, ma leeento, così lento che il caro Meyer ci ha messo anni per farlo uscire e il risultato è stato a dir poco penoso.
Zen nasce per far retromarcia da un prodotto che per amd si è rivelato ancora più fallimentare di una architettura, quella phenom derivante dall'athlon, che a parte il silicio 45 non ha mai potuto competere con la concorrenza per il solo motivo di testardaggine dei dirigenti a non voler implementare il proprio SMT, tecnologia che era già allo studio dall'epoca degli athlon.
Che Zen prenda tutto quello che di buono ha realizzato AMD e dai suoi millemila brevetti è risaputo, che Zen sia stato sviluppato assieme a BD è cosa che non ho mai letto.
Poi se vogliamo parlare di nomi, ok, ma un conto è l'architettura in se e un conto è un nome che puoi dare a qualunque progetto a prescindere dal tipo e dal tempo.
*
bella domanda :D
mi sa che è uno dei suoi misunderstanding
*
Ormai Paolo pur di difendere Bulldozer non sa più cosa inventarsi....
AMD stessa ha dichiarato che lo sviluppo di ZEN è iniziato nel 2012......una nuova architettura a pochi mesi dal rilascio di Bulldozer, richiamando in fretta e furia Jim Keller.......chissà come mai......:fiufiu:
*
:confused:
Quello che hai postato è in contraddizione con quello che ho scritto?
Se poi vuoi metterla a bandiera, tipo AMD è corsa all'SMT di Intel, io non penso... visto che da quanto sembra in 2 anni AMD è riuscita a fare di più di quanto fatto dalla tua azienda in 15... magari l'allievo supera il maestro? :)
AMD era ENORMEMENTE in ritardo, causa Phenom prima e Bulldozer poi: è OVVIO che con Zen sia stata costretta a fare i salti mortali per cercare di essere nuovamente competitiva.
Adesso se uno a lavoro si fa una gran panzata di sonno e poi si risveglia e si sbraccia per recuperare il da fare, gli danno pure il premio produttività? Non mi pare...
La mia azienda?
Per tua conoscenza ho comprato diverse azioni AMD.....guarda caso dopo l'annuncio di Zen!
Io ho perso le mie di Intel, ormai. :cry:
Ma è diventato Paolo VS tutti? :D
Paolo, tra tutte le cose che ho sentito l'unica della quale sono graniticamente sicuro che sia uscita dalla bocca di Lisa Su è che con Zen sono partiti da un foglio bianco facendo tesoro (ovviamente) degli errori e delle intuizioni corrette passate ma comunque partendo da zero.
*
Quindi me lo sono sognato? Azzo... brutta cosa. :mc:
Mica è la prima volta...
Se non sei sicuro di una cosa, è meglio che eviti di riportarla. Oppure, meglio ancora, cerca qualche fonte a sostegno, così ti levi il dubbio.
Ed elimini alla radice i problemi.
Il Thuban mi sembra di aver letto (il mi sembra lo metto d'obbligo, ora) che non era compatibile architetturalmente con le AVX, quindi cambiare coveva cambiare...
Non c'è nulla di incompatibile a priori. Ci sono soltanto i costi per realizzare l'implementazione. Le AVX possono costare poco o molto a seconda degli obiettivi prestazionali e/o di transistor e/o di consumi, ma un'implementazione semplice (e che ricicla tantissimo dall'esistente implementazione di SSE) è possibilissimo farla.
Che riciclino delle cose è normale... ma credo che anche sto giro il silicio, o meglio la mancanza di un PP decente silicio, farà la sua parte.
Però, non credo che tutto il mondo sia sfigato tranne Intel... mi sa che giudicare il PP non fortunato sia la scusa perfetta per non affermare che Intel lo ha fatto meglio, 32nm, 22nm, 14nm.
Non mi pare che Intel se la sia goduta nel passaggio ai 22nm prima, e soprattutto i 14nm dopo. E coi 10nm è, nuovamente, in ritardo...
tuttodigitale
21-12-2016, 23:11
Ho sempre letto che BD ha avuto uno sviluppo lento, ma leeento, così lento che il caro Meyer ci ha messo anni per farlo uscire e il risultato è stato a dir poco penoso.
lo sviluppo di ZEN non è che sia stato molto più veloce......sono passati più di 4 anni....e anche k8, il progetto Hammer, ci sono voluti quasi 6 anni per avere il primo prodotto commerciale.
fermo restando che BD con il silicio di Intel avrebbe probabilmente fatto meglio di SB....di questo ne sono certo.:)
lo sviluppo di ZEN non è che sia stato molto più veloce......sono passati più di 4 anni....e anche k8, il progetto Hammer, ci sono voluti quasi 6 anni per avere il primo prodotto commerciale.
fermo restando che BD con il silicio di Intel avrebbe probabilmente fatto meglio di SB....di questo ne sono certo.:)
Pozhar
21-12-2016, 23:31
...
su un processo produttivo nuovo la stessa micro-architettura consente di raggiungere prestazioni migliori, senza essere stata pensata appositamente per quel nuovo processo.
Per prima cosa, sempre impeccabile http://emoticonforum.altervista.org/_altervista_ht/faccine/occhiolino/9.gif
venendo a noi, avrei una curiosità che nessuno fino adesso a cui l'ho chiesto mi ha saputo rispondere con esattezza e precisione. E quindi chi meglio di te in questo caso. :)
Ne approfitto allora per chiederti delle delucidazioni in merito al seguente quesito:
Parto col fatto che so che in linea teorica un affinamento al pp a parità della stessa architettura come ad esempio nel caso di sky e kaby non apporta un miglioramento dell'ipc.
La mia domanda e curiosità (e come dicevo a cui non ho avuto mai una risposta concreta), è: prendendo come riferimento ad esempio il socket 775 (non voglio prendere come esempio architetture troppo vecchie) e più precisamente le cpu Core 2 Quad Q9x50 (Yorkfield) se ipoteticamente senza modificare nulla, fosse possibile portare questa architettura all'attuale pp (14nm) credo che ci siano miglioramenti in molti aspetti, in primis nei consumi etc... ma quello che m'interessa sapere, è: anche all'ipc?
Per dire un Q9650 a 14nm in questo aspetto (ipc) andrebbe uguale al modello nativo a 45nm o migliorerebbe? E se si, facendo un rapido calcolo a spanne, di quanto?
Ti ringrazio anticipatamente per tutto ;)
su un processo produttivo nuovo la stessa micro-architettura consente di raggiungere prestazioni migliori, senza essere stata pensata appositamente per quel nuovo processo.
Per prima cosa, sempre impeccabile http://emoticonforum.altervista.org/_altervista_ht/faccine/occhiolino/9.gif
venendo a noi, avrei una curiosità che nessuno fino adesso a cui l'ho chiesto mi ha saputo rispondere con esattezza e precisione. E quindi chi meglio di te in questo caso. :)
Ne approfitto allora per chiederti delle delucidazioni in merito al seguente quesito:
Parto col fatto che so che in linea teorica un affinamento al pp a parità della stessa architettura come ad esempio nel caso di sky e kaby non apporta un miglioramento dell'ipc.
La mia domanda e curiosità (e come dicevo a cui non ho avuto mai una risposta concreta), è: prendendo come riferimento ad esempio il socket 775 (non voglio prendere come esempio architetture troppo vecchie) e più precisamente le cpu Core 2 Quad Q9x50 (Yorkfield) se ipoteticamente senza modificare nulla, fosse possibile portare questa architettura all'attuale pp (14nm) credo che ci siano miglioramenti in molti aspetti, in primis nei consumi etc... ma quello che m'interessa sapere, è: anche all'ipc?
Per dire un Q9650 a 14nm in questo aspetto (ipc) andrebbe uguale al modello nativo a 45nm o migliorerebbe? E se si, facendo un rapido calcolo a spanne, di quanto?
Ti ringrazio anticipatamente per tutto ;)
george_p
21-12-2016, 23:36
lo sviluppo di ZEN non è che sia stato molto più veloce......sono passati più di 4 anni....e anche k8, il progetto Hammer, ci sono voluti quasi 6 anni per avere il primo prodotto commerciale.
fermo restando che BD con il silicio di Intel avrebbe probabilmente fatto meglio di SB....di questo ne sono certo.:)
Se conti da quando è entrato Keller a quando è uscito si parla di soli 3 anni e non 4, il resto è dovuto alla realizzazione su silicio.
Aggiungerei a sfavore i pochissimi soldi di AMD in quest'ultimo quasi quinquennio e alla crisi del mercato pc, elementi tutti che all'epoca di BD rappresentavano invece un vantaggio per l'azienda (più soldi da investire e un mercato pc desktop decisamente molto più florido rispetto all'ultimo triennio).
fermo restando che BD con il silicio di Intel avrebbe probabilmente fatto meglio di SB....di questo ne sono certo.:)
Se conti da quando è entrato Keller a quando è uscito si parla di soli 3 anni e non 4, il resto è dovuto alla realizzazione su silicio.
Aggiungerei a sfavore i pochissimi soldi di AMD in quest'ultimo quasi quinquennio e alla crisi del mercato pc, elementi tutti che all'epoca di BD rappresentavano invece un vantaggio per l'azienda (più soldi da investire e un mercato pc desktop decisamente molto più florido rispetto all'ultimo triennio).
Gioz
21-12-2016, 23:38
Per prima cosa, sempre impeccabile http://emoticonforum.altervista.org/_altervista_ht/faccine/occhiolino/9.gif
venendo a noi, avrei una curiosità che nessuno fino adesso a cui l'ho chiesto mi ha saputo rispondere con esattezza e precisione. E quindi chi meglio di te in questo caso. :)
Ne approfitto allora per chiederti delle delucidazioni in merito al seguente quesito:
Parto col fatto che so che in linea teorica un affinamento al pp a parità della stessa architettura come ad esempio nel caso di sky e kaby non apporta un miglioramento dell'ipc.
La mia domanda e curiosità (e come dicevo a cui non ho avuto mai una risposta concreta), è: prendendo come riferimento ad esempio il socket 775 (non voglio prendere come esempio architetture troppo vecchie) e più precisamente le cpu Core 2 Quad Q9x50 (Yorkfield) se ipoteticamente senza modificare nulla, fosse possibile portare questa architettura all'attuale pp (14nm) credo che ci siano miglioramenti in molti aspetti, in primis nei consumi etc... ma quello che m'interessa sapere, è: anche all'ipc?
Per dire un Q9650 a 14nm in questo aspetto (ipc) andrebbe uguale al modello nativo a 45nm o migliorerebbe? E se si, facendo un rapido calcolo a spanne, di quanto?
Ti ringrazio anticipatamente per tutto ;)
se l'architettura rimane del tutto invariata allora le operazioni che è in grado di eseguire nel singolo ciclo sono potenzialmente le stesse.
venendo a noi, avrei una curiosità che nessuno fino adesso a cui l'ho chiesto mi ha saputo rispondere con esattezza e precisione. E quindi chi meglio di te in questo caso. :)
Ne approfitto allora per chiederti delle delucidazioni in merito al seguente quesito:
Parto col fatto che so che in linea teorica un affinamento al pp a parità della stessa architettura come ad esempio nel caso di sky e kaby non apporta un miglioramento dell'ipc.
La mia domanda e curiosità (e come dicevo a cui non ho avuto mai una risposta concreta), è: prendendo come riferimento ad esempio il socket 775 (non voglio prendere come esempio architetture troppo vecchie) e più precisamente le cpu Core 2 Quad Q9x50 (Yorkfield) se ipoteticamente senza modificare nulla, fosse possibile portare questa architettura all'attuale pp (14nm) credo che ci siano miglioramenti in molti aspetti, in primis nei consumi etc... ma quello che m'interessa sapere, è: anche all'ipc?
Per dire un Q9650 a 14nm in questo aspetto (ipc) andrebbe uguale al modello nativo a 45nm o migliorerebbe? E se si, facendo un rapido calcolo a spanne, di quanto?
Ti ringrazio anticipatamente per tutto ;)
se l'architettura rimane del tutto invariata allora le operazioni che è in grado di eseguire nel singolo ciclo sono potenzialmente le stesse.
Pozhar
21-12-2016, 23:42
se l'architettura rimane del tutto invariata allora le operazioni che è in grado di eseguire nel singolo ciclo sono potenzialmente le stesse.
E su questo ci siamo. Infatti la mia conclusione è quella.
E' che m'intessa sapere in modo più approfondito/esaustivo con qualche calcolo/ formula etc.. del perché. sia in caso affermativo che in caso contrario.
cioè se è spiegabile e fosse possibile in qualche modo differente...
E su questo ci siamo. Infatti la mia conclusione è quella.
E' che m'intessa sapere in modo più approfondito/esaustivo con qualche calcolo/ formula etc.. del perché. sia in caso affermativo che in caso contrario.
cioè se è spiegabile e fosse possibile in qualche modo differente...
tuttodigitale
21-12-2016, 23:50
Il Thuban mi sembra di aver letto (il mi sembra lo metto d'obbligo, ora) che non era compatibile architetturalmente con le AVX, quindi cambiare coveva cambiare... con BD hanno speso poco per aumentare l'IPC (che da quanto so aumentare l'IPC è quello che costa di più), hanno puntato tutto sull'FO4 e sul 32nm SOI, e sappiamo come è andata.
costato poco BD? BD che io sappia è costato molto più di ZEN. Non si è trattato di aumentare semplicemente le frequenze....ma anche di mantenere a livello decente l'ipc (e il CMT viene in soccorso, raddoppiando alcune risorse per thread, che mai sarebbero state raddoppiate con un dual core puro), anche perchè non si era affatto messo in discussione che le prestazioni nel ST calassero,....anzi era stato pubblicizzato un +50% a dispetto dei soli 33% core in più, nonostante la penalità del CMT... l'obiettivo (maggiori prestazioni ST) è stato raggiunto solo confrontando k10 sullo stesso silicio
Infatti nonostante il fatto che sia presente una sola FP, 4 decoder vs 6 decoder, un modulo BD è grande esattamente quanto 2 core k10 (che sono straordinariamente piccoli paragonati a quelli di SB), segno che i core sono stati riempiti di logica.
d'altra parte il fatto che secondo una slide il consumo di ZEN è equiparabile a quella di XV, che però è su un processo planare, la dice lunga su quanto il connubio finfet-ZEN sia imprescindibile....probabilmente, il primo con XV non mostrerebbe il suo massimo, il secondo farebbe addirittura peggio di XV su un processo planare.
costato poco BD? BD che io sappia è costato molto più di ZEN. Non si è trattato di aumentare semplicemente le frequenze....ma anche di mantenere a livello decente l'ipc (e il CMT viene in soccorso, raddoppiando alcune risorse per thread, che mai sarebbero state raddoppiate con un dual core puro), anche perchè non si era affatto messo in discussione che le prestazioni nel ST calassero,....anzi era stato pubblicizzato un +50% a dispetto dei soli 33% core in più, nonostante la penalità del CMT... l'obiettivo (maggiori prestazioni ST) è stato raggiunto solo confrontando k10 sullo stesso silicio
Infatti nonostante il fatto che sia presente una sola FP, 4 decoder vs 6 decoder, un modulo BD è grande esattamente quanto 2 core k10 (che sono straordinariamente piccoli paragonati a quelli di SB), segno che i core sono stati riempiti di logica.
d'altra parte il fatto che secondo una slide il consumo di ZEN è equiparabile a quella di XV, che però è su un processo planare, la dice lunga su quanto il connubio finfet-ZEN sia imprescindibile....probabilmente, il primo con XV non mostrerebbe il suo massimo, il secondo farebbe addirittura peggio di XV su un processo planare.
Gioz
21-12-2016, 23:52
E su questo ci siamo. Infatti la mia conclusione è quella.
E' che m'intessa sapere in modo più approfondito/esaustivo con qualche calcolo/ formula etc.. del perché. sia in caso affermativo che in caso contrario.
cioè se è spiegabile e fosse possibile in qualche modo differente...
immagina un diagramma di flusso in cui ogni quadro e livello è un blocco logico o un'insieme di blocchi, se il diagramma non cambia quello che permette di fare utilizzandolo si mantiene inalterato.
poi la sua realizzazione fisica può avere dei limiti, e quindi non necessariamente essere superiore ad un'altra o avere vantaggi tali da risultare necessariamente preferibile.
E' che m'intessa sapere in modo più approfondito/esaustivo con qualche calcolo/ formula etc.. del perché. sia in caso affermativo che in caso contrario.
cioè se è spiegabile e fosse possibile in qualche modo differente...
immagina un diagramma di flusso in cui ogni quadro e livello è un blocco logico o un'insieme di blocchi, se il diagramma non cambia quello che permette di fare utilizzandolo si mantiene inalterato.
poi la sua realizzazione fisica può avere dei limiti, e quindi non necessariamente essere superiore ad un'altra o avere vantaggi tali da risultare necessariamente preferibile.
amon.akira
22-12-2016, 00:01
E su questo ci siamo. Infatti la mia conclusione è quella.
E' che m'intessa sapere in modo più approfondito/esaustivo con qualche calcolo/ formula etc.. del perché. sia in caso affermativo che in caso contrario.
cioè se è spiegabile e fosse possibile in qualche modo differente...
è una miniaturizzazione, N transistors occupano un tot spazio a 32nm, se mantenessimo gli stessi schemi e lo stesso numeri di transistors avremmo semplicemente un chip piu piccolo e consumi meno a 14nm
E' che m'intessa sapere in modo più approfondito/esaustivo con qualche calcolo/ formula etc.. del perché. sia in caso affermativo che in caso contrario.
cioè se è spiegabile e fosse possibile in qualche modo differente...
è una miniaturizzazione, N transistors occupano un tot spazio a 32nm, se mantenessimo gli stessi schemi e lo stesso numeri di transistors avremmo semplicemente un chip piu piccolo e consumi meno a 14nm
Pozhar
22-12-2016, 00:08
Vi ringrazio. mi confermate però cose che già sapevo. Ma forse sono io che voglio trovare una risposta diversa dove molto probabilmente non esiste.
Attendo cmq sempre se esiste (eventualmente) una spiegazione diversa.
Attendo cmq sempre se esiste (eventualmente) una spiegazione diversa.
paolo.oliva2
22-12-2016, 02:37
Vi ringrazio. mi confermate però cose che già sapevo. Ma forse sono io che voglio trovare una risposta diversa dove molto probabilmente non esiste.
Attendo cmq sempre se esiste (eventualmente) una spiegazione diversa.
Si potrebbe verificare anche un'altra situazione.
La realizzazione di un procio viene da un progetto su carta e poi messo sul silicio, ma dal progetto su carta al silicio c'è sempre un compromesso, perchè il silicio non sempre digerisce dei parametri spinti che invece su carta funzionano.
Poi è ovvio che se hai fatto una architettura un po' gambizzata con il silicio precedente e la riporti sul nuovo senza toccare niente, non guadagneresti comunque nulla.
Il Phenom I, per quello che sapevo, è stato un compromesso molto pesante, in quanto il 65nm aveva parecchi limiti. Il passaggio dal 65nm al 45nm ha portato mi sembra un +17% di IPC (Phenom I --> Phenom II), e un dato così alto credo sia difficile raggiungere solamente con un affinamento architetturale.
Però mi sembra che Intel unj qualcosina guadagni sempre a parità di architettura nel passaggio di silicio... credo che o "aggiusta" quello che nel silicio precedente non ha potuto fare, tipo magari per centellinare il TDP, in alcune parti del procio ha dovuto impostare parametri più rilassati e invece con il passaggio a miniaturizzazione più spinta, con un margine TDP superiore, ha usato parametri più aggressivi.
Per quello che so, che immagino....
Attendo cmq sempre se esiste (eventualmente) una spiegazione diversa.
Si potrebbe verificare anche un'altra situazione.
La realizzazione di un procio viene da un progetto su carta e poi messo sul silicio, ma dal progetto su carta al silicio c'è sempre un compromesso, perchè il silicio non sempre digerisce dei parametri spinti che invece su carta funzionano.
Poi è ovvio che se hai fatto una architettura un po' gambizzata con il silicio precedente e la riporti sul nuovo senza toccare niente, non guadagneresti comunque nulla.
Il Phenom I, per quello che sapevo, è stato un compromesso molto pesante, in quanto il 65nm aveva parecchi limiti. Il passaggio dal 65nm al 45nm ha portato mi sembra un +17% di IPC (Phenom I --> Phenom II), e un dato così alto credo sia difficile raggiungere solamente con un affinamento architetturale.
Però mi sembra che Intel unj qualcosina guadagni sempre a parità di architettura nel passaggio di silicio... credo che o "aggiusta" quello che nel silicio precedente non ha potuto fare, tipo magari per centellinare il TDP, in alcune parti del procio ha dovuto impostare parametri più rilassati e invece con il passaggio a miniaturizzazione più spinta, con un margine TDP superiore, ha usato parametri più aggressivi.
Per quello che so, che immagino....
fabius21
22-12-2016, 03:55
Invece te lo dico: AMD non è una ONLUS. Lo sa anche lei che una guerra sui prezzi non potrebbe sostenerla, visto che ha bisogno di incassare, e con margini ridotti incasserebbe poco. Per questo penso che proporrà sicuramente prezzi ridotti, ma non fuori mercato, in modo da guadagnare un po' di mercato e, dunque, incassare.
questo non è slegabile dalla premessa della prima parte sulle prestazione che rispiego perchè ho visto di non essermi espresso al meglio
e cioè che se un 8core abbia sia le prestazioni del 7700k che le prestazioni del 6900k , grazie alle tecnologie annunciate , perchè potresti aver capito che parlavo di 2 proci distinti
Solo in questo caso ,e facendo perdere la faccia per i prezzi aggressivi potrebbe essere una ottima pratica commerciale. La produzione zen è solo 8core ricordiamolo , magari prendendo adesso anche in considerazione i rumor sui sample pieni di bug, il 4core si è visto potrebbe esser uno dei primi che almeno avviavano os :D
Possiamo dire che ha sbagliato completamente esempi?
ni, se avesse messo il riferimento temporale forse era meglio ^^
Il discorso di Paolo è semplice: per lui i7 = 4 core / 8 thread. E s'è sentito fregato quando ha preso un portatile i7, e ha visto (POI! che era con la metà di core/thread. Solo che, per l'appunto, i7 è e rimane un'etichetta per identificare una categoria di prodotto, visto che il 6900K è anch'esso un i7, ma con 8 core / 16 thread.
il suo errore è stato non prendere la sigla e controllare , però quanto lo scoprii io , aiutai a scegliere un portatile ,mi sarei aspettato almeno 4 core , credevo fossero scontati , anche senza ht e frequenze basse. se l'i7 è il top 4 core castrati ci devo essere nel modello base , a meno che gli i7 non sia per identificare quelli senza gpu?
I modi sono spigolosi solo con certi personaggi. Personalmente preferirei, e GRADIREI AMPIAMENTE, continuare a intavolare esclusivamente discussioni tecniche, ma non posso certo passare sopra offese gratuite, come essere definito idiota (da uno che, peraltro, ha mostrato un grande acume) da uno che s'inventa di sana pianta delle cose che pretende di spacciare per vere, incluso infilarmi in bocca cose che non mi sono mai sognato di scrivere (e che sistematicamente sparisce, quando gli chiedo conto e ragione. Ovviamente).
Ma la cosa più fastidiosa è vedere il comportamento (incoerente, tra l'altro) di quelli che si sono sollevati in protesta soltanto DOPO che ho risposto, mentre di fronte alle cose di cui sopra sono rimasti bellamente in silenzio, perché evidentemente a questi diversamente onesti sta benissimo così.
Se ci fosse una moderazione funzionante non avrei alcun problema a rimanere in riga: mi limiterei ai meri contenuti tecnici, e a usare il testo Segnala, attendendo l'intervento del moderatore.
Quando si rifarà vivo e metterà uno stop agli OT et similia, non avrò nessunissimo problema a ritornare nei miei ranghi.
E adesso spero che si possa continuare tranquillamente senza finire come l'altro ieri.
Si deve usare più il condizionale quando si fanno pronostici etc.etc.etc. , poi a volte gli spigoli "li prendevo di proposito" anche io ;) , questa ultima frase era perchè stavo pensando di scrivere "ogni tanto sorvola e lasciali pensare ciò che vogliono" :P
Visto che andar OT è un piacere
Alla fine la maggiorparte delle fesserie che si dicon qui, è per un errato pensiero deduttivo , che potrebbe esser definito come un reato d'opinione , che sarebbero i reati per cui è pensata l'immunità parlamentare e la richiesta per poter procedere. :muro:
questo non è slegabile dalla premessa della prima parte sulle prestazione che rispiego perchè ho visto di non essermi espresso al meglio
e cioè che se un 8core abbia sia le prestazioni del 7700k che le prestazioni del 6900k , grazie alle tecnologie annunciate , perchè potresti aver capito che parlavo di 2 proci distinti
Solo in questo caso ,e facendo perdere la faccia per i prezzi aggressivi potrebbe essere una ottima pratica commerciale. La produzione zen è solo 8core ricordiamolo , magari prendendo adesso anche in considerazione i rumor sui sample pieni di bug, il 4core si è visto potrebbe esser uno dei primi che almeno avviavano os :D
Possiamo dire che ha sbagliato completamente esempi?
ni, se avesse messo il riferimento temporale forse era meglio ^^
Il discorso di Paolo è semplice: per lui i7 = 4 core / 8 thread. E s'è sentito fregato quando ha preso un portatile i7, e ha visto (POI! che era con la metà di core/thread. Solo che, per l'appunto, i7 è e rimane un'etichetta per identificare una categoria di prodotto, visto che il 6900K è anch'esso un i7, ma con 8 core / 16 thread.
il suo errore è stato non prendere la sigla e controllare , però quanto lo scoprii io , aiutai a scegliere un portatile ,mi sarei aspettato almeno 4 core , credevo fossero scontati , anche senza ht e frequenze basse. se l'i7 è il top 4 core castrati ci devo essere nel modello base , a meno che gli i7 non sia per identificare quelli senza gpu?
I modi sono spigolosi solo con certi personaggi. Personalmente preferirei, e GRADIREI AMPIAMENTE, continuare a intavolare esclusivamente discussioni tecniche, ma non posso certo passare sopra offese gratuite, come essere definito idiota (da uno che, peraltro, ha mostrato un grande acume) da uno che s'inventa di sana pianta delle cose che pretende di spacciare per vere, incluso infilarmi in bocca cose che non mi sono mai sognato di scrivere (e che sistematicamente sparisce, quando gli chiedo conto e ragione. Ovviamente).
Ma la cosa più fastidiosa è vedere il comportamento (incoerente, tra l'altro) di quelli che si sono sollevati in protesta soltanto DOPO che ho risposto, mentre di fronte alle cose di cui sopra sono rimasti bellamente in silenzio, perché evidentemente a questi diversamente onesti sta benissimo così.
Se ci fosse una moderazione funzionante non avrei alcun problema a rimanere in riga: mi limiterei ai meri contenuti tecnici, e a usare il testo Segnala, attendendo l'intervento del moderatore.
Quando si rifarà vivo e metterà uno stop agli OT et similia, non avrò nessunissimo problema a ritornare nei miei ranghi.
E adesso spero che si possa continuare tranquillamente senza finire come l'altro ieri.
Si deve usare più il condizionale quando si fanno pronostici etc.etc.etc. , poi a volte gli spigoli "li prendevo di proposito" anche io ;) , questa ultima frase era perchè stavo pensando di scrivere "ogni tanto sorvola e lasciali pensare ciò che vogliono" :P
Visto che andar OT è un piacere
Alla fine la maggiorparte delle fesserie che si dicon qui, è per un errato pensiero deduttivo , che potrebbe esser definito come un reato d'opinione , che sarebbero i reati per cui è pensata l'immunità parlamentare e la richiesta per poter procedere. :muro:
cdimauro
22-12-2016, 06:26
Vi ringrazio. mi confermate però cose che già sapevo. Ma forse sono io che voglio trovare una risposta diversa dove molto probabilmente non esiste.
Attendo cmq sempre se esiste (eventualmente) una spiegazione diversa.
No. Come ti è stato già spiegato da più parti, a livello di IPC non cambia (e non può cambiare) assolutamente di una virgola, perché l'IPC è legato al funzionamento della micro-architettura (in che modo svolge i compiti assegnati) e non è affetta da frequenze e consumi (è una metrica da essi indipendenti).
questo non è slegabile dalla premessa della prima parte sulle prestazione che rispiego perchè ho visto di non essermi espresso al meglio
e cioè che se un 8core abbia sia le prestazioni del 7700k che le prestazioni del 6900k , grazie alle tecnologie annunciate , perchè potresti aver capito che parlavo di 2 proci distinti
Solo in questo caso ,e facendo perdere la faccia per i prezzi aggressivi potrebbe essere una ottima pratica commerciale. La produzione zen è solo 8core ricordiamolo , magari prendendo adesso anche in considerazione i rumor sui sample pieni di bug, il 4core si è visto potrebbe esser uno dei primi che almeno avviavano os :D
4 e 8 core hanno prestazioni molto diverse (vedi anche il link al test coi giochi che avevo citato prima), per cui è un'ipotesi implausibile.
Ma nella tua ipotesi, e come peraltro avevo già detto, è chiaro che Intel ci farebbe una brutta figura, e che AMD potrebbe sfruttare commercialmente la cosa.
ni, se avesse messo il riferimento temporale forse era meglio ^^
Per me doveva proprio cambiare completamente esempio, e magari riferirsi a un Coffe Lake, Ice Lake, o altro.
Comunque... è andata. Speriamo di non ricascare sulle stesse cose.
il suo errore è stato non prendere la sigla e controllare , però quanto lo scoprii io , aiutai a scegliere un portatile ,mi sarei aspettato almeno 4 core , credevo fossero scontati , anche senza ht e frequenze basse. se l'i7 è il top 4 core castrati ci devo essere nel modello base , a meno che gli i7 non sia per identificare quelli senza gpu?
No, non c'è nessuna indicazione in tal senso. Infatti generalmente gli i7 senza GPU arrivano direttamente dagli Xeon, che sono senza GPU, ma la sigla non aiuta a distinguere né il numero di core né quest'altra informazione.
Per cui rimane una classe di CPU.
Si deve usare più il condizionale quando si fanno pronostici etc.etc.etc. , poi a volte gli spigoli "li prendevo di proposito" anche io ;) , questa ultima frase era perchè stavo pensando di scrivere "ogni tanto sorvola e lasciali pensare ciò che vogliono" :P
Visto che andar OT è un piacere
Alla fine la maggiorparte delle fesserie che si dicon qui, è per un errato pensiero deduttivo , che potrebbe esser definito come un reato d'opinione , che sarebbero i reati per cui è pensata l'immunità parlamentare e la richiesta per poter procedere. :muro:
Personalmente non sono a favore dell'immunità parlare, perché la legge regola già i casi di ingiuria, diffamazione, ecc., e i politici non devono esserne esenti soltanto perché hanno quel ruolo.
Premesso questo, qui il problema è un altro: le "fesserie" di cui mi sono lamentato non sono certo errori del pensiero deduttivo, ma OFFESE (gratuite) e MISTIFICAZIONI. Che non hanno nulla a che fare con ciò, e con la finalità del thread.
Infatti ognuno può pensare e fantastica quanto vuole. Ci mancherebbe. Il problema nasce quando ciò ricade in quanto ho appena riportato.
E adesso di corsa a consegnare portatile e badge: oggi è finita... :muro: :cry:
Attendo cmq sempre se esiste (eventualmente) una spiegazione diversa.
No. Come ti è stato già spiegato da più parti, a livello di IPC non cambia (e non può cambiare) assolutamente di una virgola, perché l'IPC è legato al funzionamento della micro-architettura (in che modo svolge i compiti assegnati) e non è affetta da frequenze e consumi (è una metrica da essi indipendenti).
questo non è slegabile dalla premessa della prima parte sulle prestazione che rispiego perchè ho visto di non essermi espresso al meglio
e cioè che se un 8core abbia sia le prestazioni del 7700k che le prestazioni del 6900k , grazie alle tecnologie annunciate , perchè potresti aver capito che parlavo di 2 proci distinti
Solo in questo caso ,e facendo perdere la faccia per i prezzi aggressivi potrebbe essere una ottima pratica commerciale. La produzione zen è solo 8core ricordiamolo , magari prendendo adesso anche in considerazione i rumor sui sample pieni di bug, il 4core si è visto potrebbe esser uno dei primi che almeno avviavano os :D
4 e 8 core hanno prestazioni molto diverse (vedi anche il link al test coi giochi che avevo citato prima), per cui è un'ipotesi implausibile.
Ma nella tua ipotesi, e come peraltro avevo già detto, è chiaro che Intel ci farebbe una brutta figura, e che AMD potrebbe sfruttare commercialmente la cosa.
ni, se avesse messo il riferimento temporale forse era meglio ^^
Per me doveva proprio cambiare completamente esempio, e magari riferirsi a un Coffe Lake, Ice Lake, o altro.
Comunque... è andata. Speriamo di non ricascare sulle stesse cose.
il suo errore è stato non prendere la sigla e controllare , però quanto lo scoprii io , aiutai a scegliere un portatile ,mi sarei aspettato almeno 4 core , credevo fossero scontati , anche senza ht e frequenze basse. se l'i7 è il top 4 core castrati ci devo essere nel modello base , a meno che gli i7 non sia per identificare quelli senza gpu?
No, non c'è nessuna indicazione in tal senso. Infatti generalmente gli i7 senza GPU arrivano direttamente dagli Xeon, che sono senza GPU, ma la sigla non aiuta a distinguere né il numero di core né quest'altra informazione.
Per cui rimane una classe di CPU.
Si deve usare più il condizionale quando si fanno pronostici etc.etc.etc. , poi a volte gli spigoli "li prendevo di proposito" anche io ;) , questa ultima frase era perchè stavo pensando di scrivere "ogni tanto sorvola e lasciali pensare ciò che vogliono" :P
Visto che andar OT è un piacere
Alla fine la maggiorparte delle fesserie che si dicon qui, è per un errato pensiero deduttivo , che potrebbe esser definito come un reato d'opinione , che sarebbero i reati per cui è pensata l'immunità parlamentare e la richiesta per poter procedere. :muro:
Personalmente non sono a favore dell'immunità parlare, perché la legge regola già i casi di ingiuria, diffamazione, ecc., e i politici non devono esserne esenti soltanto perché hanno quel ruolo.
Premesso questo, qui il problema è un altro: le "fesserie" di cui mi sono lamentato non sono certo errori del pensiero deduttivo, ma OFFESE (gratuite) e MISTIFICAZIONI. Che non hanno nulla a che fare con ciò, e con la finalità del thread.
Infatti ognuno può pensare e fantastica quanto vuole. Ci mancherebbe. Il problema nasce quando ciò ricade in quanto ho appena riportato.
E adesso di corsa a consegnare portatile e badge: oggi è finita... :muro: :cry:
bjt2
22-12-2016, 07:06
Peccato che funzioni esclusivamente con istruzioni microcodificate. :D
Nel caso di AMD, finora (non sappiamo se Zen cambierà, ma non credo, visto che è un progetto consolidato) si tratta di istruzioni che richiedono più di 2 MOP, che non sono comuni, e anzi a livello di esecuzione sono abbastanza rare.
Se ricordi, tuttodigitale aveva postato una bella immagine di Intel con delle statistiche sulla tipologia di istruzioni eseguite, e il 99% (se non ricordo male) non erano microcodificate.
Dunque il risparmio con questo nuovo meccanismo c'è sicuramente, ma nel mondo reale non incide, visto che è per lo più per roba legacy (e pochissimo utilizzata).
Beh si, è chiaro che si risparmia solo con le microcodificate... :D Per le altre non serve... :D
Ricordavo di questa statistica. Ma ci sono le istruzioni di context switch, bound check, stack frame management e altre per virtualizzazione che sono sicuramente microcodificate. Non credo che siano poi così rare... E poi le DIV e sqrt sono sicuramente microcodificate visto la latenza e se vedi anche in blender non è che siano così rare... Sospetto che questo sia anche uno dei motivi per cui performa bene...
Se, come penso, una istruzione microcodificata non blocca più il decoder, questo è un grosso vantaggio. Penso sempre a blender: se hai una (F)DIV in un ciclo, quando non c'era la uop cache, tu avevi che a ogni ciclo la DIV (microcodificata) ti bloccava i decoder (e non penso che bastassero 4 uops).
Con la uop cache ma senza questo trucco, il decoder ti viene bloccato solo la prima volta, ma consumi molto spazio nella uop cache per le uop della divisione.
Con questo meccanismo occupi un solo slot (dovrebbe bastare, non credo che la rom sia così grande da richiedere un puntatore enorme) ed hai una unità separata dal decoder che ti spara le uop: questo è maggiore pipelining e sospetto che contribuisca ulteriormente ad abbassare il FO4, perchè hai sgravato lo stadio di decoding dal compito di sparare le uop, risparmiando anche un muxer a valle dei decoder per muxare tra le uop dai decoder e quelle dalla microcode rom...
All'inizio, quando c'era l'overview generale, ha detto che poteva ritirare 8 uop (non istruzioni). E questo era il totale (come da slide, peraltro).
Successivamente ha detto che lo potevano fare indipendentemente i due blocchi intero e FPU. Quindi parrebbe un 8+8.
Solo che mi pare un po' esagerato, visto che non sono certo scenari comuni quelli in cui si possano superare gli 8 retire.
Zen ha il partizionamento statico in SMT per la(le?) retire queue. Se sono separate come sembra, 2+2 per thread mi sembra un po' poco, sopratutto per gestire un picco. Lui ha esplicitamente detto a voce che sono così grandi per gestire il picco. 4+4 per thread mi sembra ragionevole. E poi così le voci di uno Zen+ con SMT4 acquistano ancora più consistenza. Se vedi in quel video, all'inizio c'è la presentazione di skylake, poi il power9 e poi Zen. Il power9 per SMT 4 non è che abbia poi tutte ste pipe in più anche dello zen attuale. Anzi forse meno. E da bench che girano in rete, solo in SMT 8 il guadagno è irrisorio. Ma da SMT2 a SMT4 c'è ancora un po' di succo da spremere. E se non mi sbaglio il power9 può ritirare 8 uop/ciclo...
Nel caso di AMD, finora (non sappiamo se Zen cambierà, ma non credo, visto che è un progetto consolidato) si tratta di istruzioni che richiedono più di 2 MOP, che non sono comuni, e anzi a livello di esecuzione sono abbastanza rare.
Se ricordi, tuttodigitale aveva postato una bella immagine di Intel con delle statistiche sulla tipologia di istruzioni eseguite, e il 99% (se non ricordo male) non erano microcodificate.
Dunque il risparmio con questo nuovo meccanismo c'è sicuramente, ma nel mondo reale non incide, visto che è per lo più per roba legacy (e pochissimo utilizzata).
Beh si, è chiaro che si risparmia solo con le microcodificate... :D Per le altre non serve... :D
Ricordavo di questa statistica. Ma ci sono le istruzioni di context switch, bound check, stack frame management e altre per virtualizzazione che sono sicuramente microcodificate. Non credo che siano poi così rare... E poi le DIV e sqrt sono sicuramente microcodificate visto la latenza e se vedi anche in blender non è che siano così rare... Sospetto che questo sia anche uno dei motivi per cui performa bene...
Se, come penso, una istruzione microcodificata non blocca più il decoder, questo è un grosso vantaggio. Penso sempre a blender: se hai una (F)DIV in un ciclo, quando non c'era la uop cache, tu avevi che a ogni ciclo la DIV (microcodificata) ti bloccava i decoder (e non penso che bastassero 4 uops).
Con la uop cache ma senza questo trucco, il decoder ti viene bloccato solo la prima volta, ma consumi molto spazio nella uop cache per le uop della divisione.
Con questo meccanismo occupi un solo slot (dovrebbe bastare, non credo che la rom sia così grande da richiedere un puntatore enorme) ed hai una unità separata dal decoder che ti spara le uop: questo è maggiore pipelining e sospetto che contribuisca ulteriormente ad abbassare il FO4, perchè hai sgravato lo stadio di decoding dal compito di sparare le uop, risparmiando anche un muxer a valle dei decoder per muxare tra le uop dai decoder e quelle dalla microcode rom...
All'inizio, quando c'era l'overview generale, ha detto che poteva ritirare 8 uop (non istruzioni). E questo era il totale (come da slide, peraltro).
Successivamente ha detto che lo potevano fare indipendentemente i due blocchi intero e FPU. Quindi parrebbe un 8+8.
Solo che mi pare un po' esagerato, visto che non sono certo scenari comuni quelli in cui si possano superare gli 8 retire.
Zen ha il partizionamento statico in SMT per la(le?) retire queue. Se sono separate come sembra, 2+2 per thread mi sembra un po' poco, sopratutto per gestire un picco. Lui ha esplicitamente detto a voce che sono così grandi per gestire il picco. 4+4 per thread mi sembra ragionevole. E poi così le voci di uno Zen+ con SMT4 acquistano ancora più consistenza. Se vedi in quel video, all'inizio c'è la presentazione di skylake, poi il power9 e poi Zen. Il power9 per SMT 4 non è che abbia poi tutte ste pipe in più anche dello zen attuale. Anzi forse meno. E da bench che girano in rete, solo in SMT 8 il guadagno è irrisorio. Ma da SMT2 a SMT4 c'è ancora un po' di succo da spremere. E se non mi sbaglio il power9 può ritirare 8 uop/ciclo...
Piedone1113
22-12-2016, 07:56
No. Come ti è stato già spiegato da più parti, a livello di IPC non cambia (e non può cambiare) assolutamente di una virgola, perché l'IPC è legato al funzionamento della micro-architettura (in che modo svolge i compiti assegnati) e non è affetta da frequenze e consumi (è una metrica da essi indipendenti).
Esatto, ma quell'architettura con quei path non sfrutterebbe le possibilità offerte dal nuovo pp, ma consentirebbe una riduzione di area / consumo relativa alla sola derivazione fisica del processo.
Mi spiego meglio:
l'architettura core è stata studiata per i 45nm ed ottimizzata per essa.
il passaggio a 32 nm ha avuto una revisione ed un adattamento che ne ha aumentato l'ipc e la frequenza (quest'ultima relativa) ed un leggero abbassamento del consumo medio a parità di frequenza.
Stessa cosa per i pp successivi fino al 16+ che ha portato un aumento del consumo limitato a fronte di un aumento delle frequenze leggermente maggiore (ed ipc pressochè immutato rispetto al 16 liscio).
Quello che dico non è che l'architettura core è diventata ineffeciente con il passaggio a pp inferiori, ma che un'architettura ex novo avrebbe permesso sicuramente di sfruttare meglio il pp (come nel 45-32 nm) e permesso di ottenere una cpu più efficiente.
Insomma un 6950 10 core gflop X a 140w avrebbe potuto essere un 7950 10 core gflop X in 110w ( insomma sfruttare meglio il pp con un'architettura fatta su misura per esso).
Un poco come ha fatto ibm con Power ed i tanto discussi 32 nm, oppure Amd con zen (e credo che siamo d'accordo nel definire il 16 intel migliore del 14 gf ) che in soli 95w dovrebbe (il condizionale è d'obbligo) offrire prestazioni per watt migliori del 6900x
PS hai portato i cleanex dietro?
In bocca al lupo ed i migliori auguri per un futuro pieno di soddisfazioni (e magari tra 2 anni ti ritrovi a lavorare per AMD ;) )
Esatto, ma quell'architettura con quei path non sfrutterebbe le possibilità offerte dal nuovo pp, ma consentirebbe una riduzione di area / consumo relativa alla sola derivazione fisica del processo.
Mi spiego meglio:
l'architettura core è stata studiata per i 45nm ed ottimizzata per essa.
il passaggio a 32 nm ha avuto una revisione ed un adattamento che ne ha aumentato l'ipc e la frequenza (quest'ultima relativa) ed un leggero abbassamento del consumo medio a parità di frequenza.
Stessa cosa per i pp successivi fino al 16+ che ha portato un aumento del consumo limitato a fronte di un aumento delle frequenze leggermente maggiore (ed ipc pressochè immutato rispetto al 16 liscio).
Quello che dico non è che l'architettura core è diventata ineffeciente con il passaggio a pp inferiori, ma che un'architettura ex novo avrebbe permesso sicuramente di sfruttare meglio il pp (come nel 45-32 nm) e permesso di ottenere una cpu più efficiente.
Insomma un 6950 10 core gflop X a 140w avrebbe potuto essere un 7950 10 core gflop X in 110w ( insomma sfruttare meglio il pp con un'architettura fatta su misura per esso).
Un poco come ha fatto ibm con Power ed i tanto discussi 32 nm, oppure Amd con zen (e credo che siamo d'accordo nel definire il 16 intel migliore del 14 gf ) che in soli 95w dovrebbe (il condizionale è d'obbligo) offrire prestazioni per watt migliori del 6900x
PS hai portato i cleanex dietro?
In bocca al lupo ed i migliori auguri per un futuro pieno di soddisfazioni (e magari tra 2 anni ti ritrovi a lavorare per AMD ;) )
Pozhar
22-12-2016, 08:00
Grazie a tutti per la precisazione.
Buona giornata :)
Buona giornata :)
digieffe
22-12-2016, 08:56
E adesso di corsa a consegnare portatile e badge: oggi è finita... :muro: :cry:
quando prenderai servizio nel nuovo posto?
quando prenderai servizio nel nuovo posto?
tuttodigitale
22-12-2016, 09:14
Il Phenom I, per quello che sapevo, è stato un compromesso molto pesante, in quanto il 65nm aveva parecchi limiti. Il passaggio dal 65nm al 45nm ha portato mi sembra un +17% di IPC (Phenom I --> Phenom II), e un dato così alto credo sia difficile raggiungere solamente con un affinamento architetturale.
l'ipc dal phenom I al II non è cambiato molto ...il grosso del miglioramento siè avuto nei giochi, con punte FINO al 10%, dovuto soprattutto al maggior quantitativo di L3...si e no l'ipc è variato complessivamente del 5%...
poi certamente esistono delle eccezioni, dei carichi di lavoro che beneficiano e molto della l3..in cui l'athlon I (2x512+2MB)risulta nettamente più veloce dei core propus (2x1MB).
è chiaro che i soli 2MB di l3 è dovuto al progetto monolitico, ma il compromesso mi pare (Anche alla luce dell'ipc non certo ridotto) un buon compromesso...quelloche fa storcere il naso sui 65nm è il fatto che gli athlon k8 raggiungevano le più alte prestazioni con i 90nm... senza offrire grossi miglioramenti a basse frequenze (c'erano già gli athlon 5200+ a 90nm, con TDP da 65W e i 3800+ con tdp da 35W)
l'ipc dal phenom I al II non è cambiato molto ...il grosso del miglioramento siè avuto nei giochi, con punte FINO al 10%, dovuto soprattutto al maggior quantitativo di L3...si e no l'ipc è variato complessivamente del 5%...
poi certamente esistono delle eccezioni, dei carichi di lavoro che beneficiano e molto della l3..in cui l'athlon I (2x512+2MB)risulta nettamente più veloce dei core propus (2x1MB).
è chiaro che i soli 2MB di l3 è dovuto al progetto monolitico, ma il compromesso mi pare (Anche alla luce dell'ipc non certo ridotto) un buon compromesso...quelloche fa storcere il naso sui 65nm è il fatto che gli athlon k8 raggiungevano le più alte prestazioni con i 90nm... senza offrire grossi miglioramenti a basse frequenze (c'erano già gli athlon 5200+ a 90nm, con TDP da 65W e i 3800+ con tdp da 35W)
fabius21
22-12-2016, 10:29
4 e 8 core hanno prestazioni molto diverse (vedi anche il link al test coi giochi che avevo citato prima), per cui è un'ipotesi implausibile.
Ma nella tua ipotesi, e come peraltro avevo già detto, è chiaro che Intel ci farebbe una brutta figura, e che AMD potrebbe sfruttare commercialmente la cosa.
coi proci intel non è possibile ciò , ma non sappiamo come andranno tutte quelle funzionalità annunciate da amd. magari sfruttando "un modulo" o soli 4 core , potrebbe far meglio dei 7700k , per via della maggiore superfice di contatto. Sempre e solo se questa situazione fosse veritiera , le conviene far una guerra sui prezzi ,perchè azzerebbe la richiesta dei proci 4core intel, altrimenti come hai ben detto tu nel lungo periodo non riuscirebbe a reggere. Perchè le parole di lisa su parlavano di rivoluzione del mercato pc , che ormai è stagnato , altrimenti che rivoluzione sarebbe? nessuna se non nell'ambito economico, visto solo come un abbassamento dei prezzi.
Le mie molto probabilmente saranno sogni/deliri o come li vogliam chiamare :D però una minima possibilità c'è . Poi io coi pc son un pò avanti col pensiero , nel senso che già dai pentium-2 i miei pc gestiscono 2 thread ;) come così nel 2000 volevo passare la scheda grafica alle macchine virtuali , ero in anticipo solo di 10 anni tecnologicamente XD e possiam dire 13 se calcoliamo il software
Ti auguro una buona chiusura del rapporto lavorativo e un buon inizio nel nuovo lavoro ;)
Ma nella tua ipotesi, e come peraltro avevo già detto, è chiaro che Intel ci farebbe una brutta figura, e che AMD potrebbe sfruttare commercialmente la cosa.
coi proci intel non è possibile ciò , ma non sappiamo come andranno tutte quelle funzionalità annunciate da amd. magari sfruttando "un modulo" o soli 4 core , potrebbe far meglio dei 7700k , per via della maggiore superfice di contatto. Sempre e solo se questa situazione fosse veritiera , le conviene far una guerra sui prezzi ,perchè azzerebbe la richiesta dei proci 4core intel, altrimenti come hai ben detto tu nel lungo periodo non riuscirebbe a reggere. Perchè le parole di lisa su parlavano di rivoluzione del mercato pc , che ormai è stagnato , altrimenti che rivoluzione sarebbe? nessuna se non nell'ambito economico, visto solo come un abbassamento dei prezzi.
Le mie molto probabilmente saranno sogni/deliri o come li vogliam chiamare :D però una minima possibilità c'è . Poi io coi pc son un pò avanti col pensiero , nel senso che già dai pentium-2 i miei pc gestiscono 2 thread ;) come così nel 2000 volevo passare la scheda grafica alle macchine virtuali , ero in anticipo solo di 10 anni tecnologicamente XD e possiam dire 13 se calcoliamo il software
Ti auguro una buona chiusura del rapporto lavorativo e un buon inizio nel nuovo lavoro ;)
capitan_crasy
22-12-2016, 10:30
l'ipc dal phenom I al II non è cambiato molto ...il grosso del miglioramento siè avuto nei giochi, con punte FINO al 10%, dovuto soprattutto al maggior quantitativo di L3...si e no l'ipc è variato complessivamente del 5%...
Ni..
La L3 del K10 65nm aveva anche una latenza apocalittica, tanto che i propus a parità di clock e senza L3 andava mediamente di più
poi certamente esistono delle eccezioni, dei carichi di lavoro che beneficiano e molto della l3..in cui l'athlon I (2x512+2MB)risulta nettamente più veloce dei core propus (2x1MB).
Con i 45nm AMD ha aggiunto una altra cosa; le frequenze.
Mi ricordo un PC fatto con un K10 Toliman a 2.10Ghz (non ricordo il modello); un anno dopo allo stesso prezzo stessa configurazione ho preso un X3 Rana a 2.90Ghz..:asd:
è chiaro che i soli 2MB di l3 è dovuto al progetto monolitico, ma il compromesso mi pare (Anche alla luce dell'ipc non certo ridotto) un buon compromesso...quelloche fa storcere il naso sui 65nm è il fatto che gli athlon k8 raggiungevano le più alte prestazioni con i 90nm... senza offrire grossi miglioramenti a basse frequenze (c'erano già gli athlon 5200+ a 90nm, con TDP da 65W e i 3800+ con tdp da 35W)
Ci sono pochi dubbi che i 65nm SOI siano stati i peggiori nella storia produttiva AMD...
Ni..
La L3 del K10 65nm aveva anche una latenza apocalittica, tanto che i propus a parità di clock e senza L3 andava mediamente di più
poi certamente esistono delle eccezioni, dei carichi di lavoro che beneficiano e molto della l3..in cui l'athlon I (2x512+2MB)risulta nettamente più veloce dei core propus (2x1MB).
Con i 45nm AMD ha aggiunto una altra cosa; le frequenze.
Mi ricordo un PC fatto con un K10 Toliman a 2.10Ghz (non ricordo il modello); un anno dopo allo stesso prezzo stessa configurazione ho preso un X3 Rana a 2.90Ghz..:asd:
è chiaro che i soli 2MB di l3 è dovuto al progetto monolitico, ma il compromesso mi pare (Anche alla luce dell'ipc non certo ridotto) un buon compromesso...quelloche fa storcere il naso sui 65nm è il fatto che gli athlon k8 raggiungevano le più alte prestazioni con i 90nm... senza offrire grossi miglioramenti a basse frequenze (c'erano già gli athlon 5200+ a 90nm, con TDP da 65W e i 3800+ con tdp da 35W)
Ci sono pochi dubbi che i 65nm SOI siano stati i peggiori nella storia produttiva AMD...
Ric666
22-12-2016, 11:47
Ohhh e anche oggi mi son letto le mie belle 10 pagine di offtopic e litigi..
george_p
22-12-2016, 11:59
Ohhh e anche oggi mi son letto le mie belle 10 pagine di offtopic e litigi..
Va bene, no?
Ti fai una CULtura generale :stordita:
Va bene, no?
Ti fai una CULtura generale :stordita:
paolo.oliva2
22-12-2016, 11:59
coi proci intel non è possibile ciò , ma non sappiamo come andranno tutte quelle funzionalità annunciate da amd. magari sfruttando "un modulo" o soli 4 core , potrebbe far meglio dei 7700k , per via della maggiore superfice di contatto. Sempre e solo se questa situazione fosse veritiera , le conviene far una guerra sui prezzi ,perchè azzerebbe la richiesta dei proci 4core intel, altrimenti come hai ben detto tu nel lungo periodo non riuscirebbe a reggere. Perchè le parole di lisa su parlavano di rivoluzione del mercato pc , che ormai è stagnato , altrimenti che rivoluzione sarebbe? nessuna se non nell'ambito economico, visto solo come un abbassamento dei prezzi.
Le mie molto probabilmente saranno sogni/deliri o come li vogliam chiamare :D però una minima possibilità c'è . Poi io coi pc son un pò avanti col pensiero , nel senso che già dai pentium-2 i miei pc gestiscono 2 thread ;) come così nel 2000 volevo passare la scheda grafica alle macchine virtuali , ero in anticipo solo di 10 anni tecnologicamente XD e possiam dire 13 se calcoliamo il software
Ti auguro una buona chiusura del rapporto lavorativo e un buon inizio nel nuovo lavoro ;)
C'è anche un'altra frase del CEO di AMD, quella che "c'è bisogno dei secondi perchè i primi applichino prezzi onesti", che indubbiamente è una frase da marketing, prò se la colleghi a quella postata da te precedentemente, il quadro è indubbiamente orientato a prezzi bassi.
Ribadisco, perchè altrimenti assume significati diversi, che quello che AMD oggi dice potrebbe essere tranquillamente Intel a parti invertite.
Se il costo di un Zen X8+8 TOTALE, tra R&D e produzione può aggirarsi attorno ai 130$ (in rete da fonti affidabili è trapelato quanto paga AMD per il die Zen, 17/18$ e quanto ha speso per l'intera realizzaione R&D di Zen, quindi il calcolo è piùttosto preciso), il termine Onlus sarebbe riferito se AMD vendesse Zen pari pari a 130$, perchè Onlus equivale a dire no profit.
Se da un costo di 130$ AMD vendesse Zen da 300$ a 500$, staremmo parlando di margini sopra il 250% MINIMI, ecco che affibiare Onlus ad AMD nel momento che applicherebbe prezzi più bassi di Intel, è assolutamente fuorviante, perchè al limite si potrebbe dire che sarebbe Onlus se applicasse sui 130$ a Zen X8+8 e Babbo Natale sotto i 200$.
P.S.
Il termine Onlus è comparso da molto prima delle persone attuali nel TH... quindi non faccio polemica specifica verso una persona.
Le mie molto probabilmente saranno sogni/deliri o come li vogliam chiamare :D però una minima possibilità c'è . Poi io coi pc son un pò avanti col pensiero , nel senso che già dai pentium-2 i miei pc gestiscono 2 thread ;) come così nel 2000 volevo passare la scheda grafica alle macchine virtuali , ero in anticipo solo di 10 anni tecnologicamente XD e possiam dire 13 se calcoliamo il software
Ti auguro una buona chiusura del rapporto lavorativo e un buon inizio nel nuovo lavoro ;)
C'è anche un'altra frase del CEO di AMD, quella che "c'è bisogno dei secondi perchè i primi applichino prezzi onesti", che indubbiamente è una frase da marketing, prò se la colleghi a quella postata da te precedentemente, il quadro è indubbiamente orientato a prezzi bassi.
Ribadisco, perchè altrimenti assume significati diversi, che quello che AMD oggi dice potrebbe essere tranquillamente Intel a parti invertite.
Se il costo di un Zen X8+8 TOTALE, tra R&D e produzione può aggirarsi attorno ai 130$ (in rete da fonti affidabili è trapelato quanto paga AMD per il die Zen, 17/18$ e quanto ha speso per l'intera realizzaione R&D di Zen, quindi il calcolo è piùttosto preciso), il termine Onlus sarebbe riferito se AMD vendesse Zen pari pari a 130$, perchè Onlus equivale a dire no profit.
Se da un costo di 130$ AMD vendesse Zen da 300$ a 500$, staremmo parlando di margini sopra il 250% MINIMI, ecco che affibiare Onlus ad AMD nel momento che applicherebbe prezzi più bassi di Intel, è assolutamente fuorviante, perchè al limite si potrebbe dire che sarebbe Onlus se applicasse sui 130$ a Zen X8+8 e Babbo Natale sotto i 200$.
P.S.
Il termine Onlus è comparso da molto prima delle persone attuali nel TH... quindi non faccio polemica specifica verso una persona.
fabius21
22-12-2016, 12:29
Ma il termine onlus , è stato usato perchè il loro concetto economico è basato solo sul capitalismo , e cioè al guadagnare il più possibile,tipo intel, ma come l'attualità ci ha dimostrato è sbagliata ;)
Poi se si avverassero i miei "deliri" comprensivi di prezzo , la faccia che perderebbe intel , avrebbero gli stessi effetti della pratica commerciale che una decade fà messe in campo intel ;) , ma senza violare nulla.
Ps.
Si son fantasie quasi senza senso le mie, però possibili.
Io le espongo tanto finchè non esce non sapremo.
Poi se si avverassero i miei "deliri" comprensivi di prezzo , la faccia che perderebbe intel , avrebbero gli stessi effetti della pratica commerciale che una decade fà messe in campo intel ;) , ma senza violare nulla.
Ps.
Si son fantasie quasi senza senso le mie, però possibili.
Io le espongo tanto finchè non esce non sapremo.
paolo.oliva2
22-12-2016, 13:02
La possibilità che tutto ciò si avveri secondo me è principalmente una conseguenza di quanto funziona bene il nuovo turbo, cioè quanto la richiesta applicativa di spunto ST riesce ad essere soddisfatta sacrificando le prestazioni MT.
Se questo meccanismo funziona bene non hanno nemmeno bisogno dei quad e degli esa, ma possono direttamente segmentare sui picchi raggiungibili (perché un range di funzionamento dovranno imporlo alle CPU, per garantire la stabilità)
Però la resa del turbo sarebbe anche inversamente proporzionale alla convenienza del prezzo :)
Il discorso di prezzo per AMD è principalmente basato sul fatto di riuscire a piazzare Zen come alternativa ai prodotti Intel.
Ma siccome il brand Intel è forte, la presenza sul mercato idem, il marketing ancor più, cosa può fare AMD?
minor prezzo prestazioni, proporzionato alla potenza Zen, ma pur sempre più conveniente. Cioè... se andasse il 10% in meno ma prezzato il 50% in meno, non sarebbe "costa meno perchè va meno". Fantasticando prequenze di Zen alla BD, 5GHz turbo, già -30% sarebbe grasso che cola.
P.S.
Preciso... se Zen riuscisse ad avere frequenze turbo in linea con il 7700K, sarebbe più competitivo e di qui un prezzaggio superiore. Io parto dal presupposto che potrebbe averle tranquillamente anche -500MHz inferiori, però magari in OC RS/DU se a 4,5GHz ci sta, a me che mazza mi frega se per quei -500MGz def magari l'ho pagato 100€ in meno rispetto a +100€ e 4,5GHz turbo dalla casa?
Se questo meccanismo funziona bene non hanno nemmeno bisogno dei quad e degli esa, ma possono direttamente segmentare sui picchi raggiungibili (perché un range di funzionamento dovranno imporlo alle CPU, per garantire la stabilità)
Però la resa del turbo sarebbe anche inversamente proporzionale alla convenienza del prezzo :)
Il discorso di prezzo per AMD è principalmente basato sul fatto di riuscire a piazzare Zen come alternativa ai prodotti Intel.
Ma siccome il brand Intel è forte, la presenza sul mercato idem, il marketing ancor più, cosa può fare AMD?
minor prezzo prestazioni, proporzionato alla potenza Zen, ma pur sempre più conveniente. Cioè... se andasse il 10% in meno ma prezzato il 50% in meno, non sarebbe "costa meno perchè va meno". Fantasticando prequenze di Zen alla BD, 5GHz turbo, già -30% sarebbe grasso che cola.
P.S.
Preciso... se Zen riuscisse ad avere frequenze turbo in linea con il 7700K, sarebbe più competitivo e di qui un prezzaggio superiore. Io parto dal presupposto che potrebbe averle tranquillamente anche -500MHz inferiori, però magari in OC RS/DU se a 4,5GHz ci sta, a me che mazza mi frega se per quei -500MGz def magari l'ho pagato 100€ in meno rispetto a +100€ e 4,5GHz turbo dalla casa?
paolo.oliva2
22-12-2016, 13:16
Ma il termine onlus , è stato usato perchè il loro concetto economico è basato solo sul capitalismo , e cioè al guadagnare il più possibile,tipo intel, ma come l'attualità ci ha dimostrato è sbagliata ;)
Poi se si avverassero i miei "deliri" comprensivi di prezzo , la faccia che perderebbe intel , avrebbero gli stessi effetti della pratica commerciale che una decade fà messe in campo intel ;) , ma senza violare nulla.
Ps.
Si son fantasie quasi senza senso le mie, però possibili.
Io le espongo tanto finchè non esce non sapremo.
I tuoi deliri sono pure i miei... del resto è da giugno che dico che un Zen X8+8 potrebbe partire da 300$, perchè non avrebbe senso una produzione nativa di Zen X86 unicamente per l'1% di mercato, applicando prezzi simili ad Intel, quando potrebbe prendere il 95% del mercato con ricarichi almeno 5 volte superiori di quelli applicati ad oggi... e se fino ad oggi è vissuta e ha rimediato 250 milioni di $ per l'R&D di Zen, insomma, non penso che AMD sarebbe dispiaciuta.
Oltretutto bisogna pure inquadrare AMD per quanto sta facendo attualmente, cioè progettare e realizzare prodotti per terzi, i cui ricarichi credo sarebbero nettamente inferiori rispetto a Zen realizzato in proprio e prodotto e commercializzato in proprio. Poi che ritorno commerciale avrebbe nell'acquisire fette di mercato? Oltre al guadagno, anche l'immagine.
Per Zen AMD non deve spendere nelle FAB, non deve spendere per sviluppare il silicio, AMD ha un prezzo di costo che è quello richiesto da GF, probabilmente a scaglioni di volume. La prox spesa che ha, è l'R&D di Zen APU e di Zen+. Non si deve preoccupare del 7nm FinFet a rlivello di realizzazione silicio.
Poi se si avverassero i miei "deliri" comprensivi di prezzo , la faccia che perderebbe intel , avrebbero gli stessi effetti della pratica commerciale che una decade fà messe in campo intel ;) , ma senza violare nulla.
Ps.
Si son fantasie quasi senza senso le mie, però possibili.
Io le espongo tanto finchè non esce non sapremo.
I tuoi deliri sono pure i miei... del resto è da giugno che dico che un Zen X8+8 potrebbe partire da 300$, perchè non avrebbe senso una produzione nativa di Zen X86 unicamente per l'1% di mercato, applicando prezzi simili ad Intel, quando potrebbe prendere il 95% del mercato con ricarichi almeno 5 volte superiori di quelli applicati ad oggi... e se fino ad oggi è vissuta e ha rimediato 250 milioni di $ per l'R&D di Zen, insomma, non penso che AMD sarebbe dispiaciuta.
Oltretutto bisogna pure inquadrare AMD per quanto sta facendo attualmente, cioè progettare e realizzare prodotti per terzi, i cui ricarichi credo sarebbero nettamente inferiori rispetto a Zen realizzato in proprio e prodotto e commercializzato in proprio. Poi che ritorno commerciale avrebbe nell'acquisire fette di mercato? Oltre al guadagno, anche l'immagine.
Per Zen AMD non deve spendere nelle FAB, non deve spendere per sviluppare il silicio, AMD ha un prezzo di costo che è quello richiesto da GF, probabilmente a scaglioni di volume. La prox spesa che ha, è l'R&D di Zen APU e di Zen+. Non si deve preoccupare del 7nm FinFet a rlivello di realizzazione silicio.
george_p
22-12-2016, 13:22
I tuoi deliri sono pure i miei... del resto è da giugno che dico che un Zen X8+8 potrebbe partire da 300$, perchè non avrebbe senso una produzione nativa di Zen X86 unicamente per l'1% di mercato, applicando prezzi simili ad Intel, quando potrebbe prendere il 95% del mercato con ricarichi almeno 5 volte superiori di quelli applicati ad oggi... e se fino ad oggi è vissuta e ha rimediato 250 milioni di $ per l'R&D di Zen, insomma, non penso che AMD sarebbe dispiaciuta.
Oltretutto bisogna pure inquadrare AMD per quanto sta facendo attualmente, cioè progettare e realizzare prodotti per terzi, i cui ricarichi credo sarebbero nettamente inferiori rispetto a Zen realizzato in proprio e prodotto e commercializzato in proprio. Poi che ritorno commerciale avrebbe nell'acquisire fette di mercato? Oltre al guadagno, anche l'immagine.
Per Zen AMD non deve spendere nelle FAB, non deve spendere per sviluppare il silicio, AMD ha un prezzo di costo che è quello richiesto da GF, probabilmente a scaglioni di volume. La prox spesa che ha, è l'R&D di Zen APU e di Zen+. Non si deve preoccupare del 7nm FinFet a rlivello di realizzazione silicio.
Non so se hai mai solo letto un poco di economia e strategie aziendali in relazione al mercato.
Dal mio punto di vista penso che 8+8 core a 300 euro sia davvero troppo poco, anche se i costi di ricerca e sviluppo sono stati pagati dai suoi clienti.
Ha pur sempre un debito ancora elevato da estinguere e quote di mercato che non sono quelle (nemmeno) ai tempi di BD appena uscito.
Poi, tutto è possibile. Ma se lo vende a 300 spero per lei che guadagni più di 10 euro a processore venduto.
Oltretutto bisogna pure inquadrare AMD per quanto sta facendo attualmente, cioè progettare e realizzare prodotti per terzi, i cui ricarichi credo sarebbero nettamente inferiori rispetto a Zen realizzato in proprio e prodotto e commercializzato in proprio. Poi che ritorno commerciale avrebbe nell'acquisire fette di mercato? Oltre al guadagno, anche l'immagine.
Per Zen AMD non deve spendere nelle FAB, non deve spendere per sviluppare il silicio, AMD ha un prezzo di costo che è quello richiesto da GF, probabilmente a scaglioni di volume. La prox spesa che ha, è l'R&D di Zen APU e di Zen+. Non si deve preoccupare del 7nm FinFet a rlivello di realizzazione silicio.
Non so se hai mai solo letto un poco di economia e strategie aziendali in relazione al mercato.
Dal mio punto di vista penso che 8+8 core a 300 euro sia davvero troppo poco, anche se i costi di ricerca e sviluppo sono stati pagati dai suoi clienti.
Ha pur sempre un debito ancora elevato da estinguere e quote di mercato che non sono quelle (nemmeno) ai tempi di BD appena uscito.
Poi, tutto è possibile. Ma se lo vende a 300 spero per lei che guadagni più di 10 euro a processore venduto.
fabius21
22-12-2016, 13:45
Paolo non son proprio deliri , ma sopposizioni prendendo in esame un ampio spettro di argomenti , e non solo quelli derivati alle evoluzioni tecnologiche.
Poi, tutto è possibile. Ma se lo vende a 300 spero per lei che guadagni più di 10 euro a processore venduto.
Ma la premessa è che ci guadagni a procio almeno un centone , altrimenti il discorso non reggerebbe ;)
Per quanto riguarda gli argomenti economici , se espongo il mio pensiero andiamo un pò troppo OT e andar OT anche dall'argomento economico ;)
veradun , si a 300$ il modello base
Poi, tutto è possibile. Ma se lo vende a 300 spero per lei che guadagni più di 10 euro a processore venduto.
Ma la premessa è che ci guadagni a procio almeno un centone , altrimenti il discorso non reggerebbe ;)
Per quanto riguarda gli argomenti economici , se espongo il mio pensiero andiamo un pò troppo OT e andar OT anche dall'argomento economico ;)
veradun , si a 300$ il modello base
george_p
22-12-2016, 14:03
Paolo non son proprio deliri , ma sopposizioni prendendo in esame un ampio spettro di argomenti , e non solo quelli derivati alle evoluzioni tecnologiche.
Ma la premessa è che ci guadagni a procio almeno un centone , altrimenti il discorso non reggerebbe ;)
Per quanto riguarda gli argomenti economici , se espongo il mio pensiero andiamo un pò troppo OT e andar OT anche dall'argomento economico ;)
veradun , si a 300$ il modello base
La mia frase era riferito proprio a questo.
Perché se davvero vendesse un processore 8+8 a 300 euro deve averne un minimo di guadagno... ma per come funzionano le cose non potrà venderlo a quel tanto, e non molti capiranno il perché.
Ma la premessa è che ci guadagni a procio almeno un centone , altrimenti il discorso non reggerebbe ;)
Per quanto riguarda gli argomenti economici , se espongo il mio pensiero andiamo un pò troppo OT e andar OT anche dall'argomento economico ;)
veradun , si a 300$ il modello base
La mia frase era riferito proprio a questo.
Perché se davvero vendesse un processore 8+8 a 300 euro deve averne un minimo di guadagno... ma per come funzionano le cose non potrà venderlo a quel tanto, e non molti capiranno il perché.
fabius21
22-12-2016, 14:45
La mia frase era riferito proprio a questo.
Perché se davvero vendesse un processore 8+8 a 300 euro deve averne un minimo di guadagno... ma per come funzionano le cose non potrà venderlo a quel tanto, e non molti capiranno il perché.
Non capendo come funzionano le cose, mi fermo qui ;)
Aggiungo solo che questa strategia(quello che ho esposto) si potrebbe adottare in questo periodo perchè siam vicini più o meno al limite fisico del silicio , percui intel non potrà contare su 2/3 avanzamenti di pp, confronto i concorrenti, e premesso che la resa di zen sia molto alta.
Perché se davvero vendesse un processore 8+8 a 300 euro deve averne un minimo di guadagno... ma per come funzionano le cose non potrà venderlo a quel tanto, e non molti capiranno il perché.
Non capendo come funzionano le cose, mi fermo qui ;)
Aggiungo solo che questa strategia(quello che ho esposto) si potrebbe adottare in questo periodo perchè siam vicini più o meno al limite fisico del silicio , percui intel non potrà contare su 2/3 avanzamenti di pp, confronto i concorrenti, e premesso che la resa di zen sia molto alta.
george_p
22-12-2016, 16:20
Non capendo come funzionano le cose, mi fermo qui ;)
Aggiungo solo che questa strategia(quello che ho esposto) si potrebbe adottare in questo periodo perchè siam vicini più o meno al limite fisico del silicio , percui intel non potrà contare su 2/3 avanzamenti di pp, confronto i concorrenti, e premesso che la resa di zen sia molto alta.
Questa resa altissima di Zen deve essere tale da costare a processore fatto su silicio pochi spiccioli, perché poi vanno aggiunti tutti i costi per fare arrivare il prodotto finito sugli scaffali.
Quando uscì BD se non ricordo male fu venduto a 300/360 euro inizialmente, e sapevano pure quanto fosse inferiore alla concorrenza nonostante i loro "otto" cores, addirittura sotto come ipc all'esa Thuban.
Ecco perché rimarrei molto perplesso se amd facesse un prezzo da patatine sancarlo con Zen 8+8, poi ripeto ...tutto è possibile ma lo sapremo solo a commercializzazione avvenuta.
Aggiungo solo che questa strategia(quello che ho esposto) si potrebbe adottare in questo periodo perchè siam vicini più o meno al limite fisico del silicio , percui intel non potrà contare su 2/3 avanzamenti di pp, confronto i concorrenti, e premesso che la resa di zen sia molto alta.
Questa resa altissima di Zen deve essere tale da costare a processore fatto su silicio pochi spiccioli, perché poi vanno aggiunti tutti i costi per fare arrivare il prodotto finito sugli scaffali.
Quando uscì BD se non ricordo male fu venduto a 300/360 euro inizialmente, e sapevano pure quanto fosse inferiore alla concorrenza nonostante i loro "otto" cores, addirittura sotto come ipc all'esa Thuban.
Ecco perché rimarrei molto perplesso se amd facesse un prezzo da patatine sancarlo con Zen 8+8, poi ripeto ...tutto è possibile ma lo sapremo solo a commercializzazione avvenuta.
bjt2
22-12-2016, 16:42
https://www.youtube.com/watch?v=buOKWKyJ4-I
Il tizio che ha calcolato l'IPC, aveva anche un core i5 skylake.
Ha rifatto i calcoli e si trova ancora 2.2 come ipc per core per zen
Per l'i5, siccome non ha HT, ha trovato meno di 1.5
Il tizio che ha calcolato l'IPC, aveva anche un core i5 skylake.
Ha rifatto i calcoli e si trova ancora 2.2 come ipc per core per zen
Per l'i5, siccome non ha HT, ha trovato meno di 1.5
Phopho
22-12-2016, 17:19
Ma secondo te regge un paragone del genere?
Inviato dal mio SM-N7505 utilizzando Tapatalk
Inviato dal mio SM-N7505 utilizzando Tapatalk
bjt2
22-12-2016, 17:39
Ma secondo te regge un paragone del genere?
Inviato dal mio SM-N7505 utilizzando Tapatalk
Sul thread su anand gli avevano contestato che aveva provato con un dual xeon, che aveva troppi core, che era numa e blablabla.
Ora con un quadcore ottiene gli stessi risultati (per l'IPC calcolato di Zen).
Avrà anche sottostimato l'IPC di ivybridge (perchè ha molti core, è 2p ecc) ma non ha sbagliato sull'IPC di Zen perchè il suo software conta le istruzioni, da cui si possono ricavare le istruzioni totali, che sono le stesse di Zen (la versione ufficiale di blender non fa schedulazione separata a seconda della cpu)
Quindi ragionevolmente ha coperto tutto lo spettro. Comunque sta cercando di procurarsi broadwell, skylake più potenti e kabilake...
Inviato dal mio SM-N7505 utilizzando Tapatalk
Sul thread su anand gli avevano contestato che aveva provato con un dual xeon, che aveva troppi core, che era numa e blablabla.
Ora con un quadcore ottiene gli stessi risultati (per l'IPC calcolato di Zen).
Avrà anche sottostimato l'IPC di ivybridge (perchè ha molti core, è 2p ecc) ma non ha sbagliato sull'IPC di Zen perchè il suo software conta le istruzioni, da cui si possono ricavare le istruzioni totali, che sono le stesse di Zen (la versione ufficiale di blender non fa schedulazione separata a seconda della cpu)
Quindi ragionevolmente ha coperto tutto lo spettro. Comunque sta cercando di procurarsi broadwell, skylake più potenti e kabilake...
Roland74Fun
22-12-2016, 19:17
Sul thread su anand gli avevano contestato che aveva provato con un dual xeon, che aveva troppi core, che era numa e blablabla.
Ora con un quadcore ottiene gli stessi risultati (per l'IPC calcolato di Zen).
Avrà anche sottostimato l'IPC di ivybridge (perchè ha molti core, è 2p ecc) ma non ha sbagliato sull'IPC di Zen perchè il suo software conta le istruzioni, da cui si possono ricavare le istruzioni totali, che sono le stesse di Zen (la versione ufficiale di blender non fa schedulazione separata a seconda della cpu)
In un sito di bench misero a confronto con i giochi un i7 5960x con un 8370 entrambi con una R9 290x.
In quasi tutti i giochi il framerate era uguale.
E giù bestemmie ed insulti nei commenti.
Ora con un quadcore ottiene gli stessi risultati (per l'IPC calcolato di Zen).
Avrà anche sottostimato l'IPC di ivybridge (perchè ha molti core, è 2p ecc) ma non ha sbagliato sull'IPC di Zen perchè il suo software conta le istruzioni, da cui si possono ricavare le istruzioni totali, che sono le stesse di Zen (la versione ufficiale di blender non fa schedulazione separata a seconda della cpu)
In un sito di bench misero a confronto con i giochi un i7 5960x con un 8370 entrambi con una R9 290x.
In quasi tutti i giochi il framerate era uguale.
E giù bestemmie ed insulti nei commenti.
paolo.oliva2
22-12-2016, 19:37
Questa resa altissima di Zen deve essere tale da costare a processore fatto su silicio pochi spiccioli, perché poi vanno aggiunti tutti i costi per fare arrivare il prodotto finito sugli scaffali.
Quando uscì BD se non ricordo male fu venduto a 300/360 euro inizialmente, e sapevano pure quanto fosse inferiore alla concorrenza nonostante i loro "otto" cores, addirittura sotto come ipc all'esa Thuban.
Ecco perché rimarrei molto perplesso se amd facesse un prezzo da patatine sancarlo con Zen 8+8, poi ripeto ...tutto è possibile ma lo sapremo solo a commercializzazione avvenuta.
Però, bisogna che stimiamo il prezzo del procio, comprensivo di tutto, perchè altrimenti è inutile.
Io parto da questo presupposto:
BR viene venduto a 170$ ed è 280mmq. Zen costa il doppio ogni 100mmq, però è anche 170/180mmq contro 280mmq, quindi se saremmo a prezzi simili.
Gridracedriver riporta 17/18$ a die per Zen, qa detta di B&C, ed abbiamo l'info ufficiale di Samsung che riporta 10,5$ ogni 100mmq, quindi direi che combacia.
I die fallati non li possiamo sapere, ma anche considerando un +5% per Zen, vorrebbe dire quanto? ogni 1000$ di die, 50$ di fallati in più... quanto cambierebbe?
BR e Zen, a parte il testing e la selezione, che sono si costosi, ma non è che testare un Zen X8+8 costa e per BR lo fanno gratis, perchè BR è un X4 ma ha anche l'iGPU, da quel momento in poi il package è identico, la scatola ed il resto, non penso che cambi... BR AMD lo vende a 170$ il modello top, io non penso che AMD non possa vendere a 300$ il modello base di Zen perchè non guadagnerebbe 10$...
Tieni presente che R&D su BR AMD certamente ci ha speso, non penso come Zen, ma è anche vero che se prevedi 1.000.000 di proci Zen, di BR quanti? 300.000? Quindi probabilmente le spese a procio in R&D sarebbero simili.
Vedi, io non voglio fare discorsi di bandiera, ma vorrei far capire che il prezzo dei proci desktop è TROPPO alto, talmente troppo alto che noi siamo portati a ipotizzare che costino davvero un'enormità, mentre io sono convinto che non è così, anzi, le spese superiori sono assolutamente ammortizzate dai volumi, quindi, per me, un procio per PC se non possa costare meno di un procio per telefonini, di sicuro uguale, ma certamente non 10 volte di più. Leggevo ieri di un X10 per telefonini a meno di 400$, tutto completo... con display 2K e tutte le ultime features e S.O. disponibili.
Dopo non lamentiamoci che la gente cambia telefono al posto del PC. Cacchio, se devo spendere 800€ per avere incrementi del 5% o 2000€ per avere di più, alla grande che la gente preferisce 300-400€ e si prende l'ultimo telefonino.
P.S.
Ricordati che quando uscì BD, tutti dicevano "impossibile un X8 sui 300€". Poi si sono salvati in calcio d'angolo dicendo che AMD è stata obbligata per basse performances, ma la cosa inequivocabile è che AMD comunque lo produceva perchè ci guadagnava, non certo in perdita, quindi?
Quando uscì BD se non ricordo male fu venduto a 300/360 euro inizialmente, e sapevano pure quanto fosse inferiore alla concorrenza nonostante i loro "otto" cores, addirittura sotto come ipc all'esa Thuban.
Ecco perché rimarrei molto perplesso se amd facesse un prezzo da patatine sancarlo con Zen 8+8, poi ripeto ...tutto è possibile ma lo sapremo solo a commercializzazione avvenuta.
Però, bisogna che stimiamo il prezzo del procio, comprensivo di tutto, perchè altrimenti è inutile.
Io parto da questo presupposto:
BR viene venduto a 170$ ed è 280mmq. Zen costa il doppio ogni 100mmq, però è anche 170/180mmq contro 280mmq, quindi se saremmo a prezzi simili.
Gridracedriver riporta 17/18$ a die per Zen, qa detta di B&C, ed abbiamo l'info ufficiale di Samsung che riporta 10,5$ ogni 100mmq, quindi direi che combacia.
I die fallati non li possiamo sapere, ma anche considerando un +5% per Zen, vorrebbe dire quanto? ogni 1000$ di die, 50$ di fallati in più... quanto cambierebbe?
BR e Zen, a parte il testing e la selezione, che sono si costosi, ma non è che testare un Zen X8+8 costa e per BR lo fanno gratis, perchè BR è un X4 ma ha anche l'iGPU, da quel momento in poi il package è identico, la scatola ed il resto, non penso che cambi... BR AMD lo vende a 170$ il modello top, io non penso che AMD non possa vendere a 300$ il modello base di Zen perchè non guadagnerebbe 10$...
Tieni presente che R&D su BR AMD certamente ci ha speso, non penso come Zen, ma è anche vero che se prevedi 1.000.000 di proci Zen, di BR quanti? 300.000? Quindi probabilmente le spese a procio in R&D sarebbero simili.
Vedi, io non voglio fare discorsi di bandiera, ma vorrei far capire che il prezzo dei proci desktop è TROPPO alto, talmente troppo alto che noi siamo portati a ipotizzare che costino davvero un'enormità, mentre io sono convinto che non è così, anzi, le spese superiori sono assolutamente ammortizzate dai volumi, quindi, per me, un procio per PC se non possa costare meno di un procio per telefonini, di sicuro uguale, ma certamente non 10 volte di più. Leggevo ieri di un X10 per telefonini a meno di 400$, tutto completo... con display 2K e tutte le ultime features e S.O. disponibili.
Dopo non lamentiamoci che la gente cambia telefono al posto del PC. Cacchio, se devo spendere 800€ per avere incrementi del 5% o 2000€ per avere di più, alla grande che la gente preferisce 300-400€ e si prende l'ultimo telefonino.
P.S.
Ricordati che quando uscì BD, tutti dicevano "impossibile un X8 sui 300€". Poi si sono salvati in calcio d'angolo dicendo che AMD è stata obbligata per basse performances, ma la cosa inequivocabile è che AMD comunque lo produceva perchè ci guadagnava, non certo in perdita, quindi?
digieffe
22-12-2016, 20:05
Però, bisogna che stimiamo il prezzo del procio, comprensivo di tutto, perchè altrimenti è inutile.
Io parto da questo presupposto:
BR viene venduto a 170$ ed è 280mmq. Zen costa il doppio ogni 100mmq, però è anche 170/180mmq contro 280mmq, quindi se saremmo a prezzi simili.
Gridracedriver riporta 17/18$ a die per Zen, qa detta di B&C, ed abbiamo l'info ufficiale di Samsung che riporta 10,5$ ogni 100mmq, quindi direi che combacia.
I die fallati non li possiamo sapere, ma anche considerando un +5% per Zen, vorrebbe dire quanto? ogni 1000$ di die, 50$ di fallati in più... quanto cambierebbe?
BR e Zen, a parte il testing e la selezione, che sono si costosi, ma non è che testare un Zen X8+8 costa e per BR lo fanno gratis, perchè BR è un X4 ma ha anche l'iGPU, da quel momento in poi il package è identico, la scatola ed il resto, non penso che cambi... BR AMD lo vende a 170$ il modello top, io non penso che AMD non possa vendere a 300$ il modello base di Zen perchè non guadagnerebbe 10$...
Tieni presente che R&D su BR AMD certamente ci ha speso, non penso come Zen, ma è anche vero che se prevedi 1.000.000 di proci Zen, di BR quanti? 300.000? Quindi probabilmente le spese a procio in R&D sarebbero simili.
Vedi, io non voglio fare discorsi di bandiera, ma vorrei far capire che il prezzo dei proci desktop è TROPPO alto, talmente troppo alto che noi siamo portati a ipotizzare che costino davvero un'enormità, mentre io sono convinto che non è così, anzi, le spese superiori sono assolutamente ammortizzate dai volumi, quindi, per me, un procio per PC se non possa costare meno di un procio per telefonini, di sicuro uguale, ma certamente non 10 volte di più. Leggevo ieri di un X10 per telefonini a meno di 400$, tutto completo... con display 2K e tutte le ultime features e S.O. disponibili.
Dopo non lamentiamoci che la gente cambia telefono al posto del PC. Cacchio, se devo spendere 800€ per avere incrementi del 5% o 2000€ per avere di più, alla grande che la gente preferisce 300-400€ e si prende l'ultimo telefonino.
P.S.
Ricordati che quando uscì BD, tutti dicevano "impossibile un X8 sui 300€". Poi si sono salvati in calcio d'angolo dicendo che AMD è stata obbligata per basse performances, ma la cosa inequivocabile è che AMD comunque lo produceva perchè ci guadagnava, non certo in perdita, quindi?
francamente, non credo che una grande azienda il prezzo di vendita lo faccia sui criteri da te esposti... criteri che rappresentano più desiderii da consumatori che formazione del prezzo secondo criteri economici e strategie aziendali.
ci son tanti fattori che si possono considerare:
(elenco solo i primi che mi vengono in mente)
- costo di produzione. - nel contesto specifico incide solo in parte
- costo di progettazione - nel contesto specifico può incidere significativamente
- reale capacità produttiva. - insufficiente quasi certamente prezzo più alto
- fasce di mercato che si vuol coprire. - es. BR 4c+512sp - BD fino al 9590 - ZEN
- capacità di assorbimento del mercato.
- strategia: voler massimizzare i guadagni o altre. - si fanno delle precise indagini di mercato ed in base a queste si può stabilire "il punto di convenienza"
e tanti altri sulle quali ora non mi va di riflettere...
in sintesi, le tue, sono ipotesi molto semplicistiche delle quali non abbiamo neanche un minimo d'informazioni
Io parto da questo presupposto:
BR viene venduto a 170$ ed è 280mmq. Zen costa il doppio ogni 100mmq, però è anche 170/180mmq contro 280mmq, quindi se saremmo a prezzi simili.
Gridracedriver riporta 17/18$ a die per Zen, qa detta di B&C, ed abbiamo l'info ufficiale di Samsung che riporta 10,5$ ogni 100mmq, quindi direi che combacia.
I die fallati non li possiamo sapere, ma anche considerando un +5% per Zen, vorrebbe dire quanto? ogni 1000$ di die, 50$ di fallati in più... quanto cambierebbe?
BR e Zen, a parte il testing e la selezione, che sono si costosi, ma non è che testare un Zen X8+8 costa e per BR lo fanno gratis, perchè BR è un X4 ma ha anche l'iGPU, da quel momento in poi il package è identico, la scatola ed il resto, non penso che cambi... BR AMD lo vende a 170$ il modello top, io non penso che AMD non possa vendere a 300$ il modello base di Zen perchè non guadagnerebbe 10$...
Tieni presente che R&D su BR AMD certamente ci ha speso, non penso come Zen, ma è anche vero che se prevedi 1.000.000 di proci Zen, di BR quanti? 300.000? Quindi probabilmente le spese a procio in R&D sarebbero simili.
Vedi, io non voglio fare discorsi di bandiera, ma vorrei far capire che il prezzo dei proci desktop è TROPPO alto, talmente troppo alto che noi siamo portati a ipotizzare che costino davvero un'enormità, mentre io sono convinto che non è così, anzi, le spese superiori sono assolutamente ammortizzate dai volumi, quindi, per me, un procio per PC se non possa costare meno di un procio per telefonini, di sicuro uguale, ma certamente non 10 volte di più. Leggevo ieri di un X10 per telefonini a meno di 400$, tutto completo... con display 2K e tutte le ultime features e S.O. disponibili.
Dopo non lamentiamoci che la gente cambia telefono al posto del PC. Cacchio, se devo spendere 800€ per avere incrementi del 5% o 2000€ per avere di più, alla grande che la gente preferisce 300-400€ e si prende l'ultimo telefonino.
P.S.
Ricordati che quando uscì BD, tutti dicevano "impossibile un X8 sui 300€". Poi si sono salvati in calcio d'angolo dicendo che AMD è stata obbligata per basse performances, ma la cosa inequivocabile è che AMD comunque lo produceva perchè ci guadagnava, non certo in perdita, quindi?
francamente, non credo che una grande azienda il prezzo di vendita lo faccia sui criteri da te esposti... criteri che rappresentano più desiderii da consumatori che formazione del prezzo secondo criteri economici e strategie aziendali.
ci son tanti fattori che si possono considerare:
(elenco solo i primi che mi vengono in mente)
- costo di produzione. - nel contesto specifico incide solo in parte
- costo di progettazione - nel contesto specifico può incidere significativamente
- reale capacità produttiva. - insufficiente quasi certamente prezzo più alto
- fasce di mercato che si vuol coprire. - es. BR 4c+512sp - BD fino al 9590 - ZEN
- capacità di assorbimento del mercato.
- strategia: voler massimizzare i guadagni o altre. - si fanno delle precise indagini di mercato ed in base a queste si può stabilire "il punto di convenienza"
e tanti altri sulle quali ora non mi va di riflettere...
in sintesi, le tue, sono ipotesi molto semplicistiche delle quali non abbiamo neanche un minimo d'informazioni
Dextroy
22-12-2016, 21:40
Dai raga sicuro il top a meno di 400 non ce lo fanno nemmeno vedere. Se le performances rimangono in linea con i rumore/horizon.
Inviato dal mio LG-D802 utilizzando Tapatalk
Inviato dal mio LG-D802 utilizzando Tapatalk
.Hellraiser.
22-12-2016, 21:42
Dai raga sicuro il top a meno di 400 non ce lo fanno nemmeno vedere. Se le performances rimangono in linea con i rumore/horizon.
Inviato dal mio LG-D802 utilizzando Tapatalk
io resto dell'idea che un top ai livelli di un 6900k non lo piazzeranno a meno di 8-900€
Inviato dal mio LG-D802 utilizzando Tapatalk
io resto dell'idea che un top ai livelli di un 6900k non lo piazzeranno a meno di 8-900€
digieffe
22-12-2016, 21:56
io resto dell'idea che un top ai livelli di un 6900k non lo piazzeranno a meno di 8-900€
quoto
se fosse un po' inferiore allora lo vedremmo sui 600.
quoto
se fosse un po' inferiore allora lo vedremmo sui 600.
.Hellraiser.
22-12-2016, 22:06
quoto
se fosse un po' inferiore allora lo vedremmo sui 600.
credo anche io, altrimenti sui 600 potrebbero proporre un 8c più limitato del top
se fosse un po' inferiore allora lo vedremmo sui 600.
credo anche io, altrimenti sui 600 potrebbero proporre un 8c più limitato del top
Gioz
22-12-2016, 22:15
in New Horizon quando giocavano facendo streaming è stato detto qualcosa come "6900K ce la fa benissimo...come ci si aspetta da una cpu che costa 1000$" passando poi a mostrare le difficoltà del 6700K, quindi credo che vogliano puntare su un prezzo fortemente competitivo, mi aspetterei qualcosa ad 1/4-1/3 meno dell'intel di riferimento, che sarebbe appetibile in una workstation e potrebbe tradursi in un marcato risparmio se anche le mobo avessero costi relativamente contenuti supponendo che le prestazioni siano effettivamente paragonabili mediamente alla cpu intel.
https://s29.postimg.org/5d8thkjl3/ryzen.jpg
https://s29.postimg.org/5d8thkjl3/ryzen.jpg
paolo.oliva2
22-12-2016, 22:35
francamente, non credo che una grande azienda il prezzo di vendita lo faccia sui criteri da te esposti... criteri che rappresentano più desiderii da consumatori che formazione del prezzo secondo criteri economici e strategie aziendali.
ci son tanti fattori che si possono considerare:
(elenco solo i primi che mi vengono in mente)
- costo di produzione. - nel contesto specifico incide solo in parte
- costo di progettazione - nel contesto specifico può incidere significativamente
- reale capacità produttiva. - insufficiente quasi certamente prezzo più alto
- fasce di mercato che si vuol coprire. - es. BR 4c+512sp - BD fino al 9590 - ZEN
- capacità di assorbimento del mercato.
- strategia: voler massimizzare i guadagni o altre. - si fanno delle precise indagini di mercato ed in base a queste si può stabilire "il punto di convenienza"
e tanti altri sulle quali ora non mi va di riflettere...
in sintesi, le tue, sono ipotesi molto semplicistiche delle quali non abbiamo neanche un minimo d'informazioni
Tutto quanto hai postato può variare il prezzo, però di quanto?
Io te la voglio fare ancora più semplice:
Abbiamo il costo produzione di BR e sappiamo già il prezzo di vendita.
il costo è 13$ circa, il prezzo di vendita per il top è 170$.
Abbiamo un rapporto di 13X tra costo produzione silicio e prezzo di vendita.
L'incognita è il costo R&D (che comunque sappiamo) e la percentuale di fallati.
La frase che ho evidenziato... la FAB negli USA, quella che produrrebbe il 14nm per Zen, mi sembra di aver letto che ha una produzione wafer 300mm simile a quella di Dresda. AMD, con la FAB di Dresda, a 45nm, copriva il 45% del mercato. Oggi AMD è al 5%? Produrre a 14nm rispetto a 45nm, garantisce tipo una produzione di die almeno doppia se non tripla. Samsung ha dato conferma di disponibilità delle sue catene a GF, nel caso lo chieda. Ora... siccome il mercato si è contratto, credo che il 45% di allora corrisponda ad una quantità superiore rispetto alla attuale. Inoltre, cerchiamo di capirci. Il problema, l'avrebbe ora che ha il 5%? Se lo avrà, credo che sarebbe un problema che AMD lo vorrebbe avere con tutto il cuore, e quando lo avrà, se lo avrà, allora aumenterà i prezzi, ma di certo non li aumenterebbe ora che il problema, quel problema, sarebbe l'ultimo dei problemi.
Devo tirare in causa Intel, ma non lo faccio per screditarla, però i dubbi che hai circa i costi, non li hai anche per Intel? Tipo... l'offerta desktop praticamente oltre X4+4, è l'unica ad offrirla, quindi vedrei più Intel che massimizza il prezzo a die, nel senso che se riesce a prezzare e vendere un X4+4, non gli frega una tozza di sovraprezzare un X8, perchè se l'X8 costa troppo, il cliente o acquista un X4+4 o al più un X6, e comunque è sempre lei a produrlo...
Oppure vogliamo pensare che Intel vende un 6900K a 1100$ perchè altrimenti a 1000$ sarebbe in perdita?
TORNO A PRECISARE. SE FOSSI IL CAPO DI INTEL, IO PREZZEREI UN 6900K a 1500$, giuro non posto per screditare. Il punto del discorso è che i rumors danno Zen X8+8 a partire da 300$. E' possibile? Per me si, magari per te no, ma da 300$ a quanto vuoi arrivare? 400$? 500$? Un tetto ci deve essere, o addirittura Intel è una Onlus?
ci son tanti fattori che si possono considerare:
(elenco solo i primi che mi vengono in mente)
- costo di produzione. - nel contesto specifico incide solo in parte
- costo di progettazione - nel contesto specifico può incidere significativamente
- reale capacità produttiva. - insufficiente quasi certamente prezzo più alto
- fasce di mercato che si vuol coprire. - es. BR 4c+512sp - BD fino al 9590 - ZEN
- capacità di assorbimento del mercato.
- strategia: voler massimizzare i guadagni o altre. - si fanno delle precise indagini di mercato ed in base a queste si può stabilire "il punto di convenienza"
e tanti altri sulle quali ora non mi va di riflettere...
in sintesi, le tue, sono ipotesi molto semplicistiche delle quali non abbiamo neanche un minimo d'informazioni
Tutto quanto hai postato può variare il prezzo, però di quanto?
Io te la voglio fare ancora più semplice:
Abbiamo il costo produzione di BR e sappiamo già il prezzo di vendita.
il costo è 13$ circa, il prezzo di vendita per il top è 170$.
Abbiamo un rapporto di 13X tra costo produzione silicio e prezzo di vendita.
L'incognita è il costo R&D (che comunque sappiamo) e la percentuale di fallati.
La frase che ho evidenziato... la FAB negli USA, quella che produrrebbe il 14nm per Zen, mi sembra di aver letto che ha una produzione wafer 300mm simile a quella di Dresda. AMD, con la FAB di Dresda, a 45nm, copriva il 45% del mercato. Oggi AMD è al 5%? Produrre a 14nm rispetto a 45nm, garantisce tipo una produzione di die almeno doppia se non tripla. Samsung ha dato conferma di disponibilità delle sue catene a GF, nel caso lo chieda. Ora... siccome il mercato si è contratto, credo che il 45% di allora corrisponda ad una quantità superiore rispetto alla attuale. Inoltre, cerchiamo di capirci. Il problema, l'avrebbe ora che ha il 5%? Se lo avrà, credo che sarebbe un problema che AMD lo vorrebbe avere con tutto il cuore, e quando lo avrà, se lo avrà, allora aumenterà i prezzi, ma di certo non li aumenterebbe ora che il problema, quel problema, sarebbe l'ultimo dei problemi.
Devo tirare in causa Intel, ma non lo faccio per screditarla, però i dubbi che hai circa i costi, non li hai anche per Intel? Tipo... l'offerta desktop praticamente oltre X4+4, è l'unica ad offrirla, quindi vedrei più Intel che massimizza il prezzo a die, nel senso che se riesce a prezzare e vendere un X4+4, non gli frega una tozza di sovraprezzare un X8, perchè se l'X8 costa troppo, il cliente o acquista un X4+4 o al più un X6, e comunque è sempre lei a produrlo...
Oppure vogliamo pensare che Intel vende un 6900K a 1100$ perchè altrimenti a 1000$ sarebbe in perdita?
TORNO A PRECISARE. SE FOSSI IL CAPO DI INTEL, IO PREZZEREI UN 6900K a 1500$, giuro non posto per screditare. Il punto del discorso è che i rumors danno Zen X8+8 a partire da 300$. E' possibile? Per me si, magari per te no, ma da 300$ a quanto vuoi arrivare? 400$? 500$? Un tetto ci deve essere, o addirittura Intel è una Onlus?
digieffe
22-12-2016, 23:23
Tutto quanto hai postato può variare il prezzo, però di quanto?
IMHO da 300$ a 1001$, ma non è che se può vendere a 300$ con margini risicati lo farà per il bene del consumatore... amd non è un'azienda padronale, è quotata in borsa e dalla propria gestione deve rispondere agli stakeholder, agli organi di controllo ecc.
oltre a curare un minimo il marketing nel posizionamento del prezzo dei proddotti.
quindi sui suoi prodotti DEVE mantenere una certa redditività per via degli stackeholder, inoltre deve dare la percezione che ha prodotti buoni e questo, che a te piaccia o no, si fa mantenendo i prezzi alti almeno su determinate linee.
ne consegue che SE, e ripeto SE, il top dovesse andare in media più del 6900k sarà prezzato ai soliti 1001$ (vedi FX dei tempi andati), altrimenti significherebbe far percepire che il prodotto è inferiore. Ovviamente i modelli inferiori saranno ad un prezzo/prestaz. migliore di intel.
la maggiorparte degli acquirenti non si chiama nè paolo.oliva, nè digieffe, nè frequenta forum d'informatica. Semplicemente fa delle valutazioni superficiali e poi acquista.
purtroppo tu come tutti (me incluso) soffri del bias (non so come spiegarlo, diciamo deformazione "professionale" e non) che ti porta a fare delle valutazioni tendenti ai tuoi desideri e relativi alla tua complessità di ragionamento.
Quando ho scritto della "formazione del prezzo", non era una frase casuale, ma una specifica branca di economia, vedi libri di economia o ingegneria gestionale.
qui non è come una azienda a conduzione familiare dove le cose si fanno ad occhio, i soli studi di mercato commissionati ad apposite società costano milioni di $. Un errore di posizionamento può causare problemi in borsa, con le banche creditrici, e terzi in generale.
diciamo che io come te potrei apprezzare dei fuoristrada "trattori", ma solo nel momento in cui ne conosco i reali pregi. La GGGente (l'utente medio) in generale vuole il fuoristrada luccicoso e se costa poco per definizione non sarà buono. Potrei sbagliarmi ma forse fai l'errore di considerare che l'utente medio possa valutare queste cose come te che pur non essendo un tecnico specifico sei comunque addentrato nella materia.
ciao
IMHO da 300$ a 1001$, ma non è che se può vendere a 300$ con margini risicati lo farà per il bene del consumatore... amd non è un'azienda padronale, è quotata in borsa e dalla propria gestione deve rispondere agli stakeholder, agli organi di controllo ecc.
oltre a curare un minimo il marketing nel posizionamento del prezzo dei proddotti.
quindi sui suoi prodotti DEVE mantenere una certa redditività per via degli stackeholder, inoltre deve dare la percezione che ha prodotti buoni e questo, che a te piaccia o no, si fa mantenendo i prezzi alti almeno su determinate linee.
ne consegue che SE, e ripeto SE, il top dovesse andare in media più del 6900k sarà prezzato ai soliti 1001$ (vedi FX dei tempi andati), altrimenti significherebbe far percepire che il prodotto è inferiore. Ovviamente i modelli inferiori saranno ad un prezzo/prestaz. migliore di intel.
la maggiorparte degli acquirenti non si chiama nè paolo.oliva, nè digieffe, nè frequenta forum d'informatica. Semplicemente fa delle valutazioni superficiali e poi acquista.
purtroppo tu come tutti (me incluso) soffri del bias (non so come spiegarlo, diciamo deformazione "professionale" e non) che ti porta a fare delle valutazioni tendenti ai tuoi desideri e relativi alla tua complessità di ragionamento.
Quando ho scritto della "formazione del prezzo", non era una frase casuale, ma una specifica branca di economia, vedi libri di economia o ingegneria gestionale.
qui non è come una azienda a conduzione familiare dove le cose si fanno ad occhio, i soli studi di mercato commissionati ad apposite società costano milioni di $. Un errore di posizionamento può causare problemi in borsa, con le banche creditrici, e terzi in generale.
diciamo che io come te potrei apprezzare dei fuoristrada "trattori", ma solo nel momento in cui ne conosco i reali pregi. La GGGente (l'utente medio) in generale vuole il fuoristrada luccicoso e se costa poco per definizione non sarà buono. Potrei sbagliarmi ma forse fai l'errore di considerare che l'utente medio possa valutare queste cose come te che pur non essendo un tecnico specifico sei comunque addentrato nella materia.
ciao
digieffe
22-12-2016, 23:46
ho perso il post con il quale spiegavo una possibile logica dei prezzi, sintetizzo al max, spero si capisca
SE il top dovesse andare in media più del 6900k:
Zen top 1001$ (8c, più potente del 8c intel e più costoso)
Zen 2° 600$ (8c, più potente del 6 top intel, stesso prezzo)
Zen 3° 450$ (6/8c più potente del 6 2° intel, stesso prezzo)
Zen 4° 350$ (6c, più potente in MT, vicino in ST, al 4c top intel stesso prezzo)
BD 9xxx vs i5
SR vs i3
SE il top dovesse andare in media più del 6900k:
Zen top 1001$ (8c, più potente del 8c intel e più costoso)
Zen 2° 600$ (8c, più potente del 6 top intel, stesso prezzo)
Zen 3° 450$ (6/8c più potente del 6 2° intel, stesso prezzo)
Zen 4° 350$ (6c, più potente in MT, vicino in ST, al 4c top intel stesso prezzo)
BD 9xxx vs i5
SR vs i3
OvErClOck82
22-12-2016, 23:47
quoto tutto.
Però è anche vero che quelli che spendono tali cifre sono in gran parte persone informate
Però è anche vero che quelli che spendono tali cifre sono in gran parte persone informate
tuttodigitale
23-12-2016, 00:13
Se conti da quando è entrato Keller a quando è uscito si parla di soli 3 anni e non 4, il resto è dovuto alla realizzazione su silicio.
ma Keller non fa certo tutto il lavoro....
a parte la modifica dell'isa per supportare le AVX e non le SSE5, potrebbe non essere stata fatta nessuna modificata radicale...8-16 core (informazioni datate al 2007) erano e 8-16 sono rimasti (invero AMD si attendeva i 10-20 core per la generazione PILEDRIVER...)
anche perchè se ragioniamo all'inverso, erano trascorsi 4 anni da quando keller se ne andò da AM, e la messa in produzione in volumi di k8....in 4 anni , tempo impiegato per fare ZEN....del disegno originale di keller potrebbe essere rimasto niente.
.mi sembra quasi che si voglia solo denigrare il lavoro fatto su Bulldozer...
EDIT
le prime slide di roadmap di BD risalgono al 2008 e già aall'epoca il debutto era previsto con i 32nm....
ma Keller non fa certo tutto il lavoro....
a parte la modifica dell'isa per supportare le AVX e non le SSE5, potrebbe non essere stata fatta nessuna modificata radicale...8-16 core (informazioni datate al 2007) erano e 8-16 sono rimasti (invero AMD si attendeva i 10-20 core per la generazione PILEDRIVER...)
anche perchè se ragioniamo all'inverso, erano trascorsi 4 anni da quando keller se ne andò da AM, e la messa in produzione in volumi di k8....in 4 anni , tempo impiegato per fare ZEN....del disegno originale di keller potrebbe essere rimasto niente.
.mi sembra quasi che si voglia solo denigrare il lavoro fatto su Bulldozer...
EDIT
le prime slide di roadmap di BD risalgono al 2008 e già aall'epoca il debutto era previsto con i 32nm....
george_p
23-12-2016, 00:38
.mi sembra quasi che si voglia solo denigrare il lavoro fatto su Bulldozer...
Guardiamo i fatti, se BD fosse stato all'altezza anche con un silicio poco performante avrebbe detto la sua in diverse occasioni.
invece AMD ha perso quote di mercato e non hanno tirato a dadi per tornare su un approccio diverso dal CMT implementando finalmente l'SMT.
Poi non si dice che sia assolutamente scarso ma ha messo l'azienda nella condizioni di medio-sufficienza.
Questo va riconosciuto.
Guardiamo i fatti, se BD fosse stato all'altezza anche con un silicio poco performante avrebbe detto la sua in diverse occasioni.
invece AMD ha perso quote di mercato e non hanno tirato a dadi per tornare su un approccio diverso dal CMT implementando finalmente l'SMT.
Poi non si dice che sia assolutamente scarso ma ha messo l'azienda nella condizioni di medio-sufficienza.
Questo va riconosciuto.
tuttodigitale
23-12-2016, 00:59
Guardiamo i fatti, se BD fosse stato all'altezza anche con un silicio poco performante avrebbe detto la sua in diverse occasioni.
invece AMD ha perso quote di mercato e non hanno tirato a dadi per tornare su un approccio diverso dal CMT implementando finalmente l'SMT.
Questo va riconosciuto.
sarebbe stato davvero strano NON passare da QUATTRO implementazioni parziali del SMT, ad una cpu con SMT anche lato integer (anche se come fatto notare da Cesare anche la parte integer, beneficia dal CMT con carico scarsamente parallelizzabile).
Semmai non era logico passare al SMT2, ma direttamente ad un più esotico SMT2+CMT (4thread sulla fpu) o addirittura SMT4...anche li avranno ragionato..e non è detto che ZEN non debba svilupparsi in tal senso se le AVX-256, prenderanno piede (ma perchè dubitarne?)
Non lo so, pare che le cpu con SMT2, ma anche 8-vie debbano avere un ipc relativamente alto, dimenticandosi per strada che il P4 era con il SMT e conroe no..
sul fatto che BD, non sembrerebbe affatto un progetto troppo spinto lato frequenza sui 32nm SOI ce l'ha fatto notare CESARE, facendo l'esempio di IBM che ha migliorato le prestazioni per watt di brutto con una cpu da oltre 5GHz....
quel silicio, a livello di leakage rassomiglia più i finfet che non i bulk planari....
invece AMD ha perso quote di mercato e non hanno tirato a dadi per tornare su un approccio diverso dal CMT implementando finalmente l'SMT.
Questo va riconosciuto.
sarebbe stato davvero strano NON passare da QUATTRO implementazioni parziali del SMT, ad una cpu con SMT anche lato integer (anche se come fatto notare da Cesare anche la parte integer, beneficia dal CMT con carico scarsamente parallelizzabile).
Semmai non era logico passare al SMT2, ma direttamente ad un più esotico SMT2+CMT (4thread sulla fpu) o addirittura SMT4...anche li avranno ragionato..e non è detto che ZEN non debba svilupparsi in tal senso se le AVX-256, prenderanno piede (ma perchè dubitarne?)
Non lo so, pare che le cpu con SMT2, ma anche 8-vie debbano avere un ipc relativamente alto, dimenticandosi per strada che il P4 era con il SMT e conroe no..
sul fatto che BD, non sembrerebbe affatto un progetto troppo spinto lato frequenza sui 32nm SOI ce l'ha fatto notare CESARE, facendo l'esempio di IBM che ha migliorato le prestazioni per watt di brutto con una cpu da oltre 5GHz....
quel silicio, a livello di leakage rassomiglia più i finfet che non i bulk planari....
tuttodigitale
23-12-2016, 01:23
Ni..
La L3 del K10 65nm aveva anche una latenza apocalittica, tanto che i propus a parità di clock e senza L3 andava mediamente di più
la differenza tra propus e agena pare insignificante
http://www.anandtech.com/bench/product/106?vs=21
Con i 45nm AMD ha aggiunto una altra cosa; le frequenze.
direi soprattutto
2,6GHz@140W ->3,7GHz@125W
Ci sono pochi dubbi che i 65nm SOI siano stati i peggiori nella storia produttiva AMD...
con la stessa frequenza del phenom 9950 (2,6GHz), su 45nm AMD proponeva Opteron a 8 core con TDP da 115W...credo che non ci sia bisogno di commentare.
@george_p
se BD/PD fosse stata una pessima architettura, quale è il motivo che ha spinto AMD a cancellare un'architettura che sembrava in grado di lottare praticamente sullo stesso piano di quella INTEL nel mercato data-center, come k10, che non avrà chissà quale ipc, ma consumava niente nei confronti di Nehalem a parità di clock con i 45nm...
il fatto che per quanto una architettura possa essere buona con un silicio che ti soffoca le prestazioni sul nascere, c'è poco da fare...Credo che in INTEL non siano dei sprovveduti se hanno investito (investono?) quanto TSMC, GLOFO, SAMSUNG e ST messi assieme....
i 32nm per certi versi rassomigliano e molto i 65nm SOI..
La L3 del K10 65nm aveva anche una latenza apocalittica, tanto che i propus a parità di clock e senza L3 andava mediamente di più
la differenza tra propus e agena pare insignificante
http://www.anandtech.com/bench/product/106?vs=21
Con i 45nm AMD ha aggiunto una altra cosa; le frequenze.
direi soprattutto
2,6GHz@140W ->3,7GHz@125W
Ci sono pochi dubbi che i 65nm SOI siano stati i peggiori nella storia produttiva AMD...
con la stessa frequenza del phenom 9950 (2,6GHz), su 45nm AMD proponeva Opteron a 8 core con TDP da 115W...credo che non ci sia bisogno di commentare.
@george_p
se BD/PD fosse stata una pessima architettura, quale è il motivo che ha spinto AMD a cancellare un'architettura che sembrava in grado di lottare praticamente sullo stesso piano di quella INTEL nel mercato data-center, come k10, che non avrà chissà quale ipc, ma consumava niente nei confronti di Nehalem a parità di clock con i 45nm...
il fatto che per quanto una architettura possa essere buona con un silicio che ti soffoca le prestazioni sul nascere, c'è poco da fare...Credo che in INTEL non siano dei sprovveduti se hanno investito (investono?) quanto TSMC, GLOFO, SAMSUNG e ST messi assieme....
i 32nm per certi versi rassomigliano e molto i 65nm SOI..
cdimauro
23-12-2016, 06:06
Non lo sono sicuramente, visto che continuano a investirci. E... si stanno muovendo... ma non posso dire altro.
Beh si, è chiaro che si risparmia solo con le microcodificate... :D Per le altre non serve... :D
Ricordavo di questa statistica. Ma ci sono le istruzioni di context switch, bound check, stack frame management e altre per virtualizzazione che sono sicuramente microcodificate. Non credo che siano poi così rare...
Invece sono molto rare. :D
Quelle di bound check e di stack manipulation, poi, non le usa praticamente nessuno, perché sono troppo lente.
Infatti il prologue delle funzioni utilizza delle normale istruzioni di PUSH/MOV/SUB, mentre l'epilogue usa la LEAVE, che però non è microdificata.
Mentre per il bound check Intel ha tirato fuori un'estensione completamente nuova: MPX. Proprio perché nessuna usava la BOUND, che così com'era non era tanto utile.
Riguardo a context switch e virtualizzazione, devi contestualizzare: in un secondo = 3-4 miliardi di cicli di clock, QUANTE volte vengono utilizzate? Pochissime volte. E ogni volta COME vengono utilizzate? One shot: una volta eseguite, non servono più, perché non vengono eseguite in un ciclo, e dunque "cacharle" (brutto termine. :stordita:) non serve assolutamente.
E poi le DIV e sqrt sono sicuramente microcodificate visto la latenza e se vedi anche in blender non è che siano così rare... Sospetto che questo sia anche uno dei motivi per cui performa bene...
Se, come penso, una istruzione microcodificata non blocca più il decoder, questo è un grosso vantaggio. Penso sempre a blender: se hai una (F)DIV in un ciclo, quando non c'era la uop cache, tu avevi che a ogni ciclo la DIV (microcodificata) ti bloccava i decoder (e non penso che bastassero 4 uops).
E invece no: FDIV/FSQRT per la vecchia FPU e (V)DIV*/ (V)SQRT* non sono affatto microcodificate (su Steamroller; penso che per Zen sarà la stessa cosa). :D
Non confondere latenza (quella è elevata, senz'altro) con numero di uop necessarie per eseguire l'istruzione. :)
Se ti scorri il manuale delle ottimizzazioni di Agner, vedrai tu stesso che la microcodifica c'è in tante istruzioni, ma sono veramente rare... SE vengono usate nel codice. Perché dubito che i compilatori le usino tutte; secondo me alcune nemmeno vengono mai emesse. ;)
Con la uop cache ma senza questo trucco, il decoder ti viene bloccato solo la prima volta, ma consumi molto spazio nella uop cache per le uop della divisione.
Per la divisione, come già detto. Per quelle realmente microcodificate, è corretto.
Con questo meccanismo occupi un solo slot (dovrebbe bastare, non credo che la rom sia così grande da richiedere un puntatore enorme) ed hai una unità separata dal decoder che ti spara le uop: questo è maggiore pipelining e sospetto che contribuisca ulteriormente ad abbassare il FO4, perchè hai sgravato lo stadio di decoding dal compito di sparare le uop, risparmiando anche un muxer a valle dei decoder per muxare tra le uop dai decoder e quelle dalla microcode rom...
Questo succede anche con le (micro)architetture Intel: le uop delle istruzioni microcodificate non vengono generate dal decoder, ma da un'apposita sezione che si ricongiunge poi alla micro-op cache. Il design di Zen è molto simile a quello Intel (praticamente identico a prima vista).
Ma non so se Intel usa il trucchetto del puntatore alla uop. Questa potrebbe essere l'unica differenza sostanziale (ad alto livello, ovviamente).
Zen ha il partizionamento statico in SMT per la(le?) retire queue. Se sono separate come sembra, 2+2 per thread mi sembra un po' poco, sopratutto per gestire un picco. Lui ha esplicitamente detto a voce che sono così grandi per gestire il picco. 4+4 per thread mi sembra ragionevole. E poi così le voci di uno Zen+ con SMT4 acquistano ancora più consistenza. Se vedi in quel video, all'inizio c'è la presentazione di skylake, poi il power9 e poi Zen. Il power9 per SMT 4 non è che abbia poi tutte ste pipe in più anche dello zen attuale. Anzi forse meno. E da bench che girano in rete, solo in SMT 8 il guadagno è irrisorio. Ma da SMT2 a SMT4 c'è ancora un po' di succo da spremere. E se non mi sbaglio il power9 può ritirare 8 uop/ciclo...
Che non sono 16. ;)
Come già detto, 8+8 sono veramente troppe, a fronte del throughput del backend. E questo anche tenendo conto di eventuali limiti di partizionamento dovuti all'esecuzione di due thread.
Esatto, ma quell'architettura con quei path non sfrutterebbe le possibilità offerte dal nuovo pp, ma consentirebbe una riduzione di area / consumo relativa alla sola derivazione fisica del processo.
Mi spiego meglio:
l'architettura core è stata studiata per i 45nm ed ottimizzata per essa.
il passaggio a 32 nm ha avuto una revisione ed un adattamento che ne ha aumentato l'ipc e la frequenza (quest'ultima relativa) ed un leggero abbassamento del consumo medio a parità di frequenza.
Stessa cosa per i pp successivi fino al 16+ che ha portato un aumento del consumo limitato a fronte di un aumento delle frequenze leggermente maggiore (ed ipc pressochè immutato rispetto al 16 liscio).
Quello che dico non è che l'architettura core è diventata ineffeciente con il passaggio a pp inferiori, ma che un'architettura ex novo avrebbe permesso sicuramente di sfruttare meglio il pp (come nel 45-32 nm) e permesso di ottenere una cpu più efficiente.
Insomma un 6950 10 core gflop X a 140w avrebbe potuto essere un 7950 10 core gflop X in 110w ( insomma sfruttare meglio il pp con un'architettura fatta su misura per esso).
Un poco come ha fatto ibm con Power ed i tanto discussi 32 nm, oppure Amd con zen (e credo che siamo d'accordo nel definire il 16 intel migliore del 14 gf ) che in soli 95w dovrebbe (il condizionale è d'obbligo) offrire prestazioni per watt migliori del 6900x
Cerco di capirti, ma onestamente non capisco perché per sfruttare i benefici di un nuovo processo produttivo si dovrebbe sviluppare un'architettura ex-novo.
Non penso che con Zen AMD abbia buttato tutto quello fatto finora, e ricominciato da zero, reinventandosi la ruota per ogni cosa. Sono convinto che utilizzi molto dei vecchi processori, con alcune parti riprogettate, ovviamente.
Per essere chiari, se devo implementare una certa funzionalità, e ho già a disposizione un circuito che la implementa ottimamente, perché dovrei riprogettarlo da capo?
Con le (micro)architetture è così: si cambia se se ne ravvisa la necessità. Se prendi Skylake, ad esempio, tante cose sono cambiate rispetto ai predecessori, pur mantenendo un design di massima che è abbastanza consolidato.
Intel potrebbe anche progettare una (micro)architettura completamente nuova, certamente, ma questo lo potrebbe fare a prescindere dal processo produttivo.
IBM con POWER e i 32nm non ha assolutamente cambiato la microarchitettura. Tutt'altro. Ha aumentato moltissimo la cache L3 e ritoccato la virtualizzazione, ma tutto il resto è rimasto esattamente così com'è. Diciamo che passando da Haswell a Broadwell (22nm -> 14nm), Intel ha fatto di gran lunga più cambiamenti. ;)
PS hai portato i cleanex dietro?
Beh, in certe occasioni mi stavano proprio scappando qualche lacrima, ma ho cercato di contenermi. Per me rimane un duro colpo.
In bocca al lupo ed i migliori auguri per un futuro pieno di soddisfazioni (e magari tra 2 anni ti ritrovi a lavorare per AMD ;) )
Grazie. Speriamo bene, perché non so come sarà il nuovo lavoro.
Sì, non è certo escluso che possa anche lavorare per AMD in futuro. Se costruisse una sede qui a Ulm. :D Oppure se accettasse il lavoro da remoto, con alcuni viaggetti alla sede centrale ogni tanto. Perché Intel l'ho lasciata per non dovermi spostare a Monaco (i bambini sono troppo piccoli: non voglio altri traumi, dopo quello mostruoso dello spostamento dall'Italia a qui). :fagiano:
Sono un professionista e non metto dei paletti a prescindere. Ad esempio lavoro spesso con Windows, ma alla BMW dovrò mettere le mani per lo più su Linux. Non per questo ho deciso di non accettare la posizione lavorativa. Andrò avanti lo stesso, e mi farò un nuovo background / bagaglio culturale.
Certo, lavorare per un'azienda che produce o progetta processori è stato un sogno che ho realizzato, e che non mi dispiacerebbe riprendere. Sono 5 anni che lavoro a una mia architettura, che potrebbe fare molto comodo in diversi ambiti. In realtà, a parte l'embedded economico (chip da pochi centinaia di migliaia di transistor), si presta bene per qualunque cosa. Dunque si potrebbe anche usare per le future console, per cominciare in un settore dove il legacy non è indispensabile. HPC... server... pure.
E' tutta roba dove il legacy non serve, o si può comunque aggirare, e dove le prestazioni (nonché la densità di codice) della mia architettura potrebbe fare la differenza rispetto a Intel, ARM, e POWER.
Per cui... vedremo. Anche perché mi spuntano ogni tanto idee che si potrebbero tradurre in brevetti, e mi servirà qualche azienda a cui appoggiarmi per farlo. Però stavo pensando di rifare un salto all'STM, quando sono giù, in Sicilia, a rivedere un po' di colleghi e amici che ci lavorano. Francamente preferirei che a sfruttare certe idee fosse un'azienda nostrana anziché la solita multinazionale americana. :fagiano:
Certamente non ho intenzione di lasciare tutta quella roba nel mio cassetto. Ho diverse cosucce interessanti, e voglio sfruttarle. Per cui mi muoverò in tal senso fra un po' di mesi, dopo che mi sarò ambientato qui alla BMW.
quando prenderai servizio nel nuovo posto?
2 Gennaio.
coi proci intel non è possibile ciò , ma non sappiamo come andranno tutte quelle funzionalità annunciate da amd. magari sfruttando "un modulo" o soli 4 core , potrebbe far meglio dei 7700k , per via della maggiore superfice di contatto.
Al momento sembra che abbia soltanto un design da 8 core. Quando però ricordo di aver letto, in passato, di un design nativo da 4 core. Boh.
Sempre e solo se questa situazione fosse veritiera , le conviene far una guerra sui prezzi ,perchè azzerebbe la richiesta dei proci 4core intel, altrimenti come hai ben detto tu nel lungo periodo non riuscirebbe a reggere. Perchè le parole di lisa su parlavano di rivoluzione del mercato pc , che ormai è stagnato , altrimenti che rivoluzione sarebbe? nessuna se non nell'ambito economico, visto solo come un abbassamento dei prezzi.
Le mie molto probabilmente saranno sogni/deliri o come li vogliam chiamare :D però una minima possibilità c'è . Poi io coi pc son un pò avanti col pensiero , nel senso che già dai pentium-2 i miei pc gestiscono 2 thread ;) come così nel 2000 volevo passare la scheda grafica alle macchine virtuali , ero in anticipo solo di 10 anni tecnologicamente XD e possiam dire 13 se calcoliamo il software
Non è delirio. Personalmente lo trovo più un wishful thinking.
Come ha scritto digieffe negli commenti, e con cui sono d'accordo, parliamo pur sempre di aziende votate al massimo profitto.
Non ha senso realizzare un buon prodotto e venderlo a prezzi stracciati, quando il valore di mercato (che è ciò che conta) è un altro.
Poi, che dire: aspettiamo e vediamo. Ma io la penso così.
Ti auguro una buona chiusura del rapporto lavorativo e un buon inizio nel nuovo lavoro ;)
Grazie! :)
P.S.
Il termine Onlus è comparso da molto prima delle persone attuali nel TH... quindi non faccio polemica specifica verso una persona.
Tranquillo, Paolo: richiamare Onlus in quel contesto è un comunissimo modo di dire. ;)
Sul thread su anand gli avevano contestato che aveva provato con un dual xeon, che aveva troppi core, che era numa e blablabla.
Ora con un quadcore ottiene gli stessi risultati (per l'IPC calcolato di Zen).
Avrà anche sottostimato l'IPC di ivybridge (perchè ha molti core, è 2p ecc) ma non ha sbagliato sull'IPC di Zen perchè il suo software conta le istruzioni, da cui si possono ricavare le istruzioni totali, che sono le stesse di Zen (la versione ufficiale di blender non fa schedulazione separata a seconda della cpu)
Quindi ragionevolmente ha coperto tutto lo spettro. Comunque sta cercando di procurarsi broadwell, skylake più potenti e kabilake...
Ma infatti quel metodo l'avevo già descritto nei miei scontri con gli altri (fra cui Dresdenboy) su AnandTech.
Non è il metodo di per sé a essere sbagliato (d'altra parte, come lo calcoli l'IPC, se non così), ma la piattaforma che ha utilizzato che era sbagliata. E vedo che gli hanno fatto le stesse critiche che ti ho sollevato pure io qui. :p
C'è solo un appunto sul resto: lui non ha Zen, e non sa quante istruzioni siano state effettivamente eseguite. Per cui penso che abbia usato quelle eseguite sui processori Intel. Personalmente mi aspetto differenze assolutamente trascurabili fra Zen e i processori Intel, ma questo lo preciso.
Buona giornata a tutti.
Beh si, è chiaro che si risparmia solo con le microcodificate... :D Per le altre non serve... :D
Ricordavo di questa statistica. Ma ci sono le istruzioni di context switch, bound check, stack frame management e altre per virtualizzazione che sono sicuramente microcodificate. Non credo che siano poi così rare...
Invece sono molto rare. :D
Quelle di bound check e di stack manipulation, poi, non le usa praticamente nessuno, perché sono troppo lente.
Infatti il prologue delle funzioni utilizza delle normale istruzioni di PUSH/MOV/SUB, mentre l'epilogue usa la LEAVE, che però non è microdificata.
Mentre per il bound check Intel ha tirato fuori un'estensione completamente nuova: MPX. Proprio perché nessuna usava la BOUND, che così com'era non era tanto utile.
Riguardo a context switch e virtualizzazione, devi contestualizzare: in un secondo = 3-4 miliardi di cicli di clock, QUANTE volte vengono utilizzate? Pochissime volte. E ogni volta COME vengono utilizzate? One shot: una volta eseguite, non servono più, perché non vengono eseguite in un ciclo, e dunque "cacharle" (brutto termine. :stordita:) non serve assolutamente.
E poi le DIV e sqrt sono sicuramente microcodificate visto la latenza e se vedi anche in blender non è che siano così rare... Sospetto che questo sia anche uno dei motivi per cui performa bene...
Se, come penso, una istruzione microcodificata non blocca più il decoder, questo è un grosso vantaggio. Penso sempre a blender: se hai una (F)DIV in un ciclo, quando non c'era la uop cache, tu avevi che a ogni ciclo la DIV (microcodificata) ti bloccava i decoder (e non penso che bastassero 4 uops).
E invece no: FDIV/FSQRT per la vecchia FPU e (V)DIV*/ (V)SQRT* non sono affatto microcodificate (su Steamroller; penso che per Zen sarà la stessa cosa). :D
Non confondere latenza (quella è elevata, senz'altro) con numero di uop necessarie per eseguire l'istruzione. :)
Se ti scorri il manuale delle ottimizzazioni di Agner, vedrai tu stesso che la microcodifica c'è in tante istruzioni, ma sono veramente rare... SE vengono usate nel codice. Perché dubito che i compilatori le usino tutte; secondo me alcune nemmeno vengono mai emesse. ;)
Con la uop cache ma senza questo trucco, il decoder ti viene bloccato solo la prima volta, ma consumi molto spazio nella uop cache per le uop della divisione.
Per la divisione, come già detto. Per quelle realmente microcodificate, è corretto.
Con questo meccanismo occupi un solo slot (dovrebbe bastare, non credo che la rom sia così grande da richiedere un puntatore enorme) ed hai una unità separata dal decoder che ti spara le uop: questo è maggiore pipelining e sospetto che contribuisca ulteriormente ad abbassare il FO4, perchè hai sgravato lo stadio di decoding dal compito di sparare le uop, risparmiando anche un muxer a valle dei decoder per muxare tra le uop dai decoder e quelle dalla microcode rom...
Questo succede anche con le (micro)architetture Intel: le uop delle istruzioni microcodificate non vengono generate dal decoder, ma da un'apposita sezione che si ricongiunge poi alla micro-op cache. Il design di Zen è molto simile a quello Intel (praticamente identico a prima vista).
Ma non so se Intel usa il trucchetto del puntatore alla uop. Questa potrebbe essere l'unica differenza sostanziale (ad alto livello, ovviamente).
Zen ha il partizionamento statico in SMT per la(le?) retire queue. Se sono separate come sembra, 2+2 per thread mi sembra un po' poco, sopratutto per gestire un picco. Lui ha esplicitamente detto a voce che sono così grandi per gestire il picco. 4+4 per thread mi sembra ragionevole. E poi così le voci di uno Zen+ con SMT4 acquistano ancora più consistenza. Se vedi in quel video, all'inizio c'è la presentazione di skylake, poi il power9 e poi Zen. Il power9 per SMT 4 non è che abbia poi tutte ste pipe in più anche dello zen attuale. Anzi forse meno. E da bench che girano in rete, solo in SMT 8 il guadagno è irrisorio. Ma da SMT2 a SMT4 c'è ancora un po' di succo da spremere. E se non mi sbaglio il power9 può ritirare 8 uop/ciclo...
Che non sono 16. ;)
Come già detto, 8+8 sono veramente troppe, a fronte del throughput del backend. E questo anche tenendo conto di eventuali limiti di partizionamento dovuti all'esecuzione di due thread.
Esatto, ma quell'architettura con quei path non sfrutterebbe le possibilità offerte dal nuovo pp, ma consentirebbe una riduzione di area / consumo relativa alla sola derivazione fisica del processo.
Mi spiego meglio:
l'architettura core è stata studiata per i 45nm ed ottimizzata per essa.
il passaggio a 32 nm ha avuto una revisione ed un adattamento che ne ha aumentato l'ipc e la frequenza (quest'ultima relativa) ed un leggero abbassamento del consumo medio a parità di frequenza.
Stessa cosa per i pp successivi fino al 16+ che ha portato un aumento del consumo limitato a fronte di un aumento delle frequenze leggermente maggiore (ed ipc pressochè immutato rispetto al 16 liscio).
Quello che dico non è che l'architettura core è diventata ineffeciente con il passaggio a pp inferiori, ma che un'architettura ex novo avrebbe permesso sicuramente di sfruttare meglio il pp (come nel 45-32 nm) e permesso di ottenere una cpu più efficiente.
Insomma un 6950 10 core gflop X a 140w avrebbe potuto essere un 7950 10 core gflop X in 110w ( insomma sfruttare meglio il pp con un'architettura fatta su misura per esso).
Un poco come ha fatto ibm con Power ed i tanto discussi 32 nm, oppure Amd con zen (e credo che siamo d'accordo nel definire il 16 intel migliore del 14 gf ) che in soli 95w dovrebbe (il condizionale è d'obbligo) offrire prestazioni per watt migliori del 6900x
Cerco di capirti, ma onestamente non capisco perché per sfruttare i benefici di un nuovo processo produttivo si dovrebbe sviluppare un'architettura ex-novo.
Non penso che con Zen AMD abbia buttato tutto quello fatto finora, e ricominciato da zero, reinventandosi la ruota per ogni cosa. Sono convinto che utilizzi molto dei vecchi processori, con alcune parti riprogettate, ovviamente.
Per essere chiari, se devo implementare una certa funzionalità, e ho già a disposizione un circuito che la implementa ottimamente, perché dovrei riprogettarlo da capo?
Con le (micro)architetture è così: si cambia se se ne ravvisa la necessità. Se prendi Skylake, ad esempio, tante cose sono cambiate rispetto ai predecessori, pur mantenendo un design di massima che è abbastanza consolidato.
Intel potrebbe anche progettare una (micro)architettura completamente nuova, certamente, ma questo lo potrebbe fare a prescindere dal processo produttivo.
IBM con POWER e i 32nm non ha assolutamente cambiato la microarchitettura. Tutt'altro. Ha aumentato moltissimo la cache L3 e ritoccato la virtualizzazione, ma tutto il resto è rimasto esattamente così com'è. Diciamo che passando da Haswell a Broadwell (22nm -> 14nm), Intel ha fatto di gran lunga più cambiamenti. ;)
PS hai portato i cleanex dietro?
Beh, in certe occasioni mi stavano proprio scappando qualche lacrima, ma ho cercato di contenermi. Per me rimane un duro colpo.
In bocca al lupo ed i migliori auguri per un futuro pieno di soddisfazioni (e magari tra 2 anni ti ritrovi a lavorare per AMD ;) )
Grazie. Speriamo bene, perché non so come sarà il nuovo lavoro.
Sì, non è certo escluso che possa anche lavorare per AMD in futuro. Se costruisse una sede qui a Ulm. :D Oppure se accettasse il lavoro da remoto, con alcuni viaggetti alla sede centrale ogni tanto. Perché Intel l'ho lasciata per non dovermi spostare a Monaco (i bambini sono troppo piccoli: non voglio altri traumi, dopo quello mostruoso dello spostamento dall'Italia a qui). :fagiano:
Sono un professionista e non metto dei paletti a prescindere. Ad esempio lavoro spesso con Windows, ma alla BMW dovrò mettere le mani per lo più su Linux. Non per questo ho deciso di non accettare la posizione lavorativa. Andrò avanti lo stesso, e mi farò un nuovo background / bagaglio culturale.
Certo, lavorare per un'azienda che produce o progetta processori è stato un sogno che ho realizzato, e che non mi dispiacerebbe riprendere. Sono 5 anni che lavoro a una mia architettura, che potrebbe fare molto comodo in diversi ambiti. In realtà, a parte l'embedded economico (chip da pochi centinaia di migliaia di transistor), si presta bene per qualunque cosa. Dunque si potrebbe anche usare per le future console, per cominciare in un settore dove il legacy non è indispensabile. HPC... server... pure.
E' tutta roba dove il legacy non serve, o si può comunque aggirare, e dove le prestazioni (nonché la densità di codice) della mia architettura potrebbe fare la differenza rispetto a Intel, ARM, e POWER.
Per cui... vedremo. Anche perché mi spuntano ogni tanto idee che si potrebbero tradurre in brevetti, e mi servirà qualche azienda a cui appoggiarmi per farlo. Però stavo pensando di rifare un salto all'STM, quando sono giù, in Sicilia, a rivedere un po' di colleghi e amici che ci lavorano. Francamente preferirei che a sfruttare certe idee fosse un'azienda nostrana anziché la solita multinazionale americana. :fagiano:
Certamente non ho intenzione di lasciare tutta quella roba nel mio cassetto. Ho diverse cosucce interessanti, e voglio sfruttarle. Per cui mi muoverò in tal senso fra un po' di mesi, dopo che mi sarò ambientato qui alla BMW.
quando prenderai servizio nel nuovo posto?
2 Gennaio.
coi proci intel non è possibile ciò , ma non sappiamo come andranno tutte quelle funzionalità annunciate da amd. magari sfruttando "un modulo" o soli 4 core , potrebbe far meglio dei 7700k , per via della maggiore superfice di contatto.
Al momento sembra che abbia soltanto un design da 8 core. Quando però ricordo di aver letto, in passato, di un design nativo da 4 core. Boh.
Sempre e solo se questa situazione fosse veritiera , le conviene far una guerra sui prezzi ,perchè azzerebbe la richiesta dei proci 4core intel, altrimenti come hai ben detto tu nel lungo periodo non riuscirebbe a reggere. Perchè le parole di lisa su parlavano di rivoluzione del mercato pc , che ormai è stagnato , altrimenti che rivoluzione sarebbe? nessuna se non nell'ambito economico, visto solo come un abbassamento dei prezzi.
Le mie molto probabilmente saranno sogni/deliri o come li vogliam chiamare :D però una minima possibilità c'è . Poi io coi pc son un pò avanti col pensiero , nel senso che già dai pentium-2 i miei pc gestiscono 2 thread ;) come così nel 2000 volevo passare la scheda grafica alle macchine virtuali , ero in anticipo solo di 10 anni tecnologicamente XD e possiam dire 13 se calcoliamo il software
Non è delirio. Personalmente lo trovo più un wishful thinking.
Come ha scritto digieffe negli commenti, e con cui sono d'accordo, parliamo pur sempre di aziende votate al massimo profitto.
Non ha senso realizzare un buon prodotto e venderlo a prezzi stracciati, quando il valore di mercato (che è ciò che conta) è un altro.
Poi, che dire: aspettiamo e vediamo. Ma io la penso così.
Ti auguro una buona chiusura del rapporto lavorativo e un buon inizio nel nuovo lavoro ;)
Grazie! :)
P.S.
Il termine Onlus è comparso da molto prima delle persone attuali nel TH... quindi non faccio polemica specifica verso una persona.
Tranquillo, Paolo: richiamare Onlus in quel contesto è un comunissimo modo di dire. ;)
Sul thread su anand gli avevano contestato che aveva provato con un dual xeon, che aveva troppi core, che era numa e blablabla.
Ora con un quadcore ottiene gli stessi risultati (per l'IPC calcolato di Zen).
Avrà anche sottostimato l'IPC di ivybridge (perchè ha molti core, è 2p ecc) ma non ha sbagliato sull'IPC di Zen perchè il suo software conta le istruzioni, da cui si possono ricavare le istruzioni totali, che sono le stesse di Zen (la versione ufficiale di blender non fa schedulazione separata a seconda della cpu)
Quindi ragionevolmente ha coperto tutto lo spettro. Comunque sta cercando di procurarsi broadwell, skylake più potenti e kabilake...
Ma infatti quel metodo l'avevo già descritto nei miei scontri con gli altri (fra cui Dresdenboy) su AnandTech.
Non è il metodo di per sé a essere sbagliato (d'altra parte, come lo calcoli l'IPC, se non così), ma la piattaforma che ha utilizzato che era sbagliata. E vedo che gli hanno fatto le stesse critiche che ti ho sollevato pure io qui. :p
C'è solo un appunto sul resto: lui non ha Zen, e non sa quante istruzioni siano state effettivamente eseguite. Per cui penso che abbia usato quelle eseguite sui processori Intel. Personalmente mi aspetto differenze assolutamente trascurabili fra Zen e i processori Intel, ma questo lo preciso.
Buona giornata a tutti.
paolo.oliva2
23-12-2016, 07:48
Guardiamo i fatti, se BD fosse stato all'altezza anche con un silicio poco performante avrebbe detto la sua in diverse occasioni.
invece AMD ha perso quote di mercato e non hanno tirato a dadi per tornare su un approccio diverso dal CMT implementando finalmente l'SMT.
Poi non si dice che sia assolutamente scarso ma ha messo l'azienda nella condizioni di medio-sufficienza.
Questo va riconosciuto.
Io penso una cosa... che Intel ha vinto per un semplice motivo... perchè quando ha saputo che AMD vendeva le FAB, ha investito sul silicio.
Tuttodigitale riporta "Credo che in INTEL non siano dei sprovveduti se hanno investito (investono?) quanto TSMC, GLOFO, SAMSUNG e ST messi assieme....", perchè ha intuito che se hai un silicio performante, l'avversario può fare pure i miracoli architetturalmente, ma non ci caverebbe una tozza.
Io concordo che una architettura può essere più o meno efficiente rispetto ad un'altra, ma credo che l'indice prestazionale di architettura + silicio sia rappresentato dalla massima potenza a die in correlazione al TDP.
Il 65nm vedeva un Phenom I X4, il 45nm ha visto il Thuban X6 (+60% almeno), il 32nm ha visto l'8350 (+20% sul Thuban) e Zen vedrà +100% almeno sull'8350.
Io concordo al 1000000% che BD abbia contribuito a perdere nella potenza ST rispetto a qualsiasi altra architettura al suo posto, ma dobbiamo pure considerare che la massima potenza ST Intel l'ha grazie ai suoi core, indubbiamente, ma grazie al silicio ha consentito alla sua architettura di annullare le frequenze superiori di BD, e questo per certo ha contribuito ad aumentarla e far risaltare ancor più la pecca di BD.
Ma un Zen al posto di BD, sul 32nm, avrebbe concesso un X4+4 al posto di un 8350, ovvero una potenza ST superiore ma circa la stessa potenza MT. Zen non avrebbe mai concesso un 5960X sul 32nm.... la battaglia AMD l'avrebbe persa ugualmente, perchè avevqa perso la battaglia sul silicio... Un Zen X2+2 sicuramente sarebbe stato competitivo vs gli i3, ma sembra una fotocopia di BD, perchè alla fin fine, quando il silicio è sufficiente tanto da non limitare le prestazioni, pure BR (BD) non è che sia distante dagli i3.
invece AMD ha perso quote di mercato e non hanno tirato a dadi per tornare su un approccio diverso dal CMT implementando finalmente l'SMT.
Poi non si dice che sia assolutamente scarso ma ha messo l'azienda nella condizioni di medio-sufficienza.
Questo va riconosciuto.
Io penso una cosa... che Intel ha vinto per un semplice motivo... perchè quando ha saputo che AMD vendeva le FAB, ha investito sul silicio.
Tuttodigitale riporta "Credo che in INTEL non siano dei sprovveduti se hanno investito (investono?) quanto TSMC, GLOFO, SAMSUNG e ST messi assieme....", perchè ha intuito che se hai un silicio performante, l'avversario può fare pure i miracoli architetturalmente, ma non ci caverebbe una tozza.
Io concordo che una architettura può essere più o meno efficiente rispetto ad un'altra, ma credo che l'indice prestazionale di architettura + silicio sia rappresentato dalla massima potenza a die in correlazione al TDP.
Il 65nm vedeva un Phenom I X4, il 45nm ha visto il Thuban X6 (+60% almeno), il 32nm ha visto l'8350 (+20% sul Thuban) e Zen vedrà +100% almeno sull'8350.
Io concordo al 1000000% che BD abbia contribuito a perdere nella potenza ST rispetto a qualsiasi altra architettura al suo posto, ma dobbiamo pure considerare che la massima potenza ST Intel l'ha grazie ai suoi core, indubbiamente, ma grazie al silicio ha consentito alla sua architettura di annullare le frequenze superiori di BD, e questo per certo ha contribuito ad aumentarla e far risaltare ancor più la pecca di BD.
Ma un Zen al posto di BD, sul 32nm, avrebbe concesso un X4+4 al posto di un 8350, ovvero una potenza ST superiore ma circa la stessa potenza MT. Zen non avrebbe mai concesso un 5960X sul 32nm.... la battaglia AMD l'avrebbe persa ugualmente, perchè avevqa perso la battaglia sul silicio... Un Zen X2+2 sicuramente sarebbe stato competitivo vs gli i3, ma sembra una fotocopia di BD, perchè alla fin fine, quando il silicio è sufficiente tanto da non limitare le prestazioni, pure BR (BD) non è che sia distante dagli i3.
Phopho
23-12-2016, 08:09
Sul thread su anand gli avevano contestato che aveva provato con un dual xeon, che aveva troppi core, che era numa e blablabla.
Ora con un quadcore ottiene gli stessi risultati (per l'IPC calcolato di Zen).
Avrà anche sottostimato l'IPC di ivybridge (perchè ha molti core, è 2p ecc) ma non ha sbagliato sull'IPC di Zen perchè il suo software conta le istruzioni, da cui si possono ricavare le istruzioni totali, che sono le stesse di Zen (la versione ufficiale di blender non fa schedulazione separata a seconda della cpu)
Quindi ragionevolmente ha coperto tutto lo spettro. Comunque sta cercando di procurarsi broadwell, skylake più potenti e kabilake...
grazie per la spiegazione :D
Ora con un quadcore ottiene gli stessi risultati (per l'IPC calcolato di Zen).
Avrà anche sottostimato l'IPC di ivybridge (perchè ha molti core, è 2p ecc) ma non ha sbagliato sull'IPC di Zen perchè il suo software conta le istruzioni, da cui si possono ricavare le istruzioni totali, che sono le stesse di Zen (la versione ufficiale di blender non fa schedulazione separata a seconda della cpu)
Quindi ragionevolmente ha coperto tutto lo spettro. Comunque sta cercando di procurarsi broadwell, skylake più potenti e kabilake...
grazie per la spiegazione :D
bjt2
23-12-2016, 08:19
Non lo sono sicuramente, visto che continuano a investirci. E... si stanno muovendo... ma non posso dire altro.
Invece sono molto rare. :D
Quelle di bound check e di stack manipulation, poi, non le usa praticamente nessuno, perché sono troppo lente.
Infatti il prologue delle funzioni utilizza delle normale istruzioni di PUSH/MOV/SUB, mentre l'epilogue usa la LEAVE, che però non è microdificata.
Mentre per il bound check Intel ha tirato fuori un'estensione completamente nuova: MPX. Proprio perché nessuna usava la BOUND, che così com'era non era tanto utile.
Riguardo a context switch e virtualizzazione, devi contestualizzare: in un secondo = 3-4 miliardi di cicli di clock, QUANTE volte vengono utilizzate? Pochissime volte. E ogni volta COME vengono utilizzate? One shot: una volta eseguite, non servono più, perché non vengono eseguite in un ciclo, e dunque "cacharle" (brutto termine. :stordita:) non serve assolutamente.
In effetti il loro apporto è trascurabile...
E invece no: FDIV/FSQRT per la vecchia FPU e (V)DIV*/ (V)SQRT* non sono affatto microcodificate (su Steamroller; penso che per Zen sarà la stessa cosa). :D
Non confondere latenza (quella è elevata, senz'altro) con numero di uop necessarie per eseguire l'istruzione. :)
Se ti scorri il manuale delle ottimizzazioni di Agner, vedrai tu stesso che la microcodifica c'è in tante istruzioni, ma sono veramente rare... SE vengono usate nel codice. Perché dubito che i compilatori le usino tutte; secondo me alcune nemmeno vengono mai emesse. ;)
Per la divisione, come già detto. Per quelle realmente microcodificate, è corretto.
Buono a sapersi. Avevo pensato che fossero microcodificate sia perchè l'algoritmo è iterativo e al massimo si sentiva dire che era di tipo radix 16 (4 bit alla volta), sia perchè spesso non sono pipelined e bloccano la pipe per tutto il tempo di esecuzione... Meglio così... :) Si spera che prima o poi qualcuno le faccia fully pipelined (se sai qualcosa, ogni informazione è benvenuta... :) ).
BTW sembra che quelli di instxlat64 abbiano zen, perchè hanno fatto prove con AIDA per calcolare le latenze e dicono che sono tutte sbagliate quelle che avevano ipotizzato dalle patch di gcc... In arrivo il chart aggiornato: https://twitter.com/InstLatX64/status/812040863748685824 versione 1.5 con la colonna di Zen lasciata intenzionalmente bianca: https://twitter.com/InstLatX64/status/812000676373032966
Questo succede anche con le (micro)architetture Intel: le uop delle istruzioni microcodificate non vengono generate dal decoder, ma da un'apposita sezione che si ricongiunge poi alla micro-op cache. Il design di Zen è molto simile a quello Intel (praticamente identico a prima vista).
Ma non so se Intel usa il trucchetto del puntatore alla uop. Questa potrebbe essere l'unica differenza sostanziale (ad alto livello, ovviamente).
https://youtu.be/Ln9WKPEHm4w?t=17m56s Forse è troppo ad alto livello, ma in Zen tra il mux e la uop queue c'è lo stack memfile che filtra le operazioni e la microcode rom che invece le espande. Da questo diagramma invece sembra che l'architettura intel sia piuttosto standard e la microcode rom potrebbe stare vicino o subito dopo i decoder...
Che non sono 16. ;)
Come già detto, 8+8 sono veramente troppe, a fronte del throughput del backend. E questo anche tenendo conto di eventuali limiti di partizionamento dovuti all'esecuzione di due thread.
Può anche darsi che il tizio si sia espresso male.
Beh, in certe occasioni mi stavano proprio scappando qualche lacrima, ma ho cercato di contenermi. Per me rimane un duro colpo.
Grazie. Speriamo bene, perché non so come sarà il nuovo lavoro.
Sì, non è certo escluso che possa anche lavorare per AMD in futuro. Se costruisse una sede qui a Ulm. :D Oppure se accettasse il lavoro da remoto, con alcuni viaggetti alla sede centrale ogni tanto. Perché Intel l'ho lasciata per non dovermi spostare a Monaco (i bambini sono troppo piccoli: non voglio altri traumi, dopo quello mostruoso dello spostamento dall'Italia a qui). :fagiano:
In bocca al lupo per il tuo lavoro... Di cuore... :)
Sono un professionista e non metto dei paletti a prescindere. Ad esempio lavoro spesso con Windows, ma alla BMW dovrò mettere le mani per lo più su Linux. Non per questo ho deciso di non accettare la posizione lavorativa. Andrò avanti lo stesso, e mi farò un nuovo background / bagaglio culturale.
Certo, lavorare per un'azienda che produce o progetta processori è stato un sogno che ho realizzato, e che non mi dispiacerebbe riprendere. Sono 5 anni che lavoro a una mia architettura, che potrebbe fare molto comodo in diversi ambiti. In realtà, a parte l'embedded economico (chip da pochi centinaia di migliaia di transistor), si presta bene per qualunque cosa. Dunque si potrebbe anche usare per le future console, per cominciare in un settore dove il legacy non è indispensabile. HPC... server... pure.
E' tutta roba dove il legacy non serve, o si può comunque aggirare, e dove le prestazioni (nonché la densità di codice) della mia architettura potrebbe fare la differenza rispetto a Intel, ARM, e POWER.
E' anche il mio sogno, di progettare una CPU, ci penso spesso... :) Ti auguro di realizzarlo... :)
Anche io ho parecchie idee e una in particolare AMD finalmente l'ha realizzata, anche se in "scala ridotta". Sto parlando del PTE coalescing... In Zen 8 pagine contigue possono essere memorizzate in una sola TLB entry di pagina 4k, senza intervento del SO (ovviamente in memoria la page table non cambia). Io avevo pensato a una cosa senza limiti, ma 2 registri con pagina iniziale e finale in modo che il range potesse essere illimitato... Ma già una compressione 8:1 è notevole... :)
Per cui... vedremo. Anche perché mi spuntano ogni tanto idee che si potrebbero tradurre in brevetti, e mi servirà qualche azienda a cui appoggiarmi per farlo. Però stavo pensando di rifare un salto all'STM, quando sono giù, in Sicilia, a rivedere un po' di colleghi e amici che ci lavorano. Francamente preferirei che a sfruttare certe idee fosse un'azienda nostrana anziché la solita multinazionale americana. :fagiano:
Certamente non ho intenzione di lasciare tutta quella roba nel mio cassetto. Ho diverse cosucce interessanti, e voglio sfruttarle. Per cui mi muoverò in tal senso fra un po' di mesi, dopo che mi sarò ambientato qui alla BMW.
Ma STM non è stata acquisita e non è più italiana?
Ma infatti quel metodo l'avevo già descritto nei miei scontri con gli altri (fra cui Dresdenboy) su AnandTech.
Non è il metodo di per sé a essere sbagliato (d'altra parte, come lo calcoli l'IPC, se non così), ma la piattaforma che ha utilizzato che era sbagliata. E vedo che gli hanno fatto le stesse critiche che ti ho sollevato pure io qui. :p
C'è solo un appunto sul resto: lui non ha Zen, e non sa quante istruzioni siano state effettivamente eseguite. Per cui penso che abbia usato quelle eseguite sui processori Intel. Personalmente mi aspetto differenze assolutamente trascurabili fra Zen e i processori Intel, ma questo lo preciso.
Buona giornata a tutti.
Che io sappia blender non fa schedulazione sulla CPu, quindi il codice dovrebbe essere lo stesso...
Invece sono molto rare. :D
Quelle di bound check e di stack manipulation, poi, non le usa praticamente nessuno, perché sono troppo lente.
Infatti il prologue delle funzioni utilizza delle normale istruzioni di PUSH/MOV/SUB, mentre l'epilogue usa la LEAVE, che però non è microdificata.
Mentre per il bound check Intel ha tirato fuori un'estensione completamente nuova: MPX. Proprio perché nessuna usava la BOUND, che così com'era non era tanto utile.
Riguardo a context switch e virtualizzazione, devi contestualizzare: in un secondo = 3-4 miliardi di cicli di clock, QUANTE volte vengono utilizzate? Pochissime volte. E ogni volta COME vengono utilizzate? One shot: una volta eseguite, non servono più, perché non vengono eseguite in un ciclo, e dunque "cacharle" (brutto termine. :stordita:) non serve assolutamente.
In effetti il loro apporto è trascurabile...
E invece no: FDIV/FSQRT per la vecchia FPU e (V)DIV*/ (V)SQRT* non sono affatto microcodificate (su Steamroller; penso che per Zen sarà la stessa cosa). :D
Non confondere latenza (quella è elevata, senz'altro) con numero di uop necessarie per eseguire l'istruzione. :)
Se ti scorri il manuale delle ottimizzazioni di Agner, vedrai tu stesso che la microcodifica c'è in tante istruzioni, ma sono veramente rare... SE vengono usate nel codice. Perché dubito che i compilatori le usino tutte; secondo me alcune nemmeno vengono mai emesse. ;)
Per la divisione, come già detto. Per quelle realmente microcodificate, è corretto.
Buono a sapersi. Avevo pensato che fossero microcodificate sia perchè l'algoritmo è iterativo e al massimo si sentiva dire che era di tipo radix 16 (4 bit alla volta), sia perchè spesso non sono pipelined e bloccano la pipe per tutto il tempo di esecuzione... Meglio così... :) Si spera che prima o poi qualcuno le faccia fully pipelined (se sai qualcosa, ogni informazione è benvenuta... :) ).
BTW sembra che quelli di instxlat64 abbiano zen, perchè hanno fatto prove con AIDA per calcolare le latenze e dicono che sono tutte sbagliate quelle che avevano ipotizzato dalle patch di gcc... In arrivo il chart aggiornato: https://twitter.com/InstLatX64/status/812040863748685824 versione 1.5 con la colonna di Zen lasciata intenzionalmente bianca: https://twitter.com/InstLatX64/status/812000676373032966
Questo succede anche con le (micro)architetture Intel: le uop delle istruzioni microcodificate non vengono generate dal decoder, ma da un'apposita sezione che si ricongiunge poi alla micro-op cache. Il design di Zen è molto simile a quello Intel (praticamente identico a prima vista).
Ma non so se Intel usa il trucchetto del puntatore alla uop. Questa potrebbe essere l'unica differenza sostanziale (ad alto livello, ovviamente).
https://youtu.be/Ln9WKPEHm4w?t=17m56s Forse è troppo ad alto livello, ma in Zen tra il mux e la uop queue c'è lo stack memfile che filtra le operazioni e la microcode rom che invece le espande. Da questo diagramma invece sembra che l'architettura intel sia piuttosto standard e la microcode rom potrebbe stare vicino o subito dopo i decoder...
Che non sono 16. ;)
Come già detto, 8+8 sono veramente troppe, a fronte del throughput del backend. E questo anche tenendo conto di eventuali limiti di partizionamento dovuti all'esecuzione di due thread.
Può anche darsi che il tizio si sia espresso male.
Beh, in certe occasioni mi stavano proprio scappando qualche lacrima, ma ho cercato di contenermi. Per me rimane un duro colpo.
Grazie. Speriamo bene, perché non so come sarà il nuovo lavoro.
Sì, non è certo escluso che possa anche lavorare per AMD in futuro. Se costruisse una sede qui a Ulm. :D Oppure se accettasse il lavoro da remoto, con alcuni viaggetti alla sede centrale ogni tanto. Perché Intel l'ho lasciata per non dovermi spostare a Monaco (i bambini sono troppo piccoli: non voglio altri traumi, dopo quello mostruoso dello spostamento dall'Italia a qui). :fagiano:
In bocca al lupo per il tuo lavoro... Di cuore... :)
Sono un professionista e non metto dei paletti a prescindere. Ad esempio lavoro spesso con Windows, ma alla BMW dovrò mettere le mani per lo più su Linux. Non per questo ho deciso di non accettare la posizione lavorativa. Andrò avanti lo stesso, e mi farò un nuovo background / bagaglio culturale.
Certo, lavorare per un'azienda che produce o progetta processori è stato un sogno che ho realizzato, e che non mi dispiacerebbe riprendere. Sono 5 anni che lavoro a una mia architettura, che potrebbe fare molto comodo in diversi ambiti. In realtà, a parte l'embedded economico (chip da pochi centinaia di migliaia di transistor), si presta bene per qualunque cosa. Dunque si potrebbe anche usare per le future console, per cominciare in un settore dove il legacy non è indispensabile. HPC... server... pure.
E' tutta roba dove il legacy non serve, o si può comunque aggirare, e dove le prestazioni (nonché la densità di codice) della mia architettura potrebbe fare la differenza rispetto a Intel, ARM, e POWER.
E' anche il mio sogno, di progettare una CPU, ci penso spesso... :) Ti auguro di realizzarlo... :)
Anche io ho parecchie idee e una in particolare AMD finalmente l'ha realizzata, anche se in "scala ridotta". Sto parlando del PTE coalescing... In Zen 8 pagine contigue possono essere memorizzate in una sola TLB entry di pagina 4k, senza intervento del SO (ovviamente in memoria la page table non cambia). Io avevo pensato a una cosa senza limiti, ma 2 registri con pagina iniziale e finale in modo che il range potesse essere illimitato... Ma già una compressione 8:1 è notevole... :)
Per cui... vedremo. Anche perché mi spuntano ogni tanto idee che si potrebbero tradurre in brevetti, e mi servirà qualche azienda a cui appoggiarmi per farlo. Però stavo pensando di rifare un salto all'STM, quando sono giù, in Sicilia, a rivedere un po' di colleghi e amici che ci lavorano. Francamente preferirei che a sfruttare certe idee fosse un'azienda nostrana anziché la solita multinazionale americana. :fagiano:
Certamente non ho intenzione di lasciare tutta quella roba nel mio cassetto. Ho diverse cosucce interessanti, e voglio sfruttarle. Per cui mi muoverò in tal senso fra un po' di mesi, dopo che mi sarò ambientato qui alla BMW.
Ma STM non è stata acquisita e non è più italiana?
Ma infatti quel metodo l'avevo già descritto nei miei scontri con gli altri (fra cui Dresdenboy) su AnandTech.
Non è il metodo di per sé a essere sbagliato (d'altra parte, come lo calcoli l'IPC, se non così), ma la piattaforma che ha utilizzato che era sbagliata. E vedo che gli hanno fatto le stesse critiche che ti ho sollevato pure io qui. :p
C'è solo un appunto sul resto: lui non ha Zen, e non sa quante istruzioni siano state effettivamente eseguite. Per cui penso che abbia usato quelle eseguite sui processori Intel. Personalmente mi aspetto differenze assolutamente trascurabili fra Zen e i processori Intel, ma questo lo preciso.
Buona giornata a tutti.
Che io sappia blender non fa schedulazione sulla CPu, quindi il codice dovrebbe essere lo stesso...
bjt2
23-12-2016, 10:06
Invece sono molto rare. :D
Quelle di bound check e di stack manipulation, poi, non le usa praticamente nessuno, perché sono troppo lente.
Infatti il prologue delle funzioni utilizza delle normale istruzioni di PUSH/MOV/SUB, mentre l'epilogue usa la LEAVE, che però non è microdificata.
Mentre per il bound check Intel ha tirato fuori un'estensione completamente nuova: MPX. Proprio perché nessuna usava la BOUND, che così com'era non era tanto utile.
Riguardo a context switch e virtualizzazione, devi contestualizzare: in un secondo = 3-4 miliardi di cicli di clock, QUANTE volte vengono utilizzate? Pochissime volte. E ogni volta COME vengono utilizzate? One shot: una volta eseguite, non servono più, perché non vengono eseguite in un ciclo, e dunque "cacharle" (brutto termine. :stordita:) non serve assolutamente.
E invece no: FDIV/FSQRT per la vecchia FPU e (V)DIV*/ (V)SQRT* non sono affatto microcodificate (su Steamroller; penso che per Zen sarà la stessa cosa). :D
Non confondere latenza (quella è elevata, senz'altro) con numero di uop necessarie per eseguire l'istruzione. :)
Se ti scorri il manuale delle ottimizzazioni di Agner, vedrai tu stesso che la microcodifica c'è in tante istruzioni, ma sono veramente rare... SE vengono usate nel codice. Perché dubito che i compilatori le usino tutte; secondo me alcune nemmeno vengono mai emesse. ;)
Per la divisione, come già detto. Per quelle realmente microcodificate, è corretto.
Sono andato a scorrere il pdf di agner fog, alla sezione AMD più nuova (Steamroller).http://www.agner.org/optimize/instruction_tables.pdf
Effettivamente quasi tutte le DIV hanno 1 o 2 MOP, tranne la 8 e 16 bit che quindi è microcodificata. Le SQRT hanno più di 2 mop quindi anche queste lo sono. Alcune routine di push e pop (per i flag) che dovrebbero essere usate in tutte le ISR sono microcodificate, ma qui, ovviamente sono usate pochissimo, perchè le interruzioni non sono poi così frequenti.
Ci siamo scordati tre classi di istruzioni che possono non essere così rare e che sono microcodificate: le istruzioni di locking (per tutti i semafori, quindi usate spesso nel SO ma anche in codice utente, se multitasking/threading), le istruzioni di crittografia, usate spesso nei software a cui serve (quindi penso a VPN, driver del file system nel caso sia criptato, browser quando si usa l'https) e le istruzioni stringa. Se supponiamo che memcpy sia implementato con REP MOVxx, allora potrebbe essere anche usata spesso. E avere in uop cache solo il placeholder alla routine potrebbe essere vantaggioso...
Quelle di bound check e di stack manipulation, poi, non le usa praticamente nessuno, perché sono troppo lente.
Infatti il prologue delle funzioni utilizza delle normale istruzioni di PUSH/MOV/SUB, mentre l'epilogue usa la LEAVE, che però non è microdificata.
Mentre per il bound check Intel ha tirato fuori un'estensione completamente nuova: MPX. Proprio perché nessuna usava la BOUND, che così com'era non era tanto utile.
Riguardo a context switch e virtualizzazione, devi contestualizzare: in un secondo = 3-4 miliardi di cicli di clock, QUANTE volte vengono utilizzate? Pochissime volte. E ogni volta COME vengono utilizzate? One shot: una volta eseguite, non servono più, perché non vengono eseguite in un ciclo, e dunque "cacharle" (brutto termine. :stordita:) non serve assolutamente.
E invece no: FDIV/FSQRT per la vecchia FPU e (V)DIV*/ (V)SQRT* non sono affatto microcodificate (su Steamroller; penso che per Zen sarà la stessa cosa). :D
Non confondere latenza (quella è elevata, senz'altro) con numero di uop necessarie per eseguire l'istruzione. :)
Se ti scorri il manuale delle ottimizzazioni di Agner, vedrai tu stesso che la microcodifica c'è in tante istruzioni, ma sono veramente rare... SE vengono usate nel codice. Perché dubito che i compilatori le usino tutte; secondo me alcune nemmeno vengono mai emesse. ;)
Per la divisione, come già detto. Per quelle realmente microcodificate, è corretto.
Sono andato a scorrere il pdf di agner fog, alla sezione AMD più nuova (Steamroller).http://www.agner.org/optimize/instruction_tables.pdf
Effettivamente quasi tutte le DIV hanno 1 o 2 MOP, tranne la 8 e 16 bit che quindi è microcodificata. Le SQRT hanno più di 2 mop quindi anche queste lo sono. Alcune routine di push e pop (per i flag) che dovrebbero essere usate in tutte le ISR sono microcodificate, ma qui, ovviamente sono usate pochissimo, perchè le interruzioni non sono poi così frequenti.
Ci siamo scordati tre classi di istruzioni che possono non essere così rare e che sono microcodificate: le istruzioni di locking (per tutti i semafori, quindi usate spesso nel SO ma anche in codice utente, se multitasking/threading), le istruzioni di crittografia, usate spesso nei software a cui serve (quindi penso a VPN, driver del file system nel caso sia criptato, browser quando si usa l'https) e le istruzioni stringa. Se supponiamo che memcpy sia implementato con REP MOVxx, allora potrebbe essere anche usata spesso. E avere in uop cache solo il placeholder alla routine potrebbe essere vantaggioso...
george_p
23-12-2016, 10:46
sarebbe stato davvero strano NON passare da QUATTRO implementazioni parziali del SMT, ad una cpu con SMT anche lato integer (anche se come fatto notare da Cesare anche la parte integer, beneficia dal CMT con carico scarsamente parallelizzabile).
Semmai non era logico passare al SMT2, ma direttamente ad un più esotico SMT2+CMT (4thread sulla fpu) o addirittura SMT4...anche li avranno ragionato..e non è detto che ZEN non debba svilupparsi in tal senso se le AVX-256, prenderanno piede (ma perchè dubitarne?)
Non lo so, pare che le cpu con SMT2, ma anche 8-vie debbano avere un ipc relativamente alto, dimenticandosi per strada che il P4 era con il SMT e conroe no..
sul fatto che BD, non sembrerebbe affatto un progetto troppo spinto lato frequenza sui 32nm SOI ce l'ha fatto notare CESARE, facendo l'esempio di IBM che ha migliorato le prestazioni per watt di brutto con una cpu da oltre 5GHz....
quel silicio, a livello di leakage rassomiglia più i finfet che non i bulk planari....
la differenza tra propus e agena pare insignificante
http://www.anandtech.com/bench/product/106?vs=21
direi soprattutto
2,6GHz@140W ->3,7GHz@125W
con la stessa frequenza del phenom 9950 (2,6GHz), su 45nm AMD proponeva Opteron a 8 core con TDP da 115W...credo che non ci sia bisogno di commentare.
@george_p
se BD/PD fosse stata una pessima architettura, quale è il motivo che ha spinto AMD a cancellare un'architettura che sembrava in grado di lottare praticamente sullo stesso piano di quella INTEL nel mercato data-center, come k10, che non avrà chissà quale ipc, ma consumava niente nei confronti di Nehalem a parità di clock con i 45nm...
il fatto che per quanto una architettura possa essere buona con un silicio che ti soffoca le prestazioni sul nascere, c'è poco da fare...Credo che in INTEL non siano dei sprovveduti se hanno investito (investono?) quanto TSMC, GLOFO, SAMSUNG e ST messi assieme....
i 32nm per certi versi rassomigliano e molto i 65nm SOI..
Nessuno se non la sola AMD ha le informazioni più corrispondenti alla verità ... Ipotizzo che amd non avesse (in effetti non li aveva) liquidi sufficienti per spingere sul miglioramento del silicio 32 soi come pare abbia fatto IBM che in fatto di liquidi "inonda" la prima.
Se hai i soldi riesci a fare tutto anche su un processo che apparentemente e inizialmente può sembrare poco buono, se i soldi non ce li hai ti appendi da qualche parte.
Penso sia un buon elemento per capire la differenza tra lo stesso silicio usato per IBM e quello usato per AMD.
CHe ne dici/dite?
BD mancava di sufficiente IPC figuriamoci di buon IPC visto che per definirlo buono doveva essere 25% sopra l'architettura precedente e non 25% sotto, per non parlare che sempre rispetto a quella precedente perdeva anche in MT un ulteriore 10% (recuperato solo con Kaveri), per cui già sappiamo che per recuperare in prestazioni aveva bisogno di frequenze elevate.
Il resto è storia per mancanza di buon silicio, vuoi che sia stata amd incapace vuoi che non abbia avuto i soldi per migliorarlo (anche se son dell'idea che spetterebbe alla fabbrica di turno investirci sopra).
Per quanto riguarda Zen e SMT1/2/4 non so che risponderti poiché non sono minimamente informato, aspetto di vedere i risultati su strada come per BD.
Semmai non era logico passare al SMT2, ma direttamente ad un più esotico SMT2+CMT (4thread sulla fpu) o addirittura SMT4...anche li avranno ragionato..e non è detto che ZEN non debba svilupparsi in tal senso se le AVX-256, prenderanno piede (ma perchè dubitarne?)
Non lo so, pare che le cpu con SMT2, ma anche 8-vie debbano avere un ipc relativamente alto, dimenticandosi per strada che il P4 era con il SMT e conroe no..
sul fatto che BD, non sembrerebbe affatto un progetto troppo spinto lato frequenza sui 32nm SOI ce l'ha fatto notare CESARE, facendo l'esempio di IBM che ha migliorato le prestazioni per watt di brutto con una cpu da oltre 5GHz....
quel silicio, a livello di leakage rassomiglia più i finfet che non i bulk planari....
la differenza tra propus e agena pare insignificante
http://www.anandtech.com/bench/product/106?vs=21
direi soprattutto
2,6GHz@140W ->3,7GHz@125W
con la stessa frequenza del phenom 9950 (2,6GHz), su 45nm AMD proponeva Opteron a 8 core con TDP da 115W...credo che non ci sia bisogno di commentare.
@george_p
se BD/PD fosse stata una pessima architettura, quale è il motivo che ha spinto AMD a cancellare un'architettura che sembrava in grado di lottare praticamente sullo stesso piano di quella INTEL nel mercato data-center, come k10, che non avrà chissà quale ipc, ma consumava niente nei confronti di Nehalem a parità di clock con i 45nm...
il fatto che per quanto una architettura possa essere buona con un silicio che ti soffoca le prestazioni sul nascere, c'è poco da fare...Credo che in INTEL non siano dei sprovveduti se hanno investito (investono?) quanto TSMC, GLOFO, SAMSUNG e ST messi assieme....
i 32nm per certi versi rassomigliano e molto i 65nm SOI..
Nessuno se non la sola AMD ha le informazioni più corrispondenti alla verità ... Ipotizzo che amd non avesse (in effetti non li aveva) liquidi sufficienti per spingere sul miglioramento del silicio 32 soi come pare abbia fatto IBM che in fatto di liquidi "inonda" la prima.
Se hai i soldi riesci a fare tutto anche su un processo che apparentemente e inizialmente può sembrare poco buono, se i soldi non ce li hai ti appendi da qualche parte.
Penso sia un buon elemento per capire la differenza tra lo stesso silicio usato per IBM e quello usato per AMD.
CHe ne dici/dite?
BD mancava di sufficiente IPC figuriamoci di buon IPC visto che per definirlo buono doveva essere 25% sopra l'architettura precedente e non 25% sotto, per non parlare che sempre rispetto a quella precedente perdeva anche in MT un ulteriore 10% (recuperato solo con Kaveri), per cui già sappiamo che per recuperare in prestazioni aveva bisogno di frequenze elevate.
Il resto è storia per mancanza di buon silicio, vuoi che sia stata amd incapace vuoi che non abbia avuto i soldi per migliorarlo (anche se son dell'idea che spetterebbe alla fabbrica di turno investirci sopra).
Per quanto riguarda Zen e SMT1/2/4 non so che risponderti poiché non sono minimamente informato, aspetto di vedere i risultati su strada come per BD.
bomkill
23-12-2016, 11:14
ho perso il post con il quale spiegavo una possibile logica dei prezzi, sintetizzo al max, spero si capisca
SE il top dovesse andare in media più del 6900k:
Zen top 1001$ (8c, più potente del 8c intel e più costoso)
Zen 2° 600$ (8c, più potente del 6 top intel, stesso prezzo)
Zen 3° 450$ (6/8c più potente del 6 2° intel, stesso prezzo)
Zen 4° 350$ (6c, più potente in MT, vicino in ST, al 4c top intel stesso prezzo)
BD 9xxx vs i5
SR vs i3
gmail
Se cosi fosse specie Zen Amd non venderebbe una beata fava le persone non stanno aspettando Zen per spendere poco meno se devo spendere poco meno scelgo intel (anche per ripicca) Se amd vuole vendere deve esordire con un i5 a 150€ un i7 da 220 e un i7 E da 350.
SE il top dovesse andare in media più del 6900k:
Zen top 1001$ (8c, più potente del 8c intel e più costoso)
Zen 2° 600$ (8c, più potente del 6 top intel, stesso prezzo)
Zen 3° 450$ (6/8c più potente del 6 2° intel, stesso prezzo)
Zen 4° 350$ (6c, più potente in MT, vicino in ST, al 4c top intel stesso prezzo)
BD 9xxx vs i5
SR vs i3
gmail
Se cosi fosse specie Zen Amd non venderebbe una beata fava le persone non stanno aspettando Zen per spendere poco meno se devo spendere poco meno scelgo intel (anche per ripicca) Se amd vuole vendere deve esordire con un i5 a 150€ un i7 da 220 e un i7 E da 350.
Gioz
23-12-2016, 11:24
gmail
Se cosi fosse specie Zen Amd non venderebbe una beata fava le persone non stanno aspettando Zen per spendere poco meno se devo spendere poco meno scelgo intel (anche per ripicca) Se amd vuole vendere deve esordire con un i5 a 150€ un i7 da 220 e un i7 E da 350.
mi sembra veramente troppo ottimistica come aspettativa lato consumatore, è come aspettarsi che la dacia fatta un'automobile di livello lamborghini aventador e te la venda a 90mila euro. poi tutto può essere, ma per aggressività sui prezzi non mi sembra plausibile una spesa del 30% per un prodotto simile.
se poi avrai avuto ragione ne sarò sicuramente felice :D
Se cosi fosse specie Zen Amd non venderebbe una beata fava le persone non stanno aspettando Zen per spendere poco meno se devo spendere poco meno scelgo intel (anche per ripicca) Se amd vuole vendere deve esordire con un i5 a 150€ un i7 da 220 e un i7 E da 350.
mi sembra veramente troppo ottimistica come aspettativa lato consumatore, è come aspettarsi che la dacia fatta un'automobile di livello lamborghini aventador e te la venda a 90mila euro. poi tutto può essere, ma per aggressività sui prezzi non mi sembra plausibile una spesa del 30% per un prodotto simile.
se poi avrai avuto ragione ne sarò sicuramente felice :D
.Hellraiser.
23-12-2016, 11:29
gmail
Se cosi fosse specie Zen Amd non venderebbe una beata fava le persone non stanno aspettando Zen per spendere poco meno se devo spendere poco meno scelgo intel (anche per ripicca)
non è detto, io se amd facesse un'ottima cpu la comprerei pure se costasse più di intel, se le prestazioni ci sono non capisco che problema ci sarebbe a meno di non essere proprio legati ad un marchio piuttosto che all'altro (dando per scontato che la piattaforma sia almeno equivalente come funzionalità)
Se cosi fosse specie Zen Amd non venderebbe una beata fava le persone non stanno aspettando Zen per spendere poco meno se devo spendere poco meno scelgo intel (anche per ripicca)
non è detto, io se amd facesse un'ottima cpu la comprerei pure se costasse più di intel, se le prestazioni ci sono non capisco che problema ci sarebbe a meno di non essere proprio legati ad un marchio piuttosto che all'altro (dando per scontato che la piattaforma sia almeno equivalente come funzionalità)
capitan_crasy
23-12-2016, 11:55
Niente più che rumors/speculazioni del tutto non confermate. E il fatto che entro fine anno vogliano presentare Raven Ridge mi fa pensare che un design nativo 4c sia quello da inserire nel progetto APU, non da proporre come CPU, anche perché vorrebbe dire fare una sovrapposizione di prodotto francamente del tutto inutile.
Esistono dei codici OPN di CPU ES ZEN a 4 core; che siano di derivazione degli 8 core oppure dei quad core nativi per ora non si sa (personalmente credo che siano nativi)...
Raven Ridge dovrebbe essere pronto a 2017 inoltrato (credo verso la fine del 2017) e ad oggi esistono i primi sample funzionanti, ma siamo sono all'inizio...
Esistono dei codici OPN di CPU ES ZEN a 4 core; che siano di derivazione degli 8 core oppure dei quad core nativi per ora non si sa (personalmente credo che siano nativi)...
Raven Ridge dovrebbe essere pronto a 2017 inoltrato (credo verso la fine del 2017) e ad oggi esistono i primi sample funzionanti, ma siamo sono all'inizio...
bjt2
23-12-2016, 12:09
BTW sembra che quelli di instxlat64 abbiano zen, perchè hanno fatto prove con AIDA per calcolare le latenze e dicono che sono tutte sbagliate quelle che avevano ipotizzato dalle patch di gcc... In arrivo il chart aggiornato: https://twitter.com/InstLatX64/status/812040863748685824 versione 1.5 con la colonna di Zen lasciata intenzionalmente bianca: https://twitter.com/InstLatX64/status/812000676373032966
Mi quoto, perchè forse in mezzo alle risposte tecniche a cdmauro, qualcuno non l'ha notato... Non volevo fare due post, ma purtroppo a volte è necessario...
Mi quoto, perchè forse in mezzo alle risposte tecniche a cdmauro, qualcuno non l'ha notato... Non volevo fare due post, ma purtroppo a volte è necessario...
bomkill
23-12-2016, 12:18
mi sembra veramente troppo ottimistica come aspettativa lato consumatore, è come aspettarsi che la dacia fatta un'automobile di livello lamborghini aventador e te la venda a 90mila euro. poi tutto può essere, ma per aggressività sui prezzi non mi sembra plausibile una spesa del 30% per un prodotto simile.
se poi avrai avuto ragione ne sarò sicuramente felice :D
Sia chiaro parlo da consumatore io mi accontenterei di uno Zen 4+4 che in st pareggi gli i5 e in mt sia in zona i7 base sui 200/250 max.
Qualcuno nel forum saprà sicuramente la verità ma non potrà dirlo,vedo diversi frequentatori troppo tecnici per essere semplici appassionati.
Comunque spero che Amd dipani al più presto il mistero , e da 1 anno che ho dato via il mio pc principale in attesa di Zen( o intel se Zen non sarà all'altezza).
se poi avrai avuto ragione ne sarò sicuramente felice :D
Sia chiaro parlo da consumatore io mi accontenterei di uno Zen 4+4 che in st pareggi gli i5 e in mt sia in zona i7 base sui 200/250 max.
Qualcuno nel forum saprà sicuramente la verità ma non potrà dirlo,vedo diversi frequentatori troppo tecnici per essere semplici appassionati.
Comunque spero che Amd dipani al più presto il mistero , e da 1 anno che ho dato via il mio pc principale in attesa di Zen( o intel se Zen non sarà all'altezza).
Roland74Fun
23-12-2016, 12:20
ho perso il post con il quale spiegavo una possibile logica dei prezzi, sintetizzo al max, spero si capisca
SE il top dovesse andare in media più del 6900k:
Zen top 1001$ (8c, più potente del 8c intel e più costoso)
Zen 2° 600$ (8c, più potente del 6 top intel, stesso prezzo)
Zen 3° 450$ (6/8c più potente del 6 2° intel, stesso prezzo)
Zen 4° 350$ (6c, più potente in MT, vicino in ST, al 4c top intel stesso prezzo)
BD 9xxx vs i5
SR vs i3
Potrebbero darli in regalo colle patatine, od allegarli eventualmete a Famiglia Cristiana a 4.90€ più il prezzo della rivista. :cool: :cool:
SE il top dovesse andare in media più del 6900k:
Zen top 1001$ (8c, più potente del 8c intel e più costoso)
Zen 2° 600$ (8c, più potente del 6 top intel, stesso prezzo)
Zen 3° 450$ (6/8c più potente del 6 2° intel, stesso prezzo)
Zen 4° 350$ (6c, più potente in MT, vicino in ST, al 4c top intel stesso prezzo)
BD 9xxx vs i5
SR vs i3
Potrebbero darli in regalo colle patatine, od allegarli eventualmete a Famiglia Cristiana a 4.90€ più il prezzo della rivista. :cool: :cool:
Grizlod®
23-12-2016, 12:45
Mi quoto, perchè forse in mezzo alle risposte tecniche a cdmauro, qualcuno non l'ha notato... Non volevo fare due post, ma purtroppo a volte è necessario...Sembra abbiano un sample di quelli apparsi su Geekbench 4 quest'estate (quindi non ultimissima revisione).
Dal grafico (interpretazione personale) sembra sia sprovvisto di AVX 512, in quanto hanno messo un trattino (-), tanto come in µop-cache ed L3 size per Excavator e Bristol Ridge, non lasciando il campo in blanc.
Dal grafico (interpretazione personale) sembra sia sprovvisto di AVX 512, in quanto hanno messo un trattino (-), tanto come in µop-cache ed L3 size per Excavator e Bristol Ridge, non lasciando il campo in blanc.
digieffe
23-12-2016, 13:31
Io penso una cosa... che Intel ha vinto per un semplice motivo... perchè quando ha saputo che AMD vendeva le FAB, ha investito sul silicio.
Tuttodigitale riporta "Credo che in INTEL non siano dei sprovveduti se hanno investito (investono?) quanto TSMC, GLOFO, SAMSUNG e ST messi assieme....", perchè ha intuito che se hai un silicio performante, l'avversario può fare pure i miracoli architetturalmente, ma non ci caverebbe una tozza.
Io concordo che una architettura può essere più o meno efficiente rispetto ad un'altra, ma credo che l'indice prestazionale di architettura + silicio sia rappresentato dalla massima potenza a die in correlazione al TDP.
Il 65nm vedeva un Phenom I X4, il 45nm ha visto il Thuban X6 (+60% almeno), il 32nm ha visto l'8350 (+20% sul Thuban) e Zen vedrà +100% almeno sull'8350.
Io concordo al 1000000% che BD abbia contribuito a perdere nella potenza ST rispetto a qualsiasi altra architettura al suo posto, ma dobbiamo pure considerare che la massima potenza ST Intel l'ha grazie ai suoi core, indubbiamente, ma grazie al silicio ha consentito alla sua architettura di annullare le frequenze superiori di BD, e questo per certo ha contribuito ad aumentarla e far risaltare ancor più la pecca di BD.
Ma un Zen al posto di BD, sul 32nm, avrebbe concesso un X4+4 al posto di un 8350, ovvero una potenza ST superiore ma circa la stessa potenza MT. Zen non avrebbe mai concesso un 5960X sul 32nm.... la battaglia AMD l'avrebbe persa ugualmente, perchè avevqa perso la battaglia sul silicio... Un Zen X2+2 sicuramente sarebbe stato competitivo vs gli i3, ma sembra una fotocopia di BD, perchè alla fin fine, quando il silicio è sufficiente tanto da non limitare le prestazioni, pure BR (BD) non è che sia distante dagli i3.
secondo me ti sbagli ampiamente, un zen x8 a 3.0ghz freq base nei 140w ci sarebbe stato benissimo, potendo competere col 5960x, oppure mi stai dicendo che il 14mnm attuale consente un risparmio di consumi maggiore di 2x.
Tuttodigitale riporta "Credo che in INTEL non siano dei sprovveduti se hanno investito (investono?) quanto TSMC, GLOFO, SAMSUNG e ST messi assieme....", perchè ha intuito che se hai un silicio performante, l'avversario può fare pure i miracoli architetturalmente, ma non ci caverebbe una tozza.
Io concordo che una architettura può essere più o meno efficiente rispetto ad un'altra, ma credo che l'indice prestazionale di architettura + silicio sia rappresentato dalla massima potenza a die in correlazione al TDP.
Il 65nm vedeva un Phenom I X4, il 45nm ha visto il Thuban X6 (+60% almeno), il 32nm ha visto l'8350 (+20% sul Thuban) e Zen vedrà +100% almeno sull'8350.
Io concordo al 1000000% che BD abbia contribuito a perdere nella potenza ST rispetto a qualsiasi altra architettura al suo posto, ma dobbiamo pure considerare che la massima potenza ST Intel l'ha grazie ai suoi core, indubbiamente, ma grazie al silicio ha consentito alla sua architettura di annullare le frequenze superiori di BD, e questo per certo ha contribuito ad aumentarla e far risaltare ancor più la pecca di BD.
Ma un Zen al posto di BD, sul 32nm, avrebbe concesso un X4+4 al posto di un 8350, ovvero una potenza ST superiore ma circa la stessa potenza MT. Zen non avrebbe mai concesso un 5960X sul 32nm.... la battaglia AMD l'avrebbe persa ugualmente, perchè avevqa perso la battaglia sul silicio... Un Zen X2+2 sicuramente sarebbe stato competitivo vs gli i3, ma sembra una fotocopia di BD, perchè alla fin fine, quando il silicio è sufficiente tanto da non limitare le prestazioni, pure BR (BD) non è che sia distante dagli i3.
secondo me ti sbagli ampiamente, un zen x8 a 3.0ghz freq base nei 140w ci sarebbe stato benissimo, potendo competere col 5960x, oppure mi stai dicendo che il 14mnm attuale consente un risparmio di consumi maggiore di 2x.
george_p
23-12-2016, 13:35
Mi quoto, perchè forse in mezzo alle risposte tecniche a cdmauro, qualcuno non l'ha notato... Non volevo fare due post, ma purtroppo a volte è necessario...
...che significa...?
Sia chiaro parlo da consumatore io mi accontenterei di uno Zen 4+4 che in st pareggi gli i5 e in mt sia in zona i7 base sui 200/250 max.
Ma quando si parla di un prodotto realizzato da una azienda non si può ragionare come un consumatore. O per lo meno confrontare sempre due posizioni differenti.
Perché anche a me farebbe piacere il tuo punto di vista ma se vado a vedere i costi di una azienda per fare arrivare il prodotto finale a me vedo che il prezzo del singolo bene aumenta durante il percorso dall'azienda a casa mia.
Qualcuno nel forum saprà sicuramente la verità ma non potrà dirlo,vedo diversi frequentatori troppo tecnici per essere semplici appassionati.
Comunque spero che Amd dipani al più presto il mistero , e da 1 anno che ho dato via il mio pc principale in attesa di Zen( o intel se Zen non sarà all'altezza).
Verità, questa sconosciuta.
Solo gli addetti ai lavori di Zen sanno la verità e aggiungo forse, non certo i più preparati tecnici che frequentano questo e altri forums. Perché se così fosse non esisterebbero chilometri di parole per formulare il proprio punto di vista su cosa sia Zen.
...che significa...?
Sia chiaro parlo da consumatore io mi accontenterei di uno Zen 4+4 che in st pareggi gli i5 e in mt sia in zona i7 base sui 200/250 max.
Ma quando si parla di un prodotto realizzato da una azienda non si può ragionare come un consumatore. O per lo meno confrontare sempre due posizioni differenti.
Perché anche a me farebbe piacere il tuo punto di vista ma se vado a vedere i costi di una azienda per fare arrivare il prodotto finale a me vedo che il prezzo del singolo bene aumenta durante il percorso dall'azienda a casa mia.
Qualcuno nel forum saprà sicuramente la verità ma non potrà dirlo,vedo diversi frequentatori troppo tecnici per essere semplici appassionati.
Comunque spero che Amd dipani al più presto il mistero , e da 1 anno che ho dato via il mio pc principale in attesa di Zen( o intel se Zen non sarà all'altezza).
Verità, questa sconosciuta.
Solo gli addetti ai lavori di Zen sanno la verità e aggiungo forse, non certo i più preparati tecnici che frequentano questo e altri forums. Perché se così fosse non esisterebbero chilometri di parole per formulare il proprio punto di vista su cosa sia Zen.
george_p
23-12-2016, 13:43
Ma un Zen al posto di BD, sul 32nm, avrebbe concesso un X4+4 al posto di un 8350, ovvero una potenza ST superiore ma circa la stessa potenza MT. Zen non avrebbe mai concesso un 5960X sul 32nm.... la battaglia AMD l'avrebbe persa ugualmente, perchè avevqa perso la battaglia sul silicio... Un Zen X2+2 sicuramente sarebbe stato competitivo vs gli i3, ma sembra una fotocopia di BD, perchè alla fin fine, quando il silicio è sufficiente tanto da non limitare le prestazioni, pure BR (BD) non è che sia distante dagli i3.
Premettendo che tanto è realtà che non vedremo mai e quindi possiamo solo ipotizzare, la penso in modo diverso.
Ok, forse sul 32nm Zen 8+8 non ci sarebbe stato ma almeno 6+6 si però, visti i minori consumi rispetto all'architettura modulare CMT. E avrebbe dato ampio respiro ad amd per competere con intel.
Ma tanto questa è pura fantasia no? In primis perché Zen nasce dalla "cattiva" condotta del ceo che ha pure progettato BD, quindi senza quell'esperienza in casa AMD non ci sarebbe stato Zen.
Ma poi, perché costruire ogni volta tutte ste storie sul Se, sul Ma e sul Però?
Ma aspettiamo sto benedetto Zen, ormai manca davvero poco.
secondo me ti sbagli ampiamente, un zen x8 a 3.0ghz freq base nei 140w ci sarebbe stato benissimo, potendo competere col 5960x, oppure mi stai dicendo che il 14mnm attuale consente un risparmio di consumi maggiore di 2x.
Anche questo non è da scartare infatti.
Premettendo che tanto è realtà che non vedremo mai e quindi possiamo solo ipotizzare, la penso in modo diverso.
Ok, forse sul 32nm Zen 8+8 non ci sarebbe stato ma almeno 6+6 si però, visti i minori consumi rispetto all'architettura modulare CMT. E avrebbe dato ampio respiro ad amd per competere con intel.
Ma tanto questa è pura fantasia no? In primis perché Zen nasce dalla "cattiva" condotta del ceo che ha pure progettato BD, quindi senza quell'esperienza in casa AMD non ci sarebbe stato Zen.
Ma poi, perché costruire ogni volta tutte ste storie sul Se, sul Ma e sul Però?
Ma aspettiamo sto benedetto Zen, ormai manca davvero poco.
secondo me ti sbagli ampiamente, un zen x8 a 3.0ghz freq base nei 140w ci sarebbe stato benissimo, potendo competere col 5960x, oppure mi stai dicendo che il 14mnm attuale consente un risparmio di consumi maggiore di 2x.
Anche questo non è da scartare infatti.
Ren
23-12-2016, 13:57
secondo me ti sbagli ampiamente, un zen x8 a 3.0ghz freq base nei 140w ci sarebbe stato benissimo, potendo competere col 5960x, oppure mi stai dicendo che il 14mnm attuale consente un risparmio di consumi maggiore di 2x.
Se c'è riuscito pure il sandy bridge (Xeon 32nm)...;)
Se c'è riuscito pure il sandy bridge (Xeon 32nm)...;)
bjt2
23-12-2016, 14:17
...che significa...?
Che ora che hanno un ES, invece di fare ipotesi, possono misurare latenze, throughputs e altre cose della CPU, in modo da farci una migliore idea di lunghezza pipeline, FO4, capacità delle pipelines ecc...
Che ora che hanno un ES, invece di fare ipotesi, possono misurare latenze, throughputs e altre cose della CPU, in modo da farci una migliore idea di lunghezza pipeline, FO4, capacità delle pipelines ecc...
Emaximus
23-12-2016, 14:42
Link al thread di overclock.net:
http://www.overclock.net/t/1619110/cpc-first-unofficial-ryzen-benchmarks
AMD 2D3151A2M88E
ES 8C/16T
3.15 Ghz Stock
3.30 Ghz Turbo su tutti i core
3.50 Ghz Turbo su singolo core
https://s27.postimg.org/slq98up4j/8a14207f_a115_4534_b6bd_c7801085ca42.jpg
latenze e throughput delle istruzioni:
https://d1rktuf34l9h2g.cloudfront.net/f/f2/f2d6be0c_7053d10c-8a51-420d-b92f-aff4b9d1a487.jpeg
Canard PC Hardware (magazine francese)
https://twitter.com/CPCHardware/status/811883423371526144
http://www.overclock.net/t/1619110/cpc-first-unofficial-ryzen-benchmarks
AMD 2D3151A2M88E
ES 8C/16T
3.15 Ghz Stock
3.30 Ghz Turbo su tutti i core
3.50 Ghz Turbo su singolo core
https://s27.postimg.org/slq98up4j/8a14207f_a115_4534_b6bd_c7801085ca42.jpg
latenze e throughput delle istruzioni:
https://d1rktuf34l9h2g.cloudfront.net/f/f2/f2d6be0c_7053d10c-8a51-420d-b92f-aff4b9d1a487.jpeg
Canard PC Hardware (magazine francese)
https://twitter.com/CPCHardware/status/811883423371526144
bjt2
23-12-2016, 15:05
Preview Ryzen
http://www.overclock.net/t/1619110/cpc-first-unofficial-ryzen-benchmarks
ES 8C/16T 3.15 Ghz / 3.30 Ghz Turbo su tutti i core / 3.5 Ghz Turbo su singolo core
https://s27.postimg.org/slq98up4j/8a14207f_a115_4534_b6bd_c7801085ca42.jpg
latenze e throughput delle istruzioni:
https://d1rktuf34l9h2g.cloudfront.net/f/f2/f2d6be0c_7053d10c-8a51-420d-b92f-aff4b9d1a487.jpeg
Fonte: CanardPc Hardware (magazine francese)
https://twitter.com/CPCHardware/status/811883423371526144
Se ho capito bene, gli ES 4 core sono 3.8 base, 4 all core e 4.2 max turbo... Non male per un ES vecchio... Se si ha lo stesso incremento dell'8 core tra ES e finale, possiamo aspettarci 4.1-4.2 base e turbo almeno a 4.5, come kabylake...
Questi grafici sono per un ES di 3.15 base. Con 3.5 base, i risultati dovrebbero essere migliori...
http://www.overclock.net/t/1619110/cpc-first-unofficial-ryzen-benchmarks
ES 8C/16T 3.15 Ghz / 3.30 Ghz Turbo su tutti i core / 3.5 Ghz Turbo su singolo core
https://s27.postimg.org/slq98up4j/8a14207f_a115_4534_b6bd_c7801085ca42.jpg
latenze e throughput delle istruzioni:
https://d1rktuf34l9h2g.cloudfront.net/f/f2/f2d6be0c_7053d10c-8a51-420d-b92f-aff4b9d1a487.jpeg
Fonte: CanardPc Hardware (magazine francese)
https://twitter.com/CPCHardware/status/811883423371526144
Se ho capito bene, gli ES 4 core sono 3.8 base, 4 all core e 4.2 max turbo... Non male per un ES vecchio... Se si ha lo stesso incremento dell'8 core tra ES e finale, possiamo aspettarci 4.1-4.2 base e turbo almeno a 4.5, come kabylake...
Questi grafici sono per un ES di 3.15 base. Con 3.5 base, i risultati dovrebbero essere migliori...
Ryddyck
23-12-2016, 15:05
Finalmente mezzo benchmark, mi procuro la rivista va ;)
digieffe
23-12-2016, 15:22
Link al thread di overclock.net:
http://www.overclock.net/t/1619110/cpc-first-unofficial-ryzen-benchmarks
AMD 2D3151A2M88E
ES 8C/16T
3.15 Ghz Stock
3.30 Ghz Turbo su tutti i core
3.50 Ghz Turbo su singolo core
https://s27.postimg.org/slq98up4j/8a14207f_a115_4534_b6bd_c7801085ca42.jpg
latenze e throughput delle istruzioni:
https://d1rktuf34l9h2g.cloudfront.net/f/f2/f2d6be0c_7053d10c-8a51-420d-b92f-aff4b9d1a487.jpeg
Canard PC Hardware (magazine francese)
https://twitter.com/CPCHardware/status/811883423371526144
come immaginabile -6..-10% di throughput a parità di frequenza...
http://www.overclock.net/t/1619110/cpc-first-unofficial-ryzen-benchmarks
AMD 2D3151A2M88E
ES 8C/16T
3.15 Ghz Stock
3.30 Ghz Turbo su tutti i core
3.50 Ghz Turbo su singolo core
https://s27.postimg.org/slq98up4j/8a14207f_a115_4534_b6bd_c7801085ca42.jpg
latenze e throughput delle istruzioni:
https://d1rktuf34l9h2g.cloudfront.net/f/f2/f2d6be0c_7053d10c-8a51-420d-b92f-aff4b9d1a487.jpeg
Canard PC Hardware (magazine francese)
https://twitter.com/CPCHardware/status/811883423371526144
come immaginabile -6..-10% di throughput a parità di frequenza...
Ren
23-12-2016, 15:33
Ottimo sta sotto solo del 10%. Sono pari come consumi, speravo meglio.
Intel ha ancora alcune carte da giocare, dato che broadwell è sfigato come propensione al clock. Vedremo se il distacco con SkylakeX e silicio 14nm+ aumenterà.
Secondo me la variante 4core consumerà più di kabylake (clock to clock).
Peccato che il silicio 14nm SOI sia esclusiva di IBM...
Intel ha ancora alcune carte da giocare, dato che broadwell è sfigato come propensione al clock. Vedremo se il distacco con SkylakeX e silicio 14nm+ aumenterà.
Secondo me la variante 4core consumerà più di kabylake (clock to clock).
Peccato che il silicio 14nm SOI sia esclusiva di IBM...
Roland74Fun
23-12-2016, 15:35
Ma di cosa state a parlare?
Avranno rilevanza per il pubblico queste cose?
Proprio oggi all'ora di pranzo sul pullman per tornare dal lavoro, vicino a me parlavano due ragazzotti di seconda o terza superiore.
Uno ha detto:
"Il ragazzo di mia sorella si è preso in offerta al madiawalk un PC i7, e c'ha pure la scheda GT! ora tutti i giochi gli vanno appalla!!!"
E'altro.
"Secondo me ha sbagliato. Ho letto su internet che stanno per uscire dei nuovi computer dei cinesi, mi pare si chiamino ZED o forse... ZEN, che dovrebbero andare al doppio dell'i7 e costare la metà!".... :eek: :eek:
Ecco il livello!
E voi state a farvi le pippe sul soi e sul bulk.....:muro: :muro:
Avranno rilevanza per il pubblico queste cose?
Proprio oggi all'ora di pranzo sul pullman per tornare dal lavoro, vicino a me parlavano due ragazzotti di seconda o terza superiore.
Uno ha detto:
"Il ragazzo di mia sorella si è preso in offerta al madiawalk un PC i7, e c'ha pure la scheda GT! ora tutti i giochi gli vanno appalla!!!"
E'altro.
"Secondo me ha sbagliato. Ho letto su internet che stanno per uscire dei nuovi computer dei cinesi, mi pare si chiamino ZED o forse... ZEN, che dovrebbero andare al doppio dell'i7 e costare la metà!".... :eek: :eek:
Ecco il livello!
E voi state a farvi le pippe sul soi e sul bulk.....:muro: :muro:
Ren
23-12-2016, 15:47
Ma di cosa state a parlare?
Avranno rilevanza per il pubblico queste cose?
Proprio oggi all'ora di pranzo sul pullman per tornare dal lavoro, vicino a me parlavano due ragazzotti di di seconda o terza superiore.
Uno ha detto:
"Il ragazzo di mia sorella si è preso in offerta al madiawalk un PC i7, e c'ha pure la scheda GT! ora tutti i giochi gli vanno appalla!!!"
E'altro.
"Secondo me ha sbagliato. Ho letto su internet che stanno per uscire dei nuovi computer dei cinesi, mi pare si chiamino ZED o forse... ZEN, che dovrebbero andare al doppio dell'i7 e costare la metà!".... :eek: :eek:
Ecco il livello!
E voi state a farvi le pippe sul soi e sul bulk.....:muro: :muro:
Ancora ti meravigli di queste cose...:sofico:
C'est la vie.:)
cmq AMD deve spaccare nei server prima di tutto...
Avranno rilevanza per il pubblico queste cose?
Proprio oggi all'ora di pranzo sul pullman per tornare dal lavoro, vicino a me parlavano due ragazzotti di di seconda o terza superiore.
Uno ha detto:
"Il ragazzo di mia sorella si è preso in offerta al madiawalk un PC i7, e c'ha pure la scheda GT! ora tutti i giochi gli vanno appalla!!!"
E'altro.
"Secondo me ha sbagliato. Ho letto su internet che stanno per uscire dei nuovi computer dei cinesi, mi pare si chiamino ZED o forse... ZEN, che dovrebbero andare al doppio dell'i7 e costare la metà!".... :eek: :eek:
Ecco il livello!
E voi state a farvi le pippe sul soi e sul bulk.....:muro: :muro:
Ancora ti meravigli di queste cose...:sofico:
C'est la vie.:)
cmq AMD deve spaccare nei server prima di tutto...
Pozhar
23-12-2016, 15:49
La gt 710 da 4gb che va meglio di una gtx 1060 da 3 gb?
Roba seria... :asd:
ecco come ragionano... :asd:
Roba seria... :asd:
ecco come ragionano... :asd:
Ren
23-12-2016, 15:54
La gt 710 da 4gb che va meglio di una gtx 1060 da 3 gb?
Roba seria... :asd:
ecco come ragionano... :asd:
Certo che va meglio, ha 4GB...:asd:
Roba seria... :asd:
ecco come ragionano... :asd:
Certo che va meglio, ha 4GB...:asd:
feldvonmanstein
23-12-2016, 15:56
salve, qualcuno sa identificare la data di produzione dell'8370e ?
https://bcz4nq.bl3302.livefilestore.com/y3mIi_qti21b0TizWwBLRBKJ1LeRbMkpgW3JpBsdBkeNqQ-uQW94-5mohfGnFVwINCGN3e99PorDH7XafVZWvIewXtTpYcVHlMyJgZaIm8n93ApuEtmmHo5EL5UHC_e5HCAcBKTK2Q_BoYTvqcK4ebgT_Vk6a3cdF-pgVLQbFQtFok/WP_20161223_12_31_52_Pro.jpg?psid=1
https://bcz4nq.bl3302.livefilestore.com/y3mIi_qti21b0TizWwBLRBKJ1LeRbMkpgW3JpBsdBkeNqQ-uQW94-5mohfGnFVwINCGN3e99PorDH7XafVZWvIewXtTpYcVHlMyJgZaIm8n93ApuEtmmHo5EL5UHC_e5HCAcBKTK2Q_BoYTvqcK4ebgT_Vk6a3cdF-pgVLQbFQtFok/WP_20161223_12_31_52_Pro.jpg?psid=1
fatantony
23-12-2016, 15:56
Ma di cosa state a parlare?
Avranno rilevanza per il pubblico queste cose?
Proprio oggi all'ora di pranzo sul pullman per tornare dal lavoro, vicino a me parlavano due ragazzotti di di seconda o terza superiore.
Uno ha detto:
"Il ragazzo di mia sorella si è preso in offerta al madiawalk un PC i7, e c'ha pure la scheda GT! ora tutti i giochi gli vanno appalla!!!"
E'altro.
"Secondo me ha sbagliato. Ho letto su internet che stanno per uscire dei nuovi computer dei cinesi, mi pare si chiamino ZED o forse... ZEN, che dovrebbero andare al doppio dell'i7 e costare la metà!".... :eek: :eek:
Ecco il livello!
E voi state a farvi le pippe sul soi e sul bulk.....:muro: :muro:
Ahah! mi hai fatto rotolare dalle risate! :D
Quello che a me "preoccupa" di più è quando queste "dinamiche" (mi hanno detto, ho sentito, ho letto su internet, blabla) vengono applicate in campi un po' più "seri" dell'informatica...:doh:
Comunque MENO MALE che esistono posti come questo, in cui si discute (anche troppo, a volte) seriamente... Anche di SOI e Bulk :D
Avranno rilevanza per il pubblico queste cose?
Proprio oggi all'ora di pranzo sul pullman per tornare dal lavoro, vicino a me parlavano due ragazzotti di di seconda o terza superiore.
Uno ha detto:
"Il ragazzo di mia sorella si è preso in offerta al madiawalk un PC i7, e c'ha pure la scheda GT! ora tutti i giochi gli vanno appalla!!!"
E'altro.
"Secondo me ha sbagliato. Ho letto su internet che stanno per uscire dei nuovi computer dei cinesi, mi pare si chiamino ZED o forse... ZEN, che dovrebbero andare al doppio dell'i7 e costare la metà!".... :eek: :eek:
Ecco il livello!
E voi state a farvi le pippe sul soi e sul bulk.....:muro: :muro:
Ahah! mi hai fatto rotolare dalle risate! :D
Quello che a me "preoccupa" di più è quando queste "dinamiche" (mi hanno detto, ho sentito, ho letto su internet, blabla) vengono applicate in campi un po' più "seri" dell'informatica...:doh:
Comunque MENO MALE che esistono posti come questo, in cui si discute (anche troppo, a volte) seriamente... Anche di SOI e Bulk :D
Ren
23-12-2016, 16:23
dopotutto i miracoli non esistono :D
si ma anche non fosse esclusiva, quando sarà pronto? si diceva 2018 o peggio, in pratica assieme ai 10nm...
Sempre detto :fagiano: , ma qua è pieno di sognatori...:sofico:
Il power9 è dato per 2H/2017.
Una bella padella da 24core/120mb di L3...:eek:
si ma anche non fosse esclusiva, quando sarà pronto? si diceva 2018 o peggio, in pratica assieme ai 10nm...
Sempre detto :fagiano: , ma qua è pieno di sognatori...:sofico:
Il power9 è dato per 2H/2017.
Una bella padella da 24core/120mb di L3...:eek:
tuttodigitale
23-12-2016, 16:44
il fatto che ZEN x8 a 3GHz competa con il 5960x è tuttora da dimostrare...l'ipc dichiarato da AMD dovrebbe quantomeno riportarci con i piedi per terra....
di buono sembrerebbe che un core ZEN consumi circa il 50-55% in più di un core XV a parità di silicio e frequenza, e questo potrebbe stare a significare che sia aumentata l'efficienza complessiva ANCHE nel multithread, anche se al massimo del 15% (che non sarebbe affatto poco, per un'architettura appena nata).
Tutto questo nell'ipotesi che ZEN consumi quanto XV che il silicio permetta di ridurre i consumi del 35% (le gpu hanno visto scendere i consumi del 50% a parità di clock), e che mediamente le prestazioni di un core ZEN siano pari a quello del singolo modulo XV.
Premettendo che tanto è realtà che non vedremo mai e quindi possiamo solo ipotizzare, la penso in modo diverso.
Ok, forse sul 32nm Zen 8+8 non ci sarebbe stato ma almeno 6+6 si però, visti i minori consumi rispetto all'architettura modulare CMT.
francamente questa non la capisco....
i core bulldozer sono come k10 piccoli molto piccoli, la metà di SB, oltre ad avere le pipeline più lunghe....c'è un motivo se AMD aveva dei quad core SR (KAVERI) da 2,1GHz base 19W vs dual core SB da 1,8GHz 17W....la "sfortuna" di AMD è che il 28nm bulk è nato quando Intel era già da tempo sui finfet...processo che ha permesso di guadagnare un ulteriore 30-40% di efficienza ad Intel..
il fatto che AMD non sia passato interamente alla produzione sul bulk potrebbe essere legata ai motivi contrattuali con GF (avevo letto qualcosa su bitsandchips)
di buono sembrerebbe che un core ZEN consumi circa il 50-55% in più di un core XV a parità di silicio e frequenza, e questo potrebbe stare a significare che sia aumentata l'efficienza complessiva ANCHE nel multithread, anche se al massimo del 15% (che non sarebbe affatto poco, per un'architettura appena nata).
Tutto questo nell'ipotesi che ZEN consumi quanto XV che il silicio permetta di ridurre i consumi del 35% (le gpu hanno visto scendere i consumi del 50% a parità di clock), e che mediamente le prestazioni di un core ZEN siano pari a quello del singolo modulo XV.
Premettendo che tanto è realtà che non vedremo mai e quindi possiamo solo ipotizzare, la penso in modo diverso.
Ok, forse sul 32nm Zen 8+8 non ci sarebbe stato ma almeno 6+6 si però, visti i minori consumi rispetto all'architettura modulare CMT.
francamente questa non la capisco....
i core bulldozer sono come k10 piccoli molto piccoli, la metà di SB, oltre ad avere le pipeline più lunghe....c'è un motivo se AMD aveva dei quad core SR (KAVERI) da 2,1GHz base 19W vs dual core SB da 1,8GHz 17W....la "sfortuna" di AMD è che il 28nm bulk è nato quando Intel era già da tempo sui finfet...processo che ha permesso di guadagnare un ulteriore 30-40% di efficienza ad Intel..
il fatto che AMD non sia passato interamente alla produzione sul bulk potrebbe essere legata ai motivi contrattuali con GF (avevo letto qualcosa su bitsandchips)
tuttodigitale
23-12-2016, 16:53
come immaginabile -6..-10% di throughput a parità di frequenza...
sembra dannatamente buono....
mi pare che le prestazioni siano in linea con le nostre previsioni....1 core+HT ZEN = 1 modulo XV
con gli inevitabili errori di scaling, le prestazioni di un ipotetico 16core XV da 3,15GHz è di 189 vs 169 di ZEN....direi che ci siamo.
sembra dannatamente buono....
mi pare che le prestazioni siano in linea con le nostre previsioni....1 core+HT ZEN = 1 modulo XV
con gli inevitabili errori di scaling, le prestazioni di un ipotetico 16core XV da 3,15GHz è di 189 vs 169 di ZEN....direi che ci siamo.
digieffe
23-12-2016, 17:08
se sarà confermato mi pare un buon risultato ed un ottimo punto di partenza su cui basare le revisioni future, ma mi affretterei a farlo uscire prima di Skylake per non dover calare troppo il prezzo al lancio se vogliono fare cassa.
in base ai grafici con dei conti un po' accurati
per pareggiare serve
freq. base 3.4-3.5
turbo all core 3.7
turbo single core 3.9
in base ai grafici con dei conti un po' accurati
per pareggiare serve
freq. base 3.4-3.5
turbo all core 3.7
turbo single core 3.9
suneatshours86
23-12-2016, 17:25
direi che siamo in linea con le aspettative più rosee :D se il turbo, sul quale rimane ancora qualche mistero sarà all'altezza amd avrà sostanzialmente pareggiato i conti :cool: ovviamente dando per scontato che i prezzi siano competitivi :read:
bjt2
23-12-2016, 17:37
il fatto che ZEN x8 a 3GHz competa con il 5960x è tuttora da dimostrare...l'ipc dichiarato da AMD dovrebbe quantomeno riportarci con i piedi per terra....
di buono sembrerebbe che un core ZEN consumi circa il 50-55% in più di un core XV a parità di silicio e frequenza, e questo potrebbe stare a significare che sia aumentata l'efficienza complessiva ANCHE nel multithread, anche se al massimo del 15% (che non sarebbe affatto poco, per un'architettura appena nata).
Tutto questo nell'ipotesi che ZEN consumi quanto XV che il silicio permetta di ridurre i consumi del 35% (le gpu hanno visto scendere i consumi del 50% a parità di clock), e che mediamente le prestazioni di un core ZEN siano pari a quello del singolo modulo XV.
francamente questa non la capisco....
i core bulldozer sono come k10 piccoli molto piccoli, la metà di SB, oltre ad avere le pipeline più lunghe....c'è un motivo se AMD aveva dei quad core SR (KAVERI) da 2,1GHz base 19W vs dual core SB da 1,8GHz 17W....la "sfortuna" di AMD è che il 28nm bulk è nato quando Intel era già da tempo sui finfet...processo che ha permesso di guadagnare un ulteriore 30-40% di efficienza ad Intel..
il fatto che AMD non sia passato interamente alla produzione sul bulk potrebbe essere legata ai motivi contrattuali con GF (avevo letto qualcosa su bitsandchips)
Le dichiarazioni di AMD sono di un core Zen che consuma quanto un core XV a parità di clock... Poichè un core XV non esiste, possiamo solo dedurre che 2 core zen consumano quanto un XV monomodulo, oppure un CCX Zen consuma quanto 2 moduli XV (quadcore). E vorrei ben vedere... Zen potrebbe consumare quanto un modulo XV già sul 28nm. Scendendo di 2 nodi e passando al finfet, si guadagna ben più del -50% (metà). In realtà polaris scende del 50% come consumo e contemporaneamente sale del 20% di clock. Ma evidentemente la complessità di Zen ha fatto si che ci si debba accontentare solo di metà consumo (1 core zen che consuma quanto mezzo modulo XV, che ad occhio sono più o meno gli stessi transistors...)
di buono sembrerebbe che un core ZEN consumi circa il 50-55% in più di un core XV a parità di silicio e frequenza, e questo potrebbe stare a significare che sia aumentata l'efficienza complessiva ANCHE nel multithread, anche se al massimo del 15% (che non sarebbe affatto poco, per un'architettura appena nata).
Tutto questo nell'ipotesi che ZEN consumi quanto XV che il silicio permetta di ridurre i consumi del 35% (le gpu hanno visto scendere i consumi del 50% a parità di clock), e che mediamente le prestazioni di un core ZEN siano pari a quello del singolo modulo XV.
francamente questa non la capisco....
i core bulldozer sono come k10 piccoli molto piccoli, la metà di SB, oltre ad avere le pipeline più lunghe....c'è un motivo se AMD aveva dei quad core SR (KAVERI) da 2,1GHz base 19W vs dual core SB da 1,8GHz 17W....la "sfortuna" di AMD è che il 28nm bulk è nato quando Intel era già da tempo sui finfet...processo che ha permesso di guadagnare un ulteriore 30-40% di efficienza ad Intel..
il fatto che AMD non sia passato interamente alla produzione sul bulk potrebbe essere legata ai motivi contrattuali con GF (avevo letto qualcosa su bitsandchips)
Le dichiarazioni di AMD sono di un core Zen che consuma quanto un core XV a parità di clock... Poichè un core XV non esiste, possiamo solo dedurre che 2 core zen consumano quanto un XV monomodulo, oppure un CCX Zen consuma quanto 2 moduli XV (quadcore). E vorrei ben vedere... Zen potrebbe consumare quanto un modulo XV già sul 28nm. Scendendo di 2 nodi e passando al finfet, si guadagna ben più del -50% (metà). In realtà polaris scende del 50% come consumo e contemporaneamente sale del 20% di clock. Ma evidentemente la complessità di Zen ha fatto si che ci si debba accontentare solo di metà consumo (1 core zen che consuma quanto mezzo modulo XV, che ad occhio sono più o meno gli stessi transistors...)
capitan_crasy
23-12-2016, 17:51
http://i.imgur.com/Sb6GAtZ.jpg
salve, qualcuno sa identificare la data di produzione dell'8370e ?
https://bcz4nq.bl3302.livefilestore.com/y3mIi_qti21b0TizWwBLRBKJ1LeRbMkpgW3JpBsdBkeNqQ-uQW94-5mohfGnFVwINCGN3e99PorDH7XafVZWvIewXtTpYcVHlMyJgZaIm8n93ApuEtmmHo5EL5UHC_e5HCAcBKTK2Q_BoYTvqcK4ebgT_Vk6a3cdF-pgVLQbFQtFok/WP_20161223_12_31_52_Pro.jpg?psid=1
Anno di produzione 2014, 32 settimana quello a sinistra; 2014, 34 settimana quello a destra...
salve, qualcuno sa identificare la data di produzione dell'8370e ?
https://bcz4nq.bl3302.livefilestore.com/y3mIi_qti21b0TizWwBLRBKJ1LeRbMkpgW3JpBsdBkeNqQ-uQW94-5mohfGnFVwINCGN3e99PorDH7XafVZWvIewXtTpYcVHlMyJgZaIm8n93ApuEtmmHo5EL5UHC_e5HCAcBKTK2Q_BoYTvqcK4ebgT_Vk6a3cdF-pgVLQbFQtFok/WP_20161223_12_31_52_Pro.jpg?psid=1
Anno di produzione 2014, 32 settimana quello a sinistra; 2014, 34 settimana quello a destra...
paolo.oliva2
23-12-2016, 17:51
secondo me ti sbagli ampiamente, un zen x8 a 3.0ghz freq base nei 140w ci sarebbe stato benissimo, potendo competere col 5960x, oppure mi stai dicendo che il 14mnm attuale consente un risparmio di consumi maggiore di 2x.
Qui si è detto che 1 modulo XV consuma quanto 1 core Zen
Quindi realizzare un X8+8 Zen è equivalente ad un XV X16, giusto?
Komodo era un X10, già in roadmap, ma AMD ha rinunciato a produrlo o è stata costretta a non produrlo?
Qui si è detto che 1 modulo XV consuma quanto 1 core Zen
Quindi realizzare un X8+8 Zen è equivalente ad un XV X16, giusto?
Komodo era un X10, già in roadmap, ma AMD ha rinunciato a produrlo o è stata costretta a non produrlo?
Free Gordon
23-12-2016, 17:55
in base ai grafici con dei conti un po' accurati
per pareggiare serve
freq. base 3.4-3.5
turbo all core 3.7
turbo single core 3.9
Imho con un PP più raffinato (speriamo in GF :D ), ce la possono anche fare a prendere quei clock in 100W. ;)
Sarebbe davvero bono..........:oink: :oink: :oink:
per pareggiare serve
freq. base 3.4-3.5
turbo all core 3.7
turbo single core 3.9
Imho con un PP più raffinato (speriamo in GF :D ), ce la possono anche fare a prendere quei clock in 100W. ;)
Sarebbe davvero bono..........:oink: :oink: :oink:
paolo.oliva2
23-12-2016, 18:06
in base ai grafici con dei conti un po' accurati
per pareggiare serve
freq. base 3.4-3.5
turbo all core 3.7
turbo single core 3.9
Io intando prendo per buono che in OC RS/DU Zen a @3,9GHz ci dovrebbe stare, e questo non mi sembra poco.
Per il fatto che mi sembra si era esposto -5/-10% in MT, ammesso e concesso che i bench siano veritieri, a Zen basterebbe un +5/+10% di clock.
Ora... sull'X4 mi sembra remota la cosa, ma su X8 vs 6900K, ci siamo, perchè a quei clock Zen avrebbe +9% di clock def, il turbo tutti i core non lo considero perchè bisognerebbe sapere il funzionamento, e 3,9GHz di frequenza massima sarebbe un +6% rispetto ai 3,7GHz massimi del 6900K... Cioè, Zen sarebbe alla pari al 6900K, non certo verso il 6850K.
per pareggiare serve
freq. base 3.4-3.5
turbo all core 3.7
turbo single core 3.9
Io intando prendo per buono che in OC RS/DU Zen a @3,9GHz ci dovrebbe stare, e questo non mi sembra poco.
Per il fatto che mi sembra si era esposto -5/-10% in MT, ammesso e concesso che i bench siano veritieri, a Zen basterebbe un +5/+10% di clock.
Ora... sull'X4 mi sembra remota la cosa, ma su X8 vs 6900K, ci siamo, perchè a quei clock Zen avrebbe +9% di clock def, il turbo tutti i core non lo considero perchè bisognerebbe sapere il funzionamento, e 3,9GHz di frequenza massima sarebbe un +6% rispetto ai 3,7GHz massimi del 6900K... Cioè, Zen sarebbe alla pari al 6900K, non certo verso il 6850K.
shellx
23-12-2016, 18:12
Ma di cosa state a parlare?
Avranno rilevanza per il pubblico queste cose?
Proprio oggi all'ora di pranzo sul pullman per tornare dal lavoro, vicino a me parlavano due ragazzotti di seconda o terza superiore.
Uno ha detto:
"Il ragazzo di mia sorella si è preso in offerta al madiawalk un PC i7, e c'ha pure la scheda GT! ora tutti i giochi gli vanno appalla!!!"
E'altro.
"Secondo me ha sbagliato. Ho letto su internet che stanno per uscire dei nuovi computer dei cinesi, mi pare si chiamino ZED o forse... ZEN, che dovrebbero andare al doppio dell'i7 e costare la metà!".... :eek: :eek:
Ecco il livello!
E voi state a farvi le pippe sul soi e sul bulk.....:muro: :muro:
E non potevi intervenire con un: "ehm scusate, siete due bimbi ignorantelli, approfondite prima cosa è amd e cosa intel in caso contrario compratevi una playstation (dove dentro c'è processore amd quello che voi chiamate cinese)" E te ne andavi con aria soddisfatta di aver umiliato e rovinato la giornata a due ragazzini. :D
Avranno rilevanza per il pubblico queste cose?
Proprio oggi all'ora di pranzo sul pullman per tornare dal lavoro, vicino a me parlavano due ragazzotti di seconda o terza superiore.
Uno ha detto:
"Il ragazzo di mia sorella si è preso in offerta al madiawalk un PC i7, e c'ha pure la scheda GT! ora tutti i giochi gli vanno appalla!!!"
E'altro.
"Secondo me ha sbagliato. Ho letto su internet che stanno per uscire dei nuovi computer dei cinesi, mi pare si chiamino ZED o forse... ZEN, che dovrebbero andare al doppio dell'i7 e costare la metà!".... :eek: :eek:
Ecco il livello!
E voi state a farvi le pippe sul soi e sul bulk.....:muro: :muro:
E non potevi intervenire con un: "ehm scusate, siete due bimbi ignorantelli, approfondite prima cosa è amd e cosa intel in caso contrario compratevi una playstation (dove dentro c'è processore amd quello che voi chiamate cinese)" E te ne andavi con aria soddisfatta di aver umiliato e rovinato la giornata a due ragazzini. :D
digieffe
23-12-2016, 18:54
Io intando prendo per buono che in OC RS/DU Zen a @3,9GHz ci dovrebbe stare, e questo non mi sembra poco.
Per il fatto che mi sembra si era esposto -5/-10% in MT, ammesso e concesso che i bench siano veritieri, a Zen basterebbe un +5/+10% di clock.
Ora... sull'X4 mi sembra remota la cosa, ma su X8 vs 6900K, ci siamo, perchè a quei clock Zen avrebbe +9% di clock def, il turbo tutti i core non lo considero perchè bisognerebbe sapere il funzionamento, e 3,9GHz di frequenza massima sarebbe un +6% rispetto ai 3,7GHz massimi del 6900K... Cioè, Zen sarebbe alla pari al 6900K, non certo verso il 6850K.
se fossero veritieri, siamo più a -10% (probabilmente -13% in alcuni ambiti) che a -5%. Quindi il +10% di frequenza servirà tutto, ammesso che ci sarà.
ho fatto considerazioni un po' diverse: ritengo il turbo all core la cosa più importante, in quanto, il 6900k gira praticamente sempre tra i 3.4 ed i 3.5 su tutti i core (escluso carichi particolari). Ne consegue, quindi, che Zen dovrà necessariamente girare a 3.7 su tutti i core con la maggiorparte dei carichi, altrimenti sarà ben sotto.
in base ai dati esposti, non trovo giusto paragonare le freq. di zen a quelle del 6900k ma solo allo stesso ES di zen. Cioè 3.5 vs 3.150 base, 3.7 vs 3.3 turbo all core, 3.9 vs 3.5 turbo single core, in media hai un +~10% ad ogni binning ;)
Per il fatto che mi sembra si era esposto -5/-10% in MT, ammesso e concesso che i bench siano veritieri, a Zen basterebbe un +5/+10% di clock.
Ora... sull'X4 mi sembra remota la cosa, ma su X8 vs 6900K, ci siamo, perchè a quei clock Zen avrebbe +9% di clock def, il turbo tutti i core non lo considero perchè bisognerebbe sapere il funzionamento, e 3,9GHz di frequenza massima sarebbe un +6% rispetto ai 3,7GHz massimi del 6900K... Cioè, Zen sarebbe alla pari al 6900K, non certo verso il 6850K.
se fossero veritieri, siamo più a -10% (probabilmente -13% in alcuni ambiti) che a -5%. Quindi il +10% di frequenza servirà tutto, ammesso che ci sarà.
ho fatto considerazioni un po' diverse: ritengo il turbo all core la cosa più importante, in quanto, il 6900k gira praticamente sempre tra i 3.4 ed i 3.5 su tutti i core (escluso carichi particolari). Ne consegue, quindi, che Zen dovrà necessariamente girare a 3.7 su tutti i core con la maggiorparte dei carichi, altrimenti sarà ben sotto.
in base ai dati esposti, non trovo giusto paragonare le freq. di zen a quelle del 6900k ma solo allo stesso ES di zen. Cioè 3.5 vs 3.150 base, 3.7 vs 3.3 turbo all core, 3.9 vs 3.5 turbo single core, in media hai un +~10% ad ogni binning ;)
digieffe
23-12-2016, 18:58
intel sostituirà l'architettura core?
Even Intel is studying a new x86 uArch. clicca qui (http://www.bitsandchips.it/english/52-english-news/7854-rumor-even-intel-is-studying-a-new-x86-uarch)
Even Intel is studying a new x86 uArch. clicca qui (http://www.bitsandchips.it/english/52-english-news/7854-rumor-even-intel-is-studying-a-new-x86-uarch)
stefanonweb
23-12-2016, 18:59
Intanto ziobepi: :asd: :asd: :asd: :asd: :asd:
Segnalo anche l'uscita dei primi bench gaming per Zen.
http://www.overclock.net/t/1619110/cpc-first-unofficial-ryzen-benchmarks
In perfetto accordo con le mie previsioni direi.
Spero di resistere alla tentazione 7700K,
per riuscirci devo convincermi di aspettare la piattaforma -x :D
Segnalo anche l'uscita dei primi bench gaming per Zen.
http://www.overclock.net/t/1619110/cpc-first-unofficial-ryzen-benchmarks
In perfetto accordo con le mie previsioni direi.
Spero di resistere alla tentazione 7700K,
per riuscirci devo convincermi di aspettare la piattaforma -x :D
Pozhar
23-12-2016, 19:23
Intanto ziobepi:
Deve ringraziare la moderazione lassista, perché se era per me già l'avevo bannato da tempo.
Deve ringraziare la moderazione lassista, perché se era per me già l'avevo bannato da tempo.
capitan_crasy
23-12-2016, 20:12
Deve ringraziare la moderazione lassista, perché se era per me già l'avevo bannato da tempo.
Il problema è che questo cialtrone è già stato bannato molte volte su questo forum; quel nick è solo l'ennesimo clone...:rolleyes:
Il problema è che questo cialtrone è già stato bannato molte volte su questo forum; quel nick è solo l'ennesimo clone...:rolleyes:
Gioz
23-12-2016, 20:18
Deve ringraziare la moderazione lassista, perché se era per me già l'avevo bannato da tempo.
quando tornerà attivo gianni1879 probabilmente si troverà 1 miliardo di segnalazioni
quando tornerà attivo gianni1879 probabilmente si troverà 1 miliardo di segnalazioni
digieffe
23-12-2016, 20:34
Il problema è che questo cialtrone è già stato bannato molte volte su questo forum; quel nick è solo l'ennesimo clone...:rolleyes:
giusto per curiosità come li riconoscete?
giusto per curiosità come li riconoscete?
paolo.oliva2
23-12-2016, 20:38
intel sostituirà l'architettura core?
Even Intel is studying a new x86 uArch. clicca qui (http://www.bitsandchips.it/english/52-english-news/7854-rumor-even-intel-is-studying-a-new-x86-uarch)
Fa prima AMD a fare la prox architettura post Zen.
This new uArch will be ready in 2019-2020.:stordita:
Non ho capito sta frase...
The next Intel uArch will be very similar to the approach used by AMD with Zen – perfect balance of power consumption/performance/price – quindi danno per buoni i rumors dei prezzi? Perchè non c'è null'altro sui prezzi...
Even Intel is studying a new x86 uArch. clicca qui (http://www.bitsandchips.it/english/52-english-news/7854-rumor-even-intel-is-studying-a-new-x86-uarch)
Fa prima AMD a fare la prox architettura post Zen.
This new uArch will be ready in 2019-2020.:stordita:
Non ho capito sta frase...
The next Intel uArch will be very similar to the approach used by AMD with Zen – perfect balance of power consumption/performance/price – quindi danno per buoni i rumors dei prezzi? Perchè non c'è null'altro sui prezzi...
bjt2
23-12-2016, 20:40
Il problema è che questo cialtrone è già stato bannato molte volte su questo forum; quel nick è solo l'ennesimo clone...:rolleyes:
E da quanto dura sto clone? :D Saranno almeno un paio di anni che lo sento nominare... :asd:
E da quanto dura sto clone? :D Saranno almeno un paio di anni che lo sento nominare... :asd:
sgrinfia
23-12-2016, 20:41
E non potevi intervenire con un: "ehm scusate, siete due bimbi ignorantelli, approfondite prima cosa è amd e cosa intel in caso contrario compratevi una playstation (dove dentro c'è processore amd quello che voi chiamate cinese)" E te ne andavi con aria soddisfatta di aver umiliato e rovinato la giornata a due ragazzini. :D
E perché mai doveva farlo ?, nel ignoranza si vive meglio:D
E perché mai doveva farlo ?, nel ignoranza si vive meglio:D
cdimauro
23-12-2016, 20:42
Niente più che rumors/speculazioni del tutto non confermate. E il fatto che entro fine anno vogliano presentare Raven Ridge mi fa pensare che un design nativo 4c sia quello da inserire nel progetto APU, non da proporre come CPU, anche perché vorrebbe dire fare una sovrapposizione di prodotto francamente del tutto inutile.
Quindi il design 4c ci sarebbe, ma riservato alle APU. Makes sense: AMD non ha molte risorse per sviluppare tanti progetti.
E d'altra parte mi pare che tutti i processori Intel da 4 o meno core integrino una GPU (ma non mi va di controllarli uno per uno :D).
Io penso una cosa... che Intel ha vinto per un semplice motivo... perchè quando ha saputo che AMD vendeva le FAB, ha investito sul silicio.
Paolo, ancora? Ma perché ti devi inventare cose di sana pianta?
Intel investe sul silicio da quand'è nata!!!
Io concordo al 1000000% che BD abbia contribuito a perdere nella potenza ST rispetto a qualsiasi altra architettura al suo posto, ma dobbiamo pure considerare che la massima potenza ST Intel l'ha grazie ai suoi core, indubbiamente, ma grazie al silicio ha consentito alla sua architettura di annullare le frequenze superiori di BD, e questo per certo ha contribuito ad aumentarla e far risaltare ancor più la pecca di BD.
Sandy Bridge era a 32 nm, come BD.
Il 2600K era a 3,4Ghz di base e 3,8Ghz di Turbo. 4C/8T (SMT). In 95W.
L'FX-8150 era a 3,6Ghz di base e 4,2Ghz di Turbo. 4C/8T (CMT). In 125W.
Ecco i test (http://www.hwupgrade.it/articoli/cpu/2997/amd-fx-8150-al-debutto-le-soluzioni-bulldozer_9.html): il confronto fra i due, in diversi casi, mi pare impietoso, e non è certo questione di frequenze, ma soprattutto di efficienza, e qui il il silicio c'entra ben poco.
Buono a sapersi. Avevo pensato che fossero microcodificate sia perchè l'algoritmo è iterativo e al massimo si sentiva dire che era di tipo radix 16 (4 bit alla volta), sia perchè spesso non sono pipelined e bloccano la pipe per tutto il tempo di esecuzione... Meglio così... :) Si spera che prima o poi qualcuno le faccia fully pipelined (se sai qualcosa, ogni informazione è benvenuta... :) ).
Ormai sono fuori. :stordita:
BTW sembra che quelli di instxlat64 abbiano zen, perchè hanno fatto prove con AIDA per calcolare le latenze e dicono che sono tutte sbagliate quelle che avevano ipotizzato dalle patch di gcc... In arrivo il chart aggiornato: https://twitter.com/InstLatX64/status/812040863748685824 versione 1.5 con la colonna di Zen lasciata intenzionalmente bianca: https://twitter.com/InstLatX64/status/812000676373032966
Visto. Devono rifare i conti. :D Ma a questo punto se le patch di GCC sono sbagliate, i binari che verranno fuori non saranno ben ottimizzati per Zen. :fagiano:
Solo che non capisco perché si ostinino a riportare differenze fra ALU a 32 e 64 bit per i processori Intel: sia il manuale di Agner sia quello di Intel riportano informazioni ben diverse, e nessuna differenza fra 32 e 64 bit (per lo meno per le operazioni "intere" più comuni).
https://youtu.be/Ln9WKPEHm4w?t=17m56s Forse è troppo ad alto livello, ma in Zen tra il mux e la uop queue c'è lo stack memfile che filtra le operazioni e la microcode rom che invece le espande. Da questo diagramma invece sembra che l'architettura intel sia piuttosto standard e la microcode rom potrebbe stare vicino o subito dopo i decoder...
Se prendi il manuale delle ottimizzazioni di Intel, c'è lo schema di Skylake che mostra come la micro-op queue riceva uop da: decoder, uROM, e uop cache. Come Zen.
Chiaro che Zen ha pure lo stack mem in mezzo, ma in linea di massima fanno esattamente le stesse cose.
Può anche darsi che il tizio si sia espresso male.
E' quel che penso.
In bocca al lupo per il tuo lavoro... Di cuore... :)
Grazie!
E' anche il mio sogno, di progettare una CPU, ci penso spesso... :) Ti auguro di realizzarlo... :)
Se hai esperienza con RTL / VHDL / Verilog e hai già implementato qualche architettura, potremmo "fare comitiva", come si dice dalle mie parti. :cool:
Della mia architettura ho già definito in maniera precisa l'ISA e la relativa opcode table. Ovviamente non serve implementare tutto in una volta (c'è troppa carne al fuoco), ma si può partire da un subset minimale, per poi espanderlo.
L'ho realizzata in modo che certe parti (FPU, MMX, SSE, AVX 1&2/AVX-512/AVX-1024 :D) si possano inserire o rimuovere molto facilmente. Idem per la modalità a 32 o 64 bit, e anche i vari register set sono scalabili a piacere (16 o 32 GPR; 16/32/64/128 VecR; 0/8/16 MaskR). Diverse altre cose (istruzioni) sono organizzate in gruppi che si possono aggiungere o rimuovere; fra queste c'è il legacy (segmentazione, address size, tutte le vecchie istruzioni x86), che è confinato in precise zone. E infine le numerose modalità d'indirizzamento hanno una certa regolarità / semplicità, e si possono aggiungere o togliere a piacere.
Anche io ho parecchie idee e una in particolare AMD finalmente l'ha realizzata, anche se in "scala ridotta". Sto parlando del PTE coalescing... In Zen 8 pagine contigue possono essere memorizzate in una sola TLB entry di pagina 4k, senza intervento del SO (ovviamente in memoria la page table non cambia). Io avevo pensato a una cosa senza limiti, ma 2 registri con pagina iniziale e finale in modo che il range potesse essere illimitato... Ma già una compressione 8:1 è notevole... :)
Credo che l'ISA proposta lo scorso anno da Agner Fog abbia qualcosa di simile, visto che non utilizza la paginazione, ma implementa una sorta di segmentazione dello spazio d'indirizzamento (virtuale), in modo da evitare di usare la TLB a priori.
Se vuoi dargli un'occhiata, trovi tutto qui: ForwardCom (http://www.forwardcom.info)
In particolare, dall'abstract su Efficient memory management (http://www.forwardcom.info/#memory_management):
"he number of memory sections that a running process or thread has access to is so small that it all can be contained in a memory map inside the CPU chip. This is very different from most common systems that have very large page tables. A large page table requires fixed-size memory pages in order to make table lookup simple. But if we can keep the number of table entries small then it is feasible to have variable-size table entries. The ForwardCom design has the goal of keeping all code or data that a process has access to contiguous and to avoid memory fragmentation as much as possible. This makes it possible to replace the huge multi-level page tables and translation-lookaside-buffers of current systems with a small on-chip memory map."
Ma STM non è stata acquisita e non è più italiana?
No, è ancora italiana. Ma ha diversi investitori che ne posseggono le azioni, e la controllano.
Che io sappia blender non fa schedulazione sulla CPu, quindi il codice dovrebbe essere lo stesso...
OK, quindi codice generico per qualunque processore.
Sono andato a scorrere il pdf di agner fog, alla sezione AMD più nuova (Steamroller).http://www.agner.org/optimize/instruction_tables.pdf
Effettivamente quasi tutte le DIV hanno 1 o 2 MOP, tranne la 8 e 16 bit che quindi è microcodificata. Le SQRT hanno più di 2 mop quindi anche queste lo sono.
No, hanno al massimo 2MOP. Controlla bene. :)
Alcune routine di push e pop (per i flag) che dovrebbero essere usate in tutte le ISR sono microcodificate, ma qui, ovviamente sono usate pochissimo, perchè le interruzioni non sono poi così frequenti.
In realtà i flag sono automaticamente conservati quando una ISR viene chiamata. Per cui non si devono salvare e ripristinare.
Comunque AMD richiede troppe MOP & cicli di clock per PUSHF/POPF/LAHF/SAHF. Intel è messa di gran lunga meglio, e non usa microcodice, a parte per la POPF (per ovvie ragioni), che comunque richiede di gran lunga meno uop rispetto ad AMD.
Ci siamo scordati tre classi di istruzioni che possono non essere così rare e che sono microcodificate: le istruzioni di locking (per tutti i semafori, quindi usate spesso nel SO ma anche in codice utente, se multitasking/threading), le istruzioni di crittografia, usate spesso nei software a cui serve (quindi penso a VPN, driver del file system nel caso sia criptato, browser quando si usa l'https) e le istruzioni stringa. Se supponiamo che memcpy sia implementato con REP MOVxx, allora potrebbe essere anche usata spesso. E avere in uop cache solo il placeholder alla routine potrebbe essere vantaggioso...
C'è da dire che Intel è messa molto meglio di AMD per quanto riguarda crittografia e REPs.
Soltanto in quest'ultimo caso vengono generate diverse uop, ma sono decisamente poche, e specialmente se i dati sono allineati in memoria.
Comunque riguardo a REP e lock, bisogna anche considerare quanto verranno utilizzate in loop.
Nel primo caso ben poco, perché in genere trasferisci (o riempi) zone di memoria, e vai avanti col codice. Dunque "cachare" le uop non ha senso.
I lock in genere si trovano in mezzo a loop, ma il loop è piccolo e con la finalità di aggiudicarsi la risorsa. Una volta che la risorsa è stata presa, non torni nuovamente in quel loop, ma continui con la sezione critica che farà tutt'altro..
Quindi in questo caso la uop cache viene usata pochissimo, e poi non serve più.
Questo per sottolineare come non si possa pensare "sui massimi sistemi", tenendo conto della feature di per sé, ma bisogna calare sempre il tutto nel mondo reale, e vedere in che modo funzionano le cose, e in che modo / misura possa incidere una particolare feature. :)
Sembra abbiano un sample di quelli apparsi su Geekbench 4 quest'estate (quindi non ultimissima revisione).
Dal grafico (interpretazione personale) sembra sia sprovvisto di AVX 512, in quanto hanno messo un trattino (-), tanto come in µop-cache ed L3 size per Excavator e Bristol Ridge, non lasciando il campo in blanc.
Si sa già che Zen non avrà le AVX-512. Come non le ha Skylake, se non in versione server.
Già adesso deve suddividere le istruzioni AVX a 256 bit in 2 parti a 128 bit per eseguirle nelle sue FPU a 128 bit, che non è certo il massimo.
Potrebbe anche fare lo stesso con la AVX-512, spezzandolo in 4 parti a 128 bit, ma non è certo molto efficiente. E comunque non basterebbe, perché le AVX-512 richiedono diverse altre cose per il loro funzionamento (registri di maschera, e supporto per il mascheramento delle lane per l'appunto. Compressed offset a 8 bit. E credo ci sia altra roba), complicando l'implementazione.
in base ai dati esposti, non trovo giusto paragonare le freq. di zen a quelle del 6900k ma solo allo stesso ES di zen. Cioè 3.5 vs 3.150 base, 3.7 vs 3.3 turbo all core, 3.9 vs 3.5 turbo single core, in media hai un +~10% ad ogni binning ;)
Il 6900K ha 3,2Ghz di base, che è simile al 3,15 di Zen. SE questo leak risultasse vero, ovviamente.
intel sostituirà l'architettura core?
Even Intel is studying a new x86 uArch. clicca qui (http://www.bitsandchips.it/english/52-english-news/7854-rumor-even-intel-is-studying-a-new-x86-uarch)
Non so se la sostituirà, con qualcosa di ridisegnato da zero.
Eliminare parti dell'ISA è già possibile, ma finora non l'ha mai fatto. Col codice a 64 bit che è ormai molto diffuso, e che usa quasi sempre le SSE2 (che sono il requisito minimo per x64), l'FPU x87 non è quasi mai utilizzata. Inoltre non ho mai trovato codice MMX (ma non ho disassemblato molte applicazioni: solo alcune molto comuni).
Per cui rimuovere MMX ed FPU x86, specialmente fra 3-4 anni, potrebbe essere fattibile.
Quindi il design 4c ci sarebbe, ma riservato alle APU. Makes sense: AMD non ha molte risorse per sviluppare tanti progetti.
E d'altra parte mi pare che tutti i processori Intel da 4 o meno core integrino una GPU (ma non mi va di controllarli uno per uno :D).
Io penso una cosa... che Intel ha vinto per un semplice motivo... perchè quando ha saputo che AMD vendeva le FAB, ha investito sul silicio.
Paolo, ancora? Ma perché ti devi inventare cose di sana pianta?
Intel investe sul silicio da quand'è nata!!!
Io concordo al 1000000% che BD abbia contribuito a perdere nella potenza ST rispetto a qualsiasi altra architettura al suo posto, ma dobbiamo pure considerare che la massima potenza ST Intel l'ha grazie ai suoi core, indubbiamente, ma grazie al silicio ha consentito alla sua architettura di annullare le frequenze superiori di BD, e questo per certo ha contribuito ad aumentarla e far risaltare ancor più la pecca di BD.
Sandy Bridge era a 32 nm, come BD.
Il 2600K era a 3,4Ghz di base e 3,8Ghz di Turbo. 4C/8T (SMT). In 95W.
L'FX-8150 era a 3,6Ghz di base e 4,2Ghz di Turbo. 4C/8T (CMT). In 125W.
Ecco i test (http://www.hwupgrade.it/articoli/cpu/2997/amd-fx-8150-al-debutto-le-soluzioni-bulldozer_9.html): il confronto fra i due, in diversi casi, mi pare impietoso, e non è certo questione di frequenze, ma soprattutto di efficienza, e qui il il silicio c'entra ben poco.
Buono a sapersi. Avevo pensato che fossero microcodificate sia perchè l'algoritmo è iterativo e al massimo si sentiva dire che era di tipo radix 16 (4 bit alla volta), sia perchè spesso non sono pipelined e bloccano la pipe per tutto il tempo di esecuzione... Meglio così... :) Si spera che prima o poi qualcuno le faccia fully pipelined (se sai qualcosa, ogni informazione è benvenuta... :) ).
Ormai sono fuori. :stordita:
BTW sembra che quelli di instxlat64 abbiano zen, perchè hanno fatto prove con AIDA per calcolare le latenze e dicono che sono tutte sbagliate quelle che avevano ipotizzato dalle patch di gcc... In arrivo il chart aggiornato: https://twitter.com/InstLatX64/status/812040863748685824 versione 1.5 con la colonna di Zen lasciata intenzionalmente bianca: https://twitter.com/InstLatX64/status/812000676373032966
Visto. Devono rifare i conti. :D Ma a questo punto se le patch di GCC sono sbagliate, i binari che verranno fuori non saranno ben ottimizzati per Zen. :fagiano:
Solo che non capisco perché si ostinino a riportare differenze fra ALU a 32 e 64 bit per i processori Intel: sia il manuale di Agner sia quello di Intel riportano informazioni ben diverse, e nessuna differenza fra 32 e 64 bit (per lo meno per le operazioni "intere" più comuni).
https://youtu.be/Ln9WKPEHm4w?t=17m56s Forse è troppo ad alto livello, ma in Zen tra il mux e la uop queue c'è lo stack memfile che filtra le operazioni e la microcode rom che invece le espande. Da questo diagramma invece sembra che l'architettura intel sia piuttosto standard e la microcode rom potrebbe stare vicino o subito dopo i decoder...
Se prendi il manuale delle ottimizzazioni di Intel, c'è lo schema di Skylake che mostra come la micro-op queue riceva uop da: decoder, uROM, e uop cache. Come Zen.
Chiaro che Zen ha pure lo stack mem in mezzo, ma in linea di massima fanno esattamente le stesse cose.
Può anche darsi che il tizio si sia espresso male.
E' quel che penso.
In bocca al lupo per il tuo lavoro... Di cuore... :)
Grazie!
E' anche il mio sogno, di progettare una CPU, ci penso spesso... :) Ti auguro di realizzarlo... :)
Se hai esperienza con RTL / VHDL / Verilog e hai già implementato qualche architettura, potremmo "fare comitiva", come si dice dalle mie parti. :cool:
Della mia architettura ho già definito in maniera precisa l'ISA e la relativa opcode table. Ovviamente non serve implementare tutto in una volta (c'è troppa carne al fuoco), ma si può partire da un subset minimale, per poi espanderlo.
L'ho realizzata in modo che certe parti (FPU, MMX, SSE, AVX 1&2/AVX-512/AVX-1024 :D) si possano inserire o rimuovere molto facilmente. Idem per la modalità a 32 o 64 bit, e anche i vari register set sono scalabili a piacere (16 o 32 GPR; 16/32/64/128 VecR; 0/8/16 MaskR). Diverse altre cose (istruzioni) sono organizzate in gruppi che si possono aggiungere o rimuovere; fra queste c'è il legacy (segmentazione, address size, tutte le vecchie istruzioni x86), che è confinato in precise zone. E infine le numerose modalità d'indirizzamento hanno una certa regolarità / semplicità, e si possono aggiungere o togliere a piacere.
Anche io ho parecchie idee e una in particolare AMD finalmente l'ha realizzata, anche se in "scala ridotta". Sto parlando del PTE coalescing... In Zen 8 pagine contigue possono essere memorizzate in una sola TLB entry di pagina 4k, senza intervento del SO (ovviamente in memoria la page table non cambia). Io avevo pensato a una cosa senza limiti, ma 2 registri con pagina iniziale e finale in modo che il range potesse essere illimitato... Ma già una compressione 8:1 è notevole... :)
Credo che l'ISA proposta lo scorso anno da Agner Fog abbia qualcosa di simile, visto che non utilizza la paginazione, ma implementa una sorta di segmentazione dello spazio d'indirizzamento (virtuale), in modo da evitare di usare la TLB a priori.
Se vuoi dargli un'occhiata, trovi tutto qui: ForwardCom (http://www.forwardcom.info)
In particolare, dall'abstract su Efficient memory management (http://www.forwardcom.info/#memory_management):
"he number of memory sections that a running process or thread has access to is so small that it all can be contained in a memory map inside the CPU chip. This is very different from most common systems that have very large page tables. A large page table requires fixed-size memory pages in order to make table lookup simple. But if we can keep the number of table entries small then it is feasible to have variable-size table entries. The ForwardCom design has the goal of keeping all code or data that a process has access to contiguous and to avoid memory fragmentation as much as possible. This makes it possible to replace the huge multi-level page tables and translation-lookaside-buffers of current systems with a small on-chip memory map."
Ma STM non è stata acquisita e non è più italiana?
No, è ancora italiana. Ma ha diversi investitori che ne posseggono le azioni, e la controllano.
Che io sappia blender non fa schedulazione sulla CPu, quindi il codice dovrebbe essere lo stesso...
OK, quindi codice generico per qualunque processore.
Sono andato a scorrere il pdf di agner fog, alla sezione AMD più nuova (Steamroller).http://www.agner.org/optimize/instruction_tables.pdf
Effettivamente quasi tutte le DIV hanno 1 o 2 MOP, tranne la 8 e 16 bit che quindi è microcodificata. Le SQRT hanno più di 2 mop quindi anche queste lo sono.
No, hanno al massimo 2MOP. Controlla bene. :)
Alcune routine di push e pop (per i flag) che dovrebbero essere usate in tutte le ISR sono microcodificate, ma qui, ovviamente sono usate pochissimo, perchè le interruzioni non sono poi così frequenti.
In realtà i flag sono automaticamente conservati quando una ISR viene chiamata. Per cui non si devono salvare e ripristinare.
Comunque AMD richiede troppe MOP & cicli di clock per PUSHF/POPF/LAHF/SAHF. Intel è messa di gran lunga meglio, e non usa microcodice, a parte per la POPF (per ovvie ragioni), che comunque richiede di gran lunga meno uop rispetto ad AMD.
Ci siamo scordati tre classi di istruzioni che possono non essere così rare e che sono microcodificate: le istruzioni di locking (per tutti i semafori, quindi usate spesso nel SO ma anche in codice utente, se multitasking/threading), le istruzioni di crittografia, usate spesso nei software a cui serve (quindi penso a VPN, driver del file system nel caso sia criptato, browser quando si usa l'https) e le istruzioni stringa. Se supponiamo che memcpy sia implementato con REP MOVxx, allora potrebbe essere anche usata spesso. E avere in uop cache solo il placeholder alla routine potrebbe essere vantaggioso...
C'è da dire che Intel è messa molto meglio di AMD per quanto riguarda crittografia e REPs.
Soltanto in quest'ultimo caso vengono generate diverse uop, ma sono decisamente poche, e specialmente se i dati sono allineati in memoria.
Comunque riguardo a REP e lock, bisogna anche considerare quanto verranno utilizzate in loop.
Nel primo caso ben poco, perché in genere trasferisci (o riempi) zone di memoria, e vai avanti col codice. Dunque "cachare" le uop non ha senso.
I lock in genere si trovano in mezzo a loop, ma il loop è piccolo e con la finalità di aggiudicarsi la risorsa. Una volta che la risorsa è stata presa, non torni nuovamente in quel loop, ma continui con la sezione critica che farà tutt'altro..
Quindi in questo caso la uop cache viene usata pochissimo, e poi non serve più.
Questo per sottolineare come non si possa pensare "sui massimi sistemi", tenendo conto della feature di per sé, ma bisogna calare sempre il tutto nel mondo reale, e vedere in che modo funzionano le cose, e in che modo / misura possa incidere una particolare feature. :)
Sembra abbiano un sample di quelli apparsi su Geekbench 4 quest'estate (quindi non ultimissima revisione).
Dal grafico (interpretazione personale) sembra sia sprovvisto di AVX 512, in quanto hanno messo un trattino (-), tanto come in µop-cache ed L3 size per Excavator e Bristol Ridge, non lasciando il campo in blanc.
Si sa già che Zen non avrà le AVX-512. Come non le ha Skylake, se non in versione server.
Già adesso deve suddividere le istruzioni AVX a 256 bit in 2 parti a 128 bit per eseguirle nelle sue FPU a 128 bit, che non è certo il massimo.
Potrebbe anche fare lo stesso con la AVX-512, spezzandolo in 4 parti a 128 bit, ma non è certo molto efficiente. E comunque non basterebbe, perché le AVX-512 richiedono diverse altre cose per il loro funzionamento (registri di maschera, e supporto per il mascheramento delle lane per l'appunto. Compressed offset a 8 bit. E credo ci sia altra roba), complicando l'implementazione.
in base ai dati esposti, non trovo giusto paragonare le freq. di zen a quelle del 6900k ma solo allo stesso ES di zen. Cioè 3.5 vs 3.150 base, 3.7 vs 3.3 turbo all core, 3.9 vs 3.5 turbo single core, in media hai un +~10% ad ogni binning ;)
Il 6900K ha 3,2Ghz di base, che è simile al 3,15 di Zen. SE questo leak risultasse vero, ovviamente.
intel sostituirà l'architettura core?
Even Intel is studying a new x86 uArch. clicca qui (http://www.bitsandchips.it/english/52-english-news/7854-rumor-even-intel-is-studying-a-new-x86-uarch)
Non so se la sostituirà, con qualcosa di ridisegnato da zero.
Eliminare parti dell'ISA è già possibile, ma finora non l'ha mai fatto. Col codice a 64 bit che è ormai molto diffuso, e che usa quasi sempre le SSE2 (che sono il requisito minimo per x64), l'FPU x87 non è quasi mai utilizzata. Inoltre non ho mai trovato codice MMX (ma non ho disassemblato molte applicazioni: solo alcune molto comuni).
Per cui rimuovere MMX ed FPU x86, specialmente fra 3-4 anni, potrebbe essere fattibile.
bjt2
23-12-2016, 20:43
Fa prima AMD a fare la prox architettura post Zen.
This new uArch will be ready in 2019-2020.:stordita:
Non ho capito sta frase...
The next Intel uArch will be very similar to the approach used by AMD with Zen – perfect balance of power consumption/performance/price – quindi danno per buoni i rumors dei prezzi? Perchè non c'è null'altro sui prezzi...
Beh, se la prima infornata avrà 3.5-3.6 base, metti le seconde infornate, metti il 14nmHP, metti il 7nm GF, metti Zen+ con ulteriori migliorie e l'SMT4, hai voglia a strada che deve fare INTEL per recuperare... :D Prevedo che già sul 14nm si arrivi a superare i 4GHz base (magari solo sull'HP) e sul 7nm qualcosina in più... Poi un po' di IPC in più con zen+
This new uArch will be ready in 2019-2020.:stordita:
Non ho capito sta frase...
The next Intel uArch will be very similar to the approach used by AMD with Zen – perfect balance of power consumption/performance/price – quindi danno per buoni i rumors dei prezzi? Perchè non c'è null'altro sui prezzi...
Beh, se la prima infornata avrà 3.5-3.6 base, metti le seconde infornate, metti il 14nmHP, metti il 7nm GF, metti Zen+ con ulteriori migliorie e l'SMT4, hai voglia a strada che deve fare INTEL per recuperare... :D Prevedo che già sul 14nm si arrivi a superare i 4GHz base (magari solo sull'HP) e sul 7nm qualcosina in più... Poi un po' di IPC in più con zen+
george_p
23-12-2016, 20:47
francamente questa non la capisco....
i core bulldozer sono come k10 piccoli molto piccoli, la metà di SB, oltre ad avere le pipeline più lunghe....c'è un motivo se AMD aveva dei quad core SR (KAVERI) da 2,1GHz base 19W vs dual core SB da 1,8GHz 17W....la "sfortuna" di AMD è che il 28nm bulk è nato quando Intel era già da tempo sui finfet...processo che ha permesso di guadagnare un ulteriore 30-40% di efficienza ad Intel..
il fatto che AMD non sia passato interamente alla produzione sul bulk potrebbe essere legata ai motivi contrattuali con GF (avevo letto qualcosa su bitsandchips)
Scusa ma nemmeno io capisco la tua risposta al quote del mio post.
i core bulldozer sono come k10 piccoli molto piccoli, la metà di SB, oltre ad avere le pipeline più lunghe....c'è un motivo se AMD aveva dei quad core SR (KAVERI) da 2,1GHz base 19W vs dual core SB da 1,8GHz 17W....la "sfortuna" di AMD è che il 28nm bulk è nato quando Intel era già da tempo sui finfet...processo che ha permesso di guadagnare un ulteriore 30-40% di efficienza ad Intel..
il fatto che AMD non sia passato interamente alla produzione sul bulk potrebbe essere legata ai motivi contrattuali con GF (avevo letto qualcosa su bitsandchips)
Scusa ma nemmeno io capisco la tua risposta al quote del mio post.
bjt2
23-12-2016, 21:13
Ormai sono fuori. :stordita:
Beh, a memoria, ho ricordi vaghi che le unità non erano fully pipelined. Ora mi ricordo che basta vedere le tabelle del PDF di Agner Fog e guardare la colonna del 1/throughput. Se è dello stesso ordine di grandezza della latenza (o qualche ciclo meno) allora non è pipelined, perchè vuol dire che deve terminare tutta l'esecuzione prima di poterne fare un'altra (e ovviamente blocca tutta la pipeline)
Visto. Devono rifare i conti. :D Ma a questo punto se le patch di GCC sono sbagliate, i binari che verranno fuori non saranno ben ottimizzati per Zen. :fagiano:
Beh, penso che una volta pubblicate le informazioni di instlat86, tempo un paio di giorni e ci sarà la nuova patch...
Solo che non capisco perché si ostinino a riportare differenze fra ALU a 32 e 64 bit per i processori Intel: sia il manuale di Agner sia quello di Intel riportano informazioni ben diverse, e nessuna differenza fra 32 e 64 bit (per lo meno per le operazioni "intere" più comuni).
Penso che sia per un fatto di uniformità: nel manuale di Fog ci sono tante CPU, comprese low power, knight xxx, mi pare anche il pentium 4 e magari per loro la distinzione ha senso.
Se prendi il manuale delle ottimizzazioni di Intel, c'è lo schema di Skylake che mostra come la micro-op queue riceva uop da: decoder, uROM, e uop cache. Come Zen.
Chiaro che Zen ha pure lo stack mem in mezzo, ma in linea di massima fanno esattamente le stesse cose.
Ok, credo che anche quella gif che postai giorni fa dica lo stesso. ovviamente i documenti ufficiali fanno ancora più testo
Se hai esperienza con RTL / VHDL / Verilog e hai già implementato qualche architettura, potremmo "fare comitiva", come si dice dalle mie parti. :cool:
VHDL l'ho studiato all'università (e anche il dimensionamento dei MOS), ma non ricordo granchè... :asd:
Della mia architettura ho già definito in maniera precisa l'ISA e la relativa opcode table. Ovviamente non serve implementare tutto in una volta (c'è troppa carne al fuoco), ma si può partire da un subset minimale, per poi espanderlo.
L'ho realizzata in modo che certe parti (FPU, MMX, SSE, AVX 1&2/AVX-512/AVX-1024 :D) si possano inserire o rimuovere molto facilmente. Idem per la modalità a 32 o 64 bit, e anche i vari register set sono scalabili a piacere (16 o 32 GPR; 16/32/64/128 VecR; 0/8/16 MaskR). Diverse altre cose (istruzioni) sono organizzate in gruppi che si possono aggiungere o rimuovere; fra queste c'è il legacy (segmentazione, address size, tutte le vecchie istruzioni x86), che è confinato in precise zone. E infine le numerose modalità d'indirizzamento hanno una certa regolarità / semplicità, e si possono aggiungere o togliere a piacere.
Ma è una specie di subset/superset di x86? :eek: Le mie elugubrazioni erano più per una CISC (ovviamente con motore RISC) completamente ortogonale dove ogni operando aveva il tipo annesso ed erano automaticamente emesse le uop di conversione se il tipo dei vari operandi era diverso. Istruzioni a 0-4 operandi, dove ogni operando aveva campi di bit per tipo, modo indirizzamento e dati, avevo anche calcolato i bit ecc...
Credo che l'ISA proposta lo scorso anno da Agner Fog abbia qualcosa di simile, visto che non utilizza la paginazione, ma implementa una sorta di segmentazione dello spazio d'indirizzamento (virtuale), in modo da evitare di usare la TLB a priori.
Se vuoi dargli un'occhiata, trovi tutto qui: ForwardCom (http://www.forwardcom.info)
In particolare, dall'abstract su Efficient memory management (http://www.forwardcom.info/#memory_management):
"he number of memory sections that a running process or thread has access to is so small that it all can be contained in a memory map inside the CPU chip. This is very different from most common systems that have very large page tables. A large page table requires fixed-size memory pages in order to make table lookup simple. But if we can keep the number of table entries small then it is feasible to have variable-size table entries. The ForwardCom design has the goal of keeping all code or data that a process has access to contiguous and to avoid memory fragmentation as much as possible. This makes it possible to replace the huge multi-level page tables and translation-lookaside-buffers of current systems with a small on-chip memory map."
Già dall'abstract vedo che mi ha copiato l'indirizzamento... :asd: Anche a me è sempre stata antipatica la paginazione e pensavo di dividere in range lo spazio, il tutto da mettere in registri interni del processore... La PTE coalescing è l'adattamento della mia idea alla paginazione, senza modificare i SO correnti, quindi con granularità 4KB, ma limite di 8 pagine alla volta...
Suggerirei ad AMD di modificare le TLB in modo da mettere pagina iniziale e finale e quindi non limitarsi a range di 8 pagine...
No, hanno al massimo 2MOP. Controlla bene. :)
Qualcuna ce n'è:
Ad esempio:
Pag 67:
DIV r8/m8 9 17-22 13-17 EX0
DIV r16/m16 7 15-25 15-25 EX0
IDIV r8/m8 9 17-22 13-17 EX0
IDIV r16/m16 7 14-25 14-24 EX0
9 e 7 MOPs
Pag 68:
Varie istruzioni di shift rotazione (non riesco ad incollare...)
Pag 69-75
Molte istruzioni di mascheramento e floating point...
In realtà i flag sono automaticamente conservati quando una ISR viene chiamata. Per cui non si devono salvare e ripristinare.
Giusto! Sono BOCCIATO! :banned: :asd:
Comunque AMD richiede troppe MOP & cicli di clock per PUSHF/POPF/LAHF/SAHF. Intel è messa di gran lunga meglio, e non usa microcodice, a parte per la POPF (per ovvie ragioni), che comunque richiede di gran lunga meno uop rispetto ad AMD.
Immagino...
C'è da dire che Intel è messa molto meglio di AMD per quanto riguarda crittografia e REPs.
Soltanto in quest'ultimo caso vengono generate diverse uop, ma sono decisamente poche, e specialmente se i dati sono allineati in memoria.
Beh, se vedi quelle poco efficienti sono le legacy... Ce ne sono altre che hanno una uop per ogni 16 bytes, più un setup... Meglio non si può fare (con bus a 128 bit... Ovviamente intel ha il bus doppio...)
Comunque riguardo a REP e lock, bisogna anche considerare quanto verranno utilizzate in loop.
Nel primo caso ben poco, perché in genere trasferisci (o riempi) zone di memoria, e vai avanti col codice. Dunque "cachare" le uop non ha senso.
I lock in genere si trovano in mezzo a loop, ma il loop è piccolo e con la finalità di aggiudicarsi la risorsa. Una volta che la risorsa è stata presa, non torni nuovamente in quel loop, ma continui con la sezione critica che farà tutt'altro..
Quindi in questo caso la uop cache viene usata pochissimo, e poi non serve più.
Hai ragione. Il contributo è minimo. Ma almeno in AMD non hai uop cache pollution perchè è una sola uop. In INTEL, se non usi questo trucco, quando incontri qualche mostro di questo ti può svuotare parte della cache uop.
Questo per sottolineare come non si possa pensare "sui massimi sistemi", tenendo conto della feature di per sé, ma bisogna calare sempre il tutto nel mondo reale, e vedere in che modo funzionano le cose, e in che modo / misura possa incidere una particolare feature. :)
Si sa già che Zen non avrà le AVX-512. Come non le ha Skylake, se non in versione server.
Già adesso deve suddividere le istruzioni AVX a 256 bit in 2 parti a 128 bit per eseguirle nelle sue FPU a 128 bit, che non è certo il massimo.
Potrebbe anche fare lo stesso con la AVX-512, spezzandolo in 4 parti a 128 bit, ma non è certo molto efficiente. E comunque non basterebbe, perché le AVX-512 richiedono diverse altre cose per il loro funzionamento (registri di maschera, e supporto per il mascheramento delle lane per l'appunto. Compressed offset a 8 bit. E credo ci sia altra roba), complicando l'implementazione.
Beh, se i 4 decoder possono sparare 4 puntatori alla rom per ciclo, non è che impatta molto: vai di microcodice e via... Forse è per questo che l'hanno fatto questa genialata...
Non so se la sostituirà, con qualcosa di ridisegnato da zero.
Eliminare parti dell'ISA è già possibile, ma finora non l'ha mai fatto. Col codice a 64 bit che è ormai molto diffuso, e che usa quasi sempre le SSE2 (che sono il requisito minimo per x64), l'FPU x87 non è quasi mai utilizzata. Inoltre non ho mai trovato codice MMX (ma non ho disassemblato molte applicazioni: solo alcune molto comuni).
Per cui rimuovere MMX ed FPU x86, specialmente fra 3-4 anni, potrebbe essere fattibile.
Non mi toccare la FPU x87! :O Già ora 64 bit mi stanno stretti... :O E anche 80... :O Power 9 avrà i 128 bit, anche se leggendo il reference manual (si! ho fatto la pazzia di leggerlo tutto! :D ) per questa versione è tutto o quasi in trap, ossia emulazione software, ma hanno gettato le basi per una futura versione hardware. D'altronde anche gli 80 bit su x87 sono più lenti e sulle CPU di bassa potenza (mi pare ad esempio le bobcat e jaguar) addirittura la denormalizzazione è demandata a routine di microcode ROM...
Beh, a memoria, ho ricordi vaghi che le unità non erano fully pipelined. Ora mi ricordo che basta vedere le tabelle del PDF di Agner Fog e guardare la colonna del 1/throughput. Se è dello stesso ordine di grandezza della latenza (o qualche ciclo meno) allora non è pipelined, perchè vuol dire che deve terminare tutta l'esecuzione prima di poterne fare un'altra (e ovviamente blocca tutta la pipeline)
Visto. Devono rifare i conti. :D Ma a questo punto se le patch di GCC sono sbagliate, i binari che verranno fuori non saranno ben ottimizzati per Zen. :fagiano:
Beh, penso che una volta pubblicate le informazioni di instlat86, tempo un paio di giorni e ci sarà la nuova patch...
Solo che non capisco perché si ostinino a riportare differenze fra ALU a 32 e 64 bit per i processori Intel: sia il manuale di Agner sia quello di Intel riportano informazioni ben diverse, e nessuna differenza fra 32 e 64 bit (per lo meno per le operazioni "intere" più comuni).
Penso che sia per un fatto di uniformità: nel manuale di Fog ci sono tante CPU, comprese low power, knight xxx, mi pare anche il pentium 4 e magari per loro la distinzione ha senso.
Se prendi il manuale delle ottimizzazioni di Intel, c'è lo schema di Skylake che mostra come la micro-op queue riceva uop da: decoder, uROM, e uop cache. Come Zen.
Chiaro che Zen ha pure lo stack mem in mezzo, ma in linea di massima fanno esattamente le stesse cose.
Ok, credo che anche quella gif che postai giorni fa dica lo stesso. ovviamente i documenti ufficiali fanno ancora più testo
Se hai esperienza con RTL / VHDL / Verilog e hai già implementato qualche architettura, potremmo "fare comitiva", come si dice dalle mie parti. :cool:
VHDL l'ho studiato all'università (e anche il dimensionamento dei MOS), ma non ricordo granchè... :asd:
Della mia architettura ho già definito in maniera precisa l'ISA e la relativa opcode table. Ovviamente non serve implementare tutto in una volta (c'è troppa carne al fuoco), ma si può partire da un subset minimale, per poi espanderlo.
L'ho realizzata in modo che certe parti (FPU, MMX, SSE, AVX 1&2/AVX-512/AVX-1024 :D) si possano inserire o rimuovere molto facilmente. Idem per la modalità a 32 o 64 bit, e anche i vari register set sono scalabili a piacere (16 o 32 GPR; 16/32/64/128 VecR; 0/8/16 MaskR). Diverse altre cose (istruzioni) sono organizzate in gruppi che si possono aggiungere o rimuovere; fra queste c'è il legacy (segmentazione, address size, tutte le vecchie istruzioni x86), che è confinato in precise zone. E infine le numerose modalità d'indirizzamento hanno una certa regolarità / semplicità, e si possono aggiungere o togliere a piacere.
Ma è una specie di subset/superset di x86? :eek: Le mie elugubrazioni erano più per una CISC (ovviamente con motore RISC) completamente ortogonale dove ogni operando aveva il tipo annesso ed erano automaticamente emesse le uop di conversione se il tipo dei vari operandi era diverso. Istruzioni a 0-4 operandi, dove ogni operando aveva campi di bit per tipo, modo indirizzamento e dati, avevo anche calcolato i bit ecc...
Credo che l'ISA proposta lo scorso anno da Agner Fog abbia qualcosa di simile, visto che non utilizza la paginazione, ma implementa una sorta di segmentazione dello spazio d'indirizzamento (virtuale), in modo da evitare di usare la TLB a priori.
Se vuoi dargli un'occhiata, trovi tutto qui: ForwardCom (http://www.forwardcom.info)
In particolare, dall'abstract su Efficient memory management (http://www.forwardcom.info/#memory_management):
"he number of memory sections that a running process or thread has access to is so small that it all can be contained in a memory map inside the CPU chip. This is very different from most common systems that have very large page tables. A large page table requires fixed-size memory pages in order to make table lookup simple. But if we can keep the number of table entries small then it is feasible to have variable-size table entries. The ForwardCom design has the goal of keeping all code or data that a process has access to contiguous and to avoid memory fragmentation as much as possible. This makes it possible to replace the huge multi-level page tables and translation-lookaside-buffers of current systems with a small on-chip memory map."
Già dall'abstract vedo che mi ha copiato l'indirizzamento... :asd: Anche a me è sempre stata antipatica la paginazione e pensavo di dividere in range lo spazio, il tutto da mettere in registri interni del processore... La PTE coalescing è l'adattamento della mia idea alla paginazione, senza modificare i SO correnti, quindi con granularità 4KB, ma limite di 8 pagine alla volta...
Suggerirei ad AMD di modificare le TLB in modo da mettere pagina iniziale e finale e quindi non limitarsi a range di 8 pagine...
No, hanno al massimo 2MOP. Controlla bene. :)
Qualcuna ce n'è:
Ad esempio:
Pag 67:
DIV r8/m8 9 17-22 13-17 EX0
DIV r16/m16 7 15-25 15-25 EX0
IDIV r8/m8 9 17-22 13-17 EX0
IDIV r16/m16 7 14-25 14-24 EX0
9 e 7 MOPs
Pag 68:
Varie istruzioni di shift rotazione (non riesco ad incollare...)
Pag 69-75
Molte istruzioni di mascheramento e floating point...
In realtà i flag sono automaticamente conservati quando una ISR viene chiamata. Per cui non si devono salvare e ripristinare.
Giusto! Sono BOCCIATO! :banned: :asd:
Comunque AMD richiede troppe MOP & cicli di clock per PUSHF/POPF/LAHF/SAHF. Intel è messa di gran lunga meglio, e non usa microcodice, a parte per la POPF (per ovvie ragioni), che comunque richiede di gran lunga meno uop rispetto ad AMD.
Immagino...
C'è da dire che Intel è messa molto meglio di AMD per quanto riguarda crittografia e REPs.
Soltanto in quest'ultimo caso vengono generate diverse uop, ma sono decisamente poche, e specialmente se i dati sono allineati in memoria.
Beh, se vedi quelle poco efficienti sono le legacy... Ce ne sono altre che hanno una uop per ogni 16 bytes, più un setup... Meglio non si può fare (con bus a 128 bit... Ovviamente intel ha il bus doppio...)
Comunque riguardo a REP e lock, bisogna anche considerare quanto verranno utilizzate in loop.
Nel primo caso ben poco, perché in genere trasferisci (o riempi) zone di memoria, e vai avanti col codice. Dunque "cachare" le uop non ha senso.
I lock in genere si trovano in mezzo a loop, ma il loop è piccolo e con la finalità di aggiudicarsi la risorsa. Una volta che la risorsa è stata presa, non torni nuovamente in quel loop, ma continui con la sezione critica che farà tutt'altro..
Quindi in questo caso la uop cache viene usata pochissimo, e poi non serve più.
Hai ragione. Il contributo è minimo. Ma almeno in AMD non hai uop cache pollution perchè è una sola uop. In INTEL, se non usi questo trucco, quando incontri qualche mostro di questo ti può svuotare parte della cache uop.
Questo per sottolineare come non si possa pensare "sui massimi sistemi", tenendo conto della feature di per sé, ma bisogna calare sempre il tutto nel mondo reale, e vedere in che modo funzionano le cose, e in che modo / misura possa incidere una particolare feature. :)
Si sa già che Zen non avrà le AVX-512. Come non le ha Skylake, se non in versione server.
Già adesso deve suddividere le istruzioni AVX a 256 bit in 2 parti a 128 bit per eseguirle nelle sue FPU a 128 bit, che non è certo il massimo.
Potrebbe anche fare lo stesso con la AVX-512, spezzandolo in 4 parti a 128 bit, ma non è certo molto efficiente. E comunque non basterebbe, perché le AVX-512 richiedono diverse altre cose per il loro funzionamento (registri di maschera, e supporto per il mascheramento delle lane per l'appunto. Compressed offset a 8 bit. E credo ci sia altra roba), complicando l'implementazione.
Beh, se i 4 decoder possono sparare 4 puntatori alla rom per ciclo, non è che impatta molto: vai di microcodice e via... Forse è per questo che l'hanno fatto questa genialata...
Non so se la sostituirà, con qualcosa di ridisegnato da zero.
Eliminare parti dell'ISA è già possibile, ma finora non l'ha mai fatto. Col codice a 64 bit che è ormai molto diffuso, e che usa quasi sempre le SSE2 (che sono il requisito minimo per x64), l'FPU x87 non è quasi mai utilizzata. Inoltre non ho mai trovato codice MMX (ma non ho disassemblato molte applicazioni: solo alcune molto comuni).
Per cui rimuovere MMX ed FPU x86, specialmente fra 3-4 anni, potrebbe essere fattibile.
Non mi toccare la FPU x87! :O Già ora 64 bit mi stanno stretti... :O E anche 80... :O Power 9 avrà i 128 bit, anche se leggendo il reference manual (si! ho fatto la pazzia di leggerlo tutto! :D ) per questa versione è tutto o quasi in trap, ossia emulazione software, ma hanno gettato le basi per una futura versione hardware. D'altronde anche gli 80 bit su x87 sono più lenti e sulle CPU di bassa potenza (mi pare ad esempio le bobcat e jaguar) addirittura la denormalizzazione è demandata a routine di microcode ROM...
Gioz
23-12-2016, 21:27
VHDL l'ho studiato all'università (e anche il dimensionamento dei MOS), ma non ricordo granchè... :asd:
quando studiavo io non c'erano neanche i fondi per avere qualcosa in laboratorio, per cui nell'esame di logiche programmabili in cui venne trattato l'argomento ricordo di aver fatto dei progetti con il software di simulazione della xilinx (mi pare simulando la programmazione della spartan 3) incappando in un bug che non c'era modo di verificare fisicamente.
ti auguro di aver avuto modo di studiarlo meglio di quanto abbia potuto fare io qualora potesse/dovesse mai servirti.
quando studiavo io non c'erano neanche i fondi per avere qualcosa in laboratorio, per cui nell'esame di logiche programmabili in cui venne trattato l'argomento ricordo di aver fatto dei progetti con il software di simulazione della xilinx (mi pare simulando la programmazione della spartan 3) incappando in un bug che non c'era modo di verificare fisicamente.
ti auguro di aver avuto modo di studiarlo meglio di quanto abbia potuto fare io qualora potesse/dovesse mai servirti.
bjt2
23-12-2016, 21:38
quando studiavo io non c'erano neanche i fondi per avere qualcosa in laboratorio, per cui nell'esame di logiche programmabili in cui venne trattato l'argomento ricordo di aver fatto dei progetti con il software di simulazione della xilinx (mi pare simulando la programmazione della spartan 3) incappando in un bug che non c'era modo di verificare fisicamente.
ti auguro di aver avuto modo di studiarlo meglio di quanto abbia potuto fare io qualora potesse/dovesse mai servirti.
Non ricordo il software ma era un simulatore, dove potevi mettere gli oscilloscopi virtuali in vari punti e vedere i segnali ecc...
ti auguro di aver avuto modo di studiarlo meglio di quanto abbia potuto fare io qualora potesse/dovesse mai servirti.
Non ricordo il software ma era un simulatore, dove potevi mettere gli oscilloscopi virtuali in vari punti e vedere i segnali ecc...
tuttodigitale
23-12-2016, 21:39
Le dichiarazioni di AMD sono di un core Zen che consuma quanto un core XV a parità di clock... Poichè un core XV non esiste, possiamo solo dedurre che 2 core zen consumano quanto un XV monomodulo, oppure un CCX Zen consuma quanto 2 moduli XV (quadcore).
la mia chiave di lettura è proprio questa...
consumo::= 2 core ZEN 14nm = 1 Modulo XV 28nm
ma il primo è su finfet...(-35/55% rispetto al 28nm)
2core ZEN = 1 modulo XV +55% (caso -35%) , ovvero sarebbe da paragonare : ZEN x8/16t vs XV 12 core CMT
2 core ZEN = 1 modulo XV +120% (caso -55%), ovvero sarebbe da paragonare : ZEN x8/16t vs XV 18 core CMT
quando paolo.oliva, dice che per misurare il reale beneficio dell'architettura ZEN, a netto dei finfet, bisognerebbe paragonarlo ad un ipotetico XV con lo stesso numero di thread non ha tutti i torti.
Zen potrebbe consumare quanto un modulo XV già sul 28nm.
mi pare difficile, assai difficile da credere che ZEN X4 @3GHz possa consumare 35W sui 28nm.
Scendendo di 2 nodi e passando al finfet, si guadagna ben più del -50% (metà).
mi sono mantenuto basso....
la verità, può anche non piacere per chi vede il progetto BD nato male ed evoluto peggio, che stando a quanto dichiarato da AMD, ZEN a parità di frequenza, thread e watt migliorerebbe mediamente l'efficienza nel MT del 15% (caso pessimistico -35%), ma potrebbe portare guadagni pari a 0% se non addirittura una leggerissima regressione, se consideriamo che le gpu hanno visto più che dimezzato i consumi a parità di frequenza, di quanto possibile con XV...
in sostanza i progressi resi pubblici fino ad oggi, sembrerebbero praticamente solo merito dei finfet e non di ZEN...."aspettando le prove nel ST":p
Scusa ma nemmeno io capisco la tua risposta al quote del mio post.
dicevi che ZEN dovesse essere molto più efficiente di XV anche sui 28nm, dando la colpa al CMT... i core non sono tutti uguali...non hanno lo stesso consumo (e ahimè neppure le stesse prestazioni)
la mia chiave di lettura è proprio questa...
consumo::= 2 core ZEN 14nm = 1 Modulo XV 28nm
ma il primo è su finfet...(-35/55% rispetto al 28nm)
2core ZEN = 1 modulo XV +55% (caso -35%) , ovvero sarebbe da paragonare : ZEN x8/16t vs XV 12 core CMT
2 core ZEN = 1 modulo XV +120% (caso -55%), ovvero sarebbe da paragonare : ZEN x8/16t vs XV 18 core CMT
quando paolo.oliva, dice che per misurare il reale beneficio dell'architettura ZEN, a netto dei finfet, bisognerebbe paragonarlo ad un ipotetico XV con lo stesso numero di thread non ha tutti i torti.
Zen potrebbe consumare quanto un modulo XV già sul 28nm.
mi pare difficile, assai difficile da credere che ZEN X4 @3GHz possa consumare 35W sui 28nm.
Scendendo di 2 nodi e passando al finfet, si guadagna ben più del -50% (metà).
mi sono mantenuto basso....
la verità, può anche non piacere per chi vede il progetto BD nato male ed evoluto peggio, che stando a quanto dichiarato da AMD, ZEN a parità di frequenza, thread e watt migliorerebbe mediamente l'efficienza nel MT del 15% (caso pessimistico -35%), ma potrebbe portare guadagni pari a 0% se non addirittura una leggerissima regressione, se consideriamo che le gpu hanno visto più che dimezzato i consumi a parità di frequenza, di quanto possibile con XV...
in sostanza i progressi resi pubblici fino ad oggi, sembrerebbero praticamente solo merito dei finfet e non di ZEN...."aspettando le prove nel ST":p
Scusa ma nemmeno io capisco la tua risposta al quote del mio post.
dicevi che ZEN dovesse essere molto più efficiente di XV anche sui 28nm, dando la colpa al CMT... i core non sono tutti uguali...non hanno lo stesso consumo (e ahimè neppure le stesse prestazioni)
george_p
23-12-2016, 22:52
la mia chiave di lettura è proprio questa...
consumo::= 2 core ZEN 14nm = 1 Modulo XV 28nm
ma il primo è su finfet...(-35/55% rispetto al 28nm)
2core ZEN = 1 modulo XV +55% (caso -35%) , ovvero sarebbe da paragonare : ZEN x8/16t vs XV 12 core CMT
2 core ZEN = 1 modulo XV +120% (caso -55%), ovvero sarebbe da paragonare : ZEN x8/16t vs XV 18 core CMT
quando paolo.oliva, dice che per misurare il reale beneficio dell'architettura ZEN, a netto dei finfet, bisognerebbe paragonarlo ad un ipotetico XV con lo stesso numero di thread non ha tutti i torti.
mi pare difficile, assai difficile da credere che ZEN X4 @3GHz possa consumare 35W sui 28nm.
mi sono mantenuto basso....
la verità, può anche non piacere per chi vede il progetto BD nato male ed evoluto peggio, che stando a quanto dichiarato da AMD, ZEN a parità di frequenza, thread e watt migliorerebbe mediamente l'efficienza nel MT del 15% (caso pessimistico -35%), ma potrebbe portare guadagni pari a 0% se non addirittura una leggerissima regressione, se consideriamo che le gpu hanno visto più che dimezzato i consumi a parità di frequenza, di quanto possibile con XV...
in sostanza i progressi resi pubblici fino ad oggi, sembrerebbero praticamente solo merito dei finfet e non di ZEN...."aspettando le prove nel ST":p
dicevi che ZEN dovesse essere molto più efficiente di XV anche sui 28nm, dando la colpa al CMT... i core non sono tutti uguali...non hanno lo stesso consumo (e ahimè neppure le stesse prestazioni)
Più che altro intendo che Zen ha dalla sua un ipc maggiore rispetto a quanto aveva BD appena uscito. Ma soprattutto BD aveva un ipc ben inferiore alla sua precedente.
Quindi, oggi con il silicio adeguato anche se non eccellente possiamo disporre di un buon ipc alla stessa frequenza di thuban e BD, mica noccioline.
Quindi un pò per logica mi viene da pensare che se Zen davvero raggiunge queste frequenze con otto core a 95 w di tdp sul 14 perché non dovrebbe come esacore anche a 125 sul 32 o sul 28nm?
Semplice logica, e visto che tanto speculazione per speculazione.
Poi, gli ingegneri di Zen hanno progettato l'architettura basandosi sui pp più piccoli di 28. Ma ciò che conta è che hanno aumentato di nuovo l'ipc mentre in BD hanno riportato indietro di 4 anni all'epoca.
consumo::= 2 core ZEN 14nm = 1 Modulo XV 28nm
ma il primo è su finfet...(-35/55% rispetto al 28nm)
2core ZEN = 1 modulo XV +55% (caso -35%) , ovvero sarebbe da paragonare : ZEN x8/16t vs XV 12 core CMT
2 core ZEN = 1 modulo XV +120% (caso -55%), ovvero sarebbe da paragonare : ZEN x8/16t vs XV 18 core CMT
quando paolo.oliva, dice che per misurare il reale beneficio dell'architettura ZEN, a netto dei finfet, bisognerebbe paragonarlo ad un ipotetico XV con lo stesso numero di thread non ha tutti i torti.
mi pare difficile, assai difficile da credere che ZEN X4 @3GHz possa consumare 35W sui 28nm.
mi sono mantenuto basso....
la verità, può anche non piacere per chi vede il progetto BD nato male ed evoluto peggio, che stando a quanto dichiarato da AMD, ZEN a parità di frequenza, thread e watt migliorerebbe mediamente l'efficienza nel MT del 15% (caso pessimistico -35%), ma potrebbe portare guadagni pari a 0% se non addirittura una leggerissima regressione, se consideriamo che le gpu hanno visto più che dimezzato i consumi a parità di frequenza, di quanto possibile con XV...
in sostanza i progressi resi pubblici fino ad oggi, sembrerebbero praticamente solo merito dei finfet e non di ZEN...."aspettando le prove nel ST":p
dicevi che ZEN dovesse essere molto più efficiente di XV anche sui 28nm, dando la colpa al CMT... i core non sono tutti uguali...non hanno lo stesso consumo (e ahimè neppure le stesse prestazioni)
Più che altro intendo che Zen ha dalla sua un ipc maggiore rispetto a quanto aveva BD appena uscito. Ma soprattutto BD aveva un ipc ben inferiore alla sua precedente.
Quindi, oggi con il silicio adeguato anche se non eccellente possiamo disporre di un buon ipc alla stessa frequenza di thuban e BD, mica noccioline.
Quindi un pò per logica mi viene da pensare che se Zen davvero raggiunge queste frequenze con otto core a 95 w di tdp sul 14 perché non dovrebbe come esacore anche a 125 sul 32 o sul 28nm?
Semplice logica, e visto che tanto speculazione per speculazione.
Poi, gli ingegneri di Zen hanno progettato l'architettura basandosi sui pp più piccoli di 28. Ma ciò che conta è che hanno aumentato di nuovo l'ipc mentre in BD hanno riportato indietro di 4 anni all'epoca.
Grizlod®
23-12-2016, 23:29
Più che altro intendo che Zen ha dalla sua un ipc maggiore rispetto a quanto aveva BD appena uscito. Ma soprattutto BD aveva un ipc ben inferiore alla sua precedente.
Quindi, oggi con il silicio adeguato anche se non eccellente possiamo disporre di un buon ipc alla stessa frequenza di thuban e BD, mica noccioline.
Quindi un pò per logica mi viene da pensare che se Zen davvero raggiunge queste frequenze con otto core a 95 w di tdp sul 14 perché non dovrebbe come esacore anche a 125 sul 32 o sul 28nm?
Semplice logica, e visto che tanto speculazione per speculazione.
Poi, gli ingegneri di Zen hanno progettato l'architettura basandosi sui pp più piccoli di 28. Ma ciò che conta è che hanno aumentato di nuovo l'ipc mentre in BD hanno riportato indietro di 4 anni all'epoca.Non credo ci sarebbe stato lo stesso quantitativo di L3 e forse neppure l'HW per l'SMT.
Inoltre, maggior area, quindi minor resa sul wafer ed anche problemi a salire in OC.
IMO interessantissima la feature dell' overclock automatico rilevando la temperatura (*), ed in ambito server, se non ricordo male, il minichip ARM di cifratura.
* pensando alla stragrande maggioranza di utenti che neppure ci pensano o neanche ne hanno mai sentito parlare.
Quindi, oggi con il silicio adeguato anche se non eccellente possiamo disporre di un buon ipc alla stessa frequenza di thuban e BD, mica noccioline.
Quindi un pò per logica mi viene da pensare che se Zen davvero raggiunge queste frequenze con otto core a 95 w di tdp sul 14 perché non dovrebbe come esacore anche a 125 sul 32 o sul 28nm?
Semplice logica, e visto che tanto speculazione per speculazione.
Poi, gli ingegneri di Zen hanno progettato l'architettura basandosi sui pp più piccoli di 28. Ma ciò che conta è che hanno aumentato di nuovo l'ipc mentre in BD hanno riportato indietro di 4 anni all'epoca.Non credo ci sarebbe stato lo stesso quantitativo di L3 e forse neppure l'HW per l'SMT.
Inoltre, maggior area, quindi minor resa sul wafer ed anche problemi a salire in OC.
IMO interessantissima la feature dell' overclock automatico rilevando la temperatura (*), ed in ambito server, se non ricordo male, il minichip ARM di cifratura.
* pensando alla stragrande maggioranza di utenti che neppure ci pensano o neanche ne hanno mai sentito parlare.
paolo.oliva2
23-12-2016, 23:29
la mia chiave di lettura è proprio questa...
consumo::= 2 core ZEN 14nm = 1 Modulo XV 28nm
ma il primo è su finfet...(-35/55% rispetto al 28nm)
2core ZEN = 1 modulo XV +55% (caso -35%) , ovvero sarebbe da paragonare : ZEN x8/16t vs XV 12 core CMT
2 core ZEN = 1 modulo XV +120% (caso -55%), ovvero sarebbe da paragonare : ZEN x8/16t vs XV 18 core CMT
quando paolo.oliva, dice che per misurare il reale beneficio dell'architettura ZEN, a netto dei finfet, bisognerebbe paragonarlo ad un ipotetico XV con lo stesso numero di thread non ha tutti i torti.
Comunque la si gira, se XV dal 32nm (ipotetico) al 14nm raddoppierebbe i core, è ovvio che Zen li dimezzerebbe, quindi più di Zen X4+4 sul 32nm cosa ci scapperebbe? Anche perchè Zen, essendo a multipli di X4, o ci sta un X8 o ci sta X4, X6 non può esistere... nativamente. Sarebbe come ipotizzare un BD X9.
Ancora non è detta l'ultima parola per le frequenze finali e per il top magari con una selezione plus, stile 9590.
Comunque ancora non ho capito i reali margini (o limiti :D) del 14nm... da 3,5GHz def a 3,9GHz Turbo, ci sono +500MHz, va bene che è un X8 e quindi il margine di TDP è molto (da X8 a X1 o X2...), ma in fin dei conti il margine è inferiore rispetto ad Intel, perchè comunque il funzionamento è 95W massimi, in Intel è 140W, eppure da frequenza def alla massima ci sarebbe sempre un range di 500MHz.
Comunque io sono convinto che AMD voglia piazzare Zen come 95W per far risaltare = TDP degli i7 X4, ma io ho un X8. Altrimenti, se volesse piazzare un Zen vs gli E Intel, avrebbe potuto impostare Zen 140W, se proprio il PP silicio facesse perdere efficienza, giocare la carta di 3 CCX.
Io spero, per AMD, che non faccia un procio né carne nè pesce. Cioè, se castri un X8 a 95W, si può correre il rischio di un TDP troppo basso per competere con gli E Intel, ma frequenze troppo inferiori agli i7 X4, rischierebbe di perdere in marketing, perchè Intel la promozione ai propri proci la sa fare e bene, li intorterebbe più che bene.
Se rinuncia a Zen X4 X86 nativo, la carta prezzo la gioca di sicuro.
consumo::= 2 core ZEN 14nm = 1 Modulo XV 28nm
ma il primo è su finfet...(-35/55% rispetto al 28nm)
2core ZEN = 1 modulo XV +55% (caso -35%) , ovvero sarebbe da paragonare : ZEN x8/16t vs XV 12 core CMT
2 core ZEN = 1 modulo XV +120% (caso -55%), ovvero sarebbe da paragonare : ZEN x8/16t vs XV 18 core CMT
quando paolo.oliva, dice che per misurare il reale beneficio dell'architettura ZEN, a netto dei finfet, bisognerebbe paragonarlo ad un ipotetico XV con lo stesso numero di thread non ha tutti i torti.
Comunque la si gira, se XV dal 32nm (ipotetico) al 14nm raddoppierebbe i core, è ovvio che Zen li dimezzerebbe, quindi più di Zen X4+4 sul 32nm cosa ci scapperebbe? Anche perchè Zen, essendo a multipli di X4, o ci sta un X8 o ci sta X4, X6 non può esistere... nativamente. Sarebbe come ipotizzare un BD X9.
Ancora non è detta l'ultima parola per le frequenze finali e per il top magari con una selezione plus, stile 9590.
Comunque ancora non ho capito i reali margini (o limiti :D) del 14nm... da 3,5GHz def a 3,9GHz Turbo, ci sono +500MHz, va bene che è un X8 e quindi il margine di TDP è molto (da X8 a X1 o X2...), ma in fin dei conti il margine è inferiore rispetto ad Intel, perchè comunque il funzionamento è 95W massimi, in Intel è 140W, eppure da frequenza def alla massima ci sarebbe sempre un range di 500MHz.
Comunque io sono convinto che AMD voglia piazzare Zen come 95W per far risaltare = TDP degli i7 X4, ma io ho un X8. Altrimenti, se volesse piazzare un Zen vs gli E Intel, avrebbe potuto impostare Zen 140W, se proprio il PP silicio facesse perdere efficienza, giocare la carta di 3 CCX.
Io spero, per AMD, che non faccia un procio né carne nè pesce. Cioè, se castri un X8 a 95W, si può correre il rischio di un TDP troppo basso per competere con gli E Intel, ma frequenze troppo inferiori agli i7 X4, rischierebbe di perdere in marketing, perchè Intel la promozione ai propri proci la sa fare e bene, li intorterebbe più che bene.
Se rinuncia a Zen X4 X86 nativo, la carta prezzo la gioca di sicuro.
paolo.oliva2
23-12-2016, 23:43
Beh, se la prima infornata avrà 3.5-3.6 base, metti le seconde infornate, metti il 14nmHP, metti il 7nm GF, metti Zen+ con ulteriori migliorie e l'SMT4, hai voglia a strada che deve fare INTEL per recuperare... :D Prevedo che già sul 14nm si arrivi a superare i 4GHz base (magari solo sull'HP) e sul 7nm qualcosina in più... Poi un po' di IPC in più con zen+
Per quello che si è visto, penso più che AMD abbia fatto vedere dove Zen è più performante rispetto a che abbia giocato a nascondino facendo vedere meno potenzialità, ma alla fine, sembra equo un Zen +10% di frequenza e -10% di IPC, con risultato finale abbastanza simili... il che è una vittoria, considerando l'architettura Zen acerba e il 14nm GF inferiore a quello Intel.
Ora è tutta nelle mani AMD, se commercializzasse Zen ai prezzi dei rumors, non basterebbe GF e Samsung, dovrebbe far produrre anche a TSMC :).
Certo che se promuovesse Zen con abbianata una RX 480, come ha fatto per gli i5... Lo sai che pensando male... il fatto di fare un pacchetto i5 + RX480, mi sa tanto di messaggio tipo "non calare troppo il prezzo dei proci ed io in cambio ti faccio vendere un tot di VGA in bandle ai miei proci...".
Per quello che si è visto, penso più che AMD abbia fatto vedere dove Zen è più performante rispetto a che abbia giocato a nascondino facendo vedere meno potenzialità, ma alla fine, sembra equo un Zen +10% di frequenza e -10% di IPC, con risultato finale abbastanza simili... il che è una vittoria, considerando l'architettura Zen acerba e il 14nm GF inferiore a quello Intel.
Ora è tutta nelle mani AMD, se commercializzasse Zen ai prezzi dei rumors, non basterebbe GF e Samsung, dovrebbe far produrre anche a TSMC :).
Certo che se promuovesse Zen con abbianata una RX 480, come ha fatto per gli i5... Lo sai che pensando male... il fatto di fare un pacchetto i5 + RX480, mi sa tanto di messaggio tipo "non calare troppo il prezzo dei proci ed io in cambio ti faccio vendere un tot di VGA in bandle ai miei proci...".
george_p
24-12-2016, 01:36
Non credo ci sarebbe stato lo stesso quantitativo di L3 e forse neppure l'HW per l'SMT.
Inoltre, maggior area, quindi minor resa sul wafer ed anche problemi a salire in OC.
IMO interessantissima la feature dell' overclock automatico rilevando la temperatura (*), ed in ambito server, se non ricordo male, il minichip ARM di cifratura.
* pensando alla stragrande maggioranza di utenti che neppure ci pensano o neanche ne hanno mai sentito parlare.
Speculazione personale la mia, e ogni progetto ha una sua storia dietro, se Keller e soci avessero lavorato al posto di Meyer avrebbero tirato fuori una cpu diversa da BD e Zen non sarebbe mai esistito.
Ciò che conta oggi è che Zen sia competitivo sul processo per il quale è stato progettato, tutto il resto è solo speculazione che non vedrà mai luce.
Inoltre, maggior area, quindi minor resa sul wafer ed anche problemi a salire in OC.
IMO interessantissima la feature dell' overclock automatico rilevando la temperatura (*), ed in ambito server, se non ricordo male, il minichip ARM di cifratura.
* pensando alla stragrande maggioranza di utenti che neppure ci pensano o neanche ne hanno mai sentito parlare.
Speculazione personale la mia, e ogni progetto ha una sua storia dietro, se Keller e soci avessero lavorato al posto di Meyer avrebbero tirato fuori una cpu diversa da BD e Zen non sarebbe mai esistito.
Ciò che conta oggi è che Zen sia competitivo sul processo per il quale è stato progettato, tutto il resto è solo speculazione che non vedrà mai luce.
bomkill
24-12-2016, 02:06
[QUOTE=paolo.oliva2
Certo che se promuovesse Zen con abbianata una RX 480, come ha fatto per gli i5... Lo sai che pensando male... il fatto di fare un pacchetto i5 + RX480, mi sa tanto di messaggio tipo "non calare troppo il prezzo dei proci ed io in cambio ti faccio vendere un tot di VGA in bandle ai miei proci...".[/QUOTE]
A questo non avevo pensato anche se sarebbe suicida per Amd tenere i prezzi allineati o poco inferiori a Intel,certo che un bundle zen+polaris/vega con un sostanziale sconto non sarebbe male
Certo che se promuovesse Zen con abbianata una RX 480, come ha fatto per gli i5... Lo sai che pensando male... il fatto di fare un pacchetto i5 + RX480, mi sa tanto di messaggio tipo "non calare troppo il prezzo dei proci ed io in cambio ti faccio vendere un tot di VGA in bandle ai miei proci...".[/QUOTE]
A questo non avevo pensato anche se sarebbe suicida per Amd tenere i prezzi allineati o poco inferiori a Intel,certo che un bundle zen+polaris/vega con un sostanziale sconto non sarebbe male
fabius21
24-12-2016, 02:06
IMO interessantissima la feature dell' overclock automatico rilevando la temperatura (*), ed in ambito server, se non ricordo male, il minichip ARM di cifratura.
* pensando alla stragrande maggioranza di utenti che neppure ci pensano o neanche ne hanno mai sentito parlare.
Il mio amico non mi permette di overcloccargli il suo q6600 ed ha un noctua girantesco :muro: :muro:
* pensando alla stragrande maggioranza di utenti che neppure ci pensano o neanche ne hanno mai sentito parlare.
Il mio amico non mi permette di overcloccargli il suo q6600 ed ha un noctua girantesco :muro: :muro:
cdimauro
24-12-2016, 05:56
Beh, a memoria, ho ricordi vaghi che le unità non erano fully pipelined. Ora mi ricordo che basta vedere le tabelle del PDF di Agner Fog e guardare la colonna del 1/throughput. Se è dello stesso ordine di grandezza della latenza (o qualche ciclo meno) allora non è pipelined, perchè vuol dire che deve terminare tutta l'esecuzione prima di poterne fare un'altra (e ovviamente blocca tutta la pipeline)
Le DIV (intere) a 64 bit (e solo queste) non sono pipelined (su Broadwell e Skylake), e probabilmente anche le SQRT (SIMD; ma Skylake fa molto meglio di Broadwell, e sembra non pipelined solo la versione vettoriale a doppia precisione e a 256 bit) ma non il loro reciproco.
Beh, penso che una volta pubblicate le informazioni di instlat86, tempo un paio di giorni e ci sarà la nuova patch...
Sì, ma la cosa strana è che sarebbe dovuta essere AMD a fornire fin da principio la patch corretta: se non lo sa lei qual è la latenza (e throughput) delle sue istruzioni. :p
Penso che sia per un fatto di uniformità: nel manuale di Fog ci sono tante CPU, comprese low power, knight xxx, mi pare anche il pentium 4 e magari per loro la distinzione ha senso.
Vedi sopra: l'unica ipotesi è che utilizzino le DIV per differenziare. E' l'unico caso in cui le versioni a 64 bit si comportano peggio (sembrano non pipelined, appunto) delle versioni con meno bit.
VHDL l'ho studiato all'università (e anche il dimensionamento dei MOS), ma non ricordo granchè... :asd:
Azz. Pensavo di averti adescato, e m'è andata buca. :asd:
Ma è una specie di subset/superset di x86? :eek:
Superset, perché include tutte le istruzioni x86, più diverse altre (e parecchie altre modalità d'indirizzamento: ho perfino pre-post incremento e decremento, e l'aggiornamento del registro base. E altro ancora :cool:).
Subset nell'implementazione, perché quasi tutte quelle legacy le ho relegate in un settore "low-performance": le eseguo, ma a velocità molto minore.
L'obiettivo è di garantire comunque l'esecuzione di qualunque tipo di istruzione, ma per il vecchiume c'è una penalità da pagare.
L'architettura è anche compatibile al 100% in assembly con x86 e x64, a patto di rimanere interamente a livello di sorgente. Ergo: niente uso di codice binario inserito nell'assembly (DB etc.) o facendo assunzioni sulla struttura degli opcode, ecc.
Quindi è possibile ricompilare tranquillamente quasi tutte le applicazioni x86 e x64 esistenti, e girano senza problemi (molto meglio. Densità nettamente migliore per codice a 64 bit, comparato a x64. E solo leggermente superiore con codice a 32 bit, comparato con x86). Fatta eccezione per quelle che ricadono nei casi di cui sopra (es: che fanno uso di JITer che generano ed eseguono dinamicamente codice macchina).
Le mie elugubrazioni erano più per una CISC (ovviamente con motore RISC) completamente ortogonale dove ogni operando aveva il tipo annesso ed erano automaticamente emesse le uop di conversione se il tipo dei vari operandi era diverso. Istruzioni a 0-4 operandi, dove ogni operando aveva campi di bit per tipo, modo indirizzamento e dati, avevo anche calcolato i bit ecc...
Troppo complicato, e non sarebbe abbastanza performante. Certo, nei soli casi in cui ha una conversione di tipo, guadagneresti, ma non sono casi comuni. Sicuramente non tali da giustificare una notevole complessità per implementare i tuoi core.
Da questo punto di vista ho preferito utilizzare un approccio più conservativo / tradizionale: l'ISA è molto simile alle attuali x64, ARM64, POWER.
Non è ortogonale, perché non potevo "ortogonalizzare" tutto, ma ritengo che da questo punto di vista sia un ottimo compromesso. Le eccezioni che i compilatori devono gestire sono poche, anche se alcune sono particolari.
Già dall'abstract vedo che mi ha copiato l'indirizzamento... :asd: Anche a me è sempre stata antipatica la paginazione e pensavo di dividere in range lo spazio, il tutto da mettere in registri interni del processore... La PTE coalescing è l'adattamento della mia idea alla paginazione, senza modificare i SO correnti, quindi con granularità 4KB, ma limite di 8 pagine alla volta...
Suggerirei ad AMD di modificare le TLB in modo da mettere pagina iniziale e finale e quindi non limitarsi a range di 8 pagine...
Abbiamo le stesse idee. Io adoro la segmentazione per questo. :D
Ma mentre per codice e segmento di dati le dimensioni sono GENERALMENTE (vedi jiter et similia) statici, per l'heap e lo stack non è così: si espandono e contraggono. E la paginazione qui è veramente comoda.
Oltre al fatto che con la paginazione è più facile gestire la memoria virtuale (swap et similia) e fare altre cosucce interessanti.
Purtroppo non c'è una soluzione universale per tutto: segmentazione e paginazione hanno i loro pregi e difetti, e ha senso che esistano entrambe.
Comunque l'idea di accorpare le pagine è buona. Ma generalizzarla a qualunque dimensione (non solo 8 pagine alla volta) la vedo complicata a livello implementativo.
Qualcuna ce n'è:
Ad esempio:
Pag 67:
DIV r8/m8 9 17-22 13-17 EX0
DIV r16/m16 7 15-25 15-25 EX0
IDIV r8/m8 9 17-22 13-17 EX0
IDIV r16/m16 7 14-25 14-24 EX0
9 e 7 MOPs
Pag 68:
Varie istruzioni di shift rotazione (non riesco ad incollare...)
Pag 69-75
Molte istruzioni di mascheramento e floating point...
Sì, è vero. Ma prima ti rispondevo solo sulla SQRT. :stordita:
Hai ragione. Il contributo è minimo. Ma almeno in AMD non hai uop cache pollution perchè è una sola uop. In INTEL, se non usi questo trucco, quando incontri qualche mostro di questo ti può svuotare parte della cache uop.
Non è un problema proprio per il contesto di cui parlavo prima: la cache verrebbe comunque ripulita immediatamente dopo l'uso, perché il processore farebbe altro.
Beh, se i 4 decoder possono sparare 4 puntatori alla rom per ciclo, non è che impatta molto: vai di microcodice e via... Forse è per questo che l'hanno fatto questa genialata...
AMD ha molti più casi di questo tipo (perché ha un massimo di 2MOP per istruzioni), ed è anche per questo che ha 4 decoder complessi. Per cui ha senso quest'approccio.
Non mi toccare la FPU x87! :O Già ora 64 bit mi stanno stretti... :O E anche 80... :O Power 9 avrà i 128 bit, anche se leggendo il reference manual (si! ho fatto la pazzia di leggerlo tutto! :D ) per questa versione è tutto o quasi in trap, ossia emulazione software, ma hanno gettato le basi per una futura versione hardware. D'altronde anche gli 80 bit su x87 sono più lenti e sulle CPU di bassa potenza (mi pare ad esempio le bobcat e jaguar) addirittura la denormalizzazione è demandata a routine di microcode ROM...
Tranquillo: non te li tocco i 128 bit. So bene quanto sia importante poter eseguire calcoli con una precisione più elevata.
Infatti l'unità SIMD della mia architettura è completamente ortogonale da questo punto di vista, e supporta float a 16/32/64/128 bit e interi a 8/16/32/64, in versione packed o scalare.
Questo proprio in previsione di supportare i settori HPC (128 bit) e machine learning / AI (16 bit spesso sono sufficienti qui).
E come densità di codice è leggermente inferiore ad AVX (che ha max 16 registri), ma meglio di AVX-512 (32 registri), ma usando 64 registri (fino a 128 con un altro meccanismo, comunque trasparente, ma che fa aumentare la dimensione delle istruzioni).
:cool:
Buondì a tutti.
Le DIV (intere) a 64 bit (e solo queste) non sono pipelined (su Broadwell e Skylake), e probabilmente anche le SQRT (SIMD; ma Skylake fa molto meglio di Broadwell, e sembra non pipelined solo la versione vettoriale a doppia precisione e a 256 bit) ma non il loro reciproco.
Beh, penso che una volta pubblicate le informazioni di instlat86, tempo un paio di giorni e ci sarà la nuova patch...
Sì, ma la cosa strana è che sarebbe dovuta essere AMD a fornire fin da principio la patch corretta: se non lo sa lei qual è la latenza (e throughput) delle sue istruzioni. :p
Penso che sia per un fatto di uniformità: nel manuale di Fog ci sono tante CPU, comprese low power, knight xxx, mi pare anche il pentium 4 e magari per loro la distinzione ha senso.
Vedi sopra: l'unica ipotesi è che utilizzino le DIV per differenziare. E' l'unico caso in cui le versioni a 64 bit si comportano peggio (sembrano non pipelined, appunto) delle versioni con meno bit.
VHDL l'ho studiato all'università (e anche il dimensionamento dei MOS), ma non ricordo granchè... :asd:
Azz. Pensavo di averti adescato, e m'è andata buca. :asd:
Ma è una specie di subset/superset di x86? :eek:
Superset, perché include tutte le istruzioni x86, più diverse altre (e parecchie altre modalità d'indirizzamento: ho perfino pre-post incremento e decremento, e l'aggiornamento del registro base. E altro ancora :cool:).
Subset nell'implementazione, perché quasi tutte quelle legacy le ho relegate in un settore "low-performance": le eseguo, ma a velocità molto minore.
L'obiettivo è di garantire comunque l'esecuzione di qualunque tipo di istruzione, ma per il vecchiume c'è una penalità da pagare.
L'architettura è anche compatibile al 100% in assembly con x86 e x64, a patto di rimanere interamente a livello di sorgente. Ergo: niente uso di codice binario inserito nell'assembly (DB etc.) o facendo assunzioni sulla struttura degli opcode, ecc.
Quindi è possibile ricompilare tranquillamente quasi tutte le applicazioni x86 e x64 esistenti, e girano senza problemi (molto meglio. Densità nettamente migliore per codice a 64 bit, comparato a x64. E solo leggermente superiore con codice a 32 bit, comparato con x86). Fatta eccezione per quelle che ricadono nei casi di cui sopra (es: che fanno uso di JITer che generano ed eseguono dinamicamente codice macchina).
Le mie elugubrazioni erano più per una CISC (ovviamente con motore RISC) completamente ortogonale dove ogni operando aveva il tipo annesso ed erano automaticamente emesse le uop di conversione se il tipo dei vari operandi era diverso. Istruzioni a 0-4 operandi, dove ogni operando aveva campi di bit per tipo, modo indirizzamento e dati, avevo anche calcolato i bit ecc...
Troppo complicato, e non sarebbe abbastanza performante. Certo, nei soli casi in cui ha una conversione di tipo, guadagneresti, ma non sono casi comuni. Sicuramente non tali da giustificare una notevole complessità per implementare i tuoi core.
Da questo punto di vista ho preferito utilizzare un approccio più conservativo / tradizionale: l'ISA è molto simile alle attuali x64, ARM64, POWER.
Non è ortogonale, perché non potevo "ortogonalizzare" tutto, ma ritengo che da questo punto di vista sia un ottimo compromesso. Le eccezioni che i compilatori devono gestire sono poche, anche se alcune sono particolari.
Già dall'abstract vedo che mi ha copiato l'indirizzamento... :asd: Anche a me è sempre stata antipatica la paginazione e pensavo di dividere in range lo spazio, il tutto da mettere in registri interni del processore... La PTE coalescing è l'adattamento della mia idea alla paginazione, senza modificare i SO correnti, quindi con granularità 4KB, ma limite di 8 pagine alla volta...
Suggerirei ad AMD di modificare le TLB in modo da mettere pagina iniziale e finale e quindi non limitarsi a range di 8 pagine...
Abbiamo le stesse idee. Io adoro la segmentazione per questo. :D
Ma mentre per codice e segmento di dati le dimensioni sono GENERALMENTE (vedi jiter et similia) statici, per l'heap e lo stack non è così: si espandono e contraggono. E la paginazione qui è veramente comoda.
Oltre al fatto che con la paginazione è più facile gestire la memoria virtuale (swap et similia) e fare altre cosucce interessanti.
Purtroppo non c'è una soluzione universale per tutto: segmentazione e paginazione hanno i loro pregi e difetti, e ha senso che esistano entrambe.
Comunque l'idea di accorpare le pagine è buona. Ma generalizzarla a qualunque dimensione (non solo 8 pagine alla volta) la vedo complicata a livello implementativo.
Qualcuna ce n'è:
Ad esempio:
Pag 67:
DIV r8/m8 9 17-22 13-17 EX0
DIV r16/m16 7 15-25 15-25 EX0
IDIV r8/m8 9 17-22 13-17 EX0
IDIV r16/m16 7 14-25 14-24 EX0
9 e 7 MOPs
Pag 68:
Varie istruzioni di shift rotazione (non riesco ad incollare...)
Pag 69-75
Molte istruzioni di mascheramento e floating point...
Sì, è vero. Ma prima ti rispondevo solo sulla SQRT. :stordita:
Hai ragione. Il contributo è minimo. Ma almeno in AMD non hai uop cache pollution perchè è una sola uop. In INTEL, se non usi questo trucco, quando incontri qualche mostro di questo ti può svuotare parte della cache uop.
Non è un problema proprio per il contesto di cui parlavo prima: la cache verrebbe comunque ripulita immediatamente dopo l'uso, perché il processore farebbe altro.
Beh, se i 4 decoder possono sparare 4 puntatori alla rom per ciclo, non è che impatta molto: vai di microcodice e via... Forse è per questo che l'hanno fatto questa genialata...
AMD ha molti più casi di questo tipo (perché ha un massimo di 2MOP per istruzioni), ed è anche per questo che ha 4 decoder complessi. Per cui ha senso quest'approccio.
Non mi toccare la FPU x87! :O Già ora 64 bit mi stanno stretti... :O E anche 80... :O Power 9 avrà i 128 bit, anche se leggendo il reference manual (si! ho fatto la pazzia di leggerlo tutto! :D ) per questa versione è tutto o quasi in trap, ossia emulazione software, ma hanno gettato le basi per una futura versione hardware. D'altronde anche gli 80 bit su x87 sono più lenti e sulle CPU di bassa potenza (mi pare ad esempio le bobcat e jaguar) addirittura la denormalizzazione è demandata a routine di microcode ROM...
Tranquillo: non te li tocco i 128 bit. So bene quanto sia importante poter eseguire calcoli con una precisione più elevata.
Infatti l'unità SIMD della mia architettura è completamente ortogonale da questo punto di vista, e supporta float a 16/32/64/128 bit e interi a 8/16/32/64, in versione packed o scalare.
Questo proprio in previsione di supportare i settori HPC (128 bit) e machine learning / AI (16 bit spesso sono sufficienti qui).
E come densità di codice è leggermente inferiore ad AVX (che ha max 16 registri), ma meglio di AVX-512 (32 registri), ma usando 64 registri (fino a 128 con un altro meccanismo, comunque trasparente, ma che fa aumentare la dimensione delle istruzioni).
:cool:
Buondì a tutti.
Piedone1113
24-12-2016, 08:23
Non so se la sostituirà, con qualcosa di ridisegnato da zero.
Eliminare parti dell'ISA è già possibile, ma finora non l'ha mai fatto. Col codice a 64 bit che è ormai molto diffuso, e che usa quasi sempre le SSE2 (che sono il requisito minimo per x64), l'FPU x87 non è quasi mai utilizzata. Inoltre non ho mai trovato codice MMX (ma non ho disassemblato molte applicazioni: solo alcune molto comuni).
Per cui rimuovere MMX ed FPU x86, specialmente fra 3-4 anni, potrebbe essere fattibile.
Come hai detto anche tu (ed io) non si reinventa la ruota.
X87 difficilmente verrà eliminata (a meno che non la si voglia emulare a livello hardware, ma poi il superPI non farà più testo), le MMX invece andrebbero eliminate e di netto (non credo che esistano software usciti da Vista in poi che abbiano un path esclusivo per MMX).
Certamente mettere mano ad un'architettura per rinnovarla profondamente (e poter quindi meglio sfruttare il silicio disponibile) equivale a riscriverla, tanto vale allora prendere tutto quello che si può adattare e ricreare il resto, aggiungere nuove implementazioni, riconcepire profondamente la cache L3 (che per la miniutarizzazione spinta di adesso e del prossimo futuro saranno sempre di dimensioni più imponenti) e predisporre per cache L4 (sperando che i dati non debbano passare per forza lungo tutta la gerarchia di cache).
Sinceramente sono certo che intel potrebbe presentare una cpu delle stesse prestazioni di un 6950 in meno di 70w sui 10 nm, amd con zen+ invece dovrebbe avere + 20% prestazioni a -30% consumi (e queste sono cose che ho visto nella palla di cristallo)
Eliminare parti dell'ISA è già possibile, ma finora non l'ha mai fatto. Col codice a 64 bit che è ormai molto diffuso, e che usa quasi sempre le SSE2 (che sono il requisito minimo per x64), l'FPU x87 non è quasi mai utilizzata. Inoltre non ho mai trovato codice MMX (ma non ho disassemblato molte applicazioni: solo alcune molto comuni).
Per cui rimuovere MMX ed FPU x86, specialmente fra 3-4 anni, potrebbe essere fattibile.
Come hai detto anche tu (ed io) non si reinventa la ruota.
X87 difficilmente verrà eliminata (a meno che non la si voglia emulare a livello hardware, ma poi il superPI non farà più testo), le MMX invece andrebbero eliminate e di netto (non credo che esistano software usciti da Vista in poi che abbiano un path esclusivo per MMX).
Certamente mettere mano ad un'architettura per rinnovarla profondamente (e poter quindi meglio sfruttare il silicio disponibile) equivale a riscriverla, tanto vale allora prendere tutto quello che si può adattare e ricreare il resto, aggiungere nuove implementazioni, riconcepire profondamente la cache L3 (che per la miniutarizzazione spinta di adesso e del prossimo futuro saranno sempre di dimensioni più imponenti) e predisporre per cache L4 (sperando che i dati non debbano passare per forza lungo tutta la gerarchia di cache).
Sinceramente sono certo che intel potrebbe presentare una cpu delle stesse prestazioni di un 6950 in meno di 70w sui 10 nm, amd con zen+ invece dovrebbe avere + 20% prestazioni a -30% consumi (e queste sono cose che ho visto nella palla di cristallo)
bjt2
24-12-2016, 08:52
Le DIV (intere) a 64 bit (e solo queste) non sono pipelined (su Broadwell e Skylake), e probabilmente anche le SQRT (SIMD; ma Skylake fa molto meglio di Broadwell, e sembra non pipelined solo la versione vettoriale a doppia precisione e a 256 bit) ma non il loro reciproco.
Ecco, questo ero curioso di sapere... :)
Sì, ma la cosa strana è che sarebbe dovuta essere AMD a fornire fin da principio la patch corretta: se non lo sa lei qual è la latenza (e throughput) delle sue istruzioni. :p
E scoprire così le sue carte? Naaaa! Sai perchè? Dalle latenze puoi scoprire se hanno alzato o abbassato il FO4. Siccome tutti quanti (tranne pochi come me :cool: ) davano clock nel range dei 3GHz base max, vuol dire che tutti si aspettavano un alto FO4, secondo il classico schema alta IPC=>alto FO4. Avendo le latenze, se sono alte, o comunque simili a BD, potevi scoprire le carte. In particolare se le latenze mostrassero un FO4 uguale o inferiore a BD, con la proiezione del +40% di IPC e un clock potenzialmente alto (almeno con il 14nm a regime), allora staresti mostrando le tue carte... Potenzialmente il FUD sparato da molta gente su clock disastrosi ha fatto il gioco di AMD e ora potrebbe fare una uscita a sorpresa. Io sono ancora convinto di almeno 3.5 base e almeno 4.5 turbomax più l'XFR. Se così fosse almeno nel breve termine non ci sarebbe neanche bisogno del 4 core, perchè kabylake ha 4.5Ghz di turbomax...
Vedi sopra: l'unica ipotesi è che utilizzino le DIV per differenziare. E' l'unico caso in cui le versioni a 64 bit si comportano peggio (sembrano non pipelined, appunto) delle versioni con meno bit.
E' proprio quello che intendevo...
Azz. Pensavo di averti adescato, e m'è andata buca. :asd:
Beh, sono sempre un ingegniiiiiere ancora nel pieno delle facoltà mentali :asd: (aka ancora niente alzheimer galoppante), quindi se mi dai un manuale lo dovrei capire... :asd:
Superset, perché include tutte le istruzioni x86, più diverse altre (e parecchie altre modalità d'indirizzamento: ho perfino pre-post incremento e decremento, e l'aggiornamento del registro base. E altro ancora :cool:).
Subset nell'implementazione, perché quasi tutte quelle legacy le ho relegate in un settore "low-performance": le eseguo, ma a velocità molto minore.
L'obiettivo è di garantire comunque l'esecuzione di qualunque tipo di istruzione, ma per il vecchiume c'è una penalità da pagare.
L'architettura è anche compatibile al 100% in assembly con x86 e x64, a patto di rimanere interamente a livello di sorgente. Ergo: niente uso di codice binario inserito nell'assembly (DB etc.) o facendo assunzioni sulla struttura degli opcode, ecc.
Quindi è possibile ricompilare tranquillamente quasi tutte le applicazioni x86 e x64 esistenti, e girano senza problemi (molto meglio. Densità nettamente migliore per codice a 64 bit, comparato a x64. E solo leggermente superiore con codice a 32 bit, comparato con x86). Fatta eccezione per quelle che ricadono nei casi di cui sopra (es: che fanno uso di JITer che generano ed eseguono dinamicamente codice macchina).
Quindi se ho capito bene, compatibilità solo a livello di assembly e quindi possibilità di JIT one to one con codice già compilato, con riprogettazione del formato istruzioni, immagino più efficiente e facile da decodificare. Ottima idea... :)
Troppo complicato, e non sarebbe abbastanza performante. Certo, nei soli casi in cui ha una conversione di tipo, guadagneresti, ma non sono casi comuni. Sicuramente non tali da giustificare una notevole complessità per implementare i tuoi core.
Da questo punto di vista ho preferito utilizzare un approccio più conservativo / tradizionale: l'ISA è molto simile alle attuali x64, ARM64, POWER.
Non è ortogonale, perché non potevo "ortogonalizzare" tutto, ma ritengo che da questo punto di vista sia un ottimo compromesso. Le eccezioni che i compilatori devono gestire sono poche, anche se alcune sono particolari.
Ho dimenticato di dire che ho previsto anche un campo di bit per la numerosità. 0= scalare, 1=2 elementi, 2=4, 3=8 ecc e rendere tutto agnostico dalle implementazioni. Es implementazione economica con unità a 64 bit, che trappano per gli FP128 e fanno in una sola uop 1x64, 2x32 ecc e implementazioni high end magari a 256-512 bit, che fanno in un solo clock praticamente tutte le operazioni. Così hai un solo codice denso che gira a varie prestazioni sulle varie implementazioni.
Ma ovviamente la compatibilità con x86 è molto importante. Si può unire il meglio dei due mondi prevedendo TUTTE le istruzioni x86, più quelle che escono fuori dalle mie elugubrazioni, con la compatibilità assembly e la possibilità di fare JIT 1 to 1...
Abbiamo le stesse idee. Io adoro la segmentazione per questo. :D
Ma mentre per codice e segmento di dati le dimensioni sono GENERALMENTE (vedi jiter et similia) statici, per l'heap e lo stack non è così: si espandono e contraggono. E la paginazione qui è veramente comoda.
Oltre al fatto che con la paginazione è più facile gestire la memoria virtuale (swap et similia) e fare altre cosucce interessanti.
Purtroppo non c'è una soluzione universale per tutto: segmentazione e paginazione hanno i loro pregi e difetti, e ha senso che esistano entrambe.
Ma la mia idea era di avere al posto delle TLB, un range di MTTR come i range register, per esempio 64/128 coppie dove hai indirizzo iniziale, finale, permessi e offset. In questo modo il SO si può organizzare anche per lo heap (in genere lo stack frame è preallocato, mi pare ci sia una opzione nel linker o compilatore e di default sia 4MB) e magari sul "segment fault" se i permessi del processo lo permettono, può spostare eventualmente qualcosa e allargare un range già esistente. Non è detto che devi per forza fare 1000 ranges... Diventerebbe una sorta di cache con 64/128 coppie di comparatori.
Ancora meglio invece di MTTRR da impostare a mano, fare una struttura di segment table (invece di page table) in memoria a 1 livello e nei TLB (che a questo punto possono anche essere 16-32 e solo di primo livello) mettere i range, che se il SO è intelligente, come ho detto sopra, possono essere veramente pochi e quindi praticamente non dover andare mai in memoria, tranne la prima volta. Magari al task switch in background possono anche essere caricati nel TLB i segmenti...
Comunque l'idea di accorpare le pagine è buona. Ma generalizzarla a qualunque dimensione (non solo 8 pagine alla volta) la vedo complicata a livello implementativo.
Non è complicato: vedi sopra. Ora semplicemente Zen esclude i 3 bit bassi dal confronto. Con la mia idea deve fare due comparazioni in parallelo per ogni TLB e metterle in AND anzichè una. In pratica potrebbe anche non incrementare il FO4.
Sì, è vero. Ma prima ti rispondevo solo sulla SQRT. :stordita:
Non è un problema proprio per il contesto di cui parlavo prima: la cache verrebbe comunque ripulita immediatamente dopo l'uso, perché il processore farebbe altro.
AMD ha molti più casi di questo tipo (perché ha un massimo di 2MOP per istruzioni), ed è anche per questo che ha 4 decoder complessi. Per cui ha senso quest'approccio.
Tranquillo: non te li tocco i 128 bit. So bene quanto sia importante poter eseguire calcoli con una precisione più elevata.
Infatti l'unità SIMD della mia architettura è completamente ortogonale da questo punto di vista, e supporta float a 16/32/64/128 bit e interi a 8/16/32/64, in versione packed o scalare.
Questo proprio in previsione di supportare i settori HPC (128 bit) e machine learning / AI (16 bit spesso sono sufficienti qui).
E come densità di codice è leggermente inferiore ad AVX (che ha max 16 registri), ma meglio di AVX-512 (32 registri), ma usando 64 registri (fino a 128 con un altro meccanismo, comunque trasparente, ma che fa aumentare la dimensione delle istruzioni).
:cool:
Buondì a tutti.
Interessante. Se non lo hai già fatto, potresti incominciare a scrivere il codice di una JIT x86->tuo formato magari sotto forma di libreria compatibile con i tool in commercio (non so se abbia più senso farlo a livello di assembler o linker), in modo da poter emettere il codice già a livello di compilazione...
Ecco, questo ero curioso di sapere... :)
Sì, ma la cosa strana è che sarebbe dovuta essere AMD a fornire fin da principio la patch corretta: se non lo sa lei qual è la latenza (e throughput) delle sue istruzioni. :p
E scoprire così le sue carte? Naaaa! Sai perchè? Dalle latenze puoi scoprire se hanno alzato o abbassato il FO4. Siccome tutti quanti (tranne pochi come me :cool: ) davano clock nel range dei 3GHz base max, vuol dire che tutti si aspettavano un alto FO4, secondo il classico schema alta IPC=>alto FO4. Avendo le latenze, se sono alte, o comunque simili a BD, potevi scoprire le carte. In particolare se le latenze mostrassero un FO4 uguale o inferiore a BD, con la proiezione del +40% di IPC e un clock potenzialmente alto (almeno con il 14nm a regime), allora staresti mostrando le tue carte... Potenzialmente il FUD sparato da molta gente su clock disastrosi ha fatto il gioco di AMD e ora potrebbe fare una uscita a sorpresa. Io sono ancora convinto di almeno 3.5 base e almeno 4.5 turbomax più l'XFR. Se così fosse almeno nel breve termine non ci sarebbe neanche bisogno del 4 core, perchè kabylake ha 4.5Ghz di turbomax...
Vedi sopra: l'unica ipotesi è che utilizzino le DIV per differenziare. E' l'unico caso in cui le versioni a 64 bit si comportano peggio (sembrano non pipelined, appunto) delle versioni con meno bit.
E' proprio quello che intendevo...
Azz. Pensavo di averti adescato, e m'è andata buca. :asd:
Beh, sono sempre un ingegniiiiiere ancora nel pieno delle facoltà mentali :asd: (aka ancora niente alzheimer galoppante), quindi se mi dai un manuale lo dovrei capire... :asd:
Superset, perché include tutte le istruzioni x86, più diverse altre (e parecchie altre modalità d'indirizzamento: ho perfino pre-post incremento e decremento, e l'aggiornamento del registro base. E altro ancora :cool:).
Subset nell'implementazione, perché quasi tutte quelle legacy le ho relegate in un settore "low-performance": le eseguo, ma a velocità molto minore.
L'obiettivo è di garantire comunque l'esecuzione di qualunque tipo di istruzione, ma per il vecchiume c'è una penalità da pagare.
L'architettura è anche compatibile al 100% in assembly con x86 e x64, a patto di rimanere interamente a livello di sorgente. Ergo: niente uso di codice binario inserito nell'assembly (DB etc.) o facendo assunzioni sulla struttura degli opcode, ecc.
Quindi è possibile ricompilare tranquillamente quasi tutte le applicazioni x86 e x64 esistenti, e girano senza problemi (molto meglio. Densità nettamente migliore per codice a 64 bit, comparato a x64. E solo leggermente superiore con codice a 32 bit, comparato con x86). Fatta eccezione per quelle che ricadono nei casi di cui sopra (es: che fanno uso di JITer che generano ed eseguono dinamicamente codice macchina).
Quindi se ho capito bene, compatibilità solo a livello di assembly e quindi possibilità di JIT one to one con codice già compilato, con riprogettazione del formato istruzioni, immagino più efficiente e facile da decodificare. Ottima idea... :)
Troppo complicato, e non sarebbe abbastanza performante. Certo, nei soli casi in cui ha una conversione di tipo, guadagneresti, ma non sono casi comuni. Sicuramente non tali da giustificare una notevole complessità per implementare i tuoi core.
Da questo punto di vista ho preferito utilizzare un approccio più conservativo / tradizionale: l'ISA è molto simile alle attuali x64, ARM64, POWER.
Non è ortogonale, perché non potevo "ortogonalizzare" tutto, ma ritengo che da questo punto di vista sia un ottimo compromesso. Le eccezioni che i compilatori devono gestire sono poche, anche se alcune sono particolari.
Ho dimenticato di dire che ho previsto anche un campo di bit per la numerosità. 0= scalare, 1=2 elementi, 2=4, 3=8 ecc e rendere tutto agnostico dalle implementazioni. Es implementazione economica con unità a 64 bit, che trappano per gli FP128 e fanno in una sola uop 1x64, 2x32 ecc e implementazioni high end magari a 256-512 bit, che fanno in un solo clock praticamente tutte le operazioni. Così hai un solo codice denso che gira a varie prestazioni sulle varie implementazioni.
Ma ovviamente la compatibilità con x86 è molto importante. Si può unire il meglio dei due mondi prevedendo TUTTE le istruzioni x86, più quelle che escono fuori dalle mie elugubrazioni, con la compatibilità assembly e la possibilità di fare JIT 1 to 1...
Abbiamo le stesse idee. Io adoro la segmentazione per questo. :D
Ma mentre per codice e segmento di dati le dimensioni sono GENERALMENTE (vedi jiter et similia) statici, per l'heap e lo stack non è così: si espandono e contraggono. E la paginazione qui è veramente comoda.
Oltre al fatto che con la paginazione è più facile gestire la memoria virtuale (swap et similia) e fare altre cosucce interessanti.
Purtroppo non c'è una soluzione universale per tutto: segmentazione e paginazione hanno i loro pregi e difetti, e ha senso che esistano entrambe.
Ma la mia idea era di avere al posto delle TLB, un range di MTTR come i range register, per esempio 64/128 coppie dove hai indirizzo iniziale, finale, permessi e offset. In questo modo il SO si può organizzare anche per lo heap (in genere lo stack frame è preallocato, mi pare ci sia una opzione nel linker o compilatore e di default sia 4MB) e magari sul "segment fault" se i permessi del processo lo permettono, può spostare eventualmente qualcosa e allargare un range già esistente. Non è detto che devi per forza fare 1000 ranges... Diventerebbe una sorta di cache con 64/128 coppie di comparatori.
Ancora meglio invece di MTTRR da impostare a mano, fare una struttura di segment table (invece di page table) in memoria a 1 livello e nei TLB (che a questo punto possono anche essere 16-32 e solo di primo livello) mettere i range, che se il SO è intelligente, come ho detto sopra, possono essere veramente pochi e quindi praticamente non dover andare mai in memoria, tranne la prima volta. Magari al task switch in background possono anche essere caricati nel TLB i segmenti...
Comunque l'idea di accorpare le pagine è buona. Ma generalizzarla a qualunque dimensione (non solo 8 pagine alla volta) la vedo complicata a livello implementativo.
Non è complicato: vedi sopra. Ora semplicemente Zen esclude i 3 bit bassi dal confronto. Con la mia idea deve fare due comparazioni in parallelo per ogni TLB e metterle in AND anzichè una. In pratica potrebbe anche non incrementare il FO4.
Sì, è vero. Ma prima ti rispondevo solo sulla SQRT. :stordita:
Non è un problema proprio per il contesto di cui parlavo prima: la cache verrebbe comunque ripulita immediatamente dopo l'uso, perché il processore farebbe altro.
AMD ha molti più casi di questo tipo (perché ha un massimo di 2MOP per istruzioni), ed è anche per questo che ha 4 decoder complessi. Per cui ha senso quest'approccio.
Tranquillo: non te li tocco i 128 bit. So bene quanto sia importante poter eseguire calcoli con una precisione più elevata.
Infatti l'unità SIMD della mia architettura è completamente ortogonale da questo punto di vista, e supporta float a 16/32/64/128 bit e interi a 8/16/32/64, in versione packed o scalare.
Questo proprio in previsione di supportare i settori HPC (128 bit) e machine learning / AI (16 bit spesso sono sufficienti qui).
E come densità di codice è leggermente inferiore ad AVX (che ha max 16 registri), ma meglio di AVX-512 (32 registri), ma usando 64 registri (fino a 128 con un altro meccanismo, comunque trasparente, ma che fa aumentare la dimensione delle istruzioni).
:cool:
Buondì a tutti.
Interessante. Se non lo hai già fatto, potresti incominciare a scrivere il codice di una JIT x86->tuo formato magari sotto forma di libreria compatibile con i tool in commercio (non so se abbia più senso farlo a livello di assembler o linker), in modo da poter emettere il codice già a livello di compilazione...
bjt2
24-12-2016, 08:59
Come hai detto anche tu (ed io) non si reinventa la ruota.
X87 difficilmente verrà eliminata (a meno che non la si voglia emulare a livello hardware, ma poi il superPI non farà più testo), le MMX invece andrebbero eliminate e di netto (non credo che esistano software usciti da Vista in poi che abbiano un path esclusivo per MMX).
Certamente mettere mano ad un'architettura per rinnovarla profondamente (e poter quindi meglio sfruttare il silicio disponibile) equivale a riscriverla, tanto vale allora prendere tutto quello che si può adattare e ricreare il resto, aggiungere nuove implementazioni, riconcepire profondamente la cache L3 (che per la miniutarizzazione spinta di adesso e del prossimo futuro saranno sempre di dimensioni più imponenti) e predisporre per cache L4 (sperando che i dati non debbano passare per forza lungo tutta la gerarchia di cache).
Sinceramente sono certo che intel potrebbe presentare una cpu delle stesse prestazioni di un 6950 in meno di 70w sui 10 nm, amd con zen+ invece dovrebbe avere + 20% prestazioni a -30% consumi (e queste sono cose che ho visto nella palla di cristallo)
Tutte le estensioni hanno un bit nella CPUID che deve essere controlalto prima di iniziare. I software scritti correttamente semplicemente o terminano o usano un path 386/486 e quindi girano più lenti. ma se sono così vecchi, probabilmente erano progettati per CPU a 200-300MHz max e comunque volerebbero su CPU a 4Ghz. Analogamente l'x87, pochè ai tempi del 386 era un coprocessore opzionale, è fatto fin dalla fondamenta come trappabile con routine di emulazione software. Se ci sono software che usano qualche feature x87, si può avere una routine software. In realtà anche le CPU correnti fanno una cosa del genere, ma con microcodice: non sprecano area chip per cose oscure x87, ma c'è micorocodice. Ad esempio le funzioni trascendenti hanno microcodice di più di 200 uops!
X87 difficilmente verrà eliminata (a meno che non la si voglia emulare a livello hardware, ma poi il superPI non farà più testo), le MMX invece andrebbero eliminate e di netto (non credo che esistano software usciti da Vista in poi che abbiano un path esclusivo per MMX).
Certamente mettere mano ad un'architettura per rinnovarla profondamente (e poter quindi meglio sfruttare il silicio disponibile) equivale a riscriverla, tanto vale allora prendere tutto quello che si può adattare e ricreare il resto, aggiungere nuove implementazioni, riconcepire profondamente la cache L3 (che per la miniutarizzazione spinta di adesso e del prossimo futuro saranno sempre di dimensioni più imponenti) e predisporre per cache L4 (sperando che i dati non debbano passare per forza lungo tutta la gerarchia di cache).
Sinceramente sono certo che intel potrebbe presentare una cpu delle stesse prestazioni di un 6950 in meno di 70w sui 10 nm, amd con zen+ invece dovrebbe avere + 20% prestazioni a -30% consumi (e queste sono cose che ho visto nella palla di cristallo)
Tutte le estensioni hanno un bit nella CPUID che deve essere controlalto prima di iniziare. I software scritti correttamente semplicemente o terminano o usano un path 386/486 e quindi girano più lenti. ma se sono così vecchi, probabilmente erano progettati per CPU a 200-300MHz max e comunque volerebbero su CPU a 4Ghz. Analogamente l'x87, pochè ai tempi del 386 era un coprocessore opzionale, è fatto fin dalla fondamenta come trappabile con routine di emulazione software. Se ci sono software che usano qualche feature x87, si può avere una routine software. In realtà anche le CPU correnti fanno una cosa del genere, ma con microcodice: non sprecano area chip per cose oscure x87, ma c'è micorocodice. Ad esempio le funzioni trascendenti hanno microcodice di più di 200 uops!
Ale55andr0
24-12-2016, 09:31
http://wccftech.com/amd-ryzen-review-leaked/
Stessero così le cose, aggiungendo i 3.4+ ghz finali rispetto i 3.15 di questo presunto bench, a me andrebbe benissimo, se i prezzi fossero quelli in tabella...un affare colossale un sr7 a 350 cartoni di listino
Stessero così le cose, aggiungendo i 3.4+ ghz finali rispetto i 3.15 di questo presunto bench, a me andrebbe benissimo, se i prezzi fossero quelli in tabella...un affare colossale un sr7 a 350 cartoni di listino
digieffe
24-12-2016, 09:47
@bjt2
non puoi fare delle freq. di un 8 core le stesse di un 4 per via del tdp: pronosticai 3.2 base ma solo per il tdp di 95w, per un 125 3.7 base, aggiungo per un 140w 4.0 base limiti del silicio permettendo. è ovvio che un 4c nativo dovrà andare almeno 200mhz (4.4) in più di BR ma a quale tdp? non di certo 65w.
il problema resta il tdp e dove mura il silicio.
non puoi fare delle freq. di un 8 core le stesse di un 4 per via del tdp: pronosticai 3.2 base ma solo per il tdp di 95w, per un 125 3.7 base, aggiungo per un 140w 4.0 base limiti del silicio permettendo. è ovvio che un 4c nativo dovrà andare almeno 200mhz (4.4) in più di BR ma a quale tdp? non di certo 65w.
il problema resta il tdp e dove mura il silicio.
.338 lapua magnum
24-12-2016, 09:50
http://wccftech.com/amd-ryzen-review-leaked/
Stessero così le cose, aggiungendo i 3.4+ ghz finali rispetto i 3.15 di questo presunto bench, a me andrebbe benissimo, se i prezzi fossero quelli in tabella...un affare colossale un sr7 a 350 cartoni di listino
prestazioni nulla da dire
quello che mi preoccupa è la tabella della lineup sr7 e sr7 BE (a 500€)
l'sr5 che dovrebbe essere quello più equilibrato tra freq e core, la sua variante BE, (se mai ci sarà) affianca il sr7 liscio con il prezzo? :eek:
sono rumors, però non ho intenzione di sganciare centoni in più per l'oc stile intel.
abituati troppo bene con gli fx tutti BE :D , però per me così non ci siamo.
Stessero così le cose, aggiungendo i 3.4+ ghz finali rispetto i 3.15 di questo presunto bench, a me andrebbe benissimo, se i prezzi fossero quelli in tabella...un affare colossale un sr7 a 350 cartoni di listino
prestazioni nulla da dire
quello che mi preoccupa è la tabella della lineup sr7 e sr7 BE (a 500€)
l'sr5 che dovrebbe essere quello più equilibrato tra freq e core, la sua variante BE, (se mai ci sarà) affianca il sr7 liscio con il prezzo? :eek:
sono rumors, però non ho intenzione di sganciare centoni in più per l'oc stile intel.
abituati troppo bene con gli fx tutti BE :D , però per me così non ci siamo.
Roland74Fun
24-12-2016, 10:30
Ahah! mi hai fatto rotolare dalle risate! :D
Quello che a me "preoccupa" di più è quando queste "dinamiche" (mi hanno detto, ho sentito, ho letto su internet, blabla) vengono applicate in campi un po' più "seri" dell'informatica...:doh:
Comunque MENO MALE che esistono posti come questo, in cui si discute (anche troppo, a volte) seriamente... Anche di SOI e Bulk :D
Tipo quelli, ho letto su facebbok che agli immigrati danno la casa i soldi le sigarette, l'iPhone, un pc Zen con 16 core, :D ed agli italiani nulla...
Per soi/bulk hai ragione. Non volevo dire che non é giusto parlarne ma che comunque l'utente di un pc normalmente non é competente od interessato a tali informazioni.
E non potevi intervenire con un: "ehm scusate, siete due bimbi ignorantelli, approfondite prima cosa è amd e cosa intel in caso contrario compratevi una playstation (dove dentro c'è processore amd quello che voi chiamate cinese)" E te ne andavi con aria soddisfatta di aver umiliato e rovinato la giornata a due ragazzini. :D
E perché mai doveva farlo ?, nel ignoranza si vive meglio:D
No, non c'erano le basi per intavolare un discorso con gente del tipo Zen, sicuramente=Cina.
Quello che a me "preoccupa" di più è quando queste "dinamiche" (mi hanno detto, ho sentito, ho letto su internet, blabla) vengono applicate in campi un po' più "seri" dell'informatica...:doh:
Comunque MENO MALE che esistono posti come questo, in cui si discute (anche troppo, a volte) seriamente... Anche di SOI e Bulk :D
Tipo quelli, ho letto su facebbok che agli immigrati danno la casa i soldi le sigarette, l'iPhone, un pc Zen con 16 core, :D ed agli italiani nulla...
Per soi/bulk hai ragione. Non volevo dire che non é giusto parlarne ma che comunque l'utente di un pc normalmente non é competente od interessato a tali informazioni.
E non potevi intervenire con un: "ehm scusate, siete due bimbi ignorantelli, approfondite prima cosa è amd e cosa intel in caso contrario compratevi una playstation (dove dentro c'è processore amd quello che voi chiamate cinese)" E te ne andavi con aria soddisfatta di aver umiliato e rovinato la giornata a due ragazzini. :D
E perché mai doveva farlo ?, nel ignoranza si vive meglio:D
No, non c'erano le basi per intavolare un discorso con gente del tipo Zen, sicuramente=Cina.
paolo.oliva2
24-12-2016, 10:35
- reale capacità produttiva. - insufficiente quasi certamente prezzo più alto
Mi è venuto in mente questo riflettendo sulle VGA.
Una RX 480 ha un die sui 250mmq, non ricordo bene se 220 o 280). E' prodotta sul 14nm, quindi a tutti gli effetti DEVE essere prodotta nelle stesse catene dove verrà prodotto Zen. La RX 480 io l'ho pagata 220€ al D-DAY, è ovvio che ad AMD, per il solo die, se avesse incassato solamente 150€, sarebbe già un miracolo.
Lo stesso wafer produrrebbe più die come Zen che come RX 480 (die Zen 170/180mmq, die RX 480 più grande), posso credere che il die Zen abbia una percentuale fallati superiore, un test/selezione più caro, e qualsivoglia, ma faccio fatica a ipotizzare che AMD occupi le catene per produrre 250mmq di die RX 480 che porta alle sue tasche 150€, e noi discutiamo che 170/180mmq di die Zen non possono essere venduti a meno di 600€ perchè altrimenti si intaserebbero le catene.
Non voglio dare l'impressione come se volessi imporre il mio pensiero, però credo che ci sia una differenza tra fattibilità ed impossibilità.
Una cosa è ipotizzare di pagare 50 una cosa che costa 100, un'altra è pagare 300 una cosa che costa 100 e che al momento ne costa 1000.
Per me, il prezzo finale di Zen è tutto relazionato su quanto AMD deciderà di fare cartello con Intel più che da effettivi costi.
Mi è venuto in mente questo riflettendo sulle VGA.
Una RX 480 ha un die sui 250mmq, non ricordo bene se 220 o 280). E' prodotta sul 14nm, quindi a tutti gli effetti DEVE essere prodotta nelle stesse catene dove verrà prodotto Zen. La RX 480 io l'ho pagata 220€ al D-DAY, è ovvio che ad AMD, per il solo die, se avesse incassato solamente 150€, sarebbe già un miracolo.
Lo stesso wafer produrrebbe più die come Zen che come RX 480 (die Zen 170/180mmq, die RX 480 più grande), posso credere che il die Zen abbia una percentuale fallati superiore, un test/selezione più caro, e qualsivoglia, ma faccio fatica a ipotizzare che AMD occupi le catene per produrre 250mmq di die RX 480 che porta alle sue tasche 150€, e noi discutiamo che 170/180mmq di die Zen non possono essere venduti a meno di 600€ perchè altrimenti si intaserebbero le catene.
Non voglio dare l'impressione come se volessi imporre il mio pensiero, però credo che ci sia una differenza tra fattibilità ed impossibilità.
Una cosa è ipotizzare di pagare 50 una cosa che costa 100, un'altra è pagare 300 una cosa che costa 100 e che al momento ne costa 1000.
Per me, il prezzo finale di Zen è tutto relazionato su quanto AMD deciderà di fare cartello con Intel più che da effettivi costi.
Roland74Fun
24-12-2016, 10:59
....La RX 480 io l'ho pagata 220€ al D-DAY,
Ma dove? Ma come? :eek: :eek: Che versione é? :confused:
Ma dove? Ma come? :eek: :eek: Che versione é? :confused:
capitan_crasy
24-12-2016, 11:28
Ma dove? Ma come? :eek: :eek: Che versione é? :confused:
Anch'io l'ho trovata a quel prezzo, ma la versione a 4GB...
Anch'io l'ho trovata a quel prezzo, ma la versione a 4GB...
Roland74Fun
24-12-2016, 11:31
Forse in Costa d'Avorio costano meno.
Dovevo andare lì per comprarla. :cool: :cool:
Dovevo andare lì per comprarla. :cool: :cool:
capitan_crasy
24-12-2016, 11:41
Forse in Costa d'Avorio costano meno.
Dovevo andare lì per comprarla. :cool: :cool:
Io abito in Italia e per trovare i "veri" prezzi al lancio basta guardare il mercato tedesco, la media era di 50/70 euro in meno se paragonato al nostro...
Dovevo andare lì per comprarla. :cool: :cool:
Io abito in Italia e per trovare i "veri" prezzi al lancio basta guardare il mercato tedesco, la media era di 50/70 euro in meno se paragonato al nostro...
paolo.oliva2
24-12-2016, 11:57
Forse in Costa d'Avorio costano meno.
Dovevo andare lì per comprarla. :cool: :cool:
Io l'ho comprata in Italia, al lancio e ne ho comprate 3, ho cercato su trovaprezzi, guardato chi la proponeva a meno, ed acquistate.
Dovevo andare lì per comprarla. :cool: :cool:
Io l'ho comprata in Italia, al lancio e ne ho comprate 3, ho cercato su trovaprezzi, guardato chi la proponeva a meno, ed acquistate.
Athlon
24-12-2016, 12:02
Ma è una specie di subset/superset di x86? :eek: Le mie elugubrazioni erano più per una CISC (ovviamente con motore RISC) completamente ortogonale dove ogni operando aveva il tipo annesso ed erano automaticamente emesse le uop di conversione se il tipo dei vari operandi era diverso. Istruzioni a 0-4 operandi, dove ogni operando aveva campi di bit per tipo, modo indirizzamento e dati, avevo anche calcolato i bit ecc...
..
:stordita: :stordita: :stordita: a questo punto faccio outing anche io con la mia """architettura"""
cioe' un FPGA all interno del core che viene di volta in volta programato con le istruzioni complesse piu' utilizate , ad esempio se si deve fare un encoding si puo' mettere nel FPGA la versione "hardware" del' algoritmo di encoding per avere le massime performace.
lo stesso si puo' fare per l' encription
se viene rilevato l'uso ripetuto di una istruzione complessa microprogrammata allora il processore configura il GA per eseguirla in hardware
..
:stordita: :stordita: :stordita: a questo punto faccio outing anche io con la mia """architettura"""
cioe' un FPGA all interno del core che viene di volta in volta programato con le istruzioni complesse piu' utilizate , ad esempio se si deve fare un encoding si puo' mettere nel FPGA la versione "hardware" del' algoritmo di encoding per avere le massime performace.
lo stesso si puo' fare per l' encription
se viene rilevato l'uso ripetuto di una istruzione complessa microprogrammata allora il processore configura il GA per eseguirla in hardware
paolo.oliva2
24-12-2016, 12:03
Anch'io l'ho trovata a quel prezzo, ma la versione a 4GB...
Qui mi fai venire un dubbio... ma non posso dire nulla in proposito, perchè ancora non ho potuto avviare il sistema, in quanto montato la RX, avevo i monitor con la sola presa VGA, ho cercato l'adattatore, trovato, i sistemi non partivano ugualmente e rimane solamente le DDR3 (10 banchi nessuno funzia più, manco in SC, perquesto avevo pensato alle VGA, in quanto ne avevo 3, le probabilità di guasto erano più sulle VGA), quindi ancora nada.
Aspettiamo sto Zen... a seconda del prezzo o faccio tutto AM4/DDR4 o 1 solo sistema Zen e acquisto le DDR3.
Qui mi fai venire un dubbio... ma non posso dire nulla in proposito, perchè ancora non ho potuto avviare il sistema, in quanto montato la RX, avevo i monitor con la sola presa VGA, ho cercato l'adattatore, trovato, i sistemi non partivano ugualmente e rimane solamente le DDR3 (10 banchi nessuno funzia più, manco in SC, perquesto avevo pensato alle VGA, in quanto ne avevo 3, le probabilità di guasto erano più sulle VGA), quindi ancora nada.
Aspettiamo sto Zen... a seconda del prezzo o faccio tutto AM4/DDR4 o 1 solo sistema Zen e acquisto le DDR3.
bjt2
24-12-2016, 12:20
@bjt2
non puoi fare delle freq. di un 8 core le stesse di un 4 per via del tdp: pronosticai 3.2 base ma solo per il tdp di 95w, per un 125 3.7 base, aggiungo per un 140w 4.0 base limiti del silicio permettendo. è ovvio che un 4c nativo dovrà andare almeno 200mhz (4.4) in più di BR ma a quale tdp? non di certo 65w.
il problema resta il tdp e dove mura il silicio.
Non ho detto che il 4 core non salirà di più. Ho detto che per combattere il 4 core intel può bastare ryzen se arriva a 4.5+GHz di turbo... ;)
E' chiaro che un 4c può cloccarsi di più. Ma solo se non è uno scarto.
Attualmente i 4c saranno probabilmente gli scarti dell'8c e quindi non credo che vadano a clock superiore... Ci vuole un 4c nativo o dobbiamo aspettare l'APU...
non puoi fare delle freq. di un 8 core le stesse di un 4 per via del tdp: pronosticai 3.2 base ma solo per il tdp di 95w, per un 125 3.7 base, aggiungo per un 140w 4.0 base limiti del silicio permettendo. è ovvio che un 4c nativo dovrà andare almeno 200mhz (4.4) in più di BR ma a quale tdp? non di certo 65w.
il problema resta il tdp e dove mura il silicio.
Non ho detto che il 4 core non salirà di più. Ho detto che per combattere il 4 core intel può bastare ryzen se arriva a 4.5+GHz di turbo... ;)
E' chiaro che un 4c può cloccarsi di più. Ma solo se non è uno scarto.
Attualmente i 4c saranno probabilmente gli scarti dell'8c e quindi non credo che vadano a clock superiore... Ci vuole un 4c nativo o dobbiamo aspettare l'APU...
okorop
24-12-2016, 12:20
Io l'ho comprata in Italia, al lancio e ne ho comprate 3, ho cercato su trovaprezzi, guardato chi la proponeva a meno, ed acquistate.
:O io l'ho presa a novembre custom, la reference non potevo prenderla per via della porta dvi mancante......comunque buon prezzo :)
:O io l'ho presa a novembre custom, la reference non potevo prenderla per via della porta dvi mancante......comunque buon prezzo :)
paolo.oliva2
24-12-2016, 12:47
Non ho detto che il 4 core non salirà di più. Ho detto che per combattere il 4 core intel può bastare ryzen se arriva a 4.5+GHz di turbo... ;)
E' chiaro che un 4c può cloccarsi di più. Ma solo se non è uno scarto.
Attualmente i 4c saranno probabilmente gli scarti dell'8c e quindi non credo che vadano a clock superiore... Ci vuole un 4c nativo o dobbiamo aspettare l'APU...
http://cdn.wccftech.com/wp-content/uploads/2016/12/AMD-Ryzen-Power-Consumption-and-TDP.jpg
Comunque è impressionante le performances vs consumi.
Nella figura sopra, non è tanto il consumo di Zen X8+8 vs 6900K X8+8, quanto il consumo a parità di elaborazione tra un Zen X8+8 e un 6700K.
Zen X8+8 93W, 6900K 96W sono simili, il 6700K 62W, ma rappresentano il consumo a parità di carico proporzionato ai TH massimi del procio, quindi sia Zen X8 che il 6900K, con un carico proporzionato a quello di un 6700K che sul 6700K produce 62W, sarebbero ambedue sicuramente sotto i 50W.
Quello che voglio dire, è che Zen avrà un consumo nettamente inferiore ad un 6700K/7700K, perchè comunque Zen X4 è 65W mentre un 6700K 95W, vuoi per l'iGPU assente, vuoi perchè il silicio perde efficienza a frequenze del 6700K.
Comunque io rimango dell'idea che la superiorità del 6700K (intesa in possibili frequenze superiori) lo sarà unicamente finchè i TH saranno fisici (cioè max 4TH come 4 i core fisici). Nel momento che il software potrà richiedere >4TH, un procio >4 core, risulterà sia più performante che molto più efficiente.
Cioè... un Zen X8+8 che lavora come X4 no SMT, il 6700K sarà più performante nel caso di frequenze/IPC superiori, ma sicuramente meno efficiente. Nel momento in cui utilizzeranno >4TH, il 6700K concederà il 30% di potenza per ogni TH basato su SMT vs un Zen X8 che ne concederà il 100% seppur a frequenze inferiori. Oltre gli 8 TH, Zen potrà concedere fino a 16TH con un consumo al max 50% superiore, ma che si dovrebbe tradurre simile al 100% superiore, quindi molto più efficiente.
E' chiaro che un 4c può cloccarsi di più. Ma solo se non è uno scarto.
Attualmente i 4c saranno probabilmente gli scarti dell'8c e quindi non credo che vadano a clock superiore... Ci vuole un 4c nativo o dobbiamo aspettare l'APU...
http://cdn.wccftech.com/wp-content/uploads/2016/12/AMD-Ryzen-Power-Consumption-and-TDP.jpg
Comunque è impressionante le performances vs consumi.
Nella figura sopra, non è tanto il consumo di Zen X8+8 vs 6900K X8+8, quanto il consumo a parità di elaborazione tra un Zen X8+8 e un 6700K.
Zen X8+8 93W, 6900K 96W sono simili, il 6700K 62W, ma rappresentano il consumo a parità di carico proporzionato ai TH massimi del procio, quindi sia Zen X8 che il 6900K, con un carico proporzionato a quello di un 6700K che sul 6700K produce 62W, sarebbero ambedue sicuramente sotto i 50W.
Quello che voglio dire, è che Zen avrà un consumo nettamente inferiore ad un 6700K/7700K, perchè comunque Zen X4 è 65W mentre un 6700K 95W, vuoi per l'iGPU assente, vuoi perchè il silicio perde efficienza a frequenze del 6700K.
Comunque io rimango dell'idea che la superiorità del 6700K (intesa in possibili frequenze superiori) lo sarà unicamente finchè i TH saranno fisici (cioè max 4TH come 4 i core fisici). Nel momento che il software potrà richiedere >4TH, un procio >4 core, risulterà sia più performante che molto più efficiente.
Cioè... un Zen X8+8 che lavora come X4 no SMT, il 6700K sarà più performante nel caso di frequenze/IPC superiori, ma sicuramente meno efficiente. Nel momento in cui utilizzeranno >4TH, il 6700K concederà il 30% di potenza per ogni TH basato su SMT vs un Zen X8 che ne concederà il 100% seppur a frequenze inferiori. Oltre gli 8 TH, Zen potrà concedere fino a 16TH con un consumo al max 50% superiore, ma che si dovrebbe tradurre simile al 100% superiore, quindi molto più efficiente.
Gioz
24-12-2016, 12:53
http://cdn.wccftech.com/wp-content/uploads/2016/12/AMD-Ryzen-Power-Consumption-and-TDP.jpg
Comunque è impressionante le performances vs consumi.
Nella figura sopra, non è tanto il consumo di Zen X8+8 vs 6900K X8+8, quanto il consumo a parità di elaborazione tra un Zen X8+8 e un 6700K.
Zen X8+8 93W, 6900K 96W sono simili, il 6700K 62W, ma rappresentano il consumo a parità di carico proporzionato ai TH massimi del procio, quindi sia Zen X8 che il 6900K, con un carico proporzionato a quello di un 6700K che sul 6700K produce 62W, sarebbero ambedue sicuramente sotto i 50W.
è normale, il 6900K gira a frequenze molto più basse del 6700K, sono uno 4GHz base e l'altro 3.2GHz base.
Comunque è impressionante le performances vs consumi.
Nella figura sopra, non è tanto il consumo di Zen X8+8 vs 6900K X8+8, quanto il consumo a parità di elaborazione tra un Zen X8+8 e un 6700K.
Zen X8+8 93W, 6900K 96W sono simili, il 6700K 62W, ma rappresentano il consumo a parità di carico proporzionato ai TH massimi del procio, quindi sia Zen X8 che il 6900K, con un carico proporzionato a quello di un 6700K che sul 6700K produce 62W, sarebbero ambedue sicuramente sotto i 50W.
è normale, il 6900K gira a frequenze molto più basse del 6700K, sono uno 4GHz base e l'altro 3.2GHz base.
Emaximus
24-12-2016, 12:56
Io sto aspettando di vedere qualche scheda madre top con l'x370 (si è già vista la giga x370 gaming k3 di preproduzione). So che all'evento "new horizon" come scheda hanno usato la msi tomahawk e che sembrerebbe avere 6 fasi (spero niente mosfet NIKOS). Mi piacerebbe vedere una crosshair VI formula sinceramente. :D
Nui_Mg
24-12-2016, 14:19
Tipo quelli, ho letto su facebbok che agli immigrati danno la casa i soldi le sigarette, l'iPhone, un pc Zen con 16 core, :D ed agli italiani nulla...
Non ci si informa su Facebook, bastano le cronache/indagini delle tv locali (io sono sintonizzato, per quanto l'Italia, soprattutto su quelle veronesi/bresciane/milanesi) per scoprire che c'è moltissimo di vero: non gli danno lo smartphone perché molti "profughi" già ce l'hanno (chi anche più di uno), ma hanno gratuite le sim, gli alloggi (hotel, pensioni, ecc., tutta roba pagata dallo stato verso l'imprenditore locale che accetta; ah, mi sono dimenticato di menzionare pure i trasporti pubblici, di cui sono un grande intenditore visto che li prendo ogni giorno, cioè gratuità/totale impunibilità dai bus di superficie, alla metro e ai treni regionali), i pocket money, i pasti, accesso gratuito a tutte le infrastrutture ospedaliere (spesso anche il dentista). E' poi pur sempre vero che, e sono casi saltati alla ribalta pure nazionale, vi sono vari italiani in notevoli difficoltà che non hanno niente e che dormono in macchina, quando va bene.
Cose che, onestamente, non accadono oltre Alpi (o accadono in maniera minore, come in Germaia) e non per niente tutti gli immigrati che arrivano da noi non sono accettati oltre alpi (oppure lo sono ma vengono attentamente selezionati, per esempio la Merkel è molto più ben disposta verso i siriani perché hanno di più da offrire a livello di preparazione).
L'europa dice all'Italia "brava Italia, così civile, così accogliente, così umana, ecc. che va a salvare gli immigrati perfino non nelle acque italiane o internazionali, ma perfino in quelle libiche, abbiamo tutti da imparare dall'Italia" per poi all'atto pratico fare cosa? Rifiutare/bloccare qualsiasi immigrato provenga dalla stessa Italia tanto "leccata".
Tutte cose che ovviamente non mi invento e documentate perfino a livello informazione nazionale (che è certamente stra pro-accoglienza, pro-cattolica, pro-bla bla).
Non hai idea del ridere che ci siamo fatti a Monaco quando pochi giorni prima dell'apertura dell'expo a Milano un rumeno è stato ripreso (poi circolato a livello mondiale) che letteralmente cagava nella piazza frontale alla stazione centrale di Milano.
Oh, d'altronde se sono gli stessi italiani di Italia a volere così... :)
Non ci si informa su Facebook, bastano le cronache/indagini delle tv locali (io sono sintonizzato, per quanto l'Italia, soprattutto su quelle veronesi/bresciane/milanesi) per scoprire che c'è moltissimo di vero: non gli danno lo smartphone perché molti "profughi" già ce l'hanno (chi anche più di uno), ma hanno gratuite le sim, gli alloggi (hotel, pensioni, ecc., tutta roba pagata dallo stato verso l'imprenditore locale che accetta; ah, mi sono dimenticato di menzionare pure i trasporti pubblici, di cui sono un grande intenditore visto che li prendo ogni giorno, cioè gratuità/totale impunibilità dai bus di superficie, alla metro e ai treni regionali), i pocket money, i pasti, accesso gratuito a tutte le infrastrutture ospedaliere (spesso anche il dentista). E' poi pur sempre vero che, e sono casi saltati alla ribalta pure nazionale, vi sono vari italiani in notevoli difficoltà che non hanno niente e che dormono in macchina, quando va bene.
Cose che, onestamente, non accadono oltre Alpi (o accadono in maniera minore, come in Germaia) e non per niente tutti gli immigrati che arrivano da noi non sono accettati oltre alpi (oppure lo sono ma vengono attentamente selezionati, per esempio la Merkel è molto più ben disposta verso i siriani perché hanno di più da offrire a livello di preparazione).
L'europa dice all'Italia "brava Italia, così civile, così accogliente, così umana, ecc. che va a salvare gli immigrati perfino non nelle acque italiane o internazionali, ma perfino in quelle libiche, abbiamo tutti da imparare dall'Italia" per poi all'atto pratico fare cosa? Rifiutare/bloccare qualsiasi immigrato provenga dalla stessa Italia tanto "leccata".
Tutte cose che ovviamente non mi invento e documentate perfino a livello informazione nazionale (che è certamente stra pro-accoglienza, pro-cattolica, pro-bla bla).
Non hai idea del ridere che ci siamo fatti a Monaco quando pochi giorni prima dell'apertura dell'expo a Milano un rumeno è stato ripreso (poi circolato a livello mondiale) che letteralmente cagava nella piazza frontale alla stazione centrale di Milano.
Oh, d'altronde se sono gli stessi italiani di Italia a volere così... :)
Nui_Mg
24-12-2016, 14:23
Stessero così le cose, aggiungendo i 3.4+ ghz finali rispetto i 3.15 di questo presunto bench, a me andrebbe benissimo, se i prezzi fossero quelli in tabella...un affare colossale un sr7 a 350 cartoni di listino
Se quelli sono dati che si riveleranno veritieri, allora la situazione è più che rosea, considerando pure che siamo agli inizi come affinamento, un esa-core del genere sarebbe veramente grandioso, pensando anche alla mia fissa che dal package di Zen esce qualche linea usb 3.1 gen.2, quindi nativa (non richiederebbe driver appositi con le livecd), a differenza perfino di kabylake il cui south intel non ha usb 3.1 gen.2 (ma eventualmente sarà supportato solo a livello terzi da produttori di mobo, quindi funzionalità disponibili solo all'interno dell'ambiente win).
Se quelli sono dati che si riveleranno veritieri, allora la situazione è più che rosea, considerando pure che siamo agli inizi come affinamento, un esa-core del genere sarebbe veramente grandioso, pensando anche alla mia fissa che dal package di Zen esce qualche linea usb 3.1 gen.2, quindi nativa (non richiederebbe driver appositi con le livecd), a differenza perfino di kabylake il cui south intel non ha usb 3.1 gen.2 (ma eventualmente sarà supportato solo a livello terzi da produttori di mobo, quindi funzionalità disponibili solo all'interno dell'ambiente win).
Nui_Mg
24-12-2016, 14:27
Io sto aspettando di vedere qualche scheda madre top con l'x370 (si è già vista la giga x370 gaming k3 di preproduzione). So che all'evento "new horizon" come scheda hanno usato la msi tomahawk e che sembrerebbe avere 6 fasi (spero niente mosfet NIKOS). Mi piacerebbe vedere una crosshair VI formula sinceramente. :D
L'incognita per me è proprio questa: se sul procio pare ormai che vi sia bontà/competitività, un forte interrogativo rimane sulla bontà/qualità delle mobo che lo supporteranno, storicamente spesso inferiori (almeno quelle che ho avuto io all'epoca dell'athlon 64) alle controparti di piattaforma intel.
L'incognita per me è proprio questa: se sul procio pare ormai che vi sia bontà/competitività, un forte interrogativo rimane sulla bontà/qualità delle mobo che lo supporteranno, storicamente spesso inferiori (almeno quelle che ho avuto io all'epoca dell'athlon 64) alle controparti di piattaforma intel.
paolo.oliva2
24-12-2016, 16:11
è normale, il 6900K gira a frequenze molto più basse del 6700K, sono uno 4GHz base e l'altro 3.2GHz base.
Ma infatti io evidenzio il fatto che erroneamente si suppone che un X8 consumi il doppio di un X4, mentre non si valuta che a parità di dati elaborati, l'X8 consuma meno di un X4 perchè un X4 è più facile che lavori ad un'efficienza peggiore di un X8 semplicemente perchè si cerca potenza con la frequenza (che aumentando fa perdere efficienza) che con i core.
In pratica, io trovo alquanto sbagliato pensare ad un X4 come soluzione green, cosa che del resto era stata ampiamente sottolineata ai tempi di BD 125W. Oggi, siamo esattamente all'opposto, nel senso che con la miniaturizzazione odierna, alla ricerca di potenza la soluzione è aumentare il numero di core, non la frequenza. Massimizza ciò che dico... cosa cambierebbe in un X4 a 10nm? a 7nm? Avresti un X4 a 65W, 4,4GHz def con +5% di IPC rispetto ad un 7700k? Cosa avresti, invece con un X8? Le frequenze di un X4 odierne al TDP di un X4 odierno.
Oltretutto, spero che l'iGPU si possa disabilitare nel 6700K/7700K, perchè concordo con il fatto che un APU può far risparmiare i soldi di una discreta, ma questo punto cozza con il fatto di scegliere una frequenza/IPC core alta quando con l'iGPU dell'APU non potresti mai sfruttare la potenza dei core, perchè GPU limited.
Ma infatti io evidenzio il fatto che erroneamente si suppone che un X8 consumi il doppio di un X4, mentre non si valuta che a parità di dati elaborati, l'X8 consuma meno di un X4 perchè un X4 è più facile che lavori ad un'efficienza peggiore di un X8 semplicemente perchè si cerca potenza con la frequenza (che aumentando fa perdere efficienza) che con i core.
In pratica, io trovo alquanto sbagliato pensare ad un X4 come soluzione green, cosa che del resto era stata ampiamente sottolineata ai tempi di BD 125W. Oggi, siamo esattamente all'opposto, nel senso che con la miniaturizzazione odierna, alla ricerca di potenza la soluzione è aumentare il numero di core, non la frequenza. Massimizza ciò che dico... cosa cambierebbe in un X4 a 10nm? a 7nm? Avresti un X4 a 65W, 4,4GHz def con +5% di IPC rispetto ad un 7700k? Cosa avresti, invece con un X8? Le frequenze di un X4 odierne al TDP di un X4 odierno.
Oltretutto, spero che l'iGPU si possa disabilitare nel 6700K/7700K, perchè concordo con il fatto che un APU può far risparmiare i soldi di una discreta, ma questo punto cozza con il fatto di scegliere una frequenza/IPC core alta quando con l'iGPU dell'APU non potresti mai sfruttare la potenza dei core, perchè GPU limited.
paolo.oliva2
24-12-2016, 16:22
Non ci si informa su Facebook, bastano le cronache/indagini delle tv locali (io sono sintonizzato, per quanto l'Italia, soprattutto su quelle veronesi/bresciane/milanesi) per scoprire che c'è moltissimo di vero: non gli danno lo smartphone perché molti "profughi" già ce l'hanno (chi anche più di uno), ma hanno gratuite le sim, gli alloggi (hotel, pensioni, ecc., tutta roba pagata dallo stato verso l'imprenditore locale che accetta; ah, mi sono dimenticato di menzionare pure i trasporti pubblici, di cui sono un grande intenditore visto che li prendo ogni giorno, cioè gratuità/totale impunibilità dai bus di superficie, alla metro e ai treni regionali), i pocket money, i pasti, accesso gratuito a tutte le infrastrutture ospedaliere (spesso anche il dentista). E' poi pur sempre vero che, e sono casi saltati alla ribalta pure nazionale, vi sono vari italiani in notevoli difficoltà che non hanno niente e che dormono in macchina, quando va bene.
Cose che, onestamente, non accadono oltre Alpi (o accadono in maniera minore, come in Germaia) e non per niente tutti gli immigrati che arrivano da noi non sono accettati oltre alpi (oppure lo sono ma vengono attentamente selezionati, per esempio la Merkel è molto più ben disposta verso i siriani perché hanno di più da offrire a livello di preparazione).
L'europa dice all'Italia "brava Italia, così civile, così accogliente, così umana, ecc. che va a salvare gli immigrati perfino non nelle acque italiane o internazionali, ma perfino in quelle libiche, abbiamo tutti da imparare dall'Italia" per poi all'atto pratico fare cosa? Rifiutare/bloccare qualsiasi immigrato provenga dalla stessa Italia tanto "leccata".
Tutte cose che ovviamente non mi invento e documentate perfino a livello informazione nazionale (che è certamente stra pro-accoglienza, pro-cattolica, pro-bla bla).
Non hai idea del ridere che ci siamo fatti a Monaco quando pochi giorni prima dell'apertura dell'expo a Milano un rumeno è stato ripreso (poi circolato a livello mondiale) che letteralmente cagava nella piazza frontale alla stazione centrale di Milano.
Oh, d'altronde se sono gli stessi italiani di Italia a volere così... :)
Come non quotarti. :)
Oltre a ciò, l'assurdo, e sottolineo assurdo, è quanto capitato a me. Sono sposato con una ivoriana da agosto 2014, faccio il visto all'ambasciata italiana in Costa d'Avorio e la porto con me in Italia. Vado al comando della polizia della mia città, per regolalizzarla, mi dicono che non ci sono problemi che va bene così, che non c'è bisogno di fare il permesso di soggiorno. Dopo 1 anno torno in Costa d'Avorio, e arrivato il momento di un altro viaggio in Italia, rivado all'ambasciata per rifare il visto per mia moglie (2016), mi hanno fatto aspettare 3 settimane facendo tutte le verifiche come se fossi un importatore clandestino :confused: e, beffa, mi hanno detto IMPOSSIBILE che ti abbiano risposto così, che per loro io non era affatto andato dalla Polizia. Al che a luglio 2016 sono andato nello stesso comando con la lettera dell'ambasciata (che riportava in base all'articolo tal dei tali, bla bla bla, dovevano fare il permesso di soggiornno a mia moglie), dicendo che a fine luglio sarei partito. La risposta è stata che me lo scordo, perchè ci vogliono 45 giorni solamente per l'appuntamento e altri 2 mesi per averlo. Chiaramentte sono partito e ho il foglietto timbrato dal comando di polizia che mi sono presentato. Ora dovrò ritornare all'ambasciata per rifare il visto... e magari SUBIRE pure altre discussioni. Poi, come dici tu, ti vanno a prendere il clandestino sulle coste libiche ed il permesso di soggiorno glielo danno dopo 7 giorni, gratis, mentre io spendo 60€ circa ogni visto + il tempo + il viaggio. :mad:
Cose che, onestamente, non accadono oltre Alpi (o accadono in maniera minore, come in Germaia) e non per niente tutti gli immigrati che arrivano da noi non sono accettati oltre alpi (oppure lo sono ma vengono attentamente selezionati, per esempio la Merkel è molto più ben disposta verso i siriani perché hanno di più da offrire a livello di preparazione).
L'europa dice all'Italia "brava Italia, così civile, così accogliente, così umana, ecc. che va a salvare gli immigrati perfino non nelle acque italiane o internazionali, ma perfino in quelle libiche, abbiamo tutti da imparare dall'Italia" per poi all'atto pratico fare cosa? Rifiutare/bloccare qualsiasi immigrato provenga dalla stessa Italia tanto "leccata".
Tutte cose che ovviamente non mi invento e documentate perfino a livello informazione nazionale (che è certamente stra pro-accoglienza, pro-cattolica, pro-bla bla).
Non hai idea del ridere che ci siamo fatti a Monaco quando pochi giorni prima dell'apertura dell'expo a Milano un rumeno è stato ripreso (poi circolato a livello mondiale) che letteralmente cagava nella piazza frontale alla stazione centrale di Milano.
Oh, d'altronde se sono gli stessi italiani di Italia a volere così... :)
Come non quotarti. :)
Oltre a ciò, l'assurdo, e sottolineo assurdo, è quanto capitato a me. Sono sposato con una ivoriana da agosto 2014, faccio il visto all'ambasciata italiana in Costa d'Avorio e la porto con me in Italia. Vado al comando della polizia della mia città, per regolalizzarla, mi dicono che non ci sono problemi che va bene così, che non c'è bisogno di fare il permesso di soggiorno. Dopo 1 anno torno in Costa d'Avorio, e arrivato il momento di un altro viaggio in Italia, rivado all'ambasciata per rifare il visto per mia moglie (2016), mi hanno fatto aspettare 3 settimane facendo tutte le verifiche come se fossi un importatore clandestino :confused: e, beffa, mi hanno detto IMPOSSIBILE che ti abbiano risposto così, che per loro io non era affatto andato dalla Polizia. Al che a luglio 2016 sono andato nello stesso comando con la lettera dell'ambasciata (che riportava in base all'articolo tal dei tali, bla bla bla, dovevano fare il permesso di soggiornno a mia moglie), dicendo che a fine luglio sarei partito. La risposta è stata che me lo scordo, perchè ci vogliono 45 giorni solamente per l'appuntamento e altri 2 mesi per averlo. Chiaramentte sono partito e ho il foglietto timbrato dal comando di polizia che mi sono presentato. Ora dovrò ritornare all'ambasciata per rifare il visto... e magari SUBIRE pure altre discussioni. Poi, come dici tu, ti vanno a prendere il clandestino sulle coste libiche ed il permesso di soggiorno glielo danno dopo 7 giorni, gratis, mentre io spendo 60€ circa ogni visto + il tempo + il viaggio. :mad:
bomkill
24-12-2016, 17:32
Come non quotarti. :)
Oltre a ciò, l'assurdo, e sottolineo assurdo, è quanto capitato a me. Sono sposato con una ivoriana da agosto 2014, faccio il visto all'ambasciata italiana in Costa d'Avorio e la porto con me in Italia. Vado al comando della polizia della mia città, per regolalizzarla, mi dicono che non ci sono problemi che va bene così, che non c'è bisogno di fare il permesso di soggiorno. Dopo 1 anno torno in Costa d'Avorio, e arrivato il momento di un altro viaggio in Italia, rivado all'ambasciata per rifare il visto per mia moglie (2016), mi hanno fatto aspettare 3 settimane facendo tutte le verifiche come se fossi un importatore clandestino :confused: e, beffa, mi hanno detto IMPOSSIBILE che ti abbiano risposto così, che per loro io non era affatto andato dalla Polizia. Al che a luglio 2016 sono andato nello stesso comando con la lettera dell'ambasciata (che riportava in base all'articolo tal dei tali, bla bla bla, dovevano fare il permesso di soggiornno a mia moglie), dicendo che a fine luglio sarei partito. La risposta è stata che me lo scordo, perchè ci vogliono 45 giorni solamente per l'appuntamento e altri 2 mesi per averlo. Chiaramentte sono partito e ho il foglietto timbrato dal comando di polizia che mi sono presentato. Ora dovrò ritornare all'ambasciata per rifare il visto... e magari SUBIRE pure altre discussioni. Poi, come dici tu, ti vanno a prendere il clandestino sulle coste libiche ed il permesso di soggiorno glielo danno dopo 7 giorni, gratis, mentre io spendo 60€ circa ogni visto + il tempo + il viaggio. :mad:
E si la nostra classe digerente:D (dirigente) non si rende conto che sta montando l'incazzatura della gente e te lo dice uno che comprende le ragioni di chi cerca una vita migliore,quello che non comprendo e il diverso trattamento tra italiani indigenti e immigrati,non comprendo il non rispetto degli usi e tradizioni del paese ospitante,non comprendo la ritrosia degli immigrati ad integrarsi ed accettare il cibo che viene loro dato (io se vado a casa di altri anche se non mi piace non butto per terra il cibo,piuttosto mangio ringrazio e se il posto non mi piace me ne vado per non tornare più e se non lo posso fare mi sforzo di accettare in segno di riconoscenza).
Ma in fondo la verità in fondo la conosciamo gli immigrati servono principalmente a chi gestisce l'economia per abbassare i diritti degli autoctoni .
BUON NATALE A TUTTI.
Oltre a ciò, l'assurdo, e sottolineo assurdo, è quanto capitato a me. Sono sposato con una ivoriana da agosto 2014, faccio il visto all'ambasciata italiana in Costa d'Avorio e la porto con me in Italia. Vado al comando della polizia della mia città, per regolalizzarla, mi dicono che non ci sono problemi che va bene così, che non c'è bisogno di fare il permesso di soggiorno. Dopo 1 anno torno in Costa d'Avorio, e arrivato il momento di un altro viaggio in Italia, rivado all'ambasciata per rifare il visto per mia moglie (2016), mi hanno fatto aspettare 3 settimane facendo tutte le verifiche come se fossi un importatore clandestino :confused: e, beffa, mi hanno detto IMPOSSIBILE che ti abbiano risposto così, che per loro io non era affatto andato dalla Polizia. Al che a luglio 2016 sono andato nello stesso comando con la lettera dell'ambasciata (che riportava in base all'articolo tal dei tali, bla bla bla, dovevano fare il permesso di soggiornno a mia moglie), dicendo che a fine luglio sarei partito. La risposta è stata che me lo scordo, perchè ci vogliono 45 giorni solamente per l'appuntamento e altri 2 mesi per averlo. Chiaramentte sono partito e ho il foglietto timbrato dal comando di polizia che mi sono presentato. Ora dovrò ritornare all'ambasciata per rifare il visto... e magari SUBIRE pure altre discussioni. Poi, come dici tu, ti vanno a prendere il clandestino sulle coste libiche ed il permesso di soggiorno glielo danno dopo 7 giorni, gratis, mentre io spendo 60€ circa ogni visto + il tempo + il viaggio. :mad:
E si la nostra classe digerente:D (dirigente) non si rende conto che sta montando l'incazzatura della gente e te lo dice uno che comprende le ragioni di chi cerca una vita migliore,quello che non comprendo e il diverso trattamento tra italiani indigenti e immigrati,non comprendo il non rispetto degli usi e tradizioni del paese ospitante,non comprendo la ritrosia degli immigrati ad integrarsi ed accettare il cibo che viene loro dato (io se vado a casa di altri anche se non mi piace non butto per terra il cibo,piuttosto mangio ringrazio e se il posto non mi piace me ne vado per non tornare più e se non lo posso fare mi sforzo di accettare in segno di riconoscenza).
Ma in fondo la verità in fondo la conosciamo gli immigrati servono principalmente a chi gestisce l'economia per abbassare i diritti degli autoctoni .
BUON NATALE A TUTTI.
cdimauro
24-12-2016, 17:38
Come hai detto anche tu (ed io) non si reinventa la ruota.
X87 difficilmente verrà eliminata (a meno che non la si voglia emulare a livello hardware, ma poi il superPI non farà più testo), le MMX invece andrebbero eliminate e di netto (non credo che esistano software usciti da Vista in poi che abbiano un path esclusivo per MMX).
Per entrambi l'emulazione software potrebbe essere sufficiente: compatibilità garantita, però al prezzo di prestazioni nettamente inferiori. Meglio che toglierla completamente di mezzo.
Ed è già possibile, come ha scritto bjt2. Solo che attualmente il trap + emulazione di istruzioni x87, MMX, e in generale di una qualunque istruzione, è mostruosamente lento, a causa della chiamata di una ISR (e dunque doppio context switch).
Servirebbe una soluzione migliore. :fiufiu: :D
Certamente mettere mano ad un'architettura per rinnovarla profondamente (e poter quindi meglio sfruttare il silicio disponibile) equivale a riscriverla, tanto vale allora prendere tutto quello che si può adattare e ricreare il resto, aggiungere nuove implementazioni, riconcepire profondamente la cache L3 (che per la miniutarizzazione spinta di adesso e del prossimo futuro saranno sempre di dimensioni più imponenti) e predisporre per cache L4 (sperando che i dati non debbano passare per forza lungo tutta la gerarchia di cache).
Se ci pensi bene, più o meno è quello che Intel ha iniziato a fare con AVX prima e AVX-512 poi, visto che l'unità SIMD è ormai diventata un elemento fondamentale per un processore, ed è quella che cresce e si evolve di più e più velocemente in un processore, ormai.
MMX ed SSE sono delle pezze all'ISA x86, con troppi limiti. La prima è ormai abbandonata da tempo, ma la seconda è ancora troppo usata. Le AVX consentono una transizione "morbida" dalle SSE (visto che sono una sostanziale riscrittura delle stesse operazioni), e prima o poi si riuscirà a eliminare anche questa.
Sinceramente sono certo che intel potrebbe presentare una cpu delle stesse prestazioni di un 6950 in meno di 70w sui 10 nm, amd con zen+ invece dovrebbe avere + 20% prestazioni a -30% consumi (e queste sono cose che ho visto nella palla di cristallo)
Sulle quali non sono mai intervenuto, come sai, e non lo farò nemmeno ora. :)
Però sarebbe veramente un cambiamento epocale per Intel, se decidesse di deprecare alcune parti dell'ISA. Fosse anche soltanto l'MMX.
D'altra parte ARM con ARM64 ha colto l'occasione per ripensare da zero tutto, e togliere di mezzo un sacco di roba legacy. E' anche vero che aveva le mani molto più libere (visto che non ha mai avuto un'ISA a 64 bit, e giocoforza doveva presentarne una per rimanere competitiva), per cui le è venuto più facile.
Il mio cruccio rimane quello che AMD avrebbe potuto approfittarne allo stesso modo, e con x64 avrebbe potuto tirare fuori un'ISA a 64 bit nuova di pacca, con una struttura degli opcode di gran lunga più efficiente, e togliendo di mezzo molto più legacy.
E scoprire così le sue carte? Naaaa! Sai perchè? Dalle latenze puoi scoprire se hanno alzato o abbassato il FO4. Siccome tutti quanti (tranne pochi come me :cool: ) davano clock nel range dei 3GHz base max, vuol dire che tutti si aspettavano un alto FO4, secondo il classico schema alta IPC=>alto FO4. Avendo le latenze, se sono alte, o comunque simili a BD, potevi scoprire le carte. In particolare se le latenze mostrassero un FO4 uguale o inferiore a BD, con la proiezione del +40% di IPC e un clock potenzialmente alto (almeno con il 14nm a regime), allora staresti mostrando le tue carte... Potenzialmente il FUD sparato da molta gente su clock disastrosi ha fatto il gioco di AMD e ora potrebbe fare una uscita a sorpresa. Io sono ancora convinto di almeno 3.5 base e almeno 4.5 turbomax più l'XFR. Se così fosse almeno nel breve termine non ci sarebbe neanche bisogno del 4 core, perchè kabylake ha 4.5Ghz di turbomax...
Non è che ci sia tanto da scoprire o da temere. Intel non potrebbe certo cambiare le sue (micro)architetture in poco tempo, anche se AMD avesse rilasciato questi dettagli.
Si tratta di tempi molto lunghi per cambiamenti di quella portata.
Beh, sono sempre un ingegniiiiiere ancora nel pieno delle facoltà mentali :asd: (aka ancora niente alzheimer galoppante), quindi se mi dai un manuale lo dovrei capire... :asd:
Ecco qui (https://www.altera.com/en_US/pdfs/literature/misc/FPGAs_For_Dummies_eBook.pdf). :fiufiu: :D
Quindi se ho capito bene, compatibilità solo a livello di assembly e quindi possibilità di JIT one to one con codice già compilato, con riprogettazione del formato istruzioni, immagino più efficiente e facile da decodificare. Ottima idea... :)
Esattamente. La mia ISA è totalmente compatibile con x86 & x64 a livello di registri e istruzioni: ogni istruzione x86 o x64, infatti, può essere mappata esattamente 1:1 con una della mia ISA.
La decodifica è estremamente semplice ed efficiente. Penso che sia del tutto inutile utilizzare tag bit nella cache L1 codice, per stabilire l'inizio e la fine di ogni istruzione, perché è possibile recuperare / calcolare quest'informazione molto velocemente e richiedendo pochi bit estratti dall'istruzione; in realtà, oltre alla lunghezza, si possono recuperare praticamente tutte le informazioni utili alla decodifica più altro.
Non uso nemmeno prefissi. Mi sono inventato un meccanismo particolare per gestire i casi più complessi (registri "high" come AH, BH, ecc.. Estensione dei registri SIMD da 64 a 128. ecc..)
Nonostante tutto, la densità è simile a x86 (leggermente inferiore), e di gran lunga migliore rispetto a x64.
Ho dimenticato di dire che ho previsto anche un campo di bit per la numerosità. 0= scalare, 1=2 elementi, 2=4, 3=8 ecc e rendere tutto agnostico dalle implementazioni. Es implementazione economica con unità a 64 bit, che trappano per gli FP128 e fanno in una sola uop 1x64, 2x32 ecc e implementazioni high end magari a 256-512 bit, che fanno in un solo clock praticamente tutte le operazioni. Così hai un solo codice denso che gira a varie prestazioni sulle varie implementazioni.
Quant'è lungo il campo di bit? E fino a quanti elementi puoi specificare? Perché questo potrebbe condizionare la dimensione delle istruzioni e, dunque, la densità del codice, con ricadute negative sulle prestazioni.
La mia ISA prevede già nativamente supporto a registri SIMD a 128, 256, 512, e 1024 bit. Più il supporto a MMX (64 bit) ed SSE (128 bit, ma la parte alta del vettore viene mantenuta intatta), in maniera simile (nel senso che possono usare esattamente tutte le istruzioni della mia ISA, con la stessa identica struttura, ma con qualche limite. Ad esempio non viene fornito oppure ho proibito l'uso delle maschere).
Ho preferito un approccio più tradizionale, come vedi, con dimensione esplicita, anziché quello usato da Agner con la ForwardCom, oppure di recente con ARM e la sua nuova SIMD con registri "variabili" fino a 2048 bit. Ma nulla toglie di implementare il supporto ai registri a 1024 bit, spezzando internamente le istruzioni in più uop, come fa Zen, e faceva il Pentium-III con le sue SSE: così si scrive il codice una sola volta sfruttando la massima dimensione, e si delega alla micro-architettura come implementare il tutto, in base al budget/obiettivi.
Ma ovviamente la compatibilità con x86 è molto importante. Si può unire il meglio dei due mondi prevedendo TUTTE le istruzioni x86, più quelle che escono fuori dalle mie elugubrazioni, con la compatibilità assembly e la possibilità di fare JIT 1 to 1...
E' esattamente quello che ho fatto io. :D
Ma la mia idea era di avere al posto delle TLB, un range di MTTR come i range register, per esempio 64/128 coppie dove hai indirizzo iniziale, finale, permessi e offset. In questo modo il SO si può organizzare anche per lo heap (in genere lo stack frame è preallocato, mi pare ci sia una opzione nel linker o compilatore e di default sia 4MB) e magari sul "segment fault" se i permessi del processo lo permettono, può spostare eventualmente qualcosa e allargare un range già esistente. Non è detto che devi per forza fare 1000 ranges... Diventerebbe una sorta di cache con 64/128 coppie di comparatori.
Ancora meglio invece di MTTRR da impostare a mano, fare una struttura di segment table (invece di page table) in memoria a 1 livello e nei TLB (che a questo punto possono anche essere 16-32 e solo di primo livello) mettere i range, che se il SO è intelligente, come ho detto sopra, possono essere veramente pochi e quindi praticamente non dover andare mai in memoria, tranne la prima volta. Magari al task switch in background possono anche essere caricati nel TLB i segmenti...
Ma non è troppo pesante usare tutti quei comparatori? Da replicare poi per le 2-3 load/store eseguibili per ciclo di clock.
L'idea di sei segmenti/range IMO sarebbe utile per ridurre notevolmente l'uso delle entry TLB, con vantaggi sia a livello prestazionale sia di consumi.
Non è complicato: vedi sopra. Ora semplicemente Zen esclude i 3 bit bassi dal confronto. Con la mia idea deve fare due comparazioni in parallelo per ogni TLB e metterle in AND anzichè una. In pratica potrebbe anche non incrementare il FO4.
Per operazioni così semplici, e in questa parte del chip, è plausibile che non aumenti.
Rimangono solo i miei dubbi relativi a tutte quelle comparazioni.
Interessante. Se non lo hai già fatto, potresti incominciare a scrivere il codice di una JIT x86->tuo formato magari sotto forma di libreria compatibile con i tool in commercio (non so se abbia più senso farlo a livello di assembler o linker), in modo da poter emettere il codice già a livello di compilazione...
Già fatto. :D
Ho uno script Python che legge un .exe, disassembla quante più istruzioni possibili partendo dall'entry point, e traduce ogni istruzione x86 o x64 nell'equivalente della mia ISA. Inoltre genera un sacco di statistiche; è così che ho potuto misurare la densità del codice e confrontarla con x86 e x64.
C'è da dire che in questo modo ottengo "soltanto" un lower bound riguardo alla densità, perché sto soltanto mappando, rozzamente, un'istruzione x86/x64 in una mia.
Quindi non sto usando nulla delle cose nuove che ho introdotto, come i registri in più (meno load / store in memoria), nuove istruzioni ternarie o binarie non distruttive per i GPR (RISC-like :D), istruzioni ternarie con valore immediato a 8 bit (idem come prima), nuove modalità d'indirizzamento, e persino una move memory to memory.
Son tutte cose che consentiranno non soltanto di aumentare le prestazioni, ma di migliorare anche la densità di codice, andando a rivaleggiare con soluzioni come RISC-V (che al momento sono fra le migliori da questo punto di vista).
Dunque devo muovermi ad aggiornare lo script per la terza versione della mia ISA, perché devo poi modificarlo per la quarta (già definita. E sarà anche l'ultima). :fagiano:
:stordita: :stordita: :stordita: a questo punto faccio outing anche io con la mia """architettura"""
cioe' un FPGA all interno del core che viene di volta in volta programato con le istruzioni complesse piu' utilizate , ad esempio se si deve fare un encoding si puo' mettere nel FPGA la versione "hardware" del' algoritmo di encoding per avere le massime performace.
lo stesso si puo' fare per l' encription
se viene rilevato l'uso ripetuto di una istruzione complessa microprogrammata allora il processore configura il GA per eseguirla in hardware
In parte puoi già farlo con alcuni Xeon, che integrano un FPGA. :fagiano:
Anche se ciò che descrivi è decisamente più estremo. IMO sarebbe meglio lasciare qualche spazio nell'ISA per istruzioni "customizzabili", da smistare all'FPGA. Modello coprocessore, per intenderci.
Sarebbe un buon compromesso, e di più semplice realizzazione.
Nella mia ISA c'è spazio per centinaia di future istruzioni GPR, e migliaia di istruzioni SIMD. Per cui riservare qualche gruppo per un coprocessore è decisamente banale. :cool:
E' chiaro che un 4c può cloccarsi di più. Ma solo se non è uno scarto.
Attualmente i 4c saranno probabilmente gli scarti dell'8c e quindi non credo che vadano a clock superiore... Ci vuole un 4c nativo o dobbiamo aspettare l'APU...
*
@Nui_Mg: la situazione in Germania non è così diversa. Ma bisognerebbe distinguere fra immigrati / clandestini, e profughi, che sono cose completamente diverse. Altrimenti si finisce per fare dell'insano populismo, e fomentare la solita xenofobia.
X87 difficilmente verrà eliminata (a meno che non la si voglia emulare a livello hardware, ma poi il superPI non farà più testo), le MMX invece andrebbero eliminate e di netto (non credo che esistano software usciti da Vista in poi che abbiano un path esclusivo per MMX).
Per entrambi l'emulazione software potrebbe essere sufficiente: compatibilità garantita, però al prezzo di prestazioni nettamente inferiori. Meglio che toglierla completamente di mezzo.
Ed è già possibile, come ha scritto bjt2. Solo che attualmente il trap + emulazione di istruzioni x87, MMX, e in generale di una qualunque istruzione, è mostruosamente lento, a causa della chiamata di una ISR (e dunque doppio context switch).
Servirebbe una soluzione migliore. :fiufiu: :D
Certamente mettere mano ad un'architettura per rinnovarla profondamente (e poter quindi meglio sfruttare il silicio disponibile) equivale a riscriverla, tanto vale allora prendere tutto quello che si può adattare e ricreare il resto, aggiungere nuove implementazioni, riconcepire profondamente la cache L3 (che per la miniutarizzazione spinta di adesso e del prossimo futuro saranno sempre di dimensioni più imponenti) e predisporre per cache L4 (sperando che i dati non debbano passare per forza lungo tutta la gerarchia di cache).
Se ci pensi bene, più o meno è quello che Intel ha iniziato a fare con AVX prima e AVX-512 poi, visto che l'unità SIMD è ormai diventata un elemento fondamentale per un processore, ed è quella che cresce e si evolve di più e più velocemente in un processore, ormai.
MMX ed SSE sono delle pezze all'ISA x86, con troppi limiti. La prima è ormai abbandonata da tempo, ma la seconda è ancora troppo usata. Le AVX consentono una transizione "morbida" dalle SSE (visto che sono una sostanziale riscrittura delle stesse operazioni), e prima o poi si riuscirà a eliminare anche questa.
Sinceramente sono certo che intel potrebbe presentare una cpu delle stesse prestazioni di un 6950 in meno di 70w sui 10 nm, amd con zen+ invece dovrebbe avere + 20% prestazioni a -30% consumi (e queste sono cose che ho visto nella palla di cristallo)
Sulle quali non sono mai intervenuto, come sai, e non lo farò nemmeno ora. :)
Però sarebbe veramente un cambiamento epocale per Intel, se decidesse di deprecare alcune parti dell'ISA. Fosse anche soltanto l'MMX.
D'altra parte ARM con ARM64 ha colto l'occasione per ripensare da zero tutto, e togliere di mezzo un sacco di roba legacy. E' anche vero che aveva le mani molto più libere (visto che non ha mai avuto un'ISA a 64 bit, e giocoforza doveva presentarne una per rimanere competitiva), per cui le è venuto più facile.
Il mio cruccio rimane quello che AMD avrebbe potuto approfittarne allo stesso modo, e con x64 avrebbe potuto tirare fuori un'ISA a 64 bit nuova di pacca, con una struttura degli opcode di gran lunga più efficiente, e togliendo di mezzo molto più legacy.
E scoprire così le sue carte? Naaaa! Sai perchè? Dalle latenze puoi scoprire se hanno alzato o abbassato il FO4. Siccome tutti quanti (tranne pochi come me :cool: ) davano clock nel range dei 3GHz base max, vuol dire che tutti si aspettavano un alto FO4, secondo il classico schema alta IPC=>alto FO4. Avendo le latenze, se sono alte, o comunque simili a BD, potevi scoprire le carte. In particolare se le latenze mostrassero un FO4 uguale o inferiore a BD, con la proiezione del +40% di IPC e un clock potenzialmente alto (almeno con il 14nm a regime), allora staresti mostrando le tue carte... Potenzialmente il FUD sparato da molta gente su clock disastrosi ha fatto il gioco di AMD e ora potrebbe fare una uscita a sorpresa. Io sono ancora convinto di almeno 3.5 base e almeno 4.5 turbomax più l'XFR. Se così fosse almeno nel breve termine non ci sarebbe neanche bisogno del 4 core, perchè kabylake ha 4.5Ghz di turbomax...
Non è che ci sia tanto da scoprire o da temere. Intel non potrebbe certo cambiare le sue (micro)architetture in poco tempo, anche se AMD avesse rilasciato questi dettagli.
Si tratta di tempi molto lunghi per cambiamenti di quella portata.
Beh, sono sempre un ingegniiiiiere ancora nel pieno delle facoltà mentali :asd: (aka ancora niente alzheimer galoppante), quindi se mi dai un manuale lo dovrei capire... :asd:
Ecco qui (https://www.altera.com/en_US/pdfs/literature/misc/FPGAs_For_Dummies_eBook.pdf). :fiufiu: :D
Quindi se ho capito bene, compatibilità solo a livello di assembly e quindi possibilità di JIT one to one con codice già compilato, con riprogettazione del formato istruzioni, immagino più efficiente e facile da decodificare. Ottima idea... :)
Esattamente. La mia ISA è totalmente compatibile con x86 & x64 a livello di registri e istruzioni: ogni istruzione x86 o x64, infatti, può essere mappata esattamente 1:1 con una della mia ISA.
La decodifica è estremamente semplice ed efficiente. Penso che sia del tutto inutile utilizzare tag bit nella cache L1 codice, per stabilire l'inizio e la fine di ogni istruzione, perché è possibile recuperare / calcolare quest'informazione molto velocemente e richiedendo pochi bit estratti dall'istruzione; in realtà, oltre alla lunghezza, si possono recuperare praticamente tutte le informazioni utili alla decodifica più altro.
Non uso nemmeno prefissi. Mi sono inventato un meccanismo particolare per gestire i casi più complessi (registri "high" come AH, BH, ecc.. Estensione dei registri SIMD da 64 a 128. ecc..)
Nonostante tutto, la densità è simile a x86 (leggermente inferiore), e di gran lunga migliore rispetto a x64.
Ho dimenticato di dire che ho previsto anche un campo di bit per la numerosità. 0= scalare, 1=2 elementi, 2=4, 3=8 ecc e rendere tutto agnostico dalle implementazioni. Es implementazione economica con unità a 64 bit, che trappano per gli FP128 e fanno in una sola uop 1x64, 2x32 ecc e implementazioni high end magari a 256-512 bit, che fanno in un solo clock praticamente tutte le operazioni. Così hai un solo codice denso che gira a varie prestazioni sulle varie implementazioni.
Quant'è lungo il campo di bit? E fino a quanti elementi puoi specificare? Perché questo potrebbe condizionare la dimensione delle istruzioni e, dunque, la densità del codice, con ricadute negative sulle prestazioni.
La mia ISA prevede già nativamente supporto a registri SIMD a 128, 256, 512, e 1024 bit. Più il supporto a MMX (64 bit) ed SSE (128 bit, ma la parte alta del vettore viene mantenuta intatta), in maniera simile (nel senso che possono usare esattamente tutte le istruzioni della mia ISA, con la stessa identica struttura, ma con qualche limite. Ad esempio non viene fornito oppure ho proibito l'uso delle maschere).
Ho preferito un approccio più tradizionale, come vedi, con dimensione esplicita, anziché quello usato da Agner con la ForwardCom, oppure di recente con ARM e la sua nuova SIMD con registri "variabili" fino a 2048 bit. Ma nulla toglie di implementare il supporto ai registri a 1024 bit, spezzando internamente le istruzioni in più uop, come fa Zen, e faceva il Pentium-III con le sue SSE: così si scrive il codice una sola volta sfruttando la massima dimensione, e si delega alla micro-architettura come implementare il tutto, in base al budget/obiettivi.
Ma ovviamente la compatibilità con x86 è molto importante. Si può unire il meglio dei due mondi prevedendo TUTTE le istruzioni x86, più quelle che escono fuori dalle mie elugubrazioni, con la compatibilità assembly e la possibilità di fare JIT 1 to 1...
E' esattamente quello che ho fatto io. :D
Ma la mia idea era di avere al posto delle TLB, un range di MTTR come i range register, per esempio 64/128 coppie dove hai indirizzo iniziale, finale, permessi e offset. In questo modo il SO si può organizzare anche per lo heap (in genere lo stack frame è preallocato, mi pare ci sia una opzione nel linker o compilatore e di default sia 4MB) e magari sul "segment fault" se i permessi del processo lo permettono, può spostare eventualmente qualcosa e allargare un range già esistente. Non è detto che devi per forza fare 1000 ranges... Diventerebbe una sorta di cache con 64/128 coppie di comparatori.
Ancora meglio invece di MTTRR da impostare a mano, fare una struttura di segment table (invece di page table) in memoria a 1 livello e nei TLB (che a questo punto possono anche essere 16-32 e solo di primo livello) mettere i range, che se il SO è intelligente, come ho detto sopra, possono essere veramente pochi e quindi praticamente non dover andare mai in memoria, tranne la prima volta. Magari al task switch in background possono anche essere caricati nel TLB i segmenti...
Ma non è troppo pesante usare tutti quei comparatori? Da replicare poi per le 2-3 load/store eseguibili per ciclo di clock.
L'idea di sei segmenti/range IMO sarebbe utile per ridurre notevolmente l'uso delle entry TLB, con vantaggi sia a livello prestazionale sia di consumi.
Non è complicato: vedi sopra. Ora semplicemente Zen esclude i 3 bit bassi dal confronto. Con la mia idea deve fare due comparazioni in parallelo per ogni TLB e metterle in AND anzichè una. In pratica potrebbe anche non incrementare il FO4.
Per operazioni così semplici, e in questa parte del chip, è plausibile che non aumenti.
Rimangono solo i miei dubbi relativi a tutte quelle comparazioni.
Interessante. Se non lo hai già fatto, potresti incominciare a scrivere il codice di una JIT x86->tuo formato magari sotto forma di libreria compatibile con i tool in commercio (non so se abbia più senso farlo a livello di assembler o linker), in modo da poter emettere il codice già a livello di compilazione...
Già fatto. :D
Ho uno script Python che legge un .exe, disassembla quante più istruzioni possibili partendo dall'entry point, e traduce ogni istruzione x86 o x64 nell'equivalente della mia ISA. Inoltre genera un sacco di statistiche; è così che ho potuto misurare la densità del codice e confrontarla con x86 e x64.
C'è da dire che in questo modo ottengo "soltanto" un lower bound riguardo alla densità, perché sto soltanto mappando, rozzamente, un'istruzione x86/x64 in una mia.
Quindi non sto usando nulla delle cose nuove che ho introdotto, come i registri in più (meno load / store in memoria), nuove istruzioni ternarie o binarie non distruttive per i GPR (RISC-like :D), istruzioni ternarie con valore immediato a 8 bit (idem come prima), nuove modalità d'indirizzamento, e persino una move memory to memory.
Son tutte cose che consentiranno non soltanto di aumentare le prestazioni, ma di migliorare anche la densità di codice, andando a rivaleggiare con soluzioni come RISC-V (che al momento sono fra le migliori da questo punto di vista).
Dunque devo muovermi ad aggiornare lo script per la terza versione della mia ISA, perché devo poi modificarlo per la quarta (già definita. E sarà anche l'ultima). :fagiano:
:stordita: :stordita: :stordita: a questo punto faccio outing anche io con la mia """architettura"""
cioe' un FPGA all interno del core che viene di volta in volta programato con le istruzioni complesse piu' utilizate , ad esempio se si deve fare un encoding si puo' mettere nel FPGA la versione "hardware" del' algoritmo di encoding per avere le massime performace.
lo stesso si puo' fare per l' encription
se viene rilevato l'uso ripetuto di una istruzione complessa microprogrammata allora il processore configura il GA per eseguirla in hardware
In parte puoi già farlo con alcuni Xeon, che integrano un FPGA. :fagiano:
Anche se ciò che descrivi è decisamente più estremo. IMO sarebbe meglio lasciare qualche spazio nell'ISA per istruzioni "customizzabili", da smistare all'FPGA. Modello coprocessore, per intenderci.
Sarebbe un buon compromesso, e di più semplice realizzazione.
Nella mia ISA c'è spazio per centinaia di future istruzioni GPR, e migliaia di istruzioni SIMD. Per cui riservare qualche gruppo per un coprocessore è decisamente banale. :cool:
E' chiaro che un 4c può cloccarsi di più. Ma solo se non è uno scarto.
Attualmente i 4c saranno probabilmente gli scarti dell'8c e quindi non credo che vadano a clock superiore... Ci vuole un 4c nativo o dobbiamo aspettare l'APU...
*
@Nui_Mg: la situazione in Germania non è così diversa. Ma bisognerebbe distinguere fra immigrati / clandestini, e profughi, che sono cose completamente diverse. Altrimenti si finisce per fare dell'insano populismo, e fomentare la solita xenofobia.
Athlon
24-12-2016, 18:06
Anche se ciò che descrivi è decisamente più estremo. IMO sarebbe meglio lasciare qualche spazio nell'ISA per istruzioni "customizzabili", da smistare all'FPGA. Modello coprocessore, per intenderci.
.
ho avuto modo di utilizzare tempo addietro un processore Transmeta e ne sono rimasto affascinato.
Da allora il mio sogno e' un piccolissimo core fisico a basso consumo visto dal sistema come 16 o piu' core logici ed una FPGA molto estesa che viene riconfigurata ed attivata solo quando serve e solo per le istruzioni che sono in coda e che non riescono a venir processate dal piccolo core fisico.
In pratica accenderei i transistor solo quando servono e solo configurati per risolvere le istruzioni che gia' sono in coda
.
ho avuto modo di utilizzare tempo addietro un processore Transmeta e ne sono rimasto affascinato.
Da allora il mio sogno e' un piccolissimo core fisico a basso consumo visto dal sistema come 16 o piu' core logici ed una FPGA molto estesa che viene riconfigurata ed attivata solo quando serve e solo per le istruzioni che sono in coda e che non riescono a venir processate dal piccolo core fisico.
In pratica accenderei i transistor solo quando servono e solo configurati per risolvere le istruzioni che gia' sono in coda
Gioz
24-12-2016, 18:09
Ma infatti io evidenzio il fatto che erroneamente si suppone che un X8 consumi il doppio di un X4, mentre non si valuta che a parità di dati elaborati, l'X8 consuma meno di un X4 perchè un X4 è più facile che lavori ad un'efficienza peggiore di un X8 semplicemente perchè si cerca potenza con la frequenza (che aumentando fa perdere efficienza) che con i core.
In pratica, io trovo alquanto sbagliato pensare ad un X4 come soluzione green, cosa che del resto era stata ampiamente sottolineata ai tempi di BD 125W. Oggi, siamo esattamente all'opposto, nel senso che con la miniaturizzazione odierna, alla ricerca di potenza la soluzione è aumentare il numero di core, non la frequenza. Massimizza ciò che dico... cosa cambierebbe in un X4 a 10nm? a 7nm? Avresti un X4 a 65W, 4,4GHz def con +5% di IPC rispetto ad un 7700k? Cosa avresti, invece con un X8? Le frequenze di un X4 odierne al TDP di un X4 odierno.
si concordo, va tutto relazionato all'esigenza e al tipo di utilizzo reale.
poi ovviamente continuano comunque a spingere il possibile sulle frequenze e sull'st perché c'è un grosso mercato a cui interessa quello e perchè rimane comunque molto complicato parallelizzare "bene" i compiti da svolgere
Oltretutto, spero che l'iGPU si possa disabilitare nel 6700K/7700K, perchè concordo con il fatto che un APU può far risparmiare i soldi di una discreta, ma questo punto cozza con il fatto di scegliere una frequenza/IPC core alta quando con l'iGPU dell'APU non potresti mai sfruttare la potenza dei core, perchè GPU limited.
dovrebbe bastare settare come grafica primaria la pci-e per disattivare la igpu.
In pratica, io trovo alquanto sbagliato pensare ad un X4 come soluzione green, cosa che del resto era stata ampiamente sottolineata ai tempi di BD 125W. Oggi, siamo esattamente all'opposto, nel senso che con la miniaturizzazione odierna, alla ricerca di potenza la soluzione è aumentare il numero di core, non la frequenza. Massimizza ciò che dico... cosa cambierebbe in un X4 a 10nm? a 7nm? Avresti un X4 a 65W, 4,4GHz def con +5% di IPC rispetto ad un 7700k? Cosa avresti, invece con un X8? Le frequenze di un X4 odierne al TDP di un X4 odierno.
si concordo, va tutto relazionato all'esigenza e al tipo di utilizzo reale.
poi ovviamente continuano comunque a spingere il possibile sulle frequenze e sull'st perché c'è un grosso mercato a cui interessa quello e perchè rimane comunque molto complicato parallelizzare "bene" i compiti da svolgere
Oltretutto, spero che l'iGPU si possa disabilitare nel 6700K/7700K, perchè concordo con il fatto che un APU può far risparmiare i soldi di una discreta, ma questo punto cozza con il fatto di scegliere una frequenza/IPC core alta quando con l'iGPU dell'APU non potresti mai sfruttare la potenza dei core, perchè GPU limited.
dovrebbe bastare settare come grafica primaria la pci-e per disattivare la igpu.
bjt2
24-12-2016, 18:35
Ecco qui (https://www.altera.com/en_US/pdfs/literature/misc/FPGAs_For_Dummies_eBook.pdf). :fiufiu: :D
:asd: vedendo che avevi postato un link, ho pensato a un manuale VHDL... :asd: Poi me lo leggo, ma non ora perchè è quasi Natale... :asd:
A proposito: AUGURI!
Esattamente. La mia ISA è totalmente compatibile con x86 & x64 a livello di registri e istruzioni: ogni istruzione x86 o x64, infatti, può essere mappata esattamente 1:1 con una della mia ISA.
La decodifica è estremamente semplice ed efficiente. Penso che sia del tutto inutile utilizzare tag bit nella cache L1 codice, per stabilire l'inizio e la fine di ogni istruzione, perché è possibile recuperare / calcolare quest'informazione molto velocemente e richiedendo pochi bit estratti dall'istruzione; in realtà, oltre alla lunghezza, si possono recuperare praticamente tutte le informazioni utili alla decodifica più altro.
Non uso nemmeno prefissi. Mi sono inventato un meccanismo particolare per gestire i casi più complessi (registri "high" come AH, BH, ecc.. Estensione dei registri SIMD da 64 a 128. ecc..)
Nonostante tutto, la densità è simile a x86 (leggermente inferiore), e di gran lunga migliore rispetto a x64.
Quant'è lungo il campo di bit? E fino a quanti elementi puoi specificare? Perché questo potrebbe condizionare la dimensione delle istruzioni e, dunque, la densità del codice, con ricadute negative sulle prestazioni.
E' tutto molto fluido. Avevo pensato a una ISA a lunghezza variabile, ma con unità da 32 bit, di cui la prima divisa tra opcode (da cui derivare il numero di parametri, con opcode diversi per add1 2 ecc e magari bit iniziali diversi per istruzioni intere, fp ecc) e bit per la numerosità. Avevo pensato ad almeno 3 bit, con potenze di due crescenti, quindi con 111=256 elementi. Gli altri per opcode e numero parametri. E poi blocchi di 32 bit per i parametri, con bit per tipo di indirizzamento e indirizzo ecc. Ovviamente nessun limite e teoricamente possibilità di avere anche istruzioni ternarie con 3 operandi memoria, anche indiretti. Un vero CISCone! Ma ovviamente era solo una idea allo stato embrionale.
La mia ISA prevede già nativamente supporto a registri SIMD a 128, 256, 512, e 1024 bit. Più il supporto a MMX (64 bit) ed SSE (128 bit, ma la parte alta del vettore viene mantenuta intatta), in maniera simile (nel senso che possono usare esattamente tutte le istruzioni della mia ISA, con la stessa identica struttura, ma con qualche limite. Ad esempio non viene fornito oppure ho proibito l'uso delle maschere).
Ho preferito un approccio più tradizionale, come vedi, con dimensione esplicita, anziché quello usato da Agner con la ForwardCom, oppure di recente con ARM e la sua nuova SIMD con registri "variabili" fino a 2048 bit. Ma nulla toglie di implementare il supporto ai registri a 1024 bit, spezzando internamente le istruzioni in più uop, come fa Zen, e faceva il Pentium-III con le sue SSE: così si scrive il codice una sola volta sfruttando la massima dimensione, e si delega alla micro-architettura come implementare il tutto, in base al budget/obiettivi.
E' esattamente quello che ho fatto io. :D
:D
Ma non è troppo pesante usare tutti quei comparatori? Da replicare poi per le 2-3 load/store eseguibili per ciclo di clock.
L'idea di sei segmenti/range IMO sarebbe utile per ridurre notevolmente l'uso delle entry TLB, con vantaggi sia a livello prestazionale sia di consumi.
Per operazioni così semplici, e in questa parte del chip, è plausibile che non aumenti.
Rimangono solo i miei dubbi relativi a tutte quelle comparazioni.
Che io sappia tutte le caches, essendo memorie associative, comparano in parallelo i vari tag. Quindi anche i TLB. Ma il problema è l'organizzazione a vie. Una cache come vorrei farla io dovrebbe essere fully associative e comparare TUTTI i tag in parallelo. Quindi la devi fare piccola. E' da vedere se bastano 16-32 ranges, visto che i SO non sono obbligati a fare allocazioni consecutive.
L'idea di AMD è geniale, perchè la comparazione è uguale al caso standard, solo che mascheri 3 bit bassi. E' un ottimo compromesso, ma il range di pagine 4k deve essere allineato a 32kb... Suggerirei ad AMD di almeno estendere a 16/32/64 ecc pagine consecutive... Magari lo faranno in Zen+...
Già fatto. :D
Ho uno script Python che legge un .exe, disassembla quante più istruzioni possibili partendo dall'entry point, e traduce ogni istruzione x86 o x64 nell'equivalente della mia ISA. Inoltre genera un sacco di statistiche; è così che ho potuto misurare la densità del codice e confrontarla con x86 e x64.
C'è da dire che in questo modo ottengo "soltanto" un lower bound riguardo alla densità, perché sto soltanto mappando, rozzamente, un'istruzione x86/x64 in una mia.
Quindi non sto usando nulla delle cose nuove che ho introdotto, come i registri in più (meno load / store in memoria), nuove istruzioni ternarie o binarie non distruttive per i GPR (RISC-like :D), istruzioni ternarie con valore immediato a 8 bit (idem come prima), nuove modalità d'indirizzamento, e persino una move memory to memory.
Son tutte cose che consentiranno non soltanto di aumentare le prestazioni, ma di migliorare anche la densità di codice, andando a rivaleggiare con soluzioni come RISC-V (che al momento sono fra le migliori da questo punto di vista).
Dunque devo muovermi ad aggiornare lo script per la terza versione della mia ISA, perché devo poi modificarlo per la quarta (già definita. E sarà anche l'ultima). :fagiano:
Bellissimo! Lo sai, vero, che gcc (e penso tutti i compilatori, magari per ICC ce lo puoi dire tu se lo ricordi) chiama il compilatore c che spara codice assembler e poi l'assemblatore e il linker? E che se non sbaglio, almeno l'assemblatore di gcc è abbastanza standard ed ha un file di configurazione per mappare le istruzioni assembler in opcode? Potresti studiarti il formato e scrivere il file per la tua ISA... Comprese le nuove istruzioni... Poi basterebbe solo cambiare isa target in gcc et voilà...
AUGURI DI BUON NATALE!
:asd: vedendo che avevi postato un link, ho pensato a un manuale VHDL... :asd: Poi me lo leggo, ma non ora perchè è quasi Natale... :asd:
A proposito: AUGURI!
Esattamente. La mia ISA è totalmente compatibile con x86 & x64 a livello di registri e istruzioni: ogni istruzione x86 o x64, infatti, può essere mappata esattamente 1:1 con una della mia ISA.
La decodifica è estremamente semplice ed efficiente. Penso che sia del tutto inutile utilizzare tag bit nella cache L1 codice, per stabilire l'inizio e la fine di ogni istruzione, perché è possibile recuperare / calcolare quest'informazione molto velocemente e richiedendo pochi bit estratti dall'istruzione; in realtà, oltre alla lunghezza, si possono recuperare praticamente tutte le informazioni utili alla decodifica più altro.
Non uso nemmeno prefissi. Mi sono inventato un meccanismo particolare per gestire i casi più complessi (registri "high" come AH, BH, ecc.. Estensione dei registri SIMD da 64 a 128. ecc..)
Nonostante tutto, la densità è simile a x86 (leggermente inferiore), e di gran lunga migliore rispetto a x64.
Quant'è lungo il campo di bit? E fino a quanti elementi puoi specificare? Perché questo potrebbe condizionare la dimensione delle istruzioni e, dunque, la densità del codice, con ricadute negative sulle prestazioni.
E' tutto molto fluido. Avevo pensato a una ISA a lunghezza variabile, ma con unità da 32 bit, di cui la prima divisa tra opcode (da cui derivare il numero di parametri, con opcode diversi per add1 2 ecc e magari bit iniziali diversi per istruzioni intere, fp ecc) e bit per la numerosità. Avevo pensato ad almeno 3 bit, con potenze di due crescenti, quindi con 111=256 elementi. Gli altri per opcode e numero parametri. E poi blocchi di 32 bit per i parametri, con bit per tipo di indirizzamento e indirizzo ecc. Ovviamente nessun limite e teoricamente possibilità di avere anche istruzioni ternarie con 3 operandi memoria, anche indiretti. Un vero CISCone! Ma ovviamente era solo una idea allo stato embrionale.
La mia ISA prevede già nativamente supporto a registri SIMD a 128, 256, 512, e 1024 bit. Più il supporto a MMX (64 bit) ed SSE (128 bit, ma la parte alta del vettore viene mantenuta intatta), in maniera simile (nel senso che possono usare esattamente tutte le istruzioni della mia ISA, con la stessa identica struttura, ma con qualche limite. Ad esempio non viene fornito oppure ho proibito l'uso delle maschere).
Ho preferito un approccio più tradizionale, come vedi, con dimensione esplicita, anziché quello usato da Agner con la ForwardCom, oppure di recente con ARM e la sua nuova SIMD con registri "variabili" fino a 2048 bit. Ma nulla toglie di implementare il supporto ai registri a 1024 bit, spezzando internamente le istruzioni in più uop, come fa Zen, e faceva il Pentium-III con le sue SSE: così si scrive il codice una sola volta sfruttando la massima dimensione, e si delega alla micro-architettura come implementare il tutto, in base al budget/obiettivi.
E' esattamente quello che ho fatto io. :D
:D
Ma non è troppo pesante usare tutti quei comparatori? Da replicare poi per le 2-3 load/store eseguibili per ciclo di clock.
L'idea di sei segmenti/range IMO sarebbe utile per ridurre notevolmente l'uso delle entry TLB, con vantaggi sia a livello prestazionale sia di consumi.
Per operazioni così semplici, e in questa parte del chip, è plausibile che non aumenti.
Rimangono solo i miei dubbi relativi a tutte quelle comparazioni.
Che io sappia tutte le caches, essendo memorie associative, comparano in parallelo i vari tag. Quindi anche i TLB. Ma il problema è l'organizzazione a vie. Una cache come vorrei farla io dovrebbe essere fully associative e comparare TUTTI i tag in parallelo. Quindi la devi fare piccola. E' da vedere se bastano 16-32 ranges, visto che i SO non sono obbligati a fare allocazioni consecutive.
L'idea di AMD è geniale, perchè la comparazione è uguale al caso standard, solo che mascheri 3 bit bassi. E' un ottimo compromesso, ma il range di pagine 4k deve essere allineato a 32kb... Suggerirei ad AMD di almeno estendere a 16/32/64 ecc pagine consecutive... Magari lo faranno in Zen+...
Già fatto. :D
Ho uno script Python che legge un .exe, disassembla quante più istruzioni possibili partendo dall'entry point, e traduce ogni istruzione x86 o x64 nell'equivalente della mia ISA. Inoltre genera un sacco di statistiche; è così che ho potuto misurare la densità del codice e confrontarla con x86 e x64.
C'è da dire che in questo modo ottengo "soltanto" un lower bound riguardo alla densità, perché sto soltanto mappando, rozzamente, un'istruzione x86/x64 in una mia.
Quindi non sto usando nulla delle cose nuove che ho introdotto, come i registri in più (meno load / store in memoria), nuove istruzioni ternarie o binarie non distruttive per i GPR (RISC-like :D), istruzioni ternarie con valore immediato a 8 bit (idem come prima), nuove modalità d'indirizzamento, e persino una move memory to memory.
Son tutte cose che consentiranno non soltanto di aumentare le prestazioni, ma di migliorare anche la densità di codice, andando a rivaleggiare con soluzioni come RISC-V (che al momento sono fra le migliori da questo punto di vista).
Dunque devo muovermi ad aggiornare lo script per la terza versione della mia ISA, perché devo poi modificarlo per la quarta (già definita. E sarà anche l'ultima). :fagiano:
Bellissimo! Lo sai, vero, che gcc (e penso tutti i compilatori, magari per ICC ce lo puoi dire tu se lo ricordi) chiama il compilatore c che spara codice assembler e poi l'assemblatore e il linker? E che se non sbaglio, almeno l'assemblatore di gcc è abbastanza standard ed ha un file di configurazione per mappare le istruzioni assembler in opcode? Potresti studiarti il formato e scrivere il file per la tua ISA... Comprese le nuove istruzioni... Poi basterebbe solo cambiare isa target in gcc et voilà...
AUGURI DI BUON NATALE!
bjt2
24-12-2016, 18:45
Da anandtech:
La situazione di INTEL:
They said they didn't have time to bench Kaby Lake against Zen in the benchmarks, but there is another section in which they bench Kaby Lake, I posted them in the last picture.
Anyway it's 100% legit
If someone could explain the table with all the values where they compare Bristol Ridge, Summit Ridge and Kaby Lake, I don't understand anything
Also they think it's unlikely Zen will be available in January given the current state of the platform, even a March mass availability is optimistic.
Info I got from reading their file on Intel:
They have internal sources at Intel and the climate there is currently awful apparently, employees are very discouraged and some feel like "they have nothing left to lose". They are making big profits now by totally screwing up the future. According to the magazine, Intel is "probably in the most delicate situation it has had to face to this day". The CEO is reducing cost so much that he's managing engineers like "supermarket cashiers", he doesn't care about taking the time to train them.
Krzanich is very impatient and eager and keeps changing his mind about projects. If a new architecture isn't created in like a couple weeks, he gives up and cancels the project... he keeps sending contradictory instructions to the teams.
"Fab Hell": Intel is likely going to have a 6 month delay on 10nm. Worse, even Cannon Lake is not expected to feature any significant architectural improvement. Basically Intel was just hoping AMD would keep not competing with them.
Krzanich is apparently a disaster, and he won't be able to stay CEO for long. Apparently some people have heard him yelling from the next building when he was angry. But he seems unaware of him being perceived so negatively. Employees at Intel hope Murthy Renduchintala will replace him ASAP, and he seems much more capable and is slowly refocusing Intel in the right path, but basically R&D is fucked atm and there will be a huge empty space until about 2019. Apparently, Krzanich completely underestimated the possibility of an AMD comeback.
(I didn't really understand that point I'm not expert enough) but apparently x86 is going to disappear sooner than expected, it'll be replaced by ARM and Intel is panicking about that.
Intel is currently working on a "multichip package" (MCM) integrating an Intel CPU and an AMD GPU. So this is confirmed guys.
In the picture before the last picture I posted, it is said that Kaby Lake has exactly the same IPC as Skylake. No improvement as to perf/watt but there seems to be more room for overclocking.
Their conclusion is that if AMD doesn't mess up the launch, "Zen obviously has the necessary capacities to shake up the market..."
Link alle scansioni del giornale francese:
https://www.reddit.com/r/AMD_Stock/comments/5k31sr/i_bought_canard_pc_there_you_go/
http://imgur.com/a/KOXPd
La situazione di INTEL:
They said they didn't have time to bench Kaby Lake against Zen in the benchmarks, but there is another section in which they bench Kaby Lake, I posted them in the last picture.
Anyway it's 100% legit
If someone could explain the table with all the values where they compare Bristol Ridge, Summit Ridge and Kaby Lake, I don't understand anything
Also they think it's unlikely Zen will be available in January given the current state of the platform, even a March mass availability is optimistic.
Info I got from reading their file on Intel:
They have internal sources at Intel and the climate there is currently awful apparently, employees are very discouraged and some feel like "they have nothing left to lose". They are making big profits now by totally screwing up the future. According to the magazine, Intel is "probably in the most delicate situation it has had to face to this day". The CEO is reducing cost so much that he's managing engineers like "supermarket cashiers", he doesn't care about taking the time to train them.
Krzanich is very impatient and eager and keeps changing his mind about projects. If a new architecture isn't created in like a couple weeks, he gives up and cancels the project... he keeps sending contradictory instructions to the teams.
"Fab Hell": Intel is likely going to have a 6 month delay on 10nm. Worse, even Cannon Lake is not expected to feature any significant architectural improvement. Basically Intel was just hoping AMD would keep not competing with them.
Krzanich is apparently a disaster, and he won't be able to stay CEO for long. Apparently some people have heard him yelling from the next building when he was angry. But he seems unaware of him being perceived so negatively. Employees at Intel hope Murthy Renduchintala will replace him ASAP, and he seems much more capable and is slowly refocusing Intel in the right path, but basically R&D is fucked atm and there will be a huge empty space until about 2019. Apparently, Krzanich completely underestimated the possibility of an AMD comeback.
(I didn't really understand that point I'm not expert enough) but apparently x86 is going to disappear sooner than expected, it'll be replaced by ARM and Intel is panicking about that.
Intel is currently working on a "multichip package" (MCM) integrating an Intel CPU and an AMD GPU. So this is confirmed guys.
In the picture before the last picture I posted, it is said that Kaby Lake has exactly the same IPC as Skylake. No improvement as to perf/watt but there seems to be more room for overclocking.
Their conclusion is that if AMD doesn't mess up the launch, "Zen obviously has the necessary capacities to shake up the market..."
Link alle scansioni del giornale francese:
https://www.reddit.com/r/AMD_Stock/comments/5k31sr/i_bought_canard_pc_there_you_go/
http://imgur.com/a/KOXPd
Roland74Fun
24-12-2016, 19:12
Mi pare poco credibile che siano nel panico. Quei virgolettati poi.....
paolo.oliva2
24-12-2016, 19:24
Da anandtech:
La situazione di INTEL:
Link alle scansioni del giornale francese:
https://www.reddit.com/r/AMD_Stock/comments/5k31sr/i_bought_canard_pc_there_you_go/
http://imgur.com/a/KOXPd
Da panico.
Lo dicevo io che Intel si era seduta... altro che ricerca programmata.
"A quanto pare, Krzanich completamente sottovalutato la possibilità di un ritorno AMD. R&D... uno spazio vuoto enorme fino a circa 2019.
Intel sta attualmente lavorando su un "pacchetto multichip" (MCM) che integra una CPU Intel e una GPU AMD. Quindi, questo è confermato ragazzi.".
"Fab Hell": Intel è probabile che per avere un ritardo di 6 mesi su 10nm. Peggio ancora, anche Cannon Lago non si prevede per caratterizzare qualsiasi significativo miglioramento architettonico. Fondamentalmente Intel stava sperando AMD avrebbe mantenuto non in competizione con loro.
Quindi se l'atmosfera è questa, di certo Zen poco non può essere.
----
Se io fossi AMD, sfrutterei al max il 1° anno di Zen vendendo a tabula rasa.
Prezzo basso e avanti Savoia. :)
La situazione di INTEL:
Link alle scansioni del giornale francese:
https://www.reddit.com/r/AMD_Stock/comments/5k31sr/i_bought_canard_pc_there_you_go/
http://imgur.com/a/KOXPd
Da panico.
Lo dicevo io che Intel si era seduta... altro che ricerca programmata.
"A quanto pare, Krzanich completamente sottovalutato la possibilità di un ritorno AMD. R&D... uno spazio vuoto enorme fino a circa 2019.
Intel sta attualmente lavorando su un "pacchetto multichip" (MCM) che integra una CPU Intel e una GPU AMD. Quindi, questo è confermato ragazzi.".
"Fab Hell": Intel è probabile che per avere un ritardo di 6 mesi su 10nm. Peggio ancora, anche Cannon Lago non si prevede per caratterizzare qualsiasi significativo miglioramento architettonico. Fondamentalmente Intel stava sperando AMD avrebbe mantenuto non in competizione con loro.
Quindi se l'atmosfera è questa, di certo Zen poco non può essere.
----
Se io fossi AMD, sfrutterei al max il 1° anno di Zen vendendo a tabula rasa.
Prezzo basso e avanti Savoia. :)
Emaximus
24-12-2016, 19:25
Mi pare poco credibile che siano nel panico. Quei virgolettati poi.....
Penso anche io. Dubito fortemente ci sia una situazione del genere in Intel.
Penso anche io. Dubito fortemente ci sia una situazione del genere in Intel.
paolo.oliva2
24-12-2016, 19:37
si concordo, va tutto relazionato all'esigenza e al tipo di utilizzo reale.
Io ho la sensazione che se AMD venderà Zen X8+8 a 300€, gran parte avrebbe l'esigenza di 16TH. :)
poi ovviamente continuano comunque a spingere il possibile sulle frequenze e sull'st perché c'è un grosso mercato a cui interessa quello e perchè rimane comunque molto complicato parallelizzare "bene" i compiti da svolgere
Ma è questo il punto. La massima frequenza turbo non è scritto da nessuna parte che la può avere solamente un procio con numero nativo di core basso. E' solamente la gestione del procio, perchè con una buona logica di funzionamento (disattivazione di parti non utilizzate), in linea di massima un X32 con 28 core disattivati (e pure la relativa parte di L3), risulterebbe nè più nè meno come un X4 nativo.
Poi è ovvio che se fai pagare un X8 1000€, mi prendo un X4 a 300€, perchè 700€ non li spendo per qualche volta con l'MT. Ma se mi piazzi l'X8 a 300€ e l'X4 a 250€, nessuno ci pensa e tutti acquisterebbero l'X8.
Togli la bandiera e qualsiasi brand. Tu acquisteresti un 6700K a 250$ SE un 6900K ti costasse 350$ e lo monteresti sulla STESSA mobo? Io penso che chi solamente ha seri problemi di budget non prenderebbe il 6900K, e se ne fregherebbe alla grande dell'ST e di tutte le menate.
dovrebbe bastare settare come grafica primaria la pci-e per disattivare la igpu.
K, non lo sapevo, ora lo so.
Io ho la sensazione che se AMD venderà Zen X8+8 a 300€, gran parte avrebbe l'esigenza di 16TH. :)
poi ovviamente continuano comunque a spingere il possibile sulle frequenze e sull'st perché c'è un grosso mercato a cui interessa quello e perchè rimane comunque molto complicato parallelizzare "bene" i compiti da svolgere
Ma è questo il punto. La massima frequenza turbo non è scritto da nessuna parte che la può avere solamente un procio con numero nativo di core basso. E' solamente la gestione del procio, perchè con una buona logica di funzionamento (disattivazione di parti non utilizzate), in linea di massima un X32 con 28 core disattivati (e pure la relativa parte di L3), risulterebbe nè più nè meno come un X4 nativo.
Poi è ovvio che se fai pagare un X8 1000€, mi prendo un X4 a 300€, perchè 700€ non li spendo per qualche volta con l'MT. Ma se mi piazzi l'X8 a 300€ e l'X4 a 250€, nessuno ci pensa e tutti acquisterebbero l'X8.
Togli la bandiera e qualsiasi brand. Tu acquisteresti un 6700K a 250$ SE un 6900K ti costasse 350$ e lo monteresti sulla STESSA mobo? Io penso che chi solamente ha seri problemi di budget non prenderebbe il 6900K, e se ne fregherebbe alla grande dell'ST e di tutte le menate.
dovrebbe bastare settare come grafica primaria la pci-e per disattivare la igpu.
K, non lo sapevo, ora lo so.
mtk
24-12-2016, 19:50
ho un deja vu'......mi ricorda tanto la sfilata in stile gay pride per bulldozer....infatti poi in tanti l han preso in....tasca...
calma e gesso,vediamo i risultati e poi vediamo se far festa o no....
io tifo chi mi offre di piu' per il poco che voglio spendere...amd 64 3800x2,intel pentium d920,core 2 quad 6600,720 be,fx 8350....
pazienza e via,vediamo che succede....
calma e gesso,vediamo i risultati e poi vediamo se far festa o no....
io tifo chi mi offre di piu' per il poco che voglio spendere...amd 64 3800x2,intel pentium d920,core 2 quad 6600,720 be,fx 8350....
pazienza e via,vediamo che succede....
paolo.oliva2
24-12-2016, 19:52
Penso anche io. Dubito fortemente ci sia una situazione del genere in Intel.
(se era riferito a me)
Io ho scritto panico, ma era un modo di dire... però bisogna sottolineare che Intel ha tempistiche ben più lunghe di AMD, perchè essendo un'azienda molto più grande, ha spostamenti logistici più "pesanti".
AMD con il Phenom si è seduta, e Intel gli ha mangiato gli spaghetti sulla testa.
La situazione AMD antecedente com'era? Silicio 28nm Bulk, Intel 14nm con la previsione 14nm+. Architettura BD e Intel Broadwell.
Intel ha sottovalutato AMD... perchè in questi anni, non avendo e non potendo realizzare granchè, si è dedicata a circuiti atti per risparmiare il più possibile il consumo (BR ne è l'esempio) e nel contempo ha progettato un'architettura nuova, accorpando tutte le features del risparmio energetico + ovviamente, un'architettura studiata per il 14nm.
Chi tra noi non ha pensato "il 14nm Intel è il migliore... AMD con GF non ce la può fare ad arrivare alla stessa efficienza", "Intel è 15 anni che è sull'SMT, AMD con Zen sarebbe alla prima stesura"... AMD non ha fatto il miracolo, inteso come AMD+Keller, ma si è trovata nel momento giusto al posto giusto. Zen nuova architettura studiata da Keller (e scusate se è poco), con tutte le features di risparmio energetico che AMD è stata costretta a realizzare per rendere almeno appetibile un BR + 28nm vs un Broadwell 14nm, e nel contempo Intel che ha massimizzato i guadagni a scapito degli investimenti R&D architetturali, investendo solamente sul silicio e campando di rendita.
Io non vedo un problema specifico di Intel con Zen, forse lato prezzi... ma per come è scritto su quell'articolo, prima del 10nm (rinviato di ulteriori 6 mesi) e cioè fino al 2019, non ci sarebbero cambiamenti architetturali se non quel +2/5% di IPC a release. Zen dal 14nm al 7nm si prevedono aumenti di potenza del 10/20% e riduzioni di consumo del 30%... e cosa proporrà Intel?
In questo senso il panico lo vedo e molto, ma non verso Zen del 1° trimestre 2017.
(se era riferito a me)
Io ho scritto panico, ma era un modo di dire... però bisogna sottolineare che Intel ha tempistiche ben più lunghe di AMD, perchè essendo un'azienda molto più grande, ha spostamenti logistici più "pesanti".
AMD con il Phenom si è seduta, e Intel gli ha mangiato gli spaghetti sulla testa.
La situazione AMD antecedente com'era? Silicio 28nm Bulk, Intel 14nm con la previsione 14nm+. Architettura BD e Intel Broadwell.
Intel ha sottovalutato AMD... perchè in questi anni, non avendo e non potendo realizzare granchè, si è dedicata a circuiti atti per risparmiare il più possibile il consumo (BR ne è l'esempio) e nel contempo ha progettato un'architettura nuova, accorpando tutte le features del risparmio energetico + ovviamente, un'architettura studiata per il 14nm.
Chi tra noi non ha pensato "il 14nm Intel è il migliore... AMD con GF non ce la può fare ad arrivare alla stessa efficienza", "Intel è 15 anni che è sull'SMT, AMD con Zen sarebbe alla prima stesura"... AMD non ha fatto il miracolo, inteso come AMD+Keller, ma si è trovata nel momento giusto al posto giusto. Zen nuova architettura studiata da Keller (e scusate se è poco), con tutte le features di risparmio energetico che AMD è stata costretta a realizzare per rendere almeno appetibile un BR + 28nm vs un Broadwell 14nm, e nel contempo Intel che ha massimizzato i guadagni a scapito degli investimenti R&D architetturali, investendo solamente sul silicio e campando di rendita.
Io non vedo un problema specifico di Intel con Zen, forse lato prezzi... ma per come è scritto su quell'articolo, prima del 10nm (rinviato di ulteriori 6 mesi) e cioè fino al 2019, non ci sarebbero cambiamenti architetturali se non quel +2/5% di IPC a release. Zen dal 14nm al 7nm si prevedono aumenti di potenza del 10/20% e riduzioni di consumo del 30%... e cosa proporrà Intel?
In questo senso il panico lo vedo e molto, ma non verso Zen del 1° trimestre 2017.
Gioz
24-12-2016, 20:02
Io ho la sensazione che se AMD venderà Zen X8+8 a 300€, gran parte avrebbe l'esigenza di 16TH. :)
bhè si, è la ragione per cui ti avevo detto che secondo me non è da fanboy sperare in prestazioni buone (non dico più/meno/pari, semplicemente buone...poi si quantificherà), come sembra che sia, ad un prezzo inferiore.
dovesse costare così poco il processore 8/16 risulterebbe allettante anche per chi non ne ha bisogno.
ma in fondo, come mi pare abbia spesso scritto anche tu, guardando ad intel anche tra il 6700k ed il 5820k(ed anche il 6800K tutto sommato, guardando su trovaprezzi e simili) il salto economico non sarebbe terrificante e finisce per pesare di più o quasi la mobo dato che per uno con 160-200€ ne prendi una molto valida, sull'altra toccherebbe spendere 100-150€ extra.
ovviamente l'esigenza si piega ai vantaggi ipotetici di un prezzo conveniente, soprattutto se fosse così conveniente...però non credo che ryzen 8/16, in particolare con le prestazioni che sembrano emergere, possa costare così poco
Ma è questo il punto. La massima frequenza turbo non è scritto da nessuna parte che la può avere solamente un procio con numero nativo di core basso. E' solamente la gestione del procio, perchè con una buona logica di funzionamento (disattivazione di parti non utilizzate), in linea di massima un X32 con 28 core disattivati (e pure la relativa parte di L3), risulterebbe nè più nè meno come un X4 nativo.
Poi è ovvio che se fai pagare un X8 1000€, mi prendo un X4 a 300€, perchè 700€ non li spendo per qualche volta con l'MT. Ma se mi piazzi l'X8 a 300€ e l'X4 a 250€, nessuno ci pensa e tutti acquisterebbero l'X8.
io sinceramente sono fiducioso per le frequenze massime ed il turbo.
finchè si parla di ES non le prendo per certe, e questa prova sulla rivista francese torna a far ben sperare anche per consumi.
Togli la bandiera e qualsiasi brand. Tu acquisteresti un 6700K a 250$ SE un 6900K ti costasse 350$ e lo monteresti sulla STESSA mobo? Io penso che chi solamente ha seri problemi di budget non prenderebbe il 6900K, e se ne fregherebbe alla grande dell'ST e di tutte le menate.
sono d'accordo con te sul concetto, ma sono povero come una scimmia quindi dovessi cambiare oggi probabilmente prenderei qualcosa a 200$ che va meno sia in ST che MT :cry: :cry:
bhè si, è la ragione per cui ti avevo detto che secondo me non è da fanboy sperare in prestazioni buone (non dico più/meno/pari, semplicemente buone...poi si quantificherà), come sembra che sia, ad un prezzo inferiore.
dovesse costare così poco il processore 8/16 risulterebbe allettante anche per chi non ne ha bisogno.
ma in fondo, come mi pare abbia spesso scritto anche tu, guardando ad intel anche tra il 6700k ed il 5820k(ed anche il 6800K tutto sommato, guardando su trovaprezzi e simili) il salto economico non sarebbe terrificante e finisce per pesare di più o quasi la mobo dato che per uno con 160-200€ ne prendi una molto valida, sull'altra toccherebbe spendere 100-150€ extra.
ovviamente l'esigenza si piega ai vantaggi ipotetici di un prezzo conveniente, soprattutto se fosse così conveniente...però non credo che ryzen 8/16, in particolare con le prestazioni che sembrano emergere, possa costare così poco
Ma è questo il punto. La massima frequenza turbo non è scritto da nessuna parte che la può avere solamente un procio con numero nativo di core basso. E' solamente la gestione del procio, perchè con una buona logica di funzionamento (disattivazione di parti non utilizzate), in linea di massima un X32 con 28 core disattivati (e pure la relativa parte di L3), risulterebbe nè più nè meno come un X4 nativo.
Poi è ovvio che se fai pagare un X8 1000€, mi prendo un X4 a 300€, perchè 700€ non li spendo per qualche volta con l'MT. Ma se mi piazzi l'X8 a 300€ e l'X4 a 250€, nessuno ci pensa e tutti acquisterebbero l'X8.
io sinceramente sono fiducioso per le frequenze massime ed il turbo.
finchè si parla di ES non le prendo per certe, e questa prova sulla rivista francese torna a far ben sperare anche per consumi.
Togli la bandiera e qualsiasi brand. Tu acquisteresti un 6700K a 250$ SE un 6900K ti costasse 350$ e lo monteresti sulla STESSA mobo? Io penso che chi solamente ha seri problemi di budget non prenderebbe il 6900K, e se ne fregherebbe alla grande dell'ST e di tutte le menate.
sono d'accordo con te sul concetto, ma sono povero come una scimmia quindi dovessi cambiare oggi probabilmente prenderei qualcosa a 200$ che va meno sia in ST che MT :cry: :cry:
Nui_Mg
24-12-2016, 20:28
@Nui_Mg: la situazione in Germania non è così diversa. Ma bisognerebbe distinguere fra immigrati / clandestini, e profughi,
La situazione è PIUTTOSTO diversa (inoltre le cose in Germania stanno per cambiare, in maniera più restrittiva, pure per la Merkel che ha il coraggio di ricandidarsi), in Germania non ho mai visto, ripeto mai, tutti i casi di furti, rapine nei negozi e convivenze in case altrui bollati dal giudice di turno con la scusa di "disagio sociale" e poi di conseguenza lasciati immediatamente liberi come è successo e CONTINUA ad accadere in Italia. Inoltre in Germania non si catturano numerosissimi clandestini, rei di aver commesso l'ennesimo reato, che all'attivo hanno pure più di 5 ordinanze di espulsione dall'Italia (cosa ci facevano ancora su suolo italico? Ovvio, non vi è alcun controllo. Lo sai, inoltre, che un clandestino con il foglio di espulsione ha la possibilità di appellarsi ai tre gradi previsti dalla giustizia italiana? Lo sai che questo vuol dire tempi di attesa perfino di anni PER UN SINGOLO CLANDESTINO che abbia fatto ricorso e che quindi nel frattempo abbia la possibilità di andare/fare ciò che vuole? Lo sai invece che in Germania se hai l'ordinanza di espulsione vieni immediatamente sbattuto fuori senza se e senza ma?).
L'italia non controlla i propri confini, la Germania lo fa certamente di più (soprattutto con le persone provenienti dalle ferrovie colabrodo italiane).
Qua in Italia, come detto pure dal questore di Verona, quando è stato possibile si è calcolato che solo tre su 10 immigrati in Italia sono veramente profughi. Come detto dai tg nazionali, la Germania controlla tutto ciò che arriva dall'Italia proprio perché ha accusato l'Italia di non saper "sviscerare" tra chi è veramente profugo e chi invece è solo immigrato economico. Io vorrei poi aggiungere che è veramente un'impresa fare una tale cernita visto che i paesi dai quali provengono gli immigrati non collaborano per niente o, sempre più spesso, lo fanno in cambio di aiuti economici.
In definitiva, in Europa, Italia stracciona a parte (che ovviamente lo fa con il culo degli italiani, non con quello di chi ci governa) nessuno se li vuole accollare, al massimo oltre alpi tendono la mano per quelli che si è scoperto essere veramente profughi e che hanno una certa preparazione culturale spendibile (come il caso di Merkel e siriano accennato in precedenza). In Italia invece, OGGETTIVAMENTE entrano cani e porci.
Dalle mie parti (e già faccio sempre più fatica a vendere la mia casa, nonostante la zona turistica), altro che apporto culturale, è iniziato tutto ai tempi perfino della prima immigrazione albanese dei primi anni 90 che tantissimi sono stati costretti a mettere le inferiate e allarmi a tutto spiano (che avrebbe dovuto assolutamente finanziare il governo visto che le sue scellerate decisioni portate avanti senza alcuna seria pianificazione) alle proprie abitazioni visto che in quel periodo imperversavano albanesi, rumeni e zingari (altro che populismo, bisogna essere coglioni a negarlo, come mi dicono negli emirati arabi, dove se sei un lavoratore normale per entrare da loro devi avere uno "sponsor", e dove mi sento dire dalla mattina alla sera "voi italiani siete masochisti").
La situazione è PIUTTOSTO diversa (inoltre le cose in Germania stanno per cambiare, in maniera più restrittiva, pure per la Merkel che ha il coraggio di ricandidarsi), in Germania non ho mai visto, ripeto mai, tutti i casi di furti, rapine nei negozi e convivenze in case altrui bollati dal giudice di turno con la scusa di "disagio sociale" e poi di conseguenza lasciati immediatamente liberi come è successo e CONTINUA ad accadere in Italia. Inoltre in Germania non si catturano numerosissimi clandestini, rei di aver commesso l'ennesimo reato, che all'attivo hanno pure più di 5 ordinanze di espulsione dall'Italia (cosa ci facevano ancora su suolo italico? Ovvio, non vi è alcun controllo. Lo sai, inoltre, che un clandestino con il foglio di espulsione ha la possibilità di appellarsi ai tre gradi previsti dalla giustizia italiana? Lo sai che questo vuol dire tempi di attesa perfino di anni PER UN SINGOLO CLANDESTINO che abbia fatto ricorso e che quindi nel frattempo abbia la possibilità di andare/fare ciò che vuole? Lo sai invece che in Germania se hai l'ordinanza di espulsione vieni immediatamente sbattuto fuori senza se e senza ma?).
L'italia non controlla i propri confini, la Germania lo fa certamente di più (soprattutto con le persone provenienti dalle ferrovie colabrodo italiane).
Qua in Italia, come detto pure dal questore di Verona, quando è stato possibile si è calcolato che solo tre su 10 immigrati in Italia sono veramente profughi. Come detto dai tg nazionali, la Germania controlla tutto ciò che arriva dall'Italia proprio perché ha accusato l'Italia di non saper "sviscerare" tra chi è veramente profugo e chi invece è solo immigrato economico. Io vorrei poi aggiungere che è veramente un'impresa fare una tale cernita visto che i paesi dai quali provengono gli immigrati non collaborano per niente o, sempre più spesso, lo fanno in cambio di aiuti economici.
In definitiva, in Europa, Italia stracciona a parte (che ovviamente lo fa con il culo degli italiani, non con quello di chi ci governa) nessuno se li vuole accollare, al massimo oltre alpi tendono la mano per quelli che si è scoperto essere veramente profughi e che hanno una certa preparazione culturale spendibile (come il caso di Merkel e siriano accennato in precedenza). In Italia invece, OGGETTIVAMENTE entrano cani e porci.
Dalle mie parti (e già faccio sempre più fatica a vendere la mia casa, nonostante la zona turistica), altro che apporto culturale, è iniziato tutto ai tempi perfino della prima immigrazione albanese dei primi anni 90 che tantissimi sono stati costretti a mettere le inferiate e allarmi a tutto spiano (che avrebbe dovuto assolutamente finanziare il governo visto che le sue scellerate decisioni portate avanti senza alcuna seria pianificazione) alle proprie abitazioni visto che in quel periodo imperversavano albanesi, rumeni e zingari (altro che populismo, bisogna essere coglioni a negarlo, come mi dicono negli emirati arabi, dove se sei un lavoratore normale per entrare da loro devi avere uno "sponsor", e dove mi sento dire dalla mattina alla sera "voi italiani siete masochisti").
bjt2
24-12-2016, 20:49
Io ho la sensazione che se AMD venderà Zen X8+8 a 300€, gran parte avrebbe l'esigenza di 16TH. :)
Ma è questo il punto. La massima frequenza turbo non è scritto da nessuna parte che la può avere solamente un procio con numero nativo di core basso. E' solamente la gestione del procio, perchè con una buona logica di funzionamento (disattivazione di parti non utilizzate), in linea di massima un X32 con 28 core disattivati (e pure la relativa parte di L3), risulterebbe nè più nè meno come un X4 nativo.
Poi è ovvio che se fai pagare un X8 1000€, mi prendo un X4 a 300€, perchè 700€ non li spendo per qualche volta con l'MT. Ma se mi piazzi l'X8 a 300€ e l'X4 a 250€, nessuno ci pensa e tutti acquisterebbero l'X8.
Togli la bandiera e qualsiasi brand. Tu acquisteresti un 6700K a 250$ SE un 6900K ti costasse 350$ e lo monteresti sulla STESSA mobo? Io penso che chi solamente ha seri problemi di budget non prenderebbe il 6900K, e se ne fregherebbe alla grande dell'ST e di tutte le menate.
K, non lo sapevo, ora lo so.
Il quadcore ha frequenza maggiore di un 8c a causa del leakage. Ma sul 14nm il leakage è molto basso... Quindi mi aspetto un clock turbomax vicino per entrambi, ma solo sul 4c nativo, perchè come dicevo, i 4c derivati dall'8c sono scarti e non credo che si clocckeranno alti...
Ma è questo il punto. La massima frequenza turbo non è scritto da nessuna parte che la può avere solamente un procio con numero nativo di core basso. E' solamente la gestione del procio, perchè con una buona logica di funzionamento (disattivazione di parti non utilizzate), in linea di massima un X32 con 28 core disattivati (e pure la relativa parte di L3), risulterebbe nè più nè meno come un X4 nativo.
Poi è ovvio che se fai pagare un X8 1000€, mi prendo un X4 a 300€, perchè 700€ non li spendo per qualche volta con l'MT. Ma se mi piazzi l'X8 a 300€ e l'X4 a 250€, nessuno ci pensa e tutti acquisterebbero l'X8.
Togli la bandiera e qualsiasi brand. Tu acquisteresti un 6700K a 250$ SE un 6900K ti costasse 350$ e lo monteresti sulla STESSA mobo? Io penso che chi solamente ha seri problemi di budget non prenderebbe il 6900K, e se ne fregherebbe alla grande dell'ST e di tutte le menate.
K, non lo sapevo, ora lo so.
Il quadcore ha frequenza maggiore di un 8c a causa del leakage. Ma sul 14nm il leakage è molto basso... Quindi mi aspetto un clock turbomax vicino per entrambi, ma solo sul 4c nativo, perchè come dicevo, i 4c derivati dall'8c sono scarti e non credo che si clocckeranno alti...
Roland74Fun
24-12-2016, 20:57
ho un deja vu'......mi ricorda tanto la sfilata in stile gay pride per bulldozer....infatti poi in tanti l han preso in....tasca...
calma e gesso,vediamo i risultati e poi vediamo se far festa o no....
io tifo chi mi offre di piu' per il poco che voglio spendere...amd 64 3800x2,intel pentium d920,core 2 quad 6600,720 be,fx 8350....
Alla fine poi lo hai preso il però il procio da gay pride. :D :D
E se le cose vanno così come si sta mettendo, guardando spesa prestazioni, mi sa che ci tira ancora per due o tre anni. :)
calma e gesso,vediamo i risultati e poi vediamo se far festa o no....
io tifo chi mi offre di piu' per il poco che voglio spendere...amd 64 3800x2,intel pentium d920,core 2 quad 6600,720 be,fx 8350....
Alla fine poi lo hai preso il però il procio da gay pride. :D :D
E se le cose vanno così come si sta mettendo, guardando spesa prestazioni, mi sa che ci tira ancora per due o tre anni. :)
Piedone1113
24-12-2016, 21:45
Sulle quali non sono mai intervenuto, come sai, e non lo farò nemmeno ora. :)
.
Ps i dati di AMD erano riferiti a zen + Vs zen e non a AMD Vs Intel.
Nulla possiamo dire circa zen, anche se avevamo previsto -10 % circa Vs Intel.
.
Ps i dati di AMD erano riferiti a zen + Vs zen e non a AMD Vs Intel.
Nulla possiamo dire circa zen, anche se avevamo previsto -10 % circa Vs Intel.
Piedone1113
24-12-2016, 21:47
Buon Natale a tutti.
fatantony
24-12-2016, 22:18
Buon natale a tutti gli "aspettanti ZEN" :)
.Hellraiser.
24-12-2016, 22:19
Buon Natale a tutti!!:)
tuttodigitale
24-12-2016, 22:26
Più che altro intendo che Zen ha dalla sua un ipc maggiore rispetto a quanto aveva BD appena uscito. Ma soprattutto BD aveva un ipc ben inferiore alla sua precedente.
Quindi, oggi con il silicio adeguato anche se non eccellente possiamo disporre di un buon ipc alla stessa frequenza di thuban e BD, mica noccioline.
ci sarebbe da fare diverse precisazioni...
la prima e ovvia che hanno cambiato silicio....
kaveri in 19W va il 40% più di Richland...buona parte del merito imho va ai 28nm HMKG.
Con Carrizo/BR AMD ha fatto un ulteriore passo in avanti...ma il grosso miglioramento intorno ai 2,3-3GHz, ovvero le normali frequenze di funzionamento dei core XV, sono dovute più all'uso delle HDL che ad altro, per stessa ammissione di AMD....
imho, con i 32nm non ci sarebbe stata comunque storia, neppure con ZEN.
Se prendiamo per buoni i numeri che ho scritto:di prestazioni migliorate per ZEN del 80-85%, per un consumo superiore del 55-120% rispetto a XV, ZEN non sembra stravolgere le carte in tavola....e lo sappiamo che prima ancora delle prestazioni ST, la vera spina nel fianco dell'architettura BD, è stata la scarsa efficienza nel MT....efficienza che è migliorata con i 28nm bulk, a patto di accontentarsi di frequenze drasticamente più basse.
Quindi, oggi con il silicio adeguato anche se non eccellente possiamo disporre di un buon ipc alla stessa frequenza di thuban e BD, mica noccioline.
ci sarebbe da fare diverse precisazioni...
la prima e ovvia che hanno cambiato silicio....
kaveri in 19W va il 40% più di Richland...buona parte del merito imho va ai 28nm HMKG.
Con Carrizo/BR AMD ha fatto un ulteriore passo in avanti...ma il grosso miglioramento intorno ai 2,3-3GHz, ovvero le normali frequenze di funzionamento dei core XV, sono dovute più all'uso delle HDL che ad altro, per stessa ammissione di AMD....
imho, con i 32nm non ci sarebbe stata comunque storia, neppure con ZEN.
Se prendiamo per buoni i numeri che ho scritto:di prestazioni migliorate per ZEN del 80-85%, per un consumo superiore del 55-120% rispetto a XV, ZEN non sembra stravolgere le carte in tavola....e lo sappiamo che prima ancora delle prestazioni ST, la vera spina nel fianco dell'architettura BD, è stata la scarsa efficienza nel MT....efficienza che è migliorata con i 28nm bulk, a patto di accontentarsi di frequenze drasticamente più basse.
tuttodigitale
24-12-2016, 22:44
Quindi un pò per logica mi viene da pensare che se Zen davvero raggiunge queste frequenze con otto core a 95 w di tdp sul 14 perché non dovrebbe come esacore anche a 125 sul 32 o sul 28nm?
la mia obiezione era sul fatto che ZEN fosse efficiente più di XV solo perchè è un progetto SMT classico.
se prendi i numeri che ho postato, che non sono nient'altro dovute a dichiarazioni di AMD unite a ipotesi sulla riduzione del consumo offerto dakl passaggio 28->14nm
uno ZEN x6, andrebbe confrontato con uno XV x10 o addirittura x14.
Quello che voglio dire che la tanto eclatante efficienza di ZEN pare averla pure XV, che però rimane un progetto senza sbocco, mentre ZEN può ancora migliorare molto come è successo con il predecessore.
Infatti, e qui si torna sempre allo stesso punto...in 15W di TDP, AMD ha messo il doppio dei core con frequenza del 20% più alta, rispetto a quanto fatto da Intel su i 22nm finfet....e Intel ha presentato un octacore Haswell desktop e un 22 core server....:read:
la mia obiezione era sul fatto che ZEN fosse efficiente più di XV solo perchè è un progetto SMT classico.
se prendi i numeri che ho postato, che non sono nient'altro dovute a dichiarazioni di AMD unite a ipotesi sulla riduzione del consumo offerto dakl passaggio 28->14nm
uno ZEN x6, andrebbe confrontato con uno XV x10 o addirittura x14.
Quello che voglio dire che la tanto eclatante efficienza di ZEN pare averla pure XV, che però rimane un progetto senza sbocco, mentre ZEN può ancora migliorare molto come è successo con il predecessore.
Infatti, e qui si torna sempre allo stesso punto...in 15W di TDP, AMD ha messo il doppio dei core con frequenza del 20% più alta, rispetto a quanto fatto da Intel su i 22nm finfet....e Intel ha presentato un octacore Haswell desktop e un 22 core server....:read:
paolo.oliva2
24-12-2016, 23:13
la mia obiezione era sul fatto che ZEN fosse efficiente più di XV solo perchè è un progetto SMT classico.
se prendi i numeri che ho postato, che non sono nient'altro dovute a dichiarazioni di AMD unite a ipotesi sulla riduzione del consumo offerto dakl passaggio 28->14nm
uno ZEN x6, andrebbe confrontato con uno XV x10 o addirittura x14.
Quello che voglio dire che la tanto eclatante efficienza di ZEN pare averla pure XV, che però rimane un progetto senza sbocco, mentre ZEN può ancora migliorare molto come è successo con il predecessore.
Infatti, e qui si torna sempre allo stesso punto...in 15W di TDP, AMD ha messo il doppio dei core con frequenza del 20% più alta, rispetto a quanto fatto da Intel su i 22nm finfet....e Intel ha presentato un octacore Haswell desktop e un 22 core server....:read:
Però io penso che ci sono dei punti precisi che non bisogna trascurare.
Dal Thuban a Zambesi, la frequenza di Zambesi era penosa, ovvero rappresentava il passaggio dal 45nm al 32nm HKMG. Piledriver ha aumentato le frequenze solamente grazie all'RCM (+400MHz). Poi Buldsozer è rimasto fermo li nella fascia FX, eccetto l'8370 con +100MHz di turbo.
Invece da Trinity negli APU ci si è evoluti a Steamroller e Excavator, con tante features di risparmio energetico.
Ed ecco che arriva Zen, ma Zen integra quanto fatto su BR con probabilmente delle aggiunte, inoltre AMD ha perfezionato di brutto la gestione delle frequenze/turbo.
Beh... se confronti BD Piledriver, BD BR e Zen, tra Zen e BR diciamo che siamo lì, ma tra Zen e Piledriver non c'è storia, ma siccome BR e Piledriver sono sempre Buldozer, mi pare ovvio che la differenza non sia l'architettura, quanto il silicio e le features applicate all'architettura.
Se guardi tutti i confronti, c'è sempre l'8350 e il 9590, è ovvio che nella classe desktop media non ci puoi mettere BR, e in commercio AMD ha ancora Piledriver di certo non per colpa di altri, però va valutato, se parliamo di architettura e di efficienze architetturali, non puoi prendere un procio di 5 anni fa e dire "cacchio come consuma, l'architettura BD è un cesso", se poi la stessa architettura, nelle vesti di BR, è efficiente similarmente a Zen. Giudicheresti l'efficienza dell'architettura SMT prendendo un 2600K (epoca 8350) e lo confronteresti a Zen? Ovvio che no, prenderesti un Broadwell o SkyLake. Invece è prassi prendere il procio Buldozer meno efficiente per fare il confronto... magari siamo fortunati che non prendono Zambesi.
se prendi i numeri che ho postato, che non sono nient'altro dovute a dichiarazioni di AMD unite a ipotesi sulla riduzione del consumo offerto dakl passaggio 28->14nm
uno ZEN x6, andrebbe confrontato con uno XV x10 o addirittura x14.
Quello che voglio dire che la tanto eclatante efficienza di ZEN pare averla pure XV, che però rimane un progetto senza sbocco, mentre ZEN può ancora migliorare molto come è successo con il predecessore.
Infatti, e qui si torna sempre allo stesso punto...in 15W di TDP, AMD ha messo il doppio dei core con frequenza del 20% più alta, rispetto a quanto fatto da Intel su i 22nm finfet....e Intel ha presentato un octacore Haswell desktop e un 22 core server....:read:
Però io penso che ci sono dei punti precisi che non bisogna trascurare.
Dal Thuban a Zambesi, la frequenza di Zambesi era penosa, ovvero rappresentava il passaggio dal 45nm al 32nm HKMG. Piledriver ha aumentato le frequenze solamente grazie all'RCM (+400MHz). Poi Buldsozer è rimasto fermo li nella fascia FX, eccetto l'8370 con +100MHz di turbo.
Invece da Trinity negli APU ci si è evoluti a Steamroller e Excavator, con tante features di risparmio energetico.
Ed ecco che arriva Zen, ma Zen integra quanto fatto su BR con probabilmente delle aggiunte, inoltre AMD ha perfezionato di brutto la gestione delle frequenze/turbo.
Beh... se confronti BD Piledriver, BD BR e Zen, tra Zen e BR diciamo che siamo lì, ma tra Zen e Piledriver non c'è storia, ma siccome BR e Piledriver sono sempre Buldozer, mi pare ovvio che la differenza non sia l'architettura, quanto il silicio e le features applicate all'architettura.
Se guardi tutti i confronti, c'è sempre l'8350 e il 9590, è ovvio che nella classe desktop media non ci puoi mettere BR, e in commercio AMD ha ancora Piledriver di certo non per colpa di altri, però va valutato, se parliamo di architettura e di efficienze architetturali, non puoi prendere un procio di 5 anni fa e dire "cacchio come consuma, l'architettura BD è un cesso", se poi la stessa architettura, nelle vesti di BR, è efficiente similarmente a Zen. Giudicheresti l'efficienza dell'architettura SMT prendendo un 2600K (epoca 8350) e lo confronteresti a Zen? Ovvio che no, prenderesti un Broadwell o SkyLake. Invece è prassi prendere il procio Buldozer meno efficiente per fare il confronto... magari siamo fortunati che non prendono Zambesi.
Grizlod®
25-12-2016, 00:20
Auguri di Buon Natale
sgrinfia
25-12-2016, 00:38
Buon Natale di cuore a tutti......:)
Emaximus
25-12-2016, 00:47
Buon Natale a tutti :D
george_p
25-12-2016, 01:07
ci sarebbe da fare diverse precisazioni...
la prima e ovvia che hanno cambiato silicio....
imho, con i 32nm non ci sarebbe stata comunque storia, neppure con ZEN.
Se prendiamo per buoni i numeri che ho scritto:di prestazioni migliorate per ZEN del 80-85%, per un consumo superiore del 55-120% rispetto a XV, ZEN non sembra stravolgere le carte in tavola....e lo sappiamo che prima ancora delle prestazioni ST, la vera spina nel fianco dell'architettura BD, è stata la scarsa efficienza nel MT....efficienza che è migliorata con i 28nm bulk, a patto di accontentarsi di frequenze drasticamente più basse.
Certo, sono miriadi di calcoli e fattori da considerare, ma quando io parlo di BD e Zen mi riferisco includendo per ognuno il proprio rispettivo silicio.
Ovvio che Zen rispetto a BD/zambesi abbia molti più transistors sia a parità di core che nel complesso. Ma almeno con Zen hanno puntato ad ottenere un buon ipc che, va ricordato, arriva molto tardi mentre con BD lo hanno pure diminuito rispetto al Thuban.
Però non è nemmeno semplice e immediato fare il confronto tra un modulo BD e due core Zen, intanto il primo ha ipc inferiore e pure una fpu in meno.
Zen consumerà di più ma va molto di più e penso che il rapporto prestazioni per watt sia molto più a favore di Zen.
Quanto consumerebbe un esacore Zen sul 32nm o sul 28nm?
Sempre meglio del PD gonfiato a 5 GHZ e con tdp da 200w non credi? Anzi, magari in quel range ci starebbe tranquillamente l'8+8, hai consumo elevato ma perlomeno vai circa il doppio.
P.s.: Buon Natale.
la prima e ovvia che hanno cambiato silicio....
imho, con i 32nm non ci sarebbe stata comunque storia, neppure con ZEN.
Se prendiamo per buoni i numeri che ho scritto:di prestazioni migliorate per ZEN del 80-85%, per un consumo superiore del 55-120% rispetto a XV, ZEN non sembra stravolgere le carte in tavola....e lo sappiamo che prima ancora delle prestazioni ST, la vera spina nel fianco dell'architettura BD, è stata la scarsa efficienza nel MT....efficienza che è migliorata con i 28nm bulk, a patto di accontentarsi di frequenze drasticamente più basse.
Certo, sono miriadi di calcoli e fattori da considerare, ma quando io parlo di BD e Zen mi riferisco includendo per ognuno il proprio rispettivo silicio.
Ovvio che Zen rispetto a BD/zambesi abbia molti più transistors sia a parità di core che nel complesso. Ma almeno con Zen hanno puntato ad ottenere un buon ipc che, va ricordato, arriva molto tardi mentre con BD lo hanno pure diminuito rispetto al Thuban.
Però non è nemmeno semplice e immediato fare il confronto tra un modulo BD e due core Zen, intanto il primo ha ipc inferiore e pure una fpu in meno.
Zen consumerà di più ma va molto di più e penso che il rapporto prestazioni per watt sia molto più a favore di Zen.
Quanto consumerebbe un esacore Zen sul 32nm o sul 28nm?
Sempre meglio del PD gonfiato a 5 GHZ e con tdp da 200w non credi? Anzi, magari in quel range ci starebbe tranquillamente l'8+8, hai consumo elevato ma perlomeno vai circa il doppio.
P.s.: Buon Natale.
paolo.oliva2
25-12-2016, 06:39
Certo, sono miriadi di calcoli e fattori da considerare, ma quando io parlo di BD e Zen mi riferisco includendo per ognuno il proprio rispettivo silicio.
Ovvio che Zen rispetto a BD/zambesi abbia molti più transistors sia a parità di core che nel complesso. Ma almeno con Zen hanno puntato ad ottenere un buon ipc che, va ricordato, arriva molto tardi mentre con BD lo hanno pure diminuito rispetto al Thuban.
Però non è nemmeno semplice e immediato fare il confronto tra un modulo BD e due core Zen, intanto il primo ha ipc inferiore e pure una fpu in meno.
Zen consumerà di più ma va molto di più e penso che il rapporto prestazioni per watt sia molto più a favore di Zen.
Quanto consumerebbe un esacore Zen sul 32nm o sul 28nm?
Sempre meglio del PD gonfiato a 5 GHZ e con tdp da 200w non credi? Anzi, magari in quel range ci starebbe tranquillamente l'8+8, hai consumo elevato ma perlomeno vai circa il doppio.
P.s.: Buon Natale.
Conta che un 8350 è 1,2 milioni di transistor e che un Zen X8+8 ne dovrebbe avere più del doppio (considerando che un 5960X ne ha 2,5 milioni).
Quindi a livello di die, se un 8350 è già 320mmq, un Zen X4+4 sui 350mmq, un Zen X6+6 sui 500mmq e un Zen X8+8 sarebbe sui 700mmq.
Ipotizzare un Zen X8+8 sul 32nm sarebbe come ipotizzare un Thuban sul 65nm o un 6950X quando Intel sul 32nm si fermava ad un X6+6.
C'è una analogia di transistor... cioè 1 modulo BD = 1 core Zen. Quindi già ipotizzare un Zen X6+6 equivarrebbe a dire un FX X12, e AMD ha dovuto rinunciare a Komodo X10 che di transistor quanti ne aveva in più rispetto ad un 8350? 200.000? Zen X8+8 ne avrebbe almeno 1.300.000 in più.
Ovvio che Zen rispetto a BD/zambesi abbia molti più transistors sia a parità di core che nel complesso. Ma almeno con Zen hanno puntato ad ottenere un buon ipc che, va ricordato, arriva molto tardi mentre con BD lo hanno pure diminuito rispetto al Thuban.
Però non è nemmeno semplice e immediato fare il confronto tra un modulo BD e due core Zen, intanto il primo ha ipc inferiore e pure una fpu in meno.
Zen consumerà di più ma va molto di più e penso che il rapporto prestazioni per watt sia molto più a favore di Zen.
Quanto consumerebbe un esacore Zen sul 32nm o sul 28nm?
Sempre meglio del PD gonfiato a 5 GHZ e con tdp da 200w non credi? Anzi, magari in quel range ci starebbe tranquillamente l'8+8, hai consumo elevato ma perlomeno vai circa il doppio.
P.s.: Buon Natale.
Conta che un 8350 è 1,2 milioni di transistor e che un Zen X8+8 ne dovrebbe avere più del doppio (considerando che un 5960X ne ha 2,5 milioni).
Quindi a livello di die, se un 8350 è già 320mmq, un Zen X4+4 sui 350mmq, un Zen X6+6 sui 500mmq e un Zen X8+8 sarebbe sui 700mmq.
Ipotizzare un Zen X8+8 sul 32nm sarebbe come ipotizzare un Thuban sul 65nm o un 6950X quando Intel sul 32nm si fermava ad un X6+6.
C'è una analogia di transistor... cioè 1 modulo BD = 1 core Zen. Quindi già ipotizzare un Zen X6+6 equivarrebbe a dire un FX X12, e AMD ha dovuto rinunciare a Komodo X10 che di transistor quanti ne aveva in più rispetto ad un 8350? 200.000? Zen X8+8 ne avrebbe almeno 1.300.000 in più.
cdimauro
25-12-2016, 08:05
Ma com'è che si parla tanto di quanto fosse fico ed efficiente BD, e che la colpa delle sue prestazioni sia stata del silicio, ma poi posto il link coi benchmark, dove si vede che oggettivamente il suo IPC fosse alquanto scarso, e "stranamente" i suoi difensori fanno finta di non averlo visto... :rolleyes:
ho avuto modo di utilizzare tempo addietro un processore Transmeta e ne sono rimasto affascinato.
Da allora il mio sogno e' un piccolissimo core fisico a basso consumo visto dal sistema come 16 o piu' core logici ed una FPGA molto estesa che viene riconfigurata ed attivata solo quando serve e solo per le istruzioni che sono in coda e che non riescono a venir processate dal piccolo core fisico.
In pratica accenderei i transistor solo quando servono e solo configurati per risolvere le istruzioni che gia' sono in coda
OK, ma se il core fisico è piccolissimo immagino che non sia molto "general purpose".
Personalmente la mia sfida è realizzare processori general purpose, utilizzabili in qualunque ambito: dall'embedded all'HPC.
A proposito: AUGURI!
Grazie, e anche a te e a tutti. :)
E' tutto molto fluido. Avevo pensato a una ISA a lunghezza variabile, ma con unità da 32 bit, di cui la prima divisa tra opcode (da cui derivare il numero di parametri, con opcode diversi per add1 2 ecc e magari bit iniziali diversi per istruzioni intere, fp ecc) e bit per la numerosità. Avevo pensato ad almeno 3 bit, con potenze di due crescenti, quindi con 111=256 elementi. Gli altri per opcode e numero parametri. E poi blocchi di 32 bit per i parametri, con bit per tipo di indirizzamento e indirizzo ecc. Ovviamente nessun limite e teoricamente possibilità di avere anche istruzioni ternarie con 3 operandi memoria, anche indiretti. Un vero CISCone! Ma ovviamente era solo una idea allo stato embrionale.
OK, quindi non ti sei messo a stilare la opcode table, definendo minuziosamente tutte le strutture. E' un esercizio che potresti fare. :fagiano:
Comunque a primo acchito prevedo una scarsa densità di codice per la tua ISA, perché tutta quella flessibilità si paga, anche se l'hai definita a lunghezza variabile. Il problema è rappresentato dall'unità base rappresentata da 32 bit, che sono ben 4 byte.
Per farti un esempio, disassemblando la beta pubblica di Photoshop CS6 ottengo (su circa 1,7 milioni di istruzioni disassemblate) una media di 3.2 byte per x86 (quindi istruzioni a 32 bit) e 3.4 per la seconda versione della mia ISA (che è leggermente meno densa, ma perché non sfrutto nulla: sempre e solo 8 registri, pur avendone 32 a disposizione nello stesso opcode. Giusto per fare soltanto un esempio). Mentre per x64 ottengo 4.3, e 3.6 per la mia seconda ISA (anche qui non usando niente).
Se provi a fare qualcosa del genere con la tua ISA, penso che la media esploderà, a livelli superiori anche a x64 (che è già molto scarsa come densità: si fa battere persino da ARM64).
Che io sappia tutte le caches, essendo memorie associative, comparano in parallelo i vari tag. Quindi anche i TLB. Ma il problema è l'organizzazione a vie. Una cache come vorrei farla io dovrebbe essere fully associative e comparare TUTTI i tag in parallelo. Quindi la devi fare piccola. E' da vedere se bastano 16-32 ranges, visto che i SO non sono obbligati a fare allocazioni consecutive.
Se ci sono pochi range il vantaggio sarebbe tangibile. Se ce ne sono troppi, a questo punto tanto vale tenersi i TLB, che oggigiorno sono abbastanza ben dimensionati.
L'idea di AMD è geniale, perchè la comparazione è uguale al caso standard, solo che mascheri 3 bit bassi.
Sicuro che siano quelli bassi, e non i 3 bit immediatamente sopra la dimensione della pagina?
E' un ottimo compromesso, ma il range di pagine 4k deve essere allineato a 32kb... Suggerirei ad AMD di almeno estendere a 16/32/64 ecc pagine consecutive... Magari lo faranno in Zen+...
Su Linux / ELF mi pare che le sezioni abbiano una granularità di 64KB.
Bellissimo! Lo sai, vero, che gcc (e penso tutti i compilatori, magari per ICC ce lo puoi dire tu se lo ricordi) chiama il compilatore c che spara codice assembler e poi l'assemblatore e il linker? E che se non sbaglio, almeno l'assemblatore di gcc è abbastanza standard ed ha un file di configurazione per mappare le istruzioni assembler in opcode? Potresti studiarti il formato e scrivere il file per la tua ISA... Comprese le nuove istruzioni... Poi basterebbe solo cambiare isa target in gcc et voilà...
Preferisco evitare GCC, perché cambiando soltanto l'assemblatore non potrei sfruttare nulla della mia ISA. Quindi dovrei cambiare il backend, e qui è un bagno di sangue: molto meglio passare a LLVM, che rende la vita decisamente più semplice.
Ma prima devo finire lo script Python per analizzare densità e statistiche. E ho già in programma pure una quinta versione, perché parlandone fra ieri e stamattina mi sono venute in mente altre idee. Neverendingstory. :asd:
Da anandtech:
La situazione di INTEL:
Link alle scansioni del giornale francese:
https://www.reddit.com/r/AMD_Stock/comments/5k31sr/i_bought_canard_pc_there_you_go/
http://imgur.com/a/KOXPd
Mi pare poco credibile che siano nel panico. Quei virgolettati poi.....
La penso allo stesso modo. Tra l'altro fino all'ultimo giorno ho avuto accesso al portale interno dell'azienda, e fino al 22 l'unica cosa di Ry/Zen che ho letto era della sua ultima presentazione. Dunque niente crisi et similia.
Ma su una cosa sono d'accordo: credo che Murthy diventerà il prossimo CEO. E' uno squalo, ma a Qualcomm ha fatto molto bene, e ho visto una sua presentazione qualche mese fa: è davvero una persona molto in gamba.
Da panico.
Lo dicevo io che Intel si era seduta... altro che ricerca programmata.
Ma anche no: tu hai detto molte cose, e non mi pare che ne abbia azzeccate così tante. :D
Lascia perdere.
Se io fossi AMD, sfrutterei al max il 1° anno di Zen vendendo a tabula rasa.
Prezzo basso e avanti Savoia. :)
Meno male che non sei AMD, perché la porteresti rapidamente al fallimento. :asd:
Penso anche io. Dubito fortemente ci sia una situazione del genere in Intel.
*
(se era riferito a me)
Io ho scritto panico, ma era un modo di dire... però bisogna sottolineare che Intel ha tempistiche ben più lunghe di AMD, perchè essendo un'azienda molto più grande, ha spostamenti logistici più "pesanti".
Anche qui, decisamente no.
I cambiamenti sono lunghi per altre ragioni: perché la progettazione parte un bel po' di anni prima.
Intel ha sottovalutato AMD... perchè in questi anni, non avendo e non potendo realizzare granchè, si è dedicata a circuiti atti per risparmiare il più possibile il consumo (BR ne è l'esempio) e nel contempo ha progettato un'architettura nuova, accorpando tutte le features del risparmio energetico + ovviamente, un'architettura studiata per il 14nm.
Perché parli con certezza, quando questi sono soltanto rumor?
Chi tra noi non ha pensato "il 14nm Intel è il migliore... AMD con GF non ce la può fare ad arrivare alla stessa efficienza", "Intel è 15 anni che è sull'SMT, AMD con Zen sarebbe alla prima stesura"... AMD non ha fatto il miracolo, inteso come AMD+Keller, ma si è trovata nel momento giusto al posto giusto. Zen nuova architettura studiata da Keller (e scusate se è poco),
Non mi pare che gli ingegneri Intel abbiano qualcosa meno di Keller.
con tutte le features di risparmio energetico che AMD è stata costretta a realizzare per rendere almeno appetibile un BR + 28nm vs un Broadwell 14nm, e nel contempo Intel che ha massimizzato i guadagni a scapito degli investimenti R&D architetturali, investendo solamente sul silicio e campando di rendita.
Come ribaltare completamente la realtà. Continui ancora a spacciare le tue fantasie per realtà.
E' l'esatto contrario: in questi anni Intel ha AUMENTATO gli investimenti in R&D. :read:
Perché, come ti ho già suggerito non so quante volte, non ti limiti a parlare di cose che realmente conosci?
La situazione è PIUTTOSTO diversa (inoltre le cose in Germania stanno per cambiare, in maniera più restrittiva, pure per la Merkel che ha il coraggio di ricandidarsi), in Germania non ho mai visto, ripeto mai, tutti i casi di furti, rapine nei negozi e convivenze in case altrui bollati dal giudice di turno con la scusa di "disagio sociale" e poi di conseguenza lasciati immediatamente liberi come è successo e CONTINUA ad accadere in Italia. Inoltre in Germania non si catturano numerosissimi clandestini, rei di aver commesso l'ennesimo reato, che all'attivo hanno pure più di 5 ordinanze di espulsione dall'Italia (cosa ci facevano ancora su suolo italico? Ovvio, non vi è alcun controllo. Lo sai, inoltre, che un clandestino con il foglio di espulsione ha la possibilità di appellarsi ai tre gradi previsti dalla giustizia italiana? Lo sai che questo vuol dire tempi di attesa perfino di anni PER UN SINGOLO CLANDESTINO che abbia fatto ricorso e che quindi nel frattempo abbia la possibilità di andare/fare ciò che vuole? Lo sai invece che in Germania se hai l'ordinanza di espulsione vieni immediatamente sbattuto fuori senza se e senza ma?).
L'italia non controlla i propri confini, la Germania lo fa certamente di più (soprattutto con le persone provenienti dalle ferrovie colabrodo italiane).
Qua in Italia, come detto pure dal questore di Verona, quando è stato possibile si è calcolato che solo tre su 10 immigrati in Italia sono veramente profughi. Come detto dai tg nazionali, la Germania controlla tutto ciò che arriva dall'Italia proprio perché ha accusato l'Italia di non saper "sviscerare" tra chi è veramente profugo e chi invece è solo immigrato economico. Io vorrei poi aggiungere che è veramente un'impresa fare una tale cernita visto che i paesi dai quali provengono gli immigrati non collaborano per niente o, sempre più spesso, lo fanno in cambio di aiuti economici.
Prima mi riferivo ai benefit che gli immigrati ricevono in Germania, visto che era di questo che vi lamentavate in Italia.
Se proprio vogliamo dirla tutta, la differenza è che la Germania ha un sistema di walfare per tutti, mentre l'Italia no, ed è questo che esacerba i conflitti.
In definitiva, in Europa, Italia stracciona a parte (che ovviamente lo fa con il culo degli italiani, non con quello di chi ci governa)
Cosa non ti è chiaro del fatto che la nostra è una democrazia RAPPRESENTATIVA, e chi ci governa nasce dal "culo degli italiani"?
nessuno se li vuole accollare, al massimo oltre alpi tendono la mano per quelli che si è scoperto essere veramente profughi e che hanno una certa preparazione culturale spendibile (come il caso di Merkel e siriano accennato in precedenza). In Italia invece, OGGETTIVAMENTE entrano cani e porci.
In Italia entrano anche i clandestini, ma è ovvio che sia così, vista la vicinanza con l'Africa. E' una questione meramente logistica.
In Germania mica "sbarcano" i clandestini...
Dalle mie parti (e già faccio sempre più fatica a vendere la mia casa, nonostante la zona turistica), altro che apporto culturale, è iniziato tutto ai tempi perfino della prima immigrazione albanese dei primi anni 90 che tantissimi sono stati costretti a mettere le inferiate e allarmi a tutto spiano (che avrebbe dovuto assolutamente finanziare il governo visto che le sue scellerate decisioni portate avanti senza alcuna seria pianificazione) alle proprie abitazioni visto che in quel periodo imperversavano albanesi, rumeni e zingari (altro che populismo, bisogna essere coglioni a negarlo, come mi dicono negli emirati arabi, dove se sei un lavoratore normale per entrare da loro devi avere uno "sponsor", e dove mi sento dire dalla mattina alla sera "voi italiani siete masochisti").
Mentre in Germania non hai notato nessun cambiamento, immagino.
La situazione sta cambiando anche qui, da un po' di tempo.
"Basta" viverci.
E finché ci sarà gente disperata, sarà così. Anche e soprattutto per colpa della nostra politica di colonizzazione ed "esportazione della democrazia".
Ma questo non fa mai comodo ricordarlo, vero?
Ps i dati di AMD erano riferiti a zen + Vs zen e non a AMD Vs Intel.
Nulla possiamo dire circa zen, anche se avevamo previsto -10 % circa Vs Intel.
OK, grazie del chiarimento.
ho avuto modo di utilizzare tempo addietro un processore Transmeta e ne sono rimasto affascinato.
Da allora il mio sogno e' un piccolissimo core fisico a basso consumo visto dal sistema come 16 o piu' core logici ed una FPGA molto estesa che viene riconfigurata ed attivata solo quando serve e solo per le istruzioni che sono in coda e che non riescono a venir processate dal piccolo core fisico.
In pratica accenderei i transistor solo quando servono e solo configurati per risolvere le istruzioni che gia' sono in coda
OK, ma se il core fisico è piccolissimo immagino che non sia molto "general purpose".
Personalmente la mia sfida è realizzare processori general purpose, utilizzabili in qualunque ambito: dall'embedded all'HPC.
A proposito: AUGURI!
Grazie, e anche a te e a tutti. :)
E' tutto molto fluido. Avevo pensato a una ISA a lunghezza variabile, ma con unità da 32 bit, di cui la prima divisa tra opcode (da cui derivare il numero di parametri, con opcode diversi per add1 2 ecc e magari bit iniziali diversi per istruzioni intere, fp ecc) e bit per la numerosità. Avevo pensato ad almeno 3 bit, con potenze di due crescenti, quindi con 111=256 elementi. Gli altri per opcode e numero parametri. E poi blocchi di 32 bit per i parametri, con bit per tipo di indirizzamento e indirizzo ecc. Ovviamente nessun limite e teoricamente possibilità di avere anche istruzioni ternarie con 3 operandi memoria, anche indiretti. Un vero CISCone! Ma ovviamente era solo una idea allo stato embrionale.
OK, quindi non ti sei messo a stilare la opcode table, definendo minuziosamente tutte le strutture. E' un esercizio che potresti fare. :fagiano:
Comunque a primo acchito prevedo una scarsa densità di codice per la tua ISA, perché tutta quella flessibilità si paga, anche se l'hai definita a lunghezza variabile. Il problema è rappresentato dall'unità base rappresentata da 32 bit, che sono ben 4 byte.
Per farti un esempio, disassemblando la beta pubblica di Photoshop CS6 ottengo (su circa 1,7 milioni di istruzioni disassemblate) una media di 3.2 byte per x86 (quindi istruzioni a 32 bit) e 3.4 per la seconda versione della mia ISA (che è leggermente meno densa, ma perché non sfrutto nulla: sempre e solo 8 registri, pur avendone 32 a disposizione nello stesso opcode. Giusto per fare soltanto un esempio). Mentre per x64 ottengo 4.3, e 3.6 per la mia seconda ISA (anche qui non usando niente).
Se provi a fare qualcosa del genere con la tua ISA, penso che la media esploderà, a livelli superiori anche a x64 (che è già molto scarsa come densità: si fa battere persino da ARM64).
Che io sappia tutte le caches, essendo memorie associative, comparano in parallelo i vari tag. Quindi anche i TLB. Ma il problema è l'organizzazione a vie. Una cache come vorrei farla io dovrebbe essere fully associative e comparare TUTTI i tag in parallelo. Quindi la devi fare piccola. E' da vedere se bastano 16-32 ranges, visto che i SO non sono obbligati a fare allocazioni consecutive.
Se ci sono pochi range il vantaggio sarebbe tangibile. Se ce ne sono troppi, a questo punto tanto vale tenersi i TLB, che oggigiorno sono abbastanza ben dimensionati.
L'idea di AMD è geniale, perchè la comparazione è uguale al caso standard, solo che mascheri 3 bit bassi.
Sicuro che siano quelli bassi, e non i 3 bit immediatamente sopra la dimensione della pagina?
E' un ottimo compromesso, ma il range di pagine 4k deve essere allineato a 32kb... Suggerirei ad AMD di almeno estendere a 16/32/64 ecc pagine consecutive... Magari lo faranno in Zen+...
Su Linux / ELF mi pare che le sezioni abbiano una granularità di 64KB.
Bellissimo! Lo sai, vero, che gcc (e penso tutti i compilatori, magari per ICC ce lo puoi dire tu se lo ricordi) chiama il compilatore c che spara codice assembler e poi l'assemblatore e il linker? E che se non sbaglio, almeno l'assemblatore di gcc è abbastanza standard ed ha un file di configurazione per mappare le istruzioni assembler in opcode? Potresti studiarti il formato e scrivere il file per la tua ISA... Comprese le nuove istruzioni... Poi basterebbe solo cambiare isa target in gcc et voilà...
Preferisco evitare GCC, perché cambiando soltanto l'assemblatore non potrei sfruttare nulla della mia ISA. Quindi dovrei cambiare il backend, e qui è un bagno di sangue: molto meglio passare a LLVM, che rende la vita decisamente più semplice.
Ma prima devo finire lo script Python per analizzare densità e statistiche. E ho già in programma pure una quinta versione, perché parlandone fra ieri e stamattina mi sono venute in mente altre idee. Neverendingstory. :asd:
Da anandtech:
La situazione di INTEL:
Link alle scansioni del giornale francese:
https://www.reddit.com/r/AMD_Stock/comments/5k31sr/i_bought_canard_pc_there_you_go/
http://imgur.com/a/KOXPd
Mi pare poco credibile che siano nel panico. Quei virgolettati poi.....
La penso allo stesso modo. Tra l'altro fino all'ultimo giorno ho avuto accesso al portale interno dell'azienda, e fino al 22 l'unica cosa di Ry/Zen che ho letto era della sua ultima presentazione. Dunque niente crisi et similia.
Ma su una cosa sono d'accordo: credo che Murthy diventerà il prossimo CEO. E' uno squalo, ma a Qualcomm ha fatto molto bene, e ho visto una sua presentazione qualche mese fa: è davvero una persona molto in gamba.
Da panico.
Lo dicevo io che Intel si era seduta... altro che ricerca programmata.
Ma anche no: tu hai detto molte cose, e non mi pare che ne abbia azzeccate così tante. :D
Lascia perdere.
Se io fossi AMD, sfrutterei al max il 1° anno di Zen vendendo a tabula rasa.
Prezzo basso e avanti Savoia. :)
Meno male che non sei AMD, perché la porteresti rapidamente al fallimento. :asd:
Penso anche io. Dubito fortemente ci sia una situazione del genere in Intel.
*
(se era riferito a me)
Io ho scritto panico, ma era un modo di dire... però bisogna sottolineare che Intel ha tempistiche ben più lunghe di AMD, perchè essendo un'azienda molto più grande, ha spostamenti logistici più "pesanti".
Anche qui, decisamente no.
I cambiamenti sono lunghi per altre ragioni: perché la progettazione parte un bel po' di anni prima.
Intel ha sottovalutato AMD... perchè in questi anni, non avendo e non potendo realizzare granchè, si è dedicata a circuiti atti per risparmiare il più possibile il consumo (BR ne è l'esempio) e nel contempo ha progettato un'architettura nuova, accorpando tutte le features del risparmio energetico + ovviamente, un'architettura studiata per il 14nm.
Perché parli con certezza, quando questi sono soltanto rumor?
Chi tra noi non ha pensato "il 14nm Intel è il migliore... AMD con GF non ce la può fare ad arrivare alla stessa efficienza", "Intel è 15 anni che è sull'SMT, AMD con Zen sarebbe alla prima stesura"... AMD non ha fatto il miracolo, inteso come AMD+Keller, ma si è trovata nel momento giusto al posto giusto. Zen nuova architettura studiata da Keller (e scusate se è poco),
Non mi pare che gli ingegneri Intel abbiano qualcosa meno di Keller.
con tutte le features di risparmio energetico che AMD è stata costretta a realizzare per rendere almeno appetibile un BR + 28nm vs un Broadwell 14nm, e nel contempo Intel che ha massimizzato i guadagni a scapito degli investimenti R&D architetturali, investendo solamente sul silicio e campando di rendita.
Come ribaltare completamente la realtà. Continui ancora a spacciare le tue fantasie per realtà.
E' l'esatto contrario: in questi anni Intel ha AUMENTATO gli investimenti in R&D. :read:
Perché, come ti ho già suggerito non so quante volte, non ti limiti a parlare di cose che realmente conosci?
La situazione è PIUTTOSTO diversa (inoltre le cose in Germania stanno per cambiare, in maniera più restrittiva, pure per la Merkel che ha il coraggio di ricandidarsi), in Germania non ho mai visto, ripeto mai, tutti i casi di furti, rapine nei negozi e convivenze in case altrui bollati dal giudice di turno con la scusa di "disagio sociale" e poi di conseguenza lasciati immediatamente liberi come è successo e CONTINUA ad accadere in Italia. Inoltre in Germania non si catturano numerosissimi clandestini, rei di aver commesso l'ennesimo reato, che all'attivo hanno pure più di 5 ordinanze di espulsione dall'Italia (cosa ci facevano ancora su suolo italico? Ovvio, non vi è alcun controllo. Lo sai, inoltre, che un clandestino con il foglio di espulsione ha la possibilità di appellarsi ai tre gradi previsti dalla giustizia italiana? Lo sai che questo vuol dire tempi di attesa perfino di anni PER UN SINGOLO CLANDESTINO che abbia fatto ricorso e che quindi nel frattempo abbia la possibilità di andare/fare ciò che vuole? Lo sai invece che in Germania se hai l'ordinanza di espulsione vieni immediatamente sbattuto fuori senza se e senza ma?).
L'italia non controlla i propri confini, la Germania lo fa certamente di più (soprattutto con le persone provenienti dalle ferrovie colabrodo italiane).
Qua in Italia, come detto pure dal questore di Verona, quando è stato possibile si è calcolato che solo tre su 10 immigrati in Italia sono veramente profughi. Come detto dai tg nazionali, la Germania controlla tutto ciò che arriva dall'Italia proprio perché ha accusato l'Italia di non saper "sviscerare" tra chi è veramente profugo e chi invece è solo immigrato economico. Io vorrei poi aggiungere che è veramente un'impresa fare una tale cernita visto che i paesi dai quali provengono gli immigrati non collaborano per niente o, sempre più spesso, lo fanno in cambio di aiuti economici.
Prima mi riferivo ai benefit che gli immigrati ricevono in Germania, visto che era di questo che vi lamentavate in Italia.
Se proprio vogliamo dirla tutta, la differenza è che la Germania ha un sistema di walfare per tutti, mentre l'Italia no, ed è questo che esacerba i conflitti.
In definitiva, in Europa, Italia stracciona a parte (che ovviamente lo fa con il culo degli italiani, non con quello di chi ci governa)
Cosa non ti è chiaro del fatto che la nostra è una democrazia RAPPRESENTATIVA, e chi ci governa nasce dal "culo degli italiani"?
nessuno se li vuole accollare, al massimo oltre alpi tendono la mano per quelli che si è scoperto essere veramente profughi e che hanno una certa preparazione culturale spendibile (come il caso di Merkel e siriano accennato in precedenza). In Italia invece, OGGETTIVAMENTE entrano cani e porci.
In Italia entrano anche i clandestini, ma è ovvio che sia così, vista la vicinanza con l'Africa. E' una questione meramente logistica.
In Germania mica "sbarcano" i clandestini...
Dalle mie parti (e già faccio sempre più fatica a vendere la mia casa, nonostante la zona turistica), altro che apporto culturale, è iniziato tutto ai tempi perfino della prima immigrazione albanese dei primi anni 90 che tantissimi sono stati costretti a mettere le inferiate e allarmi a tutto spiano (che avrebbe dovuto assolutamente finanziare il governo visto che le sue scellerate decisioni portate avanti senza alcuna seria pianificazione) alle proprie abitazioni visto che in quel periodo imperversavano albanesi, rumeni e zingari (altro che populismo, bisogna essere coglioni a negarlo, come mi dicono negli emirati arabi, dove se sei un lavoratore normale per entrare da loro devi avere uno "sponsor", e dove mi sento dire dalla mattina alla sera "voi italiani siete masochisti").
Mentre in Germania non hai notato nessun cambiamento, immagino.
La situazione sta cambiando anche qui, da un po' di tempo.
"Basta" viverci.
E finché ci sarà gente disperata, sarà così. Anche e soprattutto per colpa della nostra politica di colonizzazione ed "esportazione della democrazia".
Ma questo non fa mai comodo ricordarlo, vero?
Ps i dati di AMD erano riferiti a zen + Vs zen e non a AMD Vs Intel.
Nulla possiamo dire circa zen, anche se avevamo previsto -10 % circa Vs Intel.
OK, grazie del chiarimento.
bjt2
25-12-2016, 09:41
OK, quindi non ti sei messo a stilare la opcode table, definendo minuziosamente tutte le strutture. E' un esercizio che potresti fare. :fagiano:
Comunque a primo acchito prevedo una scarsa densità di codice per la tua ISA, perché tutta quella flessibilità si paga, anche se l'hai definita a lunghezza variabile. Il problema è rappresentato dall'unità base rappresentata da 32 bit, che sono ben 4 byte.
Per farti un esempio, disassemblando la beta pubblica di Photoshop CS6 ottengo (su circa 1,7 milioni di istruzioni disassemblate) una media di 3.2 byte per x86 (quindi istruzioni a 32 bit) e 3.4 per la seconda versione della mia ISA (che è leggermente meno densa, ma perché non sfrutto nulla: sempre e solo 8 registri, pur avendone 32 a disposizione nello stesso opcode. Giusto per fare soltanto un esempio). Mentre per x64 ottengo 4.3, e 3.6 per la mia seconda ISA (anche qui non usando niente).
Se provi a fare qualcosa del genere con la tua ISA, penso che la media esploderà, a livelli superiori anche a x64 (che è già molto scarsa come densità: si fa battere persino da ARM64).
I ricordi sono molto sbiaditi, ma se per l'opcode ci si accontenta di 13 bit, codificando anche data type e numero di parametri nell'opcode, si può anche fare blocchi di 16 bit (2 bytes) e per istruzioni a 0 operandi, si occupano 2 byte e su registro avevo pensato a un banco da 256 registri unificati.
Ma ricordo come fosse ieri l'esame di Calcolatori I, dove mi fece come ultima domanda, a bruciapelo, su una cosa che spiegò esplicitamente al corso: una istruzione usata di frequente è conveniente che sia codificata con meno o più bit? Quindi poi ricordo di aver anche pensato a una struttura a byte, dove i primi bit dicevano i byte occupati dall'opcode (1 bit 1/2 byte opcode) e il numero di parametri (2 bit 0-3 parametri e 1-4 per istruzioni che non possono avere 0 parametri, come le aritmetiche), così da avere classi di istruzioni, in modo da poterle smistare in eventuali domini separati. Dopo l'opcode (1/2 bytes) il byte con tipo e numerosità (4 bit + 4 bit sono sufficienti per 16 tipi interi e float e 16 misure di vettore) solo per istruzioni aritmetiche, magari segnalate da un bit nell'opcode. Quindi i primi 3 bit dell'opcode sono per dimensione opcode e numero parametri, 1 per aritmetica/non (il dominio poi sarà dato anche dal tipo) e restanti 4-12 bit per l'opcode vero e proprio...
Se ci sono pochi range il vantaggio sarebbe tangibile. Se ce ne sono troppi, a questo punto tanto vale tenersi i TLB, che oggigiorno sono abbastanza ben dimensionati.
Sicuro che siano quelli bassi, e non i 3 bit immediatamente sopra la dimensione della pagina?
Su Linux / ELF mi pare che le sezioni abbiano una granularità di 64KB.
I 3 bit bassi tra quelli memorizzati della TLB, ovviamente, quindi escludendo già i 12 bit bassi di offset nella pagina.
Preferisco evitare GCC, perché cambiando soltanto l'assemblatore non potrei sfruttare nulla della mia ISA. Quindi dovrei cambiare il backend, e qui è un bagno di sangue: molto meglio passare a LLVM, che rende la vita decisamente più semplice.
Ma prima devo finire lo script Python per analizzare densità e statistiche. E ho già in programma pure una quinta versione, perché parlandone fra ieri e stamattina mi sono venute in mente altre idee. Neverendingstory. :asd:
Ho sentito nominare questo LLVM, ma non so i dettagli... Immagino sia opensource, ricordo di aver sentito che AMD stessa aveva collaborato con pathc per le sue CPU, ma c'è davvero bisogno di un concorrente a gcc?
Comunque a primo acchito prevedo una scarsa densità di codice per la tua ISA, perché tutta quella flessibilità si paga, anche se l'hai definita a lunghezza variabile. Il problema è rappresentato dall'unità base rappresentata da 32 bit, che sono ben 4 byte.
Per farti un esempio, disassemblando la beta pubblica di Photoshop CS6 ottengo (su circa 1,7 milioni di istruzioni disassemblate) una media di 3.2 byte per x86 (quindi istruzioni a 32 bit) e 3.4 per la seconda versione della mia ISA (che è leggermente meno densa, ma perché non sfrutto nulla: sempre e solo 8 registri, pur avendone 32 a disposizione nello stesso opcode. Giusto per fare soltanto un esempio). Mentre per x64 ottengo 4.3, e 3.6 per la mia seconda ISA (anche qui non usando niente).
Se provi a fare qualcosa del genere con la tua ISA, penso che la media esploderà, a livelli superiori anche a x64 (che è già molto scarsa come densità: si fa battere persino da ARM64).
I ricordi sono molto sbiaditi, ma se per l'opcode ci si accontenta di 13 bit, codificando anche data type e numero di parametri nell'opcode, si può anche fare blocchi di 16 bit (2 bytes) e per istruzioni a 0 operandi, si occupano 2 byte e su registro avevo pensato a un banco da 256 registri unificati.
Ma ricordo come fosse ieri l'esame di Calcolatori I, dove mi fece come ultima domanda, a bruciapelo, su una cosa che spiegò esplicitamente al corso: una istruzione usata di frequente è conveniente che sia codificata con meno o più bit? Quindi poi ricordo di aver anche pensato a una struttura a byte, dove i primi bit dicevano i byte occupati dall'opcode (1 bit 1/2 byte opcode) e il numero di parametri (2 bit 0-3 parametri e 1-4 per istruzioni che non possono avere 0 parametri, come le aritmetiche), così da avere classi di istruzioni, in modo da poterle smistare in eventuali domini separati. Dopo l'opcode (1/2 bytes) il byte con tipo e numerosità (4 bit + 4 bit sono sufficienti per 16 tipi interi e float e 16 misure di vettore) solo per istruzioni aritmetiche, magari segnalate da un bit nell'opcode. Quindi i primi 3 bit dell'opcode sono per dimensione opcode e numero parametri, 1 per aritmetica/non (il dominio poi sarà dato anche dal tipo) e restanti 4-12 bit per l'opcode vero e proprio...
Se ci sono pochi range il vantaggio sarebbe tangibile. Se ce ne sono troppi, a questo punto tanto vale tenersi i TLB, che oggigiorno sono abbastanza ben dimensionati.
Sicuro che siano quelli bassi, e non i 3 bit immediatamente sopra la dimensione della pagina?
Su Linux / ELF mi pare che le sezioni abbiano una granularità di 64KB.
I 3 bit bassi tra quelli memorizzati della TLB, ovviamente, quindi escludendo già i 12 bit bassi di offset nella pagina.
Preferisco evitare GCC, perché cambiando soltanto l'assemblatore non potrei sfruttare nulla della mia ISA. Quindi dovrei cambiare il backend, e qui è un bagno di sangue: molto meglio passare a LLVM, che rende la vita decisamente più semplice.
Ma prima devo finire lo script Python per analizzare densità e statistiche. E ho già in programma pure una quinta versione, perché parlandone fra ieri e stamattina mi sono venute in mente altre idee. Neverendingstory. :asd:
Ho sentito nominare questo LLVM, ma non so i dettagli... Immagino sia opensource, ricordo di aver sentito che AMD stessa aveva collaborato con pathc per le sue CPU, ma c'è davvero bisogno di un concorrente a gcc?
Nui_Mg
25-12-2016, 09:41
Cosa non ti è chiaro del fatto che la nostra è una democrazia RAPPRESENTATIVA, e chi ci governa nasce dal "culo degli italiani"?
Certo, sono d'accordo, non per niente ho parlato del fatto che se "agli italiani va bene così..."
In Italia entrano anche i clandestini, ma è ovvio che sia così, vista la vicinanza con l'Africa. E' una questione meramente logistica.
No, in Italia entrano soprattutto clandestini, le stesse questure locali (almeno dalle mie parti) hanno affermato che i profughi sono una netta minoranza rispetto ai clandestini economici.
In Germania mica "sbarcano" i clandestini...
Beh, anche la Germania di clandestini ne ha molti visto che non riesce a filtrare tutti quelli provenienti dall'Italia saudita e il grosso penetra dall'est europa.
Mentre in Germania non hai notato nessun cambiamento, immagino.
In Germania, eccome se c'è stato il cambiamento (in peggio) nell'ultimo decennio, ma la sua governance, per quanto in difficoltà, è ben più efficiente rispetto all'Italia (considerando anche le sue storiche comunità, come quella turca). Il cambiamento di cui stavo parlando, in Germania, è nel senso opposto, cioè le maglie si stringeranno sempre di più, perfino la coalizione che appoggia l'ennesima candidatura della Merkel spinge in tal senso (questione elettorale).
I pochi esempi che ho fatto nel post precedente, tra la lassista Italia e Germania sono più che auto-esplicativi (anzi, ne ho ancora tanti: chi segue assiduamente le news locali sa benissimo quanto non venga applicato alcun fermo, alla voce "condannato a tot qua e tot. là, con sospensione della pena", questo credo anche per "merito" della depenalizzazione dei reati fino a tre anni del caro Renzi, da me ribattezzato, ho il copyright, "pavone folle").
"Basta" viverci.
Certo e infatti io sono stra-sicuro di averci vissuto e vivere tutt'ora (ora più saltuariamente visto che frequento la facoltà a Milano per stare più vicino al genitore sul lago) molto più di altri, io a Monaco ci sono nato (e ho doppia cittadinanza) e ho un bilocale vicino allo stadio.
Ma questo non fa mai comodo ricordarlo, vero?
No, ricordalo quanto ti pare, tutte le volte che ti pare, ma detto questo esistono sul territorio europeo delle regole basilari, che devono essere rispettate (e sono gli autoctoni che comandano/dettano legge, il territorio è loro prima di tutto) e a me andrebbero bene perfino quelle di un governo dichiaramente di sinistra come quello che era di Zapatero dove, i soliti straccioni falliti comunisti lo inneggiavano (vedi la pezzente della Guzzanti con Viva Zapatero e tutti i vari soloni delle tv nostrane) guardandosi però bene dal riportare che sotto il suo governo, la Spagna, anche lei stra-confinante con l'Africa, ha approntato il muro elettronico con guardie spagnole che hanno perfino ucciso due clandestini con pallottole di gomma e il super efficiente sistema satellitare S.I.V.E. che monitorava/allertava la guardia costiera quando c'era del movimento sulla costa marocchina.
Lo ripeto e senza alcun dubbio di smentita, qualsiasi paese oltre-Alpi, per quante difficoltà possa riscontrare, è certamente meglio dell'Italia (non per una questione di numeri superiori o minori, ma per maggiore serietà/volontà di fare) nella gestione migranti anche perché nella mia testa passa sempre di più il fatto che la cosa in Italia sia voluta, viste le nuove opportunità lavorative createsi in Italia con la gestione dei migranti da parte delle solite cooperative e associazioni cattoliche (e vari indagati in tal senso, cioè di sfruttamento migranti, in Italia sono tanti, ma proprio tanti visto che pure il tg uno ha riportato che perfino i mafiosi li considerano "un affare" più remunerativo di droga ed estorsioni). Inoltre, in Italia ci sono dei "valori aggiunti" come la Boldrini, semplicemente una pazza.
Lo so che a te, da classicissimo italiano e perfino renziano (roba da spararsi in testa sostenere uno come il pavone folle; ah, non sono leghista, in casa mia e nella mia regione si è sempre parlato di serenissima e indipendenza ancor prima dell'arrivo del senatùr cacciaballe), va benone una cosa del genere, è tutto ok, non c'è niente di sbagliato, io invece, come tantissimi europei oltre-alpi, la penso in modo opposto: è folle una politica di accoglienza anche a gente allo stato brado quando tu, Stato italiano, sai benissimo, nella tua storica proverbiale inefficienza/superficialità/straccionaggine, di non essere in grado (efficienza, seria volontà, ecc.) di poterla fornire in modo adeguato tale da non gettarli nelle maglie della manovalanza criminale.
E' un dato di fatto, per chiunque bazzichi oltre-alpi o anche segua le news italiane, che la stragrandissima maggior parte di Europa NON VUOLE la ripartizione degli immigrati che chiede l'Italia, perché? Perché i loro autoctoni NON VOGLIONO ed è una posizione legittima e democratica, piaccia o meno, punto!
Certo, sono d'accordo, non per niente ho parlato del fatto che se "agli italiani va bene così..."
In Italia entrano anche i clandestini, ma è ovvio che sia così, vista la vicinanza con l'Africa. E' una questione meramente logistica.
No, in Italia entrano soprattutto clandestini, le stesse questure locali (almeno dalle mie parti) hanno affermato che i profughi sono una netta minoranza rispetto ai clandestini economici.
In Germania mica "sbarcano" i clandestini...
Beh, anche la Germania di clandestini ne ha molti visto che non riesce a filtrare tutti quelli provenienti dall'Italia saudita e il grosso penetra dall'est europa.
Mentre in Germania non hai notato nessun cambiamento, immagino.
In Germania, eccome se c'è stato il cambiamento (in peggio) nell'ultimo decennio, ma la sua governance, per quanto in difficoltà, è ben più efficiente rispetto all'Italia (considerando anche le sue storiche comunità, come quella turca). Il cambiamento di cui stavo parlando, in Germania, è nel senso opposto, cioè le maglie si stringeranno sempre di più, perfino la coalizione che appoggia l'ennesima candidatura della Merkel spinge in tal senso (questione elettorale).
I pochi esempi che ho fatto nel post precedente, tra la lassista Italia e Germania sono più che auto-esplicativi (anzi, ne ho ancora tanti: chi segue assiduamente le news locali sa benissimo quanto non venga applicato alcun fermo, alla voce "condannato a tot qua e tot. là, con sospensione della pena", questo credo anche per "merito" della depenalizzazione dei reati fino a tre anni del caro Renzi, da me ribattezzato, ho il copyright, "pavone folle").
"Basta" viverci.
Certo e infatti io sono stra-sicuro di averci vissuto e vivere tutt'ora (ora più saltuariamente visto che frequento la facoltà a Milano per stare più vicino al genitore sul lago) molto più di altri, io a Monaco ci sono nato (e ho doppia cittadinanza) e ho un bilocale vicino allo stadio.
Ma questo non fa mai comodo ricordarlo, vero?
No, ricordalo quanto ti pare, tutte le volte che ti pare, ma detto questo esistono sul territorio europeo delle regole basilari, che devono essere rispettate (e sono gli autoctoni che comandano/dettano legge, il territorio è loro prima di tutto) e a me andrebbero bene perfino quelle di un governo dichiaramente di sinistra come quello che era di Zapatero dove, i soliti straccioni falliti comunisti lo inneggiavano (vedi la pezzente della Guzzanti con Viva Zapatero e tutti i vari soloni delle tv nostrane) guardandosi però bene dal riportare che sotto il suo governo, la Spagna, anche lei stra-confinante con l'Africa, ha approntato il muro elettronico con guardie spagnole che hanno perfino ucciso due clandestini con pallottole di gomma e il super efficiente sistema satellitare S.I.V.E. che monitorava/allertava la guardia costiera quando c'era del movimento sulla costa marocchina.
Lo ripeto e senza alcun dubbio di smentita, qualsiasi paese oltre-Alpi, per quante difficoltà possa riscontrare, è certamente meglio dell'Italia (non per una questione di numeri superiori o minori, ma per maggiore serietà/volontà di fare) nella gestione migranti anche perché nella mia testa passa sempre di più il fatto che la cosa in Italia sia voluta, viste le nuove opportunità lavorative createsi in Italia con la gestione dei migranti da parte delle solite cooperative e associazioni cattoliche (e vari indagati in tal senso, cioè di sfruttamento migranti, in Italia sono tanti, ma proprio tanti visto che pure il tg uno ha riportato che perfino i mafiosi li considerano "un affare" più remunerativo di droga ed estorsioni). Inoltre, in Italia ci sono dei "valori aggiunti" come la Boldrini, semplicemente una pazza.
Lo so che a te, da classicissimo italiano e perfino renziano (roba da spararsi in testa sostenere uno come il pavone folle; ah, non sono leghista, in casa mia e nella mia regione si è sempre parlato di serenissima e indipendenza ancor prima dell'arrivo del senatùr cacciaballe), va benone una cosa del genere, è tutto ok, non c'è niente di sbagliato, io invece, come tantissimi europei oltre-alpi, la penso in modo opposto: è folle una politica di accoglienza anche a gente allo stato brado quando tu, Stato italiano, sai benissimo, nella tua storica proverbiale inefficienza/superficialità/straccionaggine, di non essere in grado (efficienza, seria volontà, ecc.) di poterla fornire in modo adeguato tale da non gettarli nelle maglie della manovalanza criminale.
E' un dato di fatto, per chiunque bazzichi oltre-alpi o anche segua le news italiane, che la stragrandissima maggior parte di Europa NON VUOLE la ripartizione degli immigrati che chiede l'Italia, perché? Perché i loro autoctoni NON VOGLIONO ed è una posizione legittima e democratica, piaccia o meno, punto!
tmx
25-12-2016, 09:55
Buon Natale a tutti :)
https://i.sli.mg/Qy6pmq.jpg
https://i.sli.mg/Qy6pmq.jpg
Wolfhang
25-12-2016, 10:06
Infatti, e qui si torna sempre allo stesso punto...in 15W di TDP, AMD ha messo il doppio dei core con frequenza del 20% più alta, rispetto a quanto fatto da Intel su i 22nm finfet....e Intel ha presentato un octacore Haswell desktop e un 22 core server....:read:
Esatto, si torna sempre allo stesso punto, frequenza 20% più alta, il doppio dei core ma le bastonate da Haswell se le prende lo stesso causa IPC penoso.
Poi hai detto bene, grazie all'uso delle HDL che nelle soluzioni a basso TDP danno il loro meglio visto le basse frequenze in gioco, ma basta alzarsi di TDP e la situazione si fa tragica dove per esempio già nei 45W di TDP NON ESISTONO soluzioni AMD contrapponibili ad Intel.
Esatto, si torna sempre allo stesso punto, frequenza 20% più alta, il doppio dei core ma le bastonate da Haswell se le prende lo stesso causa IPC penoso.
Poi hai detto bene, grazie all'uso delle HDL che nelle soluzioni a basso TDP danno il loro meglio visto le basse frequenze in gioco, ma basta alzarsi di TDP e la situazione si fa tragica dove per esempio già nei 45W di TDP NON ESISTONO soluzioni AMD contrapponibili ad Intel.
sgrinfia
25-12-2016, 10:08
Certo, sono d'accordo, non per niente ho parlato del fatto che se "agli italiani va bene così..."
No, in Italia entrano soprattutto clandestini, le stesse questure locali (almeno dalle mie parti) hanno affermato che i profughi sono una netta minoranza rispetto ai clandestini economici.
Beh, anche la Germania di clandestini ne ha molti visto che non riesce a filtrare tutti quelli provenienti dall'Italia saudita e il grosso penetra dall'est europa.
In Germania, eccome se c'è stato il cambiamento (in peggio) nell'ultimo decennio, ma la sua governance, per quanto in difficoltà, è ben più efficiente rispetto all'Italia (considerando anche le sue storiche comunità, come quella turca). Il cambiamento di cui stavo parlando, in Germania, è nel senso opposto, cioè le maglie si stringeranno sempre di più, perfino la coalizione che appoggia l'ennesima candidatura della Merkel spinge in tal senso (questione elettorale).
I pochi esempi che ho fatto nel post precedente, tra la lassista Italia e Germania sono più che auto-esplicativi (anzi, ne ho ancora tanti: chi segue assiduamente le news locali sa benissimo quanto non venga applicato alcun fermo, alla voce "condannato a tot qua e tot. là, con sospensione della pena", questo credo anche per "merito" della depenalizzazione dei reati fino a tre anni del caro Renzi, da me ribattezzato, ho il copyright, "pavone folle").
Certo e infatti io sono stra-sicuro di averci vissuto e vivere tutt'ora (ora più saltuariamente visto che frequento la facoltà a Milano per stare più vicino al genitore sul lago) molto più di altri, io a Monaco ci sono nato (e ho doppia cittadinanza) e ho un bilocale vicino allo stadio.
No, ricordalo quanto ti pare, tutte le volte che ti pare, ma detto questo esistono sul territorio europeo delle regole basilari, che devono essere rispettate (e sono gli autoctoni che comandano/dettano legge, il territorio è loro prima di tutto) e a me andrebbero bene perfino quelle di un governo dichiaramente di sinistra come quello che era di Zapatero dove, i soliti straccioni falliti comunisti lo inneggiavano (vedi la pezzente della Guzzanti con Viva Zapatero e tutti i vari soloni delle tv nostrane) guardandosi però bene dal riportare che sotto il suo governo, la Spagna, anche lei stra-confinante con l'Africa, ha approntato il muro elettronico con guardie spagnole che hanno perfino ucciso due clandestini con pallottole di gomma e il super efficiente sistema satellitare S.I.V.E. che monitorava/allertava la guardia costiera quando c'era del movimento sulla costa marocchina.
Lo ripeto e senza alcun dubbio di smentita, qualsiasi paese oltre-Alpi, per quante difficoltà possa riscontrare, è certamente meglio dell'Italia (non per una questione di numeri superiori o minori, ma per maggiore serietà/volontà di fare) nella gestione migranti anche perché nella mia testa passa sempre di più il fatto che la cosa in Italia sia voluta, viste le nuove opportunità lavorative createsi in Italia con la gestione dei migranti da parte delle solite cooperative e associazioni cattoliche (e vari indagati in tal senso, cioè di sfruttamento migranti, in Italia sono tanti, ma proprio tanti visto che pure il tg uno ha riportato che perfino i mafiosi li considerano "un affare" più remunerativo di droga ed estorsioni). Inoltre, in Italia ci sono dei "valori aggiunti" come la Boldrini, semplicemente una pazza.
Lo so che a te, da classicissimo italiano e perfino renziano (roba da spararsi in testa sostenere uno come il pavone folle; ah, non sono leghista, in casa mia e nella mia regione si è sempre parlato di serenissima e indipendenza ancor prima dell'arrivo del senatùr cacciaballe), va benone una cosa del genere, è tutto ok, non c'è niente di sbagliato, io invece, come tantissimi europei oltre-alpi, la penso in modo opposto: è folle una politica di accoglienza anche a gente allo stato brado quando tu, Stato italiano, sai benissimo, nella tua storica proverbiale inefficienza/superficialità/straccionaggine, di non essere in grado (efficienza, seria volontà, ecc.) di poterla fornire in modo adeguato tale da non gettarli nelle maglie della manovalanza criminale.
E' un dato di fatto, per chiunque bazzichi oltre-alpi o anche segua le news italiane, che la stragrandissima maggior parte di Europa NON VUOLE la ripartizione degli immigrati che chiede l'Italia, perché? Perché i loro autoctoni NON VOGLIONO ed è una posizione legittima e democratica, piaccia o meno, punto!
:nonsifa: non è un sito per seutofascisti.
No, in Italia entrano soprattutto clandestini, le stesse questure locali (almeno dalle mie parti) hanno affermato che i profughi sono una netta minoranza rispetto ai clandestini economici.
Beh, anche la Germania di clandestini ne ha molti visto che non riesce a filtrare tutti quelli provenienti dall'Italia saudita e il grosso penetra dall'est europa.
In Germania, eccome se c'è stato il cambiamento (in peggio) nell'ultimo decennio, ma la sua governance, per quanto in difficoltà, è ben più efficiente rispetto all'Italia (considerando anche le sue storiche comunità, come quella turca). Il cambiamento di cui stavo parlando, in Germania, è nel senso opposto, cioè le maglie si stringeranno sempre di più, perfino la coalizione che appoggia l'ennesima candidatura della Merkel spinge in tal senso (questione elettorale).
I pochi esempi che ho fatto nel post precedente, tra la lassista Italia e Germania sono più che auto-esplicativi (anzi, ne ho ancora tanti: chi segue assiduamente le news locali sa benissimo quanto non venga applicato alcun fermo, alla voce "condannato a tot qua e tot. là, con sospensione della pena", questo credo anche per "merito" della depenalizzazione dei reati fino a tre anni del caro Renzi, da me ribattezzato, ho il copyright, "pavone folle").
Certo e infatti io sono stra-sicuro di averci vissuto e vivere tutt'ora (ora più saltuariamente visto che frequento la facoltà a Milano per stare più vicino al genitore sul lago) molto più di altri, io a Monaco ci sono nato (e ho doppia cittadinanza) e ho un bilocale vicino allo stadio.
No, ricordalo quanto ti pare, tutte le volte che ti pare, ma detto questo esistono sul territorio europeo delle regole basilari, che devono essere rispettate (e sono gli autoctoni che comandano/dettano legge, il territorio è loro prima di tutto) e a me andrebbero bene perfino quelle di un governo dichiaramente di sinistra come quello che era di Zapatero dove, i soliti straccioni falliti comunisti lo inneggiavano (vedi la pezzente della Guzzanti con Viva Zapatero e tutti i vari soloni delle tv nostrane) guardandosi però bene dal riportare che sotto il suo governo, la Spagna, anche lei stra-confinante con l'Africa, ha approntato il muro elettronico con guardie spagnole che hanno perfino ucciso due clandestini con pallottole di gomma e il super efficiente sistema satellitare S.I.V.E. che monitorava/allertava la guardia costiera quando c'era del movimento sulla costa marocchina.
Lo ripeto e senza alcun dubbio di smentita, qualsiasi paese oltre-Alpi, per quante difficoltà possa riscontrare, è certamente meglio dell'Italia (non per una questione di numeri superiori o minori, ma per maggiore serietà/volontà di fare) nella gestione migranti anche perché nella mia testa passa sempre di più il fatto che la cosa in Italia sia voluta, viste le nuove opportunità lavorative createsi in Italia con la gestione dei migranti da parte delle solite cooperative e associazioni cattoliche (e vari indagati in tal senso, cioè di sfruttamento migranti, in Italia sono tanti, ma proprio tanti visto che pure il tg uno ha riportato che perfino i mafiosi li considerano "un affare" più remunerativo di droga ed estorsioni). Inoltre, in Italia ci sono dei "valori aggiunti" come la Boldrini, semplicemente una pazza.
Lo so che a te, da classicissimo italiano e perfino renziano (roba da spararsi in testa sostenere uno come il pavone folle; ah, non sono leghista, in casa mia e nella mia regione si è sempre parlato di serenissima e indipendenza ancor prima dell'arrivo del senatùr cacciaballe), va benone una cosa del genere, è tutto ok, non c'è niente di sbagliato, io invece, come tantissimi europei oltre-alpi, la penso in modo opposto: è folle una politica di accoglienza anche a gente allo stato brado quando tu, Stato italiano, sai benissimo, nella tua storica proverbiale inefficienza/superficialità/straccionaggine, di non essere in grado (efficienza, seria volontà, ecc.) di poterla fornire in modo adeguato tale da non gettarli nelle maglie della manovalanza criminale.
E' un dato di fatto, per chiunque bazzichi oltre-alpi o anche segua le news italiane, che la stragrandissima maggior parte di Europa NON VUOLE la ripartizione degli immigrati che chiede l'Italia, perché? Perché i loro autoctoni NON VOGLIONO ed è una posizione legittima e democratica, piaccia o meno, punto!
:nonsifa: non è un sito per seutofascisti.
Nui_Mg
25-12-2016, 10:13
:nonsifa: non è un sito per seutofascisti.
Tu lo sai vero che qua il fascismo non c'entra niente, vero (e che la parola comunista l'ho tirata fuori perché sono loro stessi che si sono definiti in tal modo)? Mie opinioni personali a parte sulla faccenda, il resto sono fatti verificabili da tutti con un po' di impegno/volontà. Ah, e l'off-topic non l'ho iniziato io e non avevi bisogno di ri-quotare il tutto visto che il post precedente aveva già tutto.
Tu lo sai vero che qua il fascismo non c'entra niente, vero (e che la parola comunista l'ho tirata fuori perché sono loro stessi che si sono definiti in tal modo)? Mie opinioni personali a parte sulla faccenda, il resto sono fatti verificabili da tutti con un po' di impegno/volontà. Ah, e l'off-topic non l'ho iniziato io e non avevi bisogno di ri-quotare il tutto visto che il post precedente aveva già tutto.
digieffe
25-12-2016, 10:22
buon natale agli intellisti e agli amdisti, ma soprattuto a chi non è fanboy :D
Roland74Fun
25-12-2016, 10:42
buon natale agli intellisti e agli amdisti, ma soprattuto a chi non è fanboy :D
Invece io faccio gli auguri a tutti i fanboy AMD.
The AMD Fanboy Song!: http://youtu.be/EIPggCgYK38
Auguri comunque anche a tutti gli altri
Che possiate avere tanto incremento di IPC! ;)
Auguri anche agli immigrati ed ai profughi. :) :)
Invece io faccio gli auguri a tutti i fanboy AMD.
The AMD Fanboy Song!: http://youtu.be/EIPggCgYK38
Auguri comunque anche a tutti gli altri
Che possiate avere tanto incremento di IPC! ;)
Auguri anche agli immigrati ed ai profughi. :) :)
vBulletin® v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.