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

[pasqualaccio]

sysopsys ammazzate quanto sei arrogante... prima critichi la gente che ti risponde in moto secco, poi sei tu a farlo, tipico comportamento dei bambini di 10 anni, spero che i mod leggano, ti servira una bella reogola e un po di RL

http://www.hwupgrade.it/forum/showpost.php?p=35084169&postcount=2 :stordita:

[Jean240]

http://www.hwupgrade.it/forum/showpost.php?p=35084169&postcount=2 :stordita:

Questa è bella :D Predichiamo bene ma razzoliamo malissimo!

[xage]

Pasqualaccio Davvero prenditi un po di xanax....
Hai taggato una semplice risposta ma non tutto il resto della discussione... davvero pazzesco... la gente non sa piu nemmeno dove andar a sbatter la testa con questo caldo.

[xage]

Questa è bella :D Predichiamo bene ma razzoliamo malissimo!

evvaii uno dietro l'altro...... io mi chiedo a volte se la gente e normale o spamma solo x battere qualche tasto.
Che senso ha prender una parte di testo e taggarlo qui, poi la gente "furba" commenta senza sapere nulla di quella storia.

[XB-J]

evvaii uno dietro l'altro...... io mi chiedo a volte se la gente e normale o spamma solo x battere qualche tasto.
Che senso ha prender una parte di testo e taggarlo qui, poi la gente "furba" commenta senza sapere nulla di quella storia.

Bhe, la gente comune facendo 2 click in più vede che questo era il tuo primo commento subito dopo la notizia e non una parte di commento , riguardo all'inserimento da parte di intel del transistor 3d .. :mc:

[calabar]

Pasqualaccio Davvero prenditi un po di xanax....
Hai taggato una semplice risposta ma non tutto il resto della discussione... davvero pazzesco... la gente non sa più nemmeno dove andar a sbatter la testa con questo caldo.
Non lo dico per prendere parte alla gogna mediatica, però vedere quel topic nel suo contesto non migliora la tua posizione neanche un po'! :p
Vabbè dai, un intervento eccessivo può capitare a tutti.

Ora però basta con l'OT altrimenti qui si rischia di degenerare! ;)

[freedzer]

Ragazzi probabilmente lo sapete già ma al gamescom c'era un pc con bulldozer fx 8 core che runnava colin mcrae dirt...gli ho fatto la foto ricordo ovviamente :-)

[sniperspa]

Ragazzi probabilmente lo sapete già ma al gamescom c'era un pc con bulldozer fx 8 core che runnava colin mcrae dirt...gli ho fatto la foto ricordo ovviamente :-)

se non sbaglio è stato postato un video qualche pagina fa a riguardo :)

[Jean240]

Ragazzi probabilmente lo sapete già ma al gamescom c'era un pc con bulldozer fx 8 core che runnava colin mcrae dirt...gli ho fatto la foto ricordo ovviamente :-)

Se non sbaglio era già stato postato :)
Sniperspa mi hai anticipato :D

[sysopsys]

Ragazzi probabilmente lo sapete già ma al gamescom c'era un pc con bulldozer fx 8 core che runnava colin mcrae dirt...gli ho fatto la foto ricordo ovviamente :-)

che poi con tanti giochi pesanti proprio colin dirt, cosi pesante è ?

[deidara80]

ragazzi. non seguo da un po'. ancora nada?

[liberato87]

ragazzi. non seguo da un po'. ancora nada?

:read:

Ma questa nuova serie non doveva uscire a fine Giugno? A che punto sono? Ultimamente non ci sono stato dietro e non vorrei fossero usciti senza che me ne sia accorto...:confused:

non sono usciti ancora!

[bs82]

Perchè Bulldozer di seconda generazione ha integrato il northbridge nel DIE della CPU rendendo incompatibile l'attuale infrastruttura del socket AM3+...

Ehm, veramente sono eoni che le cpu amd hanno il "Northbridge" integrato nel die della cpu stessa...

Casomai il cambio socket è dovuto al fatto che sul quel socket si potranno mettere sia cpu "semplici" come Bulldozer (II) sia le APU.

[capitan_crasy]

Ehm, veramente sono eoni che le cpu amd hanno il "Northbridge" integrato nel die della cpu stessa...

Casomai il cambio socket è dovuto al fatto che sul quel socket si potranno mettere sia cpu "semplici" come Bulldozer (II) sia le APU.

Non parlo certo del Northbridge della CPU, elemento presente dalle prime soluzioni multi core, ma del northbridge inteso come chipset tipo 990FX/890FX o più semplicemente il controller PCI-Express.
Dato che il socket AM3+ ha un infrastruttura con un northbridge esterno una CPU come Komodo non può essere compatibile, anche e soprattutto per la mancanza del link Hypertransport diventato del tutto superfluo nelle configurazioni mono socket...

[scrat1702]

Ehm, veramente sono eoni che le cpu amd hanno il "Northbridge" integrato nel die della cpu stessa...

Casomai il cambio socket è dovuto al fatto che sul quel socket si potranno mettere sia cpu "semplici" come Bulldozer (II) sia le APU.

E il NB montato sulle mobo secondo te perche sta li? BD avra integrato il controller delle memorie, ma il resto e pilotato dal NB collegato alla CPU via HTT. Mentre BD2 avra un approccio stile intel core iX :)

[Athlon 64 3000+]

http://www.technic3d.com/news/hardware/cpus/6867-amd-praesentiert-details-der-bulldozer-archtitektur-auf-der-hot-chips-23.htm

nuove slide su Zambezi.

[Athlon 64 3000+]

Nell'articolo dove sono postate le slide se ho capito bene secondo loro l'IPC di BD a parità di frequenza è paragonabile al K10.
Mi chiedo come si faccia a dire una cavolata del genere visto che a parte le proiezioni di BJT2 non sappiamo le reali prestazioni di Bulldozer.

[ozlacs]

http://semiaccurate.com/2011/08/21/and-the-bulldozer-die-size-is/

[checo]

Pasqualaccio Davvero prenditi un po di xanax....
Hai taggato una semplice risposta ma non tutto il resto della discussione... davvero pazzesco... la gente non sa piu nemmeno dove andar a sbatter la testa con questo caldo.

evvaii uno dietro l'altro...... io mi chiedo a volte se la gente e normale o spamma solo x battere qualche tasto.
Che senso ha prender una parte di testo e taggarlo qui, poi la gente "furba" commenta senza sapere nulla di quella storia.

Non siamo su facebook...

[The3DProgrammer]

315 mm^2...ammazza se è grosso

[Pat77]

Nell'articolo dove sono postate le slide se ho capito bene secondo loro l'IPC di BD a parità di frequenza è paragonabile al K10.
Mi chiedo come si faccia a dire una cavolata del genere visto che a parte le proiezioni di BJT2 non sappiamo le reali prestazioni di Bulldozer.

Non so, leggendo e rileggendo, vedendo l'architettura, in ambiti specifici potrebbe anche essere, per privilegiare poi le applicazioni che usano molti core e fare la differenza li, per me in uno scenario dual core software non ci saranno grosse differenze a parità di frequenza, ma penso comunque che un 10% in più BD possa ottenerlo.

[scrat1702]

315 mm2 sono un po troppi. Cmq per gli 8 core non sono una tragedia, ci guadagnano cmq! Il problema e con gli X4 e X6. Qui sono in forte perdita. Cmq mi pare strano che un Gulftown sia 239 e un BD sia 315. Qualcosa e andato storto, oppure l' IPC e mostruoso. Per saperla bisognera aspettare ancora un po. Se il dato di 315mm2 sara confermato allora anche se andassero alla pari di un 2600K sarebbe un FAIL.

[calabar]

Mi pare che in passato fossero stati fatti calcoli sul die size e il risultato fosse proprio questo, intorno ai 315 mm^2.
Quindi niente di sorprendente, sebbene vista la dimensione dei processori della concorrenza (che presumibilmente diminuirà ancora con i 22nm) il die di BD appare piuttosto grosso, e ci si chiede dove sta il vantaggio di tutta questa condivisione.
Vabbè, aspettiamo a vedere le performance prima di giudicare.

[OEidolon]

LOL ma copiate i commenti che ci sono su SA?! :asd: (sto scherzando, eh! non state a prendervela, che non ho alcun intento polemico ;) )

battute a parte...mi spiegate dove sta il problema di questi (immensi) 315mm^2?

partendo dal considerare che un thuban è su 346mm^2, facendo poi dei conti spanning (cioè a spanne, senza alcuna pretesa scientifica, eh...), facendo finta di fare un thuban a 8c su sti benedetti 32nm:
thuban 6c 45nm 346mm^2 -> 8c 45nm 346x8/6=461mm^2
45nm -> 32nm 461x32/45=328mm^2
per confronto gulftown 6c 32nm è su 240mm^2 (8c diventerebbero 320mm^2, quindi siamo lì...)

tutto sommato, non mi pare che 315mm^2 siano chissà che eresia...il punto sta nel fatto che prestazionalmente ed economicamente siano competitivi, ma per vedere questo basta avere ancora un po' di pazienza...

[ozlacs]

vabbè ma giudicare la grandezza del die confrontondola con quella di altri processori che senso ha così?
o meglio, bisognerebbe sapere quanta roba contiene un die BD, quanti transistor, in quel modo si vede la densità, o sbaglio?

[scrat1702]

LOL ma copiate i commenti che ci sono su SA?! :asd: (sto scherzando, eh! non state a prendervela, che non ho alcun intento polemico ;) )

battute a parte...mi spiegate dove sta il problema di questi (immensi) 315mm^2?

partendo dal considerare che un thuban è su 346mm^2, facendo poi dei conti spanning (cioè a spanne, senza alcuna pretesa scientifica, eh...), facendo finta di fare un thuban a 8c su sti benedetti 32nm:
thuban 6c 45nm 346mm^2 -> 8c 45nm 346x8/6=461mm^2
45nm -> 32nm 461x32/45=328mm^2
per confronto gulftown 6c 32nm è su 240mm^2 (8c diventerebbero 320mm^2, quindi siamo lì...)

tutto sommato, non mi pare che 315mm^2 siano chissà che eresia...il punto sta nel fatto che prestazionalmente ed economicamente siano competitivi, ma per vedere questo basta avere ancora un po' di pazienza...

Si OK, ma un Gulftown a 8 core (sarebbe meno dei 320mm2 visto che l'uncore e memory cntroller non cambiano) avrebbe 8 core INT e 8 FPU con 16 thread ;) Il problema non sta nella misura in se, ma nel costo di produzione. Intel vende 239mm2 a 1000$, AMD 315mm2 a 300$..... fatti due calcoli....

[marchigiano]

315 mm2 sono un po troppi. Cmq per gli 8 core non sono una tragedia, ci guadagnano cmq! Il problema e con gli X4 e X6. Qui sono in forte perdita. Cmq mi pare strano che un Gulftown sia 239 e un BD sia 315. Qualcosa e andato storto, oppure l' IPC e mostruoso. Per saperla bisognera aspettare ancora un po. Se il dato di 315mm2 sara confermato allora anche se andassero alla pari di un 2600K sarebbe un FAIL.

considerando anche che il silicio amd costa di più per via del soi


- Il progetto di bulldozer non era stato portato avanti pensando al contenimento delle dimensioni grazie alla condivisione di risorse?
- L'HKMG gate first non doveva consentire densità favolose rispetto al gate last?

si ma se ci metti 16mb di cache contro 9.5 della concorrenza...

Almeno abbiamo capito perché la versione 45nm non ha mai visto la luce

già :D un mostro da 600mm2

ora capisco perchè hanno dato la precedenza a llano con i suoi 228mm2

[The3DProgrammer]

315 mm2 sono un po troppi. Cmq per gli 8 core non sono una tragedia, ci guadagnano cmq! Il problema e con gli X4 e X6. Qui sono in forte perdita. Cmq mi pare strano che un Gulftown sia 239 e un BD sia 315. Qualcosa e andato storto, oppure l' IPC e mostruoso. Per saperla bisognera aspettare ancora un po. Se il dato di 315mm2 sara confermato allora anche se andassero alla pari di un 2600K sarebbe un FAIL.

tradizionalmente comunque le CPU AMD sono quasi sempre state + grosse di quelle intel, questo penso che abbia radici ben precise: l'ottimizzazione software. Intel ha sempre spinto fortemente sull'ottimizzazione del software per le proprie architetture, di conseguenza e' + facile tirarne fuori il massimo.

[scrat1702]

si ma se ci metti 16mb di cache contro 9.5 della concorrenza...



Anche questo e vero, vedremo il die di SB-Ex con 15Mb di L3. Pero se questi 16Mb non danno vataggi tangibili, tanto faceva lasciarne 8. A questo punto mi aspetto prestazioni superiori a K10 di almeno un 50-60%, altrimenti sara un buco nell'ucqua per AMD.

[marchigiano]

Lo dicevo appunto qualche post fa, la quantità di cache è enorme, quindi tutto questo spazio penso sia "colpa" sua.

la cosa buona almeno è che se capita un difetto sulla cache la disattivi in parte e puoi vendere comunque la cpu. inoltre la cache fa poco calore e notate come l'hanno messa, con i core ai lati per dissipare meglio

Anche questo e vero, vedremo il die di SB-Ex con 15Mb di L3. Pero se questi 16Mb non danno vataggi tangibili, tanto faceva lasciarne 8. A questo punto mi aspetto prestazioni superiori a K10 di almeno un 50-60%, altrimenti sara un buco nell'ucqua per AMD.

il fatto è che amd non ha i volumi per permettersi svariati die size, almeno per ora, quindi fa la cpu opteron che necessita di tanta cache e la vende anche per desk anche se ci guadagna meno

poi non è detto che tra un po faranno delle versioni specifiche desk con meno l2 o senza l3

[OEidolon]

Si OK, ma un Gulftown a 8 core (sarebbe meno dei 320mm2 visto che l'uncore e memory cntroller non cambiano) avrebbe 8 core INT e 8 FPU con 16 thread ;) Il problema non sta nella misura in se, ma nel costo di produzione. Intel vende 239mm2 a 1000$, AMD 315mm2 a 300$..... fatti due calcoli....

su questo non c'è dubbio. Però per esempio adesso AMD sta vendendo 346mm^2 a 180euro, facciamo anche qui due calcoli...vendere 346mm^2 a 200$ e 315mm^2 a 300$ (e nel prezzo è sempre inclusa una parte relativa ai costi di progettazione). Non la vedo così brutta neanche in questo ambito. Poi ricordiamoci anche del contratto di fornitura "pago solo la roba buona", in cui AMD non deve neanche preoccuparsi dei pezzi difettosi.

come anticipato da Veradun, anche andasse uguale a thuban, per singola cpu AMD ci guadagna. Volendo essere realisti oltre che fiduciosi, non penso che AMD si metta a commercializzare una nuova cpu top di gamma che va come la precedente ma ad un costo superiore :sperem:

[capitan_crasy]

considerando anche che il silicio amd costa di più per via del soi


Ma anche no, anche se è difficile fare un paragone con il silicio di Intel o quello utilizzato da TSCM soprattutto per le diverse cifre investite per lo sviluppo e la messa in opera...



315 mm2 sono un po troppi. Cmq per gli 8 core non sono una tragedia, ci guadagnano cmq! Il problema e con gli X4 e X6. Qui sono in forte perdita. Cmq mi pare strano che un Gulftown sia 239 e un BD sia 315. Qualcosa e andato storto, oppure l' IPC e mostruoso. Per saperla bisognera aspettare ancora un po. Se il dato di 315mm2 sara confermato allora anche se andassero alla pari di un 2600K sarebbe un FAIL.

AMD ha sempre venduto CPU con core fallati e con BD farà lo stesso...
Qui abbiamo una CPU con più cache, più core, più transistor in un DIE più piccolo del six core K10 45nm e anche in questo caso AMD vende il "castrato" (detta così sembra la sagra del maiale:D ).
E chiaro che se non era economicamente produttivo gli eventuali scarti non sarebbero mai proposti alla vendita...
Un conto progettare, sviluppare e produrre 3 versioni della stessa CPU su tre linee diverse, un conto è averne a disposizione una sola linea produttiva per tre modelli diversi...

[RIC3]

Domanda da nubbio cosa sono 315mm^2?

[Jean240]

Domanda da nubbio cosa sono 315mm^2?

La dimensione del Die della cpu

[gianni1879]

sysopsys ammazzate quanto sei arrogante... prima critichi la gente che ti risponde in moto secco, poi sei tu a farlo, tipico comportamento dei bambini di 10 anni, spero che i mod leggano, ti servira una bella reogola e un po di RL

E quante volte bisogna ancora ripeterlo: NO!

http://www.hwupgrade.it/forum/showpost.php?p=35084169&postcount=2 :stordita:

Questa è bella :D Predichiamo bene ma razzoliamo malissimo!

Pasqualaccio Davvero prenditi un po di xanax....
Hai taggato una semplice risposta ma non tutto il resto della discussione... davvero pazzesco... la gente non sa piu nemmeno dove andar a sbatter la testa con questo caldo.

evvaii uno dietro l'altro...... io mi chiedo a volte se la gente e normale o spamma solo x battere qualche tasto.
Che senso ha prender una parte di testo e taggarlo qui, poi la gente "furba" commenta senza sapere nulla di quella storia.
non quoto nemmeno gli altri, cmq

xage, pasqualaccio e sysopsys siete sospesi 5gg.

Jean240 2gg

[gianni1879]

no la fregatura è quella...invece io farò questa mossa costruirò un bel sistema 1155 tranne che x la cpu mettendo il minimo sindacabile ovvero un i5 2300 magari preso dal mercatino e vado avanti fino all'uscita di ivy bridge dopodichè lo sostituisco o con un ivy appunto oppure con un sandy i7 sfruttando il calo di prezzo che dovranno x forza subire dato che ivy andrà a sostituirli nelle stessa fasce....x le prestazioni è vero bisogna aspettare ma inutile illudersi andranno +o- uguali con differenze a seconda dei bench e cmq sia nn li prenderò lo stesso:D

non vedo cosa centri tutto questo con il thread.

Sei palesemente ot e ti invito a leggere la prima pagina per bene.

Sei sospeso 3gg

[gianni1879]

Statte bono che qui aspettano il Messia
non disturbare PLS

2gg di sospensione

[capitan_crasy]

Per Athlon 64 3000+ e ozlacs:
Grazie per la segnalazione:

Die Bulldozer per soluzioni server
http://img26.imageshack.us/img26/7990/bulldozerdiesize.png
Viene confermato che le dimensioni del DIE 8 core Bulldozer 32nm SOI è più piccolo (315mm2) del DIE 6 core Thuban 45nm SOI (346mm2).

http://img508.imageshack.us/img508/5964/slide01.jpg
http://img3.imageshack.us/img3/2374/slide02s.jpg
http://img29.imageshack.us/img29/8261/slide03p.jpg
http://img405.imageshack.us/img405/9157/slide04.jpg
http://img835.imageshack.us/img835/5605/slide05.jpg
http://img198.imageshack.us/img198/8755/slide06.jpg
http://img814.imageshack.us/img814/463/slide07.jpg
http://img41.imageshack.us/img41/8702/slide08h.jpg
http://img30.imageshack.us/img30/4761/slide09fi.jpg
http://img15.imageshack.us/img15/4528/slide10s.jpg
http://img27.imageshack.us/img27/5549/slide11ht.jpg

["Blue"]

ma il mio amico Pasqualaccio non ha fatto una ceppa se non quello di far notare il tenore del Post:o

Ci divertiamo col tasto ban :D

[FroZen]

"Viene confermato che le dimensioni del DIE 8 core Bulldozer 32nm SOI è più piccolo (315mm2) del DIE 6 core Thuban 45nm SOI (346mm2)."

Ottimo risultato no?

Come mai leggo pareri perplessi invece? :mbe: :mbe: :mbe:

[calabar]

Ottimo risultato no?
Come mai leggo pareri perplessi invece? :mbe: :mbe: :mbe:
Perchè gli utenti non si limitano a fare confronti con thuban, ma li fanno anche con i processori della concorrenza. :)

@"Blue"
Credo sia meglio che tu editi, prima che diventiate due a divertirvi per il ban! :p

[marchigiano]

Il Nehalem-EX era oltre 600mm2 se non sbaglio, che è un enormità per 8 core

si ma li vendono a 3-5000€, ci rientrano comunque penso :D

Ma anche no, anche se è difficile fare un paragone con il silicio di Intel o quello utilizzato da TSCM soprattutto per le diverse cifre investite per lo sviluppo e la messa in opera...

a certo per lo sviluppo di sicuro spende più intel, però qui si è sempre sostenuto che il soi costa abbastanza di più, penso sia vero

"Viene confermato che le dimensioni del DIE 8 core Bulldozer 32nm SOI è più piccolo (315mm2) del DIE 6 core Thuban 45nm SOI (346mm2)."

Ottimo risultato no?

Come mai leggo pareri perplessi invece? :mbe: :mbe: :mbe:

perchè ci aspettavamo sui 290mm

[scrat1702]

"Viene confermato che le dimensioni del DIE 8 core Bulldozer 32nm SOI è più piccolo (315mm2) del DIE 6 core Thuban 45nm SOI (346mm2)."

Ottimo risultato no?

Come mai leggo pareri perplessi invece? :mbe: :mbe: :mbe:

Perche le unita di calcolo sono le stesse, cioe 6+6 Thuban e 8+4 Zambezi, considerando la differenza di PP la differenza dovrebbe essere maggiore. pero ci sono le cache doppie che occupano spazio. Il dubbio resta sul fatto se veramente serva tutta quella cache in ambito desktop. Purtroppo AMD non puo permettersi di avere 2 linee separate per gli Opteron e gli FX, e credo che il tutto e stato calcolato. Vedremo con i bench quanto queste cache diano risultati. La concorrenza e riuscita a rientrare in 240mm2 per 12 unita e 13.5Mb di cache. Avendo, a detta di tutti, un PP meno raffinato.

[AceGranger]

Il Nehalem-EX era oltre 600mm2 se non sbaglio, che è un enormità per 8 core.


bè era anceh a 45nm...

attualmente lo Xeon E7-8870 ( Westmere-EX a 32nm ) 10+10, 30 MB di cache ( lol ) dovrebbe avere una superficie di 513mm2

[AceGranger]

Cos'è 10+10?

l'HT :stordita:... 10 core + 10 HT

[bjt2]

"Viene confermato che le dimensioni del DIE 8 core Bulldozer 32nm SOI è più piccolo (315mm2) del DIE 6 core Thuban 45nm SOI (346mm2)."

Ottimo risultato no?

Come mai leggo pareri perplessi invece? :mbe: :mbe: :mbe:

È colpa delle voci pessimistiche sulle prestazioni che girano... BD ha molti più transistors per core di Thuban e quindi occupa molto spazio... Non solo come cache ma anche come logica... Io credo che avrà maggiore IPC e quindi l'area in più è giustificata...

[dav1deser]

È colpa delle voci pessimistiche sulle prestazioni che girano... BD ha molti più transistors per core di Thuban e quindi occupa molto spazio... Non solo come cache ma anche come logica... Io credo che avrà maggiore IPC e quindi l'area in più è giustificata...

Non credi però ci sia il rischio che BD X10 risulti eccessivamente grosso? Cioè 2 core in più, il northbridge, nuove istruzioni, e forse altra cache di sicuro si faranno sentire...

[The3DProgrammer]

È colpa delle voci pessimistiche sulle prestazioni che girano... BD ha molti più transistors per core di Thuban e quindi occupa molto spazio... Non solo come cache ma anche come logica... Io credo che avrà maggiore IPC e quindi l'area in più è giustificata...

sicuramente sara' giustificata rispetto al thuban, bisognera' vedere se sara' giustificata rispetto a SB (anche se come dicevo prima, l'ottimizzazione software gioca un ruolo troppo importante in questo senso)

[dav1deser]

Senza forse, c'è obbligatoriamente altra cache, almeno tutta quella che fa parte del modulo in più.

Be' quella si, ma io parlo della L3, che non mi pare essere strettamente dipendente dal numero di moduli (se non ricordo male).

[calabar]

l'HT :stordita:... 10 core + 10 HT
No, 10 int e 10 fp, in contrasto con il numero di fp dimezzato di bulldozer (ma cerchiamo di ricordare che sono fp più grosse!)

Parlare di 10 core + 10 HT è concettualmente sbagliato, sono 10 core reali, o 20 virtuali ottenuti con HT. Pardon, SMT.

[paolo.oliva2]

C'è qualche cosa che non mi torna....

All'inizio BD non doveva essere 290mm2? Perché ora sarebbe passato a 316mm2?
Hanno aggiunto altra logica?

Inoltre... Una volta si parlava di un Turbo di +500MHz... ma ciò sarebbe impossibile per frequenze base di 200MHz se non usando frazioni (2.5) ed impossibili se la frequenza base fosse 300MHz.

Un'altra cosa da appuntare è che non capisco tutta sta storia che BD non sarebbe da prendere perché il socket sarebbe morto (forse chi lo scrive non sa che in scaletta già altri modelli ad inizio 2012, cioè fra 6 mesi e credo impossibile che non venga conservato sul mercato almeno per altri 6 mesi).

Non voglio fare assolutamente un discorso di parte... ma prima di emettere sto giudizio credo sia utile aspettare di conoscere le potenzialità del procio...

Facciamo questo esempio: il vero cambiamento per il socket FM2 cos'è? Avere l'NB integrato? Cacchio, 1-3 fp in più... L'aumento di frequenza ed IPC di BD2? Bisognerebbe quantificare l'aumento e rapportarlo sul costo del sistema, altrimenti su che base si parla? E poi BD next-generations, quello a 22nm, probabilmente cambierà ulteriormente il socket, quindi il discorso dove cambierebbe? Che sarebbe inutile comprare l'FM2 perché si aspetterebbe l'FM3?

Il discorso principale invece sarebbe quantificare le potenzialità di BD X8, quantificare il rapporto prezzo/prestazioni, sapere quando uscirà BD2 e poi decidere, il discorso socket vecchio non c'entra una mazza.

Cos'è che reputa vecchio un socket? Non tanto l'upgrade a modelli nuovi di procio, ma l'impossibilità di poter arrivare a prestazioni massime, ottenibili unicamente con il nuovo socket.

Cercate allora di convincermi che un BD 1 X8 non possa offrire una potenza superiore di un BD2 X4 o X6, oppure che tutti si butteranno a pesce ad acquistare Komodo X10...

[gianni1879]

ma il mio amico Pasqualaccio non ha fatto una ceppa se non quello di far notare il tenore del Post:o

Ci divertiamo col tasto ban :D

il regolamento questo sconosciuto...


3gg di sospensione

[NOKX]

quando andrò a scegliere fra BD e SB conteranno solo quanto vanno e quanto costano a me, quanto costano a loro a prodursi (AMD e Intel) o quanto siano stati dei fighi della madonna ad ottimizzare il die m'importa meno che niente :asd:
concordo in pienoooooooooooooo:cool: :cool: :cool: :cool:

[calabar]

C'è qualche cosa che non mi torna....
All'inizio BD non doveva essere 290mm2? Perché ora sarebbe passato a 316mm2?
Non mi pare che quella stima fosse altro che una supposizione, quindi non devo nulla di strano con la differenza rispetto al dato reale.
Inoltre ricordo stime anche più elevate, quella più accreditata qualche tempo fa era appunto "un po' più di 300mm^2".

[marchigiano]

All'inizio BD non doveva essere 290mm2? Perché ora sarebbe passato a 316mm2?
Hanno aggiunto altra logica?[QUOTE]

no erano solo supposizioni, si andava da 290 a 320, solo che pure io speravo magari nel colpaccio e un valore addirittura sotto i 290...

[QUOTE]Inoltre... Una volta si parlava di un Turbo di +500MHz... ma ciò sarebbe impossibile per frequenze base di 200MHz se non usando frazioni (2.5) ed impossibili se la frequenza base fosse 300MHz.

è ovvio che usano frazioni :) il tuo thuban come fa scusa? e la freq base mi pare assodato che sia 200

il vero cambiamento per il socket FM2 cos'è? Avere l'NB integrato? Cacchio, 1-3 fp in più... L'aumento di frequenza ed IPC di BD2? Bisognerebbe quantificare l'aumento e rapportarlo sul costo del sistema, altrimenti su che base si parla? E poi BD next-generations, quello a 22nm, probabilmente cambierà ulteriormente il socket, quindi il discorso dove cambierebbe? Che sarebbe inutile comprare l'FM2 perché si aspetterebbe l'FM3?


il northbridge integrato, oltre ad aumentare un pochino l'ipc, ti fa costare meno le mobo, un solo chip invece di 2, mobo più semplici con meno bus...

per il socket, c'è gente che è fissata con la longevità della mobo, porta pazienza

a proposito di mobo non ho capito se si può parlare qui di am3+ o c'è una discussione apposita nel forum mobo?

[paolo.guidx]

Io le sospensioni ad-minkiam non le capisco. :nono:

Che serve, una riforma della giustizia anche qui? :mbe:

[digieffe]

Io le sospensioni ad-minkiam non le capisco. :nono:

Che serve, una riforma della giustizia anche qui? :mbe:

da qualche parte nel regolamento c'è scritto che i motivi delle sospensioni vanno discussi in privato con il moderatore.... e non nel forum (credo che sia questo il motivo della sospensione /OT

[jok3r87]

C'è qualche cosa che non mi torna....

All'inizio BD non doveva essere 290mm2? Perché ora sarebbe passato a 316mm2?
Hanno aggiunto altra logica?

Inoltre... Una volta si parlava di un Turbo di +500MHz... ma ciò sarebbe impossibile per frequenze base di 200MHz se non usando frazioni (2.5) ed impossibili se la frequenza base fosse 300MHz.

Un'altra cosa da appuntare è che non capisco tutta sta storia che BD non sarebbe da prendere perché il socket sarebbe morto (forse chi lo scrive non sa che in scaletta già altri modelli ad inizio 2012, cioè fra 6 mesi e credo impossibile che non venga conservato sul mercato almeno per altri 6 mesi).

Non voglio fare assolutamente un discorso di parte... ma prima di emettere sto giudizio credo sia utile aspettare di conoscere le potenzialità del procio...

Facciamo questo esempio: il vero cambiamento per il socket FM2 cos'è? Avere l'NB integrato? Cacchio, 1-3 fp in più... L'aumento di frequenza ed IPC di BD2? Bisognerebbe quantificare l'aumento e rapportarlo sul costo del sistema, altrimenti su che base si parla? E poi BD next-generations, quello a 22nm, probabilmente cambierà ulteriormente il socket, quindi il discorso dove cambierebbe? Che sarebbe inutile comprare l'FM2 perché si aspetterebbe l'FM3?

Il discorso principale invece sarebbe quantificare le potenzialità di BD X8, quantificare il rapporto prezzo/prestazioni, sapere quando uscirà BD2 e poi decidere, il discorso socket vecchio non c'entra una mazza.

Cos'è che reputa vecchio un socket? Non tanto l'upgrade a modelli nuovi di procio, ma l'impossibilità di poter arrivare a prestazioni massime, ottenibili unicamente con il nuovo socket.

Cercate allora di convincermi che un BD 1 X8 non possa offrire una potenza superiore di un BD2 X4 o X6, oppure che tutti si butteranno a pesce ad acquistare Komodo X10...

Saranno sempre e solo 8 core con qualche mhz in più. Se per te il cambiamento da BD1 a BD2 e insignificante come fai a considerare rilevante l'uscita tra 6 mesi (forse :rolleyes: ) di un BD1 con 400mhz in più rispetto a quelli che dovrebbero uscire a Settembre ?

Ovviamente restando fermi alle sole possibilità offerte da AMD se poi prendiamo in considerazione cosa offre la concorrenza adesso con possibilità di upgrade tra 6 mesi...

[crazyduck00]

il northbridge integrato, oltre ad aumentare un pochino l'ipc, ti fa costare meno le mobo, un solo chip invece di 2, mobo più semplici con meno bus...

per il socket, c'è gente che è fissata con la longevità della mobo, porta pazienza

a proposito di mobo non ho capito se si può parlare qui di am3+ o c'è una discussione apposita nel forum mobo?

Quoto su tutto tranne sul fatto dei prezzi. O meglio, forse andranno a costare di meno rispetto quelle attuali le mobo con qualche modello inferiore della famiglia hudson d4 (sempre enthusiast), ma non credo proprio che i modelli top di gamma dello stile crosshair, o msi, o gigabyte stile super overclocked caxxi e mazzi, con chip per oc genie, chip di qua chip di la, dissipatori per mosfet di qualita, reparti di alimentazione super cazzuti, ecc ecc avranno prezzi diversi dalle top di gamma attuali (990fx). Io credo che questa tipologia di mobo si piazzera sempre sulle 140/200 euro come è sempre stato. Perchè poi i prezzi gli e li fanno lievitare proponendo soluzioni mobo super gamer o per gli overclocked esigenti, e cose che gia sappiamo.
Ti ricordo che ci saranno anche le mobo per la fascia mainstream che dovranno avere un prezzo, in base la tua teoria sulle mobo enthusiast praticamente le A75/55 con hudson d2 e d3 per mainstream dovranno costare 30 euro ? Non credo proprio sarà cosi.
Vedi per esempio la controparte dove anche li il pci express è integrato su SB, ma se vai a guardare i prezzi della maximus iv o gigabyte super overclocked con i dissipatori a forma di canna di fucile e tutte quelle cavolate ke gli fanno per speculare denaro, ti assicuro che tutto sono quelle mobo meno che semplici.
Sicuramente la rimozione del northbridge e del bus ht influirà sulla semplicità della mobo, ma la complessità di una scheda madre non è influenzata solo dalal presenza del northbridge.
Poi ovviamente io spero che tu abbia ragione. se costeranno di meno sara meglio per le nostre tasche. Ma ti ricordo anche che le mobo enthusiast dovranno gestire komodo, cpu a 10 core con tutti i sacramenti integrati nel package. Non credo che bastera una mobo semplice per soddisfare komodo e l'utente super appassionato. O cmq non credo proprio che faranno mobo soltanto economiche e scrause da 80 euro, le top da bava alla bocca ci saranno sempre come ci sn sempre state, epurtroppo sono quelle che hanno il prezzo piu elevato delle sorelle piu economiche.
E' importante ricordare che la differenza fra mainstream ed enthusiast non dovra manifestarsi solo sulle cpu/apu, ma come è sempre stato si fara sentire anche nel comparto mobo, almeno questa è la politica di una piattaforma rispetto un altra. Altrimenti che senso ha fare due fasce hardware e poi adottare le identiche e precise mobo per entrambi cambiando solo la cpu ? Non ha senso, soprattutto dal punto di vista marketing.

[scrat1702]

è ovvio che usano frazioni :) il tuo thuban come fa scusa? e la freq base mi pare assodato che sia 200



il northbridge integrato, oltre ad aumentare un pochino l'ipc, ti fa costare meno le mobo, un solo chip invece di 2, mobo più semplici con meno bus...

per il socket, c'è gente che è fissata con la longevità della mobo, porta pazienza

a proposito di mobo non ho capito se si può parlare qui di am3+ o c'è una discussione apposita nel forum mobo?

Si anche i Lynnfield hanno moltiplicatori .5 nel turbo e negli C-State. Cosa che non ho notato nei SB.
Per il NB integrato, non mi pare che le mobo abbiano subito un calo del prezzo da quando qualcuno ha integrato in NB nelle CPU. Risparmiano loro ma non paghiamo sempre in pieno purtroppo.

[crazyduck00]

Si anche i Lynnfield hanno moltiplicatori .5 nel turbo e negli C-State. Cosa che non ho notato nei SB.
Per il NB integrato, non mi pare che le mobo abbiano subito un calo del prezzo da quando qualcuno ha integrato in NB nelle CPU. Risparmiano loro ma non paghiamo sempre in pieno purtroppo.

quoto, proprio perchè anche se ne aumenta la semplicità con l'integrazione del pci-e, i partner fanno marketing con soluzioni super cazzute giusto per aspirare qualke euro in piu. Anche se nella maggiorparte di volte come è sempre stato le soluzione top di gamma hanno VERAMENTE layout e reparti di alimentazioni da bava, e condensatori di qualità. E sono queste cose a far lievitare poi i prezzi. E diciamoci la verità, sono cose che poi ci fanno gola un po a tutti, in qualita di appassionati hardware.

[Pat77]

Il discorso principale invece sarebbe quantificare le potenzialità di BD X8

Appunto, tutto parte da qui, è la base di tutto, certo i soket col Plus non hanno mai avuto vita lunga, e penso che BD sia comunque un primo procio di una nuova serie, quindi con molte cose da scoprire e incognite.

[marchigiano]

Quoto su tutto tranne sul fatto dei prezzi. O meglio, forse andranno a costare di meno rispetto quelle attuali le mobo con qualche modello inferiore della famiglia hudson d4 (sempre enthusiast), ma non credo proprio che i modelli top di gamma dello stile crosshair, o msi, o gigabyte stile super overclocked caxxi e mazzi, con chip per oc genie, chip di qua chip di la, dissipatori per mosfet di qualita, reparti di alimentazione super cazzuti, ecc ecc avranno prezzi diversi dalle top di gamma attuali (990fx)

be ovvio.. il chipset costerà tipo 3 euro di meno, su una mobo da 40€ si sente, su una da 200 no

Si anche i Lynnfield hanno moltiplicatori .5 nel turbo e negli C-State. Cosa che non ho notato nei SB.
Per il NB integrato, non mi pare che le mobo abbiano subito un calo del prezzo da quando qualcuno ha integrato in NB nelle CPU. Risparmiano loro ma non paghiamo sempre in pieno purtroppo.

lynnfield e sandy a quanto ne so hanno i molti interi essendo i bus 133 e 100mhz

per il risparmio, di sicuro risparmiano più loro di noi, però attualmente ci sono mobo da 40€ entrambe le parti non ci si può lamentare. poi se incrementano gli utili meglio, avranno più soldi da investire in ricerca

[floydbarber]

quoto, proprio perchè anche se ne aumenta la semplicità con l'integrazione del pci-e, i partner fanno marketing con soluzioni super cazzute giusto per aspirare qualke euro in piu. Anche se nella maggiorparte di volte come è sempre stato le soluzione top di gamma hanno VERAMENTE layout e reparti di alimentazioni da bava, e condensatori di qualità. E sono queste cose a far lievitare poi i prezzi. E diciamoci la verità, sono cose che poi ci fanno gola un po a tutti, in qualita di appassionati hardware.

Sul fatto del risparmio non si può negare che poi all'utente finale ne deriva ben poco.
Due chip più semplici per uno più complicato però alla fine sul valore della scheda madre non influiscono gran che. Credo che l'integrazione sia più utile per miniaturizzare il tutto..
Poi il discorso sulle mobo da overclock non va neanche considerato. Lo sappiamo tutti che il mercato dei beni "di lusso" è l'unico che tiene

[scrat1702]

lynnfield e sandy a quanto ne so hanno i molti interi essendo i bus 133 e 100mhz


A meno che core temp non spari freq a casaccio non e cosi come dici tu ;) Aida invece mostra solo i molti interi, mantrese prendi core temp e segui un attimo vedrai che mostra anche moltiplicatori frazionati. Potrebbe benissimo essere un bug del programma.
Adesso sono fuori e son il portatile percio non posso controllare.

[gianni1879]

Io le sospensioni ad-minkiam non le capisco. :nono:

Che serve, una riforma della giustizia anche qui? :mbe:

eppure quando vi siete scritti in questo forum dovreste aver letto e sottoscritto il regolamento, inoltre di recente è anche stato aggiornato e quindi in teoria doveva essere riletto. Cosa che evidentemente sfugge a molti utenti, eppure basterebbe un minimo di buon senso ed educazione.

Ti invito ancora una volta a leggere il regolamento
http://www.hwupgrade.it/forum/regolamento.php

inoltre hai la firma irregolare, nel regolamento è scritto anche quello, ma evidentemente sfugge..

In ogni caso sei sospeso 3gg in virtù di essere andato contro il punto 5 del suddetto regolamento, inoltre al punto 6 è descritta la signature.
Sei pregato di editarla e di comunicarmelo via pvt, al momento sei sospeso a tempo indeterminato fino a quando non la regolarizzerai.

[D1o]

....

Facciamo questo esempio: il vero cambiamento per il socket FM2 cos'è? Avere l'NB integrato? Cacchio, 1-3 fp in più......



per i giochi non cambia tanto, ma per un sacco di applicazioni (HPC soprtattutto) avere un canale di accesso diretto con la ram fa tutta la differenza del mondo.

[marchigiano]

A meno che core temp non spari freq a casaccio non e cosi come dici tu ;) Aida invece mostra solo i molti interi, mantrese prendi core temp e segui un attimo vedrai che mostra anche moltiplicatori frazionati. Potrebbe benissimo essere un bug del programma.
Adesso sono fuori e son il portatile percio non posso controllare.

però nei bios amd puoi settare il molti anche mezze unità, nei bios intel solo interi... credo sia un errore di core temp

[bjt2]

Non credi però ci sia il rischio che BD X10 risulti eccessivamente grosso? Cioè 2 core in più, il northbridge, nuove istruzioni, e forse altra cache di sicuro si faranno sentire...

Arriverà a poco più di un thuban... Perfettamente giustificati date le prestazioni...

[blackshard]

però nei bios amd puoi settare il molti anche mezze unità, nei bios intel solo interi... credo sia un errore di core temp

Dai K10 in poi AMD non usa più il concetto classico di moltiplicatore, ma la famosa coppia FID/DID. Escono fuori moltiplicatori anche con quarto di punto, ottavo di punto (3.25x, 3.12x ...)
Con Llano puoi ottenere anche moltiplicatori periodici (8.666...) e con Zacate esistono solo i divisori... il mondo dei rapporti di frequenza AMD è davvero variopinto.

[Athlon 64 3000+]

Sinceramente non me lo aspettavo cosi grosso Zambezi nonostante nel modulo ci siano diverse logiche condivise.
Spero che l'FX-41xx e l'FX-61xx siano rispetto a Deneb e Thuban(sempre a parità di frequenza)decisamente più veloce e che le 2 versione x8 siano molto competitive.

[Athlon 64 3000+]

http://www.pcgameshardware.de/aid,840641/AMD-Bulldozer-FX-8150-als-Topmodell-neue-Folien-von-der-Hot-Chips-23-News-des-Tages/CPU/News/

Ci sono oltre le slide già postate anche delle nuove che prima non avevo visto.

[paolo.oliva2]

Sinceramente non me lo aspettavo cosi grosso Zambezi nonostante nel modulo ci siano diverse logiche condivise.
Spero che l'FX-41xx e l'FX-61xx siano rispetto a Deneb e Thuban(sempre a parità di frequenza)decisamente più veloce e che le 2 versione x8 siano molto competitive.

Ma io lo darei per scontato che siano più potenti, resta da vedere in che modo... cioè verificare con che margine per l'IPC, con che margine di frequenza e con che margine con entrambi.

Abbiano saputo che AMD da tempo aveva portato avanti soluzioni alternative al Phenom II, poi abbandonate. Quello che supporrei è che non siano state possibili per motivi commerciali, cioè che il costo progettazione/sviluppo/produzione non fosse conveniente.

A prescindere da tutto, visto che comunque anche il Phenom II è modulare (nel senso che gli interventi per aumentare i core sarebbero minimi) e Llano comunque deriva dal Phenom II, gli sforzi per creare Llano si sarebbero comunque potuti utilizzare per un Phenom II X6-X8-X10 ugualmente.

Quindi se AMD non ha fatto nulla su questo, mi sembra logico supporre che comunque BD assicurerebbe ad AMD guadagni maggiori perché comunque assicurerebbe una potenza finale maggiore.

Inoltre, Llano è stato commercializzato perché un Trinity avrebbe richiesto più tempo e che AMD faccia vedere AMPIAMENTE gli sviluppi basati su BD, vedi Trinity, Komodo, BD 2, BD Next generations, vuol dire a tutti gli effetti che i dubbi che ci assillano circa la potenza BD rimangono unicamente dubbi per lo più fondati da chi ha interesse a far credere ciò, più che su dati ben precisi.

Ti ricordi quando a gennaio comparì degli screen circa un BD X8 a 3,6GHz? Io sono stato l'unico a dire di non dare per certo che fosse un 125W ma di considerare possibile che fosse pure un 95W.
A distanza di 7 mesi cosa abbiamo? Un 95W X8 che arriva a 3,9GHz in Turbo, un 125W che arriva a 4,2GHz in turbo e di un 8170 X8 125W addirittura a 3,9GHz def.
Ora... posso capire che io sono ottimista... però se alla fine il mio ottimismo si traduce in realtà (se non addirittura lieve pessimismo), certamente altri che si definivano "realisti" in realtà erano pessimisti, no?

[crazyduck00]

A distanza di 7 mesi cosa abbiamo? Un 95W X8 che arriva a 3,9GHz in Turbo, un 125W che arriva a 4,2GHz in turbo e di un 8170 X8 125W addirittura a 3,9GHz def.


se per 95w x8 ti riferisci all'8120: in turbo fa 4ghz e no 3,9
e comunque i vecchi rumors lo davano per 95w, ma gli ultimi confermano rettificando che sia il modello 8120 che 8150 sono entrambi 125w

http://www.hwupgrade.it/forum/showpost.php?p=35747736&postcount=21057

[liberato87]

sono d'accordo con Paolo.. io dall inizio sono ottimista.
certo il ritardo ha fatto storcere il naso anche a me però da un lato penso pure che se BD avesse avuto bug incredibili oppure, come sostiene obr e la sua comunità di overclockers, tra B0 e B2 non cambia niente, le performance sono davvero scadenti, allora AMD avrebbe potuto tranquillamente cancellarlo! mica è costretta a farlo uscire lo stesso?

nel senso, se BD non fosse competitivo visto che gli viene a costare anche parecchio per via del die comunque di dimensioni generose ecc ecc allora perchè lo farebbero uscire?
a sto punto, visto che tutti dicono "tra 6 mesi esce il BD2 questo socket è morto" allora perchè se BD non fosse competitivo, non sarebbe meglio per amd puntare direttamente al nuovo socket e lasciare perdere?

per questi motivi, oltre al fatto che da differenze strutturali e di architettura (spiegate più e più volte dal buon bjt2) si presumono solo buone notizie, io sono molto fiducioso, e tra l altro le frequenze sono ben più alte di quello che personalmente mi aspettavo.

spero in un ottimo 4 o 6 core, ottimo overclock (magari un daily superiore ai 4,5ghz), che non consumi tantissimo e che renda molto nei game.
e poi personalmente punterei all ultimo step che uscirà del 8 core, per dare il colpo di grazia al socket am3+ e sfruttarlo fino alla fine.. senza considerare l overclock...

anyway, non vedo l ora che sia presentato così finalmente sapremo la verità e finiranno queste speculazioni

[capitan_crasy]

AMD conferma attraverso una sua slide ufficiale che le CPU socket AM3+ avranno i PIN sul socket più grandi delle CPU socket AM3:

http://www.xtremeshack.com/immagine/t106518_amd-hot-chips-23-19.jpg (http://www.xtremeshack.com/scheda/106518_amd-hot-chips-23-19.jpg.html)

Tale caratteristiche era già stata anticipata da Asrock con questa slide qualche mese fa:

http://www.pctunerup.com/up/results/_201104/th_20110422193955_am3_1.jpg

I PIN più grossi potrebbero rendere meccanicamente incompatibili le schede mamme socket AM3, anche se alcuni produttori come Asus e MSI hanno dichiarato che alcune delle loro schede mamme socket AM3 saranno comunque compatibili con le nuove CPU Bulldozer...

[DottorLeo]

http://www.pcgameshardware.de/aid,840641/AMD-Bulldozer-FX-8150-als-Topmodell-neue-Folien-von-der-Hot-Chips-23-News-des-Tages/CPU/News/

Ci sono oltre le slide già postate anche delle nuove che prima non avevo visto.

Se bjt2 (o chiunque conosca bene il lato tecnico di una CPU) è qua di passaggio potrebbe dirci se vi sono ulteriori informazioni deducibili da quelle slides che possano completare la sua precedente analisi fatta il a fine giugno?

Le sue analisi tecniche sono sempre così informative! :)

[crazyduck00]

sono d'accordo con Paolo.. io dall inizio sono ottimista.
certo il ritardo ha fatto storcere il naso anche a me però da un lato penso pure che se BD avesse avuto bug incredibili oppure, come sostiene obr e la sua comunità di overclockers, tra B0 e B2 non cambia niente, le performance sono davvero scadenti, allora AMD avrebbe potuto tranquillamente cancellarlo! mica è costretta a farlo uscire lo stesso?

nel senso, se BD non fosse competitivo visto che gli viene a costare anche parecchio per via del die comunque di dimensioni generose ecc ecc allora perchè lo farebbero uscire?
a sto punto, visto che tutti dicono "tra 6 mesi esce il BD2 questo socket è morto" allora perchè se BD non fosse competitivo, non sarebbe meglio per amd puntare direttamente al nuovo socket e lasciare perdere?

per questi motivi, oltre al fatto che da differenze strutturali e di architettura (spiegate più e più volte dal buon bjt2) si presumono solo buone notizie, io sono molto fiducioso, e tra l altro le frequenze sono ben più alte di quello che personalmente mi aspettavo.

spero in un ottimo 4 o 6 core, ottimo overclock (magari un daily superiore ai 4,5ghz), che non consumi tantissimo e che renda molto nei game.
e poi personalmente punterei all ultimo step che uscirà del 8 core, per dare il colpo di grazia al socket am3+ e sfruttarlo fino alla fine.. senza considerare l overclock...

anyway, non vedo l ora che sia presentato così finalmente sapremo la verità e finiranno queste speculazioni

impossibile non QUOTARE

[marchigiano]

Ti ricordi quando a gennaio comparì degli screen circa un BD X8 a 3,6GHz? Io sono stato l'unico a dire di non dare per certo che fosse un 125W ma di considerare possibile che fosse pure un 95W.
A distanza di 7 mesi cosa abbiamo? Un 95W X8 che arriva a 3,9GHz in Turbo, un 125W che arriva a 4,2GHz in turbo e di un 8170 X8 125W addirittura a 3,9GHz def.
Ora... posso capire che io sono ottimista... però se alla fine il mio ottimismo si traduce in realtà (se non addirittura lieve pessimismo), certamente altri che si definivano "realisti" in realtà erano pessimisti, no?

a distanza di 7 mesi abbiamo NIENTE mentre te davi per scontata l'uscita a aprile/maggio

8170, sempre che sia reale, è un passo successivo ancora deve uscire il primo figuriamoci... inoltre le frequenze turbo dovrebbero essere riferite al single-core non a tutti i core

[capitan_crasy]

a distanza di 7 mesi abbiamo NIENTE mentre te davi per scontata l'uscita a aprile/maggio

8170, sempre che sia reale, è un passo successivo ancora deve uscire il primo figuriamoci... inoltre le frequenze turbo dovrebbero essere riferite al single-core non a tutti i core


AMD ha sempre parlato di Turbo core su più core e mai a singolo core...
Sappiamo che Interlagos avrà un turbo su tutti i core e un altro sulla metà di essi; quindi come minimo dobbiamo aspettarci per Zambezi un turbo core di almeno 4 core o due moduli...

[Darkest Side]

Ho da poco scoperto questo thread..... avendo comprato da poco una scheda madre Am3+...ho scoperto ora per caso che sarà compatibile con questo nuovo processore.

Ero propenso a cambiare tutto per un sistema intel ma ora sono un pò più fiducioso...spero che arrivi presto e valga l'acquisto. Mi auguro veramente che AMD torni alla ribalta, con una CPU che tenga testa a intel a costi contenuti.

soprattutto che nel gaming faccia la differenza...come adesso la fà intel.

speriamo bene, spenderei sicuramente meno in una CPU bulldozer che nel cambiare MB,CPU,dissipatore etc etc....

[Wawacco]

AMD conferma attraverso una sua slide ufficiale che le CPU socket AM3+ avranno i PIN sul socket più grandi delle CPU socket AM3:

http://www.xtremeshack.com/immagine/t106518_amd-hot-chips-23-19.jpg (http://www.xtremeshack.com/scheda/106518_amd-hot-chips-23-19.jpg.html)

Tale caratteristiche era già stata anticipata da Asrock con questa slide qualche mese fa:

http://www.pctunerup.com/up/results/_201104/th_20110422193955_am3_1.jpg

I PIN più grossi potrebbero rendere meccanicamente incompatibili le schede mamme socket AM3, anche se alcuni produttori come Asus e MSI hanno dichiarato che alcune delle loro schede mamme socket AM3 saranno comunque compatibili con le nuove CPU Bulldozer...

Prevedo tante martellate sulla cpu per farla entrare :asd:

[Claudio-x64]

Toto-bench con Cinebench R11:

FX 8150 (125W) = 14.1
FX 8100 (95W) = 12.3
FX 6100 (95W) = 9.7
FX 4100 (95W) = 6.9

:asd: :asd:

[Efic]

Toto-bench con Cinebench R11:

FX 8150 (125W) = 14.1
FX 8100 (95W) = 12.3
FX 6100 (95W) = 9.7
FX 4100 (95W) = 6.9

:asd: :asd:

tanto ormai manca poco...

Io credo che il nuovo core andrà più forte del k10,amd di certo non investe miliardi per un prodotto più scadente tanto valeva un die shrink del phenom 2.

Poi ha già fatto 2 passi falsi uno con il core Agena e il secondo con la radeon 2900 xt (anche se qui in verità la colpa è della sola ati)... non credo che ci abbia preso gusto:rolleyes:

[The3DProgrammer]

Toto-bench con Cinebench R11:

FX 8150 (125W) = 14.1
FX 8100 (95W) = 12.3
FX 6100 (95W) = 9.7
FX 4100 (95W) = 6.9

:asd: :asd:

ci metterei la firma

[Pat77]

tanto ormai manca poco...

Io credo che il nuovo core andrà più forte del k10,amd di certo non investe miliardi per un prodotto più scadente tanto valeva un die shrink del phenom 2.

Poi ha già fatto 2 passi falsi uno con il core Agena e il secondo con la radeon 2900 xt (anche se qui in verità la colpa è della sola ati)... non credo che ci abbia preso gusto:rolleyes:

AMD poco centra con 2900xt, che comunque non era un passo falso, tant'è che è la base tecnologica anche delle schede attuali. Era troppo evoluta, tesseletor, ringbus a 512, aa via shaders...

Riguardo a K10 vedremo, lo scenario, a partire dal soket fino al ritardo è molto simile ad Agena, che soffrì anch'esso di una certa stitichezza di info.

[The3DProgrammer]

AMD poco centra con 2900xt, che comunque non era un passo falso, tant'è che è la base tecnologica anche delle schede attuali. Era troppo evoluta, tesseletor, ringbus a 512, aa via shaders...

Riguardo a K10 vedremo, lo scenario, a partire dal soket fino al ritardo è molto simile ad Agena, che soffrì anch'esso di una certa stitichezza di info.

appunto. Purtroppo tanti progetti di alto livello su carta non sempre si sono rivelati vincenti, anche se poi quasi sempre sono stati alla base di grandi prodotti in evoluzioni successive. Nessuno nega che BD sia eccezionale dal punto di vista architetturale, ma questa incertezza che va avanti da mesi mi preoccupa un po. Personalmente mi accontenterei che l'8150 fosse >= 2600k, ad un prezzo + competitivo. Se fosse cosi' amd avrebbe comunque un grosso potenziale per il futuro a breve medio termine su cui lavorare.

[Pat77]

appunto. Purtroppo tanti progetti di alto livello su carta non sempre si sono rivelati vincenti, anche se poi quasi sempre sono stati alla base di grandi prodotti in evoluzioni successive. Nessuno nega che BD sia eccezionale dal punto di vista architetturale, ma questa incertezza che va avanti da mesi mi preoccupa un po. Personalmente mi accontenterei che l'8150 fosse >= 2600k, ad un prezzo + competitivo. Se fosse cosi' amd avrebbe comunque un grosso potenziale per il futuro a breve medio termine su cui lavorare.

Se vuoi la mia, il treno è già passato. Bd lo vedo come la base per qualcosa di competitivo... poi i soket col plus non sono mai stati fortunati.

[jolly74]

Se vuoi la mia, il treno è già passato. Bd lo vedo come la base per qualcosa di competitivo... poi i soket col plus non sono mai stati fortunati.

Sgrat sgrat , toccatina di rigore ... speriamo che invece sia dalla sua prima incarnazione competitivo , anche perchè fine sett max ottobre vorrei rifarmi il PC , e volevo proprio ritornare in casa AMD :p

[Wawacco]

Personalmente mi accontenterei che l'8150 fosse >= 2600k, ad un prezzo + competitivo. Se fosse cosi' amd avrebbe comunque un grosso potenziale per il futuro a breve medio termine su cui lavorare.

Concordo, però credo che visto il periodo di uscita andrebbero più che altro confrontati con i SB-E, tanto in previsione cambi socket con ivy o cambi socket con FM2 sempre altri dindi toccherà tirar fuori :rolleyes:.

[AceGranger]

Concordo, però credo che visto il periodo di uscita andrebbero più che altro confrontati con i SB-E, tanto in previsione cambi socket con ivy o cambi socket con FM2 sempre altri dindi toccherà tirar fuori :rolleyes:.

:mbe: con ivy non cambierai socket, il 2011, essendo quello professionale, dovrebbe farsi tranquillamente tick e tock; IB-E avra socket 2011, (non si è mai vista una piattaforma professionale non farsi almeno tick e tock, la 1366 è durata 3 anni) e concorrera con BD 2.

[Efic]

Riguardo a K10 vedremo, lo scenario, a partire dal soket fino al ritardo è molto simile ad Agena, che soffrì anch'esso di una certa stitichezza di info.

uhm non credo...
i 65 nm amd facevano schifo anche con il core Brisbane che andava peggio del toledo a 90nm. Da qui i problemi con Agena vincolato con frequenze ridicole.(oltre ai bug:doh: )

Con i 32 nm non "dovrebbe" andare così male considerando che è rodato anche con le apu a8 e a6.
sono fiducioso:)

[Spitfire84]

uhm non credo...
i 65 nm amd facevano schifo anche con il core Brisbane che andava peggio del toledo a 90nm. Da qui i problemi con Agena vincolato con frequenze ridicole.(oltre ai bug:doh: )

Con i 32 nm non "dovrebbe" andare così male considerando che è rodato anche con le apu a8 e a6.
sono fiducioso:)

nuovo processo produttivo + nuova architettura, tutto insieme è un bel rischio, maggiore ad Agena a 65 nm. Questo non implica comunque che la ciambella riesca o meno con il buco. ;)

[blackshard]

uhm non credo...
i 65 nm amd facevano schifo anche con il core Brisbane che andava peggio del toledo a 90nm. Da qui i problemi con Agena vincolato con frequenze ridicole.(oltre ai bug:doh: )

Con i 32 nm non "dovrebbe" andare così male considerando che è rodato anche con le apu a8 e a6.
sono fiducioso:)

Rodato, imho però non con troppo successo a quanto pare.
I consumi delle apu a8 e a6 sono davvero poco incoraggianti.

[Sevenday]

Poco incoraggianti non mi sembra...
considerando che vanno paragonati ad altre APU in commercio. Non certo a semplici CPU...

[blackshard]

Poco incoraggianti non mi sembra...
considerando che vanno paragonati ad altre APU in commercio. Non certo a semplici CPU...

Sono poco incoraggianti credimi. Le altre "APU" in commercio (perchè sandy bridge è un'APU allo stesso modo di fusion, anzi forse pure di più visto che la parte GPU condivide una parte di cache con le unità esecutive CPU, cosa che sono certo avrebbe garantito un certo beneficio anche a llano) hanno consumi dimezzati e prestazioni mediamente simili, se non superiori.

AMD deve necessariamente potenziare l'aspetto single-threaded e massimizzare l'interazione fra gpu e cpu per avere qualcosa di realmente competitivo nel medio periodo e non accontentarsi delle briciole del breve periodo.

Io spero che bulldozer offra un IPC decisamente superiore in ambito single-threaded, ma temo che sotto questo aspetto rimarrò deluso. Temo di vedere di nuovo benchmark in multithreading pesante dove AMD compete e benchmark in single threading (giochi compresi) dove AMD è due generazioni indietro.

[paolo.oliva2]

a distanza di 7 mesi abbiamo NIENTE mentre te davi per scontata l'uscita a aprile/maggio

8170, sempre che sia reale, è un passo successivo ancora deve uscire il primo figuriamoci... inoltre le frequenze turbo dovrebbero essere riferite al single-core non a tutti i core

Dai Marchigiano... l'ho già spiegato più volte il perché io davo BD ad aprile.
Da un ES alla versione commerciale (SE DELLO STESSO STEP) quanto tempo passa? 1-2 mesi, vedi Thuban.

Ora, basandosi sul fatto che nessuno sulla terra poteva sapere che BD commerciale non era dello stesso step e che AMD dava l'uscita di BD1 nel 2Q 2011, mi sembrava perfettamente proponibile un BD pure ad aprile se non addirittura a marzo.

E' chiaro che se avessimo saputo che BD1 sarebbe stato commercializzato con uno step differente, nessuno ed io per primo avrebbe ipotizzato aprile.

Ricordati che qui nel forum chi dava la disponibilità a settembre non si basava assolutamente sullo step ma 60-90 giorni di tempo per la commercializzazione per tempi commerciali non ben precisati (tra l'altro se AMD commercializzerà BD1 a settembre come sembra, voglio vedere chi proverà ad avanzare l'assurda ipotesi che per lo stesso motivo li vedremo a gennaio 2012)

[paolo.oliva2]

Io suggerirei anche di riflettere su un altro punto, cioè sul fatto del brand FX AMD e di EE per Intel. Vediamo un po':

AMD Phenom I - Intel Core2 EE
AMD Phenom II X4 - Intel I7 X4 EE i7X6 EE
AMD Phenom II X6 - Intel i7 X6 EE

(premetto che Intel ancora commercializza i Core2 EE, ma ciò non vuole dire che l'offerta sia allettante per la clientela).

Il punto è... perché Intel non ha commercializzato SB come EE ed a prezzi da EE ma come K a prezzi di gran lunga più bassi? Perché Intel più volte ha detto che BD non va confrontato con gli i7 (X4 e X6) ma con SB?

Io non voglio con questo non voglio dire che BD sarà superiore a SB, ma di certo non trovo giustificato un così forte abbassamento prezzi (ed incassi) per il quale Intel non possa proporre un 2600K a 500€ e SB-e come EE.

In poche parole... in questa politica di prezzi di Intel, perlomeno a me sembra di vedere che sia la stessa Intel a prevedere potenze di BD tali da non giustificare prezzi da EE per versioni di SB.
Per spiegarmi meglio, un SB X6 tra IPC superiore e clock inferiore rispetto ad un i990X potrà proporre una potenza superiore si, ma abbastanza risicata. Mi sembra chiaro che se un BD X8 top di gamma potesse arrivare a potenze simili ad un i7 X6, nessuno sarebbe disposto per un 10% in più di potenza di SB rispetto ad un i7 X6 a spendere 3 volte di più...

Io la politica del listino Intel me la sono spiegata così... Se Intel stessa avesse la certezza che un BD X8 non arrivasse nemmeno ad un 2600K, non vedo il perché, visto la politica attuata da Intel negli ultimi anni, che lei sputi sopra a profitti ben ben più alti.

P.S.
Non ho l'intenzione, con questo post, né di confrontare prezzi tra le 2 case e tantomeno le potenze. L'ho scritto unicamente per portare una riflessione in più tra ottimismo-pessimismo, visto che comunque su Intel ne sappiamo molto di più di quanto trapela da AMD.

[paolo.oliva2]

Sono poco incoraggianti credimi. Le altre "APU" in commercio (perchè sandy bridge è un'APU allo stesso modo di fusion, anzi forse pure di più visto che la parte GPU condivide una parte di cache con le unità esecutive CPU, cosa che sono certo avrebbe garantito un certo beneficio anche a llano) hanno consumi dimezzati e prestazioni mediamente simili, se non superiori.

AMD deve necessariamente potenziare l'aspetto single-threaded e massimizzare l'interazione fra gpu e cpu per avere qualcosa di realmente competitivo nel medio periodo e non accontentarsi delle briciole del breve periodo.

Io spero che bulldozer offra un IPC decisamente superiore in ambito single-threaded, ma temo che sotto questo aspetto rimarrò deluso. Temo di vedere di nuovo benchmark in multithreading pesante dove AMD compete e benchmark in single threading (giochi compresi) dove AMD è due generazioni indietro.

Vedi... che BD debba avere una potenza superiore rispetto al Phenom è indubbio, ma la potenza di un procio non è data unicamente dall'IPC.

Ti faccio un esempio MOLTO pratico, addirittura dando per BD un IPC UGUALE al Phenom II:
Il Thuban a def raggiunge i 3,7GHz. BD dovrebbe raggiungere i 4,2-4,5GHz sempre a def.

Ora... un 20% di potenza in più la si avrebbe già con BD operativo a 4,440GHz, IPC o non IPC e questo in ambito ST.
Aggiungici il fatto che questo riguarderebbe unicamente l'ST, in quanto nell'MT in programmi tipo Cinebench il guadagno di un procio AMD è perfettamente lineare rispetto all'incremento dei core, e passare a X8 rispetto ad un X6 significherebbe +33% a parità di frequenza.

Quello che ti voglio dire, è che non è strettamente importante che BD arrivi all'IPC di un SB, perché comunque da parte sua avrebbe una frequenza maggiore oltre ad avere anche 2 core in più se non 4 con Komodo.
Il gioco al più rimarrebbe aperto quando Intel produrrà SB sul 22nm, in quanto probabilmente Intel potrà proporre frequenze superiori a quelle di SB sul 32nm.

Vedi... io sono molto più contento di avere informazioni (non ufficiali) di un BD X8 sui 300$ ed incognite sulla potenza piuttosto che sapere di un BD X8 FX a prezzi da FX (800-1000$) senza sapere nulla sulla potenza, perché comunque a quella cifra non lo acquisterei nemmeno se andasse il doppio di un SB-e X6, non so se mi capisci. Io al momento preferisco comunque aspettarmi incrementi anche solo del 20% di IPC accompagnati da 2 core in più e da frequenze più alte che comunque mi garantirebbero un prezzo/prestazioni più che soddisfacente.... Io mi tengo abbastanza certo che non sia di meno... se poi sarà di più... ben venga.

[marchigiano]

Il punto è... perché Intel non ha commercializzato SB come EE ed a prezzi da EE ma come K a prezzi di gran lunga più bassi? Perché Intel più volte ha detto che BD non va confrontato con gli i7 (X4 e X6) ma con SB?

perchè 1155 è una piattaforma mainstream limitata a 95w e neanche con lynnfield si sono mai viste cpu da 1000€, anche perchè altrimenti a quanto dovrebbero vendere le cpu 2011?

Io la politica del listino Intel me la sono spiegata così... Se Intel stessa avesse la certezza che un BD X8 non arrivasse nemmeno ad un 2600K, non vedo il perché, visto la politica attuata da Intel negli ultimi anni, che lei sputi sopra a profitti ben ben più alti.

perchè già ci straguadagna così essendo un die da 216mm contro i 298 del lynnfield

[calabar]

Io spero che bulldozer offra un IPC decisamente superiore in ambito single-threaded, ma temo che sotto questo aspetto rimarrò deluso. Temo di vedere di nuovo benchmark in multithreading pesante dove AMD compete e benchmark in single threading (giochi compresi) dove AMD è due generazioni indietro.
Ne ha decisamente bisogno, ma secondo me ci sono le premesse perchè possa dire la sua in ambito single thread.
Al di la delle migliorie generali, il nuovo turbo in questo senso dovrebbe dare ottimi risultati, così come ha fatto con la generazione nehalem per intel.
Per di più, se in un modulo BD la logica condivisa fa calare le prestazioni in multithread rispetto a due core completi (il famoso 80% dichiarato da amd), in single thread il solo core servito avrà una logica e un throughput sovrabbondante rispetto ad un core completo, tanto che potrebbe dargli una spintina in più, superando le prestazioni del core completo.

Il punto è... perché Intel non ha commercializzato SB come EE ed a prezzi da EE ma come K a prezzi di gran lunga più bassi? Perché Intel più volte ha detto che BD non va confrontato con gli i7 (X4 e X6) ma con SB?
La risposta a queste domande è semplice.
SB EE semplicemente non è ancora uscito, gli attuali SB sono quelli di fascia mainstream , gli SB "pesanti" usciranno tra qualche mese e si chiameranno SB-E.
Vista l'attuale situazione, Intel si è potuta permettere di far uscire prima la fascia mainstream, che vende di più, e lasciare in fascia alta la vecchia generazione, che comunque la concorrenza non era in grado di raggiungere, mantenendo quindi il podio.
BD va confrontato con SB semplicemente perchè fanno parte della stessa "generazione". Del resto nehalem ha ormai tre anni, non pochi in ambito informatico.
Tutto qui.

[digieffe]

...cut

Ti faccio un esempio MOLTO pratico, addirittura dando per BD un IPC UGUALE al Phenom II:
Il Thuban a def raggiunge i 3,7GHz. BD dovrebbe raggiungere i 4,2-4,5GHz sempre a def.

Ora... un 20% di potenza in più la si avrebbe già con BD operativo a 4,440GHz, IPC o non IPC e questo in ambito ST.
Aggiungici il fatto che questo riguarderebbe unicamente l'ST, in quanto nell'MT in programmi tipo Cinebench il guadagno di un procio AMD è perfettamente lineare rispetto all'incremento dei core, e passare a X8 rispetto ad un X6 significherebbe +33% a parità di frequenza.

...cut

per stare al tuo esempio preciso alcuni dettagli:

Phenom II 1100T in ST 3,7 ... Fx 8150 ST 4,2 (+13%) ... Fx 8170 ST 4,5 (+21%)
Phenom II 1100T in MT 3,3 ... Fx 8150 MT no turbo* 3,6 (+9%) ... Fx 8170 MT no turbo* 3,9 (+18%) -> solo differenza di freq.

*non conosco la freq. di turbo1 di questi processori.

il resto dipende dall'ipc e dal throughput.

Ps:
data la struttura a cluster di BD, ipotizando un ipc uguale in ST con il Thuban, non credo affatto che l'8 core dia +33% rispetto al Thuban, in quanto ogni cluster avrà un throughput inferiore a 2 core Thuban (alla condizione specificata -> uguale ipc)
es: ipotizzando che non ci siano perdite di scalabilità tra l'ipc ed il throughput (alla stessa condizione di prima) abbiamo
Thuban ipc x 6, BD ipc x 8 x efficienza cluster -> (ponendo ipc=1) Thuban 6, BD 8 x 90% = 7,2 (+20%) e non 8 (+33%).

EDIT: il 90% è solo a titolo indicativo qualora fosse più basso...

[Matalf]

Io suggerirei anche di riflettere su un altro punto, cioè sul fatto del brand FX AMD e di EE per Intel. Vediamo un po':

AMD Phenom I - Intel Core2 EE
AMD Phenom II X4 - Intel I7 X4 EE i7X6 EE
AMD Phenom II X6 - Intel i7 X6 EE

(premetto che Intel ancora commercializza i Core2 EE, ma ciò non vuole dire che l'offerta sia allettante per la clientela).

Il punto è... perché Intel non ha commercializzato SB come EE ed a prezzi da EE ma come K a prezzi di gran lunga più bassi? Perché Intel più volte ha detto che BD non va confrontato con gli i7 (X4 e X6) ma con SB?

Io non voglio con questo non voglio dire che BD sarà superiore a SB, ma di certo non trovo giustificato un così forte abbassamento prezzi (ed incassi) per il quale Intel non possa proporre un 2600K a 500€ e SB-e come EE.

In poche parole... in questa politica di prezzi di Intel, perlomeno a me sembra di vedere che sia la stessa Intel a prevedere potenze di BD tali da non giustificare prezzi da EE per versioni di SB.
Per spiegarmi meglio, un SB X6 tra IPC superiore e clock inferiore rispetto ad un i990X potrà proporre una potenza superiore si, ma abbastanza risicata. Mi sembra chiaro che se un BD X8 top di gamma potesse arrivare a potenze simili ad un i7 X6, nessuno sarebbe disposto per un 10% in più di potenza di SB rispetto ad un i7 X6 a spendere 3 volte di più...

Io la politica del listino Intel me la sono spiegata così... Se Intel stessa avesse la certezza che un BD X8 non arrivasse nemmeno ad un 2600K, non vedo il perché, visto la politica attuata da Intel negli ultimi anni, che lei sputi sopra a profitti ben ben più alti.

P.S.
Non ho l'intenzione, con questo post, né di confrontare prezzi tra le 2 case e tantomeno le potenze. L'ho scritto unicamente per portare una riflessione in più tra ottimismo-pessimismo, visto che comunque su Intel ne sappiamo molto di più di quanto trapela da AMD.

A me sembra fantascenza questa riflessione....

avessimo anche un incremento netto del 50% di prestazioni dal 1090T un ipotetico BDx8 a pari frequenza andrebbe comunque a rivaleggiare con il 2600k, la mancanza della sigla EE ed da interpretare solo come posizionamento di mercato, anche sul 1056 manca la nomenclatura EE ma nessuno se ne fa un dramma visto che non è un socket fascia alta, men che meno pensato per i server...

[digieffe]

LOL ma copiate i commenti che ci sono su SA?! :asd: (sto scherzando, eh! non state a prendervela, che non ho alcun intento polemico ;) )

battute a parte...mi spiegate dove sta il problema di questi (immensi) 315mm^2?

partendo dal considerare che un thuban è su 346mm^2, facendo poi dei conti spanning (cioè a spanne, senza alcuna pretesa scientifica, eh...), facendo finta di fare un thuban a 8c su sti benedetti 32nm:
thuban 6c 45nm 346mm^2 -> 8c 45nm 346x8/6=461mm^2
45nm -> 32nm 461x32/45=328mm^2
per confronto gulftown 6c 32nm è su 240mm^2 (8c diventerebbero 320mm^2, quindi siamo lì...)

tutto sommato, non mi pare che 315mm^2 siano chissà che eresia...il punto sta nel fatto che prestazionalmente ed economicamente siano competitivi, ma per vedere questo basta avere ancora un po' di pazienza...

I conti mi sembrano tutti giusti ma:
...cut
anche se arrivo un pò tardi i conti sono sbagliati (c'è un passaggio errato):
45nm -> 32nm 461x32/45=328mm^2
45nm -> 32nm 461x(32^2)/(45^2)=230mm^2
quindi BD sarebbe circa 1,37 volte un thuban 8 core (spannometricamente)
è da tener conto che BD avrebbe 4MB di cache l2 in più rispetto a Thuban, non so quanto possa occupare...

[blackshard]

Vedi... che BD debba avere una potenza superiore rispetto al Phenom è indubbio, ma la potenza di un procio non è data unicamente dall'IPC.

Ti faccio un esempio MOLTO pratico, addirittura dando per BD un IPC UGUALE al Phenom II:
Il Thuban a def raggiunge i 3,7GHz. BD dovrebbe raggiungere i 4,2-4,5GHz sempre a def.

Ora... un 20% di potenza in più la si avrebbe già con BD operativo a 4,440GHz, IPC o non IPC e questo in ambito ST.
Aggiungici il fatto che questo riguarderebbe unicamente l'ST, in quanto nell'MT in programmi tipo Cinebench il guadagno di un procio AMD è perfettamente lineare rispetto all'incremento dei core, e passare a X8 rispetto ad un X6 significherebbe +33% a parità di frequenza.

Quello che ti voglio dire, è che non è strettamente importante che BD arrivi all'IPC di un SB, perché comunque da parte sua avrebbe una frequenza maggiore oltre ad avere anche 2 core in più se non 4 con Komodo.
Il gioco al più rimarrebbe aperto quando Intel produrrà SB sul 22nm, in quanto probabilmente Intel potrà proporre frequenze superiori a quelle di SB sul 32nm.

Vedi... io sono molto più contento di avere informazioni (non ufficiali) di un BD X8 sui 300$ ed incognite sulla potenza piuttosto che sapere di un BD X8 FX a prezzi da FX (800-1000$) senza sapere nulla sulla potenza, perché comunque a quella cifra non lo acquisterei nemmeno se andasse il doppio di un SB-e X6, non so se mi capisci. Io al momento preferisco comunque aspettarmi incrementi anche solo del 20% di IPC accompagnati da 2 core in più e da frequenze più alte che comunque mi garantirebbero un prezzo/prestazioni più che soddisfacente.... Io mi tengo abbastanza certo che non sia di meno... se poi sarà di più... ben venga.

Allora, togliendo il discorso prezzo di mercato che non lo voglio fare, l'IPC serve e subito.
Il turbo è un bello specchietto per le allodole, ma NON è una soluzione definitiva perchè con lo scheduler di windows che fa saltare i processi da un core all'altro ne vanifica in gran parte l'efficacia.
Al contrario, IPC migliore sono prestazioni pure migliori.

Cosa succede nella realtà: due core della concorrenza + hyperthreading hanno performance paragonabili a tre/quattro core degli attuali K10. Ma ciò non va bene, perchè 4 core di AMD consumano un buon 50% in più di due core + hyperthreading.

Ripeto che, se si confrontano i consumi delle APU, questi sono davvero impietosi e sono un monito d'allarme per i 32nm di AMD. Una cosa che fa ben sperare sono gli interessanti margini in downvolt che si possono ottenere, ma attualmente la situazione sul mercato è che i nuovi chip AMD hanno TDP da 100 watt e performance per core di due generazioni indietro.

Questo grafico a me non va' proprio giù:

http://images.anandtech.com/graphs/graph4524/40753.png

e se la differenza fra i3-2100 e a8-3850 non sembra essere troppa, bisogna anche considerare che l'i3 è decisamente più performante in diversi task.

Ne ha decisamente bisogno, ma secondo me ci sono le premesse perchè possa dire la sua in ambito single thread.
Al di la delle migliorie generali, il nuovo turbo in questo senso dovrebbe dare ottimi risultati, così come ha fatto con la generazione nehalem per intel.
Per di più, se in un modulo BD la logica condivisa fa calare le prestazioni in multithread rispetto a due core completi (il famoso 80% dichiarato da amd), in single thread il solo core servito avrà una logica e un throughput sovrabbondante rispetto ad un core completo, tanto che potrebbe dargli una spintina in più, superando le prestazioni del core completo.

Guarda io vedo solo che il turbo su thuban non ha reso quello che doveva rendere. Quindi o il collo di bottiglia è altrove (tipo cache non sufficientemente veloci per stare dietro ad un core a 3.7 ghz) oppure semplicemente il turbo core non funziona a dovere, vuoi per una implementazione posticcia, vuoi per lo scheduler di windows, vuoi per altri motivi.

Sono proprio curioso di vedere come si comporterà il turbo core 2.0, però ripeto che non serve a niente avere un core a 5 ghz se poi non lo riesci a rifornire adeguatamente.

Molto interessante è questa prova di overclock/downvolt recensita qui:

http://www.zimbio.com/Laptop+Reviews/articles/y_IUcPJgudd/AMD+APU+A8+3850+Overclocked+Undervolted

In particolare nel caso del downvolt si riduce il consumo del sistema di ben 70 watt alla presa, che netti dell'efficienza dell'alimentatore e del VRM credo siano un buon 50 watt tolti al solo processore. Questo mi fa ben sperare.

[digieffe]

dalla immagine di semiaccurate ho ricavato le seguenti misure:

dimensioni del die: largh 20mm, alt. 15.76, area 315.24
dimensioni del modulo: largh 5.04, alt. 4.27, area 21.55
dimensioni del cache L2: largh 3.29, alt. 3.54, area 11.65

calcolerò anche la cache l3....

riuscite a confrontare questi valori con deneb/thuban/sb?

Ps:chiaro che ci possono essere degli errori trascurabili per via della misurazione in pixel

[Wawacco]

:mbe: con ivy non cambierai socket, il 2011, essendo quello professionale, dovrebbe farsi tranquillamente tick e tock; IB-E avra socket 2011, (non si è mai vista una piattaforma professionale non farsi almeno tick e tock, la 1366 è durata 3 anni) e concorrera con BD 2.

Mi sembra ovvio che parlando di ivy comparato al BD2 su FM2 intendevo su socket 2011 ;)

[gi0v3]

non so se er agià stato postato, xt review conferma i clock per fx-8120 e fx-8150

http://xtreview.com/images/FX-8150%20and%20FX-8120.jpg

http://xtreview.com/addcomment-id-18003-view-FX-8150-and-FX-8120-stepping-B2.html

quindi
8120->3,1/4,0 ghz
8150->3,6/4,2 ghz

si è poi capito se il secondo clock è quello che ci dice il massimo clock raggiungibile su tutti i core o il massimo turbo su 4 core soli?

[FroZen]

Ripeto che, se si confrontano i consumi delle APU, questi sono davvero impietosi e sono un monito d'allarme per i 32nm di AMD. Una cosa che fa ben sperare sono gli interessanti margini in downvolt che si possono ottenere, ma attualmente la situazione sul mercato è che i nuovi chip AMD hanno TDP da 100 watt e performance per core di due generazioni indietro.

Questo grafico a me non va' proprio giù:

http://images.anandtech.com/graphs/graph4524/40753.png

e se la differenza fra i3-2100 e a8-3850 non sembra essere troppa, bisogna anche considerare che l'i3 è decisamente più performante in diversi task.



Guarda io vedo solo che il turbo su thuban non ha reso quello che doveva rendere. Quindi o il collo di bottiglia è altrove (tipo cache non sufficientemente veloci per stare dietro ad un core a 3.7 ghz) oppure semplicemente il turbo core non funziona a dovere, vuoi per una implementazione posticcia, vuoi per lo scheduler di windows, vuoi per altri motivi.

Sono proprio curioso di vedere come si comporterà il turbo core 2.0, però ripeto che non serve a niente avere un core a 5 ghz se poi non lo riesci a rifornire adeguatamente.

Molto interessante è questa prova di overclock/downvolt recensita qui:

http://www.zimbio.com/Laptop+Reviews/articles/y_IUcPJgudd/AMD+APU+A8+3850+Overclocked+Undervolted

In particolare nel caso del downvolt si riduce il consumo del sistema di ben 70 watt alla presa, che netti dell'efficienza dell'alimentatore e del VRM credo siano un buon 50 watt tolti al solo processore. Questo mi fa ben sperare.

Stavo per scriverti che c'è gente qui che fa andare il 3850@def a 1,15V dai 1,4V originali :read: e hai una vera APU, l'i3 arrossisce.......al di là del HT che mah non mi convince molto......sono anche io per il "real men uses real cores" :D

Certo è incredibile come si possa passare da 1,4 a 1,15V con tanta scioltezza.....o che in AMD abbiano avuto poco tempo per consolidare gli stress test e abbiano pompato voltaggi che alla luce di quanto sopra sono realmente TROPPO alti per avere margini di sicurezza decenti, avendo comunque un consumo buono per una APU....speriamo che con FX li facciano uscire con voltaggi più attinenti, ma non ci sarà alcun problema a downvoltare pure loro......certo che se arrivano a 4,2 sui 4 core gli servirà corrente....

[The3DProgrammer]

Ne ha decisamente bisogno, ma secondo me ci sono le premesse perchè possa dire la sua in ambito single thread.
Al di la delle migliorie generali, il nuovo turbo in questo senso dovrebbe dare ottimi risultati, così come ha fatto con la generazione nehalem per intel.
Per di più, se in un modulo BD la logica condivisa fa calare le prestazioni in multithread rispetto a due core completi (il famoso 80% dichiarato da amd), in single thread il solo core servito avrà una logica e un throughput sovrabbondante rispetto ad un core completo, tanto che potrebbe dargli una spintina in più, superando le prestazioni del core completo.


In realta' non è cosi' e non puo' esserlo, purtroppo. Che sia single thread o multithread, ogni cluster int ha 2 ALU e 2 AGU e lo scheduler int (che non è condiviso) puo' schedulare massimo 4 op per ciclo di clock (una a pipeline). Di conseguenza, in single thread il throughtput massimo di BD è di 2 istruzioni per ciclo di clock, e non puo' essere maggiore di questa soglia. In MT, presumibilmente il throughput medio si abbassa a causa della logica condivisa che di fatto, limita le performance dei cluster int.


La risposta a queste domande è semplice.
SB EE semplicemente non è ancora uscito, gli attuali SB sono quelli di fascia mainstream , gli SB "pesanti" usciranno tra qualche mese e si chiameranno SB-E.
Vista l'attuale situazione, Intel si è potuta permettere di far uscire prima la fascia mainstream, che vende di più, e lasciare in fascia alta la vecchia generazione, che comunque la concorrenza non era in grado di raggiungere, mantenendo quindi il podio.
BD va confrontato con SB semplicemente perchè fanno parte della stessa "generazione". Del resto nehalem ha ormai tre anni, non pochi in ambito informatico.
Tutto qui.

secondo me la situazione ruota tutta intorno alle performance di BD in ST. Se in questa situazione BD sara' in grado, a parita' di clock, di mantenersi ai livelli di SB (diciamo in un range di + o - 5%) allora AMD potra' giocarsela, magari non subito ma sicuramente molto presto, con le soluzioni intel top di gamma. Se la differenza in ST dovesse essere + marcata (diciamo 15/20% a favore di SB) AMD potrebbe ancora essere competitiva puntando tutto sulle frequenze di clock, ma gia' questa non sarebbe una bella situazione perchè significherebbe dover tirare il collo a BD, con tutti gli svantaggi in termini di potenza dissipata conseguenti. Se la differenza dovesse essere ancora maggiore (ma onestamente dubito che possa essere cosi') allora sarebbe un fail e bisognerebbe attendere BD2 per avere qualcosa di veramente competitivo.

[Ares17]

In realta' non è cosi' e non puo' esserlo, purtroppo. Che sia single thread o multithread, ogni cluster int ha 2 ALU e 2 AGU e lo scheduler int (che non è condiviso) puo' schedulare massimo 4 op per ciclo di clock (una a pipeline). Di conseguenza, in single thread il throughtput massimo di BD è di 2 istruzioni per ciclo di clock, e non puo' essere maggiore di questa soglia. In MT, presumibilmente il throughput medio si abbassa a causa della logica condivisa che di fatto, limita le performance dei cluster int.




Tutto giusto con prefech identico a thuban (il famoso scemo + scemo di BJT2 :D ).

[Spitfire84]

non so se er agià stato postato, xt review conferma i clock per fx-8120 e fx-8150

http://xtreview.com/images/FX-8150%20and%20FX-8120.jpg

http://xtreview.com/addcomment-id-18003-view-FX-8150-and-FX-8120-stepping-B2.html

quindi
8120->3,1/4,0 ghz
8150->3,6/4,2 ghz

si è poi capito se il secondo clock è quello che ci dice il massimo clock raggiungibile su tutti i core o il massimo turbo su 4 core soli?

è un copia incolla dal blog di obr..certo che pubblicare una immagine di cpu-z con scritto sopra "crap is coming..." :doh:

[The3DProgrammer]

Perhaps everyone should consider that AMD did not release these benchmarks and they might not even be real. Nothing I have seen, to date, has been representational of actual performance.


post di JFAMD su XS

[calabar]

Il turbo è un bello specchietto per le allodole [...]
Guarda io vedo solo che il turbo su thuban non ha reso quello che doveva rendere. [...]
A me sembra che il turbo, a livello generale, funzioni abbastanza bene.
Persino quello di thuban, che per esempio nei giochi compete grazie ad esso con i phenom quad core a frequenza più spinta.
Nei nehalmen poi hanno portato un miglioramento davvero notevole (prova a cercare qualche recensione con e senza turbo attivo).
A questo punto non vedo perchè su BD il turbo debba essere inefficace. Quello di Thuban era un pezza per portarlo ad essere più competitivo nelle applicazioni che fanno uso di pochi thread a causa dell'elevato numero di core, ma in BD diventa una funzionalità con un altro livello di integrazione.

Su una cosa però sicuramente hai ragione: il turbo da solo non basta.
E fortunatamente, come dicevo sopra, è solo una delle carte che questo BD è in grado di giocare sul single thread.
Oltretutto con un ipc basso non c'è turbo che tenga: all'aumentare della frequenza il gap tra un processore con ipc elevato e uno con ipc più basso non fa altro che aumentare, per colmare questo gap con la frequenza bisogna raggiungere frequenze che, nonostante un progetto mirato i questo senso, diventano comunque troppo elevate per essere raggiunte.
Per capirci, se ho un prodotto con ipc=6 (numero a caso) a 4ghz, per raggiungere lo stesso risultato con un prodotto con ipc=4 devo raggiungere i 6ghz, traguardo a mio parere un po' troppo elevato da raggiungere (tenendo poi conto che anche il prodotto concorrente si clocca bene).

Morale della favola, serve in ogni caso una base consistente, o non c'è turbo ne frequenze alte che tengano.

data la struttura a cluster di BD, ipotizando un ipc uguale in ST con il Thuban, non credo affatto che l'8 core dia +33% rispetto al Thuban, in quanto ogni cluster avrà un throughput inferiore a 2 core Thuban (alla condizione specificata -> uguale ipc)
Esattamente. Vista la struttura di BD, un ipc in single core identico a thuban sarebbe a dir poco tragico.
Significherebbe che sfruttando tutti i core avremo il famoso calo all'80% dichiarato da AMD per la logica condivisa: BD rischierebbe di essere solo leggermente più veloce di thuban in multicore, ma con due core in più!

In realta' non è cosi' e non puo' esserlo, purtroppo. Che sia single thread o multithread, ogni cluster int ha 2 ALU e 2 AGU e lo scheduler int (che non è condiviso) puo' schedulare massimo 4 op per ciclo di clock (una a pipeline). Di conseguenza, in single thread il throughtput massimo di BD è di 2 istruzioni per ciclo di clock, e non puo' essere maggiore di questa soglia. In MT, presumibilmente il throughput medio si abbassa a causa della logica condivisa che di fatto, limita le performance dei cluster int.
Al di la dei particolari tecnici (per cui mi piacerebbe sentire anche qualche altra voce informata, per confronto), il discorso non mi torna affatto. Significherebbe che la logica condivisa non fa mai da collo di bottiglia in single thread, neanche nelle situazioni limite, e questo mi pare senza senso, perchè significa aver fatto una logica troppo castrata per servire due core, se poi tale sovrabbondanza non porta alcun seppur piccolo vantaggio quando il core utilizzato è uno solo. Vantaggio rispetto ad una logica studiata per un solo core in un approccio tradizionale, intendo.

[The3DProgrammer]

Al di la dei particolari tecnici (per cui mi piacerebbe sentire anche qualche altra voce informata, per confronto), il discorso non mi torna affatto. Significherebbe che la logica condivisa non fa mai da collo di bottiglia in single thread, neanche nelle situazioni limite, e questo mi pare senza senso, perchè significa aver fatto una logica troppo castrata per servire due core, se poi tale sovrabbondanza non porta alcun seppur piccolo vantaggio quando il core utilizzato è uno solo. Vantaggio rispetto ad una logica studiata per un solo core in un approccio tradizionale, intendo.

Ma guarda che l'approccio di BD è tradizionalissimo eh. Potresti tranquillamente togliere il cluster int e la logica aggiunta per gestirlo (che fondamentalmente sono la fetch window e poco altro) ed avere comunque un design 4 way perfettamente bilanciato (4 decoder servono 8 unita di esecuzione, 4 int e 4 FP). Rispetto a questa ipotetica configurazione, l'aggiunta del secondo cluster int comporta una penalita' delle prestazioni (chiaramente intuibile, visto che ora 4 decoder servono 12 unita' di esecuzione invece di 8) quantificabile, secondo AMD, nel 20%. Non vedo come possa esserci un boost nel ST dato dal non utilizzare il secondo cluster int. Il colpaccio ci sarebbe stato se avessro trovato un modo di riutilizzare le ALU del secondo cluster int in ST, rendendo di fatto un modulo un mega cluster int in situazioni ST...

[calabar]

La logica aggiunta per gestire il secondo cluster int non da alcun vantaggio prestazionale quando non utilizzata.
Dovrebbe invece, dato che è condivisa, quindi in grado di servire entrambi i core. Nei casi limite ovviamente (in cui la logica fa da collo di bottiglia), dando quindi un piccolo aiuto, ma pur sempre un aiuto.

Per "approccio tradizionale" intendo naturalmente quello utilizzato finora con i phenom o i processori intel: non un modulo con due core e logica condivisa, ma un singolo core con la sua logica.

[The3DProgrammer]

Dovrebbe invece, dato che è condivisa, quindi in grado di servire entrambi i core. Nei casi limite ovviamente, dando quindi un piccolo aiuto, ma pur sempre un aiuto.

Per "approccio tradizionale" intendo naturalmente quello utilizzato finora con i phenom o i processori intel: non un modulo con due core e logica condivisa, ma un singolo core con la sua logica.

ho editato il post precedente per errore invece di farne uno nuovo :stordita: rileggi quello sopra per la risposta :D

[digieffe]

In realta' non è cosi' e non puo' esserlo, purtroppo. Che sia single thread o multithread, ogni cluster int ha 2 ALU e 2 AGU e lo scheduler int (che non è condiviso) puo' schedulare massimo 4 op per ciclo di clock (una a pipeline). Di conseguenza, in single thread il throughtput massimo di BD è di 2 istruzioni per ciclo di clock, e non puo' essere maggiore di questa soglia. In MT, presumibilmente il throughput medio si abbassa a causa della logica condivisa che di fatto, limita le performance dei cluster int.

..cut
A questo punto si dovrebbe supporre che l'ipc dei phenomII (con 3 pipeline int+agu e scheduler scemo+scemo) sia abbastanza inferiore a 2:
per poter avere BD un incremento del 20% di ipc, il PhenomII dovrebbe avere un ipc di 1.67... (1.67+20%=2) ?!? possibile così basso?

nessuno conosce l'ipc del PhenomII? (es nelle schede Amd/Ati serie 5870 l'ipc è di 3,4 su 5 unità,ma parliamo di una architettura vliw asimmetrica e non centra nulla, era solo per far capire che a volte si conoscono questi dati)

[calabar]

Il boost, seppure limitato, dovrebbe esserci proprio perchè se hanno calcolato che il decoder è sufficiente per gestire 2 core con una perdita di prestazioni contenuto, allora dovrebbe risultare almeno un po' "abbondante" per un solo core.
Se cioè avessero fatto un modulo con un singolo core, presumibilmente avrebbero bilanciato la minore capacità di calcolo con un decoder più limitato (se non sbaglio quello del k10 riesce a processare una istruzione in meno, infatti), perchè sarebbe inutile sprecare tanti transistor in una logica usata poi solo in casi estremi.
Ma se questa logica già c'è per servire un secondo core, allora tanto di guadagnato.

Sul fatto che il colpaccio sarebbe riuscire ad utilizzare le unità del secondo core sono d'accordo, ma se ne era già discusso, e al di la della difficoltà tecnica, mi pare non fosse tanto conveniente per due motivi:
- un'unità int difficilmente sfrutta più di tre pipeline, quindi non si avrebbe certo un raddoppio di prestazioni, ma un boost limitato.
- non potresti mettere a riposo il secondo core, avendo quindi consumi elevati che renderebbero impossibile l'uso del turbo core. In tal caso, si avrebbero più vantaggi dalla "fusione" o dall'aumento di frequenza?

[capitan_crasy]

non so se er agià stato postato, xt review conferma i clock per fx-8120 e fx-8150

http://xtreview.com/images/FX-8150%20and%20FX-8120.jpg

http://xtreview.com/addcomment-id-18003-view-FX-8150-and-FX-8120-stepping-B2.html

quindi
8120->3,1/4,0 ghz
8150->3,6/4,2 ghz

si è poi capito se il secondo clock è quello che ci dice il massimo clock raggiungibile su tutti i core o il massimo turbo su 4 core soli?

Lo chiedo a tutti:
Basta postare, una volta per tutte le porcate provenienti da quel mentecatto di Obrovsky: nel forum di xtremesystems.org sono stati bandite qualsiasi cosa che riguarda o prevenga da questo individuo...

[The3DProgrammer]

A questo punto si dovrebbe supporre che l'ipc dei phenomII (con 3 pipeline int+agu e scheduler scemo+scemo) sia abbastanza inferiore a 2:
per poter avere BD un incremento del 20% di ipc, il PhenomII dovrebbe avere un ipc di 1.67... (1.67+20%=2) ?!? possibile così basso?

nessuno conosce l'ipc del PhenomII? (es nelle schede Amd/Ati serie 5870 l'ipc è di 3,4 su 5 unità,ma parliamo di una architettura vliw asimmetrica e non centra nulla, era solo per far capire che a volte si conoscono questi dati)

occhio che io parlavo di throughput massimo TEORICO del solo cluster INT. sempre in questo caso, quello di phenom II e' anche maggiore di BD (dato che un core K10 dispone di 6 unita' int per core, 3 ALU e 3 AGU). La realta' poi pero' è sempre molto diversa, e l'IPC finale (a valle del retirement) dipende da tantissimi altri fattori, tra cui anche il codice da eseguire.

[The3DProgrammer]

Il boost, seppure limitato, dovrebbe esserci proprio perchè se hanno calcolato che il decoder è sufficiente per gestire 2 core con una perdita di prestazioni contenuto, allora dovrebbe risultare almeno un po' "abbondante" per un solo core.
Se cioè avessero fatto un modulo con un singolo core, presumibilmente avrebbero bilanciato la minore capacità di calcolo con un decoder più limitato (se non sbaglio quello del k10 riesce a processare una istruzione in meno, infatti), perchè sarebbe inutile sprecare tanti transistor in una logica usata poi solo in casi estremi.
Ma se questa logica già c'è per servire un secondo core, allora tanto di guadagnato.


In realta' il discorso è molto + complicato di come lo stiamo trattando perchè dipende da tantissimi fattori come ho detto sopra, non per ultimo la particolare composizione del codice da eseguire.

Comunque adesso ho capito il tuo ragionamento, per come la vedo io il frontend di BD sarebbe stato + che adatto ad essere utilizzato anche per un solo cluster int, vista la FPU che si ritrova. Per inciso, intel campa sui 4 decoder dai tempi del conroe. Non credo che avrebbero tolto un decoder se ci fosse stato un solo cluster int (anche perche' sarebbe stato asimmetrico, k10 ha 3 decoder per 9 unita' di esecuzione, BD ha 4 decoder per 12 unita' di esecuzione, il rapporto è lo stesso)



- non potresti mettere a riposo il secondo core, avendo quindi consumi elevati che renderebbero impossibile l'uso del turbo core. In tal caso, si avrebbero più vantaggi dalla "fusione" o dall'aumento di frequenza?

ottimo punto, non avevo pensato a questo effetto collaterale.

[digieffe]

cut

Sul fatto che il colpaccio sarebbe riuscire ad utilizzare le unità del secondo core sono d'accordo, ma se ne era già discusso, e al di la della difficoltà tecnica, mi pare non fosse tanto conveniente per due motivi:
- un'unità int difficilmente sfrutta più di tre pipeline, quindi non si avrebbe certo un raddoppio di prestazioni, ma un boost limitato.
- non potresti mettere a riposo il secondo core, avendo quindi consumi elevati che renderebbero impossibile l'uso del turbo core. In tal caso, si avrebbero più vantaggi dalla "fusione" o dall'aumento di frequenza?
Non so quali difficoltà avrebbe comportato avere una sola ulteriore pipeline int condivisa tra i 2 core (un pò come la fpu) e quali vantaggi avrebbe potuto apportare.
ipotizzandone la fattibilità avrebbe potuto alzare la soglia teorica di ipc massimo di un core a 3 e quella media del cluster a 2.5, permettendo anche lo spegnimento di uno dei due core se non anche di se stessa e non variando nulla nel turbo... (ma queste sono solo congetture... forse si sarebbe dovuta aumentare anche la logica condivisa per alimentare il tutto a dovere e forse avrebbe richiesto una complessità che non valeva la pena raggiungere)
occhio che io parlavo di throughput massimo TEORICO del solo cluster INT. sempre in questo caso, quello di phenom II e' anche maggiore di BD (dato che un core K10 dispone di 6 unita' int per core, 3 ALU e 3 AGU). La realta' poi pero' è sempre molto diversa, e l'IPC finale dipende da tantissimi altri fattori, tra cui anche il codice da eseguire.
concordo, ciò che vorrei capire è qual'è l'ipc medio della parte int del PhenomII (mediato tra vari software e situazioni),
perchè se è 2 (su 3 di picco) BD potrà fare ben poco se non il minimo apporto dato dalle aglu (soprattutto nei cicli in quanto esegue sostanzialmente inc)
il max teorico di BD è 2 pipeline int più ciò che riescono ad apportare le aglu...
questo di media a quanto ammonta? (in amd lo sanno di certo... noi nessuna fonte?)

[The3DProgrammer]

concordo, ciò che vorrei capire è qual'è l'ipc medio della parte int del PhenomII (mediato tra vari software e situazioni),
perchè se è 2 (su 3 di picco) BD potrà fare ben poco se non il minimo apporto dato dalle aglu (soprattutto nei cicli in quanto esegue sostanzialmente inc)
il max teorico di BD è 2 pipeline int più ciò che riescono ad apportare le aglu...
questo di media a quanto ammonta? (in amd lo sanno di certo... noi nessuna fonte?)

In realta' io penso che BD sia un'architettura molto + bilanciata rispetto a K10. Sacrifica qualcosa in termini di capacita' di esecuzione int x86 in favore di una FPU/MMX molto potente, con un frontend estremamente + evoluto di quello di K10 e che dovrebbe gradire molto di + il codice intel optimized grazie al branch fusion, al memory disambiguation e ai 4 decoder. Un singolo modulo BD (senza secondo cluster int) lo vedo in grado di competere tranquillamente, su carta, con un singolo core SB. Il problema è che molti si attendono dalla sola aggiunta del secondo cluster int prestazioni da dual core puro, cosa che personalmente ritengo impossibile come ho gia' detto in precedenza.

[calabar]

Comunque adesso ho capito il tuo ragionamento [...]
Alla fine è un ragionamento decisamente poco "tecnico", ma credo abbastanza intuitivo. E basato sulla speranza che BD abbia un decoder adeguato per gestire decentemente due core, quindi un po' sovrabbondante per uno solo.
L'importante è essersi capiti, comunque. ;)

Non so quali difficoltà avrebbe comportato avere una sola ulteriore pipeline int condivisa tra i 2 core (un pò come la fpu) e quali vantaggi avrebbe potuto apportare.
Questa è una soluzione ancora differente, noi parlavamo di utilizzare le unità int del secondo core quando non in uso per un suo thread, non di aggiungere un'ulteriore unità int condivisa.
Non so quanto la soluzione sarebbe appetibile: richiede silicio in più (l'unità int) e una logica di gestione temo complessa per condividerla. A questo punto sarebbe forse meglio fare i due core asimmetrici, uno con tre e l'altro con due unità int.

ciò che vorrei capire è qual'è l'ipc medio della parte int del PhenomII (mediato tra vari software e situazioni),
perchè se è 2 (su 3 di picco) BD potrà fare ben poco se non il minimo apporto dato dalle aglu (soprattutto nei cicli in quanto esegue sostanzialmente inc)
il max teorico di BD è 2 pipeline int più ciò che riescono ad apportare le aglu...
questo di media a quanto ammonta? (in amd lo sanno di certo... noi nessuna fonte?)
Io non mi sento in grado di dirlo, però ricorda che sebbene le unità int del core BD siano meno, sono meglio servite e meno vincolate (e mi pare anche siano meno specifiche). E questi dovrebbero essere due (o tre) vantaggi non da poco.

[paolo.oliva2]

A me sembra fantascenza questa riflessione....

avessimo anche un incremento netto del 50% di prestazioni dal 1090T un ipotetico BDx8 a pari frequenza andrebbe comunque a rivaleggiare con il 2600k, la mancanza della sigla EE ed da interpretare solo come posizionamento di mercato, anche sul 1056 manca la nomenclatura EE ma nessuno se ne fa un dramma visto che non è un socket fascia alta, men che meno pensato per i server...

Io ho fatto una pura riflessione...
Comunque ti faccio notare come già postato da altri, che l'incremento del 50% di un BD X8 in MT rispetto ad un Thuban non è da considerarsi "se avessimo", ma bensì "al minimo avremmo", perché già in linea teorica con un IPC UGUALE, l'incremento di frequenza operativa e l'incremento di 2 core in più di per sè supererebbe già il 50%.

Comunque, volevo farti notare che da un Thuban ad un i7 X6 980X c'è una differenza del 48% di potenza, ma che un 2600K non arriva certamente a uguagliare la potenza di un i7 X6 in MT, quindi mi pare logico dedurre che la differenza tra un Thuban ed un SB sia inferiore e che quindi se un BD guadagnasse un +50% sul Thuban, per forza di cose, almeno in MT, dovrebbere essere superiore ad un SB X4.

Io ho solamente detto che non ho sentito parlare di SB-e EE... ma forse mi hai frainteso, perché il problema non è chi l'avrà più lungo ma il prezzo finale per la potenza offerta. Vedi... se Intel con SB-e X6 avesse una superiorità di potenza tale da poterlo vendere come EE, non capisco che ci guadagnamo... nel senso che se Intel l'ha più lungo ma a 1000$, BD l'ha più corto ma a 300$, le cose andrebbero male per noi, soprattutto in vista di SB sul 22nm. Viceversa, più BD sarà competitivo nei confronti di SB-e e più Intel applicherà un prezzo inferiore e più ci sarà concorrenza e quindi con prezzi di ambedue le case proiettati verso il basso.

[paolo.oliva2]

Io la vedo molto dura che un BD possa arrivare a potenze ST similari di SB, anche per il fatto che da sempre i proci AMD hanno un'architettura pensata per server e quindi propensi per MT (discorso cache circolare di Intel).

A prescindere da questo, mi sembra che non si voglia capire che un BD X8, turbo o non turbo, avrebbe il 10%-20% di clock in più di un SB (io sono rimasto ad un SB-e X6 a 3,3GHz def) e quindi, anche non prendendo in considerazione i 2 core in più di BD X8 vs SB-e X6, anche con un IPC inferiore del 10-20% a parità di core la potenza risultante sarebbe UGUALE.

Il discorso IPC conta in senso lato, perché se BD avesse un IPC uguale al Thuban, per sopperire ad un -50% di IPC (valori a caso) dovrebbe avere un clock superiore del 50%, e qui si arriverebbe ai limiti del silicio, quindi IMPOSSIBILITA' di uguagliare SB.
Ma questo rimane un discorso in ST, perché in MT BD può mettere in campo il fatto di poter avere 2 core in più, quindi anche se con IPC uguale al Thuban, si avrebbero comunque differenze percentuali come da un Thuban X6 ad un Phenom II X4.

Per questo anche se l'IPC di BD a core non fosse comunque super, comunque non danneggerebbe l'MT ma unicamente l'ST.
Ma il confronto di IPC ST non ha senso per la tipologia dei proci, in quanto nessuno comprerebbe un SB-e X6 o BD X8 per poi utilizzarlo unicamente con un'unica applicazione ST (usando più applicazioni ST contemporaneamente, rimarrebbe sempre la differenza di BD con 2 core ancora liberi).
Inoltre... credo che importante sia arrivare a determinate potenze ST, diciamo almeno 4GHz IPC Phenom II, per soddisfare le proprie esigenze.

[The3DProgrammer]

Io la vedo molto dura che un BD possa arrivare a potenze ST similari di SB, anche per il fatto che da sempre i proci AMD hanno un'architettura pensata per server e quindi propensi per MT (discorso cache circolare di Intel).

A prescindere da questo, mi sembra che non si voglia capire che un BD X8, turbo o non turbo, avrebbe il 10%-20% di clock in più di un SB (io sono rimasto ad un SB-e X6 a 3,3GHz def) e quindi, anche non prendendo in considerazione i 2 core in più di BD X8 vs SB-e X6, anche con un IPC inferiore del 10-20% a parità di core la potenza risultante sarebbe UGUALE.

Il discorso IPC conta in senso lato, perché se BD avesse un IPC uguale al Thuban, per sopperire ad un -50% di IPC (valori a caso) dovrebbe avere un clock superiore del 50%, e qui si arriverebbe ai limiti del silicio, quindi IMPOSSIBILITA' di uguagliare SB.
Ma questo rimane un discorso in ST, perché in MT BD può mettere in campo il fatto di poter avere 2 core in più, quindi anche se con IPC uguale al Thuban, si avrebbero comunque differenze percentuali come da un Thuban X6 ad un Phenom II X4.

Per questo anche se l'IPC di BD a core non fosse comunque super, comunque non danneggerebbe l'MT ma unicamente l'ST.
Ma il confronto di IPC ST non ha senso per la tipologia dei proci, in quanto nessuno comprerebbe un SB-e X6 o BD X8 per poi utilizzarlo unicamente con un'unica applicazione ST (usando più applicazioni ST contemporaneamente, rimarrebbe sempre la differenza di BD con 2 core ancora liberi).
Inoltre... credo che importante sia arrivare a determinate potenze ST, diciamo almeno 4GHz IPC Phenom II, per soddisfare le proprie esigenze.

Paolo il problema è che gran parte delle tue ipotesi si basano su due punti fondamentalmente non corretti:

1) I core di BD non garantiscono un raddoppio delle prestazioni teorico cosi' come farebbero due core completi

2) Le prestazioni non scalano quasi mai linearmente con la frequenza. Ergo se in un determinato bench BD è + lento del 10% rispetto a SB, non è detto che un aumento del clock del 10% sia sufficiente a colmare quel gap.

Volente o nolente, gran parte delle applicazioni ancora oggi sfruttano uno o due thread, difficilmente si arriva a 8 core se non in rendering o editing video. Purtroppo oggi il grosso e + evidente punto debole delle CPU amd nel mercato desktop riguarda le prestazioni in ambito single thread. E' proprio li che ci vuole un grande passo in avanti per tornare competitivi.

[ozlacs]

habemus CEO :D

ex IBM ed ex Lenovo tra l'altro

[>>The Red<<]

Questi Bulldozer vanno meglio degli 1155?

visto che devo cambiare configurazione conviene aspettare o vado di 1155?

[mtk]

Questi Bulldozer vanno meglio degli 1155?

visto che devo cambiare configurazione conviene aspettare o vado di 1155?

visto che cio' la boccia di vetro.....mmmm....si!
no!......
dagli il tempo di presentarli e poi si vedra :asd:

[>>The Red<<]

visto che cio' la boccia di vetro.....mmmm....si!
no!......
dagli il tempo di presentarli e poi si vedra :asd:

ahah perche non sto seguendo il mercato , credevo che gia l'avessero presentati :D

piu o meno quando usciranno sul mercato?

[mtk]

ahah perche non sto seguendo il mercato , credevo che gia l'avessero presentati :D

piu o meno quando usciranno sul mercato?

si spera entro la fine di settembre...

[>>The Red<<]

si spera entro la fine di settembre...

mmm... allora mi sa che andro di sandy bridge xD

[RIC3]

mmm... allora mi sa che andro di sandy bridge xD

Ma non potevano creare un unico socket,cos' chi vuole amd mette amd,chi vuole intel mette intel:D

[digieffe]

Io la vedo molto dura che un BD possa arrivare a potenze ST similari di SB, anche per il fatto che da sempre i proci AMD hanno un'architettura pensata per server e quindi propensi per MT (discorso cache circolare di Intel).

A prescindere da questo, mi sembra che non si voglia capire che un BD X8, turbo o non turbo, avrebbe il 10%-20% di clock in più di un SB (io sono rimasto ad un SB-e X6 a 3,3GHz def) e quindi, anche non prendendo in considerazione i 2 core in più di BD X8 vs SB-e X6, anche con un IPC inferiore del 10-20% a parità di core la potenza risultante sarebbe UGUALE.

Il discorso IPC conta in senso lato, perché se BD avesse un IPC uguale al Thuban, per sopperire ad un -50% di IPC (valori a caso) dovrebbe avere un clock superiore del 50%, e qui si arriverebbe ai limiti del silicio, quindi IMPOSSIBILITA' di uguagliare SB.
Ma questo rimane un discorso in ST, perché in MT BD può mettere in campo il fatto di poter avere 2 core in più, quindi anche se con IPC uguale al Thuban, si avrebbero comunque differenze percentuali come da un Thuban X6 ad un Phenom II X4.

Per questo anche se l'IPC di BD a core non fosse comunque super, comunque non danneggerebbe l'MT ma unicamente l'ST.
Ma il confronto di IPC ST non ha senso per la tipologia dei proci, in quanto nessuno comprerebbe un SB-e X6 o BD X8 per poi utilizzarlo unicamente con un'unica applicazione ST (usando più applicazioni ST contemporaneamente, rimarrebbe sempre la differenza di BD con 2 core ancora liberi).
Inoltre... credo che importante sia arrivare a determinate potenze ST, diciamo almeno 4GHz IPC Phenom II, per soddisfare le proprie esigenze.
Paolo il problema è che gran parte delle tue ipotesi si basano su due punti fondamentalmente non corretti:

1) I core di BD non garantiscono un raddoppio delle prestazioni teorico cosi' come farebbero due core completi

2) Le prestazioni non scalano quasi mai linearmente con la frequenza. Ergo se in un determinato bench BD è + lento del 10% rispetto a SB, non è detto che un aumento del clock del 10% sia sufficiente a colmare quel gap.

Volente o nolente, gran parte delle applicazioni ancora oggi sfruttano uno o due thread, difficilmente si arriva a 8 core se non in rendering o editing video. Purtroppo oggi il grosso e + evidente punto debole delle CPU amd nel mercato desktop riguarda le prestazioni in ambito single thread. E' proprio li che ci vuole un grande passo in avanti per tornare competitivi.



escludendo il discorso economico volevo aggiungere, anche se in precedenza scritto già in modo soft che l'ipc di BD è fondamentale

(ri)faccio 2 conti (semplicistici) con i dati che abbiamo in mano e con l'ipotesi fatta da Paolo che ipc di DB=ipc di thuban:

ipotizzando
l'ipc di 1 core thuban = 1;
l'ipc di 1 core BD = 1;

potenza ST Thuban = 1 (ipc) x 3700 (frequenza) = 3700
potenza ST BD = 1 x 4200 (o 4500) = 4200 (o 4500)

fin qui sembra tutto ok visto che abbiamo dal 13 al 21% in più di clock


Paolo quanto segue è indirizzato particolarmente a te ;)

ipotizzando uno scaling perfetto in frequenza e in numero di core (non è mai così)

potenza MT Thuban = 1 (ipc) x 3300 (frequenza) x 6 (core) = 19800
potenza MT BD = 1 x 3600 (o 3900) x 8 x 80% (efficienza modulo completo) = 23040 (o 24960)

BD a 3600 vs thuban 1100t a 3300: 23040/19800 = +16%
BD a 3900 vs thuban 1100t a 3300: 24960/19800 = +26%

caro Paolo alle tue condizioni il 50% NON esiste!!!


per avere il 50% in più è necessario un ipc più alto o una frequenza più alta del:
a 3600 (o 3900) 1.50/1.16 (o 1.26) = 29% (o 19%)

quindi o sono necessari incrementi di ipc dal 19% (o 29%) oppure a parità di ipc per avere il 50% in più di Thuban BD dovrà girare con tutti i moduli a 3600 + 29% (o 3900 +19%) = 4650 mhz


a questo va aggiunto quanto scritto da The3DProgrammer


senza polemica, questa volta spero di esser stato chiaro ...


Ps: Paolo non è un attacco diretto a te, ho approfittato del tuo intervento per cercare di fare un pò di chiarezza, in quanto ho notato che diversi utenti sottovalutano che l'utilizzo del completo del modulo porta a un decadimento delle prestazioni, come già detto da JF.

Pps: per quanto mi riguarda la frequenza da tenere in considerazione per BD è quella da 3600 in quanto sarà quella top al lancio. (quindi +29% di ipc, speriamo....)

[digieffe]

solo a titolo d'ipotesi a parità di frequenza con il Thuban 1100T fermo restando i vincoli precedenti:

potenza MT Thuban = 1 (ipc) x 3300 (frequenza) x 6 (core) = 19800
potenza MT BD = 1 x 3300 x 8 x 80% (efficienza modulo completo) = 21120

BD a 3300 vs thuban 1100t a 3300: 21120/19800 = +7%

a parità di clock e condizioni "perfette" avrebbe, nonostante i 2 core in più non il 33%, ma solo il 7% per via dell'utilizzo delle parti condivise....


EDIT: questo esempio fa capire quanto sia necessario un aumento di ipc... a pari frequenza quasi pari prestazioni con 2 core in più

[paolo.oliva2]

Paolo il problema è che gran parte delle tue ipotesi si basano su due punti fondamentalmente non corretti:

1) I core di BD non garantiscono un raddoppio delle prestazioni teorico cosi' come farebbero due core completi

Si ma è relativo... perché la condivisione di parti potrebbe anche portare un IPC inferiore, però bisogna sempre riportare il discorso nel confronto a 2 core Phenom II ed anche stabilire la condivisione quanto TDP fa risparmiare a vantaggio di frequenze superiori e quantificare il risparmio di transistor sia in termini di costo (superficie inferiore) e sia in termini di numero di core massimo a parità di transistor (nel senso, ogni modulo risparmia il 20% di transistor, quindi 5 moduli (10 core) potrebbero necessitare la stessa quantità di transistor di un 8 core "tradizionale")


2) Le prestazioni non scalano quasi mai linearmente con la frequenza. Ergo se in un determinato bench BD è + lento del 10% rispetto a SB, non è detto che un aumento del clock del 10% sia sufficiente a colmare quel gap.
Ma neanche no... perché se una architettura è studiata per determinate frequenze, mi sembra chiaro che il decadimento delle prestazioni si abbia almeno il 30% sopra alla frequenza def... quindi se BD avesse un IPC inferiore del 10% rispetto a SB, non vedo il perché se avesse un margine del 10% superiore di frequenza il gap non si annullerebbe.

Volente o nolente, gran parte delle applicazioni ancora oggi sfruttano uno o due thread, difficilmente si arriva a 8 core se non in rendering o editing video. Purtroppo oggi il grosso e + evidente punto debole delle CPU amd nel mercato desktop riguarda le prestazioni in ambito single thread. E' proprio li che ci vuole un grande passo in avanti per tornare competitivi.
Si, ma a quello che dici c'è una differenza. Internet explorer è una applicazione ST ma non vedo una necessità di avere una potenza di un Thuban a 5GHz per farlo girare, in quanto già un Atom soddisferebbe.
Fammi un elenco di applicazioni ST in cui la potenza di un SB 2600K occato a 4,5GHz sia indispensabile... quante sono? E' certo che la maggior parte di applicazioni sarebbero ancora 1TH vengono soddisfate ampiamente già con un Phenom II 940 a 3GHz...
Nell'utilizzo normale, ad esempio, un Thuban si avvantaggia parecchio rispetto ad un Phenom II X4 perché con 6 core fisici disponibili risulta sempre più libero ad eseguire singoli TH aggiuntivi rispetto ad un X4. Stesso discorso lo si potrà comunque avere con BD X8... cioè un conto sarà un bench su 1TH, tutt'altro un bench con 8 TH contemporanei che si appoggiano ad 8 core fisici contro un 4 core fisici, sia che abbia l'SMT o meno.

[digieffe]

Ma che roba sono questi conti basati sul niente? :mbe:

Aspettare e basta no, eh? :D

è una risposta a quanto postato da altri per dare l'idea generica di come si potrà comportare BD nei confronti di Thuban...

sono teorie basate su numeri esemplificativi, perchè poi basate sul niente??? oramai sono quasi tutti dati noti...

se a qualcuno danno fastidio interventi del genere la prossima volta mi rivolgerò in privato agli interlocutori, privando però altri lettori la possibilità di farsi una idea...

[paolo.oliva2]

escludendo il discorso economico volevo aggiungere, anche se in precedenza scritto già in modo soft che l'ipc di BD è fondamentale

(ri)faccio 2 conti (semplicistici) con i dati che abbiamo in mano e con l'ipotesi fatta da Paolo che ipc di DB=ipc di thuban:

ipotizzando
l'ipc di 1 core thuban = 1;
l'ipc di 1 core BD = 1;

potenza ST Thuban = 1 (ipc) x 3700 (frequenza) = 3700
potenza ST BD = 1 x 4200 (o 4500) = 4200 (o 4500)

fin qui sembra tutto ok visto che abbiamo dal 13 al 21% in più di clock


Paolo quanto segue è indirizzato particolarmente a te ;)

ipotizzando uno scaling perfetto in frequenza e in numero di core (non è mai così)

potenza MT Thuban = 1 (ipc) x 3300 (frequenza) x 6 (core) = 19800
potenza MT BD = 1 x 3600 (o 3900) x 8 x 80% (efficienza modulo completo) = 23040 (o 24960)

BD a 3600 vs thuban 1100t a 3300: 23040/19800 = +16%
BD a 3900 vs thuban 1100t a 3300: 24960/19800 = +26%

caro Paolo alle tue condizioni il 50% NON esiste!!!


per avere il 50% in più è necessario un ipc più alto o una frequenza più alta del:
a 3600 (o 3900) 1.50/1.16 (o 1.26) = 29% (o 19%)

quindi o sono necessari incrementi di ipc dal 19% (o 29%) oppure a parità di ipc per avere il 50% in più di Thuban BD dovrà girare con tutti i moduli a 3600 + 29% (o 3900 +19%) = 4650 mhz


a questo va aggiunto quanto scritto da The3DProgrammer

senza polemica, questa volta spero di esser stato chiaro ...

Ps: Paolo non è un attacco diretto a te, ho approfittato del tuo intervento per cercare di fare un pò di chiarezza, in quanto ho notato che diversi utenti sottovalutano che l'utilizzo del completo del modulo porta a un decadimento delle prestazioni, come già detto da JF.

Pps: per quanto mi riguarda la frequenza da tenere in considerazione per BD è quella da 3600 in quanto sarà quella top al lancio. (quindi +29% di ipc, speriamo....)

Ma quello che scrivi di certo non lo discuto, ma era per far capire che guardare solamente l'incremento di IPC è fuorviante in quanto bisogna considerare sia l'aumento di frequenza che l'aumento dei core.

Per quanto riguarda il discorso di guadagno per i 2 core aggiuntivi, vediamo di utilizzare un metro preciso: cosa vogliamo prendere? La media, il massimo o il risultato peggiore?
Il risultato peggiore è zero (programmi che non usano più di 6 core).
Il risultato medio è il 7%.
Il risultato migliore è ad esempio Cinebench, che scala a meraviglia all'aumentare dei core.
Per parcondicio... si parla che l'SMT di Intel porta a punte del +50% (come letto più volte), ma è anche vero che l'apporto medio è ben più basso ed il risultato peggiore porta addirittura valori negativi.
Ora... mi sembra chiaro che se parliamo di SMT +50% parliamo del massimo ottenibile, quindi mi sembra corretto riportare anche il massimo ottenibile con l'avere 2 core in più, altrimenti chi legge si farebbe un'idea che un BD X8 porterebbe solamente a +7% rispetto ad un X6 mentre un SB2600K con l'SMT +50%... mi sembra difficile da comprendere.

------------

A parte tutto questo, io rifletterei pure su un altro punto:
perché AMD parte con un X8? Non certo perché doveva scontrarsi con un SB X8 desktop (penso che AMD già sapeva che un SB-e X8 non sarebbe stato un problema per motivi di TDP/frequenza), ma con un SB-e X6.
Ora... se BD avesse un IPC uguale ad SB, praticamente avrebbe tutto il vantaggio della frequenza in più e di 2 core in più.
Questo NON E' POSSIBILE, perché altrimenti AMD sarebbe partita con un BD X6, con un tot di superficie silicio inferiore ergo costo produzione inferiore ergo + guadagno commerciale.

[Anachronox]

è una risposta a quanto postato da altri per dare l'idea generica di come si potrà comportare BD nei confronti di Thuban...

sono teorie basate su numeri esemplificativi, perchè poi basate sul niente??? oramai sono quasi tutti dati noti...

se a qualcuno danno fastidio interventi del genere la prossima volta mi rivolgerò in privato agli interlocutori, privando però altri lettori la possibilità di farsi una idea...

Personalmente a me fa piacere leggere queste ipotesi. Se a qualcuno danno fastidio, non è mica obbligato a leggerle e commentarle imho.

[digieffe]

Di farsi un'idea sbagliata.

Ipotesi non verificate:

- IPC uguale a K10
- Un fattore arbitrario di 0.8 applicato al singolo core non si sa per quale motivo (no, non me lo spiegare, lo so da cosa l'hai tirato fuori, ma un numero riferito a tutt'altro non puo' essere usato dentro un conto tanto per fare)
- Lo scaling del throughput non e' lineare con il numero di cores

A causa di queste determinanti falle nelle ipotesi il ragionamento porta ad una conclusione completamente invalida.

- IPC uguale a K10 -> è stata ipotizzata da un altro utente e volevo dimostrargli che con quell'ipc non si va da nessuna parte (infatti ho scritto che sarebbero necessari degli incrementi di ipc)
- Un fattore arbitrario di 0.8 applicato al singolo core -> JF di AMD
- Lo scaling del throughput non e' lineare con il numero di cores -> se è per questo neanche con la frequenza (ho scritto esemplificativa e "perfetta")

A causa di queste determinanti falle nelle ipotesi il ragionamento porta ad una conclusione completamente invalida -> sembra che tu non abbia neanche letto chiò che ho scritto...

allora quale sarebbe la mia conclusione completamente invalida?

[calabar]

Di farsi un'idea sbagliata.

Ipotesi non verificate:

- IPC uguale a K10
- Un fattore arbitrario di 0.8 applicato al singolo core non si sa per quale motivo (no, non me lo spiegare, lo so da cosa l'hai tirato fuori, ma un numero riferito a tutt'altro non puo' essere usato dentro un conto tanto per fare)
- Lo scaling del throughput non e' lineare con il numero di cores

A causa di queste determinanti falle nelle ipotesi il ragionamento porta ad una conclusione completamente invalida.

Non si tratta di ipotesi non verificate, ma di un discorso ipotetico per mostrare come BD abbia bisogno di avere un buon ipc single thread.

Per quanto riguarda i tuoi dubbi:
- Quella è la premessa ipotetica per mostrare come un ipc identico a thuban in single core sarebbe disastroso per BD.
- Il "fattore 0.8" è stato dichiarato da AMD come stima del calo di prestazioni che i core di BD hanno in multithread rispetto a dei core completi, senza logica condivisa. Il prezzo del CMT, insomma.
- Le prestazioni non sono mai state lineari con il numero di core, anche in quei software ben parallelizzati. E in ogni caso non lo è in media, che è ciò che conta nell'esempio. Mi pare verosimile che BD non stravolga questa realtà misurabile in tutti i processori odierni.

Per quanto riguarda il discorso di guadagno per i 2 core aggiuntivi, vediamo di utilizzare un metro preciso: cosa vogliamo prendere? La media, il massimo o il risultato peggiore?
Il risultato peggiore è zero (programmi che non usano più di 6 core).
Il risultato medio è il 7%.
Il risultato migliore è ad esempio Cinebench, che scala a meraviglia all'aumentare dei core.
[...]
Ora... mi sembra chiaro che se parliamo di SMT +50%, non possiamo parlare di massimo +7% l'avere 2 core in più, no?
Si, i calcoli non mentono.
Il motivo è semplice: SMT da semplicemente un "qualcosa in più" rispetto ai 4 core, CMT invece da "qualcosa in meno" rispetto agli 8.
Insomma... hai sbagliato esempio.
Avresti dovuto misurare quanto un 4core+smt va rispetto ad un 6 core senza smt, non quanto un 4core senza smt va rispetto ad un 4core+smt.
In questo caso, supponendo +50% per l'smt (ma si, esageriamo!), avremo avuto 1*4*freq + 50% = 6 *freq, ossia un bel +0% rispetto al 6 core. Che è comunque meno del +7% calcolato per il CMT. ;)

Inoltre il "caso medio" del 7%, nell'esempio, non è legato alla capacità del software di scalare con l'aumento dei core (l'esempio già supponeva uno scaling perfetto se non sbaglio), ma è legato alla capacità di mettere in crisi la logica condivisa del task in esecuzione.

EDIT: oops, preceduto


Dimenticavo...
perché AMD parte con un X8? Non certo perché doveva scontrarsi con un SB X8 desktop (penso che AMD già sapeva che un SB-e X8 non sarebbe stato un problema per motivi di TDP/frequenza), ma con un SB-e X6.
In realtà AMD ha dichiarato più volte di aver messo 8 core per contrastare gli 8 thread dei processori intel con SMT, offrendo una soluzione migliore. Se poi risulta così migliore da competere con gli x6 o gli x8 tanto meglio, ma non era quello il target, quello concettuale per lo meno.

[paolo.oliva2]

- IPC uguale a K10 -> è stata ipotizzata da un altro utente e volevo dimostrargli che con quell'ipc non si va da nessuna parte (infatti ho scritto che sarebbero necessari degli incrementi di ipc)
- Un fattore arbitrario di 0.8 applicato al singolo core -> JF di AMD
- Lo scaling del throughput non e' lineare con il numero di cores -> se è per questo neanche con la frequenza (ho scritto esemplificativa e "perfetta")

A causa di queste determinanti falle nelle ipotesi il ragionamento porta ad una conclusione completamente invalida -> sembra che tu non abbia neanche letto chiò che ho scritto...

allora quale sarebbe la mia conclusione completamente invalida?

Tranquilli...
L'esempio che vuoi portare tu è il seguente:
IPC 10 con clock 2GHz (discorso limitato ad 1 core) = 20
IPC 1 con clock 10GHz = 10

E' chiaro che l'IPC di BD comunque non può essere basso perché l'aumento di frequenza ha limiti fisici precisi, come pure l'aumento del numero dei core ha dei limiti economici per l'aumento della grandezza del die.

Ora... mi sembra chiaro che in 5 anni AMD non possa aver speso tempo e soldi per arrivare ad una architettura che non conceda guadagni rispetto al Phenom II.

Ma è anche chiaro che progettare BD come X8 già alla partenza porta a pensare che quei 2 core in più (e quindi aumentando i costi) siano dovuti in una visione totale del progetto, cioè il bilanciamento tra potenza/costi e performances nei confronti ad Intel.

A questo possiamo aggiungere il fatto che l'8130p non sia stato commercializzato non perché la frequenza def su tutti i core era bassa, quanto invece la frequenza Turbo massima su 1-4 core.
L'8120 arriva a 3,9-4GHz come frequenza massima, anche se come X8 risulta essere pure inferiore a quella dell'8130p.

[RIC3]

ipc sta per...?

[sniperspa]

ipc sta per...?

istructions per clock

[tmx]

ipc sta per...?

http://it.wikipedia.org/wiki/Istruzioni_Per_Ciclo

[paolo.oliva2]

Non si tratta di ipotesi non verificate, ma di un discorso ipotetico per mostrare come BD abbia bisogno di avere un buon ipc single thread.

Per quanto riguarda i tuoi dubbi:
- Quella è la premessa ipotetica per mostrare come un ipc identico a thuban in single core sarebbe disastroso per BD.
- Il "fattore 0.8" è stato dichiarato da AMD come stima del calo di prestazioni che i core di BD hanno in multithread rispetto a dei core completi, senza logica condivisa. Il prezzo del CMT, insomma.
- Le prestazioni non sono mai state lineari con il numero di core, anche in quei software ben parallelizzati. E in ogni caso non lo è in media, che è ciò che conta nell'esempio. Mi pare verosimile che BD non stravolga questa realtà misurabile in tutti i processori odierni.


Si, i calcoli non mentono.
Il motivo è semplice: SMT da semplicemente un "qualcosa in più" rispetto ai 4 core, CMT invece da "qualcosa in meno" rispetto agli 8.
Insomma... hai sbagliato esempio.
Avresti dovuto misurare quanto un 4core+smt va rispetto ad un 6 core senza smt, non quanto un 4core con smt va rispetto ad un 4core+smt.
In questo caso, supponendo +50% per l'smt (ma si, esageriamo!), avremo avuto 1*4*freq + 50% = 6 *freq, ossia un bel +0% rispetto al 6 core. Che è comunque meno del +7% calcolato per il CMT. ;)

Inoltre il "caso medio" del 7%, nell'esempio, non è legato alla capacità del software di scalare con l'aumento dei core (l'esempio già supponeva uno scaling perfetto se non sbaglio), ma è legato alla capacità di mettere in crisi la logica condivisa del task in esecuzione.

EDIT: oops, preceduto

Come possa comportarsi BD nella pratica è difficile da prognosticare, perché AMD ha sì detto un rendimento dell'80% del modulo rispetto a 2 core "normali", ma ha anche detto +50% di un BD X16 rispetto ad un MC X12.
Ora... se ipotizziamo al massimo un +7% l'avere 2 core in più, ne risulterebbe che il restante +43% deve essere per forza un mix tra IPC e frequenza, il che porterebbe un BD X6 già a +43% rispetto al Thuban (butta via).

Comunque io non ci metto becco sull'IPC perché per le mie possibilità è difficile da capire... comunque secondo me un aumento almeno del 20% di BD sul Phenom II è lecito... a cui si aggiungerà pure la frequenza di lavoro (ben superiore al Phenom II) e i 2 core in più per l'MT.

Poi la vera potenza per me è relativa, nel senso che comunque io mi diverto ad occarlo il procio, e vedere che un BD X8 arriva in Turbo a frequenze simili del mio Thuban a liquido con WC, mi fa ben sperare a OC massimi ben superiori, ed è per questo che lo aspetto con ansia, anche per vedere a che risultati nei bench potrò arrivare.

[digieffe]

cut...
Ora... se ipotizziamo al massimo un +7% l'avere 2 core in più, ne risulterebbe che il restante +43% deve essere per forza un mix tra IPC e frequenza, il che porterebbe un BD X6 già a +43% rispetto al Thuban (butta via).

non posso che quotare :)

semplificando al massimo 8 core * 80% efficenza modulo = 6.4 core...

inutile che ripeto tutte le condizioni di imperfezione di questo ragionamento...

è proprio cosi servirà più frequenza e più ipc

[giovanbattista]

io credo che si viaggi con un aumento magg. (40/50? di media) il 20%?
......nel caso peggiore

[digieffe]

Ostia dopo tutto questo tempo ancora non avete capito il significato di quella frase sullo 0.8?

E dire che e' stata e rispiegata un miliardo di volte su ogni forum conosciuto e sconosciuto da quel poveraccio. Credo si sia mangiato le mani per aver menzionato quel fattore la prima volta.

Il riferimento e' a quello che sarebbe stato bulldozer senza condividere le risorse, non rispetto a K10.

Se ammetti l'ipotesi che l'IPC di BD e' uguale a quella del K10 hai gia' considerato l'architettura nel suo insieme, compresi tutti i tradeoffs. Altrimenti dovremmo cominciare a moltiplicare per fattori all'infinito: e se ci fossero stati 7GB di cache L1 per core? E se ci fossero stati 8 canali di memoria? E se la cache fosse stata fully inclusive? Tutte queste cose formano l'architettura, la quale produce un certo IPC (per quanto questo termini significhi poco perche' ne esistono infinite definizioni): i prezzi sono stati gia' tutti pagati e i vantaggi tutti considerati quando si parla di IPC.

Quel conteggio non ha senso. Che a qualcuno piaccia vedere elucubrazioni benissimo, ma che non si possa dire che non hanno senso e' ridicolo: rivendicate il diritto di scrivere assurdita' perche' e' un forum e tutti ne hanno il diritto ma vorreste negare quello di replica? :asd:

Mi disiscrivo dal thread, tanto e' piu' disinformativo che informativo.
Prendo atto che ti disiscrivi, a tutti è consentito sia il diritto di replica sia di dissentire: ho l'impressione però che dal tuo ragionamento è come se tu non avessi ben chiara la differenza tra ipc e throughput, ne avremmo potuto discutere... ma tant'è.

Buon proseguimento su altri forum :).


Ps: seguo questo thread praticamente fin dall'inizio e non credo sia disinformativo più di tanto, fosse solo per i primi post che sono un riferimento per informazioni e notizie.


EDIT: Purtroppo sei capitato in un periodo un pò "fermo" con pochi contributori e poche informazioni/notizie, così va che vengon fuori dei ragionamenti/riflessioni... dai quali si può tranquillamente dissentire.
Poi c'è anche il fattore complessità: se si scrive in modalità molto tecnica c'è una parte della platea che va in contro a difficoltà, se semplifichi in molti possono "intuire" ma scontenti i tecnici...

[capitan_crasy]

Ragazzi non scannatevi troppo sul IPC...
JF, quindi AMD, ha dichiarato che IPC di BD sarà superiore a quello del K10.
Alla presentazione sapremo di quanto sarà superiore in percentuale e in quali condizioni...

[paolo.oliva2]

Comunque... senza essere pessimisti, non c'è un po' troppo silenzio per un BD al lancio per metà settembre?

Pensare che sto facendo i salti mortali per seguire il TH
OT per ridire
http://www.pctunerup.com/up/results/_201108/th_20110825232726_Velocitbanda.jpg (http://www.pctunerup.com/up/image.php?src=_201108/20110825232726_Velocitbanda.jpg)
Fine OT

[digieffe]

Ragazzi non scannatevi troppo sul IPC...
JF, quindi AMD, ha dichiarato che IPC di BD sarà superiore a quello del K10.
Alla presentazione sapremo di quanto sarà superiore in percentuale e in quali condizioni...

Lo so da tempo che sarà superiore... (non però di quanto)
quella era solo una ipotesi di ragionamento per capire qualora fosse stato uguale a cosa si sarebbe andato in contro...



EDIT:
Comunque... senza essere pessimisti, non c'è un po' troppo silenzio per un BD al lancio per metà settembre?

Pensare che sto facendo i salti mortali per seguire il TH
OT per ridire
http://www.pctunerup.com/up/results/_201108/th_20110825232726_Velocitbanda.jpg (http://www.pctunerup.com/up/image.php?src=_201108/20110825232726_Velocitbanda.jpg)
Fine OT
francamente a questo punto non mi importa quando sarò lanciato... l'importante e che abbiano fatto un buon lavoro con il design ed il silicio.

OT: con cosa sei collegato?

[calabar]

Ostia dopo tutto questo tempo ancora non avete capito il significato di quella frase sullo 0.8?
[...]
Quel conteggio non ha senso. Che a qualcuno piaccia vedere elucubrazioni benissimo, ma che non si possa dire che non hanno senso e' ridicolo: rivendicate il diritto di scrivere assurdita' perche' e' un forum e tutti ne hanno il diritto ma vorreste negare quello di replica? :asd:
Io ho l'impressione che sia tu a non aver capito, a non aver cosa fosse quell'esempio.

Si tratta semplicemente di una dimostrazione "per assurdo": assumendo un ipc di BD in single thread identico al k10, quali sarebbero i risultati in multithread?
Il risultato ottenuto serve per mostrare come sarebbe assurdo non aspettarsi un aumento di ipc rispetto il k10, a meno che BD non risulti essere un progetto davvero fallimentare.

E non facciamo i polemici ogni volta, dai! ;)

[digieffe]

Io ho l'impressione che sia tu a non aver capito, a non aver cosa fosse quell'esempio.

Si tratta semplicemente di una dimostrazione "per assurdo": assumendo un ipc di BD in single thread identico al k10, quali sarebbero i risultati in multithread?
Il risultato ottenuto serve per mostrare come sarebbe assurdo non aspettarsi un aumento di ipc rispetto il k10, a meno che BD non risulti essere un progetto davvero fallimentare.

E non facciamo i polemici ogni volta, dai! ;)

Non avrei saputo spiegarlo meglio, grazie :).

Fatto sta che anche io ho un tempo ridottissimo...

EDIT: ... a disposizione

[marchigiano]

Ragazzi non scannatevi troppo sul IPC...
JF, quindi AMD, ha dichiarato che IPC di BD sarà superiore a quello del K10.
Alla presentazione sapremo di quanto sarà superiore in percentuale e in quali condizioni...

mah... dopo quello che hanno combinato non gli credo più

insomma non vorrei che 2 giorni prima la presentazione se ne uscissero con "abbiamo preferito dare la precedenza alla frequenza quindi l'ipc è inferiore" :rolleyes:

inoltre dipende cosa si intende per ipc, dell'intero processore o del singolo core? perchè nel primo caso ci sta ma nel secondo ho parecchi dubbi...

che poi essendo BD profondamente diverso da phenom penso che ci saranno delle applicazioni in cui andrà il doppio se non di più del thuban, ma in altre potrebbe andare uguale se non di meno...

[crazyduck00]

Ostia dopo tutto questo tempo ancora non avete capito il significato di quella frase sullo 0.8?

E dire che e' stata e rispiegata un miliardo di volte su ogni forum conosciuto e sconosciuto da quel poveraccio. Credo si sia mangiato le mani per aver menzionato quel fattore la prima volta.

Il riferimento e' a quello che sarebbe stato bulldozer senza condividere le risorse, non rispetto a K10.

Se ammetti l'ipotesi che l'IPC di BD e' uguale a quella del K10 hai gia' considerato l'architettura nel suo insieme, compresi tutti i tradeoffs. Altrimenti dovremmo cominciare a moltiplicare per fattori all'infinito: e se ci fossero stati 7GB di cache L1 per core? E se ci fossero stati 8 canali di memoria? E se la cache fosse stata fully inclusive? Tutte queste cose formano l'architettura, la quale produce un certo IPC (per quanto questo termini significhi poco perche' ne esistono infinite definizioni): i prezzi sono stati gia' tutti pagati e i vantaggi tutti considerati quando si parla di IPC.

Quel conteggio non ha senso. Che a qualcuno piaccia vedere elucubrazioni benissimo, ma che non si possa dire che non hanno senso e' ridicolo: rivendicate il diritto di scrivere assurdita' perche' e' un forum e tutti ne hanno il diritto ma vorreste negare quello di replica? :asd:

Mi disiscrivo dal thread, tanto e' piu' disinformativo che informativo.

:mbe: ma scherzi ?
ma guarda che non stanno dicendo che BD avrà un ipc analogo a thuban sarebbe il colmo pensarlo in questo tread dopo tutti questi dialoghi tecnici.
Stanno solo dialogando su delle ipotesi un po come dire: " wee raga BD ha l'ipc superiore a thuban e su questo non ci piove, ma immaginiamo di pareggiarlo PER UNO NOSTRO CALCOLO a thuban, vediamo a parita di ipc in che percentuale BD e superiore a thuban".

Dai è da oggi che li seguo con attenzione e piacere ma non intervengo perchè ho meno di loro da dire tecnicamente parlando, ma l'ho capito perfino io il loro ragionamento, e non mi sembra che stiano dando disinformazioni, stanno solo discutendo tecnicamente su una cpu come puo essere in certe condizioni in assenza o parita di altre, ma tali assenze o parita non sono citate xkè cosi saranno ma solo per fare esempi tecnici su una cpu.

Io non capisco perchè tutta questa aria, LO SO CHE SEI ARRABBIATO COME TUTTI NOI che sto BD ancora non è uscito ehehehe ma tranquillo metà settembre sono sicuro che lo vedremo :p

Ma non dire che questo forum è disinformativo, perchè forse è l'unico dei tanti italiani piu genuino che io ho trovato fino ad oggi.

[crazyduck00]

Comunque... senza essere pessimisti, non c'è un po' troppo silenzio per un BD al lancio per metà settembre?

Pensare che sto facendo i salti mortali per seguire il TH
OT per ridire
http://www.pctunerup.com/up/results/_201108/th_20110825232726_Velocitbanda.jpg (http://www.pctunerup.com/up/image.php?src=_201108/20110825232726_Velocitbanda.jpg)
Fine OT

oO ammazza tua, sei ritornato al 56kakka :D

[digieffe]

mah... dopo quello che hanno combinato non gli credo più

insomma non vorrei che 2 giorni prima la presentazione se ne uscissero con "abbiamo preferito dare la precedenza alla frequenza quindi l'ipc è inferiore" :rolleyes:

inoltre dipende cosa si intende per ipc, dell'intero processore o del singolo core? perchè nel primo caso ci sta ma nel secondo ho parecchi dubbi...

che poi essendo BD profondamente diverso da phenom penso che ci saranno delle applicazioni in cui andrà il doppio se non di più del thuban, ma in altre potrebbe andare uguale se non di meno...
c'è la distinzione tra ipc che è relativo al singolo core e throughput relativo a più core.

[capitan_crasy]

mah... dopo quello che hanno combinato non gli credo più

Che JF abbia fornito molte informazioni su BD attraverso il Blog ufficiale, che lavori per AMD e condivida i suoi pensieri sui vari forum e che alla fine è la fonte più attendibile sulle CPU Bulldozer è un dannato dato di fatto che ti piaccia o no...

insomma non vorrei che 2 giorni prima la presentazione se ne uscissero con "abbiamo preferito dare la precedenza alla frequenza quindi l'ipc è inferiore" :rolleyes:

E' un pò ridicolo attaccarsi al rinvio di BD per giudicare interamente l'operato di JF.
Insomma il posticipo non la certo deciso lui e comunque sia sarebbe ingenuo pensare che è stato pianificato due giorni prima della presunta presentazione a giugno.
E' ancora più ingenuo pensare che anche lui non sia sotto all'NDA e che avesse dovuto dirlo prima per qualche forma di ridicolo cameratismo...


inoltre dipende cosa si intende per ipc, dell'intero processore o del singolo core? perchè nel primo caso ci sta ma nel secondo ho parecchi dubbi...

che poi essendo BD profondamente diverso da phenom penso che ci saranno delle applicazioni in cui andrà il doppio se non di più del thuban, ma in altre potrebbe andare uguale se non di meno...

http://www.xtremeshack.com/immagine/i106801_screenhunter-70.jpg
:D :sofico:

[paolo.oliva2]

:mbe: ma scherzi ?
ma guarda che non stanno dicendo che BD avrà un ipc analogo a thuban sarebbe il colmo pensarlo in questo tread dopo tutti questi dialoghi tecnici.
Stanno solo dialogando su delle ipotesi un po come dire: " wee raga BD ha l'ipc superiore a thuban e su questo non ci piove, ma immaginiamo di pareggiarlo PER UNO NOSTRO CALCOLO a thuban, vediamo a parita di ipc in che percentuale BD e superiore a thuban".

Dai è da oggi che li seguo con attenzione e piacere ma non intervengo perchè ho meno di loro da dire tecnicamente parlando, ma l'ho capito perfino io il loro ragionamento, e non mi sembra che stiano dando disinformazioni, stanno solo discutendo tecnicamente su una cpu come puo essere in certe condizioni in assenza o parita di altre, ma tali assenze o parita non sono citate xkè cosi saranno ma solo per fare esempi tecnici su una cpu.

Io non capisco perchè tutta questa aria, LO SO CHE SEI ARRABBIATO COME TUTTI NOI che sto BD ancora non è uscito ehehehe ma tranquillo metà settembre sono sicuro che lo vedremo :p

Ma non dire che questo forum è disinformativo, perchè forse è l'unico dei tanti italiani piu genuino che io ho trovato fino ad oggi.

:)
Per la banda, non dipende da me, dipende dallo stato (guarda dove è appoggiato l'omino nel test di banda).

[crazyduck00]

:)
Per la banda, non dipende da me, dipende dallo stato (guarda dove è appoggiato l'omino nel test di banda).

ah ! adesso è tutto chiaro :D e bravo bravo... ;)

[phicrand_6358]

faccio notare a digieffe che se ne suoi conti applica l'IPC di BD=Thuban=1 lo deve fare al netto del fattore 0.8, non lo può stornare poi poichè sarebbe un errore di logica matematica...

[paolo.oliva2]

@Calabar.

Comunque non mi tornano i tuoi calcoli che 2 core in più concederebbero solamente un +7%.

Risultati Cinebench:

# paolo.oliva2| 1090T @200x22,5 | 4 GB DDR3 @800 MHz | 890FX/SB850 | Seven 64 | 1.36 | 8.02
# Labview | PhenomII X4 975 @ 200*22.5 (4,5 GHz)| 4 GB DDR3 @800 MHz | AMD 890FX | Seven 64 | 1.36 | 5.33

Ho preso questi risultati perché entrambi con Phenom II (X4 e X6) ed entrambi con la stessa frequenza di OC.

Come puoi vedere, il risultato in ST è il medesimo.
Prendendo il risultato in MT, l'X4 da' 5.33.
Ora... un X6 con un +50% di core dovrebbe dare 5.33 + il 50%, cioé 7.995. Il mio Thuban addirittura arriva a 8.02, quindi Cinebench rispetta in pieno la perfetta scalabilità di aumento dei core.

Preciso, non voglio dire che qualsiasi programma fornirà lo stesso vantaggio, ma come ho detto, io ho precisato un vantaggio "fino al" e non sempre.

Ora... il 7% non ho capito da che calcoli lo tiri fuori... però se da X4 a X6 ci sarebbe un +50% di core contro il +33% dato da un X6 a un X8, in teoria un Thuban dovrebbe dare solamente un +10% contro il +7% di BD... ma 5.33 (risultato di un Phenom II X4) + il 10% darebbe 5.86.... ben molto più basso di un Phenom II X6 che da' 8.02, di gran lunga superiore.

Sulla stessa linea, un teorico Thuban X8 allo stesso OC dovrebbe dare con Cinebench 10.666 (8.02 +33%), mentre per te con un un +7% massimo si avrebbe 8,58, solamente di 0,56 superiore...

Sulla stessa linea, visto la differenza che con il Thuban 1090T il mio massimo OC ottenibile è di 4,5GHz (+900MHz rispetto alla massima frequenza def turbo) mentre per un BD i 4,5GHz sarebbero solamente a +300MHz rispetto alla massima frequenza def turbo.
Chiaro che è tutto teorico, ma se BD si occasse con la stessa percentuale di un Thuban (3.6GHz massima frequenza def --> 4.5GHz = +20%, BD 8150 4,2GHz +20% = 5.04GHz) fornirebbe già un risultato di 11.84, tra l'altro con la possibilità che un 8170 con 300MHz in più sia def che turbo possa salire ancora più in alto.

[calabar]

@Calabar.
Comunque non mi tornano i tuoi calcoli che 2 core in più concederebbero solamente un +7%.
I calcoli non erano miei :p
In ogni caso anche l'esempio che ha portato al 7% supponeva uno scaling perfetto con i core (nonostante il caso di cinebench sia decisamente anomalo nel panorama generale).

Il 7% vien fuori dal fatto che, partendo da un ipc uguale a thuban in single core, in BD devi applicare anche il calo di prestazioni (stimato mediamente nel 20% da AMD) quanto utilizzi entrambi i core di un modulo, quindi sei "frenato" dalla logica condivisa.
Questo handicap non si applica ai k10 perchè a differenza di BD non hanno moduli CMT.

Capito? ;)

[The3DProgrammer]

I calcoli non erano miei :p
In ogni caso anche l'esempio che ha portato al 7% supponeva uno scaling perfetto con i core (nonostante il caso di cinebench sia decisamente anomalo nel panorama generale).

Il 7% vien fuori dal fatto che, partendo da un ipc uguale a thuban in single core, in BD devi applicare anche il calo di prestazioni (stimato mediamente nel 20% da AMD) quanto utilizzi entrambi i core di un modulo, quindi sei "frenato" dalla logica condivisa.
Questo handicap non si applica ai k10 perchè a differenza di BD non hanno moduli CMT.

Capito? ;)

alla fine non servono nemmeno tanto i numeri ipotetici per capire l'importanza di avere un BD forte nel ST, basta guardare le tante recensioni su internet e vedere come in tantissime applicazioni single o MT non spinte, tra cui i giochi (killer applications per il mercato enthusiast) qualsiasi CPU SB based straccia il top di gamma attuale AMD. Che poi paolo per applicazioni non spinte basti un normale PII a 3 GHz sono assolutamente d'accordo (tant'è che nel mio desktop attuale c'è un PII [email protected] e ci stara' ancora a lungo) ma BD sara' un FX, quindi una CPU per la fascia enthusiast, e dovra' almeno pareggiare SB, che sia con l'IPC o con IPC/frequenza (preferisco la prima opzione onestamente).

Comunque, non c'era stata una previsione secondo cui BD server doveva essere presentata tipo il 18 agosto (quella dei furlong)? Mancata anche questa?

[digieffe]

faccio notare a digieffe che se ne suoi conti applica l'IPC di BD=Thuban=1 lo deve fare al netto del fattore 0.8, non lo può stornare poi poichè sarebbe un errore di logica matematica...
Sinceramente non ho capito bene cosa intendi, provo a vedere se intuisco altrimenti correggimi, grazie:
(ipc di un core thuban = 1 = ipc di un core BD) x 8 core x 0.8 fattore di riduzione modulo = 6.4 cores (thuban) di throughput equivalente di BD

6.0 + 7% = 6.4



ciao Paolo scusa se mi permetto di rispondere (dopo Calabar dirà la sua)
@Calabar.

Comunque non mi tornano i tuoi calcoli che 2 core in più concederebbero solamente un +7%.

Risultati Cinebench:

# paolo.oliva2| 1090T @200x22,5 | 4 GB DDR3 @800 MHz | 890FX/SB850 | Seven 64 | 1.36 | 8.02
# Labview | PhenomII X4 975 @ 200*22.5 (4,5 GHz)| 4 GB DDR3 @800 MHz | AMD 890FX | Seven 64 | 1.36 | 5.33

Ho preso questi risultati perché entrambi con Phenom II (X4 e X6) ed entrambi con la stessa frequenza di OC.

Come puoi vedere, il risultato in ST è il medesimo.
Prendendo il risultato in MT, l'X4 da' 5.33.
Ora... un X6 con un +50% di core dovrebbe dare 5.33 + il 50%, cioé 7.995. Il mio Thuban addirittura arriva a 8.02, quindi Cinebench rispetta in pieno la perfetta scalabilità di aumento dei core.

Preciso, non voglio dire che qualsiasi programma fornirà lo stesso vantaggio, ma come ho detto, io ho precisato un vantaggio "fino al" e non sempre.
in questo caso hai ragione perchè questi sono core completi dove ogno core conta 1: quindi a parità di frequenza 4 core danno circa 4x e 6 core danno circa 6x;

Ora... il 7% non ho capito da che calcoli lo tiri fuori...
utilizzerò il tuo steso esempio ipotizzando che sia un BD al posto dei due:

# paolo.oliva2| 1090T @200x22,5 | 4 GB DDR3 @800 MHz | 890FX/SB850 | Seven 64 | 1.36 | 8.02
# BD | xxxx @200x22,5 | 4 GB DDR3 @800 MHz | 890FX/SB850 | Seven 64 | 1.36 | 1.36 x 8 = 10.88 x 80% riduzione di efficienza del modulo per le parti condivise = 8.704

8.704 (BD) / 8.02 (Thuban) = +8.5% (è 8.5 e non 7 poichè l'efficienza in MT de tuo Thuban è 5.89 e non 6 ma siamo li non è +33%)


semplicemente ciò che non consideri e che, quando utilizzi un solo core di un modulo BD fa 1.36, quando utilizzi tutti e 2 i core dello stesso modulo BD per via delle parti condivise fanno:
non 1.36 x 2 = 2.72 ma
1.36 x 2 x 80% (penalizzazione per le parti condivise) = 2.176
2.176 x 4 moduli = 8.704


quindi in parole povere:
con core completi dove ogni core conta 1:
4 core danno circa 4x
6 core danno circa 6x
con core con logica condivisa (modulo) dove ogni coppia di core (dello stesso modulo) conta 2 x 0.8 = 1.6:
4 moduli danno circa 1.6 x 4 = 6.4x (+7%)
o in un altra forma 8 core danno circa 8 x 80% = 6.4x

questo quando nei un moduli sono utilizzati contemporaneamente entrambi i core


EDIT: avevo in parte preparato la risposta ma mi sono dovuto allontanare, nel frattempo hai avuto anche altre risposte

[calabar]

ciao Paolo scusa se mi permetto di rispondere (dopo Calabar dirà la sua)
Ma io ho già detto la mia prima! :p

[XatiX]

Habemus CEO :D

[The3DProgrammer]

Habemus CEO :D

:old: ;)

[digieffe]

come già scritto http://www.hwupgrade.it/forum/showpost.php?p=35798696&postcount=21327 (alle condizioni specificate)

in MT per avere il 50% in più è necessario un ipc più alto del:
BD a 3.6ghz = ipc +29% vs thuban 1100T
BD a 3.9ghz = ipc +19% vs thuban 1100T

[Pat77]

@Calabar.

Comunque non mi tornano i tuoi calcoli che 2 core in più concederebbero solamente un +7%.

Risultati Cinebench:

# paolo.oliva2| 1090T @200x22,5 | 4 GB DDR3 @800 MHz | 890FX/SB850 | Seven 64 | 1.36 | 8.02
# Labview | PhenomII X4 975 @ 200*22.5 (4,5 GHz)| 4 GB DDR3 @800 MHz | AMD 890FX | Seven 64 | 1.36 | 5.33

Ho preso questi risultati perché entrambi con Phenom II (X4 e X6) ed entrambi con la stessa frequenza di OC.

Come puoi vedere, il risultato in ST è il medesimo.
Prendendo il risultato in MT, l'X4 da' 5.33.
Ora... un X6 con un +50% di core dovrebbe dare 5.33 + il 50%, cioé 7.995. Il mio Thuban addirittura arriva a 8.02, quindi Cinebench rispetta in pieno la perfetta scalabilità di aumento dei core.

Preciso, non voglio dire che qualsiasi programma fornirà lo stesso vantaggio, ma come ho detto, io ho precisato un vantaggio "fino al" e non sempre.

Ora... il 7% non ho capito da che calcoli lo tiri fuori... però se da X4 a X6 ci sarebbe un +50% di core contro il +33% dato da un X6 a un X8, in teoria un Thuban dovrebbe dare solamente un +10% contro il +7% di BD... ma 5.33 (risultato di un Phenom II X4) + il 10% darebbe 5.86.... ben molto più basso di un Phenom II X6 che da' 8.02, di gran lunga superiore.

Sulla stessa linea, un teorico Thuban X8 allo stesso OC dovrebbe dare con Cinebench 10.666 (8.02 +33%), mentre per te con un un +7% massimo si avrebbe 8,58, solamente di 0,56 superiore...

Sulla stessa linea, visto la differenza che con il Thuban 1090T il mio massimo OC ottenibile è di 4,5GHz (+900MHz rispetto alla massima frequenza def turbo) mentre per un BD i 4,5GHz sarebbero solamente a +300MHz rispetto alla massima frequenza def turbo.
Chiaro che è tutto teorico, ma se BD si occasse con la stessa percentuale di un Thuban (3.6GHz massima frequenza def --> 4.5GHz = +20%, BD 8150 4,2GHz +20% = 5.04GHz) fornirebbe già un risultato di 11.84, tra l'altro con la possibilità che un 8170 con 300MHz in più sia def che turbo possa salire ancora più in alto.

Ma cinebench non dice tutto, imho.

QUI (http://www.anandtech.com/show/3877/asrock-890fx-deluxe-full-review-and-an-investigation-of-thuban-performance-scaling/7) c'è un articolo interessantissimo su come l'influenza del NB, che su BD dovrebbe essere a 3200, se non ricordo male, basti solo lei ad assicurare un forte incremento di performance, il mio 955 sta a 3,8 ghz con nb a 2600 nel test CPU di 3dmark2011 va meglio di un Phenom 2 a 4,2 ghz ma con nb default, e come si vede nel link postato nelle applicazioni gaming un 3,2 ghz batte un 4 ghz.

[The3DProgrammer]

Ma cinebench non dice tutto, imho.

QUI (http://www.anandtech.com/show/3877/asrock-890fx-deluxe-full-review-and-an-investigation-of-thuban-performance-scaling/7) c'è un articolo interessantissimo su come l'influenza del NB, che su BD dovrebbe essere a 3200, se non ricordo male, basti solo lui ad assicurare un forte incremento di performance, il mio 955 sta a 3,8 ghz con nb a 2600 nel test CPU di 3dmark2011 va meglio di un Phenom 2 a 4,2 ghz ma con nb default, e come si vede nel link postato nelle applicazioni gaming un 3,2 ghz batte un 4 ghz.

ammazza che differenze, review interessantissima che mi ero perso (e grande AT come sempre). Io ricordo che ai tempi quando presi il PII smanettai un bel po col NB ma oltre certe frequenze avevo addirittura un calo di prestazioni..cosa cambia nel NB da deneb a thuban (e cosa cambiera' nel NB di BD?)

[liberato87]

ammazza che differenze, review interessantissima che mi ero perso (e grande AT come sempre). Io ricordo che ai tempi quando presi il PII smanettai un bel po col NB ma oltre certe frequenze avevo addirittura un calo di prestazioni..cosa cambia nel NB da deneb a thuban (e cosa cambiera' nel NB di BD?)

io da quando seguo questo thread ho chiesto e sperato che sarebbe migliorato il controller di memoria perchè finalmente si potevano sfruttare le ram a pieno e ovviamente avere un incremento di prestazioni.
lasciando il nb a 2000 praticamente se uno ha le ram 1333 o 2000 non cambia nulla. è quindi importante occare il nb e sul thuban si può portare anche a 3000 mantentendo la stabilità e senza bisogno di un grandissimo overvolt, ovviamente impostando nb a 3000 il guadagno è veramente notevole.
e quindi pensare che su BD a def stia a 3200 (che è invece il massimo che si può avere con il thuban e con salti mortali per mantenere la stabilità) e se si aggiungerebbe (si spera) un buon margine di overclock mi fa essere ancora più fiducioso ( se non altro perchè finalmente si potranno sfruttare le ram come si deve, per esempio le ram che ho io sono certificate su intel 2200 8-8-8-24! mentre qui su amd neanche bootano.. e comunque avendo il nb a 3000 non sarebbero sfruttate a pieno; io il massimo guadagno ce l ho con 1866 7-7-7-21)

se hai notato un calo di prestazioni è probabilmente perchè non eri stabile al 100% (anche io nei vari bench che ho fatto ho notato appunto che spesso anche se non crashava i risultati erano peggiori, quindi si doveva incrementare un pò il vcore, e questo vale sia per la cpu che per il nb). ->questa è solo un mia opinione comunque.

[phicrand_6358]

Sinceramente non ho capito bene cosa intendi, provo a vedere se intuisco altrimenti correggimi, grazie:
(ipc di un core thuban = 1 = ipc di un core BD) x 8 core x 0.8 fattore di riduzione modulo = 6.4 cores (thuban) di throughput equivalente di BD

6.0 + 7% = 6.4



ciao Paolo scusa se mi permetto di rispondere (dopo Calabar dirà la sua)

in questo caso hai ragione perchè questi sono core completi dove ogno core conta 1: quindi a parità di frequenza 4 core danno circa 4x e 6 core danno circa 6x;


utilizzerò il tuo steso esempio ipotizzando che sia un BD al posto dei due:

# paolo.oliva2| 1090T @200x22,5 | 4 GB DDR3 @800 MHz | 890FX/SB850 | Seven 64 | 1.36 | 8.02
# BD | xxxx @200x22,5 | 4 GB DDR3 @800 MHz | 890FX/SB850 | Seven 64 | 1.36 | 1.36 x 8 = 10.88 x 80% riduzione di efficienza del modulo per le parti condivise = 8.704

8.704 (BD) / 8.02 (Thuban) = +8.5% (è 8.5 e non 7 poichè l'efficienza in MT de tuo Thuban è 5.89 e non 6 ma siamo li non è +33%)


semplicemente ciò che non consideri e che, quando utilizzi un solo core di un modulo BD fa 1.36, quando utilizzi tutti e 2 i core dello stesso modulo BD per via delle parti condivise fanno:
non 1.36 x 2 = 2.72 ma
1.36 x 2 x 80% (penalizzazione per le parti condivise) = 2.176
2.176 x 4 moduli = 8.704


quindi in parole povere:
con core completi dove ogni core conta 1:
4 core danno circa 4x
6 core danno circa 6x
con core con logica condivisa (modulo) dove ogni coppia di core (dello stesso modulo) conta 2 x 0.8 = 1.6:
4 moduli danno circa 1.6 x 4 = 6.4x (+7%)
o in un altra forma 8 core danno circa 8 x 80% = 6.4x

questo quando nei un moduli sono utilizzati contemporaneamente entrambi i core


EDIT: avevo in parte preparato la risposta ma mi sono dovuto allontanare, nel frattempo hai avuto anche altre risposte

no... cosi assegni a BD un IPC inferiore del 20% in MT rispetto a Thuban, cioè secondo i tuoi conti
IPC ST=Thuban
IPC MT=Thuban - 20%
il che non può essere
in pratica tu assegni una penalità del 20% quando BD usa tutti i core...

ricordo che l'efficienza del famoso 80% si riferiva solamente rispetto allo stesso processore ma costruito senza logica condivisa ma esclusiva, quindi non è applicabile a confronti con altre cpu sul mercato

tipo come dire "con lo zaino pieno addosso salto la metà", ma la metà di quanto salto io potrebbe pure essere il doppio di quanto saltano gli altri...

[The3DProgrammer]

io da quando seguo questo thread ho chiesto e sperato che sarebbe migliorato il controller di memoria perchè finalmente si potevano sfruttare le ram a pieno e ovviamente avere un incremento di prestazioni.
lasciando il nb a 2000 praticamente se uno ha le ram 1333 o 2000 non cambia nulla. è quindi importante occare il nb e sul thuban si può portare anche a 3000 mantentendo la stabilità e senza bisogno di un grandissimo overvolt, ovviamente impostando nb a 3000 il guadagno è veramente notevole.
e quindi pensare che su BD a def stia a 3200 (che è invece il massimo che si può avere con il thuban e con salti mortali per mantenere la stabilità) e se si aggiungerebbe (si spera) un buon margine di overclock mi fa essere ancora più fiducioso ( se non altro perchè finalmente si potranno sfruttare le ram come si deve, per esempio le ram che ho io sono certificate su intel 2200 8-8-8-24! mentre qui su amd neanche bootano.. e comunque avendo il nb a 3000 non sarebbero sfruttate a pieno; io il massimo guadagno ce l ho con 1866 7-7-7-21)

se hai notato un calo di prestazioni è probabilmente perchè non eri stabile al 100% (anche io nei vari bench che ho fatto ho notato appunto che spesso anche se non crashava i risultati erano peggiori, quindi si doveva incrementare un pò il vcore, e questo vale sia per la cpu che per il nb). ->questa è solo un mia opinione comunque.

ma tra l'altro se non ricordo male sui primi PII la frequenza della L3 era legata alla frequenza del NB, su thuban è ancora cosi? Su bd sara' cosi? O non è mai stato cosi' e mi ricordo male io?

[calabar]

no... cosi assegni a BD un IPC inferiore del 20% in MT rispetto a Thuban [...]
Esatto, e questo sarebbe il risultato se l'ipc per un task single thread di BD e del k10 fossero uguali, perchè quella (-20%) è la perdita prestazionale che AMD ha valutato per l'utilizzo del CMT.
Ricorda che i core del k10, per quanto ormai vecchi, lenti e tutto quello che vuoi, sono core senza elementi condivisi che ne limitano le prestazioni in multithread (ossia quando, con BD, si utilizzano entrambi i core del modulo e le parti condivise devono occuparsi di due core).

[The3DProgrammer]

ricordo che l'efficienza del famoso 80% si riferiva solamente rispetto allo stesso processore ma costruito senza logica condivisa ma esclusiva, quindi non è applicabile a confronti con altre cpu sul mercato


io se ho capito bene tutti sti calcoli (che onestamente non ho seguito perchè gia' ne faccio abbastanza al lavoro :fagiano: ) si basano sul presupposto ipotetico che un core BD, costruito con logica esclusiva (quindi senza CMT) abbia lo stesso IPC di un core thuban. Di conseguenza, considerando il CMT, è giusto togliergli quel 20% sugli 8 core.

Il ragionamento da fare alla fine pero' è anche sull'area occupatanel die: Ricordiamoci che un BD 4 moduli è grosso solo il 12% (era il 12 o altro?) in + di un ipotetico BD 4 core senza CMT, quindi nettamente + piccolo di un altro ipotetico BD con 8 core senza CMT

[Pat77]

Esatto, e questo sarebbe il risultato se l'ipc per un task single thread di BD e del k10 fossero uguali, perchè quella (-20%) è la perdita prestazionale che AMD ha valutato per l'utilizzo del CMT.
Ricorda che i core del k10, per quanto ormai vecchi, lenti e tutto quello che vuoi, sono core senza elementi condivisi che ne limitano le prestazioni in multithread (ossia quando, con BD, si utilizzano entrambi i core del modulo e le parti condivise devono occuparsi di due core).

Vedremo sarà interessante soprattutto valutare il quad fx e l'esa fx vs i rispettivi phenom 2 a parità di frequenza, come ripeto già solo per le differenze del controller ram prevedo un bel boost, tendenzialmente in aumento con applicazioni fortemente multi.

[Phenomenale]

Qualunque sarà l' IPC del Bulldozer, ormai disponiamo di hardware molto potenti rispetto a quello che avevamo in casa solo 5 anni fà, ma i software scritti per sfruttarli appieno dove sono? :(
Immagino chi ad ottobre si farà il computer nuovo con Bulldozer FX... :lamer: avrà sotto il cofano 8 CPU che il fumetto di AMD rappresenta come una squadra di 8 ninja :p , ma quando quegli eroi potranno combattere tutti insieme? A parte Cinebench e Linx :rolleyes: oggi già si fatica a saturare un quad con una singola applicazione! :nonsifa:
Direi che la filosofia attuale dei software è il limite, gli sviluppatori di programmi dovrebbero cominciare a pensare multithread IMHO..... :vicini:

[marchigiano]

Insomma il posticipo non la certo deciso lui e comunque sia sarebbe ingenuo pensare che è stato pianificato due giorni prima della presunta presentazione a giugno.
E' ancora più ingenuo pensare che anche lui non sia sotto all'NDA e che avesse dovuto dirlo prima per qualche forma di ridicolo cameratismo...

ma infatti non dico che jf ha ha sbagliato, lui fa il suo lavoro e dice quello che gli dicono che deve dire, proprio per questo, visto che gli dicono di dire a volte anche cose non vere, non credo a quello che dice

in fondo il lavoro del pr è questo...

[The3DProgrammer]

Qualunque sarà l' IPC del Bulldozer, ormai disponiamo di hardware molto potenti rispetto a quello che avevamo in casa solo 5 anni fà, ma i software scritti per sfruttarli appieno dove sono? :(
Immagino chi ad ottobre si farà il computer nuovo con Bulldozer FX... :lamer: avrà sotto il cofano 8 CPU che il fumetto di AMD rappresenta come una squadra di 8 ninja :p , ma quando quegli eroi potranno combattere tutti insieme? A parte Cinebench e Linx :rolleyes: oggi già si fatica a saturare un quad con una singola applicazione! :nonsifa:
Direi che la filosofia attuale dei software è il limite, gli sviluppatori di programmi dovrebbero cominciare a pensare multithread IMHO..... :vicini:

La programmazione parallela è difficile, costosa ed estremamente bug prone. Fin quando non ci saranno degli strumenti di sviluppo in grado di facilitare lo sviluppo di applicazioni MT sara' difficile vedere le software house investirci pesantemente. Da non trascurare inoltre che ci sono intere classi di problemi intrinsecamente sequenziali (non potranno mai essere risolte cioè tramite algoritmi paralleli).

[crazyduck00]

Qualunque sarà l' IPC del Bulldozer, ormai disponiamo di hardware molto potenti rispetto a quello che avevamo in casa solo 5 anni fà, ma i software scritti per sfruttarli appieno dove sono? :(
Immagino chi ad ottobre si farà il computer nuovo con Bulldozer FX... :lamer: avrà sotto il cofano 8 CPU che il fumetto di AMD rappresenta come una squadra di 8 ninja :p , ma quando quegli eroi potranno combattere tutti insieme? A parte Cinebench e Linx :rolleyes: oggi già si fatica a saturare un quad con una singola applicazione! :nonsifa:
Direi che la filosofia attuale dei software è il limite, gli sviluppatori di programmi dovrebbero cominciare a pensare multithread IMHO..... :vicini:

Il discorso è diverso: le cpu a 8 core non nascono per tutti gli utenti, ma vengono prodotti per quella fascia di utenza dove utilizzano applicazioni multi core, e ti assicuro che fare editing video o rendering video, lavorare su grafica 3d vettoriale ecc ecc sfrutta a pieno 6 core (8 non lo so ancora).
AMD o azienda alternativa per gli utenti che usano il pc in daily (games, multimedia, qualche editing video leggero casalingo, applicazioni di vario genere quotidiano) produce x2 e x4, per cui avere vedere i ninja nei fumetti è solo marketing indirizzato a una certa fetta di utenti, tutti gli altri si prendono processori con meno core.
Le applicazioni oggi utilizzate è vero sono poche quelle che sfruttano 6 o + core, ma è anche vero che ci sono utenti che lavorano SOLAMENTE SU QUELLE POCHE (applicaz.citate prima).
In questi tipi di tread ( e anche molti altri utenti appassionati che vogliono il massimo anche se fanno il minimo con il pc) ovviamente non si sta a guardare la motivazione per la quale vengono prodotti dalle aziende o a quale fascia di mercato sono destinate, ma semplicmente essendo un forum di appassionati, si aquistano anche i top per occarli testarli, poi fa poco se li usi o meno.
Es: guarda la firma di paolo.oliva2, ha multi sistemi degni di programmatori di grafica 3d o montatori cinematografici :D , ma prova a domandargli oltre a smanettarci su l'oc, cosa altro ci fa con i computer ? Sicuramente apre firefox, guarda qualche film, e fa i test con speedtest ehehehehe, i suoi processori x6 x4 e quello che SICURAMENTE prendera x8 fx li usa solo per smanettarci sull'oc e poi dopo che ne è sazio li usa per giocarci a PACMAN ;)

Per qui questo discorso è molto complesso ma anche molto semplice.
Esistono automobili utilitarie e poi c'è la Ferrari, io posso prendermi un utilitaria per usarla in cio ke davvero mi serve, ma posso prendermi un ferrari per fare comunque la stessa cosa o smanettarci per sfizio su, tanto non la sfruttero mai a pieno la ferrari soprattutto su strade urbane (software che io uso). Ma c'è anche chi con la ferrari ci corre davvero sui circuiti (software adeguati per quel mezzo), per cui la sfrutta in pieno e sempre.

PS: oggi ormai il 40% di applicazioni usano sicuramente quattro core. Ai giochi ne bastano a dire il vero anche 2 (ancora) ma il 50% di games iniziano a sfruttarne 4 core (vedi MDW3, BC3, ecc che usciranno a ottobre).

[Phenomenale]

Fin quando non ci saranno degli strumenti di sviluppo in grado di facilitare lo sviluppo di applicazioni MT sara' difficile vedere le software house investirci pesantemente
Hai ragione!!! :angel:
Però anche progettare nuovi microprocessori su nuovi processi a meno nanometri richiede pesanti investimenti: e vengono fatti. :)
Solo nello sviluppo software non si vuole cacciare fuori soldi per investimenti, il vecchio compilatore C monolitico funziona e si tira avanti ad usare quello...
Nell' hardware ogni nuovo dispositivo è più veloce del precedente, solo nel software ogni nuova versione è più lenta e pesante della precedente. :doh:

Il succo della questione è che voglio software Bulldozer-ready, non Sempron-ready :ncomment:

[crazyduck00]

Hai ragione!!! :angel:
Però anche progettare nuovi microprocessori su nuovi processi a meno nanometri richiede pesanti investimenti: e vengono fatti. :)
Solo nello sviluppo software non si vuole cacciare fuori soldi per investimenti, il vecchio compilatore C monolitico funziona e si tira avanti ad usare quello...
Nell' hardware ogni nuovo dispositivo è più veloce del precedente, solo nel software ogni nuova versione è più lenta e pesante della precedente. :doh:

Il succo della questione è che voglio software Bulldozer-ready, non Sempron-ready :ncomment:

mettici anche che il 70% di software sono scritti per andar meglio con istruzioni Intel...e la pappetta è pronta e amara.

[maurilio968]

PS: oggi ormai il 40% di applicazioni usano sicuramente quattro core. Ai giochi ne bastano a dire il vero anche 2 (ancora) ma il 50% di games iniziano a sfruttarne 4 core (vedi MDW3, BC3, ecc che usciranno a ottobre).

Piccolo Ot

tra quelli che usano 4 core mettiamoci anche Deus Ex Human Revolution che è uscito oggi

http://www.hwupgrade.it/forum/showpost.php?p=35801484&postcount=17

Fine OT.

[Megakirops]

Scusate l'OT ma non posso più trattenermi. Fate attenzione all'uso dell'italiano, ho visto numerosi post dove sé ne fà un uso scorretto, ad esempio ''qui'' al posto di ''cui'', oppure ''la detto'' invece di ''l'ha detto o lo ha detto''.
Non è per presunzione ma fate più attenzione, stiamo in Italia.

[fastleo63]

...Fate attenzione all'uso dell'italiano...Non è per presunzione ma fate più attenzione, stiamo in Italia.Mi associo. Abbiamo la fortuna di avere una delle più belle lingue esistenti. E' un pò un peccato, anche se siamo in un forum tecnico e non "letterario", storpiarla così... :)

[paolo.oliva2]

no... cosi assegni a BD un IPC inferiore del 20% in MT rispetto a Thuban, cioè secondo i tuoi conti
IPC ST=Thuban
IPC MT=Thuban - 20%
il che non può essere
in pratica tu assegni una penalità del 20% quando BD usa tutti i core...

ricordo che l'efficienza del famoso 80% si riferiva solamente rispetto allo stesso processore ma costruito senza logica condivisa ma esclusiva, quindi non è applicabile a confronti con altre cpu sul mercato

tipo come dire "con lo zaino pieno addosso salto la metà", ma la metà di quanto salto io potrebbe pure essere il doppio di quanto saltano gli altri...

Infatti... quoto.

Praticamente se applicassimo questo -20% non lo applicheremmo ad un BD stile Phenom II ma ad un BD stile modulo, ma facendo così, è come se parlassimo che BD avrà una diminuzione del 20% di IPC rispetto al Phenom II.

Siccome AMD ha più volte detto che BD avrà un IPC superiore rispetto al Phenom, al più il ragionamento sarebbe che BD perderebbe un -20% rispetto al suo vantaggio per la logica del modulo e non -20% rispetto al Phenom.

A prescindere da questo, mi sembra chiaro che se un BD X8 concedesse margini minimi su un BD X6 la stessa logica di aumentare il numero dei core di un procio non varrebbe la spesa superiore, per cui i guadagni chiaramente saranno variabili rispetto al programma utilizzato, ma si deve comunque prendere atto che vi sono programmi in cui il guadagno è lineare al numero dei core e di conseguenza si potrebbe arrivare "fino al" +33%, specialmente anche sul fatto che la stessa architettura prevederebbe già un X10 e chissà se un X12 strada facendo.

[calabar]

Infatti... quoto.
Ma come quoti!! :doh:
E io che pensavo avessi capito il senso del ragionamento! :Prrr:

[phicrand_6358]

Ma come quoti!! :doh:
E io che pensavo avessi capito il senso del ragionamento! :Prrr:

a me pare l'unico che ha capito il ragionamento mio...:O

assegnare il meno 20% di IPC in MT rispetto a quello in ST alla stessa CPU mi sembrano "i cunti ra ricuttara"...

[The3DProgrammer]

A prescindere da questo, mi sembra chiaro che se un BD X8 concedesse margini minimi su un BD X6 la stessa logica di aumentare il numero dei core di un procio non varrebbe la spesa superiore

e invece sta proprio qua il punto. Perchè se un BD x8 CMT concedesse margini minimi su un ipotetico BD X6 puro (senza CMT) sarebbe comunque un guadagno enorme visto che effettivamente un BD x8 CMT è poco + grosso di un quadcore. E proprio il motivo per cui hanno introdotto CMT, e non creato qualcosa di simile a SMT o aggiunto semplicemente nuovi core

[calabar]

a me pare l'unico che ha capito il ragionamento mio...:O
assegnare il meno 20% di IPC in MT rispetto a quello in ST alla stessa CPU mi sembrano "i cunti ra ricuttara"...
Ma è il tuo ragionamento che si basa sul non aver capito l'esempio! :p
Se paolo ti "quota", dimostra di non averlo capito neanche lui! ;)

...indipendentemente da cosa "i cunti ra ricuttara" voglia dire... :eek:

[The3DProgrammer]

Ma è il tuo ragionamento che si basa sul non aver capito l'esempio! :p
Se paolo ti "quota", dimostra di non averlo capito neanche lui! ;)

...indipendentemente da cosa "i cunti ra ricuttara" voglia dire... :eek:

i conti della ricottara (di solito le vecchiette di paese che fanno le ricotte, che non sono esattamente bravissime a fare i conti :p )

[phicrand_6358]

Ma è il tuo ragionamento che si basa sul non aver capito l'esempio! :p
Se paolo ti "quota", dimostra di non averlo capito neanche lui! ;)

...indipendentemente da cosa "i cunti ra ricuttara" voglia dire... :eek:

io l'esempio l'ho capito... faccio solo notare che è basato su basi, come dire,"fragili"...:fagiano: :stordita:

[phicrand_6358]

i conti della ricottara (di solito le vecchiette di paese che fanno le ricotte, che non sono esattamente bravissime a fare i conti :p )

bene... anche in calabria si dice allora :D

[paolo.oliva2]

Aspetta, cerco di spiegarmi meglio su 2 cose.

Che il discorso modulo con parti condivise di 2 core non possa esprimere la stessa potenza di 2 core ben distinti, è una cosa, e la stessa AMD a dirlo, con il teorico -20%.

Il punto è che AMD ha detto che il core BDà è più potente del core Phenom II, quindi il -20% sarebbe già compreso nel risultato che comunque BD avrà un IPC superiore al Phenom II condivisione parti dei core nel modulo compresa.

Ora... se qui parliamo che un BD perderà un 20% rispetto al Phenom II, lo si interpreta che BD avrà un 20% in meno di IPC rispetto al Phenom II... mentre il discorso è che il CMT perde un -20% di potenza pura ma comunque portando altri vantaggi (costi, TDP, frequenze, numero dei core) ma sempre valutando a parità di IPC su core BD e non BD-Phenom II.

Per il discorso del guadagno +7% di un X8 rispetto ad un X6, io faccio un discorso a parte, dettato più dalla logica che dai paroloni.

X6 = 100, X8 = 107 (+7%).

Se il guadagno fosse solamente del 7%, un X8 di per sé avrebbe già un rapporto prestazioni/prezzo peggiore rispetto ad un X6, in quanto già solamente il costo di produzione (die + grande) sarebbe di gran lunga superiore.

Inoltre... quanto TDP in più può generare un X8 rispetto ad un X6? Certamente superiore al 7%, quindi teoricamente un X6 potrebbe avere una frequenza superiore del 7% rispetto ad un X8 con la risultante che un X6, ad un costo inferiore, potrebbe fornire la stessa potenza di un X8 ad una frequenza inferiore.

Io non è che voglio avere ragione e non voglio dire che sia tutto lineare... però se applicassimo percentuali così basse all'aumentare del numero dei core, già ora avremmo degli X4 che in MT dovrebbero andare meno degli X2.
Chiaramente il discorso è nell'MT, perché, per assurdo, nel discorso ST meno core ci sono, meno TDP ha il procio e più alta (teoricamente) sarà la frequenza operativa.

[calabar]

io l'esempio l'ho capito... faccio solo notare che è basato su basi, come dire,"fragili"...:fagiano: :stordita:
A me pare che le basi siano invece abbastanza solide, e cioè:
- Un calo prestazionale del 20% dichiarato da AMD per l'approccio CMT (abbastanza solido, vista la fonte, anche se un po' adattato alle circostanze)
- La supposizione di un ipc single thread identico al k10 (e questa è solidissima, dato che è l'ipotesi necessaria per arrivare a quelle conclusioni)

No. Quella è la perdita prestazionale che un singolo core ha subito a causa della progettazione con risorse condivise rispetto alla prestazione che avrebbe avuto se fosse stato progettato senza la condivisione.

Esattamente. Il che grossomodo dovrebbe equivalere alle prestazioni di un core all'interno di un modulo di BD quando l'altro modulo non è in uso (ossia quando non condivide la logica con l'altro core, quindi ce l'ha tutta per se).

Non è un valore esatto (ma anche il famoso 20% è una stima), anzi a mio parere potrebbe essere una stima per difetto: come affermavo in precedenza, avendo il singolo core a disposizione tutta per se una logica nata per gestire due core, la forbice potrebbe persino aumentare un poco. In tal caso il famoso "7%" si assottiglierebbe ulteriormente.

Il punto è che AMD ha detto che il core BDà è più potente del core Phenom II, quindi il -20% sarebbe già compreso nel risultato che comunque BD avrà un IPC superiore al Phenom II condivisione parti dei core nel modulo compresa.
NON nell'esempio fatto dall'utente, dove un ipc pari in single thread era la premessa di tutto il ragionamento. ;)

Se il guadagno fosse solamente del 7%, un X8 di per sé avrebbe già un rapporto prestazioni/prezzo peggiore rispetto ad un X6, in quanto già solamente il costo di produzione (die + grande) sarebbe di gran lunga superiore.
Ancora NO, l'x8 con CMT ha un die più piccolo di un BD x6 con 6 core completi. Se non sbaglio AMD dichiarava che un modulo CMT aveva una dimensione superiore del 12% rispetto ad un core completo.
Quindi avremo un 1x6 = 60 (6 core completi) contro 1,12x4 = 4,48 (4 moduli CMT, ossia 8 core).
La conclusione sarebbe comunque un BD fallimentare, ma per altri motivi ;)

PS: la comparazione sarebbe da fare con i 6 core thuban, ma in questo caso non abbiamo dati per farla. Possiamo però chiudere un occhio e supporla identica visto l'identico ipc single core che era la premessa del ragionamento.

[The3DProgrammer]

No. Quella è la perdita prestazionale che un singolo core ha subito a causa della progettazione con risorse condivise rispetto alla prestazione che avrebbe avuto se fosse stato progettato senza la condivisione.



http://blogs.amd.com/work/2010/08/30/bulldozer-20-questions-%e2%80%93-part-2/


no aspe, vediamo se ho capito cio' che intendi: prendiamo un core BD che supponiamo senza CMT, poi prendiamo un modulo BD con CMT, e su entrambi eseguiamo la stessa applicazione single thread ALU intensive: secondo te nel caso 2 andrebbe il 20% + lenta che nel caso uno?

[calabar]

no aspe, vediamo se ho capito cio' che intendi: prendiamo un core BD che supponiamo senza CMT, poi prendiamo un modulo BD con CMT, e su entrambi eseguiamo la stessa applicazione single thread ALU intensive: secondo te nel caso 2 andrebbe il 20% + lenta che nel caso uno?
Una cosa del genere, ma per capirci meglio, poniamo l'esempio in questi termini:
Abbiamo un task multithread perfettamente parallelizzabile da eseguire su due processori:
- uno composto da un modulo BD con CMT
- uno composto da due core completi di BD (senza CMT)
Nel primo caso avresti un calo del 20% nelle prestazioni.

Il 20% naturalmente è una stima media, dipende dal task in questione.

[deidara80]

7 ottobre RAGE
2 novembre Battlefield 3
11 novembre The Elder Scrolls V: Skyrim


secondo voi farà in tempo amd?
di solito quali sono le tempistiche tra presentazione e disponibilità effetiva nei negozi?
io per battlefield 3 vorrei avere un pc nuovo.

[Jean240]

7 ottobre RAGE
2 novembre Battlefield 3
11 novembre The Elder Scrolls V: Skyrim


secondo voi farà in tempo amd?
di solito quali sono le tempistiche tra presentazione e disponibilità effetiva nei negozi?
io per battlefield 3 vorrei avere un pc nuovo.

Per quelle date spero proprio di si!!!!

[calabar]

I due core di un modulo hanno certe prestazioni perché progettati in un certo modo, il fatto che il secondo sia attivo o meno non cambia le prestazioni del singolo core non cambia le prestazioni in peggio, ma più facilmente in meglio a causa dell'esclusività delle risorse condivise.
Ecco, direi che è questo il punto in cui secondo me sbagli.
Il compromesso che si ha con CMT è una logica che deve servire due core. Quando li serve entrambi deve suddividere la sua capacità di fornire le operazioni ai core (perchè il suo throughput è sempre lo stesso, che serva uno o due core), e questo provoca il calo di prestazioni quantificato nel -20% (nell'approssimazione di cui abbiamo parlato sopra).

Vorrei far notare che se non fosse così il progetto BD perderebbe moltissimo del suo appeal. É proprio la possibilità di usare le risorse condivise su un singolo core aumentando l'ipc quando per i task poco parallelizzati a rendere questa architettura vincente.
Altrimenti non avrebbe senso la scelta fatta con il CMT, che a causa di quel -20% stimato da AMD, condannerebbe BD ad essere sempre molto inferiore alla concorrenza (che non ha questo handicap) nella applicazioni single thread, seppure magari efficiente in quelle multithread, mantenendo quello che è ora il difetto principale dei k10 rispetto alla concorrenza.

Quello che non afferri è che la prima e la seconda questione riguardano entrambe le scelte architetturali. L'IPC è quello di una architettura, ed in questo è già considerata qualunque perdita prestazionale dovuta a scelte di privilegiare altro (die size, per esempio). Quindi nell'ipotesi che l'IPC sia lo stesso del K10, non c'è da moltiplicare per nessun 80%, perché fa già parte dell'architettura.
In base a quanto detto sopra, quindi, è sbagliata anche questa considerazione.
Ossia... l'utente che ha fatto i calcoli che sono il pomo della discordia, ha supposto un IPC identico nelle applicazioni single thread.
Quindi è ovvio che nel momento in cui si utilizzino tutti i core dei moduli, sia necessario applicare quel -20%.
E da li nasce tutto il ragionamento.

[phicrand_6358]

Quindi è ovvio che nel momento in cui si utilizzino tutti i core dei moduli, sia necessario applicare quel -20%.
E da li nasce tutto il ragionamento.

aridaje...:rolleyes:
è proprio questo che si contesta...
AMD non ha dichiarato assolutamente sto fatto... è una vostra interpretazione che definire opinabile è anche riduttivo...

[calabar]

aridaje...:rolleyes:
è proprio questo che si contesta...
AMD non ha dichiarato assolutamente sto fatto... è una vostra interpretazione che definire opinabile è anche riduttivo...
Questo è vero.
Ma è un'interpretazione che su questo topic nessuno ha mai contestato da quando sono emerse le prime specifiche sull'architettura.
Anche perchè basata su un ragionamento logico: AMD ha dichiarato che il calo di prestazioni è dovuto alla condivisione di risorse. Nel momento in cui il secondo core del modulo è inattivo, non c'è nulla da condividere e non c'è più motivo per quel calo.

E aggiungo, se così non fosse, gli ingegneri AMD si sarebbero bevuti il cervello, eliminando uno dei principali vantaggi di un'architettura di questo tipo.
Prima vanno a dire che SMT non è una buona tecnologia perchè in certi contesti fa perdere prestazioni, poi ne implementano una loro che invece fa perdere il 20% in TUTTE le condizioni. La cosa è senza senso.

[calabar]

Non e' che mi sbaglio, lo ha detto AMD. [...]
L'80% e' rispetto ad un'architettura ipotetica che non esiste, non c'e' nessun 80% da applicare a niente per fare delle simulazioni dei poveri [...]
Veramente AMD non ha mai specificato nulla del genere.
Inoltre sei davvero sicuro che tale situazione non sia invece simulabile, anche se non in maniera precisa, semplicemente mettendo a dormire un core nel modulo? Sicuro che BD non lo permetta?

Io credo che lo sia, e che BD potrà in questo modo avere prestazioni interessanti in single thread.
Se così non fosse, ripeto, sarebbe fallimentare, perchè non risolverebbe il problema maggiore che hanno ora i k10 rispetto ai processori della concorrenza: prestazioni deludenti in ST.

[paolo.oliva2]

Ancora NO, l'x8 con CMT ha un die più piccolo di un BD x6 con 6 core completi. Se non sbaglio AMD dichiarava che un modulo CMT aveva una dimensione superiore del 12% rispetto ad un core completo.
Quindi avremo un 1x6 = 60 (6 core completi) contro 1,12x4 = 4,48 (4 moduli CMT, ossia 8 core).
La conclusione sarebbe comunque un BD fallimentare, ma per altri motivi ;)

PS: la comparazione sarebbe da fare con i 6 core thuban, ma in questo caso non abbiamo dati per farla. Possiamo però chiudere un occhio e supporla identica visto l'identico ipc single core che era la premessa del ragionamento.

Aspetta, non facciamo una confusione inutile, lasciamo perdere il discorso confronto con il Thuban.

Il discorso io l'ho precisato sul guadagno di avere 8 core al posto di 6 core e mi hai postato che un 8 core guadagnerebbe solamente il 7% sul 6 core per calcoli fatti da altri.

Il costo di produzione di un BD X6 nativo rispetto ad un BD X8 nativo non ha nulla a che vedere con il CMT di BD nei confronti del Thuban, ma rimane sempre valido tra un CMT X6 ed un CMT X8.

Detto papale... valutando che MC, I/O ed altro sono fissi indipendentemente dal numero dei core, un BD X8 avrebbe 2 core, 1MB di L2, 2MB di L3 che aumenterebbero il costo produzione (superficie silicio quindi die a wafer e aumento delle possibilità di scarto per transistor fallati), mettiamo solamente del 25%.
Ora... chi aumenterebbe i costi del 25% con aumenti prestazionali solamente del 7% quando questo guadagno sarebbe già ottenibile dalla frequenza più alta perché sicuramente un X6 avrebbe il 7% in meno di TDP rispetto ad un X8? BD X8 125W TDP 3,6/4,2GHz, un BD X6 nativo non penso che avrebbe problemi ad essere 3,850/4,5GHz (+7%) e rientrare nei 125W TDP.

Io ti ho solo fatto vedere che con Cinebench si guadagna il 50% da un X4 ad un X6 e che quindi, comunque, il discorso CMT non incide nel mio ragionamento, in quanto già un BD X6 è composto da 3 moduli, quindi il valore ottenuto da 3 moduli di MT rispecchierà papale papale la linea con il 4° modulo. Se poi vogliamo fare il confronto con il Thuban, sarebbe ipotizzabile che questo guadagna il 50%, un BD 6 da un X4 il 50% -20% teorizzato da AMD, quindi sarebbe il 40%. Proiettandolo su BD, ammesso che il ragionamento CMT si applichi, da un teorico +33% si passerebbe a 33% -20% = 26% e rotti, ma comunque sempre piuttosto distanti dal 7%.

Poi tutto ciò sarà ampiamente verificabile, in quanto mi rendo disponibile a fare tutti i test quando avrò BD, disabilitando 1 o più moduli.

P.S.
Poi, tra parentesi, rifletto anche su un altro punto che è in contrasto con quanto dici. Ti ricordi quando discutevamo di far "lavorare" 1TH a modulo supponendo che così un 4 moduli potesse operare con 4TH senza il calo di CMT? JF aveva risposto che BD "rendeva" comunque meglio con il discorso di 2 TH a modulo. Ora... basta fare questa riflessione: un BD X8 lavora a 3,6GHz con 4 moduli e 4,2GHz con 2 moduli. Ora... se noi facessimo lavorare 4 TH su 4 moduli (cioè 1 TH a modulo), rinunceremmo alla frequenza Turbo che è di 600MHz, a favore di 2 moduli con 4 TH con 600MHz di frequenza superiore. Se noi applicassimo il -20% per il CMT, cosa otterremmo? Che i core dovrebbero lavorare ad una frequenza maggiore del 20% per confermare il -20% del CMT, e per confermare quanto detto da JF da 3,6GHz si dovrebbe passare ad almeno 4,340GHz per ottenere unaparità ed almeno 4,4-4,5GHz per essere vantaggioso. A questo punto mi sembra chiaro che il discorso 20% o è sbagliato, oppure le frequenze turbo dovrebbero essere maggiori. Visto che ormai i +600MHz del turbo sembrano confermati... mi sembra chiaro che la teoria del -20% debba necessariamente essere differente, presumibilmente AMD avrà attuato cambiamenti/ottimizzazioni agli ES B0 di dicembre 2010, visto che comunque quel 20% era stato tirato fuori in quel periodo.

Vedi, io concordo che senza avere dati precisi tutto è discutibile, ma non vedo il motivo per il quale tutto debba essere necessariamente visto verso il basso. Fino ad ora tutto quanto era negativo è puntualmente caduto, vedi frequenze basse e tanto altro. Mi sa che anche altri presupposti negativi svaniranno.

Edit
Comincio a capire come sia scappato fuori quel +7%. Per me hanno ipotizzato una perdita del 20% ogni 2 core tra BD a Thuban, quindi 4 moduli BD, 8 core, perderebbe il 20% ogni modulo, arrivando al fatto che 4 moduli perderebbero l'80% di 8 core stile Thuban, e quindi da qui il 7% ipotizzato. Ma questo fa acqua da tutte le parti, perché parte già dal presupposto che BD abbia un IPC uguale a quello del Phenom II e che quindi AMD avrebbe investito soldi e tempo in questi 5 anni unicamente per progettare un procio con meno transistor e meno TDP aumentando unicamente il numero totale dei core. Mi sembra una vaccata pazzesca.... Al più il CMT perde il 20%, ma questo è tutt'altra storia rispetto all'IPC di BD e quindi ad un teorico BD non CMT e BD CMT, ma nulla a che vedere tra BD e Thuban.

[Spitfire84]

http://www.bit-tech.net/news/hardware/2011/08/26/amd-bulldozer-to-ship-within-the-next-week/1

[calabar]

Il costo di produzione di un BD X6 nativo rispetto ad un BD X8 nativo non ha nulla a che vedere con il CMT di BD nei confronti del Thuban, ma rimane sempre valido tra un CMT X6 ed un CMT X8.
Vedo che non ci capiamo.
Il famoso "+7%" dell'esempio era relativo ad un BD x8 con CMT nei confronti di un x6 senza CMT.
Che sia un x6 thuban o un x6 BD non CMT non importa, dato che stavamo assumendo che avessero ipc identico.
Poniamo però che, come dici tu, si tratti appunto di un x6 BD non CMT, dato che conosciamo l'incremento di dimensione del modulo (dichiarato da AMD) e questo permette il confronto.

Rimane il fatto che il BD x8 CMT dovrebbe occupare meno area del BD x6 non CMT, ed è ciò che dovrebbe rendere il primo conveniente (uso il condizionale perchè non ricordo esattamente a cosa fosse riferito quel 12%).

[Claudio-x64]

Originariamente inviato da Veradun
Non e' che mi sbaglio, lo ha detto AMD. [...]
L'80% e' rispetto ad un'architettura ipotetica che non esiste, non c'e' nessun 80% da applicare a niente per fare delle simulazioni dei poveri [...]
Anch'io ho letto questa cosa da un post di JF su XS.

Inoltre sei davvero sicuro che tale situazione non sia invece simulabile, anche se non in maniera precisa, semplicemente mettendo a dormire un core nel modulo? Sicuro che BD non lo permetta?
non credo sia mai stato specificato questo :boh:

[calabar]

non credo sia mai stato specificato questo :boh:
No, ma neanche il contrario :)
JF si riferiva alle prestazioni complessive (in multithreading) quando ha tirato fuori quella percentuale.
L'architettura condivisa di BD ha fatto dedurre a molti (non sono il solo a pensarla così, basta rileggere le ultime centinaia di pagine di questo topic) che tale calo fosse imputabile esclusivamente ad una situazione in cui entrambi i core cmt venivano utilizzati.
Un calo generalizzato dell'ipc single thread del 20% sarebbe assolutamente deleterio.

[Claudio-x64]

No, ma neanche il contrario :)
JF si riferiva alle prestazioni complessive (in multithreading) quando ha tirato fuori quella percentuale.
L'architettura condivisa di BD ha fatto dedurre a molti (non sono il solo a pensarlo così, basta rileggere le ultime centinaia di pagine di questo topic) che tale calo fosse imputabile esclusivamente ad una situazione in cui entrambi i core cmt venivano utilizzati.
Un calo generalizzato dell'ipc single thread del 20% sarebbe assolutamente deleterio.
Sono d'accordo su tutto, e spero in quello in grassetto.

[Claudio-x64]

Spitfire84
http://www.bit-tech.net/news/hardwar...he-next-week/1
Secondo me, aspettavano l'insediamento del nuovo CEO.

[paolo.oliva2]

Vedo che non ci capiamo.
Il famoso "+7%" dell'esempio era relativo ad un BD x8 con CMT nei confronti di un x6 senza CMT.
Che sia un x6 thuban o un x6 BD non CMT non importa, dato che stavamo assumendo che avessero ipc identico.
Poniamo però che, come dici tu, si tratti appunto di un x6 BD non CMT, dato che conosciamo l'incremento di dimensione del modulo (dichiarato da AMD) e questo permette il confronto.

Rimane il fatto che il BD x8 CMT dovrebbe occupare meno area del BD x6 non CMT, ed è ciò che dovrebbe rendere il primo conveniente (uso il condizionale perchè non ricordo esattamente a cosa fosse riferito quel 12%).

Veramente non ci capiamo.... :)

Ribalto con questa domanda. Quanto renderà di più un BD CMT X8 rispetto ad un BD CMT X6 in MT? Concordi che sarà più del 7% o no?

[digieffe]

no... cosi assegni a BD un IPC inferiore del 20% in MT rispetto a Thuban, cioè secondo i tuoi conti
IPC ST=Thuban
IPC MT=Thuban - 20%
il che non può essere
in pratica tu assegni una penalità del 20% quando BD usa tutti i core...

ricordo che l'efficienza del famoso 80% si riferiva solamente rispetto allo stesso processore ma costruito senza logica condivisa ma esclusiva, quindi non è applicabile a confronti con altre cpu sul mercato

tipo come dire "con lo zaino pieno addosso salto la metà", ma la metà di quanto salto io potrebbe pure essere il doppio di quanto saltano gli altri...
Sono d'accordo con te, infatti impostare l'ipc di BD uguale al Thuban era solo una ipotesi...
fatto sta che BD nell'utilizzo di un modulo completo, ha un calo del 20% di throughput rispetto al doppio dell'ipc del singolo core (dello stesso BD)
Poi per ovviare a questa penalità di throughput (soprattuto rispetto al thuban) hanno alzato il clock e l'ipc... e quindi a meno di un fail (nel quale non credo) BD sarà sempre superiore a Thuban in ipc (ST) e Throughput (MT)



Esatto, e questo sarebbe il risultato se l'ipc per un task single thread di BD e del k10 fossero uguali, perchè quella (-20%) è la perdita prestazionale che AMD ha valutato per l'utilizzo del CMT.
Ricorda che i core del k10, per quanto ormai vecchi, lenti e tutto quello che vuoi, sono core senza elementi condivisi che ne limitano le prestazioni in multithread (ossia quando, con BD, si utilizzano entrambi i core del modulo e le parti condivise devono occuparsi di due core).
Appunto se gli ipc fossero uguali...



[...]

Il ragionamento da fare alla fine pero' è anche sull'area occupatanel die: Ricordiamoci che un BD 4 moduli è grosso solo il 12% (era il 12 o altro?) in + di un ipotetico BD 4 core senza CMT, quindi nettamente + piccolo di un altro ipotetico BD con 8 core senza CMT
infatti se BD manterrà fede a quanto detto da AMD dovrebbe esseci una grossa convenienza... (per loro :D)
anche se personalmente il chip mi sembra un pò grande 315mm^2 per un (4 core+12%), sarà tutta quella cache L2 (8MB) + altri 2MB di L3, sarà il silicio non pronto... mah



Infatti... quoto.

Praticamente se applicassimo questo -20% non lo applicheremmo ad un BD stile Phenom II ma ad un BD stile modulo, ma facendo così, è come se parlassimo che BD avrà una diminuzione del 20% di IPC rispetto al Phenom II.

Siccome AMD ha più volte detto che BD avrà un IPC superiore rispetto al Phenom, al più il ragionamento sarebbe che BD perderebbe un -20% rispetto al suo vantaggio per la logica del modulo e non -20% rispetto al Phenom.
qui si continua a confondere l'ipc che è relativo al singolo core con il throughput che è relativo a tutti i core:
se non fissiamo un linguaggio comune sarà facile non intendersi mai, non vanno bene i termini che ho scritto? va bene, decidiamone un paio in modo convenzionale e facciamo riferimento ad essi

...quindi AMD ha detto che avrà un ipc più alto, se lo ha detto sarà cosi...
IPOTIZZIAMO un +X% di ipc: un singolo core di un modulo sarà a parità di clock il +X% più veloce di un core Thuban, ok?
questo però non vuol dire che un modulo con entrambi i core sotto carico sia +X% più veloce di 2 core Thuban, ma +X% -20% (?).

A prescindere da questo, mi sembra chiaro che se un BD X8 concedesse margini minimi su un BD X6 la stessa logica di aumentare il numero dei core di un procio non varrebbe la spesa superiore, per cui i guadagni chiaramente saranno variabili rispetto al programma utilizzato, ma si deve comunque prendere atto che vi sono programmi in cui il guadagno è lineare al numero dei core e di conseguenza si potrebbe arrivare "fino al" +33%, specialmente anche sul fatto che la stessa architettura prevederebbe già un X10 e chissà se un X12 strada facendo.
Un BD X8 sarà "teoricamente" il 33% più veloce di un BD X6 (a patto che quest'ultimo utilizzi solo 3 moduli)



e invece sta proprio qua il punto. Perchè se un BD x8 CMT concedesse margini minimi su un ipotetico BD X6 puro (senza CMT) sarebbe comunque un guadagno enorme visto che effettivamente un BD x8 CMT è poco + grosso di un quadcore. E proprio il motivo per cui hanno introdotto CMT, e non creato qualcosa di simile a SMT o aggiunto semplicemente nuovi core
quoto, anche se al momento sono comunque perplesso per le dimensioni...



a me pare l'unico che ha capito il ragionamento mio...:O

assegnare il meno 20% di IPC in MT rispetto a quello in ST alla stessa CPU mi sembrano "i cunti ra ricuttara"...
può essere che abbia capito male quanto dichiarato da JF?
vado a ritrovare il post :)



No. Quella è la perdita prestazionale che un singolo core ha subito a causa della progettazione con risorse condivise rispetto alla prestazione che avrebbe avuto se fosse stato progettato senza la condivisione.



http://blogs.amd.com/work/2010/08/30/bulldozer-20-questions-%e2%80%93-part-2/
Ciao, mi fa piacere rivederti, vediamo qualora tu ne abbia voglia se riusciamo ad intenderci :)
Preciso che appena finito di rispondere leggerò il link da te postato (è già troppo lungo questo post da tenerlo in sospeso).

Da quanto tu affermi, ed immagino sia citato nel link, si potrebbe allora supporre che con la progettazione CMT NON ci siano perdite di prestazioni tra l'utilizzare solo un core del modulo o due?
ma queste perdite ci sarebbero state solo rispetto ad una progettazione non CMT?

[calabar]

Ribalto con questa domanda. Quanto renderà di più un BD CMT X8 rispetto ad un BD CMT X6 in MT? Concordi che sarà più del 7% o no?
In questo caso direi, supponendo uno scaling perfetto sul numero dei core (situazione che sappiamo non essere la norma), che l'incremento sarebbe banalmente del 25%... ahem 33%. :)

(riferito al post di Veradun)
Da quanto tu affermi, ed immagino sia citato nel link, si potrebbe allora supporre che con la progettazione CMT NON ci siano perdite di prestazioni tra l'utilizzare solo un core del modulo o due?
ma queste perdite ci sarebbero state solo rispetto ad una progettazione non CMT?
Direi che lui intendeva che non avresti vantaggi con l'ipc usando un solo core del modulo rispetto all'usarne due.
Afferma cioè che l'architettura CMT causa una perdita (media stimata) del 20% sempre, anche usando un solo core del modulo (cosa che secondo lui non avverrà perchè piuttosto BD spegnerà gli altri moduli per risparmiare corrente e salire di frequenza).
Io non sono d'accordo, e ovviamente spero che si sbagli :p

[marchigiano]

Direi che lui intendeva che non avresti vantaggi con l'ipc usando un solo core del modulo rispetto all'usarne due.
Afferma cioè che l'architettura CMT causa una perdita (media stimata) del 20% sempre, anche usando un solo core del modulo (cosa che secondo lui non avverrà perchè piuttosto BD spegnerà gli altri moduli per risparmiare corrente e salire di frequenza).
Io non sono d'accordo, e ovviamente spero che si sbagli :p

jf diceva che conviene usare 2 thread su un modulo piuttosto che un thread su due moduli perchè possono sfruttare la L2 condivisa

poi se è vero non lo so :fagiano:

[Ares17]

Sono d'accordo con te, infatti impostare l'ipc di BD uguale al Thuban era solo una ipotesi...
fatto sta che BD nell'utilizzo di un modulo completo, ha un calo del 20% di throughput rispetto al doppio dell'ipc del singolo core (dello stesso BD)
Poi per ovviare a questa penalità di throughput (soprattuto rispetto al thuban) hanno alzato il clock e l'ipc... e quindi a meno di un fail (nel quale non credo) BD sarà sempre superiore a Thuban in ipc (ST) e Throughput (MT)




Appunto se gli ipc fossero uguali...




infatti se BD manterrà fede a quanto detto da AMD dovrebbe esseci una grossa convenienza... (per loro :D)
anche se personalmente il chip mi sembra un pò grande 315mm^2 per un (4 core+12%), sarà tutta quella cache L2 (8MB) + altri 2MB di L3, sarà il silicio non pronto... mah




qui si continua a confondere l'ipc che è relativo al singolo core con il throughput che è relativo a tutti i core:
se non fissiamo un linguaggio comune sarà facile non intendersi mai, non vanno bene i termini che ho scritto? va bene, decidiamone un paio in modo convenzionale e facciamo riferimento ad essi

...quindi AMD ha detto che avrà un ipc più alto, se lo ha detto sarà cosi...
IPOTIZZIAMO un +X% di ipc: un singolo core di un modulo sarà a parità di clock il +X% più veloce di un core Thuban, ok?
questo però non vuol dire che un modulo con entrambi i core sotto carico sia +X% più veloce di 2 core Thuban, ma +X% -20% (?).


Un BD X8 sarà "teoricamente" il 33% più veloce di un BD X6 (a patto che quest'ultimo utilizzi solo 3 moduli)




quoto, anche se al momento sono comunque perplesso per le dimensioni...




può essere che abbia capito male quanto dichiarato da JF?
vado a ritrovare il post :)




Ciao, mi fa piacere rivederti, vediamo qualora tu ne abbia voglia se riusciamo ad intenderci :)
Preciso che appena finito di rispondere leggerò il link da te postato (è già troppo lungo questo post da tenerlo in sospeso).

Da quanto tu affermi, ed immagino sia citato nel link, si potrebbe allora supporre che con la progettazione CMT NON ci siano perdite di prestazioni tra l'utilizzare solo un core del modulo o due?
ma queste perdite ci sarebbero state solo rispetto ad una progettazione non CMT?

Finora non ho mai risposto a questa diatriba, ma mi sorgono dei dubbi:

Il fatto che amd continui ad indicare che l'ipc di un core BD sia superiore a quello di Thuban è noto, ma riferito a single th esclusivo per il modulo, all'ipc del singolo core in multi-th, oppure a single th con l'altro core del modulo impegnato con un altro th ?

Quel famoso 20% in meno di prestazioni sui due core del singolo modulo è una media?, il caso peggiore? o quello migliore? (credo che a seconda del software dovremmo avere scenari diversi), e se come credo quel - 20% è riferito al solo ipc dell'fpu, be allora tutto lo scenario cambia di brutto, o sbaglio?.

[calabar]

Quel famoso 20% in meno di prestazioni sui due core del singolo modulo è una media?, il caso peggiore? o quello migliore? (credo che a seconda del software dovremmo avere scenari diversi), e se come credo quel - 20% è riferito al solo ipc dell'fpu, be allora tutto lo scenario cambia di brutto, o sbaglio?.
Una stima media del calo prestazionale a causa della logica condivisa legata all'architettura CMT.
Direi che visto che si parlava di core, quindi di core int, la fpu è da escludere.

jf diceva che conviene usare 2 thread su un modulo piuttosto che un thread su due moduli perchè possono sfruttare la L2 condivisa
Intendevi forse dire 2 thread su due moduli?
Ovvio che un thread su due moduli vada meno... userebbe un solo core di un solo modulo! :p

[digieffe]

Veramente non ci capiamo.... :)

Ribalto con questa domanda. Quanto renderà di più un BD CMT X8 rispetto ad un BD CMT X6 in MT? Concordi che sarà più del 7% o no?

In questo caso direi, supponendo uno scaling perfetto sul numero dei core (situazione che sappiamo non essere la norma), che l'incremento sarebbe banalmente del 25%. :)

avevo intuito l'equivoco di Paolo, cmq forse volevi dire 33% in situazione "teoricamente perfetta"



jf diceva che conviene usare 2 thread su un modulo piuttosto che un thread su due moduli perchè possono sfruttare la L2 condivisa

poi se è vero non lo so :fagiano:

forse 2 thread dello stesso processo SI, in quanto avrebbero la possibilità di agire sugli stessi dati nella L2 condivisa,
credo di NO per 2 thread di processi differenti o dello stesso processo ma che trattano dati diversi in quanto la cache sarebbe riempita di set di dati differenti col rischio di perdere di efficienza

[calabar]

avevo intuito l'equivoco di Paolo, cmq forse volevi dire 33% in situazione "teoricamente perfetta"
Oops, si certo ovviamente.

[digieffe]

Quello che non afferri è che la prima e la seconda questione riguardano entrambe le scelte architetturali. L'IPC è quello di una architettura, ed in questo è già considerata qualunque perdita prestazionale dovuta a scelte di privilegiare altro (die size, per esempio). Quindi nell'ipotesi che l'IPC sia lo stesso del K10, non c'è da moltiplicare per nessun 80%, perché fa già parte dell'architettura.



I due core di un modulo hanno certe prestazioni perché progettati in un certo modo, il fatto che il secondo sia attivo o meno non cambia le prestazioni del singolo core non cambia le prestazioni in peggio, ma più facilmente in meglio a causa dell'esclusività delle risorse condivise.



Secondo AMD. Ovviamente è una elucubrazione non esistendo alcun BD senza CMT.

Non e' che mi sbaglio, lo ha detto AMD. Ora si possono prendere due strade, non credere ad AMD, quindi nemmeno all'80% e lasciar cadere tutto il discorso oppure credere a quello che scrivono loro e quindi anche a questo.

L'80% e' rispetto ad un'architettura ipotetica che non esiste, non c'e' nessun 80% da applicare a niente per fare delle simulazioni dei poveri, e' un numero che non ha alcuna attinenza con la realta' effettiva e dato in risposta a chi chiese "ma non conveniva farlo normale invece che CMT?"

Riguardo al discorso "handicap": progettare una CPU (ma anche una GPU, un chip in generale) e' una sfida che mette continuamente un progettista di fronte a scelte fra occupazione di area, consumi, rese produttive, performance. Tutte insieme non si possono avere "gratis". L'SMT di Intel e' una scelta che consuma spazio e non stabilmente conveniente quanto a performance. Al posto di quello spazio potevano metterci piu' cache, o alzare la frequenza, ma evidentemente i tradeoff scelti non hanno dato risultati scadenti.



L'architettura e' una sola, non cambia al variare del carico di lavoro e quel conto non ha senso alcuno. Quel conto rappresenta la differenza fra il BD che uscira' di qui a poco rispetto ad un ipotetico BD mai esistito senza CMT in un carico multithreaded. L'IPC dei core di BD sara' lo stesso in MT e ST, salvo pochi percento dovuti all'esclusivita' del condiviso, situazione che fra le altre cose non si verifichera' mai nel mondo reale, perche' anche in un carico di due threads si spegneranno tutti i moduli escluso uno, che continuera' a condividere le risorse fra i due core, proprio perche' lo svantaggio prestazionale nel fare cosi' rispetto a distribuire i thread su tutti i moduli prima di fare il secondo giro di riempimento e' sovrabbondantemente ripagato dalla possibilita' di aumentare il turbo grazie al risparmio energetico ottentuo spengendo l'inutile.
finalmente anche con l'aiuto di calabar ho capito dov'era il punto...
vado a rivedere un pò di materiale mi hai messo il dubbio

[The3DProgrammer]

jf diceva che conviene usare 2 thread su un modulo piuttosto che un thread su due moduli perchè possono sfruttare la L2 condivisa

poi se è vero non lo so :fagiano:

se i thread lavorano sugli stessi dati, è + conveniente farli eseguire nello stesso modulo. se i thread lavorano su dati totalmente diversi o sono di due applicazioni diverse, conviene farli eseguire su 2 moduli diversi. e' spiegato nelle 20 domande su bd linkate prima - ed è anche abbastanza ragionevole.

[paolo.oliva2]

jf diceva che conviene usare 2 thread su un modulo piuttosto che un thread su due moduli perchè possono sfruttare la L2 condivisa

poi se è vero non lo so :fagiano:

Ma infatti è proprio questo il punto che ho affrontato nel mio post precedente.

Noi stiamo prendendo in considerazione che 2 core non condivisi sarebbero più potenti perché indipendenti, e questo lo concorda pure AMD, ma bisogna vedere bene se nel calcolo puro o nel totale. Ad esempio, come hai detto tu, il fatto di ricercare dei dati (AMD ha la L2-L3 esclusiva e non inclusiva) porterebbe tempi superiori perché un conto sarebbe cercare il dato tra 1 L2 e L3 del modulo ed un altro cercare lo stesso dato in tutte le l2 e nella totalità della L3 del procio.

Il confronto è relativamente semplice: se prendessimo 4 TH e li distribuissimo 1 a modulo, avremmo la condizione che il CMT non influenzerebbe per nulla ma ciò porterebbe il procio lavorare ad una frequenza def.

Invece se il procio lavorasse con 2 moduli completi e 4 TH, la frequenza aumenterebbe di 600MHz, cioè la frequenza accreditata al Turbo.

8150p (3,6GHz) + 600MHz = 16,66%
8170p (3,9GHz) + 600MHz = 15,3%

Quindi, o JF ha sparato -20% prendendo in considerazione UNICAMENTE i contro senza valutare i pro (tipo ricerca dati nelle cache ed altro ancora) o comunque forse ha sparato un valore massimo nelle condizioni più negative visto che quel valore dato all'impatto del CMT in ogni caso deve essere inferiore a -15,3%, quindi ben inferiore al 20%.

Edit:

se i thread lavorano sugli stessi dati, è + conveniente farli eseguire nello stesso modulo. se i thread lavorano su dati totalmente diversi o sono di due applicazioni diverse, conviene farli eseguire su 2 moduli diversi. e' spiegato nelle 20 domande su bd linkate prima - ed è anche abbastanza ragionevole.

E qui già avremmo condizioni differenti, quindi è già da ritenere che il valore -20% non può essere una costante ma forse da considerari "fino al" -20%.

[marchigiano]

Intendevi forse dire 2 thread su due moduli?
Ovvio che un thread su due moduli vada meno... userebbe un solo core di un solo modulo! :p

si intendevo 2 thread uno per modulo

forse 2 thread dello stesso processo SI, in quanto avrebbero la possibilità di agire sugli stessi dati nella L2 condivisa,
credo di NO per 2 thread di processi differenti o dello stesso processo ma che trattano dati diversi in quanto la cache sarebbe riempita di set di dati differenti col rischio di perdere di efficienza

questa è una buona osservazione, ma alla fine non penso esistano dei scheduler talmente intelligenti da capire come è meglio suddividere i thread, quindi avranno simulato vari carichi di lavoro e scelto l'approccio MEDIAMENTE migliore, questo vuol dire che non sempre sarà ottimizzato al massimo

[paolo.oliva2]

Posto questo, ma non sao se sia già stato postato o sia una bufala.

Comunque... è un 8130p, portato ancora ad aria a 5,13GHz

http://lenzfire.com/2011/07/amd-bulldozer-processor-overclocking-record-easy-to-reach-5-1ghz/

Questo artico è già stato postato ma consiglio di leggere le ultime 3 righe visto le discussioni circa "momento non propizio" per BD.

http://www.bit-tech.net/news/hardware/2011/08/26/amd-bulldozer-to-ship-within-the-next-week/1

[Matalf]

Posto questo, ma non sao se sia già stato postato o sia una bufala.

Comunque... è un 8130p, portato ancora ad aria a 5,13GHz

http://lenzfire.com/2011/07/amd-bulldozer-processor-overclocking-record-easy-to-reach-5-1ghz/


Per quello che si vede nello screen penso che a 4,6GHz il punteggio sia circa 7...


un po pochino in somma, lo prendo per un fake e mi metto il quore in pace :D

[Claudio-x64]

un po pochino in somma, lo prendo per un fake e mi metto il quore in pace
:eek: :D

[digieffe]

si intendevo 2 thread uno per modulo



questa è una buona osservazione, ma alla fine non penso esistano dei scheduler talmente intelligenti da capire come è meglio suddividere i thread, quindi avranno simulato vari carichi di lavoro e scelto l'approccio MEDIAMENTE migliore, questo vuol dire che non sempre sarà ottimizzato al massimo

non sono certo ma, se i due core di un modulo fossero dichiarati come core logici (ugualmente a quanto accade con l'ht della controparte),
lo scheduler saprebbe che hanno parti condivise (anche se dovrebbe comunque conoscere le relazioni gerachiche nella cpu, per funzioni qual core parking, ecc)

però anche conoscendo la struttura della cpu, sapere come allocare i thread che operano sugli stessi dati...

non so se esiste, dovrebbero fare una chiamata di sistema da utilizzare nei programmi per indicare allo scheduler che 2 thread operano sullo stesso set di dati...
altrimenti l'unica distinzione possibile è solo che i thread appartengono a 2 processi diversi... (il che farebbe solo supporre che operino su dati diversi)

poi c'è un altro fattore: se mettendo insieme thread di 2 processi diversi sullo stesso modulo è possibile spegnerne un altro ed incrementare il clock addirittura da apportare vantaggi...

servirebbe uno scheduler apposito con driver specifico per la cpu, tale da valutare tutti questi casi...

speriamo che con windows 8 facciano qualcosa...
con Linux a parte ilnumero di scheduler disponibili, qualche tweak si trova sempre ;)

[digieffe]

Per quello che si vede nello screen penso che a 4,6GHz il punteggio sia circa 7...


un po pochino in somma, lo prendo per un fake e mi metto il quore in pace :D

per pura curiosità: da dove deduci il 7? c'è qualche indicatore che s'intravede?

[marchigiano]

Posto questo, ma non sao se sia già stato postato o sia una bufala.

Comunque... è un 8130p, portato ancora ad aria a 5,13GHz

http://lenzfire.com/2011/07/amd-bulldozer-processor-overclocking-record-easy-to-reach-5-1ghz/

non dirmi che non hai visto il 6.5ghz ad azoto :)

servirebbe uno scheduler apposito con driver specifico per la cpu, tale da valutare tutti questi casi...

più che altro servirebbe una patch per ogni software sviluppata dalla propria software house per forzare l'uso dei core nel modo più redditizio, un lavoraccio mica da ridere... non penso lo faranno subito ma col passare dei mesi

[capitan_crasy]

Posto questo, ma non sao se sia già stato postato o sia una bufala.

Comunque... è un 8130p, portato ancora ad aria a 5,13GHz

http://lenzfire.com/2011/07/amd-bulldozer-processor-overclocking-record-easy-to-reach-5-1ghz/

Questo artico è già stato postato ma consiglio di leggere le ultime 3 righe visto le discussioni circa "momento non propizio" per BD.

http://www.bit-tech.net/news/hardware/2011/08/26/amd-bulldozer-to-ship-within-the-next-week/1

Old, Step B0...
Tieni buono la scimmia paolo, ormai manca poco...:cool:

[digieffe]

non dirmi che non hai visto il 6.5ghz ad azoto :)



più che altro servirebbe una patch per ogni software sviluppata dalla propria software house per forzare l'uso dei core nel modo più redditizio, un lavoraccio mica da ridere... non penso lo faranno subito ma col passare dei mesi

era ciò a cui mi riferivo con questa frase:
"non so se esiste, dovrebbero fare una chiamata di sistema da utilizzare nei programmi per indicare allo scheduler che 2 thread operano sullo stesso set di dati..."

chiaramente non mi aspetto che sia il software ad indicare in che modo utilizzare i core
ma solo che possa indicare al SO che 2 o più thread operano sugli stessi dati
dopo sarà lo scheduler in base alla CPU a regolarsi di conseguenza
non credo sia tando difficile da implementare dal lato del software (nella creazione del thread ci sarebbe un campo in più es: "gruppo_dati")
il fatto e che lo scheduler deve essere predisposto (ma chissa che già non esista -in Linux- controllo)

per il resto, con l'affinità dei processi verso i core, già si può fare da software ma in questo modo il software deve conoscere la struttura della CPU e sarebbe pesante e non standard da implementare


UPDATE: esludendo windows, sembrerebbe che esistano una serie di strumenti e modi per bloccare sia i thread sia le pagine dei dati ad un certo core... questo dai sistemi Posix (Linux, Unix, ...) a quelli proprietari IBM, non ancora ho capito se si può fare in automatico o solo in modo esplicito, il che comporterebbe fatica.

[marchigiano]

Old, Step B0...
Tieni buono la scimmia paolo, ormai manca poco...:cool:

ma alle redazioni sono arrivate le cpu da testare?

[capitan_crasy]

ma alle redazioni sono arrivate le cpu da testare?

Dovresti chiederlo a gianni...:)

[paolo.oliva2]

Old, Step B0...
Tieni buono la scimmia paolo, ormai manca poco...:cool:
Te hai ragione... ma è dura :)
Comunque... a meno che AMD/NDA non abbiano preso a busta paga i servizi segreti di tutto il mondo e/o che abbiano i magazzini pieni e comincino le spedizioni il 1° settembre, dubito per una reperibilità di BD prima di 2 settimane... mi sa che si va quasi a fine settembre.

[Wawacco]

Arrivà prima la disponibilità che le recensioni :asd:

[Polpi_91]

toto paper lunch: io scommetto tra il 12 e il 16 settembre

[crazyduck00]

non sono certo ma, se i due core di un modulo fossero dichiarati come core logici (ugualmente a quanto accade con l'ht della controparte),
lo scheduler saprebbe che hanno parti condivise (anche se dovrebbe comunque conoscere le relazioni gerachiche nella cpu, per funzioni qual core parking, ecc)

però anche conoscendo la struttura della cpu, sapere come allocare i thread che operano sugli stessi dati...

non so se esiste, dovrebbero fare una chiamata di sistema da utilizzare nei programmi per indicare allo scheduler che 2 thread operano sullo stesso set di dati...
altrimenti l'unica distinzione possibile è solo che i thread appartengono a 2 processi diversi... (il che farebbe solo supporre che operino su dati diversi)

poi c'è un altro fattore: se mettendo insieme thread di 2 processi diversi sullo stesso modulo è possibile spegnerne un altro ed incrementare il clock addirittura da apportare vantaggi...

servirebbe uno scheduler apposito con driver specifico per la cpu, tale da valutare tutti questi casi...

speriamo che con windows 8 facciano qualcosa...
con Linux a parte ilnumero di scheduler disponibili, qualche tweak si trova sempre ;)

BINGO !
I processi applicativi sono gestiti dall'os, basterebbe soltanto che:
quando vede un processo appartenente allo stessa applicazione la manda sul core libero del modulo dove c'è l'altro core che processa il processo della stessa applicazione, se vede invece un processo appartenente ad un altra applicazione lo spara su un core di un altro modulo.
Non è difficile, e non sarà il software a gestire questo, niente patch ai software e nulla di complicato per chi li scrive, niente di tutto questo.
Linux già lo fa di suo, e tutto questo è gia implentato all'interno del kernel.

era ciò a cui mi riferivo con questa frase:
"non so se esiste, dovrebbero fare una chiamata di sistema da utilizzare nei programmi per indicare allo scheduler che 2 thread operano sullo stesso set di dati..."

chiaramente non mi aspetto che sia il software ad indicare in che modo utilizzare i core
ma solo che possa indicare al SO che 2 o più thread operano sugli stessi dati
dopo sarà lo scheduler in base alla CPU a regolarsi di conseguenza
non credo sia tando difficile da implementare dal lato del software (nella creazione del thread ci sarebbe un campo in più es: "gruppo_dati")
il fatto e che lo scheduler deve essere predisposto (ma chissa che già non esista -in Linux- controllo)

per il resto, con l'affinità dei processi verso i core, già si può fare da software ma in questo modo il software deve conoscere la struttura della CPU e sarebbe pesante e non standard da implementare


*UPDATE: esludendo windows, sembrerebbe che esistano una serie di strumenti e modi per bloccare sia i thread sia le pagine dei dati ad un certo core... questo dai sistemi Posix (Linux, Unix, ...) a quelli proprietari IBM, non ancora ho capito se si può fare in automatico o solo in modo esplicito, il che comporterebbe fatica.

Ma il software non centra niente infatti. Non è il software che deve riconsocere la struttura della cpu ma è' il sistema operativo a gestire i processi delle applicazioni software, e quindi a distribuire i processi all'elaborazione sui vari core e moduli della cpu, sfruttando la logica del core occupato. Se CORE.0 è occupato da un processo mando quest'altro su CORE.1 ... per il caso BD e i suoi moduli basta un aggiornamento al kernel di windows 7 non serve windows 8 per una cosa cosi banale.

*UPDATE Linux non ha bisogno di nessun aggiornamento invece perchè questa logica la implementa gia nel kernel.

[calabar]

Leggi il link che ho riportato dal BD Blog, AMD lo ha specificato li. La cosa e' simulabile da AMD, e sicuramente in fase di pianificazione e' stata valutata come ipotesi, ma se metti a dormire un core di BD stai usando un BD CMT, non stai simulando come avrebbe funzionato senza CMT, perche' avrebbero fatto un'abnorme quantita' di scelte diverse.
Puoi indicarmi esattamente dove lo dice? Dove dice che spegnere un core del modulo non possa in qualche modo avvicinarsi alle prestazioni di un BD non CMT. Io non l'ho trovato, ma ho dato una lettura approssimativa.

La scelta del CMT ha sicuramente portato tanti piccoli cambiamenti, ma concettualmente il passaggio è molto semplice: inserisci un altro core e ampli la logica di gestione in modo che sia dimensionata per gestire efficacemente i dati da passargli.
Considerando che si tratta delle stesse soluzioni tecniche (si parla comunque di BD, non di un processore X fatto chissà come), non credo che un modulo BD con un core non utilizzato possa discostarsi molto, come prestazioni, dall'ipotetico BD senza quel core.

Esattamente. E' chiaro che se un core si trova a lavorare da solo in un modulo avra' un leggero guadagno dal fatto di avere la L2 tutta per se', ma la strategia di BD, quando i thread siano pochi, non e' mai quella di distribuirsi omogeneamente sui moduli ma quella di caricarne uno prima di passare al successivo. Il guadagno nel fare nel primo modo e' irrisorio rispetto al guadagno in TDP del secondo. Guadagno in TDP che puo' essere speso in un turbo molto piu' aggressivo con benefici molto maggiori.
Io questa certezza non ce l'ho affatto. Anzi credo che se davvero la perdita di prestazioni è quantificabile intorno al 20% (che è un'enormità... mai vista una perdita di prestazioni del genere con l'uso di cache ridotte), BD possa privilegiare l'uso di un core per modulo.
Dai poi per scontato che questo porterebbe ad un grosso problema di risparmio energetico, ma sei sicuro che BD non riesca a far consumare poco il core inattivo di un modulo, magari spegnendolo?
E non sarebbe certo solo l'aumento di L2 a migliorare le prestazioni del core che lavora da solo (sarebbe marginale), quanto la logica di gestione tutta per se, dato che è proprio la condivisione di tale logica a far calare del 20% le prestazioni rispetto al'ipotetico BD non CTM.

[SwatMaster]

*UPDATE Linux non ha bisogno di nessun aggiornamento invece perchè questa logica la implementa gia nel kernel.

E tutto ciò va a vantaggio del mondo server, perchè lì Linux domina.

Ma per quanto riguarda i desktop, dove Windows è padrone, cosa succederà? AMD e MS lavoreranno insieme ad una sorta di patch per il kernel? Penso sia d'obbligo.

[crazyduck00]

E tutto ciò va a vantaggio del mondo server, perchè lì Linux domina.

Ma per quanto riguarda i desktop, dove Windows è padrone, cosa succederà? AMD e MS lavoreranno insieme ad una sorta di patch per il kernel? Penso sia d'obbligo.

Purtroppo non è d'obbligo.
Winzoz essendo un os -non opensource- è l'azienda stessa che scrive e riedita il codice del suo sistema operativo, ottimizzandolo al meglio per chi la paga meglio.
Per cui se non è lei ad aggiornare il suos istema per l'ottimizzazione di BD, sara AMD stessa a tirare fuori un DRIVER per la sua cpu, come fece con il "dual core optimizer", tale driver installato nell'os gestira a pieno l'intera architettura BD, sfruttandone tutte le sue funzioni durante l'interazione con il sistema operativo e i processi eseguiti su di esso dalle applicazioni.

[The3DProgrammer]

non sono certo ma, se i due core di un modulo fossero dichiarati come core logici (ugualmente a quanto accade con l'ht della controparte),
lo scheduler saprebbe che hanno parti condivise (anche se dovrebbe comunque conoscere le relazioni gerachiche nella cpu, per funzioni qual core parking, ecc)

però anche conoscendo la struttura della cpu, sapere come allocare i thread che operano sugli stessi dati...

non so se esiste, dovrebbero fare una chiamata di sistema da utilizzare nei programmi per indicare allo scheduler che 2 thread operano sullo stesso set di dati...
altrimenti l'unica distinzione possibile è solo che i thread appartengono a 2 processi diversi... (il che farebbe solo supporre che operino su dati diversi)

poi c'è un altro fattore: se mettendo insieme thread di 2 processi diversi sullo stesso modulo è possibile spegnerne un altro ed incrementare il clock addirittura da apportare vantaggi...

servirebbe uno scheduler apposito con driver specifico per la cpu, tale da valutare tutti questi casi...

speriamo che con windows 8 facciano qualcosa...
con Linux a parte ilnumero di scheduler disponibili, qualche tweak si trova sempre ;)

c'è scritto sempre nelle 20 domande su bd che ms sta gia lavorando con amd per lo scheduler. In piu si può anche ottimizzare il software tramite l'affinity mask (c'è un'api in windows apposita, si chiama setthreadaffinitymask) per indicare su quale cpu si vuole che un determinato thread venga eseguito. c'è gia' tutto quello che serve in pratica

[Danckan]

ma alle redazioni sono arrivate le cpu da testare?

Ancora niente sample in italia purtroppo. Ma la disponibilità dovrebbe arrivare a giorni.

[digieffe]

c'è scritto sempre nelle 20 domande su bd che ms sta gia lavorando con amd per lo scheduler. In piu si può anche ottimizzare il software tramite l'affinity mask (c'è un'api in windows apposita, si chiama setthreadaffinitymask) per indicare su quale cpu si vuole che un determinato thread venga eseguito. c'è gia' tutto quello che serve in pratica

che si potesse fare tramite l'impostazione dell'affinity (anche non conoscendo il metodo in windows) lo sapevo... ogni os da anni permette di impostare l'affinit di core (cpu), i/o, ed eventulmente muovere le pagine dei dati... il tutto in maniera esplicita (con apposite chiamate all'os)... il che comporta una certa mole di lavoro da parte dello sviluppatore

ciò che mi chiedo ed a cui non sono riuscito a darmi una risposta certa, è se sia possibile in maniera semplice (senza esplicitare affinity varie), indicare allo scheduler solo che, per esempio, 2 thread trattano lo stesso set di dati e poi l'os fa tutto da solo, es: alloca i 2 thread a una cpu (o nel nostro caso un modulo) in automatico, senza impostare particolari affinità

questo qualora esista ridurrebbe di molto la fase di ottimizzazione del software lasciando l'os un pò più libero di gestirsi le risorse...

forse tu che ti occuppi di 3D hai più a che fare con la programmazione parallela :)


EDIT: che questo argomento è leggermente ot ma ritengo che siano informazioni utili, anche perche bulldozer è un architettura cmt e non, come siamo abituati, smt.

[calabar]

Cosi' ad alto livello e' sicuramente molto semplice. Ma siamo talmente lontani dal livello fisico che l'approssimazione rende il ragionamento completamente inaccurato.

Di fatto l'architettura e' una ed una sola. Ogni calcolo basato su una stima approssimativa di come sarebbero state le prestazioni con un'altra architettura lascia il tempo che trova.
Questa è un po' una contraddizione in termini.
Se AMD quantifica in un 20% di perdita prestazionale rispetto ad un bulldozer realizzato senza CMT, evidentemente si sta parlando della stessa architettura, non di una fantomatica architettura completamente differente.

Ovvio poi che le differenze di siano, ma le tecnologie implementate nei due processori devono essere le stesse, altrimenti il confronto non avrebbe alcun senso.

E ci sono tonnellate di slide su BD che spiegano come il power gating possa essere fatto solo per modulo e non per core.
Questa è una cosa interessante, perchè qui sul forum si stava ancora dibattendo su questo fatto, dato che non si erano trovate conferme definitive, e alcuni utenti esperti avevano letto per bene la documentazione disponibile.
Era persino spuntato fuori uno screenshot, su cui si era discusso un po', che mostrava core di uno stesso modulo con frequenze e tensioni differenti, ma era di dubbia provenienza e non fa testo.
Nel frattempo è spuntato fuori qualcosa di nuovo?

[digieffe]

distrattamente penso alla dimensione di 315mm^2...


se togliamo il 12% per l'occupazione del secondo core int abbiamo 281mm^2

per 4 core + 8MB l2 + 8MB L3 + contr ram 2ch + 4 hypertransport + varie.



la concorrenza con lo stesso processo produttivo ha 215mm^2:

se togliamo il 40mm^2 per l'occupazione della gpu abbiamo 175mm^2

per 4 core (incluso HT (5% sup.)) + 1MB l2 + 8MB L3 + contr ram 2ch + 1 contr pci-e


ora possibile che per 7 mb di L2 + 3 contr. i/o in più ci siano circa 100mm^2 di differenza pari al 57% in più?

[capitan_crasy]

Questa è una cosa interessante, perchè qui sul forum si stava ancora dibattendo su questo fatto, dato che non si erano trovate conferme definitive, e alcuni utenti esperti avevano letto per bene la documentazione disponibile.
Era persino spuntato fuori uno screenshot, su cui si era discusso un po', che mostrava core di uno stesso modulo con frequenze e tensioni differenti, ma era di dubbia provenienza e non fa testo.
Nel frattempo è spuntato fuori qualcosa di nuovo?

Di dubbia origine direi proprio di no dato che lo screen è stato fatto ad una dimostrazione pubblica organizzata da AMD stessa...
http://www.xtremeshack.com/immagine/t106917_009.jpg (http://www.xtremeshack.com/scheda/106917_009.jpg.html)

L'immagine dei Vcore differenti (per modulo) è questa:
http://www.xtremeshack.com/immagine/i106918_l-kn-amdfx-01-01.jpg

Inoltre sembra appurato che anche le frequenze di clock dei core siano totalmente indipendenti uno dall'altro, anche se derivano dallo stesso modulo...
Parliamo comunque di CPU BD ES...

[calabar]

Di dubbia origine direi proprio di no dato che lo screen è stato fatto ad una dimostrazione pubblica organizzata da AMD stessa...
Ooops, ricordavo male!
E ricordavo male due volte, dato che mi pareva si parlasse anche di vcore differenti all'interno di un modulo (non confermato ovviamente). Ma già le frequenze indipendenti possono essere un buon compromesso, nel discorso fatto sopra.