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

[liberato87]

Originariamente inviato da Danckan

Ogni tanto vengo a sfogliare le pagine di questo thread per vedere se ci sono news su bulldozer, ma tra OT, diserzioni chilometriche e inconcludenti oppure rivolte ad altri aspetti non strettamente legati a bulldozer, mi risulta davvero difficile trovare quelle poche informazioni utili che man mano vengono snocciolate dalle varie fonti... vi prego di placarvi

mi associo; mi sono arrivate 25 mail di notifica speravo fosse uscita qualche news sensazionale e invece... OT su vecchi computer

Sicuramente non c'è niente di nuovo, però se avete voglia date un occhio quì....

[capitan_crasy]

Aggiornamento 11/04/2011

Originariamente inviato da bjt2

Allora... Menziono le cose più importanti mano a mano che leggo...


- E' confermato che internamente BD usa ancora macro-op (operazione intera oppure FP + operazione memoria). Ciò è importante per stabilire quanto riesce a macinare...

- E' confermato che esistono ancora operazioni single, double e vector (anche se i nomi sono cambiati: FastPath Single, FastPath Double e Microcode). Ciò è importante per stabilire la potenza del decoder.

- Parla delle istruzioni supportate: AVX, XOP, FMA(C) ecc... Tutto confermato. Più qualche cosa poco nota come istruzioni per l'estrazione della parte frazionaria di un numero FP e istruzioni vettoriali di rotazione, shift, shuffle.

- Menziona le nuove unità FP a 128 bit e dice che le prestazioni possono essere fino al doppio. Non mi è chiaro questo punto. Anche le unità del K10 sono a 128 bit. Ma poi spiega l'uso del FMAC che non è automatico e dice che l'FMA è più preciso di una ADD+MUL (si sapeva già). Forse è a questo che si riferisce quando parla di prestazioni doppie.

- Ora BD non soffre più in prestazioni se le istruzioni sia di load/store, sia load/execute lavorano su dati non allineati. Possibili benefici con codice con dati non allineati. Questo potrebbe essere un refuso del documento del K10. Mi pare di ricordare che era una delle novità del passaggio da K8 a K10...

- Novità del fetching istruzioni. Non più una finestra di 32 bytes, ma DUE finestre di 32 bytes da cui possono essere prodotte fino a 4 mops/ciclo. Si accenna al fatto che queste due finestre assieme alla FPU a 128 bit consentono di avere un ritmo di fetch/execute/retire di 4 mops/ciclo... Ora come ora è molto nebulosa la cosa. Non menziona mai il fatto che è condivisa tra due thread...

- Accenno al fatto che molte istruzioni sono state promosse da vector a double o a single, che sono migliorate le latenze e che molte istruzioni FPU sono state spostate di pipe... ATTENZIONE! Fino ad ora avevamo supposto che l'architettura a FO4 17 avrebbe comportato l'aumento delle latenze delle istruzioni... Secondo quanto scritto qui E' IL CONTRARIO! Potrebbe anche questo essere un refuso della modifica del documento del K10.

- Miglioramento in velocità delle istruzioni di shuffle, di trasferimento registri FP-interi (nonostante la FP condivisa!), di trasferimento FP-FP (quello a cui accennava JF-AMD degli zero latency move), delle operazioni su stringhe (i vari REP, SCAS ecc), delle operazioni stack e del paging a 1GB.

- Le operazioni di shuffle (tallone di achille) possono essere fatte al quadruplo della velocità grazie a più unità, al fatto che sono a 128 bit (???) e ora le istruzioni sono Direct Path e non vector path (mi sa che è un refuso del vecchio documento perchè parla delle pipeline FADD, FMUL e FSTORE... anche per le operazioni di move reg-reg)

- poi parla delle TLB e della virtualizzazione.

--- FINE SEZIONE INTRODUTTIVA ---

- Confermate le cose che si sapevano sull'architettura (caches ecc). Predizione e fetch sono disaccoppiati, decoding a 4 vie (limite teorico). Scheduling dinamico. 2 istruzioni ALU + 2 AGU per ciclo (confermato). 2 128 BIT FPU. Supporto AVX, XOP ecc. Superforwarding (probabilmente quella cosa del poter usare subito i risultati di una operazione).

- Descrive il fatto delle 4 microop/ciclo. Dice che può fare il fetch di 32 bytes per ciclo e che puo fare la scansione di due blocchi da 16 bytes per ciclo (su due finestre di 32 bytes). Può decodificare fino a 4 mops/ciclo. E' un limite teorico che dipende dalle istruzioni presenti nelle finestre di 16 bytes e anche dalla modalità in cui si trova la CPU: FAST o SLOW (???)

- Schema a blocchi della CPU: nulla da notare se non che non divide le ALU/AGU ma le chiama genericamente pipeline e anche qui la FPU è indicata con solo le due pipeline a 128 bit...

- Caches: L1 istruzioni UNICA da 64 KB, a 2 vie con linea da 64 bytes e lettura di 32 bytes (come quella del K10). Quando è letta una nuova cache line è automaticamente fatto il prefetch di quella successiva. Il predecoing è fatto subito dopo il load. La L1 dati è da 16 KB. Può fare 2 load a 128 bit per ciclo. Ha 16 banchi e un solo load per banco. Quindi i due load sono simultanei se sono in banchi separati. Latenza di 4 cicli (! data l'alta latenza, prevedo clock stratosferici). Menziona genericamente il prefetching. La cache L1 è write through e non write back come il K10... Hanno imparato da INTEL... Ci sono vantaggi nello snooping. Solo la cache L2 va testata... Quest'ultima appunto è inclusiva e condivisa tra i due core. Menziona il write trough e finalmente conferma che le caches sono due. La latenza è 18-20 cicli e la cache è full speed (quindi con il clock alto... ). Il perchè è presto detto: la dimensione è dipendente dall'implementazione! Ci possono essere modelli con più o meno L2 per core (magari parzialmente disattivata per difetti...). La cache L3 può essere massimo 8MB con 4 blocchi di massimo 2MB (anche qui il binning per difettosità...). La cache L3 è non inclusiva e victim buffer. Ci vanno i dati buttiati dalle L2. Un dato rimane nella L3 se è usato da più cores (un predittore?). Altrimenti va nella L1 del core che la usa. La L3 è dichiarata migliorata come banda. Latenza non specificata.

- Branch prediction: penalità da 15 a 20 cicli in caso di miss. In caso di hit, un solo ciclo se è nella cache L1, 4 cicli se è nella L2. La L1 è 4x128 entry e la L2 5x1024 entry. 512 entry per gli indiretti e 24 per il return stack. Il branch prediction è abbastanza complesso ma credo che sia simile a quello del K10...

- Fetch e decode. Sono letti 32 bytes/ciclo. Le finestre sono di 16 bytes e esistono due code (una per thread). Si possono decodificare fino a 4 istruzioni per ciclo contenute in 2 finestre a 16 bytes.

- TLB: L1 istruzioni 48 4KB, 24 2MB o 1GB. Entry da 4MB occupano due entry da 2MB. L1 dati 32 (64 per i modelli 20H-2FH) per 4KB, 2MB e 1GB. Entry da 4MB occupano due entry da 2MB. L2 istruzioni 512 4KB. L2 dati 1024 condiviso tra 4KB, 2MB e 1GB. Entry da 4MB occupano 2 slot.

- Esecuzione intera: c'è lo scheduler e le unità di esecuzione. Lo scheduler è completamente data-driven. Non ci sono più le lane del K10. Ossia è più inteligente: l'unico limite è la disponibilità dei dati e delle unità. Inoltre tiene traccia del completamento e delle eccezioni delle istruzioni FP: è questa unità che decide il da farsi. L'unità FP fa solo il "lavoro sporco"... Lo scheduler intero può ricevere e schedulare fino a 4 mops/ciclo. Fa il register renaming e sveglia le istruzioni in attesa. Le unità di esecuzione sono 4. ATTENZIONE: 2 ALU e 2 AGLU. Le due ALU sono chiamate Ex0 e Ex1. Possono fare tutte le operazioni aritmetiche, logiche e di shift. La Ex0 fa anche DIV e POPCNT. La EX1 fa anche MUL e BRANCH. Le AGLU possono fare le AGU e operazioni ALU SEMPLICI. NOVITA' rispetto al K10: le mops sono divise nello scheduler in microops. Possono essere eseguite indipendentemente e fuori ordine (non più le lanes... ) quando dati e unità esecutiva sono libere, in particolare in contemporanea in ALU e AGLU separate. Lo scheduler può ricevere 4 MOPS/ciclo (quindi potenzialmente 4 istruzioni intere più 4 memoria). Questo è un dispatch group. Il divisore di EX0 non è pipelined ed è a latenza variabile. Il moltiplicatore in EX1 è pipelined. L'AGLU contiene una ALU semplice per fare istruzioni aritmentico logiche semplici... Guardando le tabelle delle latenze sembra che le AGLU siano sfruttate in poche istruzioni, giusto per non usare le EX unit. LZCNT e POPCNT sono gestite in EX0.

- FPU. E' dichiarato che la FPU ha 4 volte la potenza di picco di quella del K10. 4 pipeline. 2 FMAC a 128 bit. Una può fare anche le IMAC (multiply - accumulate su dati interi) e le conversioni tra int e fp e una ha un crossbar per gli shuffle SIMD. 2 unità SIMD intere per MMX e SIMD intere. Una delle due ha la pipeline FSTORE. C'è poi una unità di load/store che può fare 2 letture a 128 bit + una scrittura a 128 bit. La CPU può ricevere fino a 4 mops/ciclo, ma da un solo thread alla volta. Il thread può cambiare a ogni ciclo. La FPU può eseguire 4 mops/ciclo. Una volta ricevute in cicli separati, poi possono essere eseguite anche inframezzate nello stesso ciclo, al ritmo di 4/ciclo. Nella FPU possono essere accettati fino a 2 loads per ciclo, anche da 2 thread separati. 4 pipeline, 2 FP e 2 INT. 2 128 bit FMAC. Ognuno può fare anche ADD e MUL anche x87. Ogni FMAC ha anche un divisore e calcolo radice quadrata a latenza variabile. Una istruzione a 256 bit può essere eseguita in un ciclo. Se non ci sono due unità libere è spezzata in due senza penalità. Cioè in pratica una istruzione a 256 bit è spezzata in due subistruzioni a 128 bit che possono essere eseguite indipendentemente (e anche in due cicli separati) senza bloccare le altre. Massima flessibilità, dunque.

- Unità di load/store. Una per core, due per modulo. Ogni unità supporta 2 letture a 128 bit e una scrittura a 128 bit per ciclo. La coda di scrittura è di 24 entry. La coda di lettura ha 40 entry. Due pipeline per ogni unità LS per fare 2 operazioni in contemporanea. Menziona il fuori ordine per le operazioni memoria ma non entra nei dettagli. Il write combining supporta 4 stream, con 4 buffer da 64 bytes (condivisi tra i due cores). C'è una cache di 4KB prima della L2 (64 blocchi da 64 bytes) per gestire il write combining da sorgenti varie (compreso il write chaining per la trasmissione su bus HT).

- Controller RAM. Supporta DIMM da 4, 8 e 16 bit, interleaving, ECC, e canali a 64 bit indipendenti. Ha algoritmi di scheduling e predizione ottimizzati in particolare per sequenze alternate di read e write. Il prefetcher tiene i dati nel controller e non li spedisce alle caches. Può adattarsi a pattern ascendenti e discendenti e altri più complicati. Le specifiche del MC possono cambiare da modello a modello.

- HT: supporto a 25.6GB/s (quindi 3.2 GHz) e varie features dell'HT 3. HT assist per sistemi a 4 o più socket: ancora con consumo di 1-2 MB di L3.

- Branch fusion. Non è specificato un limite al numero massimo di branch fusion però molto probabilmente al massimo uno. Perchè i limiti sono che il compare e il branch devono essere adiacenti, che il compare non deve essere la quarta istruzione del dispatch group, che il branch deve avere indirizzamento rip-relativo, che il compare non deve avere dati immediati o indirizzamento SIB.

- LATENZE istruzioni. Purtroppo è difficile confrontare le latenze senza avere a fianco quelle del K10. Ci dobbiamo fidare dei proclami dell'inizio del PDF. Molte istruzioni hanno un N/A, non so se per NDA oppure perchè effettivamente al tempo di stesura del PDF non erano note. Però lo scheduler data-driven, le uops che possono andare indipendentemente, le pipeline intere e FP separate possono addirittura far sperare in un IPC superiore al SB!

Questo è quanto...

[SwatMaster]

Ahahah, Capitano sei un grande!

E ovviamente grandissimo anche bjt2


....Senza di voi questo thread sarebbe come il Far West.

[D1o]

Originariamente inviato da bjt2

Allora... ...cuttone...
Questo è quanto...

complimenti per la analisi. purtoppo le mie conoscenze limitate non mi permettono di capire approfonditamente le implicazioni di quanto sopra.

quindi la mia domanda è: spannomentricamente è possibile stimare se ci sarà un migioramento (se si quanto?) nell'uso di software cpu intensive che fanno conti su FP, inversione di matrici, et similia (codici strutturalei fem, cfd, fft etc...)

grazie mille

[khael]

Salve a tutti,
avrei bisogno di un piccolo aiuto, al momento ho una gigabyte d510, ma vorrei sostituirla con amd fusion;
Sperando non sbagliare th, chiedo qui il consiglio:
Mi serve per fare le seguenti cose:
1) visione filmati (blu-ray, dvb-t 1080p e dvb-s2 1080p, mkv 1080p)
2) visione youtube fino a 1080p
3) qualche giochino semplice semplice (considerando che la hd3200 mi basta penso che la 6310 basti!)

Dal mio fornitore avrei a 120€ questa qui:
Codice FUSION-350-DX11 P/N: 52036-00-40G

che dovrebbe essere la "Pure White Fusion" sapphire....

grazie!

[Danckan]

Ottima analisi di bjt2 e grande rotolata per i soliti fotomontaggi del capitano!

Inoltre proprio su HWUpgrade oggi questa news su Llano: http://www.hwupgrade.it/news/cpu/nuo...ano_36267.html

2,4Ghz per un sample lasciano ben sperare. Tuttavia la mancanza di chace L3 o particolari novità architetturali sul lato CPU mi fa pensare che questi nuovi processori non siano altro che degli Athlon II con GPU integrata il che li renderebbe poco competitivi con la nuova fascia media SB di Intel.

Se attivano una sorta di Hybrid Crossfire tra AP e scheda discreta però potrebbe comunque essere interessante.

[idkfa]

Originariamente inviato da Danckan

Ottima analisi di bjt2 e grande rotolata per i soliti fotomontaggi del capitano!

Inoltre proprio su HWUpgrade oggi questa news su Llano: http://www.hwupgrade.it/news/cpu/nuo...ano_36267.html

2,4Ghz per un sample lasciano ben sperare. Tuttavia la mancanza di chace L3 o particolari novità architetturali sul lato CPU mi fa pensare che questi nuovi processori non siano altro che degli Athlon II con GPU integrata il che li renderebbe poco competitivi con la nuova fascia media SB di Intel.

Se attivano una sorta di Hybrid Crossfire tra AP e scheda discreta però potrebbe comunque essere interessante.

A me fanno pensare 2.4GHz e i 0.396V .

Se sono valori dovuti da bug del software allora OK.
Ma se fossero reali si può anche ipotizzare che se in idle sta a 2.4, in full... può arrivare a

[e.greg.io]

Originariamente inviato da idkfa

A me fanno pensare 2.4GHz e i 0.396V .

Se sono valori dovuti da bug del software allora OK.
Ma se fossero reali si può anche ipotizzare che se in idle sta a 2.4, in full... può arrivare a

è cpuz che scazza

[Spitfire84]

Originariamente inviato da khael

Salve a tutti,
avrei bisogno di un piccolo aiuto, al momento ho una gigabyte d510, ma vorrei sostituirla con amd fusion;
Sperando non sbagliare th, chiedo qui il consiglio:
Mi serve per fare le seguenti cose:
1) visione filmati (blu-ray, dvb-t 1080p e dvb-s2 1080p, mkv 1080p)
2) visione youtube fino a 1080p
3) qualche giochino semplice semplice (considerando che la hd3200 mi basta penso che la 6310 basti!)

Dal mio fornitore avrei a 120€ questa qui:
Codice FUSION-350-DX11 P/N: 52036-00-40G

che dovrebbe essere la "Pure White Fusion" sapphire....

grazie!

http://www.hwupgrade.it/forum/showthread.php?t=2323342

[blackshard]

Originariamente inviato da idkfa

A me fanno pensare 2.4GHz e i 0.396V .

Se sono valori dovuti da bug del software allora OK.
Ma se fossero reali si può anche ipotizzare che se in idle sta a 2.4, in full... può arrivare a

Naaa, è impossibile.

[paolo.oliva2]

Originariamente inviato da e.greg.io

è cpuz che scazza

.
2,4GHz probabilmente no, ma 0,396V arciultrasicuramente si.

[Vash_85]

Originariamente inviato da paolo.oliva2

.
2,4GHz probabilmente no, ma 0,396V arciultrasicuramente si.

0.4v per un quad anche se stesse a 800mhz con 3 core spenti imho sono troppo pochi....

[bjt2]

Originariamente inviato da D1o

complimenti per la analisi. purtoppo le mie conoscenze limitate non mi permettono di capire approfonditamente le implicazioni di quanto sopra.

quindi la mia domanda è: spannomentricamente è possibile stimare se ci sarà un migioramento (se si quanto?) nell'uso di software cpu intensive che fanno conti su FP, inversione di matrici, et similia (codici strutturalei fem, cfd, fft etc...)

grazie mille

Il miglioramento ci sarà sicuramente per la parte intera. Per quella FP, se si è limitati dalla banda della memoria, si può ottenere un 30% di prestazioni in più (indipendentemente da clock e IPC) perchè è tale il miglioramento nella banda della memoria dichiarato da AMD. Se non si è limitati dalla banda, si può sperare in un +80% dato dall'incremento in cinebench visto qualche settimana fa...

[liberato87]

Originariamente inviato da bjt2

Il miglioramento ci sarà sicuramente per la parte intera. Per quella FP, se si è limitati dalla banda della memoria, si può ottenere un 30% di prestazioni in più (indipendentemente da clock e IPC) perchè è tale il miglioramento nella banda della memoria dichiarato da AMD. Se non si è limitati dalla banda, si può sperare in un +80% dato dall'incremento in cinebench visto qualche settimana fa...

è questa una grande cosa per cui aspetto BD! finalmente si potranno sfruttare le ram come si deve senza dover essere limitati dalla cpu! con i phenom la differenza con la controparte era davvero imbarazzante...

[Athlon 64 3000+]

Volevo fare un piccolo OT.
Sembra che SB-E a 32nm sarà al max a 6 core con il socket LGA2011 e per la versione a 8 core si potrebbe riparlarne con i 22nm.
Se mai fosse vero Paolo ci avrebbe indovinato.
Tornando in topic questa potrebbe essere una buona notizia per AMD e per Buldozer perchè con la versione a 8 core dovrebbe essere competitivo e farebbe respirare AMD.

[NiubboXp]

ma le am3+ non dovevano trovarsi gia ad aprile? io in italia non ho ancora trovato nulla...

[capitan_crasy]

Originariamente inviato da NiubboXp

ma le am3+ non dovevano trovarsi gia ad aprile? io in italia non ho ancora trovato nulla...

In Italia no, ma in Germania sono già in vendita da un paio di settimane...
Clicca qui...

Edit:
In italia si trova la ASROCK 880G Pro3...
Clicca qui...

[fabri85]

Ragazzi siete fenomenali vi leggo sempre con passione e non trovo mai il tempo di ringraziarvi...

ho letto che vi mancano un po di spunti... ora... a parte la sviolinata iniziale ... che mi sapete dire del IOMMU? riguarda la virtualizzazione dell'IO... ma non solo quello...

[capitan_crasy]

Post interessante di JF:

Originariamente inviato da JF-AMD

I was not referring to something specific. In the past we utilized the same die, but we moved to Instanbul, they moved to Thuban and the dies diverged. With BD we move back to the same die (initially) but over time there is the opportunity for the two to diverge again.

Clicca qui...

I primi modelli di BD avranno una linea in comune con quelli server, poi con il tempo le altre CPU saranno prodotte su una linea dedicata...
In pratica avremo dei 920/940 in formato BD, almeno all'inizio...