Originariamente inviato da marchigiano (Messaggio 36145423)

certo che se fosse andato un 20% in più con 1.66 miliardi di transistors (262 mm2) sarebbe stato un gran bel processore...

poi avete notato che ci sono 4 link HT? penso per le versioni server dual socket 32 core... un die specifico per desktop sarebbe molto più piccolo

Originariamente inviato da paolo.oliva2 (Messaggio 36144941)

Infatti anche Bjt2 ha detto che di bug non ce ne sono...

Però... non mi tornano alcune cose... e ti dico.
Devono essere più cose combinate assieme.

Se fosse un problema di banda MC, i bench fatti con memorie a clock superiore e quindi più banda, darebbero di più, invece danno si di più ma non percentualmente.

Mettiamoci pure l'NB... ed allora sarebbero stupidi a farla 2GHz per alcuni modelli e 2,2GHz per altri.
(tra parentesi... un Thuban se si disabilitano dei core, si può alzare di più il clock NB... BD X4 clock NB minore di un BD X8? :confused: )

Le cache ha nno valori molto bassi ma si era data la colpa ad una cosa che non mi ricordo :D .

Poi c'è lo scheduler, il branch predictor, cache missing... ma questi secondo me possono si influire, ma non spiegano il clock NB e i risultati delle cache. Cioè se a monte va male, almeno a valle falle veloci per limitare i danni... loro teoricamente hanno fatto male a monte ed ancora peggio a valle :doh:

Io darei più la colpa al silicio (spiegazione Capitano con il Phenom) PERO', se fosse quello, Piledriver e superiori avrebbero performances ben superiori.... che non sono previste :confused: .

Per me semplicemente se toccano una cosa, va male un'altra e viceversa... ed il risultato è l'8150p, con in più il prb frequenze basse del silicio.

Originariamente inviato da Capozz (Messaggio 36145512)

Sicuramente c'entra il silicio, però guardando i risultati teorici su sandra ed i bench di xtremesystems imho è lo scheduler ad avere problemi enormi...il fatto di avere numeri mostruosi sui bench teorici ed uno schifo all'atto pratico e di registrare un grande aumento di ipc utilizzando solo un core int per ogni modulo non può dipendere dal silicio.

Originariamente inviato da paolo.oliva2 (Messaggio 36145004)

Infatti... altrimenti avrebbero predetto un salto di potenza notevole...

Sinceramente... la mia idea p che non ci stanno tirando fuori gli zampetti e tirano ad arrivare al 2014/2015 con progetto next generations con l'APU che elabora i dati (core e IGP).

Guarda, onestamente... AMD le idee le ha ma purtroppo non ha la potenza costruttiva di portare avanti tutto e al meglio (purtroppo).

Se adesso si impegnasse nei proci, perderebbe il vantaggio che ha (con ATI) sulla concorrenza per l'APU. Meglio accontentarsi della fascia media e medio-bassa, che poi è quella con i numeri maggiori di vendite e tirare a campare questi 2-3 anni e poi pensare a BD next-generations.

Ad esempio, discorso Llano e Trinity.
Llano si vende e parecchio... Trinity ha una IGP più potente del 50% rispetto a Llano, ma Llano ha molti problemi di clock rispetto al 45nm, quindi un trinity anche a livello di core, sarebbe nettamente superiore. Se di Llano ne stanno vendendo un tot, di Trinity ne venderanno ancor di più.

Ed amen alla fascia medio-alta... ma che almeno aumentino le potenze magari abbassando ancor di più i prezzi... venderebbero ugualmente.

Originariamente inviato da papafoxtrot (Messaggio 36145135)

uello di cui parli è il fatto che la L1D è write through. Sono daccordo che una cache più veloce aiuterebbe. Ma se fosse colpa della L1 non si guadagnerebbe così tanto a disattivare un core.
Per quanto riguarda la L3 e il MC, non sono certo eccellenti, soprattutto la L3, ma secondo me non è colpa loro, perché anche qui non si vedrebbe tutta sta differenza tra 4core4moduli e 4core2moduli.

Per questo ritengo che proprio il BP sia orrendo, e forse anche il decoder ci mette del suo...

Sotto queste ipotesi però mi domando: che senso ha sostituire Llano con trinity... Ad oggi un 4100 non arriva alle prestazioni di llano ed è molto più grosso (lato CPU). Quindi in pratica un trinity costerebbe di più a prodursi, per andare forse uguale... Che cosa ci guadagnano?
O erano schedulati e han deciso di andare avanti lo stesso, confidando sul fatto che comunque in qualche test è effettivamente migliore... oppure piledriver guadagnerà più di quei 10-15%...

Oppure ancora, quei 10-15% sono una media, e grazie a qualche ottimizzazione, il guadagno sarà del 20-25% dove va peggio, e del % dove va già bene. Questa la troverei la soluzione migliore...

In ogni caso spero che con piledriver, che mi par di capire è solo per desktop, riducano la cache L2, che costa un sacco e non credo aiuti così tanto..
Magari si tornerà ai 2MB per modulo quando, tra un anno o due, le prestazioni generali saranno migliori e la miniaturizzazione più spinta...
Oppure trinity sarà senza L3? E allora ci stanno gli 8MB di L2... Ma allora anche wishera avrebbe di nuovo quella costosa e inutile cache di troppo...

Hem, c'è possibilità di vedere cache 8T a breve? Almeno per la L2, dovrebbero avere migliori prestazioni, vero?
E una hem hem... z-ram per la L3? :D :D

Originariamente inviato da Athlon 64 3000+ (Messaggio 36145537)

Trinity sarà fatto da 2 moduli e da quello che sappiano occupano con le cache L2 per modulo occupano in tutto 61 mm^2 e quindi molto poco spazio.
Poi penso che la L3 verrà tolta da Trinity.

Originariamente inviato da Grizlod® (Messaggio 36145736)

Ciao, lurkerò il thread un po ad intermittenza; quando avrò un BD sulla mia MB posterò qualche impressione...anche in merito al chipset 890...

Originariamente inviato da marchigiano (Messaggio 36145820)

ma sta storia dei die tagliati a mano o automaticamente è vera o è una bufala?

Originariamente inviato da paolo.oliva2 (Messaggio 36146099)

Gli FX 6100 sono disponibili in Italia.
Pr**o, 174€.

Originariamente inviato da DottorLeo (Messaggio 36146082)

FX-8150 su Linux:

http://www.phoronix.com/scan.php?pag...tem&px=MTAwMTI

http://openbenchmarking.org/result/1...LI-BULLDOZER29