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

[Lan_Di]

Originariamente inviato da capitan_crasy

Scusate se interrompo un pò questa discussione su Bulldozer, ma vorrei attirare l'attenzione un secondo sui core X86 di Llano...
Non posto neanche le voci che sento, ma sono comunque (per lo più) ottimistiche.
Finora sappiamo che si tratta di architettura K10 (anche se i cialtroni di FUDZILLA la considera un K8 super potente); dovrebbe avere 1MB di cache L2, la L3 sarà assente mentre si parla di una possibile introduzione delle istruzioni AVX (non che quelle delle SSE 4.1/4.2).
Se la vedrà con gli SB più economici e anche se la GPU integrata di Llano sarà nettamente più potente, rimane l'incognita di quanto perderà in prestazioni sui core X86...

A quanto è stimata la potenza della GPU?
Ho letto in un articolo che la gpu integrata nei sample Sandy Bridge supera la ati HD5450, che non mi sembra poco.

[capitan_crasy]

Originariamente inviato da Lan_Di

A quanto è stimata la potenza della GPU?
Ho letto in un articolo che la gpu integrata nei sample Sandy Bridge supera la ati HD5450, che non mi sembra poco.

Ovviamente mancano ancora i numeri ufficiali ma le ultime voci davano alla GPU di Llano un massimo di 480SP, cioè molto vicina alla 5670...

[bicchiere]

Originariamente inviato da capitan_crasy

Ovviamente mancano ancora i numeri ufficiali ma le ultime voci davano alla GPU di Llano un massimo di 480SP, cioè molto vicina alla 5670...

Io ad esempio volevo sapere se LLano sarà ufficialmente supportato in Linux da AMD.

[capitan_crasy]

Originariamente inviato da bicchiere

Io ad esempio volevo sapere se LLano sarà ufficialmente supportato in Linux da AMD.

Non vedo perchè no...
Inoltre AMD sta lavorando per i catalyst "open source" dove ha già rilasciato una parte del codice sorgente dei suoi driver...

[Lan_Di]

davvero niente male, oltre a poter sfruttare l'accelerazione video per filmati ed eventuali applicazioni opencl, permetterà di giocare tranquillamente in HD-ready. Lo vedo come il modo ideale per farmi un bel sistemino mini-itx da affiancare al plasma in salotto

[calabar]

Originariamente inviato da cionci

Secondo me sono proprio in concorrenza. SMT non è un modo più efficiente di accedere alle unità, perché senza SMT solo un thread può accedere alle unità. SMT è trovare negli stage della pipeline istruzioni che provengono da più thread, se questo permetta o meno di ottenere maggiore efficienza è solo un importante side effect (che ovviamente sarà l'obiettivo della fase di progetto).

Correggetemi se sbaglio, però mi pare che SMT sia proprio un modo per sfruttare meglio la pipeline in caso di stallo.
Anche in un core normale senza SMT possiamo trovare più thread nei diversi stadi della pipeline.. altrimenti a che servirebbe la pipeline?
Con SMT ho in pratica il vantaggio di poter avere sempre un thread pronto da inserire, ma la pipeline è una, e quindi in un dato stadio di questa, solo un thread potrà esistere.
In quella che io chiamo divisione, invece, in uno stesso stadio potranno esserci più thread in contemporanea, senza concorrenza, come se le FP fossero due.

Per quanto riguarda il numero di istruzioni processabili, è stato JF (o qualcuno da AMD) a dichiarare 1xAVX, 2x128bit o 4x64bit, quindi fino a prova contraria per lo meno dovrebbe gestirne fino a 4.

Grazie (anche a Pihippo) per la spiegazione sulla parte condivisa (non ho tempo ora di leggere tutti i documenti e sono comunque meno ferrato di voi sull'argomento).
Da vedere comunque se ere quanto la parte di fetch e decodin possa costituire un collo di bottiglia: se adeguatamente potenziata poco importa che sia in comune, se poi è sovrabbondante per gestire i due core.
L'importante è che una volta avviati possano processare le operazioni senza concorrenza.

PS: ovviamente se ho detto castronerie sentitevi liberi di correggermi!

[cionci]

Originariamente inviato da calabar

Anche in un core normale senza SMT possiamo trovare più thread nei diversi stadi della pipeline.. altrimenti a che servirebbe la pipeline?

No, un core normale opera solo su un thread per core.
La pipeline serve per ridurre il critical path spezzettando ogni istruzione in operazioni più semplici e di conseguenza poter salire in frequenza.

[cionci]

Originariamente inviato da calabar

Per quanto riguarda il numero di istruzioni processabili, è stato JF (o qualcuno da AMD) a dichiarare 1xAVX, 2x128bit o 4x64bit, quindi fino a prova contraria per lo meno dovrebbe gestirne fino a 4.

Era chiaro che mi riferivo a quelle a 128 bit.
A parte le AVX, è esattamente la stessa quantità su cui può lavorare la FPU del K10: http://www.insidehw.com/Editorials/C...hitecture.html

[calabar]

Originariamente inviato da cionci

No, un core normale opera solo su un thread per core.
La pipeline serve per ridurre il critical path spezzettando ogni istruzione in operazioni più semplici e di conseguenza poter salire in frequenza.

Forse confondo thread con istruzione?

Ossia... la pipeline serve certo ad aumentare il clock, ma anche a gestire contemporaneamente più istruzioni.

Se per esempio ho una pipeline a n stadi, appena l'istruzione 1 libera lo stadio 1 della pipeline e passa allo stadio 2, lo stadio 1 è libero di eseguire l'istruzione 2.
Quindi, in un mondo ideale in cui la pipeline è sempre piena, posso trovare nella pipeline fino a n istruzioni in diversi stadi di processazione.

Originariamente inviato da cionci

Era chiaro che mi riferivo a quelle a 128 bit.
A parte le AVX, è esattamente la stessa quantità su cui può lavorare la FPU del K10: http://www.insidehw.com/Editorials/C...hitecture.html

Ah, ok, allora è chiaro, massimo possono essere 2 a 128 bit.
Mi pareva però che in questo fosse superiore al K10, dato che il k10 non ha la possibilità di eseguire codice a 256bit, e si parlava di un raddoppio di potenza dell'unità FP, avevo supposto che il k10 avesse due unità a 64 bit utilizzabili coem una da 128, funzionanti cioè con lo stesso approccio ma scalate di una potenza di 2 come dimensione.

Da cosa deriva allora l'idea che la FP si BD sia piu potente, come affermato più volte qui sul forum?

[Athlon 64 3000+]

Originariamente inviato da capitan_crasy

Scusate se interrompo un pò questa discussione su Bulldozer, ma vorrei attirare l'attenzione un secondo sui core X86 di Llano...
Non posto neanche le voci che sento, ma sono comunque (per lo più) ottimistiche.
Finora sappiamo che si tratta di architettura K10 (anche se i cialtroni di FUDZILLA la considera un K8 super potente); dovrebbe avere 1MB di cache L2, la L3 sarà assente mentre si parla di una possibile introduzione delle istruzioni AVX (non che quelle delle SSE 4.1/4.2).
Se la vedrà con gli SB più economici e anche se la GPU integrata di Llano sarà nettamente più potente, rimane l'incognita di quanto perderà in prestazioni sui core X86...

Visto che mi si è bruciata la possibilità di poter montare sulla mia MSI 870A-G54 Buldozer sono molto incuriosito da Llano perchè magari a inizio 2011 potrei anche decidere di prenderi codesta gpu con annessa scheda madre e tenermi magari le ddr3-1333 visto che non userò la gpu integrata,ma la mia attuale HD 5850.

[Pihippo]

Originariamente inviato da calabar

Cut

Ah, ok, allora è chiaro, massimo possono essere 2 a 128 bit.
Mi pareva però che in questo fosse superiore al K10, dato che il k10 non ha la possibilità di eseguire codice a 256bit, e si parlava di un raddoppio di potenza dell'unità FP, avevo supposto che il k10 avesse due unità a 64 bit utilizzabili coem una da 128, funzionanti cioè con lo stesso approccio ma scalate di una potenza di 2 come dimensione.

Da cosa deriva allora l'idea che la FP si BD sia piu potente, come affermato più volte qui sul forum?

Ciao
Dunque l'idea si basava sul fatto che il cluster fp avesse più unità fp. Almeno cosi pensavo io. La potenza è simile se non uguale a quella del k10 però vedendo la preview di realworldtech si potrebbe affermare che sia abbastanza efficiente, più di quella del k10. Quello che descrivi tu sopra è il concetto di pipelining. Ovvero stadio 1 della pipe c'è l'op x appena essa entra in stadio 2 lo stadio 1 può accettare l'op y ad esempio, non è sempre cosi, anzi spesso o la rete di fowarding la spedisce più in giu nella pipe per vari motivi (operandi pronti ad es) oppure si formano delle bolle (istruzione dipendente da operandi mancanti oppure dipendente da altra istruzione non computata)

[somethingstrangeinyourmind]

Originariamente inviato da Athlon 64 3000+

Visto che mi si è bruciata la possibilità di poter montare sulla mia MSI 870A-G54 Buldozer sono molto incuriosito da Llano perchè magari a inizio 2011 potrei anche decidere di prenderi codesta gpu con annessa scheda madre e tenermi magari le ddr3-1333 visto che non userò la gpu integrata,ma la mia attuale HD 5850.

Anch'io sono curioso di vedere come sarà Llano.
Anche perchè, come si dice nell'articolo linkato da mack.gar, alcune nuove features implementate su questo processore dovrebbero ritrovarsi anche su BD.

[malmo]

Originariamente inviato da somethingstrangeinyourmind

Anch'io sono curioso di vedere come sarà Llano.
Anche perchè, come si dice nell'articolo linkato da mack.gar, alcune nuove features implementate su questo processore dovrebbero ritrovarsi anche su BD.

quindi llano non può utilizzare semplici ddr3 a 1333? Per via della gpu che richiede maggiori frequenze?

[Athlon 64 3000+]

Riguardo le memorie ddr3 supportate da Llano penso che suppoterà ram con frequenze più alte rispetto alle 1333 perchè la gpu integrata richederà molta banda.
Sono stato io che ho detto che avrei intenzione di tenere le mie attuali ddr3-1333 se dovessi passare a Llano perchè non userò la gpu integrata,ma la HD 5850.

[bjt2]

Originariamente inviato da capitan_crasy

Scusate se interrompo un pò questa discussione su Bulldozer, ma vorrei attirare l'attenzione un secondo sui core X86 di Llano...
Non posto neanche le voci che sento, ma sono comunque (per lo più) ottimistiche.
Finora sappiamo che si tratta di architettura K10 (anche se i cialtroni di FUDZILLA la considera un K8 super potente); dovrebbe avere 1MB di cache L2, la L3 sarà assente mentre si parla di una possibile introduzione delle istruzioni AVX (non che quelle delle SSE 4.1/4.2).
Se la vedrà con gli SB più economici e anche se la GPU integrata di Llano sarà nettamente più potente, rimane l'incognita di quanto perderà in prestazioni sui core X86...

Non è cialtroneria. AMD ha smesso di usare le sigle Kx, ma fino a quando erano usate, K8 era l'architettura attuale fino al Thuban, K9 era quel famoso progetto a 13 FO4 cancellato e K10 era il bulldozer...

[bjt2]

Originariamente inviato da cionci

Era chiaro che mi riferivo a quelle a 128 bit.
A parte le AVX, è esattamente la stessa quantità su cui può lavorare la FPU del K10: http://www.insidehw.com/Editorials/C...hitecture.html

La FPU del Thuban può fare 2/3 istruzioni elaborative per clock, di cui 2 massimo FP (FMISC può fare se non mi sbaglio solo shuffle e di coversione). Le SIMD intere competono per le 2 unità FP. Inoltre se le istruzioni non sono appaiate per bene, una delle pipeline rimane vuota, per colpa delle code separate. Con coda unica, pipeline dedicate per le SIMD intere (le MMX) da quelle FP, e considerando che nel caso migliore per il Thuban il limite diventa la banda verso la memoria (in bulldozer ogni core ha più banda e comunque la FPU si "serve" da due core in parallelo), il throughput della FP del Bulldozer può tranquillamente essere doppio...

[AnonimoVeneziano]

Originariamente inviato da capitan_crasy

Non vedo perchè no...
Inoltre AMD sta lavorando per i catalyst "open source" dove ha già rilasciato una parte del codice sorgente dei suoi driver...

Uhm? Non è così. I drivers radeon opensource e i catalyst hanno code base totalmente diverse.

[capitan_crasy]

Originariamente inviato da bjt2

Non è cialtroneria. AMD ha smesso di usare le sigle Kx, ma fino a quando erano usate, K8 era l'architettura attuale fino al Thuban, K9 era quel famoso progetto a 13 FO4 cancellato e K10 era il bulldozer...

Faccio una piccola premessa:
Per AMD non esiste il K10, tale sigla è per gli addetti ai lavori o per gli articoli specialistici.
Anche se ci sono i nomi Hammer per il K8 e Stars per i K10, AMD in termini pratici considera la famiglia dei Phenom2/Athlon2 ect. come un generico K8, la quale è la base dell'architettura K10.
AMD ha dichiarato che Llano avrà i core X86 con architettura "Stars" (anzi le parole giuste sono di derivazione) ovvero i K10 e gli ultimi screen del DIE confermano una somiglianza con i core Propus a 45nm.
Già da questo l'argomento è bello che chiuso, tranne ovviamente di quali siano i numeri di questo core K10 portati a 32nm SOI.
Che FUDZILLA come al solito deve fare un teatrino dicendo che AMD andrà contro SB con un architettura di 7 anni fa è da cialtroni!
Clicca qui...
Ma porca di quella porca ma come si fa a scrivere certe caxxxxe quando basterebbe un minimo di serietà per capire come stanno veramente le cose?

[papafoxtrot]

Originariamente inviato da paolo.oliva2

@Papafoxtrot

Considerando le tue previsioni... sto giro mi sa che per prendere un BD X8 tocca mettere mano seriamente al portafoglio e non i soldi spicci per casa.

Praticamente quando uscirebbe ci sarebbe pure nella versione X8 e si troverebbe di fronte solamente SB X4 per alcuni mesi. Ciò mettrebbe nella condizione AMD di avere il procio più potente in commercio.

Purtroppo vedendo un listino Intel in cui i proci top sarebbero sull'ordine degli 800€, non penso che AMD lo piazzerà sui 300€ (se lo facesse, sbancherebbe il mercato).

Inoltre avrebbe pure la carta di portare i BD X12 e X16 dal server al desktop, ora che si sa che pure nei server adotteranno il turbo, la cosa si limiterebbe al discorso socket e volontà AMD. In questo diciamo che sarà aiutata da Intel, perché un SB X8 dovrebbe avere prezzi di listino ancora superiori degli X6 attuali, e i margini di guadagno certamente invoglierebbero AMD.

Difficile fare previsioni di prezzo... ma reputerei più facile un prezzo aggressivo per AMD anche in caso di procio più potente che un abbassamento generale del listino Intel.

Premesso che non sappiamo quando bulldozer uscirà, ma ritengo possibie che sia disponibile entro giugno (l'articolo linkatom parlava di seconda metà... ), se anche BD X6/X8 arrivasse prima di SB X6/X8, rimarrebbe comunque core i7 980 e 990x.
Intel non rimuoverà questi ultimi dal mercato fino all'arrivo dei SB di fascia più alta, i quali probabilmente saranno lanciati dopo gli X4 per il semplice motivo che ad oggi i quad core (destinati a diventare la fascia medio-alta) sono ancora a 45nm, e dunque meno avanzati e più costosi da produrre.
Per cui secondo me prima fa uscire i SB X4, svecchiando i lynnfield ed i core i7 9x0 quad core.
I core i7 9x0 a 6 core sono già a 32nm, e dunque SB comporterà un passo avanti inferiore in questo settore.
Indi per cui il confronto con core i7 990x non è butato li a caso. Quello sarà, da subito, il nemico da battere. Poi SB X6 crescerà leggermente le performance, riducendo in parte i consumi.

Ad ogni modo per quanto riguarda i listini intel, mi aspetto ache all'uscita i SB X6 siano piazzati tra i 450 e gli 800 euro. SB X8 potrebbe uscire prima extreme a 1000 euro, per poi calare successivamente uscendo in versioni inferiori, in dipendenza anche da come va bulldozer.
Prima di SB X6 penso che comunque intel potrà tagliare i prezzi di core i7 970 ed eventualmente 980, anche qui con l'eventuale scopo di fronteggiare bulldozer.
Alla fine il core di gulftown è parecchio piccolo e a distanza di un anno trovare un gulftown a 500 euro non sarebbe una sorpresa.

Originariamente inviato da calabar

Correggetemi se sbaglio, però mi pare che SMT sia proprio un modo per sfruttare meglio la pipeline in caso di stallo.
Anche in un core normale senza SMT possiamo trovare più thread nei diversi stadi della pipeline.. altrimenti a che servirebbe la pipeline?
Con SMT ho in pratica il vantaggio di poter avere sempre un thread pronto da inserire, ma la pipeline è una, e quindi in un dato stadio di questa, solo un thread potrà esistere.
In quella che io chiamo divisione, invece, in uno stesso stadio potranno esserci più thread in contemporanea, senza concorrenza, come se le FP fossero due.

Per quanto riguarda il numero di istruzioni processabili, è stato JF (o qualcuno da AMD) a dichiarare 1xAVX, 2x128bit o 4x64bit, quindi fino a prova contraria per lo meno dovrebbe gestirne fino a 4.

Grazie (anche a Pihippo) per la spiegazione sulla parte condivisa (non ho tempo ora di leggere tutti i documenti e sono comunque meno ferrato di voi sull'argomento).
Da vedere comunque se ere quanto la parte di fetch e decodin possa costituire un collo di bottiglia: se adeguatamente potenziata poco importa che sia in comune, se poi è sovrabbondante per gestire i due core.
L'importante è che una volta avviati possano processare le operazioni senza concorrenza.

PS: ovviamente se ho detto castronerie sentitevi liberi di correggermi!

Grosso modo mi trovo d'accordo col concetto che esprimi: le pipeline a 128 bit sono due diverse, e ciascuna esegue un singolo thread alla volta. Certo il front end è condiviso e ciò è positivo.
Se fosse implementato un multi threading ciascuna pipeline potrebbe lavorare, alternativamente, a due thread, ma non mi risulta sia così.
Le pipeline sono due e i thread a 128 bit anche due.

Mi domando come possano essere eseguite le istruzioni a 64bit, visto che AMD ha parlato di 4 thread .a 64 bit contemporanei. Potrebbe essere che ogni pipeline a 128bit possa eseguire i due thread in concorrenza? E dunque una specie di SMT?
Potrebbe invece essere che per l'esecuzione delle AVX la FPU possa farsi carico di due thread (uno per core INT) ed eseguirli in concorrenza?

Originariamente inviato da capitan_crasy

Scusate se interrompo un pò questa discussione su Bulldozer, ma vorrei attirare l'attenzione un secondo sui core X86 di Llano...
Non posto neanche le voci che sento, ma sono comunque (per lo più) ottimistiche.
Finora sappiamo che si tratta di architettura K10 (anche se i cialtroni di FUDZILLA la considera un K8 super potente); dovrebbe avere 1MB di cache L2, la L3 sarà assente mentre si parla di una possibile introduzione delle istruzioni AVX (non che quelle delle SSE 4.1/4.2).
Se la vedrà con gli SB più economici e anche se la GPU integrata di Llano sarà nettamente più potente, rimane l'incognita di quanto perderà in prestazioni sui core X86...

Ciao capitano,
Io credo che Llano non eseguirà AVX. Per il semplcie fatto che alla fine ad oggi le AVX non esistono, e la vita utile di Llano (un anno? due anni?) sarà sufficiente a farle comparire nei software professionali (per i quali si userà bulldozer), più che per i software consumer. L'utente di Llano non sarà certo il professionista che usa software di fascia alta...
E tu sai bene quanto le software house sono lente ad aggiornarsi ed implementare nuove tecnologie.

Piuttosto mi aspetto che anche qui AMD faccia parecchio per migliorare le tecnologie di risparmio energetico, in modo da spingere di più il turbo boost e creare CPU che in idle consumano pochissimo, caratteristica apprezzata negli home theater, nei computer di fascia bassa e soprattutto nei portatili.
Un miglioramento di IPC è certamente possibile, ma conservando l'architettura in genere non si guadagna più di un 10%, condiserato anche che k10 in llano avrà già subito upgrade precedenti e sarà già stato migliorato più volte (da barcelona a deneb a thuban).
Consideriamo anche che la L2 sarà ampliata, ma la L3 ridotta. Ad oggi i phenom II X2 sono in media più potenti degli athlon II X2 (che hanno 2x1MB di L2). Per cui credo che un incremento di IPC debba essere dedotto della mancanza della L3. Alla fine un +10% è realistico. Non credo di più. Poi ci sono ambiti dove la L3 non serve a nulla (e allora l'incremento potrà essere migliore, rispetto a deneb), e ambiti dove invece è impostante (e allora deneb potrebbe eguagliare o anche superare Llano).

Ma se non sarà presente L3, la GPU come sarà connessa?

Io però continuo a ritenere possibile un Llano a 6 core, magari successivamente. Alla fine SB X4 (8T) sarà decisamente più potente come core x86, non c'è nulla da fare. Si parte da 3GHz, per cui sarà potente come un odierno core i7 880 almeno... E sarà prezzato a pertire dai 180 euro.
Svendere LLano a 120 euro sarebbe un peccato.

Certo avrà una GPU migliore, ma haimè ho proprio l'impressione che sarà più la CPU ad essere valutata, che non la GPU. Anche perché ancora oggi nella fascia bassa molti usano GPU discrete comunque.
E purtroppo i test con i giochi sono sempre eseguiti in CPU-limited, con dettagli bassissimi, e la gente si convince che con una CPU potente si giochi meglio...

Le pipeline di Llano saranno quelle di deneb, per cui non credo vedremo un Llano alle frequenze di Bulldozer. Forse un 3,4-3,6GHz, ma almeno al lancio non credo vedremo di più.

[cionci]

Originariamente inviato da bjt2

La FPU del Thuban può fare 2/3 istruzioni elaborative per clock, di cui 2 massimo FP (FMISC può fare se non mi sbaglio solo shuffle e di coversione). Le SIMD intere competono per le 2 unità FP. Inoltre se le istruzioni non sono appaiate per bene, una delle pipeline rimane vuota, per colpa delle code separate. Con coda unica, pipeline dedicate per le SIMD intere (le MMX) da quelle FP, e considerando che nel caso migliore per il Thuban il limite diventa la banda verso la memoria (in bulldozer ogni core ha più banda e comunque la FPU si "serve" da due core in parallelo), il throughput della FP del Bulldozer può tranquillamente essere doppio...

Ma devi contare il tipo di traffico di ogni thread...
I casi in cui il throughput sarà massimo sono alquanto rari.
L'unica possibilità sarebbe avere:
- entrambi i thread eseguono SIMD su interi e su FP (occupando mediamente una unità SSE ed una MMX ciascuno)
- 1 thread esegue istruzioni SIMD su interi e 1 thread esegue istruzioni SIMD su FP