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

[The3DProgrammer]

Non mi pare che sia stato riportato, se e' stato fatto cancello il post:

http://www.anandtech.com/show/5448/t...g-patch-tested


Tutto come previsto, cmq coi giochi + cpu bound si ha un miglioramento medio da non disprezzare (secondo me sarebbero stati + indicativi gli fps minimi a bassa risoluzione ma vabbe'). Certo che lo spostare continuamente i thread da un core all'altro non aiuta il turbo di BD, altrimenti penso che avremmo potuto vedere qualche miglioramento anche in ST.
Detto qusto adoro anandtech

[paolo.oliva2]

Originariamente inviato da Randa71

ciao Paolo. volevo capire meglio con degli esempi questa cosa perche' mi ci sto cimentando anche io.... sono a 4.2 ghz con 1.280-1.296 con la cpu in fullload occt..e mi sembra un voltaggio basso per 4.2 solo che facendo bench mi sembra che le perf ci siano. per questo ti chiedevo un esempio... se vuoi continuiamo nel thread apposito cosi nn inquiniamo questo... ciao

Ti rispondo veloce qui perchè con la connessione che ho non riesco a rintracciare le altre discussioni (al limite metti il link).

Il tutto è nato quando Bjt2 ha chiesto di fare un test Vcore def/aumento di frequenza per valutare il margine del silicio, e quindi la sua bontà.
Praticamente, per fare questo test, in primis bisogna impostare un Vcore fisso da bios non modificabile, poi CPUZ attivo per mostare il Vcore/frequenza e Cinebench pronto da lanciare il bench per valutare un approssimativo RS.
(vado a memoria...)
Quindi... 1,3V Vcore fissi, 3,6GHz, 3,7GHz, 3,8GHz, 3,9GHz, fin qui Cinebench forniva un risultato proporzionato all'aumento della frequenza... a 4GHz il risultato comincio' a decadere, praticamente non c'era alcun incremento rispetto a 3,9GHz, cosi' pure a 4,1GHz. Se invece provvedevo ad aumentare il Vcore, allora il risultato tornava proporzionato alla frequenza.
Nell'OC massimo, se supero 1,525V di Vcore, si presenta il medesimo calo prestazionale, segno che a 5GHz il silicio del mio procio è alla frutta... ma direi pure al caffè e digestivo già digerito

[aldooo]

Originariamente inviato da The3DProgrammer

http://www.anandtech.com/show/5448/t...g-patch-tested
...
Detto qusto adoro anandtech

Bah, non ha testato eventuali variazioni di consumi dovuti alla patch.

[digieffe]

Originariamente inviato da The3DProgrammer

Non mi pare che sia stato riportato, se e' stato fatto cancello il post:

http://www.anandtech.com/show/5448/t...g-patch-tested


Tutto come previsto, cmq coi giochi + cpu bound si ha un miglioramento medio da non disprezzare (secondo me sarebbero stati + indicativi gli fps minimi a bassa risoluzione ma vabbe'). Certo che lo spostare continuamente i thread da un core all'altro non aiuta il turbo di BD, altrimenti penso che avremmo potuto vedere qualche miglioramento anche in ST.
Detto qusto adoro anandtech

quel 4% di media corrisponde a circa 150 mhz di turbo in più...
nel senso che in media la frequenza sarà più vicina a quella massima del turbo in questione...

[Grizlod®]

Perdonate la domanda, forse ovvia,...ma il moltiplicatore del NB, negli FX è sbloccato anche verso l'alto?? Non mi è chiaro

[paolo.oliva2]

Originariamente inviato da Grizlod®

Perdonate la domanda, forse ovvia,...ma il moltiplicatore del NB, negli FX è sbloccato anche verso l'alto?? Non mi è chiaro

E' TUTTO sbloccato... molti procio, molti NB, frequenza bus che influisce sia nella frequenza finale clock procio che in quella NB.

[Grizlod®]

Originariamente inviato da paolo.oliva2

E' TUTTO sbloccato... molti procio, molti NB, frequenza bus che influisce sia nella frequenza finale clock procio che in quella NB.

Ti ringrazio (anche per la celerità )...con l'ultima frase, intendi l'Hyper Transport...giusto!?

[paolo.oliva2]

Originariamente inviato da digieffe

quel 4% di media corrisponde a circa 150 mhz di turbo in più...
nel senso che in media la frequenza sarà più vicina a quella massima del turbo in questione...

Volevo capire una cosa... perchè non ho seguito appieno la questione e non mi è chiaro le differenze da prg a prg.

Da quello che scrivi... io intuirei come se le patch facessero questo:
(valori a caso giusto per spiegarmi)
supponendo che il core parte con la frequenza def e impiegasse mezzo secondo per salire di frequenza a step di 100MHz, impiegherebbe 1,5" per passare da 3,6GHz a 3,9GHz, ma se l'SO passa il carico al core seguente ogni secondo, di fatto i 3,9GHz non si arriverebbero mai.
Se la patch invece di cambiare core ogni secondo lo facesse ogni 2 secondi, allora chiaramente aumenterebbe la media e quindi, trattandosi dello stesso procio (8150) e quindi con lo stesso silicio con gli stessi limiti di TDP/frequenza, mi pare palese che la frequenza inferiore del turbo era a causa di una cattiva gestione dell'SO e non per limitazioni del TDP.
Mi pare chiaro che questo vantaggio del 4% interessi specificatamente BD, quindi se ipotizzassimo che tutti i proci guadagnassero il 10% nel passaggio a Windows 8, BD oltre a questo 10% vedrebbe aggiuntivo anche questo 4% che sarà già integrato nell4SO senza bisogno di patch.

Inoltre, la cosa riscuote ancor più importante nell'ipotesi di un 8170 e 8190, perchè in un range di frequenza da 3,6 a 3,9GHz se il turbo lavora a 3,68GHz per rimanere dentro i 125W ed invece puo' passare tramite un patch/fix della gestione core a 3,8GHz, un 8170, 3,9GHz 125W TDP richiederebbe un aumento di 220MHz sul silicio, mentre questa patch ridurrebbe solamente a 100MHz quello da recuperare.

[marchigiano]

Originariamente inviato da shellx

ecco tipo questa è una cosa che non ho provato, domani mi procuro un tester mi voglio togliere sta curiosità.
Mi spieghi sta cosa dell'offset, sono ignorante in ambito OC e voci bios delle mobo. E' una voce nel bios ?

l'offset è la differenza tra valore reale e letto, c'è sia per le tensioni che per le temperature

alcune mobo ti permettono di correggerlo (tipo hai misurato +0.2V? allora regoli a -0.2V e si pareggia), altre no, comunque secondo me serve a poco saperlo, l'importante è conoscere il consumo totale del sistema e le temperature della cpu

[paolo.oliva2]

Originariamente inviato da Grizlod®

Ti ringrazio (anche per la celerità )...con l'ultima frase, intendi l'Hyper Transport...giusto!?

No... l'HT è si influenzato dalla frequenza del bus, ma comunque ha un suo molti a parte, anch'esso libero ad aumenti/diminuzioni... ma non lo considero perchè non apporta aumenti prestazionali... anzi, foss'anche diminuito del 50%, non perderesti nulla (non so con un sistema SLI, ma credo di no comunque)

[shellx]

Originariamente inviato da Grizlod®

Ti ringrazio (anche per la celerità )...con l'ultima frase, intendi l'Hyper Transport...giusto!?

L'aumento di frequenza dell'ht potrebbe apportare migliore sulle periferiche collegate al pci-e, visto che la comunicazione principale è tramite il controller pci-e nel northbridge sulla mobo verso i PCI-E. Ergo conf. SLI/CF. Anche se la cosa comunque non è abissale.

Lui si riferische al bus di sistema del procio (un tempo e ancora oggi chiamato FSB).

[Grizlod®]

Originariamente inviato da shellx

............
Lui si riferische al bus di sistema del procio (un tempo e ancora oggi chiamato FSB).

Ahh...sì...ma lo davo per scontato; è libero anche sù CPU non Black Edition (diciamo così)e mi sa che dipenda dalla mainboard più che dal processore. Cmq, thanks a lot...

[shellx]

Originariamente inviato da Grizlod®

Ahh...sì...ma lo davo per scontato; è libero anche sù CPU non Black Edition (diciamo così)e mi sa che dipenda dalla mainboard più che dal processore. Cmq, thanks a lot...

E' sempre libera perchè quello non è un moltiplicatore, è la frequenza del clock della cpu, che a sua volta viene moltiplicata con il valore del ratio della cpu ( i byte-word) determinando la banda del front side bus. E comuqnue l'fsb è il bus principale che passa anche dal northbridge e dal southbridge sulla mobo, collegando la connessione cpu con il resto dell'hardware tramite i chipset. Come le radici di un albero tutti gli altri bus si collegano a sua volta all'fsb, e dipendono dalla sua velocità. Esempio il bus HT che genera la frequenza di banda sui pci-e dipende anch'esso dalla frequenza dll'fsb, ecco perchè potrebbe acquisirne prestazioni sulle periferiche collegate sul pci-e, se l'fsb viene incrementato. Ma a volte il fenomeno non è abissale in quanto dipendendo appunto dall'fsb puo il bus ht essere asincrono e creare colli di bottiglia. Come accadeva quando l'MC il bus delle memorie era gestito dal northbridge, oggi invece è integrato sulla cpu. E molto presto anche il bus HT sata integrato definitivamente nella cpu. Per cui l'fsb genererà come oggi il suo clock trasferendolo solo al chipset FCH (o southbridge) per collegare i sotto bus collegati a suo volta all'fch o southbridge (pci-e a bassa velocita, lpc, bus controller hub I/O e il bus per il clock sulla cpu).
A volte il trasferimento di banda dell'fsb è indicato in MT/s megatrasfer e no megaherz. Ed è indicato sull amobo con la voce HTT (da non confondere con l'HT).
Prova a dar eun occhiata a questa, solo che oggi la situazione non è proprio in quel modo, perchè il northbridge non ha piu il controller memory e quindi un bus memory, in quanto come dicevo prima è integrato nella cpu, lo stesso vale per il controller onboard graphics, ormai non esistono piu mobo con video integrata, anch'essa è sulla cpu oggi.
Praticamente oggi (tranne per le 990fx) tutte le altre mobo e fascie sia amd che intel, l'fsb genera clock nella cpu e per la cpu con il controller di generatore di clock, e dalla cpu verso solo l'fch (o southbridge).
Comunque l'fsb è sempre stata libero su tutte la mobo.

[digieffe]

Originariamente inviato da paolo.oliva2

Volevo capire una cosa... perchè non ho seguito appieno la questione e non mi è chiaro le differenze da prg a prg.

Da quello che scrivi... io intuirei come se le patch facessero questo:
(valori a caso giusto per spiegarmi)
supponendo che il core parte con la frequenza def e impiegasse mezzo secondo per salire di frequenza a step di 100MHz, impiegherebbe 1,5" per passare da 3,6GHz a 3,9GHz, ma se l'SO passa il carico al core seguente ogni secondo, di fatto i 3,9GHz non si arriverebbero mai.
Se la patch invece di cambiare core ogni secondo lo facesse ogni 2 secondi, allora chiaramente aumenterebbe la media e quindi, trattandosi dello stesso procio (8150) e quindi con lo stesso silicio con gli stessi limiti di TDP/frequenza, mi pare palese che la frequenza inferiore del turbo era a causa di una cattiva gestione dell'SO e non per limitazioni del TDP.
Mi pare chiaro che questo vantaggio del 4% interessi specificatamente BD, quindi se ipotizzassimo che tutti i proci guadagnassero il 10% nel passaggio a Windows 8, BD oltre a questo 10% vedrebbe aggiuntivo anche questo 4% che sarà già integrato nell4SO senza bisogno di patch.

Inoltre, la cosa riscuote ancor più importante nell'ipotesi di un 8170 e 8190, perchè in un range di frequenza da 3,6 a 3,9GHz se il turbo lavora a 3,68GHz per rimanere dentro i 125W ed invece puo' passare tramite un patch/fix della gestione core a 3,8GHz, un 8170, 3,9GHz 125W TDP richiederebbe un aumento di 220MHz sul silicio, mentre questa patch ridurrebbe solamente a 100MHz quello da recuperare.

L'articolo di Anand dice che non c'è guadango in ST e neanche con 8 thread ma in situazioni con pochi thread, quindi con 8 thread restano 3.68ghz (di media), con 1 thread dovrebbe essere a 4.2 ghz, con un valore di pochi (4 ?) migliora del 4%

ipotizzo che ci siano 2 fattori:

1 - quello di non ricaricare le caches per il continuo spostamento del thread (ricordiamoci però che se il thread viene caricato sull'altro core dello stesso modulo ci sarebbe da ricaricare solo la L1)
NON so quanto questo fattore influenzi, però sicuramente più dell'intel che ha la L2 con latenze bassissime.

2 - quello di far salire il turbo più in alto, semplificando, come da tuo esempio (ci sono anche altri fattori nel turbo, non solo questione di tempo).
Azzarderei: il secondo stadio di turbo si avvicina più ai 4.2 come media

[paolo.oliva2]

Originariamente inviato da digieffe

L'articolo di Anand dice che non c'è guadango in ST e neanche con 8 thread ma in situazioni con pochi thread, quindi con 8 thread restano 3.68ghz (di media), con 1 thread dovrebbe essere a 4.2 ghz, con un valore di pochi (4 ?) migliora del 4%

ipotizzo che ci siano 2 fattori:

1 - quello di non ricaricare le caches per il continuo spostamento del thread (ricordiamoci però che se il thread viene caricato sull'altro core dello stesso modulo ci sarebbe da ricaricare solo la L1)
NON so quanto questo fattore influenzi, però sicuramente più dell'intel che ha la L2 con latenze bassissime.

2 - quello di far salire il turbo più in alto, semplificando, come da tuo esempio (ci sono anche altri fattori nel turbo, non solo questione di tempo).
Azzarderei: il secondo stadio di turbo si avvicina più ai 4.2 come media

Pero'... sono 2 cose differenti e distinte.

Cioè, nella prima, ci sarebbe un incremento di IPC, perchè non si dovrebbero caricare e scaricare la L1/L2/L3.
Che le latenze in AMD siano superiori a uelle Intel, è chiaro, ma la vera differenza è che Intel, avendo la L3 inclusiva, di fatto l'operazione di cambio core interesserebbe solo L3 verso la L2 interessata, mentre in AMD comunque si aggiungerebbe lo spostamento dalla L2 alla L3.
Poi, non so se l'SMT possa interessare, perchè di fatto ipotizzando un carico di 8 TH con 8 core fisici per AMD e 8 logici su 4 fisici per Intel, di fatto nel 50% dei casi Intel comunque ritroverebbe il dato nella L2 cosa che con AMD sarebbe impossibile.

Nella seconda, sarebbe unicamente un punto di incontro tra l'SO e la logica TurboCore per uno sfruttamento migliore.
L'articolo di Anand non l'ho letto per prb connessione, pero' lo troverei strano... Cioè, con pochi TH (4) incrementa fino al 4%, e fino a qui ci siamo... con 8 TH non incrementerebbe nulla... il che sarebbe illogico se la patch ottimizzasse unicamente il salto da core a core...
Se invece la patch variasse la logica TurboCore per sfruttare sino all'ultimo W TDP disponibile, potrei capire che con 8 TH non si abbiano guadagni, ma nello stesso tempo allora in ST dovrebbe concedere più frequenza semplicemente perchè 1 core non consuma come 4...

Io torno sulla mia idea iniziale... JF aveva detto che tra frequenza def e frequenza massima Turbo si arrivava ad 1GHz di differenza.
A tutt'oggi, a parte i BD Opteron (perchè la frequenza def è inferiore), non si arriva a queste differenze e collegandosi anche all'affermazione, sempre di JF, che 2 TH a modulo avrebbero reso di più che 2 TH su 2 moduli, ed abbiamo visto che cio' sarebbe stato possibile unicamente se la percentuale di frequenza per il Turbo fosse stata maggiore della percentuale persa in IPC per 2 TH a modulo anzichè 1 TH.
In poche parole... sparando dati con valori simbolici, se 1 TH a modulo concedesse +10% di IPC, 2 TH a modulo, per rendere di più, il turbo deve concedere una percentuale di frequenza maggiore di quella di incremento IPC per 1 TH a modulo.
Io credo che finchè AMD pensava di riuscire ad ottenere le frequenze uguali alle aspettative, abbia lavorato nell'ottica TurboCore in una certa direzione... poi si è trovata nella condizione il Turbo portava meno guadagno rispetto che a dividere i TH a modulo... e credo che la potenza ST ne sia un esempio eclatante... quindi ha dovuto per forza aumentare la frequenza def al massimo rinunciando quasi a quella Turbo (e 3,6GHz def e 3,680GHz Turbo ne sarebbero l'esempio)... allora forse questa patch ottimizza unicamente dove c'è margine nel TDP e chiaramente non nella frequenza massima a 1 TH (proprio per le caratteristiche consumo/frequenza di questo step silicio anche con 1 core solo sotto carico) e nemmeno nella condizione 8 TH.

[Pat77]

Originariamente inviato da The3DProgrammer

Non mi pare che sia stato riportato, se e' stato fatto cancello il post:

http://www.anandtech.com/show/5448/t...g-patch-tested


Tutto come previsto, cmq coi giochi + cpu bound si ha un miglioramento medio da non disprezzare (secondo me sarebbero stati + indicativi gli fps minimi a bassa risoluzione ma vabbe'). Certo che lo spostare continuamente i thread da un core all'altro non aiuta il turbo di BD, altrimenti penso che avremmo potuto vedere qualche miglioramento anche in ST.
Detto qusto adoro anandtech

Sinceramente a basse risoluzioni nei giochi pensavo andasse un pochino meglio, certo non stravolge il livello di performance, ma è comunque un segnale positivo.
Quello che manca veramente è una revision che migliori i consumi imho.

[winebar]

Originariamente inviato da paolo.oliva2

allora forse questa patch ottimizza unicamente dove c'è margine nel TDP e chiaramente non nella frequenza massima a 1 TH (proprio per le caratteristiche consumo/frequenza di questo step silicio anche con 1 core solo sotto carico) e nemmeno nella condizione 8 TH.

La patch va ad evitare che i thread saltino tra i vari core, rimandendo assrgnati allo stesso core finchè non viene finito il task.
Inoltre se hai 2 thread che fanno uso di risorse simili in termini di memoria, nel senso che alcuni dati servono a entrambi i processi, vengono assegnati allo stesso modulo, in modo da ridurre i consumi, abilitare il turbo max.
Ricroda che il margine di TDP per determinare il turbo da applicare è gestito dal processore stesso in tempo reale.

[paolo.oliva2]

Originariamente inviato da winebar

La patch va ad evitare che i thread saltino tra i vari core, rimandendo assrgnati allo stesso core finchè non viene finito il task.
Inoltre se hai 2 thread che fanno uso di risorse simili in termini di memoria, nel senso che alcuni dati servono a entrambi i processi, vengono assegnati allo stesso modulo, in modo da ridurre i consumi, abilitare il turbo max.

Si, ma la gestione di salto carico da core a core dell'SO, agisce solamente quando ci sono core liberi o comunque è una rotazione fissa?
Perchè osservando il carico dei core, se lancio 8 applicazioni ST con affinità ognuna a core differente, i core lavorano abbastanza linearmente, cosa che non succede con applicazioni con più TH lasciati liberi di ballare da core a core. Ad esempio, lanciando 4 istanze di WinRar, 2 su 2 moduli + 2 sugli altri 2 moduli, i tempi sono migliori nel complesso che lasciati su 4 moduli, semplicemente perchè la probabilità di cambio modulo diminuirebbe del 50%.
Quindi, sempre se la mia valutazione fosse giusta, se la patch intervenisse nel non far saltare il tast da un core all'altro, il guadagno dovrebbe essere maggiore con 8 TH attivi anzichè con 4, cosa che non succede.

Ricroda che il margine di TDP per determinare il turbo da applicare è gestito dal processore stesso in tempo reale.

Si, per un totale di volte al secondo, ma è sempre influenzato dal carico e comunque parte sempre dalla frequenza def per poi salire in base al carico.
Estremizzando, ti faccio questo esempio: facciamo finta che il rimbalzo da core a core sia 1000 volte al secondo e che il procio possa gestire la frequenza massima in base al carico sempre 1000 volte al secondo (ma è molto più alta), cosa succederebbe? Che il turbo non entrerebbe mai in funzione.
Poi, per assurdo, nel caso di rimbalzo task da modulo a modulo, in ogni caso il turbo non sarà attivo in ambedue (forse), quindi se il modulo 2 è in turbo e di conseguenza quindi la sua L2 ed L3 perchè non ha carico, comunque aspetterebbe i dati dalla L2 e L3 dell'altro modulo che magari non è in Turbo e quindi a velocità inferiori... quindi sarebbe poi inutile valutare le medie.

Non voglio fare il capiscione, sia chiaro , pero' comunque tra patch e risposta procio ci sono delle divergenze che non sarebbero tutte nella stessa direzione (a mio parere), quindi un qualche cosa di più di impiccio che non sappiamo ci dovrebbe essere.

[gianni1879]

Penso interessi a tutti i possessori di cpu AMD FX:

http://www.xtremehardware.it/news/ha...-201201316379/

sconto in vista

[jolly74]

Originariamente inviato da Pat77

Sinceramente a basse risoluzioni nei giochi pensavo andasse un pochino meglio, certo non stravolge il livello di performance, ma è comunque un segnale positivo.
Quello che manca veramente è una revision che migliori i consumi imho.

OT
Come tieni dissipato il tuo 2500K a quella frequenza ?

Tornando in topic , anche con la patch i miglioramenti sono troppo risicati , e la storia dello sconto mi sa di bazza per i rivenditori , che continueranno a prezzarli alla stessa maniera , beneficiando loro del vantaggio economico , poi magari sbaglio ....