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

[calabar]

Originariamente inviato da papafoxtrot

Sbagli il presupposto! Lo scopo di CMT è quello di aumentare i core a disposizione! Lo scopo di SMT è diametralmente opposto... Serve per migliorare lo sfruttamento di quelli disponibili! I core infattir estano 4, si cerca solo di non farli rimanere mai con le mani in mano! Che questo lo si faccia raddoppiando i thread elaborabili è un'altro paio di maniche...

A mio parere sei tu che confondi il "cosa" con il "come".
Sia SMT che CMT si propongono di aumentare il parallelismo e migliorare l'efficienza. Il primo lo fa cercando di sfruttare il core presente, il secondo lo fa aggiungendo un cluster ci calcolo int per modulo.
Sono due approcci opposti che però mirano allo stesso scopo. E questo non lo dico io, l'ha detto AMD stessa molto prima dell'uscita di BD, quando ha annunciato l'implementazione di questa tecnologia.

[papafoxtrot]

Originariamente inviato da calabar

A mio parere sei tu che confondi il "cosa" con il "come".
Sia SMT che CMT si propongono di aumentare il parallelismo e migliorare l'efficienza. Il primo lo fa cercando di sfruttare il core presente, il secondo lo fa aggiungendo un cluster ci calcolo int per modulo.
Sono due approcci opposti che però mirano allo stesso scopo. E questo non lo dico io, l'ha detto AMD stessa molto prima dell'uscita di BD, quando ha annunciato l'implementazione di questa tecnologia.

Si puoi dire quello che vuoi... Certo che il fine ultimo è quello di aumentare le prestazioni contenendo i consumi e i costi... Allora puoi anche dirmi che il fine ultimo è batter cassa, sia per la Barilla che per la Fiat... Una fa pastasciutta e una macchine... Tutte due vogliono far soldi.

Ma lo scopo intrinseco nell?SMT, le dichiarazioni dei commerciali AMD le lasciamo dove stanno, è cercare di migliorare il modo in cui il core viene sfruttato.
L'obiettivo di CMT è invece fregarsene dell'efficienza della pipeline, e cercare di mettergliene di fianco un'altra a poco costo. In pratica aumentare il parallelismo. Anzi, l'efficienza della singola pipeline cala, con lo scopo di aumentarne il numero.

Tu prima hai detto (e ora lo ripeti in qualche modo) che lo scopo di SMT è aumentare il parallelismo, e questo è errato! Il raddoppio dei thread non è un fine, è un mezzo!

Comunque il discorso da cui siamo partiti è se sia possibile implementare un SMT in una CPU che implementa già il CMT.
Ebbene a mio avviso la cosa è tecnicamente fattibile, e mi sembra che tu concordi. Dopodiché non è detto che il risultato sia certamente positivo, in quanto la logica di controllo dovrebbe operare in modo molto raffinato, ed AMD non ha esperienza in questo settore, e su questo sono d'accordo.
Certo dovrebbe fare esperienza, magari con brazos, e poi portarla in BD, se non vuole fare il passo subito, perché per come è fatto bulldozer:
- pipeline lunghe che stallano di più
- BP peggiore di quella di intel
- CMT che riduce l'efficienza della singola pipeline
Senza SMT secondo me è difficile recuperare su intel, non a livello di prestazioni, ma a livello di efficienza energetica, che è il fattore chiave oggi... E di costi...

[Phenomenale]

Originariamente inviato da papafoxtrot

Comunque il discorso da cui siamo partiti è se sia possibile implementare un SMT in una CPU che implementa già il CMT.
Ebbene a mio avviso la cosa è tecnicamente fattibile, e mi sembra che tu concordi.
.....
Senza SMT secondo me è difficile recuperare su intel, non a livello di prestazioni, ma a livello di efficienza energetica, che è il fattore chiave oggi... E di costi...

Facciamo finta che sia come dici: AMD fa un FX-II con 16 core virtuali lenti come quelli attuali. A cosa servono in ambiente desktop? A parte i benchmark, intendo?
.....
Per il resto: il successo dei SandyBridge Intel non è certo nell' SMT: quasi tutti si comprano il I5-2500K che costa meno e ne è privo, guarda nei thread intel.

Il CMT è una buona idea: bisogna solo farla funzionare. Non capisco la tua apologia del SMT come fattore chiave di successo, non riesco ad immaginare come un accrocchio CMT+SMT possa permettere ad AMD di recuperare su Intel.

Non ti arrabbiare, non capisco la tua tesi.

[paolo.oliva2]

Originariamente inviato da Phenomenale

Facciamo finta che sia come dici: AMD fa un FX-II con 16 core virtuali lenti come quelli attuali. A cosa servono in ambiente desktop? A parte i benchmark, intendo?
.....
Per il resto: il successo dei SandyBridge Intel non è certo nell' SMT: quasi tutti si comprano il I5-2500K che costa meno e ne è privo, guarda nei thread intel.

Il CMT è una buona idea: bisogna solo farla funzionare. Non capisco la tua apologia del SMT come fattore chiave di successo, non riesco ad immaginare come un accrocchio CMT+SMT possa permettere ad AMD di recuperare su Intel.

Non ti arrabbiare, non capisco la tua tesi.

Quoto. Il discorso SMT è una soluzione per aumentare la potenza, ed al momento è la migliore sul mercato, ma questo non vuole dire che l'SMT sarà presente sui proci anche tra 5 anni (l'SMT è stato un cambiamento nell'architettura Intel, come ce ne sarà un'altra che prenderà il suo posto perché migliore...), come non vuole dire che il potenziale CMT di oggi sia il massimo possibile architetturalmente (quanti anni di sviluppo ha avuto l'SMT?).

[paolo.oliva2]

Tra parentesi non capisco ancora una cosa... oppure mi sono perso.

Si parlava che un modulo BD perde un 10% di prestazioni rispetto a 2 core classici Phenom II... questo per via della condivisione.
Allora perché si parla di un -20% in ST quando la condivisione non avrebbe alcun effetto?

Cioè... se attribuissimo un -20% in ST, allora un BD X6 (allo stesso clock 8150) dovrebbe perdere un 30% in MT... ed allora un BD X8 con i 2 core aggiunti avrebbe un'efficienza +33% (cioè 6 core +2), visto che l'8150 nella media è più veloce del Thuban in MT?

[rainbow69]

Scusate se faccio qualche domanda fuori tema ma non sapevo a chi meglio di voi chiedere.
1) Le cpu komodo saranno compatibili col socket FM2?
2) Trinity e komodo condivideranno lo stesso socket (FM2) ?
2) L'uscita di queste cpu (komodo) e del socket FM2 quando è prevista?

Grazie in anticipo per le delucidazioni.

[shellx]

Originariamente inviato da rainbow69

Scusate se faccio qualche domanda fuori tema ma non sapevo a chi meglio di voi chiedere.
1) Le cpu komodo saranno compatibili col socket FM2?
2) Trinity e komodo condivideranno lo stesso socket (FM2) ?
2) L'uscita di queste cpu (komodo) e del socket FM2 quando è prevista?

Grazie in anticipo per le delucidazioni.

La piattaforma si chiamava korona (no corona come la birra o come il fidanzato di belen)

1) le cpu komodo dovevano essere socket fm2 condividendo lo stesso socket del segmento mainstream (ritornando al singolo socket per tutte le fasce), ma tali cpu con relativa piattaforma sono state cancellate da amd per far posto a vishera.
2) trinity è fm2, komodo doveva essere anch'esso fm2 ma con chispet della famiglia Hudson D4 - A85FX, prima di essere cancellato.
3) le cpu komodo come ho detto prima sono state cancellate per far posto alla prossima piattaforma per cpu vishera FX basate sull'evoluzione architetturale di Bulldozer chiamata Piledriver, ma nulla toglie che dopo Vishera qualcosa di molto simile a komodo possa essere annunciato da amd (forse per steamroller e 28nm -hub pcie integrato in cpu e socket con infrastruttura FMx) ma parliamo della meta 2013 e comunque è una ipotesi non un dato ufficiale.

[°Phenom°]

Sono impaziente dell'uscita di Vishera, spero sia una valida cpu, si ha qualche altra nuova notizia a riguardo?

[plainsong]

Non so se è già stata postata, risale a febbraio, una recensione davvero dettagliata del fx 4170 con interessanti confronti prestazionali anche in overclock: http://www.the-overclock-hole.it/rec...html?showall=1 .
Alcuni risultati mi hanno positivamente stupito.

[°Phenom°]

Si, è fatto abbastanza bene quel confronto

[papafoxtrot]

Originariamente inviato da Phenomenale

Facciamo finta che sia come dici: AMD fa un FX-II con 16 core virtuali lenti come quelli attuali. A cosa servono in ambiente desktop? A parte i benchmark, intendo?
.....
Per il resto: il successo dei SandyBridge Intel non è certo nell' SMT: quasi tutti si comprano il I5-2500K che costa meno e ne è privo, guarda nei thread intel.

Il CMT è una buona idea: bisogna solo farla funzionare. Non capisco la tua apologia del SMT come fattore chiave di successo, non riesco ad immaginare come un accrocchio CMT+SMT possa permettere ad AMD di recuperare su Intel.

Non ti arrabbiare, non capisco la tua tesi.

Purtroppo a suon di botta e risposta si perde il filo del discorso. Se rileggi bene io parlavo di SMT per il futuro, quando l'IPC del singolo core sarà poco importante perché si avrà a che fare con codici finalmente ben parallelizzati.
Io non sto dicendo che vada fatto a tutti i costi e che se AMD è indietro è perché le manca l'SMT. Tra l'altro sono d'accordo con te sul fatto che non sia certo semplice implementare una simile soluzione.
Per quanto riguarda le prestazioni in ambiente desktop hai ragione; tuttavia c'è tutto l'ambito workstation, dove AMD è completamente assente, che trae vantaggi enormi dall?SMT... Io assemblo (assemblavo) macchine per grafica 3D... L'unica eccezione è stato il phenom II X6, che secondo me è stato un signor processore... per il resto o core i7 o xeon... Non c'è niente da fare, si ottengono tutt'altri risultati.

Comunque il mio discorso era partito dal fatto che lo sbaglio in bulldozer è stato optare per pipeline lunghe, che richiedono una tecnologia sulla quale AMD è debole... Sia perché le manca una BP efficace, sia perché non ha un SMT, sia perché i moduli stessi di BD non realizzzano un'aumento di efficenza della logica di controllo, ma bensì una sua diminuzione, perché condivisa tra due core...

L'approccio a moduli ci può stare, ma secondo me ben si addiceva ad un'architettura con pipeline corte, che poco dipendenssero dalle prestazioni della logica di controllo.

Dopodiché si è andati a parlare di SMT, ed io ho detto che nelle CPU AMD potrebbe starci in futuro, quando i carichi di lavoro saranno parallelizzati in modo simile a quanto accade nelle GPU.. A quel punto l'IPC del singolo core passerà in secondo piano, mentre sarà (lo è già) cruciale l'efficienza energetica della CPU...

Certo ora la prima cosa di cui BD ha bisogno è un aumento dell'IPC, e quello non si realizza con il SMT perché in single core le prestazioni non crescono... E come ho detto vari post fa la BPU, probabilmente anche il decoder, e le latenze delle cache sono le principali indiziate per prestazioni così sotto tono... Come dicevo passino le pipoeline lunghe, ma mi sarei aspettato quantomeno l'IPC di K10...

[Mister D]

Visto che siamo ritornati sul discorso CMT vs SMT vorrei rendervi partecipi di questa piccola ma ben fatta recensione sullo scaling dei due diversi modi di interpretare la parellelizzazione:
http://atenra.blog.com/2012/02/01/am...r-cmt-scaling/
Si vede bene come il singolo core (INT) abbia perso IPC rispetto al vecchio core k10 e come il CMT scali molto meglio del SMT ma che alla fine partendo da una performance scarsa in ST si può solo arrivare a stare dietro ai core i7 con SMT.
Interessante vedere come anche quando vengono caricati un thread a modulo (2 th con 2 moduli o 4 th con 4 moduli) le performance sia del 20% più alte cosa che mi fa pensare che la vera mancanza di BD sia un turbo max scarso rispetto sia al turbo all cores sia alla frequenza di default. Più che avere maggiore frequenza di default sarebbe stato opportuno aumentare il delta del turbo per aumentare la performance quando 2 th sono caricati in un modulo solo, in moda da recuperare questo 20%.

[papafoxtrot]

Originariamente inviato da Mister D

Visto che siamo ritornati sul discorso CMT vs SMT vorrei rendervi partecipi di questa piccola ma ben fatta recensione sullo scaling dei due diversi modi di interpretare la parellelizzazione:
http://atenra.blog.com/2012/02/01/am...r-cmt-scaling/
Si vede bene come il singolo core (INT) abbia perso IPC rispetto al vecchio core k10 e come il CMT scali molto meglio del SMT ma che alla fine partendo da una performance scarsa in ST si può solo arrivare a stare dietro ai core i7 con SMT.
Interessante vedere come anche quando vengono caricati un thread a modulo (2 th con 2 moduli o 4 th con 4 moduli) le performance sia del 20% più alte cosa che mi fa pensare che la vera mancanza di BD sia un turbo max scarso rispetto sia al turbo all cores sia alla frequenza di default. Più che avere maggiore frequenza di default sarebbe stato opportuno aumentare il delta del turbo per aumentare la performance quando 2 th sono caricati in un modulo solo, in moda da recuperare questo 20%.

Il turbo sarebbe solo un'inutile pezza. Se le prestazioni con un thread a modulo crescono significa che la logica di controllo non riesce a gestire bene le due pipeline. E qui sicuramente BD è scarso. Branch prediction e decoder non sono evidentemente all'altezza. Rattoppare con frequenze turbo più alte farebbe crescere i consumi senza risolvere il problema alla base.

Per quanto riguarda il confronto CMT vs SMT lasciamo stare perché è evidente che non si riesce a capire che sono due cose differenti... SMT non è "un modo di interpretare la parallelizzazione", come l'hai chiamato tu. L'avere due thread a core è un mezzo, non un fine, nell'SMT.

[Mister D]

Originariamente inviato da papafoxtrot

Il turbo sarebbe solo un'inutile pezza. Se le prestazioni con un thread a modulo crescono significa che la logica di controllo non riesce a gestire bene le due pipeline. E qui sicuramente BD è scarso. Branch prediction e decoder non sono evidentemente all'altezza. Rattoppare con frequenze turbo più alte farebbe crescere i consumi senza risolvere il problema alla base.

Per quanto riguarda il confronto CMT vs SMT lasciamo stare perché è evidente che non si riesce a capire che sono due cose differenti... SMT non è "un modo di interpretare la parallelizzazione", come l'hai chiamato tu. L'avere due thread a core è un mezzo, non un fine, nell'SMT.

Orca miseria, evidentemente non sono stato abbastanza chiaro. Quando dico che sarebbe stato meglio avere un turbo più alto è ovvio che mi riferisco a parità di TDP e per cui a parità di consumi. Altrimenti è altrettanto ovvio che non serve ad una mazza, perché se per avere un turbo più elevato devo avere una cpu che consuma tantissimo in più allora addio all'efficienza energetica. Poi sono d'accordo con te che non è solo colpa del silicio e che BD pecchi proprio nella parte del FRONT-END e si vede bene dai grafici che ho postato, come hai fatto notare tu. Ma devi anche pensare che se avesse avuto le migliori unità BP e decoders possibili, una piccola perdita rispetto a non avere il CMT ci sarebbe comunque stata. E' qui un turbo in percentuale più alta sarebbe utile a mascherare questa perdita intrinseca dell'architettura CMT. Questo volevo dire

Per quanto riguardao il SMT ok non sarà il fine ma un mezzo per avere maggiore efficienza, ma alla fine della fiera il risultato è anche poter processare più thread senza dover implementare più risorse. Ecco perché intel non fa la corsa ad aumentare i core fisici e per cui per me questa è la sua interpretazione di parallelizzazione. Poi ognuno la può vedere come vuole.

[shellx]

Originariamente inviato da Mister D

Visto che siamo ritornati sul discorso CMT vs SMT vorrei rendervi partecipi di questa piccola ma ben fatta recensione sullo scaling dei due diversi modi di interpretare la parellelizzazione:
http://atenra.blog.com/2012/02/01/am...r-cmt-scaling/
Si vede bene come il singolo core (INT) abbia perso IPC rispetto al vecchio core k10 e come il CMT scali molto meglio del SMT ma che alla fine partendo da una performance scarsa in ST si può solo arrivare a stare dietro ai core i7 con SMT.
Interessante vedere come anche quando vengono caricati un thread a modulo (2 th con 2 moduli o 4 th con 4 moduli) le performance sia del 20% più alte cosa che mi fa pensare che la vera mancanza di BD sia un turbo max scarso rispetto sia al turbo all cores sia alla frequenza di default. Più che avere maggiore frequenza di default sarebbe stato opportuno aumentare il delta del turbo per aumentare la performance quando 2 th sono caricati in un modulo solo, in moda da recuperare questo 20%.

Il tipo utilizza la stessa templeate WPress (gia fatta) del mio bloghetto schifosetto

Ergo mi è venuta ispirazione di farci la traduzione di quell'articolo se qualcuno si scoccia tradurre (ovviamete traduzione by google).

Il link è nella mia firma se volete leggere l'articolo in italiano,non lo metto qui altrimenti si chiama SPAM.

[rainbow69]

Originariamente inviato da shellx

La piattaforma si chiamava korona (no corona come la birra o come il fidanzato di belen)

1) le cpu komodo dovevano essere socket fm2 condividendo lo stesso socket del segmento mainstream (ritornando al singolo socket per tutte le fasce), ma tali cpu con relativa piattaforma sono state cancellate da amd per far posto a vishera.
2) trinity è fm2, komodo doveva essere anch'esso fm2 ma con chispet della famiglia Hudson D4 - A85FX, prima di essere cancellato.
3) le cpu komodo come ho detto prima sono state cancellate per far posto alla prossima piattaforma per cpu vishera FX basate sull'evoluzione architetturale di Bulldozer chiamata Piledriver, ma nulla toglie che dopo Vishera qualcosa di molto simile a komodo possa essere annunciato da amd (forse per steamroller e 28nm -hub pcie integrato in cpu e socket con infrastruttura FMx) ma parliamo della meta 2013 e comunque è una ipotesi non un dato ufficiale.

Grazie delle delucidazioni adesso ho le idee più chiare
A proposito di Vishera, i primi modelli sono attesi per l'autunno o sbaglio?

P.S.
Alcune slides (care ad amd) http://www.tomshw.it/img_vedi.php?im...oadmap-amd.jpg riportano la piattaforma col nome "corona" come io ho riportato, mi spiace aver citato la concorrenza (non lo farò più)

[papafoxtrot]

Originariamente inviato da Mister D

Orca miseria, evidentemente non sono stato abbastanza chiaro. Quando dico che sarebbe stato meglio avere un turbo più alto è ovvio che mi riferisco a parità di TDP e per cui a parità di consumi. Altrimenti è altrettanto ovvio che non serve ad una mazza, perché se per avere un turbo più elevato devo avere una cpu che consuma tantissimo in più allora addio all'efficienza energetica. Poi sono d'accordo con te che non è solo colpa del silicio e che BD pecchi proprio nella parte del FRONT-END e si vede bene dai grafici che ho postato, come hai fatto notare tu. Ma devi anche pensare che se avesse avuto le migliori unità BP e decoders possibili, una piccola perdita rispetto a non avere il CMT ci sarebbe comunque stata. E' qui un turbo in percentuale più alta sarebbe utile a mascherare questa perdita intrinseca dell'architettura CMT. Questo volevo dire

Per quanto riguardao il SMT ok non sarà il fine ma un mezzo per avere maggiore efficienza, ma alla fine della fiera il risultato è anche poter processare più thread senza dover implementare più risorse. Ecco perché intel non fa la corsa ad aumentare i core fisici e per cui per me questa è la sua interpretazione di parallelizzazione. Poi ognuno la può vedere come vuole.

Il turbo in realtà servirebbe anche a poco, perché avendo impostato lo scheduling in modo da distribuire un thread a modulo, finché non si arriva a superare i 4 thread, comunque non entra in funzione... A meno di impiegare solo due thread al massimo, per cui si impiegano due moduli...

Purtroppo per com'è fatto il CMT, il turbo con granularità per modulo serve a poco... Servirebbe un turbo con granularità più fine (per core), e lo stesso per il power gating, ma allora si perderebbero parte dei vantaggi dei moduli, cioè la semplificazione della logica di controllo.

Comunque ciò che volevo dire è che anche se si avesse una frequenza più alta in turbo a pari consumo energetico, non si avrebbe risolto il problema, perché la soluzione non sarebbe efficace dal punto di vista del rendimento; vorrebbe dire che si potrebbero ottenere le stesse prestazioni con un turbo più basso e un consumo inferiore, ad esempio...
Far fare cicli persi ad una CPU è sempre un cattivo risultato, e questo è ciò che avviene, purtroppo, nei moduli bulldozer; metterci una pezza con un turbo spinto (ma come ho già detto funziona solo per il single threading) non è una soluzione... Questo volevo dire.

Mi auguro che in piledriver ci siano tante novità di cui AMD non ha parlato, altrimenti andiamo davvero a male...
Lo ripeto, il progetto di BD non è ottimizzato per quelle ceh sono le conoscenze di AMD... Secondo me doveva sruttare la sua esperienza fatta con K8 e K10... In ogni caso ormai siamo qui, e tante piccole cose rendono BD lento... In passato AMD è stata molto lenta a correggere le sue architetture, speriamo che oggi si dia una sveltita...

[paolo.oliva2]

Guarda Papafoxtrot, qui occhio e croce tutti diciamo la stessa cosa.

Tralasciando IPC e quant'altro, è molto più facile e concreto dirla in questo modo: se Intel con un X4 con SMT, che occupa 150mm2 (dedurrei togliendo considerando i 180mm2 del 2600K), riesce ad ottenere una potenza maggiore di un X8 CMT AMD, oltretutto con 30W TDP in meno, Intel indubbiamente non è che ha vinto, ha stravinto...

Quello che io cerco di farti capire (ma non da capiscione ma solo per come la penso io) un gap del 30-40% in meno di prestazioni/consumi NON può essere per le latenze delle cache (che non inciderebbero nulla sui consumi perché probabilmente si avrebbe più efficienza a parità di consumo), non è per le grandezze delle cache, non è per la predizione o qualsivoglia altro motivo... ma il consumo/prestazioni dipende in larghissima parte dal silicio... quindi non si può parlare di pezza del silicio con un -40% di efficienza. Un 8150 è 125W TDP per 3,6GHz def e 4,2GHz come massima frequenza Turbo. Per Vishera ci potrebbe essere la concreta possibilità di 4,2GHz def sempre a 125W TDP... quindi avremmo che un procio girerebbe a def su 8 core già alla frequenza massima che un 8150 assegnava a 4 core in turbo, ma con un turbo su 8 core superiore alla frequenza massima di un 8150 su 4 core. Sarebbe come un 2600K a 3,4GHz con 3,9GHz di turbo e la versione dopo a 4GHz def...

Perché io parlo sempre SE AMD migliorasse il silicio, perché se da un -40% di efficienza si arrivasse ad un -20%, già vorrebbe dire un +20% di performances di un 8150 sempre nei 125W TDP.
Se questo FOSSE possibile, la lacuna più grande verrebbe colmata, perché per me prima ancora di confrontarmi con Intel, sarebbe doveroso confrontarsi con il Thuban, ed un BD con la possibilità di una frequenza massima Turbo sul 15%-20% superiore su 1 modulo risolverebbe il problema IPC ST, arrivando ad essere simile al Thuban.
Nell'MT non ci sono grandi problemi, perché già un 8150 è migliore del Thuban, e con un -20% di consumi non avrebbe nessun problema nel consumo/prestazioni.

Ma non è un alibi il silicio, se GF non migliora il PP del silicio, BD non può sperare di recuperare granché con l'IPC, e quindi CMT o non CMT, anche un Thuban non avrebbe concesso di più.

Quello che invece pensi tu, è che la colpa sia solamente dell'architettura, aggiungendoci che doveva fare un'architettura SMT, ma se il silicio è questo, non sarebbe cambiato nulla, anzi, forse ancora meno, visto che un Llano K10 per 100W non supera i 2,9GHz, quando per 95W e sul 45nm credo già sia possibile un Phenom II X6 a 3GHz... cacchio, 32nm, HKMG, ULK, possibile che non abbiano portato NULLA su consumi inferiori? Se la dichiarazione ufficiale di AMD/GF circa un -40% di consumi a parità di potenza si fosse dimostrata reale, un 8150 dovrebbe avere 65W TDP ed invece ne abbiamo 125W e considera che il TDP reale del Phenom II rispetto al nominale era del 17% inferiore, in BD si arriva al 5%, quindi al TDP nominale si deve aggiungere anche un TDP reale più sfruttato.

[shellx]

Originariamente inviato da rainbow69

Grazie delle delucidazioni adesso ho le idee più chiare
A proposito di Vishera, i primi modelli sono attesi per l'autunno o sbaglio?

P.S.
Alcune slides (care ad amd) http://www.tomshw.it/img_vedi.php?im...oadmap-amd.jpg riportano la piattaforma col nome "corona" come io ho riportato, mi spiace aver citato la concorrenza (non lo farò più)

Si in autunno.
Mi sa che hai ragione sul discorso corona/korona. Molti la chiamano korona, ma sulle testate negli articoli e slide (anche amd) viene citata come Corona. Per cui si, mi sono sbagliato io: si chiama, anzi si chiamava "Corona" con cpu Komodo.

[LS1987]

Se il problema fosse invece il socket? Magari con un nuovo socket avrebbe reso di più. In pratica AM3+ è un socket 939 con controller DDR3 (cambia solo qualche pin).