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

[FroZen]

Sintetizzando al massimo per farlo andare più corentemente bisogna tornare a 4C/4CU quindi farlo assomigliare ad un quad-core classico diciamo?

[Polpi_91]

Originariamente inviato da paolo.oliva2

Se andasse come questo grafico.... spaccherebbe tutto... e pensare che è solamente a 3,6GHz... (pensa a 4,5Ghz def).

Per me c'è un bug da qualche parte che è mostruoso... oppure semplicemente come ha detto il capitano, può darsi che sia il silicio non nel discorso di frequenza quanto (so un cavolo), un discorso di riflusso di dati in caso di errore? Che spiegherebbe anche le latenze?

In effetti Bjt2 ci aveva centrato in pieno quando diceva delle potenzialità di BD superiori a SB.

E quoto digieffe

il silicio c'entra poco, di bug grossi non ce ne sono almeno secondo i documenti ufficiali di AMD, è una questione di come arrivano e vengono "serviti" i dati alla cpu, BD ha delle unità di calcolo (sia FPU che INT) veloci solo che sono servite male (e qui entrano in gioco Cache, MC banda passante) e poi lavorano molto a vuoto causa branch predictor che fa fare molti calcoli a vuoto (miss prediction) quindi le unità lavorano con poca efficienza

[Polpi_91]

Originariamente inviato da FroZen

Sintetizzando al massimo per farlo andare più corentemente bisogna tornare a 4C/4CU quindi farlo assomigliare ad un quad-core classico diciamo?

guadagni forse qualcosa (è da vedere quanto) se il n° di Th è compreso da 1 a 4 ma se superi i 4th perdi e basta.

non so quanto il gioco valga la candela

[paolo.oliva2]

Originariamente inviato da papafoxtrot

Mi preoccupa quel +10/15% di performance per watt ogni anno.
Significa +10/15% di performance ogni anno, ovviamente, perché ci si ferma sempre agli stessi TDP.

Mi preoccupa perché sarebbe un buon risultato se la CPU di partenza fosse uscita bene, cioè avesse pochi margini.

Vuol dire che BD è difficile da migliorare...?
Il primo +10/15 lo posso capire. Piledriver esce nel Q1 2012 con Trinity, mica c'era tanto tempo... Ma secondo me il secondo step dovrebbe promettere il saltone.

Concordo con chi trova che la BP possa essere inadatta a gestire i due due thread. Ma non potrebbe essere anche il decoder ad essere limitativo?
Fino a poco fa credevo che le prestazioni della cache fossero un grosso problema, ma visto quanto migliora il songolo core disattivandogli il fratello, è evidente che prima di toccare la cache L1 (che fa schifo) conviene rivedere la logica condivisa del modulo.

Se è vero che ci sono tutti sti transistor in più ( miliardi in effetti sembrano un autentico disastro di transistor) spero si riesca a limarli. D'altra parte è vero il calcolo di Xbitlabs... 213 milioni a modulo fanno meno di 1 miliardo... Poi c'è la L3 che con celle 6T porta a circa 1,2 miliardi. Dove diamine sono andati gli altri 800 milioni, che bastano per fare una CPU intera?
Azz, sono davvero tantissimi...

Spero che col passare delle settimane arrivino da amd notizie rassicuranti su piledriver e steamroller...

Non sono d'accordo con chi dice che il PP è inadatto. 2 miliardi di transistor e tenerli a 3,6GHz non è affatto un brutto risultato. E difatti anche lano ciuccia poco.

Il problema (da quello che ho capito io) non è assolutamente il consumo a frequenze basse, dove il 32nm è nettamente più parsimonioso del 45nm. Il problema è l'impennata dei consumi sotto OC, che però sinceramente non comprendo molto (se dicono 5GHz+ ad aria... come farebbe ad impennarsi il consumo?
Tra l'altro... con 2 miliardi di transistor sarebbero più o meno 2 Thuban in un die... a livello architetturale BD si tirerebbe una favola... Llano sempre con il 32nm mi sembra non supera i 3,6GHz con un tot di transistor in meno.

[paolo.oliva2]

Originariamente inviato da Polpi_91

il silicio c'entra poco, di bug grossi non ce ne sono almeno secondo i documenti ufficiali di AMD, è una questione di come arrivano e vengono "serviti" i dati alla cpu, BD ha delle unità di calcolo (sia FPU che INT) veloci solo che sono servite male (e qui entrano in gioco Cache, MC banda passante) e poi lavorano molto a vuoto causa branch predictor che fa fare molti calcoli a vuoto (miss prediction) quindi le unità lavorano con poca efficienza

Infatti anche Bjt2 ha detto che di bug non ce ne sono...

Però... non mi tornano alcune cose... e ti dico.
Devono essere più cose combinate assieme.

Se fosse un problema di banda MC, i bench fatti con memorie a clock superiore e quindi più banda, darebbero di più, invece danno si di più ma non percentualmente.

Mettiamoci pure l'NB... ed allora sarebbero stupidi a farla 2GHz per alcuni modelli e 2,2GHz per altri.
(tra parentesi... un Thuban se si disabilitano dei core, si può alzare di più il clock NB... BD X4 clock NB minore di un BD X8? )

Le cache ha nno valori molto bassi ma si era data la colpa ad una cosa che non mi ricordo .

Poi c'è lo scheduler, il branch predictor, cache missing... ma questi secondo me possono si influire, ma non spiegano il clock NB e i risultati delle cache. Cioè se a monte va male, almeno a valle falle veloci per limitare i danni... loro teoricamente hanno fatto male a monte ed ancora peggio a valle

Io darei più la colpa al silicio (spiegazione Capitano con il Phenom) PERO', se fosse quello, Piledriver e superiori avrebbero performances ben superiori.... che non sono previste .

Per me semplicemente se toccano una cosa, va male un'altra e viceversa... ed il risultato è l'8150p, con in più il prb frequenze basse del silicio.

[paolo.oliva2]

Originariamente inviato da Veradun

Una marea.

Infatti... altrimenti avrebbero predetto un salto di potenza notevole...

Sinceramente... la mia idea p che non ci stanno tirando fuori gli zampetti e tirano ad arrivare al 2014/2015 con progetto next generations con l'APU che elabora i dati (core e IGP).

Guarda, onestamente... AMD le idee le ha ma purtroppo non ha la potenza costruttiva di portare avanti tutto e al meglio (purtroppo).

Se adesso si impegnasse nei proci, perderebbe il vantaggio che ha (con ATI) sulla concorrenza per l'APU. Meglio accontentarsi della fascia media e medio-bassa, che poi è quella con i numeri maggiori di vendite e tirare a campare questi 2-3 anni e poi pensare a BD next-generations.

Ad esempio, discorso Llano e Trinity.
Llano si vende e parecchio... Trinity ha una IGP più potente del 50% rispetto a Llano, ma Llano ha molti problemi di clock rispetto al 45nm, quindi un trinity anche a livello di core, sarebbe nettamente superiore. Se di Llano ne stanno vendendo un tot, di Trinity ne venderanno ancor di più.

Ed amen alla fascia medio-alta... ma che almeno aumentino le potenze magari abbassando ancor di più i prezzi... venderebbero ugualmente.

[JDM70]

Ciao Paolo, quel 15% in più magari era dato "visto che le slide erano vecchie" da un BD in prima infornata funzionare come si deve e quindi bastare per il loro scopo prefissato, adesso è da vedere se riescono a recuperare quello che manca o è mancato per le vere potenzialità di BD.

[Krato§]

eccoci quà..

[Ares17]

Originariamente inviato da paolo.oliva2

Infatti anche Bjt2 ha detto che di bug non ce ne sono...

Però... non mi tornano alcune cose... e ti dico.
Devono essere più cose combinate assieme.

Se fosse un problema di banda MC, i bench fatti con memorie a clock superiore e quindi più banda, darebbero di più, invece danno si di più ma non percentualmente.

Mettiamoci pure l'NB... ed allora sarebbero stupidi a farla 2GHz per alcuni modelli e 2,2GHz per altri.
(tra parentesi... un Thuban se si disabilitano dei core, si può alzare di più il clock NB... BD X4 clock NB minore di un BD X8? )

Le cache ha nno valori molto bassi ma si era data la colpa ad una cosa che non mi ricordo .

Poi c'è lo scheduler, il branch predictor, cache missing... ma questi secondo me possono si influire, ma non spiegano il clock NB e i risultati delle cache. Cioè se a monte va male, almeno a valle falle veloci per limitare i danni... loro teoricamente hanno fatto male a monte ed ancora peggio a valle

Io darei più la colpa al silicio (spiegazione Capitano con il Phenom) PERO', se fosse quello, Piledriver e superiori avrebbero performances ben superiori.... che non sono previste .

Per me semplicemente se toccano una cosa, va male un'altra e viceversa... ed il risultato è l'8150p, con in più il prb frequenze basse del silicio.

Se davvero hanno usato sistemi automatici per progettare Bd di bug non ne dovrebbero esistere (terrore di agena?).
Al massimo l'errore è nel software di progettazione (sicuramente passato al compilatore INTEL )

Potrebbero essere diversi i punti da migliorare, ma per il momento ci dobbiamo aspettare solo miglioramenti del silicio.
La progettazione a soc (intesa come tutta in una a blocchi), permetterà di avere evoluzioni di cpu molto più rapide che adesso, se il modulo a come sembra funziona discretamente potrebbe essere preso pari pari e spostato sulla nuova architettura, oppure usare diversi design per differenziare meglio l'offerta (sempre in prospettiva apu).

[shellx]

Iscritto a questo bel thread
Vi seguo da moltissimo anche nel thread precedente "Aspettando Bulldozer".

Ho sentito molte volte parlare di software (es.AOD) che potrebbero dare istruzioni allo scheduler per indirizzare l'allocamento dei T e dei processi applicativi verso cluster/core specifichi all'interno delle unita FP e quindi dei moduli.
Vi rispondo in merito a quello che io conosco nell'ambito dei sistemi operativi e delle applicazioni:
delle operazioni di questo genere sono da affidare meglio ai sistemi operativi e no alle applicazioni di terze parti.
Es: in linux una situazione di questo tipo è molto meglio gestibile che su windows, sia per via del fatto che ti ricompili il kernel a tuo piacimento e sia perchè ahimè mi dispiace doverlo dire, ma il kernel dei sistemi linux/unix è altamente piu efficiente di quel pesantone del k di win.

Tornando al discorso scheduler, c'è una condizione che andrebbe fatta riconoscere ai registri del sistema operativo, ossia quella di istruirlo in modo tale da allocare si 4t in 4m, ma contemporanemante dare istruzione in caso si superano i 4t. Esempio: se stiamo processando 4t e li allochiamo fedelmente una per C all'interno dei 4m, puo capitare che aprendo un'altra qualsiasi applicazione anche int e di carico leggero, lo scheduler deve poter gestire anch'essa allocandola da qualche parte.
Per cui basta istruire il kernel, dicendogli che in caso di T>4 alloca dal quinto in poi in un cluster non utilizzato. Altrimenti questo resta in attesa che uno dei 4 si liberano, e non è una cosa piacevole in termini di prestazioni, perchè trasfomeresti un 8core in un processore inefficiente, dove superati i 4t diventa come un single core che processa 2t.
A questo punto sono piu convenienti 6 unita core di thuban.

Spero di non aver spiegato al meglio la mia opinione, ovviamente mi piacerebbe condividere le vostre opinioni a riguardo. In quanto se è vera questa spiacevole situazione di Zambesi, dobbiamo trovare il modo di renderlo efficiente il piu possibile in qualita delle nostre abitudini quotidiane nell'uso del nostro sistema.

Comunque molto bravi per questo thread, forse il migliore di tutti i forum di hardware italiani. Buona serata

[papafoxtrot]

Originariamente inviato da paolo.oliva2

Infatti anche Bjt2 ha detto che di bug non ce ne sono...

Però... non mi tornano alcune cose... e ti dico.
Devono essere più cose combinate assieme.

Se fosse un problema di banda MC, i bench fatti con memorie a clock superiore e quindi più banda, darebbero di più, invece danno si di più ma non percentualmente.

Mettiamoci pure l'NB... ed allora sarebbero stupidi a farla 2GHz per alcuni modelli e 2,2GHz per altri.
(tra parentesi... un Thuban se si disabilitano dei core, si può alzare di più il clock NB... BD X4 clock NB minore di un BD X8? )

Le cache ha nno valori molto bassi ma si era data la colpa ad una cosa che non mi ricordo .

Poi c'è lo scheduler, il branch predictor, cache missing... ma questi secondo me possono si influire, ma non spiegano il clock NB e i risultati delle cache. Cioè se a monte va male, almeno a valle falle veloci per limitare i danni... loro teoricamente hanno fatto male a monte ed ancora peggio a valle

Io darei più la colpa al silicio (spiegazione Capitano con il Phenom) PERO', se fosse quello, Piledriver e superiori avrebbero performances ben superiori.... che non sono previste .

Per me semplicemente se toccano una cosa, va male un'altra e viceversa... ed il risultato è l'8150p, con in più il prb frequenze basse del silicio.

uello di cui parli è il fatto che la L1D è write through. Sono daccordo che una cache più veloce aiuterebbe. Ma se fosse colpa della L1 non si guadagnerebbe così tanto a disattivare un core.
Per quanto riguarda la L3 e il MC, non sono certo eccellenti, soprattutto la L3, ma secondo me non è colpa loro, perché anche qui non si vedrebbe tutta sta differenza tra 4core4moduli e 4core2moduli.

Per questo ritengo che proprio il BP sia orrendo, e forse anche il decoder ci mette del suo...

Sotto queste ipotesi però mi domando: che senso ha sostituire Llano con trinity... Ad oggi un 4100 non arriva alle prestazioni di llano ed è molto più grosso (lato CPU). Quindi in pratica un trinity costerebbe di più a prodursi, per andare forse uguale... Che cosa ci guadagnano?
O erano schedulati e han deciso di andare avanti lo stesso, confidando sul fatto che comunque in qualche test è effettivamente migliore... oppure piledriver guadagnerà più di quei 10-15%...

Oppure ancora, quei 10-15% sono una media, e grazie a qualche ottimizzazione, il guadagno sarà del 20-25% dove va peggio, e del % dove va già bene. Questa la troverei la soluzione migliore...

In ogni caso spero che con piledriver, che mi par di capire è solo per desktop, riducano la cache L2, che costa un sacco e non credo aiuti così tanto..
Magari si tornerà ai 2MB per modulo quando, tra un anno o due, le prestazioni generali saranno migliori e la miniaturizzazione più spinta...
Oppure trinity sarà senza L3? E allora ci stanno gli 8MB di L2... Ma allora anche wishera avrebbe di nuovo quella costosa e inutile cache di troppo...

Hem, c'è possibilità di vedere cache 8T a breve? Almeno per la L2, dovrebbero avere migliori prestazioni, vero?
E una hem hem... z-ram per la L3?

[Mparlav]

Questo sito è l'unico dove sia stato riportato con successo il funzionamento dell'FX-810 su una Mb AM3, laMSI 890FXA-GD70 con bios beta BIOS 1B6

Tutto ha funzionato nel breve tempo del test, eccetto le memorie che hanno settato a 1333 invece di 1866.
Ma a frequenza stock (niente test di overclock), HT, Turbo e risparmio energetico, non hanno dato problemi e le prestazioni erano le stesse rilevate sulla Crosshair V.

Sulla Crosshair IV è uscito un bios (il 2002 final) che introduce supporto per nuove cpu, ma il Bulldozer su quello non fa' manco il boot.

[navarre63]

http://www.asrock.com/mb/cpu.asp?Model=960GM-S3%20FX

anche il 960...
ma non capisco perchè adesso compaiono gli FX,sia prima che dopo il 12 ott,il bios era ed è il 1.10


vecchi bios oppure hanno aspettato il lancio ufficiale?

[Guglio]

iscritto

[marchigiano]

Originariamente inviato da ozlacs

Ex-AMD Engineer Explains Bulldozer Fiasco: Lack of Fine Tuning

http://www.xbitlabs.com/news/cpu/dis...er_Fiasco.html

quindi si può dire che la marmotta confeziona i sandy bridge

[maxsin72]

Non so se è già ma una spiegazione possibile delle prestazioni non soddisfacenti di Bulldozer si può leggere a questo link http://www.tomshw.it/cont/news/bulld...d/33980/1.html

[Polpi_91]

Originariamente inviato da paolo.oliva2

Infatti anche Bjt2 ha detto che di bug non ce ne sono...

Però... non mi tornano alcune cose... e ti dico.
Devono essere più cose combinate assieme.

Se fosse un problema di banda MC, i bench fatti con memorie a clock superiore e quindi più banda, darebbero di più, invece danno si di più ma non percentualmente.

Mettiamoci pure l'NB... ed allora sarebbero stupidi a farla 2GHz per alcuni modelli e 2,2GHz per altri.
(tra parentesi... un Thuban se si disabilitano dei core, si può alzare di più il clock NB... BD X4 clock NB minore di un BD X8? )

Le cache ha nno valori molto bassi ma si era data la colpa ad una cosa che non mi ricordo .

Poi c'è lo scheduler, il branch predictor, cache missing... ma questi secondo me possono si influire, ma non spiegano il clock NB e i risultati delle cache. Cioè se a monte va male, almeno a valle falle veloci per limitare i danni... loro teoricamente hanno fatto male a monte ed ancora peggio a valle

Io darei più la colpa al silicio (spiegazione Capitano con il Phenom) PERO', se fosse quello, Piledriver e superiori avrebbero performances ben superiori.... che non sono previste .

Per me semplicemente se toccano una cosa, va male un'altra e viceversa... ed il risultato è l'8150p, con in più il prb frequenze basse del silicio.

NB e banda passante non sono un fattore al momento molto limitante per BD, è migliorato rispetto a PHII ma non è assolutamente ancora ai livelli di intel.
certo che da un progetto del genere ci si aspettava un po' più di frequenza anche dal NB.

BP e chace missing non c'entarno con i risultati della cache.

al momento il più grosso fattore penalizzante il BP che fa fare un sacco di lavoro a vuoto alla cpu

[stefano_sa]

.....Capitano, tenuto conto che Paolone, io e probabilmente altri siamo intenzionati a prendere BD appena disponibile, che ne diresti di pianificare una suite di test con relative metodologie di esecuzione, in modo da avere risultati confrontabili e vedere anche la reazione del procio in base alle configurazioni/sistemi di raffreddamento da noi posseduti? Imho sarebbe interessante (e divertente )

[Polpi_91]

Originariamente inviato da papafoxtrot

uello di cui parli è il fatto che la L1D è write through. Sono daccordo che una cache più veloce aiuterebbe. Ma se fosse colpa della L1 non si guadagnerebbe così tanto a disattivare un core.
Per quanto riguarda la L3 e il MC, non sono certo eccellenti, soprattutto la L3, ma secondo me non è colpa loro, perché anche qui non si vedrebbe tutta sta differenza tra 4core4moduli e 4core2moduli.

Per questo ritengo che proprio il BP sia orrendo, e forse anche il decoder ci mette del suo...

Sotto queste ipotesi però mi domando: che senso ha sostituire Llano con trinity... Ad oggi un 4100 non arriva alle prestazioni di llano ed è molto più grosso (lato CPU). Quindi in pratica un trinity costerebbe di più a prodursi, per andare forse uguale... Che cosa ci guadagnano?
O erano schedulati e han deciso di andare avanti lo stesso, confidando sul fatto che comunque in qualche test è effettivamente migliore... oppure piledriver guadagnerà più di quei 10-15%...

Oppure ancora, quei 10-15% sono una media, e grazie a qualche ottimizzazione, il guadagno sarà del 20-25% dove va peggio, e del % dove va già bene. Questa la troverei la soluzione migliore...

In ogni caso spero che con piledriver, che mi par di capire è solo per desktop, riducano la cache L2, che costa un sacco e non credo aiuti così tanto..
Magari si tornerà ai 2MB per modulo quando, tra un anno o due, le prestazioni generali saranno migliori e la miniaturizzazione più spinta...
Oppure trinity sarà senza L3? E allora ci stanno gli 8MB di L2... Ma allora anche wishera avrebbe di nuovo quella costosa e inutile cache di troppo...

Hem, c'è possibilità di vedere cache 8T a breve? Almeno per la L2, dovrebbero avere migliori prestazioni, vero?
E una hem hem... z-ram per la L3?

Quoto in pieno.

io al momento se fossi in AMD punterei a sistemare prima di tutto decoder e BP, poi penserei alla cache e al mc

[marchigiano]

certo che se fosse andato un 20% in più con 1.66 miliardi di transistors (262 mm2) sarebbe stato un gran bel processore...

poi avete notato che ci sono 4 link HT? penso per le versioni server dual socket 32 core... un die specifico per desktop sarebbe molto più piccolo