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

[The3DProgrammer]

Originariamente inviato da paolo.oliva2

Ed è infatti quello che dico anche io...
Cioè... a prescindere dalla quantità di FP, penso conti più la qualità, nel senso che poi l'IPC lo si valuta a prodotto finito.
Se un X4 Intel può andare più o meno di un X8 AMD, e fino a prova contraria l'X4 Intel ha 4 FPU, non vedo perché 4 FPU di BD dovrebbero condizionare il discorso ragionando sempre e solamente solo numericamente non tenendo conto che nel Thuban sono a 64bit per 1 core e in BD sono a 128bit per 2 core.

Secondo me, un utente che segue il TH e legge "BD X8 ha 4 FP mentre il Thuban ne ha 6" in continuazione e non legge la spiegazione tecnica di Bjt2 (ed i suoi post sono in netta minoranza) mi sembra chiaro che all'utente inesperto nella sua testa rimbalzi il fatto che 4 è inferiore a 6 e quindi = meno potenza.

cerchiamo di non ragionare per sentito dire per favore. Dove hai letto che l'FPU di thuban e' a 64 bit? L'FPU di thuban e' a 128 bit, esattamente come quella di BD. Ed e' in grado, NEL CASO MIGLIORE, di eseguire 2 op SSE FP per ciclo di clock, esattamente come UNA FPU di bd. La spiegazione di bjt2 l'ho letta, e infatti ha perfettamente ragione. Il fatto e' che bjt2 quando parla di "2 unita' FP" non si riferisce a 2 FPU complete, ma si riferisce alle 2 FMAC di BD. Le 2 FMAC sono interne alla SINGOLA FPU, e il fatto che lo scheduler possa assegnare 1 singola FMAC a + thread diversi non ne fa automaticamente una FPU completa. Per inciso, anche l'FPU di thuban ha 2 unita' interne (FADD e FMUL) ma oltre ad essere nettamente meno potenti delle 2 FMAC, non possono essere utilizzate in SMT e in alcune condizioni non possono lavorare in parallelo. Le spiegazioni vanno si lette, ma vanno anche capite se no non serve a nulla.

EDIT: Ovviamente mi riferisco al puro calcolo FP SIMD. Poi nell'FPU di BD ci sono ulteriori migliorie relative alle istruzioni SIMD int e alle vectorized move/load/store, ma sono state menzionate tante di quelle volte che e' inutile ripeterle ogni volta.

[paolo.oliva2]

Originariamente inviato da The3DProgrammer

cerchiamo di non ragionare per sentito dire per favore. Dove hai letto che l'FPU di thuban e' a 64 bit? L'FPU di thuban e' a 128 bit, esattamente come quella di BD. Ed e' in grado, NEL CASO MIGLIORE, di eseguire 2 op SSE FP per ciclo di clock, esattamente come UNA FPU di bd. La spiegazione di bjt2 l'ho letta, e infatti ha perfettamente ragione. Il fatto e' che bjt2 quando parla di "2 unita' FP" non si riferisce a 2 FPU complete, ma si riferisce alle 2 FMAC di BD. Le 2 FMAC sono interne alla SINGOLA FPU, e il fatto che lo scheduler possa assegnare 1 singola FMAC a + thread diversi non ne fa automaticamente una FPU completa. Per inciso, anche l'FPU di thuban ha 2 unita' interne (FADD e FMUL) ma oltre ad essere nettamente meno potenti delle 2 FMAC, non possono essere utilizzate in SMT e in alcune condizioni non possono lavorare in parallelo. Le spiegazioni vanno si lette, ma vanno anche capite se no non serve a nulla.

In sostanza, traducendo in un numero quantificatamente capibile da TUTTI.

FP Thuban potenza 100 per 1 core.
FP Buldozer per 2 core potenza? (Thuban = 200 cioè 100x2)

Perché nelle spiegazioni di Bjt2 io personalmente ho capito che l'FP condivisa di BD su 2 core risulterebbe comunque più potente e duttile rispetto a 2 FP su 2 core del Thuban.
Possibilissimo che abbia capito male io, però per i profani continuare a parlare di numero di FP e non quantificarne le potenze... non conduce a nulla di comprensibile perché per me 4 FP di BD contro le 6 del Thuban equivarrebbe a dire che BD in FP avrebbe una potenza del 50% inferiore a parità di frequenza rispetto al Thuban anche se con 2 core in più, cosa che comunque non scappa fuori anche dai bench (veri o falsi che siano) di Cinebench dove 4 FP di BD a +8% di frequenza superano o comunque equivalgono le 6 FP di un Thuban.
Quindi già da questo potremmo presumere che se una 1 FP del Thuban da' 100, 1 FP di BD darebbe 150 e non 100, mentre 2 FP del Thuban darebbero 200 e l'FP di BD darebbe 150 e non 200, comunque la vedi, non si può parlare di 4 FP o 6 FP indistintamente perché avrebbero potenze differenti, anche perché a questo punto ci sarebbe da quantificare anche il comportamento FP BD con 1 TH o 2 TH, dove presumibilmente il rapporto 150 BD 2TH a 100/200 1-2TH Thuban dovrebbe aumentare a favore di BD.

[The3DProgrammer]

Originariamente inviato da paolo.oliva2

In sostanza, traducendo in un numero quantitificamente capibile da TUTTI.

FP Thuban potenza 100 per 1 core.
FP Buldozer per 2 core potenza?

io direi cosi:

per 1 core
FP Thuban potenza MASSIMA 100
FP Thuban potenza MEDIA 30-40 (numero ideale stimato da me in via puramente teorica solo per rendere l'idea, quindi prendere con le pinze)

per 2 core
FPU BD potenza MASSIMA 100
FPU BD Potenza MEDIA 60-90 (idem come sopra)

Questo e', SECONDO me, la stima delle prestazioni di una SINGOLA FPU di BD per codice FP puro.

Stima della SOLA fpu, senza tener conto delle latenze aumentate, un po dappertutto, sia per quanto riguarda il sottosistema memoria che le latenze delle istruzioni vere e proprie (x esempio in BD le x87 hanno subito un tracollo in termini di latenze di esecuzione per cui e' anche possibile che su codice x87 BD vada anche + lento che thuban, ad esempio in SPI).

EDIT: per rendere ancora + chiara l'idea, un esempio di che impatto possa avere l'aumento delle latenze:

Prendiamo l'istruzione FDIV, in K10 viene eseguita se non sbaglio in minimo 18 cicli di clock. In BD invece, la latenza di FDIV e' aumentata a 42 cicli di clock.
Ora sappiamo che K10 e' in grado di eseguire 1 FDIV alla volta, mentre BD 2 grazie alle 2 FMAC. Supponiamo di dover eseguire 6 FDIV di seguito, indipendenti una dall'altra.

K10 6x18 cicli = 108 cicli di clock
BD 3 (2 alla volta)x42 cicli = 126 cicli di clock

K10 e' + veloce di BD a parita' di clock pur potendo eseguire una sola FDIV alla volta.

EDIT 2: Per rendere ancora + chiara la spiegazione sopra, vi riporto le condizioni in cui quelle latenze vengono valutate (riporto solo quelle di BD, nn so se quelle di k10 sono le stesse ma penso di si):

• The instruction is an L1-cache hit that has already been fetched and decoded, with the operations
loaded into the scheduler.
• Memory operands are in the L1 data cache.
• There is no contention for execution resources or load-store unit resources.
Each latency in the table denotes the typical execution time of the instruction when run in isolation on
a processor with any referenced memory locations already in the L1 cache. For real programs
executed on this highly aggressive superscalar family of processors, multiple instructions can execute
simultaneously; therefore, the effective latency for any given instruction's execution may be
overlapped with the latency of other instructions executing in parallel. An example of this effect can
be seen for an SIMD load-compute instruction like ADDPD reg, mem, which effectively adds 4 cycles
of latency (10 cycles total) over ADDPD reg, reg, which uses 6 cycles when run in isolation. In a
real program, however, the load portion of the instruction often occurs in parallel with earlier work,
effectively hiding the extra 4 cycles from the critical execution path. There are also other cases of
additional latencies that may be incurred in a real program that are not described in the latency table,
such as delays caused by L1 cache misses or contention for execution or load-store unit resources.

[bjt2]

Originariamente inviato da The3DProgrammer

io direi cosi:

per 1 core
FP Thuban potenza MASSIMA 100
FP Thuban potenza MEDIA 30-40 (numero ideale stimato da me in via puramente teorica solo per rendere l'idea, quindi prendere con le pinze)

per 2 core
FPU BD potenza MASSIMA 100
FPU BD Potenza MEDIA 60-90 (idem come sopra)

Questo e', SECONDO me, la stima delle prestazioni di una SINGOLA FPU di BD per codice FP puro.

Stima della SOLA fpu, senza tener conto delle latenze aumentate, un po dappertutto, sia per quanto riguarda il sottosistema memoria che le latenze delle istruzioni vere e proprie (x esempio in BD le x87 hanno subito un tracollo in termini di latenze di esecuzione per cui e' anche possibile che su codice x87 BD vada anche + lento che thuban, ad esempio in SPI).

EDIT: per rendere ancora + chiara l'idea, un esempio di che impatto possa avere l'aumento delle latenze:

Prendiamo l'istruzione FDIV, in K10 viene eseguita se non sbaglio in minimo 18 cicli di clock. In BD invece, la latenza di FDIV e' aumentata a 42 cicli di clock.
Ora sappiamo che K10 e' in grado di eseguire 1 FDIV alla volta, mentre BD 2 grazie alle 2 FMAC. Supponiamo di dover eseguire 6 FDIV di seguito, indipendenti una dall'altra.

K10 6x18 cicli = 108 cicli di clock
BD 3 (2 alla volta)x42 cicli = 126 cicli di clock

K10 e' + veloce di BD a parita' di clock pur potendo eseguire una sola FDIV alla volta.

EDIT 2: Per rendere ancora + chiara la spiegazione sopra, vi riporto le condizioni in cui quelle latenze vengono valutate (riporto solo quelle di BD, nn so se quelle di k10 sono le stesse ma penso di si):

• The instruction is an L1-cache hit that has already been fetched and decoded, with the operations
loaded into the scheduler.
• Memory operands are in the L1 data cache.
• There is no contention for execution resources or load-store unit resources.
Each latency in the table denotes the typical execution time of the instruction when run in isolation on
a processor with any referenced memory locations already in the L1 cache. For real programs
executed on this highly aggressive superscalar family of processors, multiple instructions can execute
simultaneously; therefore, the effective latency for any given instruction's execution may be
overlapped with the latency of other instructions executing in parallel. An example of this effect can
be seen for an SIMD load-compute instruction like ADDPD reg, mem, which effectively adds 4 cycles
of latency (10 cycles total) over ADDPD reg, reg, which uses 6 cycles when run in isolation. In a
real program, however, the load portion of the instruction often occurs in parallel with earlier work,
effectively hiding the extra 4 cycles from the critical execution path. There are also other cases of
additional latencies that may be incurred in a real program that are not described in the latency table,
such as delays caused by L1 cache misses or contention for execution or load-store unit resources.

La FP di Thuban ha 3 unità, spesso sottoutilizzate. La FP di BD ne ha 4, più potenti e potenzialmente più sfruttabili per lo scheduler migliore e per il fatto di avere due thread su di essa... In più nella FPU di BD molte istruzioni che sulla FPU di Thuban richiedevano una unità, sono "gratis"... Inoltre c'è maggiore flessibilità perchè le unità sono più generiche...

[paolo.oliva2]

Io avevo editato il mio post (sempre quel vizio ho ) ed avevo aggiunto dei valori dai bench.

Per le latenze... l'8150p dovrebbe essere peggiore da quel punto di vista perché le cache L1 e L2 viaggiano allo stesso clock del procio.

E' chiaro che architetturalmente queste latenze sono state definite da tempo in base a dei clock previsti e non si possono certamente cambiare.
Ad esempio, se la L2 sia stata concepita con latenza 10 per funzionamento 4,5GHz, ritroveremmo la stessa latenza 10 anche con funzionamento a 3,6GHz, che sarebbe quindi penalizzante (fortuna che c'è l'OC).

Ti dico questo perché se fai il rapporto con il Thuban, se questo prevedeva latenza 10 per clock 3,2GHz e poi BD aumenta la latenza a 12 perché girerebbe a 4,5GHz, in realtà sarebbe meno penalizzante del Thuban, ma tutt'altro se a 3,6GHz.

[The3DProgrammer]

Originariamente inviato da bjt2

La FP di Thuban ha 3 unità, spesso sottoutilizzate. La FP di BD ne ha 4, più potenti e potenzialmente più sfruttabili per lo scheduler migliore e per il fatto di avere due thread su di essa... In più nella FPU di BD molte istruzioni che sulla FPU di Thuban richiedevano una unità, sono "gratis"... Inoltre c'è maggiore flessibilità perchè le unità sono più generiche...

concordo pienamente, io infatti sto parlando di codice FP puro..ho scritto + su che se consideriamo anche le SIMD int la differenza aumenta ulteriormente..
Di tutte le migliorie che hai detto ne ho tenuto conto quando ho dato il "numerino magico" () infatti secondo me mediamente una singola fpu di BD nel caso medio andra' dal doppio a + del doppio di una singola FPU di K10..ma non sempre, e sicuramente questo non trasforma magicamente una FPU di BD in 2...

[The3DProgrammer]

per par condicio riporto anche un esempio di possibile throughput delle 2 FPU con la DIV SSE: (DIVPD)

K10: 22 cicli
BD: 27 cicli

su 6 FDIV eseguite sotto quelle condizioni, si ha:

K10 = 6x22 = 132 cicli
BD = 3x 27= 81 cicli

BD e' nettamente + veloce.


Spero di aver reso l'idea...

[liberato87]

@ the3dprogrammer ; bjt2

quindi.. in soldoni..
alla luce di quanto avete postato, quel risultato basso nel cinebench (quasi stesso score thuban @ 3.3ghz e bd @ 3.6ghz) è spiegabile o no?

EDIT

io su ocn ho chiesto a jf un commento su queste slide dato che non le aveva smentite direttamente e mi ha "risposto" (in realtà non è una risposta... ovviamente non pensavo che dicesse si provengono da noi però almeno che dicesse sono fake come il resto che è stato postato fino ad ora..)

Originariamente inviato da JF-AMD

I don't comment on that.
I know they are not my slides but I can't say if
a.) they are from AMD
b.) if they were fabricated somewhere else
c.) if they were AMD slides that someone altered.

I can only speak to the slides I make.

[The3DProgrammer]

Originariamente inviato da liberato87

@ the3dprogrammer ; bjt2

quindi.. in soldoni..
alla luce di quanto avete postato, quel risultato basso nel cinebench (quasi stesso score thuban @ 3.3ghz e bd @ 3.6ghz) è spiegabile o no?

bisogna vedere come sono stati eseguiti i test, io mi aspettavo un risultato ai livelli di un 2600k, un po inferiore alle mie attese quindi ma di sicuro non mi aspettavo 10 o 12...
Poi come detto in precedenza solo cinebench non basta, potrebbe essere "indigesto" a bd data la differenza nelle latenze delle istruzioni...magari fa quel punteggio in cinebench ma poi va + di un 990x in 3dstudio o blender... tutto e' possibile.

[maurilio968]

Originariamente inviato da The3DProgrammer

L'FPU di thuban e' a 128 bit, esattamente come quella di BD. Ed e' in grado, NEL CASO MIGLIORE, di eseguire 2 op SSE FP per ciclo di clock, esattamente come UNA FPU di bd. La spiegazione di bjt2 l'ho letta, e infatti ha perfettamente ragione. Il fatto e' che bjt2 quando parla di "2 unita' FP" non si riferisce a 2 FPU complete, ma si riferisce alle 2 FMAC di BD. Le 2 FMAC sono interne alla SINGOLA FPU, e il fatto che lo scheduler possa assegnare 1 singola FMAC a + thread diversi non ne fa automaticamente una FPU completa. Per inciso, anche l'FPU di thuban ha 2 unita' interne (FADD e FMUL) ma oltre ad essere nettamente meno potenti delle 2 FMAC, non possono essere utilizzate in SMT e in alcune condizioni non possono lavorare in parallelo.

quindi abbiamo (restando nel codice fp):

thuban: 6 fpu ciascuna con 1 fadd e 1 fmul = 6 fadd e 6 fmul
bd 8150p: 4 fpu ciascuna con 2 fmac = 8 fmac

Quindi ci stà che nel cinebench, le 6 fpu (6fmul+6fadd) del thuban 1100t vadano come le 4fpu(2x4 fmac) di bd 8150p , ovviamente il tutto a frequenze default.

Ho capito bene ?

[The3DProgrammer]

Originariamente inviato da maurilio968

quindi abbiamo (restando nel codice fp):

thuban: 6 fpu ciascuna con 1 fadd e 1 fmul = 6 fadd e 6 fmul
bd 8150p: 4 fpu ciascuna con 2 fmac = 8 fmac

Quindi ci stà che nel cinebench, le 6 fpu (6fmul+6fadd) del thuban 1100t vadano come le 4fpu(2x4 fmac) di bd 8150p , ovviamente il tutto a frequenze default.

Ho capito bene ?

la situazione e' + complicata e non si puo' rispondere si o no direttamente, nei post successivi a quello che hai quotatocerco di chiarire un po la situazione...

poi libero di essere smentito eh, ma quei numeri e quei calcoli li ho presi dal software development manual di k10 e BD.

[marchigiano]

ma può essere che la fpu era stata progettata per eseguire due istruzioni 128bit alla volta, poi però nei test sul silicio è venuto fuori un qualche problema e le abbiano castrate a una sola operazione per volta?

[scrat1702]

Originariamente inviato da marchigiano

ma può essere che la fpu era stata progettata per eseguire due istruzioni 128bit alla volta, poi però nei test sul silicio è venuto fuori un qualche problema e le abbiano castrate a una sola operazione per volta?

Questo sarebbe un bug gravissimo, e siccome e ormai assodato che di bug gravi non ce ne sono tenderei ad escludere un'ipotesi del genere. Potrebbe essere che sia stata studiata così sin dall'inizio.

[maurilio968]

Originariamente inviato da liberato87

io su ocn ho chiesto a jf un commento su queste slide dato che non le aveva smentite direttamente e mi ha "risposto" (in realtà non è una risposta... ovviamente non pensavo che dicesse si provengono da noi però almeno che dicesse sono fake come il resto che è stato postato fino ad ora..)

Originariamente inviato da JF-AMD Guarda i messaggi
I don't comment on that.
I know they are not my slides but I can't say if
a.) they are from AMD
b.) if they were fabricated somewhere else
c.) if they were AMD slides that someone altered.

I can only speak to the slides I make.

giusto per alleggerire un po' la discussione:

io (ripeto: scherzando) le interpreto così : JF ha detto una cosa vera in ciascuna delle tre opzioni a),b),c) quindi se le "sommiamo" ti ha risposto:

"Le slide sono materiale di AMD (e dovevano restare sotto nda) ma sono state fatte fare da qualcuno in altra sede (ecco perchè non è stato rispettato l'nda) ed infine qualcunaltro ancora le ha alterate (quello che le ha avute a disposizione violando l'nda) prima di pubblicarle" e infine ha aggiunto "io le mie slides non le ho date a nessun altro, ovvero non è colpa mia se sono uscite queste sotto nda" e perciò io ho il sospetto che sia prorpio lui "il colpevole"

[Mparlav]

Originariamente inviato da be_inspired79

Non c'è scritto nulla di Zambezi perchè non era inserito nelle previsioni di vendita per il 3Q. Il fatto che non venga citato non indica nè che è in ritardo nè (soprattutto) che non lo sia.

Appunto.
Come si fa' a dire che Zambezi potrebbe essere in ritardo o ha problemi di produzione se Amd non ne ha parlato?

[The3DProgrammer]

Originariamente inviato da marchigiano

ma può essere che la fpu era stata progettata per eseguire due istruzioni 128bit alla volta, poi però nei test sul silicio è venuto fuori un qualche problema e le abbiano castrate a una sola operazione per volta?

no, c'e' scritto chiaramente nel sw development manual che le fmac possono lavorare in parallelo.

[xk180j]

Originariamente inviato da Mparlav

Appunto.
Come si fa' a dire che Zambezi potrebbe essere in ritardo o ha problemi di produzione se Amd non ne ha parlato?

si pensa che potrebbe essere in ritardo per il semplice motivo che a una decina di giorni dalla PRESUNTA data d'uscita non è ancora stato confermato nulla da amd

[Pat77]

Originariamente inviato da xk180j

si pensa che potrebbe essere in ritardo per il semplice motivo che a una decina di giorni dalla PRESUNTA data d'uscita non è ancora stato confermato nulla da amd

E aggiungerei per l'ennesima volta.

[maurilio968]

Originariamente inviato da The3DProgrammer

la situazione e' + complicata e non si puo' rispondere si o no direttamente, nei post successivi a quello che hai quotatocerco di chiarire un po la situazione...

poi libero di essere smentito eh, ma quei numeri e quei calcoli li ho presi dal software development manual di k10 e BD.

li ho letti, e sono stati molto chiari per me. Grazie.

Riassumendo quanto ho capito direi che:

data l'architettura completamente nuova non ci si può aspettare che in tutti gli scenari le nuove implementazioni rendano più delle vecchie

Però (notare che in quanto segue userò il condizionale):

AMD proprio perchè passa ad una nuova architettura dovrebbe comunque assicurarsi egualmente che in tutti gli scenari le nuove cpu ,da lei stessa marchiate FX quindi cpu top, vadano >= dei Thuban 1100T.

E nella versione 8150p , se stiamo alle ultime controverse slides, questo sembra essere stato fatto puntando al "minimo sindacale" vedi test cinebench ( e potrebbero in seguito esserci altri test in cui il 8150p va solo un po' più di un thuban 1100T ).

Ora se I BD in versioni inferiori (ma anch'essi tutti marchiati FX) al 8150p in certe circostanze (per esempio cinebench, adobe suite, 3d studio max, ansys) andassero meno di un thuban 1100T saremmo sotto a questo "minimo sindacale".

Cerco di spiegarmi meglio con un esempio: ad inizio 2012 quando il 1100t non sarà più in vendita, un utente AMD interessato a prestazioni "tipo" cinema4d ( o adobe suite, 3d studio max, ansys) avrebbe paradossalmente una scelta peggiore in casa AMD.

Infatti ha due scelte:

- compra un 8150p che però costerebbe (stando sempre alle indiscrezioni) più di un 1100t andando solo poco di più nel campo che interessa a lui

- compra un modello inferiore tipo un Fx-6100 che magari costerà (stime dicono 175$) quanto un 1100T andando però meno del 1100T nel campo che interessa a lui

Quindi commercialmente AMD ha tolto un processore vecchio che in certi utilizzi va meglio e costa uguale al nuovo che lo sostituisce.

Pur considerando che questa è la prima incarnazione di future cpu molto potenti, AMD avrebbe fatto un errore a far uscire delle cpu, per di più marchiandole FX , che in certi scenari andrebbero meno del top di generazione precedente.

Perchè se il 8150p fa lo stesso punteggio del 1100t al cinebench allora che punteggio farà FX-6100?

In sostanza: qui per ora abbiamo analizzato solo un 8150p ma se proiettiamo quelle slide su un FX-6100 ho il sospetto che in certi scenari passando da un 1100T ad un FX-6100 pensando di guadagnarci si avrebbero delle amare sorprese.

E' per questo che penso che quelle slides non siano quelle del reale 8150p che vedremo tra poco.

Credo e spero che un già FX-6100 andrà meglio di un thuban 1100T e questo in tutti gli scenari. Se sarà altrimenti per mè sarà stato un mezzo flop.

E notare che non ho mai citato la controparte blu in nessun punto del discorso.

[Korn]

io spero che almeno i 6xxx vadano meglio dei thuban e la fascia bassa sia coperta dai quad e llano, non chiedo altro