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

[paolo.oliva2]

Inoltre... nel monocore nel confronto BD vs K10.

Si era detto che l'i7 era avvantaggiato (oltre all'innegabile IPC superiore), anche per la struttura della L3 "circolare".

In questo caso, con BD, passando da una L2 di 512KB ad un L2 da 2MB (condivisa tra i 2 core del modulo), in parte non allieverebbe una L3 costantemente allineata al multicore?

Cioè... avrebbe una capacità 4 volte superiore alla L2 del K10, e comunque anche se condivisa, se i 2 core del modulo operassero una sorta di paralleismo anche in mono TH, attingerebbero sempre su 2MB di L2.

Inoltre, e qui sono nubbio... se i Load e Store sono ciclici, o operandi simili, non potrebbero avvalersi della condivisione dei core in un'ottica monocore?
Cioè... se io devo trasferire dei dati dalla L2 e prima devo scrivere il risultato dai registri del procio... questa condivisione non potrebbe generare che in un ciclo posso fare 2 operazioni?
Cioè contemporaneamente leggere e scrivere? Capisco che le pipeline sarebbero comunque 2, ma si potrebbe ipotizzare dei jump dall'una all'altra un po' come passare da un'autostrada a 2 corsie ad una "teorica" 4 corsie?

[mack.gar]

Ciao a tutti.
Ho letto le ultime pagine del thread, tutto molto interessante. Vorrei aggiungere alcune cose:
1) JF ha detto (a meno di non perderci la faccia) che BD ha prestazioni in single thread migliori di K10 e una slide di hot chip (la 16 per inciso) viene riportata la stessa promessa. E' probabile che questo obbiettivo sia raggiunto sia dal clock più alto che da ipc migliore. Il "quanto" meglio penso che non sia possibile stimarlo allo stato attuale.
2) Ogni "core" può gestire due load E uno store per ciclo.
3) le LS unit sono duplicate per "core" vedi slide hot chip
4) il numero di istruzioni ritirate per core non è un dato dichiarato...

[cionci]

Originariamente inviato da bjt2

Se la FPU del Bulldozer possa spezzare l'FMAC in 1 MUL + 1 ADD indipendenti per ciclo, la potenza è doppia, ma condivisa tra due thread, rispetto a quella del K10. Anzi, più che doppia, visto che le unità chiamate MMX si occupano dei calcoli legacy x87 e che le operazioni di memoria sono state appioppate all'unità intera.

Se fosse così sarei d'accordo, ma credo che l'avrebbero messo ben in evidenza nella presentazione.

Originariamente inviato da paolo.oliva2

Perché logici? BD ha 4 moduli con 2 core ciascuno... con delle parti in comune, ma sono sempre fisici.

Sono logici, se fossero fisici non avrebbero i primi stage della pipeline in comune. Inoltre sulla FPU di fatto AMD sta facendo un vero e proprio HyperThreading, quindi più logici di così...

[bjt2]

Originariamente inviato da Pihippo

Ciao bjt2
Grazie per l'intervento, in pratica bd pur con un numero minore di ex unit sarebbe più efficiente del k10 nell'esecuzione di calcoli. Un altre cosa, anche intel splitta le macro op in micro op cosi da avere più flessibilità ed efficienza?

Intel non ha per nulla le macro-op. Le sue micro op sono semplici (o almeno più semplici di quelle del k10) e sono a 3 operandi. Anche per questo non potrà implementare le FMAC a 4 operandi a meno di stravolgimenti architetturali... E anche per questo ha un FO4 leggermente inferiore. Poichè Bulldozer ha un FO4 di 17 per poter implementare le macro-op con la stessa complessità del K10 avrebbe dovuto usare più stadi del K10 (forse troppi). IMHO si è passati a micro-op più semplici (e a detta dell'ex ingegnere AMD su google gruppi senza alcuni meccanismi di forwarding avanzati) per evitare il proliferare di stadi della pipeline...

[mack.gar]

http://www.realworldtech.com/page.cf...WT082610181333

[bjt2]

Originariamente inviato da Ren

Quindi secondo te fonderanno le istruzioni di due thread per occupare al massimo una singola FMA, riducendo così anche la pressione sulla operazioni di memoria.

Mi viene spontaneo chiedere se i due thread basteranno ad occupare le due FMAC...

Secondo te le legacy si occuperanno dei calcoli fp non vettoriali (x87) o si limiteranno alle istruzioni intere previste dalle estensioni medesime ?

Beh, le FMAC si possono occupare entrambe. Non esistono soltanto ADD e MUL fully pipelined. Dubito che la divisione sia fully pipelined, quindi se una MUL è occupata con una DIV, l'altra deve giocoforza alternarsi per i thread. Daltronde le slides di qualche anno fa dipingevano Bulldozer come un mostro FP...

Io penso che le unità chiamate MMX siano fisicamente attaccate a i due banchi di registri MMX/FP80 e che quindi eseguano tutte le istruzioni intere (MMX a 64 bit) e FP (x87 a 32/64/80 bit) su quei registri e che le FMAC siano fisicamente attaccate ai due banchi di registri XMM/YMM ed eseguano tutte le istruzioni SSEn/AVX/XOP... Poichè c'è il limite di dispatch di 4 istruzioni per clock, è da vedere come e se hanno implementato la MUL e la ADD staccata... Sarebbe un peccato non averlo fatto visto che le FMAC saranno rare... Le pipeline sarebbero almeno 6 (2 MMX 2 ADD e 2 MUL) se non 8 (2 MMX 2 ADD 2 MUL e 2 FMAC con queste ultime esclusive rispetto a MUL e ADD).
Purtroppo il modo più semplice e lineare sarebbe di avere 4 issue per clock, 2 MMX/x87 e 2 SSE o 1 AVX 256 (dove ognuna può essere ADD, MUL DIV oppure FMAC) con la possibilità di sfruttare al massimo la FPU solo con le FMAC, ma sarebbe, ripeto, un peccato...

Sarebbe comunque un miglioramento rispetto alla FPU di un signolo K10 e forse anche di un doppio K10...

[bjt2]

Originariamente inviato da cionci

Se fosse così sarei d'accordo, ma credo che l'avrebbero messo ben in evidenza nella presentazione.

Sono logici, se fossero fisici non avrebbero i primi stage della pipeline in comune. Inoltre sulla FPU di fatto AMD sta facendo un vero e proprio HyperThreading, quindi più logici di così...

Spero che sia solo un nascondino da parte di AMD. I brevetti ci starebbero tutti. E l'unico altro motivo di mettere delle FMAC sottoutilizzatissime al momento (visto INTEL e il software legacy) e quindi uno spreco di silicio, è una preparazione in vista dell'offload dei calcoli SSE/AVX agli SP di una eventuale GPU integrata... Ma questo è bulldozer 2 almeno...

Se tu fossi un progettista con dei vincoli di TDP, costo, dimensione die, metteresti delle FMAC ora considerando che INTEL non le avrà per almeno un anno? E considerando il flop delle SSE5?

[calabar]

Originariamente inviato da cionci

Sono logici, se fossero fisici non avrebbero i primi stage della pipeline in comune. Inoltre sulla FPU di fatto AMD sta facendo un vero e proprio HyperThreading, quindi più logici di così...

Ma non era oramai assodato che la FP non avesse alcun tipo di SMT (rumor apparso tra l'altro all'inizio, e subito smentito), quando piuttosto la possibilità di dividersi?
Perchè sono due cose ben diverse: SMT ottimizza la condivisione dell'unità fp tra più thread, mentre in questo caso si parla di usare in modo parallelo la stessa unità con istruzioni più piccole delle avx.

Per quanto riguarda i core int, quali sono le parti iniziali condivise?
Perchè si è sempre detto che la pipeline int fosse assolutamente indipendente, ossia che i due core potessero concretamente lavorare su due thread senza concorrenza. Quindi core reali, non logici.

Oltretutto ci mancherebbe pure che AMD avesse inserito SMT in BD dopo aver dichiarato ai 4 venti la propria contrarietà nei confronti di questo tipo di tecnologia.

[cionci]

Originariamente inviato da calabar

Ma non era oramai assodato che la FP non avesse alcun tipo di SMT (rumor apparso tra l'altro all'inizio, e subito smentito), quando piuttosto la possibilità di dividersi?
Perchè sono due cose ben diverse: SMT ottimizza la condivisione dell'unità fp tra più thread, mentre in questo caso si parla di usare in modo parallelo la stessa unità con istruzioni più piccole delle avx.

Se leggi l'articolo postato poco sopra, parla proprio di SMT per la FPU.
Poi che vuol dire "dividersi" ? SMT significa proprio far usare la stessa unità da più thread.

Originariamente inviato da calabar

Per quanto riguarda i core int, quali sono le parti iniziali condivise?
Perchè si è sempre detto che la pipeline int fosse assolutamente indipendente, ossia che i due core potessero concretamente lavorare su due thread senza concorrenza. Quindi core reali, non logici.

Solo la parte di esecuzione e di load/store è divisa. La prima parte di pipeline è condivisa (quella comune a tutte le istruzioni).

[cionci]

Originariamente inviato da bjt2

Se tu fossi un progettista con dei vincoli di TDP, costo, dimensione die, metteresti delle FMAC ora considerando che INTEL non le avrà per almeno un anno? E considerando il flop delle SSE5?

Come ti avevo detto qualche post fa, potrebbero essere anche altri i vincoli che hanno obbligato AMD all'uso di unità floating point più generiche:
- obbligo di esecuzione delle AVX in contemporanea sulle due unità
- fare in modo che istruzioni floating point provenienti da thread diversi avessero a disposizione unità più generiche in modo da diminuire la latenza

Originariamente inviato da mack.gar

http://www.realworldtech.com/page.cf...WT082610181333

Il dubbio sulle AVX è venuto anche a chi ha scritto quell'articolo

Another question regarding Bulldozer is how 256-bit AVX instructions are handled by the execution units. One option is to treat each half as a totally independent macro-op, as the K8 did for 128-bit SSE, and let the schedulers sort everything out. However, it is possible that Bulldozer's two symmetric FMAC units could be ganged together to execute both halves of an AVX instruction simultaneously to reduce latency.

[Pihippo]

Originariamente inviato da cionci

Se leggi l'articolo postato poco sopra, parla proprio di SMT per la FPU.
Poi che vuol dire "dividersi" ? SMT significa proprio far usare la stessa unità da più thread.

Solo la parte di esecuzione e di load/store sembra essere divisa. La prima parte di pipeline è condivisa (quella comune a tutte le istruzioni).

Ciao
L'articolo di Kanter si basa su quello finora emerso all'hotchip, ovvero ben pochi dettagli succosi. Io però non capisco cosa c'entri l'smt con la fpu di BD?
Essa viene divisa tra 2 core, però è quasi il doppio più grande di quella del k10 ed ogni ciclo può accettare istruzioni da un qualsiasi dei 2 core.

[cionci]

Originariamente inviato da Pihippo

ogni ciclo può accettare istruzioni da un qualsiasi dei 2 core.

Io questo lo chiamo SMT (non core, ma thread, nell'intera pipeline FP non c'è alcuna suddivisione in core, tranne forse nella Load/Store unit).

Perché dici che è il doppio più grande ?

[Pihippo]

Originariamente inviato da cionci

Io questo lo chiamo SMT.

Perché dici che è il doppio più grande ?

Ciao
Però nel smt le risorse vengono dimezzate tra 2 thread concorrenti come r.o.b scheduler ed unità di esecuzione. Qui invece mi pare che la fpu abbia abbastanza per tutti.
Io penso sia più grande la fpu poichè vi sono 2 pipeline 128bit e secondo le speculazioni di Dresdenboy sono dual ported verso la cache. http://www.realworldtech.com/page.cf...2610181333&p=7
Anche lo scheduler fp è raddoppiato di ampiezza (da 32 a 60 issue slot)..

[paolo.oliva2]

Originariamente inviato da cionci

Io questo lo chiamo SMT (non core, ma thread, nell'intera pipeline FP non c'è alcuna suddivisione in core, tranne forse nella Load/Store unit).

Perché dici che è il doppio più grande ?

Penso perché ora è 256 anziché 128. Che poi possa essere divisa e eseguita contemporaneamente dai 2 core, è un conto, ma se lavorasse solo un core, non sarebbe doppia a tutti gli effetti?

Comunque io sto cortocicuitando i miei neroni... ormai non sono più sicuro nemmeno se BD X8 ha 4 moduli... .
A parte gli scherzi... avevo le idee più chiare il 23 agosto...

[Pihippo]

Originariamente inviato da paolo.oliva2

Penso perché ora è 256 anziché 128. Che poi possa essere divisa e eseguita contemporaneamente dai 2 core, è un conto, ma se lavorasse solo un core, non sarebbe doppia a tutti gli effetti?

Comunque io sto cortocicuitando i miei neuroni... ormai non sono più sicuro nemmeno se BD X8 ha 4 moduli... .
A parte gli scherzi... avevo le idee più chiare il 23 agosto...

A chi lo dici
Leggendo l'articolo di Dkanter mi pare di aver visto tutt'altra architettura dalle slide dell'hot chips.

[cionci]

Originariamente inviato da Pihippo

Ciao
Però nel smt le risorse vengono dimezzate tra 2 thread concorrenti come r.o.b scheduler ed unità di esecuzione. Qui invece mi pare che la fpu abbia abbastanza per tutti.

Anche qui vengono dimezzate. Con un solo thread che esegue operazioni floating point la FPU è completamente a disposizione del singolo thread. Con due thread le unità di esecuzione sono comunque mediamente dimezzate.
Anche in Instambul c'erano due pipeline a 128 bit, anche se più specializzate (una FMUL e una FADD).

paolo.oliva2: guarda sopra.

[bjt2]

Originariamente inviato da mack.gar

http://www.realworldtech.com/page.cf...WT082610181333

Questo articolo è SPETTACOLARE! Dice praticamente tantissime cose. Non sono speculazioni dell'autore. Questo si deve essere registrato tutto quanto detto dal tizio AMD ad Hotchips... In confronto le altre recensioni non dicono NULLA!

Le cose più interessanti sono il cambio radicale delle varie code: prima c'erano code separate per ognuna delle 6(+3) unità di esecuzione. Una volta messa li una istruzione non poteva spostarsi. Ora c'è una coda unica per gli interi/memoria e una coda unica per gli FP. Chi ha studiato teoria delle code sa che la coda unica è molto meglio (e infatti se ne sono accorti anche alle poste italiane). L'unità FP è SMT like (una volta buttate le istruzioni lì dentro vanno per fatti loro), la banda L1/L2 è molto aumentata (Ogni core ha la stessa banda di Sandy Bridge, ma quest'ultimo deve gestire 2 Threads), l'unità FP è molto efficiente: le unità MMX fanno le SIMD intere (a 64/128 bits: mi sbagliavo prima) e le FMAC fanno le floating point e alcune altre (shuffle e logiche), am sembra che le MUL e le ADD non siano separate (o almeno il tizio AMD non l'ha menzionato). Una cosa positiva: la latenza delle L1 e L2 è relativamente alta: 4 cicli la L1 e 23 (mi pare) la L2. E' moooolto alta. Questo può voler dire che il clock di Bulldozer sarà MOLTO alto.

[paolo.oliva2]

Originariamente inviato da cionci

Anche qui vengono dimezzate. Con un solo thread che esegue operazioni floating point la FPU è completamente a disposizione del singolo thread. Con due thread le unità di esecuzione sono comunque mediamente dimezzate.
Anche in Instambul c'erano due pipeline a 128 bit, anche se più specializzate (una FMUL e una FADD).

paolo.oliva2: guarda sopra.

mmm
Mi accuccio di lato perché devo riordinare le idee.
Cioè... devo resettarmi e reinquadrare BD ex-novo.
C'è un qualche cosa che non mi torna...

Se BD è il miglioramento del K10... cioè, siamo passati da 2 core fisici del K10 a 2 logici di BD? in più con un 20% in meno di IPC? Allora... AMD si baserebbe esclusivamente sull'aumento del clock.

Cioè... allora sarebbe bastato fare un mix tra Llano e Thuban, cioé immettere Turbo e spegnimento dei core di Lano, toglierci l'APU, magari mettendo il supporto AVX, aggiungerci 2 core. Praticamente... se si fossero messi a farlo dall'uscita del Thuban in previsione del 32nm, sarebbe uscito ancor prima di Llano.

[carlottoIIx6]

Originariamente inviato da paolo.oliva2

mmm
Mi accuccio di lato perché devo riordinare le idee.
Cioè... devo resettarmi e reinquadrare BD ex-novo.
C'è un qualche cosa che non mi torna...

Se BD è il miglioramento del K10... cioè, siamo passati da 2 core fisici del K10 a 2 logici di BD? in più con un 20% in meno di IPC? Allora... AMD si baserebbe esclusivamente sull'aumento del clock.

Cioè... allora sarebbe bastato fare un mix tra Llano e Thuban, cioé immettere Turbo e spegnimento dei core di Lano, toglierci l'APU, magari mettendo il supporto AVX, aggiungerci 2 core. Praticamente... se si fossero messi a farlo dall'uscita del Thuban in previsione del 32nm, sarebbe uscito ancor prima di Llano.

bisogna distingue tra
1) comportamento in single
2) comportamento in multi

1)comportamento in single:
bhe, se un core integer occupa tutto lo scheduler fp
ci sarà un incremento di ipc, a mio avviso (un core integer più fp in bd sono più grandi di un core k10)

2a)comportamento in multi:
qui conta avere più thread fisici, dunque se sulla stessa area ci sono
8 core in invece che 4 (anche se singolarmente più performanti)
mel complesso ci sarà un aumento di ipc (due core di bl sono più forti di un k10)

2b)comportamento in multi con sceheduler fp condiviso:
qui si apre la possibilità di un ulteriore ottimizzazione dovuta al dialogo

secondo me questo è tutto

PS ancora non ho letto l'articolo

[carlottoIIx6]

Originariamente inviato da bjt2

Questo articolo è SPETTACOLARE! Dice praticamente tantissime cose. Non sono speculazioni dell'autore. Questo si deve essere registrato tutto quanto detto dal tizio AMD ad Hotchips... In confronto le altre recensioni non dicono NULLA!

Le cose più interessanti sono il cambio radicale delle varie code: prima c'erano code separate per ognuna delle 6(+3) unità di esecuzione. Una volta messa li una istruzione non poteva spostarsi. Ora c'è una coda unica per gli interi/memoria e una coda unica per gli FP. Chi ha studiato teoria delle code sa che la coda unica è molto meglio (e infatti se ne sono accorti anche alle poste italiane). L'unità FP è SMT like (una volta buttate le istruzioni lì dentro vanno per fatti loro), la banda L1/L2 è molto aumentata (Ogni core ha la stessa banda di Sandy Bridge, ma quest'ultimo deve gestire 2 Threads), l'unità FP è molto efficiente: le unità MMX fanno le SIMD intere (a 64/128 bits: mi sbagliavo prima) e le FMAC fanno le floating point e alcune altre (shuffle e logiche), am sembra che le MUL e le ADD non siano separate (o almeno il tizio AMD non l'ha menzionato). Una cosa positiva: la latenza delle L1 e L2 è relativamente alta: 4 cicli la L1 e 23 (mi pare) la L2. E' moooolto alta. Questo può voler dire che il clock di Bulldozer sarà MOLTO alto.

mentre il comportamento in smulti sembra ovvio e scontato!
in single non si capisce...
amd può computere solo con la frequenza
o l'unità FP riserva sorprese???