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

[astroimager]

Originariamente inviato da SwatMaster

Speriamo, cavolo...
Io stanotte ho sognato che mia madre tirava fuori un BD otto-core dal frigorifero.

Strane perversioni...

[z3d]

Originariamente inviato da SwatMaster

Speriamo, cavolo...
Io stanotte ho sognato che mia madre tirava fuori un BD otto-core dal frigorifero.

ma lol! XD

Tornando IT, se Bulldozer sarà veramente prestante e paragonabile a Sansy Bridge, farò subito mio un Octacores!

[digieffe]

Originariamente inviato da z3d

ma lol! XD

Tornando IT, se Bulldozer sarà veramente prestante e paragonabile a Sansy Bridge, farò subito mio un Octacores!

da elucubrazioni varie, penso che, probabilmente andrà negli interi scalari (clock to clock) quanto un SB senza HT (2500), cosa più cosa meno.
Per quanto riguarda simd di tipo int e fp ho grosse perplessità su questa flexfp che è da vedere alla prova dei fatti....

Originariamente inviato da capitan_crasy

Oppure non hanno ancora per le mani le CPU sample per i BIOS e la documentazione tecnica di BD, spacciando una tolleranza elettrica al socket AM3+ come compatibilità assoluta...
Questa faccenda sta assomigliando sempre di più ad una scenetta di Benny Hill...

Non sei il primo che me lo dice...
Girano anche voci di sample a 4 core, lo stop dello sblocco dei core con BD, ecc...

[Athlon 64 3000+]

Originariamente inviato da Labview

Non sei il primo che me lo dice...
Girano anche voci di sample a 4 core, lo stop dello sblocco dei core con BD, ecc...

Oltre che sample a 8 core girano anche quelli di BD x4?
Magari sarebbe un indicazione del fatto che potrebbe essere nativo visto che nelle slide AMD veninva riportato con 4MB di cache L3 contro gli 8 delle versione x6 e x8.

[bjt2]

Originariamente inviato da capitan_crasy

Ciao:
E' uscito il "Software Optimization Guide for AMD Family 15h Processors"...
Appena hai un attimo di tempo prova a darci un occhiata...
Clicca qui...
Un saluto...

Allora... Menziono le cose più importanti mano a mano che leggo...


- E' confermato che internamente BD usa ancora macro-op (operazione intera oppure FP + operazione memoria). Ciò è importante per stabilire quanto riesce a macinare...

- E' confermato che esistono ancora operazioni single, double e vector (anche se i nomi sono cambiati: FastPath Single, FastPath Double e Microcode). Ciò è importante per stabilire la potenza del decoder.

- Parla delle istruzioni supportate: AVX, XOP, FMA(C) ecc... Tutto confermato. Più qualche cosa poco nota come istruzioni per l'estrazione della parte frazionaria di un numero FP e istruzioni vettoriali di rotazione, shift, shuffle.

- Menziona le nuove unità FP a 128 bit e dice che le prestazioni possono essere fino al doppio. Non mi è chiaro questo punto. Anche le unità del K10 sono a 128 bit. Ma poi spiega l'uso del FMAC che non è automatico e dice che l'FMA è più preciso di una ADD+MUL (si sapeva già). Forse è a questo che si riferisce quando parla di prestazioni doppie.

- Ora BD non soffre più in prestazioni se le istruzioni sia di load/store, sia load/execute lavorano su dati non allineati. Possibili benefici con codice con dati non allineati. Questo potrebbe essere un refuso del documento del K10. Mi pare di ricordare che era una delle novità del passaggio da K8 a K10...

- Novità del fetching istruzioni. Non più una finestra di 32 bytes, ma DUE finestre di 32 bytes da cui possono essere prodotte fino a 4 mops/ciclo. Si accenna al fatto che queste due finestre assieme alla FPU a 128 bit consentono di avere un ritmo di fetch/execute/retire di 4 mops/ciclo... Ora come ora è molto nebulosa la cosa. Non menziona mai il fatto che è condivisa tra due thread...

- Accenno al fatto che molte istruzioni sono state promosse da vector a double o a single, che sono migliorate le latenze e che molte istruzioni FPU sono state spostate di pipe... ATTENZIONE! Fino ad ora avevamo supposto che l'architettura a FO4 17 avrebbe comportato l'aumento delle latenze delle istruzioni... Secondo quanto scritto qui E' IL CONTRARIO! Potrebbe anche questo essere un refuso della modifica del documento del K10.

- Miglioramento in velocità delle istruzioni di shuffle, di trasferimento registri FP-interi (nonostante la FP condivisa!), di trasferimento FP-FP (quello a cui accennava JF-AMD degli zero latency move), delle operazioni su stringhe (i vari REP, SCAS ecc), delle operazioni stack e del paging a 1GB.

- Le operazioni di shuffle (tallone di achille) possono essere fatte al quadruplo della velocità grazie a più unità, al fatto che sono a 128 bit (???) e ora le istruzioni sono Direct Path e non vector path (mi sa che è un refuso del vecchio documento perchè parla delle pipeline FADD, FMUL e FSTORE... anche per le operazioni di move reg-reg)

- poi parla delle TLB e della virtualizzazione.

--- FINE SEZIONE INTRODUTTIVA ---

- Confermate le cose che si sapevano sull'architettura (caches ecc). Predizione e fetch sono disaccoppiati, decoding a 4 vie (limite teorico). Scheduling dinamico. 2 istruzioni ALU + 2 AGU per ciclo (confermato). 2 128 BIT FPU. Supporto AVX, XOP ecc. Superforwarding (probabilmente quella cosa del poter usare subito i risultati di una operazione).

- Descrive il fatto delle 4 microop/ciclo. Dice che può fare il fetch di 32 bytes per ciclo e che puo fare la scansione di due blocchi da 16 bytes per ciclo (su due finestre di 32 bytes). Può decodificare fino a 4 mops/ciclo. E' un limite teorico che dipende dalle istruzioni presenti nelle finestre di 16 bytes e anche dalla modalità in cui si trova la CPU: FAST o SLOW (???)

- Schema a blocchi della CPU: nulla da notare se non che non divide le ALU/AGU ma le chiama genericamente pipeline e anche qui la FPU è indicata con solo le due pipeline a 128 bit...

- Caches: L1 istruzioni UNICA da 64 KB, a 2 vie con linea da 64 bytes e lettura di 32 bytes (come quella del K10). Quando è letta una nuova cache line è automaticamente fatto il prefetch di quella successiva. Il predecoing è fatto subito dopo il load. La L1 dati è da 16 KB. Può fare 2 load a 128 bit per ciclo. Ha 16 banchi e un solo load per banco. Quindi i due load sono simultanei se sono in banchi separati. Latenza di 4 cicli (! data l'alta latenza, prevedo clock stratosferici). Menziona genericamente il prefetching. La cache L1 è write through e non write back come il K10... Hanno imparato da INTEL... Ci sono vantaggi nello snooping. Solo la cache L2 va testata... Quest'ultima appunto è inclusiva e condivisa tra i due core. Menziona il write trough e finalmente conferma che le caches sono due. La latenza è 18-20 cicli e la cache è full speed (quindi con il clock alto... ). Il perchè è presto detto: la dimensione è dipendente dall'implementazione! Ci possono essere modelli con più o meno L2 per core (magari parzialmente disattivata per difetti...). La cache L3 può essere massimo 8MB con 4 blocchi di massimo 2MB (anche qui il binning per difettosità...). La cache L3 è non inclusiva e victim buffer. Ci vanno i dati buttiati dalle L2. Un dato rimane nella L3 se è usato da più cores (un predittore?). Altrimenti va nella L1 del core che la usa. La L3 è dichiarata migliorata come banda. Latenza non specificata.

- Branch prediction: penalità da 15 a 20 cicli in caso di miss. In caso di hit, un solo ciclo se è nella cache L1, 4 cicli se è nella L2. La L1 è 4x128 entry e la L2 5x1024 entry. 512 entry per gli indiretti e 24 per il return stack. Il branch prediction è abbastanza complesso ma credo che sia simile a quello del K10...

- Fetch e decode. Sono letti 32 bytes/ciclo. Le finestre sono di 16 bytes e esistono due code (una per thread). Si possono decodificare fino a 4 istruzioni per ciclo contenute in 2 finestre a 16 bytes.

- TLB: L1 istruzioni 48 4KB, 24 2MB o 1GB. Entry da 4MB occupano due entry da 2MB. L1 dati 32 (64 per i modelli 20H-2FH) per 4KB, 2MB e 1GB. Entry da 4MB occupano due entry da 2MB. L2 istruzioni 512 4KB. L2 dati 1024 condiviso tra 4KB, 2MB e 1GB. Entry da 4MB occupano 2 slot.

- Esecuzione intera: c'è lo scheduler e le unità di esecuzione. Lo scheduler è completamente data-driven. Non ci sono più le lane del K10. Ossia è più inteligente: l'unico limite è la disponibilità dei dati e delle unità. Inoltre tiene traccia del completamento e delle eccezioni delle istruzioni FP: è questa unità che decide il da farsi. L'unità FP fa solo il "lavoro sporco"... Lo scheduler intero può ricevere e schedulare fino a 4 mops/ciclo. Fa il register renaming e sveglia le istruzioni in attesa. Le unità di esecuzione sono 4. ATTENZIONE: 2 ALU e 2 AGLU. Le due ALU sono chiamate Ex0 e Ex1. Possono fare tutte le operazioni aritmetiche, logiche e di shift. La Ex0 fa anche DIV e POPCNT. La EX1 fa anche MUL e BRANCH. Le AGLU possono fare le AGU e operazioni ALU SEMPLICI. NOVITA' rispetto al K10: le mops sono divise nello scheduler in microops. Possono essere eseguite indipendentemente e fuori ordine (non più le lanes... ) quando dati e unità esecutiva sono libere, in particolare in contemporanea in ALU e AGLU separate. Lo scheduler può ricevere 4 MOPS/ciclo (quindi potenzialmente 4 istruzioni intere più 4 memoria). Questo è un dispatch group. Il divisore di EX0 non è pipelined ed è a latenza variabile. Il moltiplicatore in EX1 è pipelined. L'AGLU contiene una ALU semplice per fare istruzioni aritmentico logiche semplici... Guardando le tabelle delle latenze sembra che le AGLU siano sfruttate in poche istruzioni, giusto per non usare le EX unit. LZCNT e POPCNT sono gestite in EX0.

- FPU. E' dichiarato che la FPU ha 4 volte la potenza di picco di quella del K10. 4 pipeline. 2 FMAC a 128 bit. Una può fare anche le IMAC (multiply - accumulate su dati interi) e le conversioni tra int e fp e una ha un crossbar per gli shuffle SIMD. 2 unità SIMD intere per MMX e SIMD intere. Una delle due ha la pipeline FSTORE. C'è poi una unità di load/store che può fare 2 letture a 128 bit + una scrittura a 128 bit. La CPU può ricevere fino a 4 mops/ciclo, ma da un solo thread alla volta. Il thread può cambiare a ogni ciclo. La FPU può eseguire 4 mops/ciclo. Una volta ricevute in cicli separati, poi possono essere eseguite anche inframezzate nello stesso ciclo, al ritmo di 4/ciclo. Nella FPU possono essere accettati fino a 2 loads per ciclo, anche da 2 thread separati. 4 pipeline, 2 FP e 2 INT. 2 128 bit FMAC. Ognuno può fare anche ADD e MUL anche x87. Ogni FMAC ha anche un divisore e calcolo radice quadrata a latenza variabile. Una istruzione a 256 bit può essere eseguita in un ciclo. Se non ci sono due unità libere è spezzata in due senza penalità. Cioè in pratica una istruzione a 256 bit è spezzata in due subistruzioni a 128 bit che possono essere eseguite indipendentemente (e anche in due cicli separati) senza bloccare le altre. Massima flessibilità, dunque.

- Unità di load/store. Una per core, due per modulo. Ogni unità supporta 2 letture a 128 bit e una scrittura a 128 bit per ciclo. La coda di scrittura è di 24 entry. La coda di lettura ha 40 entry. Due pipeline per ogni unità LS per fare 2 operazioni in contemporanea. Menziona il fuori ordine per le operazioni memoria ma non entra nei dettagli. Il write combining supporta 4 stream, con 4 buffer da 64 bytes (condivisi tra i due cores). C'è una cache di 4KB prima della L2 (64 blocchi da 64 bytes) per gestire il write combining da sorgenti varie (compreso il write chaining per la trasmissione su bus HT).

- Controller RAM. Supporta DIMM da 4, 8 e 16 bit, interleaving, ECC, e canali a 64 bit indipendenti. Ha algoritmi di scheduling e predizione ottimizzati in particolare per sequenze alternate di read e write. Il prefetcher tiene i dati nel controller e non li spedisce alle caches. Può adattarsi a pattern ascendenti e discendenti e altri più complicati. Le specifiche del MC possono cambiare da modello a modello.

- HT: supporto a 25.6GB/s (quindi 3.2 GHz) e varie features dell'HT 3. HT assist per sistemi a 4 o più socket: ancora con consumo di 1-2 MB di L3.

- Branch fusion. Non è specificato un limite al numero massimo di branch fusion però molto probabilmente al massimo uno. Perchè i limiti sono che il compare e il branch devono essere adiacenti, che il compare non deve essere la quarta istruzione del dispatch group, che il branch deve avere indirizzamento rip-relativo, che il compare non deve avere dati immediati o indirizzamento SIB.

- LATENZE istruzioni. Purtroppo è difficile confrontare le latenze senza avere a fianco quelle del K10. Ci dobbiamo fidare dei proclami dell'inizio del PDF. Molte istruzioni hanno un N/A, non so se per NDA oppure perchè effettivamente al tempo di stesura del PDF non erano note. Però lo scheduler data-driven, le uops che possono andare indipendentemente, le pipeline intere e FP separate possono addirittura far sperare in un IPC superiore al SB!

Questo è quanto...

[bjt2]

Originariamente inviato da Pihippo

Ciao
C'è una flessibilità maggiore, ma leggendo l'appendice B pare che le Aglu intervengano ad eseguire la metà di una op fastpath double, intendendo con essa una istruzione che viene decodificata in 2 op da eseguire. Detto ciò, una Alu esegue una micro op e la Aglu l'altra micro op della op iniziale, da quella tabella questo pare sia il caso di poche istruzioni a dire il vero Ovvero CALL, LEA ed altra robettina. A quanto pare un add non lo possono fare. Questo è spiegabile dal fatto che si incasinerebbero con i flag dei registri. Almeno penso.

Hai ragione... Non ci avevo fatto caso...

[Pihippo]

Originariamente inviato da bjt2

Hai ragione... Non ci avevo fatto caso...

Ciao
La parte più triste è quella riguardante le SSE3 (HADDPS ecc ecc) nell'appendice B. Vabbè che non sono utilizzatissime, ma posso già immaginare bench (che magari non fanno niente di utile) in cui Sb andrà il 50% in più di BD.

[paolo.oliva2]

Originariamente inviato da Pihippo

Ciao
La parte più triste è quella riguardante le SSE3 (HADDPS ecc ecc) nell'appendice B. Vabbè che non sono utilizzatissime, ma posso già immaginare bench (che magari non fanno niente di utile) in cui Sb andrà il 50% in più di BD.

Non mettendo becco perché comunque ancora non sono riuscito a comprendere le potenzialità di BD ( ), comunque nel discorso della potenza finale rimane pur sempre il fatto di quale clock avrà BD.

Cioè... quello che voglio dire, è che BD per essere nel complesso superiore a SB si potrebbe accontentare anche di un IPC inferiore, probabilmente basterebbe addirittura un IPC -20%.

Ti faccio questo esempio sia in ST che in MT:

ST - Applicando un clock di 4GHz def con almeno 2 moduli (BD X4), nel funzionamento come X1 arriverebbe praticamente a 5GHz. Anche avendo un IPC del 20% inferiore, comunque avrebbe un clock del 20% superiore, da qui uscirebbe un risultato di pareggio, e comunque saremmo nel campo dove AMD doveva recuperare di più.

MT - AMD ha sempre scalato meglio con l'aumentare dei core rispetto ad Intel, quindi in ogni caso dovrebbe essere leggermente più favorita rispetto all'ST. Ora... assegnando 3,5GHz ad un SB X8 130W e 4GHz ad un BD X8 125W, AMD avrebbe dalla sua un +14% di clock. Se poi considerassimo il Turbo di +500MHz su tutti i core, arriveremmo oltre al +33%. Anche in questo caso, con un IPC pure del 20% inferiore, un BD X8 con Turbo2 disabilitato sarebbe comunque lì, e sicuramente sopra in Turbo.

Dal mio punto di vista, come potenzialità rispetto al Phenom II, anche senza considerare BD X8 e parlando di numero core uguali, mi sembra nettamente scontato che il +50% di potenza venga superato. Il solo clock operativo vedrebbe in BD un vantaggio del +26%/+27%, sia in ST che in MT.
A questo andrebbe aggiunto comunque l'incremento di IPC a cui andrebbero sommati in MT i +2 core di un BD X8 rispetto ad un Thuban X6.

[Pihippo]

Originariamente inviato da paolo.oliva2

Non mettendo becco perché comunque ancora non sono riuscito a comprendere le potenzialità di BD ( ), comunque nel discorso della potenza finale rimane pur sempre il fatto di quale clock avrà BD.

Cioè... quello che voglio dire, è che BD per essere nel complesso superiore a SB si potrebbe accontentare anche di un IPC inferiore, probabilmente basterebbe addirittura un IPC -20%.

Ti faccio questo esempio sia in ST che in MT:

ST - Applicando un clock di 4GHz def con almeno 2 moduli (BD X4), nel funzionamento come X1 arriverebbe praticamente a 5GHz. Anche avendo un IPC del 20% inferiore, comunque avrebbe un clock del 20% superiore, da qui uscirebbe un risultato di pareggio, e comunque saremmo nel campo dove AMD doveva recuperare di più.

MT - AMD ha sempre scalato meglio con l'aumentare dei core rispetto ad Intel, quindi in ogni caso dovrebbe essere leggermente più favorita rispetto all'ST. Ora... assegnando 3,5GHz ad un SB X8 130W e 4GHz ad un BD X8 125W, AMD avrebbe dalla sua un +14% di clock. Se poi considerassimo il Turbo di +500MHz su tutti i core, arriveremmo oltre al +33%. Anche in questo caso, con un IPC pure del 20% inferiore, un BD X8 con Turbo2 disabilitato sarebbe comunque lì, e sicuramente sopra in Turbo.

Dal mio punto di vista, come potenzialità rispetto al Phenom II, anche senza considerare BD X8 e parlando di numero core uguali, mi sembra nettamente scontato che il +50% di potenza venga superato. Il solo clock operativo vedrebbe in BD un vantaggio del +26%/+27%, sia in ST che in MT.
A questo andrebbe aggiunto comunque l'incremento di IPC a cui andrebbero sommati in MT i +2 core di un BD X8 rispetto ad un Thuban X6.

Ciao Paolo
Indubbiamente il clock finale di BD conta. Eccome Stabilire le performances di BD ora come ora mi pare abbastanza difficile Il documento non mi pare ben fatto.
Un paio di appunti.
1) SB scala fino a 3.8ghz col turbo in singlethreaded, dunque il clock con 1 core attivi dovrebbe essere un qualcosina in più.
2) Per il MT. Le cose purtroppo raramente vanno cosi, intendo come numeri

[Black_Angel77]

Buonasera, chiedo una cosa sul nuovo socket AM3+.
Io ho una piattaforma Intel con Ram LW, ma le ram LW sono compatibili con le piattaforme AMD?
Nel caso di cambio e passaggio a AM3+ posso tenermi le mie DDR3?
grazie

[liberato87]

AMD Confirms They Will Support Bulldozer on AM3+

..."The pinouts on AM3 and AM3+ are different. However, AM3+ CPUs will physically fit in an AM3 socket."

tuttavia

"AMD will only commit to one thing – they will support Bulldozer on AM3+ chipset boards."

anche se il titolo è piuttosto ad effetto in realtà non cè alcuna conferma! niente di nuovo..

[cionci]

Originariamente inviato da liberato87

AMD Confirms They Will Support Bulldozer on AM3+

..."The pinouts on AM3 and AM3+ are different. However, AM3+ CPUs will physically fit in an AM3 socket."

tuttavia

"AMD will only commit to one thing – they will support Bulldozer on AM3+ chipset boards."

anche se il titolo è piuttosto ad effetto in realtà non cè alcuna conferma! niente di nuovo..

Invece abbiamo la conferma definitiva. Il supporto ufficiale è solo ad AM3+, mentre l'eventuale compatibilità AM3 è lasciata ai produttori.

[Lunar Wolf]

Originariamente inviato da liberato87

AMD Confirms They Will Support Bulldozer on AM3+

..."The pinouts on AM3 and AM3+ are different. However, AM3+ CPUs will physically fit in an AM3 socket."

tuttavia

"AMD will only commit to one thing – they will support Bulldozer on AM3+ chipset boards."

anche se il titolo è piuttosto ad effetto in realtà non cè alcuna conferma! niente di nuovo..

Qualcosa di nuovo c'è no? C'è scritto che cpu am3+ è compattibile fisicamente sul socket am3 ma noi sappiamo che la differenza dei due socket sta in quel pin in piu che am3 non ha quindi se hanno detto che è compattibile vorra dire che sto pin non ci sara!

P.s.: piu quello che ha scritto Cionci!

[paolo.oliva2]

Originariamente inviato da Pihippo

Ciao Paolo
Indubbiamente il clock finale di BD conta. Eccome Stabilire le performances di BD ora come ora mi pare abbastanza difficile Il documento non mi pare ben fatto.
Un paio di appunti.
1) SB scala fino a 3.8ghz col turbo in singlethreaded, dunque il clock con 1 core attivi dovrebbe essere un qualcosina in più.
2) Per il MT. Le cose purtroppo raramente vanno cosi, intendo come numeri

Si, certamente.
Cioè... la mia idea non è tanto quella di chi l'avrà più lungo tra BD e SB, anche perché tutto sommato alla fine probabilmente le potenze saranno lì ma con AMD che dovrebbe essere molto competitiva nel rapporto prezzo-prestazioni.
Quello che sarebbe fantastico, almeno per noi consumatori, sarebbe che Intel realizzi un 22nm da bomba con un IB superlativo, costringendo AMD ad abbassare ulteriormente il prezzo di BD, al che nel 2012 ci potremmo trovare un BD X8 a prezzi del Thuban.

[paolo.oliva2]

Originariamente inviato da cionci

Invece abbiamo la conferma definitiva. Il supporto ufficiale è solo ad AM3+, mentre l'eventuale compatibilità AM3 è lasciata ai produttori.

Quindi se così fosse avresti ragione te, cioè AMD comunque dovrebbe prevedere nel procio una parte di controllo su che socket è montato per prevenire bruciature del procio.

[Dre@mwe@ver]

Originariamente inviato da paolo.oliva2

Quello che sarebbe fantastico, almeno per noi consumatori, sarebbe che Intel realizzi un 22nm da bomba con un IB superlativo, costringendo AMD ad abbassare ulteriormente il prezzo di BD, al che nel 2012 ci potremmo trovare un BD X8 a prezzi del Thuban.

Certo, così AMD sarebbe costretta a chiudere bottega

[z3d]

Originariamente inviato da paolo.oliva2

Quindi se così fosse avresti ragione te, cioè AMD comunque dovrebbe prevedere nel procio una parte di controllo su che socket è montato per prevenire bruciature del procio.

fosse così potremmo tenerci strette le nostre CF IV Formula/Extreme!

[capitan_crasy]

X bjt2:
Grazie per il tuo aiuto, più tardi (se la schiena mi da tregua) metto il tuo post in prima pagina...

Originariamente inviato da Pihippo

Ciao
La parte più triste è quella riguardante le SSE3 (HADDPS ecc ecc) nell'appendice B. Vabbè che non sono utilizzatissime, ma posso già immaginare bench (che magari non fanno niente di utile) in cui Sb andrà il 50% in più di BD.

Ciao:
Puoi fare un esempio (per noi comuni mortali ) di utilizzo delle SSE3 (appendice B come descritto nel documento) su un programma o su un bench?
grazie...

Originariamente inviato da liberato87

AMD Confirms They Will Support Bulldozer on AM3+

..."The pinouts on AM3 and AM3+ are different. However, AM3+ CPUs will physically fit in an AM3 socket."

tuttavia

"AMD will only commit to one thing – they will support Bulldozer on AM3+ chipset boards."

anche se il titolo è piuttosto ad effetto in realtà non cè alcuna conferma! niente di nuovo..

Originariamente inviato da cionci

Invece abbiamo la conferma definitiva. Il supporto ufficiale è solo ad AM3+, mentre l'eventuale compatibilità AM3 è lasciata ai produttori.

Originariamente inviato da Lunar Wolf

Qualcosa di nuovo c'è no? C'è scritto che cpu am3+ è compattibile fisicamente sul socket am3 ma noi sappiamo che la differenza dei due socket sta in quel pin in piu che am3 non ha quindi se hanno detto che è compattibile vorra dire che sto pin non ci sara!

P.s.: piu quello che ha scritto Cionci!

Scusate...
A parte il contenuto della notizia, il sito ha fatto un intervista ad AMD ma non dice ne con chi ne quando; non mi sembra una fonte tanto attendibile...
Mi sembra assolutamente una raccorta delle attuali informazioni e spacciata come "conferma ufficiale"; oltretutto AMD (quella vera) aveva già dichiarato Q2 per Zambezi e Q3 per Interlagos...

[dany700]

Originariamente inviato da paolo.oliva2

Si, certamente.
Cioè... la mia idea non è tanto quella di chi l'avrà più lungo tra BD e SB, anche perché tutto sommato alla fine probabilmente le potenze saranno lì ma con AMD che dovrebbe essere molto competitiva nel rapporto prezzo-prestazioni.
Quello che sarebbe fantastico, almeno per noi consumatori, sarebbe che Intel realizzi un 22nm da bomba con un IB superlativo, costringendo AMD ad abbassare ulteriormente il prezzo di BD, al che nel 2012 ci potremmo trovare un BD X8 a prezzi del Thuban.

anche prima del 2012...

Se il previsto step II arriverà nel 4Q...facile che i proci del lancio...subiranno un taglio di prezzo.

dipenderà solo da Intel...SB su lga2011 sarà poco concorrenziale in termini di prezzo...mentre con Ivy...assisteremo viceversa ad una grande guerra

Chiaro che se quest'ultima sarà lanciata in volumi solo nel 1Q...tutto è rimandato.