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

[cionci]

Originariamente inviato da bjt2

La banda RAM non basta mai. Esisteranno sempre applicazioni per cui il quadchannel da qualche vantaggio. Per esempio applicazioni di calcolo matriciale, dove i calcoli sono delle banali addizioni e moltiplicazioni... Li se usi tutti e 8 core (come fa Matlab) si è RAM bound...

Chiaro che la banda non basti mai, ma non era quello il motivo. Ne facevo più una questione di costi. E' chiaro che un quad channel su un computer da 350-500€ valga una buona percentuale di costi. Senza contare l'obbligo di inserire 4 slot sulle schede madri, invece di due.
Inoltre è un problema anche per le schede madri di alto livello, visto che obbliga ad inserire 8 slot, altrimenti qualsiasi upgrade di memoria sarebbe precluso.
E' chiaro invece che su una workstation influisca meno sul costo finale, visto che una workstation parte da costi decisamente alti.
Paradossalmente influisce di più su un server 1P che su una workstation, visto che le memorie ECC costano molto di più di quelle normali.
Chiaro che se si va oltre il costo aggiuntivo non influisce in percentuale rilevante sul costo finale.

[greeneye]

http://www.semiaccurate.com/2010/11/...-breakthrough/

[checo]

Originariamente inviato da paolo.oliva2

Condivido.
Probabilmente (ma lo immagino, la mia competenza non arriva a tanto), l'utilizzo in ambiente server, con più programmi che sfruttano più core e con più programmi che "girano" contemporaneamente... il tutto è molto più estremizzato... e quindi di qui il potenziamento. Però rimane il fatto che un BD X8 nasce come dual channel sia in ambito server che desktop... e se gli basta per server, a maggior ragione per desktop sarebbe... sovradimensionato... sempre relativamente.

dipende sempre da cosa "ci gira" la necessità di banda è ben diversa a seconda delle operazioni che la cpu deve fare.

[greeneye]

The first outward signs of problems were in the Q2 AMD conference call last July. If you recall, Dirk Meyer punted on when Llano would be out, and most people took that as a really bad sign. It was, but only for a very short period of time. The reason for it was simple, at that point in time, AMD really didn't know for sure what was going on.

...

Sources tell us, and AMD denies, that the first batch of chips out of the fab had a yield of precisely zero.

Luckily, things got much better very quickly. Sources tell SemiAccurate that the next batch of chips came back days after the CC, and yield was infinitely better. By infinitely, we mean that in the mathematical sense, not that yields were production ready, they were not, but progress was steady.

Checking in with some people wandering the halls of a certain town north of Bannewitz showed that progress was moving forward, and things were tracking well for the Q2 release. Some tool monkeys said that things may be pulled in a few weeks, but still Q2. Optimism was the key word.

As things stand today, there are a lot of people dancing in bunny suits, then going to the local beer hall and getting blitzed. Bad pun. It would not surprise me at all to hear that Llano was pulled in a great deal soon, and late Q2 becomes early Q2, maybe even sooner.

c

[Fabiano 82]

da HardwareUpgrade
...Troveremo frequenze di clock che potrebbero raggiungere e superare i 3,5 GHz di massimo, ottenute grazie alla tecnologia produttiva a 32 nanometri high-k metalgate con tensione di alimentazione variabile da 0,8V a 1,3V di massimo. Per ogni modulo Bulldozer, all'interno del quale è presente una coppia di unità di calcolo integer, la superficie complessiva sarà pari a 30,9 millimetri quadrati comprensiva della cache L2 da 2 Mbytes.

La cache di terzo livello da 8 Mbytes sarà composta da 4 moduli da 2 Mbytes ciascuno, completamente indipendenti tra di loro, con una frequenza di clock superiore a 2,4 GHz con tensione di alimentazione di 1.1V. La cache L3 integrerà varie ottimizzazioni legate a migliorare l'efficienza complessiva oltre a diminuire il consumo complessivo...

http://www.hwupgrade.it/news/cpu/nuo...zer_34531.html

[capitan_crasy]

Originariamente inviato da Fabiano 82

da HardwareUpgrade
...Troveremo frequenze di clock che potrebbero raggiungere e superare i 3,5 GHz di massimo, ottenute grazie alla tecnologia produttiva a 32 nanometri high-k metalgate con tensione di alimentazione variabile da 0,8V a 1,3V di massimo. Per ogni modulo Bulldozer, all'interno del quale è presente una coppia di unità di calcolo integer, la superficie complessiva sarà pari a 30,9 millimetri quadrati comprensiva della cache L2 da 2 Mbytes.

La cache di terzo livello da 8 Mbytes sarà composta da 4 moduli da 2 Mbytes ciascuno, completamente indipendenti tra di loro, con una frequenza di clock superiore a 2,4 GHz con tensione di alimentazione di 1.1V. La cache L3 integrerà varie ottimizzazioni legate a migliorare l'efficienza complessiva oltre a diminuire il consumo complessivo...

http://www.hwupgrade.it/news/cpu/nuo...zer_34531.html

Clicca qui...

[Fabiano 82]

scusate, sono arrivato un pò tardi...

[Capozz]

Originariamente inviato da bjt2

La banda RAM non basta mai. Esisteranno sempre applicazioni per cui il quadchannel da qualche vantaggio. Per esempio applicazioni di calcolo matriciale, dove i calcoli sono delle banali addizioni e moltiplicazioni... Li se usi tutti e 8 core (come fa Matlab) si è RAM bound...

In ambito desktop è perfettamente inutile anche il triple channel, figuriamoci il quad...
Ovviamente la musica cambia se parliamo di server e workstation, ma suppongo che per gli opteron abbiano trovato soluzioni adeguate.

[idkfa]

Originariamente inviato da Capozz

In ambito desktop è perfettamente inutile anche il triple channel, figuriamoci il quad...
Ovviamente la musica cambia se parliamo di server e workstation, ma suppongo che per gli opteron abbiano trovato soluzioni adeguate.

Se non ricordo male i tri sovrasta il dual per un enorme 3% in più di prestazioni.


Quindi con questa gran differenza conviene prendere il triple channel

[dany700]

una curiosità...

mentre BD è sviluppato mantenendo un certo equilibrio in ampiezza tra cache L2 e L3...SB avrà una strutturazione fuori dalle righe: L3 ampia sarà pure necessaria per velocizzare le operazioni sui dati in attesa...ma le operazioni "raffinate" si eseguono in L2. La L2 in SB è 1/4 rispetto a quella di BD a livello di singolo core...senza contare l'ulteriore elasticità che un modulo BD vanta nel complesso con i 2 interi.

Non vorrei dire castronerie...ma credo che la logica computazionale di BD sarà notevolmente superiore in termini di calcolo puro a valle delle operazioni...ma non tanto per la capacità elaborativa...ma per il fluire dei risultati finali in una certa unità di tempo, in particolare se di una certa complessità.

Migliorare l'ampiezza della L3 ha un senso...ma ne avrebbe maggiormente se fosse bilanciata da una corretta L2...o sbaglio?

[paolo.oliva2]

Originariamente inviato da idkfa

Se non ricordo male i tri sovrasta il dual per un enorme 3% in più di prestazioni.

Quindi con questa gran differenza conviene prendere il triple channel

Dipende cosa intendi, se per bench di banda o per differenza IPC del procio.

Ti faccio un esempio:
Se io setto le DDR3 su un Thuban double-channel a 800MHz e faccio i test di banda, ottengo un risultato chiaramente più basso (e non di poco) che applicando 2GHz per le stesse memorie. Lo stesso credo che si abbia tra fare un Bench di banda tra un double-channel e three-channel su un i7.

Il problema è che quando invece faccio un bench sulle prestazioni del procio, IPC, le cose non cambiano nella stessa misura.

Poi, ad esempio, non si può fare questa distinzione come linea di massima. Ad occhio, ad esempio, un double-channel con DDR3 a 2GHz penso equivalga ad un three-channel con DDR3 a 1333MHz, il che soddisferebbe la "voracità" del procio con entrambe le soluzioni. Però, fare un three-channel con DDR3 2GHz avresti si più banda, ma se al procio la condizione precedente già soddisferebbe, avere lo 0,01% in più cosa direbbe?

Insomma, non è che sto dicendo che avere una banda superiore faccia certamente male (Bjt2 e Cionci non hanno certamente torto), ma bisogna vedere nelle applicazioni reali cosa si guadagna effettivamente, cioè se per quello che spendi di più hai un ritorno in prestazioni.
Infatti, se noti, i più acquistano gli i7 8XX al posto degli i9XX perché appunto la differenza di prezzo non vale assolutamente la candela, e chi acquista gli i9XX, il più delle volte, se non per differenze esigue di costo, va più sul double-channel che sul three-channel.

[paolo.oliva2]

Originariamente inviato da dany700

una curiosità...

mentre BD è sviluppato mantenendo un certo equilibrio in ampiezza tra cache L2 e L3...SB avrà una strutturazione fuori dalle righe: L3 ampia sarà pure necessaria per velocizzare le operazioni sui dati in attesa...ma le operazioni "raffinate" si eseguono in L2. La L2 in SB è 1/4 rispetto a quella di BD a livello di singolo core...senza contare l'ulteriore elasticità che un modulo BD vanta nel complesso con i 2 interi.

Non vorrei dire castronerie...ma credo che la logica computazionale di BD sarà notevolmente superiore in termini di calcolo puro a valle delle operazioni...ma non tanto per la capacità elaborativa...ma per il fluire dei risultati finali in una certa unità di tempo, in particolare se di una certa complessità.

Migliorare l'ampiezza della L3 ha un senso...ma ne avrebbe maggiormente se fosse bilanciata da una corretta L2...o sbaglio?

Non sono certo super-competente, ma probabilmente l'architettura della L2-L3 di SB e di BD è in dipendenza dell'architettura dei proci e come bilanciamento di pregi-difetti degli stessi.

Mi sembra di ricordare che gli i7 nella L1 e L2 sono comunque più veloci (e mi sembra non di poco) rispetto al Phenom II. Quindi una L1 e L2 "ridotte" rispetto al Phenom II probabilmente lo è perché più grosse... non servirebbero o comunque alzerebbero il costo del procio senza una controparte di guadagno adeguata.

Comunque ricordo che un "tecnico" AMD aveva riportato che nel Phenom II avere una L2 da 1MB a core senza L3, si ottenevano circa le stesse prestazioni del sistema L2 a 512KB + L3.
BD secondo me è una via di mezzo perché ha una L2 "grossa" perché comunque è condivisa tra 2 core... (e comunque rappresenterebbe una L2 da ben 2MB per 1 core nel caso di 1 TH in esecuzione, e ciò certamente vorrà dire), conservando comunque una L3 di 8MB che comunque non sarebbe "striminzita".

[paolo.oliva2]

Volevo portare ad una riflessione su un punto, che per me è importante per comprendere il TDP/clock del 32nm HKMG AMD.

Porto questo paragone:
il 45nm SOI low-k ha queste caratteristiche, almeno per un 1090T:
1,30-1,35V (circa), per contenere il TDP dentro i 125W come X6.
1,475V, in Turbo-mode, per contenere la differenza dentro i 125W sempre, con 3 core che "lavorano" a +400MHz sopra la frequenza def.

Però, occhio, il Thuban non è selettivo con il Vcore, quindi ci troveremmo tutti e 6 i core che lavorano a 1,475V, di cui solo 3 a +400MHz, ma SEMPRE rimanendo dentro i 125W TDP.

Quello che voglio dire, è che anche considerando che il Turbo non applichi i +400MHz per 3 core, un procio dato a 125W TDP a 1,35V resterebbe sempre dentro i 125W TDP pur con un Vcore 1,475V, cioè di ben 0,125V più alto.

Con le classiche formule matematiche (che non ricordo ), se le applicassimo, il TDP certamente schizzerebbe e non di poco.

Premetto... io faccio questa riflessione ad intuito e poi, chi competente, valuterà o meno.

Se trasportiamo questa ottica riferendo il tutto come prerogativa caratteristica silicio SOI, a maggior ragione il 32nm SOI HKMG, avendo un range di tensione inferiore, l'aumento di TDP in base al Vcore dovrebbe essere ancora inferiore, con un guadagno più marcato in frequenza.

Il 32nm SOI avendo un range da 0,8V a 1,3V di massimo, che poi 1,3V certamente non sarà quello massimo applicabile prima che tutto fonda (il 45nm E0 avrebbe un massimo di 1,55V, oltre si può andare ma raffreddandolo a dovere), dovrebbe avere un aumento di frequenza maggiore del 45nm a parità di aumento di tensione.
Come dire... il 45nm con +0,05V aumenta di 200MHz? Il 32nm HKMG con lo stesso aumento di Vcore potrebbe dare +400MHz.
Di qui, se nella selezione AMD applicherebbe 95W ad esempio ad un X8 che "lavorerebbe" a 1,1V (esempio), magari il procio con un silicio "migliore", potrebbe ad esempio, sempre a 1,1V, essere 4GHz. Un po' come un 1055T a 1,3V è 125W TDP a 2,8GHz, ed un 1090T, sempre a 1,3V 3,2GHz allo stesso TDP.

[Ren]

Originariamente inviato da paolo.oliva2

Esatto, però forse ti sfugge questo:
gli MCM AMD per server hanno 12/16 core e sono formati rispettivamente da 2 BD X6 o X8, con ognuno un dual channel, ed il quad channel è la somma dei 2 MC dei 2 proci.
Ma questo di per sè cosa evidenzia? Che un BD X8 ha sempre un dual Channel e che gli "basta" nel suo impiego sia server che desktop, e non ci sarebbe alcuna differenza di performances a livello di die singolo.
Tra le versioni EX e gli stessi proci versione desktop, invece a me sembra che cambi radicalmente la cosa, aggiungendo anche L3 più piccole. Forse è stato fatto per ridurre i costi, probabilmente, ma sicuramente diminueranno pure le prestazioni... perché se non vi fosse alcuna differenza, non avrebbe senso... la differenza.

Non mi sfugge niente semmai il contrario.

Avere due chip nello stesso package presuppone che il singolo die sia dotato di più linee HT per il collegamento(+transistor), che per forza di cose sarà inferiore ad uno interno.

L'approccio di Amd è ottimo perchè riduce i design necessari, ottimizzando i costi anche in fatto di rese(die più piccolo).


La cache di solito si fa sentire di più in ambito server/workstation che in quello desktop, quindi mi sembra sensato aumentare la dotazione ed i costi solo dove se ne trae maggior beneficio.

[dany700]

Originariamente inviato da paolo.oliva2

Non sono certo super-competente, ma probabilmente l'architettura della L2-L3 di SB e di BD è in dipendenza dell'architettura dei proci e come bilanciamento di pregi-difetti degli stessi.

Mi sembra di ricordare che gli i7 nella L1 e L2 sono comunque più veloci (e mi sembra non di poco) rispetto al Phenom II. Quindi una L1 e L2 "ridotte" rispetto al Phenom II probabilmente lo è perché più grosse... non servirebbero o comunque alzerebbero il costo del procio senza una controparte di guadagno adeguata.

Comunque ricordo che un "tecnico" AMD aveva riportato che nel Phenom II avere una L2 da 1MB a core senza L3, si ottenevano circa le stesse prestazioni del sistema L2 a 512KB + L3.
BD secondo me è una via di mezzo perché ha una L2 "grossa" perché comunque è condivisa tra 2 core... (e comunque rappresenterebbe una L2 da ben 2MB per 1 core nel caso di 1 TH in esecuzione, e ciò certamente vorrà dire), conservando comunque una L3 di 8MB che comunque non sarebbe "striminzita".

appunto

quando i capoccia AMD hanno dichiarato un enorme crescita a livello del MC...non credo si riferissero semplicemente ad un throughput del 50%.

Non conosciamo le latenze...ma per quanto siano buone quelle di SB...non riusciranno mai a competere con la L2 di BD ben 4 volte più ampia. (pur ipotizzando che in BD vi sia una scarsa latenza).

l'architettura di SB così come la conosciamo ora salvo bench accurati...
IMHO...mi pare organizzata per immaganizzare una certa quantità di dati agglomerati "semplici" in L3...a causa della limitata L2. Questo non significa che si avranno colli di bottiglia a valle...ma sicuramente rappresentano un enorme inefficienza a livello temporale...a causa delle continue chiamate tra L2 e L3 in MT ma soprattutto in ST, rispetto a BD.

Per carità...io sono un niubbo...per cui, ciò che mi pare evidente, potrebbe non esserlo

[Pihippo]

Originariamente inviato da dany700

una curiosità...

mentre BD è sviluppato mantenendo un certo equilibrio in ampiezza tra cache L2 e L3...SB avrà una strutturazione fuori dalle righe: L3 ampia sarà pure necessaria per velocizzare le operazioni sui dati in attesa...ma le operazioni "raffinate" si eseguono in L2. La L2 in SB è 1/4 rispetto a quella di BD a livello di singolo core...senza contare l'ulteriore elasticità che un modulo BD vanta nel complesso con i 2 interi.

Non vorrei dire castronerie...ma credo che la logica computazionale di BD sarà notevolmente superiore in termini di calcolo puro a valle delle operazioni...ma non tanto per la capacità elaborativa...ma per il fluire dei risultati finali in una certa unità di tempo, in particolare se di una certa complessità.

Migliorare l'ampiezza della L3 ha un senso...ma ne avrebbe maggiormente se fosse bilanciata da una corretta L2...o sbaglio?

Ciao
Bd è molto throughput oriented come hai ben potuto notare.
Le dimensioni della L3 di sb sono aumentate per coprire la piccola dimensione della L2. Quello che realmente conta comunque oltre alla dimensioni, è la load to use latency, ovvero trovato ciò che mi serve quanto impiego per portarlo alle execution unit, e nel caso di un accesso alla L2 in sb si parla di circa 10 cicli, molto ben mascherabili dall'hardware. Mascherabili nel senso che in quei 10 cicli hai qualcos'altro da fare nel frattempo che ti arrivi l'operando contenuto nella L2.

Originariamente inviato da Ren

Cut

La cache di solito si fa sentire di più in ambito server/workstation cut
.

Ciao
Mi permetto di dire una cosa, in ambiente server, sopratutto se multithreaded (come il 98% delle applicazioni server) la dimensione ha un impatto minore rispetto ad un ambiente dekstop, in quanto essendoci al max 2 thread che devono compiere una marea di cose (caso giochino thread rendering + thread misto I\O fisica ai audio e corbellerie varie) tendono a tassare di più una L2 di tipo privato per core (come quella dei k10 e dei nehalem)
Ad esempio vedi le ottime prestazioni che hanno tuttora i c2q nei giochini non fortemente multithreaded, questo grazie alla loro enorme L2 condivisa

[dany700]

Originariamente inviato da paolo.oliva2

Volevo portare ad una riflessione su un punto, che per me è importante per comprendere il TDP/clock del 32nm HKMG AMD.

Porto questo paragone:
il 45nm SOI low-k ha queste caratteristiche, almeno per un 1090T:
1,30-1,35V (circa), per contenere il TDP dentro i 125W come X6.
1,475V, in Turbo-mode, per contenere la differenza dentro i 125W sempre, con 3 core che "lavorano" a +400MHz sopra la frequenza def.

Però, occhio, il Thuban non è selettivo con il Vcore, quindi ci troveremmo tutti e 6 i core che lavorano a 1,475V, di cui solo 3 a +400MHz, ma SEMPRE rimanendo dentro i 125W TDP.

Quello che voglio dire, è che anche considerando che il Turbo non applichi i +400MHz per 3 core, un procio dato a 125W TDP a 1,35V resterebbe sempre dentro i 125W TDP pur con un Vcore 1,475V, cioè di ben 0,125V più alto.

Con le classiche formule matematiche (che non ricordo ), se le applicassimo, il TDP certamente schizzerebbe e non di poco.

Premetto... io faccio questa riflessione ad intuito e poi, chi competente, valuterà o meno.

Se trasportiamo questa ottica riferendo il tutto come prerogativa caratteristica silicio SOI, a maggior ragione il 32nm SOI HKMG, avendo un range di tensione inferiore, l'aumento di TDP in base al Vcore dovrebbe essere ancora inferiore, con un guadagno più marcato in frequenza.

Il 32nm SOI avendo un range da 0,8V a 1,3V di massimo, che poi 1,3V certamente non sarà quello massimo applicabile prima che tutto fonda (il 45nm E0 avrebbe un massimo di 1,55V, oltre si può andare ma raffreddandolo a dovere), dovrebbe avere un aumento di frequenza maggiore del 45nm a parità di aumento di tensione.
Come dire... il 45nm con +0,05V aumenta di 200MHz? Il 32nm HKMG con lo stesso aumento di Vcore potrebbe dare +400MHz.
Di qui, se nella selezione AMD applicherebbe 95W ad esempio ad un X8 che "lavorerebbe" a 1,1V (esempio), magari il procio con un silicio "migliore", potrebbe ad esempio, sempre a 1,1V, essere 4GHz. Un po' come un 1055T a 1,3V è 125W TDP a 2,8GHz, ed un 1090T, sempre a 1,3V 3,2GHz allo stesso TDP.

Così a naso...qualcosa non mi quadra.

Se fosse realmente come hai prospettato...stabilendo che a 3,5Ghz abbiamo un Vcore di 0,8...portandolo a 1,3...dovremmo raggiungere la velocità della luce già a stock...e per l'aggiunta...pure su un x8

Essendo il 32nm "nuovo" per AMD...penso che gli incrementi di vcore diano un risultato meno che proporzionale in frequenza. da qui 1,3V che potrebbero servire per superare agevolmente i 4Ghz a stock.

Con un silicio e step migliori...si avrebbero i medesimi risultati...ma con un range proporzionalmente inferiore tipo 0,6-1V...nel qual caso, naturalmente con 1,3V si supererebbero agevolmente i 5Ghz con adeguato raffreddamento.

Lietissimo di essere contraddetto in tutto e per tutto

[Ares17]

Originariamente inviato da dany700

Così a naso...qualcosa non mi quadra.

Se fosse realmente come hai prospettato...stabilendo che a 3,5Ghz abbiamo un Vcore di 0,8...portandolo a 1,3...dovremmo raggiungere la velocità della luce già a stock...e per l'aggiunta...pure su un x8

Essendo il 32nm "nuovo" per AMD...penso che gli incrementi di vcore diano un risultato meno che proporzionale in frequenza. da qui 1,3V che potrebbero servire per superare agevolmente i 4Ghz a stock.

Con un silicio e step migliori...si avrebbero i medesimi risultati...ma con un range proporzionalmente inferiore tipo 0,6-1V...nel qual caso, naturalmente con 1,3V si supererebbero agevolmente i 5Ghz con adeguato raffreddamento.

Lietissimo di essere contraddetto in tutto e per tutto

0,8 volt di vcore dovrebbe essere il voltaggio in idle della cpu (frequenza bassa grazie al c&q e molte parti della cpu spente.
Bisogna vedere se 1,3v è il voltaggio senza turbo attivo o quello con il turbo (che potrebbe anche coincidere anche se ci credo poco)

[Ren]

Originariamente inviato da Pihippo

Ciao
Mi permetto di dire una cosa, in ambiente server, sopratutto se multithreaded (come il 98% delle applicazioni server) la dimensione ha un impatto minore rispetto ad un ambiente dekstop, in quanto essendoci al max 2 thread che devono compiere una marea di cose (caso giochino thread rendering + thread misto I\O fisica ai audio e corbellerie varie) tendono a tassare di più una L2 di tipo privato per core (come quella dei k10 e dei nehalem)
Ad esempio vedi le ottime prestazioni che hanno tuttora i c2q nei giochini non fortemente multithreaded, questo grazie alla loro enorme L2 condivisa

Ciao,
Non mi sembra proprio che le performance (nei giochini) single thread di westmere siano migliori di quelle del nahalem, sebbene abbia più cache L3 (8vs12).

[dany700]

Originariamente inviato da Pihippo

Ciao
Bd è molto throughput oriented come hai ben potuto notare.
Le dimensioni della L3 di sb sono aumentate per coprire la piccola dimensione della L2. Quello che realmente conta comunque oltre alla dimensioni, è la load to use latency, ovvero trovato ciò che mi serve quanto impiego per portarlo alle execution unit, e nel caso di un accesso alla L2 in sb si parla di circa 10 cicli, molto ben mascherabili dall'hardware. Mascherabili nel senso che in quei 10 cicli hai qualcos'altro da fare nel frattempo che ti arrivi l'operando contenuto nella L2.

grazie della spiegazione

rimane solo da vedere nella realtà delle apllicazioni...come si tradurrano entrambe le architetture...vista la loro estrema etereogeneità.

infatti se SB ha una L2 a 10 cicli con un'ampiezza di 256Kb oltre a godere di un IPC superiore a BD (così si legge in giro...15-20%??)...resta da capire quanto potrà rispondere a BD con una L2 da 1MB...che a prescindere dai cicli, potrebbe colmare agevolmente il gap in termini di un eventuale minore IPC in termini di calcolo puro.

Così a spanne...non credo si possano confrontare facilmente a livello di ST o moderati MT...la differenza di L2 è enorme e a vantaggio di BD, benchè sia ancora tutto sulla carta.

in MT complessi...invece...fare delle congetture accurate in mancanza di test che dimostrino efficienze architetturali empiriche di una o dell'altra...non credo sia ancora possibile.

mi riferisco ai proci in senso assoluto a parità di core, oppure a coppie di core contro un modulo e così via...e non certo considerando il rapporto performance/prezzo...naturalmente.