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

[Gigamez]

comunque io non sto parlando di unita' ALU.. la mia ipotesi si basa su una logica di parallellizzazione delle micro-ops (chiamiamoli "pacchetti di micro-ops, se preferite) sulle due unità INT (quindi sulle alu della unità).. proprio come in un crossfire o in un SLI. Il discorso delle istruzioni parallelizzate non c'entra:
se do ad una sola unita' l'istruzione 1, poi la 2, poi la 3 e poi la 4.. teoricamente ricevero' in output le istruzioni in questo ordine (al max le riordino).
Se do alla prima unita' l'istruzione 1, e mentre questa elabora grazie al fetch potente ed al decode potente riesco ad avere gia' pronta l'istruzione 2, potro' darla alla seconda unità. quando la prima unita' sara' pronta a ricevere un'altra istruzione io la avro' pronta, per poi dare nel mentre dell'elaborazione l'istruzione 4 alla seconda unità.
Supponendo le unita' di eguale potenza elaborativa, allora l'ordine di output della seconda opzione sarebbe lo stesso della pirma, con pero' la particolarità di poter eseguire le 4 istruzioni in un tempo minore.
E' per questo che mi veniva in mente l'esempio dell'SLI.
Ovviamente lo scheduler e la retire dovrebbero essere unificate..

Magari sono stupidate, ma secondo me potrebbe essere possibile.. Potrebbe essere una soluzione per aumentare di molto la potenza sugli interi, no?

vabbe', in fondo e' solamente una ipotesi probabilmente strampalata, quindi vedremo quando avremo qualcosa di piu' certo riguardante l'architettura!

[Pihippo]

Originariamente inviato da Gigamez

comunque io non sto parlando di unita' ALU.. la mia ipotesi si basa su una logica di parallellizzazione delle micro-ops (chiamiamoli "pacchetti di micro-ops, se preferite) sulle due unità INT (quindi sulle alu della unità).. proprio come in un crossfire o in un SLI. Il discorso delle istruzioni parallelizzate non c'entra:
se do ad una sola unita' l'istruzione 1, poi la 2, poi la 3 e poi la 4.. teoricamente ricevero' in output le istruzioni in questo ordine (al max le riordino).
Se do alla prima unita' l'istruzione 1, e mentre questa elabora grazie al fetch potente ed al decode potente riesco ad avere gia' pronta l'istruzione 2, potro' darla alla seconda unità. quando la prima unita' sara' pronta a ricevere un'altra istruzione io la avro' pronta, per poi dare nel mentre dell'elaborazione l'istruzione 4 alla seconda unità.
Supponendo le unita' di eguale potenza elaborativa, allora l'ordine di output della seconda opzione sarebbe lo stesso della pirma, con pero' la particolarità di poter eseguire le 4 istruzioni in un tempo minore.
E' per questo che mi veniva in mente l'esempio dell'SLI.
Ovviamente lo scheduler e la retire dovrebbero essere unificate..

Magari sono stupidate, ma secondo me potrebbe essere possibile.. Potrebbe essere una soluzione per aumentare di molto la potenza sugli interi, no?

vabbe', in fondo e' solamente una ipotesi probabilmente strampalata, quindi vedremo quando avremo qualcosa di piu' certo riguardante l'architettura!

Ciao
Scusami se non potrò dare una risposta esaustiva, ma il mio schifobook con atom ha finito la batteria.
Stai facendo un pò di confusione, quello che descrivi gia avviene dai tempi del Pii\p pro con la logica OoO e la fowarding network

[Gigamez]

Originariamente inviato da Pihippo

Ciao
Scusami se non potrò dare una risposta esaustiva, ma il mio schifobook con atom ha finito la batteria.
Stai facendo un pò di confusione, quello che descrivi gia avviene dai tempi del Pii\p pro con la logica OoO e la fowarding network

no, ma io non intendo tirare in ballo i discorsi della logica di tipo Out of order.. So che normalmente le istruzioni vengono eseguite in maniera "disordinata", so la funzione delle pipelines.. poi parlavo appunto prima della retire units. Ma non volevo tirare in mezzo la logica OoO, ormai scontata nei moderni processori: il mio esempio serviva solamente a far capire che una esecuzione di questo tipo non presenterebbe difficolta' e dipendenze superiori a quelle relative ad una esecuzione sempre OoO ma fatta con solamente una unità intera (e le sue relative ALU).
Intendevo dire che il flusso di dati sarebbe in entrambi i casi il medesimo, semplicemente raddoppiato, a patto che i decoders riescano ad essere veloci abbastanza per "dare da mangiare" ad entrambe le unità. Il vero problema infatti sarebbe proprio li': bisognerebbe decodificare al doppio della velocità, altrimenti sarebbe appunto totalmente inutile..

vabbe', mi fermo qui, sto andando forse troppo oltre con queste appunto fantasiose ipotesi, e sicuramente sto sbagliando qualcosa

[cionci]

Originariamente inviato da Gigamez

Se do alla prima unita' l'istruzione 1, e mentre questa elabora grazie al fetch potente ed al decode potente riesco ad avere gia' pronta l'istruzione 2, potro' darla alla seconda unità. quando la prima unita' sara' pronta a ricevere un'altra istruzione io la avro' pronta, per poi dare nel mentre dell'elaborazione l'istruzione 4 alla seconda unità.
Supponendo le unita' di eguale potenza elaborativa, allora l'ordine di output della seconda opzione sarebbe lo stesso della pirma, con pero' la particolarità di poter eseguire le 4 istruzioni in un tempo minore.
E' per questo che mi veniva in mente l'esempio dell'SLI.
Ovviamente lo scheduler e la retire dovrebbero essere unificate..

E' quello che fanno dal momento in cui ci sono unità di esecuzione multiple all'interno della stessa FPU o ALU. Quindi questo avviene già. Ed è proprio lo scheduler a gestire l'allocazione delle unità di esecuzione in modo da ottenere un throughput più alto possibile. Per questo prima ti dicevo che se i due core int avessero avuto lo stesso scheduler allora sarebbe stata come una grande ALU con il doppio delle unità di esecuzione.
Certo, sarebbe bello ma...lo scheduler avrebbe dovuto gestire due thread contemporaneamente in SMT (possibile, ma non è certo agevole visto l'instruction set), la cache dL1 avrebbe dovuto essere unificata (con tutti i problemi che ne conseguono in caso di stallo di un solo thread), il retirement sarebbe dovuto essere unificato.
Senza contare che se non aumentano ulteriormente le unità di esecuzione della ALU evidentemente c'è un limite pratico al numero di unità che possono essere sfruttate contemporaneamente con istruzioni x86. Quindi probabilmente questa ALU non porterebbe ad effettivi miglioramenti rispetto alle due separate.

[Ares17]

Originariamente inviato da Gigamez

no, ma io non intendo tirare in ballo i discorsi della logica di tipo Out of order.. So che normalmente le istruzioni vengono eseguite in maniera "disordinata", so la funzione delle pipelines.. poi parlavo appunto prima della retire units. Ma non volevo tirare in mezzo la logica OoO, ormai scontata nei moderni processori: il mio esempio serviva solamente a far capire che una esecuzione di questo tipo non presenterebbe difficolta' e dipendenze superiori a quelle relative ad una esecuzione sempre OoO ma fatta con solamente una unità intera (e le sue relative ALU).
Intendevo dire che il flusso di dati sarebbe in entrambi i casi il medesimo, semplicemente raddoppiato, a patto che i decoders riescano ad essere veloci abbastanza per "dare da mangiare" ad entrambe le unità. Il vero problema infatti sarebbe proprio li': bisognerebbe decodificare al doppio della velocità, altrimenti sarebbe appunto totalmente inutile..

vabbe', mi fermo qui, sto andando forse troppo oltre con queste appunto fantasiose ipotesi, e sicuramente sto sbagliando qualcosa

I decoders credo che ce la possano fare.
Quello che mi sembra "strano" è:
Un th è codificato per avere un flusso dati ottimizzato per 2-3 pipeline.
Ammettendo che la logica interna possa far vedere il secondo int come un'estensione del primo l'ipc si può migliore utilizzando questa capacità di calcolo, oppure rimarrebbe inoperoso?
Il guadagno derivante dall'utilizzare due unità di calcolo separate basterebbe a compensare l'innalzamento della latenza derivante dalla necessità di leggere e scrivere nella L2?
Certo che se la fpu possa operare sia in modalità 1x256, 2x128 e 4x64 non vedo perchè gli int (se opportunamente strutturati) non possano venire usati in parallelo.

[cionci]

Originariamente inviato da Ares17

Certo che se la fpu possa operare sia in modalità 1x256, 2x128 e 4x64 non vedo perchè gli int (se opportunamente strutturati) non possano venire usati in parallelo.

Per la FPU la cosa è molto diversa. Questo perché opera su istruzioni vettoriali. Quindi su una sequenza di dati (solitamente maggiore di 4) a 64, 128 o 256 bit. Non c'è alcun conflitto da risolvere fra le varie unità di calcolo sulle istruzioni SIMD, quindi è molto più semplice: si allocano quante più unità possibili e si cerca di terminare l'istruzione vettoriale nel minor tempo possibile. Ovviamente nel caso di un solo thread. Tra l'altro le unità FMAC sono appunto solo per istruzioni SIMD. Le istruzioni FP legacy sono eseguite dalle altre unità.
Nel caso di due thread in SMT è la politica dello scheduler a decidere come assegnare le unità di calcolo fra i vari thread.

[Gigamez]

Originariamente inviato da cionci

E' quello che fanno dal momento in cui ci sono unità di esecuzione multiple all'interno della stessa FPU o ALU. Quindi questo avviene già. Ed è proprio lo scheduler a gestire l'allocazione delle unità di esecuzione in modo da ottenere un throughput più alto possibile. Per questo prima ti dicevo che se i due core int avessero avuto lo stesso scheduler allora sarebbe stata come una grande ALU con il doppio delle unità di esecuzione.
Certo, sarebbe bello ma...lo scheduler avrebbe dovuto gestire due thread contemporaneamente in SMT (possibile, ma non è certo agevole visto l'instruction set), la cache dL1 avrebbe dovuto essere unificata (con tutti i problemi che ne conseguono in caso di stallo di un solo thread), il retirement sarebbe dovuto essere unificato.
Senza contare che se non aumentano ulteriormente le unità di esecuzione della ALU evidentemente c'è un limite pratico al numero di unità che possono essere sfruttate contemporaneamente con istruzioni x86. Quindi probabilmente questa ALU non porterebbe ad effettivi miglioramenti rispetto alle due separate.

esatto! infatti e' quello che intendevo quando dicevo che con un'ipotesi del genere sarebbe davvero tutto condiviso (e dai grafici infatti non dovrebbe essere cosi', in quanto gia' solo gli scheduler e le retire sono separate, ma il fatto che il fetch ed il decode sia unico non quadra comunque)!
Riguardo a quello che gia' succede, sono d'accordo nel senso che ogni INT unit avendo a disposizione varie ALU lavora gia' in modo parallelizzato.. ma immagina delle sorte di "pacchetti" di istruzioni mandate in maniera alternata.. pensi davvero in un caso del genere non possa essere possibile un guadagno prestazionale?

[Ares17]

Originariamente inviato da Gigamez

esatto! infatti e' quello che intendevo quando dicevo che con un'ipotesi del genere sarebbe davvero tutto condiviso (e dai grafici infatti non dovrebbe essere cosi', in quanto gia' solo gli scheduler e le retire sono separate, ma il fatto che il fetch ed il decode sia unico non quadra comunque)!
Riguardo a quello che gia' succede, sono d'accordo nel senso che ogni INT unit avendo a disposizione varie ALU lavora gia' in modo parallelizzato.. ma immagina delle sorte di "pacchetti" di istruzioni mandate in maniera alternata.. pensi davvero in un caso del genere non possa essere possibile un guadagno prestazionale?

Ragionando sul raddoppio delle pipeline:
Se fosse bastato raddoppiare le pipeline dell'alu (con tutto quello che c'è dietro) avremo un aumento della superfice per core al massimo del 20% con un ipc teorico del doppio.
Consideriamo anche il raddoppio delle cache L1 e L2 sarebbe stato, per i produttori di cpu, più agevole questa operazione che puntare al multi core per avere un raddoppio dell'ipc con un risparmio della superfice di almeno il 60% rispetto ad un dual.
Ma se così non è significa che oltre un certo numero di pipeline (3) il guadagno di ipc non è proporzionale al costo su silicio.
Io continuo a rimanere dell'idea che il massimo che si possa fare per aumentare l'ipc del singolo th in un modulo sia quello di poter ridurre (se possibile) i cicli di attesa in caso di stallo delle pipeline swichando l'alu (e credo che al massimo si possa raggiungere il 5%)

[Gigamez]

Originariamente inviato da Ares17

Ragionando sul raddoppio delle pipeline:
Se fosse bastato raddoppiare le pipeline dell'alu (con tutto quello che c'è dietro) avremo un aumento della superfice per core al massimo del 20% con un ipc teorico del doppio.
Consideriamo anche il raddoppio delle cache L1 e L2 sarebbe stato, per i produttori di cpu, più agevole questa operazione che puntare al multi core per avere un raddoppio dell'ipc con un risparmio della superfice di almeno il 60% rispetto ad un dual.
Ma se così non è significa che oltre un certo numero di pipeline (3) il guadagno di ipc non è proporzionale al costo su silicio.
Io continuo a rimanere dell'idea che il massimo che si possa fare per aumentare l'ipc del singolo th in un modulo sia quello di poter ridurre (se possibile) i cicli di attesa in caso di stallo delle pipeline swichando l'alu (e credo che al massimo si possa raggiungere il 5%)

Beh, ma allora come giustifichi ad esempio una differenza sul calcolo intero cosi' marcata tra Intel ed AMD? Secondo il tuo ragionamento dovrebbero essere pressocchè identiche in termini di potenza di calcolo..

Comunque, in effetti non sarebbe proprio tutto "rosa e fiori".. Si risparmierebbe tantissimo silicio e si avrebbero prestazioni teoricamente doppie sugli interi, ma una architettura di questo tipo sarebbe piuttosto complessa da gestire, soprattutto nella fase di decode. Bisogna creare due veri e propri "flussi" di pacchetti di istruzioni cercando di far si che i pacchetti del primo flusso non siano in dipendenza sequenziale rispetto ai pacchetti del secondo flusso. Praticamente bisognerebbe avere una sorta di secondo branch prediction sui due rami, oltre che quello "classico" sulle istruzioni ed quindi un ulteriore algoritmo di ordinamento in base alle dipendenze sui flussi di pacchetti.. non sarebbe uno scherzo, senza contare che servirebbero logiche di fetch, decode, scheduling e retire che siano decisamente piu' veloci (e magari complesse) del normale.. o sbaglio?

[Ares17]

Originariamente inviato da Gigamez

Beh, ma allora come giustifichi ad esempio una differenza sul calcolo intero cosi' marcata tra Intel ed AMD? Secondo il tuo ragionamento dovrebbero essere pressocchè identiche in termini di potenza di calcolo..

edit

per la parte editata questo gia avviene con il multicore.
Sulla prima parte piuttosto come giustifichi l'aumento di ipc in s-th passando da 4 pipeline del c2d alle 3 di I7 (oltretutto contese tra due th con l'smt attivo)?

[Ren]

Beh, ma allora come giustifichi ad esempio una differenza sul calcolo intero cosi' marcata tra Intel ed AMD? Secondo il tuo ragionamento dovrebbero essere pressocchè identiche in termini di potenza di calcolo..

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

[Gigamez]

Originariamente inviato da Ares17

per la parte editata questo gia avviene con il multicore.
Sulla prima parte piuttosto come giustifichi l'aumento di ipc in s-th passando da 4 pipeline del c2d alle 3 di I7 (oltretutto contese tra due th con l'smt attivo)?

beh, il discorso dell'HT non pregiudica l'efficienza dei calcoli INT su un singolo thread, perche' pur essendo risorse "condivise", il secondo thread viene elaborato solamente durante le fasi di "stallo" del primo, quindi possiamo dire che le risorse vengono condivise in mutua esclusione..
Per quanto riguarda il numero di ALU penso che vada considerato non solo il loro numero, ma anche la loro effettiva efficienza prestazionale, legata sia ai branch prediction, sia al numero ci cicli relativo alle tipologie di micro-ops eseguibili, sbaglio?

Ma secondo me (ed e' un discorso che penso sia a prescindere dall'architettura OoO) in qualunque caso se ad esempio una unità INT di potenza elaborativa data e composta ad esempio da 3 alu è in grado di processarmi un "pacchetto di istruzioni" composto da "X" micro-ops in "Y" tempo.. nello stesso intervallo di tempo "Y" secondo uno schema di distribuzione alternata su due unità intere identiche alla prima data (ammesso non si siano errori di predizione) potremo processare due pacchetti di di istruzioni di eguale complessità, quindi 2X micro-ops. il flusso di output sarebbe identico, quindi anche gli algoritmi di ri-ordinamento sarebbero i medesimi.

ammettendo un caso del genere con "pacchetti" di operazioni.. secondo voi servirebbero due scheduler? (uno per modulo)
Penso sicuramente almeno una memoria di bufferizzazione per i pachetti di istruzioni per ogni modulo, sbaglio?

ditelo se sto divagando troppo, ehh? mi piace chiaccherare su cose tecniche, anche perche' oltre alla curiosità imparo sempre qualcosa di nuovo dai piu' esperti di me

[cionci]

Originariamente inviato da Gigamez

beh, il discorso dell'HT non pregiudica l'efficienza dei calcoli INT su un singolo thread, perche' pur essendo risorse "condivise", il secondo thread viene elaborato solamente durante le fasi di "stallo" del primo, quindi possiamo dire che le risorse vengono condivise in mutua esclusione..

Non funziona proprio così. Il due thread vengono eseguiti contemporaneamente, mescolati tra loro. In modo da cercare di allocare in ogni istante il maggior numero di unità di esecuzione possibile. Se c'è "spazio" per l'HyperThreading (se due thread senza HyperThreading vanno più lenti di due thread con HyperThreading) significa che con un solo thread non si riescono ad allocare molto spesso tutte le unità di esecuzione

[dark.halo]

Per quanto riguarda il discorso dell 80% di prestazioni del modulo rispetto un design classico,JF ha escluso tutto.
Dal blog AMD, JF risponde ad uno che gli chiedeva informazioni a riguardo...

TIPO:u said many times..your bulldozer core will be better than one curent core..other times bulldozer core will have 80% perfformance from a current core.what is right version,make it clear please?

JF:We have never said that Bulldozer would be 80% of the performance of current cores. This was a different statement about a different product.

http://blogs.amd.com/work/2010/10/04...stions-part-4/

[Ares17]

Originariamente inviato da dark.halo

Per quanto riguarda il discorso dell 80% di prestazioni del modulo rispetto un design classico,JF ha escluso tutto.
Dal blog AMD, JF risponde ad uno che gli chiedeva informazioni a riguardo...

TIPO:u said many times..your bulldozer core will be better than one curent core..other times bulldozer core will have 80% perfformance from a current core.what is right version,make it clear please?

JF:We have never said that Bulldozer would be 80% of the performance of current cores. This was a different statement about a different product.

http://blogs.amd.com/work/2010/10/04...stions-part-4/

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

[cionci]

E' normale che la iL1 sia condivisa, visto che i primi stage sono in comune fra i due thread. Era una cosa nota tra l'altro.

[capitan_crasy]

Originariamente inviato da dark.halo

Per quanto riguarda il discorso dell 80% di prestazioni del modulo rispetto un design classico,JF ha escluso tutto.
Dal blog AMD, JF risponde ad uno che gli chiedeva informazioni a riguardo...

TIPO:u said many times..your bulldozer core will be better than one curent core..other times bulldozer core will have 80% perfformance from a current core.what is right version,make it clear please?

JF:We have never said that Bulldozer would be 80% of the performance of current cores. This was a different statement about a different product.

http://blogs.amd.com/work/2010/10/04...stions-part-4/

E' da mesi ormai che dico di non basarsi sulle percentuali rilasciate da AMD per stabilire le prestazioni di Bulldozer....

[cionci]

Originariamente inviato da capitan_crasy

E' da mesi ormai che dico di non basarsi sulle percentuali rilasciate da AMD per stabilire le prestazioni di Bulldozer....

Comunque ha risposto in quel modo perché non è quello che hanno detto. Le percentuali erano riferite ad un ipotetico dual core con un solo int per core. Quindi a parità di architettura.
Inutile quindi usare quel 80% per cercare di capire le prestazioni, visto che si riferisce a se stesso

[Ares17]

Originariamente inviato da cionci

Comunque ha risposto in quel modo perché non è quello che hanno detto. Le percentuali erano riferite ad un ipotetico dual core con un solo int per core. Quindi a parità di architettura.
Inutile quindi usare quel 80% per cercare di capire le prestazioni, visto che si riferisce a se stesso

Difatti serve solo a valutare a spanne il rapporto superfice-modulo/ipc,
superfice-dualcore/ipc

[capitan_crasy]

Ecco finalmente la conferma ufficiale!
Come più volte ipotizzato sul thread del K10 il progetto originale di Bulldozer prevedeva l'utilizzo dei 45nm SOI; l'uscita era prevista per fine 2009 e doveva scontrarsi con le CPU Nehalem di Intel.
Durante lo sviluppo il progetto Bulldozer a 45nm fu abbandonato e rivisto (aggiunta delle istruzioni AVX e abbandono delle SSE5) per i 32nm SOI.
AMD non specifica cosa andò storto e se il vecchio Bulldozer era uguale al nuovo come concetto architetturale, tuttavia nei mesi che seguirono su intrapresa la configurazione di tipo MCM per le CPU Opteron a 8/12 core e l'utilizzo del Low-k sulle CPU Six core Thuban destinate al mercato Desktop.

“How much resemblance does your today’s Bulldozer architecture have to the original design?” – Tye

As you are aware, when we initially designed “Bulldozer,” we were working with a more modular processor design. The original “Bulldozer” design was 45nm. But as development progressed, it became clear that the 45nm design that we had been working on was not going to be as competitive as we would have liked.

With the world watching your every move, all product decisions become very public (how many articles have you seen about “Bulldozer” in the press?) It is never an easy decision to make substantial changes to your product roadmap, but sometimes you have to make the tough call because it is the right thing to do. It helps when your partners are behind you and agree with the changes – sometimes a little short-term pain is necessary for a long-term gain.

We obviously aren’t going to get into specific design changes, but we think that the 32nm “Bulldozer” can bring a lot of benefit to our product due to smaller transistor size (which can help drive down the power envelope). By going for lower power, we hope to give you more room for compute cores, FP capabilities and more.

In addition, bringing the AMD Opteron™ 6100 Series processors to market allowed us to deliver an MCM design to market, which validated that technology. Having the SR5600 series chipsets, with more than a year under their belt, means that platform validation should be much easier for our partners. One of the biggest beneficiaries of a 32nm design is not necessarily a new technology added to the processor as much as it is the socket, chipset and platform work that happened ahead of the “Bulldozer” release.

Clicca qui...