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

[cionci]

Originariamente inviato da paolo.oliva2

Nell'ambito server praticamente sarebbe bastato portare un Magny-C sul 32nm per guadagnare quei 0.5-1GHz di clock.

Assolutamente imho è troppo 0.4-0.5 Ghz a dire tanto.

Originariamente inviato da paolo.oliva2

Ma, alla fine... contando la diminuzione della superficie del modulo rispetto ai 2 core Phenom II classici, e valutando anche la diminuzione nel passaggio dal 45nm al 32nm... un BD X12 starebbe dentro alla superficie di un die Thuban X6? (secondo te)

A parità di processo produttivo dubito che un BD x8 possa stare nell'area di un Thuban x6. Non tanto per i core, quanto per l'area della cache che è di fatto più che raddoppiata.
Facendo una valutazione spannometrica a parità di processo produttivo:
- l'area di 4 moduli BD potrebbe essere di circa il 35% superiore a quella di 6 core Thuban
- l'area della cache circa raddoppiata

Considerando l'area occupata da cache e core in Thuban corrisponde a circa l'11% per la cache e il 29% per i core e considerando circa costante tutto quello che gli sta intorno: il BD X8 avrebbe un'area maggiore di un Thuban X6 del 20%.

Contando che il die-shrink potrebbe portare ad una diminuzione del 50% dell'area, un BD X8 a 32 nm occuperebbe circa il 60% dell'area di un Thuban X6. Stiamo larghi e consideriamo il 70% (visto che alcune componenti della geometria non scalano linearmente).
Il BD X12 invece potrebbe stare nell'area di un Thuban 45nm.

[paolo.oliva2]

Originariamente inviato da cionci

A parità di processo produttivo dubito che un BD x8 possa stare nell'area di un Thuban x6. Non tanto per i core, quanto per l'area della cache che è di fatto più che raddoppiata.
Facendo una valutazione spannometrica a parità di processo produttivo:
- l'area di 4 moduli BD potrebbe essere di circa il 35% superiore a quella di 6 core Thuban
- l'area della cache circa raddoppiata

Considerando l'area occupata da cache e core in Thuban corrisponde a circa l'11% per la cache e il 29% per i core e considerando circa costante tutto quello che gli sta intorno: il BD X8 avrebbe un'area maggiore di un Thuban X6 del 20%.

Contando che il die-shrink potrebbe portare ad una diminuzione del 50% dell'area, un BD X8 a 32 nm occuperebbe circa il 60% dell'area di un Thuban X6. Stiamo larghi e consideriamo il 70% (visto che alcune componenti della geometria non scalano linearmente).
Il BD X12 invece potrebbe stare nell'area di un Thuban 45nm.

Allora rimane da constatare il TDP del 32nm, perché come costo produzione sarebbe proponibile.

Assolutamente imho è troppo 0.4-0.5 Ghz a dire tanto.

Considera questo:
Il D0 (il primo Opteron 6 core) era 2,8GHz 140W.
Il D1 (seconda release silicio) permette un X12 a 2,4GHz sempre a 140W (raddoppio dei core con perdita 400MHz a parità di TDP)
Già comunque si parlava di un +100MHz (2,5GHz) rimanendo sullo stesso TDP
Già se fosse fatto con il low-k (E0) sarei dell'idea di un incremento di almeno 200-300MHz (suppongo che non sia stato fatto perché il low-k rende di più a frequenze medio-alte, ma non nelle basse... Ad esempio il Vcore in idle è 1,15V con l'E0 mentre con il C2-C3 arriva a 0,8V. Probabilmente il leakage non è così alto nel D1 da permettere guadagni notevoli sull'E0, per via di Vcore particolarmente bassi)
Passando al 32nm, con un 40% in meno di TDP, un Magny-C X12 potrebbe arrivare addirittura a 85W a 2,5GHz...

[cionci]

Originariamente inviato da paolo.oliva2

Considera questo:
Il D0 (il primo Opteron 6 core) era 2,8GHz 140W.
Il D1 (seconda release silicio) è 2,5GHz 140W X12 (raddoppio dei core con perdita 300MHz)
Già se fosse fatto con il low-k (E0) sarei dell'idea di un incremento di almeno 200-300MHz.
Passando al 32nm, con in 40% in meno di TDP, un Magny-C X12 sarebbe 85W a 2,5GHz...

Confronta almeno processori con lo stesso TDP e lo stesso numero di core

Opteron 2435: 6 core, TDP 115W, frequenza 2600 Mhz
Opteron 4184: 6 core, TDP 115W, frequenza 2800 Mhz

Quindi con uno step si sono guadagnati 200 Mhz.

Primo devi contare che una CPU non esce sul mercato subito con il secondo step. Secondo è possibile che da uno step all'altro si facciano modifiche non radicali che portino ad avvantaggiarsi sul TDP. E non è detto che ogni step porti equivalenti vantaggi in termine di TDP, ma è possibile anche che non portino alcun vantaggio e si vada ad intervenire su altro.
Terzo il 45nm Low-k non viene implementato per ora sui 32nm.

Queste cose non c'entrano niente con il die-shrink... Ed in ogni caso questi possibili vantaggi si avrebbero nel tempo e non immediatamente (anche 12 mesi). Quindi rimango dell'idea che dal semplice passaggio da 45 nm low-k al 32 nm si otterrebbero circa 400 Mhz in più a parità di processore.

[paolo.oliva2]

Comunque, dando per scontato che un Magny-C non lo vedremmo mai sul desktop, considera le differenze sul Thuban.

Incremento IPC nel singolo core nullo, solamente incremento di frequenza (dando per scontato che le frequenze almeno in turbo si alzerebbero).
Incremento di IPC nel multicore elevato.

Ma infatti analizzando questo si riesce a inquadrare molto meglio il perché di BD ed i requisiti con cui è stato creato BD, passando già nell'evoluzione del Phenom II nel Thuban.

In fin dei conti il Thuban cosa ha fatto? Maggior frequenza in monocore (Turbo) per alzare la potenza nel monocore e innalzamento IPC del multicore per i 2 core aggiuntivi.

Un Magny-C X12 avrebbe tranquillamente contrastato un i7 X6 e probabilmente pure X8 con l'aumento di clock, ma non sarebbe stato competitivo in termini di IPC monocore.

Per questo reputo MOLTO fondate il discorso del modulo che possa lavorare con 1 TH come fosse un super-core, lasciando pressoché invariato l'IPC del multicore perché anche considerando una relativa perdita di prestazioni in multicore (comunque intesa nella condivisione, perché a tutti gli effetti bisogna anche valutare le differenze se non porterebbero comunque vantaggi) e comunque sarebbero compensate dal notevole aumento di frequenza, di per sé anche ammettendo solamente un + 30% (3,2GHz --> 4GHz) molto più consistente di qualsiasi calo derivante dall'IPC multicore.

AMD non può aver progettato un Buldozer in 5 anni senza tenere conto di tutto questo, e comunque seguendo la strada intrapresa dal primpo Phenom II/Opteron X4.

[Gigamez]

Originariamente inviato da Ares17

Bd è indirizzato al mercato server (quindi niente smt attivo su intel).
Bd è massimizzato per avere le massime prestazioni in multith.
L'smt di intel occupa diciamo il 3% di superfice in relazione al core.
il 2 core occupa il 12% in relazione al modulo.
Adesso cosa ti faccia pensare che un core + smt sia più efficente in multith di un modulo?
la densita di core per superfice è nettamente a favore di bd e presumibilmente dove SB avrà 8 core reali Bd avrà almeno 6 moduli (ma forse ci sarebbe lo spazio anche per 7)
Il modulo di amd serve ad aumentare la densità dei core.
Tutto il discorso sul reverse HTT sono solo speculazioni e se questo fosse reale sarebbe solo un opzional (che peraltro sarebbe del tutto inutile in ambito server)

ok, sono d'accordo
Ma quello che intendevo dire io non era che un core + SMT fosse piu' prestante di un modulo in maniera assoluta.. Intendevo dire che se usassi un modulo come un dual core dove all'occorrenza (programmi monoth) il secondo core fa da "supporto SMT fisico" al primo core vorrebbe dire che ogni core dovrebbe necessariamente avere anche il suo fetch ed il suo decode autonomo ed asclusivo, in modo da poter essere all'occorrenza totalmente indipendente. Se fosse davvero cosi', dunque, allora perche' non proporre 2 cores veramente separati (perche' sarebbero "separati" comunque, secondo la tua ipotesi visto che nell'utilizzo multith a parte alcune memorie interne agirebbero in maniera totalmente autonoma) con l'aggiunta di un SMT, cosi' come appunto ha gia' fatto Intel da un pezzo? Si risparmierebbe in progettazione, si massimerebbero le prestazioni e si consumerebbe anche di meno! Intel ha dei cores piu' estesi a livello di silicio, vero, ma sono anche decisamente piu' potenti.. quindi anche il discorso sul risparmio del silicio da solo non basterebbe, secondo me. E conta anche che per quello che vediamo se i due cores fossero davvero separati, SULLA CARTA avrebbero, presi singolarmente, un IPC addirittura inferiore di quello di un singolo core k10 (presi da soli, hanno meno risorse da poter usare). Conta inoltre che le circuitazioni e gli algoritmi necessari a gestire i trees nel caso dei prediction sarebbero dispensdiose in termini di silicio e di progettazione.. per avere un guadagno praticamente simile a quello che ha Intel con il suo SMT..

La logica del modulo penso sia quella dell'integrare alcune componenti per i due core (e non solo le memorie, come proporresti tu). E' questa integrazione che non puo' permettere una completa autonomia di questi due cores, che devono essere PER FORZA legati tra di loro in fase esecutiva (hanno ad esempio fetch e decode in comune, almeno stando ai disegni finora visti)! Ecco perche' sto cercando di fare queste speculazioni, proprio perche' per quello che ora si e' visto dai grafici architetturali una ipotesi come la tua dovrebbe partire da una architettura piuttosto diversa, ed a mio parere non sarebbe per nulla conveniente..

Per quanto riguarda i vantaggi nel mercato server.. Una fantasiosa ipotesi come la mia (quella che ho semplificato al massimo come un "SLI" tra unità int XD) porterebbe vantaggi in qualunque caso.. qualunque! Praticamente potrebbe quasi raddoppiare le prestazioni INT, avendo nel modulo in comune praticamente tutto il resto (fetch, decode, memorie, retires, ecc.). A mio parere sarebbe un esempio di integrazione decisamente piu' spinta, tale da giustificare una nuova architettura, invece ad esempio di prendere quella gia' esistente ed aggiungerci un SMT per avere vantaggi simili rispetto a quello che proponi tu.

[AceGranger]

Originariamente inviato da paolo.oliva2

Un Magny-C X12 avrebbe tranquillamente contrastato un i7 X6 e probabilmente pure X8 con l'aumento di clock, ma non sarebbe stato competitivo in termini di IPC monocore.

tranquillamente mica tanto, arranca un pochino contro i 6+6

http://www.anandtech.com/show/2978/a...-s-6-core-xeon

i test sono stai effettuati con questi proci

6174 80/115W 2.2 GHz
X5670 95W 2.93 GHz equivalente i7 970

sono entrambi i secondi proci piu veloci, i TOP gamma sono

6176 SE 105/137W 2.3 GHz + 100 MHz
W5680 130W 3.30 GHz + 370 MHz equivalente i7 980X

l'aumento di clock servirebbe per contrastare sempre i 6+6, gli 8+8 mi sa che stanno fuori portata

[george_p]

Ma visto che BD ragiona per moduli e l'inserimento di un core Int. rappresenta solo 12% dell'area dell'intero modulo, potrebbe, AMD, aver progettato questa architettura prevedendo l'inserimento di più Int. per ogni modulo così da aumentare significativamente l'elaborazione simultanea di più threads?

In questo modo aumenterebbe di poco l'area occupata a tutto vantaggio in termini di tdp e roba varia.

Fantascienza?

Sarebbe molto auspicabile

[cionci]

Originariamente inviato da george_p

Ma visto che BD ragiona per moduli e l'inserimento di un core Int. rappresenta solo 12% dell'area dell'intero modulo, potrebbe, AMD, aver progettato questa architettura prevedendo l'inserimento di più Int. per ogni modulo così da aumentare significativamente l'elaborazione simultanea di più threads?

In questo modo aumenterebbe di poco l'area occupata a tutto vantaggio in termini di tdp e roba varia.

Fantascienza?

Sarebbe molto auspicabile

No, assolutamente. Chiaramente non è una cosa possibile nell'immediato. I core interi non possono essere aggiunti come le figurine all'album, perché tutti gli stage precedenti e successivi all'esecuzione devono essere dimensionati in modo da poter gestire in modo efficiente una quantità contemporanea di istruzioni tale da lasciare il meno possibile inoperosi i vari core int. Quindi aggiungere core int senza riprogettare backend e frontend è impossibile.
Il vantaggio è che questo ridimensionamento non porta ad un raddoppio di ogni risorsa

Originariamente inviato da Gigamez

ok, sono d'accordo
Ma quello che intendevo dire io non era che un core + SMT fosse piu' prestante di un modulo in maniera assoluta.. Intendevo dire che se usassi un modulo come un dual core dove all'occorrenza (programmi monoth) il secondo core fa da "supporto SMT fisico" al primo core vorrebbe dire che ogni core dovrebbe necessariamente avere anche il suo fetch ed il suo decode autonomo ed asclusivo, in modo da poter essere all'occorrenza totalmente indipendente. Se fosse davvero cosi', dunque, allora perche' non proporre 2 cores veramente separati (perche' sarebbero "separati" comunque, secondo la tua ipotesi visto che nell'utilizzo multith a parte alcune memorie interne agirebbero in maniera totalmente autonoma) con l'aggiunta di un SMT, cosi' come appunto ha gia' fatto Intel da un pezzo? Si risparmierebbe in progettazione, si massimerebbero le prestazioni e si consumerebbe anche di meno!

Non ci sarebbe alcuno dei vantaggi che hai descritto.
Prima di tutto con un SMT classico è stato dimostrato che l'aumento di prestazioni è bassissimo in ogni situazione, tranne in quelle fortemente parallelizzabile (si arriva ad un massimo del 33% di efficienza in più in rarissimi casi, ma con medie intorno al 7% ed occupando il 5% in più di area).
L'area di due core (con singolo core int) senza SMT sarebbe pari al 178% di quella di un modulo. Le prestazioni (teoriche) sarebbero pari al 200% di quelle di un single core così come l'area occupata.
Le prestazioni di un modulo con due core int sono l'80% di quelle del dual core occupando il 56% dell'area.
Le prestazioni / area occupata sarebbero nettamente a favore del modulo
Per rendersi conto:
- prestazioni / area singole/dual core con solamente un core int: 100%
- prestazioni / area occupata modulo: 143%

Supponendo di avere un SMT sui core con singolo core int, in situazione di efficienza massima (33%) e con area occupata del 5% in più.
Le prestazioni rispetto al core senza SMT sarebbero il 133% con un'area del 105%.
Le prestazioni del singolo modulo rispetto al dual core SMT sarebbero del 60%. L'area occupata sarebbe il 53%.
Vediamo l'efficienza prestazioni / area occupata:
- per il single/dual core: 100%
- per il single/dual core SMT: 127%
- per il modulo: 143%

Quindi anche considerando un dual core SMT, le prestazioni sarebbero nettamente superiori rispetto all'area occupata per il modulo con due core int E considera che ho preso le prestazioni massime ottenibili con l'SMT. Se prendevo il 7% le cose sarebbero andate ancora peggio.

[george_p]

Capisco
Grazie della risposta cionci.
Aspettiamo e vediamo l'arrivo di bulldozer, sarà molto atteso per applicazioni 3D su desktop

[paolo.oliva2]

Originariamente inviato da AceGranger

tranquillamente mica tanto, arranca un pochino contro i 6+6

http://www.anandtech.com/show/2978/a...-s-6-core-xeon

i test sono stai effettuati con questi proci

6174 80/115W 2.2 GHz
X5670 95W 2.93 GHz equivalente i7 970

sono entrambi i secondi proci piu veloci, i TOP gamma sono

6176 SE 105/137W 2.3 GHz + 100 MHz
W5680 130W 3.30 GHz + 370 MHz equivalente i7 980X

l'aumento di clock servirebbe per contrastare sempre i 6+6, gli 8+8 mi sa che stanno fuori portata

Prova a guardare i test su linux... .
In ambito Windows, senza sollevare polemiche, le piattaforme Intel rendono sempre di più, ma le cose cambieranno, perché con le AVX non potranno esistere compilatori "partigiani", e poi perché Intel non può risciare altre sanzioni perché è già stata avvisata e nell'accordo di "liquidazione" vecchio ha messo su carta che deve cambiare.
In ambito Linux le differenze tra un Magny-C ed un X6 Intel sono esigue, ma conta il fatto che il Magny-C "gira" a 2,4GHz-2,5GHz e l'Intel gira a 3,333GHz.
Con base SB Intel avrà suppergiù gli stessi clock, mentre un Magny-C, anche consideranto (per me) il sottostimato di Cionci a +500MHz, cosa otterremo?
SB un incremento di IPC, ma se un SB X4 mostra un +12% di media.... SB X6 potrebbe averlo inferiore, ma sicuramente NON maggiore.
AMD Da 2,5GHz a 3GHz si tratterebbe di +20%.
Ai bench visti, ammettendo per SB +10% e per Magny-C +20%, la risultante è che uscirebbe un +10% a favore di AMD rispetto all'attuale, non briciole, considerando per Magny-C solo 3GHz su 32nm...
Però, se vogliamo considerare per SB un +10% di IPC e pure un +10% sul clock, con risultante di un incremento maggiore del 20%, con la stessa manica larga non possiamo considerare solo un 20% per Magny-C, allo stesso modo, dovremmo considerare almeno un 40-50% che sarebbe equivalente alla stessa diminuzione di TDP dichiarata da AMD.
Se vogliamo fare i confronti, dobbiamo utilizzare lo stesso metro. E' inutile fare confronti aumentando le aspettive sull'Intel ed abbassando nettamente sul concreto quelle AMD... che confronto verrebbe fuori?

[Ares17]

Originariamente inviato da Gigamez

ok, sono d'accordo
Ma quello che intendevo dire io non era che un core + SMT fosse piu' prestante di un modulo in maniera assoluta.. Intendevo dire che se usassi un modulo come un dual core dove all'occorrenza (programmi monoth) il secondo core fa da "supporto SMT fisico" al primo core vorrebbe dire che ogni core dovrebbe necessariamente avere anche il suo fetch ed il suo decode autonomo ed asclusivo, in modo da poter essere all'occorrenza totalmente indipendente. Se fosse davvero cosi', dunque, allora perche' non proporre 2 cores veramente separati (perche' sarebbero "separati" comunque, secondo la tua ipotesi visto che nell'utilizzo multith a parte alcune memorie interne agirebbero in maniera totalmente autonoma) con l'aggiunta di un SMT, cosi' come appunto ha gia' fatto Intel da un pezzo? Si risparmierebbe in progettazione, si massimerebbero le prestazioni e si consumerebbe anche di meno! Intel ha dei cores piu' estesi a livello di silicio, vero, ma sono anche decisamente piu' potenti.. quindi anche il discorso sul risparmio del silicio da solo non basterebbe, secondo me. E conta anche che per quello che vediamo se i due cores fossero davvero separati, SULLA CARTA avrebbero, presi singolarmente, un IPC addirittura inferiore di quello di un singolo core k10 (presi da soli, hanno meno risorse da poter usare). Conta inoltre che le circuitazioni e gli algoritmi necessari a gestire i trees nel caso dei prediction sarebbero dispensdiose in termini di silicio e di progettazione.. per avere un guadagno praticamente simile a quello che ha Intel con il suo SMT..

La logica del modulo penso sia quella dell'integrare alcune componenti per i due core (e non solo le memorie, come proporresti tu). E' questa integrazione che non puo' permettere una completa autonomia di questi due cores, che devono essere PER FORZA legati tra di loro in fase esecutiva (hanno ad esempio fetch e decode in comune, almeno stando ai disegni finora visti)! Ecco perche' sto cercando di fare queste speculazioni, proprio perche' per quello che ora si e' visto dai grafici architetturali una ipotesi come la tua dovrebbe partire da una architettura piuttosto diversa, ed a mio parere non sarebbe per nulla conveniente..

Per quanto riguarda i vantaggi nel mercato server.. Una fantasiosa ipotesi come la mia (quella che ho semplificato al massimo come un "SLI" tra unità int XD) porterebbe vantaggi in qualunque caso.. qualunque! Praticamente potrebbe quasi raddoppiare le prestazioni INT, avendo nel modulo in comune praticamente tutto il resto (fetch, decode, memorie, retires, ecc.). A mio parere sarebbe un esempio di integrazione decisamente piu' spinta, tale da giustificare una nuova architettura, invece ad esempio di prendere quella gia' esistente ed aggiungerci un SMT per avere vantaggi simili rispetto a quello che proponi tu.

edit: abbiamo una gran confusione in mente
L'SMT serve ad utilizzare le unità di calcolo inoperose durante un thread per indirizzare ed eseguirne un'altro.
Risultato di ipc al massimo uguale in single Th con un verosibilmente calo dell'ipc nel caso si utilizzi il core virtuale per l'esecuzione di un'altro th ( a causa delle risorse comuni contese dai due Th e conseguente decadimento dell'ipc)
Reverse htt:
Un core lavora al 100% delle sue possibilità sia in ambiente single th che multi.
Se il secondo core (stiamo parlando dell'unità di esecuzione int) del modulo è inattivo ed è possibile swichtando il thread tra un core e l'altro un aumento dell'ipc di solo il 5% abbiamo come risultato:
2 core 2 th ipc 80
2 core 1 th ipc 50 Rev off
2 core 1 th ipc 52.5 rev on

Con smt abbiamo:
2 core 4 th ipc 120
2 core 2 th ipc 100
2 core 1 th ipc 50 smt off
2 core 1 th ipc =< 50 smt on

Adesso ragioniamo per superfice (valuteremo il tdp uguale nel caso di superfice uguale, tralasciando la superfice occupata dalle l3 ipotizzata idendica per le due architetture)
1 core smt 105
10 core smt 1050

2 core modulo 120
9 moduli 1080
Quindi a parità di superfice avremo 10 core smt contrapposti a 9 moduli.
totale ipc in multi (ipotizzando una scalabilità perfetta) avremo
60 ipc x 10 core = 600 per architettura smt
40 ipc x 18 core = 720 per architettura a modulo

Analizzaziamo l'ipc in single th
Architettura smt =<50
architettura smt off 50
modulo 50
modulo rev htt 52.5

All'aumentare dei th avremo fino a 9 th:
architettura smt 450
architettura modulo 472,5

questa è la massimizzazione delle prestazioni a modulo per singolo th.
Qualora i th siano 10 avremo una rivalsa dell'architettura smt:
architettura smt 500
architettura moduli 420 (4 moduli in modalità rev htt) + 80 (un modulo in modalità dual)

Da adesso in poi all'aumentare dei th un'architettura smt viene sempre superata da una a moduli.
Integrando un smt nel modulo avremo due controindicazioni:
Aumento della superfice del 20-30% a modulo.
abbattimento dell'ipc in multi a causa della contesa di risorse comuni da parte non più di 2 th, bensi 4 .
Quindi ragionando a moduli l'ipc aumenta in maniera maggiore all'aumentare della superfice in multi th e rimane costante sul singolo th.
D'accordo che il singolo core di intel ha un ipc maggiore in single th.
Ma verosimilmente questo avviene perchè si utilizza più superfice per singolo core dei canonici 105 ipotizzati prima (probabilmente avremo un rapporto di 230 a 120 a parità di processo produttivo e questo implica che l'ipc debba essere almeno il doppio per poter competere a livello di superfice

[AceGranger]

Originariamente inviato da paolo.oliva2

Prova a guardare i test su linux...

te lo scrivono pure, l'engine di blender su linux non sfrutta nel modo corretto l'HT dei nuovi 6 core, è programmato male, contando che è pure una Alpha....

[paolo.oliva2]

Originariamente inviato da AceGranger

te lo scrivono pure, l'engine di blender su linux non sfrutta nel modo corretto l'HT dei nuovi 6 core, è programmato male, contando che è pure una Alpha....

Però, non è che voglio arrivare ad avere ragione e non voglio andare OT.
Se guardi l'i980X, da un TDP dichiarato di 130W, sono stati ipotizzati perfino 157W TDP sotto carico (ci sono parecchi articoli a riguardo). Tu stai partendo come di fatto che a +333MHz rimarrebbero 130W TDP reali con un i990X.

Ora, ripeto senza polemizzare, io reputo molto difficile aumentare di un 10% il clock e nello stesso tempo abbassare di un 20% il TDP, rispetto ad un Magny-C che con un 32nm avrebbe il TDP abbassato dal 40-50% ma lo si vuole vedere solo con un +20% di clock.

Il 990X lo si può considerare come un affinamento del silicio e relativa selezione. Quanto può incidere? il 5%?
Poi se consideri che Intel dal suo primo 45nm HKMG su base 1366 a 3,333GHz quanto è potuto crescere in 2 anni? ZERO. E' migliorata solo nel socket "inferiore". Ma l'i990X non va nel socket inferiore.

[Gigamez]

Originariamente inviato da Ares17

edit: abbiamo una gran confusione in mente
L'SMT serve ad utilizzare le unità di calcolo inoperose durante un thread per indirizzare ed eseguirne un'altro.
Risultato di ipc al massimo uguale in single Th con un verosibilmente calo dell'ipc nel caso si utilizzi il core virtuale per l'esecuzione di un'altro th ( a causa delle risorse comuni contese dai due Th e conseguente decadimento dell'ipc)
Reverse htt:
Un core lavora al 100% delle sue possibilità sia in ambiente single th che multi.
Se il secondo core (stiamo parlando dell'unità di esecuzione int) del modulo è inattivo ed è possibile swichtando il thread tra un core e l'altro un aumento dell'ipc di solo il 5% abbiamo come risultato:
2 core 2 th ipc 80
2 core 1 th ipc 50 Rev off
2 core 1 th ipc 52.5 rev on

Con smt abbiamo:
2 core 4 th ipc 120
2 core 2 th ipc 100
2 core 1 th ipc 50 smt off
2 core 1 th ipc =< 50 smt on

Adesso ragioniamo per superfice (valuteremo il tdp uguale nel caso di superfice uguale, tralasciando la superfice occupata dalle l3 ipotizzata idendica per le due architetture)
1 core smt 105
10 core smt 1050

2 core modulo 120
9 moduli 1080
Quindi a parità di superfice avremo 10 core smt contrapposti a 9 moduli.
totale ipc in multi (ipotizzando una scalabilità perfetta) avremo
60 ipc x 10 core = 600 per architettura smt
40 ipc x 18 core = 720 per architettura a modulo

Analizzaziamo l'ipc in single th
Architettura smt =<50
architettura smt off 50
modulo 50
modulo rev htt 52.5

All'aumentare dei th avremo fino a 9 th:
architettura smt 450
architettura modulo 472,5

questa è la massimizzazione delle prestazioni a modulo per singolo th.
Qualora i th siano 10 avremo una rivalsa dell'architettura smt:
architettura smt 500
architettura moduli 420 (4 moduli in modalità rev htt) + 80 (un modulo in modalità dual)

Da adesso in poi all'aumentare dei th un'architettura smt viene sempre superata da una a moduli.
Integrando un smt nel modulo avremo due controindicazioni:
Aumento della superfice del 20-30% a modulo.
abbattimento dell'ipc in multi a causa della contesa di risorse comuni da parte non più di 2 th, bensi 4 .
Quindi ragionando a moduli l'ipc aumenta in maniera maggiore all'aumentare della superfice in multi th e rimane costante sul singolo th.
D'accordo che il singolo core di intel ha un ipc maggiore in single th.
Ma verosimilmente questo avviene perchè si utilizza più superfice per singolo core dei canonici 105 ipotizzati prima (probabilmente avremo un rapporto di 230 a 120 a parità di processo produttivo e questo implica che l'ipc debba essere almeno il doppio per poter competere a livello di superfice

:S mi sa che nessuno dei due sta capendo quello che dice l'altro..
Le differenze tra SMT e Reverse Hyperthreading le conosco bene, tant'e' che se leggi vari post addietro vedrai che addirittura ne parlai in lungo ed in largo.

Il mio era semplicemente un discorso ipotetico di come poter fare ad aumentare la capacità di calcolo Intera in single-TH avendo a disposizione una architettura simile a quella che circola nelle varie figure relative a bulldozer.
Basandomi su cio' che amd disse e soprattutto basandomi sulle figure che abbiamo visto ho semplicemente espresso una teoria. Non ho mai detto che sara' sicuramente cosi', ma secondo me potrebbe essere una soluzione davvero interessante, tutto qui.

Io pero' vorrei capire come secondo te (e secondo la tua rispettabilissima teoria) in una architettura modulare quale quella di BD verrebbero gestite in maneira separata per le due unità int le fasi di fetch e decode, basandoti sui disegni architetturali che circolano relativi a BD. Vorrei inoltre capire sempre secondo la tua teoria un'approssimazione dei vantaggi prestazionali che ci sarebbero (oltre ovviamente al silicio "risparmiato"). Secondo te l'ipc in mono-th sarebbe davvero superiore anche solo rispetto a quello del K10?

concordo in pieno comunque con il tuo ragionamento sull'area del silicio. Ma io non stavo mettendo in dubbio nulla di cio'! Capisci che o AMD ci mette davvero il doppio dei cores (cores Intel con SMT Vs. Modulo BD), oppure sarebbe una partita (prestazionalmente parlando) gia' persa in partenza? ..E se fosse cosi', allora perche' la mia ipotesi di un core con una doppia INT unit gestita alternativamente per lo stesso thread sarebbe cosi' impossibile? (visto ceh ripeto, abbiamo UN SOLO FETCH ed un solo DECODE unificato per i due core nello stesso modulo?)

[cionci]

Abbiamo però due int scheduler e questo fa capire che i due core non possono eseguire lo stesso thread. Altrimenti lo scheduler avrebbe dovuto essere uno solo. A quel punto di fatto si sarebbe semplicemente avuta una sola ALU SMT con il doppio delle unità di calcolo.

[Athlon]

Originariamente inviato da Gigamez

:S mi sa che nessuno dei due sta capendo quello che dice l'altro..
Le differenze tra SMT e Reverse Hyperthreading le conosco bene, tant'e' che se leggi vari post addietro vedrai che addirittura ne parlai in lungo ed in largo.

Il mio era semplicemente un discorso ipotetico di come poter fare ad aumentare la capacità di calcolo Intera in single-TH avendo a disposizione una architettura simile a quella che circola nelle varie figure relative a bulldozer.
Basandomi su cio' che amd disse e soprattutto basandomi sulle figure che abbiamo visto ho semplicemente espresso una teoria. Non ho mai detto che sara' sicuramente cosi', ma secondo me potrebbe essere una soluzione davvero interessante, tutto qui.

Io pero' vorrei capire come secondo te (e secondo la tua rispettabilissima teoria) in una architettura modulare quale quella di BD verrebbero gestite in maneira separata per le due unità int le fasi di fetch e decode, basandoti sui disegni architetturali che circolano relativi a BD. Vorrei inoltre capire sempre secondo la tua teoria un'approssimazione dei vantaggi prestazionali che ci sarebbero (oltre ovviamente al silicio "risparmiato"). Secondo te l'ipc in mono-th sarebbe davvero superiore anche solo rispetto a quello del K10?

concordo in pieno comunque con il tuo ragionamento sull'area del silicio. Ma io non stavo mettendo in dubbio nulla di cio'! Capisci che o AMD ci mette davvero il doppio dei cores (cores Intel con SMT Vs. Modulo BD), oppure sarebbe una partita (prestazionalmente parlando) gia' persa in partenza? ..E se fosse cosi', allora perche' la mia ipotesi di un core con una doppia INT unit gestita alternativamente per lo stesso thread sarebbe cosi' impossibile? (visto ceh ripeto, abbiamo UN SOLO FETCH ed un solo DECODE unificato per i due core nello stesso modulo?)

Le risorse condivise nel modulo derivano dalla teoria della coda unica , cioe' e' piu' efficiente utilizzare delle risorse condivise rispetto ad una duplicazione totale delle unita'.


Se un core INT ha bisogno ad esempio di 3 unita' decode quando metto 2 core INT non ho bisogno del doppio delle unita' decode perche' statisticamente e' molto imporbabile che entrambi i core abbiano bisogno contemporaneamente di tutte le potenzialita' della sezione decode , quindi se con un core INT ho 3 unita' quando ho 2 core INT 5 unita' decode possono svolgere tranqullamente il lavoro.


L'accorpamento in moduli permette appunto di sharare tra due core INT molte unita' senza ricorrere al raddoppio secco , risparmiando cosi' silicio e energia

[paolo.oliva2]

Originariamente inviato da cionci

Abbiamo però due int scheduler e questo fa capire che i due core non possono eseguire lo stesso thread. Altrimenti lo scheduler avrebbe dovuto essere uno solo. A quel punto di fatto si sarebbe semplicemente avuta una sola ALU SMT con il doppio delle unità di calcolo.

Però fammi capire una cosa...

L'INT in più che è condiviso nel modulo deve comunque consentire l'accesso sia dallo scheduler INT A che dallo scheduler INT B.
Nel caso che il modulo debba eseguire 1 TH, ci troveremmo nella condizione che il core A avrebbe a disposizione 2 INT, cioè il doppio della condizione di un core Phenom II, con il core B in "parcheggio".

Se il procio, gestisse gli HT con una logica del tipo 1 HT = 1 modulo per n HT = a n moduli e solo nella condizione n HT > n moduli passerebbe a gestire 1 HT a core e non a modulo, avremmo la seguente condizione:

Il modulo sarebbe come un super-core, quindi con possibilità di incremento IPC. Tra la condizione SMT che sfrutta i tempi "morti" per aumentare l'IPC e la condizione che il modulo offrirebbe più unità di calcolo e quindi più IPC che cambierebbe?
Da una condizione che l'SMT porta da un teorico 95% al 100% di sfruttamento del core, un INT in più io lo vedrei come raddoppio di capacità di calcolo, semplicemente perché l'SMT deve comunque ritornare nello stesso INT, perché di fisico rimane quello, mentre con 2 INT può trovare la pappa pronta perché può saltare da uno all'altro...

Se l'INT in più a modulo non potesse essere utilizzato in parallelo né in logica 1TH e né in logica 2 TH a modulo, AMD che cacchio lo avrebbe messo a fare? Mi pare ovvio che sia in un modo che nell'altro è lì per permettere di risolvere 2 elaborazioni contemporanee con lo scopo di aumentare l'IPC.

A spanna, direi che con 1 TH a modulo le istruzioni INT potrebbero aumentare del 100% (teorico) la velocità di elaborazione, mentre con 2 TH a modulo l'incremento calerebbe al 50%, sempre teorico.

[cionci]

Originariamente inviato da paolo.oliva2

Però fammi capire una cosa...

L'INT in più che è condiviso nel modulo deve comunque consentire l'accesso sia dallo scheduler INT A che dallo scheduler INT B.

Assolutamente no. Due thread possono comunicare tra loro soltanto attraverso la memoria.

Originariamente inviato da paolo.oliva2

Nel caso che il modulo debba eseguire 1 TH, ci troveremmo nella condizione che il core A avrebbe a disposizione 2 INT, cioè il doppio della condizione di un core Phenom II, con il core B in "parcheggio".

No, solo uno per thread. C'è uno scheduler dedicato per ogni core int e quindi per ognuno dei due thread.

[paolo.oliva2]

Originariamente inviato da Athlon

Le risorse condivise nel modulo derivano dalla teoria della coda unica , cioe' e' piu' efficiente utilizzare delle risorse condivise rispetto ad una duplicazione totale delle unita'.


Se un core INT ha bisogno ad esempio di 3 unita' decode quando metto 2 core INT non ho bisogno del doppio delle unita' decode perche' statisticamente e' molto imporbabile che entrambi i core abbiano bisogno contemporaneamente di tutte le potenzialita' della sezione decode , quindi se con un core INT ho 3 unita' quando ho 2 core INT 5 unita' decode possono svolgere tranqullamente il lavoro.


L'accorpamento in moduli permette appunto di sharare tra due core INT molte unita' senza ricorrere al raddoppio secco , risparmiando cosi' silicio e energia

Quindi collegando il tuo post con il mio post precedente questo...
Un INT in più condiviso potrebbe in media incrementare del 25% la velocità di calcolo INT in caso di 2 TH a modulo, e del 50% nel caso di 1 TH.

Chiaramente potrebbe andare anche da 0% al 50%-100%, a seconda che vi sia la condizione di 2 INT possano essere eseguiti parallelamente o, caso contrario, 1 ciclo "morto".

Però... tra l'SMT software (Intel) e l'SMT (chiamiamolo così) AMD, la differenza è che comunque, allacciandoci ai post di BJT2, la condizione di più calcoli in contemporanea sarebbe nettamente a favore di AMD.

[paolo.oliva2]

Originariamente inviato da cionci

Assolutamente no. Due thread possono comunicare tra loro soltanto attraverso la memoria.

No, solo uno per thread. C'è uno scheduler dedicato per ogni core int e quindi per ognuno dei due thread.

Non mi torna... All'ora per te quell'INT in più che ci fosse o meno sarebbe uguale.

Ma se nel modulo ci sono 1 INT a core (2 totali) + 1 INT condiviso... gli scheduler rimangono 2 o sono 3?
Se sono 2... lo scheduler potrebbe gestire 2 INT, oppure se sono 3 comunque 2 scheduler dovrebbero o dialogare o essere parallelizzati.

Se AMD lo ha messo, una funzione in più la deve comunque fare.