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

[matteo1]

Originariamente inviato da revo

ps: conviene piu un quad 905e o un quad normale?

grazie

se ci tieni a risparmiare corrente vai pure sul 905e, tieni conto che da quanyto si legge in giro non si clocca molto.
Io in settimana solo per fare qualche prova provo un pò di oc

[carlottoIIx6]

Originariamente inviato da K Reloaded

uhm ... io ci andrei molto piano con l'affermare che taluni test sono truffaldini ... e cmq in generale io cercherei di rimanere con i piedi ben ancorati a terra ... a buon intenditor ...

hai visto la recensione che ho linkato???
dimmi se l'impressione che ne ricavi
è che gli i7 sono nettamente migliori???

ho spiegato come si bara! non dico che sono truccati i test (a volte si) ma che su cento test basta mostrare solo quelli che danno vantaggio solo ad un processore!

se avessi mostrato soli i test dove AMD vince, cosa vreste detto di AMD??
probabilmente quello che dite di INTEL, che è migliore!
rimango della mia idea fatta con tanti confronti e senso critico, sopratutto sul modo di fare informazione!
ed aspetto con ansia la conderma di PCPROFESSIONALE
che usciranno a novembre mi sa

comunque sia, bisogna valutare anche l'impressione di una cosa, quando tutti hanno una sola impresisone avvengono danni... come le bolle finanziarie che hanno causato la crisi finanziaria in usa e da noi!
tutti credevano che l'immobile era un investimento sicuro!
credo che i presupposti per mettere in dubbio la suppremazia intel ci siano!!! molti li avete elencati proprio voi!
credo di essere con i piedi per terra, e non di fare voli pintalici!! ma saranno i futuri test a smentirmi o darmi ragione.

[Pihippo]

Originariamente inviato da Мир

Scusa per il ritardo della risposta...
Si, si tratta principalmente di operazioni con matrici, diagonalizzazione etc... per un programma di meccanica quantistica con un alto grado di parallelismo, che sfrutta OpenMPI o MPICH2 (sembra che il primo vada meglio...).
Io devo compilare il source e finora su Xeon ho usato ifort 11.0 con le librerie mkl che vanno decisamente bene (guadagno un 20% di velocità di esecuzione su 8 core). Ma siccome ho anche degli opteron, vorrei provare ad ottimizzare il tutto.

Inoltre, in prospettiva, mi piacerebbe sapere se ci sono dei compilatori che sfruttano per davvero le paventate superiori capacità di calcolo parallelo degli opteron. Se prenderemo degli Opteron o no dipende molto da questo. Per un confronto così sottile servono dei buoni compilatori ottimizzati per le CPU che si usano e delle buone librerie!

Ciao
Premetto che di meccanica quantistica ne so un fico secco. Presumo si tratti di, visto che richiedi ottimizzazioni su modelli a memoria condivisa, calcolare interazioni atomo\atomo ed altre cose che odiavo in chimica fisica.
Comunque per le superiorità degli opteron sugli xeon dipende a quali xeon, se basati sul penryn magari si, se su nehalem mi sa proprio di no. Comunque presumo che il compiler debba essere free? Prova open64 http://developer.amd.com/cpu/open64/Pages/default.aspx
Qui vi sono alcune delle sue caratteristiche.

[Мир]

Originariamente inviato da carlottoIIx6

hai visto la recensione che ho linkato???
dimmi se l'impressione che ne ricavi
è che gli i7 sono nettamente migliori???
[snip]
rimango della mia idea fatta con tanti confronti e senso critico, sopratutto sul modo di fare informazione!
ed aspetto con ansia la conderma di PCPROFESSIONALE!

A proposito di confronti, io ho un source parallelizzato (codice C, C++ e tanto Fortran95) che funziona con OpenMPI (vedi post sopra).
Per fare un confronto serio Intel/AMD servono dei compilatori e delle librerie ottimizzate per le CPU.
Qualcuno ha fatto delle prove con le librerie ACML di AMD? Quale compilatore?
Sarei disposto a fornire dati per un dual socket Xeon E5345 (8 Core, sorry, non ho gli Xeon Nehalem), e Dual Socket Opteron 248 (2 core, sorry, niente di meglio) con lo stesso programma (Quantum espresso)...

[pandyno]

Originariamente inviato da carlottoIIx6

hai visto la recensione che ho linkato???
dimmi se l'impressione che ne ricavi
è che gli i7 sono nettamente migliori???

ho spiegato come si bara! non dico che sono truccati i test (a volte si) ma che su cento test basta mostrare solo quelli che danno vantaggio solo ad un processore!

se avessi mostrato soli i test dove AMD vince, cosa vreste detto di AMD??
probabilmente quello che dite di INTEL, che è migliore!
rimango della mia idea fatta con tanti confronti e senso critico, sopratutto sul modo di fare informazione!
ed aspetto con ansia la conderma di PCPROFESSIONALE!

Si guarda la scheda video utilizzata è una 9800gtx+ la satura anche un E5200

[Ren]

Riporto degli articoli di ricerca per gli utenti con conoscenze tecniche, sul concetto di Clustered Core, stesso approccio che si ipotizza adotterà AMD con Bulldozer.
Gli Articoli spaziano dalla struttura interna al confronto con SMT (HyperThreading) sia dal punto delle performance che dei consumi energetici.

SMT vs CMT(Clustered Core) :

http://www.csl.cornell.edu/~albonesi...ispass05_1.pdf

Ricerca sulla miglior estrazione del IPC :

http://cseweb.ucsd.edu/users/tullsen/ipdps04.pdf

Struttura della cache :

ftp://ftp.cs.rochester.edu/pub/paper...eaded_arch.pdf

Architettura Interna :

http://www.eecg.toronto.edu/~pc/rese...as.micro97.pdf

Spero di aver colto il senso dei primi due articoli :

Il primo studio afferma che l'approccio SMT diventa penalizzante sul versante dei consumi quando questo supera i 2-4 thread per core(50% energia sprecata in 8-16 thread). Il CMT anche se leggermente meno prestante scala meglio in complessità sul singolo cluster, ma i vantaggi si riducono nei confronti del SMT-Multicore.

Il secondo è più complesso, ma in breve dice che in front-end è in parte un collo di bottiglia, quindi combinare CMT e SMT crea il miglior compromesso possibile.

Queste due conclusioni sono già note, infatti sono state adottate dal Sun Rock.


Ovviamente ci sono molte più informazioni al interno degli articoli, che non ho citato, come approcci per la cache, thread scaling ecc..


Passo la palla agli esperti per il resto.


PS. Sono ovviamente in inglese.

[Apfelsine]

Originariamente inviato da Ren

Passo la palla agli esperti per il resto

e per fortuna che gli esperti sono altri

se tu non sei un esperto cosa possiamo dire noi comuni mortali ?

[Pihippo]

Originariamente inviato da Ren

Riporto degli articoli di ricerca per gli utenti con conoscenze tecniche, sul concetto di Clustered Core, stesso approccio che si ipotizza adotterà AMD con Bulldozer.
Gli Articoli spaziano dalla struttura interna al confronto con SMT (HyperThreading) sia dal punto delle performance che dei consumi energetici.

SMT vs CMT(Clustered Core) :

http://www.csl.cornell.edu/~albonesi...ispass05_1.pdf

Ricerca sulla miglior estrazione del IPC :

http://cseweb.ucsd.edu/users/tullsen/ipdps04.pdf

Struttura della cache :

ftp://ftp.cs.rochester.edu/pub/paper...eaded_arch.pdf

Architettura Interna :

http://www.eecg.toronto.edu/~pc/rese...as.micro97.pdf

Spero di aver colto il senso dei primi due articoli :

Il primo studio afferma che l'approccio SMT diventa penalizzante sul versante dei consumi quando questo supera i 2-4 thread per core(50% energia sprecata in 8-16 thread). Il CMT anche se leggermente meno prestante scala meglio in complessità sul singolo cluster, ma i vantaggi si riducono nei confronti del SMT-Multicore.

Il secondo è più complesso, ma in breve dice che in front-end è in parte un collo di bottiglia, quindi combinare CMT e SMT crea il miglior compromesso possibile.

Queste due conclusioni sono già note, infatti sono state adottate dal Sun Rock.


Ovviamente ci sono molte più informazioni al interno degli articoli, che non ho citato, come approcci per la cache, thread scaling ecc..


Passo la palla agli esperti per il resto.


PS. Sono ovviamente in inglese.

Ciao.
Premetto che non sono per nulla esperto, comunque mi interessano molto queste cosuccie qui.
Sbaglio o molti articoli sono riportati anche su http://citavia.blog.de/ ?
Interessantissimi gli articoli. Grazie di cuore.
Sopratutto per quanto riguarda l'approccio CMT mi sembra di capire che non soffre di pesanti drawback come il SMT. Ovvero R.O.P e buffer vari e L\S unit non sono condivisi per thread, quindi ogni thread avrebbe accesso a tutte le risorse disponibile per cluster. Leggo sempre nel link 2 che ogni cluster di integer possiede 4 code da 32 entrate rifornite da una centrale più grossa e più a monte delle processore ed ogni coda rifornisce 2 unità alu ed una agu( o forse una alu ed 1 agu?)
il problema che mi sembra di aver capito è che è spiegato nel LINK 2, e che sebbene questo permetta di spremere al massimo ILP e clock(poichè la logica di controllo e fowarding è meno complessa in quanto ogni cluster "dovrebbe essere indipendente" dall'altro) si hanno delle penalità in pratica, da quello che ho capito se:
1)
L'icu fa un errore a mettere 2 istruzioni dipendenti in 2 code diverse si ha una penalità di due cicli di clock, poi sempre per errori di scheduling se si assegna un operazione ad un cluster con gli issue slot(ovvero gli slot da cui entra l'istruzione nella pipeline) piena questa istruzione non verrà processata fino a quando non si hanno le risorse disponibili anche se nel cluster parente ci sono disponibili (quindi mi sa che è complicato spostare le cose da un cluster all'altro)
2)
Nel caso in cui una istruzione venga assegnata ad un cluster con la coda piena si creeranno le cosiddette pipeline bubbles, ovvero ulteriori istruzioni non potranno essere in coda cosi che si crei una bolla nella pipeline stessa, questo poichè la pipeline e composta da più stadi, e quando un'istruzione arriva nelle queue viene divisa in tante microoperazioni che vengono eseguite dagli stadi della pipeline, quindi mancando di alcune microoperazioni nella pipeline (le bolle) essa si stalla.

Scorrendo l'articolo ci sono altri bottleneck come ad esempio il register renaming se il thread è diviso "splittato dice nell'articolo su più cluster" in quanto i registri sono condivisi da ambedue i cluster,
Poi mi sono perso in quanto si parla di tecniche di SMT che consentono l'arginare di tutti sti bottleneck e qui chiedo l'aiuto di chi ne sa più di me BJT2 ed altri.

[Emanuele86]

dei phenom 945, 955, 965 step c3 ancora nulla???

[Ren]

------------

[birmarco]

Domanda:
Come devo setteare il controller RAM? Su Ganged o Unganged? Uso 2*DDR3 2CH...

[Ren]

Sbaglio o molti articoli sono riportati anche su http://citavia.blog.de/ ?
Interessantissimi gli articoli. Grazie di cuore.

Si, da quando ho introdotto questo blog sul thread segnalo sempre le novità.
Avevo già postato i link, ma con poco riscontro da parte degli utenti. Adesso ho scritto una piccola introduzione in modo da invogliare gli utenti.

1)
L'icu fa un errore a mettere 2 istruzioni dipendenti in 2 code diverse si ha una penalità di due cicli di clock, poi sempre per errori di scheduling se si assegna un operazione ad un cluster con gli issue slot(ovvero gli slot da cui entra l'istruzione nella pipeline) piena questa istruzione non verrà processata fino a quando non si hanno le risorse disponibili anche se nel cluster parente ci sono disponibili (quindi mi sa che è complicato spostare le cose da un cluster all'altro)

2)
Nel caso in cui una istruzione venga assegnata ad un cluster con la coda piena si creeranno le cosiddette pipeline bubbles, ovvero ulteriori istruzioni non potranno essere in coda cosi che si crei una bolla nella pipeline stessa, questo poichè la pipeline e composta da più stadi, e quando un'istruzione arriva nelle queue viene divisa in tante microoperazioni che vengono eseguite dagli stadi della pipeline, quindi mancando di alcune microoperazioni nella pipeline (le bolle) essa si stalla.

1) Capisco, dunque i dati non possono essere condivisi tra le pipe intere. Vedi qualche analogia comunicativa tra il funzionamento della pipeline FP del atlhon e la doppia pipe intera del clustered ?
2)Se ho capito bene, mi viene in mente solo un aumento delle entry come soluzione.

Guarda ho letto solo le conclusioni generali, il resto lo ho tralasciato per adesso. Comunque non sono un tecnico ed ho una visione generale del insieme, grazie agli articoli di approfondimento sulla rete.

[Pihippo]

Originariamente inviato da Ren

Da quando ho introdotto questo blog sul thread segnalo sempre le novità.
Avevo già postato i link, ma con poco riscontro da parte degli utenti. Adesso ho scritto una piccola introduzione in modo da invogliare gli utenti.



1) Capisco, dunque i dati non possono essere condivisi tra le pipe intere.
Vedi qualche analogia tra il funzionamento delle
2) Forse aumenteranno le entry.


Guarda ho letto solo le conclusioni generali, il resto lo ho tralasciato per adesso. Comunque non sono un tecnico ed ho una visione generale del insieme, grazie agli articoli di approfondimento sulla rete.

Ciao
Grazie.
Continua a postare ste coestte qui che sono interessantissime, io non sono un nemmono un tecnico, oddio si ma in altri campi dell'informazione che hanno a che farre con nanometri , ho una qualche infarinatura di programmazione ma niente di che, anzi se Sql è programmazione.... però più teste si mettono a leggere questi articoli più possbilità che si faccia qualche ipotesi veritierà su buldozzer, dai ragazzi apriamo un thread speculando su buldozer? Ora il capitano mi spara
1)
Nel terzo articolo da te riportato si fa riferimento ad uno scheduling che "conosce" esattamente la latenza delle istruzioni in modo di allocarle dinamicamente per massimizzare il throughput per ciclo e da evitare stalli, lo schema non l'ho capito a fondo.
2)
Probabile
Edit:
Ho visto ora il tuo messaggio completo.
Come analogie rispetto al k10 dallo schema sembra essere dual ported verso la cache come nel k10, ma se lo scheduling è errato il drop sembra essere più grosso, però rispetto alle alu ed alle FPU del k10 dovrebbero garantire un througput ed utilizzazione superiore, se non erro solo 2 agu del k10 avevano una porta verso la cache quindi alla 3 andava in pasto una NOP, qui invece sembra che le agu abbiano una porta privata. Magari hanno trovato qualche modo di associare ad ogni Int un'operazione di memoria, perchè nel k10 alla fase di decoding si accoppiano int per le alu + operazione di memoria per poi essere risuddivise ed essere esguite, oppure le operazioni di memoria vengono processate in maniera Out of order ed i decoder non ragruppano più operazione matematica più operazione di memoria, questo potrebbe spiegare la porta privata verso la cache.

[matteo1]

Originariamente inviato da birmarco

Domanda:
Come devo setteare il controller RAM? Su Ganged o Unganged? Uso 2*DDR3 2CH...

a me è stato detto che unganged è più stabile

[capitan_crasy]

AMD pubblica 9 video dove mostra il montaggio di un Home Theater PC con CPU Phenom2 X4 con TDP 65W.

Home Theater PC DIY 101 - Intro Chassis
Home Theater PC DIY 101 - Drives
Home Theater PC DIY 101 - Power Supply
Home Theater PC DIY 101 - Motherboard
Home Theater PC DIY 101 - Cables
Home Theater PC DIY 101 - Audio
Home Theater PC DIY 101 - TV Tuner
Home Theater PC DIY 101 - Memory
Home Theater PC DIY 101 - CPU and Heatsink

[jrambo92]

Originariamente inviato da matteo1

a me è stato detto che unganged è più stabile

È anche più performante in multi-threading.

[mtk]

molto piu' rustico il mio htpc con x3 720be a 3,6 gigi

[Knukcles]

Originariamente inviato da capitan_crasy

AMD pubblica 9 video dove mostra il montaggio di un Home Theater PC con CPU Phenom2 X4 con TDP 65W.

Home Theater PC DIY 101 - Intro Chassis
Home Theater PC DIY 101 - Drives
Home Theater PC DIY 101 - Power Supply
Home Theater PC DIY 101 - Motherboard
Home Theater PC DIY 101 - Cables
Home Theater PC DIY 101 - Audio
Home Theater PC DIY 101 - TV Tuner
Home Theater PC DIY 101 - Memory
Home Theater PC DIY 101 - CPU and Heatsink

Voglio quella tastiera della logitech!!

mia mia!

Non ho visto il tutto dettagliatamente......ma che scheda madre è?......mi pare di 3 anni fa.....

[-Maxx-]

Originariamente inviato da Knukcles

Voglio quella tastiera della logitech!!

mia mia!

Non ho visto il tutto dettagliatamente......ma che scheda madre è?......mi pare di 3 anni fa.....

La mitica diNovo Mini

La mobo non l'ho mai sentita, dice che è una MSI Media Live DIVA...

[matteo1]

http://blogs.amd.com/home/tag/msi-media-live-diva/