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

[Pihippo]

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.

Ciao
Si ma le pipe del k10( tra l'altro fmul fadd e fmisc\fstore non erano dual ported con la cache Quindi ogni thread ha bene o male a disposizione le stesse, se non più risorse del k10.

[Pihippo]

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.

Ciao
Bjt2 alla luce dell'articolo di D kanter, cosa pensi sia cambiato su Bd, ovvero come ti pare la unità fp?

[cionci]

Originariamente inviato da Pihippo

Ciao
Si ma le pipe del k10( tra l'altro fmul fadd e fmisc\fstore non erano dual ported con la cache Quindi ogni thread ha bene o male a disposizione le stesse, se non più risorse del k10.

Sinceramente non mi torna, le unità di esecuzione sono quelle. Non potrò mai avere più di 2 istruzioni FP nello stesso stage (escludendo le due unità MMX), anche con 2 thread. Quindi in sostanza non potrò mai completare più di due istruzioni per ciclo di clock. Così come avveniva in K10 (anche se qui c'erano vincoli più ristretti sul tipo di istruzioni).

[papafoxtrot]

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.

Davvero interessante il discorso sulla FP.
Quanto alla latenza delle cache sinceramente non so se essere contento. La cache doveva essere rivista con l'uso di celle 8C al fine di limare la latenza e cercare di raggiungere le cache di intel, che sono parecchio veloci, e invece è più lenta di prima...

[cionci]

I 4 cicli della L1 possono anche non essere molti rispetto alla lunghezza delle pipeline. Bisognerebbe capire quanti stage ci sono prima della fase di esecuzione.

[carlottoIIx6]

cut
doppio post

si è capito perchè la fp è condivisa?
insomma perche non si sono fatti tanti piccoli core separati?

[cionci]

Originariamente inviato da carlottoIIx6

si è capito perchè la fp è condivisa?
insomma perche non si sono fatti tanti piccoli core separati?

Con tanti piccoli core separati è avrebbero fatto una CPU completamente diversa.

La FPU è in SMT per contenere il numero di transistor e per un semplice motivo: il carico in ambito server è decisamente più sulla parte interi che su quella FP.
Inoltre bisognerebbe vedere per quanto tempo un singolo thread occupava entrambe le unità di esecuzione. Probabilmente si è visto che con un approccio SMT si potevano sfruttare i tempi morti per un altro thread. In questo modo il minore numero di transistor avrebbe permesso di avere frequenze superiori recuperando lo svantaggio che la singola FPU fornisce rispetto ad un approccio con doppia FPU (e probabilmente a superarlo).

Ricordiamoci che il problema per AMD è lo svantaggio rispetto ad Intel nelle tecnologie produttive (solo dal punto di vista della miniaturizzazione, per le tecnologie di contorno Global Foundries è forse più avanti di Intel). Quindi l'unico modo per riuscire a recuperare il gap è fare un core più piccolo e che consuma meno, in modo da salire molto in frequenza.

[Pihippo]

Originariamente inviato da cionci

Sinceramente non mi torna, le unità di esecuzione sono quelle. Non potrò mai avere più di 2 istruzioni FP nello stesso stage (escludendo le due unità MMX), anche con 2 thread. Quindi in sostanza non potrò mai completare più di due istruzioni per ciclo di clock. Così come avveniva in K10 (anche se qui c'erano vincoli più ristretti sul tipo di istruzioni).

Ciao
Scusami, hai ragione http://www.agner.org/optimize/microarchitecture.pdf
Se le fp del bd sono dual ported hai 2 op per clock ritirate per unità, esattamente ciò che avviene per il k10.

[Ren]

La FPU è in SMT per contenere il numero di transistor e per un semplice motivo: il carico in ambito server è decisamente più sulla parte interi che su quella FP.
Inoltre bisognerebbe vedere per quanto tempo un singolo thread occupava entrambe le unità di esecuzione. Probabilmente si è visto che con un approccio SMT si potevano sfruttare i tempi morti per un altro thread. In questo modo il minore numero di transistor avrebbe permesso di avere frequenze superiori recuperando lo svantaggio che la singola FPU fornisce rispetto ad un approccio con doppia FPU (e probabilmente a superarlo).

Se non ricordo male la serie Power (forse la 6) ha introdotto l'esecuzione in-order per le sole unità FP che sono guarda caso delle FMA 64bit, lasciando invece la logica fuori ordine per le fixed function.

Tanto per dire che l'approccio AMD ricorda proprio l'esperienza IBM.

[paolo.oliva2]

Stavo confrontando guardando le prestazioni di un i980X con Wprime 2.03 rispetto al mio Thuban. A spanne... dovrei portare il Thuban a 4,6-4,7GHz per eguagliare (ci metto quasi 189" a 4,450GHz rispetto ad un i980X a 3,333 o a3,6GHz non ho capito bene).
Se BD non incrementa l'IPC, mica può sparare i proci a 5GHz stock...

[Athlon 64 3000+]

Magari Buldozer uscira con clock stock sui 3,4 3,6 ghz,ma avendo un turbo più aggressivo rispetto a Thuban magari arriverà sui 4,5 ghz o anche qualcosa di più per le operazione single thread.

[papafoxtrot]

Stasera ho sviscerato tutto l'articolo di realworldtecnologies, e devo dire che tutto il bulldozer è incentrato sul risparmio di area e watt. Contestualmente ad altre scelte (pipeline allungata,critical path ridotti, latenze cache alte e quant'altro) ciò permette di crescere con le frequenze.

Devo dire che sicuramente un bulldozer X6 sarà più piccolo di thuban, e non di poco. Anche se forse le cache più grandi colmeranno almeno in parte il gap. E consumerà meno. Poi c'è il processo produttivo nuovo, sebbene thuban sia sfornato con un 45nm raffinatissimo, mentre non si sa nulla sul 32nm (non bastano i nani per descrivere la bontà di un processo).

Credo che un bulldozer X6 non avrebbe problemi a sfondare i 4GHz,, e anche un X8 potrebbe avvicinarli. Forse 3,8GHz per l'X8, e magari col passare del tempo arriverà un X8 a 4GHz o qualcosina di più.

Precedentemente avevo stimato clock inferiori,Paolo ricorderà la mia ipotesi: 3,2-3,7GHz.

Se BD dovesse andare a 3,2GHz non avrebbe motivo di implementare tutte quelle soluzioni che a prima vista fanno tornare alla mente solo il P4 (per fortuna che IBM con power 6 e power 7 ha successo )

Credo che il miglioramento del prefetch e del branch predictor compenserà la perdita di efficienza dovuta alle pipe lunghe e alle cache relativamente lente. Non credo che il loro miglioramento darà un contributo netto all'aumento di prestazioni in bulldozer.

Altri aspetti della nuova architettura, quali le code uniche, ed il sostanziale (almeno a quanto ho capito) miglioramento delle cache contribuiranno ad un aumento di PC, che come avevo già ipotizzato si piazzerebbe tra il 5 ed il 15%, nelle esecuzioni INT, tenendo conto dell'efficienza del modulo, e che non so proprio stimare per quanto riguarda la FP.
Riprendendo sempre quello 0,8 di efficienza del modulo rispetto a due core indipendenti ripeto, 15% in più di IPC vorrebbe già dire 1,15/0,8=1,44 di incremento "lordo" dell'IPC del singolo core ipotetico.
Insomma riuscire a fare +44% sul singolo core secondo me è tantissimo.

Poi chissà se quellò'80% vuol dire effettivamente prestazioni INT del modulo/prestazioni int di due core indipendenti con nuova architettura.
Potrebbe anche essere il risultato di un misto tra esecuzioni int e fp...

Ad ogni modo mi attengo, per avere un indicazione, a quel +50% con +33% di core che JF-AMD aveva dichiarato, che significa da +12% (considerando uno scaling perfetto) a +16% (considerando che ogni core cresce le prestazioni del 90%) di IPC, credo in questo senso intendendo un carico di lavoro medio in ambito server, con una combinazione di operazioni FP e operazioni INT.


Insomma la mia idea: totoprestazioni
core: +33% Tenendo conto della scalabilità non perfetta all'aumentare dei core le prestazioni possono crescere di un fattore compreso tra 1,33*0,9=1,2 e 1,33/0,95=1,26. Fissiamo una massima probabilità a 1,25 e non se ne parla più
frequenza: 3,6-4GHz con massima probabilità a 3,8GHz: +12,5% - +25%, con massima probabilità a +18,75%
IPC: +5% - +15%, con massima probabilità a +12,5%.

Facendo un'analisi di rischio alla buona viene fuori che il bulldozer potrebbe andare dal +41% di thuban, al+90,0% di thuban.
Ovviamente entrambi i risultati sono estremamente improbabili, perché prodotti di fattori improbabili.
Il massimo della densità di probabilità può trovarsi al +65%, che risulta dal prodotto dei fattori più probabili, e può risultare dal prodotto di diverse combinazioni del tipo IPC pompatissimo e frequenze basse, o IPC scarsino e frequenze altissime.

Insomma, secondo me va un +60% - +70% di thuban.

Io fisso il core i7 980x al +50% di thuban: un core nehalem ha il 50% di ipc in più di un core deneb, ma all'aumentare dei core la resa diminuisce. In compenso le frequenze sono un pelo più alte (4-5%).
Il core i7 990x (primoa vversario che bulldozer dovrà battere) avrà frequenze più alte dell'8% circa e per cui sarà un 54% più veloce del 1090T.
Insomma parere mio:come massima probabilità bulldozer potrebbe superare core i7 990x di una quantità variabile tra il 5% ed il 15% delle prestazioni di thuban, cioè di una percentuale che varia tra il 3% ed il 10% di core i7 990x.

Se va male potrebbe essere più lento di un 13% delle prestazioni di thuban, cioè di un 9% delle prestazioni del core i7 990x. Se va di potrebbe essere fino al 35% (sempre riferito alle prestazioni di thuban) più veloce, pari al 22% in più rispetto a core i7 990x.

Cioè io piazzo bulldozer X8 top di gamma all'uscita tra un +20% ed un -10% del core i7 990x, con massima probabilità che si piazzi tra il -3% ed il +10% del core i7 990x.
Con +10% eguaglierebbe anche le prestazioni dei sandy bridge X6 di fascia più alta, e ciò è abbastanza probabile.

Non è un range troppo largo, ma sono fiducioso di averci azzeccato.

Mettetelo al totoprestazioni!

[papafoxtrot]

Per quanto riguarda le prestazioni in single thread la cosa è più ardua, perchP le frequenze in turbo mode sono davvero difficili da stimare...

Mettiamo una frequenza TM compresa tra 4,2 e 4,6GHz, con max probabilità a 4,4GHz.

Si tratta di un incremento variabile tra il +600MHz e +1GHz rispetto a thuban, cioè una percentuale che varia tra il +17% ed il +28% rispetto a thuban. Massima probabilità al +22%.

Come detto prima l'IPC potrebbe essere compreso tra il +5% ed il +15%, con probabilità massima al +12,5%.

Il prodotto delle probabilità fornisce un range compreso tra il +23% di thuban ed il +47% di thuban.
La variazione più probabile esce a +37% di thuban.

Al caso pessimo (+23%) andremo proprio male. Basterebbe appena per raggiungere un quad core core i7 odierno, e non troppo cloccato.
Al caso ottimo (+47%) sarebbe possibile avvicinarsi molto ad un core dei core i7, cloccato a 3,5GHz, fino a quasi eguagliarlo.la differenza rapportata alle prestazioni di core i7 980x, sarebbe di pochissimi punti percentuali.
Si deve però pensare che SB multicore implementi anch'esso un turbo core abbastanza aggressivo, e che la granularità del power gating sarà migliore di quella di bulldozer, per cui frequenze alte (4GHz e più) sono possibili anche per i SB top di gamma.

Insomma le prestazioni in single thread non le vedo molto buone.

Ma a me non interessa, faccio workstation grafiche

[capitan_crasy]

Scusate se interrompo un pò questa discussione su Bulldozer, ma vorrei attirare l'attenzione un secondo sui core X86 di Llano...
Non posto neanche le voci che sento, ma sono comunque (per lo più) ottimistiche.
Finora sappiamo che si tratta di architettura K10 (anche se i cialtroni di FUDZILLA la considera un K8 super potente); dovrebbe avere 1MB di cache L2, la L3 sarà assente mentre si parla di una possibile introduzione delle istruzioni AVX (non che quelle delle SSE 4.1/4.2).
Se la vedrà con gli SB più economici e anche se la GPU integrata di Llano sarà nettamente più potente, rimane l'incognita di quanto perderà in prestazioni sui core X86...

[calabar]

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.

Non proprio... una unità viene in ogni caso usata da più thread (in concorrenza però!), SMT è fondamentalmente un modo più efficiente di accedere all'unità.

Per "dividersi" intendo dire che, se si usano istruzioni più brevi delle AVX, la singola unità FP si comporta come se fossero due (o quattro per istruzioni a 64 bit).
La differenza rispetto ad SMT è sostanziale: SMT gestice due thread comunque in concorrenza su una singola unità, mentre la "divisione" permette di eseguire i due thread senza concorrenza.

Questo almeno è ciò che ha detto JF qualche tempo fa, e in particolare aveva dichiarato che BD avrebbe avuto un grande vantaggio su SB (parlando di BD 4 moduli contro SB 4 core) proprio perchè:
- con istruzioni AVX, possiamo presumere un pareggio, entrambi i processori avrebbero usato tutta la loro FP per processare l'istruzione
- con istruzioni più "piccole" BD avrebbe potuto eseguirne fino al doppio rispetto a SB proprio perchè la sua unità FP poteva agire come se fossero state due unità FP a 128 bit.
Quindi se con la presentazione ufficiale quanto rivelato in precedenza non è stato rimangiato, l'unità FP di BD dovrebbe essere proprio in grado di "dividersi" nel senso che ho dato al termine.
O qualcuno ha notizie certe differenti a riguardo?

Comunque se l'articolo parla di SMT come cosa certa, in qualche modo SMT sarà. Anche se non ho ben capito come si innesti nei discorsi fatti in precedenza.

Originariamente inviato da cionci

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

La prima parte in cosa consiste esattamente?

Comunque mi riferivo alle unità di esecuzione, che a mio parere, e a detta di AMD, rendono quei core "reali" e non virtuali.
Parlare di core virtuali è negare ciò che AMD sta dicendo esplicitamente da tempo riguardo la struttira di BD.

[Pihippo]

Originariamente inviato da calabar

La prima parte in cosa consiste esattamente?

Comunque mi riferivo alle unità di esecuzione, che a mio parere, e a detta di AMD, rendono quei core "reali" e non virtuali.
Parlare di core virtuali è negare ciò che AMD sta dicendo esplicitamente da tempo riguardo la struttira di BD.

Ciao
Instruction fetch e decoding.

[paolo.oliva2]

@Papafoxtrot

Considerando le tue previsioni... sto giro mi sa che per prendere un BD X8 tocca mettere mano seriamente al portafoglio e non i soldi spicci per casa.

Praticamente quando uscirebbe ci sarebbe pure nella versione X8 e si troverebbe di fronte solamente SB X4 per alcuni mesi. Ciò mettrebbe nella condizione AMD di avere il procio più potente in commercio.

Purtroppo vedendo un listino Intel in cui i proci top sarebbero sull'ordine degli 800€, non penso che AMD lo piazzerà sui 300€ (se lo facesse, sbancherebbe il mercato).

Inoltre avrebbe pure la carta di portare i BD X12 e X16 dal server al desktop, ora che si sa che pure nei server adotteranno il turbo, la cosa si limiterebbe al discorso socket e volontà AMD. In questo diciamo che sarà aiutata da Intel, perché un SB X8 dovrebbe avere prezzi di listino ancora superiori degli X6 attuali, e i margini di guadagno certamente invoglierebbero AMD.

Difficile fare previsioni di prezzo... ma reputerei più facile un prezzo aggressivo per AMD anche in caso di procio più potente che un abbassamento generale del listino Intel.

[cionci]

Originariamente inviato da calabar

Non proprio... una unità viene in ogni caso usata da più thread (in concorrenza però!), SMT è fondamentalmente un modo più efficiente di accedere all'unità.

Secondo me sono proprio in concorrenza. SMT non è un modo più efficiente di accedere alle unità, perché senza SMT solo un thread può accedere alle unità. SMT è trovare negli stage della pipeline istruzioni che provengono da più thread, se questo permetta o meno di ottenere maggiore efficienza è solo un importante side effect (che ovviamente sarà l'obiettivo della fase di progetto).
Sul fatto delle prestazioni doppie: attualmente non sembra, a meno che ogni FMAC possa eseguire una FMUL e una FADD contemporaneamente.
Ad oggi le unità di esecuzione FP sono due, più di due istruzioni per ciclo di clock non possono occupare lo stesso stage delle pipeline, qualsiasi sia il thread da cui provengono queste istruzioni.

Originariamente inviato da Pihippo

Ciao
Instruction fetch e decoding.

E qui ci saranno anche altri stage.
Se BD avesse la stessa pipeline del K10: http://www.insidehw.com/images/stori...0-pipeline.jpg
Gli stage in comune fra due thread nello stesso modulo sarebbero 9 su 12. Immaginandoci per BD una pipeline a 18 stadi, con la stessa proporzione sarebbero 13-14 gli stadi in comune.

[sonnet]

Secondo me tutto dipende dalla % die size risparmiato rispetto alle performance perse.
Se come nel caso di deneb vs propus si ha un risparmio di 40% in menod i die size a fronte di solo un 10% di prestazioni perse alla il gioco vale la candela.
Io fossi in loro non avrei proprio prodotto il deneb. Vista la capacita' produttiva limitata di AMD (ora in mano a GF), avrei preferito invadere il mercato con prodotti dall'ottima ratio performance/prezzo.
Anche perche' e' posssibile vista la non eccessiva distanza nei prezzi, che amd non abbia margini migliori con deneb, e sicuramente guadagnava piu' quote di mercato.
Questo per dire che se con Bulldozer seguiranno la stessa strada intrapresa qualche anno fa con i chip radeon (chip piccolo buone, performance vicine al top, imbattibile ratio perf/price) a me sta piu' che bene.
Non mi interessa averlo piu' lungo degli altri, cosi come alla maggior parte dei consumatori (altrimento gli atom nemmeno esisterebbero).

[cionci]

Originariamente inviato da sonnet

Secondo me tutto dipende dalla % die size risparmiato rispetto alle performance perse.

Esatto. Sembra essere questa la chiave di volta di questa CPU.
Ottenere una CPU che garantisca ottimi indici di prestazioni/potenza dissipata e prestazioni/n° di gate.