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

[General Blue]

Originariamente inviato da bicchiere

Beh, questa è stata una SCELTA di AMD.

Ha ritenuto conveniente
"Noi abbiamo 8 core e voi no"
rispetto a
"Gli 8 core AMD vanno come i 4 Intel".

Il discorso lo vedrei più come un 8 thread AMD vanno quanto 8 Thread Intel, con il vantaggio di un maggiore resa per quelli AMD rispetto a quelli Hyperthreading Intel e la possibilità di allocare tutte le risorse condivise di un modulo ad un solo thread con incremento dell'ipc.

A livello di marketing e "io ce l'ho più lungo di te" il discorso che fai è giusto, poter dire io ho 8 core e tu no è un grande vantaggio

Non vedo l'ora di scoprire qual'è stato il miglioramento di ipc di bulldozer sul K10...

[xk180j]

a che frequenza pensate possa essere lanciato il top di gamma?

[Uncle Scrooge]

Originariamente inviato da sniperspa

Penso che comunque tutta la circuiteria per permettere la presenza della gpu abbia un consumo...quindi anche con gpu in idle è difficile fare un confronto diretto

Quoto.
Poi llano ha un IPC superiore, ha un controller DDR3 integrato a frequenza maggiore di quello di un athlon, ha il controller PCIe etc... Tutta roba che consuma.

[marchigiano]

Originariamente inviato da Uncle Scrooge

Quoto.
Poi llano ha un IPC superiore, ha un controller DDR3 integrato a frequenza maggiore di quello di un athlon, ha il controller PCIe etc... Tutta roba che consuma.

si ma io ho riportato il consumo dell'intera piattaforma, una 890fx addirittura, con una 880g la differenza sarebbe stata ancora più elevata

tra l'altro con una vga discreta quindi la gpu di llano dovrebbe proprio spegnersi

[dav1deser]

Originariamente inviato da marchigiano

si ma io ho riportato il consumo dell'intera piattaforma, una 890fx addirittura, con una 880g la differenza sarebbe stata ancora più elevata

tra l'altro con una vga discreta quindi la gpu di llano dovrebbe proprio spegnersi

Qui su hwupgrade invece l'A8-3850 consuma meno di un AII X2
http://www.hwupgrade.it/articoli/cpu...desktop_4.html

[calabar]

Originariamente inviato da The3DProgrammer

boh mi sembra che si stia giocando sul significato di un termine + per motivi commerciali che per motivi tecnici.

In che senso, scusa? AMD ha fornito la sua spiegazione tecnica, che possa piacere o meno. Non possiamo dire che non lo è solo perchè non ci piace.

Originariamente inviato da The3DProgrammer

A me la definizione di wikipedia sembra abbastanza chiara.

Ma wikipedia si può considerare tutto tranne una fonte ufficiale ed affidabile.
Non voglio screditare wikipedia, ma per sua stessa natura non può essere presa come fonte di riferimento in casi come questi.

In ogni caso la questione 386 non la riterrei poco valida perchè si tratta di un processore di 20 anni fa: in questo campo spesso le definizioni hanno ragioni storiche, anche quando l'evoluzione tecnologica le ha rese obsolete.

Per ragioni storiche per esempio la fpu è considerata coprocessore, e il conteggio dei core non si basa su di essa ma solo sulle unità di calcolo intere.

Originariamente inviato da The3DProgrammer

EDIT: Riporto un'altra definizione, questa + seria che fa parte delle licenze ibm: [...]

Ciò che questa definizione IBM porta di interessante, è la nota secondo cui una definizione univoca e universalmente accettata di core non esiste.
Del resto, non è neppure tanto facile da dare, viste le continue evoluzioni e differenze architetturali tra processori (non solo x86).

Inoltre IBM specifica che non considera SMT come core anche perchè non è possibile raddoppiare le prestazioni.
Io ho idea che questa affermazione non sia possibile applicarla per BD: laddove lo scheduler non fa da collo di bottiglia, le due unità di calcolo potrebbero portare ad un raddoppio reale di prestazioni (che non è poi così lontano, del resto, dalle percentuali dichiarate da AMD).

Originariamente inviato da The3DProgrammer

credo che lo stesso possa applicarsi alle CPU AMD

Non vedo perchè. I core AMD non mancano di scheduler, semplicemente hanno un'unità condivisa a livello di modulo (più grande e serve due core). Nei processori intel, invece, manca proprio l'unità int.

Mi pare tu stia cercando di trascinare il discorso troppo oltre: che core+smt intel sia un core unico non vi è dubbio (la stessa intel lo dichiara), qui il punto della contesa è se un modulo BD sia dual core.

A mio parere lo è. Lo è perchè AMD lo dichiara tale (e non mi sembra che nessuna industria concorrente finora l'abbia smentito), lo è perchè in base ad una definizione riconosciuta di "core" lo si può definire tale.
A questo punto entrano in gioco solo diverse teorie basate su diversi assiomi. Non essendoci una definizione univoca, non è possibile arrivare ad una conclusione univoca. Difficilmente questa discussione, cioè, potrà avere una conclusione che premia l'una o l'altra teoria.

Originariamente inviato da The3DProgrammer

Detto questo, ripeto: a me dei core cosi come della frequenza e dell'IPC non me ne frega niente, quello che guardo io sono il prezzo, le prestazioni e i consumi.

Perfettamente d'accordo.

Originariamente inviato da General Blue

Il discorso lo vedrei più come un 8 thread AMD vanno quanto 8 Thread Intel, con il vantaggio di un maggiore resa per quelli AMD rispetto a quelli Hyperthreading Intel e la possibilità di allocare tutte le risorse condivise di un modulo ad un solo thread con incremento dell'ipc.

Credo che queste due righe riassumano piuttosto bene il concetto.

[marchigiano]

Originariamente inviato da dav1deser

Qui su hwupgrade invece l'A8-3850 consuma meno di un AII X2
http://www.hwupgrade.it/articoli/cpu...desktop_4.html

perchè la mobo pro4 consuma meno della extreme6 provata da altri siti, ma anche la cf4 consuma più di una 880g

[dav1deser]

Originariamente inviato da marchigiano

perchè la mobo pro4 consuma meno della extreme6 provata da altri siti, ma anche la cf4 consuma più di una 880g

In full la CF4 consuma meno o uguale ad altre schede con 870 o 880G (non a caso l'880G ha tdp di 25W contro i meno di 20 dell'890FX), è in idle che la CF4 consuma di più:
http://www.techradar.com/news/comput...rboards-713409

[The3DProgrammer]

Originariamente inviato da calabar

In che senso, scusa? AMD ha fornito la sua spiegazione tecnica, che possa piacere o meno. Non possiamo dire che non lo è solo perchè non ci piace.

Se vogliamo dare una definizione diversa del termine core rispetto a quella comunemente utilizzata, allora é un altro discorso. Poi però non confrontiamolo con quello intel che non ha senso.

Ma wikipedia si può considerare tutto tranne una fonte ufficiale ed affidabile.
Non voglio screditare wikipedia, ma per sua stessa natura non può essere presa come fonte di riferimento in casi come questi.

In ogni caso la questione 386 non la riterrei poco valida perchè si tratta di un processore di 20 anni fa: in questo campo spesso le definizioni hanno ragioni storiche, anche quando l'evoluzione tecnologica le ha rese obsolete.

Per ragioni storiche per esempio la fpu è considerata coprocessore, e il conteggio dei core non si basa su di essa ma solo sulle unità di calcolo intere.

Potrei concordare sul discorso wikipedia, anche se spesso si rivela essere + affidabile di altre fonti. Ricordo che per quanto ognuno possa scriverci e' costantemente sotto controllo (prova a scrivere una cavolata e vediamo in quanto tempo la rimuovono). Tra l'altro, la definizione é praticamente uguale a quella di IBM. Comunque ho semplicemente messo la prima cosa che ho trovato, quando poi ho identificato una voce + autorevole l'ho aggiunta.
Per il 386, non è un discorso solo di FPU. Un 386 ha un ben definito frontend di fetch/decode, una propria interfaccia al bus, una propria cache. Cosa che un core CMT non ha. A prescidere dall'FPU.

Ciò che questa definizione IBM porta di interessante, è la nota secondo cui una definizione univoca e universalmente accettata di core non esiste.
Del resto, non è neppure tanto facile da dare, viste le continue evoluzioni e differenze architetturali tra processori (non solo x86).

Inoltre IBM specifica che non considera SMT come core anche perchè non è possibile raddoppiare le prestazioni.
Io ho idea che questa affermazione non sia possibile applicarla per BD: laddove lo scheduler non fa da collo di bottiglia, le due unità di calcolo potrebbero portare ad un raddoppio reale di prestazioni (che non è poi così lontano, del resto, dalle percentuali dichiarate da AMD).

Non vedo perchè. I core AMD non mancano di scheduler, semplicemente hanno un'unità condivisa a livello di modulo (più grande e serve due core). Nei processori intel, invece, manca proprio l'unità int.

Eh no. A parte che non vedo come il decode possa non fare da collo di bottiglia visto che é proprio quello, unito alla branch prediction, che determina una buona parte delle performance (altrimenti sarebbe come una GPU -qui faccio un paragone blasfemo solo per rendere l'idea, ovvio che nella realta' non è così-, in grado di processare N istruzioni per ciclo di clock, dove N é il numero di unita' di esecuzione). Gli scheduler ovviamente sono separati, quello che è in comune é l'unita' di decodifica che tra l'altro serve anche lo scheduler FPU. Quindi, se le CPU SMT mancano delle unita' di esecuzione, le CPU CMT mancano completamente del frontend (L1 istruzioni + TLB + logica di branch prediction + decorders). Inoltre l'80% delle performance é probabilmente un estimate del caso migliore, d'altronde ci sono 4 decoder x86 che servono FPU e le 2 unita' int, dubito che possano essere feedate tutte contemporaneamente in caso di necessita'.
Secondo la definizione di IBM quindi, CMT non è un otto core, al pari delle CPU SMT (1. non da un raddoppio delle performance. 2. Manca delle unita' di decode)

Mi pare tu stia cercando di trascinare il discorso troppo oltre: che core+smt intel sia un core unico non vi è dubbio (la stessa intel lo dichiara), qui il punto della contesa è se un modulo BD sia dual core.

A mio parere lo è. Lo è perchè AMD lo dichiara tale (e non mi sembra che nessuna industria concorrente finora l'abbia smentito), lo è perchè in base ad una definizione riconosciuta di "core" lo si può definire tale.
A questo punto entrano in gioco solo diverse teorie basate su diversi assiomi. Non essendoci una definizione univoca, non è possibile arrivare ad una conclusione univoca. Difficilmente questa discussione, cioè, potrà avere una conclusione che premia l'una o l'altra teoria.

Ripeto: se vogliamo dare al termine "core" un significato dal punto di vista tecnico differente da quello che è stata l'accezione comune fino ad oggi, allora siamo d'accordo. Poi AMD puo' chiamarli un po come vuole, la mia opinione è che tale denominazione ha + radici commerciali che tecniche (un po come successe ai tempi del Pentium 4, poter dire "la mia CPU ha + core della tua" puo' rappresentare un vantaggio psicologico sugli utenti meno esperti).

[calabar]

Originariamente inviato da The3DProgrammer

Se vogliamo dare una definizione diversa del termine core rispetto a quella comunemente utilizzata, allora é un altro discorso. Poi però non confrontiamolo con quello intel che non ha senso.

É proprio questo il punto: AMD ha dichiarato gli 8 core perchè, parole loro, si sono basati su quella che è l'accezione più comunque di core.
Ora, non dico di pendere dalle labbra di AMD, ma se non sanno loro qual'è l'accezione più comune...

Originariamente inviato da The3DProgrammer

Eh no. A parte che non vedo come il decode possa non fare da collo di bottiglia visto che é proprio quello, unito alla branch prediction, che determina una buona parte delle performance (altrimenti sarebbe come una GPU -qui faccio un paragone blasfemo solo per rendere l'idea, ovvio che nella realta' non è così-, in grado di processare N istruzioni per ciclo di clock, dove N é il numero di unita' di esecuzione). Gli scheduler ovviamente sono separati, quello che è in comune é l'unita' di decodifica che tra l'altro serve anche lo scheduler FPU. Quindi, se le CPU SMT mancano delle unita' di esecuzione, le CPU CMT mancano completamente del frontend (L1 istruzioni + TLB + logica di branch prediction + decorders). Inoltre l'80% delle performance é probabilmente un estimate del caso migliore, d'altronde ci sono 4 decoder x86 che servono FPU e le 2 unita' int, dubito che possano essere feedate tutte contemporaneamente in caso di necessita'.
Secondo la definizione di IBM quindi, CMT non è un otto core, al pari delle CPU SMT (1. non da un raddoppio delle performance. 2. Manca delle unita' di decode)

Errore mio per lo scheduler. Spero che il concetto fosse chiaro comunque.

Il decoder può fare non fare da collo di bottiglia quando sono le unità di calcolo a soffrire. In un'architettura bilanciata le diverse componenti entrano in crisi in momenti diversi a seconda del tipo di lavoro. Se una di esse entrasse sempre in crisi, allora sarebbe sottodimensionata (a meno che ovviamente le altre non possano essere sovradimensionate con un costo bassissimo).

L'80% delle performance non è il caso migliore, è il caso medio. E non avrebbe avuto senso altrimenti, dato che AMD ha dichiarato tale numero proprio facendo un rapporto tra prestazioni e area (l'incremento dell'area del die non può essere certo considerato un "caso peggiore" ).

Non sono comunque d'accordo con la conclusione. Le unità di decode non mancano, sono solo fuse insieme per garantire maggiore flessibilità. Nella soluzione intel invece l'unità di calcolo manca proprio.

[capitan_crasy]

Originariamente inviato da marchigiano

si ma io ho riportato il consumo dell'intera piattaforma, una 890fx addirittura, con una 880g la differenza sarebbe stata ancora più elevata

tra l'altro con una vga discreta quindi la gpu di llano dovrebbe proprio spegnersi

Non ti entra proprio in testa che una APU NON è una CPU anche con la GPU esclusa...
Comunque sia siamo OT...

[The3DProgrammer]

Originariamente inviato da Níðhöggr

No, affatto. E' una CPU x86. Single core. Eppure non ha FPU. Se lo scheduler condiviso per l'esecuzione FP di Bulldozer rende ogni modulo un core allora il 386 non ha alcun core. Il che e' una boiata.



Questa definizione non ha niente di opposto al fatto che un modulo contenga 2 core.

io ho mai detto che é l'FPU il determinante? No.
Un core per come si é sempre definito è un'unita' INDIPENDENTE, in grado di interpretare ed eseguire istruzioni. Un core BD lo é? No.
Avrei accettato con + tranquillita' la definizione se ci fossero stati 2 core veri e un coprocessore, ma di certo anche in quel caso non mi sarei aspettato poi prestazioni da dual core da una sola FPU.

Errore per lo scheduler. Spero che il concetto fosse chiaro comunque.

Il decoder può fare non fare da collo di bottiglia quando sono le unità di calcolo a soffrire. In un'architettura bilanciata le diverse componenti entrano in crisi in momenti diversi a seconda del tipo di lavoro. Se una di esse entrasse sempre in crisi, allora sarebbe sottodimensionata (a meno che ovviamente le altre non possano essere sovradimensionate con un costo bassissimo).

Nell'ISA x86 gran parte del tempo é preso dalla branch prediction, dal decode
e dalle penalty da branch misprediction. Penso sia assolutamente poco probabile che sia l'unita' di decode ad aspettare le ALU, anche perchè lo scheduler ha una coda abbastanza capiente. Posso portarti un esempio a conferma di questo, che é BD. Hanno estremamente potenziato la logica di decode, tagliando di fatto una ALU e una AGU per core.

L'80% delle performance non è il caso migliore, è il caso medio. E non avrebbe avuto senso altrimenti, dato che AMD ha dichiarato tale numero proprio facendo un rapporto tra prestazioni e area (l'incremento dell'area del die non può essere certo considerato un "caso peggiore" ).

AMD ha dichiarato l'80% di performance su una percentuale X di area del die, rispetto a due core veri (X mi pare fosse il 12 o 15, nn ricordo). Quando parlavo di caso migliore non mi riferivo certo all'area del die, ma alle prestazioni massime ottenibili tramite CMT, che secondo me sono esattamente quell'80% di cui parla AMD. In realta' io mi aspetto che il guadagno di performance dovuto a CMT sia abbastanza + basso dell'80% e non credo arrivera' mai al 100%.

Non sono comunque d'accordo con la conclusione. Le unità di decode non mancano, sono solo fuse insieme per garantire maggiore flessibilità. Nella soluzione intel invece l'unità di calcolo manca proprio.

Da quello che ho letto, i decoder possono decodificare nel caso migliore (una finestra di fetch da 32 byte) un massimo di 4 istruzioni per ciclo di clock, per core. Il che significa che entrambi i core non possono essere serviti allo stesso momento (non é chiaro cosa succede se si decodificano finestre da 16 byte, in quel caso non si sa se é possibile decodificarne 2 per avere comunque il throughput massimo di 4 istruzioni per ciclo di clock e servire contemporaneamente le 2 unita' di esecuzione, in ogni caso anche in questa situazione il throughput sarebbe la meta' comunque per core rispetto a 2 unita' di decode separate). Morale della favola: non ha senso parlare di 2 unita' fuse insieme se poi non si possono servire le 2 unita' di esecuzione in parallelo.

[calabar]

Originariamente inviato da The3DProgrammer

Posso portarti un esempio a conferma di questo, che é BD. Hanno estremamente potenziato la logica di decode, tagliando di fatto una ALU e una AGU per core.

Ma è appunto di BD che stiamo parlando!

Se l'architettura è equilibrata, allora non sarà sempre il decoder a fare da collo di bottiglia. Altrimenti avrebbero fatto un decoder più potente, dato che questo avrebbe fatto aumentare immediatamente le prestazioni (che è appunto quello che succede eliminando un collo di bottiglia).

Originariamente inviato da The3DProgrammer

AMD ha dichiarato l'80% di performance su una percentuale X di area del die, rispetto a due core veri (X mi pare fosse il 12 o 15, nn ricordo). Quando parlavo di caso migliore non mi riferivo certo all'area del die, ma alle prestazioni massime ottenibili tramite CMT, che secondo me sono esattamente quell'80% di cui parla AMD. In realta' io mi aspetto che il guadagno di performance dovuto a CMT sia abbastanza + basso dell'80% e non credo arrivera' mai al 100%.

Credo tu non abbia capito quello che intendevo.
Quando AMD ha parlato del famoso 80%, lo ha fatto nel confrontare il miglioramento prestazionale rispetto all'area "spesa" per aggiungere un core reale nel modulo.
Che senso avrebbe avuto confrontare una misura statica come l'area in più con una variabile e incompleta come un valore di picco riferito alle prestazioni?
Comunque secondo me in certi casi si potrà arrivare al 100%: le unità di calcolo ci sono.

Originariamente inviato da The3DProgrammer

Da quello che ho letto, i decoder possono decodificare nel caso migliore (una finestra di fetch da 32 byte) un massimo di 4 istruzioni per ciclo di clock, per core. Il che significa che entrambi i core non possono essere serviti allo stesso momento (non é chiaro cosa succede se si decodificano finestre da 16 byte, in quel caso non si sa se é possibile decodificarne 2 per avere comunque il throughput massimo di 4 istruzioni per ciclo di clock e servire contemporaneamente le 2 unita' di esecuzione, in ogni caso anche in questa situazione il throughput sarebbe la meta' comunque per core rispetto a 2 unita' di decode separate). Morale della favola: non ha senso parlare di 2 unita' fuse insieme se poi non si possono servire le 2 unita' di esecuzione in parallelo.

Forse sono io poco informato, ma da dove salta fuori che i due core non possono essere serviti insieme?

k10 poteva servire fino a 3 istruzioni su un core. BD fino a 4 per un modulo.
Il decoder è quindi potenziato (4 istruzioni anzichè 3), e in più ha una maggiore flessibilità.
Ovviamente andrebbe a perdere rispetto a quello del k10 nel momento in cui per esempio entrambi i core "richiedessero" 3 istruzioni (in quel caso due core k10 riceverebbero sei istruzioni, mentre i due core BD solo 4).
Ma se hanno fatto un decoder da 4 istruzioni anzichè da 6, evidentemente hanno stimato che quei casi sono abbastanza rari da non valerne la pena.
Inoltre, qualora un core lavorasse a basso regime, l'altro avrebbe a disposizione tutte e 4 le istruzioni, cosa che il k10 non poteva avere.

[gidan82]

Chissà se in prestazioni supererà intel questa volta...

[Vash_85]

Originariamente inviato da gidan82

Chissà se in prestazioni supererà intel questa volta...

Questa è una domanda che nessuno si era mai posto fino ad ora.....

[The3DProgrammer]

Originariamente inviato da calabar

Ma è appunto di BD che stiamo parlando!

Se l'architettura è equilibrata, allora non sarà sempre il decoder a fare da collo di bottiglia. Altrimenti avrebbero fatto un decoder più potente, dato che questo avrebbe fatto aumentare immediatamente le prestazioni (che è appunto quello che succede eliminando un collo di bottiglia).


Credo tu non abbia capito quello che intendevo.
Quando AMD ha parlato del famoso 80%, lo ha fatto nel confrontare il miglioramento prestazionale rispetto all'area "spesa" per aggiungere un core reale nel modulo.
Che senso avrebbe avuto confrontare una misura statica come l'area in più con una variabile e incompleta come un valore di picco riferito alle prestazioni?
Comunque secondo me in certi casi si potrà arrivare al 100%: le unità di calcolo ci sono.


Forse sono io poco informato, ma da dove salta fuori che i due core non possono essere serviti insieme?

k10 poteva servire fino a 3 istruzioni su un core. BD fino a 4 per un modulo.
Il decoder è quindi potenziato (4 istruzioni anzichè 3), e in più ha una maggiore flessibilità.
Ovviamente andrebbe a perdere rispetto a quello del k10 nel momento in cui per esempio entrambi i core "richiedessero" 3 istruzioni (in quel caso due core k10 riceverebbero sei istruzioni, mentre i due core BD solo 4).
Ma se hanno fatto un decoder da 4 istruzioni anzichè da 6, evidentemente hanno stimato che quei casi sono abbastanza rari da non valerne la pena.
Inoltre, qualora un core lavorasse a basso regime, l'altro avrebbe a disposizione tutte e 4 le istruzioni, cosa che il k10 non poteva avere.

no aspe..ora cosa c'entra k10?

Per il decode:

When stars align (instruction allocation is optimized and the code has pre-decode information), the frontend can decode up to 4 macro-ops from a 32-byte window per cycle for one core. Otherwise, a 16-byte window is scanned to find the boundaries for supposedly < 4 decodes per cycle. It is unclear whether in such cases one 16-byte window can be scanned for each core, thus still maintaining 32-byte decode (for both cores) per cycle. Note that it takes at least 2x time to scan a instruction window twice as large, but two instruction windows of same size can always be scanned concurrently by parallel resources, if available.

http://abinstein.blogspot.com/2011/0...bulldozer.html

é uno dei post + dettagliati che ho letto sull'architettura BD

[marchigiano]

Originariamente inviato da dav1deser

In full la CF4 consuma meno o uguale ad altre schede con 870 o 880G (non a caso l'880G ha tdp di 25W contro i meno di 20 dell'890FX), è in idle che la CF4 consuma di più:
http://www.techradar.com/news/comput...rboards-713409

il tdp si riferisce alla igp attiva, se la spegni consuma meno, senza contare le fasi molto più potenti che di solito mettono sui chipset fx

http://www.xbitlabs.com/images/mainb...xe/power-1.png
http://www.xbitlabs.com/images/cpu/p...20/power-1.png

questi sono test a valle dell'ali misurando la corrente sul jack della mobo quindi escludendo altri consumi

nel primo caso una 880g con igp attiva, nel secondo una cf4 con hd6970 (ma ripeto non tenuta in considerazione visto il tipo di misura). quindi con una discreta la 880g consumerebbe pure meno

Originariamente inviato da capitan_crasy

Non ti entra proprio in testa che una APU NON è una CPU anche con la GPU esclusa...

ok d'ora in poi la paragonerò a un frigorifero

[capitan_crasy]

Originariamente inviato da marchigiano

ok d'ora in poi la paragonerò a un frigorifero

Problema tuo, ma la prossima volta sull'altro thread...

[Gigamez]

Originariamente inviato da The3DProgrammer

Da quello che ho letto, i decoder possono decodificare nel caso migliore (una finestra di fetch da 32 byte) un massimo di 4 istruzioni per ciclo di clock, per core. Il che significa che entrambi i core non possono essere serviti allo stesso momento (non é chiaro cosa succede se si decodificano finestre da 16 byte, in quel caso non si sa se é possibile decodificarne 2 per avere comunque il throughput massimo di 4 istruzioni per ciclo di clock e servire contemporaneamente le 2 unita' di esecuzione, in ogni caso anche in questa situazione il throughput sarebbe la meta' comunque per core rispetto a 2 unita' di decode separate). Morale della favola: non ha senso parlare di 2 unita' fuse insieme se poi non si possono servire le 2 unita' di esecuzione in parallelo.

quoto, e sono totalmente d'accordo.

[Gigamez]

Originariamente inviato da calabar

k10 poteva servire fino a 3 istruzioni su un core. BD fino a 4 per un modulo.
Il decoder è quindi potenziato (4 istruzioni anzichè 3), e in più ha una maggiore flessibilità.
Ovviamente andrebbe a perdere rispetto a quello del k10 nel momento in cui per esempio entrambi i core "richiedessero" 3 istruzioni (in quel caso due core k10 riceverebbero sei istruzioni, mentre i due core BD solo 4).
Ma se hanno fatto un decoder da 4 istruzioni anzichè da 6, evidentemente hanno stimato che quei casi sono abbastanza rari da non valerne la pena.
Inoltre, qualora un core lavorasse a basso regime, l'altro avrebbe a disposizione tutte e 4 le istruzioni, cosa che il k10 non poteva avere.

Dico la mia:
Le unità di fetch e di decode sono unificate nel modulo, ed essendo tali, per quanto estremamente potenziate, non possono servire nello stesso istante le due unità intere in maniera indipendente. Per dire: se il fetcher fosse in grado di accedere nello stesso istante a due diverse celle di memoria ed a più registri del processore, di fatto sarebbe un fetcher "doppio" e non singolo, no?
E' un po' come se un pullman molto grosso, magari anche piu' capiente di due piccoli pullman messi insieme, voglia arrivare in due mete diverse nello stesso istante: è impossibile!

Leggendo queste vostre impressioni, mi ritornano in mente le ipotesi che avevamo fatto riguardanti il reverse hyperthreading (annunciato anni fa da AMD stessa).

Immaginiamo l'ipotesi che nel k10 molte risorse andavano sprecate, in quanto servivano solamente in rari casi. Poniamo ad esempio il fatto che l'esecuzione simultanea di 3 macro istruzioni per unità intera sia un caso molto raro: come faccio ad ottimizzare il tutto?
Partendo dal dato di fatto che in BD la instruction-cache è UNIFICATA nel modulo (una cosa particolare, non credete?), non potrebbe essere che le due unità intere (più piccole, ma adatte al caso medio di esecuzione) vengano utilizzate in modalità di interleaving alternato.. su un unico thread "fetchato" e decodificato per entrambe?

So che probabilmente è fantascienza, ma nn riesco a togliermi dalla testa questa fantasiosa ipotesi! XD

d'altra parte mi viene difficile pensare che in caso contrario le unità intere siano totalmente indipendenti.
Il modulo BD condivide tantissime cose.. anzi, penso sia molto più vicino ad un core "classico" con doppie unità intere, piuttosto che ad un dual core con unità FPU condivisa.

Come sarebbe possibile rendere totalmente indipendenti 2 thread all'interno di un singolo modulo, vista la consivisione del fetcher e del decoder?
Parere mio, ma le due improbabili possibilità sarebbero:
a) Il fetch ed il decode devono avere frequenza doppia rispetto a quella delle unità intere, in modo da poterle servire, non contemporaneamente, ma adeguatamente ed in maniera indipendente. Questa ipotesi, onestamente, mi sembra totalmente impossibile, anche perche' non sarebbe servito potenziarli in termini di generazione di micro-ops, ma semmai snellirli in modo da farli lavorare più velocemente per meno micro-ops. (senza contare che gli accessi alla memoria da parte del fetcher devono essere di velocità doppia!)
b) Le unità intere devono essere delle unità moooolto "modeste", in grado di eseguire molti meno calcoli rispetto ai classici core del k10, o magari micro-operazioni molto più semplici (?). Ma se fosse cosi', dove sarebbe il guadagno di IPC in ST (dichiarato ufficialmente da AMD)? ..e soprattutto, dove sarebbe il risparmio di TDP e di silicio, se poi le prestazioni sarebbero probabilmente di molto minori?

Onestamente dal basso della mia ingoranza, tutta questa storia della condivisione all'interno del modulo mi puzza, e non poco..

bisogna ascoltare il parere dell'esperto bjt2 per chiarire ogni nostro dubbio al riguardo, secondo me!

Non nascondo come però mi piaccia immaginare lo screen di CPU-z delle versioni definitive con scritto: N. core 8; N. thread... 4 !!! XD