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

[Uncle Scrooge]

Originariamente inviato da calabar

In realtà, per quello che dicevo sopra, no. L'ipc è sempre 90, il gap nei task che usano pochi thread viene recuperato grazie al turbo e la cache condivisa nel modulo.

Appunto, volevo dimostrare proprio questo e infatti walrus ci ha capito entrambi

Stavo dicendo la stessa cosa tua.

[calabar]

Originariamente inviato da Veradun

Siamo ritornati di nuovo al famoso 80%?

Quell'80% è la differenza fra il throughput di un modulo BD rispetto a due singoli core se BD fosse stato progettato in un altro modo, non rispetto ad usare un solo core del modulo.

Che è appunto quello che stavamo dicendo e su cui alla fine abbiamo concordato!

Ma il punto non è tanto il fatto che il 90% (180%) sia relativo ad un BD ipotetico, perchè anche JF ha spiegato che usando un solo core con tutta la logica condivisa di un modulo l'ipc di BD si avvicinerebbe a quell'ipotetico 100%, (200%) quanto il fatto che JF abbia chiarito che BD non opererà in quel modo, come dicevamo sopra.

[Uncle Scrooge]

Originariamente inviato da Veradun

Siamo ritornati di nuovo al famoso 80%?

Quell'80% è la differenza fra il throughput di un modulo BD rispetto a due singoli core se BD fosse stato progettato in un altro modo, non rispetto ad usare un solo core del modulo.

L'IPC non è 80, 90 o 100, o meglio, in questa scala di valori non è presente Thuban, ma diverse architetture, una è BD e l'altra un'ipotesi accademica mai realizzata di un BD progettato tradizionalmente e senza CMT. Quindi anche prendendo questo 90 per buono (ed è una cifra così, un po' sparata) non esistono termini di paragone cui associarlo e confrontarlo per trarne conclusioni.

Di nuovo, stiamo dicendo tutti la stessa cosa. Io avevo fatto un ragionamento ipotetico ed ultra semplificato tanto per spiegarmi, pur sapendo che non era rigorosamente giusto

Avevo scritto:

In altre parole, dicendo una cosa sbagliata ma che aiuta a capire quello che intendo, c'è un:

- IPC del primo core...
...

[Walrus74]

Originariamente inviato da Veradun

...CUT...

Originariamente inviato da calabar

Che è appunto quello che stavamo dicendo e su cui alla fine abbiamo concordato!

Originariamente inviato da Uncle Scrooge

Di nuovo, stiamo dicendo tutti la stessa cosa.

Sarà mica colpa mia??


Giuro che non l'ho fatto apposta...e cmq ora ho capito

[paolo.oliva2]

Originariamente inviato da Walrus74

Paolo, secondo me dimentichi una cosuccia...
A parte che poni una crescita lineare delle prestazioni alla crescita dei core ma diciamo pure che possa essere così, la stessa AMD ha dichiarato con slides ufficiali che il "secondo core" di ogni modulo apporta una crescita dell'80% delle performances, non il 100%.

Tipo questa:



Ora, possiamo dire che il primo core/cluster dà 100 e il secondo dà 80 in un modulo?
Bene quindi ogni modulo BD che in un ideale dual core darebbe 200 in realtà da 180.

Mi sono permesso di rifare le tue tabelle con questa nuova ipotesi:

Phenom x4 vs BD x4

Il 400 e 360 sta per il fatto che i due moduli BD fanno 180x2


Thuban x6 vs BD x6

Il 600 e 540 sta per il fatto che i tre moduli BD fanno 180x3

Thuban x6 vs BD x8

Il 600 e 720 sta per il fatto che i quattro moduli BD fanno 180x4

Direi che così potrebbero essere più realistici no?

AMD ha detto che il CMT ridurrebbe le prestazioni rispetto ad un teorico BD senza CMT, non ha mai detto che riduce le prestazioni rispetto a un Phenom II. Siccome un BD senza CMT non esiste, noi non potremmo mai sapere di quanto.

Inoltre quello che ha detto JF è un "fino a" ma non un SEMPRE, quindi le prestazioni sono soggettive per il tipo di software usato.

Per il discorso dell'incremento dei core, io ho scritto "fino a", in quanto non è corretto né riportare il minimo né certamente medie. Ti parrebbe corretto che aggiungere un core (quindi 2 TH su 2 core fisici per quanto condivisi) possa dare un incremento inferiore di un SMT che fa girare 2 TH sullo stesso core? (mi pare indiscutibile che non si possa sbandierare il +50% dell'SMT con winzip e pensare che 2 core possano fare meno).

Inoltre, dalla tabella sopra, ti posso dire che era un confronto teorico, perché se parliamo di confronti tipo BD X8 vs BD X4, sarebbe possibile far girare 4 TH su 4 moduli, quindi 1 TH a modulo, e se parli del CMT, a questo punto avremmo un super-core, con una L2 e L3 interamente dedicata ad 1 TH quindi totalmente il contrario di un discorso CMT.

Un altro aspetto che mi sono tenuto MOLTO conservativo è rappresentato dalle frequenze. Io ho preso quelle def, ma per quello che sappiamo dalla rete, è molto diverso parlare di Thuban 3,3GHz e BD 3,6 o 3,9GHz quando sappiamo che l'incremento di OC sul Thuban è 1,2-1,3GHz tirato per i capelli ricorrendo a liquido e WC, mentre un BD X8 incrementerebbe di 1,4GHz rimanendo ancora ad aria con il dissi stock.

Quindi se rifacessi le tabelle sopra, potrei mettere un 980 X4 e 1090T/1100T a 4GHz ad aria, mentre per BD magari 5GHz, il che incrementerebbe e di parecchio la differenza di prestazioni sempre a favore di BD.

Comunque dai risultati di pseudo-bench che ci pervengono dalla rete, io suggerisco di guardare anche quelli positivi e non solo quelli negativi. In pratica, quello che voglio dire, è che un procio che può dare 100 può anche dare 80 se la piattaforma che lo utilizza non è ottimizzata a dovere, ma in nessun caso potrebbe fornire un risultato superiore alle capacità del procio. Quindi se di risultati ottimi ci sono stati, non capisco il motivo per il quale si debba perforza fare medie di IPC solamente su quelli scarsi mentre sarebbe ben più logico farla su quelli ottimi.

Un altro punto a favore di BD è che a tutt'oggi si sceglie il procio per il tipo di lavoro che si vuole fare in base a queste riflessioni:

- tipo di applicazioni (un X4 avrebbe clock finali più alti rispetto ad un X6), ma non vale per BD, in quanto un BD X8 è tale e uguale a BD X6 e X4 perché spegne i moduli e le frequenze finali a parità di TH attivi risultano le stesse.

- costo (come sopra...) se un X4 basta alle proprie necessità, non c'è alcun motivo per spendere un tot di più per avere poco di più in MT e addirittura meno in ST. Ma anche questo non vale assolutamente per BD, in quanto addirittura un BD X8 avrebbe un costo/performances inferiore rispetto ad un X4.

Io ho un Thuban X6, di certo non upgrado né a un Llano né a un BD X4-X6, ma ad un BD X8 di corsa ed a occhi chiusi... quindi non trovo nemmeno un senso a confrontare un Phenom II X4 a 130€ con un BD X4 a 50€ in più quando aggiungeno 50€ mi ritroverei un X8.

[Walrus74]

Originariamente inviato da paolo.oliva2

...CUT...
perché se parliamo di confronti tipo BD X8 vs BD X4, sarebbe possibile far girare 4 TH su 4 moduli, quindi 1 TH a modulo, e se parli del CMT, a questo punto avremmo un super-core, con una L2 e L3 interamente dedicata ad 1 TH quindi totalmente il contrario di un discorso CMT.
...CUT...

Ok su tutto, mi avevano già spiegato Calabar, Uncle Scrooge e Veradun...

Invece, ho lasciato una parte del tuo discorso nel quote perchè mi sembra molto interessante.
Cioè avere un super-core che lavora su un thread unico.
Quindi differente da quanto diceva Calabar:

Originariamente inviato da calabar

Anche io pensavo che BD avrebbe potuto spegnere i core a livello di modulo garantendo, grazie ad un core che usufruiva di tutta la logica condivisa del modulo, prestazioni migliori. Ma JF ha smentito questa soluzione negli attuali bulldozer.

Cioè non spegnere un cluster in un modulo ma utilizzare il modulo intero (cioè due cluster con cache condivisa ecc ecc) per elaborare un thread singolo?
E' fattibile? Sarebbe spettacolare!

[Heimdallr]

Originariamente inviato da Walrus74

Cioè non spegnere un cluster in un modulo ma utilizzare il modulo intero (cioè due cluster con cache condivisa ecc ecc) per elaborare un thread singolo?
E' fattibile? Sarebbe spettacolare!

No è proprio questo che JF ha smentito, un modulo non farà girare un solo thread ma conviene riempire i moduli per sfruttare il turbo.

[paolo.oliva2]

http://www.hwupgrade.it/news/cpu/apu...012_38554.html

Il debutto della prossima generazione di APU AMD per sistemi desktop e notebook di fascia media, nota con il nome in codice di Trinity, dovrebbe avvenire nel corso dei primi mesi del prossimo anno. Stando a quanto anticipato da Thomas Seifert, CFO dell'azienda americana e sino ad alcune settimane fa CEO ad interim, il debutto delle soluzioni che prenderanno il posto delle APU AMD della serie A avverrà già a inizio 2012 e non a metà anno.

Direi che sarebbe improponibile realizzare un APU su core BD se i core BD non fossero già belli a puntino... quindi direi che ciò scarterebbe parecchie cose, in primis i ventilati bug di BD e in secondo luogo... per forza di cose BD FX deve uscire prima di Trinity, ma certamente non solo il giorno prima. Manca poco a BD X8, veramente poco.

[paolo.oliva2]

Originariamente inviato da Walrus74

Cioè non spegnere un cluster in un modulo ma utilizzare il modulo intero (cioè due cluster con cache condivisa ecc ecc) per elaborare un thread singolo?
E' fattibile? Sarebbe spettacolare!

JF a proposito ha detto che non è "conveniente".
Però... essendo responsabile settore server, può darsi che sia più abituato a ragionare W/potenza.

Cioè... se si fanno girare 2 TH a modulo, teorizzando un -10% di potenza, avrebbe comunque un consumo ben inferiore rispetto alla potenza espressa anche ipotizzando un +20 ma con 2 moduli accesi.

Per il discorso del turbo... ancora non sappiamo se si potrà disattivare o meno... ma io non condivido il discorso Turbo di JF, in quanto il turbo sarebbe la prima cosa che disabiliterei ed imposterei la frequenza def ad un valore ben superiore rispetto a quella massima Turbo. A me non interessano i consumi, ma la potenza. Poi ci sarà K10stat che li abbasserà quando si trova in idle...

[paolo.oliva2]

Edit, bufala

[Korn]

Originariamente inviato da paolo.oliva2

http://www.hwupgrade.it/news/cpu/apu...012_38554.html

Il debutto della prossima generazione di APU AMD per sistemi desktop e notebook di fascia media, nota con il nome in codice di Trinity, dovrebbe avvenire nel corso dei primi mesi del prossimo anno. Stando a quanto anticipato da Thomas Seifert, CFO dell'azienda americana e sino ad alcune settimane fa CEO ad interim, il debutto delle soluzioni che prenderanno il posto delle APU AMD della serie A avverrà già a inizio 2012 e non a metà anno.

Direi che sarebbe improponibile realizzare un APU su core BD se i core BD non fossero già belli a puntino... quindi direi che ciò scarterebbe parecchie cose, in primis i ventilati bug di BD e in secondo luogo... per forza di cose BD FX deve uscire prima di Trinity, ma certamente non solo il giorno prima. Manca poco a BD X8, veramente poco.

ma non doveva, trinity, avere i core di bd2

[kiriranshelo]

Originariamente inviato da Korn

ma non doveva, trinity, avere i core di bd2

Infatti verrà fuori con i core BD nella versione Piledriver, ovvero la rev 2 di BD. Leggi bene la notizia

Originariamente inviato da HWUpgrande

Le soluzioni Trinity riprenderanno l'architettura base delle APU Llano in quanto integreranno componente CPU sino a 4 core come massimo accanto ad una GPU compatibile con le API DirectX 11. Le differenze saranno in ogni caso notevoli: le proposte Trinity saranno infatti basate su core della famiglia Bulldozer, gli stessi per architettura base che AMD proporrà con le soluzioni della famiglia FX attese al debutto nel corso del quarto trimestre 2011. Nello specifico si tratta di soluzioni Piledriver, comuni alla famiglia di CPU desktop top di gamma attese per il 2012 che prenderanno il posto delle soluzioni FX.

[Phenomenale]

Tanto per parlare di smentite di JF, eccone altre fresche fresche:

3 domande:
1) This reminds me of when AMD also claimed Barcelona was 40% faster than any other x86 out there, including Kentsfield.
2) Aside from that, the lack of a Bulldozer-aware scheduler in Windows 7 may also have an effect on this.
3) While AMD claims that this invalidates the *False* benchmarks, I would argue against that: there *is* no such scheduler available at this point.

JF gentilmente da 3 risposte:
1. The 40% claim was a server claim, not a client claim, and it was true. There were several places (memory througput and 4P especially) that were 40% or more. the enthusiast community jumped on the claim and morphed it into a kentsfield comparison but the claim was made against server products because it was the general manager of the server business that made it.
2. Your statement about a "lack of bulldozer aware scheduler in win 7" is not true.
3. The false benchmarks have no bearing on scheduler, most are probably done in excel and photoshop be people who do not even have processors in their hands.

Il mistero continua!

[bjt2]

Originariamente inviato da paolo.oliva2

JF a proposito ha detto che non è "conveniente".
Però... essendo responsabile settore server, può darsi che sia più abituato a ragionare W/potenza.

Cioè... se si fanno girare 2 TH a modulo, teorizzando un -10% di potenza, avrebbe comunque un consumo ben inferiore rispetto alla potenza espressa anche ipotizzando un +20 ma con 2 moduli accesi.

Per il discorso del turbo... ancora non sappiamo se si potrà disattivare o meno... ma io non condivido il discorso Turbo di JF, in quanto il turbo sarebbe la prima cosa che disabiliterei ed imposterei la frequenza def ad un valore ben superiore rispetto a quella massima Turbo. A me non interessano i consumi, ma la potenza. Poi ci sarà K10stat che li abbasserà quando si trova in idle...

Io sono sempre convinto, specialmente per BD che non dovrebbe avere il muro come il thuban, che in OC conviene non disabilitare il turbo. Si devono solo fare test in più... Uno con tutta la CPU al 100% e si trova il limite per il clock base, uno con un bench che usa tutti i core ma poco stressante (da definire... Magari uno spec int...) per trovare il limite con il primo turbo e uno per il turbo con la metà dei core... Si potrebbro guadagnare anche 200-300MHz a step di turbo... Questa volta dovrebbero essere il TDP e le temperature il limite per salire...

[liberato87]

ciao ragazzi
guardando i test di coolaear ci sta qualcosa che non quadra, sopratutto in aida64.

a sinistra è lo screen di aida64 fatto "teoricamente" con amd fx a 4ghz e con nb a 2600 con ram 1333 cl9
a destra, mio screen fatto col thuban a 4ghz e nb a 2800 (quindi dovrebbero essere meglio) ram a 1600 6-6-6-18 (decisamente più tirate!)






COSA MI SEMBRA STRANO

1 RIGA, quella relativa alle ram.
nel bench di BD : migliori risultati in read-write-copy ma latenza altissima!

L1 : write è un terzo del thuban, copy la metà (non riconducibile a un nb maggiore di 200mhz)

L2 : read meno della metà.
write più o meno uguale.
copy superiore!
latenza molto superiore.

L3 : read superiore
write 1/3
copy va la metà
latenza doppia!

ciò che mi sembra strano, per quanto riguarda le ram è che la banda sembra effettivamente aumentata anche se in quel test si usano ram a 1333! però perchè le latenze sono così esageratamente alte?
i risultati della cache poi, mostrano sicuramente qualche bug perchè le prestazioni sono troppo altalenanti (molto meglio di là, 3 volte in meno da un altra parte..)

[dav1deser]

Per quanto riguarda il discorso RAM, le latenze dei moduli usati con BD sono del 50% superiori ai tuoi moduli (9-9-9 per BD vs 6-6-6 per le tue) quindi quel risultato dovrebbe essere dovuto a questo.

[The3DProgrammer]

Originariamente inviato da liberato87

ciao ragazzi
guardando i test di coolaear ci sta qualcosa che non quadra, sopratutto in aida64.

a sinistra è lo screen di aida64 fatto "teoricamente" con amd fx a 4ghz e con nb a 2600 con ram 1333 cl9
a destra, mio screen fatto col thuban a 4ghz e nb a 2800 (quindi dovrebbero essere meglio) ram a 1600 6-6-6-18 (decisamente più tirate!)






COSA MI SEMBRA STRANO

1 RIGA, quella relativa alle ram.
nel bench di BD : migliori risultati in read-write-copy ma latenza altissima!

L1 : write è un terzo del thuban, copy la metà (non riconducibile a un nb maggiore di 200mhz)

L2 : read meno della metà.
write più o meno uguale.
copy superiore!
latenza molto superiore.

L3 : read superiore
write 1/3
copy va la metà
latenza doppia!

ciò che mi sembra strano, per quanto riguarda le ram è che la banda sembra effettivamente aumentata anche se in quel test si usano ram a 1333! però perchè le latenze sono così esageratamente alte?

Latenze alte a livello delle cache L1 e L2 ci stanno perche' previste (l'L1 e' totalmente diversa da quella di K10, la L2 ha latenze + alte per avere clock + elevati)

[liberato87]

Originariamente inviato da The3DProgrammer

Latenze alte a livello delle cache L1 e L2 ci stanno perche' previste (l'L1 e' totalmente diversa da quella di K10, la L2 ha latenze + alte per avere clock + elevati)

si si questo mi ricordo che tu lo dici da parecchio tempo..
però mi sembrano molto strani gli altri valori (read write copy), cioè sono troppo altalenanti.

Originariamente inviato da dav1deser

Per quanto riguarda il discorso RAM, le latenze dei moduli usati con BD sono del 50% superiori ai tuoi moduli (9-9-9 per BD vs 6-6-6 per le tue) quindi quel risultato dovrebbe essere dovuto a questo.

sicuramente. però perchè gli altri valori read write copy sono nettamente meglio nonostante siano appunto 1333 cl9 vs 1600 cl6? non possono 200mhz di nb fare questa differenza



guarda qua! questo è superbench cpu a quas 4.4ghz , ram a 2133 cl7 e nb a 3200 e se guardi la prima riga riguardante le ram puoi vedere come non ci siano (aparte per la latenza ma questo è "speigabile") grossissime differenze in read write e copy (dove addirittura il bd on ram a 1333 cl9 e nb a 2600 è superiore..)

io dico che i risultati sono incongruenti tra loro.
molta più banda è un miglioramento (se in read copy e write si hanno gli stessi valori tra ram a 1333 cl9 con nb a 2600 e cpu a 4ghz VS ram a 2133 cl7, cpu a 4.4ghz e nb a 3200!)
i risultati delle cache sono troppo strani IMHO. (allineati col thuban, poi in alcuni vanno un terzo o meno della metà, altri sono meglio.. boh)

[Darrosquall]

scusate.. ma ieri non dovevano presentare gli 8 core?

[OPP]

Originariamente inviato da liberato87

sicuramente. però perchè gli altri valori read write copy sono nettamente meglio nonostante siano appunto 1333 cl9 vs 1600 cl6? non possono 200mhz di nb fare questa differenza

penso che sia per via di un memory controller migliorato

ho visto che usi una versione vecchia di AIDA, penso che per comparare meglio i risultati dovresti usare la stessa