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

[paolo.oliva2]

Facciamo un attimo di riflessione:

Comunque, non c'è correlazione tra la frase di AMD "proporremo TH fisici a TH logici" in un procio che con 4 moduli può gestire al max 8 TH contro già un i7 980X che ne può gestire 12.

Le uniche uscite da questo ragionamento che vedrei sono 2:

1a
-------------------------------------------------------------------
che l'affermazione sia per l'ambito server: SB X8 con 16 TH = BD X16.
Per il desktop rimane solo BD X8, magari reputandolo già sufficiente almeno sino all'arrivo di SB X8 previsto sul finire anno prox.
Nel momento in cui Intel proporrà un X10, tra affinamenti e quant'altro, penso probabile che AMD proporrà un BD X10 e a quel punto non credo problematica l'"emigrazione" pure nel desktop.
--------------------------------------------------------------------

2a.
Il desktop, ha altre prerogative.

E' importante l'IPC del singolo core (ed in questo l'esempio è l'i7 e successivamente SB, in questo Intel al momento è nettamente prima).

Se BD incrementa l'IPC singolo core, facendo lavorare il modulo come X1, risolve ampiamente il problema, aiutato inoltre dal clock di per sé almeno del 25-30% superiore a quello Intel.

Il numero di TH è secondario... e comunque, diciamo che AMD anche con un numero di TH inferiore, essendo i TH fisici, non ha problemi a contrastare un numero di TH superiore da parte di Intel, visto che sono logici ma che si basano su n core logici/2 = core fisici, quindi anche in caso di SB X6 e X8, che comunque arriveranno sul finire anno prox., AMD avrebbe tutto il tempo sia per un nuovo step di silicio, sia per aggiungere il low-k se non presente all'uscita, e, tra CTI e processo a regime, miglioramenti di TDP tali da permettere l'aggiunta di 2 core non vedrei il tutto problematico.

Inoltre, il desktop può contare su clock sicuramente più alti che nel server, può contare su proci B.E. per la gioia di tutti.... ci mancherebbe solo un listino alla Thuban e vivremmo tutti felici e contenti.

[paolo.oliva2]

Originariamente inviato da Ares17

Ci ho pensato durante tutto il pomerigio:
Per aumentare l'ipc in monoth basterebbe che in caso di prediction fault invece di attendere lo svuotamento delle pipeline prima di inserire altri dati da elaborare si manda il tutto in esecuzione sull'altro core (abbassando di molto le latenze).
Questo potrebbe permettere un doppio vantaggio:
utilizzare algoritmi di prefech più spinti e al tempo stesso riddurre di molto i cicli di attesa in caso di fetch fault.
Questo porterebbe il guadagno di ipc ad una notevole impennata (tra un fetch aggressivo ed una notevole tolleranza all'errore, senza peraltro innalzare di un solo watt il tdp del singolo modulo.
Potrebbe sembrare FS, ma credo che con una struttura logica come quella imputata a Bd sia più che possibile e senza le controindicazioni dei processi multith che generalmente sono abbastanza prevedibili limitando le latenze dovute a fetch fault.
Se ho detto una cassanata scusatemi.

Per me siamo nella strada giusta e l'abbiamo nasata molto bene... In fin dei conti il TH del Capitano è sempre stato nelle prime posizioni in fatto di nasate Vi ricordate quella dell'E0 del Thuban?

Inoltre... JF con quel 13% in più... non è attendibile nel desktop, perché lui parlava di server, quindi tutto il "nostro" discorso che si basa sul modulo inteso come X1 esula dalla sua affermazione.
Per finire... se cominciano ad essere sempre di più chi afferma che a parità di clock BD sarà sotto ma di poco a SB, ciò è ottenibile unicamente con sopra il 30% di IPC, cosa che mi sembra non sia giustificata da un INT in più e una doppia FP e L2 da 2MB. Un qualche cosa ci deve essere, e penso sia quella che abbiamo nasato....

[Megakirops]

Appoggio Gigamez, infatti l'argomento non è nuovo ma ne parlammo già nel mese di luglio, e fui proprio io ad avanzarla

Sono ancora convinto che ci sarà la sorpresa dei BD X4/4moduli/8thread fisici ed X8/8moduli/16thread fisici che però all'occorrenza possono lavorare solo su 4 ed 8 thread rispettivamente nel caso di programmi poco propensi al multi-thread in modo da ottimizzare le risorse.

[Heimdallr]

comunque i SB di fascia alta su lga 2011 sono previsti per il Q3 2011, quindi BD dovrà fronteggiarli ben presto dopo la sua uscita.

[Gigamez]

Originariamente inviato da Ares17

Ci ho pensato durante tutto il pomerigio:
Per aumentare l'ipc in monoth basterebbe che in caso di prediction fault invece di attendere lo svuotamento delle pipeline prima di inserire altri dati da elaborare si manda il tutto in esecuzione sull'altro core (abbassando di molto le latenze).
Questo potrebbe permettere un doppio vantaggio:
utilizzare algoritmi di prefech più spinti e al tempo stesso riddurre di molto i cicli di attesa in caso di fetch fault.
Questo porterebbe il guadagno di ipc ad una notevole impennata (tra un fetch aggressivo ed una notevole tolleranza all'errore, senza peraltro innalzare di un solo watt il tdp del singolo modulo.
Potrebbe sembrare FS, ma credo che con una struttura logica come quella imputata a Bd sia più che possibile e senza le controindicazioni dei processi multith che generalmente sono abbastanza prevedibili limitando le latenze dovute a fetch fault.
Se ho detto una cassanata scusatemi.

In linea teorica potrebbe funzionare.. ma non hai tenuto conto di una cosa: quando le pipeline vanno in prediction fault la vera perdita di tempo sta nel ricercare il dato o il salto che non era stato predetto. Pur avendo due cores INT questa ricerca deve comunque essere effettuata! Una volta trovata una soluzione che tu risolva l'istruzione sul core 0 (con pipelines in stallo) o sul core 1 (totalmente in idle), non cambia molto a parte appunto el latenze.. un po' poco per giustificare un CORE aggiuntivo, non credi? Insomma: il guadagno prestazionale in un'ipotesi di questo tipo sarebbe davvero molto limitato.. a meno che non si ragioni in un'ottica SMT tipo Intel HT, dove una volta che si raggiunge una condizione di stallo lo scheduler "passa la palla" direttamente su un altro thread (il famoso thread "logico") per tenere comunque impegnate le pipelines e le executions durante l'attesa dovuta a cercare il "pezzo mancante".
Effettivamente funzionerebbe un pò meglio in un'ottica "intel HT", "saltando" sul secondo core solamente quando il primo core attende qualcosa e va in stallo. Sarebbe tuttavia estremamente poco efficiente avere un core FISICO chiamato in causa solamente nelle situazioni di fallimento, e quindi con un utilizzo molto distante dal massimo teorico (100%), non credi?

Sarebbe di certo piu' conveniente a livello di ottimizzazione ed utilizzo delle risorse (avendo due veri e propri cores FISICI) creare due threads (permettetemi il gioco di parole) "logici" partendo da un unico "thread fisico"!
Mi spiego: intendo "threads logici" in quanto a partire da un'unico thread "fisico" (il vero e proprio programma "monocore") si dovrebbero creare due percorsi logici di micro-ops da eseguire simultaneamente nei due cores INT.
Ecco che pero' arriviamo alla mia precedente ipotesi, non credi?

[Athlon]

il prediction fault si avvera quando una istruzione condizionale ha un risultato diverso da quello predetto.

Di norma questo avviene all' uscita dai loop , se ho un loop che per 100 volte ha continuato a girare la branch prediction prevedera' che anche alla 101 esecuzione dopo l'istruzione condizionale vennga eseguita una determinata istruzione e quindi manda in pipeline questa istruzione prima ancora che venga completata l'esecuzione dell' istruzione condizionale.

L'idea proposta e' che nel caso di istruzioni condizionali un core int eseguirebe il ramo (true) mentre l'altro il ramo (false) , in questo modo indipendentemente dal risultato della condizionale ci sarebbe comunque un core gia' pronto con i dati correti in pipeline.


A mio parere pero' questa soluzione sebbene permetta di migliorare le performance non e' una risposta intelligente perche' raddoppia il consumo elettrico e perche' impedisce ad un unita' Int di occuparsi di altro ( o di stare spenta in idle)

[Gigamez]

Originariamente inviato da Gigamez

Mi spiego: intendo "threads logici" in quanto a partire da un'unico thread "fisico" (il vero e proprio programma "monocore") si dovrebbero creare due percorsi logici di micro-ops da eseguire simultaneamente nei due cores INT.
Ecco che pero' arriviamo alla mia precedente ipotesi, non credi?

mi quoto per semplificare AL MASSIMO cosa intendo con la mia ipotesi (permettetemi qualche licenza tecnica, hehe):

immaginate una sorta di "SLI/crossfire" tra due unità INT: nel multi GPU, la scena da renderizzare e' la stessa, ma un frame viene dato in pasto alla prima GPU, e durante l'esecuzione di questi calcoli viene dato il frame successivo alla seconda GPU, avvicinandosi ad un guadagno vicino a quello teorico, nel migliore dei casi.
Ora.. immaginate la stessa cosa, ma tra le due unità INT: Il thread da eseguire e' lo stesso, ma una micro-op viene data in pasto alla prima unità INT, e durante l'esecuzione dei calcoli viene data la micro-op successiva alla seconda unità INT. Molto semplice, ma potrebbe anche funzionare, no? Magari si spiegano anche quelle 4 unita' di decode ed il fetch unificato nei moduli..

Tutte ipotesi, ehhhh XD

[Gigamez]

Originariamente inviato da Athlon

il prediction fault si avvera quando una istruzione condizionale ha un risultato diverso da quello predetto.

Di norma questo avviene all' uscita dai loop , se ho un loop che per 100 volte ha continuato a girare la branch prediction prevedera' che anche alla 101 esecuzione dopo l'istruzione condizionale vennga eseguita una determinata istruzione e quindi manda in pipeline questa istruzione prima ancora che venga completata l'esecuzione dell' istruzione condizionale.

L'idea proposta e' che nel caso di istruzioni condizionali un core int eseguirebe il ramo (true) mentre l'altro il ramo (false) , in questo modo indipendentemente dal risultato della condizionale ci sarebbe comunque un core gia' pronto con i dati correti in pipeline.


A mio parere pero' questa soluzione sebbene permetta di migliorare le performance non e' una risposta intelligente perche' raddoppia il consumo elettrico e perche' impedisce ad un unita' Int di occuparsi di altro ( o di stare spenta in idle)

infatti: potrebbe avere senso, ma ricadremmo comunque nel caso di uno spreco di risorse davvero notevole, distanziando di troppo il massimo teorico ottenibile da due cores INT (ovvero il doppio di prestazione sugli interi). Secondo me un'ottica di questo tipo e' quasi inutile e porterebbe infatti piu' svantaggi (consumo e calore maggiori) che vantaggi (limitatissimi al solo caso di appunto fallimento)

[Ares17]

Originariamente inviato da Gigamez

In linea teorica potrebbe funzionare.. ma non hai tenuto conto di una cosa: quando le pipeline vanno in prediction fault la vera perdita di tempo sta nel ricercare il dato o il salto che non era stato predetto. Pur avendo due cores INT questa ricerca deve comunque essere effettuata! Una volta trovata una soluzione che tu risolva l'istruzione sul core 0 (con pipelines in stallo) o sul core 1 (totalmente in idle), non cambia molto a parte appunto el latenze.. un po' poco per giustificare un CORE aggiuntivo, non credi? Insomma: il guadagno prestazionale in un'ipotesi di questo tipo sarebbe davvero molto limitato.. a meno che non si ragioni in un'ottica SMT tipo Intel HT, dove una volta che si raggiunge una condizione di stallo lo scheduler "passa la palla" direttamente su un altro thread (il famoso thread "logico") per tenere comunque impegnate le pipelines e le executions durante l'attesa dovuta a cercare il "pezzo mancante".
Effettivamente funzionerebbe un pò meglio in un'ottica "intel HT", "saltando" sul secondo core solamente quando il primo core attende qualcosa e va in stallo. Sarebbe tuttavia estremamente poco efficiente avere un core FISICO chiamato in causa solamente nelle situazioni di fallimento, e quindi con un utilizzo molto distante dal massimo teorico (100%), non credi?

Sarebbe di certo piu' conveniente a livello di ottimizzazione ed utilizzo delle risorse (avendo due veri e propri cores FISICI) creare due threads (permettetemi il gioco di parole) "logici" partendo da un unico "thread fisico"!
Mi spiego: intendo "threads logici" in quanto a partire da un'unico thread "fisico" (il vero e proprio programma "monocore") si dovrebbero creare due percorsi logici di micro-ops da eseguire simultaneamente nei due cores INT.
Ecco che pero' arriviamo alla mia precedente ipotesi, non credi?

Attenzione tutto quello che ho ipotizzato prima dovrebbe corrispondere ad un + 5-7% sul totale dovuto sopratutto ad un prefech più aggressivo scortato da una bassa latenza ( all'incirca 4 cicli contro i 7, in media) in monoth.
Se ho abbastanza thread da riempire i singoli core questo reverseht non avrebbe luogo, mentre in caso di inattività innalzerebbe l'ipc del singolo th perchè eseguito alternativamente sui due core.
Sul discorso delle micro-ops credo che si avrebbero problemi di latenza nel gestire la cache L1 del singolo core (che anche se in presenza di cache esclusiva porterebbe danno il non utilizzarla)

[Ares17]

Originariamente inviato da Gigamez

infatti: potrebbe avere senso, ma ricadremmo comunque nel caso di uno spreco di risorse davvero notevole, distanziando di troppo il massimo teorico ottenibile da due cores INT (ovvero il doppio di prestazione sugli interi). Secondo me un'ottica di questo tipo e' quasi inutile e porterebbe infatti piu' svantaggi (consumo e calore maggiori) che vantaggi (limitatissimi al solo caso di appunto fallimento)

e se le prediction fault fossero il 30% sul totale?

[Gigamez]

Originariamente inviato da Ares17

Attenzione tutto quello che ho ipotizzato prima dovrebbe corrispondere ad un + 5-7% sul totale dovuto sopratutto ad un prefech più aggressivo scortato da una bassa latenza ( all'incirca 4 cicli contro i 7, in media) in monoth.
Se ho abbastanza thread da riempire i singoli core questo reverseht non avrebbe luogo, mentre in caso di inattività innalzerebbe l'ipc del singolo th perchè eseguito alternativamente sui due core.
Sul discorso delle micro-ops credo che si avrebbero problemi di latenza nel gestire la cache L1 del singolo core (che anche se in presenza di cache esclusiva porterebbe danno il non utilizzarla)

uhm.. allora mi sa che non ho capito bene cosa intendi: praticamente la tua ipotesi si basa su un qualcosa di "misto" ed alternativo tra un SMT ed un vero modulo "dualcore"?
No, perche' se fosse solamente come SMT avresti appunto un guadagno molto piccolo, e se fosse un vero dualcore penso proprio non dovresti avere unita' come fetch e branch prediction in comune..

e se le prediction fault fossero il 30% sul totale?

Teoricamente pensando al solo branch prediction avresti comunque un guadagno prestazionale <= al 30% rispetto alla singola unità int, quindi comunque troppo distante da quello teorico che l'unità aggiuntiva potrebbe darti (100%, appunto). E quando invece hai dei successi? Lasci il secondo core in idle o lo fai comunque lavorare inutilmente per qualcosa che poi non servirà (consumando comunque e producendo calore)? Gli daresti in pasto qualcos'altro quando non ci sono dei "trees" da gestire? in questo caso con quali unità di fetch e decode potresti fare una cosa simile, visto che quelle condivise starebbero gia' lavorando per il primo core? :S

[Ares17]

Originariamente inviato da Gigamez

uhm.. allora mi sa che non ho capito bene cosa intendi: praticamente la tua ipotesi si basa su un qualcosa di "misto" ed alternativo tra un SMT ed un vero modulo "dualcore"?
No, perche' se fosse solamente come SMT avresti appunto un guadagno molto piccolo, e se fosse un vero dualcore penso proprio non dovresti avere unita' come fetch e branch prediction in comune..


Teoricamente pensando al solo branch prediction avresti comunque un guadagno prestazionale <= al 30% rispetto alla singola unità int, quindi comunque troppo distante da quello teorico che l'unità aggiuntiva potrebbe darti (100%, appunto). E quando invece hai dei successi? Lasci il secondo core in idle o lo fai comunque lavorare inutilmente per qualcosa che poi non servirà (consumando comunque e producendo calore)? Gli daresti in pasto qualcos'altro quando non ci sono dei "trees" da gestire? in questo caso con quali unità di fetch e decode potresti fare una cosa simile, visto che quelle condivise starebbero gia' lavorando per il primo core? :S

onestamente preferisco avere un +5% ipc in mono th usando i core alternandoli nei calcoli (solo nel caso il numero di th in esecuzione siano inferiori al numero dei core) con peso 0 watt che +20% di ipc con peso di 5W (non dimentichiamoci che un core int è solo il 12% di un modulo, quindi l'utilizzarlo porta ad al massimo + 8% di W in più, considerando che per la struttura del modulo il singolo core non viene spento e nemmeno rallentato
ma semplicemente lasciato in c1 state)

[Gigamez]

Originariamente inviato da Ares17

onestamente preferisco avere un +5% ipc in mono th usando i core alternandoli nei calcoli (solo nel caso il numero di th in esecuzione siano inferiori al numero dei core) con peso 0 watt che +20% di ipc con peso di 5W (non dimentichiamoci che un core int è solo il 12% di un modulo, quindi l'utilizzarlo porta ad al massimo + 8% di W in più, considerando che per la struttura del modulo il singolo core non viene spento e nemmeno rallentato
ma semplicemente lasciato in c1 state)

vabbe', ma allora perche' fare un core fisico quando usando un SMT si potrebbe avere una prestazione aggiunta a volte anche molto maggiore dell'8% (senza nemmeno avere quel seppur piccolo 8% di consumo in +)?

[Ares17]

Originariamente inviato da Gigamez

vabbe', ma allora perche' fare un core fisico quando usando un SMT si potrebbe avere una prestazione aggiunta a volte anche molto maggiore dell'8% (senza nemmeno avere quel seppur piccolo 8% di consumo in +)?

ecco dove sbagli.
Io non faccio un core fisico in più per avere un 8% in più di ipc.
Io faccio un core in più per avere un thread reale in più, ma che quando questo sta a rigirarsi i pollici lo uso per avere un ipc maggiore del 5-8-20% (quello che sia insomma) prendendolo in prestito.
4 moduli possono essere visti come 8 core reali in ambito multi th o come 4 supercore in ambito single th.
L'SMT di intel dal canto suo utilizza i tempi morti dovuti a codice malamente ottimizzato per poter raddoppiare i th logici.
Per curiosità domani provo a lanciare un cinebench su i7 975 senza smt attivo (con smt on ho 6,02) per vedere la perdita di performance in sua assenza.

[Gigamez]

Originariamente inviato da Ares17

ecco dove sbagli.
Io non faccio un core fisico in più per avere un 8% in più di ipc.
Io faccio un core in più per avere un thread reale in più, ma che quando questo sta a rigirarsi i pollici lo uso per avere un ipc maggiore del 5-8-20% (quello che sia insomma) prendendolo in prestito.
4 moduli possono essere visti come 8 core reali in ambito multi th o come 4 supercore in ambito single th.
L'SMT di intel dal canto suo utilizza i tempi morti dovuti a codice malamente ottimizzato per poter raddoppiare i th logici.
Per curiosità domani provo a lanciare un cinebench su i7 975 senza smt attivo (con smt on ho 6,02) per vedere la perdita di performance in sua assenza.

ecco allora che ho capito cosa intendevi: una sorta di "misto" tra le due cose, appunto.
Ma come faresti a gestire un modulo come 2 cores reali (nel caso tu non debba gestire dei prediction), sapendo di avere moltissime unità condivise tra cui appunto fetch e decode?
Inoltre: ogni volta che avresti una "biforcazione" del tuo programma dovresti gestire simultaneamente le due possibili soluzioni, cosi' come faceva notare Athlon. Sarebbe veramente la cosa piu' ottimizzata, al livello di prestazioni? Non sarebbe allora piu' facile fare come ha fatto Intel, ovvero un modulo con un solo core molto potente in grado di implementare un SMT? avresti sicuramente consumi minori, costi minori, tdp minore ed ottimizzazione delle risorse hardware maggiore!
Secondo me non puo' essere questa l'ipotesi su cui si basa un modulo BD..

[capitan_crasy]

Ho ricevuto una notizia da confermare.
E' sotto esame il nuovo step produttivo di Llano cioè lo step B0 (quello che in pratica ha portato il posticipo a quest'estate); il primo step funzionante di Llano è stato A0....

[Ares17]

Originariamente inviato da Gigamez

ecco allora che ho capito cosa intendevi: una sorta di "misto" tra le due cose, appunto.
Ma come faresti a gestire un modulo come 2 cores reali (nel caso tu non debba gestire dei prediction), sapendo di avere moltissime unità condivise tra cui appunto fetch e decode?
Inoltre: ogni volta che avresti una "biforcazione" del tuo programma dovresti gestire simultaneamente le due possibili soluzioni, cosi' come faceva notare Athlon. Sarebbe veramente la cosa piu' ottimizzata, al livello di prestazioni? Non sarebbe allora piu' facile fare come ha fatto Intel, ovvero un modulo con un solo core molto potente in grado di implementare un SMT? avresti sicuramente consumi minori, costi minori, tdp minore ed ottimizzazione delle risorse hardware maggiore!
Secondo me non puo' essere questa l'ipotesi su cui si basa un modulo BD..

Bd è indirizzato al mercato server (quindi niente smt attivo su intel).
Bd è massimizzato per avere le massime prestazioni in multith.
L'smt di intel occupa diciamo il 3% di superfice in relazione al core.
il 2 core occupa il 12% in relazione al modulo.
Adesso cosa ti faccia pensare che un core + smt sia più efficente in multith di un modulo?
la densita di core per superfice è nettamente a favore di bd e presumibilmente dove SB avrà 8 core reali Bd avrà almeno 6 moduli (ma forse ci sarebbe lo spazio anche per 7)
Il modulo di amd serve ad aumentare la densità dei core.
Tutto il discorso sul reverse HTT sono solo speculazioni e se questo fosse reale sarebbe solo un opzional (che peraltro sarebbe del tutto inutile in ambito server)

[paolo.oliva2]

Originariamente inviato da capitan_crasy

Ho ricevuto una notizia da confermare.
E' sotto esame il nuovo step produttivo di Llano cioè lo step B0 (quello che in pratica ha portato il posticipo a quest'estate); il primo step funzionante di Llano è stato A0....

Mi sa proprio che sia il... low-k.

Se fosse il 32nm liscio, da A0 dovrebbe passare ad A1.
B0, cioè cambiare la lettera iniziale, dovrebbe essere un cambio radicale di trattamento, cioé... dovrebbe equivalere all'introduzione low-k.

(vedi Soi 45nm C2, C3... altro trattamento D0 D1, introduzione low-k E0).

Se proprio non fosse il low-k, comunque dovrebbe essere qualche cosa di importante, visto il posticipo.

[Gigamez]

Originariamente inviato da Ares17

Bd è indirizzato al mercato server (quindi niente smt attivo su intel).
Bd è massimizzato per avere le massime prestazioni in multith.
L'smt di intel occupa diciamo il 3% di superfice in relazione al core.
il 2 core occupa il 12% in relazione al modulo.
Adesso cosa ti faccia pensare che un core + smt sia più efficente in multith di un modulo?
la densita di core per superfice è nettamente a favore di bd e presumibilmente dove SB avrà 8 core reali Bd avrà almeno 6 moduli (ma forse ci sarebbe lo spazio anche per 7)
Il modulo di amd serve ad aumentare la densità dei core.
Tutto il discorso sul reverse HTT sono solo speculazioni e se questo fosse reale sarebbe solo un opzional (che peraltro sarebbe del tutto inutile in ambito server)

uhm.. mi sa che ora sei tu a non aver capito cosa intendo io.. ma te lo spiego bene domani: ora vado a dormire! XD

[paolo.oliva2]

Originariamente inviato da Ares17

Bd è indirizzato al mercato server (quindi niente smt attivo su intel).
Bd è massimizzato per avere le massime prestazioni in multith.
L'smt di intel occupa diciamo il 3% di superfice in relazione al core.
il 2 core occupa il 12% in relazione al modulo.
Adesso cosa ti faccia pensare che un core + smt sia più efficente in multith di un modulo?
la densita di core per superfice è nettamente a favore di bd e presumibilmente dove SB avrà 8 core reali Bd avrà almeno 6 moduli (ma forse ci sarebbe lo spazio anche per 7)
Il modulo di amd serve ad aumentare la densità dei core.
Tutto il discorso sul reverse HTT sono solo speculazioni e se questo fosse reale sarebbe solo un opzional (che peraltro sarebbe del tutto inutile in ambito server)

Quoto.
Il problema di AMD è quello di recuperare IPC nel monocore in desktop.
Nell'ambito server praticamente sarebbe bastato portare un Magny-C sul 32nm per guadagnare quei 0.5-1GHz di clock.

BD diciamo che sarebbe ottimizzato per sfruttare il 32nm sia sul lato clock (con pipeline idonee) che sul lato monocore inteso come IPC.

Inoltre aggiungerei una cosa... da notare che il livello di spegnimento core è inteso a livello di modulo. Quindi viene da sé che coinciderebbe con l'ipotesi di modulo visto come 1 super-core nel caso il modulo non debba servire 2 TH ma 1 TH.

E poi, semplificando, abbiamo visto che il modulo con sia l'INT in più che la FP raddoppiata sono un'ottimizzazione per ridurre la superficie del die ed ottimizzare il TDP/IPC al massimo.
Ma questo non toglie che se il modulo lavora con 1 singolo TH, praticamente avrebbe a quel punto un raddoppio di INT ed una FP doppia.
Il TDP non importerebbe, perché comunque non può arrivare al livello di 2 core che funziano.
Insomma, anche senza complicarci la vita con 2 pipeline simultanee o qualsivoglia, mi pare innegabile che un modulo fatto lavorare con 1 TH sarebbe un super-core.

Oltretutto, riducendo lo spazio a modulo (per 2 core), la potenza del multicore si troverebbe sempre e ugualmente semplicemente perché con meno TDP e con meno spazio a die, aggiungere più moduli risulterebbe comunque cosa facile.

Con questo non è che dico che Gigamez abbia torto... cerco soltanto di semplificare il concetto.