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

[leoneazzurro]

Originariamente inviato da riuzasan

Sono le due considerazioni che metto a confronto e non a caso.
Leoneazzurro ... come puoi pensare che in int BD vada peggio di K10, quando secondo quelle slide in FPU va meglio -.-
Architetturalmente vale SOLO l'opposto, non contano slide, ipotesi o idee fantasiose. L'unica logica "condivisa" tra due moduli BD riguarda il comparto FPU.
Quando JF ha detto che in int un modulo BD va meglio di un core X10, intendeva quello.
Punto.
Poi, se uno dei dipendenti di AMD più qualificati ed affidabili degli ultimi anni ha sparato fandonie, possiamo chiudere baracca e burattini.

PS: E per JF i moduli non esistono, ci sono solo e sempre i CORE anche nell'architettura BD

In INT sul singolo core, potrebbe essere. In INT sul computo totale dei core, direi decisamente di no. Dipede dalla parallellizzazione che si riesce a raggiungere. Teniamo conto che ogni core ha meno unità di esecuzione rispetto ad un K10, e che lo stadio di fetch/decoding e di ritiro delle istruzioni è condiviso in Bulldozer mentre è dedicato in un K10.
E non avendo benchmark indipendenti ed affidabili in mano, non sto dicendo che è così. Sto dicendo che è possibile che sia così, se parliamo solo di numero puro di unità di esecuzione senza poter verificare con benchmark appositi la bontà delle altre ottimizzazioni apportate alla CPU.

[digieffe]

Originariamente inviato da Korn

cioè una unità fpu di db è più veloce di 2 fpu del k10 e 2 unità int sono più lente di una unità int del k10?

riporto un pò di dati essenziali:

http://browse.geekbench.ca/geekbench2/view/405187

Linux PC (AMD Opteron(tm) Processor 6134)
Operating System.........Linux 2.6.18-194.32.1.el5.552g0002 x86_64
Processo.....................AMD Opteron 6134
Processor ID................AuthenticAMD Family 16 Model 9 Stepping 1 *** K10
Processor Frequency.....2.30 GHz......Processors 4
Cores.........................32...............Threads 32

Processor integer performance: 19604
Processor floating point performance: 35443


http://browse.geekbench.ca/geekbench2/view/484217
Supermicro H8DGT
Operating System..........Linux 2.6.39-bpo.2-amd64 x86_64
Processor.....................AMD Eng Sample, ZS232545TGG45_32/23/20_2/16
Processor ID.................AuthenticAMD Family 21 Model 1 Stepping 1 ***BD
Processor Frequency......2.30 GHz......Processors 2
Cores..........................8................Threads 32

Processor integer performance: 16795
Processor floating point performance: 40353


EDIT: @capitano, riesci a decodificare che tipo di es, turbo ecc dalla sigla?

[marchigiano]

Originariamente inviato da wikipedia

I 16 core erano assemblati in quattro core cluster. Ogni core in un cluster condivideva 32 KB di cache istruzioni, due cache dati da 32 KB e due unità in virgola mobile. I progettisti Sun fecero queste scelte perché i tipici programmi eseguiti dai server normalmente facevano un intenso riuso dei dati mentre le istruzioni in virgola mobile erano relativamente rare. Quindi includere delle unità in virgola mobile condivise riduceva il numero di transistor occupati senza deprimere le prestazioni in modo eccessivo.

notare le analogie con BD

[Cocco83]

Originariamente inviato da papafoxtrot

Gente, lasciate stare, da che mondo e mondo la frequenza ed i timings delle ram non hanno mai contato un piffero, e BD non sarà diverso; per cui risparmiate e piuttosto spendete i soldi in un bell?SSD o una VGA migliore, se ne avete bisogno.

Bè AMD con Llano ha rivoluzionato questa cosa xD.... mettici ram + veloci ottieni prestazioni sensibilmente migliori sopratutto nei giochi xD

[Korn]

no llano è un altra faccenda in quanto la parte gpu è avida di banda passante andando a contenderla alla cpu e cmq credo sia sempre più importante la velocità in MHz che i timing della ram, per BD credo sarà diverso

[Cocco83]

ovviamente concordo per la velocità.... poi che sia Llano o meno è sempre una nuova architettura che sostituisce/prende il posto del normale processore, bisogna tenerne conto anke perché l'andazzo futuro penso sarà quello

[capitan_crasy]

Originariamente inviato da leoneazzurro

Beh, come numero di unità di esecuzione ogni "core" di BD è in difetto rispetto a quello di un K10, per cui dipende molto dai carichi di lavoro e da come si riescono a riempire le pipeline. Anche a livello di fetch/ritiro delle istruzioni ci sono meno risorse TOTALI.

Originariamente inviato da leoneazzurro

In INT sul singolo core, potrebbe essere. In INT sul computo totale dei core, direi decisamente di no. Dipede dalla parallellizzazione che si riesce a raggiungere. Teniamo conto che ogni core ha meno unità di esecuzione rispetto ad un K10, e che lo stadio di fetch/decoding e di ritiro delle istruzioni è condiviso in Bulldozer mentre è dedicato in un K10.
E non avendo benchmark indipendenti ed affidabili in mano, non sto dicendo che è così. Sto dicendo che è possibile che sia così, se parliamo solo di numero puro di unità di esecuzione senza poter verificare con benchmark appositi la bontà delle altre ottimizzazioni apportate alla CPU.

Cavolo, qui ci vuole il buon bjt2...
Inoltre mi fa molto piacere averti qui leoneazzurro!!!

[bjt2]

Originariamente inviato da leoneazzurro

Mah, può essere che lui intenda per "core" in realtà un "modulo".
Il fatto è che sicuramente ci sono dei miglioramenti all' architettura, ma le unità di esecuzione ad esempio sono di meno in un "core" BD che in un "core" K10...

La maggior parte dei programmi ha IPC attorno a 1. Cinebench ha 0.65, di cui 0.55 in FP, Spec INT ha 1.15 e Spec FP 1.35 (tutti e tre i valori si riferiscono al K10 e dovrebbero essere comprese le load/store, che a parte le AGLU, usano l'unità di load/store)... Con le code enormi e i miglioramenti all'architettura (sto pensando allo scheduler a coda unificata contro quello a code separate, al nuovo branch prediction, il nuovo MC, l'enorme cache L2 condivisa tra due core, che dimezza il traffico core-core e ai nuovi prefetcher), con due unità INT e due unità AGLU si può addirittura sperare in IPC migliore...

[bjt2]

Originariamente inviato da digieffe

riporto un pò di dati essenziali:

http://browse.geekbench.ca/geekbench2/view/405187

Linux PC (AMD Opteron(tm) Processor 6134)
Operating System.........Linux 2.6.18-194.32.1.el5.552g0002 x86_64
Processo.....................AMD Opteron 6134
Processor ID................AuthenticAMD Family 16 Model 9 Stepping 1 *** K10
Processor Frequency.....2.30 GHz......Processors 4
Cores.........................32...............Threads 32

Processor integer performance: 19604
Processor floating point performance: 35443


http://browse.geekbench.ca/geekbench2/view/484217
Supermicro H8DGT
Operating System..........Linux 2.6.39-bpo.2-amd64 x86_64
Processor.....................AMD Eng Sample, ZS232545TGG45_32/23/20_2/16
Processor ID.................AuthenticAMD Family 21 Model 1 Stepping 1 ***BD
Processor Frequency......2.30 GHz......Processors 2
Cores..........................8................Threads 32

Processor integer performance: 16795
Processor floating point performance: 40353


EDIT: @capitano, riesci a decodificare che tipo di es, turbo ecc dalla sigla?

Questi dati mi fanno pensare che lo scheduler FP del K10 faceva proprio schifo (questo lo sospettavo ma non potevo dire di quanto)! E che lo scheduler INT non era poi tanto male...

Essendo un ES può darsi che abbia i vari problemi di cui si vociferava (bisognerebbe avere lo stepping) e comunque magari i BIOS e i codici Agesa non sono a puntino, anche perchè le versioni finali ancora devono arrivare a tutti gli OEM (praticamente solo Cray ce l'ha...)... Poi le RAM? Hanno usato le stesse degli MC? Perchè BD supporta RAM più veloci...

[bjt2]

Originariamente inviato da leoneazzurro

In INT sul singolo core, potrebbe essere. In INT sul computo totale dei core, direi decisamente di no. Dipede dalla parallellizzazione che si riesce a raggiungere. Teniamo conto che ogni core ha meno unità di esecuzione rispetto ad un K10, e che lo stadio di fetch/decoding e di ritiro delle istruzioni è condiviso in Bulldozer mentre è dedicato in un K10.
E non avendo benchmark indipendenti ed affidabili in mano, non sto dicendo che è così. Sto dicendo che è possibile che sia così, se parliamo solo di numero puro di unità di esecuzione senza poter verificare con benchmark appositi la bontà delle altre ottimizzazioni apportate alla CPU.

Anche qua, con IPC medio di poco superiore a 1, 4 decoder e 4 ritiri/ciclo sono più che sufficienti...
Per il ritiro, essendo a valle di tutto, questo vale sicuramente.
Per il decoding, essendo a monte, una potenza di picco potrebbe essere vantaggiosa. Bisogna vedere quanto potenti sono questi decoder... Bisogna vedere quante istruzioni sono state promosse da Vector a Double o single e quante da double a single... Ma sono abbastanza fiducioso, visto che il prefetching è guidato dal branch prediction ed entrambi sono stati migliorati...

[digieffe]

Originariamente inviato da bjt2

Questi dati mi fanno pensare che lo scheduler FP del K10 faceva proprio schifo (questo lo sospettavo ma non potevo dire di quanto)! E che lo scheduler INT non era poi tanto male...

Essendo un ES può darsi che abbia i vari problemi di cui si vociferava (bisognerebbe avere lo stepping) e comunque magari i BIOS e i codici Agesa non sono a puntino, anche perchè le versioni finali ancora devono arrivare a tutti gli OEM (praticamente solo Cray ce l'ha...)... Poi le RAM? Hanno usato le stesse degli MC? Perchè BD supporta RAM più veloci...

Capitano riesci a decodificare step, turbo ecc dalla sigla?


Avevo omesso i dati della ram

Originariamente inviato da digieffe

riporto un pò di dati essenziali:

http://browse.geekbench.ca/geekbench2/view/405187

Linux PC (AMD Opteron(tm) Processor 6134)
Operating System.........Linux 2.6.18-194.32.1.el5.552g0002 x86_64
Processo.....................AMD Opteron 6134
Processor ID................AuthenticAMD Family 16 Model 9 Stepping 1 *** K10
Processor Frequency.....2.30 GHz......Processors 4
Cores.........................32...............Threads 32

Processor integer performance: 19604
Processor floating point performance: 35443
Memory performance: 1854
Memory bandwidth performance: 1184

http://browse.geekbench.ca/geekbench2/view/484217
Supermicro H8DGT
Operating System..........Linux 2.6.39-bpo.2-amd64 x86_64
Processor.....................AMD Eng Sample, ZS232545TGG45_32/23/20_2/16 <- @Capitano
Processor ID.................AuthenticAMD Family 21 Model 1 Stepping 1 ***BD
Processor Frequency......2.30 GHz......Processors 2
Cores..........................8................Threads 32

Processor integer performance: 16795
Processor floating point performance: 40353
Memory performance: 3551
Memory bandwidth performance: 4591


EDIT: @capitano, riesci a decodificare che tipo di es, turbo ecc dalla sigla?

nella mia ignoranza, posso dedurre dalla sigla: 16 core, 2 ghz base, 2.3ghz turbo, se le deduzioni fosse esatte, sarebbe da capire se durante i test le cpu erano a 2Ghz, a 2.3 o ad una via di mezzo tramite dithering
anche perchè da 2 a 2.3 c'è +15%... che riporterebbe l'ipc int in parità...

[blackandecker]

Scusate se mi intrometto in un momento della discussione dove oltre il 50% delle parole per me è un semplice accostamento casuale di lettere.

Le slide postate una decina di pagine fa, le ultime, sono attendibili?
Perchè se lo sono, Bulldozer non ci esce mica bene.... gli autori delle slide sembrano quasi felici di aver costruito una cpu con 8 core che va QUANTO l'i7 2600 ....e di averci perso anni oltretutto.

Penso (e spero) che i risultati siano diversi, sennò o vendono BD quanto gli attuali Phenom II X6, oppure Intel avrà vita facile, causando danno all'intera fascia consumer.

[BodyKnight]

Originariamente inviato da blackandecker

e sembrano quasi felici di aver costruito una cpu con 8 core che va QUANTO l'i7 2600 ....e di averci perso anni oltretutto.

Sicneramente, per me, sarebbe un successo smodato e farei festa per 10 giorni.

[digieffe]

Originariamente inviato da blackandecker

Scusate se mi intrometto in un momento della discussione dove oltre il 50% delle parole per me è un semplice accostamento casuale di lettere.

Le slide postate una decina di pagine fa, le ultime, sono attendibili?
Perchè se lo sono, Bulldozer non ci esce mica bene.... gli autori delle slide sembrano quasi felici di aver costruito una cpu con 8 core che va QUANTO l'i7 2600 ....e di averci perso anni oltretutto.

Penso (e spero) che i risultati siano diversi, sennò o vendono BD quanto gli attuali Phenom II X6, oppure Intel avrà vita facile, causando danno all'intera fascia consumer.

Al momento non si sa la vera natura di quelli slide... su alri forum si ipotizza che siano riferite ad un briefing interno di amd e siano basate su engineering sample...

conviene comunque attendere 15 giorni e vedere come va il prodotto di mercato

[capitan_crasy]

Originariamente inviato da digieffe

Capitano riesci a decodificare step, turbo ecc dalla sigla?

La CPU è uno step B1 quindi siamo lontani dalla versione definitiva, la frequenza di clock è di 2.30Ghz, mentre il turbo dovrebbe essere compreso (purtroppo non ne sono sicuro) tra i 200/400Mhz...

[HacNet]

Originariamente inviato da blackandecker

...oppure Intel avrà vita facile, causando danno all'intera fascia consumer.

ecco cosa ne penso:intel non fara nessun danno semplicemente a nessuno, il suo interesse è riscuotere il piu posibile e vorrei vedere dopo tanto investimento in ricerche ect,quindi continuera per la sua strada come ha sempre fatto senza guardarsi indietro oppure intorno, non ne ha bisogno forse ci graziera coi prezzi quando si rendera conto che il monopolio è il suo ed abbassera i prezzi per la mancanza di concorrenza bha!
le slide parlano chiaro e molti si sono gia fatti pio o meno un idea.
spero che i bench ufficiali smentiscano anche in parte cio che si trova qualche pagina indietro la vedo dura comq. il tempo l'ha avuto anche troppo... chi semina raccoglie.

[leoneazzurro]

Originariamente inviato da bjt2

La maggior parte dei programmi ha IPC attorno a 1. Cinebench ha 0.65, di cui 0.55 in FP, Spec INT ha 1.15 e Spec FP 1.35 (tutti e tre i valori si riferiscono al K10 e dovrebbero essere comprese le load/store, che a parte le AGLU, usano l'unità di load/store)... Con le code enormi e i miglioramenti all'architettura (sto pensando allo scheduler a coda unificata contro quello a code separate, al nuovo branch prediction, il nuovo MC, l'enorme cache L2 condivisa tra due core, che dimezza il traffico core-core e ai nuovi prefetcher), con due unità INT e due unità AGLU si può addirittura sperare in IPC migliore...

La cache è aumentata, ma le latenze previste paiono non essere neanche lontanamente vicine a quelle delle CPU Intel. Purtroppo questo non aiuta e soprattutto non facilita il lavoro dello scheduler. L'IPC migliore potrebbe esserci in alcuni casi (carichi server che necessitano di frequenti scambi di dati inter-core?), in altri è possibile che invece l'overhead e la minore potenza teorica di picco possano essere deleteri.

Originariamente inviato da bjt2

Anche qua, con IPC medio di poco superiore a 1, 4 decoder e 4 ritiri/ciclo sono più che sufficienti...
Per il ritiro, essendo a valle di tutto, questo vale sicuramente.
Per il decoding, essendo a monte, una potenza di picco potrebbe essere vantaggiosa. Bisogna vedere quanto potenti sono questi decoder... Bisogna vedere quante istruzioni sono state promosse da Vector a Double o single e quante da double a single... Ma sono abbastanza fiducioso, visto che il prefetching è guidato dal branch prediction ed entrambi sono stati migliorati...

I 4 decoder e i 4 ritiri servono due "core", però, non uno solo. E la potenza di picco serve sempre, inutile dirlo. Io ho sempre visto questa CPU come l'equivalente di un quad core classico con il concetto di SMT portato all'estremo (e non solo io, ad esempio David Kanter di Extremetech, che ne capisce decisamente più di me, ne parlava proprio in questi termini). E sarebbe interessante capire se, dato lo scheduler unico, si potesse realizzare invece il lavoro comune dei due "core" su un unico thread ove servisse (difficile, soprattuto dal punto di vista SW)

[bjt2]

Originariamente inviato da capitan_crasy

La CPU è uno step B1 quindi siamo lontani dalla versione definitiva, la frequenza di clock è di 2.30Ghz, mentre il turbo dovrebbe essere compreso (purtroppo non ne sono sicuro) tra i 200/400Mhz...

Da qualche parte ho visto i modelli server definitivi... Il top di gamma è un 62xx SE (quindi 140W max) da 2.5 GHz base, 3.1GHz Turbo su tutti i core (+600 MHz, meglio di quanto promesso da JF-AMD) e 3.5GHz di turbo max su <=8 core (+1GHz, in linea con le promesse di JF-AMD)... Tutti speravamo in una frequenza base più alta, ma non ci possiamo assolutamente lamentare...
Visto che quei risultati postati sono di ES B1 e per di più a 2GHz, non possiamo che supporre che il guadagno sia ancora maggiore!

[The3DProgrammer]

Originariamente inviato da leoneazzurro

La cache è aumentata, ma le latenze previste paiono non essere neanche lontanamente vicine a quelle delle CPU Intel. Purtroppo questo non aiuta e soprattutto non facilita il lavoro dello scheduler. L'IPC migliore potrebbe esserci in alcuni casi (carichi server che necessitano di frequenti scambi di dati inter-core?), in altri è possibile che invece l'overhead e la minore potenza teorica di picco possano essere deleteri.

un altro punto critico e' che le latenze istruzione per istruzione sono nettamente aumentate, e non di poco (la situazione e' quasi tragica per le istruzioni x87, dove ci sono istruzioni tipo fdiv o fatan o fcos che costano anche dal doppio al triplo in termini di cicli di clock rispetto a k10, questo potrebbe spiegare le cattive performance in superpi). Quindi dipende tutto da quanto il nuovo prefetcher e il BP migliorato permettano di mascherare le aumentate latenze delle pipe di esecuzione, ma quello che mi fa un po preoccupare e' che nel contempo anche le latenze del sottosistema memoria sono aumentate...

I 4 decoder e i 4 ritiri servono due "core", però, non uno solo. E la potenza di picco serve sempre, inutile dirlo. Io ho sempre visto questa CPU come l'equivalente di un quad core classico con il concetto di SMT portato all'estremo (e non solo io, ad esempio David Kanter di Extremetech, che ne capisce decisamente più di me, ne parlava proprio in questi termini). E sarebbe interessante capire se, dato lo scheduler unico, si potesse realizzare invece il lavoro comune dei due "core" su un unico thread ove servisse (difficile, soprattuto dal punto di vista SW)

mi piace questo elemento
Per quanto riguarda il lavoro comune dei 2 core, se n'era giâ' parlato. E' difficile che si riesca a sfruttare solo con l'engine OoO 4 pipe int, probabilmente e' meglio usarne 2, spegnere le altre e spingere sul clock con il turbo

[marchigiano]

Originariamente inviato da bjt2

Visto che quei risultati postati sono di ES B1 e per di più a 2GHz, non possiamo che supporre che il guadagno sia ancora maggiore!

il ceo ha detto +35% a pari fascia di tdp... ti torna come stima?