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

[dark.halo]

Originariamente inviato da papafoxtrot

Infatti le CPU bulldozer di fascia più alta saranno CPU quad core nel senso stretto, in cui ogni core avrà due pipeline intere... In questo senso sono etichettate come CPU a 8 core.

A me però sarebbe piacuto vedere anche un SMT su bulldozer... Insomma è un implementazione che in termini di silicio costa poco e infatti diverse CPU di fascia più alta presentano qualcosa di simile... SUN, IBM, FUSJITSU... Hanno tutti almeno due thread per core...
Non credo che SMT e core a due pipeline rintere si escludano l'un l'altro...

In passato, in un intervista riportata qui su HWUP AMD aveva parlato di core in grado di amministrare più di due thread... c' qualche speranza ??

Ma non era un octo core nativo ??? Con in più una forma di HT all'ennesima potenza ?? L'SMT ci dovrebbe stare tutto a giudicare la lunghezza delle pipeline o mi sbaglio. Correggetemi dovessi dire castronerie

[papafoxtrot]

Non ti so proprio rispondere sulla lunghezza delle pipeline... Ad ogni modo pare che appunto AMD non sia propensa all'HT...
Ad ogni modo no. Saranno 4 "moduli" come li chiamano ora, ciascuno dotato di una unità floating point e due unità intere.

Curioso di vedere il reverse HT, anche se secondo me ormai arriva tardi... nel 2011 bene o male tutti software che richiederanno molta potenza si saranno spostati sul multicore...

Una domanda per gli specialisti: come mai succede che in un core di processore, sia x86 che non, l'occupazione non raggiunge mai il 100%, così da dover implementare soluzioni come il SMT??

Un altra domanda: sbaglio o il progetto fusion prevede in futuro la sostituzione della FPU con un unità derivante da un core grafico integrato? In tal caso come si potrà sfruttare una eventuale unità non x86??

[blackshard]

Originariamente inviato da papafoxtrot

Una domanda per gli specialisti: come mai succede che in un core di processore, sia x86 che non, l'occupazione non raggiunge mai il 100%, così da dover implementare soluzioni come il SMT??

Per via degli stalli nelle pipeline, causati dai branch imprevisti, causati a loro volta dai salti condizionati nel codice eseguibile.

Se hai un salto condizionato, tutto quello che c'è nella pipeline prima dello stadio di execute diventa immondizia e deve essere ricaricato.
E' come il principio della catena di montaggio. Purtroppo vado di fretta, altrimenti ti farei un esempio.

[papafoxtrot]

Credo di aver capito.
Si può dire che siano gli algoritmi di brench prediction che non riescono a prevedere ciò che sarà da caricare in presenza di un salto condizionato o è proprio l'esecuzione del processo che si ferma nella pipeline e deve partire dall'inizio della pipeline una nuova esecuzione?
Voglio dire... le due cose sono collegate?
Comunque: ecco perché a informatica alle superiori dicevano sempre di evitare i salti condizionati!!
Ad ogni modo una pipeline più lunga dovrebbe soffrire maggiormente in questo caso, giusto? Per questo dark qui sopra diceva che la lunghezza delle pipeline rendeva possibile l'adozione dell'SMT? Possibile quindi in senso di "vantaggioso"??

[bjt2]

Originariamente inviato da papafoxtrot

Credo di aver capito.
Si può dire che siano gli algoritmi di brench prediction che non riescono a prevedere ciò che sarà da caricare in presenza di un salto condizionato o è proprio l'esecuzione del processo che si ferma nella pipeline e deve partire dall'inizio della pipeline una nuova esecuzione?
Voglio dire... le due cose sono collegate?
Comunque: ecco perché a informatica alle superiori dicevano sempre di evitare i salti condizionati!!
Ad ogni modo una pipeline più lunga dovrebbe soffrire maggiormente in questo caso, giusto? Per questo dark qui sopra diceva che la lunghezza delle pipeline rendeva possibile l'adozione dell'SMT? Possibile quindi in senso di "vantaggioso"??

Anche quando si attende un dato da memoria...

Comunque quel core potrebbe essere anche un semplice core K10. 35 milioni di transistor mi sembrano pochi per un cluster bulldozer: ricordo che l'unità FPU per il cluster di due core è una sola, ma è potente più del doppio di quella di un singolo core K10, perchè può fare 2 FMAC a 128 bit o 1 FMAC a 256 bit, ossia ha 8 addizionatori e 8 moltiplicatori FP a 32 bit (riconfigurabili a 4+4 a 64 bit), più la logica per le SSE intere (a 128 e 256 bit), senza contare le 8 pipeline intere, i 4 decoder che sono tutti semplici + microcodice... E poi questo "esperimento" potrebbe essere per il successore del geode per applicazioni embeeded o per un concorrente dell'ATOM...

[blackshard]

Originariamente inviato da papafoxtrot

Credo di aver capito.
Si può dire che siano gli algoritmi di brench prediction che non riescono a prevedere ciò che sarà da caricare in presenza di un salto condizionato o è proprio l'esecuzione del processo che si ferma nella pipeline e deve partire dall'inizio della pipeline una nuova esecuzione?
Voglio dire... le due cose sono collegate?
Comunque: ecco perché a informatica alle superiori dicevano sempre di evitare i salti condizionati!!
Ad ogni modo una pipeline più lunga dovrebbe soffrire maggiormente in questo caso, giusto? Per questo dark qui sopra diceva che la lunghezza delle pipeline rendeva possibile l'adozione dell'SMT? Possibile quindi in senso di "vantaggioso"??

Diciamo che l'algoritmo di branch prediction serve appunto a prevedere il branch prima che questo si verifichi, in modo da caricare la pipeline con le istruzioni giuste.
Essenzialmente ogni salto condizionato ha due scelte. Se l'algoritmo ha beccato quella giusta, allora la pipeline è già caricata con le istruzioni giuste e prosegue l'esecuzione come se nulla fosse successo. Se invece l'algoritmo di branch prediction ha sbagliato la predizione, nella pipeline ci sono istruzioni sbagliate che non vanno eseguite ma scaricate (flush) e lì si crea quella che viene chiamata "bolla".

Hyperthreading, almeno nella sua prima implementazione, "iniettava" nella bolla le istruzioni assegnate ad un altro processore, per fare in modo che le unità esecutive non rimanessero mai senza lavoro. Da questo punto di vista l'ht è vantaggioso per i Pentium 4 perchè la loro pipeline era molto lunga (20 stadi i Northwood e ben 31 stadi i Prescott). A sua volta, il vantaggio della pipeline lunga è che puoi salire maggiormente col clock, perchè ogni stadio della pipeline è più semplice e quindi impiega meno tempo per fare quello che deve fare, cioè eseguire l'istruzione. D'altro canto quando hai un branch miss, avendo un pipeline più lunga, devi aspettare più tempo affinchè le unità esecutive possano rimettersi di nuovo al lavoro, e quindi l'IPC diminuisce.

[dark.halo]

La questione dei moduli mi intriga parecchio però non vorrei che vada a finire col rallentare le prestazioni in singletreadh.
Nella mia fervida immaginazione vedo bulldozer come l'anello mancante tra i multicore classici e il cell.
Per caso si sa se AMD lancerà una evoluzione della tecnologia VT???
sarebbe fantastico assegnare un modulo ad ogni virtual machine

[papafoxtrot]

Grazie mille per la spiegazione, sia bjt che black.

[Pihippo]

Originariamente inviato da blackshard

Diciamo che l'algoritmo di branch prediction serve appunto a prevedere il branch prima che questo si verifichi, in modo da caricare la pipeline con le istruzioni giuste.
Essenzialmente ogni salto condizionato ha due scelte. Se l'algoritmo ha beccato quella giusta, allora la pipeline è già caricata con le istruzioni giuste e prosegue l'esecuzione come se nulla fosse successo. Se invece l'algoritmo di branch prediction ha sbagliato la predizione, nella pipeline ci sono istruzioni sbagliate che non vanno eseguite ma scaricate (flush) e lì si crea quella che viene chiamata "bolla".

Hyperthreading, almeno nella sua prima implementazione, "iniettava" nella bolla le istruzioni assegnate ad un altro processore, per fare in modo che le unità esecutive non rimanessero mai senza lavoro. Da questo punto di vista l'ht è vantaggioso per i Pentium 4 perchè la loro pipeline era molto lunga (20 stadi i Northwood e ben 31 stadi i Prescott). A sua volta, il vantaggio della pipeline lunga è che puoi salire maggiormente col clock, perchè ogni stadio della pipeline è più semplice e quindi impiega meno tempo per fare quello che deve fare, cioè eseguire l'istruzione. D'altro canto quando hai un branch miss, avendo un pipeline più lunga, devi aspettare più tempo affinchè le unità esecutive possano rimettersi di nuovo al lavoro, e quindi l'IPC diminuisce.

Ciao
Sebbene l'Hyperthreading serva a superare le bubbles che si formano in una pipeline, ad ex quado esegui(l'operazione dall'issue slot è passata negli stadi della pipeline) un add che richiede il risultato di un mul non ancora eseguito (errore di scheduling nel R.O.B ad esempio) oppure la pipeline è in stallo perchè gli operandi non sono disponibili (e nel caso di cache miss DMA verso la memoria), secondo me la cosa più pericolosa che diminuisce le performance è che anche il thread che dovrebbe sopperire ad uno stallo della pipeline , nei casi ad esempio descritti prima, si trova ad utilizzare le stesse risorse, ed in particolare gli stessi buffer e le stesse L\S unit. Ciò è male sopratutto nei casi in cui la cpu si trova a lavorare essenzialmente con la memoria, ad ex nei giochini quando la cpu spende essenzialmente buona parte del tempo a caricare operandi\vertici dalla ram centrale alla vram ed ad aggiornare la gpu sulla posizione dei vertici, quindi potenzialmente un casino di operazioni di load e di store, ma che per l'HT andranno ad essere esguite sulla metà delle risorse disponibili...

[blackshard]

Originariamente inviato da Pihippo

Ciao
Sebbene l'Hyperthreading serva a superare le bubbles che si formano in una pipeline, ad ex quado esegui(l'operazione dall'issue slot è passata negli stadi della pipeline) un add che richiede il risultato di un mul non ancora eseguito (errore di scheduling nel R.O.B ad esempio) oppure la pipeline è in stallo perchè gli operandi non sono disponibili (e nel caso di cache miss DMA verso la memoria), secondo me la cosa più pericolosa che diminuisce le performance è che anche il thread che dovrebbe sopperire ad uno stallo della pipeline , nei casi ad esempio descritti prima, si trova ad utilizzare le stesse risorse, ed in particolare gli stessi buffer e le stesse L\S unit. Ciò è male sopratutto nei casi in cui la cpu si trova a lavorare essenzialmente con la memoria, ad ex nei giochini quando la cpu spende essenzialmente buona parte del tempo a caricare operandi\vertici dalla ram centrale alla vram ed ad aggiornare la gpu sulla posizione dei vertici, quindi potenzialmente un casino di operazioni di load e di store, ma che per l'HT andranno ad essere esguite sulla metà delle risorse disponibili...

Si, poi è anche una questione di arbitraggio su quale "thread" viene mandato in esecuzione prima e dopo lo stallo. Insomma, in situazioni limite come quelle dei giochi, accade proprio che hyperthreading può fare qualche danno.

[Pihippo]

Originariamente inviato da blackshard

Si, poi è anche una questione di arbitraggio su quale "thread" viene mandato in esecuzione prima e dopo lo stallo. Insomma, in situazioni limite come quelle dei giochi, accade proprio che hyperthreading può fare qualche danno.

Ciao
Certo. Putroppo lo scheduler di windows, ed a quanto ne sappia io, di linux non hanno capacità discernente tra core logico, quindi con buffer, porte verso la chache registri L\S unit e chi più ne ha ne metta dimezzati, e core reali e dunque le performance un pò ballerine.
La cosa che un pò mi fa sorridere che in ambito server ed HPC dove i programmi sono avidi di cores, l'HT viene disabilitato nella maggioranza dei casi.
Un esempio applicazioni per HPC quindi con codici ricchi di operazioni in Floating point e dunque che necessitano di tonnellate di Bandwidth verso la memoria.
Ci sarebbe da ridere se il thread che interviene nel caso di stallo succhi risorse, super utilizzate, a gia core che di loro sono impegnati a combattere tra di loro negli accessi verso la memoria.....

[capitan_crasy]

Per una scoperta del tutto fortuita mi sono imbattuto nella lista "Hardware Components Supported" del programma HWiNFO32 e guardate cosa ho trovato:



AMD Family 10h (DR-Ax/Bx, RB-Cx, BL-Cx, DA-Cx, HY-Dx, PH-Ex):
- AM2r2/AM3: Athlon/Sempron (Lima, Sargas), Athlon II/Neo (Kuma, Regor, Rana, Propus), Phenom II/Neo (Agena, Deneb, Callisto, Heka, Toliman), TWKR Black Edition
- Fr2/Fr4: Opteron (Barcelona, Shanghai, Suzuka, Budapest, Istanbul)
- G34: Opteron 61xx (Magny Cours)
- S1g3/g4: Turion II/Ultra, Athlon II, Phenom II
- ASB2: Athlon II Neo K, Turion II Neo K
AMD Family 11h (LG-Ax/Bx): S1g2: Sempron SI/NI/X2, Athlon QI/QL (Sable), Turion X2 Ultra/RM (Griffin)
AMD Family 12h (FS1)
AMD Family 15h: Bulldozer

Bulldozer verrà classificato da AMDo come appartenente alla famiglia 15, quindi in teoria dovrebbe chiamarsi K15; se il programma supporta tale CPU significa che AMD ha già i primi prototipi di Bulldozer funzionanti!!!

Clicca qui...

[Alberello69]

Qualche giorno fa ho letto al notizia sulla disponibilitá nei prossimi mesi di cpu a 6 core su socket AM3, ci sono novitá invece sulla eventuale disponibilitá dell'architettura Buldozzer su questo socket?

[capitan_crasy]

Originariamente inviato da Alberello69

Qualche giorno fa ho letto al notizia sulla disponibilitá nei prossimi mesi di cpu a 6 core su socket AM3, ci sono novitá invece sulla eventuale disponibilitá dell'architettura Buldozzer su questo socket?

Da Roadmap AMD il core Zambezi sarà basato sul socket AM3; se sia uguale a quello attuale non lo si sa...

[dark.halo]

Originariamente inviato da capitan_crasy

Da Roadmap AMD il core Zambezi sarà basato sul socket AM3; se sia uguale a quello attuale non lo si sa...

Speriamo sia davvero così sarebbe un'ottima notizia

[capitan_crasy]

In una nuova brochure GlobalFoundries annuncia che nel Q1 2010 sarà in grato di produrre in volumi silicio con tecnologia "High K Metal Gate".

"Customer Product Introductions in Q1 2010:
GLOBALFOUNDRIES’ customers will begin to
announce HKMG product results in early 2010 - not
test chips, not 64M SRAMS, not IP shuttle results,
but full products. As with the 45/40nm ramp, this
will be far ahead of any other pure play foundry."

Ricordo che le CPU Bulldozer e Llano saranno costruite con tecnologia 32nm SOI e HKMG.

Clicca qui...

[Athlon 64 3000+]

Quindi significa che Buldozer non subirà ritardi e sta seguendo la roadmap prevista.

[capitan_crasy]

Originariamente inviato da Ratatosk

Perché ho il sospetto che non si riferiscano alle CPU?

Chiaramente non si sarà un anticipo sulle CPU AMD a 32nm, ma almeno non sono in ritardo; inoltre sulla slide dice che i primi sample saranno disponibili nel corso del 2010...


GLOBALFOUNDRIES supports a leader
in x86 CPU’s that ramps large complex high
performance die to drive low defect density with
high manufacturability and yields. Initial 32nm CPU
products will be sampling in 2010. The 32nm HKMG
ramp will precede the 28nm HKMG ramp of other
GLOBALFOUNDRIES customers by about one
quarter. Thus, the CPU leader provides a unique

[capitan_crasy]

Originariamente inviato da Ratatosk

Dice anche che i primi prodotti HKMG saranno sul mercato nel 2010, considerando che HKMG è stato riservato unicamente a processi 32nm o inferiori sai a cosa sto pensando, vero?

In arrivo il 32/28nm ATI?

[marco XP2400+]

HKMG si userebbe anche per le gpu?? io ero rimasto al semplice bulk e forse all'adozione del soi...