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

[Mparlav]

Originariamente inviato da bjt2

Nel primo ci sono degli errori. Dice che la cache L1 può fare 2 accessi a 64 bit, mentre sono 2 a 128 bit... Dice che ha latenza 3 cicli mentre è 4 cicli. Dice che la L2 è 1MB mentre è 2MB... Mah...

Li ho trovati ieri sera tardi sperando di trovare informazioni su Tmax, vcore, etc: ma una rapida ricerca non ha condotto a nulla, se non al sonno dopo una giornataccia (che comprende il lancio di Bulldozer

Però mi sembra più documentazione riferita agli Opteron che agli FX.

Originariamente inviato da OPP

cioè sei quasi li li con 700mhz in meno? ma com'è possibile una cosa del genere?

Considera che ho preso 3 delle 4 applicazioni dove FX ha mostrato le prestazioni peggiori.
Ma certo mi ha lasciato di stucco vedere che, anche lasciando da parte Intel, è il confronto con Thuban il vero problema.

Originariamente inviato da bjt2

Se guardi più giù nella stessa pagina c'è una cosa interessante su cinebench...
Salendo di clock da default a 4.7GHz, il BD è molto più lineare, sale quasi quanto la frequenza (30% circa), mentre il SB da 3.4Ghz a 4.7Ghz guadagna SOLO il 25%... Questo vuol dire che se il silicio GF riuscisse a breve a recuperare e consentire clock stock di 4.3-4.5GHz per BD, allora avremmo un mostro...

Questa linearità di BD è indice di una BUONA architettura, contrariamente a quello che si vuole far credere. E' ottimamente bilanciata e non ha colli di bottiglia... Ha solo un IPC più basso del Thuban, ma se il silicio migliorasse...

La linearità è stata riscontrata anche qui:
http://www.xbitlabs.com/articles/cpu..._14.html#sect0

purtroppo non cambia la sostanza, perchè il concorrente ha una base di partenza migliore e molto probabilmente la manterrà col prossimo die shrink e miglioramento dell'IPC.

Ma su un punto sono "irrevomibile" perchè Netburst ha fatto scuola troppo a lungo

Il clock della cpu è importante, ma è un qualcosa "di più" senza prescindere dall'IPC della cpu (e dal CPI per singolo core decisamente scarso).

http://www.hardware.fr/articles/842-...s-calculs.html

Su questo Amd deve intervenire ed in fretta: nuovo silicio per correggere gli errata e sistemare le latenze della cache

http://www.hardware.fr/articles/842-...es-caches.html

Queste sono priorità maggiori del contare sui MHz futuri.

[Heimdallr]

Originariamente inviato da bjt2

Questa linearità di BD è indice di una BUONA architettura, contrariamente a quello che si vuole far credere. E' ottimamente bilanciata e non ha colli di bottiglia... Ha solo un IPC più basso del Thuban, ma se il silicio migliorasse...

Scusa ma non ti sembra un po' un controsenso? Se l'IPC è più basso del Thuban come facciamo a considerarla ora una buona architettura?
Magari avrà ampi margini per migliorare ma ora il problema non mi sembra solo il silicio (sembra che abbiano fatto all in sul silicio e gli sia andata male).

[beppenike81]

Ecco perché al WR di 8.3 ghz non hanno benchato, più di 10sec al superPI 1M

[capitan_crasy]

Originariamente inviato da bjt2

Gli errata sono parecchi, ma nessuno critico, perchè tutti hanno no fix planned.
La maggior parte sono errata sul conteggio delle prestazioni.

Gli unici due che potrebbero influenzare le prestazioni sono uno nella cache L3, dove si va a settare un bit riservato (che quindi disabilita probabilmente qualcosa) in un meccanismo interessantissimo (che credo non ci fosse nel K10) di allocazione dinamica della cache L3 in base alla " qualità " degli accessi... In pratica ai moduli che inquinano troppo la cache con parecchi cache miss eccetera, gli viene data una priorità più bassa nell'uso della cache L3, tanto più bassa quanto più sono "casinari"... Questa è una cosa molto furba e interessante! Il workaround modifica qualcosa ma non disabilita questa funzione.

L'altro errore, sempre non grave, riguarda un possibile incasinamento se si setta il valore massimo per un parametro della coda di sincronizzazione tra i core e il NB (che vanno a clock diversi). 6 è il massimo. Viene consigliato di usare 5, che potrebbe abbassare leggermente le prestazioni. Questo parametro indica alla CPU una latenza o qualcosa del genere per i dati.

In sostanza niente di eclatante. Possibili malfunzioamenti durante i cambi di stato, errata visualizzazione dei clock dei core in date condizioni, debug o contatori di prestazione sbagliati, blocchi di sistema in date condizioni correggibili con settaggi da BIOS... Un'altra cosa che non sembra danneggiare le prestazioni è un settaggio sui ritardi interni tra il controller RAM e il NB al boot, che devono essere settati in un certo modo, se no si possono avere errori spurii...

Credo che l'abbandono di Bergaman sia da oggi più chiaro...

[Mparlav]

Ritornando sempre sul discorso 4 threads in 4 core in 2 moduli oppure 4 threads in 4 core su 4 moduli, su hardware.fr era stata fatta un'analisi approfondita anche con i giochi (che sarebbero i maggiori beneficiari di questa situazione, visto che compressione/multimedia/rendering usano 8 threads)

http://www.hardware.fr/articles/842-...acite-cmt.html

[maurilio968]

Originariamente inviato da Mparlav

Ritornando sempre sul discorso 4 threads in 4 core in 2 moduli oppure 4 threads in 4 core su 4 moduli, su hardware.fr era stata fatta un'analisi approfondita anche con i giochi (che sarebbero i maggiori beneficiari di questa situazione, visto che compressione/multimedia/rendering usano 8 threads)

http://www.hardware.fr/articles/842-...acite-cmt.html

old

Originariamente inviato da maurilio968

Ora che ci penso il test 4/4 versus 4/2 lo hanno fatto anche i francesi

Efficacité du CMT

http://www.hardware.fr/articles/842-...acite-cmt.html

Ecco i risultati (fatto 100 il risultato del test 4/4)



Una curiosità: winrar che è uno dei test in cui l8150 va meglio è allineato in tutti e 3 i casi (un +/- 3%)
mentre , per confronto con lo stesso tipo di applicazione, 7zip è un 49% meglio in 4/8.

Mentre in tutti i giochi il 4/4 va come-meglio (del +5%) il 4/8

[Mparlav]

Originariamente inviato da capitan_crasy

Credo che l'abbandono di Bergaman sia da oggi più chiaro...

Molto peggio l'aver tolto a metà 2009 un ingegnere come Dirk Meyer per promuoverlo CEO, perplessità che manifestai già alla news del tempo.
Ha significato fare un doppio danno: togliere un progettista valido dal team di sviluppo (il suo curriculum è noto) ed inserirlo a fare gestione e strategia, per che è ovvio che non si possono fare tutte e 2 le cose.

Avrebbe dovuto rifiutare perchè quello NON è il suo lavoro, ma non mi sento di biasimare uno che a fine carriere pensa ai soldi ed ai benefit prima della pensione, ed in 1.5 anni ne ha fatti parecchi.

[bjt2]

Originariamente inviato da digieffe

tra i documenti postati nel 42301 a pagina 66 e successive sembra che i P-state di boost siano 3 (forse è già previsto un 3° step di turbo o sono io che non ne capisco)

E' solo un esempio...

[bjt2]

Originariamente inviato da maurilio968

Tesi che, vogliamo dirlo, è proprio quella dei tecnici AMD

Come ho riportato prima un BD X8 scala come un thuban 7 core al cinebench... Non mi sembra male... Però cinebench ha un IPC basso... Ma una applicazione ancora meno FP dovrebbe avere uno scaling ancora migliore...

[The3DProgrammer]

Originariamente inviato da bjt2

Come ho riportato prima un BD X8 scala come un thuban 7 core al cinebench... Non mi sembra male... Però cinebench ha un IPC basso... Ma una applicazione ancora meno FP dovrebbe avere uno scaling ancora migliore...

si ma come dicevo lo scaling di 7 significa che in ST l'FPU sta a girarsi i pollici tutto il tempo...e' da capire perche'...latenze troppo alte della cache? implementazione a coprocessore inefficiente ? Io mi sarei aspettato circa 5, quindi in proporzione prestazioni in st + elevate...sarebbe stato molto meglio. Anche perche' e' chiaro che l'FPU e' potente, se 4 in MT vanno quanto 6 di thuban...e' solo che bisogna feedarlo sto coprocessore

[bjt2]

Originariamente inviato da Mparlav

E' una recensione fissando i vcore uguali per cpu a stock ed in overclock, che sono diversi sia da quelli stabiliti dai produttori, sia da quelli realmente necessari per ottenere quegli overclock.
Di test di consumi ce ne sono a bizzeffe in rete, ed è difficile che tu possa paragonarne uno con l'altro. Piuttosto devi basarti su comparative "interne" alla recensione per tirar fuori i numeri che ti servono.

Piuttosto del mio post, darei seriamente un'occhiata alle misere prestazioni a 4.7GHz dell'FX-8150 vs il mio "misero ma mica tanto più" X6 1055T @ 4.0GHz.

Bisogna vedere se il NB era a default. Ho visto i documenti tecnici AMD e dice che il clock NB deve essere ALMENO la metà di quello dei core per andare bene... Quindi dovevano salire il NB a 2.4 minimo (meglio usare i molti pari che ancora non sono arrivato a vedere se il baco per i molti dispari esiste ancora in questa versione retail)

Gianni... Prendi nota per la rece...

[bjt2]

Originariamente inviato da Capozz

Allora bisogna rivedere l'approccio al CMT. Guarda questi dati:



L'ipc è lontanissima sia da quella di k10.5 da quella di SB, senza contare che un core SB con HT è più veloce di un modulo BD.
Considerando il divario anche Piledriver rimarrebbe comunque molto indietro.

Quel bench è notoriamente PRO-INTEL... Probabilmente usa le SSE in un modo ottimale sulle CPU INTEL, ma che non lo è sulle CPU AMD...

I test spec e HPC fatti sulle CPU Opteron danno risultati NETTAMENTE maggiori rispetto alla concorrenza... Tutta questione di compilatore...

[ozlacs]

non sono gli stepping questi? c'è un B3



(pagina 27 del secondo pdf)

[bjt2]

Originariamente inviato da gianni1879

come abbiamo notato però, il test potrebbe essere falsato perchè la cpu va in TT

E' una ipotesi...
Comunque leggendo i documenti tecnici anche BD ha il TT...
Se per SB interviene e per BD no, allora vuol dire che il silicio INTEL è messo peggio in OC, a parte i consumi...
Può darsi che siccome SB è a 95W e una parte considerevole del chip è una GPU, non ci sia sufficiente trasporto di calore, sia a causa dell'HIS dimensionato per 95W totali, che della minore superificie occupata dai core...
Comunque data la linearità di BD possiamo dire che SICURAMENTE su BD non interviene... La non linearità di SB potrebbe anche essere dovuta al turbo più aggressivo di SB. Nessuno ci assicura che cinebench gira a 3.4GHz sul SB... In ogni caso, anche se il clock medio fosse 3.6, scala meno di BD...

[niubbo69]

Originariamente inviato da bjt2

Quel bench è notoriamente PRO-INTEL... Probabilmente usa le SSE in un modo ottimale sulle CPU INTEL, ma che non lo è sulle CPU AMD...

I test spec e HPC fatti sulle CPU Opteron danno risultati NETTAMENTE maggiori rispetto alla concorrenza... Tutta questione di compilatore...

Ma i risultati di quel bench sono tragici anche tra CPU AMD e non solo rispetto ad Intel...

[Pat77]

Certo che se penso alle aspettative, io a 3,8 ghz ho un ipc su single in cinebench di circa 1,20, si parlava di un 10-15% in più per Bd (considerando che è a 3,6 default) che per 8 faceva 10 punti circa sempre in cinebench 11,5 (anche se qualcuno giurava che ne facesse 13, dov'è finito?).
La verità è che dovrebbe andare circa il doppio di quanto va, 5,9 è un punteggio indegno per un 8 core, in generale non malvagio se si guarda la concorrenza ma estremamente negativo se si guarda quanto è grosso (quindi quanto consuma), quanti core pubblicizzano e quanto costa.
Aumentare a gennaio l'ipc realmente del 10-15%, dall'attuale 0.73 (5,9/8=0,73) significherebbe passare a 3,6 a 0,84 per core e a un punteggio di 6,7, pareggiando almeno il 2600K.
E se mantengono quanto affermano, 10-15% all'anno, pareggiano il mio IPC single nel 2015, e ho un semplice 955 Phenom 2. Sandy quando lo pareggiano?

[bjt2]

Originariamente inviato da Capozz

Si ma l'ipc è più basso del 25-40% quando non si sfruttano le AVX, è un botto. Se il silicio migliorasse converrebbe seriamente shrinkare thuban, altrochè.
Come ripeto, abbiamo un'ipc più bassa con più del doppio dei transistor per avere due unità integer in più e due fpu in meno, mi sembra evidente che ci sia qualcosa che non va.

Un thuban shrinkato non raggiungerebbe le frequenze di BD... Ne abbiamo le prove: AMD aveva dichiarato di voler ottenere con BD il 30% di clock in più del K10 a parità di processo. E ci è riuscita. Llano si ferma a 2.9Ghz e non si occa oltre i 3.6GHz, perchè i consumi esplodono come per BD. Ma BD ha 3.6 GHz di default e i consumi esplodono a 4.7-4.8GHz...

Facciamo i conti:
default da 2.9 a 3.6 +24% (ma siamo 4 core contro 8)
OC da 3.6 a 4.7 +30.5%

Obiettivo raggiunto...

[Catan]

http://www.nexthardware.com/recensio...-bulldozer.htm

altra rece italiana, dove si prova prova bd con memorie a 1866, e lo si confronta con un 2600k con memorie a 1866 e un thuban 1100T sempre con ram a 1866.
viene proposto anche un interessante confronto tra i due processori con memorie a 1866 e clock di 4.6ghz per ogni uno. (purtroppo nb non è stato incrementato).

Diciamo che ad adesso mi sembra la review migliore per uno scenario di utilizzo "standard" di un buldozzer, e oggettivamente non ne esce cosi male, a confronto del 2600k, come da altre parti.

da notare la pagina dei consumi, in full alti sicuramente, ma oggettivamente poco più alti di thuban, contando le frequenze più alte e i due core fisici in più.

boh review come queste mi fanno propendere per l'acquisto di un economico 8120, per tirargli il collo.

[von Clausewitz]

Originariamente inviato da bjt2

Quel bench è notoriamente PRO-INTEL... Probabilmente usa le SSE in un modo ottimale sulle CPU INTEL, ma che non lo è sulle CPU AMD...

I test spec e HPC fatti sulle CPU Opteron danno risultati NETTAMENTE maggiori rispetto alla concorrenza... Tutta questione di compilatore...

di quale bench trattasi e soprattutto chi avrebbe stabilito che è notoriamente PRO-INTEL

[bjt2]

Originariamente inviato da Mparlav

Li ho trovati ieri sera tardi sperando di trovare informazioni su Tmax, vcore, etc: ma una rapida ricerca non ha condotto a nulla, se non al sonno dopo una giornataccia (che comprende il lancio di Bulldozer

Però mi sembra più documentazione riferita agli Opteron che agli FX.



Considera che ho preso 3 delle 4 applicazioni dove FX ha mostrato le prestazioni peggiori.
Ma certo mi ha lasciato di stucco vedere che, anche lasciando da parte Intel, è il confronto con Thuban il vero problema.



La linearità è stata riscontrata anche qui:
http://www.xbitlabs.com/articles/cpu..._14.html#sect0

purtroppo non cambia la sostanza, perchè il concorrente ha una base di partenza migliore e molto probabilmente la manterrà col prossimo die shrink e miglioramento dell'IPC.

Ma su un punto sono "irrevomibile" perchè Netburst ha fatto scuola troppo a lungo

Il clock della cpu è importante, ma è un qualcosa "di più" senza prescindere dall'IPC della cpu (e dal CPI per singolo core decisamente scarso).

http://www.hardware.fr/articles/842-...s-calculs.html

Su questo Amd deve intervenire ed in fretta: nuovo silicio per correggere gli errata e sistemare le latenze della cache

http://www.hardware.fr/articles/842-...es-caches.html

Queste sono priorità maggiori del contare sui MHz futuri.

Le latenze della cache penso siano "normali" per il clock che si erano prefissi...