[Thread Ufficiale] CPU serie FX: AMD Bulldozer/Piledriver - Aspettando Steamroller

[ra-mta]

grazie cocco, hai espresso in maniera più chiara quello che avevo scritto sopra e che non era stato capito da LS

[LS1987]

Originariamente inviato da Cocco83

tu sbagli perché ragioni in maniera lineare... invece il consumo è moooolto esponenziale.... + aumenti la freqenza, molto + aumentano a dismisura i consumi.....

Optero con turbo 3.2ghz 115w, opteron con turbo 3.3ghz 145watt (se non ricordo male)

Mi sembra strano: io pensavo che il consumo aumentasse in modo lineare con la frequenza (è chiaro che se aumento sia il clock che il northbridge del 10 % se il consumo aumenta del 20 % non mi pongo nessuna domanda) e che avesse una dipendenza quadratica dalla tensione (è chiaro che se per aumentare di 100 MHz il clock devo aumentare di 0.1 V la tensione i consumi salgono molto). Se la differenza è così tanta vuol dire che le frequenze sono vicine al "muro" in overclock.
Sandy bridge più o meno segue la regola che ho descritto (almeno fino a 4.4-4.5 GHz, forse superata questa frequenza i consumi iniziano ad essere esponenziali).

Peccato che non sia vero il contrario: diminuzione esponenziale dei consumi diminuendo la frequenza. Voi potreste chiedermi che ci faccio con una CPU del genere? Semplice: si potrebbe fare calcolo distribuito, avendo prestazioni per watt migliori di sandy-bridge. A me non interessa, ma a qualche supercalcolatore sì. Immaginate 2.4 Ghz e 1.5 W di consumo: sarebbe una CPU da sogno per il calcolo distribuito, anche se le prendesse dal Ph II x 4 955 e da qualche i 3. La scheda madre e le RAM hanno un loro consumo, però una Micro-ATX o una Mini-ITX con un solo modulo di RAM low voltage non consuma tanto, soprattutto se ha solo connettività di base (un solo canale SATA, una sola PCI-Express, due sole porte USB, no porte parallele, seriali, PS/2, solo ethernet e wi-fi). Il carico sarebbe talmente basso che si potrebbe addiritura alimentare 3 PC con un solo alimentatore, ma converrebbe solo se devono essere accesi contemporaneamente, come nel caso del calcolo distribuito.

[The3DProgrammer]

Originariamente inviato da Randa71

ne approfitto subito: mi sono sempre chiesto come mai AMD in super pi andasse la metà rispetto ad intel.
ma questo non tanto per il bench di cui non frega un beep, ma per il fatto che è un esempio di programma che utilizza le SSE (sai le versioni sse2 e sse3)..quindi quello che mi chiedevo è questo: amd nelle SSE in FPU va la metà di intel? ci sono altre spiegazioni che ignoro? tutto merito del compilatore? oppure le sse non c'entrano nulla...e magari ci sono altri motivi..è una mia semplice curiosità..

sul resto condivido, e certo sarei ben felice se fx8150 andasse di +...ma come prima incarnazione di un'architettura nuova le perf FX8150 per me ci possono stare (in multi spinto, cinebench a parte, è a livello del 2600 e davanti al 1100t guardandomi la recensione su legitreviews )....ma solo del 8150...perchè gli altri.....beep beep
che poi consumi troppo o che sarebbe stato meglio che andasse di +...nessuno lo nega

Se posso lancio i miei 2cents riguardo alle prestazioni FP di BD:

Se ne e' parlato molto in passato nel thread aspettando, in molti me compreso si aspettavano un BD molto potente in FP single thread (SSE), perche' almeno teoricamente in single un thread avrebbe accesso completo alle risorse di una singola FPU di un cluster (quindi 2 FMAC + 2 IMMX, che sono molto di + di quanto metta a disposizione una singola FPU K10 e anche molto di + a livello teorico di una FPU di SB).
I test pero' ci hanno bellamente smentito, e i motivi a mio parere sono 2:

1) L'approccio a coprocessore paga latenze + elevate rispetto ad uno FPU classico

2) Il fatto di avere aumentato le latenze di esecuzione delle istruzioni e raddoppiato a conti fatti le unita' di esecuzione ha portato ad una situazione in cui:

- In multithread, grazie all'SMT su ogni singola FPU, si possono eseguire in parallelo istruzioni per 8 thread diversi aumentando di molto il throughput totale. Infatti in MT spinto una singola FPU di BD e' molto + potente di una singola FPU di k10 ( basta vedere ad esempio con cinebench in cui BD e' leggermente + veloce di thuban pur avendo solo 4 FPU contro le 6 di thuban)

- In single invece a causa delle latenze + elevate del sottosistema memoria e delle difficolta' intrinseche che impone l'isa x86 nell esplicitare l'ILP, succede che le 4 unita' di una FPU stanno la maggior parte del tempo a girarsi i pollici, e quindi a causa delle latenze a livello istruzione + elevate viene fuori che l'FPU e' + lenta di quella di K10 (e infatti in single thread BD ha bisogno di un clock molto + elevato per pareggiare K10).

Quindi le capacita' TEORICHE computazionali di una FPU BD sono molto elevate, il problema e' tutto quello che gli sta intorno.

Per quanto riguarda SuperPI invece, il problema e' che non usa SSE ma usa la vecchia ISA x87, che ha subito un drastico taglio di prestazioni in BD (praticamente tutte le istruzioni hanno latenze molto + elevate, a livelli quasi drammatici per quanto riguarda alcune come FSIN, FCOS, FDIV etc). Di conseguenza le prestazioni finali sono quelle che vediamo.
C'e' da dire che il set di istruzioni x87 e' ormai scarsamente utilizzato in sistemi a 32 bit ed e' deprecato per applicazioni native a 64 bit (quindi se avete BD e volete assicurarvi il massimo delle prestazioni FP cercate sempre la versione a 64 bit dell'applicazione per avere la sicurezza che sia compilata usando le SSE).

[Cocco83]

Originariamente inviato da ra-mta

grazie cocco, hai espresso in maniera più chiara quello che avevo scritto sopra e che non era stato capito da LS

figurati

[The3DProgrammer]

avrei voluto che BD fosse stato la 7970 delle CPU x86

[Randa71]

Originariamente inviato da The3DProgrammer

Se posso lancio i miei 2cents riguardo alle prestazioni FP di BD:

......

Per quanto riguarda SuperPI invece, il problema e' che non usa SSE ma usa la vecchia ISA x87, che ha subito un drastico taglio di prestazioni in BD (praticamente tutte le istruzioni hanno latenze molto + elevate, a livelli quasi drammatici per quanto riguarda alcune come FSIN, FCOS, FDIV etc). Di conseguenza le prestazioni finali sono quelle che vediamo.
C'e' da dire che il set di istruzioni x87 e' ormai scarsamente utilizzato in sistemi a 32 bit ed e' deprecato per applicazioni native a 64 bit (quindi se avete BD e volete assicurarvi il massimo delle prestazioni FP cercate sempre la versione a 64 bit dell'applicazione per avere la sicurezza che sia compilata usando le SSE).

non solo puoi, devi

sul discorso super pi no, perchè se prendo l'eseguibile con le SSE2 e le SSE3 (c'è scritto così in alto al programma), non l'eseguibile generico, mi aspetto che le usi le istruzioni SSE....e se BD va la metà rispetto ad intel mi chiedo il perchè....se c'è scritto nell'eseguibile che le usa poi non è vero allora è un altro discorso.....

Che sia deprecato è verissimo, meno vera secondo me è l'affermazione che 'quindi se avete BD e volete assicurarvi il massimo delle prestazioni FP cercate sempre la versione a 64 bit dell'applicazione per avere la sicurezza che sia compilata usando le SSE'
nel senso che piu che di sicurezza parlerei di speranza
uno dei limiti di BD, per me, è che hanno poco ottimizzato a basso livello le istruzioni....e non hanno ridotto di molto le latenze delle istruzioni, cioè il tempo passato nella pipeline, non sto parlando di cache o di BP...a basso livello la circuiteria che esegue i calcoli FPU è molto simile se non uguale al k10...le latenze delle istruzioni presenti in k10 sono le stesse in BD...almeno IMHO...
sarebbe bello avere un doc comparativo delle latenze delle istruzioni tra k10 e bd.
ecco perchè ad esempio con cinebench va come il vecchio phenom.....
ha il 50% in meno di fpu, ma gestendo il doppio dei thread va uguale....perchè di fatto il tempo che impiegava k10 è lo stesso che impiega bd...
se invece a basso livello avessero migliorato le latenze, la circuiteria, magari i risultati sarebbero stati diversi....


d'accordo sul resto

[Nforce Ultra]

Originariamente inviato da The3DProgrammer

avrei voluto che BD fosse stato la 7970 delle CPU x86

Magari, sembra quasi che AMD oramai stia puntando molto più sulle VGA che sulle cpu e che si sia rassegnata...spero di sbagliarmi...

[The3DProgrammer]

Originariamente inviato da Randa71

non solo puoi, devi

sul discorso super pi no, perchè se prendo l'eseguibile con le SSE2 e le SSE3 (c'è scritto così in alto al programma), non l'eseguibile generico, mi aspetto che le usi le istruzioni SSE....e se BD va la metà rispetto ad intel mi chiedo il perchè....se c'è scritto nell'eseguibile che le usa poi non è vero allora è un altro discorso.....

Che sia deprecato è verissimo, meno vera secondo me è l'affermazione che 'quindi se avete BD e volete assicurarvi il massimo delle prestazioni FP cercate sempre la versione a 64 bit dell'applicazione per avere la sicurezza che sia compilata usando le SSE'
nel senso che piu che di certezza parlerei di speranza
uno dei limiti di BD, per me, è che hanno poco ottimizzato a basso livello le istruzioni....e non hanno ridotto di molto le latenze delle istruzioni....cioè per me a basso livello la circuiteria che esegue i calcoli FPU è molto simile se non uguale al phenom 2...le latenze delle istruzioni presenti in phenom sono le stesse in BD...


d'accordo sul resto

Nono e' certezza, se e' compilato a 64 bit, e' matematico che usa le SSE. In long mode non si possono usare le x87. Diverso invece il discorso per le applicazioni WOW64 nel qual caso bisogna verificare.
Per le latenze istruzioni, in realta' quasi tutte sono + lente su BD che su K10 (ed e' questo fondamentalmente il motivo per cui BD ha bisogno di frequenza + elevata) nel developers manual c'e' il dettaglio istruzione per istruzione. Alcune sono MOLTO + lente che su K10.

Non sapevo esistessero versioni di SPI compilate con SSE, a quale ti riferisci?

[Randa71]

Originariamente inviato da The3DProgrammer

Nono e' certezza, se e' compilato a 64 bit, e' matematico che usa le SSE. In long mode non si possono usare le x87. Diverso invece il discorso per le applicazioni WOW64 nel qual caso bisogna verificare.
Per le latenze istruzioni, in realta' quasi tutte sono + lente su BD che su K10 (ed e' questo fondamentalmente il motivo per cui BD ha bisogno di frequenza + elevata) nel developers manual c'e' il dettaglio istruzione per istruzione. Alcune sono MOLTO + lente che su K10.

Non sapevo esistessero versioni di SPI compilate con SSE, a quale ti riferisci?

http://www.xtremesystems.org/forums/...per-pi-for-a64

i print screen di quello sse3 te lo mando quando arrivo a casa in PVT
interessatissimo al developer manual...
lo scarico dal sito amd? è pubblico?
discorso latenze: ci può stare per gli interi, visto che ne vuoi mettere 8 di unità ci sta che abbasso il FO4 a 17...proprio perchè semplifico la pipeline perchè ne voglio mettere 8...raddoppio
ma per la FPU non ci sta...almeno IMHO....visto che cmq sono 4..
a meno che le 2 FMAC siano di fatto un raddoppio rispetto al k10...nel qual caso anche qui le semplifico per metterne il doppio..

edit: guardando meglio anche la FPU è molto diversa rispetto al k10.....pensavo l'avessero mantenuta con l'aggiunta delle varie SSE4.32 AVX etc etc

[The3DProgrammer]

Originariamente inviato da Randa71

http://www.xtremesystems.org/forums/...per-pi-for-a64

i print screen di quello sse3 te lo mando quando arrivo a casa
interessatissimo al developer manual...
lo scarico dal sito amd? è pubblico?
cmq allora non so che hanno in testa...se peggiorano le latenze....

http://www.google.ch/url?sa=t&rct=j&...0cAb_oqfO5c0OA

appendice 2b elenca le latenze istruzione per istruzione

[The3DProgrammer]

Originariamente inviato da Randa71

[url]ma per la FPU non ci sta...almeno IMHO....visto che cmq sono 4..
a meno che le 2 FMAC siano di fatto un raddoppio rispetto al k10...nel qual caso anche qui le semplifico per metterne il doppio

esatto sono un raddoppio, il fatto e' che in ST una delle 2 sta quasi tutto il tempo a girarsi i pollici (questo lo si intuisce facilmente da cinebench ad esempio, in cui si ha un multiprocessor speedup di circa 6...se le FPU in ST fossero state sfruttate a dovere, ci sarebbe dovuto essere un MP speedup di poco superiore a 4...mettiamo 4.5...avremmo spannometricamente avuto un risultato st di 1.35 che e' nettamente superiore a K10..)

[Cocco83]

Originariamente inviato da Nforce Ultra

Magari, sembra quasi che AMD oramai stia puntando molto più sulle VGA che sulle cpu e che si sia rassegnata...spero di sbagliarmi...

No, a mio avviso AMD sta puntando ad avere un progetto che sia facilmente integrabile con questa nuova architettura che è in uso ora nella 7970, in modo da semplificare realizzazione, interconnessioni e produzione.... almeno spero

[dark.halo]

Forse non mi sono spiegato bene... non è la cpu che consuma 40Wh ma è il consumo complessivo del sistema sotto sforzo ad essersi abbassato di tale cifra, passando da 252 a 215Wh...

[Nforce Ultra]

Originariamente inviato da Cocco83

No, a mio avviso AMD sta puntando ad avere un progetto che sia facilmente integrabile con questa nuova architettura che è in uso ora nella 7970, in modo da semplificare realizzazione, interconnessioni e produzione.... almeno spero

Bah io sono dubbioso perchè da come sono messi adesso quelli di AMD per spremere al massimo la loro 7970 hanno bisogno di affiancarla ad un Sandy Bridge non è che sia il massimo secondo me, si trovano con una GPU della madonna e un procio non all'altezza di esprimere il suo potenziale...e questo mi fa pensare che si concentrano di più sul lato Gpu.

[Phenomenale]

Magari sul fronte GPU hanno un team di sviluppo buono (con gli ex-Ati), per le CPU pare secondo rumors che molti vecchi progettisti siano usciti, in luogo di nuove leve con meno esperienza.
IMHO sul Bulldozer hanno fatto tutto quello che hanno potuto con i mezzi a disposizione, non è che lo abbiano fatto debole intenzionalmente...

Ricordiamoci anche che le HD7000 vanno sugli ottimi 28nm di TMSC, gli FX-8000 sugli sfortunati 32nm GF.

[shellx]

Originariamente inviato da Nforce Ultra

Magari, sembra quasi che AMD oramai stia puntando molto più sulle VGA che sulle cpu e che si sia rassegnata...spero di sbagliarmi...

No.
----------------
1 Vga= TSMC
2 Cpu= GF
----------------

Debug: stringa 2 grave bug di implementazione

[shellx]

Originariamente inviato da Nforce Ultra

Bah io sono dubbioso perchè da come sono messi adesso quelli di AMD per spremere al massimo la loro 7970 hanno bisogno di affiancarla ad un Sandy Bridge non è che sia il massimo secondo me, si trovano con una GPU della madonna e un procio non all'altezza di esprimere il suo potenziale...e questo mi fa pensare che si concentrano di più sul lato Gpu.

Quando la serie 7000 sara lanciata, mesi dopo ci dovra essere piledriver, ergo magari le 7000 (no le prime, ma quelle pompate in seguito) andranno in sella a sistemi con cpu piledriver.
Quindi mi fa piu pensare che amd la sa lunga, e ha in servo un piledriver piu promettente di questo primo zambesi.

Originariamente inviato da Phenomenale

Ricordiamoci anche che le HD7000 vanno sugli ottimi 28nm di TMSC, gli FX-8000 sugli sfortunati 32nm GF.

quoto

[Nforce Ultra]

Originariamente inviato da shellx

Quando la serie 7000 sara lanciata, mesi dopo ci dovra essere piledriver, ergo magari le 7000 (no le prime, ma quelle pompate in seguito) andranno in sella a sistemi con cpu piledriver.
Quindi mi fa piu pensare che amd la sa lunga, e ha in servo un piledriver piu promettente di questo primo zambesi.



quoto

Spero tanto sia come dici tu mi farebbe piacere ritornassero competitivi anche sulle cpu. Comunque ok che il processore produttivo delle GPU è migliore di quello delle CPU però anche l'architettura in se è importante e quella delle schede video mi sembra ottima invece quella del processore lascia un pò a desiderare...

[Phenomenale]

Anche io ho saltato il Bulldozer in attesa del più promettente piledriver, magari fatto su dei 32nm un 'filino' più rodati.

[shellx]

Originariamente inviato da Nforce Ultra

Spero tanto sia come dici tu mi farebbe piacere ritornassero competitivi anche sulle cpu. Comunque ok che il processore produttivo delle GPU è migliore di quello delle CPU però anche l'architettura in se è importante e quella delle schede video mi sembra ottima invece quella del processore lascia un pò a desiderare...

Cambia tipo di produzione, cambiano ingegneri, cambiano elementi produttivi, cambia il processo produttivo...cambiano diverse cose.
Quindi non si puo mettere a paragone le due produzioni.
Una scheda video si produce con criteri differenti di come si fa una cpu.
Molto probabilemente nell'ambito cpu come ho gia detto diverse volte, ci sono stati degli errori di previsione. . . che si aggiungono con il finto silicio di gf. Vedi te che cocktail.