[Thread Ufficiale] Aspettando ZEN

[Free Gordon]

Originariamente inviato da Ren

Si, Zen come la pazienza dei fan amd...

Originariamente inviato da gridracedriver

si si, se ti ricordi feci la stessa domanda molti mesi fa
può sembrare una sciocchezza ma il nome che danno alle cpu ha il suo perché, ma sinceramente con Zen non ho ancora capito cosa possa essere... con bulldozer è stato facile capirlo

Ma certo! E' Zen! Non si può mai sapere dove vuole andare a parare!

Speriamo bene.

[bjt2]

Originariamente inviato da tuttodigitale

come puoi vedere tu stesso ci sono elementi in più nella SRAM HC (high current). I famosi 10 finfet di cui parlavo...



PS Non ti fidi me?
Ho preso una slide che si riferisce ai 10nm, ma ti assicuro, che per i 14nm vale lo stesso.


a questo punto credo che ci sia un equivoco..ho preso le misure della l3 di BD, e usato lo scaling tra le SRAM test a 28 e 14nm..

Comunque 32core potrebbe anche non entrarci, abbiamo lasciato fuori elementi ingombranti come il pci express, il nuovo bus che sostituisce HT, e i 4MC dual channel...
Senza calcoli più precisi, tuttavia non mi azzardo neppure nella esclusione.....


in generale se ZEN ha un FO4 <=17 (basso quindi), un ipc inferiore è del tutto giustificabile se le dimensioni di un core ZEN non saranno maggiori di quello di Skylake. (non è esatto, ma prendiamolo per una semi-verità)

L'uso del SMT con un Predizioni rami approssimativo compromette ulteriormente le prestazioni del primo thread. Infatti il secondo thread riduce le risorse come la cache l1-l2, ma soprattutto la l0, che non solo è piccolissima (4KB se non erro) ma contiene macro-ops, ovvero istuzioni che occupano decisamente più spazio delle equivalenti x86. Lo scaling massivo pertanto non sarebbe comunque assicurato...e comunque si perderebbe assai in efficienza, che poi è l'obiettivo principale quando si cerca di non tirare troppo la corda con la ricerca del massimo ILP. (dubito molto che il power7/8 abbiano un predittore rami pessimo)

Ho le mie perplessità sulle 2 Agu, e quindi sullo scaling..secondo me un +50% MEDIO è il massimo che si può ambire (e non è poco).

Non è che non mi fidi... E' che questi sono scemi a non chiamare 10T una cella a 10 transistors...

Se i 32 core sono fatti con 2 die da 16 potresti avere ragione... Ma se sono fatti con 4 die da 8 siamo ancora entro le possibilità: la densità del 14nm abbiamo detto che è circa 2,5 volte, 1 core Zen a 14nm, considerando anche che ha meno cache L2, ma è più complesso di un modulo, potrebbe occupare come circa 0,5 moduli BD. La cache L3 per core è la stessa, ma i controller e la "colla" (PCI exp e link coerente) sono sempre gli stessi, ma per 8 core, quindi si riducono di 2,5 volte. In conclusione un die 8 core potrebbe essere più piccolo di uno 4 moduli BD, quindi fattibilissimo.

Per quanto riguarda lo scaling, ho scritto sopra che coda unica è meglio di code separate e che quindi per codice con pochi accessi RAM lo scaling dovrebbe essere superiore a quello di BD (ma non forse a quello di PD e XV che ha doppio decoder). Anche i codici con parecchi accessi ram potrebbero beneficiarne, se accoppiati con un altro thread normale. Perchè mentre un thread aspetta i dati (se non sono in L1) l'altro thread ha tutte le risorse per se... Quindi si ha basso scaling solo con tutti e 2 thread con accessi ram regolari e frequenti. In ogni caso lo scaling dovrebbe essere superiore a INTEL che ha molte meno porte...

[digieffe]

Scusate l'ignoranza: non si era sempre detto che l'ht è in multiplexing di tempo e non di spazio?
Ovvero che nel momento in cui un le pipeline di un thread sono in stallo le risorse vengono utilizzate dall'altro e non che le pipeline possono essere utilizzate contemporaneamente se non utilizzate dal primo thread.
Es. Ok: thread 1 esegue un branch errato, allora parte thread 2.
Es. No: thread 1 occupa solo 6 pipeline su 10 e thread 2 occupa le rimanenti 4.

[tuttodigitale]

Originariamente inviato da digieffe

Scusate l'ignoranza: non si era sempre detto che l'ht è in multiplexing di tempo e non di spazio?

TEcnicamente è un multithreading spaziale. Con questo si vuol intendere il fatto che i due thread possono essere eseguiti su pipeline in parallelo nello stesso istante temporale.
E più ne hai meglioi è...

Originariamente inviato da digieffe

Ovvero che nel momento in cui un le pipeline di un thread sono in stallo le risorse vengono utilizzate dall'altro e non che le pipeline possono essere utilizzate contemporaneamente se non utilizzate dal primo thread.

Possono essere utilizzate Contemporaneamente. Non a caso la sigla SMT, significa MultiThreading Simultaneo.

Quello che invece segue una filosofia temporale, è il front-end: il decodificatore, decodifica (o che fantasia) in cicli di clock differenti le istruzioni del primo e del secondo thread..

Originariamente inviato da digieffe

Es. Ok: thread 1 esegue un branch errato, allora parte thread 2.
Es. No: thread 1 occupa solo 6 pipeline su 10 e thread 2 occupa le rimanenti 4.

Entrambe sono vere.

[digieffe]

Originariamente inviato da tuttodigitale

TEcnicamente è un multithreading spaziale. Con questo si vuol intendere il fatto che i due thread possono essere eseguiti su pipeline in parallelo nello stesso istante temporale.
E più ne hai meglioi è...


Possono essere utilizzate Contemporaneamente. Non a caso la sigla SMT, significa MultiThreading Simultaneo.

Quello che invece segue una filosofia temporale, è il front-end: il decodificatore, decodifica (o che fantasia) in cicli di clock differenti le istruzioni del primo e del secondo thread..



Entrambe sono vere.

pensavo che ciò che è valido per il frontend lo fosse per tutto il core

grazie per la spiegazione

[tuttodigitale]

Originariamente inviato da bjt2

Per quanto riguarda lo scaling, ho scritto sopra che coda unica è meglio di code separate e che quindi per codice con pochi accessi RAM lo scaling dovrebbe essere superiore a quello di BD (ma non forse a quello di PD e XV che ha doppio decoder). Anche i codici con parecchi accessi ram potrebbero beneficiarne, se accoppiati con un altro thread normale. Perchè mentre un thread aspetta i dati (se non sono in L1) l'altro thread ha tutte le risorse per se... Quindi si ha basso scaling solo con tutti e 2 thread con accessi ram regolari e frequenti. In ogni caso lo scaling dovrebbe essere superiore a INTEL che ha molte meno porte...

stau facendo un pò di confusione . E' chiaro che ti riferisci alle prestazioni e non allo scaling...


in effetti un'unica coda garantirebbe prestazioni superiori di due più piccole.
Ma lo scaling no, perchè la prima coda che prima era riservata ad un thread, non lo sarà più con la presenza del secondo thread...

Lo scaling sarà per forza di cose inferiore lato integer rispetto al CMT, vuoi per il front-end più piccolo, vuoi perchè tutte le risorse EX int, sono dedicate, scheduler, l1D ecc.
Sulle prestazioni non è detta l'ultima parola: e potrebbe davvero superare un modulo XV...
PD ha 4 decoder, e XV 2x4 decoder, ma:
le pipeline sembrerebbero più corte lato integer...
la cache l1-l2, sono molto più veloci
è presenta la l0, che potrebbe tagliare anche 6 cicli..
lo scheduler integer dovrebbe avere più entries della somma dei 2 integrati in un modulo excavator...

Sulla FPU, le prestazioni saranno per forza superiore, ma con un lato integer molto più veloce, già nel ST potrebbe saturare le risorse dell'intera FlexFPu di Excavator...

[Ren]

cmq lo scaling è poco meno di 2 per le CPU.

SRAM test
28nm GF = 0.12
28nm TSMC = 0.13
14nm Samsung = 0.065

[paolo.oliva2]

@tuttodigitale

Fino ad oggi si è sempre cercato di diminuire il TDP per ottenere potenze superiori a die. Lo si è cercato tramite SMT, CMT e qualsivoglia.

Adesso ti faccio un ragionamento... che può sembrare idiota (e lo può anche essere), ma mi lascia perplesso.

Dall'epoca del passaggio X1 / X2, la potenza ST sarà anche aumentata perchè allora si era sul 65nm (mi sembra), quindi si è potuto incrementare pure la frequenza del singolo core, ma è ovvio che è aumentata di moltissimo la potenza a die perchè l'abbassamento del TDP a permesso un corposo aumento di core, L'SMT e CMT sono intervenuti semplicemente per trovare un mezzo di risparmio transistor tale da permettere più TH allo stesso TDP.

Ora... se già un Zen fosse un 8+8 con 95W sul 14nm, sul 9nm o ci ritroveremmo un X12+12 a 95W o un X8+8 a 65W... ma per che cosa?

Il ragionamento può essere più che valido per proci Server a cui si richiede il numero massimo di core/TH, ma per l'uso odierno di proci desktop, non sarebbe meglio cercare addirittura di togliere SMT/CMT per far si che il core non abbia il minimo intoppo e ricercare la massima potenza, visto che comunque un X6/X8 così composto soddisferebbe alla grande?

Non so se mi spiego... ma l'SMT e CMT in fin dei conti cercano entrambi di far lavorare 2 TH su un Hardware più potente per 1 TH, ma entrambi chiaramente NON possono raddoppiare la potenza del core.
Potenziando il core per farlo lavorare con 1 solo TH, non metto in dubbio che si avrebbe un aumento del TDP rispetto a quanto elaborato con 2 TH, ma è anche vero che comunque la potenza del core aumenterebbe.

Facendo un esempio stile Intel... il TDP del core è valutato (correggimi se sbaglio) con l'SMT attivo. Senza SMT, il TDP raggiunto è per forza di cose inferiore. Ora... supponiamo di essere sul 9nm, con 140W cosa ci sarà? 20TH? Ma non sarebbe meglio in ambito desktop, limitare i TH a 12/16 ma con un core in grado di arrivare a frequenze più alte?

[bjt2]

Originariamente inviato da tuttodigitale

stau facendo un pò di confusione . E' chiaro che ti riferisci alle prestazioni e non allo scaling...


in effetti un'unica coda garantirebbe prestazioni superiori di due più piccole.
Ma lo scaling no, perchè la prima coda che prima era riservata ad un thread, non lo sarà più con la presenza del secondo thread...

Lo scaling sarà per forza di cose inferiore lato integer rispetto al CMT, vuoi per il front-end più piccolo, vuoi perchè tutte le risorse EX int, sono dedicate, scheduler, l1D ecc.
Sulle prestazioni non è detta l'ultima parola: e potrebbe davvero superare un modulo XV...
PD ha 4 decoder, e XV 2x4 decoder, ma:
le pipeline sembrerebbero più corte lato integer...
la cache l1-l2, sono molto più veloci
è presenta la l0, che potrebbe tagliare anche 6 cicli..
lo scheduler integer dovrebbe avere più entries della somma dei 2 integrati in un modulo excavator...

Sulla FPU, le prestazioni saranno per forza superiore, ma con un lato integer molto più veloce, già nel ST potrebbe saturare le risorse dell'intera FlexFPu di Excavator...

Ovviamente la coda unica dovrebbe essere pari al doppio di quella di BD originale. Se così fosse, e non vedo perchè no, visto che sono il doppio delle unità, siamo nello stesso caso di BD ma un core contro un modulo (a parte la metà delle AGU). Per questo dicevo che per codice con pochi accessi in memoria si avrebbe lo stesso scaling di BD, se non meglio, per il fatto di coda unica, quindi >80%.
BD ha 16K di cache L1 e Zen sembra ne avrà 32. quindi stessa cache di un modulo...
Per tutte le altre risorse, se le raddoppiano, stessa storia di coda unica verso due code: è meglio...
Caso diverso per excavator che ha doppio decoder, ma li la cache L0 potrebbe sopperire e in più non sappiamo quanti decoder abbia Zen...

Io per scaling intendo il passaggio da 1 thread a 2 thread, forse mi sono espresso male...

[bjt2]

Originariamente inviato da paolo.oliva2

@tuttodigitale

Fino ad oggi si è sempre cercato di diminuire il TDP per ottenere potenze superiori a die. Lo si è cercato tramite SMT, CMT e qualsivoglia.

Adesso ti faccio un ragionamento... che può sembrare idiota (e lo può anche essere), ma mi lascia perplesso.

Dall'epoca del passaggio X1 / X2, la potenza ST sarà anche aumentata perchè allora si era sul 65nm (mi sembra), quindi si è potuto incrementare pure la frequenza del singolo core, ma è ovvio che è aumentata di moltissimo la potenza a die perchè l'abbassamento del TDP a permesso un corposo aumento di core, L'SMT e CMT sono intervenuti semplicemente per trovare un mezzo di risparmio transistor tale da permettere più TH allo stesso TDP.

Ora... se già un Zen fosse un 8+8 con 95W sul 14nm, sul 9nm o ci ritroveremmo un X12+12 a 95W o un X8+8 a 65W... ma per che cosa?

Il ragionamento può essere più che valido per proci Server a cui si richiede il numero massimo di core/TH, ma per l'uso odierno di proci desktop, non sarebbe meglio cercare addirittura di togliere SMT/CMT per far si che il core non abbia il minimo intoppo e ricercare la massima potenza, visto che comunque un X6/X8 così composto soddisferebbe alla grande?

Non so se mi spiego... ma l'SMT e CMT in fin dei conti cercano entrambi di far lavorare 2 TH su un Hardware più potente per 1 TH, ma entrambi chiaramente NON possono raddoppiare la potenza del core.
Potenziando il core per farlo lavorare con 1 solo TH, non metto in dubbio che si avrebbe un aumento del TDP rispetto a quanto elaborato con 2 TH, ma è anche vero che comunque la potenza del core aumenterebbe.

Facendo un esempio stile Intel... il TDP del core è valutato (correggimi se sbaglio) con l'SMT attivo. Senza SMT, il TDP raggiunto è per forza di cose inferiore. Ora... supponiamo di essere sul 9nm, con 140W cosa ci sarà? 20TH? Ma non sarebbe meglio in ambito desktop, limitare i TH a 12/16 ma con un core in grado di arrivare a frequenze più alte?

Il silicio inoperoso è silicio buttato, che consuma solo potenza. E' sempre meglio usarlo il più possibile, con SMT, strategie di predizione salti, caching e tenere sempre occupate le unità...

[tuttodigitale]

Originariamente inviato da bjt2

Io per scaling intendo il passaggio da 1 thread a 2 thread, forse mi sono espresso male...

appunto, è questo che non mi torna.
Da una parte abbiamo
1thread
XV vs ZEN
2ALU vs 4 ALU
2AGU vs 2AGU
1 ICache vs 1 ICache
4 decoder vs 4 decoder
48 entries vs 96entries(!?). (scheduler integer)

Ma XV nel multithread raddoppia buona parte delle risorse, cosa che ZEN non fa...
differenze MT vs ST, per ZEN e XV
ALU +0%, +100$
AGU +0%, +100%
I cache 0%, +100%
entries, 0%, +100%.
decoder 0%, +100%
Nel CMT buona parte delle risorse vengono duplicate, ecco perchè lo scaling di steamroller è pari al 87% di quello di un ipotetico dual core-2Moduli...

Se lo scaling di ZEN fosse equivalente a quello di XV, significherebbe che la grande coda unica, e le risorse maggiori a livello di core, non sarebbero minimamente sfruttate dal thread singolo...

[plainsong]

Originariamente inviato da tuttodigitale

Se lo scaling di ZEN fosse equivalente a quello di XV, significherebbe che la grande coda unica, e le risorse maggiori a livello di core, non sarebbero minimamente sfruttate dal thread singolo...

Quoto il ragionamento. Imho quando lo scaling Intel con SMT si assesta sul 30% per il secondo thread è perchè, semplicisticamente, il primo thread sta "spingendo" già molto di suo, saturando buona parte delle risorse disponibili. Su queste basi mi viene da pensare che uno scaling SMT marcatamente migliore sarebbe ottenibile solo aumentando le risorse hardware dedicate ad ogni thread, che tuttavia a quel punto risulterebbero sottoutlizzate in scenari single thread (il che ricorda quanto già tentato con Bulldozer).

[bjt2]

Originariamente inviato da tuttodigitale

appunto, è questo che non mi torna.
Da una parte abbiamo
1thread
XV vs ZEN
2ALU vs 4 ALU
2AGU vs 2AGU
1 ICache vs 1 ICache
4 decoder vs 4 decoder
48 entries vs 96entries(!?). (scheduler integer)

Ma XV nel multithread raddoppia buona parte delle risorse, cosa che ZEN non fa...
differenze MT vs ST, per ZEN e XV
ALU +0%, +100$
AGU +0%, +100%
I cache 0%, +100%
entries, 0%, +100%.
decoder 0%, +100%
Nel CMT buona parte delle risorse vengono duplicate, ecco perchè lo scaling di steamroller è pari al 87% di quello di un ipotetico dual core-2Moduli...

Se lo scaling di ZEN fosse equivalente a quello di XV, significherebbe che la grande coda unica, e le risorse maggiori a livello di core, non sarebbero minimamente sfruttate dal thread singolo...

Come ho scritto la maggior parte del software ha un IPC INT di poco superiore a 1, e comunque un buon 20-30% sono istruzioni memoria. Quelli che ne hanno 2 o più sono FP, ma comunque di istruzioni non fp sempre poco sopra una ne fanno... Quindi 4 unità INT sono quasi INUTILI, tranne casi rari o patologici. Daltronde BD ne ha solo 2 proprio per questo motivo.

Quindi nell'ST Zen vedrà una sottoutilizzazione delle 4 unità INT e con un secondo thread raddoppierà o quasi le prestazioni, da cui lo scaling superiore all'80%...

[tuttodigitale]

Originariamente inviato da bjt2

Come ho scritto la maggior parte del software ha un IPC INT di poco superiore a 1, e comunque un buon 20-30% sono istruzioni memoria. Quelli che ne hanno 2 o più sono FP, ma comunque di istruzioni non fp sempre poco sopra una ne fanno... Quindi 4 unità INT sono quasi INUTILI, tranne casi rari o patologici. Daltronde BD ne ha solo 2 proprio per questo motivo.

infatti io non mi aspettavo nulla di esaltante per la sola presenza delle 4 ALU (avevo ipotizzato un ipc nel ST complessivamente superiore del 15% figurati ). Anche nel P4, Intel dichiarava un utilizzo delle unità del back-end pari al 30%. (e lo scaling era del 15-25%, segno che i colli di bottiglia per il secondo thread erano altri )

le unità aggiuntive servono solo per catturare i picchi di ipc, ma certamente non cambiano il quadro generale più di tanto..
Proprio per questo, il solo numero di porte da solo non ci indica lo scaling. Lo scaling dipende anche da quante risorse ruba il thread aggiuntivo.

E secondo me, non ha nessun senso in chiave SMT2, progettare un'architettura con uno scaling pari o superiore al 80%.....rischi di avere consumi superiori ad un dual core, senza comunque offrire un ipc nel ST superiore in maniera tangibile. Non ha molto senso, imho. A quel punto meglio un dual core senza SMT...(il power 7/8 è lungi dall'offrire un +80% al secondo thread e non è un caso, imho)

INvece la mia prospettiva era diversa..mettere a disposizione grossomodo le stesse risorse del front end di un core Skylake, ma senza estremizzazioni a livello di ILP deletieri per l'efficienza, ottenendo grossomodo lo stesso livello di prestazioni nel MT, pur partendo da un ipc nel ST inferiore, ma non basso, ovvero significativamente maggiore di un core XV.

Originariamente inviato da bjt2

Quindi nell'ST Zen vedrà una sottoutilizzazione delle 4 unità INT e con un secondo thread raddoppierà o quasi le prestazioni, da cui lo scaling superiore all'80%...

Ma la L0 e la Dcache L1, lo scheduler, maggiorati per via del SMT, non darebbero nessun contributo al primo thread, se lo scaling fosse non solo in linea ma addirittura superiore a Piledriver.
Sono convinto del contrario.

[bjt2]

Originariamente inviato da tuttodigitale

infatti io non mi aspettavo nulla di esaltante per la sola presenza delle 4 ALU (avevo ipotizzato un ipc nel ST complessivamente superiore del 15% figurati ). Anche nel P4, Intel dichiarava un utilizzo delle unità del back-end pari al 30%. (e lo scaling era del 15-25%, segno che i colli di bottiglia per il secondo thread erano altri )

le unità aggiuntive servono solo per catturare i picchi di ipc, ma certamente non cambiano il quadro generale più di tanto..
Proprio per questo, il solo numero di porte da solo non ci indica lo scaling. Lo scaling dipende anche da quante risorse ruba il thread aggiuntivo.

E secondo me, non ha nessun senso in chiave SMT2, progettare un'architettura con uno scaling pari o superiore al 80%.....rischi di avere consumi superiori ad un dual core, senza comunque offrire un ipc nel ST superiore in maniera tangibile. Non ha molto senso, imho. A quel punto meglio un dual core senza SMT...(il power 7/8 è lungi dall'offrire un +80% al secondo thread e non è un caso, imho)

INvece la mia prospettiva era diversa..mettere a disposizione grossomodo le stesse risorse del front end di un core Skylake, ma senza estremizzazioni a livello di ILP deletieri per l'efficienza, ottenendo grossomodo lo stesso livello di prestazioni nel MT, pur partendo da un ipc nel ST inferiore, ma non basso, ovvero significativamente maggiore di un core XV.


Ma la L0 e la Dcache L1, lo scheduler, maggiorati per via del SMT, non darebbero nessun contributo al primo thread, se lo scaling fosse non solo in linea ma addirittura superiore a Piledriver.
Sono convinto del contrario.

Sarebbero dettagli... Le cache e le code, se ben dimensionate per il carico massimo, al dimezzare del carico (e quindi raddoppiare le risorse per un thread) guadagni massimo 5-10%...

[paolo.oliva2]

Originariamente inviato da bjt2

Il silicio inoperoso è silicio buttato, che consuma solo potenza. E' sempre meglio usarlo il più possibile, con SMT, strategie di predizione salti, caching e tenere sempre occupate le unità...

K, ho capito (che ho scritto una minchiata)

[digieffe]

@bjt2 quando parli di 1,2-1,5 oppure 2 IPC incaso di fp è riferito all'isa x86 immagino

sarebbe da capire quante uops o mops generano (int, mem e fp) e come queste occupano le pipeline.

ovvero quelle 1..2 istruzioni x86 quante pipeline va ad occupare in media?

[affiu]

Originariamente inviato da paolo.oliva2;

Fino ad oggi si è sempre cercato di diminuire il TDP per ottenere potenze superiori a die. Lo si è cercato tramite SMT, CMT e qualsivoglia.

Siamo quasi sicuri?HSA lo tagliamo?ci sta quasi per avvenire questo Salto:

Apu=accelerated processor unit
''MTpu=multiplied Thread processor unit''.

Nessuna miniaturizzazione e nessuna architettura potrebbe far andare un programma più velocemente di se stesso di circa un 500 volte e più a parità di tdp.

Poi la PROMESSA resta sempre i 20 teraflop di potenza grafica integrata....immagina un gioco a 8k che sta dentro un tdp di circa 200w.
Oggi come sia un gioco che un altro qualsiasi programma, non potrebbe andare piu veloce di quel fattore di velocità senza il calcolo eterogeneo, è più che impossibile.

Immagina una potenza da circa 5/10 volte quella di una play di oggi in ambiente HSA maturo

[digieffe]

Originariamente inviato da gridracedriver

comunque sia anche se Zen avesse "solo" il 90% dell'IPC di BW-E con lo scaling SMT del +50% e frequenza base di 3ghz, basterebbe per stare poco sotto in MT all'8 Core BW-E (3.2ghz ? ), in quanto:

~3ghz Zen 8C = ~3.10ghz BW-E 8C

spiego:

3.00*8*1.5 = 36
36*0.90/8/1.3 = 3.10ghz

dove 0.90 è il fattore correttivo di IPC

fosse a 3.5ghz def se la giocherebbe o starebbe poco sotto addirittura al 10C in MT:

~3.5ghz Zen 8C = ~3.65ghz BW-E 8C = ~2.9ghz BW-E 10C

quindi anche a 3ghz sarebbe molto competitivo in MT Core to Core, meno in ST ma dipende dal Turbo se può salire di 1ghz o meno o se la frequenza base fosse 3.5ghz dato che il turbo si accosterebbe sicuramente ai 4ghz...

riassumendo:

IPC = 90% BW-E
SMT = +50%

3~3.5 ghz def o 3.5~4ghz Turbo

a 95 watt avrebbe un efficienza superiore agli Intel , ma anche a 125 watt avrebbe la stessa efficienza

bah, e non mi pare di aver esagerato con i conti, anzi...

Sei riuscito a sintetizzare benissimo ciò che penso da un bel po' di tempo...

Trovo realistici anche i range da min. 3.0 ghz a max 3.5 di freq base e da 3.5 a 4.0 di turbo.
per lo scaling hai messo il massimo, io considererei un min +35% ed un max +50%

Ben fatto

[Piedone1113]

Originariamente inviato da digieffe

Sei riuscito a sintetizzare benissimo ciò che penso da un bel po' di tempo...

Trovo realistici anche i range da min. 3.0 ghz a max 3.5 di freq base e da 3.5 a 4.0 di turbo.
per lo scaling hai messo il massimo, io considererei un min +35% ed un max +50%

Ben fatto

Onestamente credo che possa essere anche sopra in determinati condizioni.
Maggiore è il contributo di smt in intel (ci sono software che danno + 8% dall'smt, mentre altri + 50%, credo che su quest'ultimi un turbo efficente potrebbe dare un bel boost a zen).