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

[cionci]

Originariamente inviato da paolo.oliva2

Non mi torna... All'ora per te quell'INT in più che ci fosse o meno sarebbe uguale.

E perché ? Non capisco cosa intendi. A livello di singolo thread uno dei due core INT è come se non esistesse. Con due thread un core INT processa un thread e un altro core INT processa un secondo thread. Se non ci fosse come potrebbe processare il secondo thread ?

[Gigamez]

Originariamente inviato da Athlon

Le risorse condivise nel modulo derivano dalla teoria della coda unica , cioe' e' piu' efficiente utilizzare delle risorse condivise rispetto ad una duplicazione totale delle unita'.


Se un core INT ha bisogno ad esempio di 3 unita' decode quando metto 2 core INT non ho bisogno del doppio delle unita' decode perche' statisticamente e' molto imporbabile che entrambi i core abbiano bisogno contemporaneamente di tutte le potenzialita' della sezione decode , quindi se con un core INT ho 3 unita' quando ho 2 core INT 5 unita' decode possono svolgere tranqullamente il lavoro.


L'accorpamento in moduli permette appunto di sharare tra due core INT molte unita' senza ricorrere al raddoppio secco , risparmiando cosi' silicio e energia

beh si.. e' sicuramente tutto vero per quanto riguarda il risparmio di silicio e di energia.. ma per quanto riguarda le prestazioni, se cosi' fosse, dove sarebbe l'aumento di IPC? Vedendo i grafici architetturali si potrebbe supporre addirittura un ipc inferiore per core rispetto al k10! Figuriamoci un BDx8 (4moduli) cosi' strutturato quante ne prenderebbe sempre e comunque rispetto ad un SB x10!!! Sarebbe una situazione catastroficamente impari, talmente drammatica che quella attuale sarebbe fantastica, in confronto!
Ci DEVE essere qualcos'altro sotto, ne sono convinto.
Conta poi che se avessi un fetch e ed un decode "comune" tra i due core ma in grado di "servire" entrambi i cores contemporaneamente avresti da gestire gli indirizzi ed i threads in maniera separata, il che vorrebbe dire avere una complessita' architetturale ed algoritmica notevole. Non sarebbe allora piu' facile (a livello di implementazione) fare un singolo core con un unico scheduler ma con 2 unita' intere a cui smistare alternativamente le micro-ops, per poi mettere tutto insieme in un'unica retire-unit? Si avrebbe IL DOPPIO di prestazione intera in mono-th, si avrebbe una superficie del modulo ancora piu' piccola (sarebbe praticamente tutto condiviso), e quindi si potrebbe senza problemi fare ALMENO un 6 moduli desktop, no?
Non mi quadra: c'e' assolutamente qualcosa che non va nelle info che abbiamo, secondo me.

Originariamente inviato da cionci

Abbiamo però due int scheduler e questo fa capire che i due core non possono eseguire lo stesso thread. Altrimenti lo scheduler avrebbe dovuto essere uno solo. A quel punto di fatto si sarebbe semplicemente avuta una sola ALU SMT con il doppio delle unità di calcolo.

beh, sugli scheduler hai ragione, cosi' come le retire che anch'esse sono separate (come avevo gia' notato)..

vabbe' tutta questa nuova architettura "solamente" (si fa per dire, eh..) per risparmiare silicio e rischiare di avere prestazioni addirittura peggiori del k10 in monocore? bah, vedremo..

Io rimango della duplice teoria che o AMD confrontera' core vs modulo (prendendole ancora di piu' in mono-TH ma rischiando di essere forse leggermente superiore in multi), oppure ogni modulo sara' di fatto un core con una doppia unita' int operativa in grado quindi di processare un solo thread alla volta (potendo virtualmente essere superiore in ogni ambito), oppure.. se non fosse nessuno dei due casi praticamente avrebbe gia' virtualmente perso in partenza, in ogni ambito prestazionale, secondo me. Visto che non penso che i loro progettisti siano assolutamente degli sprovveduti, deve sicuramente esserci qualcosa sotto.

ok, mi zittisco qui.
vedremo..

[cionci]

Originariamente inviato da Gigamez

vabbe' tutta questa nuova architettura "solamente" (si fa per dire, eh..) per risparmiare silicio e rischiare di avere prestazioni addirittura peggiori del k10 in monocore? bah, vedremo..

Come farebbero ad essere peggiori con 400-600 Mhz in più a parità di processo produttivo e TDP ?

[calabar]

Originariamente inviato da Gigamez

vabbe' tutta questa nuova architettura "solamente" (si fa per dire, eh..) per risparmiare silicio e rischiare di avere prestazioni addirittura peggiori del k10 in monocore? bah, vedremo..

Secondo quanto emerso finora, dovrebbero essere superiori anche senza considerare la differenza di frequenza, perchè nonostante la condivisione, le migliorie architetturali ci sono e sono evidenti.

Se poi come ipotizzato BD dovesse usare, nel caso di pochi thread (intendendo per pochi, non più del numero dei moduli) ogni modulo per processare un singolo thread, allora anche il problema del mono-thread non sussisterebbe, dato che ogni core non dovrebbe condividere più le risorse del modulo ma averle tutte a disposizione (oltretutto sovrabbondanti, dato che pensate per gestire due core int).

[Gigamez]

Originariamente inviato da cionci

Come farebbero ad essere peggiori con 400-600 Mhz in più a parità di processo produttivo e TDP ?

non saprei, davvero.. Progettare una architettura nuova partendo da zero non è uno scherzo: servono risorse, SOLDI, tempo (amd ci lavora da tanti anni a bulldozer). Tutto cio' per avere una architettura potenzialmente con MENO ipc della precedente (a parità di clock) che pero' "recupera" un po' per quei 600Mhz in piu'?

Bd 4Moduli (8cores) Vs SB 10 Cores + ht?
Sinceramente spero davvero non sia cosi', altrimenti vorrebbe dire senza ombra di dubbio che AMD si sarebbe definitivamente rassegnata ad essere eterna seconda (e che perde pure terreno di generazione in generazione) per quello che riguarda la battaglia prestazionale con Intel..

[Ares17]

Originariamente inviato da Gigamez

:S mi sa che nessuno dei due sta capendo quello che dice l'altro..
Le differenze tra SMT e Reverse Hyperthreading le conosco bene, tant'e' che se leggi vari post addietro vedrai che addirittura ne parlai in lungo ed in largo.

Il mio era semplicemente un discorso ipotetico di come poter fare ad aumentare la capacità di calcolo Intera in single-TH avendo a disposizione una architettura simile a quella che circola nelle varie figure relative a bulldozer.
Basandomi su cio' che amd disse e soprattutto basandomi sulle figure che abbiamo visto ho semplicemente espresso una teoria. Non ho mai detto che sara' sicuramente cosi', ma secondo me potrebbe essere una soluzione davvero interessante, tutto qui.

Io pero' vorrei capire come secondo te (e secondo la tua rispettabilissima teoria) in una architettura modulare quale quella di BD verrebbero gestite in maneira separata per le due unità int le fasi di fetch e decode, basandoti sui disegni architetturali che circolano relativi a BD. Vorrei inoltre capire sempre secondo la tua teoria un'approssimazione dei vantaggi prestazionali che ci sarebbero (oltre ovviamente al silicio "risparmiato"). Secondo te l'ipc in mono-th sarebbe davvero superiore anche solo rispetto a quello del K10?

concordo in pieno comunque con il tuo ragionamento sull'area del silicio. Ma io non stavo mettendo in dubbio nulla di cio'! Capisci che o AMD ci mette davvero il doppio dei cores (cores Intel con SMT Vs. Modulo BD), oppure sarebbe una partita (prestazionalmente parlando) gia' persa in partenza? ..E se fosse cosi', allora perche' la mia ipotesi di un core con una doppia INT unit gestita alternativamente per lo stesso thread sarebbe cosi' impossibile? (visto ceh ripeto, abbiamo UN SOLO FETCH ed un solo DECODE unificato per i due core nello stesso modulo?)

Partendo dal presupposto che l'ipc su singolo core sia almeno uguale a quello del k10 (ma come spiegato da bjt2 dovrebbe essere superiore) la mia ipotesi non è basata su come aumentare l'ipc potendo processare più dati contemporaneamente, semplicemente ipotizzo la possibilità di poter traslare l'indirizzo logico sul core inattivo nel momento che il core che stia eseguendo il th abbia bisogno di svuotare le pipeline e la cache l1 in caso di salto di codice errato.
Praticamente il thread rimane sempre uno solo e dato che Fech e Decode possono accedere indistintamente ad una qualsiasi delle due int passare i dati da elaborare all'unità che sta a spasso senza attendere che scuoti la cache e le pipeline, di conseguenza si ridurrebbero i cicli a vuoto in alcune condizioni.
Che questo possa essere realizzabile (come spero) o che tipo di incremento porti in single th (1, oppure il 20%) non importa, nel caso fosse possibile si risparmierebbe comunque sui cicli a vuoto aumentando i cicli utili e di conseguenza l'ipc.

[Ares17]

Originariamente inviato da Gigamez

non saprei, davvero.. Progettare una architettura nuova partendo da zero non è uno scherzo: servono risorse, SOLDI, tempo (amd ci lavora da tanti anni a bulldozer). Tutto cio' per avere una architettura potenzialmente con MENO ipc della precedente (a parità di clock) che pero' "recupera" un po' per quei 600Mhz in piu'?

Bd 4Moduli (8cores) Vs SB 10 Cores + ht?
Sinceramente spero davvero non sia cosi', altrimenti vorrebbe dire senza ombra di dubbio che AMD si sarebbe definitivamente rassegnata ad essere eterna seconda (e che perde pure terreno di generazione in generazione) per quello che riguarda la battaglia prestazionale con Intel..

Credo che AMD abbia maggior possibilità di produrre per prima un 8 moduli che intel un decacore.

[cionci]

Originariamente inviato da Gigamez

non saprei, davvero.. Progettare una architettura nuova partendo da zero non è uno scherzo: servono risorse, SOLDI, tempo (amd ci lavora da tanti anni a bulldozer). Tutto cio' per avere una architettura potenzialmente con MENO ipc della precedente (a parità di clock) che pero' "recupera" un po' per quei 600Mhz in piu'?

L'IPC non è il solo parametro per valutare le prestazioni, ma conta anche la frequenza a parità di TDP. Fermo restando che credo che l'IPC sarà maggiore.

[Ares17]

Originariamente inviato da cionci

L'IPC non è il solo parametro per valutare le prestazioni, ma conta anche la frequenza a parità di TDP. Fermo restando che credo che l'IPC sarà maggiore.

Protremmo parlare di IPS per la valutazione prestazionale ed IPC per valutare l'efficenza architetturale (anche se quest'ultima andrebbe misurata in gflop/watt)

[cionci]

Originariamente inviato da Ares17

Partendo dal presupposto che l'ipc su singolo core sia almeno uguale a quello del k10 (ma come spiegato da bjt2 dovrebbe essere superiore) la mia ipotesi non è basata su come aumentare l'ipc potendo processare più dati contemporaneamente, semplicemente ipotizzo la possibilità di poter traslare l'indirizzo logico sul core inattivo nel momento che il core che stia eseguendo il th abbia bisogno di svuotare le pipeline e la cache l1 in caso di salto di codice errato.
Praticamente il thread rimane sempre uno solo e dato che Fech e Decode possono accedere indistintamente ad una qualsiasi delle due int passare i dati da elaborare all'unità che sta a spasso senza attendere che scuoti la cache e le pipeline, di conseguenza si ridurrebbero i cicli a vuoto in alcune condizioni.
Che questo possa essere realizzabile (come spero) o che tipo di incremento porti in single th (1, oppure il 20%) non importa, nel caso fosse possibile si risparmierebbe comunque sui cicli a vuoto aumentando i cicli utili e di conseguenza l'ipc.

Questo credo che si possa fare senza problemi, ma non capisco quali vantaggi possa portare iniziare a processare le nuove istruzioni sul core libero o su quello appena stallato. La cache dL1 deve comunque ricaricare i dati, visto che non è condivisa. La pipeline stallata implica alcuni cicli di attesa prima della terminazione della prima istruzione del nuovo ramo, ma comporterebbe la stessa identica attesa sull'altro core.
L'unica operazione da fare in più sarebbe quella di invalidare la dL1, ma non mi sembra un così grande spreco. Dopo tutto ci sarà un circuito per invalidare tutti i bit V contemporaneamente.

[Gigamez]

Originariamente inviato da calabar

Secondo quanto emerso finora, dovrebbero essere superiori anche senza considerare la differenza di frequenza, perchè nonostante la condivisione, le migliorie architetturali ci sono e sono evidenti.

Se poi come ipotizzato BD dovesse usare, nel caso di pochi thread (intendendo per pochi, non più del numero dei moduli) ogni modulo per processare un singolo thread, allora anche il problema del mono-thread non sussisterebbe, dato che ogni core non dovrebbe condividere più le risorse del modulo ma averle tutte a disposizione (oltretutto sovrabbondanti, dato che pensate per gestire due core int).

si ma nel caso usasse un modulo (quindi 2 cores) per processare un SINGOLO thread.. si tratterebbe di un qualcosa paragonabile proprio ad un reverse Hyperthreading!!!.. ed e' quello che sto cercando di dire da 12 post a questa parte! XD
Poi che lo faccia usando il secondo core per calcolarsi i branch, che lo faccia secondo uno schema "simil-SLI" o che lo faccia secondo qualunque altra tecnica al livello sostanziale non cambia la storia (ed e' qui che volevo arrivare.. il resto erano solo ipotesi riguardanti il fatto di come sarebbe stato meglio prestazionalmente parlando gestire un reverse-HT).

AMD deve avere qualcosa in serbo, questo e' sicuro! La architettura cosi' come e' stata presentata fino ad ora da sola non sembrerebbe prestazionalmente parlando nulla di rilevante, eppure Intel sta addirittura avendo un certo timore e cerca di anticipare i 22nm, annunciando gia' un SB x10.
C'e' sicuramente qualcosa di piu': LARGO ALLE IPOTESI!

Ora ritorno con le mie domande (e lasciate perdere le ipotesi che fino ad ora ho fatto estendendo questa possibilità). Un reverse-HT come risposta prestazionale si tratterebbe di fantascienza? Se cosi' non fosse come si potrebbe immaginare una implementazione di reverse-HT partendo da una architettura modulare di questo tipo? quale sarebbe secondo voi la modalità piu' efficiente da ogni punto di vista (prestazione, silicio, consumi)?

Fin'ora ho solo espresso appunto la mia personale ipotesi (basata appunto sulla ripartizione alternata delle micro-ops sui due moduli INT) riguardo a quella che sarebbe a mio parere l'implementazione migliore per un reverse-HT, tutto qui!
I discorsi sull'SMT e sul silicio sono tutti giusti, ma molto poco inerenti rispetto a quello di cui stavo parlando, ovvero quale sia il "possibile segreto" che AMD sta celando dietro a tutto cio'.. :S (e qualcosa deve esserci per forza)

O.T. Azz, non solo non ho rispettato la mia promessa del post precedente, ma mi sa che sto scrivendo pure troppo

[Ares17]

Originariamente inviato da cionci

Questo credo che si possa fare senza problemi, ma non capisco quali vantaggi possa portare iniziare a processare le nuove istruzioni sul core libero o su quello appena stallato. La cache dL1 deve comunque ricaricare i dati, visto che non è condivisa. La pipeline stallata implica alcuni cicli di attesa prima della terminazione della prima istruzione del nuovo ramo, ma comporterebbe la stessa identica attesa sull'altro core.
L'unica operazione da fare in più sarebbe quella di invalidare la dL1, ma non mi sembra un così grande spreco. Dopo tutto ci sarà un circuito per invalidare tutti i bit V contemporaneamente.

Ho scritto che non so che tipo di guadagno ci possa essere, ma essendo la cache esclusiva l'unità accederebbe direttamente alla l2.
La l1 data con il core in idle dovrebbe gia essere vuota.
Se tutta questa manovra porterebbe ad abbassare il peso di un prefetch fault da 20 a 19 cicli non credi che sia tutto grasso che cola?

[calabar]

Originariamente inviato da Gigamez

si ma nel caso usasse un modulo (quindi 2 cores) per processare un SINGOLO thread.. si tratterebbe di un qualcosa paragonabile proprio ad un reverse Hyperthreading!!!.. ed e' quello che sto cercando di dire da 12 post a questa parte! XD

Oddio... per me quanto emerso finora per BD promette molto bene, altro che "prestazionalmente parlando nulla di rilevante".

Ma tornando al discorso del "reverse HT", anche io qualche tempo fa mi ero chiesto se il modulo fosse in grado di usare le "alu" (in senso generale) di entrambe le unità int per generare un "super core" da 8 alu (le 4 del primo core int e le 4 del secondo core int).
La risposta era stata abbastanza precisa: inutile fare un core con millemila alu, perchè statisticamente se ne sfruttano insieme al più 3 o 4.

Scartiamo quindi l'ipotesi del "supercore", scartiamo quella dello "sli", dato che nelle GPU il codice è altamente parallelo mentre quello di un'elaborazione monothread no, scartiamo l'ipotesi dell'uso del secondo core in caso di predizione sbagliata per quanto elencato da Cionci qui sopra.

Morale della favola: se il codice è poco parallelizzabile, c'è poco da fare: aggiungere potenza bruta non aiuta, ma bisogna muoversi in altre direzioni.

[paolo.oliva2]

Originariamente inviato da cionci

E perché ? Non capisco cosa intendi. A livello di singolo thread uno dei due core INT è come se non esistesse.

Scusa... sarò duro ma non capisco.

1 core = 1 INT (ottica Phenom II)

Modulo = 2 core = 3 INT (BD).

Mi sembra chiaro che non sto parlando dell'INT dedicato esclusivamente all'altro core, ma dell'INT condiviso.

Con due thread un core INT processa un thread e un altro core INT processa un secondo thread. Se non ci fosse come potrebbe processare il secondo thread ?

E il 3° INT, il modulo processa 3 TH?

Quindi se riporti "A livello di singolo thread uno dei due core INT è come se non esistesse" è la stessa cosa che a livello di 2TH il 3° INT è come se non esistesse.

Se con 2 TH il 3° INT viene usato (altrimenti cosa le metterebbero a fare?) non capisco la diffrerenza.
Con la stessa logica con la quale in base a 2 TH viene usato il 3° INT, non vedo il perché con 1 TH dovrebbe essere usato solo 1 INT e non utilizzato l'INT condiviso...

Rifacendomi a quanto postato da Bjt2, il 3° INT dovrebbe essere sfruttato sia che il modulo sia con 1 TH che con 2 TH (come posta Bjt2, infatti, le operazioni eseguite a parità di clock sarebbero superiori sia nei confronti di un Phenom II che nei confronti dell'i7).
Se il 3° incrementa la velocità di esecuzione, tale incremento lo si avrebbe maggiore in modalità 1 TH, perché con 2 TH sarebbe condiviso e potrebbe essere "occupato".

[cionci]

Originariamente inviato da paolo.oliva2

E il 3° INT, mica ha 3 TH.

3° ? Quale ?

[paolo.oliva2]

Originariamente inviato da cionci

3° ? Quale ?

Il Modulo BD ha 3 INT?

1 per core (esclusivo) = 2 core = 2 INT

+ un 3° INT condiviso.

[cionci]

Originariamente inviato da paolo.oliva2

Il Modulo BD ha 3 INT?

1 per core (esclusivo) = 2 core = 2 INT

+ un 3° INT condiviso.

Non ha 3 core int...

[paolo.oliva2]

Grrrr... allora ho preso un abbaglio.... .
Ma non si diceva all'inizio che c'era un'unità INT condivisa in più tra i 2 core?

[cionci]

Originariamente inviato da paolo.oliva2

Grrrr... allora ho preso un abbaglio.... .
Ma non si diceva all'inizio che c'era un'unità INT condivisa in più tra i 2 core?

No, c'è l'unità per le istruzioni vettoriali sugli interi, ma è nella FPU.

[Pihippo]

Originariamente inviato da Gigamez

non saprei, davvero.. Progettare una architettura nuova partendo da zero non è uno scherzo: servono risorse, SOLDI, tempo (amd ci lavora da tanti anni a bulldozer). Tutto cio' per avere una architettura potenzialmente con MENO ipc della precedente (a parità di clock) che pero' "recupera" un po' per quei 600Mhz in piu'?

Bd 4Moduli (8cores) Vs SB 10 Cores + ht?
Sinceramente spero davvero non sia cosi', altrimenti vorrebbe dire senza ombra di dubbio che AMD si sarebbe definitivamente rassegnata ad essere eterna seconda (e che perde pure terreno di generazione in generazione) per quello che riguarda la battaglia prestazionale con Intel..

Ciao
Dunque posto una frase di un ing amd:
http://www.semiaccurate.com/forums/s...?t=3443&page=2

What you're looking at today is at a processor through a terrible telescope and trying to make determinations on how it might perform. Obviously, you can tell that the planet is red and several obvious other cues, but often times the little details are what is required to make a proper performance determination.

As JF as already pointed out, you only see the big picture. The little details are extremely important, and IMHO, the most important.

There's several big big cards not shown yet
Dunque ti faccio un esempio terra terra poichè io non sono esperto in queste due cose:
I c2q hanno 4 alu , i PhII ne hanno 3, hai mai visto un c2q che vada il 33% in più rispetto ad un phII? Io dico che hanno lo stesso ipc in molte applicazioni con alcune che privilegiano i c2q ed altre i PhII. BD avrà il 33% in meno di alu del k10, andrà meno?
No, ci sono svariati motivi:
K10 retirement buffer di 3mop, BD 4 mop, 33% teorico di vantaggio sulle mop ritirate (mop= uop matematico\logico più op di memoria o load\store)
Inoltre il 60% di istruzioni x86 contiene op load e store nel rapporto di 2:1 tra di loro, il k10 può eseguire queste istruzioni in modo quasi in order, ovvero con poche possibilità di esecuzione OoO, ad es dopo 3 cicli la alu 0 è pronta a sfornare un Imul, toh, manca l'operando, pipeline stallata poichè il processore non ha precaricato gli operandi ma ha eseguito le op di memoria quasi in ordine del codice che ha eseguito. Con Bd le memory pipelines sono completamente OoO
ed altri ancora di cui alcuni postati nelle varie slides. come prefetcher migliorati ed aggressivi nuovi branch predictors, scheduler più efficiente, caches più efficienti (si spera)