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

[capitan_crasy]

Un grazie speciale a bjt2 e Ren:

Originariamente inviato da Ren

Cominciano ad uscire alcune informazioni sulla nuova architettura Bulldozer. Pare che la L1 istruction e le unità di decoding saranno condivise da due core,

ognuno con proprie ALU, registri e cache dati. Si passerebbe da un approccio Multi-Core ad uno Clustered.

Assomiglia in minima parte al Rock della SUN.

Ci sono anche dettagli sul implementazione delle AVX di Intel all'interno del progetto SSE5.

Molto materiale proviene ovviamente dai brevetti depositati negli ultimi anni.

Eccovi alcuni Links.

http://citavia.blog.de/ (Sito che elenca i brevetti)

http://pc.watch.impress.co.jp/docs/c...18_168661.html (articolo di H.Goto)

http://aceshardware.freeforums.org/i...-75.html#10678 (parte di una discussione che tratta della nuova architettura e della implementazione delle AVX)

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ù...

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...

Originariamente inviato da 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

Originariamente inviato da bjt2

In effetti questo ha più senso di quello letto nell'articolo: la cache L1 splittata porrebbe dei problemi. Invece una cache L1 unificata per coppia di core, ma con 4 porte anzichè 2 da la massima flessibilità per far girare 1 o 2 threads. Ossia dinamicamente da la possibilità di avere un Hyperthreading pompato (perchè si hanno il doppio delle porte per la L1 per 2 threads) o un reverse Hyperthreading...

Aggiornamento 24.08.2009

Originariamente inviato da Ren

Dal suo blog "dresdenboy" ha stilato un abbozzo dell’architettura bulldozer seguendo gli ultimi brevetti depositati da AMD.

Nei prossimi giorni si passerà all'argomentazione dello schema.

Comunque si evincono dettagli sulla pipeline in Virgola mobile e sulla comunicazione tra i cluster interi e FP.

Aggiornamento 28.09.2009

Originariamente inviato da M4R1|<

bulldozer, da quello che aveva detto bjt2, dovrebbe essere in grado di eseguirle in un solo passo. Cmq dire ora che Sandy Bridge nn sarà un grosso cambiamento rispetto a Nehalem è un po' azzardato

Risposta di bjt2

Originariamente inviato da bjt2

Per quanto riguarda il core buldozer... Se le voci che girano sono esatte, quel reverse hyperthreading di cui si vociferava dovrebbe essere il seguente: le unità FP sono sempre a 128 bit, ma due (o più) core fisici condividono le unità intere e FP nel senso che entrambi i core possono utilizzarle. Questo perchè nelle precedenti architetture si è visto che le unità sono sottoutilizzate. Una istruzione a 256 bit è sempre spezzata in 2 a 128 bit, ma essendoci più unità intere e FP (anche se in comune) se non sono tutte utilizzate, le due parti a 128 bit possono essere eseguite in parallelo.

Originariamente inviato da Ren

Quasi dimenticavo,
Amd ha depositato un brevetto su una tecnologia molto simile al turbo boost di intel.

Eccovi il brevetto :
http://www.freepatentsonline.com/WO2009114141A1.pdf

[Piscicani_33]

Quale sarebbe il rapporto fra Bulldozer ed il progetto "Fusion"? Nonostante tutto mi pare di capire che questa architettura preveda sempre cores omogenei, ma l'idea di AMD di passare a delle APU con cores eterogenei, che possibilmente sfruttino la potenza del GPU computing e di ATI stream, dove andrebbe a finire? Se "The future is Fusion" bulldozer così com'è presentata qui, non è un po un controsenso?

[NightStalker]

Originariamente inviato da Ratatosk

Un confronto Pentium 4 vs Atom è imbarazzante, è vero che il progetto Netburst era un cesso, ma stai confrontando un Cesso con una palla di cacca

hahahaha sto morendo

[capitan_crasy]

Originariamente inviato da Ratatosk

Intanto contrariamente alle previsioni Globalfoundries produrrà in tecnologia bulk anche a 40nm e non partirà quindi dai 32nm come si sapeva fino ad ora:

http://globalfoundries.com/Customer_...croelectronics

Non è completamente in topic, ma i chipset AMD li fa in bulk, quindi un'attinenza al topic c'è

si ma purtroppo non produrrà ne GPU, ne chipset a 40nm...

[bjt2]

Originariamente inviato da capitan_crasy

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...

AMD userà le AVX e delle sue estensioni proprietarie che includono le istruzioni di SSE5 che non ci sono in AVX.

[bjt2]

Originariamente inviato da alesc

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

Non ti so rispondere con precisione... Forse il fatto di non avere una doppia cache dati tarpa molto le prestazioni dei due core virtuali... Qui invece la cache dati, che è la parte più sollecitata, è divisa: doppia banda per due threads.

[bjt2]

Originariamente inviato da 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

In effetti questo ha più senso di quello letto nell'articolo: la cache L1 splittata porrebbe dei problemi. Invece una cache L1 unificata per coppia di core, ma con 4 porte anzichè 2 da la massima flessibilità per far girare 1 o 2 threads. Ossia dinamicamente da la possibilità di avere un Hyperthreading pompato (perchè si hanno il doppio delle porte per la L1 per 2 threads) o un reverse Hyperthreading...

[bjt2]

Originariamente inviato da navarre63

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

Sono un ingegnere informatico, attualmente ricercatore in un istituto del CNR, con la passione per l'elettronica, la microelettronica e le microarchitetture degli elaboratori...
Comunque capire uno schema non implica automaticamente saperne progettare uno ex-novo e innovativo...

[bjt2]

Originariamente inviato da ippo.g

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

Questo è lo schema per ogni coppia di core...

[bjt2]

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.

Attualmente il K8/K10 ha 3 ALU, 3 AGU e 3 FPU per core. Le ALU e AGU fanno parte della pipeline intera e le FPU di quella FP. Ora poichè il core i7 è più forte sia in intero che in FP, voglio sperare che per due pipeline intere, AMD intenda 2 blocchi del vecchio K8 completo di ALU e analogamente per FP. Perchè da quello schema sembrerebbe di no. Poi la cache L1 è meglio se è unica per due core, ma con 4 porte, così da minimizzare i giramenti di pollici delle unità...

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...

Questo sarebbe un delitto non farlo...

Originariamente inviato da Ren

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



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.

No. Il programma vede due core, che condividono alcune parti (e questo è uno svantaggio, ma non è terribile come l'hyperthreading INTEL) ma in compenso possono essere usate assieme su un solo thread (istruzione AVX a 256 che viene spezzata sulle due unità).

Originariamente inviato da calabar

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

Esatto.

Originariamente inviato da greeneye

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.

Vedi sopra.

[capitan_crasy]

Originariamente inviato da bjt2

Attualmente il K8/K10 ha 3 ALU, 3 AGU e 3 FPU per core. Le ALU e AGU fanno parte della pipeline intera e le FPU di quella FP. Ora poichè il core i7 è più forte sia in intero che in FP, voglio sperare che per due pipeline intere, AMD intenda 2 blocchi del vecchio K8 completo di ALU e analogamente per FP. Perchè da quello schema sembrerebbe di no. Poi la cache L1 è meglio se è unica per due core, ma con 4 porte, così da minimizzare i giramenti di pollici delle unità...



Questo sarebbe un delitto non farlo...



No. Il programma vede due core, che condividono alcune parti (e questo è uno svantaggio, ma non è terribile come l'hyperthreading INTEL) ma in compenso possono essere usate assieme su un solo thread (istruzione AVX a 256 che viene spezzata sulle due unità).



Esatto.



Vedi sopra.

[Soulman84]

non me ne sono persa una delle tue gif..le ho tutte in una cartella

[milanok82]

A breve dovrebbero uscire schede madri am3 con chipset 785b,vorrei chiedere ma quindi questo chipset sarà migliore del 790gx che io ho nella mia scheda madre?

[capitan_crasy]

Originariamente inviato da milanok82

A breve dovrebbero uscire schede madri am3 con chipset 785b,vorrei chiedere ma quindi questo chipset sarà migliore del 790gx che io ho nella mia scheda madre?

un attimo di pazienza e pubblico la notizia con i primi test del 785G.
In sostanza va come un 780G, ma grazie alle DX10.1 avrà pieno sostegno a seven e finalmente l'uscita HDMI potrà gestire l'audio il 5.1...

[capitan_crasy]

Overclock IGP 785G @ 700Mhz




Consumo in Idle


Consumo in Full Load


Consumo in Games


Clicca qui...

[overclock80]

Se i risultati sono questi, sono abbastanza deludenti.

Prestazioni al max migliori del 2% circa quando va bene e consumi superiori.

Spero siano dovuto ai driver acerbi che non lo sfruttano bene perchè a sto punto tanto vale stare sul 780G.

[capitan_crasy]

Originariamente inviato da overclock80

Se i risultati sono questi, sono abbastanza deludenti.

Prestazioni al max migliori del 2% circa quando va bene e consumi superiori.

Spero siano dovuto ai driver acerbi che non lo sfruttano bene perchè a sto punto tanto vale stare sul 780G.

Il miglioramento del 785G riguarda le DX 10.1 e il supporto del HDMI all'audio 5.1 ( ma li leggete i miei post? )
Per il resto è uguale al 780G soprattutto nelle frequenze dell IGP...
AMD ha introdotto RS880 in versione 55nm per portare il supporto alle DX10.1 in quanto Win7 si avvantaggia con Aero delle DX10.1 per operare un offload dalla CPU a carico della GPU...

[overclock80]

Originariamente inviato da Ratatosk

Questo chipset nasce per offrire le DX10.1. E basta. In più hanno dato un ritocco alle altre features della sezione audio-video.

E' tutto fuorché deludente, si potrebbe anzi dire che sia attualmente il miglior chipset sul mercato per PC low-cost da famiglia con Windows 7 a bordo.

Beh a parte quelle aggiunte, io sinceramente mi aspettavo un aumento delle prestazioni del 5-10% (ok, non è che ci si giochi però non guasta ).

Anche l'aumento dei consumi non so quanto si giustifichi con l'aggiunta di quelle novità, non credo siano entrate in gioco durante la recensione specie in idle.

Non dico sia un cattivo chipset, è certamente competitivo nel suo settore, come lo è il 780G. Di sicuro mi aspettavo di più specie sul lato consumi.

Prima di dare un giudizio definitivo comunque attendo qualche altra recensione magari con marche più note.

Originariamente inviato da capitan_crasy

Il miglioramento del 785G riguarda le DX 10.1 e il supporto del HDMI all'audio 5.1 ( ma li leggete i miei post? )
Per il resto è uguale al 780G soprattutto nelle frequenze dell IGP...
AMD ha introdotto RS880 in versione 55nm per portare il supporto alle DX10.1 in quanto Win7 si avvantaggia con Aero delle DX10.1 per operare un offload dalla CPU a carico della GPU...

Si li leggo però mi aspettavo di più lo stesso.

P.S Aero è la prima cosa che disabilitò su Vista quindi temo non noterò differenze da questo lato.

[capitan_crasy]

Originariamente inviato da overclock80

Si li leggo però mi aspettavo di più lo stesso.

P.S Aero è la prima cosa che disabilitò su Vista quindi temo non noterò differenze da questo lato.

Il problema è molto più complesso.
Nelle IGP e in CPU entry lever è importante avere il supporto alle DX10.1 altrimenti si rischia una pessima resa su Seven.
I grandi produttori OEM questo lo sanno e AMD ha messo sul piatto 785G per le nuove macchine, cosa che Nvidia non può fare in quanto non dispone di una IGP DX 10.1; in questa ottica è stata costretta ad inventarsi le G200 a 40nm per non rimanere fuori dal mercato...
Aero su Seven è molto più completo di quello di Vista e con il completo supporto alla GPU DX10.1 non ci sarà carico sulla CPU...

[navarre63]

Originariamente inviato da bjt2

Sono un ingegnere informatico, attualmente ricercatore in un istituto del CNR, con la passione per l'elettronica, la microelettronica e le microarchitetture degli elaboratori...
Comunque capire uno schema non implica automaticamente saperne progettare uno ex-novo e innovativo...

va bè...io cmq il curriculum ad AMD o INTEL lo invierei lo stesso