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

[Heimdallr]

Originariamente inviato da Spitfire84

ed è sbagliato ciò che dici..per farti un esempio, da quando sono uscite le schede video ati serie 5xx0, amd non ha abbassato i prezzi, anzi li ha addirittura alzati

Io credo che i prezzi in rialzo sia stati dovuto più che altro ad un peggiore cambio con il dollaro, i prezzi americano mi pare siano rimasti più o meno uguali.

Comunque al di là di questo purtroppo AMD deve fare la guerra sui prezzi, speriamo che le cose cambino però

[Ares17]

Originariamente inviato da cionci

Però sulla FPU c'è un vero è proprio SMT. E' vero che ci sono due unità di esecuzione, ma è anche vero che c'è una sola FPU, al contrario delle ALU. Quindi dal punto di vista fisico un modulo BD non è un vero e proprio dual core.
E' un dual core per gli interi, è un single core con SMT per i floating point.

Detto questo, l'unità FP sarà sicuramente sufficientemente potente per poter lavorare con due thread contemporaneamente.

Scusami la domanda da ignorante, ma i th sono gestiti anche dalla fp?
Perchè se fosse così i th degli i7 quad dovrebbero essere 12 e non 8 (ipotizzando l'smt eseguito esclusivamente dall'alu).

[Spitfire84]

Originariamente inviato da Heimdallr

Io credo che i prezzi in rialzo sia stati dovuto più che altro ad un peggiore cambio con il dollaro, i prezzi americano mi pare siano rimasti più o meno uguali.

Comunque al di là di questo purtroppo AMD deve fare la guerra sui prezzi, speriamo che le cose cambino però

se nvidia avesse rilasciato le gtx4x0 in tempo e con performance/consumo migliori delle schede ati i prezzi sarebbero scesi indipendentemente dal cambio €/dollaro o altri fattori..come è sempre stato del resto.

PS: vi prego di prendere questi commenti con un esempio di operatività sul mercato..lungi da me creare flame ati(amd)/nvidia.

[Ares17]

Originariamente inviato da Spitfire84

se nvidia avesse rilasciato le gtx4x0 in tempo e con performance/consumo migliori delle schede ati i prezzi sarebbero scesi indipendentemente dal cambio €/dollaro o altri fattori..come è sempre stato del resto.

Forse, ma dire che sono aumentati i prezzi è ben diverso dal dire che non sono scesi.

[Heimdallr]

Originariamente inviato da Spitfire84

se nvidia avesse rilasciato le gtx4x0 in tempo e con performance/consumo migliori delle schede ati i prezzi sarebbero scesi indipendentemente dal cambio €/dollaro o altri fattori..come è sempre stato del resto.

Si si questo sicuramente, ovviamente non hanno abbassato i prezzi perchè tanto le schede le hanno vendute lo stesso per cui tanto valeva avere margini più alti, però secondo me il rialzo che abbiamo avvertito qua è da imputare (anche) al cambio con il dollaro

Originariamente inviato da Spitfire84

PS: vi prego di prendere questi commenti con un esempio di operatività sul mercato..lungi da me creare flame ati(amd)/nvidia.

Chiaro

[Spitfire84]

Originariamente inviato da Ares17

Forse, ma dire che sono aumentati i prezzi è ben diverso dal dire che non sono scesi.

ma nel caso delle ati serie 5 sono vere entrambe..
Ad ogni modo, chiudo qui l'OT.

[Simo_LNX]

Io di solito non scrivo mai perche' spesso cionci, oliva2 e altri ribattono esattamente come vorrei rispondere io quindi la cosa e' futile, ma permettete di farvi un esempio.

Un po' di tempo fa, sul thread di Timeshift molti si lamentarono delle texture come troppo lucide e io risposi : "Non sono lucide, e' l'effetto pioggia..."

Ora su buldozzer ci terrei a dire : Non sono 8 core, sono 4 MODULI.

Ora io solitamente mi occupo di virtualizzazione quindi ovviamente il mio punto di vista e' incentrato strettamente a questo, ma prova in un datacenter a mettere SQL ( che tiene dati critici ) bindato a core 2,3 con intel e HT attivo mentre hai 3VMs che ti sfruttano 8 core virtuali perche' tanto intel e' 4+4 = 8 e vedrai che il giorno dopo sei ad aggiornare il curriculum.
Il concetto e' nettamente diverso. Come in MagnyC un 8c e' in realta' un 4-4 e tu devi dividere in modo da coprire un X di VMs in un "package" e le altre nell'altro "package" che sta comunque dentro il processore, con buldozzer sara' molto differente. Non piu' core assignation in base a core fisici ( o presunti in caso di intel ) ma assegnazione di due moduli e split dello stesso SQL su core 1,3 per l'offload ( o 1,2 per un main load). Inoltre in ambito ESX ( che volente o nolente e' quello che si usa in azienda e pippa ) il footprint e' principalmente sulla memoria quindi un eventuale quad-channel se implementato per me vale 20 xeon...

Ovviamente e' solo un punto di vista signori

[calabar]

Originariamente inviato da cionci

E' un dual core per gli interi, è un single core con SMT per i floating point.

E dal momento che i core si contano sulle unità int... allora è un dual core a tutti gli effetti

PS: non sono ancora convinto del fatto che l'unità FP abbia SMT.
Il fatto che sia in grado di servire due core parallelamente è dovuta al fatto che sia composta da due unità a 128 bit capaci di lavorare in parallelo per istruzioni a 128 bit, ma questo non significa che implementi SMT.
Oppure a riguardo è uscita qualche novità che chiarisce che si tratta di SMT?

[cionci]

Originariamente inviato da Ares17

Scusami la domanda da ignorante, ma i th sono gestiti anche dalla fp?
Perchè se fosse così i th degli i7 quad dovrebbero essere 12 e non 8 (ipotizzando l'smt eseguito esclusivamente dall'alu).

No, non devi contare il numero di unità di esecuzione. Le unità di esecuzione possono anche essere assegnate tutte ad un unico thread (in teoria).
Storicamente, e credo sempre prima di BD, per definire se una CPU è o meno SMT bastava contare quanti thread ci sono ad un certo istante in esecuzione in un solo core. Quindi per l'i7 la cosa è abbastanza semplice.
BD è di fatto una CPU SMT (vista nel suo insieme), visto che può servire contemporaneamente due thread.
L'innovazione è appunto quella di sdoppiare la ALU in modo da avere prestazioni paragonabili a quelle di un dual core.
La FPU, nonostante abbia due unità di esecuzione FMAC (anche prima le unità di esecuzione FP erano 2, anche se meno generiche di un FMAC), non è assolutamente sdoppiata. In un certo istante entrambe le unità FMAC possono essere assegnate ad un solo thread.

Originariamente inviato da calabar

E dal momento che i core si contano sulle unità int... allora è un dual core a tutti gli effetti

Storicamente questo è vero, però dipendeva dal fatto che un tempo le unità FP erano esterne.

Originariamente inviato da calabar

PS: non sono ancora convinto del fatto che l'unità FP abbia SMT.

Guarda quello che ho risposto sopra.

[calabar]

Originariamente inviato da cionci

per definire se una CPU è o meno SMT bastava contare quanti thread ci sono ad un certo istante in esecuzione in un solo core.

In questo caso avresti sicuramente ragione.
Io ho sempre valutato però SMT non solo come il numero di thread in esecuzione, ma anche il modo in cui questo avveniva.
Ossia SMT non è solo un risultato, ma anche un tipo di approccio per ottenerlo.

In questo la FP di Bulldozer mi sembra differente da quanto vediamo nei processori Intel con SMT.
Esiste una definizione "ufficiale" di SMT?

PS: allora anche la FP del k10 era con SMT?

[cionci]

Originariamente inviato da calabar

In questo la FP di Bulldozer mi sembra differente da quanto vediamo nei processori Intel con SMT.
Esiste una definizione "ufficiale" di SMT?

In simultaneous multithreading, instructions from more than one thread can be executing in any given pipeline stage at a time.

Originariamente inviato da calabar

PS: allora anche la FP del k10 era con SMT?

No, Fino al BD tutte le CPU AMD in un dato istante, in ogni stage della pipeline, hanno sempre processato istruzioni appartenenti ad un solo thread.

[checo]

in ottica futura il concetto di core inteso come core int e core fpu non avrà alcuna valenza.
in futuro mi aspetto che un modulo buldozzer sia composto da 4 core int ed una fpu/gpu(il fusion 2)

il tutto dipende da 2 cose però
gli stream processor della gpu devono diventare più versatili(ma la strada intrapresa da ati ed nvidia sembra quella)
il sw deve avvicinarsi a questo.
un fpu classica imho verrà mantentua per compatibilità il grosso del lavoro lo dovrebbe fare la parte gpu.

ora perchè questo avvenga anche intel dovrebbe muoversi su quella strada, ma per il momento non ha le tecnologie necessarie, quindi mi sa che rimarrà solo un bel sogno per molto tempo

[paolo.oliva2]

Ieri ho fatto una prova con Boinc, facendo lavorare la VGA (5770 con 512MB, nulla di eccezionale) comparandola con il procio.

D'accordo che la VGA ha tutti i suoi limiti e chi più ne ha, più ne metta... ma guardate i tempi di elaborazione:



In 40 minuti un core Thuban a 4,2GHz ha elaborato il 9%... la 5770 in 12 minuti ha elaborato il 100%.

Se fra 3 anni il progetto Fusion2 diventerà realtà, il procio più potente attualmente diventerebbe il procio di un telefonino, al confronto.

P.S.
Il Vcore segnato da CPU-Z è sbagliato... 1,620V LOL. Il valore corretto, come riportato da K10Stat, è 1,45V. (vorrei vedere avere 47° a pieno carico come X6 a 1,62V )

[bjt2]

Allora... Per smorzare un po' i toni e per chiarire una volta per tutte vado forse un po' OT (e il capitano e sopratutto i moderatori mi perdonino)...

Parliamo del confronto Sandy bridge core vs Bulldozer module.

2 thread vs 2 thread. Poi vediamo un confronto alla buona 1 thread vs 1 thread considerando metà delle risorse condivise.

Decodifica istruzioni:
Un core SB può decodificare al massimo 3 istruzioni semplici e una complessa oppure una sola microcodificata alla velocità di 3 uop per ciclo, questo per ciclo di clock e per un dato thread, mentre un core BD può decodificare un qualsiasi mix di istruzioni semplici o moderatamente complesse (2 mops) purchè non si superi le 4 mops per ciclo, oppure una microcodificata alla velocità di 4 mop per ciclo, tutto questo per ciclo e per thread. Anche ammettendo che le uop intel siano equipotenti alle mops AMD, qui c'è un chiaro vantaggio AMD (ancora maggiore se si pensa che le MOP amd ammettono fino a 3 ingressi e una uscita, vedi FMAC, mentre quelle INTEL max 2 ingressi e una uscita, da cui le FMA3). Se il mix di istruzioni non è del tipo complessa+3 semplici, il decoder INTEL perde MOLTISSIMO in prestazioni. Per fortuna che un compilatore decentemente inteligente riordina le istruzioni quando possibile, ma il rischio ovviamente c'è... Però per compensare, SB usa una cache delle microoperazioni che può sparare fino a 18 uop/ciclo... Non si sa se anche BD la usa. E i branch prediction sono stati migliorati sia in SB che BD e non si sa quale sia meglio. L'approccio del BD con le code degli IP predetti è però interessante...

Dispatch:
Qui dovrebbe avvenire il micro/macro op fusion. Entrambe le architetture possono fare il dispatch di 4 uops/mops. L'architettura INTEL può fare una uop fusion per ciclo, arrivando a 5. Anche BD può fare la uop fusion, ma non si sa se una o più di una e in che casi. Comunque considerando le MOP e le uop equivalenti in potenza (anche se non è vero), siamo in situazione di parità.

ROB:
Qui INTEL ha un enorme ROB che deve dare spazio a due thread (160 uop). AMD ha 2 ROB (da 128 mops l'uno) per il fatto che i due cores sono fisicamente separati. Qui giacciono le istruzioni in attesa di esecuzione o di ritiro.

Scheduler:
Qui le differenze si fanno interessanti. AMD separa INT e FP. Ha 2x40 mops intere/memoria più 60 mops FP, condivise tra i due thread. INTEL ha un unico calderone di soli 54 elementi condivisi tra interi, memoria FP e per di più di entrambi i thread. E' inutile dire chi ha le potenzialità maggiori...

Esecuzione:
INTEL ha 6 porte dove sparare le micro ops. Quindi può sparare 6 uop per ogni ciclo di clock, condiviso tra due thread. 3 porte sono dedicate alla memoria: 2 per le 2 AGU e una per gli store. 3 porte sono per le operazioni. Badate bene: le 3 porte residue sono CONDIVISE tra operazioni INT e SIMD/FP di ENTRAMBI i thread. Ossia in ogni ciclo si possono al massimo fare 3 operazioni tra INT e FP/SIMD.
AMD può, per ogni ciclo di clock e per 2 thread, sparare: 4 istruzioni FP (di entrambi i thread), 4 AGU/memoria (2 per thread max) e 4 ALU/intere (2 per thread MAX).
Considerando che anche un codice fortemente FP comunque contiene istruzioni per i loop, salti, confronti, insomma contiene istruzioni INTERE che su INTEL si contendono le 3 porte (per di più i thread sono 2!) mentre su AMD corrono su binari separati. Solo le istruzioni per la memoria hanno binari separati. Ma questo anche in AMD. Ecco che il potenziale AMD è maggiore.

Memoria:
Su SB si possono fare 2 letture a 128 bit e una scrittura a 128 bit per ciclo. Poichè però la cache L1 ha solo 2 porte, questo può essere fatto per breve tempo. E comunque queste 3 operazioni devono essere condivise tra i due threads.
Su BD, invece, ogni thread ha la sua cache L1, le sue 2 porte, le sue due letture a 128 bit e scrittura a 128 bit, le sue code di lettura e scrittura e le sue AGU. Inutile dire chi vince in questo caso.
E' vero che SB può fare fino a 3 operazioni FP a 256 bit per ciclo (1 add, 1 mul e una shuffle), ma può farlo per molto? No.

Retirement:
Qui siamo 4 a 4, ma sempre presupponendo che le mops AMD non siano più potenti di quelle INTEL.

Frequenza operativa:
A giudicare dalle latenze delle caches, sembrerebbe che BD possa avere un clock nettamente superiore a SB. Poichè la banda memoria è maggiore, anche a parità di clock, i due thread dovrebbero scorrere più fluidamente su un BD, considerando che la velocità di ritiro è la stessa e supponendo che le unità prima dello stadio di ritiro siano veloci a sufficienza (più probabile per BD che per SB alla luce di quanto visto). Se poi consideriamo che il clock sarà probabilmente maggiore...

Confronto alla buona 1 thread vs 1 thread considerando metà delle risorse condivise. In realtà in INTEL alcune risorse sono condivise dinamicamente.

Decodifica istruzioni:
Qui valgono le stesse considerazioni del 2 vs 2 considerando che la decodifica è probabilmente fatta a cilci alterni.

Dispatch:
Qui valgono le stesse considerazioni del 2 vs 2 considerando che il dispatch è probabilmente fatto a cilci alterni.

ROB:
Qui INTEL ha un enorme ROB condiviso, quindi un thread ha da 0 a 160 uop di spazio. AMD ha ROB separati da 128 mops l'uno. A secinda del carico INTEL può essere svantaggiato o meno. In un caso medio siamo 80 vs 128.

Scheduler:
AMD ha 40 mops int + 0-60 mops FP. In media 40+30.
INTEL ha 0-54 uops condivise. In media 27 totali.
La differenza è alta anche nel caso peggiore.

Esecuzione:
INTEL ha 0-6 porte disponibili per un thread. In media 3.
AMD ha 2 ALU + 2 AGU/MEM + 0-4 FP. In media 2+2+2.
La differenza è alta anche nel caso peggiore.

Memoria:
INTEL da 0 a 3 operazioni memoria. In media 1.5.
AMD 3 operazioni memoria.
Inutile dire chi vince in questo caso.

Retirement:
Qui siamo 4 a 4, ma sempre presupponendo che le mops AMD non siano più potenti di quelle INTEL.

Frequenza operativa:
Entrambi qui hanno il turbo. Il leackage in AMD è di partenza più basso. Poi lo spegnimento dei core con gli NFET è più efficiente. Prevedo che per AMD la frequenza turbo core sia ancora più elevata...




Conclusioni:
In sostanza a parità di thread Bulldozer dovrebbe surclassare SB. A parità di cores (come li intendono INTEL e AMD) non è detto che AMD la spunti. Ma comunque c'è addirittura questa possibilità...

[capitan_crasy]

Originariamente inviato da bjt2

Allora... Per smorzare un po' i toni e per chiarire una volta per tutte vado forse un po' OT (e il capitano e sopratutto i moderatori mi perdonino)...

Parliamo del confronto Sandy bridge core vs Bulldozer module.

2 thread vs 2 thread. Poi vediamo un confronto alla buona 1 thread vs 1 thread considerando metà delle risorse condivise.

Decodifica istruzioni:
Un core SB può decodificare al massimo 3 istruzioni semplici e una complessa oppure una sola microcodificata alla velocità di 3 uop per ciclo, questo per ciclo di clock e per un dato thread, mentre un core BD può decodificare un qualsiasi mix di istruzioni semplici o moderatamente complesse (2 mops) purchè non si superi le 4 mops per ciclo, oppure una microcodificata alla velocità di 4 mop per ciclo, tutto questo per ciclo e per thread. Anche ammettendo che le uop intel siano equipotenti alle mops AMD, qui c'è un chiaro vantaggio AMD (ancora maggiore se si pensa che le MOP amd ammettono fino a 3 ingressi e una uscita, vedi FMAC, mentre quelle INTEL max 2 ingressi e una uscita, da cui le FMA3). Se il mix di istruzioni non è del tipo complessa+3 semplici, il decoder INTEL perde MOLTISSIMO in prestazioni. Per fortuna che un compilatore decentemente inteligente riordina le istruzioni quando possibile, ma il rischio ovviamente c'è... Però per compensare, SB usa una cache delle microoperazioni che può sparare fino a 18 uop/ciclo... Non si sa se anche BD la usa. E i branch prediction sono stati migliorati sia in SB che BD e non si sa quale sia meglio. L'approccio del BD con le code degli IP predetti è però interessante...

Dispatch:
Qui dovrebbe avvenire il micro/macro op fusion. Entrambe le architetture possono fare il dispatch di 4 uops/mops. L'architettura INTEL può fare una uop fusion per ciclo, arrivando a 5. Anche BD può fare la uop fusion, ma non si sa se una o più di una e in che casi. Comunque considerando le MOP e le uop equivalenti in potenza (anche se non è vero), siamo in situazione di parità.

ROB:
Qui INTEL ha un enorme ROB che deve dare spazio a due thread (160 uop). AMD ha 2 ROB (da 128 mops l'uno) per il fatto che i due cores sono fisicamente separati. Qui giacciono le istruzioni in attesa di esecuzione o di ritiro.

Scheduler:
Qui le differenze si fanno interessanti. AMD separa INT e FP. Ha 2x40 mops intere/memoria più 60 mops FP, condivise tra i due thread. INTEL ha un unico calderone di soli 54 elementi condivisi tra interi, memoria FP e per di più di entrambi i thread. E' inutile dire chi ha le potenzialità maggiori...

Esecuzione:
INTEL ha 6 porte dove sparare le micro ops. Quindi può sparare 6 uop per ogni ciclo di clock, condiviso tra due thread. 3 porte sono dedicate alla memoria: 2 per le 2 AGU e una per gli store. 3 porte sono per le operazioni. Badate bene: le 3 porte residue sono CONDIVISE tra operazioni INT e SIMD/FP di ENTRAMBI i thread. Ossia in ogni ciclo si possono al massimo fare 3 operazioni tra INT e FP/SIMD.
AMD può, per ogni ciclo di clock e per 2 thread, sparare: 4 istruzioni FP (di entrambi i thread), 4 AGU/memoria (2 per thread max) e 4 ALU/intere (2 per thread MAX).
Considerando che anche un codice fortemente FP comunque contiene istruzioni per i loop, salti, confronti, insomma contiene istruzioni INTERE che su INTEL si contendono le 3 porte (per di più i thread sono 2!) mentre su AMD corrono su binari separati. Solo le istruzioni per la memoria hanno binari separati. Ma questo anche in AMD. Ecco che il potenziale AMD è maggiore.

Memoria:
Su SB si possono fare 2 letture a 128 bit e una scrittura a 128 bit per ciclo. Poichè però la cache L1 ha solo 2 porte, questo può essere fatto per breve tempo. E comunque queste 3 operazioni devono essere condivise tra i due threads.
Su BD, invece, ogni thread ha la sua cache L1, le sue 2 porte, le sue due letture a 128 bit e scrittura a 128 bit, le sue code di lettura e scrittura e le sue AGU. Inutile dire chi vince in questo caso.
E' vero che SB può fare fino a 3 operazioni FP a 256 bit per ciclo (1 add, 1 mul e una shuffle), ma può farlo per molto? No.

Retirement:
Qui siamo 4 a 4, ma sempre presupponendo che le mops AMD non siano più potenti di quelle INTEL.

Frequenza operativa:
A giudicare dalle latenze delle caches, sembrerebbe che BD possa avere un clock nettamente superiore a SB. Poichè la banda memoria è maggiore, anche a parità di clock, i due thread dovrebbero scorrere più fluidamente su un BD, considerando che la velocità di ritiro è la stessa e supponendo che le unità prima dello stadio di ritiro siano veloci a sufficienza (più probabile per BD che per SB alla luce di quanto visto). Se poi consideriamo che il clock sarà probabilmente maggiore...

Confronto alla buona 1 thread vs 1 thread considerando metà delle risorse condivise. In realtà in INTEL alcune risorse sono condivise dinamicamente.

Decodifica istruzioni:
Qui valgono le stesse considerazioni del 2 vs 2 considerando che la decodifica è probabilmente fatta a cilci alterni.

Dispatch:
Qui valgono le stesse considerazioni del 2 vs 2 considerando che il dispatch è probabilmente fatto a cilci alterni.

ROB:
Qui INTEL ha un enorme ROB condiviso, quindi un thread ha da 0 a 160 uop di spazio. AMD ha ROB separati da 128 mops l'uno. A secinda del carico INTEL può essere svantaggiato o meno. In un caso medio siamo 80 vs 128.

Scheduler:
AMD ha 40 mops int + 0-60 mops FP. In media 40+30.
INTEL ha 0-54 uops condivise. In media 27 totali.
La differenza è alta anche nel caso peggiore.

Esecuzione:
INTEL ha 0-6 porte disponibili per un thread. In media 3.
AMD ha 2 ALU + 2 AGU/MEM + 0-4 FP. In media 2+2+2.
La differenza è alta anche nel caso peggiore.

Memoria:
INTEL da 0 a 3 operazioni memoria. In media 1.5.
AMD 3 operazioni memoria.
Inutile dire chi vince in questo caso.

Retirement:
Qui siamo 4 a 4, ma sempre presupponendo che le mops AMD non siano più potenti di quelle INTEL.

Frequenza operativa:
Entrambi qui hanno il turbo. Il leackage in AMD è di partenza più basso. Poi lo spegnimento dei core con gli NFET è più efficiente. Prevedo che per AMD la frequenza turbo core sia ancora più elevata...




Conclusioni:
In sostanza a parità di thread Bulldozer dovrebbe surclassare SB. A parità di cores (come li intendono INTEL e AMD) non è detto che AMD la spunti. Ma comunque c'è addirittura questa possibilità...

In prima pagina!!!
Clicca qui!!!

[ArteTetra]

Originariamente inviato da bjt2

Allora... Per smorzare un po' i toni e per chiarire una volta per tutte vado forse un po' OT (e il capitano e sopratutto i moderatori mi perdonino)...

Parliamo del confronto Sandy bridge core vs Bulldozer module.

[...]

Finalmente qualcuno che se ne intende davvero.

[JDM70]

un grosso Applauso a bjt2 e Capitan-crasy

[paolo.oliva2]

Edit:
Ho capito... a parità di TH.
Quindi si starebbe confrontando il modulo AMD al core + SMT Intel.

Capito....

Quindi Un BD X8 vs SB 4+4 se fossero ambedue a parità di clock, AMD schianterebbe comunque SB.
Ora si tratterebbe di capire di quanto, che differenza di clock è in grado di assegnare AMD, ed i prezzi.

Praticamente a spanna BD X8 con il vantaggio del clock superiore dovrebbe comunque essere più potente di SB X6... con SB X8 bisogna vedere quanto Intel ha migliorato l'SMT, perché se consideriamo che un i980X con il 50% in più di core e TH logici guadagna solo il 22% rispetto ad un i7 X4, Intel qualche cosa deve aver fatto, altrimenti un SB X8 avrebbe forse anche solo un +10% rispetto ad un SB X6 ma con un costo del 33% più alto... e il tutto accentuato da con clock più basso...sarebbe da castramento.

Comunque la lotta mi sembra molto aperta, specialmente se AMD assegnasse a BD X8 prezzi sui 400-500€ max, anche perché il die Intel ha una superficie superiore e quindi maggiori costi dalla nascita.

[Athlon 64 3000+]

Interessante le caratteristiche di Buldozer.
Leggendo le caratteristiche dell'architettura della futura gpu top di gamma AMD mi viene da pensare che un Buldozer x4(2 moduli) possa superare in ambito multithreading il Thuban x6 e l'i7 x4 sia LGA 1366 che 1156.

[paolo.oliva2]

Originariamente inviato da Athlon 64 3000+

Interessante le caratteristiche di Buldozer.
Leggendo le caratteristiche dell'architettura della futura gpu top di gamma AMD mi viene da pensare che un Buldozer x4(2 moduli) possa superare in ambito multithreading il Thuban x6 e l'i7 x4 sia LGA 1366 che 1156.

Pure secondo me...
Io una volta non ero convinto molto dell'IPC, anche se l'ho sempre considerato superiore al Phenom II di un 10-15%.
Ma sono sempre più convinto che le potenzialità di BD sono state fino ad ora sottovalutate alla grande.

E poi non capisco il pessimismo... Già solo il passaggio al 32nm HKMG porterà un vantaggio tutt'altro che trascurabile.

Sarebbe come passare da un Thuban 3,2GHz X6 3,6GHz Turbo a 4GHz X8 e 5GHz Turbo... insomma, saremmo oltre il +40% per il monocore e +43% per il multicore (+33% per i 2 core in più e +30% per il clock). Già questi numeri sarebbero più che sufficienti per promuovere AMD alla grande...

Per l'IPC, un INT in più, la L2 di 2MB condivisa contro 512KB del Phenom II, la L3 di 8MB contro i 6MB, il Turbo molto più spinto, l'MC per fornire più banda, secondo me è assurdo non mettere sulla bilancia tutto questo e addirittura considerarlo "inferiore" al Phenom II.