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

[shellx]

Originariamente inviato da Athlon 64 3000+

http://www.xtremesystems.org/forums/...wise-at-launch

Presunto benchmark dell'FX-8170.
Mi sa di fake.

Beh io guardando cpu-z alle voci Stepping e Revision, vedo dei rettangolini bianchi accanto al "3".
Sono normali ?

Nella schermata di Cinebench, alla voce del nome della cpu "processor" la sigla 8170 del procesorre: il 7 lo vedo troppo poco allineato , tendente verso l'1! poco centrato fra i due numeri.

E per finire, CPUID Hardware Monitor: riporta i dettagli di un FX8120...per quale motivo ?

C'èe qualcosa che non ho capito ?

[tuttodigitale]

edit ho fatto un ragionamento su un dato sbagliato
comunque è indubbio che le dimensioni di BD con 8 MB di cache in meno sarebbero molte vicine a quelle di SB.

[paolo.oliva2]

Originariamente inviato da Ares17

non ho capito bene:
1 conversione 1h
4 conversioni 2h?

Le percentuali sono quelle... 15' una conversione, se le fai 1 alla volta sono 1h.
Le fai tutte e 4 contemporaneamente sono 30'.

Cioè... quello che non riesco a capire (anche perché pure il Thuban con winrar era sul 90% e con 2 applicazioni winrar contemporanee arrivava a 100%), è che con BD questo è molto più accentuato e con molti più tipi di software. E' un problema di architettura o è un problema di S.O.?

Non è ridicolo che raddoppiando il carico praticamente il tempo di esecuzione è lo stesso ma con un carico doppio? (estremizzando....)

Anche Cinebench che taskmonitor lo da' al 100%, ma se lancio 2 applicazioni contemporaneamente, la somma delle 2 è superiore al bench singolo. Praticamente.... più lo carichi, più sembra che vada veloce...

[Mister D]

Originariamente inviato da tuttodigitale

Guarda, i 20+2,5 MB di cache erano riferiti alla versione server, quella desktop vede disabiltare 5 o 8 MB di cache l3. Notare come con un quantitativo di cache simile, ma inferiore a quella di bulldozer (20+2,5 vs 16+8) SB-e richieda un die size ben maggior (esattamente il doppio) della versione quad core, oltretutto privo di componente grafica.

Quali core disabilitati... Casomai è lo xeon a 10 core ad avere due core disabilitati.
il bello si posta un link e non si ha neanche il buon gusto di leggerlo
il Core i7-3960X e il Core i7-3930K. Il terzo, chiamato Core i7-3820, arriverà nel primo trimestre del 2012 Tutti e tre sono basati sullo stesso die, composto da 2,27 miliardi di transistor dislocati su un'area di 434 millimetri quadrati (il chip è molto grande) Tutti hanno 20MB di cache l3, ma mentre il modello server li vede tutti, il 3960x ne vede 15, e gli altri 12MB.


Semplice semplice, aumentando due core il die size è aumentato del 100% nonostante l'assenza della gpu integrata. Guarda ad occhio il die size di un BD x8 moduli, privo di cache l3 è pari a circa 190mmq. (nella prima pagina dove è presente la foto del die si vede chiaramente che le cache occupano uno spazio consistente)

Ciao,
non è per contraddirti ma buldozer versione desktop ha 16,5 megabytes di cache totali dati da:
8*16+4*64+4*2048+8000=16576 KB. Sempre che non mi sia sbagliato a fare male i conti.

[tuttodigitale]

Originariamente inviato da Mister D

Ciao,
non è per contraddirti ma buldozer versione desktop ha 16,5 megabytes di cache totali dati da:
8*16+4*64+4*2048+8000=16576 KB. Sempre che non mi sia sbagliato a fare male i conti.

Azz....è meglio postare quando sono in giornata

[tmx]

Originariamente inviato da paolo.oliva2

Le percentuali sono quelle... 15' una conversione, se le fai 1 alla volta sono 1h.
Le fai tutte e 4 contemporaneamente sono 30'.

Cioè... quello che non riesco a capire (anche perché pure il Thuban con winrar era sul 90% e con 2 applicazioni winrar contemporanee arrivava a 100%), è che con BD questo è molto più accentuato e con molti più tipi di software. E' un problema di architettura o è un problema di S.O.?

Non è ridicolo che raddoppiando il carico praticamente il tempo di esecuzione è lo stesso con un carico doppio?

a me è sempre capitata [la stessa occupazione della cpu], con 7zip - winrar - conversioni video.
anche con truecrypt e altro che non ricordo.

ho sempre pensato fosse il disco il colpevole nei casi di queste applicazioni - stavo e sto con dischi 10000/7200/5400... e l'OS e i file in elaborazione stanno su macchine diverse.
su macchine entry umane (athlon xp - core) sempre OC.

comunque mi è sempre capitato che io ricordi - tu Paolo che disco hai?

[shellx]

Originariamente inviato da paolo.oliva2

Le percentuali sono quelle... 15' una conversione, se le fai 1 alla volta sono 1h.
Le fai tutte e 4 contemporaneamente sono 30'.

Cioè... quello che non riesco a capire (anche perché pure il Thuban con winrar era sul 90% e con 2 applicazioni winrar contemporanee arrivava a 100%), è che con BD questo è molto più accentuato e con molti più tipi di software. E' un problema di architettura o è un problema di S.O.?

Non è ridicolo che raddoppiando il carico praticamente il tempo di esecuzione è lo stesso ma con un carico doppio? (estremizzando....)

Anche Cinebench che taskmonitor lo da' al 100%, ma se lancio 2 applicazioni contemporaneamente, la somma delle 2 è superiore al bench singolo. Praticamente.... più lo carichi, più sembra che vada veloce...

Non è ridicolo visto che le peculiarità prestazionali di zambesi sono da cpu server.

edit: inoltre winrar è pesantemente int. Ed inoltre ancora come ha detto tmx c'è anche il disco da considerare. WINRAR fa lavorare la cpu ma dopo, il processo di estrazione o compressione re-scrive su disco, per cui la risposta di ques'ulimo influenza le prestazioni e il carico della cpu.
Ma ovviamente questo centra poco, perchè tu stai dicendo che le % della cpu restano invariate anche se apri altre instanze a differenza del tuo thuban che si inchiodava a 100% dopo due instanze, per cui il disco a questo punto centra poco. Perchè su TM le % della cpu sono della cpu no dei dischi.

[paolo.oliva2]

Originariamente inviato da tmx

a me è sempre capitata [la stessa occupazione della cpu], con 7zip - winrar - conversioni video.
anche con truecrypt e altro che non ricordo.

ho sempre pensato fosse il disco il colpevole nei casi di queste applicazioni - stavo e sto con dischi 10000/7200/5400... e l'OS e i file in elaborazione stanno su macchine diverse.
su macchine entry umane (athlon xp - core) sempre OC.

comunque mi è sempre capitato che io ricordi - tu Paolo che disco hai?

Ho dei WD Sata II (1TB e 2TB) dovrebbero essere 5900rpm (nè 5400 nè 7200), però ho dei Seagate da 1,5TB a 7200rpm, sempre SataII

Comunque non credo dipenda dal disco. La banda è quella, con 1 accesso il programma dovrebbe sfruttarla tutta, con 4 accessi, la banda mi dovrebbe diminuire perché in ogni caso le testine devono posizionarsi in parti diverse del disco. In ogni caso i dati sono continui... il disco non è deframmentato.

Io lo spiego in questo modo...

Lo scheduler di windows lo fa lavorare malissimo BD e quindi con più applicazioni aperte il rimbalzo da core a core si presenta in maniera inferiore... e questo potrebbe causare che i dati presenti in una L2 di un modulo devono essere trasferiti nella L3 e poi nella L2 dell'altro modulo, e qui tempo perso.
Oppure il fatto di trasferire il carico da core a core genera un cambiamento di P-State (da frequenza alta a idle) che fa perdere tempo... mentre con più carichi, il procio non cambia mai P-State e quindi si azzerano i tempi morti.

BD è un procio nato per i server e di conseguenza progettato per carichi intensivi, e questo in parte è spiegato dal fatto che pure con 15 applicazioni attive sotto carico, il procio è sempre comunque libero di eseguire una applicazione ex-novo (l'ho postato come differenza che si nota subito pur passando, come me, dal Thuban X6)
Però comunque non spiega che più applicazioni se eseguite in contemporanea ci mettano un tempo inferiore rispetto che singolarmente.

Comunque è assurdo... sembra come se con 1 applicazione il motore fosse scarburato e con più applicazioni carburato.
Comunque è veramente da provare... io ho sotto 3 conversioni video, torrent attivo, sto scrivendo questo post, ho caricato paint, catturato lo schermo, salvato, caricato con nero per compatttarlo, salvato (e tieni conto che le conversioni video sono a risoluzione massima, quindi HD ingolfato in banda, nessun problema... macchina fluida come se fosse a 0% di carico.

[shellx]

Originariamente inviato da paolo.oliva2

Però comunque non spiega che più applicazioni se eseguite in contemporanea ci mettano un tempo inferiore rispetto che singolarmente.

Comunque è assurdo... sembra come se con 1 applicazione il motore fosse scarburato e con più applicazioni carburato.
Comunque è veramente da provare... io ho sotto 3 conversioni video, torrent attivo, sto scrivendo questo post, ho caricato paint, catturato lo schermo, salvato, caricato con nero per compatttarlo, salvato (e tieni conto che le conversioni video sono a risoluzione massima, quindi HD ingolfato in banda, nessun problema... macchina fluida come se fosse a 0% di carico.

Riquoto la mia risposta:

Originariamente inviato da shellx

Le peculiarità prestazionali di zambesi sono da cpu server.

[Ares17]

Originariamente inviato da paolo.oliva2

Ho dei WD Sata II (1TB e 2TB) dovrebbero essere 5900rpm (nè 5400 nè 7200), però ho dei Seagate da 1,5TB a 7200rpm, sempre SataII

Comunque non credo dipenda dal disco. La banda è quella, con 1 accesso il programma dovrebbe sfruttarla tutta, con 4 accessi, la banda mi dovrebbe diminuire perché in ogni caso le testine devono posizionarsi in parti diverse del disco. In ogni caso i dati sono continui... il disco non è deframmentato.

Io lo spiego in questo modo...

Lo scheduler di windows lo fa lavorare malissimo BD e quindi con più applicazioni aperte il rimbalzo da core a core si presenta in maniera inferiore... e questo potrebbe causare che i dati presenti in una L2 di un modulo devono essere trasferiti nella L3 e poi nella L2 dell'altro modulo, e qui tempo perso.
Oppure il fatto di trasferire il carico da core a core genera un cambiamento di P-State (da frequenza alta a idle) che fa perdere tempo... mentre con più carichi, il procio non cambia mai P-State e quindi si azzerano i tempi morti.

BD è un procio nato per i server e di conseguenza progettato per carichi intensivi, e questo in parte è spiegato dal fatto che pure con 15 applicazioni attive sotto carico, il procio è sempre comunque libero di eseguire una applicazione ex-novo (l'ho postato come differenza che si nota subito pur passando, come me, dal Thuban X6)
Però comunque non spiega che più applicazioni se eseguite in contemporanea ci mettano un tempo inferiore rispetto che singolarmente.

Comunque è assurdo... sembra come se con 1 applicazione il motore fosse scarburato e con più applicazioni carburato.
Comunque è veramente da provare... io ho sotto 3 conversioni video, torrent attivo, sto scrivendo questo post, ho caricato paint, catturato lo schermo, salvato, caricato con nero per compatttarlo, salvato (e tieni conto che le conversioni video sono a risoluzione massima, quindi HD ingolfato in banda, nessun problema... macchina fluida come se fosse a 0% di carico.

Originariamente inviato da shellx

Riquoto la mia risposta:

Difatti gia dalle prime mie richieste di bench avevo ipotizzato questo.
Come i veri buldozer CAT, lenti con basso carico di lavoro, ma quando messo alla frusta continua imperterrito con la stessa andatura.
Sarei curioso di vedere in un operazione simile un 2600k, ma credo che il guadagno si assesti tra il 25 ed il 33%.

[Wolfhang]

Originariamente inviato da Ares17

Difatti gia dalle prime mie richieste di bench avevo ipotizzato questo.
Come i veri buldozer CAT, lenti con basso carico di lavoro, ma quando messo alla frusta continua imperterrito con la stessa andatura.
Sarei curioso di vedere in un operazione simile un 2600k, ma credo che il guadagno si assesti tra il 25 ed il 33%.

Ho fatto una prova veloce con il test di WinRar (win7 64bit), con il procio a default (ram a 1866) sono a circa 4Mb/s, se lancio una seconda istanza di Winrar salgo complessivamente a 6.4Mb/s, il 60% in più, per raggiungere il 100% di occupazione della cpu ne devo lanciare 5/6 e raggiungo 7-7.5Mb/s

[tmx]

@paolo
grazie per la risposta

sarebbe bello capire dov'è il collo di bottiglia... o se invece [limitatamente a quelle app] sia normale e accada ad altri - anche con intel, SSD, ecc

[Korn]

Originariamente inviato da Wolfhang

Ho fatto una prova veloce con il test di WinRar (win7 64bit), con il procio a default (ram a 1866) sono a circa 4Mb/s, se lancio una seconda istanza di Winrar salgo complessivamente a 6.4Mb/s, il 60% in più, per raggiungere il 100% di occupazione della cpu ne devo lanciare 5/6 e raggiungo 7-7.5Mb/s

altro pippa mentale smentita quindi

[paolo.oliva2]

Originariamente inviato da tmx

@paolo
grazie per la risposta

sarebbe bello capire dov'è il collo di bottiglia... o se invece [limitatamente a quelle app] sia normale e accada ad altri - anche con intel, SSD, ecc

Allora, è la gestione dei TH.

Impostando l'affinità su un modulo (es. core 0/1, 2/3, 4/5, 5/7), si arriva al 98% con una singola sessione del programma. Se invece assegno l'affinità su 2 core ma in moduli diversi, succede il casino

Questo è con 2 sessioni rispettivamente con affinità 4-5 e 6-7. Il carico è sul 98% a modulo.


Variando la prima affinità, cioè 0-2, cioè su 2 moduli, il carico diminuisce. La variazione in meno percentualmente si somma con l'aumentare dei moduli.


In ogni caso la colpa mi sembra architetturale in sé per sé... lo scheduler di windows relativamente... a meno che, essendo una conversione video e di per sé sequenziale, in teoria lo scheduler dovrebbe impostare un discorso (alla buona) 0-1-2-3-4-5-6-7 ciclico.... se facesse 0-2-1-3-5-7-4-6 penso che questo possa incasinare le cache di BD.

[paolo.oliva2]

Originariamente inviato da Korn

altro pippa mentale smentita quindi

Se vuoi postare qualcosa di utile, comprati un BD e posta le tue impressioni, altrimenti leggi le impressioni di chi lo ha.
Il tuo commento come utilità è zero, oltre che offensivo. e tra parentesi non vedo cosa hai da criticare verso chi impiega tempo, anziché fare tutt'altro, per postare cose utili a capirne l'architettura...
Non è il tuo primo post su questo tipo, gli altri li ho ignorati ma cominci ad essere pesante, anche perché praticamente mi dai del cretino apertamente.
Delucidami su che basi consideri il mio post stupido e le tue risposte intelligenti.

P.S.
"pippa" è femminile, è il soggetto, quindi scrivi "altra", non "altro".

[liberato87]

io penso che sia "normale" questa cosa che aumentando i programmi e il carico aumentino anche i risultati nonostante la cpu sia sempre al 100%.
forse dirò una stupidaggine però ad esempio quanti programmi fanno vedere un utilizzo al 100% però alcuni sono più pesanti e altri no?

ad esempio se io lancio memtest mi dice procio e memoria al 100%, eppure le temperature non salgono tanto..
se faccio linx senza il supporto alle aes, vedo propcio e memoria al 100% ma faccio 65 gflops. se abilito le aes e scarico il sp1 ne faccio il doppio.
ma io continuerò a vedere procio e memoria al 100%.

tuttavia mi pare un discorso interessante se effettivamente facendo una conversione o ho ancora potenza sufficiente per farne partire altre, senza perdere in prestazioni, mi sembra un ottima cosa.

Originariamente inviato da Wolfhang

Ho fatto una prova veloce con il test di WinRar (win7 64bit), con il procio a default (ram a 1866) sono a circa 4Mb/s, se lancio una seconda istanza di Winrar salgo complessivamente a 6.4Mb/s, il 60% in più, per raggiungere il 100% di occupazione della cpu ne devo lanciare 5/6 e raggiungo 7-7.5Mb/s

raggiungi 7-7.5mbs sommando le varie istanze giusto?

[gianni1879]

Originariamente inviato da shellx

Non è ridicolo visto che le peculiarità prestazionali di zambesi sono da cpu server.

edit: inoltre winrar è pesantemente int. Ed inoltre ancora come ha detto tmx c'è anche il disco da considerare. WINRAR fa lavorare la cpu ma dopo, il processo di estrazione o compressione re-scrive su disco, per cui la risposta di ques'ulimo influenza le prestazioni e il carico della cpu.
Ma ovviamente questo centra poco, perchè tu stai dicendo che le % della cpu restano invariate anche se apri altre instanze a differenza del tuo thuban che si inchiodava a 100% dopo due instanze, per cui il disco a questo punto centra poco. Perchè su TM le % della cpu sono della cpu no dei dischi.

vi state sfasciando la testa in qualcosa di estremamente scontato.
Non tutti i programmi sono fatti in modo da scalare perfettamente con il multi core/thread. SE un programma me ne sfrutta a mala pena 3/4 è del tutto normale se io aggiungo più istanze i tempi di esecuzione non si sommano.
Sinceramente leggo da pagine e pagine questa cosa, e non mi pare nulla di nuovo. Ecco perchè in alcuni casi è preferibile avere un core clock spinto con un forte ipc, piuttosto che avere tanti core.

Si vede benissimo in molti casi dove il passaggio da 4core a 6 o più core non fa uno scaling perfetto.

La cosa si nota con tutte le cpu da quadcore a salire, non è una strettamente legata a BD.

Originariamente inviato da Wolfhang

Ho fatto una prova veloce con il test di WinRar (win7 64bit), con il procio a default (ram a 1866) sono a circa 4Mb/s, se lancio una seconda istanza di Winrar salgo complessivamente a 6.4Mb/s, il 60% in più, per raggiungere il 100% di occupazione della cpu ne devo lanciare 5/6 e raggiungo 7-7.5Mb/s

nessuna sorpresa CVD.

[Ares17]

Originariamente inviato da gianni1879

vi state sfasciando la testa in qualcosa di estremamente scontato.
Non tutti i programmi sono fatti in modo da scalare perfettamente con il multi core/thread. SE un programma me ne sfrutta a mala pena 3/4 è del tutto normale se io aggiungo più istanze i tempi di esecuzione non si sommano.
Sinceramente leggo da pagine e pagine questa cosa, e non mi pare nulla di nuovo. Ecco perchè in alcuni casi è preferibile avere un core clock spinto con un forte ipc, piuttosto che avere tanti core.

Si vede benissimo in molti casi dove il passaggio da 4core a 6 o più core non fa uno scaling perfetto.

La cosa si nota con tutte le cpu da quadcore a salire, non è una strettamente legata a BD.



nessuna sorpresa CVD.

Tutto vero, per questo io avevo chiesto una comparativa con il 2600k con 4 esecuzioni contemporanee per capire se il carico applica bd fosse equivalente come scalabilità all'i7 (avevo ipotizzato un aumento compreso tra il 25 ed il 33%)

[Wolfhang]

Originariamente inviato da liberato87

raggiungi 7-7.5mbs sommando le varie istanze giusto?

esatto

[tmx]

Originariamente inviato da paolo.oliva2

Allora, è la gestione dei TH.
...
In ogni caso la colpa mi sembra architetturale in sé per sé... lo scheduler di windows relativamente... a meno che, essendo una conversione video e di per sé sequenziale, in teoria lo scheduler dovrebbe impostare un discorso (alla buona) 0-1-2-3-4-5-6-7 ciclico.... se facesse 0-2-1-3-5-7-4-6 penso che questo possa incasinare le cache di BD.

ok chiaro
tolta la parte di colpa dell'arch., pensi che una qualunque ottimizzazione sw possa migliorare la situazione in questo caso?
e se sì, secondo te è all'orizzonte o se ne sbatteranno...?