[Thread Ufficiale] Aspettando Bulldozer *leggere prima pagina con attenzione*

[dav1deser]

Originariamente inviato da Pihippo

Ciao
Mettiamo un pò di chiarezza, anche ad 1 secondo la frequenza di campionamento non è eccezionale, fermo restando che il tool di windows è molto accurato, per media intendevo come carico di cpu. In quanto il tool stesso ti porta il valore Media Cpu. Inoltre ti ripora i thread attivi dall'istanza dell'applicazione
Detto ciò, che potrebbe risultare una cazzata, il core super utilizzato può anche essere quello stesso core che si occupa della decompressione dei dati.

Be' ma l'ho detto...se restituisce un valore pari al 100%, e questo valore è la media fra tutti i valori istantanei, questi valori istantanei non potranno che essere pari a 100%, in quanto un CPU non può andare al 110% e di conseguenza non possono esserci all'interno di quel secondo valori inferiori al 100%, altrimenti la media sarebbe inferiore! So che il tool di windows da più informazioni, ma ci ho guardato un attimo e non ho trovato ne modo per dilatare i tempi dei grafici, ne per fare un comodissimo file di log.

[cionci]

Originariamente inviato da gi0v3

sono riuscito a fare un 3dmark (una volta, la seconda già mi dava di nuovo errore ç_ç) e ho fatto una screen appena finito il cpu test... li occupa tutti, ma non uniformemente, il primo arriva al 100% quelli dopo vanno leggermente a scalare...



i due picchi sono i due cpu test

Per una parte del test sembra occupare bene tutti i core, nella parte finale invece li occupa abbastanza male, tranne il primo e il secondo.
Quindi ecco spiegato il perché del punteggio, una parte del test scala bene con i core, l'altra parte scala poco. Tra l'altro scala male anche in frequenza con molti core, perché altrimenti i grafici avrebbero dovuto raggiungere il picco del 100% che non viene invece mai raggiunto.
In sostanza sicuramente parte il punteggio risente della presenza di molti core, ma non in modo così pesante.
La dipendenza fra i dati forniti in pasto ai vari core è anche abbastanza pesante, basti considerare che nello screen di marchigiano l'occupazione del core principale è molto simile a quella di Giov3, mentre i core secondari hanno occupazione nettamente minore.
Questo mi sembra un classico esempio di un produttore e N consumatori. In sostanza il core principale si occupa di coordinare, preparare e fornire i dati ai core secondari. E chiaramente andando al 100% non ce la fa a rifornire tutti i core e all'aumentare del numero dei core diminuisce il numero la quantità di dati che può fornire ad ogni core.
Se Giov3 potesse riprovare con 4 core si avrebbe la conferma di questo: l'uso del core principale resterebbe identico. Quello dei core secondari sarebbe mediamente più alto.

Questo benchmark non misura le prestazioni di una CPU multicore, ma la capacità di un singolo core a rifornire gli altri.

Credo che si possa anche modellare il sistema con cui scala il test in base a frequenza e numero di core. Ma sinceramente ne ho poca voglia

[paolo.oliva2]

Originariamente inviato da dav1deser

Arrivare al 100% ci arriva...però ho un dubbio, vedo che everest rileva solo 4 core (nello screen del task manager di prima ho visto 6 core) quindi mi viene il dubbio che quel 100% sia il 100% di 4 core. Ti spiacerebbe fare un rapido test con qualche programma su solo 4 core per vedere che occupazione ti indica everest? Giusto per vedere se segna il 67% come dovrebbe essere.

E' un bug solo in riporto di Everest, in quanto visualizza le temp solo di 4 core.



Se fai il test di stress per vedere la stabilità del sistema, usa la stessa schermata, ma la scala si rifersisce a 6 core.

[paolo.oliva2]

Originariamente inviato da astroimager

Ho raccolto quel poco che si sa, insieme a qualche altro dato, in una tabella:



Il grafico della slide AMD sembra complessivamente affidabile su 950 vs 1100T, specie con Cinebench.

Ho inserito anche le due CPU di punta Intel, calcolando la differenza di potenza rispetto al BD x8 della slide.

Infine una stima dell'IPC (presumibilmente contaminato dal Turbo) a varie frequenze di riferimento.

Comunque BD X8 vola.

Ho provato a rifare il bench con il 1090T@4,4GHz (non chiedetemi perché a 4,3GHz ho fatto 19.500 e ora a 4,4 faccio 17.500, non lo so neppure io)



3Dmark6 riporta 4,3GHz ma la frequenza reale è questa



7605 io li faccio a 4,4GHz... praticamente anche tirandolo al max non arriverei mai a quanto un BD X8 farebbe a def. (8290/8757).
Contando che un 1100T a 3,3GHz farebbe 6000 scarsi ed io a 4,4GHz farei il 33% in più... un BD X8 potrebbe superare facilmente i 10.000, e pure gli 11.000 in OC.

[astroimager]

Originariamente inviato da Athlon 64 3000+

...
Praticamente quando mai deciderò di passare alle DDR3-1866 spero che siano a 1,5V e con lo stesso profilo delle mia attuali ram.

Hai il mio stesso problema, e infatti io ho dovuto spostare le ram negli altri due slot, dove però vanno peggio.

Originariamente inviato da paolo.oliva2

Leggendo le notizie in rete, ma probabilmente altro non sono che copia-incolla, i più asseriscono che al Cebit ci potranno essere dimostrazioni di BD e Llano.

...

Con questo non voglio dire che BD ci sarebbe per aprile (anche se la mia scimmia lo vorrebbe per domani), ma più AMD allenta l'NDA, più a maggior diritto la data sarebbe vicina.

E se AMD se ne uscisse a sorpresa con il lancio ufficiale di BD?!?

Se fossi alla dirigenza AMD adesso passerei il tempo a frustare i dipendenti, costringendoli ad orari ottocenteschi!

[Lunar Wolf]

Originariamente inviato da astroimager

E se AMD se ne uscisse a sorpresa con il lancio ufficiale di BD?!?

Se fossi alla dirigenza AMD adesso passerei il tempo a frustare i dipendenti, costringendoli ad orari ottocenteschi!

Sono d'accordo con te....farei lavorare e dividere il lavoro a due team, uno lavora 8 ore di giorno e gli altri 8 ore la sera, e poi si faranno il cambio a settimana, cosi ogni settimana ci sara un gruppo che lavora di giorno ma che la prossima sara di sera e viceversa. cosi farei uscire bulldozer prima e tanti saluti al concorrente.

Sempre se una volta finito progetti e altre cose le fabbriche possono sfornare il pane per tutto il mondo affamatto!

[paolo.oliva2]

Originariamente inviato da astroimager

Hai il mio stesso problema, e infatti io ho dovuto spostare le ram negli altri due slot, dove però vanno peggio.



E se AMD se ne uscisse a sorpresa con il lancio ufficiale di BD?!?

Se fossi alla dirigenza AMD adesso passerei il tempo a frustare i dipendenti, costringendoli ad orari ottocenteschi!

Di... delle voci che AMD avrebbe iniziato la produzione in volumi a fine febbraio/inizi di marzo, c'è stata, ma purtroppo era un sussurro rispetto alle altre voci già per metà marzo.

Io penso questo... che stanno lavorando per ottenere lo yield più alto possibile...
Se ci pensi, non c'è mezza voce circa uno step ulteriore per BD, o qualsivoglia problema inerente a sviluppi.
Se ti ricordi, pure nell'ES parlavano di procio "finito"... quindi ultima release.

Quindi... cacchio, se il 32nm è pronto (vedi Llano anticipato a maggio), se i film pure... che cacchio stanno facendo a Dresda? Hanno i BD X8 collegati in rete per un mega-gioco in lan collettivo?

Non voglio fare l'iper-ottimista, ma mi sembra una supposizione realista. Cacchio, AMD, che mazza aspetti un yield migliore? Butta fuori che poi lo yield lo migliori strada facendo, meglio guadagnare di meno ma guadagnare che non guadagnare una mazza se non butti fuori BD.

[e.greg.io]

Quindi... cacchio, se il 32nm è pronto (vedi Llano anticipato a maggio), se i film pure... che cacchio stanno facendo a Dresda? Hanno i BD X8 collegati in rete per un mega-gioco in lan collettivo?

sono tre settimane che il capitano ripete che non hanno ancora finito lo sviluppo .
non è che si gingillano con gli es tra le mani...
certo è che se al cebit ( prima settimana di marzo) non inizieranno a presentare il tutto (bd e, visto che intendono anticiparlo, llano), allora non potrà che significare che sono ancora in alto mare.

[astroimager]

Originariamente inviato da e.greg.io

sono tre settimane che il capitano ripete che non hanno ancora finito lo sviluppo .
non è che si gingillano con gli es tra le mani...
certo è che se al cebit ( prima settimana di marzo) non inizieranno a presentare il tutto (bd e, visto che intendono anticiparlo, llano), allora non potrà che significare che sono ancora in alto mare.

Stavo appunto per scrivere che il Capitano ci fulmina.

Quando gli dissi che Llano magari potevano anticiparlo al Q3-Q4 2010, perché Q1 2011 mi sembrava troppo in là, mi disse che era praticamente impossibile, perché i tempi di sviluppo sono quelli... poi sappiamo tutti com'è andata a finire.

BD è ancora in sviluppo, in teoria a marzo dovrebbe essere pronto lo step finale, e per quanto sia bello sognare, c'è da sperare che nulla vada storto (e che soprattutto siano già oltre lo step B2 )!
Ok che l'occasione è veramente d'oro, ma lanciare una CPU troppo buggata, o con resa di tipo 20-30 die/wafer funzionanti sarebbe un bell'autogol!

Secondo me oltre al Cebit saranno importanti anche queste 4 settimane che lo precedono... se non si vede nulla, c'è poco da sperare, se invece cominciano a scoprirsi sempre più carte... un paper launch non lo vedrei così improbabile... con magari qualche screen ad elio liquido a quota 8 GHz...

[astroimager]

Originariamente inviato da paolo.oliva2

Comunque BD X8 vola.
...
7605 io li faccio a 4,4GHz... praticamente anche tirandolo al max non arriverei mai a quanto un BD X8 farebbe a def. (8290/8757).
Contando che un 1100T a 3,3GHz farebbe 6000 scarsi ed io a 4,4GHz farei il 33% in più... un BD X8 potrebbe superare facilmente i 10.000, e pure gli 11.000 in OC.

Prova a vedere a quanto dovresti tirare il tuo Thuban per avere lo stesso punteggio in Cinebench rispetto a quel BD x8 ockato del 20%

[Pihippo]

Originariamente inviato da cionci

Per una parte del test sembra occupare bene tutti i core, nella parte finale invece li occupa abbastanza male, tranne il primo e il secondo.
Quindi ecco spiegato il perché del punteggio, una parte del test scala bene con i core, l'altra parte scala poco. Tra l'altro scala male anche in frequenza con molti core, perché altrimenti i grafici avrebbero dovuto raggiungere il picco del 100% che non viene invece mai raggiunto.
In sostanza sicuramente parte il punteggio risente della presenza di molti core, ma non in modo così pesante.
La dipendenza fra i dati forniti in pasto ai vari core è anche abbastanza pesante, basti considerare che nello screen di marchigiano l'occupazione del core principale è molto simile a quella di Giov3, mentre i core secondari hanno occupazione nettamente minore.
Questo mi sembra un classico esempio di un produttore e N consumatori. In sostanza il core principale si occupa di coordinare, preparare e fornire i dati ai core secondari. E chiaramente andando al 100% non ce la fa a rifornire tutti i core e all'aumentare del numero dei core diminuisce il numero la quantità di dati che può fornire ad ogni core.
Se Giov3 potesse riprovare con 4 core si avrebbe la conferma di questo: l'uso del core principale resterebbe identico. Quello dei core secondari sarebbe mediamente più alto.

Questo benchmark non misura le prestazioni di una CPU multicore, ma la capacità di un singolo core a rifornire gli altri.

Credo che si possa anche modellare il sistema con cui scala il test in base a frequenza e numero di core. Ma sinceramente ne ho poca voglia

Ciao cionci.
Per carità, tu ne capisci molto più di me, però avrei qualche dubbio riguardo la questione producer consumer.
Ovvero, con certezza avrai skippato il post scritto più in alto da me perchè scritto in linguaggio da cani ma son convinto che più che misurar la capacità di un singolo core di fornire gli altri core di dati\operandi, sia anche un tentativo di distribuire i carichi di lavoro (ovvero rendering della scena da parte della cpu senza nessun intervento della gpu, + ai + fisica) su cores diversi.
Penso cosi perchè a meno di motivi particolari, non trovo il nesso logico di ingolfare 1 solo core. Prendiamo l'esempio di un engine di un gioco complesso che divide i task principali in diversi thread, e compariamolo ad una pipeline con diversi stadi. Possiamo notare come questo non dia le performance maggiori poichè l'overhead degli state change e degli update tra thread si mangerebbero la maggior parte dei guadagni. Si può invece (volendo ingolfare più degli altri un singolo core), ricordandoci l'analogia engine= pipeline, creare
un threads pool (una sorta di riserva di threads) , in cui un thread principale esegue tutti i task (stages della pipeline) serialmente ovvero, ad esempio, prima il rendering poi la fisica, poi l'ia, ma ogni task si scompone in diversi batches che verrano inseriti nel threads pool come diversi job,quindi in quel dato momento t di esecuzione dell'engine avremo 128 thread (dovuti ad i job) di rendering che completeranno il task di rendering in un tempo t inferiore rispetto ad un unico thread di rendering eseguito in parallelo con 127 thread di altro tipo sullo stesso processore. Questo cosa permette? Non lo so !
Ovvero penso di saperlo.
1) Scalabilità sino a 5 milioni di cores grazie al sitema del thread pool.
2)Nessun thread fa lavoro a muzzo (per l'esempio di sopra del frame utile)
3) E' più sicuro e thread safe in quanto non vi sono 128 thread che competono tra di loro per leggere\scrivere lo stesso dato nello stesso tempo
4) Ci si risparmia un sacco di overhead dovuto al mantenimento in sincronia di 128 thread diversi in modo simultaneo, ovvero ti risparmi un lock continuo delle risorse e una dispendiosa comunicazione intra thread

[Pihippo]

Originariamente inviato da dav1deser

Be' ma l'ho detto...se restituisce un valore pari al 100%, e questo valore è la media fra tutti i valori istantanei, questi valori istantanei non potranno che essere pari a 100%, in quanto un CPU non può andare al 110% e di conseguenza non possono esserci all'interno di quel secondo valori inferiori al 100%, altrimenti la media sarebbe inferiore! So che il tool di windows da più informazioni, ma ci ho guardato un attimo e non ho trovato ne modo per dilatare i tempi dei grafici, ne per fare un comodissimo file di log.

Ciao
Hai perfettamente ragione, mi sono incasinato un pò io

[cionci]

Originariamente inviato da Pihippo

un threads pool (una sorta di riserva di threads) , in cui un thread principale esegue tutti i task (stages della pipeline) serialmente ovvero, ad esempio, prima il rendering poi la fisica, poi l'ia, ma ogni task si scompone in diversi batches che verrano inseriti nel threads pool come diversi job,quindi in quel dato momento t di esecuzione dell'engine avremo 128 thread (dovuti ad i job) di rendering che completeranno il task di rendering in un tempo t inferiore rispetto ad un unico thread di rendering eseguito in parallelo con 127 thread di altro tipo sullo stesso processore. Questo cosa permette? Non lo so !

A me sembra un classico esempio di un produttore - N consumatori Chi fa la scomposizione dei lavori e prepara i vari job ? Se lo fa il thread principale la pipeline viene "simulata" serialmente dal thread principale. Se i vari thread si passassero fra di loro i vari risultati imho l'occupazione dei core secondari sarebbe nettamente più alta.
Per questo secondo me è direttamente il thread principale, magari con la collaborazione di un altro thread allocato sulla seconda CPU (ha un utilizzo medio più alto) che raccoglie i risultati.
All'aumentare dei core è vero che ottengono più risultati utili, ma la capacità di elaborazione è limitata dall'aumentato overhead e dalle capacità di calcolo del thread principale.

Sarebbe interessante overclockare solo un core... E' possibile in qualche modo ? Per vedere quanto alla fine il punteggio dipende dalla capacità di elaborazione degli altri core.

[paolo.oliva2]

Originariamente inviato da cionci

A me sembra un classico esempio di un produttore - N consumatori Chi fa la scomposizione dei lavori e prepara i vari job ? Se lo fa il thread principale la pipeline viene "simulata" serialmente dal thread principale. Se i vari thread si passassero fra di loro i vari risultati imho l'occupazione dei core secondari sarebbe nettamente più alta.
Per questo secondo me è direttamente il thread principale, magari con la collaborazione di un altro thread allocato sulla seconda CPU (ha un utilizzo medio più alto) che raccoglie i risultati.
All'aumentare dei core è vero che ottengono più risultati utili, ma la capacità di elaborazione è limitata dall'aumentato overhead e dalle capacità di calcolo del thread principale.

Sarebbe interessante overclockare solo un core... E' possibile in qualche modo ? Per vedere quanto alla fine il punteggio dipende dalla capacità di elaborazione degli altri core.

Io, onestamente, non ci ho capito una mazza di quello che dite , però ad occhio ho capito quello che vuoi.

posso impostare il 1090T un questo modo:

(posso disabilitare n core da bios)
- 4,3GHz 4 core
- 4,3GHz 6 core.
- 4,3GHz 1 core con gli altri 3 e 5 a 4GHz.

stoppo 3Dmark6 subito dopo il test CPU (non posso fare diversamente) e poi posterei i risultati.
Naturalmente Everest mi riporta la percentuale di utilizzo in base a ciò che il bios gli dice, nel secso che se il bios gli dice che è un X4, lui riporta 100% per X4 e idem come X6.

Ho capito bene?

Comunque per CPU test mi sembra che i core li utilizzi tutti, quindi un BD X8 ha 8 core e un Thuban ha 6 core.

[cionci]

Originariamente inviato da paolo.oliva2

(posso disabilitare n core da bios)
- 4,3GHz 4 core
- 4,3GHz 6 core.
- 4,3GHz 1 core con gli altri 3 e 5 a 4GHz.

Servirebbe anche il CPU Score, dal solo utilizzo della CPU imho non ci si capisce niente.

[gi0v3]

stamattina ho fatto un po' di riavvii, e ho provato a vedere come si comporta 3dmark06 con 2,3,4,5 e 6 core, lasciando invariati tutti gli altri parametri (frequenza, timings e frequenza ram, tutte le volte ho eseguito il test appena fatto il reboot, con gli stessi programmi in esecuzione)

2 core

3 core

4 core

5 core

6 core


my 2 cents: il quinto e il sesto core aumentano relativamente di poco uil punteggio in assoluto, e se guardati in percentuale l'aumento è ancora inferiore... il primo core lavora a bestia, e più core deve gestire più è lungo il preload (il primo picco) e il load del primo test, con 2 core si vede chiaramente che deve caricare molta meno roba che con 3 o più core...

nota bene: nel grafico con 4 core il secondo picco non dovete considerarlo, avevo avviato per sbaglio il bench senza togliere i test gpu, e infatti dopo ho lasciato in idle un po' per non far accavallare i picchi...

spero che sia sufficiente per farsi un'idea più precisa, comunque come test multicore non scala abbastanza, imho.

pps il clock qua è di 4,05 ghz, ho mantenuto lo stesso clock per tutti e 5 i test

[cionci]

Bravo Giov3, si vede chiaramente che l'utilizzo nella parte finale scende all'aumentare del numero dei core. Chiaro indice che il benchmark non scala bene all'aumentare dei core.

Potresti provare a settare tutto ad una frequenza più bassa di 400 Mhz rispetto all'attuale. Poi fai un test in questo stato.
Dopo un secondo test con il primo core a 400 Mhz in più degli altri.

[Alekz]

A quanto si sa, le schede madri am3+ usciranno prima o insieme a BD?

[gi0v3]

Originariamente inviato da cionci

Bravo Giov3, si vede chiaramente che l'utilizzo nella parte finale scende all'aumentare del numero dei core. Chiaro indice che il benchmark non scala bene all'aumentare dei core.

Potresti provare a settare tutto ad una frequenza più bassa di 400 Mhz rispetto all'attuale. Poi fai un test in questo stato.
Dopo un secondo test con il primo core a 400 Mhz in più degli altri.

ho fatto una batteria di test, adesso vedo di uppare le screen, ma senza riavviare di nuovo ho fatto

tutti i core @1,95, 3,00, 3,75, 4,2 ghz (i 4,05 li avevamo già)
confronto 1,95vs 4,05: primo core a 4 e gli altri a 2, 2 a 4 e 4 a 2, 3 e 3, 4 e 2, 5 e 1
confronti primi 2 core a un clock e altri 4 a un altro clock:
2@4,05 4@3,00
2@4,05 4@3,75
2@4,05 4@4,2
2@1,95 4@4,05
2@4,2 4@4,05

i più interessanti per un confronto diretto sono quelli a parti invertite (1,95vs 4,05 e 4,05 vs 4,2 ) perchè si vede chiaramente come i primi 2 core pesino più degli altri 4 messi insieme... conclusioni: imho sto test è ottimizzato per un dual core, beneficia di più di 2 core ma è ottimizzato per 2, quindi ha scarsa validità su 6-8 core.

[cionci]

Ti sei dato da fare
Credo che il confronto più interessante sia:
- primo a 4 e altri a 2
- primo e secondo a 4 altri a 2
- tutti a 4