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

[Pihippo]

Originariamente inviato da milanok82

Scusami se mi intrometto,ma tu sai qualcosa e non puoi dirlo per l'NDA?
solo cosi per curiosità volevo saperlo...

Ciao
No, non so assolutamente nulla.

[paolo.oliva2]

Originariamente inviato da Gigamez

uhm.. un ipotetico fusion FX da 24 core su singolo socket per desktop.. con anche reverse Hyperthreading!.. uhm.. Secondo me qui siamo ben oltre la fantascienza applicata all'informatica!

A meno che non si parli di qualche rumor riferito a qualcosa come 2015 o giu' di li'.. il che comunque avrebbe a mio parere oggi come oggi credibilità pari a zero

Scusa Paolo, ma secondo me e' una sparata, nulla di piu'!

Ma anche io ho scritto se era una bufala... (mi hai quotato prima che l'aggiungessi )

A parte il fatto che una cosa del genere... altro che 1000€ dell'i980X , non farebbe per me.

Aspettiamo se rumorizano sopra... A me quello che mi garberebbe è quei 12 core a 4GHz, perché se così fosse, altro che X8 a 3,5GHz

BD + APU dovrebbe essere proposto nel 2015 con il 22nm, il che porterebbe ad una ulteriore diminuzione del TDP.

Però, guarda che non sarebbe assurdo sul 22nm.
Conta questo: BD X8 a 95W, già nel 2012 ci potrebbe essere un BD X10 sempre a 95W (discorso X10 a parità di TDP di un X8 previsto da AMD). Con il passaggio al 22nm... potrebbe essere auspicabile magari portarlo sui 65W.
Una discreta di una certa potenza oggi è sui 175W TDP ma sul 40nm bulk. Tra passaggio al 32nm e ulteriore 22nm, + l'HKMG e ULK, forse forse potrebbe arrivare a un TDP della metà inferiore?
Insomma, mica sarebbe tanto distante il tutto da 125W TDP...
Inoltre un FX di questo tipo, garantirebbe un guadagno maggiore che un BD "normale" ed una VGA discreta, anche con prezzi di 700-800€

[Gigamez]

Originariamente inviato da Pihippo

Ciao
Tutto il fornte end con le sorpese più belle sono sotto NDA, mi dispiace
Edit:
Comunque posso dire che una branch mispredict ha una penalty di circa il 50%(worst case 90\100%) superiore nel k15 (bd) che in k12(llano) e k10.
Un pò di conti però sono stati fatti.

pihippo, ma scusa se e' superiore del 50% (che e' tantissimo!) o hanno rivisto gli algoritmi in maniera pesantissima (da quello che so quelli del k10 sulle predictions erano pessimi, sbaglio?), oppure sara' letteralmente un "bagno di sangue", con stalli infiniti e continue richieste di accesso a memoria.. O_o"

magari sto ipotizzando stupidate, eh..

[Pihippo]

Originariamente inviato da Gigamez

pihippo, ma scusa se e' superiore del 50% (che e' tantissimo!) o hanno rivisto gli algoritmi in maniera pesantissima (da quello che so quelli del k10 sulle predictions erano pessimi, sbaglio?), oppure sara' letteralmente un "bagno di sangue", con stalli infiniti e continue richieste di accesso a memoria.. O_o"

magari sto ipotizzando stupidate, eh..

Ciao
Quelli del k10 non erano malaccio, quelli intel erano un miglio di distanza comunque. La penalità è alta. Molto alta. Il problema è che a meno di qualche trucchetto, ogni misspredict si stalla tutto il front end per un ciclo e si flusha via tutto il lavoro già fatto, quindi tanto lavoro per nulla che in una architettura come Bd vuol dire tanto lavoro perso (ed energia consumata ad muzzum) Ma ancora il front end è sotto nda, non si sa se il trucco c'è o meno. Chi lo sà.

[paolo.oliva2]

Originariamente inviato da Pihippo

Ciao
Quelli del k10 non erano malaccio, quelli intel erano un miglio di distanza comunque. La penalità è alta. Molto alta. Il problema è che a meno di qualche trucchetto, ogni misspredict si stalla tutto il front end per un ciclo e si flusha via tutto il lavoro già fatto, quindi tanto lavoro per nulla che in una architettura come Bd vuol dire tanto lavoro perso (ed energia consumata ad muzzum) Ma ancora il front end è sotto nda, non si sa se il trucco c'è o meno. Chi lo sà.

Io avevo sentito di una cosa, ma non so spiegarti le parole tecniche, ma da quello che ho capito, c'era una specie di puntatore nelle pipeline che in caso di errore non portava allo svuotamento e rimpiazzamento della pipeline, ma riduceva il tutto a 1-2 cicli di clock a vuoto...

Bjt2 penso che l'abbia letto, perché c'erano degli schemi classici di tracciato, quelli a quadrati e rombi.

Scusa la figura di m.... ma di più non ti so dire.

[Gigamez]

Originariamente inviato da Pihippo

Ciao
Quelli del k10 non erano malaccio, quelli intel erano un miglio di distanza comunque. La penalità è alta. Molto alta. Il problema è che a meno di qualche trucchetto, ogni misspredict si stalla tutto il front end per un ciclo e si flusha via tutto il lavoro già fatto, quindi tanto lavoro per nulla che in una architettura come Bd vuol dire tanto lavoro perso (ed energia consumata ad muzzum) Ma ancora il front end è sotto nda, non si sa se il trucco c'è o meno. Chi lo sà.

Una penalità del genere sarebbe accettabile solamente a fronte di algoritmi molto piu' raffinati! Dai, se non fosse cosi' a cosa servirebbe fare una architettura cosi' evoluta per poi non essere in grado di sfruttarla?

Scusa se ti chiedo "da ignorante quale sono".. per "front-end" intendi una parte dello scheduler, vero?
Secondo te (parere del tutto personale) quale potrebbe essere un modo per far fronte ad un pericolo realmente cosi' grande?

A leggere certe cose mi ritorna in mente la mia ipotesi sul modulo usato per processare un singolo thread in maniera alternata sui due cores.. Potrebbe essere un'ipotesi a tuo parere per spiegare un penality del 50% superiore
(proprio perche' comprometterebbe un flusso sdoppiato di calcoli)?

Non so perche', ma io rimango sempre convinto della "megasorpresona" in questo senso!

speriamo in qualcosa di simile!

[Pihippo]

Originariamente inviato da paolo.oliva2

Io avevo sentito di una cosa, ma non so spiegarti le parole tecniche, ma da quello che ho capito, c'era una specie di puntatore nelle pipeline che in caso di errore non portava allo svuotamento e rimpiazzamento della pipeline, ma riduceva il tutto a 1-2 cicli di clock a vuoto...

Bjt2 penso che l'abbia letto, perché c'erano degli schemi classici di tracciato, quelli a quadrati e rombi.

Scusa la figura di m.... ma di più non ti so dire.

Ciao Paolo
E di che? Manco io so di cosa sto parlando

Originariamente inviato da Gigamez

Una penalità del genere sarebbe accettabile solamente a fronte di algoritmi molto piu' raffinati! Dai, se non fosse cosi' a cosa servirebbe fare una architettura cosi' evoluta per poi non essere in grado di sfruttarla?

Scusa se ti chiedo "da ignorante quale sono".. per "front-end" intendi una parte dello scheduler, vero?
Secondo te (parere del tutto personale) quale potrebbe essere un modo per far fronte ad un pericolo realmente cosi' grande?

A leggere certe cose mi ritorna in mente la mia ipotesi sul modulo usato per processare un singolo thread in maniera alternata sui due cores.. Potrebbe essere un'ipotesi a tuo parere per spiegare un penality del 50% superiore
(proprio perche' comprometterebbe un flusso sdoppiato di calcoli)?

Non so perche', ma io rimango sempre convinto della "megasorpresona" in questo senso!

speriamo in qualcosa di simile!

Ciao
Dunque il Front end è la parte "iniziale" di ogni processore. Ovvero è quella parte logica che si occupa di trovare le istruzioni x86 in una cache L1 I (instruction) o se non trova nulla la (e nei successivi livelli di cache) a inizializzare una richiesta alla mem centrale per trovare quello che gli serve.
In particolare in front end prende 32 bytes di questa L1 I e, per chiarire, possiamo fare questo esempio di una fabbrica: In questi 32 bytes ci sono scritte le istruzioni che deve eseguire la fabbrica per poter fabbricare , ma sono scritte in un dialetto dell' ostrogoto antico medio orientale (x86) mentre la fabbrica con i suoi operai specializzati (execution unit) capi reparto (scheduler) e capi logistica (load store unit) parlano solo l'itaGLiano. Quindi una porzione del front end (decoders) traducono questa lingua incomprensibile in itaGLiano. Succede però che le istruzioni contengano dei "ramificazioni" (ad esempio i famosissimi if, then, else) sul come fabbricare (branch del codice che indirizzano ad altri punti della memoria dove reperire quello che ci serve). Quindi la fabbrica grazie alla sua Branch prediction unit (bpu) tenta di capire se vale la pena seguire questa parte nuova di istruzioni oppure non seguire questa ramificazioni e continuiare a decodificare e processare.
Spero di aver capito anche io cosa ho scritto.
Il metodo per evitare ste penalità ci potrebbe essere. Io attualmente non lo so però

[Bingo Bongo]

Originariamente inviato da Pihippo

Ciao Paolo
E di che? Manco io so di cosa sto parlando

Originariamente inviato da Pihippo

Il metodo per evitare ste penalità ci potrebbe essere. Io attualmente non lo so però

[cionci]

E' possibile che faccia un flush solo delle istruzioni relative al thread che è andato in stallo ? Perché se dovesse farlo di entrambi sarebbe davvero un bagno di sangue.
In teoria sarebbe anche possibile marcare il branch. Cioè decodificare un certo numero di istruzioni del branch non scelto dal branch predictor (il numero ottimale sarebbe pari al numero di stage che ci sono prima del reorder buffer) e lasciarle in stallo nel reorder buffer. In caso di misprediction bisognerebbe fare il flush in tutti gli stadi del branch di quel dato thread, ma subito dopo sarebbe pronto un numero di istruzioni esiguo per continuare l'esecuzione, quasi, a piena efficienza. Chiaramente per branch multipli credo che la cosa sarebbe non solo complicata, ma ovviamente realizzabile solo fino ad un prefissato livello di profondità (anche un solo livello di profondità imho sarebbe accettabile).

[Gigamez]

Originariamente inviato da Pihippo

Ciao
Dunque il Front end è la parte "iniziale" di ogni processore. Ovvero è quella parte logica che si occupa di trovare le istruzioni x86 in una cache L1 I (instruction) o se non trova nulla la (e nei successivi livelli di cache) a inizializzare una richiesta alla mem centrale per trovare quello che gli serve.
In particolare in front end prende 32 bytes di questa L1 I e, per chiarire, possiamo fare questo esempio di una fabbrica: In questi 32 bytes ci sono scritte le istruzioni che deve eseguire la fabbrica per poter fabbricare , ma sono scritte in un dialetto dell' ostrogoto antico medio orientale (x86) mentre la fabbrica con i suoi operai specializzati (execution unit) capi reparto (scheduler) e capi logistica (load store unit) parlano solo l'itaGLiano. Quindi una porzione del front end (decoders) traducono questa lingua incomprensibile in itaGLiano. Succede però che le istruzioni contengano dei "ramificazioni" (ad esempio i famosissimi if, then, else) sul come fabbricare (branch del codice che indirizzano ad altri punti della memoria dove reperire quello che ci serve). Quindi la fabbrica grazie alla sua Branch prediction unit (bpu) tenta di capire se vale la pena seguire questa parte nuova di istruzioni oppure non seguire questa ramificazioni e continuiare a decodificare e processare.
Spero di aver capito anche io cosa ho scritto.
Il metodo per evitare ste penalità ci potrebbe essere. Io attualmente non lo so però

ok, quindi in pratica sarebbe la "sezione" tra il fetcher ed i decoders!
Te lo chiedevo in quanto ipotizzavo che in caso di branch miss potessero esseci problemi sugli schedulers, e pensavo appunto che con quel termine ti riferissi proprio a loro ^_^

comunque grazie per la spiegazione e per la disponibilità!

Originariamente inviato da cionci

E' possibile che faccia un flush solo delle istruzioni relative al thread che è andato in stallo ? Perché se dovesse farlo di entrambi sarebbe davvero un bagno di sangue.
In teoria sarebbe anche possibile marcare il branch. Cioè decodificare un certo numero di istruzioni del branch non scelto dal branch predictor (il numero ottimale sarebbe pari al numero di stage che ci sono prima del reorder buffer) e lasciarle in stallo nel reorder buffer. In caso di misprediction bisognerebbe fare il flush in tutti gli stadi del branch di quel dato thread, ma subito dopo sarebbe pronto un numero di istruzioni esiguo per continuare l'esecuzione, quasi, a piena efficienza. Chiaramente per branch multipli credo che la cosa sarebbe non solo complicata, ma ovviamente realizzabile solo fino ad un prefissato livello di profondità (anche un solo livello di profondità imho sarebbe accettabile).

ma per "marcare" intendi andare a flaggare i branch relativi al singolo thread in modo da flushare solo loro in caso di miss-prediction, oppure intendi proprio andare a risolvere anche le operazioni al di fuori del branch?
No, perchè, dall'alto della mia ignoranza, Immagino che se si eseguissero anche le istruzioni non scelte dal branch predictor si farebbero calcoli inutili in ogni caso (aumentando consumi e tdp), sbaglio?
Se cosi' fosse sarebbe una strada a dir poco inefficiente oltre che macchinosa e di difficile implementazione. Si ipotizzava qualche tempo fa di un ipotetico utilizzo del secondo core in modulo (in caso di single-th) appunto per questi scopi di predizione.. ma sincerametne io ci credo davvero poco.
Nella tua ipotesi, poi, non credi che anche il reorder-buffer dovrebbe essere piu' grande rischiando di essere meno efficiente?

L'esame di architettura degli elaboratori l'ho dato vari anni fa, ormai.. :S Se ho detto castronerie fatemelo notare senza problemi!

[capitan_crasy]

Non è una cosa ancora sicura ma sembra che AMD potrebbe mostrare per la prima volta la piattaforma "Scorpius" con CPU 8 core Bulldozer al Cebit 2011 la quale si terrà dal 1 al 5 marzo a Hanover esattamente un anno dopo aver mostrato in anteprima la piattaforma LEO.
Non è una cosa certa ma soltanto una voce, quindi da prendere con le dovute cautele.

[Athlon 64 3000+]

http://www.donanimhaber.com/islemci/...0tan-hizli.htm

Leggete e fatevi quattro risate,la fonte non sembra arrivare fa fudzilla.
Dicono che Llano dual core e quad core saranno più lenti del Athlon II 250 e Athlon II 640 rispettivamente.

[abbate]

[checo]

Originariamente inviato da paolo.oliva2

L'avete letto questa?

AMD FusionFX 12,16,24 core CPUs

FusionFX

But the really exciting thing is the platform to come shorty after. It will be called AMD FusionFX. There will be single and dual socket configurations. On the single socket side there will a desktop performance APU with up to 24 cores. Translate… equal to 12 core CPU at 4Ghz. On the dual socket side there will be 12,16 and 24 cores times TWO. Wow 48 cores! But forget cores. Think massively multi-threaded CPUs…. and with a sort of reverse hyper-threading. Operating systems that don’t recognize or use 16,24 or 48 individual CPUs will not be crippled. Again… get rid of the idea of cores.

AMD has some huge things planned for OpenCL. OpenCL will allow AMD Fusion Platforms to use all of the available computational power such as a 48 core APU combined with high end Graphics cards. So in essence we could have a 48 core 3D graphics workstation with four ATI Radeon HD7900 video cards all working at at 100% to render a scene 50 times faster that the fastest quad-core desktop today. It’s all going to be modular and expandable.

QUI

E' una bufala? E' troppo di troppo, di tutto di più.

fantainformatica credo!!

cmq su toms è uscita una rece di una mobo minitx con zacate

[Gio_87]

non so se è old....
http://www.tomshw.it/cont/articolo/r...e/29023/1.html

[gi0v3]

Originariamente inviato da Athlon 64 3000+

http://www.donanimhaber.com/islemci/...0tan-hizli.htm

Leggete e fatevi quattro risate,la fonte non sembra arrivare fa fudzilla.
Dicono che Llano dual core e quad core saranno più lenti del Athlon II 250 e Athlon II 640 rispettivamente.

come sempre non parlano di frequenze, quindi potrei stampare l'articolo e pulirmici

[capitan_crasy]

edit

[paolo.oliva2]

Volevo intavolare un discorso... perché non riesco a trovare spiegazioni logiche.

Senza polemica, partirei da presupposti positivi per SB in clock, e nagativi in IPC per BD.

SB 130W X4 4,2-4,3GHz.
BD -15% di IPC nei confronti di SB.

Ora, per non incasinare il discorso, lasciamo a parte il turbo.

Quindi un BD, per quanto scritto sopra, dovrebbe avere un clock del 15% superiore a SB, quindi dovrebbe essere sui 4,850-5GHz, per pareggiare.

Mi sembra natura che AMD, dovendo rifare l'immagine, sarebbe forzata a commercializzare un BD ALMENO che possa avere le stesse prestazioni di un SB.

In tutto questo qualche cosa non torna e non è al suo posto.
Non è un discorso che AMD SICURAMENTE deve superare SB, ma è un discorso logico per l'incomprensibilità di AMD di impostare un TDP max di 95W per X4 e X6.

Ammesso per ipotesi che un BD a 95W possa arrivare a 4,8-5GHz ed equivalere ad un SB, perché fermarsi ad una parità e non superarlo disponendo di 30W TDP ulteriori?

Inoltre... non mi tornano i conti con le tensioni.

45nm low-k (1100T). La tensione dichiarata da AMD è 1V-1,3V per 125W, il turbo necessita di 1,45V circa per i 3,7GHz.

Per il 32nm AMD riporta 0,8V-1,3V, ma 1,3V sono il massimo per il funzionamento del procio a frequenza stock, oppure è per il turbo?

In ogni caso... con 1,3V il 45nm arriva a 3,3GHz, il 32nm non può con la stessa tensione fermarsi alla stessa frequenza di un 45nm.

E non dimentichiamoci che AMD ha dichiarato il range di tensione, probabilmente sui 125W TDP, non sui 95W.

Insomma, ai miei dubbi sopra, dalla parte SB al limite si potrebbe pensare a clock stock per 130W senza APU un attimo più bassi, ma per quanto li possiamo considerare inferiori, la differenza sarebbe minima.
Quindi... o BD ha un IPC superiore al -15% su SB ipotizzato, o per i 95W TDP le frequenze dovrebbero essere sui 5GHz, oppure un mix di entrambe le cose, magari un -5% di IPC e 4,5GHz stock.

[paolo.oliva2]

Volevo intavolare un discorso... perché non riesco a trovare spiegazioni logiche.

Senza polemica, partirei da presupposti positivi per SB in clock, e nagativi in IPC per BD.

SB 130W X4 4,2-4,3GHz.
BD -15% di IPC nei confronti di SB.

Ora, per non incasinare il discorso, lasciamo a parte il turbo.
Quindi un BD, per quanto scritto sopra, dovrebbe avere un clock del 15% superiore a SB, quindi dovrebbe essere sui 4,850-5GHz, per pareggiare.
Mi sembra natura che AMD, dovendo rifare l'immagine, sarebbe forzata a commercializzare un BD ALMENO che possa avere le stesse prestazioni di un SB.
In tutto questo qualche cosa non torna e non è al suo posto.
Non è un discorso che AMD SICURAMENTE deve superare SB, ma è un discorso logico per l'incomprensibilità di AMD di impostare un TDP max di 95W per X4 e X6.
Ammesso per ipotesi che un BD a 95W possa arrivare a 4,8-5GHz ed equivalere ad un SB, perché fermarsi ad una parità e non superarlo disponendo di 30W TDP ulteriori?

Inoltre... non mi tornano i conti con le tensioni.
45nm low-k (1100T). La tensione dichiarata da AMD è 1V-1,3V per 125W, il turbo necessita di 1,45V circa per i 3,7GHz.
Per il 32nm AMD riporta 0,8V-1,3V, ma 1,3V sono il massimo per il funzionamento del procio a frequenza stock, oppure è per il turbo?

In ogni caso... con 1,3V il 45nm arriva a 3,3GHz, il 32nm non può con la stessa tensione fermarsi alla stessa frequenza di un 45nm.

E non dimentichiamoci che AMD ha dichiarato il range di tensione, probabilmente sui 125W TDP, non sui 95W.

Insomma, ai miei dubbi sopra, dalla parte SB al limite si potrebbe pensare a clock stock per 130W senza APU un attimo più bassi, ma per quanto li possiamo considerare inferiori, la differenza sarebbe minima.
Quindi... o BD ha un IPC superiore al -15% su SB ipotizzato, o per i 95W TDP le frequenze dovrebbero essere sui 5GHz, oppure un mix di entrambe le cose, magari un -5% di IPC e 4,5GHz stock.

[paolo.oliva2]

Volevo intavolare un discorso... perché non riesco a trovare spiegazioni logiche.

Senza polemica, partirei da presupposti positivi per SB in clock, e nagativi in IPC per BD.

SB 130W X4 4,2-4,3GHz.
BD -15% di IPC nei confronti di SB.

Ora, per non incasinare il discorso, lasciamo a parte il turbo.
Quindi un BD, per quanto scritto sopra, dovrebbe avere un clock del 15% superiore a SB, quindi dovrebbe essere sui 4,850-5GHz, per pareggiare.
Mi sembra natura che AMD, dovendo rifare l'immagine, sarebbe forzata a commercializzare un BD ALMENO che possa avere le stesse prestazioni di un SB.
In tutto questo qualche cosa non torna e non è al suo posto.
Non è un discorso che AMD SICURAMENTE deve superare SB, ma è un discorso logico per l'incomprensibilità di AMD di impostare un TDP max di 95W per X4 e X6.
Ammesso per ipotesi che un BD a 95W possa arrivare a 4,8-5GHz ed equivalere ad un SB, perché fermarsi ad una parità e non superarlo disponendo di 30W TDP ulteriori?

Inoltre... non mi tornano i conti con le tensioni.
45nm low-k (1100T). La tensione dichiarata da AMD è 1V-1,3V per 125W, il turbo necessita di 1,45V circa per i 3,7GHz (ma questa tensione non figura nel Vcore stock, ma la si può ritrovare nel Vcore supportato).
Per il 32nm AMD riporta 0,8V-1,3V, ma 1,3V sono il massimo per il funzionamento del procio a frequenza stock, oppure è riferita al turbo e tensione massima supportata?

In ogni caso... con 1,3V il 45nm arriva a 3,3GHz, il 32nm non può con la stessa tensione fermarsi alla stessa frequenza di un 45nm.

E non dimentichiamoci che AMD ha dichiarato il range di tensione, probabilmente sui 125W TDP, non sui 95W.

Insomma, ai miei dubbi sopra, dalla parte SB al limite si potrebbe pensare a clock stock per 130W senza APU un attimo più bassi, ma per quanto li possiamo considerare inferiori, la differenza sarebbe minima.
Quindi... o BD ha un IPC superiore al -15% su SB ipotizzato, o per i 95W TDP le frequenze dovrebbero essere sui 5GHz, oppure un mix di entrambe le cose, magari un -5% di IPC e 4,5GHz stock.