[Thread Ufficiale] Aspettando ZEN

[bjt2]

Originariamente inviato da cdimauro

Ma un core Zen non dovrebbe avere all'incirca gli stessi transistor di un core XV?

No, di un modulo BD... In realtà forse un po' meno, perchè mancano 2 AGU, due unità di L/S, 0.5-1.5MB di L2 e forse dei decoder, ma in più ha le varie feature e un po' più di L1...

Originariamente inviato da cdimauro

Ma anche no: riesce a guadagnare qualcosa soltanto in un paio di test. Negli altri non c'è guadagno, o è addirittura sotto la precedente (micro)architettura (vedi MySQL, che non è certo un engine db poco usato: tutt'altro).

Vabeh, volevo dire che in MT pesante con parecchi thread a basso IPC fa un po' meno schifo...

[Piedone1113]

Originariamente inviato da cdimauro

Molto molto in fondo, perché senza dati completi sono test che lasciano il tempo che trovano.

Vedi il test di B&C, in cui marchigiano ha ragione: mancano i dati di SuperPi. Che fine hanno fatto?

Giusto per essere chiari, se vuoi fare un test serio, devi lanciare contemporaneamente le applicazioni da un tempo x a uno y, e vedere quanto riescano a macinare all'esatto scadere del tempo y.

Ho notato che la fluidità di sistema su architettura core (ps il core duo non ha ht, refuso o confusione) si va a farsi friggere sopro a 3 th per core.
BD invece regge bene fino a 4th a core (th ad uso intensivo cpu).
Però a parità di carico (con architettura core in crisi di fluidità) le cpu intel (con ht, perchè paragoniamo smt vs cmt tra i due competitor) intel esegue sempre prima tutti i task (anche quando sembra piantato).
e la differenza di prestazioni tra i7 2600 e 8150 rimane pressocchè costante (in percentuale) con alcune situazioni dove addirittura il divario aumenta.
Test fatti in proprio perchè ho cercato di capire il comportamento di bd che sembra sempre essere sotto carico leggero, anche se non si vedono risultati al top.
Secondo me avere cmt + ht 2 vie avrebbe mitigato in alcuni scenari il distacco vs core, ma allora molto meglio architettura smt pura (magari smt4) perchè cmt+smt avrebbe avuto un costo di sviluppo e transistor molto elevato.

[bjt2]

Originariamente inviato da Piedone1113

Ho notato che la fluidità di sistema su architettura core (ps il core duo non ha ht, refuso o confusione) si va a farsi friggere sopro a 3 th per core.
BD invece regge bene fino a 4th a core (th ad uso intensivo cpu).
Però a parità di carico (con architettura core in crisi di fluidità) le cpu intel (con ht, perchè paragoniamo smt vs cmt tra i due competitor) intel esegue sempre prima tutti i task (anche quando sembra piantato).
e la differenza di prestazioni tra i7 2600 e 8150 rimane pressocchè costante (in percentuale) con alcune situazioni dove addirittura il divario aumenta.
Test fatti in proprio perchè ho cercato di capire il comportamento di bd che sembra sempre essere sotto carico leggero, anche se non si vedono risultati al top.
Secondo me avere cmt + ht 2 vie avrebbe mitigato in alcuni scenari il distacco vs core, ma allora molto meglio architettura smt pura (magari smt4) perchè cmt+smt avrebbe avuto un costo di sviluppo e transistor molto elevato.

Forse la quantità elevata di TLB di BD, sopratutto L2, aiuta... Non so se tra un task switch e l'altro la cache TLB viene azzerata, ma se così non fosse, il maggior numero di TLB potrebbe spiegare la questione del maggior numero di thread supportati senza piantaris...

[Piedone1113]

Originariamente inviato da bjt2

Forse la quantità elevata di TLB di BD, sopratutto L2, aiuta... Non so se tra un task switch e l'altro la cache TLB viene azzerata, ma se così non fosse, il maggior numero di TLB potrebbe spiegare la questione del maggior numero di thread supportati senza piantaris...

io invece ho supposto che le differenze fossero dovute alla cache in generale:
64 th non possono essere contenuti (i dati ad essi relativi) tutti nella cache l3 di intel, mentre nella cache l2+l3 di bd potrebbero starci (quindi l'architettura intel che è affamata di dati starebbe per molto tempo relativo a pescare dati in ram, mentre quella amd avendo una cache più grande (come somma ) e macinando meno dati accede metà volte (credo che sia nell'ordine di 4 a 1 intel vs amd) alla ram di sistema per ricevere dati che servono al momento dando l'impressione di essere maggiormente reattivo.
Dico questo perchè il comportamento che si ha con un i7 "piantato" mi ricorda tanto i sitemi che swappano su disco perchè hanno una memoria ram esigua (tipo xp con 128mb ram

[bjt2]

Originariamente inviato da Piedone1113

io invece ho supposto che le differenze fossero dovute alla cache in generale:
64 th non possono essere contenuti (i dati ad essi relativi) tutti nella cache l3 di intel, mentre nella cache l2+l3 di bd potrebbero starci (quindi l'architettura intel che è affamata di dati starebbe per molto tempo relativo a pescare dati in ram, mentre quella amd avendo una cache più grande (come somma ) e macinando meno dati accede metà volte (credo che sia nell'ordine di 4 a 1 intel vs amd) alla ram di sistema per ricevere dati che servono al momento dando l'impressione di essere maggiormente reattivo.
Dico questo perchè il comportamento che si ha con un i7 "piantato" mi ricorda tanto i sitemi che swappano su disco perchè hanno una memoria ram esigua (tipo xp con 128mb ram

Può essere... INTEL ha 2.5MB di L3 per core, perchè inclusiva... BD 2+1+ la L1... Però la differenza non è molta... 512 KB...

[Piedone1113]

Originariamente inviato da bjt2

Può essere... INTEL ha 2.5MB di L3 per core, perchè inclusiva... BD 2+1+ la L1... Però la differenza non è molta... 512 KB...

Gia, non è molta, ma intel "consuma" più dati cache di quella amd:
ogni secondo con 4 th a core intel utilizza 3 mb di dati cache (e qui il sistema che va a scatti ), amd invece ne consuma 2,5 a modulo (sempre con 4 th) con il sistema più reattivo.
Ma il troghtout è 5 per intel, 4 per amd (sarebbe superiore la differenza ma semplifichiamo)
Amd si avvantaggio solo con th dal basso ipc e tantissimi dati da pescare nella cache pareggiando quasi le prestazioni (non dimentichiamoci che bd ha una latenza cache molto superiore e quindi il "vantaggio" teorico viene limitato molto da questo)

[paolo.oliva2]

Cinebench, come bench, riesce a contenere tutti i dati nella cache?
A suo tempo avevo fatto dei test-bench settando i TH, da 8 a 16, 32, 64.
Non mi ricordo quando BD calava le prestazioni, se a 32 o 64 TH, però sarebbe interessante fare la stessa cosa con un i7.

P.S.
Non posso usare l'8370 perchè mi sono preso 3 vga 480 (le altre sono saltate) che hanno solamente l'uscita HDMI ed io non ho l'adattatore VGA

@piedone1113
Io con conversioni video, lanciando più conversioni contemporaneamente, ho una somma dei tempi inferiore stracaricando che fatti girare singolarmente. Di questo ne sono assolutamente sicuro perchè facendo le somme, ho rinunciato a 200 MHz di OC a favore del carico, io tenevo il procio a 4,6GHz anzichè 4,8GHz, a liquido. Tra l'altro, ho proprio dovuto abbandonare l'idea di tenerlo a 5GHz perchè con carico normale forse era RS a 1,525V (che è il limite DU del mio impianto liquido), ma con stracarico dovevo darci 1,550V e in accoppiata al fatto che le conversioni video richiedono molto tempo, la temp liquido si sarebbe alzata troppo (anche se >20 litri e quindi con un buon margine prima che entri a regime), già difficile in inverno, impensabile d'estate.

[Piedone1113]

Originariamente inviato da paolo.oliva2

Cinebench, come bench, riesce a contenere tutti i dati nella cache?
A suo tempo avevo fatto dei test-bench settando i TH, da 8 a 16, 32, 64.
Non mi ricordo quando BD calava le prestazioni, se a 32 o 64 TH, però sarebbe interessante fare la stessa cosa con un i7.

P.S.
Non posso usare l'8370 perchè mi sono preso 3 vga 480 (le altre sono saltate) che hanno solamente l'uscita HDMI ed io non ho l'adattatore VGA

Cinebench sull'8150 aveva un calo minimo su 16th, costante il calo fino a 32 th, a 64 th il calo era consistente e perdevi fluidità a desktop.
Sul 2600 il calo su 16th era leggermente più marcato in percentuale rispetto Amd, su 32 th il puntatore del mouse andava a scatti, su 64 sembrava bloccato il sitema, ma i test venivano conclusi sempre prima (se non sbaglio su 64th il divario tornava ad aumentare, è passato molto tempo e non ricordo).
Ma la mia conclusione fu che tranne fare da server per un db, una conversione video in backgroung e giocare a crisys, tutto in contemporanea l'i7 era superiore.
Ps fluidità percepita non rappresenta un maggior troughtout della cpu.

Originariamente inviato da paolo.oliva2

@piedone1113
Io con conversioni video, lanciando più conversioni contemporaneamente, ho una somma dei tempi inferiore stracaricando che fatti girare singolarmente. Di questo ne sono assolutamente sicuro perchè facendo le somme, ho rinunciato a 200 MHz di OC a favore del carico, io tenevo il procio a 4,6GHz anzichè 4,8GHz, a liquido. Tra l'altro, ho proprio dovuto abbandonare l'idea di tenerlo a 5GHz perchè con carico normale forse era RS a 1,525V (che è il limite DU del mio impianto liquido), ma con stracarico dovevo darci 1,550V e in accoppiata al fatto che le conversioni video richiedono molto tempo, la temp liquido si sarebbe alzata troppo (anche se >20 litri e quindi con un buon margine prima che entri a regime), già difficile in inverno, impensabile d'estate.

Paolo, se usavi freemake (e non format factory) la differenza a favore di due istanze vs una c'era (freemake utilizza 4 core al 50% di carico da gestione risorse, Format Factory ne utilizza 2), ma lo stesso guadagno percentuale lo ritrovavi anche con i7 se lo scheduler non assegna i th ai soli cori fisici.
Ma la proporzione era:
2 moduli vs 2 core ht 100 vs 130
4 moduli vs 4 core ht 220 vs 270
Bd recuperava in termini percentuali, ma perdeva in termini assoluti.
Se invece lo scheduler di win assegnava i 4 th ai cori fisici dell'i7 l'aumento prestazione c'era comunque perchè i core lavoravano al 50% delle capacità e praticamente egualiando i cori logici (minor carico sul core fisico maggiori risorse per il core logico)
situazione diversa invece se setti prime su 4 th vs 8th.
con 8 th attivi l'i7 guadagno circa il 20% in prestazioni (ci sono benchmark dove il guadagno è praticamente nullo), mentre con bd si aveva un quasi raddoppio delle prestazioni, ma il totale era sempre a favore di intel (a prescindere da quanti th usavi > di 8

[paolo.oliva2]

Originariamente inviato da Free Gordon

A Prime95 289 e/o IBT stabile..? (intendo 4,5ghz @1,29...perchè quello è un risultato davvero notevole col dissi stock.... )

A livello di RS ne sono sicuro al 99,99%, a livello di test tipo OCCT o carico intenso, non posso metterci la mano sul fuoco per il DU, perchè con 32° temp (ma nella stanza di più), io "soffro" quando vedo >65° e sono arrivato a max a 72°.

Però, pensandoci, una cosa è qui all'equatore e tutt'altra in Italia. A parte il DU che lo avrei sicuramente in Italia, le temp inferiori giocherebbero a favore del Vcore, che in teoria potrebbe pure essere più basso, quindi direi che a 1,29V in Italia sarei RS al 100%.

Ho potuto fare delle prove in frequenza solamente disabilitando 3 moduli, ma quello è un test farlocco, nel senso che già con la Asrock 95W potevo stare RS a 5,3GHz con 1,515V come X2, ma l'8370 mi ha dato l'impressione di non superare i 5GHz. D'altronde AMD avrebbe potuto anche fare dei 9590 C0k a meno di 220W, ma se non l'ha fatto, un perchè ci deve essere.

Tra l'altro... da 1,29V 4,5GHz starei a 1,3V a 4,6GHz, ma le temp mi si alzano almeno di 5°... +0,01V non può fare una cosa del genere, a me sembra che AMD abbia spinto l'RCM e poi ci possono essere proci fortunelli o meno nel range 4,4GHz/4,6GHz, ma oltre poi si paga vs l'8350.

[davo30]

Originariamente inviato da paolo.oliva2

Cinebench, come bench, riesce a contenere tutti i dati nella cache?
A suo tempo avevo fatto dei test-bench settando i TH, da 8 a 16, 32, 64.
Non mi ricordo quando BD calava le prestazioni, se a 32 o 64 TH, però sarebbe interessante fare la stessa cosa con un i7.

P.S.
Non posso usare l'8370 perchè mi sono preso 3 vga 480 (le altre sono saltate) che hanno solamente l'uscita HDMI ed io non ho l'adattatore VGA

@piedone1113
Io con conversioni video, lanciando più conversioni contemporaneamente, ho una somma dei tempi inferiore stracaricando che fatti girare singolarmente. Di questo ne sono assolutamente sicuro perchè facendo le somme, ho rinunciato a 200 MHz di OC a favore del carico, io tenevo il procio a 4,6GHz anzichè 4,8GHz, a liquido. Tra l'altro, ho proprio dovuto abbandonare l'idea di tenerlo a 5GHz perchè con carico normale forse era RS a 1,525V (che è il limite DU del mio impianto liquido), ma con stracarico dovevo darci 1,550V e in accoppiata al fatto che le conversioni video richiedono molto tempo, la temp liquido si sarebbe alzata troppo (anche se >20 litri e quindi con un buon margine prima che entri a regime), già difficile in inverno, impensabile d'estate.

Ci sei andato giu pesante!

[digieffe]

Originariamente inviato da cdimauro

Non mi pare proprio.

Non l'ho vista nell'elenco dei processori K10.

con un po' più di tempo l'ho trovata Athlon II X4 651K

Molto molto in fondo, perché senza dati completi sono test che lasciano il tempo che trovano.

Vedi il test di B&C, in cui marchigiano ha ragione: mancano i dati di SuperPi. Che fine hanno fatto?

Giusto per essere chiari, se vuoi fare un test serio, devi lanciare contemporaneamente le applicazioni da un tempo x a uno y, e vedere quanto riescano a macinare all'esatto scadere del tempo y.

per me è ovvio


non ricordo bene, forse l'utente Nardustyle fece dei test accettabili... qualcuno si ricorda?

[leoneazzurro]

Originariamente inviato da paolo.oliva2

@Leoneazzurro

Io non è che ne capisca tanto di trattamenti silicio, e un'altra volta mi avevi fatto notare che è sbagliato confrontare silici differenti.
Però io direi di considerare l'efficienza di una architettura rispetto ad un'altra sulla carta, ma non di giudicare il prodotto finito (architettura + silicio) perchè il silicio influenza e non poco.

Ad esempio, il Phenom I aveva 2,7GHz ed un IPC inferiore rispetto al Phenom II, che riuscì ad ottenere ben +1GHz con un IPC del 15% (o 17%) superiore.
Giudichiamo l'efficienza architetturale Phenom dalla versione I alla II. Non metto in dubbio che la variante II sia più ottimizzata della I ma certamente molto meno di quanto è incrementato per efficienza il 45nm sul 65nm (è pure da considerare che il Phenom I non abbia potuto inserire features e/o timing più spinti proprio per carenze silicio), tra l'altro il primo e unico modello 140W di AMD .

Sono in parecchi (in rete) a considerare il PP del 32nm uno dei peggiori di AMD, addirittura al livello, se non peggiore, del 65nm sempre AMD. Viceversa, il 45nm è stato uno dei migliori PP di AMD.

Ora... come si fa a giudicare l'efficienza di una architettura se poi confrontiamo Phenom II + miglior PP silicio AMD vs architettura BD con se non il peggiore tra i peggiori PP di AMD e di qui imputare l'efficienza ESCLUSIVAMENTE all'architettura?
Perchè se il SOI è migliore al Bulk, AMD ci ha speso soldi per portare BD sul 28nm Bulk? Perchè Llano (Phenom II) sul 32nm ha perso oltre il 20% rispetto al 45nm? Perchè invece BD sullo stesso silicio ha oltre 1GHz con il doppio dei core vs Llano?

Io dico solo che se una architettura non è efficiente, non lo è e punto. Ma allora come fa BR BD, per giunta sul 28nm, ad essere così efficiente?

Un calcolo approssimativo, secondo me, sarebbe questo:

Phenom II 45nm --> 32nm = -20% (prestazioni a parità di TDP, con Llano)
8350 32nm vs Thuban 45nm = +20% per BD.

Allora architettura BD vs architettura Phenom II = +40% (semplicemente sommando la perdita efficienza architettura + passaggio 45nm --> 32nm all'incremento BD 32nm vs Phenom II 45nm. Diversamente si applica tutta la perdita efficienza silicio esclusivamente all'architettura.

Il mio post era volto a ricordare che a parita' di architettura e di nodo del processo produttivo (leggi 45nm, 32nm, 28nm, ecc) si possono comunque avere variazioni riguardo le prestazioni termiche/in frequenza in base ad altre variabili come ad esempio numero e struttura delle metallizzazioni. Non solo, ma lo stesso processo produttivo a seconda dell'architettura utilizzata puo' fornire prestazioni differenti (es. le GPU Maxwell vs. Hawaii/Fiji, il processo produttivo era identico ma i consumi no).
I problemi di BD sono molteplici: il processo produttivo e' uno di questi (bisogna pero' chiedersi se fosse stato lecito aspettarsi dal processo le frequenze di 5+GHz che sarebbero state necessarie) ma anche tutta l'Architettura BD/PD/XV e' fortemente orientata all'elaborazione parallela piuttosto che alle prestazioni single thread, di deficienze strutturali ce ne sono parecchie (cache lente, mancanza di una µOp cache, ecc.) che non sono pertinenti al processo. Probabilmente AMD si aspettava un forte orientamento dello sviluppo software al multithreading, cosa che per ovvie ragioni non si e' realizzata. Accompagniamoci la mancanza di ottimizzazioni ad hoc e il quadro e' completo.

[paolo.oliva2]

S

Originariamente inviato da Piedone1113

Cinebench sull'8150 aveva un calo minimo su 16th, costante il calo fino a 32 th, a 64 th il calo era consistente e perdevi fluidità a desktop.
Sul 2600 il calo su 16th era leggermente più marcato in percentuale rispetto Amd, su 32 th il puntatore del mouse andava a scatti, su 64 sembrava bloccato il sitema, ma i test venivano conclusi sempre prima (se non sbaglio su 64th il divario tornava ad aumentare, è passato molto tempo e non ricordo).
Ma la mia conclusione fu che tranne fare da server per un db, una conversione video in backgroung e giocare a crisys, tutto in contemporanea l'i7 era superiore.
Ps fluidità percepita non rappresenta un maggior troughtout della cpu.


Paolo, se usavi freemake (e non format factory) la differenza a favore di due istanze vs una c'era (freemake utilizza 4 core al 50% di carico da gestione risorse, Format Factory ne utilizza 2), ma lo stesso guadagno percentuale lo ritrovavi anche con i7 se lo scheduler non assegna i th ai soli cori fisici.
Ma la proporzione era:
2 moduli vs 2 core ht 100 vs 130
4 moduli vs 4 core ht 220 vs 270
Bd recuperava in termini percentuali, ma perdeva in termini assoluti.
Se invece lo scheduler di win assegnava i 4 th ai cori fisici dell'i7 l'aumento prestazione c'era comunque perchè i core lavoravano al 50% delle capacità e praticamente egualiando i cori logici (minor carico sul core fisico maggiori risorse per il core logico)
situazione diversa invece se setti prime su 4 th vs 8th.
con 8 th attivi l'i7 guadagno circa il 20% in prestazioni (ci sono benchmark dove il guadagno è praticamente nullo), mentre con bd si aveva un quasi raddoppio delle prestazioni, ma il totale era sempre a favore di intel (a prescindere da quanti th usavi > di 8

Non ho capito bene... tu intendi che a fronte di un andamento a scatti l'SMT conserva comunque le prestazioni vs CMT o l'SMT ha più prestazioni finali perdendo comunque più del CMT?
Inoltre, riferito a quanto avevo postato precedentemente, l'SMT in sè, ha differenze di carico a seconda della grandezza delle cache del modello? Cioè, un Broadwell mobile, un 6700K, un 6850k (a parte la differenza del numero di core) non hanno una grandezza cache/core simile (L1+L2*l3/n° core) e quindi carichi differenti?

[paolo.oliva2]

Originariamente inviato da leoneazzurro

Il mio post era volto a ricordare che a parita' di architettura e di nodo del processo produttivo (leggi 45nm, 32nm, 28nm, ecc) si possono comunque avere variazioni riguardo le prestazioni termiche/in frequenza in base ad altre variabili come ad esempio numero e struttura delle metallizzazioni. Non solo, ma lo stesso processo produttivo a seconda dell'architettura utilizzata puo' fornire prestazioni differenti (es. le GPU Maxwell vs. Hawaii/Fiji, il processo produttivo era identico ma i consumi no).
I problemi di BD sono molteplici: il processo produttivo e' uno di questi (bisogna pero' chiedersi se fosse stato lecito aspettarsi dal processo le frequenze di 5+GHz che sarebbero state necessarie) ma anche tutta l'Architettura BD/PD/XV e' fortemente orientata all'elaborazione parallela piuttosto che alle prestazioni single thread, di deficienze strutturali ce ne sono parecchie (cache lente, mancanza di una µOp cache, ecc.) che non sono pertinenti al processo. Probabilmente AMD si aspettava un forte orientamento dello sviluppo software al multithreading, cosa che per ovvie ragioni non si e' realizzata. Accompagniamoci la mancanza di ottimizzazioni ad hoc e il quadro e' completo.

Che BD sia partita con un IPC troppo basso, nessuno lo discute, ed anche se avesse avuto frequenze di 5GHz non è che avrebbe comunque avuto un ST esaltante.

Però io penso a questo: a parte le frequenze, è innegabile che il 32nm SOI abbia segato completamente l'aspettativa di aumentare i moduli a die sia con il 32nm che con la concellazione del successivo 22nm già programmata.

BD è stato un progetto "economico", perchè AMD non ha investito nulla in cache più veloci e quant'altro, ma solamente condividendo i 2 core con alcune features marginali. Secondo me, l'intenzione di AMD, come anche hai detto tu, era di puntare sulla potenza MT, ma il silicio di fatto concedendo max 4m/8c, ha segato il tutto portando il confronto verso Intel sugli X4+4, i quali avendo frequenze più alte def/turbo, hanno amplificato il deficit IPC. Io non penso che AMD si aspettasse che le software house perfezionassero l'MT, ma penso più che AMD si aspettasse un X10 PD sul 32nm e un X16 XV sul 22nm (che avrebbe visto il 5960X sul 22nm come antagonista) e il confronto sul 14nm Intel da definire.

Facendo un confronto 32nm SOi e 28nm Bulk, abbiamo che il 28nm Bulk potrebbe permettere un FX X8 con base XV a frequenze 3,7GHz def e 4,3GHz turbo, ed ipotizzando un +15% di IPC, vorrebbe dire un equivalente PD 4,25GHz/4,9GHz, cacchio, se giudichiamo ciofeca il 28nm Bulk GF, se riesce a fare meglio del 32nm SOI, allora il 32nm SOI è proprio un cesso.

Per me oggi un 8m/X16 XV se la potrebbe vedere con un 6850K tranquillamente, sia come efficienza che come potenza MT e come carico.
La differenza in ST ci sarebbe, ma da un 8350 con le stesse frequenze di un 6700K, avremmo un 8350 (vedi sopra) a 4,9GHz in turbo (+1,4GHz quasi +50%) e un MT con +1,25GHz (+40% di frequenza), il tutto con almeno 15-20W TDP in meno, ed il tutto sempre nell'ambito 28nm GF vs 14nm Intel super cazzuto. Cacchio architettura inefficiente + 28nm vs 14nm = simile efficienza, dove sarebbe il miracolo? Adesso non è che voglio arrivare che BD sia migliore di Intel, però guardiao anche la nostra tasca. Ad esempio, io preferirei un procio che vada meno del 10% di quello Intel ma pagarlo il 50% in meno rispetto al contrario. AMD con BD ha comunque rapportato un prezzo listino coerente a quanto abbia speso. Il mio obiettivo è di aumentare la potenza del mio PD X8, che alternative avrei? Un 6700K? Troppa spesa per poco di più... un X6+6 o un X8+8 Intel? Preferibile... aspettiamo sto Zen e valutiamo nel rapporto prestazioni/prezzo... io spero di pagarlo quanto un i7 X6 5920K ma avere prestazioni in linea al 6850K. Il 6950X è un altro pianeta come prezzo.

Mi viene difficile su queste basi giudicare l'architettura BD inefficiente... non perchè voglia difenderla. E poi ipotizzare su questo che un BR con 3,2 milioni di transistor costerebbe 185$ ed un XV X16 risulterebbe essere 2/3 di quel die, oddio... schiaffalo anche a 300€ e non basterebbero manco le fonderie GF/Samsung per reggere le richieste.

[bjt2]

Originariamente inviato da leoneazzurro

Il mio post era volto a ricordare che a parita' di architettura e di nodo del processo produttivo (leggi 45nm, 32nm, 28nm, ecc) si possono comunque avere variazioni riguardo le prestazioni termiche/in frequenza in base ad altre variabili come ad esempio numero e struttura delle metallizzazioni. Non solo, ma lo stesso processo produttivo a seconda dell'architettura utilizzata puo' fornire prestazioni differenti (es. le GPU Maxwell vs. Hawaii/Fiji, il processo produttivo era identico ma i consumi no).
I problemi di BD sono molteplici: il processo produttivo e' uno di questi (bisogna pero' chiedersi se fosse stato lecito aspettarsi dal processo le frequenze di 5+GHz che sarebbero state necessarie) ma anche tutta l'Architettura BD/PD/XV e' fortemente orientata all'elaborazione parallela piuttosto che alle prestazioni single thread, di deficienze strutturali ce ne sono parecchie (cache lente, mancanza di una µOp cache, ecc.) che non sono pertinenti al processo. Probabilmente AMD si aspettava un forte orientamento dello sviluppo software al multithreading, cosa che per ovvie ragioni non si e' realizzata. Accompagniamoci la mancanza di ottimizzazioni ad hoc e il quadro e' completo.

Il problema del Pentium 4 era che scaldava e sul processo bulk il leakage esplodeva... Siccome AMD si è sempre bullata del fatto che i suoi processi SOI avevano un leakage da 10 a 20 volte inferiore, magari pensava di non avere problemi di TDP... E infatti l'architettura è progettata per non murare neanche a 5GHz, frequenza a cui l'unico problema è il TDP...

[george_p]

Originariamente inviato da leoneazzurro

Il mio post era volto a ricordare che a parita' di architettura e di nodo del processo produttivo (leggi 45nm, 32nm, 28nm, ecc) si possono comunque avere variazioni riguardo le prestazioni termiche/in frequenza in base ad altre variabili come ad esempio numero e struttura delle metallizzazioni. Non solo, ma lo stesso processo produttivo a seconda dell'architettura utilizzata puo' fornire prestazioni differenti (es. le GPU Maxwell vs. Hawaii/Fiji, il processo produttivo era identico ma i consumi no).
I problemi di BD sono molteplici: il processo produttivo e' uno di questi (bisogna pero' chiedersi se fosse stato lecito aspettarsi dal processo le frequenze di 5+GHz che sarebbero state necessarie) ma anche tutta l'Architettura BD/PD/XV e' fortemente orientata all'elaborazione parallela piuttosto che alle prestazioni single thread, di deficienze strutturali ce ne sono parecchie (cache lente, mancanza di una µOp cache, ecc.) che non sono pertinenti al processo. Probabilmente AMD si aspettava un forte orientamento dello sviluppo software al multithreading, cosa che per ovvie ragioni non si e' realizzata. Accompagniamoci la mancanza di ottimizzazioni ad hoc e il quadro e' completo.

Ciao Leoneazzurro, ottima analisi dei fatti.
Tu che conoscenze e competenze hai?
La mia è semplice curiosità
Grazie

[Piedone1113]

Originariamente inviato da paolo.oliva2

S

Non ho capito bene... tu intendi che a fronte di un andamento a scatti l'SMT conserva comunque le prestazioni vs CMT o l'SMT ha più prestazioni finali perdendo comunque più del CMT?
Inoltre, riferito a quanto avevo postato precedentemente, l'SMT in sè, ha differenze di carico a seconda della grandezza delle cache del modello? Cioè, un Broadwell mobile, un 6700K, un 6850k (a parte la differenza del numero di core) non hanno una grandezza cache/core simile (L1+L2*l3/n° core) e quindi carichi differenti?

Paolo CMT SMT sono due tecniche che dicono tutto e niente.
L'implementazione CMT di BD è fallimentare, ma non il cmt in se (immagina un modulo composto da 4 core int e 2 fpu, credi che avrebbe le stessa prestazioni del modulo BD.
Oppure un modulo bd con fpu sincrona ma al doppio della frequenza dei core int, magari coadiuvata da un smt a 4 vie a modulo.

Quello che dico è che BD aveva fino a 32 th aveva in cache i dati disponibili per il desktop, sandy bridge no.
o meglio:
Con amd tutti i dati potevano essere presi direttamente dai diversi livelli di cache, mentre con intel bisogna caricarli da ram, in l3, in l2.
Per svuotare la cache in l2 e riversarvi i dati della l3 bisogna aspettare che finisce la coda in esecuzione nei core, ed anche se vanno a 200 kmh hai delle latenza da subire.
Latenze che sommate all'alto ipc non rallentano la cpu.
Con amd non si ha il bisogno di travasare i dati tra le cache ed anche se a latenza delle singole cache maggiori hai meno latenze totali nello switchare tra i vari task.
Considera come un impianto edile:
I dati sono i mattoni per costruire, mentre i core sono i muratori.
Bene i muratori Intel ti posano 100 mattoni al secondo, mentre quelli amd 50.
Più muri dai da costruire al singolo muratore (i th) più mattoni di diverso tipo hai bisogno.
Arrivati ad un certo punto il muratore intel invece di passare al muro che ti aspetti poggia qualche mattone in più sul muro precedente in attesa che arrivino i mattoni giusti, mentre il muratore amd ha molta più probabilità di trovare il mattoni per il muro disponibile gia pronti (magari si allontana di 1 mt per prenderli in l3 invece che in l2).
Questa è la differenza (secondo me)
Se ci ragioni un poco capirai che se un core ha un ipc medio di 100, mentre l'altro di 50 il lavoro utile sarà sempre superiore quello del primo sul secondo, a dispetto dell'apperente lag del mouse (e se consideri che la piattaforma lga 2011 ha il quad channel proprio per non far restare la cpu a girarsi i pollici dato l'elavata capacità di consumare dati in attesa degli stessi dalla ram).
Vedi, l'architettura intel è limitata più dalla banda verso la ram che dall'ipc dei core, mentre quella di amd è il contrario.
Se non sbaglio avevi fatto dei test sulla ram dove sopra i 1866mhz praticamente non avevi aumenti di ipc (e spesso gli aumenti sono dovuto alle latenze ridotte dopo un cache miss e non ai maggiori dati elaborati al secondo), con le cpu intel l'ipc tende ad aumentare fino ai 2400mhz (parliamo di ddr3) segnale che alcuni tipi di calcolo sono limitati dalla ram che non riesce a fornire abbastanza dati.
Avevo letto su un articolo la differenza di prestazioni su server tra architettura ARM, Intel ed AMD ai tempi del 2600 e 8150.
il server arm era un 64 core, i server x86 erano 16 core (intel) e 32 core (amd).
Il server Arm era in vantaggio sulle architetture x86 nel rapporto performance watt fino a 32 istanze contemporanee, dopo di chè il vantaggio si assottigliava fino a raggiungere il pareggio alle 64 istanze (richieste al db sul server da client diversi).
oltre le 64 istanze contemporanee il server arm collassava, mentre amd ed intel andava avanti fino a 128 transazioni contemporanee (Amd senza avere cali di performance fino a 96 transazioni, mentre intel rallentava le proprie prestazioni oltre le 80 transazioni contemporanee).
A 140 transazioni contemporanee tutte e due i server mostravano i fianchi, ma con il server intel in vantaggio nell'esaudire le richieste rispetto a quello AMD.
Il test era fatto per valutare il costo macchina:
Il server arm venne considerato vantaggioso fino 48 istanze (ma indietro se si prendevano server a 8 core x86), superati tali limiti i server arm dovevano essere doppi per gestire i picchi di istanze ( e quindi non più economicamente vantaggiosi), il server Amd venne indicato come vantaggio fino a 96 transazioni, ma con una vita lavorativa di 30 mesi (oltre era antieconomico per i consumi totali), mentre quello intel era consigliato per 96 transazioni medie con picchi fino a 128 e/o 5 anni di vita.
Quindi paolo sotto carico spinto un core ht intel ai tempi dell'fx8150 era superiore ad un modulo AMD prestazionalmente.

[cdimauro]

Originariamente inviato da bjt2

No, di un modulo BD... In realtà forse un po' meno, perchè mancano 2 AGU, due unità di L/S, 0.5-1.5MB di L2 e forse dei decoder, ma in più ha le varie feature e un po' più di L1...

Però Zen ha pure l'FPU potenziata. Per cui bene o male i transistor potrebbero essere quelli, in base a quello di cui abbiamo discusso tempo fa qui.

Vabeh, volevo dire che in MT pesante con parecchi thread a basso IPC fa un po' meno schifo...

Comunque alla luce di questa:

http://image.slidesharecdn.com/20130...?cb=1365183251

mi rimangio quello che avevo detto sul processo 32nm SOI: no, non fa affatto schifo, considerato quello che è riuscita a guadagnare IBM nel passaggio dai 45nm. I numeri parlano chiaro.

I problemi li ha avuti AMD, con le sue (micro)architetture.

Originariamente inviato da Piedone1113

Ho notato che la fluidità di sistema su architettura core (ps il core duo non ha ht, refuso o confusione) si va a farsi friggere sopro a 3 th per core.
BD invece regge bene fino a 4th a core (th ad uso intensivo cpu).
Però a parità di carico (con architettura core in crisi di fluidità) le cpu intel (con ht, perchè paragoniamo smt vs cmt tra i due competitor) intel esegue sempre prima tutti i task (anche quando sembra piantato).
e la differenza di prestazioni tra i7 2600 e 8150 rimane pressocchè costante (in percentuale) con alcune situazioni dove addirittura il divario aumenta.
Test fatti in proprio perchè ho cercato di capire il comportamento di bd che sembra sempre essere sotto carico leggero, anche se non si vedono risultati al top.

IMO è proprio dovuto all'approccio CMT: non potendo un solo thread hardware sfruttare tutte le istruzioni & porte a disposizione, come invece fa l'SMT, il secondo thread hardware trova sempre a disposizione delle risorse da utilizzare (quelle sue, esclusive: due istruzioni decodificate + le sue macroALU), e dunque portare avanti la sua esecuzione.

Mentre con l'SMT il thread più attivo può arrivare a far morire di fame l'altro, impegnando per te la maggior parte delle risorse. Però dovrebbe esserci qualche politica di scheduling che conceda all'altro thread un po' di risorse se è da troppo tempo che è rimasto a "morire di fame".

Secondo me avere cmt + ht 2 vie avrebbe mitigato in alcuni scenari il distacco vs core, ma allora molto meglio architettura smt pura (magari smt4) perchè cmt+smt avrebbe avuto un costo di sviluppo e transistor molto elevato.

Non capisco cosa intendi con CMT + HT 2 vie.

Originariamente inviato da bjt2

Può essere... INTEL ha 2.5MB di L3 per core, perchè inclusiva... BD 2+1+ la L1... Però la differenza non è molta... 512 KB...

Concordo: non ci sono molte differenze.

A parte la cache L1 dati per ogni macroALU di Bulldozer, che IMO è troppo piccola, e ricorda, ancora una volta, lo stesso approccio di Intel col P4 (la prima versione aveva una cache L1 dati di appena 8KB. Poi portati a 16KB con la seconda versione).

E' come se AMD avesse copiato l'approccio di Intel col P4, ignorandone tutte le magagne.

Originariamente inviato da digieffe

con un po' più di tempo l'ho trovata Athlon II X4 651K

Già. Manco ricordavo che esistesse.

Originariamente inviato da leoneazzurro

Il mio post era volto a ricordare che a parita' di architettura e di nodo del processo produttivo (leggi 45nm, 32nm, 28nm, ecc) si possono comunque avere variazioni riguardo le prestazioni termiche/in frequenza in base ad altre variabili come ad esempio numero e struttura delle metallizzazioni. Non solo, ma lo stesso processo produttivo a seconda dell'architettura utilizzata puo' fornire prestazioni differenti (es. le GPU Maxwell vs. Hawaii/Fiji, il processo produttivo era identico ma i consumi no).

Infatti. Lo dimostra anche IBM coi suoi POWER 7 e 7+, passando dai 45 ai 32nm SOI. IBM non ha sofferto il passaggio, mentre AMD sì.

I problemi di BD sono molteplici: il processo produttivo e' uno di questi (bisogna pero' chiedersi se fosse stato lecito aspettarsi dal processo le frequenze di 5+GHz che sarebbero state necessarie) ma anche tutta l'Architettura BD/PD/XV e' fortemente orientata all'elaborazione parallela piuttosto che alle prestazioni single thread, di deficienze strutturali ce ne sono parecchie (cache lente, mancanza di una µOp cache, ecc.) che non sono pertinenti al processo. Probabilmente AMD si aspettava un forte orientamento dello sviluppo software al multithreading, cosa che per ovvie ragioni non si e' realizzata. Accompagniamoci la mancanza di ottimizzazioni ad hoc e il quadro e' completo.

Sostanzialmente d'accordo, ma per mancanza di ottimizzazioni a cosa ti riferisci.

Originariamente inviato da paolo.oliva2

Però io penso a questo: a parte le frequenze, è innegabile che il 32nm SOI abbia segato completamente l'aspettativa di aumentare i moduli a die sia con il 32nm che con la concellazione del successivo 22nm già programmata.

Alla luce dei risultati di IBM, direi proprio di no: è negabilissimo che i problemi di cui parli siano dovuti al passaggio ai 32nm SOI. Basti vedere l'immagine di cui sopra: i dati sono chiarissimi.

Adesso non è che voglio arrivare che BD sia migliore di Intel

Tranquillo: dati alla mano è impossibile da sostenere.

Mi viene difficile su queste basi giudicare l'architettura BD inefficiente... non perchè voglia difenderla.

Anche perché, come dicevo sopra, non ci sono proprio gli estremi per poterlo fare: BD è e rimane inefficiente, e non c'è nemmeno la scusa del processo produttivo che può mitigarlo.

Originariamente inviato da Piedone1113

Vedi, l'architettura intel è limitata più dalla banda verso la ram che dall'ipc dei core, mentre quella di amd è il contrario.
Se non sbaglio avevi fatto dei test sulla ram dove sopra i 1866mhz praticamente non avevi aumenti di ipc (e spesso gli aumenti sono dovuto alle latenze ridotte dopo un cache miss e non ai maggiori dati elaborati al secondo), con le cpu intel l'ipc tende ad aumentare fino ai 2400mhz (parliamo di ddr3) segnale che alcuni tipi di calcolo sono limitati dalla ram che non riesce a fornire abbastanza dati.

Ci sono dei test che dimostrano che la maggior banda influenza mediamente poco le prestazioni.

[Piedone1113]

Originariamente inviato da cdimauro

Però Zen ha pure l'FPU potenziata. Per cui bene o male i transistor potrebbero essere quelli, in base a quello di cui abbiamo discusso tempo fa qui.





IMO è proprio dovuto all'approccio CMT: non potendo un solo thread hardware sfruttare tutte le istruzioni & porte a disposizione, come invece fa l'SMT, il secondo thread hardware trova sempre a disposizione delle risorse da utilizzare (quelle sue, esclusive: due istruzioni decodificate + le sue macroALU), e dunque portare avanti la sua esecuzione.

Mentre con l'SMT il thread più attivo può arrivare a far morire di fame l'altro, impegnando per te la maggior parte delle risorse. Però dovrebbe esserci qualche politica di scheduling che conceda all'altro thread un po' di risorse se è da troppo tempo che è rimasto a "morire di fame".

Non capisco cosa intendi con CMT + HT 2 vie.




Infatti. Lo dimostra anche IBM coi suoi POWER 7 e 7+, passando dai 45 ai 32nm SOI. IBM non ha sofferto il passaggio, mentre AMD sì.


Alla luce dei risultati di IBM, direi proprio di no: è negabilissimo che i problemi di cui parli siano dovuti al passaggio ai 32nm SOI. Basti vedere l'immagine di cui sopra: i dati sono chiarissimi.

Tranquillo: dati alla mano è impossibile da sostenere.

Anche perché, come dicevo sopra, non ci sono proprio gli estremi per poterlo fare: BD è e rimane inefficiente, e non c'è nemmeno la scusa del processo produttivo che può mitigarlo.

Ci sono dei test che dimostrano che la maggior banda influenza mediamente poco le prestazioni.

Se non sbaglio IBM impiego oltre 18 mesi per il power7+ ed in parte le previsioni sui consumi furono disattesi.
Se poi non sbaglio il passaggio da 45 a 32 nm avrebbe dovuto portare una riduzione di un fattore 4 sulle dimensioni, (realisticamente 3,5) ma difatti la riduzione è stata di un fattore 2, quindi continuo a reputare il 32 SOI poco riuscito.

Per quando riguarda le risorse contese dall'ht ed esclusive del cmt è vero in parte:
con 4 th a modulo le risorse del singolo core in bd sarebbero comunque state insufficienti per mantenere fluidità, ma qua stiamo parlando di 8 th a modulo (4 a core int e ben 8 per la fpu condivisa) dove questa ipotesi sarebbe poco credibile (da parte mia).
Per la cache invece il core intel ha bisogno di leggere e scrivere i dati direttamente in L2 (considerando la L1 tutt'uno con il core) ma non in L3, a differenza di Amd che può farlo direttamente in L3.

E se fossero le sole risorse condivise il problema quando il sistema perde reattività le prestazioni dovrebbero calare in modo marcato, cosa che invece non avviene.
Per la ram è vero che oltre una certa frequenza la variazione di ipc è minima, ma AMD si ferma a 1866 sulla ram, oltre non vale la pena, tranne che sulle apu che sono affamate di banda per via della grafica, mentre con intel questo si inizia ad avvertire oltre i 2133mhz, ed è evidente quanto più la cpu è in overclock.
Questo, secondo me, significa che in determinate condizioni la banda verso la ram mi rallenta il sistema (in situazioni dove la ram è effettivamente stressata), chiaramente dove la banda verso la ram è minima non si avranno miglioramenti ( e probabilmente l'abbassamento di ipc sarebbe minimo anche settando la ram a 1033 mhz ).
Per quanto riguarda il CMT:
Un modulo da 4 core int e 3 fpu condivise dinamicamente tra i core rimane sempre un approcio cmt, ma questo non vieterebbe di implementare anche smt dove ogni core fisico in hardware potrebbe eseguire due th (considerando poi il rapporto ht = +25 % sarebbe come avere 5 core con 3 fpu in un rapporto più vantaggioso di 2 a 1)

[cdimauro]

Originariamente inviato da Piedone1113

Se non sbaglio IBM impiego oltre 18 mesi per il power7+

E' normale: fra POWER6 e POWER6+ ci sono circa 2 anni, e lo stesso vale per POWER7 e POWER7+.

ed in parte le previsioni sui consumi furono disattesi.

No, guarda tu stesso: frequenze aumentate e consumi ridotti, pur con col 75% di transistor in più.

E non si tratta di un caso isolato, perché risultati simili sono stati ottenuti sempre da IBM, quando la sua architettura Z (che è completamente diversa da quella POWER, e molto più CISC-like) è passata z196/45nm a zNext/32nm (sempre SOI).
Ecco qui: frequenze aumentate (anche se non di molto come per POWER 7 -> 7+, perché erano già molto tirate), una marea di cambiamenti nonché core aumentati, e consumi simili.

Ricapitolando:
- due architetture completamente diverse;
- passaggio da 45 a 32nm SOI;
- vantaggi in tutti i settori.



Risultati completamente diversi da quelli ottenuti da AMD quando ha fatto la stessa cosa col K10. Per Bulldozer non c'è un predecessore per poter fare un confronto, ma se AMD s'aspettava frequenze più elevate, come ha fatto col K10 ha fallito anche con Bulldozer, e NON certo per colpa del processo produttivo.

Se poi non sbaglio il passaggio da 45 a 32 nm avrebbe dovuto portare una riduzione di un fattore 4 sulle dimensioni, (realisticamente 3,5) ma difatti la riduzione è stata di un fattore 2, quindi continuo a reputare il 32 SOI poco riuscito.

Ancora no: fra 45 e 32 nm la riduzione è di un fattore 1,98, e dunque si avvicina al 2x di cui parlavi.

IBM fra POWER7 e POWER7+ è riuscito a impacchettare il 75% in più di transistor a parità di area: non è il 98% in più, ma è comunque un ottimo risultato.

Per quando riguarda le risorse contese dall'ht ed esclusive del cmt è vero in parte:
con 4 th a modulo le risorse del singolo core in bd sarebbero comunque state insufficienti per mantenere fluidità, ma qua stiamo parlando di 8 th a modulo (4 a core int e ben 8 per la fpu condivisa) dove questa ipotesi sarebbe poco credibile (da parte mia).

Non volevo paragonare POWER7+ a BD: ho semplicemente portato un esempio di passaggio da 45 a 32 nm SOI, che è avvenuto con successo. E adesso ne ho aggiunto un altro.

Per la cache invece il core intel ha bisogno di leggere e scrivere i dati direttamente in L2 (considerando la L1 tutt'uno con il core) ma non in L3, a differenza di Amd che può farlo direttamente in L3.

I core Intel non sono costretti a passare sempre dalla L2 quando accedono alla L1; tutt'altro. Ed è questa la cosa più importante. D'altra parte con la cache L1 più ampia (e con maggior associatività, se non ricordo male), hanno più cache hit e meno necessità di passare alla L2, alla L3, e così via.

Poi, se non ricordo male, gestire la gerarchia delle cache è molto più semplice quando non sono esclusive.

E se fossero le sole risorse condivise il problema quando il sistema perde reattività le prestazioni dovrebbero calare in modo marcato, cosa che invece non avviene.

No, è proprio il contrario: le prestazioni sono elevate quando si perde di reattività, perché c'è un thread hardware che monopolizza l'uso delle risorse.

Il che significa pure che le risorse vengono meglio sfruttate dai thread hardware.

Per la ram è vero che oltre una certa frequenza la variazione di ipc è minima, ma AMD si ferma a 1866 sulla ram, oltre non vale la pena, tranne che sulle apu che sono affamate di banda per via della grafica, mentre con intel questo si inizia ad avvertire oltre i 2133mhz, ed è evidente quanto più la cpu è in overclock.
Questo, secondo me, significa che in determinate condizioni la banda verso la ram mi rallenta il sistema (in situazioni dove la ram è effettivamente stressata), chiaramente dove la banda verso la ram è minima non si avranno miglioramenti ( e probabilmente l'abbassamento di ipc sarebbe minimo anche settando la ram a 1033 mhz ).

Tagliamo la testa al toro: Memory Performance: 16GB DDR3-1333 to DDR3-2400 on Ivy Bridge IGP with G.Skill

E ancora meno sensibile è il passaggio da DDR3 a DDR4, con Skylake:
The Intel 6th Gen Skylake Review: Core i7-6700K and i5-6600K Tested - DDR4 vs DDR3L on the CPU

Per quanto riguarda il CMT:
Un modulo da 4 core int e 3 fpu condivise dinamicamente tra i core rimane sempre un approcio cmt, ma questo non vieterebbe di implementare anche smt dove ogni core fisico in hardware potrebbe eseguire due th (considerando poi il rapporto ht = +25 % sarebbe come avere 5 core con 3 fpu in un rapporto più vantaggioso di 2 a 1)

Sì, ma nessuno l'ha fatto: o si va di CMT o di SMT. Si vede che un ibrido comporterebbe delle complicazioni.