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

[Ares17]

Originariamente inviato da Gigamez

beh, innanzitutto io non penso sia implementato, ma penso che potrebbe essere un'ipotesi!

Comunque io parto dal presupposto che una unica unità INT con larghezza doppia e pari alla somma delle due sarebbe comunque piu' lenta, perche' le latenze sarebbero piu' alte e le macroistruzioni piu' difficili da gestire con troppe unità ALU. Riguardo alle possibili "collisioni" di indirizzi ecc.ecc. penso che non sarebbero possibili, non piu' di quanto lo sarebbero in una logica classica, visto che come ripeto il flusso sarebbe comunque sequenziale, e non parallelo (non si caricano 2 istruzioni alla volta, ma una sola.. ma alla metà della velocità, ecco perche' il decoder deve essere piu veloce).
Il branch poi sarebbe anch'esso comune (si vede anche dal grafico), infatti verrebbe calcolato singolarmente per istruzione (ed e' qui che però bisognerebbe aggiungere un altro algoritmo per il controllo di flusso relativo ad i due alberi di macroistruzioni e che consideri la logica OoO di calcolo)

vabbe', penso sia inutile andare avanti oltre.. sarebbe piu' facile un confronto a parole.. aspettiamo e vedremo XD

Be sperando che dopo tutto queste speculazioni ci sia qualcosa di vero

[Pihippo]

Originariamente inviato da Gigamez

beh, innanzitutto io non penso sia implementato, ma penso che potrebbe essere un'ipotesi!

Comunque io parto dal presupposto che una unica unità INT con larghezza doppia e pari alla somma delle due sarebbe comunque piu' lenta, perche' le latenze sarebbero piu' alte e le macroistruzioni piu' difficili da gestire con troppe unità ALU. Riguardo alle possibili "collisioni" di indirizzi ecc.ecc. penso che non sarebbero possibili, non piu' di quanto lo sarebbero in una logica classica, visto che come ripeto il flusso sarebbe comunque sequenziale, e non parallelo (non si caricano 2 istruzioni alla volta, ma una sola.. ma alla metà della velocità, ecco perche' il decoder deve essere piu veloce).
Il branch poi sarebbe anch'esso comune (si vede anche dal grafico), infatti verrebbe calcolato singolarmente per istruzione (ed e' qui che però bisognerebbe aggiungere un altro algoritmo per il controllo di flusso relativo ad i due alberi di macroistruzioni e che consideri la logica OoO di calcolo)

vabbe', penso sia inutile andare avanti oltre.. sarebbe piu' facile un confronto a parole.. aspettiamo e vedremo XD

Ciao
Non per forza un core int cosi grosso deve computare con latenze maggiori rispetto ad un core più snello, vedi ad es i c2q oppure il k10 stesso, le latenze anche per operazioni con operandi nella memoria (e non nei registri) sono abbastanza basse. Semmai come giustamente dici tu, si avrebbe una grossa difficolta a mantenere occupate tutte queste alu e potenzialmente un grosso spreco di energia ogni branch miss o cache miss (flush della pipeline in ambo i casi)
Scusami ancora, riguardando il discorso delle collisioni di indirizzi, mi sono espresso male io non intendo alias di indirizzi per ops di load e store, ma mi riferisco alla instruction fetch, prendi una direzione di branch vai a fetchare una particolare porzione di codice, (sempre se hai preso la diramazione giusta). Poi non ho capito, e mi scuso, l'utilita di caricare una istruzione alla volta. Ovvero istr a core b ed istr c core a?

[paolo.oliva2]

Originariamente inviato da bjt2

E pensa che dato il FO4 minore e le dichiarazioni di GF (+40% di clock a parità di tutto), l'incremento di clock potrebbe (e dovrebbe) essere ben superiore al 33% da te stimato...
Io prevedo (almeno a regime, forse non da subito) +50% rispetto a phenom II a default e +60-70% in modalità turbo (sempre rispetto a Phenom II)... A parità di core... Anche considerato che due core BD (un modulo) probabilmente avranno meno transistors di due core Phenom II...

Riesco a portare un Thuban a screen a 4,876GHz (vedi firma)... aspetta che ho il Thuban...

[paolo.oliva2]

Originariamente inviato da astroimager

Con il mio portatile, che ha quasi 8 anni alle spalle e potenza un po' inferiore ai sistemi Atom, ho effettuato stacking di migliaia di frame, ridotto spettri, programmato in IDL, elaborato con PS... sfido a fare lavori del genere con un cellulare.

Sarò all'antica, ma a me il cellulare serve solamente per chiamare, mandare qualche mex, ora-sveglia, e al più cazzaggiare quando sto sopra il water.

Ricordati sempre che è il MANICO che conta. Riguardati questo simpatico articoletto:
http://www.appuntidigitali.it/10073/...l-mio-netbook/

Io Astro non ti do mica torto... infatti io ho postato "per me"... poi siccome il discorso era sull'Atom, non volevo che la mia opinione fosse interpretata come anti-Atom, infatti ho voluto sottolineare che se AMD facesse un portatile con prestazioni simili, a me non passa manco per l'anticamera del cervello di comprarlo.
Ti faccio questo confronto OT, per farti un'idea: con le vetture, io ho "dovuto" comprare sempre o pari CV o superiori... perché mi conosco e se passassi da una macchina "superiore" ad una "inferiore"... non mi troverei bene e mi resterebbe il magone in gola. Con questo, non è che un 1200 non ti porterebbe mai dove ti porta un 2000, ma il problema che chiederei al 1200 che andasse come il 2000. Con la stessa tipologia, non avendo necessità di mobilità di computer, se io cambio PC, lo farei unicamente per un sistema più potente e se dovessi affiancarlo con un altro sistema, farebbe la fine del mio portatile (si è bruciata la mobo perchè... dopo 6 mesi di non utilizzo, si sono invertite le polarità alla batteria).

[carlottoIIx6]

Originariamente inviato da Ares17

Be sperando che dopo tutto queste speculazioni ci sia qualcosa di vero

mi chiedo una domanda
come sarebbero le rpestazioni del k10, se avrsse una fp più generosa?

[cionci]

Originariamente inviato da carlottoIIx6

mi chiedo una domanda
come sarebbero le rpestazioni del k10, se avrsse una fp più generosa?

Avrebbe prestazioni migliori nelle applicazioni che usano l'unità FP. Quindi le prestazioni non aumenterebbero in toto. Magari nella fisica dei giochi, sicuramente nella codifica audio/video.

[Gigamez]

Originariamente inviato da Pihippo

Ciao
Non per forza un core int cosi grosso deve computare con latenze maggiori rispetto ad un core più snello, vedi ad es i c2q oppure il k10 stesso, le latenze anche per operazioni con operandi nella memoria (e non nei registri) sono abbastanza basse. Semmai come giustamente dici tu, si avrebbe una grossa difficolta a mantenere occupate tutte queste alu e potenzialmente un grosso spreco di energia ogni branch miss o cache miss (flush della pipeline in ambo i casi)
Scusami ancora, riguardando il discorso delle collisioni di indirizzi, mi sono espresso male io non intendo alias di indirizzi per ops di load e store, ma mi riferisco alla instruction fetch, prendi una direzione di branch vai a fetchare una particolare porzione di codice, (sempre se hai preso la diramazione giusta). Poi non ho capito, e mi scuso, l'utilita di caricare una istruzione alla volta. Ovvero istr a core b ed istr c core a?

Io parlo di istruzioni singole a livello di fetch e decode, anche se in effetti alle unità intere come avevo specificato addietro arriverebbero dei "pacchetti" bufferizzati di microistruzioni.

Come e' stato dimostrato unità intere con piu' di un certo numero di ALU non darebbero alcun vantaggio (da qui l'inutilità di avere una mega-unità intera con ALU doppie).. Ma se il nostro decode riuscisse a codificare a velocità doppia del normale le nostre istruzioni, potrebbe per ogni macro-istruzione mandare le microistruzioni ad essa appartenenti ad un "buffer" FIFO del core0, e mentre questo lavora mandare le micro-istruzioni della istruzione successiva al buffer del core1. I due cores lavoreranno quindi cosi' come hanno sempre fatto, su micro-istruzioni da ricomporre poi nelle loro retires (separate).
Il fatto di smistare le istruzioni alternativamente ed una alla volta servirebbe per avere meno problemi di dipendenze e sarebbe fondamentale per poter semplificare gli algoritmi di predizione, tutto qui..

semplificando al massimo la logica di funzionamento sarebbe quella che ho descritto in vari post addietro:
http://www.hwupgrade.it/forum/showpo...postcount=3967
Ovviamente qui non prevedo le pipelines all'interno delle ALU, ma anche pensando che ci siano sarebbe semplicemente un po' piu' compleso da gestire l'algoritmo di controllo di flusso sui due rami (l'unico da "aggiungere", possibile algoritmo di cui parlavo vari post fa) in quanto dovrebbe tenere conto anche del numero di stadi appunto delle pipelines, ma nulla di impossibile, comunque.. praticaemnte bisognerebbe semplicemente controllare le dipendenze su un cammino ipotetico "doppio" rispetto a quello normalmente considerato (in quanto i pacchetti vengono smistati du due unità identiche)

[capitan_crasy]

Due piccoli aggiornamenti:
Al 90% le GPU di Llano e Ontario/Zacate supporteranno la tecnologia Blu-ray 3D...
Ci saranno nuove informazioni su Bobcat al "AMD Technical Forum and Exhibition" il 18 ottobre 2010; è probabile che AMD parlerà anche di Llano e Bulldozer...

[Trokji]

Una cosa: bulldozer supporterà ddr 3 1333 oppure solo 1600 ed oltre?

[greeneye]

In uyn post ieri jf-amd ha riassunto le nuove istruzioni supportate da bulldozer:

Originariamente inviato da JF-AMD

There are few changes that need to be comprehended.

New instructions are mainly SSSE3, SSE 4.1 and 4.2, AVX, AES, FMA4, XOP, PCLMULQDQ; these mostly refer to FP and less to integer.

.... non so se è un po' old....ma mi pareva che non fosse dichiarato in modo netto.

[capitan_crasy]

Originariamente inviato da Trokji

Una cosa: bulldozer supporterà ddr 3 1333 oppure solo 1600 ed oltre?

Le ultime voci davano un supporto alle 1866Mhz, ma il fatto che AMD non abbia ancora rilasciato ufficialmente questo parametro fa pensare che non abbia ancora raggiunto una decisione definitiva; in teoria potrebbe supportare anche le 2133Mhz o forse solo le 1600Mhz ...

Originariamente inviato da capitan_crasy

Le ultime voci davano un supporto alle 1866Mhz, ma il fatto che AMD non abbia ancora rilasciato ufficialmente questo parametro fa pensare che non abbia ancora raggiunto una decisione definitiva; in teoria potrebbe supportare anche le 2133Mhz o forse solo le 1600Mhz ...

Beh.. io ho ordinato le 2000Mhz, una via di mezzo!

[Trokji]

No lo chiedo perché vorrei prendere delle memorie che possibilmente vadano bene anche su bulldozer.. se prendo delel 1333 e poi si deve downcloccare non è il massimo

[paolo.oliva2]

Originariamente inviato da Trokji

No lo chiedo perché vorrei prendere delle memorie che possibilmente vadano bene anche su bulldozer.. se prendo delel 1333 e poi si deve downcloccare non è il massimo

Secondo me si potrebbero prendere anche delle 2100MHz e oltre.
Il supporto alle ram è solamente in base al Jdec. Del resto, il Thuban è ancora fermo alle 1333, ma supporta tranquillamente le 1600 senza agire sulla frequenza del bus e sino a 2000 se supportato dalla mobo.

Mi sembra che lo standard Jdec per le 1600-1800-1866 dovrebbe essere definito a novembre di quest'anno... per questo ancora non c'è nulla di ufficiale.

[calabar]

Originariamente inviato da Gigamez

Come e' stato dimostrato unità intere con piu' di un certo numero di ALU non darebbero alcun vantaggio (da qui l'inutilità di avere una mega-unità intera con ALU doppie).. [...]

Secondo me questo è il punto, ed è anche ciò che non capisco del tuo ragionamento: in che modo due core potrebbero essere più efficienti di un singolo core "grosso"?
E' come se dicessi che un crossfire di due gpu piccole sia meglio di una singola gpu monolitica di grandi dimensioni con gli stessi elementi e la stessa frequenza.
Questo non è mai vero, la singola GPU sarà sempre superiore.

Se quindi ci fosse la possibilità di sfruttare più alu (più di quelle che già si utilizzano) in un singolo core, volendo aumentare l'ipc di un singolo core, la soluzione più diretta sarebbe quella di potenziare tale core aggiungendo tali alu (e ovviamente quanto di contorno necessario per sfruttarle).

Ma se questo non è possibile, come potrebbe essere possibile invece ottenere questo risultato con più core?
Nella mia ignoranza questa cosa non ha davvero alcun senso.

[Pihippo]

Originariamente inviato da Gigamez

Io parlo di istruzioni singole a livello di fetch e decode, anche se in effetti alle unità intere come avevo specificato addietro arriverebbero dei "pacchetti" bufferizzati di microistruzioni.

Come e' stato dimostrato unità intere con piu' di un certo numero di ALU non darebbero alcun vantaggio (da qui l'inutilità di avere una mega-unità intera con ALU doppie).. Ma se il nostro decode riuscisse a codificare a velocità doppia del normale le nostre istruzioni, potrebbe per ogni macro-istruzione mandare le microistruzioni ad essa appartenenti ad un "buffer" FIFO del core0, e mentre questo lavora mandare le micro-istruzioni della istruzione successiva al buffer del core1. I due cores lavoreranno quindi cosi' come hanno sempre fatto, su micro-istruzioni da ricomporre poi nelle loro retires (separate).
Il fatto di smistare le istruzioni alternativamente ed una alla volta servirebbe per avere meno problemi di dipendenze e sarebbe fondamentale per poter semplificare gli algoritmi di predizione, tutto qui..

semplificando al massimo la logica di funzionamento sarebbe quella che ho descritto in vari post addietro:
http://www.hwupgrade.it/forum/showpo...postcount=3967
Ovviamente qui non prevedo le pipelines all'interno delle ALU, ma anche pensando che ci siano sarebbe semplicemente un po' piu' compleso da gestire l'algoritmo di controllo di flusso sui due rami (l'unico da "aggiungere", possibile algoritmo di cui parlavo vari post fa) in quanto dovrebbe tenere conto anche del numero di stadi appunto delle pipelines, ma nulla di impossibile, comunque.. praticaemnte bisognerebbe semplicemente controllare le dipendenze su un cammino ipotetico "doppio" rispetto a quello normalmente considerato (in quanto i pacchetti vengono smistati du due unità identiche)

Ciao
Mi scuso per la lentezza, ma ho avuto qualche difficoltà a capire.
Dunque, tu ipotizzi che dopo la fase di fetch i decoders decodifichino 2 stream di istruzioni un viene mandato al core 0 e dopo un ciclo di clock (suppongo per fare uno scoreboard per vedere le dipendenze tra istruzioni mandate al core 0 ed al core1) l'altro al core 1, questo sottoforma di un pack buffer( che già viene utilizzato per il dispatch delle mops decodificate) più in giù nelle pipes dei due core. Dopo ciò si dovrebbe ritirare le ops in buffer separati e ricomporre lo stream come il codice prevede.
Se ho capito bene, mi sa che ci vuole qualcosina di esoso in termini di logica, non vorrei essere ripetitivo, ma si dovrebbe (sempre ad opinione mia, ovvero valore 0) implementare un pò di logica, molta di più di un raddoppio di alu e buffer connessi.

1) Dovresti possedere dei decoder che non si stoppino(per il calcolo del nuovo address di memoria inteso come qualsiasi memoria tranne i registri dpve fetchare la nuova porzione di codice) ad ogni branch incontrata.
2) Logica di fetch: Ogni branch risolta ti punta ad una locazione x di memoria dove prendere codice y. Bene se tutte e due i core ricevono una branch, e devono caricare due locazioni z,k quale processore carica per primo?( si parla di 2 core che eseguono uno stesso thread) Se ambedue sbagliano a calcolare una branch hai perso un sacco di energia oltre che cicli preziosi. Se le due branch sono "dipendenti" nel senso che dal risultato di una puoi prendere o meno l'altra, come fai a gestire il fatto che in 2 cicli hai riempito due core e magari solo uno ha fatto un lavoro utile ? Ad es core 0 branch presa che fa saltare il procio ad un altra porzione di codice mentre quello che fa il core 1 non è più necessario,
3)Tecniche OoO e register renaming.
I due cores 0 ed 1 che eseguono lo stesso thread hanno i gprs condivisi? Se se una lea che fa il core 1 dice di scrivere su EBX mentre un altra op m-> dice di scrivere su EBX come si risolve il conflitto? register renaming si potrebbe pensare ma se son impegnati? e come si implementerebbe questa tecnica su due cores differenti con ognuno operandi\indirizzi da salvare in questi registri.
4) sincronizzazione dei cores e comunicazione intercores.

[Gigamez]

Originariamente inviato da Pihippo

Ciao
Mi scuso per la lentezza, ma ho avuto qualche difficoltà a capire.
Dunque, tu ipotizzi che dopo la fase di fetch i decoders decodifichino 2 stream di istruzioni un viene mandato al core 0 e dopo un ciclo di clock (suppongo per fare uno scoreboard per vedere le dipendenze tra istruzioni mandate al core 0 ed al core1) l'altro al core 1, questo sottoforma di un pack buffer( che già viene utilizzato per il dispatch delle mops decodificate) più in giù nelle pipes dei due core. Dopo ciò si dovrebbe ritirare le ops in buffer separati e ricomporre lo stream come il codice prevede.
Se ho capito bene, mi sa che ci vuole qualcosina di esoso in termini di logica, non vorrei essere ripetitivo, ma si dovrebbe (sempre ad opinione mia, ovvero valore 0) implementare un pò di logica, molta di più di un raddoppio di alu e buffer connessi.

ESATTO! hai capito cosa intendevo!
Secondo me invece non sarebbe per nulla cosi' esoso in termini di risorse, ma al contrario una implementazione di questo tipo ti permetterebbe davvero di avere tutto quanto condiviso (bisognerebbe certo aggiungere qualche logica, ma sarebbe minima, a parer mio).

1) Dovresti possedere dei decoder che non si stoppino(per il calcolo del nuovo address di memoria inteso come qualsiasi memoria tranne i registri dpve fetchare la nuova porzione di codice) ad ogni branch incontrata.

secondo me teoricamente basterebbe un decoder identico a quello di un k10 ma con velocità di codifica doppia. Tu stai continuando a pensare ad un calcolo istantaneamente parallelo, mentre secondo la mia ipotesi sarebbe alternato ed esclusivo per ogni core (mentre uno calcola, l'altro restituisce il risultato e viceversa)

2) Logica di fetch: Ogni branch risolta ti punta ad una locazione x di memoria dove prendere codice y. Bene se tutte e due i core ricevono una branch, e devono caricare due locazioni z,k quale processore carica per primo?( si parla di 2 core che eseguono uno stesso thread) Se ambedue sbagliano a calcolare una branch hai perso un sacco di energia oltre che cicli preziosi. Se le due branch sono "dipendenti" nel senso che dal risultato di una puoi prendere o meno l'altra, come fai a gestire il fatto che in 2 cicli hai riempito due core e magari solo uno ha fatto un lavoro utile ? Ad es core 0 branch presa che fa saltare il procio ad un altra porzione di codice mentre quello che fa il core 1 non è più necessario,

da quello che si e' visto ogni core ha la sua logica L/s indipendente. in ogni caso visto che i calcoli sarebbero alternati (e mai eseguiti nello stesso istante di clock), sarebbe virtualmente impossibile avere richieste del genere nello stesso istante.. al max si potrebbero avere in tempi dimezzati rispetto al normale..

3)Tecniche OoO e register renaming.
I due cores 0 ed 1 che eseguono lo stesso thread hanno i gprs condivisi? Se se una lea che fa il core 1 dice di scrivere su EBX mentre un altra op m-> dice di scrivere su EBX come si risolve il conflitto? register renaming si potrebbe pensare ma se son impegnati? e come si implementerebbe questa tecnica su due cores differenti con ognuno operandi\indirizzi da salvare in questi registri.

beh, ovviamente ognuna dovrebbe avere dei registri "proprietari", oltre che appunto cache "data" autonome (infatti abbiamo visto che sarà cosi').. Ma questo sarebbe inevitabile anche se si pensasse a questi moduli come dei "veri" dual core.. sbaglio? Al max quello che non tornerebbe nel caso del "dual core classico" e' la l1 Instr comune (e sappiamo che pero' sarà cosi')

4) sincronizzazione dei cores e comunicazione intercores.

la sincronizzazione avverrebbe "a monte", quando si decide da che parte far andare una istruzione, in modo da minimizzare le possibilità di conflitto, per il resto opererebbero in maniera alternata, quindi sincronizzati direttamente sul clock di sistema. La comunicazione intercores sarebbe utile tanto quanto potrebbe esserlo tra uno stadio di pipeline e l'altro in un core "classico". La "lunghezza" su cui potrebbero verificarsi dipendenze e/o conflitti sarebbe semplicemente doppia rispetto a quella normale, ma per il resto sarebbe esattamente la stessa cosa!

Comunque non devi scusarti di nulla: mi piace molto parlare di queste possibili speculazioni con persone come te (molto piu' esperte di me).. Probabilmente c'e' davvero qualcosa che non sto considerando.. ma se così non fosse AMD potrebbe avere fatto davvero centro!

chissà..

[paolo.oliva2]

Originariamente inviato da calabar

Secondo me questo è il punto, ed è anche ciò che non capisco del tuo ragionamento: in che modo due core potrebbero essere più efficienti di un singolo core "grosso"?
E' come se dicessi che un crossfire di due gpu piccole sia meglio di una singola gpu monolitica di grandi dimensioni con gli stessi elementi e la stessa frequenza.
Questo non è mai vero, la singola GPU sarà sempre superiore.

Se quindi ci fosse la possibilità di sfruttare più alu (più di quelle che già si utilizzano) in un singolo core, volendo aumentare l'ipc di un singolo core, la soluzione più diretta sarebbe quella di potenziare tale core aggiungendo tali alu (e ovviamente quanto di contorno necessario per sfruttarle).

Ma se questo non è possibile, come potrebbe essere possibile invece ottenere questo risultato con più core?
Nella mia ignoranza questa cosa non ha davvero alcun senso.

Potrebbero subentrare dei motivi di ottimizzazione?
Cioè... concordo con quello che dici... però, entrando nella filosofia di BD, visto come ottimizzazione di spazio nello sfruttamento di risorse condivise... potrebbe avere un senso se visto in ottica sia di clock che TDP ad area?

Cioè... faccio un esempio nella mia ignoranza terra terra.
L'HT è stato reso indipendente dall'NB appunto per non essere vincolato dal clock.
"Sdoppiare" il lavoro renderebbe di per sé più snella la cosa. E' vero che comunque se varie parti del procio sono in dipendenza di un dato, gli stalli se non ottimizzati ci sarebbero, ma è anche vero che se vediamo la cosa come un core "grosso", tutta la superficie sarebbe sotto carico, mentre se la cosa fosse divisa in più parti logiche indipendenti, appunto perché non dipendenti, potrebbero entrare in IDLE e comunque se pur non aumentando l'IPC, contribuirebbero a diminuire il TDP.
(Se dico castronerie non fustigatemi).
Se una pipeline dovesse "servire" ad esempio 3 INT, a parte l'ottimizzazione che in alcuni casi gli INT potrebbero "lavorare" in parallelo, comunque la pipeline non potrebbe accettare nuovo lavoro sinché non è svuotata...
Con più pipeline, non potrebbe crearsi la situazione ad esempio che una volta volta che il risultato è passato alla L2 (e non necessariamente alla L3/RAM), la seconda pipeline potrebbe da subito caricare il dato nuovo eliminando così i cicli di svuotamento?
Cioè... tra un ciclo e l'altro, se la L2 potesse gestire a scelta una pipeline, praticamente potrebbe eliminare dei cicli servendo la prima pipeline che è già pronta e libera.
Poi... perché è stato scelto il modulo per i P-State e non i core? D'accordo... i 2 core hanno parti condivise e quindi è impossibile che una parte vada del modulo vada in idle e l'altra no... però è anche vero che se è stato scelto di inquadrare il modulo e non il singolo core... inoltre una L2 condivisa, di per sé può serivire sia il core A o core B... mi suona un po' strano che sia solo per "risparmiare" spazio, soprattutto senza avere l'obiettivo di incrementare l'IPC, perché di fondo il problema di AMD non è il TDP, ma l'IPC.

[Gigamez]

Originariamente inviato da calabar

Secondo me questo è il punto, ed è anche ciò che non capisco del tuo ragionamento: in che modo due core potrebbero essere più efficienti di un singolo core "grosso"?
E' come se dicessi che un crossfire di due gpu piccole sia meglio di una singola gpu monolitica di grandi dimensioni con gli stessi elementi e la stessa frequenza.
Questo non è mai vero, la singola GPU sarà sempre superiore.

Se quindi ci fosse la possibilità di sfruttare più alu (più di quelle che già si utilizzano) in un singolo core, volendo aumentare l'ipc di un singolo core, la soluzione più diretta sarebbe quella di potenziare tale core aggiungendo tali alu (e ovviamente quanto di contorno necessario per sfruttarle).

Ma se questo non è possibile, come potrebbe essere possibile invece ottenere questo risultato con più core?
Nella mia ignoranza questa cosa non ha davvero alcun senso.

beh, perche' nel caso dei calcoli FP piu' unità di calcolo hai piu' puoi parallelizzare e quindi teoricamente avere piu' FLOPS (floating operation per second).
Nel caso delle istruzioni complesse x86 è molto piu' importante il fatto di codificare in microistruzioni. Praticamente "scomponi" in pezzi piu' piccoli. Se hai possibilità di scomporre in pezzi ancora piu' piccoli (avendo piu' ALU) non e' detto che avrai un guadagno prestazionale, anzi.. potresti invece avere una perdita! Se invece mandi in esecuzioni due macro-istr codificate (esegui 2 macro-istr, ovvero ad esempio 8 micro-op in parallelo supponendo che una macro-instr la scomponi in 4 micro-ops) sulla stessa alu e nello stesso istante potresti avere dei seri problemi nel gestire le dipendenze ed i branch, proprio perche' sono eseguite tutte NELLO STESSO ISTANTE. (tra parentesi eseguire nello stesso istante flussi diversi di macro istruzioni sarebbe davvero un reverse hyperthreading, perche' dovremmo virtualmente fetchare e codificare due "parti" di thread istantaneamente ed arriverebbero anche NELLO STESSO ISTANTE i risultati da ricomporre!)

La mia ipotesi invece non prevede l'esecuzione di due rami di istruzioni NELLO STESSO ISTANTE, ma in maniera alternata.

L'auto-quote che ho fatto prima relativo a quello che scrissi qualche giorno fa era un esempio semplicissimo che forse vale piu' di mille parole..
http://www.hwupgrade.it/forum/showpo...postcount=3967

Ripeto ancora: posso aver solamente fantasticato in maniera assurda ed inconsistente.. Pero'.. chissà XD

[Pihippo]

Originariamente inviato da Gigamez

ESATTO! hai capito cosa intendevo!
Secondo me invece non sarebbe per nulla cosi' esoso in termini di risorse, ma al contrario una implementazione di questo tipo ti permetterebbe davvero di avere tutto quanto condiviso (bisognerebbe certo aggiungere qualche logica, ma sarebbe minima, a parer mio).



secondo me teoricamente basterebbe un decoder identico a quello di un k10 ma con velocità di codifica doppia. Tu stai continuando a pensare ad un calcolo istantaneamente parallelo, mentre secondo la mia ipotesi sarebbe alternato ed esclusivo per ogni core (mentre uno calcola, l'altro restituisce il risultato e viceversa)

da quello che si e' visto ogni core ha la sua logica L/s indipendente. in ogni caso visto che i calcoli sarebbero alternati (e mai eseguiti nello stesso istante di clock), sarebbe virtualmente impossibile avere richieste del genere nello stesso istante.. al max si potrebbero avere in tempi dimezzati rispetto al normale..


beh, ovviamente ognuna dovrebbe avere dei registri "proprietari", oltre che appunto cache "data" autonome (infatti abbiamo visto che sarà cosi').. Ma questo sarebbe inevitabile anche se si pensasse a questi moduli come dei "veri" dual core.. sbaglio? Al max quello che non tornerebbe nel caso del "dual core classico" e' la l1 Instr comune (e sappiamo che pero' sarà cosi')

la sincronizzazione avverrebbe "a monte", quando si decide da che parte far andare una istruzione, in modo da minimizzare le possibilità di conflitto, per il resto opererebbero in maniera alternata, quindi sincronizzati direttamente sul clock di sistema. La comunicazione intercores sarebbe utile tanto quanto potrebbe esserlo tra uno stadio di pipeline e l'altro in un core "classico". La "lunghezza" su cui potrebbero verificarsi dipendenze e/o conflitti sarebbe semplicemente doppia rispetto a quella normale, ma per il resto sarebbe esattamente la stessa cosa!

Comunque non devi scusarti di nulla: mi piace molto parlare di queste possibili speculazioni con persone come te (molto piu' esperte di me).. Probabilmente c'e' davvero qualcosa che non sto considerando.. ma se così non fosse AMD potrebbe avere fatto davvero centro!

chissà..

Ciao
Anche me fa piacere parlare di queste cose.
Ho finalmente capito il tuo punto di vista, ovvero un reverse SMT di intel! Invece di caricar un thread nuovo su uno stesso cores, tu ne carichi lo stesso su due cores ognuno con il proprio set di gprs buffer rob, rimane comunque la comunicazione tra L\s unit e data chache che deve avvenire per sincronizzazione e share di operandi. In pratica alterneresti in maniera interleaved l'esecuzione di uno stesso thread su due cores.
ora bisogna aspettare e vedere se amd ha risolto alcuni problemucci, che come dicevamo prima, anche se non si esegue in maniera parallela due pacchetti di istr sono comunque presenti.