[Thread Ufficiale V4.0] AMD K10 Phenom2/Athlon2: L'era dei 45nm AMD!

[bjt2]

Originariamente inviato da bjt2

L'architettura è particolare, nel senso che la pipeline di decoding è unica, ma hanno splittato la cache dati L1. Per vedere se sono miglioramenti rispetto al K8/10 bisogna vedere la lunghezza delle code dello scheduler e quante microoperazioni per ciclo può fare ogni pipeline. Ma siccome si parlava di pipeline più lunghe per frequenze presumibilmente più alte, è probabile che le unità siano anche di meno. Daltronde splittare la cache dati aiuta anche a salire di clock...
Appena ho tempo leggerò gli articoli linkati. Magari c'è qualche dettaglio in più...

Allora... Ho letto l'articolo. Sono solo ipotesi, ma si basano su brevetti depositati. A prima vista potrebbe sembrare un normale hyperthreading. Ma è diverso. Le due pipeline intere e la pipeline FP possono essere usate da entrambi i thread eventualmente combinati (per esempio operazioni AVX intere da 256 bit se le pipeline intere sono da 128 bit saranno splittate in 2 operazioni a 128 bit e occuperanno tutte e due le pipeline). Il decoder potrà decodificare 4 istruzioni per ciclo anche dei due thread misti e nel caso di istruzione semplice in un thread e complessa nell'altra, potranno andare in parallelo. Finalmente sarà introdotta una trace cache delle istruzioni decodificate e il loop detection che tiene in questa cache il codice del loop già decodificato. Ci sarà una cache L2 probabilmente condivisa tra questa coppia di core, ci sarà una modalità turbo come quella dei core i7 e forse la cache L1 sarà con latenza di 2 cicli (!). In sostanza 2 core condividono la cache L1 istruzioni, il decoder, la cache L2 e l'unità FP, ma poi per il resto sono 2 core separati, che nel caso serva, possono unire le forze per un solo thread (vedi istruzioni a 256 bit). Questo può aver fatto nascere le voci sul reverse hyperthreading, perchè in questo caso questi 2 core semplificati possono unire le forze se necessario...

[capitan_crasy]

Originariamente inviato da bjt2

Allora... Ho letto l'articolo. Sono solo ipotesi, ma si basano su brevetti depositati. A prima vista potrebbe sembrare un normale hyperthreading. Ma è diverso. Le due pipeline intere e la pipeline FP possono essere usate da entrambi i thread eventualmente combinati (per esempio operazioni AVX intere da 256 bit se le pipeline intere sono da 128 bit saranno splittate in 2 operazioni a 128 bit e occuperanno tutte e due le pipeline). Il decoder potrà decodificare 4 istruzioni per ciclo anche dei due thread misti e nel caso di istruzione semplice in un thread e complessa nell'altra, potranno andare in parallelo. Finalmente sarà introdotta una trace cache delle istruzioni decodificate e il loop detection che tiene in questa cache il codice del loop già decodificato. Ci sarà una cache L2 probabilmente condivisa tra questa coppia di core, ci sarà una modalità turbo come quella dei core i7 e forse la cache L1 sarà con latenza di 2 cicli (!). In sostanza 2 core condividono la cache L1 istruzioni, il decoder, la cache L2 e l'unità FP, ma poi per il resto sono 2 core separati, che nel caso serva, possono unire le forze per un solo thread (vedi istruzioni a 256 bit). Questo può aver fatto nascere le voci sul reverse hyperthreading, perchè in questo caso questi 2 core semplificati possono unire le forze se necessario...

bjt2 santo subito!

Trasferirò il tuo post in prima pagina!

Comunque sia alla faccia del cambiamento!
Due core che si dividono cache L1 e L2 e in grado di funzionare congiuntamente o separatamente!
Una domanda:
Non ho ancora capito se AMD utilizzerà comunque le istruzione SSE5 oppure lasci spazio solamente alle istruzioni AVX...

[alesc]

Originariamente inviato da bjt2

Allora...
...Questo può aver fatto nascere le voci sul reverse hyperthreading, perchè in questo caso questi 2 core semplificati possono unire le forze se necessario...

Molto interessanti queste anticipazioni. Se così fosse la questione storica del reverse avrebbe finalmente un senso e da profano mi sembra anche molto promettente. Sarebbe un multi core evoluto dove i singoli core non sarebbero più puri duplicati appiccicati insieme ma sarebbero integrati/integrabili (almeno a coppie) in una sorta di cluster fisico a seconda delle esigenze di calcolo. Lo definirei multi-core di seconda generazione o multi-cluster-core!
Si dice che il punto debole dell'hyperthreading sia la bassa efficienza energetica (Watt/Gflop) (perrò non ho capito perché), questo approccio che sembra per molti versi opposto dici che promette, aldilà degli altri benefici, una migliore efficienza?
alesc

[Dre@mwe@ver]

Uhm...molto interessante l'architettura bulldozer...davvero innovativa anche!

Credo che questa architettura segnerà la ribalta per AMD...o almeno lo spero

[Pentajet]

avrei una domanda ma questo bulldozer è lo stesso presentato da Ruiz o è uno diverso?Grazie.

[lishi]

Originariamente inviato da Ratatosk

Non credo proprio...

Dalla mia memoria (articolo originale non mi ricordo proprio dove lo avevo preso).

Da un confronto fra un pentium 4(3.0ghz circa) contro un atom 330.

Si è rivelato che mentre nella maggior parte dei test atom batteva il pentium 4 grazie al core supplementare durante la navigazione internet, uso di windows( file manager, documenti word etc) atom mostrava segni di debolezza mentre il pentium 4 filava liscio (lasciamo perdere i consumi).

Certamente avere un doppio core aiuta quando devi fare decompressioni, enconding etc etc, ma nei programmi di tutti i giorni raramente uso più di un core solo.

Neppure usare due programmi contemporaneamente la cosa si sente visto che di solito solo il programma che usi in quel momento consuma cicli cpu in quantità degna di nota.

[Ren]

Il progetto bulldozer doveva essere presentato diverni anni fa, ma ha accumulato ritardi su ritardi.

Tornando al tema principale, pare che gli stadi della pipeline aumenteranno, come già vi ha accennato bjt2. Si parla per l'appunto di almeno due/tre stadi dovuti alla trace cache ed un nuovo stage posto prima dello scheduler che dovrebbe chiamarsi "MAP".


L'attuale pipeline dei K8/10 è composta da 12-stage, invece quella dei core2/i7 da 14stage. Ovviamente mi riferisco alla pipeline per i numeri interi.
Vedremo come verranno migliorate le unità di branching che purtroppo sono sempre state il tallone di achille di AMD, soprattutto dal punto di vista dello spazio occupato in relazione all'efficienza.

[Ren]

Vi allego una vecchia immagine del presunto bulldozer.



Segnalo un altro processore che utilizza un approccio simile al clustered-core. Si tratta di un prototipo quasi definitivo della Sun che purtroppo non vedrà luce.
Si chiama con il nome in codice "Rock"

Eccovi il link wikipedia ed un PDF.

http://en.wikipedia.org/wiki/Rock_processor

http://www.opensparc.net/pubs/preszo...ckHotChips.pdf

[fabri27023]

Ciao a tutti, volevo chiedervi una cosa riguardo la AsRock A780GXE/128M, nel sito infatti c'è scritto AM3 CPU ready,cosa vuol dire?? Nella AsRock A780GXH/128M invece c'è scritto Support for AM3 processor.
Differenza tra AM3 ready e AM3 support ?

[navarre63]

Originariamente inviato da bjt2

Allora... Ho letto l'articolo. Sono solo ipotesi, ma si basano su brevetti depositati. A prima vista potrebbe sembrare un normale hyperthreading. Ma è diverso. Le due pipeline intere e la pipeline FP possono essere usate da entrambi i thread eventualmente combinati (per esempio operazioni AVX intere da 256 bit se le pipeline intere sono da 128 bit saranno splittate in 2 operazioni a 128 bit e occuperanno tutte e due le pipeline). Il decoder potrà decodificare 4 istruzioni per ciclo anche dei due thread misti e nel caso di istruzione semplice in un thread e complessa nell'altra, potranno andare in parallelo. Finalmente sarà introdotta una trace cache delle istruzioni decodificate e il loop detection che tiene in questa cache il codice del loop già decodificato. Ci sarà una cache L2 probabilmente condivisa tra questa coppia di core, ci sarà una modalità turbo come quella dei core i7 e forse la cache L1 sarà con latenza di 2 cicli (!). In sostanza 2 core condividono la cache L1 istruzioni, il decoder, la cache L2 e l'unità FP, ma poi per il resto sono 2 core separati, che nel caso serva, possono unire le forze per un solo thread (vedi istruzioni a 256 bit). Questo può aver fatto nascere le voci sul reverse hyperthreading, perchè in questo caso questi 2 core semplificati possono unire le forze se necessario...

io non so tu che lavoro faccia,cmq fossi in te invierei il tuo curriculum a chi di dovere...

[ippo.g]

Originariamente inviato da bjt2

Allora... Ho letto l'articolo. Sono solo ipotesi, ma si basano su brevetti depositati. A prima vista potrebbe sembrare un normale hyperthreading. Ma è diverso. Le due pipeline intere e la pipeline FP possono essere usate da entrambi i thread eventualmente combinati (per esempio operazioni AVX intere da 256 bit se le pipeline intere sono da 128 bit saranno splittate in 2 operazioni a 128 bit e occuperanno tutte e due le pipeline). Il decoder potrà decodificare 4 istruzioni per ciclo anche dei due thread misti e nel caso di istruzione semplice in un thread e complessa nell'altra, potranno andare in parallelo. Finalmente sarà introdotta una trace cache delle istruzioni decodificate e il loop detection che tiene in questa cache il codice del loop già decodificato. Ci sarà una cache L2 probabilmente condivisa tra questa coppia di core, ci sarà una modalità turbo come quella dei core i7 e forse la cache L1 sarà con latenza di 2 cicli (!). In sostanza 2 core condividono la cache L1 istruzioni, il decoder, la cache L2 e l'unità FP, ma poi per il resto sono 2 core separati, che nel caso serva, possono unire le forze per un solo thread (vedi istruzioni a 256 bit). Questo può aver fatto nascere le voci sul reverse hyperthreading, perchè in questo caso questi 2 core semplificati possono unire le forze se necessario...

ma state parlando di un dual core?
non dovrebbe essere un esacore?

[capitan_crasy]

Originariamente inviato da Ren

Il progetto bulldozer doveva essere presentato diverni anni fa, ma ha accumulato ritardi su ritardi.

Tornando al tema principale, pare che gli stadi della pipeline aumenteranno, come già vi ha accennato bjt2. Si parla per l'appunto di almeno due/tre stadi dovuti alla trace cache ed un nuovo stage posto prima dello scheduler che dovrebbe chiamarsi "MAP".


L'attuale pipeline dei K8/10 è composta da 12-stage, invece quella dei core2/i7 da 14stage. Ovviamente mi riferisco alla pipeline per i numeri interi.
Vedremo come verranno migliorate le unità di branching che purtroppo sono sempre state il tallone di achille di AMD, soprattutto dal punto di vista dello spazio occupato in relazione all'efficienza.

Bè diciamo che non è in ritardo ma non è proprio nato...
A quanto pare AMD ha cancellato o meglio ha evoluto il progetto Bulldozer del 2007:
Da un Quad core a 45nm con SSE5 a un Octa core a 32nm con AVX...
Inoltre Bulldozer sarà anche FUSION con il core Llano...

Originariamente inviato da Ren

Vi allego una vecchia immagine del presunto bulldozer.

Immagine dice "Hammer" (K8) micro architecture...

Segnalo un altro processore che utilizza un approccio simile al clustered-core. Si tratta di un prototipo quasi definitivo della Sun che purtroppo non vedrà luce.
Si chiama con il nome in codice "Rock"

Eccovi il link wikipedia ed un PDF.

http://en.wikipedia.org/wiki/Rock_processor

http://www.opensparc.net/pubs/preszo...ckHotChips.pdf

Una CPU clastered-core destinata anche al mercato desktop; alla faccia dei programmi non multicore...

Originariamente inviato da fabri27023

Ciao a tutti, volevo chiedervi una cosa riguardo la AsRock A780GXE/128M, nel sito infatti c'è scritto AM3 CPU ready,cosa vuol dire?? Nella AsRock A780GXH/128M invece c'è scritto Support for AM3 processor.
Differenza tra AM3 ready e AM3 support ?

due modi diversi per dire la stessa cosa:
Supporto alle CPU AM3...

[capitan_crasy]

Originariamente inviato da ippo.g

ma state parlando di un dual core?
non dovrebbe essere un esacore?

No, stiamo parlando dell' architettura in generale...
La domanda più succosa è:
Questi due core con L1 e L2 condivisi viene contata come due core oppure come se fosse uno?
mi spiego:
Un quad core Bulldozer potrebbe avere 8 core distinti?

[ippo.g]

Originariamente inviato da capitan_crasy

No, stiamo parlando dell' architettura in generale...
La domanda più succosa è:
Questi due core con L1 e L2 condivisi viene contata come due core oppure come se fosse uno?
mi spiego:
Un quad core Bulldozer potrebbe avere 8 core distinti?

ah ecco così è più chiaro,la struttura fondamentale sarebbe sta specie di dual core e partendo da questa si farebbe 2-4-6-8 etc?

[greeneye]

Originariamente inviato da capitan_crasy

No, stiamo parlando dell' architettura in generale...
La domanda più succosa è:
Questi due core con L1 e L2 condivisi viene contata come due core oppure come se fosse uno?
mi spiego:
Un quad core Bulldozer potrebbe avere 8 core distinti?

Secondo me le cose sono un po differenti.

L'innovazione è portare una (probabilmente piccola) cache L1 dati all'interno delle singole unità di esecuzione (che già ora sono 2 intere + una fp se non erro). L'impressione è che alla fine le 2 unità potranno lavorare su thread diversi realizzando sostanzialmente un HT e alla bisogna l'unità fp potrà usare entrambe le L1.

Probabilmente le perplessità di bjt2 circa la scarsa capacità di alimentare le unità di esecuzione dei phenom sono vere.

[capitan_crasy]

Originariamente inviato da ippo.g

ah ecco così è più chiaro,la struttura fondamentale sarebbe sta specie di dual core e partendo da questa si farebbe 2-4-6-8 etc?

In linea generale è esatto...

Originariamente inviato da greeneye

Secondo me le cose sono un po differenti.

L'innovazione è portare una (probabilmente piccola) cache L1 dati all'interno delle singole unità di esecuzione (che già ora sono 2 intere + una fp se non erro). L'impressione è che alla fine le 2 unità potranno lavorare su thread diversi realizzando sostanzialmente un HT e alla bisogna l'unità fp potrà usare entrambe le L1.

Probabilmente le perplessità di bjt2 circa la scarsa capacità di alimentare le unità di esecuzione dei phenom sono vere.

La domanda è se questo approccio non porti appunto ad un possibile reverse hyperthreading; considera anche che una L1 e L2 condivisa da due core significa meno transistor da alimentare X numero di core...

[Ren]

L'immagine che ho postato proviene da un prototipo amd di vecchia data. (mi pare provenga da un brevetto).

No, stiamo parlando dell' architettura in generale...
La domanda più succosa è:
Questi due core con L1 e L2 condivisi viene contata come due core oppure come se fosse uno?
mi spiego:
Un quad core Bulldozer potrebbe avere 8 core distinti?

Penso che il programma veda sempre un core solo, probabilmente la logica OOO si occuperà della scissione delle istruzioni in coda.
Il concetto dovrebbe essere l'inverso del SMT, cioè da un thread ne derivi due più semplici da gestire all'interno dallo scheduler/register renaming.

[calabar]

Originariamente inviato da capitan_crasy

La domanda è se questo approccio non porti appunto ad un possibile reverse hyperthreading; considera anche che una L1 e L2 condivisa da due core significa meno transistor da alimentare X numero di core...

Ho idea che greeneye parlando di "alimentare" si riferisse ai dati, non alla corrente elettrica.
O sbaglio?

[greeneye]

Originariamente inviato da capitan_crasy

In linea generale è esatto...

La domanda è se questo approccio non porti appunto ad un possibile reverse hyperthreading; considera anche che una L1 e L2 condivisa da due core significa meno transistor da alimentare X numero di core...

La L2 non è comune a più core, anzi la L1 viene spezzettata in parti più piccole associate alle unità di esecuzione ed in linea di massima servono più transistor per realizzare due cache piccole al posto di una grande.
Per quanto riguarda il reverse hypertreading non credo che sia possibile o realizzabile: un compito seriale è seriale e non parallelizzabile.

Più che altro si vede che l'unità fp accede ad entrambe le cache e quindi avrà una banda doppia e la possibilità di lavorare su insiemi di dati più grandi senza un cache miss.

[greeneye]

Originariamente inviato da calabar

Ho idea che greeneye parlando di "alimentare" si riferisse ai dati, non alla corrente elettrica.
O sbaglio?

Esatto.
L'impressione che il phenom renda poco, o meglio molto meno, di quanto dovrebbe io la ho da tempo. La stessa intel all'uscita era sorpresa di quanto andasse il k10. Probabilmente le unità di esecuzione passano gran parte del loro tempo a girarsi i pollici.