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

[Gigamez]

Originariamente inviato da Pihippo

Ciao
forse ho capito cosa intendi
Dunque a meno di non aver cannato completamente l'articolo http://www.agner.org/optimize/microarchitecture.pdf
I decoder generano le macro ops, lo scomponimento in micro ops avviene quando entrano negli issue slot, e poi ricomposti, questo succede sia per istruzioni Int che fpu ,ovvero il retirement buffer è condiviso tra alu e fp unit.

http://www.hwupgrade.it/forum/showpo...postcount=3254

Io la sapevo cosi' (dimmi se penso male!):
le macro-operazioni sono le operazioni richieste dal programma in esecuzione. Le macro operazioni sono le operazioni complesse relative in questo caso all'ISA x86, un ISA CISC, appunto (quindi in grado di supportare operazioni complesse).
I processori per poter eseguire queste macro-ops devono prima scomporle in micro-ops (RISC) , attraverso la fase di decode, e poi eseguire queste singole micro-ops (fase execute), per poi ricomporle nei risultati "complessi" che il programma si sarebbe aspettato (quello che fanno le retire units), e quindi renderle disponibili al programma stesso, scrivendone i risultati in memoria (fase di write-back).

Ad esempio (esempio stupido) se esegui una potenza sara' una operazione intera, ma a livello di unità intere non hai la possibilità di eseguirla direttamente. Userai quindi le alu (parallelizzando i calcoli) per eseguire n volte la moltiplicazione come se fosse un albero, utilizzando tanti figli quante unità ALU avrai nella tua INT unit. Moltiplicherai tra loro i risultati di ogni "foglia" componendo il risultato finale nelle retire units. Una volta avrai il tuo "macro" risultato potrai restituirlo al programma che te lo ha chiesto, rendendoglielo disponibile in memoria (fase di writeback).

ora da queste mie "nozioni" (che ripeto, potrebbero essere sbagliate) guarda questa figura:


Come vedi le due unità intere (cores) hanno un solo fetch ed un solo decoder, pur avendo ognuno la sua retire. Sappiamo inoltre che la cache l1 relativa alle istruzioni è UNIFICATA per entrambi. La mia ipotesi parte appunto da queste considerazioni, ed in effetti non sarebbe un vero e proprio "reverse hyperthreading" (lo sarebbe forse a livello di "micro-istruzioni"), in quanto agirebbe alternativamente su due unità intere senza creare un vero e proprio altro thread, ma gestendo l'unico esistente in maniera alternata e potenzialmente doppia. L'output sarebbe comunque seriale ed identico a quello di processori con singolo core.

Il paragone con l'SLI calza a pennello:

Preso da wikipedia (http://it.wikipedia.org/wiki/Scalable_Link_Interface):

Dal driver della scheda video è possibile selezionare 2 criteri differenti di ripartizione del carico di lavoro tra le schede video operanti in parallelo:

* Alternate Frame Rendering (AFR): il rendering della scena viene eseguito in modo sequenziale, con la prima scheda che renderizza i frames pari e l'altra quelli dispari.
* Split Frame Rendering (SFR): con questa tecnica il rendering di ogni frame viene diviso tra le due schede. La percentuale di rendering può essere 50-50, ma anche divisa dinamicamente tra le due schede a seconda del tipo di applicazione che viene eseguita.

Considera appunto il primo caso, ed immagina l'output seriale come la sequenza di frame che vedi su schermo.
Ogni frame e' la tua MACRO istruzione, composta da tantissime micro-istruzioni (calcoli sui vertici, effetti, ecc.ecc.)
Hai 2 GPU, ed ognuna di loro si alterna nei calcoli relativi ad una Macro-istruzione (frame), restituendoti una sequenza seriale (la visione di una schena 3d) potenzialmente al doppio della velocità.

Io ragiono in macro-istruzioni. Che poi vengano scomposte e gestite da N alu dove ognuna lavorerà ad una singola micro-istruzione non mi importa, perche' dovresti comunque ragionare come se la loro portata (in input ed in output) fosse virtualmente "doppia", capisci cosa intendevo?

[calabar]

Originariamente inviato da paolo.oliva2

Se BD X4 si posizionasse tra SB X4 e SB X6, probabilmente un BD X8 potrebbe contrastare un SB X10.

Secondo me questa affermazione va oltre ogni ragionevole ottimismo.

Si è passati da un "speriamo che BD x6 competa con SB x4" al capovolgimento completo di fronte.

A mio parere BD andrà meno di SB a parità di core fisici, per tanti motivi:
- i core di BD condividono risorse, quindi se usati entrambi i core in un solo modulo, ci sarà un calo di prestazioni (quello famoso stimato intorno al 20%).
- i core SB potranno processare ognuno due thread, in certi ambiti i migliramenti prestazionali sono sensibili.
- codice ottimizzato intel

Questo naturalmente non è di per se un male: strutturare BD in quel modo è una scelta architetturale che si spera porti nel complesso vantaggi rispetto a SB.
Ma in un raffronto core-to-core dubito che SB finirà in svantaggio.
Se poi dovesse succedere, tanto meglio per AMD!

[cionci]

Già altri siti hanno detto che a parità di frequenza e core BD andrà meno di SB. Probabilmente avrà un IPC maggiore di Phenom II, ma sicuramente minore di SB. E questo mi pare assodato.
Però se si ragionasse a parità di core e di TDP invece la situazione probabilmente cambierebbe

[capitan_crasy]

Originariamente inviato da cionci

Già altri siti hanno detto che a parità di frequenza e core BD andrà meno di SB. Probabilmente avrà un IPC maggiore di Phenom II, ma sicuramente minore di SB. E questo mi pare assodato.
Però se si ragionasse a parità di core e di TDP invece la situazione probabilmente cambierebbe

Ma anche no, caro cionci...

[cionci]

Originariamente inviato da capitan_crasy

Ma anche no, caro cionci...

Secondo me è così, c'è poco da fare. Si parla del 10-15% di IPC in più rispetto ad un Phenom II, quindi è impossibile che abbia un IPC maggiore del SB. Dovrebbe avere un IPC superiore almeno del 20-25% rispetto ad un Phenom II...

[capitan_crasy]

Originariamente inviato da cionci

Secondo me è così, c'è poco da fare. Si parla del 10-15% di IPC in più rispetto ad un Phenom II, quindi è impossibile che abbia un IPC maggiore del SB. Dovrebbe avere un IPC superiore almeno del 20-25% rispetto ad un Phenom II...

Ma il problema è chi parla del 15% o del 10% o qualsiasi altra percentuale sono solo voci o rumors, non esiste nessuna conferma del IPC di bulldozer sul K10 ne su SB.
La verità è che nessuno di noi, nelle nostre personali teorie, può dare o quantificare in modo esatto le prestazioni di BD...

[cionci]

Originariamente inviato da capitan_crasy

Ma il problema è chi parla del 15% o del 10% o qualsiasi altra percentuale sono solo voci o rumors, non esiste nessuna conferma del IPC di bulldozer sul K10 ne su SB.
La verità è che nessuno di noi, nelle nostre personali teorie, può dare o quantificare in modo esatto le prestazioni di BD...

In modo esatto è impossibile, ma non c'è un sito o forum fra tutti quelli che hanno analizzato a fondo l'architettura che assegna un aumento di IPC maggiore del 15%. Questo credo che qualcosa voglia dire. Ben venga se fosse superiore, ma al momento attuale, viste le caratteristiche del progetto, nessuno pensa o spera che lo sia.

[capitan_crasy]

Originariamente inviato da cionci

In modo esatto è impossibile, ma non c'è un sito o forum fra tutti quelli che hanno analizzato a fondo l'architettura che assegna un aumento di IPC maggiore del 15%. Questo credo che qualcosa voglia dire. Ben venga se fosse superiore, ma al momento attuale, viste le caratteristiche del progetto, nessuno pensa o spera che lo sia.

Vuol dire che ci sono rumors non confermati che parlano di un IPC del 15% ma niente di sicuro o di certo, inoltre ragionare sulla carta è un conto ma i numeri reali sul campo sono tutt'altra cosa e questo vale anche in caso di risultati negativi...

[cionci]

Originariamente inviato da capitan_crasy

Vuol dire che ci sono rumors non confermati che parlano di un IPC del 15% ma niente di sicuro o di certo, inoltre ragionare sulla carta è un conto ma i numeri reali sul campo sono tutt'altra cosa e questo vale anche in caso di risultati negativi...

Allora chiudiamo il thread ed aspettiamo che esca

[bjt2]

Non esiste solo l'IPC...
Esiste anche la frequenza...
E le latenze delle caches, le promesse di global foundries, le voci sul FO4 minore (che sarebbero confermate dalle latenze delle caches maggiori) fanno supporre che saranno moooolto alte.
Anche ammesso che l'IPC del BD non arrivi a quella del SB, ci sono buone speranze di clock di base del 30% superiori e di clock turbo anche oltre il 30% superiori...

Se il TDP e sopratutto il consumo reale (in idle e full load) sono comparabili, chi se ne frega se per avere le stesse prestazioni (o superiori) BD deve avere un GHZ in più...

[cionci]

Originariamente inviato da bjt2

Anche ammesso che l'IPC del BD non arrivi a quella del SB, ci sono buone speranze di clock di base del 30% superiori e di clock turbo anche oltre il 30% superiori...

Se il TDP e sopratutto il consumo reale (in idle e full load) sono comparabili, chi se ne frega se per avere le stesse prestazioni (o superiori) BD deve avere un GHZ in più...

Appunto, è esattamente quello che intendevo io...

[paolo.oliva2]

Originariamente inviato da calabar

Secondo me questa affermazione va oltre ogni ragionevole ottimismo.

Si è passati da un "speriamo che BD x6 competa con SB x4" al capovolgimento completo di fronte.

A mio parere BD andrà meno di SB a parità di core fisici, per tanti motivi:
- i core di BD condividono risorse, quindi se usati entrambi i core in un solo modulo, ci sarà un calo di prestazioni (quello famoso stimato intorno al 20%).
- i core SB potranno processare ognuno due thread, in certi ambiti i migliramenti prestazionali sono sensibili.
- codice ottimizzato intel

Questo naturalmente non è di per se un male: strutturare BD in quel modo è una scelta architetturale che si spera porti nel complesso vantaggi rispetto a SB.
Ma in un raffronto core-to-core dubito che SB finirà in svantaggio.
Se poi dovesse succedere, tanto meglio per AMD!

Io seguivo il ragionamento di Cionci, che avendo riportato che un BD X4 (può darsi) che si posizioni tra SB X4 e SB X6, quindi, mettendolo ai numeri, = SB X5.
visto AMD in multicore sprinta meglio e il clock lo aiuta per via di un minor leakage,
un BD X8 = SB X10.

Inoltre, visto che BD sarebbe in commercio almeno 8 mesi prima di SB X10, sarebbe presumibile un ulteriore step sia di silicio che di procio...

[capitan_crasy]

Originariamente inviato da cionci

Allora chiudiamo il thread ed aspettiamo che esca

bè questo no, volevo solo sottolineare che la frase "ormai è assodato" è azzardata...

Originariamente inviato da bjt2

Non esiste solo l'IPC...
Esiste anche la frequenza...
E le latenze delle caches, le promesse di global foundries, le voci sul FO4 minore (che sarebbero confermate dalle latenze delle caches maggiori) fanno supporre che saranno moooolto alte.
Anche ammesso che l'IPC del BD non arrivi a quella del SB, ci sono buone speranze di clock di base del 30% superiori e di clock turbo anche oltre il 30% superiori...

Se il TDP e sopratutto il consumo reale (in idle e full load) sono comparabili, chi se ne frega se per avere le stesse prestazioni (o superiori) BD deve avere un GHZ in più...

Le ultime voci su Bulldozer parlano dell'importanza della grandezza della cache L2 e di come possa essere molto più determinante di quanto sia nell'architettura K10...
Inoltre il nuovo controller RAM e la cache L3 saranno in grado di aumentare la banda passante; tutte cose che AMD non ha accennato alla presentazione di bulldozer...

[affiu]

io non sono certo un esperto ,ma bulldozer è qualcosa che è stato progettato per essere il numero ''uno'' sia in single che multi-tread;ora questa cosa puo ,chiaramente,avverarsi oppure non completamente(è pure progettato per la futura scalabilità dei moduli,che rappresentano la piu piccola unità logica che riesce ad auto gestirsi) ;ora senza tifare per uno o l'altro ,ma semplicemente mi viene il dubbio proprio che il 32nm e proprio quello idoneo(per il momento) come processo, perchè le pipeline proprio per ''svuotarsi'' richiederanno alte(e pure spinte) frequenze.(se non si'' intoppano troppo e si ingoffano'')...ed il turbo farà vedere il suo ''senso'' a frequenze già spinte

è chiaro che anche le slide siano soggette a variazioni(per la teoria della possibilità) ma in una slide amd del 26 july 2007 i nuovi core ''bulldozer'' venivano(ci sognavo che sarebbe uscito a 45 nm con 8 core sandiger,ma la sfida prese un altra via...vediamo ora la ''RIPROPOSTA'' ) proiettati ad avverarsi come(in alcuni aspetti descrittivi)

''CONTINUED scaling for single-tread performance''

''designed to be the highest performing single and multi-threaded compute core in history ''

dichiararmi incredulo a questo non avrebbe senso ,e neanche tanto meno pensare di garantirmi la sfida impostandomi come solo ottimista sognatore,ma una cosa non perdo mai d'occhio;che tutt'altro è che una parte di un disegno all'orizzante molto più ampio e piu VARIO(ci sara pure ati dentro il processore)

e tutto questo che ci aspettiamo non è solo una trepida attesa....ma anzi tutt'altro ,....l'inizio di un gradevole viaggio verso il futuro...verso il vero ''CORE'' della fusione

[paolo.oliva2]

Secondo me, per avere una situazione il più possibile vicina alla realtà, dobbiamo partire da questo punto:

Il 32nm HKMG AMD permetterà un margine del 33% sopra al clock Intel sia nella condizione Turbo che in quella stock per tutti i core.

Vantaggio Intel odierno sul Phenom II (Valori IPC approssimativi e, proprio per cercare un esempio concreto, non ho certo riportato differenze di IPC scarse, anzi, tutt'altro)

i7 = 30% di IPC maggiore del Phenom II.
SB = 45% di IPC maggiore del Phenom II.

Ora, rapportando un IPC per BD = a quello del Phenom II con il clock del 32nm HKMG AMD, uscirebbe questo:

Un i7 avrebbe una potenza (IPC x clock) del 3% inferiore a BD.
Un SB avrebbe una potenza (IPC x clock) del 12% superiore a BD.

Discutere poi se l'IPC di BD sia = al Phenom II, sia del 15% superiore, ok, si può ipotizzare qualsiasi IPC, ma comunque rimane di fatto che a tutti gli effetti già solo per il clock un BD si posizionerebbe sopra di poco un X4 i7 e sotto di poco ad un SB X4.

Con queste differenze, se già andassimo a teorizzare un BD X8 vs SB X8, visto la scalabilità migliore degli AMD, non mi sembra azzardato già reputare per certo una parità.

Se fino a qui siamo concordi, questo vorrebbe dire che BD senza incrementi di IPC rispetto ad un Phenom II si posiziona alla pari rispetto ad un SB. Ma... se ci fossero variazioni positive di IPC in BD, mi sembra abbastanza chiaro che BD andrà più di SB.

Ora... se AMD ha creato BD con l'intento di contrastare SB, IPC o non IPC, direi che l'obiettivo è centrato.
Sarebbe veramente interessante se nel secondo trimestre 2011 AMD commercializzasse BD X8 a 400€. Cosa darei per vedere la faccia dei commerciali Intel nel rivedere il loro listino

[Pihippo]

Originariamente inviato da Gigamez

http://www.hwupgrade.it/forum/showpo...postcount=3254

Io la sapevo cosi' (dimmi se penso male!):
le macro-operazioni sono le operazioni richieste dal programma in esecuzione. Le macro operazioni sono le operazioni complesse relative in questo caso all'ISA x86, un ISA CISC, appunto (quindi in grado di supportare operazioni complesse).
I processori per poter eseguire queste macro-ops devono prima scomporle in micro-ops (RISC) , attraverso la fase di decode, e poi eseguire queste singole micro-ops (fase execute), per poi ricomporle nei risultati "complessi" che il programma si sarebbe aspettato (quello che fanno le retire units), e quindi renderle disponibili al programma stesso, scrivendone i risultati in memoria (fase di write-back).


Ad esempio (esempio stupido) se esegui una potenza sara' una operazione intera, ma a livello di unità intere non hai la possibilità di eseguirla direttamente. Userai quindi le alu (parallelizzando i calcoli) per eseguire n volte la moltiplicazione come se fosse un albero, utilizzando tanti figli quante unità ALU avrai nella tua INT unit. Moltiplicherai tra loro i risultati di ogni "foglia" componendo il risultato finale nelle retire units. Una volta avrai il tuo "macro" risultato potrai restituirlo al programma che te lo ha chiesto, rendendoglielo disponibile in memoria (fase di writeback).

ora da queste mie "nozioni" (che ripeto, potrebbero essere sbagliate) guarda questa figura:


Come vedi le due unità intere (cores) hanno un solo fetch ed un solo decoder, pur avendo ognuno la sua retire. Sappiamo inoltre che la cache l1 relativa alle istruzioni è UNIFICATA per entrambi. La mia ipotesi parte appunto da queste considerazioni, ed in effetti non sarebbe un vero e proprio "reverse hyperthreading" (lo sarebbe forse a livello di "micro-istruzioni"), in quanto agirebbe alternativamente su due unità intere senza creare un vero e proprio altro thread, ma gestendo l'unico esistente in maniera alternata e potenzialmente doppia. L'output sarebbe comunque seriale ed identico a quello di processori con singolo core.

Il paragone con l'SLI calza a pennello:

Preso da wikipedia (http://it.wikipedia.org/wiki/Scalable_Link_Interface):


Considera appunto il primo caso, ed immagina l'output seriale come la sequenza di frame che vedi su schermo.
Ogni frame e' la tua MACRO istruzione, composta da tantissime micro-istruzioni (calcoli sui vertici, effetti, ecc.ecc.)
Hai 2 GPU, ed ognuna di loro si alterna nei calcoli relativi ad una Macro-istruzione (frame), restituendoti una sequenza seriale (la visione di una schena 3d) potenzialmente al doppio della velocità.

Io ragiono in macro-istruzioni. Che poi vengano scomposte e gestite da N alu dove ognuna lavorerà ad una singola micro-istruzione non mi importa, perche' dovresti comunque ragionare come se la loro portata (in input ed in output) fosse virtualmente "doppia", capisci cosa intendevo?

Ciao
E' vero che l'isa x86 sia CISC, ma ogni istruzione non è una macro ops, ovvero una LEA m->r ad esempio , calcola l'effettivo indirizzo di un operando (m) e lo salva in un registro R, come puòi vedere si tratta di operazioni scomponibili in un calcolo dell'indirizzo (AGU) e suo store in registro (gprs od i registri architetturali) specificato. Bene nelle arhcitetture amd i decoder leggono questa istruzione e la decodificiano in una singola mop, in intel invece si avranno diverse micro op, ma l'istruzione x86 è sempre una.
Queste sono le fasi del decoding fetch del k10\k8
1. Instruction fetch 1. 32 bytes per clock cycle on K10, 16 bytes on K7 and K8.
2. Instruction fetch 2 and branch prediction.
3. Pick/Scan. Can buffer up to 7 instructions. Distributes three instructions into the
three decoder pipelines. The following stages are all split into three parallel pipes.
4. Decode 1. Splits the instruction codes into their components.
5. Decode 2. Determines input and output registers.
6. Pack. Up to six macro-operations generated from the decoders are arranged into
lines of three macro-operations for the three execution pipelines.
7. Pack/Decode. Register renaming. Integer registers are read from the "Integer Future
File and Register File". Submits integer macro-operations to the three integer pipes.
Submits floating point macro-operations to the floating point pipes.

Un punto per il reverse hypertreading, le L d dovrebbero avere delle porte di comunicazione cosi come le L\S unit...

[astroimager]

Mamma mia, ho esigenze quasi immediate di mobilità... quando vedremo secondo voi le prime soluzioni Ontario (a prezzi non da latrocinio)?

[capitan_crasy]

Originariamente inviato da astroimager

Mamma mia, ho esigenze quasi immediate di mobilità... quando vedremo secondo voi le prime soluzioni Ontario (a prezzi non da latrocinio)?

primi mesi del 2011 (forse già a gennaio)...

[astroimager]

Originariamente inviato da capitan_crasy

primi mesi del 2011 (forse già a gennaio)...

Sarà dura resistere... 2 giorni fa stavo già per cedere (cornificando AMD)!

Sono anche un po' preoccupato da questo:
http://www.hwupgrade.it/articoli/por...-vision_5.html

Speriamo di vedere presto una paronamica completa sulle prestazioni (ivi inclusi i consumi)!

[Pihippo]

Originariamente inviato da astroimager

Sarà dura resistere... 2 giorni fa stavo già per cedere (cornificando AMD)!

Sono anche un po' preoccupato da questo:
http://www.hwupgrade.it/articoli/por...-vision_5.html

Speriamo di vedere presto una paronamica completa sulle prestazioni (ivi inclusi i consumi)!

Ciao
A chi lo dici. Chi non ha mai provato un netbook con atom non può capire
Dal mio phII 3.7GHZ al netbook con atom ho sentito una differenza pazzesca, 3 ore per apire una slide od estrarre un archivio ... Eppure pure io purtroppo ho esigenze di mobilità da netbook però sta cpu fa veramente troppo schifo
Ontario dove sei?