Newsgroup: it.comp.hardware.cpu
Titolo: Ram e duron

Da qualche parte ho letto che piu' di 128 mega di ram non vanno d'accordo
col duron, potendo causare dei colli di bottiglia e' vero?
(duron 1200@1333 con 128MB Ram)


Sul mio pc (Duron 850) ho 512MB su due DIMM da 256MB double sided
e va che e' un piacere.
L. Micheletto

 su
it.news.votazioni, se interessati.

 RAM non dovrebber esserci alcun problema di efficienza.
No, su Duron e K7 non ci sono problemi di prestazioni
legati alle dimensioni della ram installata rispetto
a quelle delle cache L2 ed L1.
Il (vecchio) problema che riguardava sia cpu Intel che AMD
su Socket 7 era dovuto al chipset.
L. Micheletto

su Socket 7 era dovuto al chipset.
No.  La  quantità  di  cache,  ovviamente,  influisce  *sempre* sulle
prestazioni (senza dire della sua struttura). Molto  a  spanne,  come
scrivevo,  un  rapporto  1/1000  o  1/2000 con la RAM va benone. Se è
parecchio superiore, i vantaggi sono raramente  apprezzabili  per  un
uso  domestico.  Se  è  parecchio  inferiore,  le  prestazioni calano
vistosamente.
Il problema a cui tu fai riferimento, relativo alla quantità  massima
di RAM cacheabile, dovuto al chipset, qui appunto non c'entra.


 vistosamente.
Giusto. A questo aggiungo che la cache L2 del Duron, essendo associativa a
16 vie, è molto efficiente anche con grandi quantitativi di ram, pur essendo
molto piccola.
Saluti.
--
 +------> Xe||oss <-------+       in real life: Wilmer Ricciotti
 | 
wirix...@libero.it
  |    * elimina il DEMONE per rispondermi *
 |     ICQ: 3233084       |  -----------------------------------------
 |IRC: Xe||oss@AzzurraNet |   No one was born to be servant or slave
 +------------------------+   Can you tell me the color of the rain?

 vistosamente.
    Quindi il mio K6-2 333Mhz con 36 KB di cache con 128MB di SDRAM
potrebbe avere prestazioni migliori se avesse meno RAM (ovviamente senza
tenere presente i sistemi operativi)? O ho capito male?
--
Enduring Freedom: Kabul&Kandahar are taken! - Come out, if you have
courage...

 tenere presente i sistemi operativi)? O ho capito male?
Si sta parlando di Duron.
Il K6-2 usa la cache montata sulla scheda madre per gestire la ram.
--
+ > Piersandro Guerrera <-> PaRRoT <-> 
par...@edengames.net
  < +
+ > ICQ: 8372114 <--> Eden.Games - 
http://www.edengames.net
  < +
-> PGP Key Available - 
http://parrot.edengames.net/pgpkey.asc
 <-
+ > News Hardware and Games <---> 
http://news.edengames.net
  < +

 Il K6-2 usa la cache montata sulla scheda madre per gestire la ram.
     Ma sei sicuro che sia montata sulla scheda madre? Potrei vederla,
allora? E' come un componente?
Thanks


 molto piccola.
[Nota: Mi inserisco qui perche non vedo il messaggio di risposta di Ghost
       ma anche per rispondere a Xe||oss]
Un momento, se il working set "medio" di quel che si esegue sta nelle cache
non importa quanta ram e' installata.
L'inghippo sta nel fatto che piu aumenta la ram installata e piu
le strutture "interne" del S.O. occupano piu spazio, ecc. ecc.
Ma qui a fare la differenza sta in come il sistema operativo
gestisce le cose.
In pratica la cpu non ha a che fare con il solo working set del programma
in esecuzione ma *anche* con quello del sistema operativo (che dipende
dalle risorse da gestire).
E' per questo che ad esempio se si da un occhiata allo sviluppo
in corso di Linux si vedono molti ritocchi al VMM e ad altre parti
"critiche" proprio per limitare il degrado delle prestazioni
al cresce dei processi e delle risorse allocate.
Il motivo per cui con un "uso domestico" si notano meno le differenze
sta proprio nel fatto che e' raro vedere un utente domestico caricare
di processi e risorse allocate il pc come avviene su un server.
L. Micheletto

delle prestazioni inferiori aumentando la RAM...
Con  certi  sistemi operativi, come w95 o 98, che utilizzano la ram a
partire dall'ultimo byte e non dal primo.
I  chipset  a  cui  ti  riferisci  limitavano  la  quantità  di   ram
cacheabile   ai  primi  64-512MB[*]  di  RAM.  Se  montavi  più  ram,
ed il tuo sistema operativo la usava a partire dal fondo,  era  quasi
come   se  non  avessi  la  cache.  Un  problema  rilevantissimo,  ma
completamente diverso rispetto a quello che discutiamo, quindi.
[*]  L'Intel VX arrivava a 128MB, per esempio (vado a memoria). Il TX
variava in base al chip-tag che montavi... (sempre a memoria).
In  sostanza: la quantità giusta di ram è quella che ti evita lo swap
(*molto* peggiore di tutti gli altri mali). Montare molta più  ram  è
inutile, e può essere apprezzabilmente dannoso.


non importa quanta ram e' installata.
Importa.  Come  sai,  la  cache, in particolare la L2, lavora in modo
n-associativo: ogni gruppo di n linee di cache (dipende  da  come  la
cache  è  costruita) può cacheare solo un certo range di indirizzi di
RAM (deciso ad ogni reset del PC,  a  seconda  di  quanta  RAM  viene
trovata).  Più  RAM hai, più indirizzi deve servire un set di n linee
di cache. Inoltre: se non usi parte della RAM, non  usi  parte  della
cache! Da ciò, il problema.


allora? E' come un componente?
Si, generalmente sono quei due integrati SMD che stanno  vicini alla cpu. 
Se e' una mb AT li trovi solitamente tra il socket 7 e i pettini delle
SIMM/DIMM.
-- 
Sidewinder  
---------------------------------------------------------------------
Blinding speed can compensate for a lot of deficiencies.
		-- David Nichols
---------------------------------------------------------------------

 cache! Da ciò, il problema.
????? Ma stiamo parlando di cache n-associative o di altro ?
L. Micheletto

????? Ma stiamo parlando di cache n-associative o di altro ?
Non credo di capir bene il motivo del tuo disappunto.
Facciamo un esempio pratico: W98 usa la  RAM  in  modo  'contiguo'  a
partire  dall'ultimo  byte  fisico.  Ciò rende il problema dei vecchi
chipset, a cui  accennavi  in  precedenza,  tanto  grave.  Ovviamente
'contiguo'  significa  che  il  SO  *tende*  ad  usare la ram in modo
incrementale, e a  riutilizzare  i  'buchi'  che  necessariamente  si
formano  (dovuti  ai processi che nascono e muoiono, che vogliono più
o meno ram, alla cache del disco che cresce e poi  diminuisce  etc.).
Inoltre  la  contiguità  si riferisce più al totale di ram usato, che
ai  parziali  destinati  alle   singole   applicazioni.   Quindi   la
frammentazione  (o  sparpagliamento)  c'è,  soprattutto  a livello di
singole applicazioni (vedi i molti deframmentatori RAM per  W9x),  ma
non  è  affatto  ragionata,  mirata a massimizzare l'efficienza della
cache.
Se ho un P2 con 512KB di cache  4-way(ricordo  bene?),  con  ciascuna
linea  di  32B,  ho 4096 set di 4 linee di cache. All'accensione vien
trovato che monto 512MB di RAM, e vien  deciso  che  ogni  set  di  4
linee  di  cache  servirà  un  blocco  *contiguo* di 128KB di RAM: il
primo set serve i primi 128KB, il secondo i successivi 128KB,  e  via
sino  alla  fine.  Se  in un dato momento capita che w98 usi solo 1/4
della ram, ovvero solo gli  ultimi  128MB  (in  ipotesi  di  perfetta
contiguità,  che  spesso può ben approssimare la realtà), ovvero solo
gli ultimi 1024 blocchi RAM, allora sta sfruttando  solo  gli  ultimi
1024  set  di 4 linee di cache, ovvero solo 1/4 della cache, perché i
restanti 3/4 si riferiscono a indirizzi RAM che sono "liberi".
Altro esempio: un'applicazione lavora con solo 128KB di  dati.  Sulla
macchina  precedente, per essere certi di averli tutti in cache, quei
128KB dovrebbero essere suddivisi in 1024 tranches da 128B  l'una,  e
ciascuna   tranches  scritta  in  un  blocco  RAM  diverso,  che  non
contenesse alcun altro byte utile  (che  altrimenti  potrebbe  essere
letto  e rubare agli altri il posto in cache). Fanno 128MB di RAM. Se
non è il programma ad esser scritto così, dubito  che  il  SO  scelga
autonomamente  questa  via,  anche con RAM a disposizione (sì, ma per
quanto tempo? che cosa succederà fra 1 secondo? vale la pena?).
Un raffronto fattibile. Installiamo w98 su una macchina con 128MB  di
RAM,  ed  impostiamo  lo  swap  a  32MB fissi, e usiamola. Poi, sulla
stessa macchina, mettiamo 768MB di RAM, dei quali  640  destinati  ad
un  disco  ram  che  lasceremo  vuoto,  e  usiamola. Nel secondo caso
sfruttiamo, se siamo fortunati, 1/6 della cache. Vediamo che  accade,
con varie applicazioni e/o bench.
Quanto sopra per chiarire come funziona l'hardware.
Veniamo ora allo  "sparpagliamento", o "frammentazione  ragionata  al
fine di massimizzare  l'efficienza  della cache", da parte del SO. Se
tale sparpagliamento *ragionato* ci fosse davvero, e fosse  efficace,
potrebbe  naturalmente  ovviare  al  problema  in  oggetto.  Resta da
vedere se e quali SO lo attuino, e come.  E'  ovvio  che  un  moderno
sistema  operativo mette a disposizione delle applicazioni uno spazio
di indirizzamento virtuale (esclusivo o condiviso), che  poi  rimappa
sulla  RAM  fisica  (lasciando perdere lo swap). Mi pare evidente che
quanto più semplice e lineare  sia  la  rimappatura,  tanto  migliori
siano  le  prestazioni.  Attendo  comunque  maggiori  informazioni da
parte tua in merito.
Nel frattempo credo che possiamo considerare i  seguenti  punti  (qui
ragiono  senza  una  gran  cognizione  di causa, però). Ammesso e non
concesso che un qualche tipo di  sparpagliamento  ragionato  ci  sia:
 1) lo  sparpagliamento  può  portare inefficienze quando comunque il
dato nella cache non ci sia, e si debba accedere alla RAM: un  trade-
off  da  tenere  in  conto,  credo,  prima  di sparpagliare troppo (i
deframmentatori RAM perché esistono? Perché deframmentare  di  solito
conviene.  Perché  la  gestione della memoria da parte di Linux viene
considerata migliore di quella dei vari w9x? Una delle ragioni è  che
la  minore  frammentazione  -  analogamente  a  quanto  avviene per i
rispettivi filesystem);
 2) ad un SO non converrebbe sparpagliare troppo (posto  che  davvero
sparpagli  mai  *ragionatamente*  al  fine di ottimizzare l'uso della
cache, del che ribadisco che non ho prove [e se me le  indicassi,  mi
faresti  un  favore.  TIA :-) ]), semplicemente perché quando dovesse
recuperare un dato in RAM dovrebbe poi  cercare,  in  elenchi  lunghi
kilometri, in quale minuscolo blocchettino l'avesse messo; 
 ;-)
 3) un  SO  non  avrebbe  criteri  certi per frammentare applicazioni
esterne, ed anche  se  glieli  passassero  esplicitamente  le  stesse
applicazioni,  potrebbero  essere  solo  stime  (non  è  detto che la
dimensione e la struttura dei dati e  la  sequenza  delle  istruzioni
che si renderanno necessarie sia nota a priori);
 4) a  seconda dei processi di volta in volta attivi e del lavoro che
fanno, immagino  che  potrebbe  facilmente  rendersi  necessaria  una
riorganizzazione     dello     sparpagliamento,     per     mantenere
l'ottimizzazione: riorganizzazione che  porterebbe  via  un  mare  di
tempo,  se fosse frequente. Se non si può riorganizzare spesso, mi sa
che siamo daccapo.
Perciò contesto che lo sparpagliamento possa servire  davvero,  posto
che sia in qualche modo ragionato.


 restanti 3/4 si riferiscono a indirizzi RAM che sono "liberi".
No, anche nell'esempio che fai, sfrutti *tutte* le linee di cache
a disposizione.
Il meccanismo di partizionamento degli indirizzi che descrivi
assegna i range in spezzoni di 128KB (1/4 di 512KB) "alternati" quindi
che ci siano 16MB, 64MB,128MB,256MB o anche 4GB le cose non cambiano
quanto a "copertura" degli indirizzi di memoria.
Non e' che forse ti stai confondendo con il meccanismo
di gestione delle page table della memoria virtuale ? 
L. Micheletto

quanto a "copertura" degli indirizzi di memoria.
Uhm...
Il  fatto  che  ogni range di RAM sia di 128KB dipende dalla quantità
di RAM montata, non dal fatto che 128KB siano un quarto  della  cache
4way:  se monto solo 64MB di RAM, ogni range di RAM sarà di 16KB, no?
A parte ciò, tu mi dici che ogni range di RAM (che fa riferimento  al
suo  set  di  4  linee di cache che lo 'cacheano') non è contiguo, ma
frammentato? Anche su questo GTREVIZE  non  pare  d'accordo.  Esempio
fittizio  con  8000B  di ram e 10 righe di cache in 5 set 2way, cito:
RAM (byte)		CACHE (riga)
0-1599             0,1
1600-3199          2,3
...                ...
6400-7999          8,9
Va da sé che, se ho scritto cavolate, mi scuso con te  e  con  tutti.


PREMESSA: Sto procedendo a memoria, quindi se qualcuno nota errori
          mi corregga senza problemi.
Iniziamo con il caso piu semplice: cache direct mapped (1-associativa).
Se hai una cache direct mapped da 512KB con linee da 32byte
hai 16384 linee di cache
La prima linea mappa gli indirizzi  0, 1*512K, 2*512K, ..., N*512K;
la seconda linea mappa gli indirizzi 1, 1+(1*512K),1+(2*512K), .. , 1 + N*512K;
la terza linea mappa gli indirizzi 2, 2+(1*512K),2+(2*512K), .. , 2 + N*512K;
ecc. ecc.
Quindi non puoi caricare in cache la linea che inizia all' indirizzo M
insieme a quella che inizia ad M+N*512K.
Una cache direct mapped e' molto semplice da realizzare, basta associare
ad ogni linea un registro ausiliario (tag) che memorizza la parte alta
dell'indirizzo caricato (in modo da fare i confronti e capire se una linea
e' gia caricata oppure no).
Con ad esempio una cache da 512KB (19bit di indirizzo per "coprire"
tutto il range) i singoli "registri" tag richiedono 32-19 = 13 bit 
per ogni linea da 32byte (che sono 256bit, quindi il registro tag 
"costa poco"). I tag contengono i 13 bit piu alti
dell'indirizzo di memoria mappato sulla linea corrispondente.
Una cache direct mapped e' molto veloce perche per sapere se la linea che
inizia all'indirizzo N e' presente in cache, basta indirizzare la linea 
di indice ((N MOD dimensione_cache) DIV dimensione_linea_di_cache)
[nel nostro caso ((N DIV 512K) DIV 32) dove visto che i valori
 eccetto N sono potenze di due, il risultato lo si ottiene
 "estraendo" i bit da bit5 a bit18 dell' indirizzo a 32bit]
e fare un confronto del suo tag con (N DIV (dimensione_cache)
[bit da bit19 a bit31 dell'indirizzo a 32bit].
[N.B. DIV e' la divisione intera 
    e MOD e' l'operazione resto di divisione intera]
Ovviamente, per quanto semplici, le cache direct mapped non sono 
ultra efficienti (specialmente se si beccano casi patologici
con un sacco di dati a multipli della dimensione della cache).
Per ovviare a questo si passa an un modello piu complesso: ovvero
la cache K-associativa (K-way associative) con K numero costante.
Prendiamo il caso di una cache 4-way associative.
Con una cache 4-way associative da 512KB con linee da 32byte
abbiamo sempre 16384 linee, ma questa volta
Il range di memoria "coperto" e' 512K/4 = 128K (17 bit di indirizzo)
e ad ogni gruppo di indirizzi con i 17bit piu bassi uguali
vengono associate 4 linee di cache.
In pratica le 16384 linee sono suddivise in 4096 "gruppi"
(dove ad ogni gruppo appartengono 4 linee).
Il modello 4-associativo "generico" prevede la seguente mappatura:
Il primo GRUPPO mappa gli indirizzi 0, 1*128K, 2*128K, ..., N*128K;
il secondo GRUPPO mappa gli indirizzi 1, 1+1*128K, 1+2*128K, ..., 1+N*128K
e cosi via.
Per vedere se una linea e' gia stata caricata in cache
questa volta prima si seleziona il gruppo (sfruttando
la parte bassa dell'indirizzo come si fa con la cache
direct mapped) e poi si guarda se una delle 4 linee
del gruppo ha il tag uguale alla parte alta.
Il "costo" rispetto alla cache direct mapped sono tag
leggermente piu lunghi (2 bit in piu passando da direct mapped
a 4-way) ED IL CONFRONTO con piu tag (che puo essere
eseguito molto velocemente usando un circuito a memoria associativa
che fa un confronto "simultaneo" dei tag).
La cosa importante da notare e' che i tag rappresentano
sempre "la parte alta" degli indirizzi, quindi se una cpu
e' certificata per gestire con la cache indirizzi a 32bit
deve avere tag di indirizzo a sufficienza per gestire
32bit di indirizzamento, non ha senso che si "autoconfiguri"
(visto che le cache delle cpu hanno associativita e dimensione
 *fisse*).
Oltre a questo c'e' la circuiteria associativa che ha un suo
peso sulle prestazioni massime ottenibili e sull'occupazione
di spazio sul chip.
E' a questo punto che entrano in gioco i "trucchi" per abbassare
la complessita' del circuito di confronto dei tag, aumentarne
la velocita oppure l'associativita e magari ridurre pure il numero
di bit per tag.
Se si usasse lo schema che Ghost ha descritto in precedenza
alcuni bit del tag verrebbero "fissati" tramite un semplice
circuito combinatorio (2 bit nel caso di
cache 4-way) in modo da risparmiare qualcosa (con l'aiutino
di un circuitino interno alla circuiteria di confronto
dei tag che assegna bit "fissi" diversi alle linee id un gruppo
in base al massimo indirizzo di ram installata), ma al costo di
ridurre l'efficienza della cache ad ogni raddoppio della ram ed
il risultato sarebbe equivalente  a 4 cache direct mapped che si
spartiscono "in quarti" la ram.
NON HO NOTIZIE che si utilizzi uno schema simile (anche perche non sarebbe
un comune schema n-associativo, sarebbe roba da proteggere con un bel
brevetto e magari con un nome tutto suo da poter usare per impressionare
i non-tecnici).
Ma anche se si usasse, visto che tutti i S.O. "decenti" implementano
la memoria virtuale, basta che le pagine di memoria virtuale vengano
"spartite equamente" mappandole tra i vari spezzoni "direct mapped" e 
la perdita di prestazioni viene annullata dal S.O. (per questo
mi sembra strano che ci siano questi fantomatici cali).
Un altro motivo per cui sono perplesso e' che non ho mai
sentito che simili schemi di allocazione "per bilanciare l'uso
della cache" siano usati da Windows oppure da Linux
[e specialmente parlando di Linux, non passa mese che qualcuno
 non aggiunga qualche cosa di nuovo che da un ulteriore spinta
 alle prestazioni del sistema di gestione della memoria, possibile
 che una cosa simile non venga mai citata ?].
L. Micheletto

Va da sé che, se ho scritto cavolate, mi scuso con te  e  con  tutti.
Dal mio corso di Architettura dei calcolatori:
Se ho (per semplificare) 200 righe di cache da 8 bit 2-way e 1000 byte
di RAM:
il primo byte può essere messo in una delle prime due righe
il secondo nella 3^ o nella 4^
il terzo nella 5^ / 6^ riga
...
100° byte -> 199^-200^ riga
101° byte -> di nuovo nella 1^ o 2^ riga
e così via... proprio per evitare il problema di cui parlavi tu!
-- 
ZHELGADIS THE LIGHTBRINGER (ICQ 33134824)
Tessera #008 B.A.G., #000 DPPSJ, #013 B.A.T
"Il Grande Fratello? Non lo farei mai vedere ai miei figli."
(Giovanni Modina, direttore di Canale 5)

variava in base al chip-tag che montavi... (sempre a memoria).
VX e TX -> 64 MB
HX -> da 64 a 512, a seconda della TAG-RAM


spartiscono "in quarti" la ram.
Non direi.
Il mio schema è equivalente a 4 direct mapped, ciascuna di 4096 linee
di cui *ciascuna* delle quattro mappa tutta la  RAM;  ovvero  a  4096
cache  fully  associative, ciascuna di 4 linee, che si spartiscano la
RAM in 4096 blocchettini. Ovvero è equivalente al tuo schema, con una
semplice differenza: tu dici che il primo set di linee di cache mappa
gli  indirizzi  RAM  0, 1*128K, 2*128K, 3*218K...  (lasciamo  perdere
quanto visto sopra), io dico che il primo set mappa 0,1,2,3... -e gli
altri set si comportano di conseguenza, naturalmente.
Ehm... avrei finito.
Ho scritto 'sto articolo, che sono ancora un po' assonnato.
Speriamo bene.


di  RAM ampie 32byte, non 1 byte. Affronto meglio la cosa in seguito.
Volevo dire il contrario: nel tuo esempio le porzioni sono in 
blocchetti di un byte, mentre in realtà sono in blocchetti di 32 
byte contigui alla volta.
Il seguito chiariva, in ogni caso.


(x DIV 32)*32 +31
A parte questo lapsus, il discorso che facevo va bene.
Beh,  non c'è due senza tre... vediamo quale sarà la prossima cazzata
che trovo.


 altri set si comportano di conseguenza, naturalmente.
Era questo che intendevo per dividere "in quarti" la ram installata.
Il "circuitino" che descrivevo (che "fissa" i bit piu significativi
dell'indirizzo massimo valido in base alla quantita di ram installata)
non fa altro che selezionare la dimensione delle sezioni mappate.
L. Micheletto

HX -> da 64 a 512, a seconda della TAG-RAM
ho una scheda HX con 256k saldati, non upgradabili, che arriva solo
fino a 64, anche se ha 3 banchi di simm (192MB max). indovinate il
produttore ? :)

produttore ? :)
 
anche le famosissime asus hx avevano questo bruttissimo difetto, ma
almeno in alcune revisioni c'era il connettore per espandere la l2...
--
    (iao!!oai)                                    (ICQ: 10860566)
    //.aurizio
[WARNING!: togliete _nessuno_ per rispondere]
    Time may change me
    But I can't trace time

almeno in alcune revisioni c'era il connettore per espandere la l2...
no, questa e' intel (e non ha nemmeno l'alimentazione doppia per la
cpu...). cmq alcune versioni avevano il connettore COAST (c'e' lo spazio
su scheda...)

 fino a 128MB (specifiche da manuale scaricato dalla rete).
Anche 430vx arrivava a 128 mb e il tx a 256 mb di ram ma solo 64mb erano
coperti dalla cache
By ALex 9000