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

[Ares17]

Originariamente inviato da calabar

Secondo me il problema continua ad essere quello di cui avevamo parlato all'inizio di questa discussione:
inutile mettere a disposizione di un singolo thread il doppio delle pipeline int, perchè a causa delle dipendenze non è mai possibile sfruttarne più di tre o quattro insieme.

Le unità int attuali sono cioè già ben dimensionate per gestire un unico flusso, e per poter avere prestazioni superiori ci sono solo due strade:
- dividere questo "flusso" in due, ossia avere due thread distinti (e quindi lavorare sulla parallelizzazione del codice)
- lavorare su ciò che sta intorno alle unità int in maniera tale da sfruttarle al meglio (con decoder migliori, algoritmi di branch prediction migliori, occupazione delle pipeline tramite SMT, ecc...)

L'unico modo per aumentare l'ipc in mono th a parità di algoritmo di predizione è:
1 Avere pipeline veloci (freq elevate oppure pochi stadi ad alta capacità)
2 Ridurre i cicli di stallo delle pipeline in caso di predizione di salto errata (credo intorno al 30% delle predizioni totali).

[capitan_crasy]

Originariamente inviato da paolo.oliva2

Capitano... c'è una cosa che non mi è chiara.

Praticamente nell'intervista AMD riporta che hanno tralasciato Buldozer sul 45nm perché sarebbe stato meno competitivo, e modificato per sfruttare al meglio il 32nm perché con la riduzione di TDP avrebbe garantito più spazio per i core e FPU. By going for lower power, we hope to give you more room for compute cores, FP capabilities and more

Ora... c'è qualche cosa che non mi torna.
BD può contare su un'ottimizzazione migliore per quello che riguarda IPC/W.
Quindi, se fosse realizzato ancora sul 45nm, potrebbe garantire 8 core suppergiù al TDP del Thuban, ad essere pessimisti, diciamo 140W.
A questo si aggiunge il 32nm che a parità di potenza produrrebbe il 40-50% in meno di TDP.
Insomma... su questa base, un BD X8 a 3,2GHz sul 32nm dovrebbe essere dai 70W ai 94W...
Per arrivare ai 125W... c'è un margine pazzesco... dai 31W ai 55W.

Praticamente se un BD "lavorasse" a frequenze del Thuban avrebbe un margine tale nel TDP da poter garantire da un +40% a un + 80% dei core.

Riportando quello in neretto... possibile che AMD si fermi a solo 2 core in più? Mi suona strano che 800MHz di clock stock maggiore possano assorbire da soli 50W, quando un Thuban già sull'E0 45nm per i 4GHz X6 si ferma ad un TDP maggiore sotto i 30W, considerando poi pure il fatto che teorizzando 1GHz di Turbo, mi pare chiaro che il Vcore non può arrivare alle stelle...

Non sapremo mai come e perchè AMD abbia prima cancellato poi modificato il progetto Bulldozer a 45nm; tuttavia il primo annuncio della nuova architettura fu data sotto l'egemonia di RUIZ.
Quindi mi dispiace solo in parte che Bulldozer non si sia visto a 45nm, anche perchè intanto AMD ha modificato il suo assetto societario e certe cassate fatte con i 65nm devono restare solo un brutto ricordo (tremo solo all'idea di un fiasco costruttivo con un Bulldozer a 45nm stile K10 a 65nm)...

Originariamente inviato da Athlon

Il consumo di Bulldozer DEVE essere molto basso perche' non dobbiao dimenticare che a breve all' interno del Chip verra' integrata una scheda video completa e che al giorno d'oggi una scheda video assorbe anche 200W.

sicuramente in futuro i TDP delle CPU verranno alzati di molto perche' dovranno includere quello che e' oggi consumato da una schda video.

Sicuramente ci saranno un po' di ottimizzazioni dovute al fatto che la FPU tradizionale verra' eliminata e verranno usate le pipeline grafiche , pero' si tratta comunque di circa 200W che si aggiungono all' attuale TDP.

Non ci saranno mai GPU integrate con core X86 con quel TDP, sarebbe totalmente fuori mercato anche sul lato produttivo.
Guardando al futuro Llano saranno utilizzati GPU mainstream e non Top level; inoltre il passaggio dei core Bulldozer con core GPU verrà con tutta probabilità con i 22nm SOI quindi si avranno nuove GPU e nuovi parametri non confrontabili direttamente con le produzioni attuali...

Per come la vedo io con Fusion2 il TDP di una CPU viaggera' intorno ai 200-250W e nelle maniboard Gaming sara' possibile montare una seconda CPU per avere piu' potenza grafica


Questo vuol dire che OGGI l'architettura Buldozzer deve consumare veramente poco per potersi adattare in futuro a questa nuova e grande inclusione.


Personalmente ritengo che da parte di AMD non ci sarebbero problemi tecnicamente a proporre fin da subito un bulldozer 16x , pero' se si giocano subito tutte le carte poi si resta senza risorse

Fusion2 sarà l'ibrido tra i core X86 e le GPU, cioè un unico elemento dove le due tecnologie non saranno più distinguibili.
Ciò significa una sola frequenza, una sola cache e un solo TDP che sarà a livello di quelli attuali...

[bjt2]

Originariamente inviato da paolo.oliva2

Probabile.
Però non mi torna che un BD 32nm odierno possa avere il limite di 8 core per restare dentro i 125W.

Con un 50% in meno di TDP a parità di frequenza per il silicio e con un 10-20% a parità di architettura per le migliorie, un BD alle frequenze del Thuban (3,2GHz) dovrebbe consentire almeno un 65-80% in più di core del Thuban.
Thuban X6, BD X10-X11... X8 è un totale sotto...

Ti sei dimenticato l'area che occuperebbe e quindi il costo, dato anche il basso yield iniziale... Forse tra un anno, a processo 32nm maturo e sopratutto se il settore server richiederà più di 16 core per socket (attuale limite dell'MCM di 2 Bulldozer)...
Per ora un X8 a 4GHz stock lo vedo un sogno forse non così irrealizzabile...

[bjt2]

Originariamente inviato da capitan_crasy

Non sapremo mai come e perchè AMD abbia prima cancellato poi modificato il progetto Bulldozer a 45nm; tuttavia il primo annuncio della nuova architettura fu data sotto l'egemonia di RUIZ.
Quindi mi dispiace solo in parte che Bulldozer non si sia visto a 45nm, anche perchè intanto AMD ha modificato il suo assetto societario e certe cassate fatte con i 65nm devono restare solo un brutto ricordo (tremo solo all'idea di un fiasco costruttivo con un Bulldozer a 45nm stile K10 a 65nm)...



Non ci saranno mai GPU integrate con core X86 con quel TDP, sarebbe totalmente fuori mercato anche sul lato produttivo.
Guardando al futuro Llano saranno utilizzati GPU mainstream e non Top level; inoltre il passaggio dei core Bulldozer con core GPU verrà con tutta probabilità con i 22nm SOI quindi si avranno nuove GPU e nuovi parametri non confrontabili direttamente con le produzioni attuali...



Fusion2 sarà l'ibrido tra i core X86 e le GPU, cioè un unico elemento dove le due tecnologie non saranno più distinguibili.
Ciò significa una sola frequenza, una sola cache e un solo TDP che sarà a livello di quelli attuali...

Non necessariamente una sola frequenza... Già con questo bulldozer e date le code che separano i vari stadi non mi stupirei se ogni stadio (i due int core, la FPU, load/store/L2, L3 e controller e il feth/decode/dispatch/retire) abbiano frequenze diverse e indipendenti... E' forse per questo che JF-AMD ha la bocca cucita sul turbocore 2.0...

Anzi: avevo una mezza idea di suggerirlo a JF-AMD...

La mia idea era questa:
Ogni stadio in bulldozer è accoppiato al successivo tramite una coda e anche piuttosto generosa. Già nel K10 esistono dei contatori di prestazione che consentono di sapere l'occupazione media delle code interne e ritengo molto probabile che anche bulldozer le abbia. Posto che teoricamente ogni stadio può essere cloccato indipendentemente (sarebbe facile da implementare) e posto che esistano questi contatori di prestazioni, se non fosse implementato già in hardware io farei la seguente implementazione software (magari con AOD o K10-stat):

Per ogni stadio si monitorizza il riempimento medio della coda. Ogni tot millisecondi si calcola l'utilizzo medio delle code. Se la coda è vuota in media (esempio: occupazione sotto il 10-20%), allora scendi di un moltiplicatore il clock dello stadio a valle della coda, se non è già al minimo, impostabile per esempio da BIOS o come parametro ausiliario (es: FPU sottoutilizzata? Scendo il clock).
Se la coda è piena (es: utilizzazione sopra il 60-70%), se il budget di TDP e corrente dei VRM lo consente, se la temperatura è sotto un tot, se il moltiplicatore non è già al massimo consentito dal modello (o impostato nel BIOS a rischio e pericolo dell'utente per i modelli Black edition) allora sali di uno il moltiplicatore dello stadio a valle. Questo per tutti gli stadi che ho elencato sopra. Ogni tot millisecondi. E come parametri di configurazione ci sono le percentuali delle code: in modalità aggressiva, si possono mettere percentuali del tipo 10-50 per le due soglie. Così da avere le massime prestazioni in monothread. In modalità conservativa si possono mettere percentuali del tipo 20-80 per le due soglie, così da avere il miglior rapporto prestazioni/W in multicore, sacrificando un po' il monocore...

[Pihippo]

Originariamente inviato da Gigamez

Cut
Per quanto invece riguarda i vari algoritmi di predizione sarebbero tali e quali a quelli normalmente usati. Secondo me l'unico problema aggiuntivo come ho già detto in una logica di questo tipo sarebbe il far fronte alle dipendeze di flusso tra pacchetti..

Ciao.
Dunque è qusto il problema, dovresti ridisegnare tutti i predictors, come detto prima le dipendenze esistono anche tra dati non solo tra istruzioni dunque i predictors dovrebbero oltre che prevedere le diramazioni, prevedere che tutti e i due cores seguano la direzione giusta, metti caso che nelle istruzioni decodificate ed inviate al core B vi sia una branch che invalida tutto il codice nel core A. Che si farebbe?
Preciso che probabilmente ho scritto cazzate ma penso di aver reso il concetto.

[paolo.oliva2]

Originariamente inviato da bjt2

Ti sei dimenticato l'area che occuperebbe e quindi il costo, dato anche il basso yield iniziale... Forse tra un anno, a processo 32nm maturo e sopratutto se il settore server richiederà più di 16 core per socket (attuale limite dell'MCM di 2 Bulldozer)...
Per ora un X8 a 4GHz stock lo vedo un sogno forse non così irrealizzabile...

Si, si, certamente.
Ma la mia non era tanto un'idea all'uscita, perché tanto chi si ritroverebbe di fronte? SB X4 e i7 9XX X6.
In Monocore BD avrebbe almeno 1,2GHz in più...
In Multicore... con il doppio dei core rispetto ad un SB e con 2 core in più rispetto ad un i7 9XX, e su entrambi almeno 500MHz in più di clock def... basta ed avanza un X8.

Le cose cambieranno, al limite, verso la fine del 2012... con SB X8 e inizio 2013 con forse un X10 Intel... ma per quelle date è più che presumibile uno step ulteriore sul silicio, il low-k se non presente al debutto ci sarà sicuramente (anche perchè... nel 2013 dovrebbe subentrare il 22nm...), insomma, se ci sarà la necessità e spazio commerciale per un X10/X12, il TDP lo vedrei l'ultimo dei prb.

[Gigamez]

Originariamente inviato da Pihippo

Ciao.
Dunque è qusto il problema, dovresti ridisegnare tutti i predictors, come detto prima le dipendenze esistono anche tra dati non solo tra istruzioni dunque i predictors dovrebbero oltre che prevedere le diramazioni, prevedere che tutti e i due cores seguano la direzione giusta, metti caso che nelle istruzioni decodificate ed inviate al core B vi sia una branch che invalida tutto il codice nel core A. Che si farebbe?
Preciso che probabilmente ho scritto cazzate ma penso di aver reso il concetto.

Infatti: non devono esserci dipendenze di alcun genere ne' tra singole micro-ops "parallele" (come già è), ne' tra pacchetti su due rami diversi (cosa invece da aggiungere al possibile algoritmo di smistamento).

Quello che pero' riguarda l'ordine delle predizioni sui possibili risultati riguardanti cicli, controlli ecc.ecc. non cambierebbe rispetto ad ora in quanto il flusso di input ed il flusso di output a/dalle unità intere sarebbe il medesimo rispetto ad un processore classico. Il fallimento o il successo non dipenderrebbero in ogni caso dalla architettura, ma solamente dalla bontà dell'algoritmo.. sbaglio?

[dark.halo]

Originariamente inviato da bjt2

Non necessariamente una sola frequenza... Già con questo bulldozer e date le code che separano i vari stadi non mi stupirei se ogni stadio (i due int core, la FPU, load/store/L2, L3 e controller e il feth/decode/dispatch/retire) abbiano frequenze diverse e indipendenti... E' forse per questo che JF-AMD ha la bocca cucita sul turbocore 2.0...

Anzi: avevo una mezza idea di suggerirlo a JF-AMD...

La mia idea era questa:
Ogni stadio in bulldozer è accoppiato al successivo tramite una coda e anche piuttosto generosa. Già nel K10 esistono dei contatori di prestazione che consentono di sapere l'occupazione media delle code interne e ritengo molto probabile che anche bulldozer le abbia. Posto che teoricamente ogni stadio può essere cloccato indipendentemente (sarebbe facile da implementare) e posto che esistano questi contatori di prestazioni, se non fosse implementato già in hardware io farei la seguente implementazione software (magari con AOD o K10-stat):

Per ogni stadio si monitorizza il riempimento medio della coda. Ogni tot millisecondi si calcola l'utilizzo medio delle code. Se la coda è vuota in media (esempio: occupazione sotto il 10-20%), allora scendi di un moltiplicatore il clock dello stadio a valle della coda, se non è già al minimo, impostabile per esempio da BIOS o come parametro ausiliario (es: FPU sottoutilizzata? Scendo il clock).
Se la coda è piena (es: utilizzazione sopra il 60-70%), se il budget di TDP e corrente dei VRM lo consente, se la temperatura è sotto un tot, se il moltiplicatore non è già al massimo consentito dal modello (o impostato nel BIOS a rischio e pericolo dell'utente per i modelli Black edition) allora sali di uno il moltiplicatore dello stadio a valle. Questo per tutti gli stadi che ho elencato sopra. Ogni tot millisecondi. E come parametri di configurazione ci sono le percentuali delle code: in modalità aggressiva, si possono mettere percentuali del tipo 10-50 per le due soglie. Così da avere le massime prestazioni in monothread. In modalità conservativa si possono mettere percentuali del tipo 20-80 per le due soglie, così da avere il miglior rapporto prestazioni/W in multicore, sacrificando un po' il monocore...

qualcosa di simile non c'è anche in moorestrown/medfield ???

[Pihippo]

Originariamente inviato da Gigamez

Infatti: non devono esserci dipendenze di alcun genere ne' tra singole micro-ops "parallele" (come già è), ne' tra pacchetti su due rami diversi (cosa invece da aggiungere al possibile algoritmo di smistamento).

Quello che pero' riguarda l'ordine delle predizioni sui possibili risultati riguardanti cicli, controlli ecc.ecc. non cambierebbe rispetto ad ora in quanto il flusso di input ed il flusso di output a/dalle unità intere sarebbe il medesimo rispetto ad un processore classico. Il fallimento o il successo non dipenderrebbero in ogni caso dalla architettura, ma solamente dalla bontà dell'algoritmo.. sbaglio?

Ciao
Però permettimi di farti notare una cosa, il codice parallelo per eccellenza è quello di tipo vettoriale (quindi calcoli simd e fp) mentre quello x86-64 è molto seriale, quindi se si implementasse, un meccanismo di pachetti di dati paralleli, i vantaggi in campo int (escludendo vettori int) sarebbe basso. Cosa diversa invece se i due core su un modulo agissero in maniera concertata, ovvero core A esegue il codice, core b uno scout thread che esplora il codice, risolve le branch ecc ecc.

[affiu]

Originariamente inviato da paolo.oliva2

Si, si, certamente.
Ma la mia non era tanto un'idea all'uscita, perché tanto chi si ritroverebbe di fronte? SB X4 e i7 9XX X6.
In Monocore BD avrebbe almeno 1,2GHz in più...
In Multicore... con il doppio dei core rispetto ad un SB e con 2 core in più rispetto ad un i7 9XX, e su entrambi almeno 500MHz in più di clock def... basta ed avanza un X8.

Le cose cambieranno, al limite, verso la fine del 2012... con SB X8 e inizio 2013 con forse un X10 Intel... ma per quelle date è più che presumibile uno step ulteriore sul silicio, il low-k se non presente al debutto ci sarà sicuramente (anche perchè... nel 2013 dovrebbe subentrare il 22nm...), insomma, se ci sarà la necessità e spazio commerciale per un X10/X12, il TDP lo vedrei l'ultimo dei prb.

anche uno zambezi x8 concepito a 22 nm ed alla frequenza di un altro 1 giga hertz in piu sarebbe piu consono;in fondo piu si ''potrebbe'' accelerare bulldozer è meglio è, anche a 6 ghz a 22 nm(per questioni di fantasia,se forse gia non lo vedremo a 32nm) 8 core bulldozer si farebbero sentire lo stesso

in ogni caso ,dopo bulldozer 32nm, per i 22 nm si dovrebbe cominciare a delinearsi sempre più lo sposalizio finale ,tra i core 22 nm ed le gpu a 28 nm(vicine al 22)

ben presto anche bulldozer si allontanera dal senso di ''spoglio'' e solo;ripeterei sempre le stesse cose ,ma il fidanzamento forse lo vedremo a 22nm a cui seguiranno le nozze di questi ''promessi fusi''

ma APU family....è già una ineluttabile meta scritta;se dopo devo essere felice dovrei ammettere che 2/4 gpu piccoline a 16 nm ,con potenze simili ad esempio ad una 5870 non mi dispiacerebbero e tutto il frullato in una parola sola:

''all(il max di cpu e gpu) on the same die!''

[Gigamez]

Originariamente inviato da Pihippo

Ciao
Però permettimi di farti notare una cosa, il codice parallelo per eccellenza è quello di tipo vettoriale (quindi calcoli simd e fp) mentre quello x86-64 è molto seriale, quindi se si implementasse, un meccanismo di pachetti di dati paralleli, i vantaggi in campo int (escludendo vettori int) sarebbe basso. Cosa diversa invece se i due core su un modulo agissero in maniera concertata, ovvero core A esegue il codice, core b uno scout thread che esplora il codice, risolve le branch ecc ecc.

ragionando in termini di flusso di dati le unità fpu lavorano in superscalare, mentre una architettura ad unita' alternate lavorerebbe comunque con un flusso seriale, pur avendo appunto due unità..

[Pihippo]

Originariamente inviato da Gigamez

ragionando in termini di flusso di dati le unità fpu lavorano in superscalare, mentre una architettura ad unita' alternate lavorerebbe comunque con un flusso seriale, pur avendo appunto due unità..

Ciao
Scusami, non ti seguo, superscalari lo possono esse le fpu come le alu, a seconda dell'algoritmo che sta alla base dello scheduling della cpu.
Le fpu simd lavorano in genere su un flusso di dati del tipi x,y,z e su questi dati devono eseguire le operazioni.

[B|4KWH|T3]

Originariamente inviato da paolo.oliva2

Ma il discorso non riguardava o meno le librerie più ottimizzate... il discorso era incentrato sul fatto "IF not genuine cpu Intel Then...." che è ben altro.
Una cosa è che AMD utilizzi librerie fatte da Intel per CPU Intel, e qui certamente AMD non può obbligare Intel a ottimizzarle per proci AMD, un altro che le stesse librerie in caso di una CPU NON Intel, di proposito instaura loop assurdi e non ottimizzati, giustificati da Intel come "realizzati per assicurare una piena compatibilità"... . L'intento con cui è stato fatto, come ben sappiamo, è tutt'altro.
Infatti nessuno ha chiesto che Intel realizzasse qualche cosa ad hoc per AMD, ma solamente che Intel togliesse le discriminazioni.
Poi è chiaro che se andiamo a vedere la spiegazione ufficiale sul sito Intel, tutto scriveranno tranne che l'hanno fatto per far andare più piano la concorrenza e far apparire i propri proci più veloci.

Ma infatti la mia è una critica ad AMD che non si sveglia dal punto di vista software

[Gigamez]

Originariamente inviato da Pihippo

Ciao
Scusami, non ti seguo, superscalari lo possono esse le fpu come le alu, a seconda dell'algoritmo che sta alla base dello scheduling della cpu.
Le fpu simd lavorano in genere su un flusso di dati del tipi x,y,z e su questi dati devono eseguire le operazioni.

si, ma penso (magari mi sbaglio, ehh! XD) che nelle INT il flusso di macro ops (scomposte in micro-ops dal decoder e ricomposte in macro-risultati dalle retire) sia seriale (anche nella mia ipotesi), nella fpu questo livello è assente, quindi e' realmente superscalare anche a livello trasparente verso il programma, sia in input che in output, e non solo durante la fase computazionale..

Dimmi se sto sbagliando di brutto, come ho detto ipotizzo, ma sicuramente ne sai tu molto piu' di me!

[bjt2]

Originariamente inviato da dark.halo

qualcosa di simile non c'è anche in moorestrown/medfield ???

Non ne ho idea... Non seguo molto le architetture INTEL... Se hai qualche link però lo leggo con piacere...

[ban8]

ragazzi vorrei cambiare pc e passare ad un quad o al massimo a un six core..... secondo voi posso tranquillamente buttarmi su un 955 o al massimo su un 1050t, oppure è meglio aspettare i bulldozer (che se non ho capito male dovrebbero uscire verso primavera)? C sarà così tanta differenza d prestazioni ?
grazie in anticipo

[Fabiano 82]

con il sistema che hai in firma, potresti tranquillamente ( a meno di esigenze particolari) aspettare bulldozer, che dovrebbe uscire verso l'estate se non sbaglio(anche se non ci sono conferme)

[Heimdallr]

Beh dipende ovviamente se puoi aspettare, BD dovrebbe scire in primavera per cui l'uscita è vicina in termini 'informatici' ma aspettare 6 mesi o più per cambiare pc se ne hai bisogno è un tempo parecchio lungo imho.

[ban8]

In caso d cambio una configurazione del genere sarebbe ottimale ?

AMD AM3 Phenom II X4 955 Bl.Ed. Box - C3- 3,2GHz - 8MB Cache - 125W € 120
Gigabyte GA-890GPA-UD3H (890GX,AM3,ATX,DDR3,VGA,AMD) € 105,50
Kingston DDR3 4GB 1333Mhz HyperX KIT (2x2) CL7 XMP (KHX1333C7D3K2/4GX) € 89,00
CORSAIR 550W CMPSU-550VXEU € 64,00

o sarebbe meglio andare sul
AMD PHENOM II X6 1055T Soket AM3 2,8GHz - 9MB Cache - 125W Box 157,00 €
pensando anche al futuro

calcolando che prevalentemente gioco (la vga resterebbe qualla in firma)

[Heimdallr]

va bene l'X4 per giocare, chiudiamo l'OT comunque, se ti servono consigli ti conviene aprire un topic a parte