Newsgroup: it.comp.hardware.cpu
Titolo: Cosa rende davvero interessante Bulldozer

Le considerazioni che seguono di basano sulle informazioni
contenute in questo articolo:
http://www.anandtech.com/cpuchipsets/showdoc.aspx?i=3674
AMD ha rilasciato (finalmente!) delle nuove informazioni
riguardo Bobcat e Bulldozer.
Dei due il piu interessante e' Bulldozer, a distanza di anni
certi "discorsi strani" dei progettisti di AMD cominciano
ad aver senso.
Innanzitutto quello di Bulldozer *non* e' l'Hyperthreading
di Intel, con quello un secondo thread "sfrutta i buchi liberi"
di un altro thread su un core dimensionato per un thread "tipico"
(le varie unita funzionali vengono implementate tenendo conto
  in termini di costi/benefici rispetto all'esecuzione di
  un *singolo* thread e *poi* si sfruttano anche i "buchi liberi"
  per eseguirne un secondo).
Nel caso di Bulldozer invece il numero ed il tipo delle
unita funzionali presenti e' stato dimensionato su *due*
thread "tipici" (si e' tenuto conto di cosa serve in media
per avere un rapporto costi/prestazioni ottimo nel caso
di *due* thread in esecuzione simultanea).
La cosa ha senso, un sistema dual core con un clock di X Gz
in media non va veloce come un single core "ideale"
(che scala linearmente di prestazioni al crescere del clock)
con clock a 2*X Ghz
(di solito con roba che sfrutta entrambi i core le prestazioni
  sono intorno all' 180% invece del 200% teorico massimo).
Con un quad-core le prestazioni rispetto ad una cpu single core
"ideale" calano ancora di piu, ecc. ecc.
Questo perche devono condividere alcune risorse
(le cache condivise, i link verso i dispositivi esterni, ecc.)
e quindi devono "attendere" qualche volta in piu rispetto
ad un single core "ideale" che ha tutto per se.
Piu core si aggiungono e piu gli intralci reciproci aumentano.
Quindi piu core si aggiungono e piu dentro il chip ci sono
unita funzionali che "sprecano" spazio e corrente perche
non sono utilizzate al 100% rispetto al caso ideale
di un singolo core che macina al massimo.
"Fondendo" (e questo ci da un idea di una altro motivo del
nome Fusion per identificare questa nuova classe di cpu di cui
Bulldozer e' solo la prima generazione) i core come e' stato fatto
con Bulldozer diventa possibile "ridurre gli sprechi" perche il
calcolo costi/prestazioni tiene conto sin dal principio di cosa
possono fare contemporaneamente *due* thread.
Lo stesso giochetto lo si puo fare con 4,6,8 core "fusi", ecc. ecc.
con "guadagni" in termini di riduzione dei consumi e dimensioni sul chip
sempre piu decrescenti al crescere dei core "fusi"
ma comunque di gran lunga migliori rispetto a 4,6,8 core "normali".
Adesso resta da capire come intendono "fondere" la GPU.
Un unita funzionale "distinta" alla Larrabee che si prende
carico anche delle operazioni FP/SSE della cpu oppure
una "fusione" delle pipeline calcolando il rapporto ottimale
di (ad esempio) 4 "pseudo-core" ed 1 "pseudo-GPU" che
condividono le risorse ?
Nell'articolo Anand ragiona come se la GPU fosse un entita
separata dentro il chip (tipo i core di Larrabee) rispetto
ad un core vero e proprio, ma nello schema "AMD Fusion Design Metodology"
dell'articolo citato sopra, nel caso di Fusion usano il termine
APU, forse per indicare un gruppo di cpu/gpu "fuse insieme" ?
Come al solito AMD sta molto abbottonata, ma sembra che
nei prossimi anni (finalmente!) ci sara nuovamente battaglia
tra Intel ed AMD e non la pallosissima competizione a chi ha
piu core (quasi uguali a quelli della generazione precedente)
che c'e' stata ultimamente.
L. Micheletto


Inoltre pare che le cpu Bulldozer (almeno inizialmente) saranno 
compatibili con il Socket AM3...:)

 condividono le risorse ?
Mi sa che la GPU ha unita' funzionali cosi' diverse che e' dura fonderla 
colla CPU nello stesso datapath. Se gia' solo fossero affiancate on-chip 
avresti sufficiente banda e bassa latenza da poterti permettere cose 
interessanti (magari comunicando a livello della L3, come suggerisce Anand).
Per Larrabee, sembra essere un gran bel processore vettoriale... e' da 
vedere se sara' anche una GPU ;))
Pleg

 di quelle preposte al calcolo dei dati in virgola mobile.
Questo non toglie che nel caso dell'HT di Intel il dimensionamento
delle unita di esecuzione ecc. ecc. fosse stato fatto per *un* thread.
Per questo l'HT era disabilitabile, senza abbastanza unita di esecuzione
condivise era ovvio in certe situazioni sarebbe stato d'intralcio.
Nel caso di Bulldozer invece i "core virtuali" erano due in tutte
le fasi di progettazione e non possono aver trascurato le prestazioni FP
proprio su un core "di fascia alta" (altrimenti ai progettisti
converrebbe fare subito seppuku, sarebbe al morte di AMD).
AMD non ha ancora rivelato esattamente come e' fatto Bulldozer, pure
gli schemi che hanno reso pubblici non sono il massimo della chiarezza
ma viene da chiedersi come mai sullo schema le pipeline FP sono
disegnate "piu lunghe"; ricalcano il layout del chip
oppure sono indicative della lunghezza delle pipeline ?
Uno dei problemi con le pipeline FP (che eseguono
anche le istruzioni SSE/AVX, se ricordo bene) e' che sono
piu complesse, se invece di progettare una pipeline FP "per un solo thread"
(con le "bolle" utilizzabili per un secondo thread) la si progetta
sin dal principio per reggere due thread "a pieno carico" le cose cambiano
radicalmente rispetto al caso dell'HT:
1) si puo tollerare una pipeline piu lunga perche si avranno *sempre*
    due gruppi di istruzioni FP da eseguire senza nessuna dipendenza
    (non e' come con l'Hyperthreading che era disattivabile proprio
     perche era un "di piu" che non sempre portava benefici);
2) la pipeline FP "piu lunga" puo essere fatta viaggiare a frequenza
    piu elevata perche e' "foraggiata" *certamente* da due thread
    ed avendola "allungata" i singoli stadi sono piu "corti"/"semplici".
Spero abbiano tenuto conto di questo, oppure che i Bulldozer possano
salire di clock a livelli mostruosi (tipo Power 7) perche altrimenti
sono guai.
Come avevo scritto in precedenza, *finalmente*
le cose si stanno facendo nuovamente interessanti a livello
di architettura interna. :-)
Il problema e' che bisognera' aspettare il 2011. :-(
L. Micheletto

    ed avendola "allungata" i singoli stadi sono piu "corti"/"semplici".
per le unitï¿œ di floating point si parlava di prima "cpu a 128bit" in alcuni 
articoli, legati anche al fatto delle sse5....
come sono legate queste info?
-- 
SimBus82.net coming soon - 
http://www.simbus82.net
Blog allenamento - 
http://simbus82-workout.blogspot.com/
 

     perche era un "di piu" che non sempre portava benefici);
Intendi dire un fine-grain multithreading, in modo da ridurre la penalita' 
del non poter eseguire istruzioni back-to-back?
Pleg


Lo penso anch'io.

http://www.fudzilla.com/content/view/16425/1
Fudzilla parla di 2 quadcore nello stesso die, mentre per
le unit� floating-point, ritengo puntino molto sulle SSE5 (parlando
 di 128bit ...forse a grandi linee una migliorata implementazione
dell'interpretazione di Ganged riguardo la RAM), quindi di software ottimizzati.
Considerato che Bulldozer nasce innanzitutto come CPU per server/workstation
 non credo ci metteranno molto per crearvi programmi dedicati (AMD ha
tutto il tempo necessario per collaborazioni con SH...); discorso diverso per
il mondo desktop, ma dopo l'accordo con Intel,
http://www.amd.com/us/press-releases/Pages/amd-press-release-2009nov12.aspx
penso integreranno (oltre le proprie) gi� le SSE4.1 e sue evoluzioni.
Resta poi appunto la "fusione" della/e GPU/s (..."pura" x87?)...
Grizlod{R} 


Volevo puntualizzare che (da come scrive Fudo: This CPU will be designed
to easily interconnect with graphics...) sarebbe possibile (forse...forse a 28nm) il
progetto 'Torrenza', per cui si dovrebbero vedere mainboard abbastanza
differenti come layout, nel senso che dovrebbero sparire gli slot grafici, sostituiti
 dai socket per videocard, con sempre l'interfaccia di connessione sulla mascherina
 posteriore.
Ci� porterebbe ad intuibili vantaggi oltre ad agevolare per esempio
 la dissipazione del chip grafico...cosa che sta divenendo un cruccio
piuttosto serio.
Queste sono solo mie supposizioni +/- fantasiose...ma forse neppure tanto...
Grizlod{R} 

 progetto 'Torrenza',
Qualche link per chiarire cosa intende AMD con Torrenza:
http://en.wikipedia.org/wiki/Torrenza
http://www.tomshw.it/cpu.php?guide=20060625
http://punto-informatico.it/1663143/PI/News/amd-aprira-socket-delle-sue-cpu.aspx
...forse Bulldozer potrebbe essere l'inizio (e si spiegherebbero le
sole 2 unit� FP) ; come detto sopra la priorit� sar� per server/workstation...
Grizlod{R}

 la dissipazione del chip grafico...
Perche'? Se la potenza da dissipare e' quella, non e' cambiando posizione o 
interconnessione che risolvi il problema.
Pleg


Considerando tipicamente un case Tower (con un case Desktop la
situazione migliora...), la scheda gafica ha lo stesso chip grafico
 ed il resto della componentistica (alimentazione compresa), rivolti verso
il basso una volta inserita nel proprio slot (cioï¿½ verso il fondo del cabinet).
Ora il calore sviluppato dalla stessa tende (per legge fisica) a salire
 verso l'alto, quindi si puo dedurre che non venga proprio favorita
l'evaquazione dello stesso. Tant'ï¿½ vero che qualche produttore di schede grafiche
lanciï¿½, qualche tempo fa, layout di PBC "specchiati", ovvero con la componentistica HW
dal lato opposto a quello consueto. In tal modo il calore non ï¿½ + "ingabbiato"
 dal circuito stampato stesso, ma puï¿½ essere espulso dalla ventola nel retro del
 cabinet (sempre parlando di tower).
Senza contare che spesso e volentieri (sia gli originali che dissipatori
di terze parti) si fregano 2 o + slot liberi. Quindi anche in ottica
multi GPU (CF o SLI) un cabinet tower potrebbe divenire un bel fornelletto.
Grizlod{R}
 

[cut]
Ah ok d'accordo, stavo pensando alla ventilazione forzata e non ci avevo 
pensato.
Pleg

 
Mah...anche la ventilazione canalizzata non risolve tutti i problemi.
Le carenature delle schede grafiche hanno aperture per l'espulsione
 del calore anche superiormente, oltre che sulla griglia di ancoraggio.
La maggior parte del calore sviluppato resta cmq nel cabinet ed in 
qualche modo bisogna evacuarlo.
Ho recentemente acquistato un' HD5770 per collocarla in un case desktop.
Beh...ho dovuto praticare delle aperture sulla lamiera del cabinet, altrimenti
 il calore ristagnava, con conseguente riscaldamento, sia della MB che del
 resto...
Grizlod{R}      

 vedere se sara' anche una GPU ;))
Se come ipotizza Anand le operazioni FP verranno delegate alle
"pipeline della GPU" mi sa che la dovranno tenere piu vicino possibile
al "core virtuale" delle CPU, altrimenti le prestazioni FP sul lato x86
subiscono un crollo pauroso.
E' per quello che ipotizzavo una "fusione" pure di esse.
In fin dei conti, le GPU attuali lavorano con *clock molto bassi*
rispetto ad una CPU, quindi se si progetta una pipeline "ibrida"
con una parte "veloce" condivisa tra CPU e GPU, anche in presenza
di ottimizzazioni utili solo alle operazioni "per CPU"
la "sezione GPU" non sarebbe penalizzata piu di tanto.
Anzi, la "GPU virtuale" potrebbe avere delle "pipeline virtuali"
in parte implementate nel "core" ed in parte implementate
allo stesso livello gerarchico della L3 (nel senso che operano
alla stessa frequenza di clock della L3 e magari hanno link tutti
loro da e verso il memory controller).
L. Micheletto

 ottimizzati.
no i 128bit per le sse5 credo siano intesi come "precisione"



Stando al sito ufficiale, non mi pare venga citata la (tu la intendevi
quadrupla?) "precisione", ma un set di istruzioni per
 semplificare + operazioni in una sola...
http://www.amd.com/us-en/Corporate/VirtualPressRoom/0,,51_104_543_15008~119091,00.html
...quindi software ottimizzati...
Comunque... cercando in rete sembra che AMD "abbandoni"
 le SSE5 (ormai datate 2007), o meglio le integrer� nel set
AVX di Intel...
http://forums.amd.com/devblog/blogpost.cfm?catid=208&threadid=112934
Grizlod{R}


Esatto... alla fine dovrebbe andare proprio cosï¿œ.

 come sono legate queste info?
Le due pipeline FP operano su word a 128bit perche gestiscono
*anche* l'esecuzione delle istruzioni SSE (i registri XMM sono
a 128bit).
L. Micheletto

 loro da e verso il memory controller).
Qui non ti seguo: cosa intendi per pipeline virtuali?
Ho sempre pensato che la frequenza piu' bassa delle GPU fosse dovuta a un 
paio di fattori (ma anche qui non so niente di preciso, sto solo 
ipotizzando):
* per ottenere le frequenze piu' spinte devi progettare buona parte del 
datapath praticamente a livello di transistor, in logica dinamica (o peggio 
:) , o cmq con tecniche molto piu' complesse e costose del semplice "compila 
il Verilog su celle di libreria"; lo sforzo progettuale e di verifica per 
fare quei datapath dev'essere molto maggiore
* il parallelismo intrinseco delle operazioni grafiche fa si' che puoi 
sopravvivere con frequenze piu' basse, basta buttare una marea di unita' 
funzionali in parallelo; anzi, grazie a questo (e al parallelismo) puoi 
ottenere un'efficienza energetica che le CPU si sognano (giusto oggi ho 
visto dei numeri di EPI (Energy Per Instruction) interessanti: il P4 aveva 
un EPI di 29 nJ per istruzione, i core 2 sono scesi a 9, i nehalem credo 
siano un pochino piu' bassi ancora... certe schede NVidia arrivano a 0.6 
nJ/instr... un'ordine di grandezza di meno! Impressionante!)
Inoltre, le GPU hanno un fottio di istruzioni e unita' funzionali dedicate 
(specifiche per la grafica) che non potresti portare dentro la CPU (sarebbe 
la negazione del concetto di CPU).
Di piu': avere CPU e GPU fisicamente separate dentro il chip ti permette di 
poter fare power gating in modo molto piu' selettivo. Considerando che tra 
un po' ci potremo permettere di avere solo il 10% del chip acceso alla volta 
se no fonde :) mi vedo bene le due cose separate nei loro ring di 
alimentazione dedicati, accesi alla bisogna.
Pleg

 Qui non ti seguo: cosa intendi per pipeline virtuali?
Pipeline distinte che insieme implementano le funzioni equivalenti
a quelle di una "vecchia" pipeline per GPU.
Le sezioni di pipeline "compatibili" con le operazioni svolte tipicamente
dalle pipeline intere ed FP di una cpu potrebbero essere implementate
"nel core" mentre quelle "tipiche delle GPU" potrebbero essere spostate
in unita funzionali separate (sullo stesso chip), magari piu vicine
alle cache L3 ed operanti a velocita piu basse (ma con parallelismo
piu elevato).
In pratica sarebbe il passo successivo in cui si ottimizza globalmente
lo schema architetturale con CPU e GPU sullo stesso chip
analizzando operazioni e traffico generato dal sistema CPU+GPU.
Non e' una cosa cosi' fuori di testa come potrebbe apparire a prima
vista, la cosa viene gia fatta ora per partizionare il codice OpenCL
tra CPU e GPU (usando LLVM) negli SDK OpenCL e pure dal compilatore
degli shader OpenGL di Apple (sempre usando LLVM).
L. Micheletto

 si tratta di 128GByte/sec di traffico.
Cioe' 64 GB/s in arrivo dal register file, e 64 GB/s verso la logica di 
commit.
Poco :) un register file con ad es. 10 porte di lettura, 64 bit, ti 
sosterrebbe 2e9*10*64/8 = 160 GB/s   :))
Pleg


Per questo parlavo dei colli di bottiglia "esterni".
Se stai lavorando su matrici/bitmap ecc. ecc. e' tutto traffico da e verso
le cache e la memoria esterna (e ci sono i rispettivi colli di bottiglia
da considerare).
Se invece si tratta di dati che vengono elaborati piu volte nei registri
interni, di solito c'e da aspettarsi che vi siano parecchie operazioni
che coinvolgono anche le unita intere, jump condizionali, ecc. ecc.
con dipendenze dagli esiti delle operazioni eseguite poco prima.
Ripeto, non penso che in AMD siano degli stupidi, devono aver valutato
ed analizzato per bene i mix d'istruzioni ricorrenti e cosa succede durante
l'esecuzione dei programmi considerati piu "pesanti".
Inoltre, come ho gia scritto la condivisione delle pipeline FP permette
di applicare alcune ottimizzazioni che non sarebbero efficaci su
pipeline "ottimizzate per un singolo thread".
L. Micheletto