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

[gianni1879]

Originariamente inviato da paolo.oliva2

Sta arrivando in BD2 o in BD1?

arriverà quando MS deciderà di metterlo in commercio

[maurilio968]

Originariamente inviato da paolo.oliva2

beh... se non altro sappiamo che l'IPC attuale può già aumentare solo con ottimizzazioni software.
Bisogna vedere se anche solamente Windows 8 potrebbe già influire.

a me sembra che il post di gianni vada in questo senso.
Speriamo.

Originariamente inviato da paolo.oliva2

Comunque J.F. dice che 2TH in un modulo darebbero 180, 90+90, mentre 2TH su 2 moduli darebbero 190-195. Quindi ci sarebbe una differenza di +10/15.
Non è poco... 180x2=360, 190/195x2 =380/390. Con 4TH su 4 moduli anzichè su 2 l'aumento sarebbe rilevante.

Già.

Comunque AMD si desse una mossa anche lato software.

[Athlon 64 3000+]

A questo giro è come penso e cioè che Zambezi avrà probabilmente delle pessime perfomance non per bug gravi(visto che sono arrivati alla step B2G) come è successo ad Agena B2,ma per via della sua architettura che richiede software ottimizzato ad hoc.
Per me è peggio che avere una CPU bacata perchè potevi sperare con lo step successivo di risolvere i problemi,mentre con una architettura del genere la situazione è molto più complicata.

[HacNet]

Originariamente inviato da gianni1879

W8 sta arrivando...

se si deve trascinar sul groppone errori dal tempo di xp come "crash di explorer.exe"
e bug simille credo che non ci sia patch che tenga e puo rianere d'ove scafalle!

[The3DProgrammer]

Originariamente inviato da maurilio968

Penso la prima.

"It should definitely not be negligible if XOP or FMA are utilized. With one thread per module, the bandwidth is 2 XOP + 2 FMA (128-bit) per thread cycle. With two threads sharing the module, the bandwidth is 1 XOP + 1 FMA per thread cycle.
Well, of course, if the software you use is NOT optimized with XOP/FMA instructions, then as you said, the difference between two cores on same and different modules would be small. But is that really a strength of your module, or a weakness of your software?"

Questo in realta' e' un grosso punto di domanda e ci pensavo proprio l'altro giorno. E tra l'altro non e' vero che vale solo per FMA, ma vale per tutti i task fp intensive siano x87 o SSE o XOP. Il motivo e' presto detto. Se 2 thread "integer" girano sullo stesso modulo avendo 2 cluster separati l'unico overhead e' dato dalla logica condivisa, che come detto dovrebbe essere trascurabile. Se invece i task sono fp intensive non solo si paga lo scotto della logica condivisa ma si dimezza a conti fatti il throughput per thread dell'FPU (infatti condividendo la stessa fpu nel caso ideale viene usata una fmac per thread). Se invece i 2 thread venissero eseguiti su 2 moduli separati si avrebbe un raddoppio effettivo delle prestazioni, in quanto entrambi i thread poggiano su 2 fpu complete. Ora che ci penso questo potrebbe essere uno dei motivi per cui bd paga con i giochi (sempre se e' vero ma a questo punto vistô che i rumors continuano a venire confermati inizio a crederci). Se un gioco usa 4 thread fp intensive e questi thread vengono allocati su 2 moduli vengono sfruttati solo il 50% delle capacita' di calcolo della cpu...

questo e' un GROSSO punto interrogativo.

[|ron]

Wooooot!
Anche SoF (noto clocker tedesco, di awardfabrik) ha in mano un BD, per l'evento di oc che quel sito sta tenendo in questi gg!
Dai che magari tra uno e l'altro, qualche bench scappa fuori!

[B|4KWH|T3]

Originariamente inviato da maurilio968

Ho trovato questo video in cui Maxon celebra (per così dire) il suo "matrimonio" con Intel


Maxon Computer uses Intel software tools for better performance

http://www.youtube.com/watch?v=-M1eX...el_video_title


Forse i (presunti, in base alle solite slides) risultati di Bulldozer con Cinebench hanno qualche spiegazione esterna ad AMD.

O che semplicemente gli strumenti che mette a disposizione AMD (da anni) non sono all'altezza.

Tempo fa leggevo che, nonostante le ottimizzazioni Intel-only nel compilatore Intel e nelle MKL, i processori AMD andavano meglio con software compilato cosi` che con software compilato con gcc e altra roba.

[B|4KWH|T3]

Originariamente inviato da The3DProgrammer

Questo in realta' e' un grosso punto di domanda e ci pensavo proprio l'altro giorno. E tra l'altro non e' vero che vale solo per FMA, ma vale per tutti i task fp intensive siano x87 o SSE o XOP. Il motivo e' presto detto. Se 2 thread "integer" girano sullo stesso modulo avendo 2 cluster separati l'unico overhead e' dato dalla logica condivisa, che come detto dovrebbe essere trascurabile. Se invece i task sono fp intensive non solo si paga lo scotto della logica condivisa ma si dimezza a conti fatti il throughput per thread dell'FPU (infatti condividendo la stessa fpu nel caso ideale viene usata una fmac per thread). Se invece i 2 thread venissero eseguiti su 2 moduli separati si avrebbe un raddoppio effettivo delle prestazioni, in quanto entrambi i thread poggiano su 2 fpu complete. Ora che ci penso questo potrebbe essere uno dei motivi per cui bd paga con i giochi (sempre se e' vero ma a questo punto vistô che i rumors continuano a venire confermati inizio a crederci). Se un gioco usa 4 thread fp intensive e questi thread vengono allocati su 2 moduli vengono sfruttati solo il 50% delle capacita' di calcolo della cpu...

questo e' un GROSSO punto interrogativo.

Non dovrebbe valere un discorso simile all'hyperthreading di Intel?

[capitan_crasy]

Originariamente inviato da maurilio968

Ho trovato questo video in cui Maxon celebra (per così dire) il suo "matrimonio" con Intel


Maxon Computer uses Intel software tools for better performance

http://www.youtube.com/watch?v=-M1eX...el_video_title


Forse i (presunti, in base alle solite slides) risultati di Bulldozer con Cinebench hanno qualche spiegazione esterna ad AMD.

Originariamente inviato da B|4KWH|T3

O che semplicemente gli strumenti che mette a disposizione AMD (da anni) non sono all'altezza.

Tempo fa leggevo che, nonostante le ottimizzazioni Intel-only nel compilatore Intel e nelle MKL, i processori AMD andavano meglio con software compilato cosi` che con software compilato con gcc e altra roba.

Siamo OT, ce un thread adatto per questo argomento...
Clicca qui...

[The3DProgrammer]

Originariamente inviato da B|4KWH|T3

Non dovrebbe valere un discorso simile all'hyperthreading di Intel?

si ma vale per modulo, non su tutta la cpu. Cioe' c'e' una fpu per modulo, quindi se 2 thread sono in esecuzione sullo stesso modulo possono condividere solo 1 fpu, non hanno possibilita' di accedere alle fpu inutilizzate negli altri moduli. almeno da quello che so io. Quindi per thread fp intensive non conviene ASSOLUTAMENTE allocarli per core int, ma bisogna allocarli per modulo per avere il massimo delle prestazioni. altrimenti le performance crollano.

EDIT bjt che ne pensi? Mi sono perso qualcosa io?

[gianni1879]

Originariamente inviato da HacNet

se si deve trascinar sul groppone errori dal tempo di xp come "crash di explorer.exe"
e bug simille credo che non ci sia patch che tenga e puo rianere d'ove scafalle!

non andare OT e non cominciamo con queste storie di guerre..

[The3DProgrammer]

Originariamente inviato da Veradun

Questo presumo valga solo in 256bit, non a 128bit, visto che diventano a tutti gli effetti due FPU. O sbaglio qualcosa?

allora mettiamola cosi. Ignorate questa storia dei 128bit che si riferisce solo alla dimensione dei registri sse e del datapath. Una sola FPU di BD contiene 2 unita' FP, che si chiamano FMAC. Ogni FMAC e' in grado di eseguire 1 op per ciclo di clock. Quindi, nel caso in cui su 1 modulo ci sia solo un thread in esecuzione, quel thread avrebbe a disposizione entrambe le fmac (+ le unita' sse int che non considero per semplicita'). Quindi 2 op fp per ciclo di clock. Se 2 thread sono in condivisione sullo stesso modulo, nel caso migliore hanno entrambi accesso ad una singola fmac dell'fpu di bd in SMT, il che si traduce in un throughput, per thread, di 1 op fp per ciclo di clock (totale 2 sui 2 thread). Se i 2 thread girassero su 2 moduli separati avrebbero invece accesso a 2 fpu distinte quindi 4 fmac, per un totale sui 2 thread di 4 op/ciclo. Quindi 2 thread su 2 moduli separati andrebbero, qui si, esattamente il doppio di 2 thread su un singolo modulo (anzi forse anche di + a causa dell'overhead dato dalla logica condivisa).

Se 1 gioco che usa 4 thread viene eseguito su BD e i 4 thread vengono eseguiti su 2 moduli, le prestazioni sarebbero effettivamente il 50% di quanto teoricamente ottenibile. Su questo non ci piove, a meno che nn abbia trascurato qualcosa o mi manchi qualche info sull'utilizzo delle FP per modulo BD.

[HacNet]

Originariamente inviato da gianni1879

non andare OT e non cominciamo con queste storie di guerre..

[bjt2]

Allora...
La maggior parte dei software ha una IPC FP minore di uno (ad esempio Cinebench ha 0.55+0.1 di intero sul K10).
Quindi condividere una FPU da 4 istruzioni per ciclo (anche se 2 FP e 2 SIMD) è una OTTIMA idea.
Se metti un solo thread in un modulo, non riuscirai praticamente mai a saturare la FPU per vari motivi:
1) La banda di decodifica e ritiro è 4 istruzioni/ciclo. Del codice intero che si mangia questa banda, oltre a istruzioni vector path o double, ci sono sempre. Saremo in media, se va bene a poco più di due istruzioni per ciclo.
2) Il codice FP è di solito anche memory intensive. Una sola pipeline INT può leggere 256 bit e scrivere 128 bit in un ciclo dalla cache L1. Quindi anche nella situazione ottimale di tutti i dati in cache, si possono servire solo due delle 4 unità a 128 bit (FP e SIMD), in lettura e una in scrittura... Ovviamente tale limite è anche teorico per via dei banchi della cache e altre limitazioni che ci possono essere che non conosciamo...
3) Ci sono comunque i salti e l'IPC medio non supera di molto 1. Persino Spec FP che è ottimizzato al massimo ha 1.35 di IPC (sul K10)...

Il motivo delle prestazioni in cinebench è probabilmente che usa istruzioni su cui il clock maggiore e l'architettura migliore non compensano le latenze maggiori delle cache e di queste istruzioni... Se poi è compilato con compilatore INTEL...

[bjt2]

Originariamente inviato da The3DProgrammer

si ma vale per modulo, non su tutta la cpu. Cioe' c'e' una fpu per modulo, quindi se 2 thread sono in esecuzione sullo stesso modulo possono condividere solo 1 fpu, non hanno possibilita' di accedere alle fpu inutilizzate negli altri moduli. almeno da quello che so io. Quindi per thread fp intensive non conviene ASSOLUTAMENTE allocarli per core int, ma bisogna allocarli per modulo per avere il massimo delle prestazioni. altrimenti le performance crollano.

EDIT bjt che ne pensi? Mi sono perso qualcosa io?

Esatto... C'è poi la questione Turbo... L'8150, ad esempio, è 3.6/3.9/4.2. Ha comunque il turbo all core a 3.9. E vi dirò di più. Visto l'esiguo IPC di cinebench, non mi stupirei se stesse più a 3.9 che a 3.6 (ricordate la storia del dithering del turbo di Llano... Vale anche qui...)... Urge che qualcuno lo testi (Giaaaaanniiiii! )...

[thedarkest]

avevate visto questi? sembra proprio che stia tra il 2500k e il 2600 come previsto



fonte

[Alekz]

Originariamente inviato da thedarkest

cut

lol? zero?

[HacNet]

Originariamente inviato da thedarkest

avevate visto questi? sembra proprio che stia tra il 2500k e il 2600 come previsto



fonte

credo di aver gia visto qualcosa del genere pagine addietro

[thedarkest]

Originariamente inviato da Alekz

lol? zero?

visto che ancora non e' uscito ufficialmente, credo che il valore 0 stia del perche' non si ha un prezzo ufficialmente stabilito ( anche se non sarebbe vero)
Magari finche non esce ufficialmente non e lo mettono quel rapporto
@hacnet, visto che i benchmark sono aggiornati ad oggi, credevo fosse nuovo

[maurilio968]

Originariamente inviato da bjt2

... ultimi post ...

Originariamente inviato da The3DProgrammer

... ultimi post ...

Quindi mi sembra che dallo spunto iniziale di discussione emerga un comportamento che può spiegare sia cinebench che il presunto comportamento nei giochi. E che questo sia inerente all'architettura nuova e non a eventuali bugs.

Qui oltre che i benchmark va visto il comportamento reale sul campo nell'uso daily in MT. Per entrambe le cose confido in Paolo.

Ho letto in giro (se non ho capito male) che anche il kernel di linux andrebbe compilato con un workaround per via di come è strutturata la cache di Bulldozer.

https://patchwork.kernel.org/patch/999102/


-----------------------------------------------
> From the thread:
>
>> Out of curiosity, what's the performance impact if the workaround is
>> not enabled?
>
> Up to 3% for a CPU-intensive style benchmark, and it can vary highly in
> a microbenchmark depending on workload and compiler.
>
> What are the odds that Microsoft would even bother with this?

0.0003% percent chance for a future major windows OS version kernel change for an AMD chip, but 100% chance if it were an intel one - with backports to all past major windows OS versions as well.

-----------------------------------

Non commento l'ultima frase sennò il capitano mi ridice che sono OT.