Newsgroup: it.comp.hardware.cpu
Titolo: Latenza cache delle CPU.

Stavo leggendo l'ennesima recensione sui nuovi P4, quando ho rivisto la
conferma dei dati che già sapevo sulla latenza della cache.
http://www.anandtech.com/cpuchipsets/showdoc.aspx?i=2353&p=2
Come mai tutte queste discrepanze? Sempre per 2 MB di cache L2, passiamo dai
10 cicli del P-M ai ben 27 cicli del P4 6xx. Come mai tutta questa
differenza? Insomma, da cosa dipende la latenza della cache di un
processore?
MaxArt



nei p4 a parte le pure e semplici dimensioni in gran parte suppongo
dipenda dalle necessita' di renderla ultradensa (leggi la pagina
seguente dell'articolo di anand), alcuni compromessi diventano
necessari.
quello che mi lascia basito e' la cache del p-m, 10 cicli sono davvero
pochissimi!
non mi e' riuscito di capire se si parli di banias o dothan, comunque
10 cicli per una l2 devono costargli non poco in silicio...
-- 
    (iao!!oai)                                    (ICQ: 10860566)
    //.aurizio
[WARNING!: togliete _nessuno_ per rispondere]
    Coloro che sono disposti a farsi togliere alcune liberta' 
essenziali per ottenere un piccolo, temporaneo senso di sicurezza
non meritano ne liberta' ne sicurezza. [B. Franklin]

Mi intrometto....
Il problema dei cicli di latenza dovrebbe agganciarsi al discorso della 
lunghezza della pipeline.
Badate che AMD è sui 7, sui Barton (gli ultimi non so)
Ma è lo scotto che da sempre paga Intel, relativa facilità ad incrementare 
il clock con modelli aggiornati rispetto ad AMD, ma realmente fruibile in 
applicazioni che la pipeline riesce a prevedere senza errori, ti tutto 
quello che riguarda la gestione dei flussi video.
Per il resto, l'unico modo che ha trovato Intel per sopperire (virtualmente) 
alla latenza, è stata l'introduzione di 2MB cache L2 (extreme), ma di fatto 
non riduce la latenza, ma elimina la latenza fra L2 e RAM in quanto 2MB non 
sono certo pochi...

 10 cicli per una l2 devono costargli non poco in silicio...
Sicuramente per il Dothan e' cosi'. Te lo confermo. L'accesso alla L2 di 
Dothan e' velocissimo. Se i P4 avessero una cache delle prestazioni di 
quella di dothan probabilmente sarebbero velocissimi.
Il fatto che la latenza sia cosi' alta mi fa pensare che la L2 di prescott 
sia implementata male o abbiano avuto seri problemi in questa parte della 
progettazione del processore.
-- 
Ciao
Riccardo 

lunghezza della pipeline.
no, la pipeline non ha niente a che vedere con i tempi di propagazione
dei dati nella cache.


quella di dothan probabilmente sarebbero velocissimi.
d'altra parte guarda la foto, c'e' una cache con un microscopico
processore su un lato... il processore occupera' si e no un sesto del
die...
suppongo che cambi completamente il sistema di interconnessione fra le
varie celle di memoria per aumentare la densita o ridurre la latenza.
quindi hai o l'uno o l'altro - e come al solito p-m e p4 rappresentano
perfettamente i due massimi estremi possibili :)



volevo dire un terzo... :)


 -- 
Certo che Intel fa di tutto per "tarpargli" le ali ai P4...:-\
Ciao

 Certo che Intel fa di tutto per "tarpargli" le ali ai P4...:-\
Be', più densità = die più piccolo = die più economico = processore più 
economico... è perfettamente nella logica di marketing di intel degli ultimi 
tempi: avere processori mainstream economici (per loro ;) che se la cavano 
bene contro la concorrenza =)
Piuttosto, mi chiedevo se la latenza della cache è in qualche modo occultata 
dalla "distanza" (in stadi di pipeline del processore) fra una richiesta e 
l'effettivo bisogno del dato richiesto. Non so se mi sono spiegato... tipo: 
lo stadio 3 "stabilisce" il bisogno di un certo dato, e manda la richiesta 
alla cache; lo stadio 15, che avrà bisogno di quel dato, attenderà 
(latenza-15+3) cicli per avere detto dato.
Dico tutto ciò perché in questo caso vedrei ridotta l'importanza di 
quest'alta latenza: Banias avrebbe pochi stadi per "scappare" alla latenza, 
Prescott invece molti di più, quindi subirebbe di meno l'impatto 
dell'accesso alla cache.
-- 
ColdShine
"L'esperienza è un'insegnante severa: prima ci esamina
 e solo dopo ci fa lezione." - legge di Vernon Sanders
Athlon XP 2000+ @ 3400+ (Barton/2280 MHz/1,575V)
su Jetway N2PAP-Ultra
http://coldshine.altervista.org/comp/
 

Scusate l'ignoranza, ma non potrebbe essere che il tutto dipende 
dalla velocità di clock? Clock più basso , stesse performance di 
memoria, bastano meno cicli per avere pronto il dato.
O ho detto una fesseria? (probabile).
Ciao
-- 
Inviato da Virgilio 
http://newsgroup.virgilio.it
Filtra gli antipatici, segnala le risposte, segue i thread, e tutto da web

 (latenza-15+3) cicli per avere detto dato.
Non funziona cosi` ;) Nell'attesa dei dati la pipeline e` stallata. Da
qualche parte tra la sezione di decode e quella di esecuzione viene
fatto il fetch degli operandi: se gli operandi non ci sono l'istruzione
non prosegue nella pipe (stallo).
Luca
-- 
Home: 
http://kronoz.cjb.net
"It is more complicated than you think"
                -- The Eighth Networking Truth from RFC 1925


Il discorso rimane immutato anche se ad esempio si sta usando
un applicativo che si avvantaggia dell'hyperthreading?

 non prosegue nella pipe (stallo).
Ok, quindi i processori funzionano "ancora" come ci fanno studiare 
all'università =)
No perché quando a Calcolatori Elettronici II il professore c'ha fatto 
studiare i MIPS, ho pensato "forse non è molto aggiornato" :P (non che io 
abbia da proporre qualcosa di meglio, immagino non sarebe adatto 
all'insegnamento accademico... però ci sono rimasto un po' stranito)


 un applicativo che si avvantaggia dell'hyperthreading?
Bella domanda. Forse, più che per un'attesa con cache hit, l'HT passa 
all'altro processore virtuale quando è in attesa della memoria (cache miss); 
sennò non credo abbia senso cambiare processore per poche decine di cicli. 
Tutto questo "a naso", eh! =)
Ripensandoci, perché funzionasse così sarebbe necessario che il controller 
della cache informasse le unità di esecuzione dell'esito dell'accesso PRIMA 
di aver finalmente il dato disponibile... tipo "ok unità 1, il dato ce l'ho, 
ora te lo passo" o "niente da fare unità 2, st'indirizzo non ce l'ho, mo' 
aspetti la RAM" :D


 10 cicli per una l2 devono costargli non poco in silicio...
A proposito delle cache L2 per Pentium M e Pentium 4 ...
Guardate su 
www.techreport.com
 nell'articolo:
"Intel's Pentium 4 600 series processors
  Plus: Prescott goes extreme".
Nella quarta pagina ci sono i benchmark Linpack
e Cachemem Memory Access Latency.
Sul Linpack ("deciso" dalle cache) si vede che il
Pentium M 755 (a 2Ghz e FSB400)
confrontato con i P4 6xx e con gli Extreme Edition
(FSB800 e FSB1000) inizialmente e' leggermente piu veloce
(grazie alle L1 piu grandi) e poi diventa leggermente piu lento
(a causa del FSB piu lento che lo penalizza man mano che gli
  accessi alla ram diventano sempre piu frequenti).
Sul Cachemem Memory Access Latency poi si nota che le latenze
di Pentium 4 e Pentium M sono praticamente identiche !!!!!!!!!!!
In conclusione, ad occhio e croce i "sottosistemi cache L2"
di Pentium 4 e Pentium M hanno gli stessi colli di bottiglia
(forse le pompe di carica dei circuiti della L2
  con maggior consumo di potenza ?).
L. Micheletto


si, anzi - la cosa e' ancora piu' pesante perche' la cache viene
condivisa da due "processori", per quanto virtuali questi siano, e
quindi lo spazio disponibile per ogni "processore" e' dimezzato.
e' uno dei motivi per cui i p4 giovano cosi' tanto da l2
mastodontiche.


 mastodontiche.
vale anche per i p4 NW ? dici che con ht abilitato si gioverebbe di una l2
da 2mb.. mah io non so quanto... visto la pipe piu snella dei prescott...
 e allora spigami come mai negli extreme edition hanno aggiunto un l3 da
2mb invece di aumentare l'l2 a 2mb....

 vale anche per i p4 NW ?
No, meno. I Northwood hanno una pipeline da soli 20 stadi.
MaxArt

 2mb invece di aumentare l'l2 a 2mb....
Con i recenti Xeon aventi 2MB di cache L2, come nei
P4 serie 6xx e si č notato un buon scaling nelle prestazioni...cosa
che perň non si č verificata, o quantomeno il miglioramento č
stato piů limitato in questi ultimi.

 No, meno. I Northwood hanno una pipeline da soli 20 stadi.
si la conosco la pipe dei nw..
ma all'inizio del 3d non si è detto e ribadito che la velocità della cache
L2 non dipende dalla lunghezza della pipeline? 

 No, meno. I Northwood hanno una pipeline da soli 20 stadi.
si la conosco la pipe dei nw..
ma all'inizio del 3d non si è detto e ribadito che la velocità della cache
L2 non dipende dalla lunghezza della pipeline? e poi il discorso della
cache grande il mugelli lo collegava all'ht che hanno anche i NW

 anche i NW
Infatti è dai NW che si è abilitato l'HT, che se non ricordo male era in
nuce anche dei Willamette.
MaxArt

 cache... come potrebbero fare altrimenti?
Il discorso della trace cache dovrebbe rimanere, per il resto fammi
controllare ché non vorrei aver detto fesserie :-)
Promemoria: non devo mettermi a ragionare alle 2:20!
MaxArt

2mb invece di aumentare l'l2 a 2mb....
perche' negli EE la l3 viene implementata in maniera piu' semplice
(minore associativita', minore ampiezza di bus ecc...) e quindi costa
meno da produrre e progettare (ad esempio una normale L1 occupa circa
tre-cinque volte lo spazio della l2 a pari capienza, non so
esattamente quale sia l'implementazione della l3 negli EE).


cache grande il mugelli lo collegava all'ht che hanno anche i NW
stiamo parlando dello -sfruttamento- della cache, non piu' delle
latenze pure.
se hai un processore ht e' il sistema operativo che ti assegna due
thread in contemporanea, non e' il processore a gestire la cosa.



In ogni caso anche i P4 con HT si avvantaggiano di applicativi
scritti per sfruttare il multithreading... anche se la maggiorparte
delle sezioni presenti nella cpu sono condivise, non come accade
con due processori distinti.
Ciao

 Promemoria: non devo mettermi a ragionare alle 2:20!
non dirlo a me...:) che oltretutto sono afflitto da una doppia estrazione
dentaria subita ieri..;(((((

 meno da produrre e progettare 
avevo pensato al discporso maggior semplicità di implementazione..
ma visto quello che costavano .. potevano anche sprecarsi un po..:)

 quale thread verra' caricato in cache e quanta cache questo occupera'.
ok grazie del chiarimento.

 dentaria subita ieri..;(((((
Accidenti, hia tutto il mio sostegno "morale"... :-\

 a sufficienza).
 Senza contare al fatto che di norma una cache più grande
automaticamente comporta un aumento della latenza dovuta
al controllo dei dati nella cache stessa...a parità di implementazione.
 Ciao

 Accidenti, hia tutto il mio sostegno "morale"... :-\
E già che c'eri potevi davvero scriverlo, "molare" :-D
MaxArt

 ha scritto nel messaggio
news:388rccF...@individual.net...

Non volevo infierire ulteriormente...;))

 Non volevo infierire ulteriormente...;))
Grazie per la "sin-patia" intesa alla graca!!!
Almeno oggi imbottito di antidolorifici riesco a stare davanti al pc .)
Ciao

 Non volevo infierire ulteriormente...;))
Grazie per la "sin-patia" intesa alla greca!!!


Certo che Intel fa di tutto per "tarpargli" le ali ai P4...:-\
Eh ma che deve fare, mettere un sottovaso al posto del package? :-)
-- 
ZHELGADIS THE LIGHTBRINGER (ICQ 33134824)
BAG#008,DPPSJ#000,BAT#013,TFC#012,GAM#026,ZZZZ#027,CID#027,PAN#015
"Aspettare non č mai stato un problema, per me.
Posso trascorrere piacevolmente ore e ore con l'aiuto di un buon caffč"

a sufficienza).
AFAIK, la L1 dedicata ai dati e' raddoppiata, ma la trace cache resta
sempre ferma ai suoi asfittici 12 kuops... quindi l'incremento di
latenza porta piu' danni che altro, o sbaglio?


latenza porta piu' danni che altro, o sbaglio?
in linea di massima si, come i bench dimostrano...


con due processori distinti.
Ma alla fine l'unica cosa non condivisa se non sbaglio è il set di
registri, che viene duplicato ... o no?
Già che ci sono, un po' di domande :)
Il context switch tra i due thread è deciso dal kernel dell'OS
suppongo, come nel caso di un dualP reale... sbaglio?
Altra cosa... stringi stringi il vantaggio dato dall'HT sta nel fatto
che - quando avviene un branch miss - invece di dover vuotare tutti i
20/31 stadi della pipeline si vuotano soltanto i 10/15 (ipotizzando
una suddivisione in cui il 50% della pipe contiene i dati del
processore virtuale 1 e l'altro 50% quelli del processore 2), quindi
quando uno dei due thread stalla devo vuotare soltanto metà pipe,
giusto?
Avevo letto da qualche parte (aggiungo la mia interpretazione) che
l'HT dovrebbe aiutare a sfruttare tutte le unità di esecuzione del
processore, dimodoché se il thread 1 usa (estremizzando) soltanto le
ALU e il thread 2 soltanto le FPU, i due thread possono procedere in
simultanea... vi risulta?
Ma a questo punto, quante istruzioni può caricare (per ciclo di clock)
un processore moderno? Suppongo più di una per volta... ma quante di
preciso?
-- 
ZHELGADIS THE LIGHTBRINGER (ICQ 33134824)
BAG#008,DPPSJ#000,BAT#013,TFC#012,GAM#026,ZZZZ#027,CID#027,PAN#015
"Aspettare non è mai stato un problema, per me.
Posso trascorrere piacevolmente ore e ore con l'aiuto di un buon caffè"

preciso?
non ho dati su prescott ma mi pare che north potesse avere piu' di
trenta istruzioni "issued" e quattro ritirate per ciclo (non ti fidare
di questi dati, vado a memoria)
