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

[cionci]

Originariamente inviato da paolo.oliva2

Ora... se nei server proprio per la loro tipologia la banda ha un'importanza fondamentale, l'aumento della frequenza ram per i BD desktop mi sembra a maggior ragione il motivo sia quello di frequenze def/turbo ben superiori.

E' normale che i desktop supportino frequenze superiori per le ram, per un semplice motivo: le ram per i server sono ECC. Lo sviluppo delle memorie ECC prosegue sempre più lento rispetto a quelle desktop.
Meglio non cercare motivazioni dove non ci sono.

[capitan_crasy]

Originariamente inviato da Caterpillar86

Raga visto che Buldozer ritarderà ancora più del previsto, pensate che AMD faccia uscire qualche Phenom II X6 con più cache del 1100T?

E' da più di un anno che BD è atteso per il secondo trimestre 2011 ed è ancora così...
Per quanto riguarda Thuban non ci saranno ulteriori aggiornamenti all'architettura K10 sui 45nm, ne tanto meno aumenti di cache...

[Caterpillar86]

Originariamente inviato da capitan_crasy

E' da più di un anno che BD è atteso per il secondo trimestre 2011 ed è ancora così...
Per quanto riguarda Thuban non ci saranno ulteriori aggiornamenti all'architettura K10 sui 45nm, ne tanto meno aumenti di cache...

Quindi il 1100 sarà il miglior pezzo per socket AM3.
Allora bisogna solo aspettare che scenda di prezzo

[digieffe]

vero o fake?

http://www.xtremesystems.org/forums/...1&postcount=67

qualcuno riesce ad interpretare ?

edit:riporto il post

Originariamente inviato da JF-AMD

OK, daddy is going to do some math, everyone follow along please.

First: There is only ONE performance number that has been legally cleared, 16-core Interlagos will give 50% more throughput than 12-core Opteron 6100. This is a statement about throughput and about server workloads only. You CANNOT make any client performance assumptions about that statement.

Now, let's get started.

First, everything that I am about to say below is about THROUGHPUT and throughput is different than speed. If you do not understand that, then please stop reading here.

Second, ALL comparisons are against the same cores, these are not comparison different generations nor are they comparisons against different architectures.

Assume that a processor core has 100% throughput.

Adding a second core to an architecture is typically going to give ~95% greater throughput. There is obviously some overhead because the threads will stall, the threads will wait for each other and the threads may share data. So, two completely independent cores would equal 195% (100% for the first core, 95% for the second core.)


Looking at SPEC int and SPEC FP, Hyperthreading gives you 14% greater throughput for integer and 22% greater throughput for FP. Let's just average the two together.

One core is 100%. Two cores are 118%. Everyone following so far? We have 195% for 2 threads on 2 cores and we have 118% for 2 threads on 1 core.

Now, one bulldozer core is 100%. Running 2 threads on 2 seperate modules would lead to ~195%, it's consistent with running on two independent cores.

Running 2 threads on the same module is ~180%.

You can see why the strategy is more appealing than HT when it comes to threaded workloads. And, yes, the world is becoming more threaded.

Now, where does the 90% come from? What is 180% /2? 90%.

People have argued that there is a 10% overhead for sharing because you are not getting 200%. But, as we saw before, 2 cores actually only equals 195%, so the net per core if you divide the workload is actually 97.5%, so it is roughly a 7-8% delta from just having cores.

Now, before anyone starts complaining about this overhead and saying that AMD is compromising single thread performance (because the fanboys will), keep in mind that a processor with HT equals ~118% for 2 threads, so per thread that equals 59%, so there is a ~36% hit for HT. This is specifically why I think that people need to stay away from talking about it. If you want to pick on AMD for the 7-8%, you have to acknowledge the ~36% hit from HT. But ultimately that is not how people jusdge these things. Having 5 people in a car consumes more gas than driving alone, but nobody talks about the increase in gas consumption because it is so much less than 5 individual cars driving to the same place.

So, now you know the approximate metrics about how the numbers work out. But what does that mean to a processor? Well, let's do some rough math to show where the architecture shines.

An Orochi die has 8 cores. Let's say, for sake of argument, that if we blew up the design and said not modules, only independent cores, we'd end up with about 6 cores.

Now let's compare the two with the assumption that all of the cores are independent on one and in modules on the other. For sake of argument we will assume that all cores scale identically and that all modules scale identically. The fact that incremental cores scale to something less than 100% is already comprehended in the 180% number, so don't fixate on that. In reality the 3rd core would not be at 95% but we are holding that constant for example.

Mythical 6-core bulldozer:
100% + 95% + 95% + 95% + 95% + 95% = 575%

Orochi die with 4 modules:
180% + 180% + 180% + 180% = 720%

What if we had just done a 4 core and added HT (keeping in the same die space):
100% + 95% +95% +95% + 18% + 18% + 18% + 18% = 457%

What about a 6 core with HT (has to assume more die space):
100% + 95% +95% +95% +95% +95% + 18% + 18% + 18% + 18% + 18% + 18% = 683%

(Spoiler alert - this is a comparison using the same cores, do NOT start saying that there is a 25% performance gain over a 6-core Thuban, which I am sure someone is already starting to type.)

The reality is that by making the architecture modular and by sharing some resources you are able to squeeze more throughput out of the design than if you tried to use independent cores or tried to use HT. In the last example I did not take into consideration that the HT circuitry would have delivered an extra 5% circuitry overhead....

Every design has some degree of tradeoff involved, there is no free lunch. The goal behind BD was to increase core count and get more throughput. Because cores scale better than HT, it's the most predictable way to get there.

When you do the math on die space vs. throughput, you find that adding more cores is the best way to get to higher throughput. Taking a small hit on overall performance but having the extra space for additional cores is a much better tradeoff in my mind.

Nothing I have provided above would allow anyone to make a performance estimate of BD vs. either our current architecture or our compeition, so, everyone please use this as a learning experience and do not try to make a performance estimate, OK?
__________________
While I work for AMD, my posts are my own opinions.

http://blogs.amd.com/work/author/jfruehe/

[cionci]

Originariamente inviato da digieffe

vero o fake?

Tutto vero, roba che si sapeva più o meno esplicitamente. Comunque non c'è alcun confronto fra Intel e AMD, si riferisce a CPU con la stessa architettura e alle motivazioni della scelta dell'uso dei due core per modulo invece di un HT.

[digieffe]

http://blogs.amd.com/work/2011/02/21...ign-solutions/

EDIT 1: "Handling up to four 64-bit instructions per thread" cosa vorrebbe significare?


http://blogs.amd.com/work/2011/02/21...hats-in-a-box/

EDIT 2: The execution units must compute results in a single cycle and forward them to dependent operations in the following cycle. All of this is required so that the module gives high architectural performance, measured in the number of instructions completed per cycle (IPC).

[george_p]

JF sottolinea che questo è solo UNO dei fattori di performance che sta descrivendo.
Da ciò che accenna in seguito, il punto di forza dell'architettura BD sarà la possibilità di inserire molti moduli a parità di area die, e presumo che all'aumentare dei moduli ci sia pure una evidente scalabilità nelle prestazioni verso l'alto.

Questo pare il succo del discorso BD.

[Pihippo]

Originariamente inviato da digieffe

http://blogs.amd.com/work/2011/02/21...ign-solutions/

EDIT 1: "Handling up to four 64-bit instructions per thread" cosa vorrebbe significare?


http://blogs.amd.com/work/2011/02/21...hats-in-a-box/

EDIT 2: The execution units must compute results in a single cycle and forward them to dependent operations in the following cycle. All of this is required so that the module gives high architectural performance, measured in the number of instructions completed per cycle (IPC).

Ciao
In due parole? IPC più alto dei phenom II.
Quel 64bit instruction lascia presagire che le aglu facciano qualcos'altro oltre che computare indirizzi di memoria, oppure 4 istruzioni intese come 2 op di memoria +2 di logica\aritimetica.
Il secondo punto indica uno scheduler più avanzato di quello dei k10.

[bjt2]

Originariamente inviato da Pihippo

Ciao
In due parole? IPC più alto dei phenom II.
Quel 64bit instruction lascia presagire che le aglu facciano qualcos'altro oltre che computare indirizzi di memoria, oppure 4 istruzioni intese come 2 op di memoria +2 di logica\aritimetica.
Il secondo punto indica uno scheduler più avanzato di quello dei k10.

Non è detto che siano 4 istruzioni intere computazionali. ne sapremo di più a breve quando sul blog AMD dovrebbe essere postato un sunto dei talk sui paper...
Anche per il secondo punto: dovrebbe essere così anche per tutti gli scheduler di CPU moderne, ossia che il risultato di una operazione è disponibile il ciclo di clock successivo (è anche il meglio che si può fisicamente fare). La novità è che dice che tutte le istruzioni intere (penso escluse MUL e DIV) vengono eseguite in un solo ciclo di clock e l'altra novità è che tutto è stato fatto con logica standard, senza trucchetti e circuiti particolari. Se si guardano alcune slide, poi, sul blog AMD, si nota che le 4 pipelines sono denomitate EX,MUL ; EX,DIV ; AGen ; AGen . Questo cosa vuol dire? Che una pipeline può fare tutte le istruzione intere o una MUL, un'altra tutte le istruzione intere o una DIV e le altre due sono AG(L?)U... Il bello è che con il nuovo scheduler a coda unica, anche se DIV e MUL fossero bloccanti (ossia fermano tutte le istruzioni in quella pipeline), le altre istruzioni possono usare l'altra pipeline. Invece nel K10 se una pipeline era bloccata, rimanevano bloccate anche le altre istruzioni in coda. Nel K10 la DIV era microcodificata, così era spezzata in tante microistruzioni che ingolfavano le code. In LLano è stata creata una unità pipelined. Si spera che non sia bloccante, ma che richieda uno slot nella pipeline solo in fase di caricamento dati e scaricamento risultati, altrimenti una DIV a 64 bit che impiega anche 70 cicli, lascerebbe bloccata tutta una pipeline! Ricordiamo che in Llano c'è ancora il problema delle code separate. Ma già il fatto di liberare le code dalla pletora di microistruzioni necessarie per la divisione (che fa anche abbassare le istruzioni decodificate perchè è vector path) da un vantaggio in codice con molte divisioni intere... Se poi la DIV è anche non bloccate... Si spera che lo sia in Llano, pechè in BD il danno sarebbe minore, ma ovviamente speriamo che non sia bloccante anche in BD! Forse lo sapremo domani...

[Pihippo]

Originariamente inviato da bjt2

Non è detto che siano 4 istruzioni intere computazionali. ne sapremo di più a breve quando sul blog AMD dovrebbe essere postato un sunto dei talk sui paper...
Anche per il secondo punto: dovrebbe essere così anche per tutti gli scheduler di CPU moderne, ossia che il risultato di una operazione è disponibile il ciclo di clock successivo (è anche il meglio che si può fisicamente fare). La novità è che dice che tutte le istruzioni intere (penso escluse MUL e DIV) vengono eseguite in un solo ciclo di clock e l'altra novità è che tutto è stato fatto con logica standard, senza trucchetti e circuiti particolari. Se si guardano alcune slide, poi, sul blog AMD, si nota che le 4 pipelines sono denomitate EX,MUL ; EX,DIV ; AGen ; AGen . Questo cosa vuol dire? Che una pipeline può fare tutte le istruzione intere o una MUL, un'altra tutte le istruzione intere o una DIV e le altre due sono AG(L?)U... Il bello è che con il nuovo scheduler a coda unica, anche se DIV e MUL fossero bloccanti (ossia fermano tutte le istruzioni in quella pipeline), le altre istruzioni possono usare l'altra pipeline. Invece nel K10 se una pipeline era bloccata, rimanevano bloccate anche le altre istruzioni in coda. Nel K10 la DIV era microcodificata, così era spezzata in tante microistruzioni che ingolfavano le code. In LLano è stata creata una unità pipelined. Si spera che non sia bloccante, ma che richieda uno slot nella pipeline solo in fase di caricamento dati e scaricamento risultati, altrimenti una DIV a 64 bit che impiega anche 70 cicli, lascerebbe bloccata tutta una pipeline! Ricordiamo che in Llano c'è ancora il problema delle code separate. Ma già il fatto di liberare le code dalla pletora di microistruzioni necessarie per la divisione (che fa anche abbassare le istruzioni decodificate perchè è vector path) da un vantaggio in codice con molte divisioni intere... Se poi la DIV è anche non bloccate... Si spera che lo sia in Llano, pechè in BD il danno sarebbe minore, ma ovviamente speriamo che non sia bloccante anche in BD! Forse lo sapremo domani...

Ciao Bjt2
Pure io penso che non debbano essere per forza 4 op di logica\aritmetica.
Per il secondo punto. Penso che si parli solo di op che hanno già gli operandi caricati o di op r-->r altrimenti vorrebbe dire che bd ha load to use latency pari a 1 ciclo. Il che sarebbe impressionante.

[paolo.oliva2]

http://blogs.amd.com/work/2011/02/22...gy-efficiency/

The Bulldozer core implements numerous improvements that target super-efficient computation in all aspects of the design. These features build on and extend the foundational innovations that were discussed as part of the “Llano” disclosures made a year ago and covered in a prior blog.

* Fully power gating the core to essentially zero power when not in use (questo si sapeva)

* Sharing components in the dual core design (instruction fetch, decode, L2 cache, FP) to make more efficient use of them while still delivering the performance of a true dual core. This is sort of like the efficiency of a duplex home design where heat, plumbing, foundation and electrical infrastructure can all be shared, but the structure still provides independent homes for two families.

* Optimizing the low level circuits for maximal efficiency at all levels. For instance low-power flip-flop design shown in paper 4.5 yesterday at ISSCC provides innovative power reductions for one of the biggest power consuming circuits in the core. The clock grid (another big power sink) builds on the power efficiencies of past designs, and adds more improvements. Perhaps most importantly, the grounds-up design opportunity enabled an unprecedented level of clock gating (see figure below from the paper) to reduce power waste as shown in the graph below. Retrofitting a design to add logic to turn clocks off when circuits aren’t used is a time consuming and error-prone process. The Bulldozer team designed these in from the beginning which enabled the inclusion of over 30,000 individual clock enables to be used.

And finally, a next generation AMD Turbo CORE technology implementation that provides maximum compute speed when required, and throttles back to maximum efficiency when appropriate. Bulldozer implements a significantly more aggressive version of this capability than “Llano” with more details to be disclosed in the future.

[luppif]

very news

[Snake156]

Originariamente inviato da cionci

Leggiti qui vai: http://www.hwupgrade.it/articoli/cpu...da-amd_13.html
Semplicemente il 1090T si è posizionato come concorrente del Core i7 860, non certo del modello superiore, dal quale veniva superato praticamente in ogni frangente.
Quindi visto che poteva vantare prestazioni un bel po' superiori del 860 (solo nel multithreading), ma non certo dell'870 o del 960, allora si è posizionato a parità di prezzo dell'860.

Per l'ennesima volta, il posizionamento sul mercato lo fanno le prestazioni, non certo la volontà di AMD di "regalare" ai propri clienti.

straverissimo
e a volte, i cali di prezzo sono dovuti proprio a questo...sbagliato posizionamento.

[paolo.oliva2]

Originariamente inviato da george_p

JF sottolinea che questo è solo UNO dei fattori di performance che sta descrivendo.
Da ciò che accenna in seguito, il punto di forza dell'architettura BD sarà la possibilità di inserire molti moduli a parità di area die, e presumo che all'aumentare dei moduli ci sia pure una evidente scalabilità nelle prestazioni verso l'alto.

Questo pare il succo del discorso BD.

Quindi... a parità di costi (riferito al 32nm, che dovrebbe costare di più di un 45nm a parità di area) più core e più potenza.
Il punto sarà l'intenzione di AMD, cioè massimizzare i guadagni rispetto alla potenza di BD, o aggredire il mercato offrendo prodotti con un prezzo/core diverso.
In poche parole, AMD certamente non arriverà a regale i proci, ma non è da escludere che possa richiedere un prezzo/prestazioni inferiore all'attuale. Comunque se un BD X8 fosse più potente dei proci sul mercato, il fatto che probabilmente possa essere proposto allo stesso prezzo o addirittura inferiore, è innegabile che di per sé rappresenti di fatto già una riduzione di prezzo a prestazione.

[bjt2]

Originariamente inviato da Pihippo

Ciao Bjt2
Pure io penso che non debbano essere per forza 4 op di logica\aritmetica.
Per il secondo punto. Penso che si parli solo di op che hanno già gli operandi caricati o di op r-->r altrimenti vorrebbe dire che bd ha load to use latency pari a 1 ciclo. Il che sarebbe impressionante.

Ovviamente... La cache L1 dovrebbe avere latenza di 3-4 cicli... Non sarebbe possibile...

[Pihippo]

Originariamente inviato da bjt2

Ovviamente... La cache L1 dovrebbe avere latenza di 3-4 cicli... Non sarebbe possibile...

Ciao
Infatti la L1 dovrebbe avere 3-4 cicli di latenza, e la L2 16-18. Chissa quanto sarebbero potuti salire con il clock (e die size) con una L1 cosi veloce, di sicuro meno di quanto si presume.

[bjt2]

Originariamente inviato da paolo.oliva2

http://blogs.amd.com/work/2011/02/22...gy-efficiency/

The Bulldozer core implements numerous improvements that target super-efficient computation in all aspects of the design. These features build on and extend the foundational innovations that were discussed as part of the “Llano” disclosures made a year ago and covered in a prior blog.

* Fully power gating the core to essentially zero power when not in use (questo si sapeva)

* Sharing components in the dual core design (instruction fetch, decode, L2 cache, FP) to make more efficient use of them while still delivering the performance of a true dual core. This is sort of like the efficiency of a duplex home design where heat, plumbing, foundation and electrical infrastructure can all be shared, but the structure still provides independent homes for two families.

* Optimizing the low level circuits for maximal efficiency at all levels. For instance low-power flip-flop design shown in paper 4.5 yesterday at ISSCC provides innovative power reductions for one of the biggest power consuming circuits in the core. The clock grid (another big power sink) builds on the power efficiencies of past designs, and adds more improvements. Perhaps most importantly, the grounds-up design opportunity enabled an unprecedented level of clock gating (see figure below from the paper) to reduce power waste as shown in the graph below. Retrofitting a design to add logic to turn clocks off when circuits aren’t used is a time consuming and error-prone process. The Bulldozer team designed these in from the beginning which enabled the inclusion of over 30,000 individual clock enables to be used.

And finally, a next generation AMD Turbo CORE technology implementation that provides maximum compute speed when required, and throttles back to maximum efficiency when appropriate. Bulldozer implements a significantly more aggressive version of this capability than “Llano” with more details to be disclosed in the future.

Ci sono varie cose... Già sappiamo che Llano è un notevole miglioramento del K10 dal punto di vista del consumo energetico (si parla del 25% in meno). Ma qui è detto che BD sarà anche meglio di Llano. E si fa vedere quel grafico con l'incidenza del clock sul TDP totale al massimo carico, medio carico e in IDLE. In ogni caso se ci facciamo i conti e supponendo che il core di riferimento sia il K10, vediamo che a medio carico e in IDLE siamo ben oltre il -25% anche se parliamo solo del clock. Poi è detto che con il core ridisegnato da zero si sono potuti spingere oltre Llano. Quindi a parità di transistors, clock e processo, avremmo più del 25% in meno di TDP. Inoltre il Turbo Core 2.0 è ancora migliore di quello di Llano... Insomma è un MOSTRO!

Anche fosse realizzato con il 45nm e con FO4 di 23 consumerebbe il 25-30% in meno e quindi potrebbe andare ALMENO un 15-20% in più di clock rispetto a un K10 con lo stesso numero di transistors. Poi però abbiamo il FO4 di 17 (un altro 10-15% MINIMO) e il processo a 32nm (un altro 40%) e abbiamo nel caso peggiore (ossia prendendo i minimi e sommando brutalmente le percentuali, anche se non si fa così) un +65% di clock. Ovviamente a stock. Poichè un BD X4 dovrebbe avere un numero di transistors leggermente inferiore a un Thuban, prendiamo un 1100T come riferimento. 3.3 Ghz+65%=5.45GHz. Quindi un ipotetico BD X4 a 125W (che non faranno MAI) potrebbe raggiungere i 5.5GHz a stock. Penso che a 95W i 4.5GHz e oltre sono molto probabili... Ora considerando l'IPC del BD superiore del 10% rispetto al Thuban/Deneb, abbiamo che un BD X4 4.5Ghz, anche non consiedrando il turbo andrebbe come un Deneb a 5GHz... Dovrebbe essere sufficiente a spazzare SB X4...
Per l'X8 possiamo supporre un TDP doppio a parità di frequenza (anche se è di meno perchè il MC e il NB sono gli stessi dell'X4). Quindi un BD X8 5.5GHz dissiperebbe 250W (e non è neanche un risultato ottimo visto che IBM in una potenza paragonabile e con processo a 45nm riesce a far andare il suo nuovo power 7 a 5.2 Ghz). Se ipotizziamo che il TDP va con il cubo della frequenza, allora possiamo calcolare la frequenza dell'X8, come 5.5GHz/radicecubica(2)=4.4GHz... Poniamoci con un adeguato coefficiente di sicurezza e possiamo ipotizzare un BD X8 4GHz stock a 125W... I 3.5GHz probabilmente sono per il 95W. E quei 3.8GHz sono un BD X8 125W di un ES che gioco forza non può essere come le CPU che usciranno tra 2 mesi, essendo stato prodotto probabilmente a novembre/dicembre...

[bjt2]

Originariamente inviato da Pihippo

Ciao
Infatti la L1 dovrebbe avere 3-4 cicli di latenza, e la L2 16-18. Chissa quanto sarebbero potuti salire con il clock (e die size) con una L1 cosi veloce, di sicuro meno di quanto si presume.

Secondo alcune cose che ho letto, si parla di L1 a 4 cicli e L2 verso i 20-22... Più sono alti questi numeri, più è alta la speranza che il clock sia elevato... Vedi il mio post precedente...

[cionci]

Originariamente inviato da bjt2

E quei 3.8GHz sono un BD X8 125W di un ES che gioco forza non può essere come le CPU che usciranno tra 2 mesi, essendo stato prodotto probabilmente a novembre/dicembre...

Imho ci stanno benissimo al lancio i 3.4 Ghz per il 95W ed i 3.8 Ghz per il 125W. Questo gli lascerebbe notevoli margini per il rilascio di un 3.5 Ghz a 95W e di un 4 e un 4.2 Ghz a 125W, ovviamente tutto questo per massimizzare i ricavi. Credo che tirare fuori un 4.2 Ghz subito sarebbe controproducente, anche se potessero. Dando per assodato che il 3.8 Ghz sia più veloce del 990X...

[bjt2]

Originariamente inviato da cionci

Imho ci stanno benissimo al lancio i 3.4 Ghz per il 95W ed i 3.8 Ghz per il 125W. Questo gli lascerebbe notevoli margini per il rilascio di un 3.5 Ghz a 95W e di un 4 e un 4.2 Ghz a 125W, ovviamente tutto questo per massimizzare i ricavi. Credo che tirare fuori un 4.2 Ghz subito sarebbe controproducente, anche se potessero. Dando per assodato che il 3.8 Ghz sia più veloce del 990X...

Beh, si, è possibile che quel +40% di clock e -50% di TDP, oltre a essere casi ideali, si verifichino a processo maturo... E' vero che GF sta testando il 32nm da tempo (è pronto per loro da mesi, è colpa di AMD il ritardo) ma sicuramente il 45nm è più maturo... Quel +40% di clock, a processo appena cambiato, potrebbe essere benissimo solo +10-20%. Siamo comunque ampiamente entro i margini per avere anche adesso le frequenze che tu dici nel tuo post che ho quotato...

EDIT: l'X8 3.8 Ghz probabilmente sarà anche più veloce del SB X8 che uscirà, che probabilmente non andrà oltre i 3.2GHz, sopratutto a bassi carichi dove il turbocore 2.0, grazie al basso leackage del processo AMD, potrà fare la differenza: ALMENO 4.3GHz (probabilmente 4.5-4.6GHz)... Anche se l'IPC del SB fosse del 20% più elevato (a bassi carichi l'HT non serve, quindi non lo consideriamo), un core SB a 3.5GHz (supponiamo 300MHz di turbo con pochi thread) dovrebbe equivalere a un core BD a 4.2GHz...