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

[Diablo III]

Originariamente inviato da Folgore 101

se adesso consideriamo che l'FX8150 nel CMP fa un +72% rispetto il 3770K, per pareggiarlo a che frequenze dovrebbe andare?
Vorrei solo capire di che aumento avrebbe bisogno l'FX8150 per pareggiare con il 3770K.

interessante domanda, a cui purtroppo non ti so dare una risposta precisa
volendo potrei provare a rifare le prove con l'8150 a 5/5.5ghz così da farsi un'idea un pò più precisa

se ti interessa la cosa ti faccio le prove e te le mando in pvt

[shellx]

Originariamente inviato da Folgore 101

Come avevo scritto, le mie constatazioni potevano essere sbagliate in quanto non sono in grado di comprendere la tipologia del test, e tu giustamente me lo hai confermato.
Scusa se insisto ma per un aumento di frequenza di circa il 25% nel CMP Normal c'è un miglioramento del 36% mentre nel CMP X8 c'è un miglioramento del 11% se adesso consideriamo che l'FX8150 nel CMP fa un +72% rispetto il 3770K, per pareggiarlo a che frequenze dovrebbe andare?
Vorrei solo capire di che aumento avrebbe bisogno l'FX8150 per pareggiare con il 3770K.

PS: Se ho sbagliato qualche percentuale chiedo anticipatamente scusa.

Aumentare i carichi nell'xtreme load in modalità CMP (oltre che per test di confronto) non ha un senso logico. L'approccio CMP non prevede carichi superiori.
Sarebbe stato giusto se io avessi fatto una guida piu dettagliata (ma mi scoccio pesantemente dopo tutti i codici che ho in testa) ove avrei dovuto specificare che per risultati genuini è consigliato aumentare i carichi solo nel caso CMT/SMT, e di testare settando le architetture relative a quelle reali, altrimenti gli script che eseguono le gestioni subiscono un omit code relativo all'hardware reale, dando appunto risutalti insensati (uno di questi è la negatività nel CMT a load disabilitato, ma in questo caso è colpa mia per una dimenticanza di finalizzazione di una variabile di uno script).

Quanto dovrebbe aumentare la frequenza l'FX per pareggiare il 3770k non lo so, ma ti posso dire una cosa: domani uppo sul blog di nuovo SOD ri-rettificato, a fine mese tiro fuori la versione 1.1. Devo finirmi di studiare bene alcuni documenti relativi all'architettura di sti FX, altrimenti non posso capire come strutturare a puntino gli script (e causa lavoro non ho sempre la possibilita di dedicare tutti i giorni a SOD, perchè devo finire altre soluzioni software per clienti). Con questo dico appunto che per quanto ottimizzato sia SOD per gli FX, non lo è nemmeno al 100%, ma non lo è nemmeno per le architetture SMT (anzi in questo caso peggio).
La 1.0 è una specie di cavia. La versione delta sarà la 1.1 di SOD.
Per il momento c'è quasi un pareggio dal punto di vista di comportamento del codice con le tre architetture, dove vede dedicati 6 script per la gestione architetturali, ottimizzati per il CMT.
Voi siete i tester, lascio a voi il giudizio, critica, e testing.

[paolo.oliva2]

Originariamente inviato da Diablo III

interessante domanda, a cui purtroppo non ti so dare una risposta precisa
volendo potrei provare a rifare le prove con l'8150 a 5/5.5ghz così da farsi un'idea un pò più precisa

se ti interessa la cosa ti faccio le prove e te le mando in pvt

Io credo che non ci siamo capiti... e a tal proposito mi sono permesso di scriverti in PVT.

Per lo sbaglio sulla frequenza def del 3770K, è che essendo fuori casa qua la connessione è penosa e non so le caratteristiche di quel procio, per cui leggendo altri post che davano +1GHz, ho dedotto che la frequenza def fosse 3,4GHz anzichè 3,5GHz, ma tuttavia la logica del mio post non è che cambia, se da 3,4GHz per il 3770K si passa a 3,5GHz, rimane pur sempre un OC di 800MHz per l'8150 e di 900MHz per il 3770K, che sicuramente non stravolge la situazione, ma è indubbio che la fa apparire più negativa di quello che è, diciamo che da un -50% circa si passerebbe ad un -48% circa, quindi non capisco la tua reazione dicendo di non postare più perchè la mia critica è da fan-boy, il tutto senza chiave ironica...

[Wolfhang]

Originariamente inviato da paolo.oliva2

Io credo che non ci siamo capiti... e a tal proposito mi sono permesso di scriverti in PVT.

Per lo sbaglio sulla frequenza def del 3770K, è che essendo fuori casa qua la connessione è penosa e non so le caratteristiche di quel procio, per cui leggendo altri post che davano +1GHz, ho dedotto che la frequenza def fosse 3,4GHz anzichè 3,5GHz, ma tuttavia la logica del mio post non è che cambia, se da 3,4GHz per il 3770K si passa a 3,5GHz, rimane pur sempre un OC di 800MHz per l'8150 e di 900MHz per il 3770K, che sicuramente non stravolge la situazione, ma è indubbio che la fa apparire più negativa di quello che è, diciamo che da un -50% circa si passerebbe ad un -48% circa, quindi non capisco la tua reazione dicendo di non postare più perchè la mia critica è da fan-boy, il tutto senza chiave ironica...

ma li hai visti i test a default con HT off ????

[bjt2]

Originariamente inviato da paolo.oliva2

Ciao Bjt2

Quotando il tuo post, anche io ho i miei dubbi circa le frequenze turbo, perchè se da una parte i +400MHz def risulterebbero fattibilissimi a parità di TDP, rispettando gli scalini del Turbo di Zambesi, risulterebbe da 4GHz a 4,3GHz la frequenza su tutti e 8 i core e 4,7GHz la frequenza masima su 4 core. Sono questi 4,7GHz Turbo def che mi lasciano perplesso...
Tra l'altro... tempo fa si diceva che il TurboCore 3.0 avrebbe forse implementato il turbo su 1 modulo... proprio il fatto che sembra passato sul dimenticatoio mi farebbe pensare a dei limiti di raggiungimento frequenze alte, perchè se fosse possibile raggiungere i 4,7GHz su 4 core vorrebbe dire un silicio che scalerebbe bene tra frequenza e TDP, quindi, a parità di TDP, con un carico su 2 core anzichè 4, dovrebbe guadagnare di più.
L'8150 poteva arrivare a 3,9GHz su 8 core, ma passando ad un carico massimo di 4 core, a parità di TDP guadagnava solamente 300MHz.

Per il resto, tra aumenti di frequenza e IPC, già solamente l'aumento di frequenza, se confermati i 4GHz, costituirebbe da solo un incremento prestazioni dell'11,11%, ed è ben diverso dall'IPC, perchè l'aumento di frequenza procio incrementa a 360° l'IPC, mentre un incremento i IPC di solito interessa alcune parti ed altre potrebbero essere del tutto escluse.

Quella del terzo step di turbo era una ipotesi... E' possibile che il turbo 3.0 sia solo più aggressivo e magari non sia ristretto a scalini fissi. Mi spiego. Sappiamo che il turbo 2.0 attiva il turbo max solo se ci sono la metà dei core attivi (e gli altri DEVONO essere in stato C6). Magari questo turbo è più tollerante e fa scattare il gradino più alto del turbo anche con tutti i core attivi ma solo se sono poco carichi. Poi può anche essere che il turbo 3.0 sia chiamato così solo per il turbo sulla GPU e che sulle versioni desktop non APU sia uguale al turbo 2.0...

[Folgore 101]

Originariamente inviato da Diablo III

interessante domanda, a cui purtroppo non ti so dare una risposta precisa
volendo potrei provare a rifare le prove con l'8150 a 5/5.5ghz così da farsi un'idea un pò più precisa

se ti interessa la cosa ti faccio le prove e te le mando in pvt

La cosa mi interessa, quindi se hai tempo e voglia te ne sarei grato, almeno si ragiona su dei numeri e si possono fare dei ragionamenti un po più mirati.

Originariamente inviato da shellx

Aumentare i carichi nell'xtreme load in modalità CMP (oltre che per test di confronto) non ha un senso logico. L'approccio CMP non prevede carichi superiori.
Sarebbe stato giusto se io avessi fatto una guida piu dettagliata (ma mi scoccio pesantemente dopo tutti i codici che ho in testa) ove avrei dovuto specificare che per risultati genuini è consigliato aumentare i carichi solo nel caso CMT/SMT, e di testare settando le architetture relative a quelle reali, altrimenti gli script che eseguono le gestioni subiscono un omit code relativo all'hardware reale, dando appunto risutalti insensati (uno di questi è la negatività nel CMT a load disabilitato, ma in questo caso è colpa mia per una dimenticanza di finalizzazione di una variabile di uno script).

Quanto dovrebbe aumentare la frequenza l'FX per pareggiare il 3770k non lo so, ma ti posso dire una cosa: domani uppo sul blog di nuovo SOD ri-rettificato, a fine mese tiro fuori la versione 1.1. Devo finirmi di studiare bene alcuni documenti relativi all'architettura di sti FX, altrimenti non posso capire come strutturare a puntino gli script (e causa lavoro non ho sempre la possibilita di dedicare tutti i giorni a SOD, perchè devo finire altre soluzioni software per clienti). Con questo dico appunto che per quanto ottimizzato sia SOD per gli FX, non lo è nemmeno al 100%, ma non lo è nemmeno per le architetture SMT (anzi in questo caso peggio).
La 1.0 è una specie di cavia. La versione delta sarà la 1.1 di SOD.
Per il momento c'è quasi un pareggio dal punto di vista di comportamento del codice con le tre architetture, dove vede dedicati 6 script per la gestione architetturali, ottimizzati per il CMT.
Voi siete i tester, lascio a voi il giudizio, critica, e testing.

Grazie per la spiegazione, attendiamo quindi l'evoluzione di SOD.
Io i test li farei pure ma con il mio Athlon XP 3000+ rischio di starci settimane per completarli.

[capitan_crasy]

Originariamente inviato da bjt2

Quella del terzo step di turbo era una ipotesi... E' possibile che il turbo 3.0 sia solo più aggressivo e magari non sia ristretto a scalini fissi. Mi spiego. Sappiamo che il turbo 2.0 attiva il turbo max solo se ci sono la metà dei core attivi (e gli altri DEVONO essere in stato C6). Magari questo turbo è più tollerante e fa scattare il gradino più alto del turbo anche con tutti i core attivi ma solo se sono poco carichi. Poi può anche essere che il turbo 3.0 sia chiamato così solo per il turbo sulla GPU e che sulle versioni desktop non APU sia uguale al turbo 2.0...

Il Turbo core 3.0 introduce un pstate alla GPU integrata in Trinity, aumentando la frequenza di quest'ultima lasciando invariata quelle dei core X86; le altre funzioni sono uguali a quelle di BD.



Secondo molte voci il fatto che AMD abbia dovuto immettere una revisione del vecchio socket non compatibile con le soluzioni precedenti è derivato proprio dal turbo core 3.0.
Vishera utilizzando lo stesso socket di Bulldozer e non avendo la GPU integrata non dovrebbe subire modifiche nei numero dei pstate; si spera che aumenti l'efficienza di questa tecnologia alquanto scarsa come tempi di interventi (in alcuni casi con alcuni programmi non interviene neanche)...

[bjt2]

Originariamente inviato da capitan_crasy

Il Turbo core 3.0 introduce un pstate alla GPU integrata in Trinity, aumentando la frequenza di quest'ultima lasciando invariata quelle dei core X86; le altre funzioni sono uguali a quelle di BD.



Secondo molte voci il fatto che AMD abbia dovuto immettere una revisione del vecchio socket non compatibile con le soluzioni precedenti è derivato proprio dal turbo core 3.0.
Vishera utilizzando lo stesso socket di Bulldozer e non avendo la GPU integrata non dovrebbe subire modifiche nei numero dei pstate; si spera che aumenti l'efficienza di questa tecnologia alquanto scarsa come tempi di interventi (in alcuni casi con alcuni programmi non interviene neanche)...

I registri architetturali supportano fino a 8 p-state che possono anche essere uno normale e 7 di turbo. Le basi ci sono. Bisogna solo implementarle. Avere 3 p-state di turbo non è impossibile. Il problema del non intervento potrebbe essere dovuto al non spegnimento completo dei core: devono essere in stato C6, ossia parcheggiati, altrimenti il turbo massimo non interviene e il consumo dei core in idle potrebbe non far scattare neanche il primo step di turbo....

[shellx]

Tra le altre cose l'utente °Phenom° dovrebbe aprire il thread dedicato a SOD (sta aspettando una risposta dal mod per alcune dritte), per cui tutti (pro-amd e pro-intel) posteranno li, cosi si esclude il problema: "non posto in questo thread perchè il mio compagno è stato cattivo e mi ha dato le botte". Che tra le altre cose quando subentrano contesti amd vs intel che prendono direzioni eccesse, si cade nell'ot.

Per cui meglio fare tutto nel thread specifico cosi non essendoci una regola di thread ma solo quelle di forum, si puo parlare di intel quanto di amd e ci si puo scannare in beata armonia (rispettando sempre il forum e gli utenti).

[affiu]

a diablo
secondo voi sono esagerate queste ipotesi che penso su vishera sempre parlando di simulazioni approssimative e tenendo conto della scalabilità dell'architettura con la frequenza:

partendo da questa recensione: http://www.insidehardware.it/hardwar...art=13#content

in questo confronto vediamo che (in media,con quei programmi) un fx8150 rispetto ad un phenom2 980 sta a +15% mentre un 2600k a + 30%, quindi la differenza tra un 2600k (secondo la media di quei programmi testati) ed un fx sarebbe 30 -15 = 15% inferiore ad un 2600k e stesso discorso anche per il 2500k ,che risulta il 121-115= un 6% inferiore ''spalmato'' in quei programmi.

in overclock a 4500 mhz(se non ho letto male) cioè a + 900 mhz rispetto alla frequenza default l'fx 8150 ottiene un 26% piu veloce di un phenom 980 e dunque sarebbe solo un 4% inferiore rispetto a sandy ,giustamente quest'ultimo a default.
Ora parte la fantasia ,perchè a quanto ho letto sul web di un fx 8150 e trinity ,chiaramente disabilitato 4 core ,in modo da fare il confronto e nonostante la l3 non ci sia ,trinity va piu veloce del 15%= LO CHIAMEREMO IPC(ed a questo per essere pignoli dobbiamo aggiungerci la cache l3 di vischera e windows 8,e da qui penso che altri 3-5% tra tutte e 2 le cose escono fuori!)

gia solo questo 15%(o anche il 10%), spalmato su questi stessi programmi , porterebbero l'fx a posizionarsi a 15+15(ipc)= 30 % maggiore rispetto a 980 e dunque pareggio con sandy.
da quel grafico possiamo(sempre approssimativamente )vedere che 900 mhz di frequenza in overclock apportano un +11% di velocità ,CIOè 126(fx overclock) -115(fx default)% =11% di performance in media tra quei programmi.

questi ''punti'' percentuali associati ,sempre secondo quella media, alla frequenza ci dicono che 11 punti % diviso 9 (corrispondente ai 900mhz) significa che bulldozer guadagna circa 1,2 punti% ogni 100 mhz di frequenza .

ad esempio un fx 8350 a 4000 mhz default corrisponderebbe ad
400 mhz (che sono in piu rispetto all'8150 default) corrisponderebbero a 1,22(punteggio approssimativo per ogni 100 mhz) x 4 = 4,88%
a questa aggiungiamo nella peggiore delle ipotesi anche un 10%(o 15%) di IPC farebbe

10ipc + 4,88 =circa 15%(o 20% se fosse 15% di ipc) e qui siamo in parità con sandy e sempre a default.
se poi a questo aggiungiamo 1 ghz di overclock ,cioe da 4 ghz default +dissipatore = 5ghz , avremo un + 12% che si somma.

quindi magicamente e matematicamente se si potesse tenere in daily a 5 ghz ,rispetto a zambezi di oggi avremo:

15 % di ipc + 1400(per arrivare a 5ghz e rispetto ai 3,6 ghz dell'fx 8150) mhz di overclock e considerando che 100 mhz corrispondono(approssimativamente e considerando la scalabilità dell'architettura) a 1,22 % avremo 14 x1,22 = 17,11%
se per DISGRAZIA PILEDRIVER avesse il 20% di ipc sommato al famoso daily 5ghz sarebbero:
20% di ipc + 17 % dovuto sempre ai 1400 mhz di overclock per arrivare a 5 ghz, + windows pacth 3% = 40% tondi tondi.

stesso discorso per l'8320 cioe rispetto al 8120 di oggi ,rispetto a quella media , sarebbe ad un + 9% (considerando i 500 mhz in meno ,cioe 5 x 1,22 in meno) rispetto al 980 e inferiore del 12% rispetto al 2500k a default ,quindi con il 15 %(di previsione) di ipc proveniente dal core piledriver si va verso pareggio anche con lui.

poi se proprio dobbiamo dare sfogo alla scimmia ,ci sarebbe pure da mettere in conto che altri 5-10% da steamroller ed altri 5-10% da excavator ,come ipc e siamo abbondantemente oltre il 40% rispetto al'fx8150 ....ecco ,secondo me,perchè non serve affatto un x10 buldozer.

infine se proprio uno deve essere cattivo ,un semplice ed IPOTETICO fx 8350 overcloccato a liquido a 5,4 ghz corrisponde rispetto al 8150 default a:

15% di ipc + 11% dovuto ai 900mhz visto nella recensione (da 3,6 a 4,5) + 11% dovuto ad altri 900 mhz(da 4,5 ghz a 5,4). totale 37%; piu semplice di cosi ,tenedo conto sempre di quella media di programmi e simulando le permormance ,approsimativamente ci siamo,secondo me.
e vero che gli struzzi non volano e che gli elefanti non sono velocissimi ,ma se la storia sembra ''questa'' tra piledriver-steamroller-excavator , forse vedremo gli elefanti correre come ghepardi!

[gianni1879]

ho pulito il thread da discussioni inutili, per l'ennesima volta.

Vedete di darvi una calmata e se avete qualcosa su cui discutere fatelo in pvt.

Grazie

[Pat77]

affiu

Non si può prendere una media e farne un trattato.
Ti do 2 percentuali ricavate da numeri reali:

Il distacco in SOD rispetto a un 3770k è di circa l'80%, cioè BD x8 richiede l'80% di frequenza in più per pareggiare i risultati di 3770K.
In handbrake, scoppattando 11 Gb di filmato in modalità iphone, il distacco scende a circa il 30% su 3770K e del 2-3% su 3570k.
Quindi per pareggiare i conti, in alcuni ambiti, Piledriver deve andare almeno il 30% meglio, tra frequenza e ipc, rispetto alla generazione precedente.

[carlottoIIx6]

Originariamente inviato da Pat77

affiu

Non si può prendere una media e farne un trattato.
Ti do 2 percentuali ricavate da numeri reali:

Il distacco in SOD rispetto a un 3770k è di circa l'80%, cioè BD x8 richiede l'80% di frequenza in più per pareggiare i risultati di 3770K.
In handbrake, scoppattando 11 Gb di filmato in modalità iphone, il distacco scende a circa il 30% su 3770K e del 2-3% su 3570k.
Quindi per pareggiare i conti, in alcuni ambiti, Piledriver deve andare almeno il 30% meglio, tra frequenza e ipc, rispetto alla generazione precedente.

amd andrà meglio in quei programmi che sono più ottimizzati per la sua architettura.

[sergio.p.]

fudzilla dice che http://www.hwupgrade.it/news/cpu/3-v...-fx_43101.html

certo che 100w tra gpue cpu@3.8 lasciava sperare meglio di 125w per vishera x4 @4.2, è pur sempre silicio scartato essendo ritagli degli octa''core'' e la fonte è pur sempre fudzilla

[shellx]

Io continuo a domandarmi come un dannato: se gli ultimi rumors danno trinity per ottobre, vishera (che è sempre stato previsto per lo stesso mese piu o meno) uscira prima, contemporaneamente o dopo ?

Seguendo il concetto degli scalini delle uscite cpu (prima degli ultimi rumors) praticamente avremo vishera a novembre minimo... ?

hardware upgrade dice: Il debutto di questi processori, basati su architettura Piledriver, dovrebbe avvenire nel corso del mese di Ottobre assieme o in prossimità del lancio delle APU della famiglia Trinity per sistemi desktop.

Mi viene da pensare: inizi ottobre trinity, fine ottobre vishera ?
mah speriamo...ma stento a crederci...

[Catan]

Se pensi che lo scorso anno a novembre è stato commercializzato bd, siamo in linea con le tempistiche ed le slide amd.
semplicemente sembra che abbiano anticipato le apu, tutto qui.

[shellx]

Originariamente inviato da Catan

Se pensi che lo scorso anno a novembre è stato commercializzato bd, siamo in linea con le tempistiche ed le slide amd.
semplicemente sembra che abbiano anticipato le apu, tutto qui.

La commercializzazione di Zambesi è partita il 12 Ottobre. Llano tre mesi prima a Luglio.
Trinity è stato posticipato rispetto la data di uscita di llano. E se Vishera uscirà come detto da hwupgrade in prossimità del lancio di Trinity allora rispetterà la stessa data (piu o meno, forse qualche giorno oltre il 12 di ottobre stavolta) di Zambesi. Ma se verra posticipato a Novembre anche vishera come trinity subisce una data d'uscita piu tardiva rispetto lo stesso periodo dei corrispettivi zambesi e llano dell'anno precedente.

[paolo.oliva2]

Originariamente inviato da Pat77

affiu

Non si può prendere una media e farne un trattato.
Ti do 2 percentuali ricavate da numeri reali:

Il distacco in SOD rispetto a un 3770k è di circa l'80%, cioè BD x8 richiede l'80% di frequenza in più per pareggiare i risultati di 3770K.
In handbrake, scoppattando 11 Gb di filmato in modalità iphone, il distacco scende a circa il 30% su 3770K e del 2-3% su 3570k.
Quindi per pareggiare i conti, in alcuni ambiti, Piledriver deve andare almeno il 30% meglio, tra frequenza e ipc, rispetto alla generazione precedente.

Una cosa è il guadagno prestazionale tra Piledriver e Zambesi, che rappresenta lo spazio di incremento che puo' avere l'architettura BD.

Il confronto invece con altri processori è diverso, perchè una cosa è l'acquisto della massima potenza disponibile sul mercato, e qui se solamente uno la puo' offrire, non c'è alternativa, un'altra invece è l'acquisto di una determinata potenza che 2 fornitori la possono offrire, e qui interviene il confronto prezzo.

Se un 8350 va l'80% in meno del procio X, rimane comunque un prodotto valido se costa pure l'80% in meno del procio X e se la potenza e soddisfacente al suo utilizzo. Da quanti anni AMD non commercializza un processore la cui potenza massima è simile a quella di Intel? Eppure vende ugualmente...

[Pat77]

Originariamente inviato da paolo.oliva2

Una cosa è il guadagno prestazionale tra Piledriver e Zambesi, che rappresenta lo spazio di incremento che puo' avere l'architettura BD.

Il confronto invece con altri processori è diverso, perchè una cosa è l'acquisto della massima potenza disponibile sul mercato, e qui se solamente uno la puo' offrire, non c'è alternativa, un'altra invece è l'acquisto di una determinata potenza che 2 fornitori la possono offrire, e qui interviene il confronto prezzo.

Se un 8350 va l'80% in meno del procio X, rimane comunque un prodotto valido se costa pure l'80% in meno del procio X e se la potenza e soddisfacente al suo utilizzo. Da quanti anni AMD non commercializza un processore la cui potenza massima è simile a quella di Intel? Eppure vende ugualmente...

Non so che dirti Paolo, abbiamo una visione diversa, e dirti che in "aspettando" la pensavamo in modo simile, anche tu sei inorridito quando OBR disse che non arrivava a 6 punti nel cinebench multi, AMD con Phenom 2 che si confrontava con un I7 920-930 non aveva comunque ancora accumulato tutto questo svantaggio e la differenza di prezzo era simile, sai già che per me la base deve cambiare, e se non hanno fondi a questo punto penso che per avere un po' di concorrenza forse sarebbe il caso che qualche grande gruppo pensasse all'acquisto di AMD.

[Pinco Pallino #1]

Dico la fesseria del giorno (qualcuno lo deve pur fare)...


Visto che AMD va forte nelle GPU...
Invece di una CPU con GPU integra non potrebbero fare il contrario?
Una GPU che macina codice x86.

Rincaro pure la dose...

Le schede video AMD saranno dotate di socket e faranno appositi driver in modo che la GPU possa essere vista come una CPU aggiuntiva o come un coprocessore.