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

[digieffe]

http://translate.googleusercontent.c...803_dxGokMdU5A

so già che dovrebbe essere postato nel thread sulla disparita di trattamento del compilatore intel ma voglio informare anche voi!!!

Intel C / C++ 11.1 0.93 / 1,24 (SPECint_2006base / SPECfp_2006base)
Intel C / C++ 12.0 1,10 / 1,42 (SPECint_2006base / SPECfp_2006base)
other compilers 1,00 / 1,00 (SPECint_2006base / SPECfp_2006base) *

* Best of Visual Studio 2010 and PGI

1,10 / 0,93 = 1,18 (+18%)
1,42 / 1,24 = 1,14 (+14%)

complimenti a tutti i possessori di processori amd diventati più veloci del 18% sugli int e 14% sui fp


EDIT: con questi dati qual'è la reale differenza tra k10 e SB? e quale sarà tra Bd e SB???

[Pihippo]

Originariamente inviato da digieffe

secondo me un BD X8 sarà sicuramente sopra un SB X6 per i due fattori che citavi (clock più alto e 2 core in più). Personalmente per l'utilizzo che ne faccio io (virtualizzazione ecc) l'HT è più un problema che altro, a me servono core veri!!! ed anche se questi condividono qualcosa vanno ugualmente bene (certo che se BD avesse avuto un pò più di I-cache L1 es 96k al posto di 64k, qualche ciclo in meno per l'accesso alla abbondate cache L2, credo sarebbe stato meglio, così come, se le aglu avessero avuto la possibilità di eseguire qualche altra operazione es. add e sub su interi senza segno e qualche altra op semplice) spero in una miglioria in BDII.

Ciao
A quanto pare le aglu sono capaci di fare INC e DEC (incrementi e decrementi). Sono molto comuni come istruzioni. Inoltre mi pare di capire dal grafico postato un pò di tempo fa sulla L3 che essa è banked in 2mb e vi si può accedere tramite un bus di 256bit. Rispetto a quello attuale di 64bit.
Per la load to use latency della L2 anche a me par alta ma sicuramente sarà compensata da clock alti e prefetch intelligente.

[digieffe]

Originariamente inviato da Pihippo

Ciao
A quanto pare le aglu sono capaci di fare INC e DEC (incrementi e decrementi). Sono molto comuni come istruzioni. Inoltre mi pare di capire dal grafico postato un pò di tempo fa sulla L3 che essa è banked in 2mb e vi si può accedere tramite un bus di 256bit. Rispetto a quello attuale di 64bit.
Per la load to use latency della L2 anche a me par alta ma sicuramente sarà compensata da clock alti e prefetch intelligente.

proprio perchè fa inc e dec avrebbe potuto fare altre istruzioni semplici comuni (ricorrenti) ...
si confermo l'enorme miglioria di banda alla l3, ho letto di migliorie anche alla cross bar per evitare che diventi collo di bottiglia ma non trovo il link...

mi è venuto un dubbio: il k10 con le sue 3 pipeline (composte ognuna da 1 alu + 1 agu) esegue (per pipeline) contemporaneamente (1 mop = 1 alu + 1 agu) oppure no (le serializza)?
farebbe una enorme differenza!

[Pihippo]

Originariamente inviato da digieffe

proprio perchè fa inc e dec avrebbe potuto fare altre istruzioni semplici comuni (ricorrenti) ...
si confermo l'enorme miglioria di banda alla l3, ho letto di migliorie anche alla cross bar per evitare che diventi collo di bottiglia ma non trovo il link...

mi è venuto un dubbio: il k10 con le sue 3 pipeline (composte ognuna da 1 alu + 1 agu) esegue (per pipeline) contemporaneamente (1 mop = 1 alu + 1 agu) oppure no (le serializza)?
farebbe una enorme differenza!

Ciao
Si, ma bisogna pensare che comunque non si può complicare troppo il discorso dei flag, anche se ad onor del vero, una agu per poter calcolare un indirizzo deve poter comunque disporre di un adder a 3 vie, quindi il silicio per fare add e sub c'è.
Per il discorso k10: esso può eseguire al massimo 3 op logico aritmetiche e 2 di memoria (la 3 agu è li solo per simmetria) ovviamente le uop di memoria devono essere della stessa mop della uop aritmetico logica inoltre, se non erro, ci sono solo 3 bus di result, mentre BD ne ha 4. Ovviamente vi sarà il caso in cui avere una alu in meno penalizzerà un poco ma lo schema di bd pare più flessibile.

[iGio]

Originariamente inviato da digieffe

a parità di core con o senza HT? a parità di clock?


EDIT: imho, BD con l'ipc aumentato del 15-18% dovrebbe sommariamente raggiungere SB senza HT (2500) la differenza con l'HT (2600) si dovrebbe colmare con il clock? forse non del tutto!

HT ? QUESTE TECNOLOGIE VIRTUALI NON SONO DA PRENDERE PIù DI TANTO IN CONSIDERAZIONE. giudichiamo in base ai core fisici. per quanto riguarda il clock anche qui dobbiamo considerare la bonta dell'architettura. puo darsi che BD abbia un clock più basso ma performance uguali oppure superiori.

p.s scusa il caps lock !

[iGio]

Originariamente inviato da paolo.oliva2

Ma guarda che stiamo parlando di clock e su basi ben fondate, il discorso di confronto su SB è tutta un'altra cosa e si potrà vedere solo sul campo.

Il discorso clock è basato sia sul tipo di architettura sia sulle possibilità che può offrire il silicio. Forse non hai presente che AMD sul 45nm liscio è arrivato a 12 core, Intel sul 32nm HKMG non può superare i 10 core e con un clock inferiore rispetto a quello di AMD sul 12 core.

Sul discorso prestazioni è tutta un'altra cosa... ma comunque è tutto da vedere che IPC avrà BD, ma per il discorso di clock a parità di core, mi sembra ormai più che scontato che l'ago sia tutto a favore di BD. Tieni presente che Intel non immetterà mai sul mercato un 95W per proci con più di 4 core, ma solamente a 130W. AMD invece destinerà i 125W solamente per l'X8 top di gamma, il resto saranno a 95W sia X8 che X6 e X4. Pensa il margine di frequenza che avrebbe AMD nel caso decidesse di farli a 125W o addirittura a 140W.

Inoltre, la cosa che non è da sottovalutare, non è sul fatto se AMD possa o meno superare a parità di core SB, ma quanto potrà essere competitiva AMD nel rapporto prezzo-prestazioni. Secondo me, ad esempio ora Intel ha nell'i7 X6 (i980X) il procio più potente. Ma a fronte di un +10% di performances di un 2600K dai 300€ si passa ai 900€. Se BD X8 fosse il 10% meno potente di un SB X8 (ma sembra non lo facciano più...), se l'SB X8 costasse 1000€ e un BD X8 400€, avrebbe un senso dire unicamente che Intel avrebbe il procio più potente, ma che comunque non sarebbe conveniente e quindi la gente opterebbe per un BD X8. Ciò cosa vorrebbe dire? Chiunque per bandiera potrebbe dire che Intel sarebbe più potente... ma per il discorso portafoglio si comprerebbe AMD.

o ben presente un po' tutto. dico solo che di dati certi ne abbiamo pochi. il resto e solo pura speculazione. detto ciò io sono un fan AMD e mi trovo d'accordo con la politica di questa azienda. Spero che bulldozer diventi un vero Killdozer per intel. il tempo ci dara ragione oppure torto fino ad allora teniamo duro !

[blackshard]

Originariamente inviato da iGio

HT ? QUESTE TECNOLOGIE VIRTUALI NON SONO DA PRENDERE PIù DI TANTO IN CONSIDERAZIONE. giudichiamo in base ai core fisici. per quanto riguarda il clock anche qui dobbiamo considerare la bonta del architettura. puo darsi che BD abbia un clock più basso ma performance uguali oppure superiori.

p.s scusa il caps lock !

La mia idea è che l'hyperthreading nelle revisioni di nehalem e sandy bridge è un ottimo elemento in più nella faretra intel.
A livello concettuale intel, a mio modo di vedere, sfrutta la parallelizzazione intrinseca di un'ambiente operativo multithreading per meglio rifornire le pipeline. Secondo me non è mai stata una cattiva idea, neanche ai tempi dei pentium 4.

[blackshard]

Una riflessione su bulldozer e i sistemi operativi, scaturita dal mio post precedente.

Bulldozer avrà due core integer + una singola fpu per modulo.
Siccome in passato le occasioni fallaci non sono mancate (il tanto famigerato quanto finto bug del cool&quiet sotto windows) ho il forte dubbio delle capacità degli scheduler dei sistemi operativi di approcciare la cosa. Cosa succede, per esempio, se ho due thread che fanno uso intensivo della fpu e, malauguratamente, lo scheduler li assegna entrambi allo stesso modulo e quindi alla stessa FPU? Non sarebbe meglio se li spedisse a due moduli diversi così da occupare due FPU separate?

Un problema simile ce l'aveva intel con hyperthreading: il sistema operativo vedeva come core fisici anche i core logici "condivisi", non sfruttando appieno le potenzialità e a volte peggiorando addirittura la situazione.
Con windows 7 ci hanno messo una pezza con il core parking: in pratica i core logici diventano core di "serie B" che vengono scelti come destinatari di un processo solo se tutti i core fisici di "serie A" sono già occupati.

Ora leggevo tempo fa che con bulldozer tutti i core saranno mostrati come core fisici, mi domandavo quindi se è una buona scelta, oppure se non sia ipotizzabile che un core per modulo diventi logico per ingannare windows e sfruttare il core parking per meglio utilizzare le varie fpu.

[iGio]

Originariamente inviato da blackshard

La mia idea è che l'hyperthreading nelle revisioni di nehalem e sandy bridge è un ottimo elemento in più nella faretra intel.
A livello concettuale intel, a mio modo di vedere, sfrutta la parallelizzazione intrinseca di un'ambiente operativo multithreading per meglio rifornire le pipeline. Secondo me non è mai stata una cattiva idea, neanche ai tempi dei pentium 4.

attenzione non dico che sia un cattiva idea. ma se vogliamo misurare la vera potenza di una cpu facciamolo solo in base ai cv disponibili e alla loro resa.

[digieffe]

Originariamente inviato da blackshard

La mia idea è che l'hyperthreading nelle revisioni di nehalem e sandy bridge è un ottimo elemento in più nella faretra intel.
A livello concettuale intel, a mio modo di vedere, sfrutta la parallelizzazione intrinseca di un'ambiente operativo multithreading per meglio rifornire le pipeline. Secondo me non è mai stata una cattiva idea, neanche ai tempi dei pentium 4.

concordo sul fatto che "è un ottimo elemento in più nella faretra intel" ma generalmente da i suoi vantaggi nel multi threading (1 processo con più istanze dati), nel multi processing (processi diversi con dati diversi) i casi sono da valutare, nella virtualizzazione non ho trovato mai dei bench soddisfacenti, la mia esperienza però è in genere negativa (indipendentemente dal sistema: vmware, xen, kvm o virtualbox)

EDIT: se trovate bench fatti bene sulla virtualizz. con ht e senza fatemi sapere , grazie

[blackshard]

Originariamente inviato da digieffe

concordo sul fatto che "è un ottimo elemento in più nella faretra intel" ma generalmente da i suoi vantaggi nel multi threading (1 processo con più istanze dati), nel multi processing (processi diversi con dati diversi) i casi sono da valutare, nella virtualizzazione non ho trovato mai dei bench soddisfacenti, la mia esperienza però è in genere negativa (indipendentemente dal sistema: vmware, xen, kvm o virtualbox)

EDIT: se trovate bench fatti bene sulla virtualizz. con ht e senza fatemi sapere , grazie

Interessante punto di vista. Comunque l'unico di cui vedo benchmark su virtualizzazione e multiprocessore è anandtech. Ricordo di un bench in particolare con sistemi multiprocessore fra nehalem e opteron e ricordo anche che nehalem offriva latenze minori e throughput maggiori. Insomma, non era affatto un bel vedere per l'attuale generazione AMD.

[digieffe]

Originariamente inviato da blackshard

Una riflessione su bulldozer e i sistemi operativi, scaturita dal mio post precedente.

Bulldozer avrà due core integer + una singola fpu per modulo.
Siccome in passato le occasioni fallaci non sono mancate (il tanto famigerato quanto finto bug del cool&quiet sotto windows) ho il forte dubbio delle capacità degli scheduler dei sistemi operativi di approcciare la cosa. Cosa succede, per esempio, se ho due thread che fanno uso intensivo della fpu e, malauguratamente, lo scheduler li assegna entrambi allo stesso modulo e quindi alla stessa FPU? Non sarebbe meglio se li spedisse a due moduli diversi così da occupare due FPU separate?

Un problema simile ce l'aveva intel con hyperthreading: il sistema operativo vedeva come core fisici anche i core logici "condivisi", non sfruttando appieno le potenzialità e a volte peggiorando addirittura la situazione.
Con windows 7 ci hanno messo una pezza con il core parking: in pratica i core logici diventano core di "serie B" che vengono scelti come destinatari di un processo solo se tutti i core fisici di "serie A" sono già occupati.

Ora leggevo tempo fa che con bulldozer tutti i core saranno mostrati come core fisici, mi domandavo quindi se è una buona scelta, oppure se non sia ipotizzabile che un core per modulo diventi logico per ingannare windows e sfruttare il core parking per meglio utilizzare le varie fpu.

anche se io ne sono fuori, uso solo sistemi *nix, spero che implementino diverse politiche di scheduling, semmai selezionabili.

[paolo.oliva2]

C'era stato in passato un post molto interessante sulla potenza di un procio.
A grandi linee, lo ripropongo giusto per mettere in luce altri aspetti che fanno un procio potente.
All'inizio, c'era stata la corsa al clock sempre più alto per aumentare la potenza del procio, fino a che si giunse ai limiti (esempio PIV).
In un secondo tempo, si scelse la via del multicore (il numero massimo di core es AMD) e dell'SMT (Intel), ma ora come ora qual'è il limite reale contro cui combattere per aumentare la potenza del procio? Il TDP.
Ora, se vogliamo, le idee attuali dovrebbero essere l'hyperthreading (che di fatto aumenta l'IPC del procio con un ridotto aumento del TDP in proporzione) e la filosofia BD (che diminuisce alla radice l'aumento del TDP perché condivide parti dei core con il risultato che il TDP a parità di potenza risulta inferiore).
Fermo restando che non voglio intavolare il discorso né su chi l'abbia più lungo né su chi abbia ragione, come al solito la scelta vincente sarà nella somma dei pregi e limiti di ciascuna casa.
Però, in ogni caso un dato su cui riflettere l'avremmo già:
AMD deve misurarsi con Intel e deve comunque in ogni caso poter offrire un prodotto (BD) la cui potenza necessariamente deve essere simile a quella di SB.
Allora, perché BD X4, X6 e X8 avrebbe solamente 95W e unicamente il top degli X8 sarebbe 125W? Perché AMD ha più volte annunciato che non produrrà BD nella versione 140W? Anche BD X10 sarà 125W.
In quest'ottica, mi pare scontato che AMD non possa coniugare il fatto di dover essere competitivo con i prodotti Intel e nello stesso tempo castrare BD di 30W TDP.
La mia riflessione è questa: se BD avesse un IPC basso, a maggior ragione AMD dovrebbe aumentarne il clock e di conseguenza offrire BD a 125W e magari pure a 140W.
Se AMD non agisce in questo modo, o il 32nm AMD + architettura BD permettono insieme di arrivare a clock super con un TDP ridotto, o l'IPC comunque sarebbe ottimo e non ci sarebbe bisogno di arrivare a TDP limiti per ottenere una determinata potenza.

Vedremo.

[digieffe]

Originariamente inviato da blackshard

Interessante punto di vista. Comunque l'unico di cui vedo benchmark su virtualizzazione e multiprocessore è anandtech. Ricordo di un bench in particolare con sistemi multiprocessore fra nehalem e opteron e ricordo anche che nehalem offriva latenze minori e throughput maggiori. Insomma, non era affatto un bel vedere per l'attuale generazione AMD.

chiaro che è tutto IMHO ed é solo il mio punto di vista, deduzioni (o sensazioni) tratte da un mare di bench.
Comunque appena avrò un pò di tempo verificherò qualche fonte affidabile incominciando da anand.
Sperando che le fonti siano in buona fede.


EDIT: una precisazione IMHO i bench fatti con una sola virtual machine (soprattutto se poi affinizzata ad un tot di core) non sono granche utili a valutare la situazione, per ciò che mi riguarda.
Servirebbero bench che avessero da 1..4 core fisici per ogni VM (senza impostazione affinità) e da 2 a 6 VM per CPU (4 .. 8 core fisici).

[cionci]

Originariamente inviato da iGio

HT ? QUESTE TECNOLOGIE VIRTUALI NON SONO DA PRENDERE PIù DI TANTO IN CONSIDERAZIONE. giudichiamo in base ai core fisici. per quanto riguarda il clock anche qui dobbiamo considerare la bonta dell'architettura. puo darsi che BD abbia un clock più basso ma performance uguali oppure superiori.

p.s scusa il caps lock !

Non sono d'accordo. L'HT con Sandy Bridge funziona veramente molto bene. Il problema è che all'aumentare dei core, allocare tutti quei thread diventa sempre più difficile. Ecco perché probabilmente SB non uscirà in versione X8.

Originariamente inviato da blackshard

Un problema simile ce l'aveva intel con hyperthreading: il sistema operativo vedeva come core fisici anche i core logici "condivisi", non sfruttando appieno le potenzialità e a volte peggiorando addirittura la situazione.
Con windows 7 ci hanno messo una pezza con il core parking: in pratica i core logici diventano core di "serie B" che vengono scelti come destinatari di un processo solo se tutti i core fisici di "serie A" sono già occupati.

Ora leggevo tempo fa che con bulldozer tutti i core saranno mostrati come core fisici, mi domandavo quindi se è una buona scelta, oppure se non sia ipotizzabile che un core per modulo diventi logico per ingannare windows e sfruttare il core parking per meglio utilizzare le varie fpu.

Non c'è una distinzione fra core fisici e logici su Intel, sono tutti logici. Non ci sono core di seria A e di serie B. Semplicemente è il sistema operativo a battezzare uno dei core virtuali presentati dal core fisico come core di serie A e l'altro come core di serie B. Se la scelta venisse invertita non cambierebbe di una virgola.
Per BD è esattamente la stessa cosa, solo che parte della pipeline intera non è condivisa, ma è implementata in posizioni diverse della CPU.
Quindi il core parking funzionerà esattamente allo stesso modo anche su BD, il quale trarrà vantaggio dalla priorità all'allocazione dei thread ai moduli liberi e solo successivamente ai core battezzati di "serie B". Anche perché ricordiamoci che le prestazioni con un solo core sfruttato per modulo saranno maggiori.
In pratica i thread visti dalla CPU sono a tutti gli effetti logici al pari di Intel, solo che l'implementazione della tecnologia che permette eseguire due thread per modulo è assolutamente più performante, tanto da rendere di fatto le prestazioni intere paragonabili a quelle di due core fisici.

Quindi anche sul discorso del calcolo delle prestazioni, semplicemente si dovrà fare allocando il numero massimo dei thread che la CPU può gestire.

Originariamente inviato da digieffe

http://translate.googleusercontent.c...803_dxGokMdU5A

so già che dovrebbe essere postato nel thread sulla disparita di trattamento del compilatore intel ma voglio informare anche voi!!!

Intel C / C++ 11.1 0.93 / 1,24 (SPECint_2006base / SPECfp_2006base)
Intel C / C++ 12.0 1,10 / 1,42 (SPECint_2006base / SPECfp_2006base)
other compilers 1,00 / 1,00 (SPECint_2006base / SPECfp_2006base) *

* Best of Visual Studio 2010 and PGI

1,10 / 0,93 = 1,18 (+18%)
1,42 / 1,24 = 1,14 (+14%)

complimenti a tutti i possessori di processori amd diventati più veloci del 18% sugli int e 14% sui fp


EDIT: con questi dati qual'è la reale differenza tra k10 e SB? e quale sarà tra Bd e SB???

Bellissima notizia che fa anche molto pensare su quali basi venissero realmente fatte fino ad ora le valutazioni sulle prestazioni. Riporto anche in auge la questione driver nVidia e i giochi, che sono praticamente tutti compilati con compilatori Intel. L'unica nota negativa è che per trarre giovamento da questi vantaggi passeranno non mesi, ma anni (difficilmente i progetti già iniziati cambieranno compilatore).
Tra l'altro solo qualche pagina fa avevo puntato il dito su questa questione...

[paolo.oliva2]

Ma con le AVX mi sembra che non ci possano essere "partigianità" e forse qualche cosa Windows 8 dovrebbe cambiare, spero.

La cosa migliore per verificare effettivamente la potenzialità di un procio sarebbe quella di testarla in ambiente linux .

Comunque sarebbe interessante se qualcuno intentasse una violazione dei diritti del consumatore, in quanto "preso in giro" sul fatto di far apparire proci di una marca ben più potenti e quindi praticamente giustificando il concetto "più potenza = + costo". In effetti, se il tutto si fermasse al "chi l'ha più lungo", ci si farebbe solamente una risata, peccato che il tutto è voluto unicamente per incassare di più.

[Pihippo]

Originariamente inviato da cionci

.

Bellissima notizia che fa anche molto pensare su quali basi venissero realmente fatte fino ad ora le valutazioni sulle prestazioni. Riporto anche in auge la questione driver nVidia e i giochi, che sono praticamente tutti compilati con compilatori Intel. L'unica nota negativa è che per trarre giovamento da questi vantaggi passeranno non mesi, ma anni (difficilmente i progetti già iniziati cambieranno compilatore).
Tra l'altro solo qualche pagina fa avevo puntato il dito su questa questione...

Ciao Cionci
Scusami, ma si sa qualcosa di certo sull compiler dei driver nvidia? Anche se per un driver l'aggiornamento del compiler non dovrebbe essere cosi traumatico, sono convito che le disparità tra una scheda nvida su sistema amd ed una amd su sitema amd siano da imputare a come le due architettura gestiscano gli state changes e il passaggio tra modalità kernel ed user. (costano qualcosa come 5000 cicli di cpu tanto tempo a far nulla )
Ovviamente a mia opinione e dunque ciò scritto potrebbe essere completamente sbagliato.

[cionci]

Originariamente inviato da Pihippo

Ciao Cionci
Scusami, ma si sa qualcosa di certo sull compiler dei driver nvidia? Anche se per un driver l'aggiornamento del compiler non dovrebbe essere cosi traumatico, sono convito che le disparità tra una scheda nvida su sistema amd ed una amd su sitema amd siano da imputare a come le due architettura gestiscano gli state changes e il passaggio tra modalità kernel ed user. (costano qualcosa come 5000 cicli di cpu tanto tempo a far nulla )
Ovviamente a mia opinione e dunque ciò scritto potrebbe essere completamente sbagliato.

Di solito il compilatore più performante è quello Intel, dubito che nVidia non lo usi.
Dici che non sia traumatico ? Secondo te ci sono poche istruzioni SIMD in un driver video ? Te lo chiedo perché sinceramente non ne ho idea.

[digieffe]

Originariamente inviato da Pihippo

Ciao Cionci
Scusami, ma si sa qualcosa di certo sull compiler dei driver nvidia? Anche se per un driver l'aggiornamento del compiler non dovrebbe essere cosi traumatico, sono convito che le disparità tra una scheda nvida su sistema amd ed una amd su sitema amd siano da imputare a come le due architettura gestiscano gli state changes e il passaggio tra modalità kernel ed user. (costano qualcosa come 5000 cicli di cpu tanto tempo a far nulla )
Ovviamente a mia opinione e dunque ciò scritto potrebbe essere completamente sbagliato.

ciao,
nella mia ignoranza provo a fare 2 calcoli...
con linux kernel 2.6.35, cpu in idle ho circa 1000 context switch al secondo (1 solo core attivo) 1000*5000=5.000.000 allora se è così la cpu perde 5 mhz a girarsi i pollici? se faccio fare degli accessi al disco salgo a 3000 se aggiungo il play un video da youtube (streaming rete + visualizzazione) e faccio ballare le finestre 3d a video arrivo a 8000 quindi arriverei a perdere 40 mhz (40M cicli).

Bingo ogni istanza di glxgears (diagnostico sistema grafico x) mi genera circa 4000 cambi di contesto al secondo. (20M cicli persi)

.... mmm .... premesso che stiamo parlando di sistemi diversi è come se il caso nvidia riuscisse a fare meno chiamate al kernel space

ps: senza intenzione di voler mettere in dubbio ciò ch scrivi ma per capire, come si formano quei 5000 cicli?

[digieffe]

con 5000 cicli di una cpu a 2 ghz si riuscirebbe a scrivere in una ram da 10GB/s 25k, sicuramente di più in una L3 e più ancora in L2.

non ne sono sicuro, mi sembra di aver letto che lo stato di un core di una cpu moderna è circa 45k, che possa dipendere da ciò ???