[Thread Ufficiale] Aspettando Bulldozer *leggere prima pagina con attenzione*

[Gigamez]

Originariamente inviato da Ares17

In quella pagina c'è scritto che la cache istruction (l1 ?) è di 64k ed è condivisa tra le due unità int, mentre la cache data è di 16k per ogni int.
Che le speculazioni fatte prima su un possibile supercore (sia le mie che quelle di Gigamez) non siano davvero implementate in qualche modo?

vero (e me ne ero sinceramente dimenticato), lo avevo letto e fatto notare anche io qualche settimana fa..

dai che magari ci scappa il sorpresone XD!
Si, ma se poi ci abbiamo azzeccato il capitano deve come minimo offrire da bere a tutti,
hehe

[Pihippo]

Originariamente inviato da Ren

Le solite cose per cui intel si avvantaggia, ossia algoritmi di predizione migliore, scheduler unificati e compilatori ottimizzati...

Ciao
Appunto, oltre a un sistema di caches più efficiente di quello di amd ed i migliori prefetchers sino ad ora in circolazione, (che fanno grandi cose nei c2q e nei nehalem) Oltre ad avere con nehalem un memory controller che ti da più banda e meno latenza di quello dei k10, e non è da poco.

[Pihippo]

Originariamente inviato da Gigamez

Cut

Bisogna creare due veri e propri "flussi" di pacchetti di istruzioni cercando di far si che i pacchetti del primo flusso non siano in dipendenza sequenziale rispetto ai pacchetti del secondo flusso. Praticamente bisognerebbe avere una sorta di secondo branch prediction sui due rami, oltre che quello "classico" sulle istruzioni ed quindi un ulteriore algoritmo di ordinamento in base alle dipendenze sui flussi di pacchetti.. non sarebbe uno scherzo, senza contare che servirebbero logiche di fetch, decode, scheduling e retire che siano decisamente piu' veloci (e magari complesse) del normale.. o sbaglio?

Ciao.
Guarda purtroppo l'isa x86 contiene istruzioni tra loro non ortagonali, ovvero di lunghezza in n di bit differenti tra loro, perciò una bella fase di tempo viene spesa nello scanning delle istruzioni, ovvero, esempio, fetch di 32 bytes quante istruzioni in essi? 15, bene il procio decodifichera tranquillamente fino a quando non trova una istruzione di branch, si perde un ciclo, si rifectha il codice giusto (se hai preso la diramazione giusta e se hai gli operandi caricati ) e si ricontinua.
Ovviamente non sono un tecnico e nelle cose soprascritte c'è di vero assumo il 10%, però come puoi ben vedere predire le dipendenze di due flussi "pachetti" è abbastanza difficile.

[paolo.oliva2]

Capitano... c'è una cosa che non mi è chiara.

Praticamente nell'intervista AMD riporta che hanno tralasciato Buldozer sul 45nm perché sarebbe stato meno competitivo, e modificato per sfruttare al meglio il 32nm perché con la riduzione di TDP avrebbe garantito più spazio per i core e FPU. By going for lower power, we hope to give you more room for compute cores, FP capabilities and more

Ora... c'è qualche cosa che non mi torna.
BD può contare su un'ottimizzazione migliore per quello che riguarda IPC/W.
Quindi, se fosse realizzato ancora sul 45nm, potrebbe garantire 8 core suppergiù al TDP del Thuban, ad essere pessimisti, diciamo 140W.
A questo si aggiunge il 32nm che a parità di potenza produrrebbe il 40-50% in meno di TDP.
Insomma... su questa base, un BD X8 a 3,2GHz sul 32nm dovrebbe essere dai 70W ai 94W...
Per arrivare ai 125W... c'è un margine pazzesco... dai 31W ai 55W.

Praticamente se un BD "lavorasse" a frequenze del Thuban avrebbe un margine tale nel TDP da poter garantire da un +40% a un + 80% dei core.

Riportando quello in neretto... possibile che AMD si fermi a solo 2 core in più? Mi suona strano che 800MHz di clock stock maggiore possano assorbire da soli 50W, quando un Thuban già sull'E0 45nm per i 4GHz X6 si ferma ad un TDP maggiore sotto i 30W, considerando poi pure il fatto che teorizzando 1GHz di Turbo, mi pare chiaro che il Vcore non può arrivare alle stelle...

[cionci]

Probabilmente il progetto non era quello che vediamo oggi.
Inoltre pare evidente che fosse il processo produttivo stesso a limitare la possibilità di salire in frequenza, quindi di fatto castrando il progetto.

[paolo.oliva2]

Originariamente inviato da cionci

Probabilmente il progetto non era quello che vediamo oggi.
Inoltre pare evidente che fosse il processo produttivo stesso a limitare la possibilità di salire in frequenza, quindi di fatto castrando il progetto.

Probabile.
Però non mi torna che un BD 32nm odierno possa avere il limite di 8 core per restare dentro i 125W.

Con un 50% in meno di TDP a parità di frequenza per il silicio e con un 10-20% a parità di architettura per le migliorie, un BD alle frequenze del Thuban (3,2GHz) dovrebbe consentire almeno un 65-80% in più di core del Thuban.
Thuban X6, BD X10-X11... X8 è un totale sotto...

[calabar]

Forse AMD ha voluto evitare che il progetto BullDozer subisse la sorte del progetto Phenom: un processore troppo complesso per il processo produttivo per cui è stato pensato.
Così, anzichè rischiare di perdere tempo a rappezzare un eventuale Bulldozer inadatto al processo produttivo, hanno deciso di saltare a pie pari i 45nm migliorando ulteriormente il progetto, ed evitando così di perdere altra strada nei confronti di Intel.
Scelta abbastanza condivisibile, direi, se i risultati non sono stati da subito quelli sperati.

[Gigamez]

Originariamente inviato da Pihippo

Ciao.
Guarda purtroppo l'isa x86 contiene istruzioni tra loro non ortagonali, ovvero di lunghezza in n di bit differenti tra loro, perciò una bella fase di tempo viene spesa nello scanning delle istruzioni, ovvero, esempio, fetch di 32 bytes quante istruzioni in essi? 15, bene il procio decodifichera tranquillamente fino a quando non trova una istruzione di branch, si perde un ciclo, si rifectha il codice giusto (se hai preso la diramazione giusta e se hai gli operandi caricati ) e si ricontinua.
Ovviamente non sono un tecnico e nelle cose soprascritte c'è di vero assumo il 10%, però come puoi ben vedere predire le dipendenze di due flussi "pachetti" è abbastanza difficile.

allora, ragioniamo nella "pratica" impropriamente con una logica di "pacchetti" considerando l'assenza di ogni ulteriore algoritmo di ordinamento rispetto a quelli gia' classici che ci sono..

Ragioniamo inizialmente nel caso di un solo core. Mando in sequenza i pacchetti A,C,B,D alle mie alu. Sappiamo che i nostri algoritmi "classici" li hanno cosi' ordinati in quanto il pacchetto "B" dipende dal risultato del pacchetto "C". L'esecuzione sarà dunque lineare in quanto l'ordine di invio scelto e' ottimale per non avere interruzioni di flusso.
In ordine possiamo schematizzare in questo modo:

core0
1)loading A
2)return A
3)loading C
4)return C
5)loading B
6)return B
7)loading D
8)return D

abbiamo eseguito 8 ipotetici cicli di clock.

Ora ragioniamo secondo la stessa logica e secondo LO STESSO algoritmo di ordinamento usato nel primo esempio. Abbiamo il pacchetto A che viene mandato al core0. Quando il core0 mi dara' il risultato di A, allora caricherò il pacchetto C sul core1. Mentre il core1 mi da il risultato di C, carichero' sul core0 B. Non avro' comunque problemi di esecuzione riguardo al pacchetto B, perche' il risultato di C da cui dipende, io ce l'ho gia'!
Vediamo uno schema semplificato al massimo come il precedente:

Core0 | Core1
1) Loading A | IDLE
2) Return A | Loading C
3) Loading B | Return C
4) Return B | Loading D
5) IDLE | Return D

abbiamo eseguito solamente 5 ipotetici cicli di clock, senza nemmeno aver dovuto modificare il nostro algoritmo (perche' non ci sarebbe nulla da modificare). Ovviamente il guadagno e' minore per frammenti di codice tanto piu' piccoli in quanto i due idle di inizio e di coda di uno dei due core incidono in percentuale in maniera inversamente proporzionale al numero di pacchetti. Se invece di avere 4 pacchetti ne avessimo avuti ad esempio 4000, il guadagno sarebbe stato sempre piu' vicino al teorico 50%.

dove sto sbagliando? XD

[B|4KWH|T3]

Originariamente inviato da paolo.oliva2

Prova a guardare i test su linux... .
In ambito Windows, senza sollevare polemiche, le piattaforme Intel rendono sempre di più, ma le cose cambieranno, perché con le AVX non potranno esistere compilatori "partigiani", e poi perché Intel non può risciare altre sanzioni perché è già stata avvisata e nell'accordo di "liquidazione" vecchio ha messo su carta che deve cambiare.
In ambito Linux le differenze tra un Magny-C ed un X6 Intel sono esigue, ma conta il fatto che il Magny-C "gira" a 2,4GHz-2,5GHz e l'Intel gira a 3,333GHz.
Con base SB Intel avrà suppergiù gli stessi clock, mentre un Magny-C, anche consideranto (per me) il sottostimato di Cionci a +500MHz, cosa otterremo?
SB un incremento di IPC, ma se un SB X4 mostra un +12% di media.... SB X6 potrebbe averlo inferiore, ma sicuramente NON maggiore.
AMD Da 2,5GHz a 3GHz si tratterebbe di +20%.
Ai bench visti, ammettendo per SB +10% e per Magny-C +20%, la risultante è che uscirebbe un +10% a favore di AMD rispetto all'attuale, non briciole, considerando per Magny-C solo 3GHz su 32nm...
Però, se vogliamo considerare per SB un +10% di IPC e pure un +10% sul clock, con risultante di un incremento maggiore del 20%, con la stessa manica larga non possiamo considerare solo un 20% per Magny-C, allo stesso modo, dovremmo considerare almeno un 40-50% che sarebbe equivalente alla stessa diminuzione di TDP dichiarata da AMD.
Se vogliamo fare i confronti, dobbiamo utilizzare lo stesso metro. E' inutile fare confronti aumentando le aspettive sull'Intel ed abbassando nettamente sul concreto quelle AMD... che confronto verrebbe fuori?

Per ora con il compilatore non è cambiato ancora nulla e dubito fortemente che cambierà.
Con l'ultimo uscito Intel ha messo un disclaimer e basta

La cosa di cui si parla poco sono queste:
http://software.intel.com/en-us/intel-mkl/

Anche queste sono ottimizzate per modello di processore e non per verifica della presenza del set di istruzioni corretto (ovvero, abilitano il corretto path di codice verificando il modello). Ciò porta ad un degrado per i processori non Intel.

Il vero problema è che quelle librerie sono le migliori disponibili e usandone altre le prestazioni non arrivano a quelle che si hanno usando le librerie Intel. Anche se non viene abilitato il path più ottimizzato.

AMD deve darsi una seria svegliata sotto questo punto di vista e assumere un po' di sviluppatori. Addirittura le stesse ottimizzazione pro intel sono state trovate anche nella AML (AMD Math Library).

Qui puoi seguire tutta la storia: http://software.intel.com/en-us/intel-mkl/

[paolo.oliva2]

Originariamente inviato da B|4KWH|T3

Per ora con il compilatore non è cambiato ancora nulla e dubito fortemente che cambierà.
Con l'ultimo uscito Intel ha messo un disclaimer e basta

La cosa di cui si parla poco sono queste:
http://software.intel.com/en-us/intel-mkl/

Anche queste sono ottimizzate per modello di processore e non per verifica della presenza del set di istruzioni corretto (ovvero, abilitano il corretto path di codice verificando il modello). Ciò porta ad un degrado per i processori non Intel.

Il vero problema è che quelle librerie sono le migliori disponibili e usandone altre le prestazioni non arrivano a quelle che si hanno usando le librerie Intel. Anche se non viene abilitato il path più ottimizzato.

AMD deve darsi una seria svegliata sotto questo punto di vista e assumere un po' di sviluppatori. Addirittura le stesse ottimizzazione pro intel sono state trovate anche nella AML (AMD Math Library).

Qui puoi seguire tutta la storia: http://software.intel.com/en-us/intel-mkl/

Ma il discorso non riguardava o meno le librerie più ottimizzate... il discorso era incentrato sul fatto "IF not genuine cpu Intel Then...." che è ben altro.
Una cosa è che AMD utilizzi librerie fatte da Intel per CPU Intel, e qui certamente AMD non può obbligare Intel a ottimizzarle per proci AMD, un altro che le stesse librerie in caso di una CPU NON Intel, di proposito instaura loop assurdi e non ottimizzati, giustificati da Intel come "realizzati per assicurare una piena compatibilità"... . L'intento con cui è stato fatto, come ben sappiamo, è tutt'altro.
Infatti nessuno ha chiesto che Intel realizzasse qualche cosa ad hoc per AMD, ma solamente che Intel togliesse le discriminazioni.
Poi è chiaro che se andiamo a vedere la spiegazione ufficiale sul sito Intel, tutto scriveranno tranne che l'hanno fatto per far andare più piano la concorrenza e far apparire i propri proci più veloci.

[affiu]

Originariamente inviato da paolo.oliva2

Probabile.
Però non mi torna che un BD 32nm odierno possa avere il limite di 8 core per restare dentro i 125W.

Con un 50% in meno di TDP a parità di frequenza per il silicio e con un 10-20% a parità di architettura per le migliorie, un BD alle frequenze del Thuban (3,2GHz) dovrebbe consentire almeno un 65-80% in più di core del Thuban.
Thuban X6, BD X10-X11... X8 è un totale sotto...

il controller di memoria di bulldozer è diverso dal k10 e non solo per la frequenza,anche se dual .dovrà resistere a stress di overclock spinti e deve tenere a bada 2 o 4 moduli a 5 o piu gigahertz

questo significa che per essere all'altezza deve pompare parecchio perche deve tenere a bada il lavoro di un bulldozer x8 a 5 ghz + 8/16 giga di ram a 2500 mghz (o su di li )

[cionci]

Originariamente inviato da Gigamez

Vediamo uno schema semplificato al massimo come il precedente:

Core0 | Core1
1) Loading A | IDLE
2) Return A | Loading C
3) Loading B | Return C
4) Return B | Loading D
5) IDLE | Return D

Questa cosa si fa sfruttando le varie unità di esecuzione della stesso core INT. Lo scheduler riordina le istruzioni a seconda delle dipendenze e le smista in modo da svolgere il più possibile dei compiti in parallelo. I pacchetti di istruzioni non esistono, le dipendenze possono anche esistere a centinaia di istruzioni di distanza.

[Gigamez]

Originariamente inviato da cionci

Questa cosa si fa sfruttando le varie unità di esecuzione della stesso core INT. Lo scheduler riordina le istruzioni a seconda delle dipendenze e le smista in modo da svolgere il più possibile dei compiti in parallelo. I pacchetti di istruzioni non esistono, le dipendenze possono anche esistere a centinaia di istruzioni di distanza.

infatti, so che non esistono per i pacchetti ma solo per le singole micro-op, per quello parlavo di pacchetti in maniera ipotetica.. ma se si usasse lo stesso algoritmo invece che sulle singole micro-ops, direttamente su dei "pacchetti", allora il risultato sarebbe questo, o sbaglio?
Teoricamente non dovrebbe essere molto piu' dispendioso calcolare il tutto secondo lo stesso algoritmo non per l'istruzione ma per il pacchetto (anche inteso come un array di 4 micro istruzioni, tante quante sono le alu nella singola unità INT).
Se poi le dipendenze fossero molto distanti tra loro, magari distanti piu' dell'intervallo di tempo necessario a processare cio' che ci sta in mezzo diviso il numero di istruzioni per pacchetto, non servirebbe nemmeno calcolarle, sbaglio?

[Pihippo]

Originariamente inviato da Gigamez

infatti, so che non esistono per i pacchetti ma solo per le singole micro-op, per quello parlavo di pacchetti in maniera ipotetica.. ma se si usasse lo stesso algoritmo invece che sulle singole micro-ops, direttamente su dei "pacchetti", allora il risultato sarebbe questo, o sbaglio?
Teoricamente non dovrebbe essere molto piu' dispendioso calcolare il tutto secondo lo stesso algoritmo non per l'istruzione ma per il pacchetto (anche inteso come un array di 4 micro istruzioni, tante quante sono le alu nella singola unità INT).
Se poi le dipendenze fossero molto distanti tra loro, magari distanti piu' dell'intervallo di tempo necessario a processare cio' che ci sta in mezzo diviso il numero di istruzioni per pacchetto, non servirebbe nemmeno calcolarle, sbaglio?

Ciao
Dunque, premetto che le dipendenze non esistono solo sulle istruzioni, ma anche sui dati. Detto ciò, se calcoli come dici in maniera OoO, devi poi comunque riordinare per ritirare come il programma richiede. Quindi, scusami se ancora non ho abbastanza vita da sto schifobook, le istruzioni in mezzo le devi comunque calcolare.
Cosa succederebbe ad esempio nel caso di un salto indiretto (ovvero memory address non conosciuto) ?

[carlottoIIx6]

Originariamente inviato da Pihippo

Ciao
Dunque, premetto che le dipendenze non esistono solo sulle istruzioni, ma anche sui dati. Detto ciò, se calcoli come dici in maniera OoO, devi poi comunque riordinare per ritirare come il programma richiede. Quindi, scusami se ancora non ho abbastanza vita da sto schifobook, le istruzioni in mezzo le devi comunque calcolare.
Cosa succederebbe ad esempio nel caso di un salto indiretto (ovvero memory address non conosciuto) ?

non sputiamo, plese, nel piatto in vui mangiamo
secondo me bulldozer nasconde un segreto
chi lo capisce è bravo

[Gigamez]

Originariamente inviato da Pihippo

Ciao
Dunque, premetto che le dipendenze non esistono solo sulle istruzioni, ma anche sui dati. Detto ciò, se calcoli come dici in maniera OoO, devi poi comunque riordinare per ritirare come il programma richiede. Quindi, scusami se ancora non ho abbastanza vita da sto schifobook, le istruzioni in mezzo le devi comunque calcolare.
Cosa succederebbe ad esempio nel caso di un salto indiretto (ovvero memory address non conosciuto) ?

certo, ragionando in ottica OoO la retire-unit dovrebbe essere unificata per i due core. Gli algoritmi di "riordino" sarebbero esattamente i medesimi di quelli tradizionali in quanto il flusso di output sarebbe appunto esattamente il medesimo con pero' una portata doppia. Il riordino pertanto dovrebbe essere eseguito ovviamente anch'esso al doppio della velocità.
Anche se penso la cosa migliore sia avere un'unica retire (era questo appunto l'unico "neo" che dai grafici visti non quadrerebbe nel mio ragionamento, come appunto piu' volte ho detto), volendo si potrebbero anche avere due retire core più una retire unificata a livello modulo, in modo da frammentare il carico di lavoro relativo a riordinamento per magari cercare di avere una implementazione piu' semplice.

Per quanto invece riguarda i vari algoritmi di predizione sarebbero tali e quali a quelli normalmente usati. Secondo me l'unico problema aggiuntivo come ho già detto in una logica di questo tipo sarebbe il far fronte alle dipendeze di flusso tra pacchetti..

[Athlon]

Il consumo di Bulldozer DEVE essere molto basso perche' non dobbiao dimenticare che a breve all' interno del Chip verra' integrata una scheda video completa e che al giorno d'oggi una scheda video assorbe anche 200W.

sicuramente in futuro i TDP delle CPU verranno alzati di molto perche' dovranno includere quello che e' oggi consumato da una schda video.

Sicuramente ci saranno un po' di ottimizzazioni dovute al fatto che la FPU tradizionale verra' eliminata e verranno usate le pipeline grafiche , pero' si tratta comunque di circa 200W che si aggiungono all' attuale TDP.


Per come la vedo io con Fusion2 il TDP di una CPU viaggera' intorno ai 200-250W e nelle maniboard Gaming sara' possibile montare una seconda CPU per avere piu' potenza grafica


Questo vuol dire che OGGI l'architettura Buldozzer deve consumare veramente poco per potersi adattare in futuro a questa nuova e grande inclusione.


Personalmente ritengo che da parte di AMD non ci sarebbero problemi tecnicamente a proporre fin da subito un bulldozer 16x , pero' se si giocano subito tutte le carte poi si resta senza risorse

[Gigamez]

Originariamente inviato da Gigamez

Se invece di avere 4 pacchetti ne avessimo avuti ad esempio 4000, il guadagno sarebbe stato sempre piu' vicino al teorico 50%.

dove sto sbagliando? XD

beh, un errore l'ho gia' trovato.. il guadagno TEORICO sarebbe del doppio (sugli INT), quindi del 100%

[calabar]

Originariamente inviato da Gigamez

certo, ragionando in ottica OoO la retire-unit dovrebbe essere unificata per i due core. Gli algoritmi di "riordino" sarebbero esattamente i medesimi di quelli tradizionali in quanto il flusso di output sarebbe appunto esattamente il medesimo con pero' una portata doppia. Il riordino pertanto dovrebbe essere eseguito ovviamente anch'esso al doppio della velocità.

Secondo me il problema continua ad essere quello di cui avevamo parlato all'inizio di questa discussione:
inutile mettere a disposizione di un singolo thread il doppio delle pipeline int, perchè a causa delle dipendenze non è mai possibile sfruttarne più di tre o quattro insieme.

Le unità int attuali sono cioè già ben dimensionate per gestire un unico flusso, e per poter avere prestazioni superiori ci sono solo due strade:
- dividere questo "flusso" in due, ossia avere due thread distinti (e quindi lavorare sulla parallelizzazione del codice)
- lavorare su ciò che sta intorno alle unità int in maniera tale da sfruttarle al meglio (con decoder migliori, algoritmi di branch prediction migliori, occupazione delle pipeline tramite SMT, ecc...)

[paolo.oliva2]

Io aspetto altre dichiarazioni da parte di AMD, che dovrebbero arrivare entro i primi di novembre.
Non mi posso addentrare "dentro" al funzionamento del procio perché non ne ho le basi.
Però, a intuito, BD è un po' "strano" al suo interno... e non credo sia uno step di architettura che non avrà nulla a che fare con Fusion2.
Secondo me, rimango dell'idea che ci sfugge qualche cosa nell'ottica di funzionamento di BD.
Tra l'altro... trovo molto strano che BD si limiti ad un X8 per i 125W.
E trovo alquanto strano che in caso di IPC non superiore al 15% del Phenom II non si faccia ricorso ad aumentare i core sfruttando il clock del Turbo che secondo me da un X4 ad un X8 non dovrebbe praticamente cambiare.
Tanto le caratteristiche del silicio sono simili... se si dovesse portare un BD X8 a 4GHz stock per ottenere potenza (IPC x Core), tralasciando il Turbo che non dovrebbe cambiare da X4/X8 per via dello spegnimento dei moduli se non attivi, si otterrebbero più benefici in caso di frequenze minori ma con aumento dei core.
Io supporrei che se AMD così non ha fatto, vuol dire che X8 ha un sufficiente IPC e che non si ricerca il clock massimo per compensarlo.
In vista di Fusion2, questa architettura dovrebbe avere i requisiti trasformarsi in una APU... e con la coesione con le unità di calcolo VGA, se proprio non è presente in questa release, perlomeno l'0architettura di sé per sé dev'essere comunque idonea.
Su queste basi... nel modulo c'è certamente almeno un approccio, e secondo me è quello che sfugge per inquadrare l'IPC che dovrebbe essere anche più del 15%... BD è nato per contrastare SB... e se l'SB tra 1 anno lo vedremo come X8, se l'IPC fosse basso, BD sarebbe nato almeno come X10.
Scusate... partendo da un dato di fatto che il silicio AMD 32nm HKMG (forse pure low-k dall'inizio) sarà indubbiamente migliore di quello Intel... che vie può attuare AMD? TUTTE.
- aumento dei core, stile Thuban X6 vs X4.
- aumento del clock
- aumento dell'IPC
Ora... 8 core al posto di 6 del 45nm... a me sembra scarso... avrebbe potuto realizzare almeno un X10 e pure un X12 (se colleghiamo strategia Turbo clock alto per il monocore e clock relativamente più basso di un X8 ma con più core).
Il clock sarà certamente alto... però riflettiamo un attimo: una frequenza turbo ipotizzata a +1GH, non è di per sé la conferma che il clock per tutti i core sia "limitato" dal TDP?
Faccio un esempio: Thuban X6 3,2GHz... X4 3,6GHz.
Questo perché? Perché oltre i 3,6GHz ci vogliono più di 1,3-1,35V che, ipotizzo io, comincia nell'aumento di W rispetto a clock*IPC.
Ma il Turbo di +800MHz-1GHz, per me rendono l'idea che ancora non ci sia l'impennata dei consumi rispetto alla potenza.
Quindi cosa vorrebbe dire? Che gli 8 core lavorano pienamente a frequenze quasi di "riposo".
Con frequenze così "relativamente" basse, che aumento di TDP si avrebbe ad avere 10 core o 12? Guardiamo il Magny-C, ha 700MHz in meno con 12 core rispetto ad un Thuban che è a 3,2GHz ma come X6 e per giunta con il low-k. E' così assurdo pensare che un X12 BD sul 32nm "pagherebbe" una diminuzione di frequenza ridicola? Probabilmente almeno 3GHz.
Ma... ci facciamo un'idea che già di per sé potremmo parlare di 12 core sui 3GHz? Se il Turbo potesse da solo permettere i 5GHz, l'IPC monocore non avrebbe di per sé problemi.
Vediamo il multicore... Un Thuban @4,5GHz corrisponderebbe ad un Thuban X8 a 3,4GHz scarsi... e ad un X10 a 2,7GHz, addirittura un X12 a 2,250GHz (almeno con Cinebench, pov-ray, H-264 e similari). Un 12 core a 3GHz sarebbero tanto quanto un Thuban a 6GHz. Un Thuban a 6GHz se lo pappa un I7 X6 a 3,3GHz, in qualsiasi condizione, pure nella versione SB.
Allora... la risposta si deve trovare nella semplice equazione X12=X8.
P.S.
Che vi devo dire? Ho fatto il mio classico poema...